Skip to main content

Proxy MPLS Echo Request
draft-ietf-mpls-proxy-lsp-ping-05

Revision differences

Document history

Date Rev. By Action
2015-06-08
05 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-05-08
05 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-05-07
05 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2015-05-06
05 (System) RFC Editor state changed to AUTH from EDIT
2015-04-10
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-04-10
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2015-04-10
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-04-08
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-04-07
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-04-03
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-03-26
05 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-03-26
05 (System) RFC Editor state changed to EDIT
2015-03-26
05 (System) Announcement was received by RFC Editor
2015-03-26
05 (System) IANA Action state changed to In Progress
2015-03-25
05 Amy Vezza Shepherding AD changed to Deborah Brungard
2015-03-25
05 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-03-25
05 Cindy Morgan IESG has approved the document
2015-03-25
05 Cindy Morgan Closed "Approve" ballot
2015-03-25
05 Adrian Farrel Ballot approval text was generated
2015-03-25
05 Adrian Farrel Ballot writeup was changed
2015-03-25
05 Adrian Farrel IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-03-25
05 Adrian Farrel [Ballot comment]
Thanks for addressing IANA's concerns (my Discuss) and for picking up the Comments.
2015-03-25
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss
2015-03-25
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-03-25
05 Sam Aldrin IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-03-25
05 Sam Aldrin New version available: draft-ietf-mpls-proxy-lsp-ping-05.txt
2015-03-23
04 Loa Andersson Notification list changed to mpls@ietf.org, draft-ietf-mpls-proxy-lsp-ping.shepherd@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-proxy-lsp-ping.ad@ietf.org, draft-ietf-mpls-proxy-lsp-ping@ietf.org, loa@pi.nu from mpls-chairs@ietf.org, draft-ietf-mpls-proxy-lsp-ping@ietf.org
2015-03-06
04 Adrian Farrel IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2015-03-05
04 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2015-03-05
04 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-03-05
04 Stephen Farrell
[Ballot comment]

- the security considerations seems to use the term "proxy
node" when "proxy lsr" is used (there and) elsewhere. Maybe
that could do …
[Ballot comment]

- the security considerations seems to use the term "proxy
node" when "proxy lsr" is used (there and) elsewhere. Maybe
that could do with a bit of clean up? In particular the 3rd
last para is unclear as to which node is meant in the 2nd
sentence. (Or it wasn't clear to me at least.)
2015-03-05
04 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-03-05
04 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-03-05
04 Adrian Farrel [Ballot comment]
Review comments from Tom Taylor and Tom Yu appear to have been fumbled
2015-03-05
04 Adrian Farrel Ballot comment text updated for Adrian Farrel
2015-03-05
04 Adrian Farrel
[Ballot discuss]
IANA asked a question on 2/27 that hasn't been answered

> Two comments/questions:
> 1) For future reference purposes, please update the next …
[Ballot discuss]
IANA asked a question on 2/27 that hasn't been answered

> Two comments/questions:
> 1) For future reference purposes, please update the next version to include the
> "K Octets" values  for each of the new DS Mapping TLV:
>
> For IpV4 - 16
> For IPV6 - 40.
>
> Please note that IANA cannot reserve specific values.  Value 5 is not
> available. 
> However, early allocation is available for some types of registrations.
> For more information, please see RFC 7120.
>
> 2) There is a place holder  in section 1.2 of this draft:
>
>  [Note (to be removed after assignments occur):  = to be assigned
>  by IANA]
>
> Any value for ?
2015-03-05
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes
2015-03-05
04 Jari Arkko
[Ballot comment]
Thanks for writing this document, and for working through issues raised
in the Gen-ART review.

There was still a couple of questions in …
[Ballot comment]
Thanks for writing this document, and for working through issues raised
in the Gen-ART review.

There was still a couple of questions in the review that I also looked into,
and after reading the text in question, I also do not know the answer to.
Perhaps some clarifications would be useful? Or otherwise, maybe there
is some other explanation that at wasn't obvious to me.

---

2. Section 3.2.1, third paragraph, second sentence currently reads:

  "If the Proxy LSR is a budnode, a MPLS
  proxy ping reply SHOULD be sent to the initiator with the return code
  set to 3 (Reply router is Egress for FEC) with return Subcode set to
  0 and DS/DDMAPs only if the Proxy initiator requested information to
  be returned in a MPLS proxy ping reply."

Do you mean that the DS/DDMAP TLV is included only if the initiator
asked for it (which seems like redundant advice) or do you mean that the
reply is sent only if the initiator asked for the DS/DDMAP information?

