Virtual Private Wire Service Support in Ethernet VPN
draft-ietf-bess-evpn-vpws-14
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-04-06
|
14 | (System) | Received changes through RFC Editor sync (added Errata tag) |
|
2021-02-09
|
14 | (System) | Received changes through RFC Editor sync (removed Errata tag (all errata rejected)) |
|
2019-11-20
|
14 | Alvaro Retana | Downref to RFC 7348 approved by Last Call for rfc8214-14 |
|
2018-12-11
|
14 | (System) | Received changes through RFC Editor sync (added Errata tag) |
|
2017-08-24
|
14 | (System) | IANA registries were updated to include RFC8214 |
|
2017-08-23
|
14 | (System) | Received changes through RFC Editor sync (created alias RFC 8214, changed title to 'Virtual Private Wire Service Support in Ethernet VPN', changed abstract to … Received changes through RFC Editor sync (created alias RFC 8214, changed title to 'Virtual Private Wire Service Support in Ethernet VPN', changed abstract to 'This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.', changed pages to 17, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-08-23, changed IESG state to RFC Published) |
|
2017-08-23
|
14 | (System) | RFC published |
|
2017-08-18
|
14 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8214">AUTH48-DONE</a> from AUTH48 |
|
2017-07-21
|
14 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8214">AUTH48</a> from RFC-EDITOR |
|
2017-07-11
|
14 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2017-06-19
|
14 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2017-06-16
|
14 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2017-06-15
|
14 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2017-06-14
|
14 | (System) | IANA Action state changed to In Progress |
|
2017-06-13
|
14 | (System) | RFC Editor state changed to EDIT |
|
2017-06-13
|
14 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2017-06-13
|
14 | (System) | Announcement was received by RFC Editor |
|
2017-06-13
|
14 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2017-06-13
|
14 | Amy Vezza | IESG has approved the document |
|
2017-06-13
|
14 | Amy Vezza | Closed "Approve" ballot |
|
2017-06-13
|
14 | Alvaro Retana | Ballot approval text was generated |
|
2017-06-13
|
14 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2017-05-22
|
14 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
|
2017-05-15
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2017-05-15
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2017-05-15
|
14 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-14.txt |
|
2017-05-15
|
14 | (System) | New version approved |
|
2017-05-15
|
14 | (System) | Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam … Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam <ssalam@cisco.com>, Ali Sajassi <sajassi@cisco.com> |
|
2017-05-15
|
14 | Sami Boutros | Uploaded new revision |
|
2017-05-11
|
13 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
|
2017-05-11
|
13 | Adam Roach | [Ballot comment] From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations … [Ballot comment] From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations are often > called acronyms. Editorial guidelines for the RFC series generally > require expansion of these abbreviations on first occurrence in a > title, in an abstract, or in the body of the document. These guidelines go on to point out which acronyms are common enough not to require expansion on first use. The following acronyms are not considered common, and require expansion on first use *and* in the title (I'm being very careful to cite only those which are *not* expanded on first use, so each of these should be actionable): - VPWS - EVPN - P2P - MAC (which is, itself, ambiguous without an expansion on first use) - PE - CE - L2 - DF - iBGP - eBGP I don't think "encap" is a word. I have not made a complete effort to understand the technical aspects of this document as its acronym use is literally too thick for me to read and comprehend its contents. I presume it is readable to its community of interest (as three implementations already exist); but finding ways to write in prose instead of acronyms where possible would be highly welcome. |
|
2017-05-11
|
13 | Adam Roach | Ballot comment text updated for Adam Roach |
|
2017-05-11
|
13 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
|
2017-05-10
|
13 | Adam Roach | [Ballot discuss] Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is … [Ballot discuss] Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is informational and part of the Independent Submission stream. As I mention in my comments below, I can't fully follow the technical contents of this document, but this seems like a red flag to me and -- as far as I can tell -- it hasn't been discussed yet. It's possible that the reference just ended up in the wrong section (and should actually be informative), but it's not immediately obvious on a casual examination whether that's true. |
|
2017-05-10
|
13 | Adam Roach | [Ballot comment] I strongly second Mirja's comment requesting positive confirmation from the WG that is is collectively aware of the associated IPR declarations. From https://www.rfc-editor.org/materials/abbrev.expansion.txt: … [Ballot comment] I strongly second Mirja's comment requesting positive confirmation from the WG that is is collectively aware of the associated IPR declarations. From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations are often > called acronyms. Editorial guidelines for the RFC series generally > require expansion of these abbreviations on first occurrence in a > title, in an abstract, or in the body of the document. These guidelines go on to point out which acronyms are common enough not to require expansion on first use. The following acronyms are not considered common, and require expansion on first use *and* in the title (I'm being very careful to cite only those which are *not* expanded on first use, so each of these should be actionable): - VPWS - EVPN - P2P - MAC (which is, itself, ambiguous without an expansion on first use) - PE - CE - L2 - DF - iBGP - eBGP I don't think "encap" is a word. I have not made a complete effort to understand the technical aspects of this document as its acronym use is literally too thick for me to read and comprehend its contents. I presume it is readable to its community of interest (as three implementations already exist); but finding ways to write in prose instead of acronyms where possible would be highly welcome. |
|
2017-05-10
|
13 | Adam Roach | Ballot comment and discuss text updated for Adam Roach |
|
2017-05-10
|
13 | Adam Roach | [Ballot discuss] Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is … [Ballot discuss] Looking at the Shepherd write up and the Ballot, I see no mention of the normative reference to RFC 7348, which is informational and part of the Independent Submission stream. As I mention in my comments below, I don't fully follow the technical contents of this document, but this seems like a red flag to me and -- as far as I can tell -- it hasn't been discussed yet. It's possible that the reference just ended up in the wrong section (and should actually be informative), but it's not immediately obvious on a casual examination whether that's true. |
|
2017-05-10
|
13 | Adam Roach | [Ballot comment] From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations … [Ballot comment] From https://www.rfc-editor.org/materials/abbrev.expansion.txt: > It is common in technical writing to abbreviate complex technical terms > by combining the first letters. The resulting abbreviations are often > called acronyms. Editorial guidelines for the RFC series generally > require expansion of these abbreviations on first occurrence in a > title, in an abstract, or in the body of the document. These guidelines go on to point out which acronyms are common enough not to require expansion on first use. The following acronyms are not considered common, and require expansion on first use *and* in the title (I'm being very careful to cite only those which are *not* expanded on first use, so each of these should be actionable): - VPWS - EVPN - P2P - MAC (which is, itself, ambiguous without an expansion on first use) - PE - CE - L2 - DF - iBGP - eBGP I don't think "encap" is a word. I have not made a complete effort to understand the technical aspects of this document as its acronym use is literally too thick for me to read and comprehend its contents. I presume it is readable to its community of interest (as three implementations already exist); but finding ways to write in prose instead of acronyms where possible would be highly welcome. |
|
2017-05-10
|
13 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
|
2017-05-10
|
13 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
|
2017-05-09
|
13 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
|
2017-05-09
|
13 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2017-05-08
|
13 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2017-05-07
|
13 | Warren Kumari | [Ballot comment] [ For -11 / -12 ] This document is very heavy on the acronyms, and could do with some expanding of these -- … [Ballot comment] [ For -11 / -12 ] This document is very heavy on the acronyms, and could do with some expanding of these -- for example, the document starts out with "This document describes how EVPN can be used...". I'm no MPLS VPN person, so much time was spent searching to try figure out what everything meant. I also agree with Spencer's "In multihoming scenarios, both B and P flags MUST NOT be both set. " being hard to parse, and disagree with Acee that is it clear. [ For -13 ] The draft was revised to address Alia's DISCUSS, and also Spencer's "traditional way" and "both B and P flags MUST NOT be both set" comment, but still does not expand EVPN; I also agree with Spencer that it would be helpful to expand P2P on first use. I reread the document and have some additional comments - note that these are are only comments, but I think that they would make the document more readable... 1: Introduction: "that in EVPN terminology would mean a single pair of Ethernet Segments ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing failure and 'Ethernet Segments (ES)' was intended? If not, You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick with one. 1.1: Terminology: "EVI: EVPN Instance." -- Ok, but EVPN is still not defined / referenced. 3.1 EVPN Layer 2 attributes extended community " A PE that receives an update with both B and P flags set MUST treat the route as a withdrawal. If the PE receives a route with both B and P clear, it MUST treat the route as a withdrawal from the sender PE." Do the above 2 sentences say the same thing? It sure sounds like repetition, if not, please explain the difference. If not, removing one would make this less confusing. Figure 3: EVPN-VPWS Deployment Model You use the terms / labels "PSN1", "PSN2" - what are these? "Provider <something> Network"? |
|
2017-05-07
|
13 | Warren Kumari | Ballot comment text updated for Warren Kumari |
|
2017-05-05
|
13 | Alia Atlas | [Ballot comment] Thanks for addressing my Discuss on clarifying the use of VXLAN & that it is the tunneling technology and how it pertains to … [Ballot comment] Thanks for addressing my Discuss on clarifying the use of VXLAN & that it is the tunneling technology and how it pertains to the services supported. ===================== |
|
2017-05-05
|
13 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to Yes from Discuss |
|
2017-05-05
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2017-05-05
|
13 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-13.txt |
|
2017-05-05
|
13 | (System) | New version approved |
|
2017-05-05
|
13 | (System) | Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam … Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam <ssalam@cisco.com>, Ali Sajassi <sajassi@cisco.com> |
|
2017-05-05
|
13 | Sami Boutros | Uploaded new revision |
|
2017-05-03
|
12 | Roni Even | Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
|
2017-04-28
|
12 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
|
2017-04-28
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
|
2017-04-28
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
|
2017-04-28
|
12 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
|
2017-04-28
|
12 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
|
2017-04-28
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-bess-evpn-vpws-12.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-bess-evpn-vpws-12.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the current draft, the authors request the following: IANA has allocated the following EVPN Extended Community sub-type: SUB-TYPE VALUE NAME Reference 0x04 EVPN Layer 2 Attributes [RFCXXXX] Subtype value 0x04 has been registered in the EVPN Extended Community sub-type registry located at: https://www.iana.org/assignments/bgp-extended-communities/ However, the name in the registry is not "EVPN Layer 2 Attributes" but "Layer 2 Extended Community." IANA Question --> which of these two names would the authors like for the sub-type? We understand that the only other action related to the sub-type is to change the reference from the current draft to [ RFC-to-be ]. Second, a new registry is to be created called the EVPN Layer 2 Attributes Control Flags registry. The registry is to be maintained through RFC Required as defined in RFC 5226. IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the list of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? There are initial registrations in the new registry as follows: Control Flag Description Reference -----------+----------------------------------------+----------------- P Advertising PE is the Primary PE. [ RFC-to-be ] B Advertising PE is the Backup PE. [ RFC-to-be ] C Control word [RFC4448] MUST be present. [ RFC-to-be ] The IANA Services Operator understands that these two actions are the only ones 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. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
|
2017-04-28
|
12 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
|
2017-04-14
|
12 | Amy Vezza | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-bess-evpn-vpws@ietf.org, zzhang@juniper.net, aretana@cisco.com, … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-bess-evpn-vpws@ietf.org, zzhang@juniper.net, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" <zzhang@juniper.net>, bess-chairs@ietf.org, bess@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-bess-evpn-vpws-12.txt> (VPWS support in EVPN) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'VPWS support in EVPN' <draft-ietf-bess-evpn-vpws-12.txt> 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 2017-04-28. 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 describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2635/ https://datatracker.ietf.org/ipr/2125/ The document contains these normative downward references. See RFC 3967 for additional information: rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream) |
|
2017-04-14
|
12 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2017-04-14
|
12 | Alvaro Retana | As part of the IESG Evaluation a downref to RFC7348 (an ISE document that describes VXLAN) was introduced. I am then re-running the IETF Last … As part of the IESG Evaluation a downref to RFC7348 (an ISE document that describes VXLAN) was introduced. I am then re-running the IETF Last Call and will place the document back on the IESG Telechat as a returning document. |
|
2017-04-14
|
12 | Alvaro Retana | Telechat date has been changed to 2017-05-11 from 2017-04-27 |
|
2017-04-14
|
12 | Alvaro Retana | Last call was requested |
|
2017-04-14
|
12 | Alvaro Retana | IESG state changed to Last Call Requested from IESG Evaluation - Defer |
|
2017-04-14
|
12 | Alvaro Retana | Last call announcement was generated |
|
2017-04-14
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2017-04-14
|
12 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-12.txt |
|
2017-04-14
|
12 | (System) | New version approved |
|
2017-04-14
|
12 | (System) | Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam … Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam <ssalam@cisco.com>, Ali Sajassi <sajassi@cisco.com> |
|
2017-04-14
|
12 | Sami Boutros | Uploaded new revision |
|
2017-04-12
|
11 | Eric Rescorla | Telechat date has been changed to 2017-04-27 from 2017-04-13 |
|
2017-04-12
|
11 | Eric Rescorla | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
|
2017-04-12
|
11 | Alexey Melnikov | [Ballot comment] I agree with people that the document is rather heavy on acronyms. |
|
2017-04-12
|
11 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
|
2017-04-11
|
11 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
|
2017-04-11
|
11 | Alia Atlas | [Ballot discuss] First, thank you for a clearly written document that contained enough context to trigger my hazy memory of some of the technical details. … [Ballot discuss] First, thank you for a clearly written document that contained enough context to trigger my hazy memory of some of the technical details. My concern is around this paragraph in the Introduction: "The MPLS label value in the Ethernet A-D route can be set to the VXLAN Network Identifier (VNI) for VXLAN encap, and this VNI may have a global scope or local scope per PE and may also be equal to the VPWS service instance identifier set in the Ethernet A-D route. " First, I recognize that folks have implemented and deployed EVPN with VXLAN. That's fine. There is an ISE RFC 7348 that describes VXLAN. Depending on what you (authors, shepherd, AD, WG) decide to do about the rest of my concern, it is likely that this should be normative references - which would be a downref. Second, the paragraph here isn't really adequate to describe how to implement the functionality. I don't see how: a) The ingress PE decides which VNIs it can send based upon the VNI=MPLS_label from the egress. Is there an assumption that VXLAN allows sending all VNIs across the particular VPWS, whether port-based, VLAN-based, etc? b) Is there an assumption that the egress PE-advertised MPLS label also indicates the VNI to be used? That seems like another mode, like the VLAN-based service, except it is perhaps VNI + VLAN-based service? Please don't take this Discuss as a reason to remove the paragraph and the implied functionality. If it's implemented and deployed (and I think it is) - then what I really want is to just have it adequately written down so that others can interoperably implement. The downref to VXLAN should just be a matter of process nuisance (i.e. another IETF Last Call and handling any concerns). |
|
2017-04-11
|
11 | Alia Atlas | [Ballot comment] 1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or "This specification" or... 2) Sec 3.1: " C … [Ballot comment] 1) (Nit) Sec 3.1 "This draft" for an RFC should be "This document" or "This specification" or... 2) Sec 3.1: " C If set to 1, a Control word [RFC4448] MUST be present when sending EVPN packets to this PE." Given discussions with IEEE about real MACs starting with 4 and 6 in top nibble, adding a statement about it being BCP to include the control word (unless using Entropy Label) would be a good idea. |
|
2017-04-11
|
11 | Alia Atlas | [Ballot Position Update] New position, Discuss, has been recorded for Alia Atlas |
|
2017-04-11
|
11 | Kathleen Moriarty | [Ballot comment] I'm interested to see the response to Mirja's comment #4. Glad to see #1 is okay. |
|
2017-04-11
|
11 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
|
2017-04-11
|
11 | Alissa Cooper | [Ballot comment] From Roni's Gen-ART review: Nits/editorial comments: In section 1 second paragraph "[RFC7432] provides the ability " looks like the reference is … |
|
2017-04-11
|
11 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
|
2017-04-11
|
11 | Mirja Kühlewind | [Ballot comment] The shepherd write-up says: "Two IPR discussions from Juniper & Cisco respectively: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws Haven't seen WG discussion on that." Can we confirm that … [Ballot comment] The shepherd write-up says: "Two IPR discussions from Juniper & Cisco respectively: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws Haven't seen WG discussion on that." Can we confirm that the wg is aware of the IPRs before publication? Other minor comments: 1) Agree with Warren that all the acronyms make it hard to read. Please check that you've spelled out all acronyms at the first occurrence in the intro accordingly, including EVPN. 2) section 3.1: Is the B flag even needed? Doesn't P=0 indicate that this is the Backup PE? 3) I would maybe move section 5 right after the intro because it provides some background on the benefits of this extension. 4) Are you sure there are no additional security consideration based on the information provided in this extension? E.g. an attacker indicates being the primary PE and thereby causes a conflict, or problems based on the indication of a small MTU by an attacker? Not sure if there is any risk or if that is covered somewhere else...? |
|
2017-04-11
|
11 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
|
2017-04-11
|
11 | Mirja Kühlewind | [Ballot comment] Minor comments: 1) Agree with Warren that all the acronyms make it hard to read. Please check that you've spelled out all acronyms … [Ballot comment] Minor comments: 1) Agree with Warren that all the acronyms make it hard to read. Please check that you've spelled out all acronyms at the first occurrence in the intro accordingly, including EVPN. 2) section 3.1: Is the B flag even needed? Doesn't P=0 indicate that this is the Backup PE? 3) I would maybe move section 5 right after the intro because it provides some background on the benefits of this extension. 4) Are you sure there are no additional security consideration based on the information provided in this extension? E.g. an attacker indicates being the primary PE and thereby causes a conflict, or problems based on the indication of a small MTU by an attacker? Not sure if there is any risk or if that is covered somewhere else...? |
|
2017-04-11
|
11 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
|
2017-04-08
|
11 | Roni Even | Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
|
2017-04-08
|
11 | Warren Kumari | [Ballot comment] This document is very heavy on the acronyms, and could do with some expanding of these -- for example, the document starts out … [Ballot comment] This document is very heavy on the acronyms, and could do with some expanding of these -- for example, the document starts out with "This document describes how EVPN can be used...". I'm no MPLS VPN person, so much time was spent searching to try figure out what everything meant. I also agree with Spencer's "In multihoming scenarios, both B and P flags MUST NOT be both set. " being hard to parse, and disagree with Acee that is it clear. |
|
2017-04-08
|
11 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
|
2017-04-07
|
11 | Spencer Dawkins | [Ballot comment] I did have some non-Discuss questions that you might wish to think about before the document is approved ... In the Abstract … [Ballot comment] I did have some non-Discuss questions that you might wish to think about before the document is approved ... In the Abstract This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. everything is exceptionally clear, except that I don't know what the "traditional way" of signaling means. The same phrase appears in Section 1 Introduction This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. The use of EVPN mechanisms for VPWS (EVPN-VPWS) brings the benefits of EVPN to P2P services. These benefits include single-active redundancy as well as all-active redundancy with flow-based load-balancing. Furthermore, the use of EVPN for VPWS eliminates the need for traditional way of PW signaling for P2P Ethernet services, as described in section 4. with the addition of "as described in section 4", but I didn't see an explicit statement in Section 4 that explained what was replacing the "traditional way". Even a clear reference to an RFC where the "traditional way" was defined would be helpful. It would probably be helpful to expand acronums like "P2P" on first use. I immediately thought "peer to peer?" but I bet you didn't mean that. Yes, there's a terminology section, but it's three and a half pages into the document. In this text, For EVPL service, the Ethernet frames transported over an MPLS/IP network SHOULD remain ^^^^^^ tagged with the originating VLAN-ID (VID) and any VID translation MUST be performed at the disposition PE. why is this a SHOULD? I guess my first question should be "does this still work if you don't?" In this text, In multihoming scenarios, both B and P flags MUST NOT be both set. the double both(s) made this difficult to parse. Is it saying In multihoming scenarios, the B and P flags MUST be cleared. or something else? But I'm guessing, and the rest of that paragraph made me doubt my guesses. |
|
2017-04-07
|
11 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
|
2017-04-06
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
|
2017-04-06
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
|
2017-03-15
|
11 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2017-03-13
|
11 | Matthew Miller | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Matthew Miller. Sent review to list. |
|
2017-03-13
|
11 | Alvaro Retana | Changed consensus to Yes from Unknown |
|
2017-03-13
|
11 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2017-03-13
|
11 | Alvaro Retana | Ballot has been issued |
|
2017-03-13
|
11 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
|
2017-03-13
|
11 | Alvaro Retana | Created "Approve" ballot |
|
2017-03-13
|
11 | Alvaro Retana | Ballot writeup was changed |
|
2017-03-12
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
|
2017-03-12
|
11 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-11.txt |
|
2017-03-12
|
11 | (System) | New version approved |
|
2017-03-12
|
11 | (System) | Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam … Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam <ssalam@cisco.com>, Ali Sajassi <sajassi@cisco.com> |
|
2017-03-12
|
11 | Sami Boutros | Uploaded new revision |
|
2017-03-10
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2017-03-07
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2017-03-07
|
10 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-bess-evpn-vpws-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-bess-evpn-vpws-09. If any part of this review is inaccurate, please let us know. Upon this document's approval by the IESG, we understand that this document will have two actions for the IANA Services Operator. We have questions about the second action. First, we'll update the following EVPN Extended Community Sub-Type registration (https://www.iana.org/assignments/bgp-extended-communities) to point to the most recent version of this document: 0x04 Layer 2 Extended Community [this document] Second, we'll create the following registry: Registry Name: EVPN Layer 2 attributes Control Flags Registration Procedure: RFC Required Reference: [this document] Value Description Reference P Advertising PE is the Primary PE. [this document] B Advertising PE is the Backup PE. [this document] C Control word [RFC4448] MUST be present [this document] QUESTION: Where should this registry be created? Does it belong at an existing URL, or does it need a new registry page? If the latter, what should be the name of the page? QUESTIONS: In the name "EVPN Layer 2 attributes Control Flags," should "attributes" be capitalized? Should the description for the third registration also end with a period? 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. Thank you, Amanda Baber Lead IANA Services Specialist PTI |
|
2017-03-06
|
10 | Roni Even | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list. |
|
2017-03-05
|
10 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Acee Lindem. |
|
2017-03-02
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
|
2017-03-02
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
|
2017-03-02
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matthew Miller |
|
2017-03-02
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Matthew Miller |
|
2017-02-28
|
10 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-10.txt |
|
2017-02-28
|
10 | (System) | New version approved |
|
2017-02-28
|
10 | (System) | Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam … Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam <ssalam@cisco.com>, Ali Sajassi <sajassi@cisco.com> |
|
2017-02-28
|
10 | Sami Boutros | Uploaded new revision |
|
2017-02-27
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Lionel Morand |
|
2017-02-27
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Lionel Morand |
|
2017-02-24
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
|
2017-02-24
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
|
2017-02-24
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2017-02-24
|
09 | Amy Vezza | The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-bess-evpn-vpws@ietf.org, zzhang@juniper.net, aretana@cisco.com, … The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-bess-evpn-vpws@ietf.org, zzhang@juniper.net, aretana@cisco.com, "Zhaohui \(Jeffrey\) Zhang" <zzhang@juniper.net>, bess-chairs@ietf.org, bess@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-bess-evpn-vpws-09.txt> (VPWS support in EVPN) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'VPWS support in EVPN' <draft-ietf-bess-evpn-vpws-09.txt> 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 2017-03-10. 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 describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of PW signaling, and provides fast protection convergence upon node or link failure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2635/ https://datatracker.ietf.org/ipr/2125/ |
|
2017-02-24
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2017-02-24
|
09 | Alvaro Retana | Requested Last Call review by RTGDIR |
|
2017-02-24
|
09 | Alvaro Retana | Placed on agenda for telechat - 2017-04-13 |
|
2017-02-24
|
09 | Alvaro Retana | Last call was requested |
|
2017-02-24
|
09 | Alvaro Retana | Ballot approval text was generated |
|
2017-02-24
|
09 | Alvaro Retana | Ballot writeup was generated |
|
2017-02-24
|
09 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
|
2017-02-24
|
09 | Alvaro Retana | Last call announcement was generated |
|
2017-02-21
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2017-02-21
|
09 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-09.txt |
|
2017-02-21
|
09 | (System) | New version approved |
|
2017-02-21
|
09 | (System) | Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam … Request for posting confirmation emailed to previous authors: Sami Boutros <sboutros@vmware.com>, John Drake <jdrake@juniper.net>, Jorge Rabadan <jorge.rabadan@nokia.com>, Samer Salam <ssalam@cisco.com>, Ali Sajassi <sajassi@cisco.com> |
|
2017-02-21
|
09 | Sami Boutros | Uploaded new revision |
|
2017-02-16
|
08 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
|
2017-02-07
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2017-02-07
|
08 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-08.txt |
|
2017-02-07
|
08 | (System) | New version approved |
|
2017-02-07
|
08 | (System) | Request for posting confirmation emailed to previous authors: "Jorge Rabadan" <jorge.rabadan@nokia.com>, "John Drake" <jdrake@juniper.net>, "Samer Salam" <ssalam@cisco.com>, "Sami Boutros" … Request for posting confirmation emailed to previous authors: "Jorge Rabadan" <jorge.rabadan@nokia.com>, "John Drake" <jdrake@juniper.net>, "Samer Salam" <ssalam@cisco.com>, "Sami Boutros" <sboutros@vmware.com>, "Thomas Beckhaus" <thomas.beckhaus@telekom.de>, " jefftant@gmail.com" <jefftant@gmail.com>, "Ali Sajassi" <sajassi@cisco.com>, bess-chairs@ietf.org, "Dirk Steinberg" <dws@steinbergnet.net> |
|
2017-02-07
|
08 | Sami Boutros | Uploaded new revision |
|
2017-01-25
|
07 | Alvaro Retana | === AD Review of draft-ietf-bess-evpn-vpws-07 === I just finished reading this document. Please take a look at my comments below – I think they should … === AD Review of draft-ietf-bess-evpn-vpws-07 === I just finished reading this document. Please take a look at my comments below – I think they should be easy to resolve. I will start the IETF Last Call when the comments have been addressed and a new revision has been published. Thanks! Alvaro. Major: M1. There are 8 authors listed on the front page. Following the guidelines in the RFC Style Guide [RFC7322], we want the list to be at most 5. Please work among yourselves to reduce the number of authors. Alternatively, you can just list an Editor or two. M2. From the Introduction: “Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero…in EVPN-VPWS, Ethernet tag ID in the Ethernet A-D route MUST be set to a valid value in all the service interface types.” Zero is a valid value for the Ethernet Tag ID. Section 3. (BGP Extensions) says that “the Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance identifier”, but I couldn’t find a place where the document told me what a valid value is. IOW, how can the “MUST” be enforced if there’s no clear indication of what is valid? OTOH, any specification wants the fields to contain valid values, obviously! What happens if the value is not valid? BTW, all this is to say that without a proper explanation (which probably doesn’t belong in the Introduction), the whole paragraph is superfluous. M3. The Introduction says that “For EVPL service, the Ethernet frames transported over an MPLS/IP network SHOULD remain tagged with the originating VID and any VID translation is performed at the disposition PE.”, later the same (or at least something similar) is mentioned in Section 2.1. (VLAN-Based Service Interface): “the Ethernet frames transported over an MPLS/IP network SHOULD remain tagged with the originating VID, and a VID translation MUST be supported in the data path and MUST be performed on the disposition PE.” Please keep the normative language in one place – I am not fond of normative language in the Introduction; note that even though the result should be the same, the text is different (the “MUSTs” are used in 2.1). M3.1. [minor] It is not clear in the text that EVPL service corresponds to VLAN-based service. Please clarify that. In fact, some of the flow of the document feel disjoint because slightly different terminology is used and no hint of how it all ties together is presented; mapping EPL/EVPL to the Service Interfaces, which are only mentioned in Section 2 (and very briefly in the Introduction – see M2). M4. Section 1.2 is titled Requirements. However, the list seems to include a combination of statements of fact (“EPL service access circuit maps to the whole Ethernet port”: this is pretty much the definition of EPL), solution-sounding lines (“Each VLAN individually (or <S-VLAN,C-VLAN> combination) will be considered to be an endpoint for an EVPL service”: not only does it sound like what the solution will do, but it is also the definition of EVPL), and statements that talk to the configuration and not what the technical solution described later can do (“A given PE could have thousands of EVPLs configured. It must be possible to configure multiple EVPL services within the same EVI.”: is there an actual scalability requirement?). I would have expected actual requirements (for example: “EPL service access circuits MUST map to the whole Ethernet port”; normative language is not required) that I can then check against the solution – but it all sounds like a rehash of what was explained before. L M5. Section 3. (BGP Extensions) says that “This document proposes the use of the per EVI Ethernet A-D route to signal VPWS services. The Ethernet Segment Identifier field is set to the customer ES and the Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance identifier.” First of all [this is minor/a nit], if this document intends to be in the Standards Track then it is past the “proposing” phase, it is *specifying*. As a specification, it is rather weak in some places; for example, RFC7432 says (as an example) that the “Ethernet Tag ID in all EVPN routes MUST be set to 0”: that is a strong statement of what is expected. On the other hand, this document is modifying the behavior, but no Normative language is used. [In general I don’t advocate for the use of Normative language everywhere, but in cases like this where the behavior is being changed from the base spec when using this extension, it seems necessary.] M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance identifier” How should this be aligned into the larger field? M6. Section 3.1 (EVPN Layer 2 attributes extended community). M6.1. For the P flag – “SHOULD be set to 1 for multihoming all-active scenarios”: in a multihoming all-active scenario, when would this flag not be set? IOW, why is the “SHOULD” not a “MUST”. A couple of paragraphs later: “…the PEs in the ES that are active and ready to forward traffic to/from the CE will set the P bit to 1”. In the all-active scenario, is there a case where a PE would not be “active and ready”? What does that mean? Clarifying may justify the “SHOULD”. M6.2. How should the other flags in the Control Flags field be assigned? Please define a new registry and include the details in the IANA Considerations section. M6.3. What should a remote PE do if it receives both the P and B flags set (or both unset)? I know that in a single-active scenario they should not be on at the same time…but what should the receiver do? M6.4. What happens if the B flag is set in the all-active scenario? I know there was some discussion about this on the list – the document needs to explicitly talk about it. M6.5. What units is the MTU in? How is it encoded? M6.6. “non-zero MTU SHOULD be checked against local MTU” When is it ok not to check? I’m wondering why this “SHOULD” is not a “MUST”, specially because the result of that check is a “MUST NOT”. M6.7. “As per [RFC6790]…the control word (C bit set) SHOULD NOT be used…” Where in RFC6790 does it say that? I searched for “control word”, but found nothing? Also, this “SHOULD NOT” is in conflict with the definition of the C flag: “If set to 1, a Control word [RFC4448] MUST be present…” Minor: P1. Please add a reference for VPWS. P2. The [MEF] reference didn’t work for me; on all tries the connection timed out. Is it possible to find a more stable reference? P3. There are several acronyms that won’t be familiar to the average reader and that need to be expanded on first use: ES, AD (A-D), EVI, VID, VNI, EP-LAN, EVP-LAN. I know that some of these are expanded in the Terminology Section, but in some cases that comes later in the text. P4. The EVPN-VPWS term is introduced for the first time in the text at the bottom of page 3. I take it that it refers to the solution presented in this document. Please include a sentence at the top of the introduction to clarify – note that this tag could be useful in other places as well. P5. “Ethernet tag field” (and not “Ethernet Tag ID”, which I’m assuming is the same thing) is used in several parts of the text. Please be consistent. P6. “VxLAN encap” is mentioned in the Introduction, and potential things about handling it…but there are no references and no additional mention anywhere else in the document. P7. “mass withdraw” is mentioned in the Introduction (“…can be used for flow-based load-balancing and mass withdraw functions”), in Section 4 (“…can be used for mass withdraw”), and finally Section 6.2 (the last section in the draft!) has a reference… Please move it earlier in the document. P8. S-VLAN, C-VLAN: expand and put a reference for them. P9. There is no Reference to any of the Extended Communities RFCs: 4360, 7153, etc… P10. Please add Figure numbers/names. P11. Section 3.1 (EVPN Layer 2 attributes extended community) defines 3 control *flags*, but they are referred to later in the text as “bits”. Please be consistent. P12. Section 4 (Operation): s/with Next Hop attribute set/with the NEXT_HOP attribute set Also, include an Informative reference to RFC4271. P13. Section 6 (Failure Scenarios): “…the PE must withdraw all the associated Ethernet AD routes…” Should that be a “MUST”? P14. A reference to “[ietf-evpn-overlay]” appears in the Security Considerations, but there’s no Reference later on. Nits: N1. “Both services are supported by using…I.e., for both EPL and EVPL services…” The second part of that explanation is a lot clearer, you might want to simplify by just leaving that part in. N2. The introduction reads like a rushed summary of the solution, which results in potentially confusing text. Suggestion: focus the Introduction on setting the stage/background – if you want to provide a summary of the solution (good idea!), then do it after the requirements. N3. s/Ethernet Segment on a PE refer to/Ethernet Segment on a PE refers to N4. s/multi home…single home/multi homed…single homed N5. The text in Section 9 is misaligned. |
|
2017-01-25
|
07 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
|
2016-12-20
|
07 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
|
2016-12-20
|
07 | Alvaro Retana | Notification list changed to "Zhaohui (Jeffrey) Zhang" <zzhang@juniper.net>, aretana@cisco.com from "Zhaohui (Jeffrey) Zhang" <zzhang@juniper.net> |
|
2016-10-11
|
07 | Martin Vigoureux | (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? Standards track, as indicated in the page header. It is appropriate because it specifies standard procedures for setting up PWs using EVPN based procedures. Implementations must follow the same procedures to be inter-operable. (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 document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of PW signaling, and provides fast protection convergence upon node or link failure. Working Group Summary This document is a BESS Working Group document, and has gone through WG adoption, WG LC processes. Document Quality Revisions -4~-07 addressed a few issues raised by the document shepherd. The shepherd agrees with co-authors that it is now solid, mature and ready for publication. Juniper supports VPWS all-active and single-active redundancy modes with sub-second recovery on egress link failure. Cisco has implemented EVPN-VPWS based on this document and it has been available since H2/2015. Nokia also has a full implementation, Personnel Document Shepherd: Jeffrey Zhang (zzhang@juniper.net) Responsible Area Director: Alvaro Retana (aretana@cisco.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. Revisions -4~-07 addressed a few issues raised by the document shepherd. The shepherd agrees with co-authors that it is now solid, mature and ready for publication. (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. (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. BESS co-chair Martin confirms that all co-authors have stated "unaware of undisclosured IPR": https://mailarchive.ietf.org/arch/msg/bess/sjtCEy5F34eqWjmoH5bWLwwJieI (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Two IPR discussions from Juniper & Cisco respectively: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws Haven't seen WG discussion on that. (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? draft-boutros-l2vpn-evpn-vpws-00 was published on 6/30/2012. Over the course of four years public discussions have been mostly among the co-authors and Jim Uttaro, Wim Henderickx and Jeffrey Zhang. This is not unusual for BESS documents. The document is solid and mature. (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. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Thorough idnits check did not show problem. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (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? 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. No. (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 draft has a reference for an already allocated code-point in FCFS range of the EVPN Extended Community Sub-Types: http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn Therefore this documents only asks IANA to update the reference so that it be this RFC if and when published. Note that currently the referred to entry is "0x04 Layer 2 Extended Community" but it should be corrected to "EVPN Layer 2 attributes" in the registry (not the draft/rfc). (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. N/A. (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. N/A. |
|
2016-10-11
|
07 | Martin Vigoureux | Responsible AD changed to Alvaro Retana |
|
2016-10-11
|
07 | Martin Vigoureux | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2016-10-11
|
07 | Martin Vigoureux | IESG state changed to Publication Requested |
|
2016-10-11
|
07 | Martin Vigoureux | IESG process started in state Publication Requested |
|
2016-10-11
|
07 | Martin Vigoureux | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway cleared. |
|
2016-10-11
|
07 | Martin Vigoureux | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
|
2016-10-11
|
07 | Zhaohui Zhang | Changed document writeup |
|
2016-07-21
|
07 | Zhaohui Zhang | Changed document writeup |
|
2016-07-05
|
07 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-07.txt |
|
2016-06-22
|
06 | Zhaohui Zhang | Changed document writeup |
|
2016-06-22
|
06 | Zhaohui Zhang | Changed document writeup |
|
2016-06-22
|
06 | Zhaohui Zhang | Changed document writeup |
|
2016-06-22
|
06 | Zhaohui Zhang | Changed document writeup |
|
2016-06-20
|
06 | Martin Vigoureux | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set. |
|
2016-06-20
|
06 | Martin Vigoureux | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2016-06-07
|
06 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-06.txt |
|
2016-06-07
|
05 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-05.txt |
|
2016-06-06
|
04 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-04.txt |
|
2016-05-10
|
03 | Martin Vigoureux | Notification list changed to "Zhaohui (Jeffrey) Zhang" <zzhang@juniper.net> |
|
2016-05-10
|
03 | Martin Vigoureux | Document shepherd changed to Zhaohui (Jeffrey) Zhang |
|
2016-05-09
|
03 | Martin Vigoureux | Changed document writeup |
|
2016-05-09
|
03 | Martin Vigoureux | IETF WG state changed to In WG Last Call from WG Document |
|
2016-03-16
|
03 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-03.txt |
|
2015-10-15
|
02 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-02.txt |
|
2015-07-14
|
Naveen Khan | Posted related IPR disclosure: Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-bess-evpn-vpws | |
|
2015-06-29
|
01 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-01.txt |
|
2015-02-02
|
00 | Thomas Morin | Intended Status changed to Proposed Standard from None |
|
2015-02-02
|
00 | Thomas Morin | This document now replaces draft-boutros-l2vpn-evpn-vpws instead of None |
|
2015-01-30
|
00 | Sami Boutros | New version available: draft-ietf-bess-evpn-vpws-00.txt |