IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)
draft-ietf-mpls-oam-ipv6-rao-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-04-15
|
03 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-04-06
|
03 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-04-02
|
03 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-03-25
|
03 | Amy Vezza | Shepherding AD changed to Deborah Brungard |
2015-03-23
|
03 | Loa Andersson | Notification list changed to mpls@ietf.org, draft-ietf-mpls-oam-ipv6-rao.ad@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-oam-ipv6-rao.shepherd@ietf.org, draft-ietf-mpls-oam-ipv6-rao@ietf.org, loa@pi.nu from mpls@ietf.org, mpls-chairs@ietf.org, loa@pi.nu |
2015-03-04
|
03 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-03-03
|
03 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2015-03-03
|
03 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2015-03-01
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tina Tsou. |
2015-02-23
|
03 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-02-23
|
03 | (System) | RFC Editor state changed to EDIT |
2015-02-23
|
03 | (System) | Announcement was received by RFC Editor |
2015-02-23
|
03 | (System) | IANA Action state changed to Waiting on Authors |
2015-02-23
|
03 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-02-23
|
03 | Amy Vezza | IESG has approved the document |
2015-02-23
|
03 | Amy Vezza | Closed "Approve" ballot |
2015-02-23
|
03 | Amy Vezza | Ballot approval text was generated |
2015-02-19
|
03 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2015-02-19
|
03 | Adrian Farrel | Ballot writeup was changed |
2015-02-19
|
03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-02-19
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-02-18
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-02-18
|
03 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2015-02-18
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-02-17
|
03 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2015-02-17
|
03 | Kathleen Moriarty | [Ballot comment] Thanks for addressing the non-security nits found by the SecDir reviewer. https://www.ietf.org/mail-archive/web/secdir/current/msg05420.html |
2015-02-17
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-17
|
03 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-02-17
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-02-17
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-02-16
|
03 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-02-16
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-02-16
|
03 | Spencer Dawkins | [Ballot comment] Thanks for working with me to clear my Discuss, which was: This Discuss ballot is probably more accurately a "Please clue in a … [Ballot comment] Thanks for working with me to clear my Discuss, which was: This Discuss ballot is probably more accurately a "Please clue in a TSV AD who is trying to pattern match and failing" ballot, and likely quick to resolve. But, I'm looking at this text: 4. Updates to RFC 4379 [RFC4379] specifies the use of the Router Alert Option in the IP header. Sections 4.3 and 4.5 of [RFC4379] are updated as follows: for every time in which the "Router Alert IP option" is used, the following text is appended: In case of an IPv4 header, the generic IPv4 Router Alert Option value 0x0 [RFC2113] SHOULD be used. In case of an IPv6 header, ^^^^^^ the IPv6 Router Alert Option value TBD1 allocated through this document for MPLS OAM MUST be used. When I click over to Section 4.3 of [RFC4379], I see this text: 4.3. Sending an MPLS Echo Request An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104. The IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). The Router Alert option MUST be set in the IP header. ^^^^ Could you help me understand whether this is really a MUST in Section 4.3 of [RFC4379] that is morphing into a SHOULD for IPv4 and remaining a MUST in IPv6? I have the same confusion in Section 4.5, but I'm betting the same answer applies. |
2015-02-16
|
03 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2015-02-16
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-16
|
03 | Spencer Dawkins | [Ballot discuss] This Discuss ballot is probably more accurately a "Please clue in a TSV AD who is trying to pattern match and failing" ballot, … [Ballot discuss] This Discuss ballot is probably more accurately a "Please clue in a TSV AD who is trying to pattern match and failing" ballot, and likely quick to resolve. But, I'm looking at this text: 4. Updates to RFC 4379 [RFC4379] specifies the use of the Router Alert Option in the IP header. Sections 4.3 and 4.5 of [RFC4379] are updated as follows: for every time in which the "Router Alert IP option" is used, the following text is appended: In case of an IPv4 header, the generic IPv4 Router Alert Option value 0x0 [RFC2113] SHOULD be used. In case of an IPv6 header, ^^^^^^ the IPv6 Router Alert Option value TBD1 allocated through this document for MPLS OAM MUST be used. When I click over to Section 4.3 of [RFC4379], I see this text: 4.3. Sending an MPLS Echo Request An MPLS echo request is a UDP packet. The IP header is set as follows: the source IP address is a routable address of the sender; the destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127/104. The IP TTL is set to 1. The source UDP port is chosen by the sender; the destination UDP port is set to 3503 (assigned by IANA for MPLS echo requests). The Router Alert option MUST be set in the IP header. ^^^^ Could you help me understand whether this is really a MUST in Section 4.3 of [RFC4379] that is morphing into a SHOULD for IPv4 and remaining a MUST in IPv6? I have the same confusion in Section 4.5, but I'm betting the same answer applies. |
2015-02-16
|
03 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2015-02-13
|
03 | Brian Carpenter | Request for Telechat review by GENART Completed: Almost Ready. Reviewer: Brian Carpenter. |
2015-02-12
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2015-02-12
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Brian Carpenter |
2015-02-05
|
03 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Vincent Roca. |
2015-02-04
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-02-04
|
03 | Carlos Pignataro | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-02-04
|
03 | Carlos Pignataro | New version available: draft-ietf-mpls-oam-ipv6-rao-03.txt |
2015-02-04
|
02 | Adrian Farrel | Ballot has been issued |
2015-02-04
|
02 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2015-02-04
|
02 | Adrian Farrel | Created "Approve" ballot |
2015-02-04
|
02 | Adrian Farrel | Changed consensus to Yes from Unknown |
2015-02-04
|
02 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-02-04
|
02 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-01-31
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2015-01-31
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2015-01-27
|
02 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2015-01-27
|
02 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-oam-ipv6-rao-02. 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-oam-ipv6-rao-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the IPv6 Router Alert Option Values registry located at: http://www.iana.org/assignments/ipv6-routeralert-values/ a new option value is to be registered as follows: Value: [ TBD-at-registration ] Description: MPLS OAM Reference: [ RFC-to-be ] IANA understands that this is the only action that needs 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. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. |
2015-01-25
|
02 | Brian Carpenter | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Brian Carpenter. |
2015-01-22
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-01-22
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2015-01-22
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2015-01-22
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2015-01-21
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-01-21
|
02 | 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: (IPv6 Router Alert Option for … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IPv6 Router Alert Option for MPLS OAM) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'IPv6 Router Alert Option for MPLS OAM' 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-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 RFC 4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the Router Alert Option MUST be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO), there is no generic Router Alert Option Value defined for IPv6 that can be used. This document allocates a new generic IPv6 Router Alert Option Value that can be used by MPLS OAM tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379. The initial motivation to request an IPv6 Router Alert Option (RAO) code point for MPLS OAM comes from MPLS LSP Ping/Traceroute. However, this code point is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-oam-ipv6-rao/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-01-21
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-01-21
|
02 | Adrian Farrel | Last call was requested |
2015-01-21
|
02 | Adrian Farrel | Ballot approval text was generated |
2015-01-21
|
02 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
2015-01-21
|
02 | Adrian Farrel | Last call announcement was changed |
2015-01-21
|
02 | Adrian Farrel | Last call announcement was generated |
2015-01-21
|
02 | Adrian Farrel | Placed on agenda for telechat - 2015-02-19 |
2015-01-21
|
02 | Adrian Farrel | Ballot writeup was changed |
2015-01-21
|
02 | Adrian Farrel | Ballot writeup was generated |
2015-01-13
|
02 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2015-01-06
|
02 | Adrian Farrel | Notification list changed to mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-ietf-mpls-oam-ipv6-rao.all@tools.ietf.org, loa@pi.nu from "Loa Andersson" <loa@pi.nu> |
2015-01-04
|
02 | Loa Andersson | The MPLS WG requests that IPv6 Router Alert Option for MPLS OAM draft-ietf-mpls-oam-ipv6-rao-02 is published as an RFC on … The MPLS WG requests that IPv6 Router Alert Option for MPLS OAM draft-ietf-mpls-oam-ipv6-rao-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? We request that this is published as a Standards Track RFC, this is also indicated in the title page header. The RFC needs to a Standards Track RFC since it updates RFC 4379 and makes an allocation from an IETF Consensus IANA registry: http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml The intended status in clearly indicated in the document header. (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 updates RFC 4379 This document fixes a gap in MPLS/IPv6, in RFC 4379 that defines the MPLS LSP Ping/Traceroute mechanism, a Router Alert Option MUST be set in the IP header of the MPLS Echo Request messages, and may conditionally be set in the IP header of the MPLS Echo Reply messages. A generic "Router shall examine packet" Option Value is used for the IPv4 Router Alert Option (RAO). There is no corresponding generic Router Alert Option Value defined for IPv6. This document allocates this new generic IPv6 RAO Value. The RAO value can be used by the entire set of MPLS OAM functions as needed, but the initial motivation comes from using RFC 4379 with IPv6. The document defines the RAO that will be used in the MPLS Echo Request and MPLS Echo Reply messagesin IPv6 environments. Consequently, it updates RFC 4379. 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? This document is generally accepted by the working group, there are several implementations of RFC 4379 going on or planned and this gap is widely recognized. 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? No expert reviews necessary! The question about implementations is a bit imprecise for this document. There are several implementations that will use the assigned RAO Value, whether this qualifies as "implementations of the protocol" is open for debate. The RAO Value is necessary to correctly implement LSP Ping and Traceroute for IPv6 networks. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Loa ANdersson Responsible Area Director: Adrian Farrel (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. Since this document is one of the first that actually fills one of the gaps pointed out by draft-ietf-mpls-ipv6-only-gap (in AUTH48) it has been of interest to follow the development of this document carefully. The document shepherd has read every new version of the document, and reviewed it at the wg adoption poll, wglc and prior to requesting publication. (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 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 the authors have declared on the working group mailing list that they are unaware of any IPRs that relate to this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPRs disclosed against this document! (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 very strong consensus that we need MPLS and MPLS OAM tools for IPv6 networks (as matter of fact it is also a policy by IESG); this document fills an exsting gap to make such implementations possible. This document has also been discussed in and reviewed by the 6man wg. (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 discontent! (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 the nits toll clean. One comment - date in the past, I can understand that this is useful when submitting drafts but for documents that been processed for a while, it is just extra noise; can we update the nits tool to only run that check if it is part of the posting process. The situation is that a document that was written about 1k RFCs before 5378 is updated by this new document, but to the best of my understanding no text from that document is reproduced; I venture to say that the disclaimer is not needed. (But I'm happily stand corrected). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews needed. (13) Have all references within this document been identified as either normative or informative? Yes - the references are correctly split! All normative references are to existing RFCs. (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 normative 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. 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 - the publication of this document will not change the status of any existing RFC. (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 considerations are well and clearly written, the registry from which the allocation is made is clearly identified. If anything we could have asked for assignement of the "first free" value, but since this seems to be IANA practice, it would be redundant. (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 defined. (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 is used in the document. |
2015-01-04
|
02 | Loa Andersson | Responsible AD changed to Adrian Farrel |
2015-01-04
|
02 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2015-01-04
|
02 | Loa Andersson | IESG state changed to Publication Requested |
2015-01-04
|
02 | Loa Andersson | IESG process started in state Publication Requested |
2015-01-04
|
02 | Loa Andersson | Intended Status changed to Proposed Standard from None |
2015-01-04
|
02 | Loa Andersson | Changed document writeup |
2015-01-04
|
02 | Loa Andersson | Changed document writeup |
2015-01-04
|
02 | Loa Andersson | Changed document writeup |
2015-01-04
|
02 | Loa Andersson | Changed document writeup |
2014-12-28
|
02 | Loa Andersson | Changed document writeup |
2014-12-21
|
02 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2014-12-20
|
02 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-12-02
|
02 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2014-11-30
|
02 | Carlos Pignataro | New version available: draft-ietf-mpls-oam-ipv6-rao-02.txt |
2014-11-30
|
01 | Carlos Pignataro | New version available: draft-ietf-mpls-oam-ipv6-rao-01.txt |
2014-11-28
|
00 | Loa Andersson | Notification list changed to "Loa Andersson" <loa@pi.nu> |
2014-11-28
|
00 | Loa Andersson | Document shepherd changed to Loa Andersson |
2014-10-19
|
00 | Loa Andersson | This document now replaces draft-raza-mpls-oam-ipv6-rao instead of None |
2014-10-19
|
00 | Kamran Raza | New version available: draft-ietf-mpls-oam-ipv6-rao-00.txt |