Skip to main content

Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
RFC 6424

Revision differences

Document history

Date Rev. By Action
2015-10-14
11 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-lsp-ping-enhanced-dsmap@ietf.org to (None)
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
11 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2011-11-07
11 Amy Vezza State changed to RFC Published from RFC Ed Queue.
2011-11-04
11 (System) RFC published
2011-09-27
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-09-27
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-09-27
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-09-23
11 (System) IANA Action state changed to In Progress
2011-09-22
11 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-21
11 Amy Vezza IESG state changed to Approved-announcement sent
2011-09-21
11 Amy Vezza IESG has approved the document
2011-09-21
11 Amy Vezza Closed "Approve" ballot
2011-09-21
11 Amy Vezza Approval announcement text regenerated
2011-09-21
11 Amy Vezza Ballot writeup text changed
2011-09-21
11 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-09-20
11 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss
2011-09-10
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-09-10
11 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-11.txt
2011-08-11
11 Cindy Morgan Removed from agenda for telechat
2011-08-11
11 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-08-11
11 Stephen Farrell
[Ballot comment]
I see that this defines a "NIL FEC" that can be used to hide
information, which is just fine. That made me wonder …
[Ballot comment]
I see that this defines a "NIL FEC" that can be used to hide
information, which is just fine. That made me wonder though
if this is only needed here or maybe also elsewhere (e.g.
in draft-ietf-mpls-p2mp-lsp-ping)? Or, perhaps other MPLS
ping functions need some equivalent? (Just checking.)
2011-08-11
11 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2011-08-10
11 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-08-09
11 David Harrington
[Ballot comment]
in 3.2.1, s/the node needs to return a different Return Code/Return SubCode for each downstream. / the node needs to return a Return …
[Ballot comment]
in 3.2.1, s/the node needs to return a different Return Code/Return SubCode for each downstream. / the node needs to return a Return Code/Return SubCode for each downstream./ (I suspect that each return code may not need to be different)
in 3.4, "The Downstream Mapping TLV has been deprecated." should this be "This document deprecates the Downstream Mapping TLV"? If another document specified the deprecation, please provide a reference.
2011-08-09
11 David Harrington
[Ballot discuss]
This document looks good overall.
I have a few questions, especially about a few places where ambiguity exists about what is required in …
[Ballot discuss]
This document looks good overall.
I have a few questions, especially about a few places where ambiguity exists about what is required in a compliant implementation. I think these will all be easy to resolve.

1) in 3.2.2, should there be a RECOMMENDED predictable return code when FEC hiding is used, rather than leaving it implementation-dependent?

2) in 3.3, shouldn't some of these SHOULDs be MUSTs to improve interoperability? If SHOULD, then what are the acceptable MAY conditions?

3) in 3.3.1.3, Figure 6 shows that an address can be 0 length, but the description of a remote peer address does not specify how to specify an Unspecified address. The table under address type seems to indicate that when type-0, length MUST be 0, when type=1, length MUST be 4, and when type=2 length MUST be 16, but these requirements are not stated explicitly in RFC2119 language.

4) in 4.1.1, "the origination point of a new tunnel" is the tunnel always new? or is this the origination point of a tunnel that already exists? Aren't we tracing existing tunnels? If so, I recommend "the origination point of a tunnel". If this is a **new** tunnel just being created, can you describe when this circumstance would occur? or does "new" mean it is new to the traceroute operation? If this is what new means, can you describe how the traceroute fucntionality on this node would know that?

5) in 4.1.1, "If the transit node does not know the address of the remote peer, it MUST leave it as Unspecified." The term 'it' is ambiguous; does this mean the address type must be set to 0 per 3.3.13? what if the node knows the address type of the tunnel, but not the address, or knows the address type but chooses to not reveal the address? could it specify the address type as IPv4 or IPv6 but leave the address 0-length? and would this be useful for the ingress (operator) to know?

6) in 4.1.1, the last paragraph starts with a conditional, but contains MUST langauge, "The transit node SHOULD add 1 FEC Stack change sub-TLV of operation type PUSH, per new tunnel being originated at the transit node." Is this normative langauge only applicable to nodes that wish to hide the nature of the tunnel? or shoudl this start a new paragraph?

7) in 4.1.2, I might just be confused. You have multiple levels of return codes; which return code is intended here - "Nodes C and D SHOULD set the Return Code to "Label switched with FEC change" (Section 6.3) to indicate change in FEC being traced."

