Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-18

[Ballot comment]
Please consider the comments from the Gen-ART Review by
  Alexey Melnikov on 31-May-2011.  The document has been updated since
  the review was posted, but it looks like these comments were not
  addressed.  None of the comments are showstoppers.  The review can
  be found here:

  http://www.ietf.org/mail-archive/web/gen-art/current/msg06355.html

[Ballot comment]
(1) 4.2.1.3 gives "guidelines" as to what to do and has a list of
Return Codes nodes that "MAY" be used but with no MUSTs. I found that a
bit puzzling so maybe saying why these are guidelines and whether
guideline == SHOULD would be good.

(2) 4.3.3 says that when you get no answer, you SHOULD retry with a
larger TTL. It doesn't say how long to wait though, nor when the SHOULD
doesn't apply. Maybe that SHOULD would be better as a "could" and
explicitly say that you're just leaving it all to the implementer?

(3) This is probably a dumb question but it wasn't clear to me how the
replies get back to the node sending the ping. 4.1.2 says that the P2MP
LSPs are unidirectional and that replies "are often sent back through
the control plane" but that, by itself, doesn't make it clear to me. I
assume that this would be clear to implementers but just wanted to
check.

[Ballot comment]
in 3.4, s/on the packet/in the packet/
in 4.2, s/is RECOMMENDED to/SHOULD/
in 4.2.1.1, there is a reference to . your terminology section mentions , butmade no sense to me at 1.2, and by the time I reached 4.2.1.1, I had forgotten it was mentioned in 1.2. I think this would be more effective if you provide the reference at first usage.

[Ballot discuss]
I found this document well-written and easy to read. I support the standardization of ping and traceroute for this environment.
However, the standard defined in this document needs additional work, especially the RFC2119 keyword usage, TBD usage, and the control of exceptional conditions. Hopefully, the authors can point out how these are already addressed somehow, that I simply overlooked. If not, I think these should be fixed before this standard is approved.

in 3.2, why SHOULD ignore rather than MUST ignore? Does this present any security vulnerabilities, such as covert channels?

in 3.2.1, why SHOULD NOT send or receive

in 3.2.1, "MUST respond only if" - the only here is ambiguous; if this is a node on the path, it MUST respond; it is not stated that a node not on  the path MUST NOT respond. Note that the use of "MUST respond only if" is used in multiple places, ad is ambiguous; this can be interpreted as "the MUST only applies if", and when the condition is false, there is no standardzied behavior.

throughout section 3, the requirements language needs to be tighter, or the valid exceptions to the SHOULDs need to be documented. for example "The address in this Sub-TLV SHOULD be of any transit, branch, bud or egress node for that P2MP LSP." Why not MUST? What should a receiver do with such an address? What are the security and operational impact of using an address that is not one of these? (for example, if the receiver can ignore this value, could this field be used to create a covert channel?)

in 3.3, why should wait, and should ignore, rather than must?

in 3.4, why should and not must? why should not rather than must not? why should ignore and not must?

in 3.5, this document, which updates 4379, relies on a work-in-progress to deprecate a TLV in 4379. So will both these documents update 4379? or will DDTM update this document? or will this document update DDTM?

If there are multiple documents doing updating, then changes to fields, such as the global flags field should probably have a registry to coordinate the flag field (re-)definition from multiple documents.

in 4.1, "If the Echo Jitter TLV is present in an echo request for any other type of LSPs, the responding egress MAY apply the jitter behavior as described here." what effect might this have on other types of LSPs, which are not necessarily expecting jitter tlvs? Is processing the new jitter TLV in a non-p2mp tlv consistent with 4379 processing?

in 4.2.1, why should and not must? what happens if a transit node DOES generate an echo reply?

in 4.2.1, "As mentioned previously, the Return Code might change based on the presence of Responder Identifier TLV or Downstream Detailed Mapping TLV." is this behavior deterministic? Can an operator depend on certain return codes being reported when DDMT or Responder ID TLVs are present?

TBD apppears to have multiple values; these should probably be differentiated so IANA and the RFC Editor know how to substitute them easily, such as TBD1, TBD2, etc. This will help avoid mistakes.
this seems to be especially needed in 4.2.1.1, wherte the TBD is apparently meant ot be assigned for the DDMT document.

transit and branch and bud should have references on first usage, or a terminology section should identify their meanings. I got through to 4.2.1.1 without knowing the distinction, but here knowing the distinction is important. I could not locate a description of transit and branch in this document ro in rfc4379, and nothing pointed me to the document that defines the distinction.

