Skip to main content

Requirements for Ethernet VPN (EVPN)
RFC 7209

Revision differences

Document history

Date Rev. By Action
2022-10-13
07 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2022-10-12
07 (System) Received changes through RFC Editor sync (added Errata tag)
2017-05-16
07 (System) Changed document authors from "Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac" to "Wim Henderickx, Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac, Jim Uttaro"
2015-10-14
07 (System) Notify list changed from l2vpn-chairs@ietf.org, draft-ietf-l2vpn-evpn-req@ietf.org to (None)
2014-05-21
07 (System) RFC published
2014-05-21
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-04-07
07 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-04-07
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-03-07
07 Adrian Farrel Shepherding AD changed to Adrian Farrel
2014-02-19
07 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-02-19
07 (System) RFC Editor state changed to EDIT
2014-02-19
07 (System) Announcement was received by RFC Editor
2014-02-17
07 (System) IANA Action state changed to No IC from In Progress
2014-02-17
07 (System) IANA Action state changed to In Progress
2014-02-17
07 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2014-02-17
07 Cindy Morgan IESG has approved the document
2014-02-17
07 Cindy Morgan Closed "Approve" ballot
2014-02-17
07 Cindy Morgan Ballot approval text was generated
2014-02-17
07 Cindy Morgan Ballot writeup was changed
2014-02-07
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-02-07
07 Ali Sajassi IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-02-07
07 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-07.txt
2014-02-02
06 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-01-30
06 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2014-01-23
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tina Tsou
2014-01-23
06 Tero Kivinen Request for Telechat review by SECDIR is assigned to Tina Tsou
2014-01-23
06 Cindy Morgan State changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2014-01-23
06 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-01-23
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2014-01-23
06 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-01-23
06 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2014-01-22
06 Spencer Dawkins
[Ballot comment]
This draft was easy to read and quite clear, with a couple of exceptions. Please consider these comments along with any other comments …
[Ballot comment]
This draft was easy to read and quite clear, with a couple of exceptions. Please consider these comments along with any other comments you receive.

In 4.3.  Geo-redundant PE Nodes

  (R3b) A solution MUST NOT assume that the IGP cost from a remote PE
  to each of the PEs in the multi-homed group is the same.

I'm guessing how to read "MUST NOT assume". Is it saying something like this?

  (R3b) A solution MUST support different IGP costs from a remote PE
  to each of the PEs in a multi-homed group.

In 6. Ease of Provisioning Requirements

  Implementations SHOULD revert to using default values for parameters
  as and where applicable.

I'm not clear on how I would know that an implementation is reverting "as and where applicable". Is there any guidance about that you could include?

I'm also supportive of comments made by Adrian and Barry (well, actually, "the other ADs").
2014-01-22
06 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-01-22
06 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-01-22
06 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-01-21
06 Vijay Gurbani Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Vijay Gurbani.
2014-01-21
06 Benoît Claise
[Ballot comment]
- I'm very surprised not to see any operational requirements, like OAM and fault.
Can you please justify why you omitted those? (no …
[Ballot comment]
- I'm very surprised not to see any operational requirements, like OAM and fault.
Can you please justify why you omitted those? (no objection on this point for now)

- The IESG recently reviewed a L2VPN requirements doc, "Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in L2VPN", draft-ietf-l2vpn-etree-reqt: I don't quite get the link between the two documents: complimentary, cover different use cases, overlapping, etc.?

- 4.5. Flexible Redundancy Grouping Support

  (R5) In order to simplify service provisioning and activation, the
  multi-homing mechanism SHOULD allow arbitrary grouping of PE nodes
  into redundancy groups where each redundancy group represents all
  multi-homed groups that share the same group of PEs.

  This is best explained with an example: consider three PE nodes -
  PE1, PE2 and PE3. The multi-homing mechanism MUST allow a given PE,
  say PE1, to be part of multiple redundancy groups concurrently. For
  example, there can be a group (PE1, PE2), a group (PE1, PE3), and
  another group (PE2, PE3) where CEs could be multi-homed to any one of
  these three redundancy groups.

I don't understand "in order to simplify service provisioning and activation" as a justification for this requirement.
As the title says, it's about flexibility.
If it's really about "simplify service provisioning", then it should be in section 6

- Agreed with Barry on the MAY in a requirements document
2014-01-21
06 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-01-21
06 Jari Arkko [Ballot comment]
Vijay Gurbani raised an issue with R13 and R14 that I thought had merit. Should this result in some edits?
2014-01-21
06 Jari Arkko Ballot comment text updated for Jari Arkko
2014-01-21
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-01-21
06 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-01-21
06 Martin Stiemerling
[Ballot comment]
Just a curiosity question from the Transport Area side of life:

Section 4.1., paragraph 2:

>    i.  Layer 2: Source MAC Address, …
[Ballot comment]
Just a curiosity question from the Transport Area side of life:

Section 4.1., paragraph 2:

>    i.  Layer 2: Source MAC Address, Destination MAC Address, VLAN
>    ii.  Layer 3: Source IP Address, Destination IP Address
>    iii. Layer 4: UDP or TCP Source Port, Destination Port

Has SCTP  ever been considered for Flow-based Load Balancing in the scope of this draft? I know that SCTP is not that heavily used by now, but this could change in the near future, especially when it comes to data centers.
2014-01-21
06 Martin Stiemerling Ballot comment text updated for Martin Stiemerling
2014-01-21
06 Martin Stiemerling
[Ballot comment]
Just a curiosity question from the Transport Area side of life:

Section 4.1., paragraph 2:

>    i.  Layer 2: Source MAC Address, …
[Ballot comment]
Just a curiosity question from the Transport Area side of life:

Section 4.1., paragraph 2:

>    i.  Layer 2: Source MAC Address, Destination MAC Address, VLAN
>    ii.  Layer 3: Source IP Address, Destination IP Address
>    iii. Layer 4: UDP or TCP Source Port, Destination Port

Has SCTP been ever considered for Flow-based Load Balancing in the scope of this draft? I know that SCTP is not that heavily used by now, but this could change in the near future, especially when it comes to data centers.
2014-01-21
06 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-01-21
06 Barry Leiba
[Ballot comment]
Minor editorial point: The Introduction reads oddly to me, with four paragraphs in a row that all start with some version of "also": …
[Ballot comment]
Minor editorial point: The Introduction reads oddly to me, with four paragraphs in a row that all start with some version of "also": "Furthermore," "Also," "In addition," and "Moreover."  I think you can just delete them all, really.

(R1c), and others: I'm always skeptical of "MAY" in protocols, but I *really* wonder about it in requirements.  What does it mean to say that a solution MAY support something?  That seems to me to be entirely a non-requirement.

(R3d), and others: Favourable comment here... As Adrian does, I always think it's important to explain SHOULDs, and especially so when SHOULD is used in requirements.  Unlike Adrian, though, I think the explanatory text in each section does this quite well; thanks.
2014-01-21
06 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-01-20
06 Adrian Farrel
[Ballot comment]
Thank you for writing an important document for guiding the future
standards development in this area. I have no objection to its
publication, …
[Ballot comment]
Thank you for writing an important document for guiding the future
standards development in this area. I have no objection to its
publication, but I found a small list of nits you may wish to fix
before proceeding.

===

The RFC Editor will want to move the Introduction to be the first
section in the document. If you are revising this document, you might
want to take care of that yourselves to make sure that no errors are
introduced when it happens.

---

This is a good example of when use of upper case words is useful to
emphasize the reuirements language, but you are not using them in the
sense of RFC 2119. in such cases it is common to vary the bolierplate
to say something like:

  Although this is not a protocol specification, the key words "MUST",
  "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
  "RECOMMENDED", "MAY", and "OPTIONAL" in this document are used for
  clarity and emphasis of requirements language and are to be
  interpreted as described in [RFC2119].

However, I think you should limit your use of this language to within
the text of the requirements themselves. For example, look at the first
paragraph of Section 4.2: here is is unclear whether the text is stating
requirements or guiding the requirements that will be stated later (R2).

You may also want to think about the meaning of "SHOULD" in a
requirement. Under what circumstances are the developers of a solution
allowed to discard this requirement?

---

H-VPLS, VPWS and VLAN need to be expanded on first use.

---

The concept of "redundancy group" could do with fuller introduction
maybe by giving it an entry of its own in Section 2.

Similarly, "multi-home group" is used in Section 4 in a way that its
meaning can be deduced, but there is no formal definition.

---

  (R2) A solution MUST be able to exercise as many ECMP paths as
  possible between any pair of PEs in conjunction with the all-active
  load-balancing described above.

Forgive my pedantry, but "as many as possible" is open to willful
misinterpretation. I think you want

  (R2) A solution MUST be able to exercise all ECMP paths between any
  pair of PEs in conjunction with the all-active load-balancing
  described above.

---

Section 4.3

  The
  latter is desirable when offering a geo-redundant solution that
  ensures business continuity for critical applications in the case of
  power outages, natural disasters, etc.

In fact, it is more than "desirable", it is part of the definition of
geo-redundancy, isn't it?

---

Section 4.4

s/R4:/(R4)/

---

Section 4.6

Readers may find the first sentence ambiguous...

  There are applications, which require an Ethernet network, rather
  than a single device, to be multi-homed to a group of PEs.

I think...
s/which/that/
It is the network that is multi-homed not the the single device.
But I may have this wrong. Think about rewording it?

---

Section 5 lines 1, 4, and 8

s/usage/use/

---

Section 6

  Implementations SHOULD revert to using default values for parameters
  as and where applicable.

Not clear whether this is part of R6e, R6f in its own right, or general
discriptive text.

"As and where applicable" may be considered by an implementer as an
easy way out of having to do anything! You might want to constrain them
by making a statement of that applicability in your document.

---

Section 7

  It is worth noting that the term 'bridge domain' as used above refers
  to a MAC forwarding table as defined in the IEEE bridge model, and
  does not denote or imply any specific implementation.

A reference for the "IEEE bridge model" would be nice.

---

Section 7

It looks to me that this section includes a number of specific
requirements that have not been numbered. It would be helpful to call
these out explicitly to distinguish them from the descriptive text.

---

Section 9 appears to have a number of requirements that are not
specifically called out as numbered requirements.

---

Section 10

s/(R12)/(R12a)/

---

I would move Section 11 down so that the requirements in Section 12 are
not orphaned.
2014-01-20
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-01-16
06 Jean Mahoney Request for Telechat review by GENART is assigned to Vijay Gurbani
2014-01-16
06 Jean Mahoney Request for Telechat review by GENART is assigned to Vijay Gurbani
2014-01-16
06 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-01-16
06 Stewart Bryant Placed on agenda for telechat - 2014-01-23
2014-01-16
06 Stewart Bryant State changed to IESG Evaluation from Waiting for Writeup::AD Followup
2014-01-16
06 Stewart Bryant Ballot has been issued
2014-01-16
06 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2014-01-16
06 Stewart Bryant Created "Approve" ballot
2014-01-16
06 Stewart Bryant Ballot writeup was changed
2014-01-16
06 Stewart Bryant Changed consensus to Yes from Unknown
2013-12-11
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-12-11
06 Ali Sajassi IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-12-11
06 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-06.txt
2013-12-11
05 Stewart Bryant Editor addressing some security comments - new version expected soon
2013-12-11
05 Stewart Bryant State changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup
2013-11-29
05 Stewart Bryant Authors need to respond on security review
2013-11-29
05 Stewart Bryant State changed to Waiting for Writeup::AD Followup from Waiting for Writeup
2013-11-28
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tina Tsou.
2013-11-27
05 (System) State changed to Waiting for Writeup from In Last Call (ends 2013-11-27)
2013-11-14
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-11-14
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-11-14
05 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l2vpn-evpn-req-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l2vpn-evpn-req-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.
2013-11-11
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Rob Austein
2013-11-11
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Rob Austein
2013-10-31
05 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2013-10-31
05 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2013-10-31
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2013-10-31
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2013-10-30
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-10-30
05 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Requirements for Ethernet VPN (EVPN)) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Requirements for Ethernet VPN (EVPN)) to Informational RFC


The IESG has received a request from the Layer 2 Virtual Private Networks
WG (l2vpn) to consider the following document:
- 'Requirements for Ethernet VPN (EVPN)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The widespread adoption of Ethernet L2VPN services and the advent of
  new applications for the technology (e.g., data center interconnect)
  have culminated in a new set of requirements that are not readily
  addressable by the current Virtual Private LAN Service (VPLS)
  solution. In particular, multi-homing with all-active forwarding is
  not supported and there's no existing solution to leverage
  Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of
  multi-destination frames. Furthermore, the provisioning of VPLS, even
  in the context of BGP-based auto-discovery, requires network
  operators to specify various network parameters on top of the access
  configuration. This document specifies the requirements for an
  Ethernet VPN (EVPN) solution which addresses the above issues.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn-req/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn-req/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-10-30
05 Amy Vezza State changed to In Last Call from Last Call Requested
2013-10-30
05 Stewart Bryant Last call was requested
2013-10-30
05 Stewart Bryant Ballot approval text was generated
2013-10-30
05 Stewart Bryant Ballot writeup was generated
2013-10-30
05 Stewart Bryant State changed to Last Call Requested from AD Evaluation::AD Followup
2013-10-30
05 Stewart Bryant Last call announcement was changed
2013-10-30
05 Stewart Bryant Last call announcement was generated
2013-10-15
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-10-15
05 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-05.txt
2013-10-02
04 Stewart Bryant State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2013-10-02
04 Stewart Bryant Waiting on answers from authors.
2013-10-02
04 Stewart Bryant State changed to AD Evaluation::AD Followup from AD Evaluation
2013-09-04
04 Stewart Bryant
Hi,

This is my AD review of draft-ietf-l2vpn-evpn-req-04

This document would be a lot clearer to the reader if
there were some diagrams to help …
Hi,

This is my AD review of draft-ietf-l2vpn-evpn-req-04

This document would be a lot clearer to the reader if
there were some diagrams to help them follow the text.

Please can you explain why there are six authors on the
front page. At this stage I am not asking anyone to
take their name off, but I will need to justify it
to my colleagues on the IESG.

It would also be really helpful in referencing this
if the requirements were numbered.



4.4.  Optimal Traffic Forwarding

  In a typical network, and considering a designated pair of PEs, it is
  common to find both single-homed as well as multi-homed CEs being
  connected to those PEs. An active/active multi-homing solution SHOULD
  support optimal forwarding of unicast traffic for all the following
  scenarios. By "optimal forwarding", we mean that traffic will not be
  forwarded between PE devices that are members of a multi-home group
  unless the destination CE is attached to one of the multi-homed PEs.

  i.  single-homed CE to single-homed CE
SB> I do not understand how this fits in the list?


6. Ease of Provisioning Requirements

  As L2VPN technologies expand into enterprise deployments, ease of
  provisioning becomes paramount. Even though current VPLS has an auto-
  discovery mechanism, which enables single-sided provisioning, further
  simplifications are required, as outlined below:

  - Single-sided provisioning behavior MUST be maintained.
SB> Needs a reference



12. Security Considerations

  For scenarios where MAC learning is performed in the data-plane,
  there are no additional security aspects beyond those considered in
  [RFC4761] and [RFC4762]. And for scenarios where MAC learning is
  performed in the control plane (via BGP), there are no additional
  security aspects beyond those considered in [RFC4364].

SB> I really find it hard to believe that there are no new security
SB> requirements, and suggest that you might want to include a note
SB> that any protocol extensions developed will include the appropriate
SB> security analysis, and that the requiremnet is to introduce no new
SB> vulnerabilities beyond those of  RFC4761 RFC4762 and RFC4364
SB> or equivalent text  .
2013-09-04
04 Stewart Bryant State changed to AD Evaluation from Publication Requested
2013-09-03
04 Stewart Bryant Changed document writeup
2013-07-23
04 Cindy Morgan
Draft Title:  Requirements for Ethernet VPN (EVPN)
Draft Name: draft-ietf-l2vpn-evpn-req-04

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, …
Draft Title:  Requirements for Ethernet VPN (EVPN)
Draft Name: draft-ietf-l2vpn-evpn-req-04

(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?

Informational.

This is the proper type of RFC as this is a requirements document.  The type of RFC is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

    Technical Summary:

    The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution which addresses the above issues.

    Working Group Summary:

    This document is an L2VPN Working Group document, and has been reviewed in the working group through multiple iterations of the draft.  There was considerable debate during and after the WG last call which resulted in new revisions being issued to resolve various comments.

    Document Quality:

    The document provides a clear and concise set of requirements for E-VPN - broken down into different requirement areas.  As a requirements draft there is no protocol to implement.

    Personnel:

    Document Shepherd: Giles Heron (giheron@cisco.com)
    Area Director: Stewart Bryant (stbryant@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.

The Document Shepherd did a full review of the text of version -03 of the draft, leading to the authors issuing version -04 with various fixes - which was subsequently reviewed by the Document Shepherd.  The Document Shepherd did a scan through the mail archives and previous IETF meeting minutes to review debates on the draft.

(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 specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There was considerable debate during the WG last call, and also strong indication of support for the draft (by 12 individuals).

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

One nit found due to an informative reference to a draft which has been updated in the last few days.

(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.  The Document Shepherd checked all this as part of the document review.

(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 - all normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No - all normative references are upward.

(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 - no impact on status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section simply says "None."  As a requirements draft there is no protocol defined, and hence no actions are required.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No sections written in a formal language.

2013-07-23
04 Cindy Morgan Intended Status changed to Informational
2013-07-23
04 Cindy Morgan IESG process started in state Publication Requested
2013-07-23
04 Cindy Morgan Changed document writeup
2013-07-23
04 Cindy Morgan Document shepherd changed to Giles Heron
2013-07-14
04 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-04.txt
2013-05-30
03 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-03.txt
2013-02-24
02 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-02.txt
2012-10-19
01 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-01.txt
2012-03-30
00 Ali Sajassi New version available: draft-ietf-l2vpn-evpn-req-00.txt