8) in 4.1.2, the description following figure 8 would be easier to read, and less ambiguous, if it used sentences rather than clauses. For example, "Downstream information for node E when echo request contains RSVP-B as top of FEC stack and an appropriate Return Code." If thi smenas what i think it means, it would be much easier to parse if it said "When the echo request contains RSVP-B as top of FEC stack, then the response should contain Downstream information for node E and an appropriate Return Code." But I can parse this sentence in other ways to get different results, including "When the echo request contains RSVP-B as top of FEC stack and an appropriate Return Code..., Downstream information for node E " (which means that I determine whether to include downstream data based on the return code in the request.)
The number of conditions makes this section difficult to read, and writing in non-sentences makes it unnecessarily more difficult.
2011-08-09
11 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2011-08-09
11 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-08-09
11 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-08-09
11 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-08-08
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-08-08
11 Sean Turner
[Ballot discuss]
The algorithm in 4.3.1.2 looks like a code component?  If it is then according to the IETF's TLP section 4.b, it needs to …
[Ballot discuss]
The algorithm in 4.3.1.2 looks like a code component?  If it is then according to the IETF's TLP section 4.b, it needs to be identified as such.  Normally, this means encapsulating the algorithm between and markers. It also needs to include the BSD license between the markers.
2011-08-08
11 Sean Turner
[Ballot discuss]
The algorithm in 4.3.1.2 looks like a code component?  If it is then according to the IETF's TLP section 4.b, it needs to …
[Ballot discuss]
The algorithm in 4.3.1.2 looks like a code component?  If it is then according to the IETF's TLP section 4.b, it needs to be identified as such.  Normally, this means encapsulating it between and markers. It also needs to include the BSD license between the markers.
2011-08-08
11 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-08-07
11 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-08-06
11 Ralph Droms
[Ballot comment]
Very minor editorial suggestions:

Section 1:

  This documents describes methods for performing LSP-Ping (specified
  in [RFC4379] traceroute over MPLS …
[Ballot comment]
Very minor editorial suggestions:

Section 1:

  This documents describes methods for performing LSP-Ping (specified
  in [RFC4379] traceroute over MPLS tunnels.

change to "This document [...]"; is there a right paren missing?

In the next sentence "in case where" sounds wrong; perhaps use
"in the case where" for both parts of the sentence?

Section 3.3.1:

  MAY be include [...]

change to "MAY be included"
2011-08-06
11 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-08-05
11 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Joseph Salowey.
2011-08-02
11 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-08-01
11 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-07-29
11 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded
2011-07-19
11 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2011-07-19
11 Stewart Bryant Ballot has been issued
2011-07-19
11 Stewart Bryant Created "Approve" ballot
2011-07-19
11 Stewart Bryant Placed on agenda for telechat - 2011-08-11
2011-07-19
11 Stewart Bryant State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-06-30
10 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-10.txt
2011-06-17
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Joseph Salowey
2011-06-17
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Joseph Salowey
2011-06-17
11 Samuel Weiler Assignment of request for Last Call review by SECDIR to Kurt Zeilenga was rejected
2011-06-17
11 Stewart Bryant Waiting on revised ID for draft-ietf-mpls-p2mp-lsp-ping-16 since they should proceed in parallel
2011-06-01
11 Michael Scharf Request for Last Call review by TSVDIR Completed. Reviewer: Michael Scharf.
2011-05-31
11 Stewart Bryant Ballot writeup text changed
2011-05-31
11 Stewart Bryant Ballot writeup text changed
2011-05-30
11 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-05-27
11 Amanda Baber
IANA understands that, upon approval of this document, there are three
IANA Actions that need to be completed.

First in the TLVs and sub-TLVs subregistry …
IANA understands that, upon approval of this document, there are three
IANA Actions that need to be completed.

First in the TLVs and sub-TLVs subregistry of the Multi-Protocol Label
Switching (MPLS) Label Switched Paths (LSPs) Parameters located at:

http://www.iana.org/assignments/mpls-lsp-parameters/mpls-lsp-parameters.xml

the reference should be changed for TLV 20 to [ RFC-to-be ] and the
temporary notation for the registration should be removed.

Second, also in the TLVs and sub-TLVs subregistry of the Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Parameters located at:

http://www.iana.org/assignments/mpls-lsp-parameters/mpls-lsp-parameters.xml

a new registry for the Sub-Type field of Downstream Detailed Mapping TLV
will be created. The range of values for this Subtype will be 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 ([RFC4379]); values in
the range 31744-32767 and 64512-65535 are for Vendor Private Use, and
MUST NOT be allocated. Initial values for the Subtype are already in the
registry described in task 1 above.
The references for these assignments will be updated to [ RFC-to-be ]
and the temporary assignment markings will be removed.

Third, the two Return Codes in the Multi-Protocol Label Switching (MPLS)
Label Switched Paths (LSPs) Parameters located at:

http://www.iana.org/assignments/mpls-lsp-parameters/mpls-lsp-parameters.xml

that were given temporary registrations will be updated so that their
reference points to [ RFC-to-be ] and have their TEMPORARY registration
notations removed.

IANA understands that these are the only actions required upon approval
of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This
message is only to confirm what actions will be performed.
2011-05-19
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2011-05-19
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kurt Zeilenga
2011-05-18
11 David Harrington Request for Last Call review by TSVDIR is assigned to Michael Scharf
2011-05-18
11 David Harrington Request for Last Call review by TSVDIR is assigned to Michael Scharf
2011-05-16
11 Amy Vezza Last call sent
2011-05-16
11 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Mechanism for performing LSP-Ping over MPLS tunnels) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Mechanism for performing LSP-Ping over MPLS tunnels'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-05-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This document describes methods for performing LSP Ping (specified in
RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched
MPLS label-switched-paths (LSPs).  The techniques outlined in RFC
4379
are insufficient to perform traceroute Forwarding Equivalency
Class (FEC) validation and path discovery for a LSP that goes over
other MPLS tunnels or for a stitched LSP.  This document describes
enhancements to the downstream-mapping TLV (defined in RFC 4379).
These enhancements along with other procedures outlined in this
document can be used to trace such LSPs.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-enhanced-dsmap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-enhanced-dsmap/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1084/
  http://datatracker.ietf.org/ipr/1053/



2011-05-16
11 Stewart Bryant Last Call was requested
2011-05-16
11 Stewart Bryant State changed to Last Call Requested from Publication Requested::AD Followup.
2011-05-16
11 Stewart Bryant Last Call text changed
2011-05-16
11 (System) Ballot writeup text was added
2011-05-16
11 (System) Last call text was added
2011-05-16
11 (System) Ballot approval text was added
2011-05-13
11 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-05-13
09 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt
2011-03-04
11 Stewart Bryant State changed to Publication Requested::Revised ID Needed from Publication Requested.
Significant number of review comments sent to authors
2011-02-07
11 Adrian Farrel Responsible AD has been changed to Stewart Bryant from Adrian Farrel
2011-02-02
11 Cindy Morgan
> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in …
> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Ross Callon is the Document Shepherd. He has reviewed the document
and believes it is ready to be forwarded to the IESG for publication.

Note: It is suggested, though not strictly necessary, the the IESG
should have the IETF last call for this draft and
draft-ietf-mpls-p2mp-lsp-ping in parallel.

We know of implementations both drafts.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

Yes the has had good review from key people. The document shepherd has
no concerns about the quality of the review.


> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

No such concerns. However in the working group review(s) this document
has been reviewed together with draft-ietf-mpls-p2mp-lsp-ping, even though
the documents are not that strictly coupled it would make sense to
progress them in parallel in IETF last call and IESG processing.



> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

Supported by the working group.


> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the Internet-Drafts Checklist
> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

The nits tool does not report any nits.


> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

References are correctly split.


> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?

There is a correctly documented IANA section in the draft, setting
up a new registry and requesting three sub-TLVs from this registry.

IANA has also made early code point allocations for this document,
everything captured in the IANA section.


> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:


Technical Summary

This documents describes methods for performing lsp-ping traceroute
over mpls tunnels. The techniques specified in [RFC4379] outline a
traceroute mechanism that includes FEC validation and ECMP path
discovery. Those mechanisms are insufficient and do not provide
details in case the FEC being traced traverses one or more mpls
tunnels and in case where LSP stitching is in use. This document
defines enhancements to the downstream-mapping TLV [RFC4379] to make
it more extensible and to enable retrieval of detailed information.
Using the enhanced TLV format along with the existing definitions of
[RFC4379], this document describes procedures by which a traceroute
request can correctly traverse mpls tunnels with proper FEC and label
validations.


Working Group Summary

The document has been reviewed by the MPLS working and has been
progressed in parallel with draft-ietf-mpls-ldp-p2mp through the
working group last call process.

Document Quality

The document is well reviewed by the MPLS working groups.
2011-02-02
11 Cindy Morgan Draft added in state Publication Requested
2011-02-02
11 Cindy Morgan [Note]: 'Ross Callon (rcallon@juniper.net) is the document shepherd.' added
2011-01-30
08 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-08.txt
2010-10-13
07 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-07.txt
2010-08-11
06 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-06.txt
2010-05-27
05 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-05.txt
2010-04-26
11 (System) Document has expired
2009-10-24
04 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-04.txt
2009-07-13
03 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-03.txt
2009-02-09
(System) Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-mpls-lsp-ping-enhanced-dsmap-01
2009-02-02
02 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-02.txt
2008-09-22
01 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-01.txt
2008-06-27
00 (System) New version available: draft-ietf-mpls-lsp-ping-enhanced-dsmap-00.txt