in 4.2.1.2, "Egress nodes do not put in any Downstream Detailed Mapping TLV in the echo reply." should this be MUST NOT?

in 4.2.1.3, there is a case structure to determine behavior. But the descriptions are not described in normative terminolgy. Please specify the appropriate responses using RFC2119 keywords, and clarify "the Return Code MAY be set to value X ('Label switched at stack-depth ') or any other error value as needed."

in 4.3.1, "Therefore it is RECOMMENDED that traceroute operations provide for a configurable upper limit on TTL values. Hence the user can choose the depth to which the tree will be probed." In the absence of such a configurable limit, this could be detrimental to the network operation, possibly to the point of denial of service. I think this should be a MUST. (As an SNMP guy, I remember when SNMP autodiscovery  in some products tried to discover the whole Internet because there was no configurable limit. Not a good thing.)

in 4.3.2, the same issue - this should be REQUIRED, not RECOMMENDED.

What are the security and operational impact in the PHP scenario?

in 4.3.3, if a node fails to respond, the ingress should send another with a greater TTL. What happens if the next node fails, and the next node? and the next node? what if the first failed node provides the connectivity to the subsequent nodes, such that the ? the nodes prior to the failure will be peppered with requests, none of which are succeeding. At what point should the ingress stop this behavior? how will it know when it has reached that point?

in 4.3.4, it discusses the processing if an egress address responder identifier sub-TLV is present, which has a limited effect on the response. However, it does not discuss the processing when that sub-TLV is not present, and I have concerns about the processing load that such processing might impose. Can you describe the behavior when the egrees ID is not present?

in 4.3.5, the reply SHOULD carry a limited response. Why is this not a MUST, and what is the security/operational impact of a SHOULD-compliant implementation choosing to do otherwise?

The sentence "Due to this restriction, the cross-over node will not duplicate" wil not is not really accurate since this is not a MUST. (and of course, with non-compliant implementations)

in 5, a non-compliant router does not respond. Does this cause the type of failure included in 4.3.3?

in 1.2, "The terminology for MPLS OAM can be found in [RFC4379]." However, RFC 4379 never mentions the term OAM. You should probably reference the MPLS OAM framework draft-ietf-mpls-tp-oam-framework-11 and/or RFC4378.

in 6, there are strong reasons presented that justify moving many of the SHOULDs in this document to MUSTs.

in 6, "Such an interface SHOULD also provide the ability to disable all active LSP Ping operations to provide a quick escape if the network becomes congested." There is no discussion of how this can be accomplished. Obviously, the ingress node can stop sending new requests, but how can the processing of already sent requests be disabled throughout the network? Maybe there should be a "kill" command that could be sent to disable continued processing of previously sent requests that require time-consuming processing. (or maybe such a kill command would just add to the congestion)

In 7, the early allocation process has already assigned values; why do we still have TBDs in the text?

In 8, "This document does not introduce security concerns over and above those described in [RFC4379]." I strongly disagree. The scalability issues can create a vulnerability to denial of service attacks, and the control of exceptional conditions could be improved.

[Ballot comment]
Two nits:

1) Maybe indent the bit that's copied from 4379:

The motivations listed in [RFC4379] are reproduced here for
completeness:

  When an LSP fails to deliver user traffic, the failure cannot always
  be detected by the MPLS control plane.  There is a need to provide a
  tool that enables users to detect such traffic "black holes" or
  misrouting within a reasonable period of time.  A mechanism to
  isolate faults is also required.

2) To line up with RFC 4875 r/Must/MUST in the packet figures in sections 3.1.1.1 and 3.1.1.2 (x4).

[Ballot comment]
Very clear and readable document.  Thank you.

I have a few minor editorial comments.

If I understand the formats of the P2MP Sub-TLVs in sections 3.1.1.1
and 3.1.1.2 correctly, the P2MP ID in both sub-TLVs are 32 bits long.
It is potentially confusing to show them as different sizes in the two
diagrams in those sections.

I was surprised not to find diagrams for the formats of the Egress
Address and Node Address Responder Identifier sub-TLVs in section 3.
If the authors think the format will be obvious to an implementor
based on the description of the sub-TLVs - they each carry a single
IPv4 or IPv6 address - there's no need for the diagrams.

