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/ |