Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN)
draft-ietf-bess-evpn-etree-14

[Ballot comment]
I'm reading the leaf to leaf prohibition as a routing optimization that isn't intended for security purposes, but could help prevent routing loops and leakage.  There is a little text early on in the document to describe the purpose, but I agree the text should be made a bit more clear.

[Ballot comment]
Section 3.3.2 says:

  The PEs implementing an E-Tree service need not perform MAC learning
  when the traffic flows between Root and Leaf sites are mainly
  multicast or broadcast.

Does this mean to say "mainly"? I would have expected "only", as in section 4.3.  In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful.

----

Section 5.1:

  The reserved bits SHOULD be set to zero by the transmitter and SHOULD
  be ignored by the receiver.

The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future.

----

The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing.

On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior.

[Ballot comment]
Section 3.3.2 says:

  The PEs implementing an E-Tree service need not perform MAC learning
  when the traffic flows between Root and Leaf sites are mainly
  multicast or broadcast.

Does this mean to say "mainly"? I would have expected "only", as in section 4.3.  In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful.

Section 5.1:

  The reserved bits SHOULD be set to zero by the transmitter and SHOULD
  be ignored by the receiver.

The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future.

----

The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing.

On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior.

[Ballot comment]
Section 3.3.2 says:

  The PEs implementing an E-Tree service need not perform MAC learning
  when the traffic flows between Root and Leaf sites are mainly
  multicast or broadcast.

Does this mean to say "mainly"? I would have expected "only", as in section 4.3.  In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful.

Section 5.1:

  The reserved bits SHOULD be set to zero by the transmitter and SHOULD
  be ignored by the receiver.

The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future.

____

The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing.

On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior.

[Ballot comment]
Section 3.3.2 says:

  The PEs implementing an E-Tree service need not perform MAC learning
  when the traffic flows between Root and Leaf sites are mainly
  multicast or broadcast.

Does this mean to say "mainly"? I would have expected "only", as in section 4.3.  In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful.

Section 5.1:

  The reserved bits SHOULD be set to zero by the transmitter and SHOULD
  be ignored by the receiver.

The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future.
____

The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing.

On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior.

[Ballot comment]
Section 3.3.2 says:

  The PEs implementing an E-Tree service need not perform MAC learning
  when the traffic flows between Root and Leaf sites are mainly
  multicast or broadcast.

Does this mean to say "mainly"? I would have expected "only", as in section 4.3.  In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful.

Section 5.1:

  The reserved bits SHOULD be set to zero by the transmitter and SHOULD
  be ignored by the receiver.

The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future.

The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing.

On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior.

[Ballot comment]
Section 3.3.2 says:

  The PEs implementing an E-Tree service need not perform MAC learning
  when the traffic flows between Root and Leaf sites are mainly
  multicast or broadcast.

Does this mean to say "mainly"? I would have expected "only", as in section 4.3.  In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful.

Section 5.1:

  The reserved bits SHOULD be set to zero by the transmitter and SHOULD
  be ignored by the receiver.

The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future.

The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing.

On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior.

[Ballot comment]
I share the questions about the prohibition of leaf-to-leaf communication. There's a fair amount of text enforcing such a requirement, but very little if any about why.

[Ballot comment]
Mostly editorial comment:
Reading sections 3 and 4 it not clear to me if this is providing an actual implementation specification or just reasoning. If the former is indented I would recommend to use more active and normative language. Also I would recommend to have section 5 before 3 and 4 because they use these new flags/fields.

Please also consider the comments provided by the new gen-art review (thanks Dale!) which probably go in the same direction and suggest some good concrete improvements.

[Ballot comment]
Mostly editorial comment:
Reading sections 3 and 4 it not clear to me if this is providing an actual implementation specification or just reasoning. If the former is indented I would recommend to use more active and normative language. Also I would recommend to have section 5 before 3 and 4 because they use these new flags/fields.

Please also consider the comments provided by the new gen-art review which probably go in the same direction and suggest some good concrete improvements.

[Ballot comment]
Mostly editorial comment:
Reading sections 3 and 4 it not clear to me if this is providing an actual implementation specification or just reasoning. If the former is indented I would recommend to use more active and normative language. Also I would recommend to have section 5 before 3 and 4 because they use these new flags/fields.

