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 |