Recommendation to Use the Ethernet Control Word
draft-ietf-pals-ethernet-cw-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-11-05
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-09-20
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-08-17
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-07-09
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2018-07-09
|
07 | (System) | RFC Editor state changed to EDIT |
2018-07-09
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-07-09
|
07 | (System) | Announcement was received by RFC Editor |
2018-07-09
|
07 | (System) | IANA Action state changed to In Progress |
2018-07-09
|
07 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2018-07-09
|
07 | Cindy Morgan | IESG has approved the document |
2018-07-09
|
07 | Cindy Morgan | Closed "Approve" ballot |
2018-07-09
|
07 | Cindy Morgan | Ballot approval text was generated |
2018-07-09
|
07 | Cindy Morgan | Ballot writeup was changed |
2018-07-09
|
07 | Cindy Morgan | RFC Editor Note was changed |
2018-07-09
|
07 | Cindy Morgan | RFC Editor Note was changed |
2018-07-09
|
07 | Cindy Morgan | RFC Editor Note for ballot was generated |
2018-07-09
|
07 | Cindy Morgan | RFC Editor Note for ballot was generated |
2018-07-09
|
07 | Deborah Brungard | Ballot writeup was changed |
2018-07-09
|
07 | Deborah Brungard | Ballot approval text was changed |
2018-07-02
|
07 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-07.txt |
2018-07-02
|
07 | (System) | New version approved |
2018-07-02
|
07 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , pals-chairs@ietf.org, Andrew Malis , Ignas Bagdonas |
2018-07-02
|
07 | Stewart Bryant | Uploaded new revision |
2018-06-21
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-06-21
|
06 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-06-21
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Alan DeKok. |
2018-06-20
|
06 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2018-06-20
|
06 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-06-20
|
06 | Spencer Dawkins | [Ballot comment] In this text, This problem has recently become more serious for a number of reasons. Firstly, due to the deployment of … [Ballot comment] In this text, This problem has recently become more serious for a number of reasons. Firstly, due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6 assigned by the IEEE Registration Authority Committee (RAC). Secondly, concerns over privacy have led to the use of MAC address randomization which assigns local MAC addresses randomly for privacy. Random assignment results in addresses starting with one of these two values one time in eight. the problem caused by the second case is explained well, but the problem caused by the first reason is not. Would it be correct to say This problem has recently become more serious for a number of reasons. Firstly, due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6 assigned by the IEEE Registration Authority Committee (RAC). Any addresses that start with either of these two values can be misidentified. Secondly, concerns over privacy have led to the use of MAC address randomization which assigns local MAC addresses randomly for privacy. Random assignment results in addresses starting with one of these two values one time in eight. ? |
2018-06-20
|
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-06-20
|
06 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-06-20
|
06 | Ignas Bagdonas | [Ballot Position Update] New position, Recuse, has been recorded for Ignas Bagdonas |
2018-06-19
|
06 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-06-19
|
06 | Ben Campbell | [Ballot comment] Others have mentioned it seems odd that the document says (in several places) that it recommends use of the CW, but section 4 … [Ballot comment] Others have mentioned it seems odd that the document says (in several places) that it recommends use of the CW, but section 4 says "MUST". In particular, the document _title_ says RECOMMENDED in all caps, which could be interpreted as an attempt at normative language. I think this is likely to confuse at least some readers. §3: The "recent posting" is from 2016. Calling that "recent" is already a bit dated. |
2018-06-19
|
06 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-06-18
|
06 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-06-18
|
06 | Alvaro Retana | [Ballot comment] The title of the document is "Use of Ethernet Control Word RECOMMENDED", which hints at the corresponding rfc2119 keyword: 3. SHOULD This … [Ballot comment] The title of the document is "Use of Ethernet Control Word RECOMMENDED", which hints at the corresponding rfc2119 keyword: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That seems to be in line with the description in the Introduction: "This document recommends the use of the Ethernet pseudowire control word in all but exceptional circumstances." However, the qualified recommendation is that if "both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used". What are the "exceptional circumstances"? Should that "MUST" be a "SHOULD"? Should the use be further qualified? This comment is not a showstopper, just a minor misalignment. |
2018-06-18
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-06-18
|
06 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-06-18
|
06 | Mirja Kühlewind | [Ballot comment] One minor recommend edit: Given that this drafts updates RFC4448 to a MUST, maybe s/This document recommends /This document requires/ |
2018-06-18
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-06-15
|
06 | Benjamin Kaduk | [Ballot comment] In Section 4: The use of both methods on the same PW is not normally necessary and should be avoided unless … [Ballot comment] In Section 4: The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. The "both" here refers to ELI and FAT PW (as opposed to CW and something), right? Should that be disambiguated or is it clear enough as-is? |
2018-06-15
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-06-15
|
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-06-11
|
06 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Brian Carpenter. Sent review to list. |
2018-06-10
|
06 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Harish Sitaraman. |
2018-06-08
|
06 | Cindy Morgan | Placed on agenda for telechat - 2018-06-21 |
2018-06-08
|
06 | Deborah Brungard | Ballot has been issued |
2018-06-08
|
06 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2018-06-08
|
06 | Deborah Brungard | Created "Approve" ballot |
2018-06-08
|
06 | Deborah Brungard | Ballot writeup was changed |
2018-06-07
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-06-07
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2018-06-07
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2018-06-07
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2018-06-05
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2018-06-05
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2018-06-01
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-06-01
|
06 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-pals-ethernet-cw-06, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-pals-ethernet-cw-06, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Amanda Baber Lead IANA Services Specialist |
2018-06-01
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-06-01
|
06 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-06-15): From: The IESG To: IETF-Announce CC: db3546@att.com, Matthew Bocci , matthew.bocci@nokia.com, pals-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2018-06-15): From: The IESG To: IETF-Announce CC: db3546@att.com, Matthew Bocci , matthew.bocci@nokia.com, pals-chairs@ietf.org, pals@ietf.org, draft-ietf-pals-ethernet-cw@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Use of Ethernet Control Word RECOMMENDED) to Proposed Standard The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the following document: - 'Use of Ethernet Control Word RECOMMENDED' 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 2018-06-15. 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 The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW an Ethernet pseudowire packet can be misidentified as an IP packet by a label switching router (LSR). This in turn may lead to the selection of the wrong equal-cost-multi- path (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document recommends the use of the Ethernet pseudowire control word in all but exceptional circumstances. This document updates RFC 4448. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pals-ethernet-cw/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-06-01
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-06-01
|
06 | Deborah Brungard | Last call was requested |
2018-06-01
|
06 | Deborah Brungard | Ballot approval text was generated |
2018-06-01
|
06 | Deborah Brungard | Ballot writeup was generated |
2018-06-01
|
06 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2018-06-01
|
06 | Deborah Brungard | Last call announcement was generated |
2018-05-25
|
06 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-06.txt |
2018-05-25
|
06 | (System) | New version approved |
2018-05-25
|
06 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Ignas Bagdonas , Andrew Malis |
2018-05-25
|
06 | Stewart Bryant | Uploaded new revision |
2018-05-14
|
05 | Deborah Brungard | Harish Sitaraman will do review for rtgdir. |
2018-05-14
|
05 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2018-05-13
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Harish Sitaraman |
2018-05-13
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Harish Sitaraman |
2018-05-11
|
05 | Deborah Brungard | Requested Last Call review by RTGDIR |
2018-05-11
|
05 | Stewart Bryant | draft-ietf-pals-ethernet-cw-05 Document Shepherd Write-Up (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … draft-ietf-pals-ethernet-cw-05 Document Shepherd Write-Up (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? Standards Track. This is appropriate as the draft describes the use of a protocol extension which is required to avoid packet reordering on Ethernet pseudowires in certain cases, updating RFC4448 in the process. The intended status is properly indicated. (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 The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW an Ethernet pseudowire packet can be misidentified as an IP packet by a label switching router (LSR). This in turn may lead to the selection of the wrong equal-cost-multi- path (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document recommends the use of the Ethernet pseudowire control word in all but exceptional circumstances. This document updates RFC 4448. Working Group Summary The document was developed to try to resolve observed misordering of packets on Ethernet PWs which can occur when ECMP is applied and the packet aliases for and IPv4 or IPv6 packet. Although this problem is already well understood, and a solution (the PW control word) widely implemented and deployed. However the CW was defined as optional in RFC4448 and so there are some cases where it is not implemented or not enabled by operators. There are reports that this is becoming an increasing problem with the IEEEE allocating MAC addresses starting with 0x4 or 0x6, and so stronger recommendations are required. There are no IPR declarations on the draft . Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed on the list over a number of years. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@nokia.com). The responsible Area Director is Deborah Brungard (db3546@att.com). (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 reviewed v05 of the document. I had no significant technical or editorial comments. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has been developed within the WG and reviewed over a period of a number of IETFs, with some in-depth discussions on both the PALS list and in face to face meetings. (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 further review required. (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 specific 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. Each author listed in the Authors Addresses section has personally indicated that they are not aware of any IPR that has not already been declared in accordance with BCP 78 and 79. (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 no IPR declarations on the draft. (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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It received a number of comments and significant discussion prior to WG last call that were addressed by the authors. In particular, these were related to text about the impact of the proposals in the draft on the deployed base. These comments were resolved after live editing sessions with the proponents. (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.) None indicated. (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. ID-Nits passes. There is one warning about pre-RFC5378 work, but I believe that the draft only contains new text. (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 relevant formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. All references are explicitly identified as informative or normative. (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? No (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. (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. This document updates RFC4448. This is listed in the abstract and the document header. (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). There are no IANA actions. (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. There are no IANA actions. (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. There are no sections containing formal language that needs reviewing. |
2018-05-11
|
05 | Stewart Bryant | Responsible AD changed to Deborah Brungard |
2018-05-11
|
05 | Stewart Bryant | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-05-11
|
05 | Stewart Bryant | IESG state changed to Publication Requested |
2018-05-11
|
05 | Stewart Bryant | IESG process started in state Publication Requested |
2018-05-10
|
05 | Matthew Bocci | Changed document writeup |
2018-05-10
|
05 | Matthew Bocci | Changed document writeup |
2018-04-16
|
05 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-05.txt |
2018-04-16
|
05 | (System) | New version approved |
2018-04-16
|
05 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Ignas Bagdonas , Andrew Malis |
2018-04-16
|
05 | Stewart Bryant | Uploaded new revision |
2018-03-20
|
04 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-04.txt |
2018-03-20
|
04 | (System) | New version approved |
2018-03-20
|
04 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Ignas Bagdonas , Andrew Malis |
2018-03-20
|
04 | Stewart Bryant | Uploaded new revision |
2018-03-15
|
03 | Dave Sinicrope | Added to session: IETF-101: pals Mon-1550 |
2018-03-01
|
03 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-03.txt |
2018-03-01
|
03 | (System) | New version approved |
2018-03-01
|
03 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Ignas Bagdonas , Andrew Malis |
2018-03-01
|
03 | Stewart Bryant | Uploaded new revision |
2018-02-28
|
02 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-02.txt |
2018-02-28
|
02 | (System) | New version approved |
2018-02-28
|
02 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Ignas Bagdonas , Andrew Malis |
2018-02-28
|
02 | Stewart Bryant | Uploaded new revision |
2018-02-27
|
01 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-01.txt |
2018-02-27
|
01 | (System) | New version approved |
2018-02-27
|
01 | (System) | Request for posting confirmation emailed to previous authors: Stewart Bryant , Ignas Bagdonas , Andrew Malis |
2018-02-27
|
01 | Stewart Bryant | Uploaded new revision |
2017-09-18
|
00 | Andy Malis | Changed consensus to Yes from Unknown |
2017-09-18
|
00 | Andy Malis | Intended Status changed to Proposed Standard from None |
2017-09-18
|
00 | Andy Malis | Notification list changed to Matthew Bocci <matthew.bocci@nokia.com> |
2017-09-18
|
00 | Andy Malis | Document shepherd changed to Matthew Bocci |
2017-09-18
|
00 | Andy Malis | This document now replaces draft-bryant-pals-ethernet-cw instead of None |
2017-09-18
|
00 | Stewart Bryant | New version available: draft-ietf-pals-ethernet-cw-00.txt |
2017-09-18
|
00 | (System) | WG -00 approved |
2017-09-18
|
00 | Stewart Bryant | Set submitter to "Stewart Bryant ", replaces to (none) and sent approval email to group chairs: pals-chairs@ietf.org |
2017-09-18
|
00 | Stewart Bryant | Uploaded new revision |