Return Path Specified Label Switched Path (LSP) Ping
draft-ietf-mpls-return-path-specified-lsp-ping-15

[Ballot comment]

Thanks for adding the security consideration text
that resolved my discuss. I think you could do with
a bit more editing of that text, but I'm sure that'll
be fixed in AUTH-48. Feel free to ping me if you
want though.

I didn't check the comments below vs. the latest
version. Again, let me know if there's something
more to say or do.

Thanks,
S.

-------

- 3.2: "A flag" - I didn't find the description here easy to
follow. Setting this means "don't use the path you'd use if
reply mode 2 or 3 was sent" but how does the egress LSR know
what non-default path to pick?

- 3.2: "B flag" - I don't get how the return path is known.
Maybe the same problem (of my understanding) as the for the A
flag:-)

- 3.2: The reply paths sub-TLV seems underspecified.  Maybe a
ref to a bit of 4379 is needed?

- 3.3: How can a sub-tlv with no typing carry any "future
defined" type? (That is I support Stewart's discuss.)

- 3.3: I can't parse this "One usage of these generic RSVP
Tunnel sub-TLVs is when LSP Ping is used to periodically
verify the control plane against the data plane [RFC5884],
using Tunnel other than particular LSP can avoid the impact
of LSP identifier changing when Make-Before-Break (MBB) is
deployed."

- 4: "the echo reply MUST carry the FEC stack information in
a Reply Path TLV" huh? do you mean echo request? and don't
you need to say which of 3.3.x is the one to use? (presumably
3.3.3)

[Ballot comment]
There is no benefit to using an IPv4-mapped IPv6 address to represent loopback addresses and there have been recommendations to not use them whenever possible.  Given that the original specification (RFC 4379) defined the use of IPv4-mapped IPv6 addresses in the multipath information field, it is not the fault of this document for their use.  In general, the use of IPv4-mapped addresses is very limited and the use-case here does not call for their use. The native IPv6 loopback would have been more appropriate.

[Ballot discuss]
I have to raise Joel's point up to a DISCUSS.  There is absolutely no benefit to using an IPv4-mapped IPv6 address to represent loopback addresses.  In general, the use of IPv4-mapped addresses is very limited and the use-case here does not call for their use.  What was the rationale for using ::FFFF:127.0.0.0/104 instead of the defined IPv6 loopback or unspecified address?

[Ballot discuss]

(1) 5: How can I check the MUST here? Can the source have an
IP address but the reply path doesn't use IP? If so, how can
the egress LSR make this check?  Or am I reading something
wrong?

(2) 5: Doesn't this raise some new potential DoS attacks?
4379 has a good discussion of security but doesn't cover all
that can be done here I think, especially if my discuss point
1 is real.  (If my discuss point 1 is just me misreading
stuff, then I think this goes away too.)

[Ballot comment]

- 3.2: "A flag" - I didn't find the description here easy to
follow. Setting this means "don't use the path you'd use if
reply mode 2 or 3 was sent" but how does the egress LSR know
what non-default path to pick?

- 3.2: "B flag" - I don't get how the return path is known.
Maybe the same problem (of my understanding) as the for the A
flag:-)

- 3.2: The reply paths sub-TLV seems underspecified.  Maybe a
ref to a bit of 4379 is needed?

- 3.3: How can a sub-tlv with no typing carry any "future
defined" type? (That is I support Stewart's discuss.)

- 3.3: I can't parse this "One usage of these generic RSVP
Tunnel sub-TLVs is when LSP Ping is used to periodically
verify the control plane against the data plane [RFC5884],
using Tunnel other than particular LSP can avoid the impact
of LSP identifier changing when Make-Before-Break (MBB) is
deployed."

- 4: "the echo reply MUST carry the FEC stack information in
a Reply Path TLV" huh? do you mean echo request? and don't
you need to say which of 3.3.x is the one to use? (presumably
3.3.3)

[Ballot discuss]
I find the definition of the data structure very confusing. In Figure 1 you have "Reply Paths", but there is no definition of Reply Paths. I assume that you mean Tunnel sub-TLVs (section 3.3). If so you need to align the notations. Also "Reply Paths" implies multiple concurrent paths, but I don't think that is what you mean.

This needs to be clarified and made consistent.

[Ballot comment]
My guess is that it is now water under the bridge due to the allocation of currently assigned return codes, but it seems to me that 64K return codes (with 10 allocated) is rather a lot, whereas 16 flags is always too few. I am surprised that a more conservative allocation plan was not used.

"The Reply Path TLV can carry any (existing and future defined)". My experience is that to be in a position to carry any future defined data structure is quite an ambitions undertaking :)

Can I assume that the response message is so small that I do not need to think about MTU?

[Ballot comment]
the use of ipv4 mapped address in lieu of the whole 0000::/8

0:0:0:0:0:FFFF:127.0.0.0/104 in section 4 kind of gives me heart burn.

in general ipv4 transition-isms shouldn't make their appearance or be imparted special meaning when that's unnecessary. and it appears to be uneccessary in this case.

e.g.

  The destination IP address of the echo reply message MUST
  never be used in a forwarding decision.  To avoid this possibility
  the destination IP address of the echo reply message that is
  transmitted along the specified return path MUST be set to numbers
  from the range 127/8 for IPv4 or 0:0:0:0:0:FFFF:127.0.0.0/104 for
  IPv6, and the IP TTL MUST be set 1, and the TTL in the outermost
  label MUST be set to 255.

e.g. ::2/128 has the same result.

[Ballot discuss]
Holding a Discuss for IANA's question

2. Regarding the new requested sub-registry "Reply Path Return Code";

QUESTION: Is it a typo for the range in the text below:

  The range of 0x0008-0xfffb is not allocated and reserved for future
  extensions and is allocated via Standard Action, the range of 0xfffc-
  0xffff is for Experimental Use.

? 

Should it be 0x0006-0xfffb as described in the preceding
table in section 6.4?

acker.
IANA Actions - YES

NOTE: This revised review is based on version 13 of the drafted
document.  IANA has the following comments/questions:

1. The current version showed that section 6.2 has been revised.
Authors are no longer requiring the new assignment from the sub-TLV
for TLV Type 21 sub-registry.  Below is the revised action:

REVISED Action:

- In the sub-TLV for TLV Type 1 and 16 subregistry in the Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs registry located at

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

three new sub-TLVs are to be assigned as follows:

Sub-Type: [TBD-at-registration ]
Sub-TLV Name: Static Tunnel
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [TBD-at-registration ]
Sub-TLV Name: IPv4 RSVP Tunnel
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [TBD-at-registration ]
Sub-TLV Name: IPv6 RSVP Tunnel
Reference: [ RFC-to-be ]
Comment:


2. Regarding the new requested sub-registry "Reply Path Return Code";

QUESTION: Is it a typo for the range in the text below:

  The range of 0x0008-0xfffb is not allocated and reserved for future
  extensions and is allocated via Standard Action, the range of 0xfffc-
  0xffff is for Experimental Use.

? 

Should it be 0x0006-0xfffb as described in the preceding
table in section 6.4?

Thank you,

Pearl Liang
ICANN/IANA