3. Same paragraph, next sentence: why SHOULD rather than MUST? What is
the exception?

4. Section 3.2.1, last paragraph (dealing with MP2MP case): the second
to fourth sentences read:

"LSP pings sent from a leaf of a MP2MP has
  different behavior in this case. MPLS Echo Request are sent to all
  upstream/downstream neighbors. The Proxy LSRs need to be consistent
  with this variation in behavior."
s/has/have/ to get that out of the way.

Do you mean that the initiator is a leaf of the MP2MP? How does the
Proxy LSR know this? Does it matter?
2015-03-05
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-03-05
04 Benoît Claise
[Ballot comment]
That always makes me a sad when I see OAM technologies developed in silo.
At least, existing OAM terminology and concepts should be …
[Ballot comment]
That always makes me a sad when I see OAM technologies developed in silo.
At least, existing OAM terminology and concepts should be reused. At the minimum, a mapping should be explained.
Why? Because this is what network operators will have to do: here is yet another OAM technology they have to learn and integrate, how does it fit with the existing OAM tools? Note that LIME was created with that goal in mind. Anyway, I'm getting sidetracked: this issue is actually an issue for the IESG, not for this document. Hence a COMMENT and not a DISCUSS.

For example, RFC 5357

        +----------------+              +-------------------+
        | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
        +----------------+              +-------------------+
          ^                                    ^
          |                                    |
          |                                    |
          |                                    |
          |  +----------------+<----------------+
          |  |    Server    |
          |  +----------------+
          |    ^
          |    |
          | TWAMP-Control
          |    |
          v    v
        +----------------+
        | Control-Client |
        +----------------+


I've been trying to modify this picture with the concepts/terminology in this draft. So I contemplated the following definitions for some time (and read the text around it obviously)...

    Initiator - the node which initiates the ping operation by sending
      an MPLS Proxy Ping Request message

      Proxy LSR - the node which is the destination of the MPLS Proxy
      Ping Request message and potential initiator of the MPLS Echo
      Request

      Receiver(s) - the nodes which receive the MPLS Echo Request
      message

      Responder - A receiver that responds to an MPLS Proxy Ping Request
      or an MPLS Echo Request

  We note that in some scenarios, the initiator could also be the
  responder, in which case the response would be internal to the node.

... and I gave up.

As mentioned by the Alia, Brian, Richard, without a diagram this is really not easy.
Let me quote Alia's COMMENT: "Sadly, I'm not expecting changes now."
I guess (and trust your routing AD) that the draft is fine from OPS point of view!
2015-03-05
04 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-03-04
04 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-03-04
04 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-03-04
04 Richard Barnes [Ballot comment]
+1 on diagrams.
2015-03-04
04 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2015-03-04
04 Spencer Dawkins
[Ballot comment]
It's a nit, but in this text:

  It is anticipated that very large Point-to-Multipoint and Multipoint-
  to-Multipoint (MP2MP) Label Switched Paths …
[Ballot comment]
It's a nit, but in this text:

  It is anticipated that very large Point-to-Multipoint and Multipoint-
  to-Multipoint (MP2MP) Label Switched Paths will exist.
 
I'm not understanding what dimension "very large" is conjuring up. Is this bandwidth, or length, or something else?
2015-03-04
04 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-03-04
04 Kathleen Moriarty
[Ballot comment]
The security considerations looks good, thanks for that. 

I don't see a response on the SecDir review.  The comments are mainly ones that …
[Ballot comment]
The security considerations looks good, thanks for that. 

I don't see a response on the SecDir review.  The comments are mainly ones that might help a reader less familiar with the space as there are a few requests for clarifying details.
https://www.ietf.org/mail-archive/web/secdir/current/msg05454.html
2015-03-04
04 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-03-03
04 Brian Haberman [Ballot comment]
I agree with Alia's assessment that a diagram or two would have made the document much easier to understand.
2015-03-03
04 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-03-03
04 Alia Atlas
[Ballot comment]
I wish this draft had both a picture or two to show the message paths and had something that clearly showed what fields …
[Ballot comment]
I wish this draft had both a picture or two to show the message paths and had something that clearly showed what fields were copied and which generated and what the conditions were for the various message replies.

