Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels
draft-ietf-mpls-lsp-ping-enhanced-dsmap-11

[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.)

[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.

[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.

[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.

[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.

[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"

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.

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/

> (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.