MPLS On-Demand Connectivity Verification and Route Tracing
draft-ietf-mpls-tp-on-demand-cv-07

[Ballot comment]
1. in section 1.1:

  o  LSP-Ping: refers to the mechanism - particularly as defined and
      used in referenced material;

What referenced material? need to be specific or provide at least an example

2. In section 4.2.3:

All responses MUST always be sent on a LSP path  ...

The word 'always' can be dropped if MUST is used in the sentence.

3. (issue raised in the OPS-DIR review by Bert Wijnen, was not answered by the authors)

    3.6.  Management Considerations for Operation with Static MPLS-TP

    Support for static MPLS-TP LSP, or Pseudowire, usage and on-demand
    CV, MAY require manageable objects to allow, for instance,
    configuring operating parameters such as:

    o  duration and periodicity of on-demand connectivity tests;
    o  identifiers associated with a statically configured LSP or PW.

    The specifics of this manageability requirement are out-of-scope in
    this document and SHOULD be addressed in appropriate management
    specifications.


Even if the manageability aspects are out-of-scope there is a need to provide some guidance as to what " duration and periodicity " values make sense with some explanation as to why those values would make sense.

[Ballot discuss]
(issue raised in the OPS-DIR review by Bert Wijnen, was not answered by the authors)

    3.6.  Management Considerations for Operation with Static MPLS-TP

    Support for static MPLS-TP LSP, or Pseudowire, usage and on-demand
    CV, MAY require manageable objects to allow, for instance,
    configuring operating parameters such as:

    o  duration and periodicity of on-demand connectivity tests;
    o  identifiers associated with a statically configured LSP or PW.

    The specifics of this manageability requirement are out-of-scope in
    this document and SHOULD be addressed in appropriate management
    specifications.


Even if the manageability aspects are out-of-scope there is a need to provide some guidance as to what " duration and periodicity " values make sense with some explanation as to why those values would make sense.

[Ballot discuss]
A number of comments were recently made on the MPLS WG mailing list and during IETF last call.
I would like to see these comments discussed and resolved before the document is approved.

IANA has questions about the first, third, and fifth actions described
below:

ACTION 1:

IANA will register the following in the "TLVs and sub-TLVs" registry at
http://www.iana.org/assignments/mpls-lsp-ping-parameters

Type Sub-Type Value Field Reference
---- -------- ----------- ---------
TBD Source ID TLV [RFC-to-be]
TBD Destination ID TLV [RFC-to-be]

QUESTION: Is this the right registry? The table in the document includes
a "length" field that this registry doesn't have.


ACTION 2:

IANA will make the following temporary registrations permanent in the
"TLVs and sub-TLVs" registry at
http://www.iana.org/assignments/mpls-lsp-ping-parameters

Type Sub-Type Value Field Reference
---- -------- ----------- ---------
1 22 Static LSP [RFC-to-be]
1 23 Static Pseudowire [RFC-to-be]


ACTION 3:

We understand that IANA needs to register the following in the "TLVs and
sub-TLVs" registry at
http://www.iana.org/assignments/mpls-lsp-ping-parameters

Type Sub-Type Value Field Reference
---- -------- ----------- ---------
TBD Reverse-path Target FEC Stack TLV [RFC-to-be]

QUESTION: We understand that this TLV should have the same sub-types as
the Target FEC Stack TLV, and that this includes future sub-type
registrations as well. To make sure that no errors are introduced into
the registry in the future, would it be acceptable if, instead of
listing all the subtypes under the Reverse-path Target FEC Stack TLV
registration, we added a line that said, "This TLV has the same sub-TLVs
as the Target FEC Stack TLV"? The alternative is list all the sub-types
and add a note to the top of the registry noting the requirement.


ACTION 4:

IANA will register the following Pseudowire Associated Channel Type at
http://www.iana.org/assignments/pwe3-parameters

Value Description TLV Follows Reference
------ ------------- ----------- ----------------------
TBD On-Demand CV No [RFC-to-be]


ACTION 5:

IANA will create the following registry:

Registry Name: Downstream Mapping Address Type Registry
Reference: [RFC4379][RFC-to-be]
Registration Procedure: Standards Action

Type # Address Type K Octets Reference
------ ------------ -------- --------------------------
1 IPv4 Numbered 16 [RFC4379]
2 IPv4 Unnumbered 16 [RFC4379]
3 IPv6 Numbered 40 [RFC4379]
4 IPv6 Unnumbered 28 [RFC4379]
5 Non IP 12 [RFC-to-be]

QUESTIONS:
- Should value 0 be "unassigned" or "reserved"?
- Is 255 the maximum value?
- Does this registry belong on an existing page?