On Tue Sep 17 10:04:28 2013, iesg-secretary@ietf.org wrote:
> Evaluation for
> can be found at
> http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-
> lsp-ping/
>
> Last call to expire on: 2013-09-04 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Adrian Farrel        [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    mpls mailing list ,
>    mpls chair
> Subject: Protocol Action: 'Return Path Specified LSP Ping' to Proposed
> Standard (draft-ietf-mpls-return-path-specified-lsp-ping-12.txt)
>
> The IESG has approved the following document:
> - 'Return Path Specified LSP Ping'
>  (draft-ietf-mpls-return-path-specified-lsp-ping-12.txt) as Proposed
> Standard
>
> This document is the product of the Multiprotocol Label Switching
> Working
> Group.
>
> The IESG contact persons are Adrian Farrel and Stewart Bryant.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-
> lsp-ping/
>
>
>
>
> Technical Summary
>
>    This document defines extensions to the data-plane failure-
> detection
>    protocol for Multiprotocol Label Switching (MPLS) Label Switched
>    Paths (LSPs) known as "LSP Ping".  These extensions allow selection
>    of the LSP to use for the echo reply return path.  Enforcing a
>    specific return path can be used to verify bidirectional
> connectivity
>    and also increase LSP ping robustness.
>
> Working Group Summary
>
>  There has not been anything in the working group process that
>  needs to be mentioned, other than we had a strong support to
>  accept it as a working group draft, after that the discussion
>  on the mailing were low for almost a year, but has pick up lately
>  and we have had a good discussion, where all comments been
>  focused on improving the and no indication that the draft is not
>  needed.
>
>  The document has support in the working group, and operators has
>  participated in writing it, and has been well reviewed.
>  After improving the IANA section (mostly off-line) the document
>  shepherd now believes we have a stable document ready to be
>  published.
>
>  A further two months' discussion focused on a discussion of the IANA
>  section of this document. We have earlier made "early allocations"
>  of code points for this document, after discussion we have
>  decided not use them, but reuse (identical) sub-TLVs allocated
>  by RFC4379. A spin-off of the IANA discussion for this
>  document is that we are discussing/thiking of writing an update
>  to the IANA allocation of RFC4379.
>
>  The AD review raised still further issues with the IANA section and
>  this delayed the document by many months while the working group
>  grappled with an understanding of how the registries were supposed
>  to work. Agreement has finally been reached leading to the latest
>  revision and a new draft in the working group to clarify the
> registries
>  for future generations.
>
> Document Quality
>
>  This is a very minor update to the LSP-Ping that does not have
>  any affect on the operations of existing LSP Ping implementations
>  and deployments, even if nodes with the new functionality are
>  introduced.
>
>  The working group mailing list has been polled for existing
>  implementations and intentions to implement this specification.
>
>  We know of vendors that intend to implement and at least one
>  operator that plans to deploy this functionality.
>
> Personnel
>
>  Loa Andersson (loa@pi.nu) is the document shepherd.
>  Adrian Farrel (adrian@olddog.co.uk) is the responsible AD.
>
> RFC Editor Note
>
>  (Insert RFC Editor Note here or remove section)
>
> IRTF Note
>
>  (Insert IRTF Note here or remove section)
>
> IESG Note
>
>  (Insert IESG Note here or remove section)
>
> IANA Note
>
>  (Insert IANA Note here or remove section)
>
>

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-return-path-specified-lsp-ping-12.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the new registry requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are six actions which IANA must complete.

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

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

the current registration for value 21: Reply Path TLV will be made permanent and have its Reference changed to [ RFC-to-be ].

Second, also in the TLVs and sub-TLVs registry in the Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs registry located at

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

a new TLV will be assigned as follows:

Value: [ TBD-at-registration ]
Meaning: Reply TC TLV
Reference: [ RFC-to-be ]

Third, in the TLVs and sub-TLVs registry in the Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs registry located at

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

the current pointer to the subTLV subregistry for value 21 will be made permanent and the contents of that subregistry, named Sub-TLVs for TLV Type 21, will be changed from a temporary allocation to a permanent allocation.

Assignments of sub-TLVs for TLV Type 21 in the range of 16384-28671 and 49162-61439 are made by Standards Action. These ranges used for the sub-TLVs that are uniquely defined for TLV Type 21. Assignments in the range of 28672-31743 and 61440-64511 are made via "Specification Required". The range 31744-32767 and 64512-65535 are for vendor private use and MUST NOT be assigned.

The sub-TLV range of TLV Type 21 is partitioned as follows:

0-16383 Directly copied from TLV Type 1, MUST NOT be assigned.
16384-28671 Allocated via Standards Action (Mandatory sub-TLV).
28672-31743 Allocated via Specification Required (Mandatory sub-TLV).
31744-32767 Vendor or Private use, MUST NOT be assigned.
32768-49161 Directly copied from TLV Type 1, MUST NOT be assigned.
49162-61439 Allocated via Standards Action (Optional sub-TLV).
61440-64511 Allocated via Specification Required (Optional sub-TLV).
64512-65535 Vendor or Private use, MUST NOT be assigned.

Fourth, in the sub-TLV for TLV Type 21 subregistry in the Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs registry located at

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

three new sub-TLVs are to be assigned as follows:

Sub-Type: [TBD-at-registration ]
Sub-TLV Name: Static Tunnel
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [TBD-at-registration ]
Sub-TLV Name: IPv4 RSVP Tunnel
Reference: [ RFC-to-be ]
Comment:

Sub-Type: [TBD-at-registration ]
Sub-TLV Name: IPv6 RSVP Tunnel
Reference: [ RFC-to-be ]
Comment:

Fifth, IANA has made an early allocation (value: 5 - Reply via specified path) from the "Reply Mode" sub-registry of the Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry located at:

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

Upon approval of this document, this temporary registration will be made permanent and the reference will be changed to [ RFC-to-be ].

Sixth, a new registry is to be created called the "Reply Path Return Code" registry.

IANA Question --> Where should this registry be created? As part of mpls-lsp-ping-parameters, or in a new page? If the latter, what should be the title of the page?

The range of 0xfffc-0xffff is for Experimental Use. Unassigned values are assigned via Standards Action [RFC5226].

These are the initial registrations in this new registry:

Value Meaning
------ ----------------------
0x0000 No return code
0x0001 Malformed Reply Path TLV was received
0x0002 One or more of the sub-TLVs in Reply Path TLV
was not understood
0x0003 The echo reply was sent successfully using the
specified Reply Path
0x0004 The specified Reply Path was not found, the echo
reply was sent via other LSP
0x0005 The specified Reply Path was not found, the echo
reply was sent via IP path
0x0006-0xfffb Not allocated, allocated via Standard Action
0xfffc-0xffff Experimental Use

Each of the initial registrations in this new registry will be marked as having a Reference of [ RFC-to-be ].

IANA understands that these are the only actions required to be completed 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Return Path Specified LSP Ping) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Return Path Specified LSP Ping'
  as 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 2013-09-04. 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 defines extensions to the failure-detection protocol
  for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
  known as "LSP Ping" that allow selection of the LSP to use for the
  echo reply return path.  Enforcing a specific return path can be used
  to verify bidirectional connectivity and also increase LSP ping
  robustness.  It may also be used by Bidirectional Forwarding
  Detection (BFD) for MPLS bootstrap signaling thereby making BFD for
  MPLS more robust.


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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-ping/ballot/


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

  http://datatracker.ietf.org/ipr/1491/

Further issue with IANA text...

Thanks to the authors for a rapid turn-round on my review.
We are almost there.

But the remaining issue is with the codepoints for the sub-TLVs of the Reply Path TLV. There seems to be some *massive* disconnect!

From the discussion of the 4379-defined "TLVs and sub-TLVs" sub-registry of the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - TLVs" registry in old versions of the I-D, I had assumed that you wanted to allow top-level TLVs from the registry to be used as sub-TLVs of the new Reply Path TLV. The reason I thought this is that the document discusses the allocation ranges for the top-level TLVs and says that new sub-TLVs of the Reply Path TLV that apply only to the Reply Path TLV must be allocated out of "safe" ranges - i.e. those ranges that cannot be allocated for top-level TLVs.

But when I look at the early allocations done in the registry (and presumably agreed by the authors) I see something completely different. What I see there is that the Reply Path TLV can carry as its own sub-TLVs those sub-TLVs that can be carried as sub-TLVs of the Target FEC Stack top-level TLV.

So, I *think* what you are asking for is:
1. A new top-level LSP Ping TLV called "Reply Path TLV"
    Early allocation has assigned this value 21
2. The ability to carry any sub-TLV of the Target FEC Stack
  top-level TLV as a sub-TLV of the Reply Path TLV
3. A way to "lock step" the two sub-TLV registries so that
  new sub-TLVs that can be carried in the Target FEC Stack
  TLV can also be carried in the Reply Path TLV