I don't have concerns about the details of the text - but it is hard to pull the full picture together of what is happening.
Sadly, I'm not expecting changes now.
2015-03-03
04 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-03-02
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tom Yu.
2015-03-02
04 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-03-01
04 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Warren Kumari.
2015-02-27
04 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-02-27
04 Adrian Farrel Ballot has been issued
2015-02-27
04 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2015-02-27
04 Adrian Farrel Created "Approve" ballot
2015-02-27
04 Adrian Farrel Ballot writeup was changed
2015-02-27
04 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2015-02-27
04 Adrian Farrel Changed consensus to Yes from Unknown
2015-02-26
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-02-26
04 Sam Aldrin IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2015-02-26
04 Sam Aldrin New version available: draft-ietf-mpls-proxy-lsp-ping-04.txt
2015-02-13
03 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2015-02-13
03 Adrian Farrel Telechat date has been changed to 2015-03-05 from 2015-02-19
2015-02-12
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-02-10
03 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-02-05
03 Jean Mahoney Request for Last Call review by GENART is assigned to Tom Taylor
2015-02-05
03 Jean Mahoney Request for Last Call review by GENART is assigned to Tom Taylor
2015-02-05
03 Adrian Farrel Placed on agenda for telechat - 2015-02-19
2015-02-05
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tom Yu
2015-02-05
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tom Yu
2015-01-31
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Warren Kumari
2015-01-31
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Warren Kumari
2015-01-29
03 Cindy Morgan IANA Review state changed to IANA - Review Needed
2015-01-29
03 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Proxy MPLS Echo Request) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Proxy MPLS Echo Request) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Proxy MPLS Echo Request'
  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 2015-02-12. 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 a means of remotely initiating Multiprotocol
  Label Switched Protocol Pings on Label Switched Paths. A MPLS proxy
  ping request is sent to any Label Switching Routers along a Label
  Switched Path. The primary motivations for this facility are first to
  limit the number of messages and related processing when using LSP
  Ping in large Point-to-Multipoint LSPs, and second to enable leaf to
  leaf/root tracing.

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

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


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

  http://datatracker.ietf.org/ipr/778/
  http://datatracker.ietf.org/ipr/2164/
  http://datatracker.ietf.org/ipr/2087/
2015-01-29
03 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2015-01-29
03 Adrian Farrel Last call was requested
2015-01-29
03 Adrian Farrel Ballot approval text was generated
2015-01-29
03 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2015-01-29
03 Adrian Farrel Ballot writeup was changed
2015-01-29
03 Adrian Farrel Ballot writeup was changed
2015-01-29
03 Adrian Farrel Ballot writeup was generated
2015-01-29
03 Adrian Farrel Last call announcement was changed
2015-01-29
03 Adrian Farrel Last call announcement was generated
2015-01-29
03 Adrian Farrel Last call announcement was generated
2015-01-29
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-01-29
03 Sam Aldrin New version available: draft-ietf-mpls-proxy-lsp-ping-03.txt
2014-08-17
02 Adrian Farrel
AD Review
=========

Hello,

Thanks for this draft. It completes another piece of the puzzle.

I have done my normal AD review to respond to …
AD Review
=========

Hello,

Thanks for this draft. It completes another piece of the puzzle.

I have done my normal AD review to respond to the publication request. I
didn't find any show-stoppers, but I have a number of minor issues and
questions.

As is usual, you should feel free (you are actively encouraged!) to tell
me I am wrong or that a change does not need to be made. I await your
response either through email or with a revised I-D.

Thanks for the work,
Adrian

===

Do you really need the pre-RFC5378 disclaimer?

---

Please check for acronym expansions. I see:

LSR

---

A little inconsistency in "a LSP" and "an LSP".

---

Section 2 would be enhanced by a figure. Something like...

                      R3--R5---egress1
                    /
                    /
  ingress---R1---R2--Proxy--R6---egress2
                    /    \
                    /      \
                  /        R7--R8---egress3
                  /          \
                R4            \
              /                R9--egress4
              /                  \
            /                    \
      initiator                  egress5


Together with some explanatory text.

---

In 3.2 you have
  An MPLS
  proxy ping reply message MAY be sent with a Return Code of ,
  "Proxy Ping not authorized".

Should read

---

Looking back at 4379, it is not clear to me how a legacy implementation
listening on port 3503 will react to receiving the new message type for
a proxy message. The text is phrased in terms of the ability to parse an
echo request/reply, and clearly the new message is neither of these.


So do you believe this is covered by 4379 section 4.4
  1. General packet sanity is verified.  If the packet is not well-
      formed, LSR X SHOULD send an MPLS Echo Reply with the Return Code
      set to "Malformed echo request received" and the Subcode to zero.
You could make a case for that, although it is inside a section that
implies that the message type has already been determined and
immediately follows the text...
  An LSR X that receives an MPLS echo request then processes it as
  follows.
(Also compare with section 4.6).

Anyway, you should include text on backward compatibility.
1. The case just described
2. The case where a targetted proxy doesn't support LSP ping at all.

