draft-kumarkini-mpls-spring-lsp-ping-05.txt | draft-kumarkini-mpls-spring-lsp-ping-06.txt | |||
---|---|---|---|---|
Network Work group N. Kumar | Network Work group N. Kumar | |||
Internet-Draft G. Swallow | Internet-Draft G. Swallow | |||
Intended status: Standards Track C. Pignataro | Intended status: Standards Track C. Pignataro | |||
Expires: August 3, 2016 Cisco Systems, Inc. | Expires: September 22, 2016 Cisco Systems, Inc. | |||
N. Akiya | N. Akiya | |||
Big Switch Networks | Big Switch Networks | |||
S. Kini | S. Kini | |||
Individual | Individual | |||
H. Gredler | H. Gredler | |||
Juniper Networks | Juniper Networks | |||
M. Chen | M. Chen | |||
Huawei | Huawei | |||
January 31, 2016 | March 21, 2016 | |||
Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using | Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using | |||
MPLS Dataplane | MPLS Dataplane | |||
draft-kumarkini-mpls-spring-lsp-ping-05 | draft-kumarkini-mpls-spring-lsp-ping-06 | |||
Abstract | Abstract | |||
Segment Routing architecture leverages the source routing and | Segment Routing architecture leverages the source routing and | |||
tunneling paradigms and can be directly applied to MPLS data plane. | tunneling paradigms and can be directly applied to MPLS data plane. | |||
A node steers a packet through a controlled set of instructions | A node steers a packet through a controlled set of instructions | |||
called segments, by prepending the packet with a Segment Routing | called segments, by prepending the packet with a Segment Routing | |||
header. | header. | |||
The segment assignment and forwarding semantic nature of Segment | The segment assignment and forwarding semantic nature of Segment | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 August 3, 2016. | This Internet-Draft will expire on September 22, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 | 4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 | |||
4.1. Path validation in Segment Routing networks . . . . . . . 4 | 4.1. Path validation in Segment Routing networks . . . . . . . 4 | |||
4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 | 5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 | |||
5.1. IPv4 Prefix Node Segment ID . . . . . . . . . . . . . . . 5 | 5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 5 | |||
5.2. IPv6 Prefix Node Segment ID . . . . . . . . . . . . . . . 6 | 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 | |||
5.3. IGP Adjacency Segment ID . . . . . . . . . . . . . . . . 7 | 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 7 | |||
6. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8 | 6. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8 | |||
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9 | 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9 | |||
7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 | 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 | |||
7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10 | 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10 | |||
7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10 | 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10 | |||
7.5. TTL Consideration for traceroute . . . . . . . . . . . . 12 | 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 12 | |||
8. Issues with non-forwarding labels . . . . . . . . . . . . . . 12 | 8. Issues with non-forwarding labels . . . . . . . . . . . . . . 13 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 9. Backward Compatibility with non Segment Routing devices . . . 13 | |||
9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 13 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 13 | |||
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13 | 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 15 | 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | 14.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
1. Introduction | 1. Introduction | |||
[I-D.ietf-spring-segment-routing] introduces and explains Segment | [I-D.ietf-spring-segment-routing] introduces and explains Segment | |||
Routing architecture that leverages the source routing and tunneling | Routing architecture that leverages the source routing and tunneling | |||
paradigms. A node steers a packet through a controlled set of | paradigms. A node steers a packet through a controlled set of | |||
instructions called segments, by prepending the packet with Segment | instructions called segments, by prepending the packet with Segment | |||
Routing header. A detailed definition about Segment Routing | Routing header. A detailed definition about Segment Routing | |||
architecture is available in [I-D.ietf-spring-segment-routing] and | architecture is available in [I-D.ietf-spring-segment-routing] | |||
different use-cases are discussed in | ||||
[I-D.filsfils-spring-segment-routing-use-cases] | ||||
The Segment Routing architecture can be directly applied to MPLS data | As defined in [I-D.ietf-spring-segment-routing-mpls], the Segment | |||
plane in a way that, the Segment identifier (Segment ID) will be of | Routing architecture can be directly applied to MPLS data plane in a | |||
20-bits size and Segment Routing header is the label stack. | way that, the Segment identifier (Segment ID) will be of 20-bits size | |||
and Segment Routing header is the label stack. | ||||
Multi Protocol Label Switching (MPLS) has defined in [RFC4379] a | "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" | |||
simple and efficient mechanism to detect data plane failures in Label | [RFC4379] defines a simple and efficient mechanism to detect data | |||
Switched Paths (LSP) by specifying information to be carried in an | plane failures in Label Switched Paths (LSP) by specifying | |||
MPLS "echo request" and "echo reply" for the purposes of fault | information to be carried in an MPLS "echo request" and "echo reply" | |||
detection and isolation, and mechanisms for reliably sending the echo | for the purposes of fault detection and isolation. Mechanisms for | |||
reply. The functionality is modeled after the ping/traceroute | reliably sending the echo reply are defined. The functionality | |||
paradigm (ICMP echo request [RFC0792]) and is typically referred to | defined in [RFC4379]is modeled after the ping/traceroute paradigm | |||
as LSP ping and LSP traceroute. | (ICMP echo request [RFC0792]) and is typically referred to as LSP | |||
ping and LSP traceroute. [RFC6424] updates [RFC4379] to support | ||||
hierarchal and stitching LSPs. | ||||
Unlike LDP or RSVP which are the other well-known MPLS control plane | Unlike LDP or RSVP which are the other well-known MPLS control plane | |||
protocols, segment assignment in Segment Routing architecture is not | protocols, segment assignment in Segment Routing architecture is not | |||
hop-by-hop basis. | hop-by-hop basis. | |||
This nature of Segment Routing raises additional consideration for | This nature of Segment Routing raises additional consideration for | |||
fault detection and isolation in Segment Routing network. This | fault detection and isolation in Segment Routing network. This | |||
document illustrates the problem and describe a mechanism to perform | document illustrates the problem and describe a mechanism to perform | |||
LSP Ping and Traceroute on Segment Routing network over MPLS data | LSP Ping and Traceroute on Segment Routing network over MPLS data | |||
plane. | plane. | |||
skipping to change at page 5, line 19 ¶ | skipping to change at page 5, line 19 ¶ | |||
helpful. For example if R3, due to misprogramming, forwards packet | helpful. For example if R3, due to misprogramming, forwards packet | |||
with Adjacency Segment ID 9236 via link L1 while it is expected to be | with Adjacency Segment ID 9236 via link L1 while it is expected to be | |||
forwarded over Link L2. | forwarded over Link L2. | |||
4.2. Service Label | 4.2. Service Label | |||
A Segment ID can represent a service based instruction. An Segment | A Segment ID can represent a service based instruction. An Segment | |||
Routing header can have label stack entries where the label | Routing header can have label stack entries where the label | |||
represents a service to be applied along the path. Since these | represents a service to be applied along the path. Since these | |||
labels are part of the label stack, they can influence the path taken | labels are part of the label stack, they can influence the path taken | |||
by a packet and consequently have implications on MPLS OAM. In | by a packet and consequently have implications on MPLS OAM. Service | |||
section 6.5 of this document, it is described how the procedures of | Label is left for future study. | |||
[RFC4379] can be applied to in the absence of service-labels in | ||||
Section 6.5. Additional considerations for service labels are | ||||
included in Section 7 and requires further discussion. | ||||
5. Segment ID sub-TLV | 5. Segment ID sub-TLV | |||
The format of the following Segment ID sub-TLVs follows the | The format of the following Segment ID sub-TLVs follows the | |||
philosophy of Target FEC Stack TLV carrying FECs corresponding to | philosophy of Target FEC Stack TLV carrying FECs corresponding to | |||
each label in the label stack. When operated with the procedures | each label in the label stack. When operated with the procedures | |||
defined in [RFC4379], this allows LSP ping/traceroute operations to | defined in [RFC4379], this allows LSP ping/traceroute operations to | |||
function when Target FEC Stack TLV contains more FECs than received | function when Target FEC Stack TLV contains more FECs than received | |||
label stack at responder nodes. | label stack at responder nodes. | |||
Three new sub-TLVs are defined for TLVs type 1, 16 and 21. | Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), | |||
Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type | ||||
21). | ||||
sub-Type Value Field | sub-Type Value Field | |||
-------- --------------- | -------- --------------- | |||
TBD1 IPv4 Prefix Node Segment ID | TBD1 IPv4 IGP-Prefix Segment ID | |||
TBD2 IPv6 Prefix Node Segment ID | TBD2 IPv6 IGP-Prefix Segment ID | |||
TBD3 Adjacency Segment ID | TBD3 IGP-Adjacency Segment ID | |||
Service Segments and FRR will be considered in future version. | Service Segments and FRR will be considered in future version. | |||
5.1. IPv4 Prefix Node Segment ID | 5.1. IPv4 IGP-Prefix Segment ID | |||
The format is as below: | The format is as below: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPv4 Prefix | | | IPv4 Prefix | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Prefix Length | Protocol | Reserved | | |Prefix Length | Protocol | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
IPv4 Prefix | IPv4 Prefix | |||
This field carries the IPv4 prefix to which the Node Segment ID is | This field carries the IPv4 prefix to which the Segment ID is | |||
assigned. If the prefix is shorter than 32 bits, trailing bits | assigned. In case of Anycast Segment ID, this field will carry | |||
SHOULD be set to zero. | IPv4 Anycast address. If the prefix is shorter than 32 bits, | |||
trailing bits SHOULD be set to zero. | ||||
Prefix Length | Prefix Length | |||
The Prefix Length field is one octet, it gives the length of the | The Prefix Length field is one octet, it gives the length of the | |||
prefix in bits (values can be 1 - 32). | prefix in bits (values can be 1 - 32). | |||
Protocol | Protocol | |||
Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is | Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is | |||
ISIS. | ISIS. | |||
5.2. IPv6 Prefix Node Segment ID | 5.2. IPv6 IGP-Prefix Segment ID | |||
The format is as below: | The format is as below: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| IPv6 Prefix | | | IPv6 Prefix | | |||
| | | | | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Prefix Length | Protocol | Reserved | | |Prefix Length | Protocol | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
IPv6 Prefix | IPv6 Prefix | |||
This field carries the IPv6 prefix to which the Node Segment ID is | This field carries the IPv6 prefix to which the Segment ID is | |||
assigned. If the prefix is shorter than 128 bits, trailing bits | assigned. In case of Anycast Segment ID, this field will carry | |||
SHOULD be set to zero. | IPv4 Anycast address. If the prefix is shorter than 128 bits, | |||
trailing bits SHOULD be set to zero. | ||||
Prefix Length | Prefix Length | |||
The Prefix Length field is one octet, it gives the length of the | The Prefix Length field is one octet, it gives the length of the | |||
prefix in bits (values can be 1 - 128). | prefix in bits (values can be 1 - 128). | |||
Protocol | Protocol | |||
Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is | Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is | |||
ISIS. | ISIS. | |||
5.3. IGP Adjacency Segment ID | 5.3. IGP-Adjacency Segment ID | |||
The format is as below: | The format is as below: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Adj. Type | Protocol | Reserved | | | Adj. Type | Protocol | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Local Interface ID (4 or 16 octets) | | | Local Interface ID (4 or 16 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Remote Interface ID (4 or 16 octets) | | | Remote Interface ID (4 or 16 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ ~ | ~ ~ | |||
| Advertising Node Identifier (4 or 6 octets) | | | Advertising Node Identifier (4 or 6 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ ~ | ~ ~ | |||
| Receiving Node Identifier (4 or 6 octets) | | | Receiving Node Identifier (4 or 6 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Adj. Type | Adj. Type (Adjacency Type) | |||
Set to 1, when the Adjacency Segment is Parallel Adjacency as | Set to 1, when the Adjacency Segment is Parallel Adjacency as | |||
defined in section 3.5.1 of [I-D.ietf-spring-segment-routing]. | defined in section 3.5.1 of [I-D.ietf-spring-segment-routing]. | |||
Set to 4, when the Adjacency segment is IPv4 based and is not a | Set to 4, when the Adjacency segment is IPv4 based and is not a | |||
parallel adjacency. Set to 6, when the Adjacency segment is IPv6 | parallel adjacency. Set to 6, when the Adjacency segment is IPv6 | |||
based and is not a parallel adjacency. | based and is not a parallel adjacency. | |||
Protocol | Protocol | |||
Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS | Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS | |||
skipping to change at page 9, line 18 ¶ | skipping to change at page 9, line 18 ¶ | |||
1 Static | 1 Static | |||
2 BGP | 2 BGP | |||
3 LDP | 3 LDP | |||
4 RSVP-TE | 4 RSVP-TE | |||
With segment routing, OSPF or ISIS can be used for label | With segment routing, OSPF or ISIS can be used for label | |||
distribution, this document adds two new protocols as follows: | distribution, this document adds two new protocols as follows: | |||
Protocol # Signaling Protocol | Protocol # Signaling Protocol | |||
---------- ------------------ | ---------- ------------------ | |||
5 OSPF | TBD5 OSPF | |||
6 ISIS | TBD6 ISIS | |||
7. Procedures | 7. Procedures | |||
This section describes aspects of LSP Ping and traceroute operations | This section describes aspects of LSP Ping and traceroute operations | |||
that require further considerations beyond [RFC4379]. | that require further considerations beyond [RFC4379]. | |||
7.1. FECs in Target FEC Stack TLV | 7.1. FECs in Target FEC Stack TLV | |||
When LSP echo request packets are generated by an initiator, FECs | When LSP echo request packets are generated by an initiator, FECs | |||
carried in Target FEC Stack TLV may need to have deviating contents. | carried in Target FEC Stack TLV may need to have deviating contents. | |||
skipping to change at page 9, line 50 ¶ | skipping to change at page 9, line 50 ¶ | |||
communicate the segments traversed. | communicate the segments traversed. | |||
Traceroute | Traceroute | |||
Initiator MUST initially include FECs corresponding to all of | Initiator MUST initially include FECs corresponding to all of | |||
segments imposed in the label stack. | segments imposed in the label stack. | |||
When a received echo reply contains FEC Stack Change TLV with | When a received echo reply contains FEC Stack Change TLV with | |||
one or more of original segment(s) being popped, initiator MAY | one or more of original segment(s) being popped, initiator MAY | |||
remove corresponding FEC(s) from Target FEC Stack TLV in the | remove corresponding FEC(s) from Target FEC Stack TLV in the | |||
next (TTL+1) traceroute request. | next (TTL+1) traceroute request as defined in section 4.3.1.2 | |||
of [RFC6424]. | ||||
When a received echo reply does not contain FEC Stack Change | When a received echo reply does not contain FEC Stack Change | |||
TLV, initiator MUST NOT attempt to remove FEC(s) from Target | TLV, initiator MUST NOT attempt to remove FEC(s) from Target | |||
FEC Stack TLV in the next (TTL+1) traceroute request. Note | FEC Stack TLV in the next (TTL+1) traceroute request. | |||
that Downstream Label field of DSMAP/DDMAP contains hints on | ||||
how initiator may be able to update the contents of next Target | ||||
FEC Stack TLV. However, such hints are ambiguous without full | ||||
understanding of PHP capabilities. | ||||
7.2. FEC Stack Change sub-TLV | 7.2. FEC Stack Change sub-TLV | |||
Section 3.3.1.3 of [RFC6424] defines a new sub-TLV that a router must | Section 3.3.1.3 of [RFC6424] defines FEC Stack Change sub-TLV that a | |||
include when the FEC stack changes. | router must include when the FEC stack changes. | |||
The network node which advertised the Node Segment ID is responsible | The network node which advertised the Node Segment ID is responsible | |||
for generating FEC Stack Change sub-TLV of &pop& operation for Node | for generating FEC Stack Change sub-TLV of &pop& operation for Node | |||
Segment ID, regardless of if PHP is enabled or not. | Segment ID, regardless of if PHP is enabled or not. | |||
The network node that is immediate downstream of the node which | The network node that is immediate downstream of the node which | |||
advertised the Adjacency Segment ID is responsible for generating FEC | advertised the Adjacency Segment ID is responsible for generating FEC | |||
Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. | Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. | |||
7.3. Segment ID POP Operation | 7.3. Segment ID POP Operation | |||
The forwarding semantic of Node Segment ID with PHP flag is | The forwarding semantic of Node Segment ID with PHP flag is | |||
equivalent to usage of implicit Null in MPLS protocols. Adjacency | equivalent to usage of implicit Null in MPLS protocols. Adjacency | |||
Segment ID is also similar in a sense that it can be thought as next | Segment ID is also similar in a sense that it can be thought as next | |||
hop destined locally allocated segment that has PHP enabled. | hop destined locally allocated segment that has PHP enabled. | |||
Procedures described in Section 4.4 of [RFC4379] relies on Stack-D | Procedures described in Section 4.4 of [RFC4379] relies on Stack-D | |||
and Stack-R explicitly having Implicit Null value. It may simplify | and Stack-R explicitly having Implicit Null value. It may simplify | |||
implementations to reuse Implicit Null for Node Segment ID PHP and | implementations to reuse Implicit Null for Node Segment ID PHP and | |||
Adjacency Segment ID cases. However, it is technically incorrect for | Adjacency Segment ID cases. | |||
Implicit Null value to externally appear. Therefore, implicit Null | ||||
MUST NOT be placed in Stack-D and Interface and Label Stack TLV for | ||||
Node Segment ID PHP and Adjacency Segment ID cases. | ||||
7.4. Segment ID Check | 7.4. Segment ID Check | |||
This section updates the procedure defined in Step 6 of section 4.4. | ||||
of [RFC4379] | ||||
If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- | If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- | |||
stack-depth is TBD1 (IPv4 Prefix Node Segment ID), the responder | stack-depth is TBD1 (IPv4 IGP-Prefix Segment ID), the responder | |||
should set Best return code to 10 if any below conditions fail: /* | should set Best return code to 10, "Mapping for this FEC is not | |||
The responder LSR is to check if it is the egress of the IPv4 | the given label at stack-depth <RSC>" if any below conditions | |||
Prefix Node Segment ID described in the Target FEC Stack Sub-TLV, | fail: | |||
/* The responder LSR is to check if it is the egress of the IPv4 | ||||
IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, | ||||
and if the FEC was advertised with the PHP bit set.*/ | and if the FEC was advertised with the PHP bit set.*/ | |||
* Validate that Node Segment ID is advertised for IPv4 Prefix. | * Validate that Node Segment ID is advertised for IPv4 Prefix. | |||
* Validate that Node Segment ID is advertisement of PHP bit. | * Validate that Node Segment ID is advertised with No-PHP flag { | |||
+ When Protocol is OSPF, NP-flag defined in Section 5 of | ||||
[I-D.ietf-ospf-segment-routing-extensions] should be set to | ||||
0. | ||||
+ When Protocol is ISIS, P-Flag defined in Section 2.1 of | ||||
[I-D.ietf-isis-segment-routing-extensions] should be set to | ||||
0. | ||||
* } | ||||
If the Label-stack-depth is more than 0 and Target FEC Stack Sub- | If the Label-stack-depth is more than 0 and Target FEC Stack Sub- | |||
TLV at FEC-stack-depth is TBD1 (IPv4 Prefix Node Segment ID), the | TLV at FEC-stack-depth is TBD1 (IPv4 IGP-Prefix Segment ID), the | |||
responder is to set Best return code to 10 if any below conditions | responder is to set Best return code to 10 if any below conditions | |||
fail: | fail: | |||
* Validate that Node Segment ID is advertised for IPv4 Prefix. | * Validate that Node Segment ID is advertised for IPv4 Prefix. | |||
If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- | If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- | |||
depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code | depth is TBD2 (IPv6 IGP-Prefix Segment ID), set Best return code | |||
to 10 if any below conditions fail: /* The LSR needs to check if | to 10 if any below conditions fail: | |||
its being a tail-end for the LSP and have the prefix advertised | ||||
with PHP bit set*/ | /* The LSR needs to check if its being a tail-end for the LSP and | |||
have the prefix advertised with PHP bit set*/ | ||||
* Validate that Node Segment ID is advertised for IPv6 Prefix. | * Validate that Node Segment ID is advertised for IPv6 Prefix. | |||
* Validate that Node Segment ID is advertised of PHP bit. | * Validate that Node Segment ID is advertised of PHP bit. | |||
If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack- | If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at | |||
depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code | FEC-stack-depth is TBD2 (IPv6 IGP-Prefix Segment ID), set Best | |||
to 10 if any below conditions fail: | return code to 10 if any below conditions fail: | |||
* Validate that Node Segment ID is advertised for IPv6 Prefix. | * Validate that Node Segment ID is advertised for IPv6 Prefix. | |||
If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- | If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- | |||
depth is TBD3 (Adjacency Segment ID), set Best return code to | depth is TBD3 (Adjacency Segment ID), set Best return code to | |||
(error code TBD) if any below conditions fail: | (error code TBD) if any below conditions fail: | |||
When the Adj.Type is 1 (Parallel Adjacency): | When the Adj. Type is 1 (Parallel Adjacency): | |||
+ Validate that Receiving Node Identifier is local IGP | + Validate that Receiving Node Identifier is local IGP | |||
identifier. | identifier. | |||
+ Validate that Adjacency Segment ID is advertised by | + Validate that Adjacency Segment ID is advertised by | |||
Advertising Node Identifier of Protocol in local IGP | Advertising Node Identifier of Protocol in local IGP | |||
database. | database. | |||
When the Adj.Type is 4 or 6: | When the Adj. Type is 4 or 6: | |||
+ Validate that Remote Interface ID matches the local | + Validate that Remote Interface ID matches the local | |||
identifier of the interface (Interface-I) on which the | identifier of the interface (Interface-I) on which the | |||
packet was received. | packet was received. | |||
+ Validate that Receiving Node Identifier is local IGP | + Validate that Receiving Node Identifier is local IGP | |||
identifier. | identifier. | |||
+ Validate that IGP Adjacency Segment ID is advertised by | + Validate that IGP-Adjacency Segment ID is advertised by | |||
Advertising Node Identifier of Protocol in local IGP | Advertising Node Identifier of Protocol in local IGP | |||
database. | database. | |||
7.5. TTL Consideration for traceroute | 7.5. TTL Consideration for traceroute | |||
LSP Traceroute operation can properly traverse every hop of Segment | LSP Traceroute operation can properly traverse every hop of Segment | |||
Routing network in Uniform Model described in [RFC3443]. If one or | Routing network in Uniform Model described in [RFC3443]. If one or | |||
more LSRs employ Short Pipe Model described in [RFC3443], then LSP | more LSRs employ Short Pipe Model described in [RFC3443], then LSP | |||
Traceroute may not be able to properly traverse every hop of Segment | Traceroute may not be able to properly traverse every hop of Segment | |||
Routing network due to absence of TTL copy operation when outer label | Routing network due to absence of TTL copy operation when outer label | |||
is popped. In such scenario, following TTL manipulation technique | is popped. Short Pipe being the most commonly used model. The | |||
MAY be used. | following TTL manipulation technique MAY be used when Short Pipe | |||
model is used. | ||||
When tracing a LSP according to the procedures in [RFC4379] the TTL | When tracing a LSP according to the procedures in [RFC4379] the TTL | |||
is incremented by one in order to trace the path sequentially along | is incremented by one in order to trace the path sequentially along | |||
the LSP. However when a source routed LSP has to be traced there are | the LSP. However when a source routed LSP has to be traced there are | |||
as many TTLs as there are labels in the stack. The LSR that | as many TTLs as there are labels in the stack. The LSR that | |||
initiates the traceroute SHOULD start by setting the TTL to 1 for the | initiates the traceroute SHOULD start by setting the TTL to 1 for the | |||
tunnel in the LSP's label stack it wants to start the tracing from, | tunnel in the LSP's label stack it wants to start the tracing from, | |||
the TTL of all outer labels in the stack to the max value, and the | the TTL of all outer labels in the stack to the max value, and the | |||
TTL of all the inner labels in the stack to zero. Thus a typical | TTL of all the inner labels in the stack to zero. Thus a typical | |||
start to the traceroute would have a TTL of 1 for the outermost label | start to the traceroute would have a TTL of 1 for the outermost label | |||
and all the inner labels would have TTL 0. If the FEC Stack TLV is | and all the inner labels would have TTL 0. If the FEC Stack TLV is | |||
included it should contain only those for the inner stacked tunnels. | included it should contain only those for the inner stacked tunnels. | |||
The lack of an echo response or the Return Code/Subcode should be | The Return Code/Subcode and FEC Stack Change TLV should be used to | |||
used to diagnose the tunnel as described in [RFC4379]. When the | diagnose the tunnel as described in [RFC4379] and [RFC6424]. When | |||
tracing of a tunnel in the stack is complete, then the next tunnel in | the tracing of a tunnel in the stack is complete, then the next | |||
the stack should be traced. The end of a tunnel can be detected from | tunnel in the stack should be traced. The end of a tunnel can be | |||
the "Return Code" when it indicates that the responding LSR is an | detected from the "Return Code" when it indicates that the responding | |||
egress for the stack at depth 1. Thus the traceroute procedures in | LSR is an egress for the stack at depth 1. Thus the traceroute | |||
[RFC4379] can be recursively applied to traceroute a source routed | procedures in [RFC4379] can be recursively applied to traceroute a | |||
LSP. | source routed LSP. | |||
8. Issues with non-forwarding labels | 8. Issues with non-forwarding labels | |||
Source stacking can be optionally used to apply services on the | Source stacking can be optionally used to apply services on the | |||
packet at a LSR along the path, where a label in the stack is used to | packet at a LSR along the path, where a label in the stack is used to | |||
trigger service application. A data plane failure detection and | trigger service application. A data plane failure detection and | |||
isolation mechanism should provide its functionality without applying | isolation mechanism should provide its functionality without applying | |||
these services. This is mandatory for services that are stateful, | these services. This is mandatory for services that are stateful, | |||
though for stateless services [RFC4379] could be used as-is. It MAY | though for stateless services [RFC4379] could be used as-is. It MAY | |||
also provide a mechanism to detect and isolate faults within the | also provide a mechanism to detect and isolate faults within the | |||
service function itself. | service function itself. | |||
To prevent services from being applied to an "echo request" packet, | How a node treats Service label is outside the scope of this document | |||
the TTL of service labels MUST be 0. However TTL processing rules of | and will be included in this or a different document later. | |||
a service label must be the same as any MPLS label. Due to this a | ||||
TTL of 0 in the service label would prevent the packet from being | ||||
forwarded beyond the LSR that provides the service. To avoid this | ||||
problem, the originator of the "echo request" MUST NOT include the | ||||
service label in the label stack of an echo request above the tunnel | ||||
label of the tunnel that is being currently traced. In other words | ||||
the ingress must remove all service-labels above the label of the | ||||
tunnel being currently traced, but retain service labels below it | ||||
when sending the echo request. Note that load balancing may affect | ||||
the path when the service labels are removed, resulting in a newer | ||||
path being traversed. However this new path is potentially different | ||||
only up to the LSR that provides the service. Since this portion of | ||||
the path was traced when the tunnels above this tunnel in the stack | ||||
were traced and followed the exact path as the source routed LSP, | ||||
this should not be a major concern. Sometimes the newer path may | ||||
have a problem that was not in the original path resulting in a false | ||||
positive. In such a case the original path can be traversed by | ||||
changing the label stack to reach the intermediate LSR with labels | ||||
that route along each hop explicitly. | ||||
9. IANA Considerations | 9. Backward Compatibility with non Segment Routing devices | |||
9.1. New Target FEC Stack Sub-TLVs | [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment | |||
Routing operates in network where SR-capable and non-SR-capable nodes | ||||
coexist. In such networks, there may not be any FEC mapping in the | ||||
responder when the Initiator is SR-capable while the responder is not | ||||
(or vice-versa). But this is not different from RSVP and LDP interop | ||||
scenarios. When LSP Ping is triggered, the responder will set the | ||||
FEC-return-code to Return 4, "Replying router has no mapping for the | ||||
FEC at stack-depth". | ||||
Similarly when SR-capable node assigns Adj-SID for non-SR-capable | ||||
node, LSP trace may fail as the non-SR-capable node is not aware of | ||||
"IGP Adjacency Segment ID" sub-TLV and may not reply with FEC Stack | ||||
change. This may result in any further downstream nodes to reply | ||||
back with Return-code as 4, "Replying router has no mapping for the | ||||
FEC at stack-depth". | ||||
10. IANA Considerations | ||||
10.1. New Target FEC Stack Sub-TLVs | ||||
IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV | IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV | |||
Types 1, 16 and 21" sub-registry. | Types 1, 16 and 21" sub-registry. | |||
Sub-Type Sub-TLV Name Reference | Sub-Type Sub-TLV Name Reference | |||
---------- ----------------- ------------ | ---------- ----------------- ------------ | |||
TBD1 IPv4 Prefix Node Segment ID Section 4.1 (this document) | TBD1 IPv4 IGP-Prefix Segment ID Section 4.1 (this document) | |||
TBD2 IPv6 Prefix Node Segment ID Section 4.2 (this document) | TBD2 IPv6 IGP-Prefix Segment ID Section 4.2 (this document) | |||
TBD3 Adjacency Segment ID Section 4.3 (this document) | TBD3 IGP-Adjacency Segment ID Section 4.3 (this document) | |||
10. Security Considerations | 11. Security Considerations | |||
This document defines additional Sub-TLVs and follows the mechanism | This document defines additional Sub-TLVs and follows the mechanism | |||
defined in [RFC4379]. So all the security consideration defined in | defined in [RFC4379]. So all the security consideration defined in | |||
[RFC4379] will be applicable for this document and in addition it | [RFC4379] will be applicable for this document and in addition it | |||
does not impose any security challenges to be considered. | does not impose any security challenges to be considered. | |||
11. Acknowledgement | 12. Acknowledgement | |||
The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji | The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji | |||
Rajagopalan and Harish Sitaraman for their review and comments. | Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta and | |||
Lizhong Jin for their review and comments. | ||||
The authors wold like to thank Loa Andersson for his comments and | The authors wold like to thank Loa Andersson for his comments and | |||
recommendation to merge drafts. | recommendation to merge drafts. | |||
12. Contributing Authors | 13. Contributing Authors | |||
Tarek Saad | Tarek Saad | |||
Cisco Systems | Cisco Systems | |||
Email: tsaad@cisco.com | Email: tsaad@cisco.com | |||
Siva Sivabalan | Siva Sivabalan | |||
Cisco Systems | Cisco Systems | |||
Email: msiva@cisco.com | Email: msiva@cisco.com | |||
Balaji Rajagopalan | Balaji Rajagopalan | |||
Juniper Networks | Juniper Networks | |||
Email: balajir@juniper.net | Email: balajir@juniper.net | |||
13. References | Faisal Iqbal | |||
Cisco Systems | ||||
Email: faiqbal@cisco.com | ||||
13.1. Normative References | 14. References | |||
[I-D.filsfils-spring-segment-routing-use-cases] | 14.1. Normative References | |||
Filsfils, C., Francois, P., Previdi, S., Decraene, B., | ||||
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | [I-D.ietf-isis-segment-routing-extensions] | |||
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. | Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., | |||
Crabbe, "Segment Routing Use Cases", draft-filsfils- | Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS | |||
spring-segment-routing-use-cases-01 (work in progress), | Extensions for Segment Routing", draft-ietf-isis-segment- | |||
October 2014. | routing-extensions-06 (work in progress), December 2015. | |||
[I-D.ietf-ospf-segment-routing-extensions] | ||||
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., | ||||
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF | ||||
Extensions for Segment Routing", draft-ietf-ospf-segment- | ||||
routing-extensions-07 (work in progress), March 2016. | ||||
[I-D.ietf-spring-segment-routing] | [I-D.ietf-spring-segment-routing] | |||
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | |||
and r. rjs@rob.sh, "Segment Routing Architecture", draft- | and R. Shakir, "Segment Routing Architecture", draft-ietf- | |||
ietf-spring-segment-routing-07 (work in progress), | spring-segment-routing-07 (work in progress), December | |||
December 2015. | 2015. | |||
[I-D.ietf-spring-segment-routing-ldp-interop] | ||||
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and | ||||
S. Litkowski, "Segment Routing interoperability with LDP", | ||||
draft-ietf-spring-segment-routing-ldp-interop-00 (work in | ||||
progress), October 2015. | ||||
[I-D.ietf-spring-segment-routing-mpls] | ||||
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | ||||
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., | ||||
and E. Crabbe, "Segment Routing with MPLS data plane", | ||||
draft-ietf-spring-segment-routing-mpls-04 (work in | ||||
progress), March 2016. | ||||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | |||
RFC 792, DOI 10.17487/RFC0792, September 1981, | RFC 792, DOI 10.17487/RFC0792, September 1981, | |||
<http://www.rfc-editor.org/info/rfc792>. | <http://www.rfc-editor.org/info/rfc792>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 15, line 20 ¶ | skipping to change at page 16, line 15 ¶ | |||
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions | [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions | |||
in Support of Generalized Multi-Protocol Label Switching | in Support of Generalized Multi-Protocol Label Switching | |||
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, | (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, | |||
<http://www.rfc-editor.org/info/rfc5307>. | <http://www.rfc-editor.org/info/rfc5307>. | |||
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for | [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for | |||
Performing Label Switched Path Ping (LSP Ping) over MPLS | Performing Label Switched Path Ping (LSP Ping) over MPLS | |||
Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, | Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, | |||
<http://www.rfc-editor.org/info/rfc6424>. | <http://www.rfc-editor.org/info/rfc6424>. | |||
13.2. Informative References | 14.2. Informative References | |||
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, | [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, | |||
D., and S. Mansfield, "Guidelines for the Use of the "OAM" | D., and S. Mansfield, "Guidelines for the Use of the "OAM" | |||
Acronym in the IETF", BCP 161, RFC 6291, | Acronym in the IETF", BCP 161, RFC 6291, | |||
DOI 10.17487/RFC6291, June 2011, | DOI 10.17487/RFC6291, June 2011, | |||
<http://www.rfc-editor.org/info/rfc6291>. | <http://www.rfc-editor.org/info/rfc6291>. | |||
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., | [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., | |||
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane | Yasukawa, S., and T. Nadeau, "Detecting Data-Plane | |||
Failures in Point-to-Multipoint MPLS - Extensions to LSP | Failures in Point-to-Multipoint MPLS - Extensions to LSP | |||
End of changes. 48 change blocks. | ||||
133 lines changed or deleted | 169 lines changed or added | |||
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |