Skip to main content

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 …
[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 not a link to RFC7432.
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