---

Section 3.2

  If not, it
  sets the Return Code set to "Malformed echo request received" or "TLV
  not understood" (as appropriate)

Delete "set"
Worry about "as appropriate" because it assumes that the reader will
make the right choice where you probably want to be more prescriptive.

---

Section 3.2

  If
  the Reply Mode of the message header is not 1(Do not reply), an MPLS
  proxy ping reply message SHOULD be sent as described below.  In the
  latter case, the misunderstood TLVs (only) are included in an Errored
  TLVs TLV.

"the latter case"?

---

3.2

  If not, it sets the Return Code set to
  "Malformed echo request received" and the Subcode set to zero.

Delete "set"

---

3.2.1 has some lower case "should". Probably worth checking the whole
document for consistent 2119 usage.

---

3.2.2.

  When the Proxy LSR is a transit or bud node, downstream maps
  corresponding to how the packet is transited can not be supplied
  unless an ingress interface for the MPLS Echo Request is specified,
  since this information is not available and since all valid output
  paths are of interest, the Proxy LSR should include DS/DDMAP(s) to
  describe the entire set of paths that the packet can be replicated,
  like in the case where an LSP ping is initiated at the Proxy LSR.


Is that two sentences with "...specified.  Since..."?


I'm not sure what purpose Section 4.1 serves. I don't like that you
have created a second (normative?) description of the message format.

Couldn't you just say:

  The format of MPLS LSP Ping messages is defined in [RFC4379].  This
  document defines two new message types as follows:

      Type    Message
      ----    -------
      TBA-1    MPLS proxy ping request
              (Pending IANA assignment)

      TBA-2    MPLS proxy ping reply
              (Pending IANA assignment)

---

The security considerations say:

  If such a network also carries Internet traffic, or permits IP access
  from other administrations, MPLS proxy ping message SHOULD be
  discarded at those points.  This can be accomplished by filtering on
  source address or by filtering all MPLS ping messages on UDP port.

I think that the mechanisms you describe here would also prohibit normal
LSP ping from transiting the network boundary. This is probably what
you intend, but I note that 4379 does not make this recommendation so
the filtering you suggest here for proxy ping would have an effect on
all LSP ping function and changes the behavior of 4379.

The way to handle this, I think, is to paint it red. That is, say that
this is an additional filter compared to the advice in 4379, but it is
a damn fine idea.

Alternatively, you need to step back slightly and call on the border
nodes to look into the message type field.

---

It seems that proxy ping messages would be relatively easy to spoof.
This, combined with the fact that the receipt of a proxy ping causes
the proxy to retain state and to issue echo requests to the network
looks like two DoS vectors for the price of one.

So, I think you need:
- discussion of authentication for proxy requests
- recommendation to rate limit receipt of proxy requests
- recommendation to discard "duplicate" proxy requests

---

I'm not quite sure about the initiator being allowed to instruct the
proxy about which source port it must use in an echo request. 

(Incidentally, Section 3.2 doesn't restate that this has to happen
although 3.2.4.1 does restate it).

What happens if the proxy request asks for a reserved port number to be
used? What if the port is already in use by the proxy for something
else? Why does it matter which source port the proxy uses? Why does the
proxy need to be able to control that? Why can't the proxy select its
own source port?
                                       
---

Should the point from 3.2.4.2 be echoed in the Security Considerations?

  If any additional labels are
  pushed onto the stack, their TTLs are set to 255. This will ensure
  that the requestor will not have control over tunnels not relevant to
  the FEC being tested.
2014-08-17
02 Adrian Farrel IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2014-08-10
02 Adrian Farrel IESG state changed to AD Evaluation from Publication Requested
2014-07-31
02 Loa Andersson
  The MPLS working group request that

                        Proxy MPLS Echo Request
    …
  The MPLS working group request that

                        Proxy MPLS Echo Request
                  draft-ietf-mpls-proxy-lsp-ping-02

        Is published as an RFC on the Standards Track.

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

  This document specifies protocol extensions and new protocol elements
  to be used with an standard tracks RFC [RFC 4379]. Consequently this
  document also needs to be on the standards track.
 

