< draft-ietf-mpls-sr-over-ip-06.txt   draft-ietf-mpls-sr-over-ip-07.txt >
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Alibaba, Inc Internet-Draft Alibaba, Inc
Intended status: Standards Track S. Bryant Intended status: Standards Track S. Bryant
Expires: November 24, 2019 Huawei Expires: December 18, 2019 Huawei
A. Farrel A. Farrel
Old Dog Consulting Old Dog Consulting
S. Hassan S. Hassan
Cisco Cisco
W. Henderickx W. Henderickx
Nokia Nokia
Z. Li Z. Li
Huawei Huawei
May 23, 2019 June 16, 2019
SR-MPLS over IP SR-MPLS over IP
draft-ietf-mpls-sr-over-ip-06 draft-ietf-mpls-sr-over-ip-07
Abstract Abstract
MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source
routing paradigm in which the sender of a packet is allowed to routing paradigm in which the sender of a packet is allowed to
partially or completely specify the route the packet takes through partially or completely specify the route the packet takes through
the network by imposing stacked MPLS labels on the packet. SR-MPLS the network by imposing stacked MPLS labels on the packet. SR-MPLS
can be leveraged to realize a source routing mechanism across MPLS, can be leveraged to realize a source routing mechanism across MPLS,
IPv4, and IPv6 data planes by using an MPLS label stack as a source IPv4, and IPv6 data planes by using an MPLS label stack as a source
routing instruction set while making no changes to SR-MPLS routing instruction set while making no changes to SR-MPLS
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2019. This Internet-Draft will expire on December 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5
3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5
3.1.1. FIB Construction Example . . . . . . . . . . . . . . 6 3.1.1. FIB Construction Example . . . . . . . . . . . . . . 6
3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 8 3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 8
3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 9
3.2.2. Packet Forwarding without Penultimate Hop Popping . . 10 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 10
3.2.3. Additional Forwarding Procedures . . . . . . . . . . 11 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls]
is an MPLS data plane-based source routing paradigm in which the is an MPLS data plane-based source routing paradigm in which the
sender of a packet is allowed to partially or completely specify the sender of a packet is allowed to partially or completely specify the
route the packet takes through the network by imposing stacked MPLS route the packet takes through the network by imposing stacked MPLS
labels on the packet. SR-MPLS uses an MPLS label stack to encode a labels on the packet. SR-MPLS uses an MPLS label stack to encode a
source routing instruction set. This can be used to realize a source source routing instruction set. This can be used to realize a source
routing mechanism that can operate across MPLS, IPv4, and IPv6 data routing mechanism that can operate across MPLS, IPv4, and IPv6 data
planes. This approach makes no changes to SR-MPLS specifications and planes. This approach makes no changes to SR-MPLS specifications and
allows interworking with SR-MPLS implementations. More specifically, allows interworking with SR-MPLS implementations. More specifically,
the source routing instruction set information contained in a source the source routing instruction set information contained in a source
routed packet could be uniformly encoded as an MPLS label stack no routed packet could be uniformly encoded as an MPLS label stack no
matter whether the underlay is IPv4, IPv6, or MPLS. matter whether the underlay is IPv4, IPv6 (including Segment Routing
for IPv6 (SRv6) [RFC8354]), or MPLS.
This document describes how SR-MPLS capable routers and IP-only This document describes how SR-MPLS capable routers and IP-only
routers can seamlessly co-exist and interoperate through the use of routers can seamlessly co-exist and interoperate through the use of
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in-
UDP [RFC7510]. UDP [RFC7510].
Section 2 describes various use cases for the tunneling SR-MPLS over Section 2 describes various use cases for the tunneling SR-MPLS over
IP. Section 3 describes a typical application scenario and how the IP. Section 3 describes a typical application scenario and how the
packet forwarding happens. packet forwarding happens.
skipping to change at page 3, line 31 skipping to change at page 3, line 32
[I-D.ietf-spring-segment-routing-mpls]. [I-D.ietf-spring-segment-routing-mpls].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Use Cases 2. Use Cases
Tunneling SR-MPLS using IPv4 and/or IPv6 tunnels is useful at least Tunneling SR-MPLS using IPv4 and/or IPv6 (including SRv6) tunnels is
in the use cases listed below. In all cases, this can be enabled useful at least in the use cases listed below. In all cases, this
using an IP tunneling mechanism such as MPLS-in-UDP as described in can be enabled using an IP tunneling mechanism such as MPLS-in-UDP as
[RFC7510]. The tunnel selected MUST have its remote end point described in [RFC7510]. The tunnel selected MUST have its remote end
(destination) address equal to the address of the next SR-MPLS point (destination) address equal to the address of the next SR-MPLS
capable node identified as being on the SR path (i.e., the egress of capable node identified as being on the SR path (i.e., the egress of
the active segment). The local end point (source) address is set to the active segment). The local end point (source) address is set to
an address of the encapsulating node. [RFC7510] gives further advice an address of the encapsulating node. [RFC7510] gives further advice
on how to set the source address if the UDP zero-checksum mode is on how to set the source address if the UDP zero-checksum mode is
used with MPLS-in-UDP. used with MPLS-in-UDP. Using UDP as the encapsulation may be
particularly beneficial because it is agnostic of the underlying
transport.
o Incremental deployment of the SR-MPLS technology may be o Incremental deployment of the SR-MPLS technology may be
facilitated by tunneling SR-MPLS packets across parts of a network facilitated by tunneling SR-MPLS packets across parts of a network
that are not SR-MPLS as shown in Figure 1. This demonstrates how that are not SR-MPLS as shown in Figure 1. This demonstrates how
islands of SR-MPLS may be connected across a legacy network. It islands of SR-MPLS may be connected across a legacy network. It
may be particularly useful for joining sites (such as data may be particularly useful for joining sites (such as data
centers). centers).
________________________ ________________________
_______ ( ) _______ _______ ( ) _______
skipping to change at page 8, line 8 skipping to change at page 8, line 8
bound of the SRGB of E bound of the SRGB of E
When forwarding the packet according to the constructed FIB entry the When forwarding the packet according to the constructed FIB entry the
router encapsulates the packet according to the encapsulation as router encapsulates the packet according to the encapsulation as
advertised using the mechanisms described in advertised using the mechanisms described in
[I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-isis-encapsulation-cap] or
[I-D.ietf-ospf-encapsulation-cap]). It then sends the packets [I-D.ietf-ospf-encapsulation-cap]). It then sends the packets
towards the next hop NHi. towards the next hop NHi.
Note that [RFC7510] specifies the use of port number 6635 to indicate
that the payload of a UDP packet is MPLS, and port number 6636 for
MPLS-in-UDP utilizing DTLS. However,
[I-D.ietf-isis-encapsulation-cap] and
[I-D.ietf-ospf-encapsulation-cap] provide dynamic protocol mechanisms
to configure the use any Dynamic Port for a tunnel that uses UDP
encapsulation. Nothing in this document prevents the use of an IGP
or any other mechanism to negotiate the use of a Dynamic Port when
UDP encapsulation is used for SR-MPLS, but if no such mechanism is
used then the port numbers specified in [RFC7510] are used.
3.2. Packet Forwarding Procedures 3.2. Packet Forwarding Procedures
[RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS-
in-UDP. This approach is applicable where IP-based encapsulation for in-UDP. This approach is applicable where IP-based encapsulation for
MPLS is required and further fine-grained load balancing of MPLS MPLS is required and further fine-grained load balancing of MPLS
packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link
Aggregation Groups (LAGs) is also required. This section provides Aggregation Groups (LAGs) is also required. This section provides
details about the forwarding procedure when UDP encapsulation is details about the forwarding procedure when UDP encapsulation is
adopted for SR-MPLS over IP. Other encapsulation and tunnelling adopted for SR-MPLS over IP. Other encapsulation and tunnelling
mechanisms can be applied using similar techniques, but for clarity mechanisms can be applied using similar techniques, but for clarity
skipping to change at page 11, line 46 skipping to change at page 11, line 46
Non-MPLS Interfaces: Although the description in the previous two Non-MPLS Interfaces: Although the description in the previous two
sections is based on the use of prefix-SIDs, tunneling SR-MPLS sections is based on the use of prefix-SIDs, tunneling SR-MPLS
packets is useful when the top label of a received SR-MPLS packet packets is useful when the top label of a received SR-MPLS packet
indicates an adjacency-SID and the corresponding adjacent node to indicates an adjacency-SID and the corresponding adjacent node to
that adjacency-SID is not capable of MPLS forwarding but can still that adjacency-SID is not capable of MPLS forwarding but can still
process SR-MPLS packets. In this scenario the top label would be process SR-MPLS packets. In this scenario the top label would be
replaced by an IP tunnel toward that adjacent node and then replaced by an IP tunnel toward that adjacent node and then
forwarded over the corresponding link indicated by the adjacency- forwarded over the corresponding link indicated by the adjacency-
SID. SID.
When to use IP-based Tunnel: The description in the previous two When to use IP-based Tunnels: The description in the previous two
sections is based on the assumption that MPLS-over-UDP tunnel is sections is based on the assumption that MPLS-over-UDP tunnel is
used when the nexthop towards the next segment is not MPLS- used when the nexthop towards the next segment is not MPLS-
enabled. However, even in the case where the nexthop towards the enabled. However, even in the case where the nexthop towards the
next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the
next segment could still be used instead due to local policies. next segment could still be used instead due to local policies.
For instance, in the example as described in Figure 4, assume F is For instance, in the example as described in Figure 4, assume F is
now an SR-MPLS-capable transit node while all the other now an SR-MPLS-capable transit node while all the other
assumptions remain unchanged: since F is not identified by a SID assumptions remain unchanged: since F is not identified by a SID
in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS
LSP according to local policies, router E replaces the current top LSP according to local policies, router E replaces the current top
skipping to change at page 12, line 23 skipping to change at page 12, line 23
resulting packet is further encapsulated in IP for transmission. resulting packet is further encapsulated in IP for transmission.
IPv4 or IPv6 may be used according to the capabilities of the IPv4 or IPv6 may be used according to the capabilities of the
network. The address fields are set as described in Section 2. network. The address fields are set as described in Section 2.
The other IP header fields (such as the ECN field [RFC6040], the The other IP header fields (such as the ECN field [RFC6040], the
DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP- DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP-
encapsulated segment SHOULD be configurable according to the encapsulated segment SHOULD be configurable according to the
operator's policy: they may be copied from the header of the operator's policy: they may be copied from the header of the
incoming packet; they may be promoted from the header of the incoming packet; they may be promoted from the header of the
payload packet; they may be set according to instructions payload packet; they may be set according to instructions
programmed to be associated with the SID; or they may be programmed to be associated with the SID; or they may be
configured dependent on the outgoing interface and payload. configured dependent on the outgoing interface and payload. The
TTL field setting in the encapsulating packet header is handled as
described in [RFC7510] which refers to [RFC4023].
Entropy and ECMP: When encapsulating an MPLS packet with an IP Entropy and ECMP: When encapsulating an MPLS packet with an IP
tunnel header that is capable of encoding entropy (such as tunnel header that is capable of encoding entropy (such as
[RFC7510]), the corresponding entropy field (the source port in [RFC7510]), the corresponding entropy field (the source port in
the case of a UDP tunnel) MAY be filled with an entropy value that the case of a UDP tunnel) MAY be filled with an entropy value that
is generated by the encapsulator to uniquely identify a flow. is generated by the encapsulator to uniquely identify a flow.
However, what constitutes a flow is locally determined by the However, what constitutes a flow is locally determined by the
encapsulator. For instance, if the MPLS label stack contains at encapsulator. For instance, if the MPLS label stack contains at
least one entropy label and the encapsulator is capable of reading least one entropy label and the encapsulator is capable of reading
that entropy label, the entropy label value could be directly that entropy label, the entropy label value could be directly
skipping to change at page 13, line 29 skipping to change at page 13, line 31
It is difficult for an attacker to pass a raw MPLS encoded packet It is difficult for an attacker to pass a raw MPLS encoded packet
into a network and operators have considerable experience at into a network and operators have considerable experience at
excluding such packets at the network boundaries, for example by excluding such packets at the network boundaries, for example by
excluding all packets that are revealed to be carrying an MPLS packet excluding all packets that are revealed to be carrying an MPLS packet
as the payload of IP tunnels. Further discussion of MPLS security is as the payload of IP tunnels. Further discussion of MPLS security is
found in [RFC5920]. found in [RFC5920].
It is easy for a network ingress node to detect any attempt to It is easy for a network ingress node to detect any attempt to
smuggle an IP packet into the network since it would see that the UDP smuggle an IP packet into the network since it would see that the UDP
destination port was set to MPLS, and such filtering SHOULD be destination port was set to MPLS, and such filtering SHOULD be
applied. SR packets not having a destination address terminating in applied. If, however, the mechanisms described in
the network would be transparently carried and would pose no [I-D.ietf-ospf-segment-routing-extensions] or
different security risk to the network under consideration than any [I-D.ietf-isis-segment-routing-extensions] are applied, a wider
other traffic. variety of UDP port numbers might be in use making port filtering
harder.
SR packets not having a destination address terminating in the
network would be transparently carried and would pose no different
security risk to the network under consideration than any other
traffic.
Where control plane techniques are used (as described in Section 3), Where control plane techniques are used (as described in Section 3),
it is important that these protocols are adequately secured for the it is important that these protocols are adequately secured for the
environment in which they are run as discussed in [RFC6862] and environment in which they are run as discussed in [RFC6862] and
[RFC5920]. [RFC5920].
6. Contributors 6. Contributors
Ahmed Bashandy Ahmed Bashandy
Individual Individual
skipping to change at page 15, line 6 skipping to change at page 15, line 12
Individual Individual
Email: jefftant@gmail.com Email: jefftant@gmail.com
7. Acknowledgements 7. Acknowledgements
Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica,
Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert
Sparks, and Al Morton for their insightful comments on this draft. Sparks, and Al Morton for their insightful comments on this draft.
Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer
Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and Dawkins, Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and Eric
resulting comments. Vyncke for careful reviews and resulting comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-22 data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), May 2019. (work in progress), May 2019.
skipping to change at page 15, line 34 skipping to change at page 15, line 40
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
skipping to change at page 16, line 35 skipping to change at page 16, line 44
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
Routing Header (SRH)", draft-ietf-6man-segment-routing- Routing Header (SRH)", draft-ietf-6man-segment-routing-
header-19 (work in progress), May 2019. header-21 (work in progress), June 2019.
[I-D.ietf-bess-datacenter-gateway] [I-D.ietf-bess-datacenter-gateway]
Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil, Farrel, A., Drake, J., Rosen, E., Patel, K., and L. Jalil,
"Gateway Auto-Discovery and Route Advertisement for "Gateway Auto-Discovery and Route Advertisement for
Segment Routing Enabled Domain Interconnection", draft- Segment Routing Enabled Domain Interconnection", draft-
ietf-bess-datacenter-gateway-02 (work in progress), ietf-bess-datacenter-gateway-02 (work in progress),
February 2019. February 2019.
[I-D.ietf-isis-encapsulation-cap] [I-D.ietf-isis-encapsulation-cap]
Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras,
skipping to change at page 17, line 33 skipping to change at page 17, line 39
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018. routing-extensions-27 (work in progress), December 2018.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000, RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>. <https://www.rfc-editor.org/info/rfc2983>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
 End of changes. 17 change blocks. 
27 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/