draft-ietf-mpls-sr-over-ip-02.txt   draft-ietf-mpls-sr-over-ip-03.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: June 21, 2019 Huawei Expires: September 4, 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
December 18, 2018 March 3, 2019
SR-MPLS over IP SR-MPLS over IP
draft-ietf-mpls-sr-over-ip-02 draft-ietf-mpls-sr-over-ip-03
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
could be leveraged to realize a source routing mechanism across MPLS, could 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 preserving backward compatibility with routing instruction set while preserving backward compatibility with
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 June 21, 2019. This Internet-Draft will expire on September 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8
3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9
3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 could be leveraged to realize a source labels on the packet. SR-MPLS uses an MPLS label stack to encode a
routing mechanism across MPLS, IPv4, and IPv6 data planes by using an source routing instruction set. This can be used to realize a source
MPLS label stack as a source routing instruction set while preserving routing mechanism that can operate across MPLS, IPv4, and IPv6 data
backward compatibility with SR-MPLS. More specifically, the source planes. This approach preserves backward compatibility with SR-MPLS.
routing instruction set information contained in a source routed More specifically, the source routing instruction set information
packet could be uniformly encoded as an MPLS label stack no matter contained in a source routed packet could be uniformly encoded as an
whether the underlay is IPv4, IPv6, or MPLS. MPLS label stack no matter whether the underlay is IPv4, IPv6, 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 35 skipping to change at page 3, line 36
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 tunnels is useful at least
in the following use cases: in the following use cases:
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 enabled using an IP tunneling mechanism such that are not SR-MPLS enabled using an IP tunneling mechanism such
as MPLS-in-UDP [RFC7510]. The tunnel destination address is the as MPLS-in-UDP [RFC7510]. The tunnel selected MUST have its
address of the next SR-MPLS capable node along the path (i.e., the remote end point (destination) address equal to the address of the
egress of the active node segment). This is shown in Figure 1. next SR-MPLS capable node along the path (i.e., the egress of the
active node segment). This is shown in Figure 1.
________________________ ________________________
_______ ( ) _______ _______ ( ) _______
( ) ( IP Network ) ( ) ( ) ( IP Network ) ( )
( SR-MPLS ) ( ) ( SR-MPLS ) ( SR-MPLS ) ( ) ( SR-MPLS )
( Network ) ( ) ( Network ) ( Network ) ( ) ( Network )
( -------- -------- ) ( -------- -------- )
( | Border | SR-in-UDP Tunnel | Border | ) ( | Border | SR-in-UDP Tunnel | Border | )
( | Router |========================| Router | ) ( | Router |========================| Router | )
( | R1 | | R2 | ) ( | R1 | | R2 | )
( -------- -------- ) ( -------- -------- )
( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( )
(_______) ( ) (_______) (_______) ( ) (_______)
(________________________) (________________________)
Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites
o If encoding of entropy is desired, IP tunneling mechanisms that o If encoding of entropy ([RFC6790] is desired, IP tunneling
allow encoding of entropy, such as MPLS-in-UDP encapsulation mechanisms that allow encoding of entropy, such as MPLS-in-UDP
[RFC7510] where the source port of the UDP header is used as an encapsulation [RFC7510] where the source port of the UDP header is
entropy field, may be used to maximize the utilization of ECMP used as an entropy field, may be used to maximize the utilization
and/or LAG, especially when it is difficult to make use of entropy of ECMP and/or LAG, especially when it is difficult to make use of
label mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) the entropy label mechanism. Refer to
for more discussion about using entropy label in SR-MPLS. [I-D.ietf-mpls-spring-entropy-label]) for more discussion about
using entropy labels in SR-MPLS.
o Tunneling MPLS into IP provides a technology that enables SR in an o Tunneling MPLS into IP provides a technology that enables SR in an
IPv4 and/or IPv6 network where the routers do not support SRv6 IPv4 and/or IPv6 network where the routers do not support SRv6
capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS
forwarding is not an option. This is shown in Figure 2. forwarding is not an option. This is shown in Figure 2.
__________________________________ __________________________________
__( IP Network )__ __( IP Network )__
__( )__ __( )__
( -- -- -- ) ( -- -- -- )
skipping to change at page 6, line 5 skipping to change at page 6, line 5
or all of the next-hops along the shortest path towards a prefix or all of the next-hops along the shortest path towards a prefix
Segment Identifier (prefix-SID) are IP-only routers. Segment Identifier (prefix-SID) are IP-only routers.
Consider router A that receives a labeled packet with top label L(E) Consider router A that receives a labeled packet with top label L(E)
that corresponds to the prefix-SID SID(E) of prefix P(E) advertised that corresponds to the prefix-SID SID(E) of prefix P(E) advertised
by router E. Suppose the i-th next-hop router (termed NHi) along the by router E. Suppose the i-th next-hop router (termed NHi) along the
shortest path from router A toward SID(E) is not SR-MPLS capable shortest path from router A toward SID(E) is not SR-MPLS capable
while both routers A and E are SR-MPLS capable. The following while both routers A and E are SR-MPLS capable. The following
processing steps apply: processing steps apply:
o Router E is SR-MPLS capable so it advertises the SRGB as described o The Segment Routing Global Block (SRGB) is defined in [RFC8402].
Router E is SR-MPLS capable, so it advertises an SRGB as described
in [I-D.ietf-ospf-segment-routing-extensions] and in [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
o When Router E advertises the prefix-SID SID(E) of prefix P(E) it o When Router E advertises the prefix-SID SID(E) of prefix P(E) it
MUST also advertise the encapsulation endpoint and the tunnel type MUST also advertise the encapsulation endpoint and the tunnel type
of any tunnel used to reach E. It does this using the mechanisms of any tunnel used to reach E. It does this using the mechanisms
described in [I-D.ietf-isis-encapsulation-cap] or described in [I-D.ietf-isis-encapsulation-cap] or
[I-D.ietf-ospf-encapsulation-cap]. [I-D.ietf-ospf-encapsulation-cap].
o If A and E are in different IGP areas/levels, then: o If A and E are in different IGP areas/levels, then:
skipping to change at page 7, line 10 skipping to change at page 7, line 10
* If the NP flag in OSPF or the P flag in ISIS is clear: * If the NP flag in OSPF or the P flag in ISIS is clear:
pop the top label pop the top label
* If the NP flag in OSPF or the P flag in ISIS is set: * If the NP flag in OSPF or the P flag in ISIS is set:
swap the top label to a value equal to SID(E) plus the lower swap the top label to a value equal to SID(E) plus the lower
bound of the SRGB of E bound of the SRGB of E
* Encapsulate the packet according to the encapsulation Once constructed, the FIB can be used to tell a router how to process
advertised in [I-D.ietf-isis-encapsulation-cap] or packets. It encapsulates the packets according to the encapsulation
[I-D.ietf-ospf-encapsulation-cap] advertised in [I-D.ietf-isis-encapsulation-cap] or
[I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards
* Send the packet towards the next hop NHi. the next hop NHi.
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, which is applicable in some circumstances where IP-based in-UDP. This approach is applicable where IP-based encapsulation for
encapsulation for MPLS is required and further fine-grained load MPLS is required and further fine-grained load balancing of MPLS
balancing of MPLS packets over IP networks over Equal-Cost Multipath packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link
(ECMP) and/or Link Aggregation Groups (LAGs) is required as well. Aggregation Groups (LAGs) is also required. This section provides
This section provides details about the forwarding procedure when details about the forwarding procedure when when UDP encapsulation is
when UDP encapsulation is adopted for SR-MPLS over IP. adopted for SR-MPLS over IP.
Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all
of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes
may be "legacy routers" that cannot handle SR-MPLS packets but can may be "legacy routers" that cannot handle SR-MPLS packets but can
forward IP packets. An SR-MPLS-capable node may advertise its forward IP packets. An SR-MPLS-capable node MAY advertise its
capabilities using the IGP as described in Section 3. There are six capabilities using the IGP as described in Section 3. There are six
types of node in an SR-MPLS domain: types of node in an SR-MPLS domain:
o Domain ingress nodes that receive packets and encapsulate them for o Domain ingress nodes that receive packets and encapsulate them for
transmission across the domain. Those packets may be any payload transmission across the domain. Those packets may be any payload
protocol including native IP packets or packets that are already protocol including native IP packets or packets that are already
MPLS encapsulated. MPLS encapsulated.
o Legacy transit nodes that are IP routers but that are not SR-MPLS o Legacy transit nodes that are IP routers but that are not SR-MPLS
capable (i.e., are not able to perform segment routing). capable (i.e., are not able to perform segment routing).
skipping to change at page 8, line 12 skipping to change at page 8, line 12
o The domain egress node that forwards the payload packet for o The domain egress node that forwards the payload packet for
ultimate delivery. ultimate delivery.
3.2.1. Packet Forwarding with Penultimate Hop Popping 3.2.1. Packet Forwarding with Penultimate Hop Popping
The description in this section assumes that the label associated The description in this section assumes that the label associated
with each prefix-SID is advertised by the owner of the prefix-SID is with each prefix-SID is advertised by the owner of the prefix-SID is
a Penultimate Hop Popping (PHP) label. That is, the NP flag in OSPF a Penultimate Hop Popping (PHP) label. That is, the NP flag in OSPF
or the P flag in ISIS associated with the prefix SID is not set. or the P flag in ISIS associated with the prefix SID is not set.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-------+ B +-------+ C +--------+ D +--------+ H | | A +-------+ B +-------+ C +-------+ D +-------+ H |
+-----+ +--+--+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+ +--+--+ +-----+
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +-------+ F +--------+ G | | E +-------+ F +-------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
+--------+ +--------+
|IP(A->E)| |IP(A->E)|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| UDP | |IP(E->G)| |IP(G->H)| | UDP | |IP(E->G)| |IP(G->H)|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(G) | | UDP | | UDP | | L(G) | | UDP | | UDP |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(H) | | L(H) | |Exp Null| | L(H) | | L(H) | |Exp Null|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Packet | ---> | Packet | ---> | Packet | | Packet | ---> | Packet | ---> | Packet |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 3: Packet Forwarding Example with PHP Figure 3: Packet Forwarding Example with PHP
In the example shown in Figure 3, assume that routers A, E, G and H In the example shown in Figure 3, assume that routers A, E, G and H
are SR-MPLS-capable while the remaining routers (B, C, D and F) are are SR-MPLS-capable while the remaining routers (B, C, D and F) are
only capable of forwarding IP packets. Routers A, E, G, and H only capable of forwarding IP packets. Routers A, E, G, and H
advertise their Segment Routing related information via IS-IS or advertise their Segment Routing related information via IS-IS or
OSPF. OSPF.
Now assume that router A (the Domain ingress) wants to send a packet Now assume that router A (the Domain ingress) wants to send a packet
skipping to change at page 9, line 9 skipping to change at page 9, line 9
Router A will impose an MPLS label stack on the packet that Router A will impose an MPLS label stack on the packet that
corresponds to that explicit path. Since the next hop toward router corresponds to that explicit path. Since the next hop toward router
E is only IP-capable (B is a legacy transit node), router A replaces E is only IP-capable (B is a legacy transit node), router A replaces
the top label (that indicated router E) with a UDP-based tunnel for the top label (that indicated router E) with a UDP-based tunnel for
MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the
packet. In other words, router A pops the top label and then packet. In other words, router A pops the top label and then
encapsulates the MPLS packet in a UDP tunnel to router E. encapsulates the MPLS packet in a UDP tunnel to router E.
When the IP-encapsulated MPLS packet arrives at router E (which is an When the IP-encapsulated MPLS packet arrives at router E (which is an
SR-MPLS-capable transit node), router E strips the IP-based tunnel SR-MPLS-capable transit node), router E strips the IP-based tunnel
header and then process the decapsulated MPLS packet. The top label header and then processes the decapsulated MPLS packet. The top
indicates that the packet must be forwarded toward router G. Since label indicates that the packet must be forwarded toward router G.
the next hop toward router G is only IP-capable, router E replaces Since the next hop toward router G is only IP-capable, router E
the current top label with an MPLS-over-UDP tunnel toward router G replaces the current top label with an MPLS-over-UDP tunnel toward
and sends it out. That is, router E pops the top label and then router G and sends it out. That is, router E pops the top label and
encapsulates the MPLS packet in a UDP tunnel to router G. then encapsulates the MPLS packet in a UDP tunnel to router G.
When the packet arrives at router G, router G will strip the IP-based When the packet arrives at router G, router G will strip the IP-based
tunnel header and then process the decapsulated MPLS packet. The top tunnel header and then process the decapsulated MPLS packet. The top
label indicates that the packet must be forwarded toward router H. label indicates that the packet must be forwarded toward router H.
Since the next hop toward router H is only IP-capable (D is a legacy Since the next hop toward router H is only IP-capable (D is a legacy
transit router), router G would replace the current top label with an transit router), router G would replace the current top label with an
MPLS-over-UDP tunnel toward router H and send it out. However, since MPLS-over-UDP tunnel toward router H and send it out. However, since
router G reaches the bottom of the label stack (G is the penultimate router G reaches the bottom of the label stack (G is the penultimate
SR-MPLS capable node on the path) this would leave the original SR-MPLS capable node on the path) this would leave the original
packet that router A wanted to send to router H encapsulated in UDP packet that router A wanted to send to router H encapsulated in UDP
skipping to change at page 11, line 18 skipping to change at page 11, line 18
the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP
according to local policies, router E would replace the current according to local policies, router E would replace the current
top label with an MPLS-over-UDP tunnel toward router G and send it top label with an MPLS-over-UDP tunnel toward router G and send it
out. out.
IP Header Fields: When encapsulating an MPLS packet in UDP, the IP Header Fields: When encapsulating an MPLS packet in UDP, the
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 DSCP code point, or IPv6 Flow The other IP header fields (such as DSCP code point, or IPv6 Flow
Label) on each UDP-encapsulated segment can be set according to Label) on each UDP-encapsulated segment SHOULD be configurable
the operator's policy: they may be copied from the header of the according to the operator's policy: they may be copied from the
incoming packet; they may be promoted from the header of the header of the incoming packet; they may be promoted from the
payload packet; they may be set according to instructions header of the payload packet; they may be set according to
programmed to be associated with the SID; or they may be instructions programmed to be associated with the SID; or they may
configured dependent on the outgoing interface and payload. be configured dependent on the outgoing interface and payload.
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
case UDP tunnel) MAY be filled with an entropy value that is case UDP tunnel) MAY be filled with an entropy value that is
generated by the encapsulator to uniquely identify a flow. 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 33 skipping to change at page 13, line 33
Marvell Marvell
Email: talmi@marvell.com Email: talmi@marvell.com
Jeff Tantsura Jeff Tantsura
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, and Gunter Van De Velde for their Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert
insightful comments on this draft. Sparks, and Al Morton for their insightful comments on this draft.
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-18 data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), December 2018. (work in progress), December 2018.
skipping to change at page 14, line 43 skipping to change at page 14, line 43
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981, for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016, DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>. <https://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/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., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-15 (work in (SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), October 2018. progress), 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,
L., and L. Jalil, "Advertising Tunnelling Capability in L., and L. Jalil, "Advertising Tunnelling Capability in
IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in
progress), April 2017. progress), April 2017.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
skipping to change at page 15, line 35 skipping to change at page 15, line 41
Jalil, "The Tunnel Encapsulations OSPF Router Jalil, "The Tunnel Encapsulations OSPF Router
Information", draft-ietf-ospf-encapsulation-cap-09 (work Information", draft-ietf-ospf-encapsulation-cap-09 (work
in progress), October 2017. in progress), October 2017.
[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.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
Ed., and M. Townsley, "Use Cases for IPv6 Source Packet Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
Routing in Networking (SPRING)", RFC 8354, Routing in Networking (SPRING)", RFC 8354,
DOI 10.17487/RFC8354, March 2018, DOI 10.17487/RFC8354, March 2018,
<https://www.rfc-editor.org/info/rfc8354>. <https://www.rfc-editor.org/info/rfc8354>.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Alibaba, Inc Alibaba, Inc
 End of changes. 21 change blocks. 
71 lines changed or deleted 85 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/