4. A way to create and register sub-TLVs that are only to
  be used in the Reply Path TLV and are not to be carried in
  the Target FEC Stack TLV

All of this has nothing to do with 4379 allocation polices or ranges applied to the top-level TLV registry.

If this is what we are trying to do, then:
- we can delete the sections of text talking about TLV allocation
  policies
- we can introduce some text instructing IANA to lock-step the
  registries of sub-TLVs
- we can work out a policy that allows values used as sub-TLVs of
  the Target FEC Stack TLV to be reserved so that they do not conflict
  with allocations for sub-TLVs of the Reply Path TLV

So, step 1: please confirm that I have now (finally) understood what it is you're trying to achieve.

Sorry it has taken me so long to understand. Hopefully we can resolve this quickly from here on in.

Regards,
Adrian

AD review...

Hi,

I've done my usual AD review of your draft prior to issuing IETF last
call and passing the I-D for IESG evaluation. The main purpose of the
review is to catch issues that might come up in later reviews and to
ensure that the document is ready for publication as and RFC.

I found Section 4 very good. It completely explains to me what is
going on in the protocol extension, and covered all the corner cases
I could think of. On the other hand, Section 3 made me generate a
really (really, really) long list of relatively minor issues. This
list is so long that I think you need to provide a new revision
before we issue the IETF last call. I will put the I-D into "Revised
I-D Needed" state and wait for the revision.

As always, all my comments are up for discussion and negotiation.

Thanks for the work,
Adrian

===

Consistency of references for bidirectional LSP. In Section 1 you have
  In this document, term bidirectional LSP includes the co-routed
  bidirectional LSP defined in [RFC3945]
In Section 2 you have:
  The co-routed bidirectional LSP is defined in [RFC3471]
  and [RFC3473]

---

Section 1
s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] session/
s/In this document, term bidirectional LSP/In this document, the term bidirectional LSP/

---

Section 3.1

OLD
  The recommended value of the Reply via Specified Path mode is 5 (This
  is to be confirmed by the IANA).

      Value    Meaning
      -----    -------
          5    Reply via Specified Path
NEW
  The value of the Reply via Specified Path mode is 5 (This has been
  allocated by IANA using early allocation and is to be confirmed by
  IANA).

      Value    Meaning
      -----    -------
          5    Reply via Specified Path
END

---

Section 3.2

OLD
  The Reply Path (RP) TLV is an optional TLV, if the Reply via
  Specified Path mode requested, the Reply Path (RP) TLV MUST be
  included in an echo request message.  It carries the specified return
  paths that the echo reply message is required to follow.  The format
  of Reply Path TLV is as follows:

NEW
  The Reply Path (RP) TLV is an optional TLV within the LSP Ping
  protocol.  However, if the Reply via Specified Path mode requested as
  described in Section 3.1, the Reply Path (RP) TLV MUST be included in
  an echo request message and its absence is treated as a malformed
  echo request as described in [RFC4379].  Furthermore, if a Reply Path
  (RP) TLV is included in an echo request message, a Reply Path (RP)
  TLV MUST be included in the corresponding echo reply message sent by
  an implementation that is conformant to this specification.
 
  The Reply Path (RP) TLV carries the specified return path that the
  echo reply message is required to follow.  The format of Reply Path
  TLV is as follows:
END

---

Section 3.2

OLD
  Reply Path TLV Type field is 2 octets in length, and the type value
  is TBD by IANA.
NEW
  Reply Path TLV Type field is 2 octets in length, and the type value
  is 21. (This has been allocated by IANA using early allocation and is
  to be confirmed by IANA).
END

---

Section 3.2

OLD
  Reply Path return code is 2 octets in length.  It is defined for the
  egress LSR of the forward LSP to report the results of Reply Path TLV
  processing and return path selection.  When sending echo request,
  these codes MUST be set to zero.  Reply Path return code only used
  when sending echo reply, and it MUST be ignored when processing echo
  request message.  This document defines the following Reply Path
  return codes:
NEW
  The Reply Path return code field is 2 octets in length.  It is
  defined for the egress LSR of the forward LSP to report the results
  of Reply Path TLV processing and return path selection.  This field
  MUST be set to zero in a Reply Path TLV carried on an echo request
  message and MUST be ignored on receipt.  This document defines the
  following Reply Path return codes for inclusion in a Reply Path TLV
  carried on an echo reply:
END

---

Section 3.2

  Value        Meaning
  ------        ----------------------
  0x0000        No return code

What does "No return code" mean? I thought it might have been the value
that you should return if the TLV has been successfully processed but
you seem to have 0x0003 for this. So, how is 0x0000 used?

---

Section 3.2

  0x0006        The Reply mode in echo request was not set to 5 (Reply
                via Specified Path) although Reply Path TLV exists
  0x0007        Reply Path TLV was missing in echo request

Surely these are malformed echo requests and will be handled with
normal echo replies with return code value 1.

---

Section 3.2

  The A bit and B bit set MUST NOT both be set, otherwise, an echo
  reply with the RP return code set to "Malformed RP TLV was received"
  SHOULD be returned.

What other options are there? I.e. why "SHOULD" not "MUST"?

---

Section 3.2

OLD
  The Reply Paths field is variable in length, not more than one sub-
  TLV MUST be carried, which describes the specified path that the echo
  reply message is required to follow.  When the Reply Mode field is
  set to "Reply via Specified Path" in an LSP echo request message, the
  Reply Path TLV MUST be present.  The Reply Path TLV SHALL only be
  used in the reply mode defined in this document (Reply via Specified
  Path).
NEW
  The Reply Paths field is variable in length and MUST contain zero or
  one sub-TLV.  The sub-TLV, if present, describes the specified path
  that the echo reply message is required to follow.
END

---

Section 3.2
 
  When the Reply Mode field is set to "Reply via Specified Path" in an
  LSP echo request message, the Reply Path TLV MUST be present. 

I think this is a duplication of a previous statement and can be removed

---

Section 3.2
 
  The Reply Path TLV SHALL only be
  used in the reply mode defined in this document (Reply via Specified
  Path).

Why do you need this?  And can it be enforced?
It is very unusual to restrict the use of information in this way. I
understand that you do not have any other use in mind, but is there a
need to make this constraint.

---

Section 3.3

  In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs
  is specified for Vendor Private Use, and MUST NOT be allocated.  This
  document changes that rule to make it not applicable to Reply Path
  TLV and redefines the rule as in Section 6.2 .  If an implementation
  recognizes any specific Vendor Private types as defined in [RFC4379],
  and uses the sub-TLV type specified in this document, care must be
  taken to ensure that the implementation does not confuse the two
  usages.

I don't think this draft changes the registry for 4379, does it?
This needs a little more care to separate the two uses clearly. How
about...

OLD
  Each of the FEC sub-TLVs (include existing and future defined) for
  the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV for
  inclusion in the Reply Path TLV for expressing a specific return
  path.  For these shared sub-TLVs, they share the same registry with
  the Target FEC Stack TLV for the range of 0-31743 and 32768-64511.

  In addition, this document defines three new sub-TLVs: IPv4 RSVP
  Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV.
  These sub-TLVs are only designed for Reply Path TLV, hence this
  document calls them dedicated sub-TLVs to Reply Path TLV.  For these
  dedicated sub-TLVs, this document will create a new registry (Section
  6.1), the sub-TLV type MUST be allocated from the new registry.
  Detailed definition is in the following sections.

  In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs
  is specified for Vendor Private Use, and MUST NOT be allocated.  This
  document changes that rule to make it not applicable to Reply Path
  TLV and redefines the rule as in Section 6.2 .  If an implementation
  recognizes any specific Vendor Private types as defined in [RFC4379],
  and uses the sub-TLV type specified in this document, care must be
  taken to ensure that the implementation does not confuse the two
  usages.