[Ballot comment]
The Abstract ends with "... new address type and requesting an IANA
  registry."  The IANA registration will take place before the document
  is published as an RFC.  At this stage, the Abstract needs to be
  written as the final RFC, not the Internet-Draft.

  The bottom of page 6 says:
  >
  > Address Type will be 5 (as shown in Section 2.1 above.
  >
  There is a missing ')'.

[Ballot comment]
The sentence "When set to zero, the field is not applicable" occurs a couple of times in the draft.  Is "not applicable" have the same meaning as "these bits are ignored"?  If so, I think it'd be clearer to say "these bits are ignored."

[Ballot comment]
The sentence "When set to zero, the field is not applicable" occurs a couple of times in the draft.  Is "not applicable" have the same meaning as "these bits are ignored"?  If so, I think it'd be clearer to say that.

[Ballot comment]
Please specify the byte order of the longer binary fields. Although network byte order (the most significant byte first) is almost universally used, there are some exceptions, so it is important to spell this out.

[Ballot comment]
1. in section 1.1:

  o  LSP-Ping: refers to the mechanism - particularly as defined and
      used in referenced material;

What referenced material? need to be specific or provide at least an example

2. In section 4.2.3:

All responses MUST always be sent on a LSP path  ...

The word 'always' can be dropped if MUST is used in the sentence.

[Ballot discuss]
1. Section 2.1:

  Multipath type SHOULD be set to 0 (no multipath) when using this
  address type.


Why is this not a MUST? In what situations the multipath type could be set to something different than 0?

Same question for 2.1.1 - although may be a particular case of the statement in 2.1

2. (issue raised in the OPS-DIR review by Bert Wijnen, was not answered by the authors)

    3.6.  Management Considerations for Operation with Static MPLS-TP

    Support for static MPLS-TP LSP, or Pseudowire, usage and on-demand
    CV, MAY require manageable objects to allow, for instance,
    configuring operating parameters such as:

    o  duration and periodicity of on-demand connectivity tests;
    o  identifiers associated with a statically configured LSP or PW.

    The specifics of this manageability requirement are out-of-scope in
    this document and SHOULD be addressed in appropriate management
    specifications.


Even if the manageability aspects are out-of-scope there is a need to provide some guidance as to what " duration and periodicity " values make sense with some explanation as to why those values would make sense.

[Ballot discuss]
1) in 2.2.2, "An On-demand CV packet MUST NOT include more than 1 Source Identifier TLV." - this statement of the requirement does not seem to be conditional.
"If more than 1 such TLV is present in an On-demand CV request packet, then an error of 1 (Malformed echo request received, Section 3.3 [RFC4379]) MUST be returned, if it is possible to unambiguously identify the source of the packet." This text is ambiguous. It is unclear what the requirement when it is NOT possible to unambiguously identify the source of the packet.
I assume the purpose of this text is to say "if it is clear who originated the message, then send this error message", but "if it  is unclear who originated  the request, implementations MUST NOT return an error." I don't think the text succeeds at saying that.
The text says an error message MUST be returned, and then details an exception; that makes it a SHOULD, not a MUST.
In additioin, by putting the conditional about identifying the source in the setence that starts with if more than 1 source TLV is in the message, you confuse the requirements mandating only 1 src tlv per request. It is unclear which part of the complex sentence the "if" applies to.

2) in 2.3.2, "The Source Global ID and Destination Global ID MAY be set to 0. When set to zero, either field is not applicable." is ambiguous. If Source Global ID is set to zero, does this mean the Destination Global ID is not applicable? and vice-versa?

3) in 3.2, "The response in this case SHOULD use ACH and SHOULD be IP encapsulated. " why only SHOULD? what are the expected exceptions to this SHOULD?

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:  (MPLS On-demand Connectivity Verification and Route Tracing) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS On-demand Connectivity Verification and Route Tracing'
  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-08-25. 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

  Label Switched Path Ping (LSP-Ping) is an existing and widely
  deployed Operations, Administration and Maintenance (OAM) mechanism
  for Multi-Protocol Label Switching (MPLS) Label Switched Paths
  (LSPs).  This document describes extensions to LSP-Ping so that LSP-
  Ping can be used for On-demand Connectivity Verification of MPLS
  Transport Profile (MPLS-TP) LSPs and Pseudowires.  This document also
  clarifies procedures to be used for processing the related OAM
  packets.  Further, it describes procedures for using LSP-Ping to
  perform Connectivity Verification and Route Tracing functions in
  MPLS-TP networks.  Finally this document updates RFC 4379 by adding a
  new address type and requesting an IANA registry.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/


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

