Return Path Specified Label Switched Path (LSP) Ping
draft-ietf-mpls-return-path-specified-lsp-ping-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-01-22
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-01-15
|
15 | (System) | RFC Editor state changed to AUTH48 from EDIT |
2013-12-20
|
15 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-12-19
|
15 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-12-18
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-12-17
|
15 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-12-16
|
15 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-12-08
|
15 | (System) | IANA Action state changed to In Progress |
2013-12-06
|
15 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-12-05
|
15 | (System) | RFC Editor state changed to EDIT |
2013-12-05
|
15 | (System) | Announcement was received by RFC Editor |
2013-12-05
|
15 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-12-05
|
15 | Amy Vezza | IESG has approved the document |
2013-12-05
|
15 | Amy Vezza | Closed "Approve" ballot |
2013-12-05
|
15 | Adrian Farrel | State changed to Approved-announcement to be sent from IESG Evaluation |
2013-12-05
|
15 | Adrian Farrel | State changed to IESG Evaluation from IESG Evaluation::AD Followup |
2013-12-05
|
15 | Adrian Farrel | Ballot writeup was changed |
2013-12-05
|
15 | Adrian Farrel | Ballot approval text was generated |
2013-12-02
|
15 | Stewart Bryant | [Ballot comment] Thank you for making the clarifying changes to the text. |
2013-12-02
|
15 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2013-10-30
|
15 | Stephen Farrell | [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 … [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) |
2013-10-30
|
15 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-10-29
|
15 | Roni Even | Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. |
2013-10-21
|
15 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-15.txt |
2013-10-16
|
14 | Mach Chen | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-10-16
|
14 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-14.txt |
2013-09-26
|
13 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-09-26
|
13 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from No Record |
2013-09-26
|
13 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-09-26
|
13 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-09-25
|
13 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-09-25
|
13 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-09-25
|
13 | Brian Haberman | [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 … [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. |
2013-09-25
|
13 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Record from Discuss |
2013-09-25
|
13 | Brian Haberman | [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 … [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? |
2013-09-25
|
13 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2013-09-24
|
13 | Martin Stiemerling | [Ballot comment] The MTU issue should be checked. |
2013-09-24
|
13 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-09-24
|
13 | Stephen Farrell | [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? … [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.) |
2013-09-24
|
13 | Stephen Farrell | [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 … [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) |
2013-09-24
|
13 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-09-23
|
13 | Spencer Dawkins | [Ballot comment] I echo Stewart's Discuss about terminology and his Comment about whether there are any MTU size concerns that should be mentioned. |
2013-09-23
|
13 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-09-23
|
13 | Stewart Bryant | [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 … [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. |
2013-09-23
|
13 | Stewart Bryant | [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 … [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? |
2013-09-23
|
13 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2013-09-23
|
13 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-09-22
|
13 | Joel Jaeggli | [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 … [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. |
2013-09-22
|
13 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-09-22
|
13 | Adrian Farrel | [Ballot comment] RFC Editor Note added to cover the issue raised by IANA |
2013-09-22
|
13 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss |
2013-09-22
|
13 | Adrian Farrel | Ballot writeup was changed |
2013-09-19
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2013-09-19
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2013-09-18
|
13 | Adrian Farrel | [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 … [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? |
2013-09-18
|
13 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes |
2013-09-18
|
13 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-09-18
|
13 | Pearl Liang | 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 … 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) > > |
2013-09-17
|
13 | Adrian Farrel | Ballot has been issued |
2013-09-17
|
13 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2013-09-17
|
13 | Adrian Farrel | Created "Approve" ballot |
2013-09-17
|
13 | Adrian Farrel | Ballot writeup was changed |
2013-09-17
|
13 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-09-17
|
13 | Adrian Farrel | Placed on agenda for telechat - 2013-09-26 |
2013-09-16
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-09-16
|
13 | Mach Chen | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-09-16
|
13 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-13.txt |
2013-09-04
|
12 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-09-04
|
12 | Adrian Farrel | Changed consensus to Yes from Unknown |
2013-09-04
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2013-09-04
|
12 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-09-03
|
12 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-09-03
|
12 | Amanda Baber | 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 … 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. |
2013-08-29
|
12 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Hoffman. |
2013-08-22
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2013-08-22
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2013-08-22
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2013-08-22
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Paul Hoffman |
2013-08-21
|
12 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-08-21
|
12 | Amy Vezza | 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) … 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/ |
2013-08-21
|
12 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-08-21
|
12 | Adrian Farrel | Last call was requested |
2013-08-21
|
12 | Adrian Farrel | Ballot approval text was generated |
2013-08-21
|
12 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::Point Raised - writeup needed |
2013-08-21
|
12 | Adrian Farrel | Last call announcement was changed |
2013-08-21
|
12 | Adrian Farrel | Last call announcement was generated |
2013-08-21
|
12 | Adrian Farrel | Ballot writeup was changed |
2013-08-21
|
12 | Adrian Farrel | Document shepherd changed to Loa Andersson |
2013-07-29
|
12 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-12.txt |
2012-10-22
|
11 | Adrian Farrel | 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 … 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 |
2012-10-22
|
11 | Adrian Farrel | State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::AD Followup |
2012-10-21
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-10-21
|
11 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-11.txt |
2012-10-17
|
10 | Adrian Farrel | 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. … 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 |
2012-10-17
|
10 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-10-17
|
10 | Adrian Farrel | Ballot writeup was changed |
2012-10-17
|
10 | Adrian Farrel | Ballot writeup was generated |
2012-10-14
|
10 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2012-09-14
|
10 | Cindy Morgan | (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? … (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. |
2012-09-14
|
10 | Cindy Morgan | Note added 'Loa Andersson (loa@pi.nu) is the document shepherd.' |
2012-09-14
|
10 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-09-14
|
10 | Cindy Morgan | IESG process started in state Publication Requested |
2012-09-14
|
10 | (System) | Earlier history may be found in the Comment Log for draft-chen-mpls-return-path-specified-lsp-ping |
2012-09-13
|
10 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-10.txt |
2012-09-12
|
09 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-09.txt |
2012-08-30
|
08 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-08.txt |
2012-08-21
|
07 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-07.txt |
2012-08-01
|
06 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-06.txt |
2012-07-02
|
05 | Mach Chen | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-05.txt |
2011-10-30
|
04 | (System) | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-04.txt |
2011-07-11
|
03 | (System) | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-03.txt |
2011-02-14
|
(System) | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mpls-return-path-specified-lsp-ping-02 | |
2011-01-27
|
02 | (System) | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-02.txt |
2010-10-25
|
01 | (System) | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-01.txt |
2010-08-19
|
00 | (System) | New version available: draft-ietf-mpls-return-path-specified-lsp-ping-00.txt |