NEW
  The FECs defined in [RFC4379] provide a good way to identify a
  specific return path.  The FEC sub-TLVs (including existing and
  future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have sub-TLV
  types assigned from a registry with ranges as follows:

      0-16383      Standards Action mandatory TLV
      16384-31743  Specification Required, Experimental RFC needed
      31744-32767  Vendor Private Use, MUST NOT be allocated
      32768-49161  Standards Action optional TLV
      49162-64511  Specification Required, Experimental RFC needed
      64512-65535  Vendor Private Use, MUST NOT be allocated

  The Reply Path TLV can carry and sub-TLV defined for use in the
  Target FEC Stack TLV that can be registered.  Thus the ranges
  0-31743 and 32768-64511 are shared by the registries, with the new
  Reply Path Sub-TLVs registry "borrowing" values from the Target FEC
  Stack TLV registry.

  Allocations from the ranges 31744-32767 and 64512-65535 are not
  recorded in the registry for Target FEC Stack TLVs, so these ranges
  are safely made available in the Reply Path Sub-TLVs registry (see
  Section 6.1) to record sub-TLVs that are specific to the Reply Path
  TLV.  This document defines three sub-TLVs specific to the Reply Path
  TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static
  Tunnel sub-TLV.

  Note that an implementation that supports specific Vendor Private
  for sub-TLVs of the Target FEC Stack must take care to not confuse
  those values with the same values allocated from the Reply Path Sub-
  TLVs registry.
END                                                       

---

Section 3.3

  2.  Specify a more generic tunnel FEC as return path

It is clear that 3.3.1 and 3.3.2 define a FEC that is more general than
the FECs in 4379. What is not clear is the use case. I think you need
some text in this document to say what you should do with one of these
FECs since it possibly identifies a set of LSPs.

---

Section 3.3.1

OLD
  The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
  the recommended type value is TBD.
NEW
  The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
  the recommended type value is TBD1.
END

---

Section 3.3.1

It is slightly weird that the bit field in this section allocates the
first two bits while the field in section 3.2 allocates the last two
bits.  This is not significantly important, but is odd.

---

Section 3.3.2

OLD
  The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
  the type value is TBD.
NEW
  The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
  the type value is TBD2.
END

---

Section 3.3.3

RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is the
MPLS-TP static equivalent of 3.3.1. But you are missing:

- the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers)
- the MPLS-TP equivalent of the 4379 RSVP LSP FECs

Do you need them?

---

Section 3.3.3

OLD
  The sub-TLV type value is TBD.
NEW
  The sub-TLV type value is TBD3.
END

---

Section 3.4

OLD
  The Reply TC TLV Type field is 2 octets in length, and the type value
  is TBD.
NEW
  The Reply TC TLV Type field is 2 octets in length, and the type value
  is TBD4.
END

---

Section 4

  The procedures defined in this document currently only apply to
  "ping" mode.  The "traceroute" mode is out of scope for this
  document.

I think this should show up in the Introduction and possibly the
Abstract.

---

Section 6

Please consider whether you want registries for the bit fields you
define in this document.

---

Section 6.1

OLD
  TBD    Reply TC TLV                      this document (sect 3.4)
NEW
  TBD4    Reply TC TLV                      this document (sect 3.4)
END

---

Section 6.4

OLD
  TBD    Reply TC TLV                      this document (sect 3.4)
NEW
  TBD4    Reply TC TLV                      this document (sect 3.4)
END

---

Section 6.2.1

OLD
  Sub-type      Value Field            Reference
  -------      -----------            ---------
  TBD          IPv4 RSVP Tunnel        this document (sect 3.3.1)
  TBD          IPv6 RSVP Tunnel        this document (sect 3.3.2)
  TBD          Static Tunnel          this document (sect 3.3.3)
NEW
  Sub-type      Value Field            Reference
  -------      -----------            ---------
  TBD1          IPv4 RSVP Tunnel        this document (sect 3.3.1)
  TBD2          IPv6 RSVP Tunnel        this document (sect 3.3.2)
  TBD3          Static Tunnel          this document (sect 3.3.3)
END

---

Section 6.3

OLD
  IANA is now requested to assign the previously assigned a new reply
  mode code point (5 - Reply via specified path) from the "Multi-
  Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
  Parameters" registry, the "Reply Mode" sub-registry on a permanent
  basis.