(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


  There are two motivations for this document..
  First the scalability of automatic replication of MPLS Echo Request Messages
  as they are traversing proceed down the tree.  Second the ability to trace a
  sub-LSP from leaf node to root node.

  Two design criteria are that large MP2MP LSPs exist and that the applications
  for P2MP/MP2MP tunnels require an OAM that is both rigorous and scalable.

  The normal tracing procedure - pinging repeatedly pinging from the
  root and the TTL by one after three pings, could produce a large
  amount of processing at midpoints and egresses, and produce large number 
  of replies back to the root.

  When an LSP is set up from the root, e.g. RSVP-TE, and the root consequently
  have knowledge of the entire tree, this could rather easily be mitigated by start
  sending pings from nodes closer to the affected area.

  When the tree is set up from the leafs, e.g. mLDP, the root may be aware of
  only the immediate downstream nodes. Leaf nodes may only be aware of the
  immediate upstream nodes. This document describes a method by which leafs
  can start the tracing process from the leaf working gradually towards the root.
  The leaf does so by sending an upstream node a message asking it to send an
  Echo Request to the leaf and the identity of the next upstream neighbor. This
  information is used to iteratively reach the root or the fualt is localized..

  This document defines protocol extensions to MPLS ping [RFC4379] to
  allow a third party to remotely cause an MPLS Echo Request message to
  be sent down a LSP or part of an LSP.


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?

    The working group process has been smooth, we had comparatively few
    comments (all of the supportive) during the wglc, but had a good discussion
    during the MPLS-RT review (April 2013). No points of particular rough
    consensus, the working group is behind this document.

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?

    We  know of  implementations of this specification. An implementation
    poll has been sent to the working group mailing list and the
    write-up will be updated as soon as we have further information.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

      Loa ANdersson is the Document Shepherd.
      Adrian Farrel is 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 has reviewed the document when it first showed
      up as an individual draft (it did replace an earlier wg document-
      draft-ietf-mpls-remote-lsp-ping), when the document was prepared for MPLS-RT
      review and when preparing it for wglc.

      This document is ready for being published as an RFC on the standards
      track.

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

      No such concerns.

(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 such reviews required or necessary.

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

      All authors and contributors have confirmed that they are not aware of
      any IPRs other than those disclosed.

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

      There are three IPR disclosures against this document, disclosures
      ID # 778, ID # 2087 and ID # 2164.

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

    There is a good consensus in the working group for this document.

(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 document passes through the nits toll clean.

      There are three comments, one on the use of pre-RFC5378 boiler
      plate; in this case it is correct to use that boiler plate.
      The other two comments are generated because a valid range is describe
      as "[1,255], causing the nits tool to ask if this is a reference, which it is
      not.
     

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

      No such formal reviews required.

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

      Yes - the references are correctly split-

(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 are to existing 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.

      There are 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.

      Publication of this document will not change the status or any other
    document.


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

      The IANA consideration are well and clearly written. The section has
      been reviewed by the Document Shepherd prior to wglc and in preparing
      the document write-up.

(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 such IANA registries.

(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 such reviews.
2014-07-31
02 Loa Andersson State Change Notice email list changed to mpls-chairs@tools.ietf.org, draft-ietf-mpls-proxy-lsp-ping@tools.ietf.org
2014-07-31
02 Loa Andersson Responsible AD changed to Adrian Farrel
2014-07-31
02 Loa Andersson IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-07-31
02 Loa Andersson IESG state changed to Publication Requested
2014-07-31
02 Loa Andersson IESG process started in state Publication Requested
2014-07-31
02 Loa Andersson Changed document writeup
2014-07-22
02 Loa Andersson Changed document writeup
2014-07-14
02 Loa Andersson Changed document writeup
2014-07-13
02 Loa Andersson Tag Revised I-D Needed - Issue raised by WGLC cleared.
2014-07-13
02 Loa Andersson IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2014-07-13
02 Loa Andersson Changed document writeup
2014-07-13
02 Loa Andersson Changed document writeup
2014-07-11
02 Loa Andersson Changed document writeup
2014-07-10
02 Loa Andersson Changed document writeup
2014-07-10
02 Loa Andersson Changed document writeup
2014-07-10
02 Loa Andersson Changed document writeup
2014-07-03
02 Sam Aldrin New version available: draft-ietf-mpls-proxy-lsp-ping-02.txt
2014-01-21
01 Loa Andersson Tag Revised I-D Needed - Issue raised by WGLC set.
2014-01-21
01 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2014-01-04
01 Loa Andersson Intended Status changed to Proposed Standard from None
2014-01-04
01 Loa Andersson IETF WG state changed to In WG Last Call from WG Document
2014-01-04
01 Loa Andersson Document shepherd changed to Loa Andersson
2014-01-02
01 George Swallow New version available: draft-ietf-mpls-proxy-lsp-ping-01.txt
2013-08-05
(System) Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-mpls-proxy-lsp-ping-00
2013-07-05
00 Vanson Lim New version available: draft-ietf-mpls-proxy-lsp-ping-00.txt