Requirements for Ethernet VPN (EVPN)
draft-ietf-l2vpn-evpn-req-07

[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").

[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

[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.

[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.

[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.

[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.

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.

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.

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  .

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.