draft-ietf-mpls-lsp-ping-enhanced-dsmap-10.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt 
Network Working Group N. Bahadur Network Working Group N. Bahadur
Internet-Draft K. Kompella Internet-Draft K. Kompella
Updates: 4379 (if approved) Juniper Networks, Inc. Updates: 4379 (if approved) Juniper Networks, Inc.
Intended status: Standards Track G. Swallow Intended status: Standards Track G. Swallow
Expires: January 1, 2012 Cisco Systems Expires: March 13, 2012 Cisco Systems
June 30, 2011 September 10, 2011
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-10 draft-ietf-mpls-lsp-ping-enhanced-dsmap-11
Abstract Abstract
This document describes methods for performing LSP-Ping (specified in This document describes methods for performing LSP-Ping (specified in
RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
MPLS label-switched-paths (LSPs). The techniques outlined in RFC MPLS label-switched-paths (LSPs). The techniques outlined in RFC
4379 are insufficient to perform traceroute Forwarding Equivalency 4379 are insufficient to perform traceroute Forwarding Equivalency
Class (FEC) validation and path discovery for an LSP that goes over Class (FEC) validation and path discovery for an LSP that goes over
other MPLS tunnels or for a stitched LSP. This document describes other MPLS tunnels or for a stitched LSP. This document describes
enhancements to the downstream-mapping TLV (defined in RFC 4379). enhancements to the downstream-mapping TLV (defined in RFC 4379).
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 1, 2012. This Internet-Draft will expire on March 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 4, line 8 skipping to change at page 4, line 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This documents describes methods for performing LSP-Ping (specified This documents describes methods for performing LSP-Ping (specified
in [RFC4379] traceroute over MPLS tunnels. The techniques in in [RFC4379]) traceroute over MPLS tunnels. The techniques in
[RFC4379] outline a traceroute mechanism that includes Forwarding [RFC4379] outline a traceroute mechanism that includes Forwarding
Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP) Equivalency Class (FEC) validation and Equal Cost Multi-Path (ECMP)
path discovery. Those mechanisms are insufficient and do not provide path discovery. Those mechanisms are insufficient and do not provide
details in case the FEC being traced traverses one or more MPLS details when the FEC being traced traverses one or more MPLS tunnels
tunnels and in case where label-switched-path (LSP) stitching and when label-switched-path (LSP) stitching [RFC5150] is in use.
[RFC5150] is in use. This document defines enhancements to the This document defines enhancements to the downstream-mapping TLV
downstream-mapping TLV [RFC4379] to make it more extensible and to [RFC4379] to make it more extensible and to enable retrieval of
enable retrieval of detailed information. Using the enhanced TLV detailed information. Using the enhanced TLV format along with the
format along with the existing definitions of [RFC4379], this existing definitions of [RFC4379], this document describes procedures
document describes procedures by which a traceroute request can by which a traceroute request can correctly traverse MPLS tunnels
correctly traverse MPLS tunnels with proper FEC and label with proper FEC and label validations.
validations.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Motivation 2. Motivation
A LSP-Ping traceroute may cross multiple MPLS tunnels en-route the A LSP-Ping traceroute may cross multiple MPLS tunnels en-route the
skipping to change at page 6, line 34 skipping to change at page 6, line 34
A new Return Code is being defined "See DDM TLV for Return Code and A new Return Code is being defined "See DDM TLV for Return Code and
Return SubCode" (Section 6.3) to indicate that the Return Code is per Return SubCode" (Section 6.3) to indicate that the Return Code is per
Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST Downstream Detailed Mapping TLV (Section 3.3). This Return Code MUST
be used only in the message header and MUST be set only in the MPLS be used only in the message header and MUST be set only in the MPLS
echo reply message. If the Return Code is set in the MPLS echo echo reply message. If the Return Code is set in the MPLS echo
request message, then it MUST be ignored. When this Return Code is request message, then it MUST be ignored. When this Return Code is
set, each Downstream Detailed Mapping TLV MUST have an appropriate set, each Downstream Detailed Mapping TLV MUST have an appropriate
Return Code and Return SubCode. This Return Code MUST be used when Return Code and Return SubCode. This Return Code MUST be used when
there are multiple downstreams for a given node (such as P2MP or there are multiple downstreams for a given node (such as P2MP or
ECMP), and the node needs to return a different Return Code/Return ECMP), and the node needs to return a Return Code/Return SubCode for
SubCode for each downstream. This Return Code MAY be used even when each downstream. This Return Code MAY be used even when there is
there is only 1 downstream for a given node. only 1 downstream for a given node.
3.2.2. Return code for stitched LSPs 3.2.2. Return code for stitched LSPs
When a traceroute is being performed on stitched LSPs (Section 4.1.2) When a traceroute is being performed on stitched LSPs (Section 4.1.2)
the stitching point SHOULD indicate the stitching action to the node the stitching point SHOULD indicate the stitching action to the node
performing the trace. This is done by setting the Return Code to performing the trace. This is done by setting the Return Code to
"Label switched with FEC change" (Section 6.3). If a node is "Label switched with FEC change" (Section 6.3). If a node is
performing FEC hiding, then it MAY choose to set the Return Code to a performing FEC hiding, then it MAY choose to set the Return Code to a
value other than "Label switched with FEC change". This Return Code value (specified in [RFC4379]) other than "Label switched with FEC
MUST NOT be used if no FEC Stack sub-TLV (Section 3.3.1.3) is present change". The Return Code of "Label switched with FEC change" MUST
in the Downstream Detailed Mapping TLV(s). This new Return Code MAY NOT be used if no FEC Stack sub-TLV (Section 3.3.1.3) is present in
be used for hierarchical LSPs (for indicating start or end of an the Downstream Detailed Mapping TLV(s). This new Return Code MAY be
outer LSP). used for hierarchical LSPs (for indicating start or end of an outer
LSP).
3.3. Downstream Detailed Mapping TLV 3.3. Downstream Detailed Mapping TLV
Type # Value Field Type # Value Field
------ ------------ ------ ------------
TBD Downstream detailed mapping TBD Downstream detailed mapping
The Downstream Detailed Mapping object is a TLV that MAY be included The Downstream Detailed Mapping object is a TLV that MAY be included
in an MPLS echo request message. Only one Downstream Detailed in an MPLS echo request message. Only one Downstream Detailed
skipping to change at page 8, line 43 skipping to change at page 8, line 43
set the Return Code field in the echo reply header to "See DDM TLV set the Return Code field in the echo reply header to "See DDM TLV
for Return Code and Return SubCode" (Section 6.3). An exception for Return Code and Return SubCode" (Section 6.3). An exception
to this is if the receiver is a bud node [RFC4461] and is replying to this is if the receiver is a bud node [RFC4461] and is replying
as both an egress and a transit node with a Return Code of 3 as both an egress and a transit node with a Return Code of 3
("Replying router is an egress for the FEC") in the echo reply ("Replying router is an egress for the FEC") in the echo reply
header. header.
If the Return Code of the echo reply message is not set to either If the Return Code of the echo reply message is not set to either
"See DDM TLV for Return Code and Return SubCode" (Section 6.3) or "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or
"Replying router is an egress for the FEC", then the Return Code "Replying router is an egress for the FEC", then the Return Code
specified in the Downstream Detailed Mapping TLV SHOULD be specified in the Downstream Detailed Mapping TLV MUST be ignored.
ignored.
Return SubCode Return SubCode
The Return SubCode is set to zero by the sender. The receiver can The Return SubCode is set to zero by the sender. The receiver can
set it to one of the values specified in the "Multi-Protocol Label set it to one of the values specified in the "Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry, Switching (MPLS) Label Switched Paths (LSPs) Parameters" registry,
"Return Codes" sub-registry. This field is filled in with the "Return Codes" sub-registry. This field is filled in with the
stack-depth for those codes that specify that. For all other stack-depth for those codes that specify that. For all other
codes, the Return SubCode MUST be set to zero. codes, the Return SubCode MUST be set to zero.
If the Return Code of the echo reply message is not set to either If the Return Code of the echo reply message is not set to either
"See DDM TLV for Return Code and Return SubCode" (Section 6.3) or "See DDM TLV for Return Code and Return SubCode" (Section 6.3) or
"Replying router is an egress for the FEC", then the Return "Replying router is an egress for the FEC", then the Return
SubCode specified in the Downstream Detailed Mapping TLV SHOULD be SubCode specified in the Downstream Detailed Mapping TLV MUST be
ignored. ignored.
Sub-tlv length Sub-tlv length
Total length in bytes of the sub-TLVs associated with this TLV. Total length in bytes of the sub-TLVs associated with this TLV.
3.3.1. Sub-TLVs 3.3.1. Sub-TLVs
This section defines the Sub-TLVs that MAY be include as part of the This section defines the Sub-TLVs that MAY be included as part of the
Downstream Detailed Mapping TLV. Downstream Detailed Mapping TLV.
Sub-Type Value Field Sub-Type Value Field
--------- ------------ --------- ------------
TBD Multipath data TBD Multipath data
TBD Label stack TBD Label stack
TBD FEC Stack change TBD FEC Stack change
3.3.1.1. Multipath data sub-TLV 3.3.1.1. Multipath data sub-TLV
skipping to change at page 11, line 9 skipping to change at page 11, line 9
LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S LSBit is bit 19, the EXP bits are bits 20-22, and bit 23 is the S
bit. The replying router SHOULD fill in the EXP and S bits; the bit. The replying router SHOULD fill in the EXP and S bits; the
LSR receiving the echo reply MAY choose to ignore these bits. LSR receiving the echo reply MAY choose to ignore these bits.
Protocol Protocol
This specifies the label distribution protocol for the downstream This specifies the label distribution protocol for the downstream
label. label.
3.3.1.3. FEC Stack change sub-TLV 3.3.1.3. FEC Stack change sub-TLV
A router SHOULD include the FEC Stack change sub-TLV when the A router MUST include the FEC Stack change sub-TLV when the
downstream node in the echo reply has a different FEC Stack than the downstream node in the echo reply has a different FEC Stack than the
FEC stack received in the echo request. One or more FEC Stack change FEC stack received in the echo request. One or more FEC Stack change
sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The sub-TLVs MAY be present in the Downstream Detailed Mapping TLV. The
format is as below. 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 2 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Operation Type | Address type | FEC-tlv length| Reserved | |Operation Type | Address type | FEC-tlv length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 45 skipping to change at page 11, line 45
------ --------- ------ ---------
1 Push 1 Push
2 Pop 2 Pop
Address Type Address Type
The Address Type indicates the remote peer's address type. The The Address Type indicates the remote peer's address type. The
Address Type is set to one of the following values. The peer Address Type is set to one of the following values. The peer
address length is determined based on the address type. The address length is determined based on the address type. The
address type MAY be different from the address type included in address type MAY be different from the address type included in
the Downstream Detailed Mapping TLV. This can happen in case the the Downstream Detailed Mapping TLV. This can happen when the LSP
LSP goes over a tunnel of a different address family. The address goes over a tunnel of a different address family. The address
type MAY be set to Unspecified if the peer-address is either type MAY be set to Unspecified if the peer-address is either
unavailable or the transit router does not wish it provide it for unavailable or the transit router does not wish it provide it for
security or administrative reasons. security or administrative reasons.
Type # Address Type Address length Type # Address Type Address length
------ ------------ -------------- ------ ------------ --------------
0 Unspecified 0 0 Unspecified 0
1 IPv4 4 1 IPv4 4
2 IPv6 16 2 IPv6 16
skipping to change at page 12, line 31 skipping to change at page 12, line 31
Remote peer address Remote peer address
The remote peer address specifies the remote peer which is the The remote peer address specifies the remote peer which is the
next-hop for the FEC being currently traced. E.g. in the LDP over next-hop for the FEC being currently traced. E.g. in the LDP over
RSVP case Figure 1, router B would respond back with the address RSVP case Figure 1, router B would respond back with the address
of router D as the remote peer address for the LDP FEC being of router D as the remote peer address for the LDP FEC being
traced. This allows the ingress node to provide information traced. This allows the ingress node to provide information
regarding FEC peers. If the operation type is PUSH, the remote regarding FEC peers. If the operation type is PUSH, the remote
peer address is the address of the peer from which the FEC being peer address is the address of the peer from which the FEC being
pushed was learnt. If the operation type is POP, the remote peer pushed was learnt. If the operation type is POP, the remote peer
address MAY be set to Unspecified. For upstream assigned labels address MAY be set to Unspecified.
[RFC5331], an operation type of POP will have a remote peer For upstream assigned labels [RFC5331], an operation type of POP
address (the upstream node that assigned the label) and this will have a remote peer address (the upstream node that assigned
SHOULD be included in the FEC Stack change sub-TLV. the label) and this SHOULD be included in the FEC Stack change
sub-TLV. The remote peer address MAY be set to Unspecified, if
the address needs to be hidden.
FEC TLV FEC TLV
The FEC TLV is present only when FEC-tlv length field is non-zero. The FEC TLV is present only when FEC-tlv length field is non-zero.
The FEC TLV specifies the FEC associated with the FEC stack change The FEC TLV specifies the FEC associated with the FEC stack change
operation. This TLV MAY be included when the operation type is operation. This TLV MAY be included when the operation type is
POP. It SHOULD be included when the operation type is PUSH. The POP. It MUST be included when the operation type is PUSH. The
FEC TLV contains exactly 1 FEC from the list of FECs specified in FEC TLV contains exactly 1 FEC from the list of FECs specified in
[RFC4379]. A NIL FEC MAY be associated with a PUSH operation if [RFC4379]. A NIL FEC MAY be associated with a PUSH operation if
the responding router wishes to hide the details of the FEC being the responding router wishes to hide the details of the FEC being
pushed. pushed.
FEC Stack change sub-TLV operation rules: FEC Stack change sub-TLV operation rules:
a. A FEC Stack change sub-TLV containing a PUSH operation MUST NOT a. A FEC Stack change sub-TLV containing a PUSH operation MUST NOT
be followed by a FEC Stack change sub-TLV containing a POP be followed by a FEC Stack change sub-TLV containing a POP
operation. operation.
b. One or more POP operations MAY be followed by one or more PUSH b. One or more POP operations MAY be followed by one or more PUSH
operations. operations.
c. One FEC Stack change sub-TLV MUST be included per FEC stack c. One FEC Stack change sub-TLV MUST be included per FEC stack
change. For example, if 2 labels are going to be pushed, then 1 change. For example, if 2 labels are going to be pushed, then 1
FEC Stack change sub-TLV MUST be included for each FEC. FEC Stack change sub-TLV MUST be included for each FEC.
d. A FEC splice operation (an operation where 1 FEC ends and another d. A FEC splice operation (an operation where 1 FEC ends and another
FEC starts, see Figure 7) SHOULD be performed by including a POP FEC starts, see Figure 7) MUST be performed by including a POP
type FEC Stack change sub-TLV followed by a PUSH type FEC Stack type FEC Stack change sub-TLV followed by a PUSH type FEC Stack
change sub-TLV. change sub-TLV.
e. A Downstream detailed mapping TLV containing only 1 FEC Stack e. A Downstream detailed mapping TLV containing only 1 FEC Stack
Change sub-TLV with Pop operation is equivalent to IS_EGRESS Change sub-TLV with Pop operation is equivalent to IS_EGRESS
(Return code 3, [RFC4379]) for the outermost FEC in the FEC (Return code 3, [RFC4379]) for the outermost FEC in the FEC
stack. The ingress router performing the MPLS traceroute MUST stack. The ingress router performing the MPLS traceroute MUST
treat such a case as an IS_EGRESS for the outermost FEC. treat such a case as an IS_EGRESS for the outermost FEC.
3.4. Deprecation of Downstream Mapping TLV 3.4. Deprecation of Downstream Mapping TLV
The Downstream Mapping TLV has been deprecated. LSP-ping procedures This document deprecates the Downstream Mapping TLV. LSP-ping
should now use the Downstream Detailed Mapping TLV. Detailed procedures should now use the Downstream Detailed Mapping TLV.
procedures regarding interoperability between the deprecated TLV and Detailed procedures regarding interoperability between the deprecated
the new TLV are specified in Section 4.4. TLV and the new TLV are specified in Section 4.4.
4. Performing MPLS traceroute on tunnels 4. Performing MPLS traceroute on tunnels
This section describes the procedures to be followed by an LSP This section describes the procedures to be followed by an LSP
ingress node and LSP transit nodes when performing MPLS traceroute ingress node and LSP transit nodes when performing MPLS traceroute
over MPLS tunnels. over MPLS tunnels.
4.1. Transit node procedure 4.1. Transit node procedure
4.1.1. Addition of a new tunnel 4.1.1. Addition of a new tunnel
skipping to change at page 13, line 48 skipping to change at page 13, line 51
enter a tunnel at that node. Thus, it knows about the new outer FEC. enter a tunnel at that node. Thus, it knows about the new outer FEC.
All transit nodes that are the origination point of a new tunnel All transit nodes that are the origination point of a new tunnel
SHOULD add the a FEC Stack change sub-TLV (Section 3.3.1.3) to the SHOULD add the a FEC Stack change sub-TLV (Section 3.3.1.3) to the
Downstream Detailed Mapping TLV (Figure 3) in the echo reply. The Downstream Detailed Mapping TLV (Figure 3) in the echo reply. The
transit node SHOULD add 1 FEC Stack change sub-TLV of operation type transit node SHOULD add 1 FEC Stack change sub-TLV of operation type
PUSH, per new tunnel being originated at the transit node. PUSH, per new tunnel being originated at the transit node.
A transit node that sends a Downstream FEC Stack change sub-TLV in A transit node that sends a Downstream FEC Stack change sub-TLV in
the echo reply SHOULD fill the address of the remote peer; which is the echo reply SHOULD fill the address of the remote peer; which is
the peer of the current LSP being traced. If the transit node does the peer of the current LSP being traced. If the transit node does
not know the address of the remote peer, it MUST leave it as not know the address of the remote peer, it MUST set the address type
unspecified. to Unspecified.
The Label stack sub-TLV MUST contain 1 additional label per FEC being The Label stack sub-TLV MUST contain 1 additional label per FEC being
PUSHed. The label MUST be encoded as per Figure 5. The label value PUSHed. The label MUST be encoded as per Figure 5. The label value
MUST be the value used to switch the data traffic. If the tunnel is MUST be the value used to switch the data traffic. If the tunnel is
transparent pipe to the node, i.e. the data-plane trace will not transparent pipe to the node, i.e. the data-plane trace will not
expire in the middle of the new tunnel, then a FEC Stack change sub- expire in the middle of the new tunnel, then a FEC Stack change sub-
TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT TLV SHOULD NOT be added and the Label stack sub-TLV SHOULD NOT
contain a label corresponding to the hidden tunnel. contain a label corresponding to the hidden tunnel.
If the transit node wishes to hide the nature of the tunnel from the If the transit node wishes to hide the nature of the tunnel from the
skipping to change at page 15, line 36 skipping to change at page 15, line 39
the end-to-end LDP LSP, then following sequence of FEC Stack change the end-to-end LDP LSP, then following sequence of FEC Stack change
sub-TLVs will be performed sub-TLVs will be performed
Node B: Node B:
Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A. Respond with 2 FEC Stack change sub-TLVs: PUSH RSVP-B, PUSH RSVP-A.
Node D: Node D:
Respond with a Return Code of 3 when RSVP-A is top of FEC stack. Respond with a Return Code of 3 when RSVP-A is top of FEC stack.
Downstream information for node E when echo request contains RSVP-B When the echo request contains RSVP-B as top of stack, respond with
as top of FEC stack and an appropriate Return Code. Downstream information for node E and an appropriate Return Code.
If node B is performing tunnel hiding, then: If node B is performing tunnel hiding, then:
Node B: Node B:
Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC. Respond with 2 FEC Stack change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC.
Node D: Node D:
Respond with either Return Code of 3 (if D can co-relate that the If D can co-relate that the NIL-FEC corresponds to RSVP-A, which
NIL-FEC corresponds to RSVP-A which is terminating at D) or respond terminates at D, then it SHOULD Respond with Return Code of 3. D can
with FEC Stack change sub-TLV: POP (since D knows that number of also respond with FEC Stack change sub-TLV: POP (since D knows that
labels towards next-hop is decreasing). number of labels towards next-hop is decreasing). Both responses
would be valid.
A B C D E F G A B C D E F G
o -------- o -------- o ------ o ------ o ----- o ----- o o -------- o -------- o ------ o ------ o ----- o ----- o
LDP LDP BGP \ RSVP RSVP / LDP LDP LDP BGP \ RSVP RSVP / LDP
\_____________/ \_____________/
LDP LDP
Figure 9: Stitched hierarchical LSPs Figure 9: Stitched hierarchical LSPs
In the above case, node D will send 3 FEC Stack change sub-TLVs. One In the above case, node D will send 3 FEC Stack change sub-TLVs. One
 End of changes. 21 change blocks. 
48 lines changed or deleted 50 lines changed or added

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