[Ballot discuss]
This is an administrative Discuss.
The IETF Last Call ends on the same day as the telechat for this document.
This Discuss is to hold the document in case there are any IETF Last Call comments to be addressed.
I intend to move to a "Yes" ballot.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Review

Hi,

I have performed my AD review of your draft prior to IETF last call and
IESG review. The purpose is to find any issues that might be raised at
those stages and to try to achieve a smoother progress through the
system.

My review has thrown up a number of minor editorial issues and a couple
of concerns with the IANA section. Otherwise the I-D is in pretty good
shape - thanks.

Can you please have a look at the issues below and spin a new revision.
All issues are, of course, open for debate.

I have put the I-D into Revised ID Needed state, and as soon as I see
a revision, I will start the IETF last call.

Thanks,
Adrian

---

Please expand LSP in the Abstract
Ditto in Section 1

---

Section 1.1

Immediately after your careful text explaining terms you use
"traceroute" without explanation!

---

Please expand LSR in Section 1.2

---

Please expand ACH in Section 1.3

---

Section 2.2.3

  When sending On-demand CV packets using ACH, without IP
  encapsulation, there MAY be a need to identify the destination of the
  packet.

I think s/MAY/may/

You mean "may" as in "might" not as in "an implementation is permitted"

---

Section 2.3

  In order to identify a statically provisioned LSP and PW, new target
  FEC stack sub-TLVs are being defined.  The new sub-TLVs are assigned
  sub-type identifiers as follows, and are described in the following
  sections.

The present continuous tense is unhelpful.
Do you mean "are defined in this document"?

---

Section 2.3.1 and 2.3.2

s/global/Global/

---

Section 3.4.1

The MBZ field is not defined or explained.
0 on TX, ignore on RX?

---

Section 7.1, 7.2, 7.3

In all three subsections you have misnamed the registry.

Should read...
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
Parameters"

---

Section 7.2                                                                   

  IANA is requested to assign sub-type values to the following sub-TLVs

Should read

  IANA has made early assignment of sub-type values to the following
  sub-TLVs. IANA is requested to make the assignments permanent.

---

Section 7.5                                         

It would help IANA if you named the new sub-registry and told them which
is the parent registry.

  Because the field in this case is an 8-octet field, the basis for all
  future allocations SHOULD be "Standards Based."

I think this is an 8 bit field! But also, I think that the reasoning is
not important to IANA. You just have to tell them what to do.
Please don't use RFC 2119 language in the IANA section.
"Standards Based" does not a recognised allocation policy.

So...

NEW
  The allocation policy for this registry is "Standards Action"
  [RFC5226].
END

---
                     
Heads-up on manageability.

We are currently attracting a bit of interest from the Ops ADs on our
drafts wrt how to make them manageable. There is not a requirement to
specify MIB or YANG modules, but there is pressure to draw out the
"objects" that should be configurable, and those that should be
inspectable in a "Normal" implementation. I don't think this is a lot
of work (and you have done it a bit in some places such as Section 3.6.

Can you look to see whether you can draw something together for a small
new section called "Guidance on Manageability"

The MPLS WG requests that:

      MPLS On-demand Connectivity Verification and Route Tracing
                  draft-ietf-mpls-tp-on-demand-cv-05

is published as an RFC on the standards track.


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

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


> (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 and by SG15
of the ITU-T.

The shephered 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?

There is a good consensus around this draft, it has passed the call to verify
that LC comments were correctly addressed with only minor comments.


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

Yes - there is one case where there is a later document than the one
referenced, but both documents are still moving so it is very hard to
coordinate that (and not really neccessary).


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

All documents that are referenced are past working group last
call (RFCs, approved by te IESG or publication requested). In
one case we are writing the request for publication in parallel
with this one.


> (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 well-written IANA section in this document.


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

  LSP-Ping is a protocol that has been used for MPLS LSPs almost
  since the MPLS networks were first deployed, it is the most  widely
  deployed OAM mechanism for MPLS LSPs. 
  This document describes extensions to LSP-Ping so that LSP-
  Ping can be used for On-demand Connectivity Verification of MPLS-TP
  LSPs.  This document also clarifies procedures to be used for
  processing the related OAM packets.  Further, it describes procedures
  for using LSP-Ping to perform Connectivity Verification and Route
  Tracing functions in MPLS-TP networks.  Finally this document updates
  RFC 4379 by adding a new address type and requesting a registry.

Working Group Summary

  This document is a MPLS working group document, and part of the joint
  IETF and ITU.T MPLS-TP project. It has been reviewed in both organizations
  and there is a solid support for the document.

Document Quality

  The document is well reviewed in the MPLS working group and ITU-T.