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

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.

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.

- 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

Vijay Gurbani raised an issue with R13 and R14 that I thought had merit. Should this result in some edits?

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.

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