[Ballot discuss]
It's not clear to me if the prohibition on leaf-to-leaf communications is intended to be a security requirement. If so, it seems like it needs to explicitly state why it is not possible for ACs which are leaf to pretend to be root. If not, then it should say so. Additionally, this solution appears to rely very heavily on filtering, so I believe some text about what happens during periods of filtering inconsistency (and what the impact on the security is).

[Ballot comment]
[ I wrote this review back on Aug 8th, but the balloting wasn't open then - I believe that there has been a new revision since, and so some of these may already have been addressed. ]


I'm balloting No Objection, but I do have significant reservations;
because of the number of nits the document is quite hard to read - a number of these required re-reading the sentence multiple times, guessing at what the sentence is trying to says, etc. Many of these are really obvious (e.g see nit #14 below) and it makes me concerned that the document hasn't been sufficiently reviewed.

In addition, the RFC Editor would have caught these, but it doesn't seem reasonable to rely on them to make documents readable, nor to waste multiple reviewers time addressing what could easily have been caught with a simple read though.


Questions / Notes:
1: The document has 6 authors (one listed as an author) and a contributors section -- is there a substantive difference between those above the fold and those below it?

2: This document uses a number of acronyms without expanding them on first use.

3: Section 8.1 Considerations for PMSI Tunnel Types
"The status of 0x7F may only be
  changed through Standards Action [RFC5226]." - what makes 0x7F special? What is it reserved for?

4: The shepherd writeup says: 
Q: (16) Will publication of this document change the status of any
existing RFCs?
A: No change of the status of existing RFCs.

I believe that this is incorrect, especially when compared with the Q/A #17.

5: The IANA considerations section seems to be incorrect / transition isn't really described.
The current registry says:
0xFB-0xFE Reserved for Experimental Use

This document changes that to be:
0x7B-0x7E      Reserved for Experimental Use

While it "only" a change to an experimental range, by their very nature you don't know if anyone is using the current range. I think that the document needs to be much more clear about the fact that it is changing this, and also what the implications are for people who are already using e.g: 0xFB - from what I can see, it could break existing deployments.

Nits:

1: Section 2.1 Scenario 1: Leaf OR Root site(s) per PE
O: In such scenario, using tailored BGP Route Target (RT) import/export
  policies among the PEs belonging to the same EVI, can be used to
  restrict the communications among Leaf PEs.
P: In such scenario, tailored BGP Route Target (RT) import/export
  policies among the PEs belonging to the same EVI can be used to
  restrict the communications among Leaf PEs.
C: Redundant 'using' when coupled with 'can be used'

2: Section  2.2 Scenario 2: Leaf OR Root site(s) per AC
O: Approach (A) would require the same data plane enhancements as
  approach (B) if MAC-VRF and bridge tables used per VLAN, are to
  remain consistent with [RFC7432] (section 6).
C: This doesn't really parse -- I cannot tell if it is just an extraneous comma (after VLAN) or if it is that subject for "used per VLAN" is unclear.

3:
O: Given that both approaches (A) and (B) would require exact same data-
  plane enhancements,
P: Given that both approaches (A) and (B) would require the same data-
  plane enhancements,
C: grammar

4:
O: It should be noted that if one wants to use RT constrain
  in order to avoid MAC advertisements
P: It should be noted that if one wants to use RT constraints
  in order to avoid MAC advertisements
C: Assuming "constraints"; if not, needs more rewording.

5:
O: For this scenario, if for a given EVI, significant number of PEs have
  both Leaf and Root sites attached, even though they may start as
  Root-only or Leaf-only PEs, then a single RT per EVI should be used.
P: If, for a given EVI, a significant number of PEs have both Leaf and Root sites attached (even though they may start as Root-only or Leaf-only PEs), then a single RT per EVI should be used.
C: Probably cleaner would just be to drop the "For this scenario"; I don't think that the reader would take this a generalization, but your views may differ.

6: 2.3 Scenario 3: Leaf OR Root site(s) per MAC
I think that this may be better titled as "2.3 Scenario 3: Leaf OR Root site(s) per MAC address" -- without the 'address' it wasn't clear for the first bit if you actually intended MAC or if this was a typo for AC. Purely a nit.

7:
O: This scenario is not covered in both [RFC7387] and [MEF6.1];
P: This scenario is not covered in either [RFC7387] or [MEF6.1];
C: At least I'm assuming you meant either!

8: Section 3.1 Known Unicast Traffic
O: Since in EVPN, MAC learning is performed in control plane via
P: Since in EVPN, MAC learning is performed in the control plane via
C: Or perhaps "by the control plane"

9:
O:  thus providing very efficient filtering and avoiding sending known unicast
  traffic over MPLS/IP core to be filtered
P:  thus providing very efficient filtering and avoiding sending known unicast
  traffic over the MPLS/IP core to be filtered

10:
O: This new Extended Community MUST be advertised with MAC/IP
  Advertisement route.
P: This new Extended Community MUST be advertised with MAC/IP
  Advertisement routes.
C: s/route/routes/ (or similar)

11: Section 3.2 BUM Traffic
O: This specification does not provide support for filtering BUM
  (Broadcast, Unknown, and Multicast) traffic on the ingress PE because
  it is not possible to perform filtering of BUM traffic on the ingress
  PE, as is the case with known unicast described above, due to the
  multi-destination nature of BUM traffic.
P: This specification does not provide support for filtering BUM (Broadcast, Unknown, and Multicast) traffic on the ingress PE; due to the multi-destination nature of BUM traffic, is is not possible to perform filtering of the same on the ingress PE.
C: Parenthesis make it a bit easier to read, but the whole sentence should be rewritten; "This specification doesn't do X because it is not possible to do X due to Y" sounds odd, even more so being a run on sentence.

12:
O: Other mechanisms for identifying root or leaf (e.g., on a per MAC address basis) is beyond the scope of this document.
P: Other mechanisms for identifying root or leaf (e.g., on a per MAC address basis) are beyond the scope of this document.
C: Plural alignment.

13: Section 3.2.1 BUM traffic originated from a single-homed site on a leaf AC
O: along with an Ethernet A-D per ES route
C: A-D is used without expansion. I'm assuming Auto-Discovery, but this is not helpful to readers.

14: 3.2.3 BUM traffic originated from a multi-homed site on a leaf AC
O: In such scenarios,  If a multicast
P: In such scenarios, if a multicast
C: Things like this (there are multiple) make the reader wonder how well this was reviewed. This has been in the document since -03 (Oct 2015), so it isn't simply a "rush to squeeze it in" event.

15: Section 3.3.1 E-Tree with MAC Learning
O: For the scenario described in section 2.1 (or possibly section 2.2), these routes are imported ...
P: For the scenario described in section 2.1 (and possibly the scenario in section 2.2), these routes are imported ...
C: The original sounds a lot like you are not clear which section you are referring to.

16:
O: To support multicast/broadcast from Leaf to Root sites, ingress
  replication should be sufficient for most scenarios where there are
  only a few Roots (typically two). Therefore, in a typical scenario, a
  root PE needs to support both ...
C: Throughout the document you are using a mix of 'Root' vs 'root', 'Leaf' vs 'leaf' -- there doesn't seem to be much consistency.

17: Section 4 Operation for PBB-EVPN
O: In PBB-EVPN, the PE advertises a Root/Leaf indication along with each
  B-MAC Advertisement route, to indicate whether the associated B-MAC
  address corresponds to a Root or a Leaf site.
C: Please fix the commas - I think you just need to delete the second (or perhaps put the "along with each" bit in parens) - the current text is confusing.

18:
O: In such multi-homing scenarios where an Ethernet Segment has
  both Root and Leaf ACs, ...
P: In multi-homing scenarios where an Ethernet Segment has
  both Root and Leaf ACs, ...

19:
O: it is assumed that While different ACs (VLANs) on the same ES
C: See #14.

20: Section 4.1 Known Unicast Traffic
O: On the ingress PE, the C-MAC destination address lookup yields, ...
C: C-MAC is used without expansion - please insert reference (probably to RFC 7623)

21: Section 4.3 E-Tree without MAC Learning
O: In scenarios where the traffic of interest is only Multicast and/or
  broadcast, the ...
P: In scenarios where the traffic of interest is only multicast and/or
  broadcast, the ...
C: Please choose a single capitalization for Broadcast and Multicast and stick to it -- there are around 5 Multicast and 6 multicast.

22: Section 5.2 PMSI Tunnel Attribute
O: This document uses all other remaining fields per
  existing definition.
  P: This document does not redefine any other terms.
C: This still ready poorly -- I think according to existing definitions (also, plural matching).

23:
O: When receiver ingress-replication label is needed, the high-order bit
  of the tunnel type field (Composite Tunnel bit) is
C: I think "When a receiver ingress-replication label is needed" or "When receiver ingress-replication labels are needed" - whatever the case, I think you are missing a word or using the wrong one.

24:
O: When this Composite Tunnel bit is set, the "tunnel identifier" field
  would begin with a three-octet label,
P: When this Composite Tunnel bit is set, the "tunnel identifier" field
  begins with a three-octet label,

25:
O: PEs that don’t understand the
  new meaning of the high-order bit would treat the tunnel type
C: As before, delete "would"

26: Section 7  Security Considerations
O: Furthermore, this document provides additional
  security check by allowing sites
P: Furthermore, this document provides an additional
  security check by allowing sites
C: Or "checks"...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-bess-evpn-etree-12. 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 [ RFC-to-be ].

The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are three actions which we must complete.

First, in the EVPN Extended Community Sub-Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the reference for Sub-Type Value 0x05 will be changed from [draft-ietf-bess-evpn-etree] to [ RFC-to-be ].

Second, a new registry is to be created called the E-Tree Flags registry. The new registry will be managed using RFC Required as defined in [ RFC 5226 ].

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix 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?

The new registry has initial registrations as follows:

Bit Name Reference
----+-------------------------+---------------
0-6 Reserved [ RFC-to-be ]
7 Leaf-Indication [ RFC-to-be ]

Third, the P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

is to be updated using [ RFC-to-be ] as a reference.

The registry is to be updated, by removing the entries for 0xFB-0xFE and 0x0F, and replacing them by:

Value Meaning Reference
--------------+----------------------------------+---------------------
0x0C-0x7A Unassigned
0x7B-0x7E Reserved for Experimental Use [ RFC-to-be ]
0x7F Reserved [ RFC-to-be ]
0x80-0xFF Reserved for Composite Tunnels [ RFC-to-be ]

In addition, the allocation policy for values 0x00 to 0x7A is IETF Review
as defined in [ RFC5226 ]. The range for experimental use is now 0x7B-0x7E, and value in this range are not to be assigned. The status of 0x7F may only be changed through Standards Action [RFC5226].

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of [ RFC-to-be ].

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

The following Last Call announcement was sent out (ends 2017-08-09):

From: The IESG
To: IETF-Announce
CC: Thomas Morin , aretana@cisco.com, thomas.morin@orange.com, bess-chairs@ietf.org, draft-ietf-bess-evpn-etree@ietf.org, bess@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (E-TREE Support in EVPN & PBB-EVPN) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'E-TREE Support in EVPN & PBB-EVPN'
  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-08-09. 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 Metro Ethernet Forum (MEF) has defined a rooted-multipoint
  Ethernet service known as Ethernet Tree (E-Tree). A solution
  framework for supporting this service in MPLS networks is proposed in
  RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a
  Multiprotocol Label Switching (MPLS) Network"). This document
  discusses how those functional requirements can be easily met with
  Ethernet VPN (EVPN) and how EVPN offers a more efficient
  implementation of these functions. This document makes use of the
  most significant bit of the scope governed by the IANA registry
  created by RFC7385, and hence updates RFC7385 accordingly.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2342/
  https://datatracker.ietf.org/ipr/2774/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7387: A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network (Informational - IETF stream)

=== AD Review of draft-ietf-bess-evpn-etree-09 ===

Dear authors:

I just finished reading this document.  In general, the document could benefit from an editorial pass to improve readability; I put in some suggestions below, but I’m sure I didn’t mention all.  I don’t think that my comments (even the Major ones) will be hard to resolve – most are around providing clarity and consistency.  I’ll wait for a revised draft before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. Both the Introduction and the Abstract mention that “this document discusses how the functional requirements for E-Tree service can be easily met…”  It seems to me that RFC7387 is used as the building block for this document.  Why is it not a Normative reference?


M2. There is no reference to E-Tree.  Please add a Normative one.


M3. In Section 2.2 (Scenario 2: Leaf OR Root site(s) per AC): “…then a single RT per EVI MAY be used…”  I think that “MAY” is out of place because it seems to be expressing just a fact.  Also, please keep the normative language where the operation is defined (in this case in 3.1).


M4. Section 3.1 (Known Unicast Traffic) talks about how in the “multi-homing scenario of section 2.2…the PE MAY advertise leaf indication along with the Ethernet A-D per EVI route”.  Given that the text later says that “in case of discrepancy, the multi-homing for that pair of PEs is assumed to be in default "root" mode”, I find the “MAY” not sufficient.  If we want to prevent as many discrepancies as possible, shouldn’t that be a “SHOULD” (or even a “MUST”)?  Given the local configuration, why would the PE not want to include the leaf indication…ever…?


M5. In Section 5.1 (E-TREE Extended Community) there is redundant information (first and last paragraphs).  Among that redundant information there is no consistency: “the Leaf Label field is set to a valid MPLS label” and “the Leaf Label MUST be set to a valid MPLS label” – please be consistent and specify things just once.

M5.1. BTW, that is a “valid MPLS label”?  How would a receiver recognize it?  Please add a reference to avoid confusion.


M6. Definition of the E-TREE Extended Community

M6.1. Only one Flag is defined.  What about the others?  Please set up a registry.

M6.2. [Minor] Please put a Figure number and heading for the community format.

M6.3. It looks like the Reserved fields are set to 0.  What should happen if the receiver gets something else?

M6.4. “…the Leaf-Indication flag MUST be set to one and Leaf Label is set to zero. The received PE should ignore Leaf Label and only processes Leaf-Indication flag.”  What if the Leaf Label is not set to zero?  The second sentence says to ignore it, but the first one that it “MUST be…set to zero”.  Which one is it?  Maybe both…  Be specific!

M6.5. “…the Leaf Label MUST be set to a valid MPLS label and the Leaf-Indication flag should be set to zero. The received PE should ignore the Leaf-Indication flag.”  Similar question for the Leaf-Indication bit.

M6.6. “A non-valid MPLS label when sent along with the Ethernet A-D per ES route, should be logged as an error.”  I’m assuming that not only the logging is needed, but is the route ignored/discarded too?


M7. The PMSI Tunnel Attribute:  Please be clear to the fact that the C bit is being defined/introduced in this document (and not just start talking about it as if it is well-known to every reader).

M7.1. It is not clear to me how the C bit is to be used.  Section 5.2 says that “the high-order bit of the tunnel type field (C bit - Composite tunnel bit) is set while the remaining low-order seven bits indicate the tunnel type as before.”  But 3.3.1 says that the “new composite tunnel type is advertised by the root PE to simultaneously indicate a P2MP tunnel in transmit direction and an ingress-replication tunnel in the receive direction…”.  Knowing, from 5.2 that when the C bit is set “Tunnel Types…0x06 'Ingress Replication' is invalid”, then does the C bit have a set meaning or ???  [BTW, s/is/are]

M7.2. [Minor] In some places you talk about the “C bit” or “Composite tunnel bit”, but later mention the “Composite flag”.  I’m assuming it is the same thing – please be consistent!

M7.3. “invalid tunnel type”  RFC6514 talks about an “undefined tunnel type”.  Do you mean the same thing?  If you do, please use the right terminology and put a reference to rfc6514 here to remind people where the action is defined.


M8. Section 8.1 (Considerations for PMSI Tunnel Types).

M8.1. What should the name of the bit be?  C bit, “composite tunnels” or “Composite tunnel bit” – all 3 versions are used, and IANA will want specific directions.

M8.2. “…by removing the entries for 0xFB-0xFE and 0x0F”  The range between 0x80-0xFA also needs to be changed/updated.  s/0x0F/0xFF.  It may be clearer to write that this document updates the range 0x80-0xFF.

M8.3. “…and replacing them by…”  Please format the table so that spacing is aligned (for better clarity for IANA).  Also, please include in it all the reallocated space; for example:

  Value        Meaning                        Reference
0x0B-0x7A    Unassigned             
0x7B-0x7E    Reserved for Experimental Use  [this document]
0x7F          Reserved                        [this document]
0x80-0xFF    Composite Tunnels              [this document]


M8.4. What is 0x7F reserved for?  It doesn’t seem to be used in this document.  Why a different registration procedure?




Minor:

P1. s/and RFC called "A Framework for E-Tree Service over MPLS Network"./RFC7387 ("A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network").

P2. Please expand EVPN on first use.  I know that this is a well-known term – please consider talking to the RFC Editor (once this document gets to them) in order to include “EVPN” in the “RFC Editor Abbreviations List” [1].

P2.1.  Please also expand: DF, BUM…

[1] https://www.rfc-editor.org/materials/abbrev.expansion.txt

P3. The abbreviation for Ethernet Segment is introduced in Section 3.2…please introduce it on first mention (Section 2) as it gets used before 3.2.  Also, the abbreviation for Attachment Circuit is introduced after AC has been used several times.  EC is used w/out definition.

P4. “E-TREE for VPLS”  Please add an Informative reference to rfc7796.

P5. “…new BGP Extended Community for leaf indication as shown later in this document.”  Please include a forward reference to Section 5.1.

P6. “MAC mobility procedures”  What are those?  Please add a reference.

P7. Section 3.2.1 (BUM traffic originated from a single-homed site on a leaf AC) starts by talking about “a special MPLS label” – even though there’s a reference later to 5.1, please be explicit (writing something like this): “the PE adds the Leaf Label advertised using the E-Tree Extended Community (Section 5.1)”.    Simplifying the text will go a long way to making implementation easier.

P8. “IRB use case is outside the scope of this document.”  An Informative reference to draft-ietf-bess-evpn-inter-subnet-forwarding would be nice.

P9. It would be nice to include a “map” of the document in the Introduction: (something like) “Section 2 talks about blah…Section 3 defines…”.

P10. s/EVPN MAC Advertisement route/MAC/IP Advertisement Route    Please be specific!

P11. “To support multicast/broadcast from Root to Leaf sites, either a P2MP tree rooted at the PE(s) with the Root site(s) or ingress replication can be used.”  References would be very nice!

P12. Section 5.3 doesn’t exist.

P13. Both Sections 3 and 4 mention the same things (other tagging mechanisms and IRB) out of scope.  It would be nice to mention common pieces of the operation in a single place.

P14. “This document defines two new BGP Extended Community for EVPN.”  I only see one.

P15. A Normative reference to rfc4360 is needed in 5.1.

P16. There’s no need to the reference to rfc7153 because you’re referring to the registry itself.

P17. The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list.

P18. There is no reference to rfc5226.


Nits:

N1. There are a lot of very long sentences…  It would be nice if the ideas were composed so that the overall document was easier to read.  For an example, take a look at the last paragraph in 2.2…  No specific action required here, but it would be nice to give it an editing pass.

N2. s/ each of its MAC/IP Advertisement route/each of its MAC/IP Advertisement routes

N3. Another example of where the text is not as clear as it could be for a specification is Section 3.2, where tagging MPLS frames is mandated (“the MPLS-encapsulated frames MUST be tagged with an indication when they originated from a Leaf AC”), but there is no indication on how to do this until 3 paragraphs later – a seemingly unrelated discussion is held in between…

N4. “we” is used a couple of times (outside the Acknowledgements) – please change that to “this document” (or something similar).

N5. s/where and Ethernet Segment/where an Ethernet Segment

N6. s/draft/document

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

Std Track, appropriately captured in doc 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 Metro Ethernet Forum (MEF) has defined a rooted-multipoint
  Ethernet service known as Ethernet Tree (E-Tree). A solution
  framework for supporting this service in MPLS networks is proposed in
  and RFC called "A Framework for E-Tree Service over MPLS Network".
  This document discusses how those functional requirements can be
  easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient
  implementation of these functions.

Working Group Summary
 
  Nothing substantial. A first call for adoption did not lead to adoption, for lack of an observable support base, but the document was later adopted on a second pass.
 
Document Quality

  The document is of satisfying technical and editorial quality.
  Three vendors are known to be working on an implementation or update of pre-standard implementations.

Personnel

  Thomas Morin is the Document Shepherd.
  Alvaro Retana is the Responsible Area Director.

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

An in-depth review was done by the document shepherd, leading to changes.
The shepherd thinks the document is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern.

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

N/A

(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 concern.

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

All authors did confirm.

(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 disclosures were made:
- one prior to WG adoption, leading to no WG discussion
- one after WG adoption, but which was withdrawn by the submitter very shortly after (see https://datatracker.ietf.org/ipr/2774 ), leading to no WG discussion.

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

Consensus of a significant subset of the working group.

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

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

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

All clear.

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

N/A

(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 change of the 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 shepherd concluded that the IANA section was not addressing the need to update RFC7385 and the registry that it created. The follow-up discussion lead to update the document to address that.


(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