I'm not sure how I would interpret this text from section 4.2.1.2
(similar text is used elsewhere in the document):

  MAY be set to value 3 ('Replying
  router is an egress for the FEC at stack-depth ') or any other
  error value as needed

Should this be interpreted as "the Return Code MUST be set to either
the value 3 or an error value" or "the Return Code MAY be set; if it
is set, is MUST be set to the value 3 or an error value".

[Ballot comment]
Very clear and readable document.  Thank you.

I have a few minor editorial comments.

If I understand the formats of the P2MP Sub-TLVs in sections 3.1.1.1
and 3.1.1.2 correctly, the P2MP ID in both sub-TLVs are 32 bits long.
It is potentially confusing to show them as different sizes in the two
diagrams in those sections.

I was surprised not to find diagrams for the formats of the Egress
Address and Node Address Responder Identifier sub-TLVs in section 3.
IF the authors think the format will be obvious to an implementor
based on the description of the sub-TLVs - they each carry a single
IPv4 or IPv6 address - there's no need for the diagrams.

I'm not sure how I would interpret this text from section 4.2.1.2
(similar text is used elsewhere in the document):

  MAY be set to value 3 ('Replying
  router is an egress for the FEC at stack-depth ') or any other
  error value as needed

Should this be interpreted as "the Return Code MUST be set to either
the value 3 or an error value" or "the Return Code MAY be set; if it
is set, is MUST be set to the value 3 or an error value".

IANA understands that, upon approval of this document, there are two
IANA Actions which much be completed. In each case IANA will make
registrations which were obtained via the early registration process
permanent.

First, in the "TLVs and sub-TLVs" sub-registry of the "Multiprotocol
Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry located at:

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

four new Sub-TLVs will be created for TLV 1 as follows:

RSVP P2MP IPv4 Session
RSVP P2MP IPv6 Session
Multicast P2MP LDP FEC Stack
Multicast MP2MP LDP FEC Stack

These have already been assigned under early registration procedures.
The values will have their reverence updated to [ RFC-to-be ] and the
TEMPORARY registration indicators removed.

Second, in the same registry as in Task 1 above, the following early
registrations, made for the Internet-Draft will be made permanent -
having their references updated and the TEMPORARY registration
indicators removed:

P2MP Responder Identifier TLV (value 11)
Four sub-TLVs were also defined via early registration.
- Type 1: IPv4 Egress Address P2MP Responder Identifier
- Type 2: IPv6 Egress Address P2MP Responder Identifier
- Type 3: IPv4 Node Address P2MP Responder Identifier
- Type 4: IPv6 Node Address P2MP Responder Identifier

and

Echo Jitter TLV (value 12)

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

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:  (Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
  Label Switching (MPLS) - Extensions to LSP Ping'
  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 updates RFC 4379.

Recent proposals have extended the scope of Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs) to encompass
point-to-multipoint (P2MP) LSPs.

The requirement for a simple and efficient mechanism that can be used
to detect data plane failures in point-to-point (P2P) MPLS LSPs has
been recognized and has led to the development of techniques for
fault detection and isolation commonly referred to as "LSP Ping".
The scope of this document is fault detection and isolation for P2MP
MPLS LSPs.  This documents does not replace any of the mechanisms of
LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the
document authors.  All rights reserved.



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

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


No IPR declarations have been submitted directly on this I-D.

> (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 beforwarded to the IESG for publication.

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

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?

The document has been reviewed in the MPLS working group. No concerns.

The shepherd is convinced that this is ample review for this document.


> (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. There is no IPR claim for this draft.



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

Due to the interdependency between the two drafts, the progress
has been a bit slow. However the support in the working group is good.



> (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 well written IANA considerations section the document, requesting
four new sub-tlvs under top TLV type 1, two new TLVs; one with four
sub-TLVs.


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

Mechanisms to detect data plane failures in point-to-point (P2P)
LSP are described in RFC 4379 - these mechanisms are known as
"LSP Ping".

The working group has also documented requirements for P2MP
LSP Ping.

This document extends the techniques described in RFC 4379 such that
they may be applied to P2MP LSPs. This document stresses the
reuse of existing LSP Ping mechanisms used for P2P LSPs, and applies
them to P2MP MPLS LSPs in order to simplify implementation and
network operation.


Working Group Summary

LSP Ping is one of the key OAM tools developed by the MPLS working,
the draft has well reviewed and is strongly supported by the
working group.

Document Quality

The document is well reviewed in all the groups mentioned above.