draft-ietf-mpls-lsp-ping-enhanced-dsmap-00.txt   draft-ietf-mpls-lsp-ping-enhanced-dsmap-01.txt 
Network Working Group N. Bahadur Network Working Group N. Bahadur
Internet-Draft K. Kompella Internet-Draft K. Kompella
Updates: RFC4379 Juniper Networks, Inc. Updates: RFC4379 (if approved) Juniper Networks, Inc.
(if approved) G. Swallow G. Swallow
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 28, 2008 June 26, 2008 Expires: March 25, 2009 September 21, 2008
Mechanism for performing LSP-Ping over MPLS tunnels Mechanism for performing LSP-Ping over MPLS tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-00 draft-ietf-mpls-lsp-ping-enhanced-dsmap-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 28, 2008. This Internet-Draft will expire on March 25, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 5 3.2. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 5
3.2.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 7 3.2.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 7
3.2.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 7 3.2.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 7
3.2.3. Stack change sub-TLV . . . . . . . . . . . . . . . . . 8 3.2.3. FEC Stack change sub-TLV . . . . . . . . . . . . . . . 8
3.3. Deprecation of Downstream Mapping TLV . . . . . . . . . . 10 3.3. Deprecation of Downstream Mapping TLV . . . . . . . . . . 10
4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 10 4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 10
4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 10 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 10
4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 10 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 10
4.1.2. Transition between tunnels . . . . . . . . . . . . . . 11 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 11
4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 12 4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 13
4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 13 4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 13
4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 13 4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 13
4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 13 4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 13
4.2.2. Modifications to handling to EGRESS_OK responses. . . 15 4.2.2. Modifications to handling to EGRESS_OK responses. . . 15
4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 15 4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
stitched LSP segments. For example, conside the figure below. stitched LSP segments. For example, conside the figure below.
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 2: Stitched LSP Figure 2: Stitched LSP
Consider ingress (A) tracing end-to-end LSP A--F. When an echo Consider ingress (A) tracing end-to-end LSP A--F. When an echo
request reaches router C, there is a FEC change happening at router request reaches router C, there is a FEC stack change happening at
C. With current lsp-ping mechanisms, there is no way to convey this router C. With current lsp-ping mechanisms, there is no way to convey
information to A. Consequently, when the next echo request reaches this information to A. Consequently, when the next echo request
router D, router D will know nothing about the LDP FEC that A is reaches router D, router D will know nothing about the LDP FEC that A
trying to trace. is trying to trace.
Thus, the procedures outlined [RFC4379] do not make it possible for Thus, the procedures outlined [RFC4379] do not make it possible for
the ingress node to: the ingress node to:
1. Know that tunneling has occured 1. Know that tunneling has occured
2. Trace the path of the tunnel 2. Trace the path of the tunnel
3. Trace the path of stitched LSPs 3. Trace the path of stitched LSPs
3. Packet format 3. Packet format
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The Label stack sub-TLV contains the set of labels in the label stack The Label stack sub-TLV contains the set of labels in the label stack
as it would have appeared if this router were forwarding the packet as it would have appeared if this router were forwarding the packet
through this interface. Any Implicit Null labels are explicitly through this interface. Any Implicit Null labels are explicitly
included. The number of labels present in the sub-TLV is determined included. The number of labels present in the sub-TLV is determined
based on the sub-TLV data length. Labels are treated as numbers, based on the sub-TLV data length. Labels are treated as numbers,
i.e., they are right justified in the field. The label format and i.e., they are right justified in the field. The label format and
protocol type are as defined in [RFC4379]. When the Detailed protocol type are as defined in [RFC4379]. When the Detailed
Downstream Mapping TLV in sent in the echo response, this sub-TLV Downstream Mapping TLV in sent in the echo response, this sub-TLV
MUST be included. MUST be included.
3.2.3. Stack change sub-TLV 3.2.3. FEC Stack change sub-TLV
A router SHOULD include the the FEC Stack change sub-TLV when the A router SHOULD include the the FEC Stack change sub-TLV when the
downstream node in the echo response has a different FEC stack than downstream node in the echo response has a different FEC stack than
the FEC stack received in the echo request. One ore more FEC Stack the FEC stack received in the echo request. One or more FEC Stack
change sub-TLVs MAY be present in the Downstream Detailed Mapping change sub-TLVs MAY be present in the Downstream Detailed Mapping
TLV. The format is as below. TLV. 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Address (0, 4 or 16 octets) | | Remote Peer Address (0, 4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. FEC TLV . . FEC TLV .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Stack Change Sub-TLV Figure 8: FEC Stack Change Sub-TLV
Operation Type Operation Type
The operation type specifies the action associated with the FEC The operation type specifies the action associated with the FEC
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
change. For example, if 2 labels are going to be pushed, then 1 stack change. For example, if 2 labels are going to be pushed,
FEC change sub-TLV MUST be included for each FEC. A FEC Swap then 1 FEC Stack change sub-TLV MUST be included for each FEC. A
operation is to be simulated by including a POP type FEC change FEC splice operation (an operation where 1 FEC ends and another
sub-TLV followed by a PUSH type FEC change sub-TLV. FEC starts, see Figure 11) SHOULD be performed by including a POP
type FEC Stack change sub-TLV followed by a PUSH type FEC Stack
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 for the sub-TLV with Pop operation is equivalent to EGRESS_OK for the
outermost FEC in the FEC stack. The ingress router performing the outermost FEC in the FEC stack. The ingress router performing the
lsp trace MUST treat such a case as an EGRESS_OK for the outermost lsp trace MUST treat such a case as an EGRESS_OK for the outermost
FEC. 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
skipping to change at page 9, line 47 skipping to change at page 10, line 5
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 was learned. 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. For upstream assigned labels
[I-D.ietf-mpls-upstream-label], an operation type of POP will have [RFC5331], an operation type of POP will have a remote peer
a remote peer address (the upstream node that assigned the label) address (the upstream node that assigned the label) and this
and this SHOULD be included in the FEC change sub-TLV. 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.
skipping to change at page 11, line 31 skipping to change at page 11, line 37
TLVs, one with a POP operation for the BGP FEC and one with a PUSH TLVs, one with a POP operation for the BGP FEC and one with a PUSH
operation for the RSVP FEC. operation for the RSVP FEC.
If node C wishes to perform FEC hiding, it SHOULD respond back with 2 If node C wishes to perform FEC hiding, it SHOULD respond back with 2
FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP
operation MAY either not include the FEC TLV (by setting FEC TLV operation MAY either not include the FEC TLV (by setting FEC TLV
length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH
operation SHOULD have the FEC TLV contain the NIL FEC. operation SHOULD have the FEC TLV contain the NIL FEC.
If node C performs FEC hiding and node D also performs FEC hiding, If node C performs FEC hiding and node D also performs FEC hiding,
then node D MAY choose to not send any FEC change sub-TLVs in the then node D MAY choose to not send any FEC Stack change sub-TLVs in
echo response since the number of labels has not changed (for the the echo response since the number of labels has not changed (for the
downstream of node D) and the FEC type also has not changed (NIL downstream of node D) and the FEC type also has not changed (NIL
FEC). If node D performs FEC hiding, then node F will respond as FEC). If node D performs FEC hiding, then node F will respond as
EGRESS_OK for the NIL FEC. The ingress (node A) will know that EGRESS_OK for the NIL FEC. The ingress (node A) will know that
EGRESS_OK corresponds to the end-to-end LSP. EGRESS_OK corresponds to the end-to-end LSP.
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 |\ RSVP-A | LDP LDP |\ RSVP-A | LDP
| \_______________________________/| | \_______________________________/|
skipping to change at page 12, line 4 skipping to change at page 12, line 13
EGRESS_OK corresponds to the end-to-end LSP. EGRESS_OK corresponds to the end-to-end LSP.
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 |\ RSVP-A | LDP LDP |\ RSVP-A | LDP
| \_______________________________/| | \_______________________________/|
| RSVP-B | | RSVP-B |
\________________________________/ \________________________________/
LDP LDP
Figure 12: Hierarchical LSPs Figure 12: Hierarchical LSPs
In the above figure, the following sequence of FEC change sub-TLVs In the above figure, the following sequence of FEC Stack change sub-
will be performed TLVs will be performed
Node B: Node B:
Respond with 2 FEC 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 EGRESS_OK when RSVP-A is top of FEC stack. Downstream Respond with EGRESS_OK when RSVP-A is top of FEC stack. Downstream
information for node E when echo request contains RSVP-B as top of information for node E when echo request contains RSVP-B as top of
FEC stack. FEC stack.
If node B is performing tunnel hiding, then: If node B is performing tunnel hiding, then:
Node B: Node B:
Respond with 2 FEC 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 EGRESS_OK (if D can co-relate that the NIL-FEC Respond with either EGRESS_OK (if D can co-relate that the NIL-FEC
corresponds to RSVP-A which is terminating at D) or respond with FEC corresponds to RSVP-A which is terminating at D) or respond with FEC
change sub-TLV: POP (since D knows that number of labels towards Stack change sub-TLV: POP (since D knows that number of labels
next-hop is decreasing). towards next-hop is decreasing).
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 13: Stitched hierarchical LSPs Figure 13: Stitched hierarchical LSPs
In the above case, node D will send 3 FEC change sub-TLVs. One POP In the above case, node D will send 3 FEC Stack change sub-TLVs. One
(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). RSVP).
4.2. Ingress node procedure 4.2. 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.
skipping to change at page 16, line 40 skipping to change at page 16, line 40
NIL FEC ensures that the trace progresses without false negatives NIL FEC ensures that the trace progresses without false negatives
and all transit nodes (of the new outer tunnel) perform some and all transit nodes (of the new outer tunnel) perform some
minimal validations on the received echo requests. minimal validations on the received echo requests.
In inter-AS (autonomous system) scenarios, information regarding the In inter-AS (autonomous system) scenarios, information regarding the
LSP FEC change(s) SHOULD NOT be passed across domains. A NIL FEC MAY LSP FEC change(s) SHOULD NOT be passed across domains. A NIL FEC MAY
be used to make the trace go through without false positives. An be used to make the trace go through without false positives. An
ASBR (autonomous system border router) may choose to intercept all ASBR (autonomous system border router) may choose to intercept all
echo requests and echo responses and change them to hide FEC echo requests and echo responses and change them to hide FEC
information from other domains. Detailed operation regarding the information from other domains. Detailed operation regarding the
same is outside the scope of this document. Passing of FEC change same is outside the scope of this document. Passing of FEC stack
information between domains MAY be done if the two AS domains belong change information between domains MAY be done if the two AS domains
to the same provider/organization. belong to the same provider/organization.
Other security considerations, as discussed in [RFC4379] are also Other security considerations, as discussed in [RFC4379] are also
applicable to this document. applicable to this document.
6. IANA Considerations 6. IANA Considerations
This document introduces a new Downstream Detailed Mapping TLV. It IANA is requested to assign TLV type value to the following TLV from
is requested that IANA assign a TLV type in the range of 0-32767 from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched
the TLV type registry created in [RFC4379]. Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-
registry.
It is requested that IANA create a new registry for the Sub-Type Downstream Detailed Mapping TLV (See Section 3.2). Suggested value:
field of Downstream Detailed Mapping TLV. The valid range for this 20.
is 0-65535. Assignments in the range 0-16383 and 32768-49161 are
made via Standards Action as defined in [RFC3692]; assignments in the IANA is requested to create a new registry for the Sub-Type field of
Downstream Detailed Mapping TLV. The valid range for this is
0-65535. Assignments in the range 0-16383 and 32768-49161 are made
via Standards Action as defined in [RFC3692]; assignments in the
range 16384-31743 and 49162-64511 are made via Specification Required range 16384-31743 and 49162-64511 are made via Specification Required
([RFC4379]); values in the range 31744-32767 and 64512-65535 are for ([RFC4379]); values in the range 31744-32767 and 64512-65535 are for
Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has a Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has a
Type that falls in the range for Vendor Private Use, the Length MUST Type that falls in the range for Vendor Private Use, the Length MUST
be at least 4, and the first four octets MUST be that vendor's SMI be at least 4, and the first four octets MUST be that vendor's SMI
Enterprise Code, in network octet order. The rest of the Value field Enterprise Code, in network octet order. The rest of the Value field
is private to the vendor. is private to the vendor.
It is requested that IANA assign a sub-TLV types from the 0-32767 It is requested that IANA assign sub-TLV types from this new registry
range for the sub-TLVs defined in Figure 5. to the following sub-TLVs (See Figure 5).
Multipath data sub-TLV: Suggested value: 1
Label stack sub-TLV: Suggested value: 2
FEC Stack change sub-TLV: Suggested value: 3
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Yakov Rekhter and Adrian Farrel for The authors would like to thank Yakov Rekhter and Adrian Farrel for
their suggestions on the draft. their suggestions on the draft.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 17, line 42 skipping to change at page 18, line 7
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
8.2. Informative References 8.2. Informative References
[I-D.ietf-mpls-upstream-label] [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
draft-ietf-mpls-upstream-label-06 (work in progress), RFC 5331, August 2008.
June 2008.
Authors' Addresses Authors' Addresses
Nitin Bahadur Nitin Bahadur
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Phone: +1 408 745 2000 Phone: +1 408 745 2000
 End of changes. 30 change blocks. 
52 lines changed or deleted 66 lines changed or added

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