NEW
  IANA has made an early allocation (5 - Reply via specified path) from
  the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
  (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. IANA
  is requested to make this allocation permanent.
END

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The MPLS working group request that:

            Return Path Specified LSP Ping

      draft-ietf-mpls-return-path-specified-lsp-ping-10

  is published as an RFC on the standards track.

  This draft specific a rather small extension to RFC4379 (Detecting
  Multi-Protocol Label Switched (MPLS) Data Plane Failures), this
  protocol specification is intended for service  provider networks
  to be useed under operational conditions, it clearly meets the
  criteria to become a standards track document.



(2) 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 document defines extensions to the failure-detection protocol
  for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
  known as "LSP Ping" that allow selection of the LSP to use for the
  echo reply return path.  Enforcing a specific return path can be used
  to verify bidirectional connectivity and also increase LSP ping
  robustness.  It may also be used by Bidirectional Forwarding
  Detection (BFD) for MPLS bootstrap signaling thereby making BFD for
  MPLS more robust.


Working Group Summary


Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  There has not been anything in the working group process that
  needs to be mentioned, other than we had a strong support to
  accept it as a working group draft, after that the discussion
  on the mailing were low for almost a year, but has pick up lately
  and we have had a good discussion, where all comments been
  focused on improving the and no indication that the draft is not
  needed. 

  The document has support in the working group, and operators has
  participated in writing it, and has been well reviewed.
  After improving the IANA section (mostly off-line) the document
  shepherd now believes we have a stable document ready to be
  published.

  The last two months has focused on a discussion of the IANA
  section of this document. We have earlier made "early allocations"
  of code points for this document, after discussion we have
  decided not use them, but reuse (identical) sub-TLVs allocated
  by RFC4379. A spin-off of the IANA discussion for this
  document is that we are discussing/thiking of writing an update
  to the IANA allocation of RFC4379.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  The working group mailing list has been polled for existing
  implementations and intentions to implement this specification.

  This is a very minor update to the LSP-Ping that does not have
  any affect on the operations of existing LSP Ping implementations
  and deployments, even if nodes with the new functionality are
  introduced.

  We know of vendors that intend to implement and at least one
  operator that plan to deploy this functionality."


Personnel



  Who is the Document Shepherd? Who is the Responsible Area
  Director?
 
  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.



(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd have reviewed the document several times,
  e.g. when deciduing to poll the doc to become a working group and
  before the wg last call, and alss recently with a focus on
  the IANA section and sections describing the code points.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.


(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

  No such concerns!

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  There is an IPR filed against this document.

  Before requesting publication the working group chairs did an IPR poll
  in the working group and for the authors, asking any members of the working
  group to speak up if they were aware of IPRs. The same poll required 
  the authors either to indicate if they were aware of IPRs or say that
  they were not.

  All the authors said they were not aware of any IPRs, othr than the
  previously filed IPR claim (ID #1491).



(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There is one IPR claim filed for this document (ID #1491). The
  working group were made aware of this IPR statement by a mail from
  one of the co-authors on July 4, i.e. immediately before the
  working group last call. It was also pointed out in the mail
  starting the working group last call.
  The IPR claim did not generate any discussion during the wg lc.



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

  The working group is behind this document. It has been well
  discussed and reviewed. 



(10) 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 publicly available.)

  No such threats.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


  The draft passes the ID-nits tool clean.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no such formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) 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 plan for their completion?

  All the references (both normative and informative) are to RFCs.
  All the normative references are to standard track RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No. However, there is a spin-off discussion if we need to (or
  should) update the IANA section of RFC4379.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  During WG last call it became apparent that there was something
  wrong or missing in the IANA section. This led to extensive IANA
  review by the Document Shepherd, and has involved a discussion
  between the WG chairs, the authors, and the AD. Most of the
  discussion was off the mailing list, but the conclusion was reported
  to the WG.

  The result was a significant update and clarification. The Shepherd
  is now comfortable that the section is correct.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


  No new IANA registries that require Expert Review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language.