draft-ietf-mpls-lsp-ping-enhanced-dsmap-05.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-06.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: November 27, 2010 Cisco Systems Expires: February 11, 2011 Cisco Systems
May 26, 2010 August 10, 2010
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-05 draft-ietf-mpls-lsp-ping-enhanced-dsmap-06
Abstract Abstract
This document describes methods for performing lsp-ping traceroute This document describes methods for performing lsp-ping traceroute
over mpls tunnels and for traceroute of stitched mpls LSPs. The over mpls tunnels and for traceroute of stitched mpls LSPs. The
techniques outlined in RFC 4379 are insufficient to perform techniques outlined in RFC 4379 are insufficient to perform
traceroute FEC validation and path discovery for a LSP that goes over traceroute FEC validation and path discovery for a 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).
These enhancements along with other procedures outlined in this These enhancements along with other procedures outlined in this
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2010. This Internet-Draft will expire on February 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 24 skipping to change at page 3, line 24
3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6 3.2.2. Return code for stitched LSPs . . . . . . . . . . . . 6
3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 6 3.3. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 6
3.3.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 8 3.3.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 8
3.3.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 9 3.3.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 9
3.3.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 9 3.3.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 9
3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 12 3.4. Deprecation of Downstream Mapping TLV . . . . . . . . . . 12
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 12 4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 12
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 12 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 12
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 12 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 12
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 13 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 13
4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 15 4.1.3. Modification to FEC Validation procedure on Transit . 15
4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 15 4.2. Modification to FEC Validation procedure on Egress . . . . 15
4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 15 4.3. Ingress node procedure . . . . . . . . . . . . . . . . . . 15
4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 15 4.3.1. Processing Downstream Detailed Mapping TLV . . . . . . 15
4.2.2. Modifications to handling to EGRESS_OK responses. . . 17 4.3.1.1. Stack Change sub-TLV not present . . . . . . . . . 15
4.2.3. Handling of new return codes . . . . . . . . . . . . . 17 4.3.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 16
4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 17 4.3.2. Modifications to handling to EGRESS_OK responses. . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4.3.3. Handling of new return codes . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4.4. Handling deprecated Downstream Mapping TLV . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This documents describes methods for performing lsp-ping traceroute This documents describes methods for performing lsp-ping traceroute
over mpls tunnels. The techniques outlined in [RFC4379] outline a over mpls tunnels. The techniques outlined in [RFC4379] outline a
traceroute mechanism that includes FEC validation and ECMP path traceroute mechanism that includes FEC validation and ECMP path
discovery. Those mechanisms are insufficient and do not provide discovery. Those mechanisms are insufficient and do not provide
details in case the FEC being traced traverses one or more mpls details in case the FEC being traced traverses one or more mpls
tunnels and in case where LSP stitching is in use. This document tunnels and in case where LSP stitching is in use. This document
defines enhancements to the downstream-mapping TLV [RFC4379] to make defines enhancements to the downstream-mapping TLV [RFC4379] to make
skipping to change at page 6, line 33 skipping to change at page 6, line 33
response message. If the Return Code is set in the echo request response message. If the Return Code is set in the echo request
message, then it SHOULD be ignored. When this Return Code is set, message, then it SHOULD be ignored. When this Return Code is set,
each Downstream Detailed Mapping TLV MUST have an appropriate Return each Downstream Detailed Mapping TLV MUST have an appropriate Return
Code and Return SubCode. This Return Code is to be used when there Code and Return SubCode. This Return Code is to be used when there
are multiple downstreams for a given node (such as P2MP or ECMP), and are multiple downstreams for a given node (such as P2MP or ECMP), and
the node wants to return a different Return Code/Return SubCode for the node wants to return a different Return Code/Return SubCode for
each downstream. each downstream.
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 Figure 10, the When a traceroute is being performed on stitched LSPs, Figure 10, the
stitching point SHOULD indicate the stitching action to the node 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 other than "Label switched with FEC change". This Return Code
MUST NOT be used if no Label Stack sub-TLVs (Section 3.3.3) are MUST NOT be used if no FEC Stack sub-TLV (Section 3.3.3) is present
present in the Downstream Detailed Mapping TLV(s). This new Return in the Downstream Detailed Mapping TLV(s). This new Return Code MAY
Code MAY be used for hierarchical LSPs (for indicating start or end be used for hierarchical LSPs (for indicating start or end of an
of an outer LSP). outer LSP).
3.3. Downstream Detailed Mapping TLV 3.3. Downstream Detailed Mapping TLV
A new TLV has been added to the mandatory range of TLVs. The TLV A new TLV has been added to the mandatory range of TLVs. The TLV
type is pending IANA allocation. type is pending IANA allocation.
Type # Value Field Type # Value Field
------ ------------ ------ ------------
TBD Downstream detailed mapping TBD Downstream detailed mapping
skipping to change at page 10, line 28 skipping to change at page 10, line 28
Operation Type Operation Type
The operation type specifies the action associated with the FEC The operation type specifies the action associated with the FEC
stack change. The following operation types are defined. stack change. The following operation types are defined.
Type # Operation Type # Operation
------ --------- ------ ---------
1 Push 1 Push
2 Pop 2 Pop
3 Swap
Operation Type Values Operation Type Values
A FEC Stack change sub-TLV containing a PUSH operation MUST NOT be A FEC Stack change sub-TLV containing a PUSH operation MUST NOT be
followed by a FEC Stack change sub-TLV containing a POP operation. followed by a FEC Stack change sub-TLV containing a POP operation.
One or more POP operations MAY be followed by one or more PUSH One or more POP operations MAY be followed by one or more PUSH
operations. One FEC Stack change sub-TLV MUST be included per FEC operations. One FEC Stack change sub-TLV MUST be included per FEC
stack change. For example, if 2 labels are going to be pushed, stack change. For example, if 2 labels are going to be pushed,
then 1 FEC Stack change sub-TLV MUST be included for each FEC. A then 1 FEC Stack change sub-TLV MUST be included for each FEC. A
FEC splice operation (an operation where 1 FEC ends and another FEC splice operation (an operation where 1 FEC ends and another
FEC starts, see Figure 10) SHOULD be performed by including a POP FEC starts, see Figure 10) SHOULD 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.
A Downstream detailed mapping TLV containing only 1 FEC change A Downstream detailed mapping TLV containing only 1 FEC change
sub-TLV with Pop operation is equivalent to EGRESS_OK (Return code sub-TLV with Pop operation is equivalent to EGRESS_OK (Return code
3, [RFC4379]) for the outermost FEC in the FEC stack. The ingress 3, [RFC4379]) for the outermost FEC in the FEC stack. The ingress
router performing the lsp trace MUST treat such a case as an router performing the lsp trace MUST treat such a case as an
EGRESS_OK for the outermost FEC. EGRESS_OK for the outermost FEC.
The Downstream Detailed Mapping TLV MUST contain at most 1 FEC
Stack change sub-TLV of type Swap. In a FEC Stack change sub-TLV
with Swap operation, the address-type MAY be set to Unspecified
and the FEC-tlv length MAY be set to 0.
FEC tlv Length FEC tlv Length
Length in bytes of the FEC TLV. Length in bytes of the FEC TLV.
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 in case the
LSP goes over a tunnel of a different address family. The address LSP goes over a tunnel of a different address family. The address
skipping to change at page 11, line 44 skipping to change at page 11, line 36
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 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 over RSVP case Figure 1, router B would respond back with the
address of router D as the remote peer address for the LDP FEC address of router D as the remote peer address for the LDP FEC
being traced. This allows the ingress node to provide helpful being traced. This allows the ingress node to provide helpful
information regarding FEC peers. If the operation type is PUSH, information regarding FEC peers. If the operation type is PUSH,
the remote peer address is the address of the peer from which the the remote peer address is the address of the peer from which the
FEC was learned. If the operation type is POP, the remote peer FEC being pushed was learnt. If the operation type is POP, the
address MAY be set to Unspecified. For upstream assigned labels remote peer address MAY be set to Unspecified. For upstream
[RFC5331], an operation type of POP will have a remote peer assigned labels [RFC5331], an operation type of POP will have a
address (the upstream node that assigned the label) and this remote peer address (the upstream node that assigned the label)
SHOULD be included in the FEC Stack change sub-TLV. and this SHOULD be included in the FEC Stack change sub-TLV.
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 SHOULD 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.
3.4. Deprecation of Downstream Mapping TLV 3.4. Deprecation of Downstream Mapping TLV
The Downstream Mapping TLV has been deprecated. LSP-ping procedures The Downstream Mapping TLV has been deprecated. LSP-ping procedures
should now use the Downstream Detailed Mapping TLV. Detailed should now use the Downstream Detailed Mapping TLV. Detailed
procedures regarding interoperability between the deprecated TLV and procedures regarding interoperability between the deprecated TLV and
the new tlv are specified in Section 4.3. the new tlv are specified in Section 4.4.
4. Performing lsp-ping traceroute on tunnels 4. Performing lsp-ping traceroute on tunnels
This section describes the procedures to be followed by an ingress This section describes the procedures to be followed by an ingress
node and transit nodes when performing lsp-ping traceroute over mpls node and transit nodes when performing lsp-ping traceroute over mpls
tunnels. 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 12, line 44 skipping to change at page 12, line 36
Downstream Detailed Mapping TLV (Figure 4) in the echo-response. The Downstream Detailed Mapping TLV (Figure 4) in the echo-response. 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 response SHOULD fill the address of the remote peer; which the echo response SHOULD fill the address of the remote peer; which
is the peer of the current LSP being traced. If the transit node is the peer of the current LSP being traced. If the transit node
does not know the address of the remote peer, it MAY leave it as does not know the address of the remote peer, it MAY leave it as
unspecified. unspecified.
The Label stack sub-TLV MUST contain 1 additional label per FEC being
PUSHed. The label value MUST be the value used to switch the data
traffic. If the tunnel is transparent 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-TLV SHOULD NOT be added and the Label stack sub-
TLV SHOULD NOT 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
ingress of the echo-request, then it MAY not want to send details ingress of the echo-request, then it MAY not want to send details
about the new tunnel FEC to the ingress. In such a case, the transit about the new tunnel FEC to the ingress. In such a case, the transit
node SHOULD use the NIL FEC. The echo response would then contain a node SHOULD use the NIL FEC. The echo response would then contain a
FEC Stack change sub-TLV with operation type PUSH and a NIL FEC. The FEC Stack change sub-TLV with operation type PUSH and a NIL FEC. The
value of the label in the NIL FEC MUST be set to zero. The remote value of the label in the NIL FEC MUST be set to zero. The remote
peer address type MUST be set to Unspecified. The transit node peer address type MUST be set to Unspecified. The transit node
SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new
tunnel being originated at the transit node. tunnel being originated at the transit node. The Label stack sub-TLV
MUST contain 1 additional label per FEC being PUSHed. The label
value MUST be the value used to switch the data traffic.
4.1.2. Transition between tunnels 4.1.2. Transition between tunnels
A B C D E F A B C D E F
o -------- o -------- o --------- o -------- o ------- o o -------- o -------- o --------- o -------- o ------- o
\_____/ \______/ \______/ \______/ \_______/ \_____/ \______/ \______/ \______/ \_______/
LDP LDP BGP RSVP RSVP LDP LDP BGP RSVP RSVP
Figure 10: Stitched LSPs Figure 10: Stitched LSPs
skipping to change at page 15, line 13 skipping to change at page 15, line 13
LDP LDP
Figure 12: Stitched hierarchical LSPs Figure 12: 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
POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for POP (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for
RSVP). Nodes C and D SHOULD set the Return Code to "Label switched RSVP). Nodes C and D SHOULD set the Return Code to "Label switched
with FEC change" (Section 6.3) to indicate change in FEC being with FEC change" (Section 6.3) to indicate change in FEC being
traced. traced.
4.2. Ingress node procedure 4.1.3. Modification to FEC Validation procedure on Transit
Section 4.4 of [RFC4379] specifies Target FEC stack validation
procedures. This document enhances the FEC validation procedures as
follows. If the outermost FEC of the target FEC stack is the NIL
FEC, then the node MUST skip the target FEC validation completely.
This is to support FEC hiding, in which the outer hidden FEC can be
the NIL FEC.
4.2. Modification to FEC Validation procedure on Egress
Section 4.4 of [RFC4379] specifies Target FEC stack validation
procedures. This document enhances the FEC validation procedures as
follows. If the outermost FEC of the target FEC stack is the NIL
FEC, then the node MUST skip the target FEC validation completely.
This is to support FEC hiding, in which the outer hidden FEC can be
the NIL FEC.
4.3. Ingress node procedure
It is the responsibility of an ingress node to understand tunnel It is the responsibility of an ingress node to understand tunnel
within tunnel semantics and lsp stitching semantics when performing a within tunnel semantics and lsp stitching semantics when performing a
lsp traceroute. This section describes the ingress node procedure lsp traceroute. This section describes the ingress node procedure
based on the kind of response an ingress node receives from a transit based on the kind of response an ingress node receives from a transit
node. node.
4.2.1. Processing Downstream Detailed Mapping TLV 4.3.1. Processing Downstream Detailed Mapping TLV
Downstream Detailed Mapping TLV should be processed in procedures Downstream Detailed Mapping TLV should be processed in procedures
similar to those of Downstream Mapping TLV, defined in Section 4.4 of similar to those of Downstream Mapping TLV, defined in Section 4.4 of
[RFC4379] [RFC4379]
4.2.1.1. Stack Change sub-TLV not present 4.3.1.1. Stack Change sub-TLV not present
This would be the default behavior as described in [RFC4379]. The This would be the default behavior as described in [RFC4379]. The
ingress node MUST perform echo response processing as per the ingress node MUST perform echo response processing as per the
procedures in [RFC4379]. procedures in [RFC4379].
4.2.1.2. Stack Change sub-TLV(s) present 4.3.1.2. Stack Change sub-TLV(s) present
If one or more FEC Stack change sub-TLVs (Section 3.3.3) are received If one or more FEC Stack change sub-TLVs (Section 3.3.3) are received
in the echo response, the ingress node SHOULD process them and in the echo response, the ingress node SHOULD process them and
perform some validation. perform some validation.
The FEC stack changes are associated with a downstream neighbor and The FEC stack changes are associated with a downstream neighbor and
along a particular path of the LSP. Consequently, the ingress will along a particular path of the LSP. Consequently, the ingress will
need to maintain a FEC-stack per path being traced (in case of need to maintain a FEC-stack per path being traced (in case of
multipath). All changes to the FEC stack resulting from the multipath). All changes to the FEC stack resulting from the
processing of FEC Stack change sub-TLV(s) should be applied only for processing of FEC Stack change sub-TLV(s) should be applied only for
skipping to change at page 17, line 17 skipping to change at page 18, line 17
If the top of the FEC stack is a NIL FEC and the echo response does If the top of the FEC stack is a NIL FEC and the echo response does
not contain any FEC Stack change sub-TLV, then it does not not contain any FEC Stack change sub-TLV, then it does not
necessarily mean that the LSP has not started traversing a different necessarily mean that the LSP has not started traversing a different
tunnel. It could be that the LSP associated with the NIL FEC tunnel. It could be that the LSP associated with the NIL FEC
terminated at a transit node and at the same time a new LSP started terminated at a transit node and at the same time a new LSP started
at the same transit node. The NIL FEC would now be associated with at the same transit node. The NIL FEC would now be associated with
the new LSP (and the ingress has no way of knowing this). Thus, it the new LSP (and the ingress has no way of knowing this). Thus, it
is not possible to build an accurate hierarchical LSP topology if a is not possible to build an accurate hierarchical LSP topology if a
traceroute contains NIL FECs. traceroute contains NIL FECs.
4.2.2. Modifications to handling to EGRESS_OK responses. 4.3.2. Modifications to handling to EGRESS_OK responses.
The procedures above allow the addition of new FECs to the original The procedures above allow the addition of new FECs to the original
FEC being traced. Consequently, the EGRESS_OK response from a FEC being traced. Consequently, the EGRESS_OK response from a
downstream node may not necessarily be for the FEC being traced. It downstream node may not necessarily be for the FEC being traced. It
could be for one of the new FECs that was added. On receipt of an could be for one of the new FECs that was added. On receipt of an
EGRESS_OK response, the ingress should check if the depth of Target EGRESS_OK response, the ingress should check if the depth of Target
FEC sent to the node that just responded, was the same as the depth FEC sent to the node that just responded, was the same as the depth
of the FEC that was being traced. If it was not, then it should pop of the FEC that was being traced. If it was not, then it should pop
the an entry from the Target FEC stack and resend the request with the an entry from the Target FEC stack and resend the request with
the same TTL (as previously sent). The process of popping a FEC is the same TTL (as previously sent). The process of popping a FEC is
to be repeated until either the ingress receives a non-EGRESS_OK to be repeated until either the ingress receives a non-EGRESS_OK
response or until all the additional FECs added to the FEC stack have response or until all the additional FECs added to the FEC stack have
already been popped. Using EGRESS_OK responses, an ingress can build already been popped. Using EGRESS_OK responses, an ingress can build
a map of the hierarchical LSP structure traversed by a given FEC. a map of the hierarchical LSP structure traversed by a given FEC.
4.2.3. Handling of new return codes 4.3.3. Handling of new return codes
When the echo response Return Code is "Label switched with FEC When the echo response Return Code is "Label switched with FEC
change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC change" (Section 3.2.2), the ingress node SHOULD manipulate the FEC
stack as per the FEC Stack change sub-TLVs contained in the detailed stack as per the FEC Stack change sub-TLVs contained in the
downstream mapping TLV. A transit node can use this Return Code for downstream detailed mapping TLV. A transit node can use this Return
stitched LSPs and for hierarchical LSPs. In case of ECMP or P2MP, Code for stitched LSPs and for hierarchical LSPs. In case of ECMP or
there could be multiple paths and detailed downstream mapping TLVs P2MP, there could be multiple paths and downstream detailed mapping
with different return codes (Section 3.2.1). The ingress node should TLVs with different return codes (Section 3.2.1). The ingress node
build the topology based off the Return Code per ECMP path/P2MP should build the topology based off the Return Code per ECMP path/
branch. P2MP branch.
4.3. Handling deprecated Downstream Mapping TLV 4.4. Handling deprecated Downstream Mapping TLV
The Downstream Mapping TLV has been deprecated. Applications should The Downstream Mapping TLV has been deprecated. Applications should
now use the Downstream Detailed Mapping TLV. The following now use the Downstream Detailed Mapping TLV. The following
procedures SHOULD be used for backward compatibility with routers procedures SHOULD be used for backward compatibility with routers
that do not support the Downstream Detailed Mapping TLV. that do not support the Downstream Detailed Mapping TLV.
o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV
MUST never be sent together in the same echo request or in the MUST never be sent together in the same echo request or in the
same echo response. same echo response.
o If the echo request contains a Downstream Detailed Mapping TLV and o If the echo request contains a Downstream Detailed Mapping TLV and
the corresponding echo response contains an Return Code of 2 (one the corresponding echo response contains an Return Code of 2 (one
or more of the TLVs was not understood), then the sender of the or more of the TLVs was not understood), then the sender of the
echo request MAY resend the echo request with the Downstream echo request MAY resend the echo request with the Downstream
Mapping TLV (instead of the Downstream Detailed Mapping TLV). In Mapping TLV (instead of the Downstream Detailed Mapping TLV). In
cases where a detailed response is needed, the sender can choose cases where a detailed response is needed, the sender can choose
to ignore the router that does not support the Downstream Detailed to ignore the router that does not support the Downstream Detailed
Mapping TLV. Mapping TLV.
o If the echo request contains a Downstream Mapping TLV, then a o If the echo request contains a Downstream Mapping TLV, then a
Downstream Detailed Mapping TLV MUST NOT be sent in the echo Downstream Detailed Mapping TLV MUST NOT be sent in the echo
response. This is to handle the case that the sender of the echo response. This is to handle the case that the sender of the echo
request does not support the new TLV. request does not support the new TLV. The echo response MAY
contain Downstream Mapping TLV(s).
o If echo request forwarding is in use; such that the echo request o If echo request forwarding is in use; such that the echo request
is processed at an intermediate router and then forwarded on; then is processed at an intermediate router and then forwarded on; then
the intermediate router is responsible for making sure that the the intermediate router is responsible for making sure that the
TLVs being used among the ingress, intermediate and destination TLVs being used among the ingress, intermediate and destination
are consistent. The intermediate router MUST NOT forward an echo are consistent. The intermediate router MUST NOT forward an echo
request or an echo response containing a Downstream Detailed request or an echo response containing a Downstream Detailed
Mapping TLV if it itself does not support that TLV. Mapping TLV if it itself does not support that TLV.
5. Security Considerations 5. Security Considerations
 End of changes. 22 change blocks. 
52 lines changed or deleted 75 lines changed or added

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