Last Call Review of draft-ietf-bess-evpn-etree-12
review-ietf-bess-evpn-etree-12-genart-lc-worley-2017-08-07-00

Request Review of draft-ietf-bess-evpn-etree
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-08-09
Requested 2017-07-26
Other Reviews Rtgdir Telechat review of -12 by Ravi Singh (diff)
Opsdir Last Call review of -12 by Carlos Pignataro (diff)
Genart Telechat review of -13 by Dale Worley
Opsdir Telechat review of -13 by Carlos Pignataro
Review State Completed
Reviewer Dale Worley
Review review-ietf-bess-evpn-etree-12-genart-lc-worley-2017-08-07
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/jykcgRXQqQpEvqB6LrMTBo1QNKE
Reviewed rev. 12 (document currently at 13)
Review result On the Right Track
Last updated 2017-08-07

Review
review-ietf-bess-evpn-etree-12-genart-lc-worley-2017-08-07

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document:  draft-ietf-bess-evpn-etree-12
Reviewer:  Dale R. Worley
Review Date:  2017-08-07
IETF LC End Date:  2017-08-09
IESG Telechat date:  2017-08-17

Summary:

This draft is on the right track but has open issues, described in the
review.  A few of the issues are directly technical.

Reading this draft, I have the sense that it isn't so much a
specification as the description of an idea, which is that EVPN can be
used to implement E-Tree functionality.  It reads as if someone who is
extremely knowledgeable about EVPN is outlining the idea to someone
similar, given that various details don't seem to be worked out
completely and that in several places there are alternative
implementation methods that are mentioned but do not seem to be
rigorously enumerated.  The document seems to more describe *class* of
ways of implementing E-Trees, and not a rigidly delimited class.

As far as I can tell, the idea works, but I suspect that an
implementor would not just be following the specification but
completing it in many respects.  Given that the document seems to
extend the mechanisms of RFC 7432, I suspect that an implementor would
have to carefully work out the details of all the BGP announcements,
and that not all implementations would interoperate.  E.g., "This Leaf
label is advertised to other PE devices, using the E-TREE Extended
Community" sounds to me like it's very under-specified.

The way forward seems to be clear:  The draft needs to be edited
carefully, filling in the missing details and making more explicit and
rigid the various implementation alternatives.  It might be worth
enumerating all of the mentioned implementation choices in one place,
as successful interoperation requires that all devices in a VPN are
using the same choices.  And I think interoperation needs to be
emphasized -- two devices that implement this draft should
interoperate if they are configured to have the same choices of the
implementation choices enumerated in the draft.  Otherwise, this draft
is just the outline for a dozen vendors' similar-but-not-interoperable
proprietary products.

Abstract

   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.

"More efficient" than what?  The abstract reads as if this document is
an alternative method of implementing E-Tree, but I read well into the
draft before it became clear that this draft is an alternative to RFC
7387, rather than that this draft and RFC 7387 are an alternative to
something else.  The abstract does not specifically state all of the
relationships between the specifications it mentions.

And although this mechanism is described as "more efficient", there
doesn't seem to be any discussion of how it is more efficient.  You
don't need a lot of detail for this, but it would be helpful if there
was at least a brief description of what way it is more efficient and
some indication of the degree.

Also, what is relationship between "EVPN" and this document?  Is EVPN
a widely-known technology whose name need not be footnoted?  Is it
something defined in this document?  Importantly, is the usage in this
document a subset within some defined EVPN specification, or is it a
modification/extension of EVPN?

   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 use of "scope" is peculiar here.  Generally, "scope" refers to a
region of some sort of space, so one would say "scope value" or "scope
value field" to refer to a group of bits that designate a scope.  But
checking with RFC 7385 and the IANA registry page for "Border Gateway
Protocol (BGP) Parameters", I am unable to find any occurrence of the
word "scope".  And other than a very similar passage in section 1,
"scope" only appears in this document in the phrase "scope of this
document".  Perhaps "scope" should be "tunnel type"?

Table of Contents

What is the capitalization rule you're using for section titles?
E.g., sections 3.2.{1,2,3,4} are capitalized in a decidedly different
way that other sections.

1  Introduction

   The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
   Ethernet service known as Ethernet Tree (E-Tree) [MEF6.1]. In an E-
   Tree service, Attachment Circuits (ACs) are labeled as either Root or
   Leaf ACs. Root ACs can communicate with all other ACs. Leaf ACs can
   communicate with Root ACs but not with other Leaf ACs. 

Given the use of "rooted-multipoint", it seems that there is to be
exactly one Root AC per virtual Ethernet, as rooted trees have exactly
one root node.  Where or not that is true is very important for the
conceptual model of the service, but is not stated clearly
here. Perhaps there is a terminology problem, as when I see "rooted"
and "tree" in a sentence, I assume that the "tree" is "rooted", i.e.,
it has exactly one root.  (Similarly in Wikipedia, "Rooted-MultiPoint"
[sic] redirects to "Point-to-multipoint", which says "providing
multiple paths from a *single* [my emphasis] location to multiple
locations".)  However, the last sentences of section 2.1 suggest that
an E-Tree might have more than one Root.

Subtle point:  If there are multiple Roots, the text implies that all
Roots can communicate with all other Roots.  It might be worth
mentioning that explicitly, as the naive reader might overlook it.
Indeed, it is possible within this model that all endpoints are Roots,
in which case the VPN is completely connected.

Also, it seems that in scenario 3 of section 2 that a single AC could
have multiple endpoints on it some of which are Root and some are
Leaf, which doesn't fit within the description in this paragraph.

(In general, meticulously editing the Introduction section is
extremely helpful to readers who aren't already thoroughly familiar
with the subject.)

   [RFC7387] proposes the solution framework for supporting E-Tree
   service in MPLS networks.

I think this should be "a solution framework".  If one says "the solution
framework", then there is in some way only one solution framework, and
the RFC would "state" it.  Saying that the RFC "proposes" a framework
shows that there could be others that could be proposed.  Similarly in
the next sentence would be "... of an overall solution ...".

   The document identifies the functional
   components of the overall solution to emulate E-Tree services in
   addition to Ethernet LAN (E-LAN) services on an existing MPLS
   network.

The relationship of E-LAN to E-Tree is not clear, and how the phrase
"on an existing MPLS network" attaches to either is not clear.  I
think you mean at least:

   The document identifies the functional components of the overall
   solution to emulate E-Tree services on an existing MPLS network.

and that the document does the same for E-LAN.  I suspect that there
is some implied relationship between E-Tree and E-LAN, other than that
solution frameworks are described in RFC 7387.

However, the term "E-LAN" does not appear anywhere else in this
document, is it important to include it?  And given that E-Tree gets
its own reference to describe its functional specification, shouldn't
there be a reference giving the functional specification of "E-LAN"?
(As opposed to the implementation specification in RFC 7387.)

   [RFC7432] is a solution for multipoint L2VPN services, with advanced
   multi-homing capabilities, using BGP for distributing customer/client
   MAC address reach-ability information over the MPLS/IP network.
   [RFC7623] combines the functionality of EVPN with [802.1ah] Provider
   Backbone Bridging (PBB) for MAC address scalability.

The structure of this paragraph suggests that "EVPN" is defined by RFC
7432, but I had to look at 7432 to verify that.  Perhaps "[RFC7432]
defines EVPN, a solution for ..."?

"[802.1ah]" appears to be a reference, but there is no entry in
section 9 for it.

   This document discusses how the functional requirements for E-Tree
   service can be met with (PBB-)EVPN and how (PBB-)EVPN offers a more
   efficient implementation of these functions.

This paragraph has some of the same problems as the abstract.  But I
am now starting to suspect that the document is proposing using EVPN
as a way to provide E-Tree service *instead of* using the RFC 7387
proposal.  If that is so, this sentence needs to end "a more efficient
implementation of these functions than RFC7387.", and the third
sentence of the Abstract should start "This document discusses how the
functional requirements for E-Tree can be ..." (making clear that it
logically succeeds the first sentence, not the second), and the use of
"EVPN" in the Abstract needs to reference RFC 7432.

   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 "scope" business is still unresolved.

Also, this sentence doesn't say what the new purpose of the bit is.
Perhaps something like, "This document repurposes the most significant
bit of the tunnel type byte governed by the IANA registry created by
RFC7385 to ...".  But that is still opaque, as few people will
immediately know the purpose of a registry referenced only by RFC
number.  Perhaps "... the Tunnel Type byte in the BGP PMSI Tunnel
attribute ...".

   Section 2 discusses E-TREE scenarios.

What the proper capitalization of "E-Tree"?

1.1  Terminology

The text uses many acronyms which may not be widely known by people
not deeply conversant in these technologies.  It may help to put a
define many of them in section 1.1.  (E.g., "EVI" is defined well down
in the second paragraph of section 2.1, whereas it is used in the
first paragraph of that section.)

2  E-Tree Scenarios

The enumeration of cases is unclear.  I think you mean for scenario 1,
"PE is exclusively Leaf or Root site(s)", etc.  But "OR" doesn't carry
that meaning unambiguously.  You could s/OR/XOR/ to make it
unambiguous, but that would be awkward and very geekish.

Also, I think "MAC address" is more correct than "MAC" here.

2.1 Scenario 1: Leaf OR Root site(s) per PE

   In this scenario, a PE may receive traffic from either Root ACs OR
   Leaf ACs for a given MAC-VRF/bridge table, but not both concurrently.

There's a problem with "receive traffic from", because one can say a
PE "receives traffic from" any endpoint in the VPN -- if the traffic
is egressing from the VPN through the PE.  I think you want to phrase
it in terms of "all endpoints attached to the ACs attached to the PE
are Root endpoints or they are all Leaf endpoints".  Or you could
rephrase it in terms of ingressing traffic.  But really, Root and Leaf
are properties of endpoints much more than properties of traffic, and
it's best to use the terms accordingly.

Also, the meaning of "concurrently" is probably not what you want --
strictly, it means that two things cannot happen at the same time, but
it implies that they can happen at different times.  I don't think
that is what you mean.

                   +---------+            +---------+
                   |   PE1   |            |   PE2   |
    +---+          |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+---AC1----+--+   |  |  | MPLS |  |  |   +--+----AC2-----+CE2|
    +---+  (Root)  |  |MAC|  |  |  /IP |  |  |MAC|  |   (Leaf)   +---+
                   |  |VRF|  |  |      |  |  |VRF|  |
                   |  |   |  |  |      |  |  |   |  |            +---+
                   |  |   |  |  |      |  |  |   +--+----AC3-----+CE3|
                   |  +---+  |  +------+  |  +---+  |   (Leaf)   +---+
                   +---------+            +---------+

The figure is useful in showing the relationship of PE, AC, and CE.
(I see now that what I call an "endpoint" is generally known as a
"CE".)  But there is a shortage of connection lines.  I think
something like this would be clearer:

                   +---------+            +---------+
                   |   PE1   |            |   PE2   |
    +---+          |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+---AC1----+--+   |  |  | MPLS |  |  |   +--+----AC2-----+CE2|
    +---+  (Root)  |  |MAC|  |  |  /IP |  |  |MAC|  |   (Leaf)   +---+
                   |  |VRF+------------------+VRF|  |
                   |  |   |  |  |      |  |  |   |  |            +---+
                   |  |   |  |  |      |  |  |   +--+----AC3-----+CE3|
                   |  +---+  |  +------+  |  +---+  |   (Leaf)   +---+
                   +---------+            +---------+


   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.

Presumably, "In such a scenario ..." but I prefer "In this scenario
...".  But the grammar has a problem, since if you elide the clause
"using ... the same EVI", it reads "In such [a] scenario ... can be
used to ...".  I think you want "In such a scenario, tailored BGP
... policies ... can be used to ...".

I think you want "prevent" rather than "restrict", since by the
definition of E-Tree service, there is to be no communication between
Leaf ACs at all -- restrict has an implication that the limitation is
not absolute (and indeed, is somehow configurable).

   from one Leaf AC to another Leaf AC on a MAC-VRF for a given E-TREE
   EVI.

Across the whole document, it's clear that the operation of the
proposed E-Tree mechanism is absolutely independent for each EVI.
E.g., here you note that scenario 1 is "for any PE, *for any EVI*, all
CEs connected to that PE are either all Roots or all Leafs".  But you
could simply state this separation of each EVI from every other EVI at
the top of the document and not have to keep repeating it at various
places throughout the document.

That is, I think it's true.  If there are ways in which the
implementation of one EVI interacts the implementation of another EVI,
that needs to be prominently flagged and carefully assessed for
causing subtle problems.  E.g., in section 3.2.1, it seems like the
advertisements of "Ethernet A-D per ES routes" may bundle information
about multiple EVIs.

2.2 Scenario 2: Leaf OR Root site(s) per AC

There is a technical question in that scenario 1 is more restrictive
than scenario 2, so any solution for scenario 2 can be used in
scenario 1.  But only alternative A is presented for scenario 1, even
though alternative B must necessarily work.  Presumably there is a
reason why alternative B is not presented for scenario 1, and I think
it should be stated.

This fact caused me some confusion when I was reading the document:
The mechanism described in 2.1 seems to be satisfactory for fulfilling
the requirements stated in paragraph 2, so but paragraph 2 introduces
"coloring" of MAC addresses.  I think that the expositions of the
three scenarios could better be done if they were all coordinated with
each other.  Perhaps the choice between alternatives A and B for
coloring MAC addresses is actually common across the three scenarios,
and what really changes between the scenarios is the efficiency
tradeoffs between the two alternatives.

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

What is the subject of "are"?

   In order to avoid data-
   plane enhancements for approach (A), multiple bridge tables per VLAN
   may be considered; 

It's not clear what the difference is between "MAC-VRF and bridge
tables used per VLAN" and "multiple bridge tables per VLAN".  Can this
be described in a way that is clearer to people who are not highly
familiar with the subject?

   then two RTs (one for Root and another for Leaf)
   can still be used with approach (B)

This seems to be proposing some sort of mixture of alternatives A and
B.  What exactly are the alternatives that are being specified that
the implementor chooses between?

2.3 Scenario 3: Leaf OR Root site(s) per MAC

   This scenario is
   not covered in both [RFC7387] and [MEF6.1]

Literally, this means "It is not true that this scenario is covered in
RFC 7387 and in MEF6.1."  But I think you mean "This scenario is not
covered in either ...".

   the Designated Forwarding (DF)
   filtering per [RFC7432] would not be compatible with the required
   egress filtering

Interestingly, "designated forwarding" is not mentioned anywhere else
in this draft.  Does it appear elsewhere or is it implied in the
mechanics of RFC 7432 that are used throughout this draft?

There seems to be no description of the techniques to be used in this
case.

And given that it seems to be contemplated to support scenario 3,
there are numerous places in the draft where "a Root AC" and "a Leaf
AC" are not correct.  You could use "a Root CE" or "a Root site", etc.

3 Operation for EVPN

   In other words,
   [RFC7432] has inherent capability to support E-TREE services without
   defining any new BGP routes but by just defining a new BGP Extended
   Community for leaf indication as shown later in this document
   (section 5.1).

And by implication, the addition of various processing of that leaf
indication.

But this does show that this draft is not just an application of RFC
7432 but an extension of it.

3.1 Known Unicast Traffic

   sending ... traffic over MPLS/IP core to be filtered at the egress
   PE ...

The implication seems to be that this "sending" that is avoided is
really multicast, from the ingress PE to all egress PEs.  Naively,
describing this as "over MPLS/IP core" doesn't seem to capture the
meaning, since *all* traffic is going to be send "over the MPLS/IP
core".

   To provide such ingress filtering for known unicast traffic, a PE
   MUST indicate to other PEs what kind of sites (root or leaf) its MAC
   addresses are associated with by advertising a leaf indication flag
   (via an Extended Community) along with each of its MAC/IP
   Advertisement routes. The lack of such flag indicates that the MAC
   address is associated with a root site. This scheme applies to all
   scenarios described in section 2. 

Read literally, this paragraph says that a leaf indication flag MUST
be present on each advertisement, but then says the absence of the
flag means that it is a root side (implying that the absence of the
flag is legitimate).  There are two alternatives -- a) the flag is a
1/0 flag, with one value meaning Leaf and one meaning Root or b) the
flag is some optional field whose presence means Leaf and whose
absence means Root -- but this wording isn't quite correct for either.

Also, this paragraph seems to be saying that the extended community is
always used to indicate Leaf/Root status (though perhaps it specifies
status by its absence).  But the descriptions in section 2 seem to be
saying that alternative A doesn't require the extended community,
which contradicts the MUST in this paragraph.

3.2 BUM Traffic

   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.

This sentence is quite awkward.  I think you can carry all of the
meaning with "This specification does not provide support for
filtering BUM (Broadcast, Unknown, and Multicast) traffic on the
ingress PE because it is not possible to do so, due to the
multi-destination nature of BUM traffic."

But the phrase "does not provide support" is not correct -- the
ingress PE fully *supports* BUM traffic (except in scenario 3), it's
just that the support doesn't include *filtering* by the ingress PE.

   the MPLS-encapsulated frames MUST be tagged with an
   indication that they originated from a Leaf AC - i.e., to be tagged
   with a Leaf label as specified in section 5.1. 

As written, the sentence requires "... tagged with an indication
whether they originated ...".  The use of "that" states that all the
frames originated from a Leaf AC.

Looking ahead to section 5.1, I see that the Leaf label is
considerably longer than the 1 bit that would seem to be necessary for
this function given its description here.  And the next paragraph
suggests that the assignment of Leaf labels is complex.  It would be
helpful if you clarified here all of the functionality of Leaf labels
so the reader has context for following paragraphs.  I suspect the
meaning here is "all MPLS-encapsulated frame are tagged with labels,
and to distinguish Leaf-originated frames, they must be tagged with
labels which are known to be Leaf labels".  Also, is there only one
leaf label (for an EVI), or can there be many, perhaps one for every
Leaf AC?

   The main difference between
   downstream and upstream assigned Leaf label is that in case of
   downstream assigned not all egress PE devices need to receive the
   label just like ESI label for ingress replication procedures defined
   in [RFC7432].

This sentence isn't clear to me.  I suspect that it just needs a few
words adjusted.  Also, I suspect that it would help to move the final
clause, "just like ESI label ..." to a separate sentence.

   On the ingress PE, the PE needs to place all its Leaf ACs for a given
   bridge domain in a single split-horizon group in order to prevent
   intra-PE forwarding among its Leaf ACs.

The phrase "bridge domain" appears only twice in this document.  I
suspect it is synonymous with some other term you are using.

My belief is that a "split-horizon group" means a group of ACs that
are visible to each other.  If that is correct, this sentence needs to
be rephrased to something like "... the PE needs to place each of its
Leaf ACs for a given bridge domain into separate split-horizon groups
...".

   Other mechanisms
   for identifying root or leaf (e.g., on a per MAC address basis) is
   beyond the scope of this document.

Scenario 3 in section 2.3 posits that a single AC may support both
Leaf and Root endpoints.  So there must be a known method of
performing this identification on a per-MAC address basis, or else
scenario 3 cannot be implemented at present.  That doesn't require
that this document specify or describe a method of doing so, but it
seems that at this point, the document should either identify one or
more ways in which it can be done, or admit that there are no known
mechanisms at this time.  (Or perhaps that there are no known *good*
mechanisms at this time.)  Otherwise the inclusion of scenario 3 is
purely hypothetical.

The acronym "ES" us used a lot in this section, meaning "Ethernet
segment".  Is "Ethernet segment" related to "AC"?

3.2.1 BUM traffic originated from a single-homed site on a leaf AC

What is the rule for capitalizing or not the words "leaf" and "root"?

   This Leaf label is
   advertised to other PE devices, using the E-TREE Extended Community
   (section 5.1) along with an Ethernet A-D per ES route with ESI of
   zero and a set of Route Targets (RTs) corresponding to all EVIs on
   the PE with at least one leaf site per EVI.

I'm not sure, but I think you mean s/all EVIs on the PE with at least
one leaf site per EVI/all EVIs which have at least one leaf site on
the PE/.

   The set of Ethernet A-D
   per ES routes may be needed if the number of Route Targets (RTs) that
   need to be sent exceed the limit on a single route per [RFC7432].

I suspect from the text that "Ethernet A-D per ES route" is a single
term, but I have no idea what it is referring to.  And I suspect that
someone has coined a shorter term to use.

I suspect that one or more words in this sentence aren't quite right
and I can't parse it.  For instance "The set of ... routes may be
needed if ..." doesn't make sense -- in what way can a set of routes
be needed only under some conditions?  Perhaps it should be "A set of
... routes", if the meaning is that in some situations only one would
be needed.  Reading this again, I think you mean "Multiple Ethernet
A-D per ES routes will need to be advertised if the number of Route
Targets needed to carry the EVIs exceeds the limit on a single route."

   The
   ESI for the Ethernet A-D per ES route is set to zero to indicate
   single-homed sites.

This sentence seems to be talking about some attribute of a route
(which is an operation in the control plane) while the section is
theoretically talking about BUM traffic (which is in the data plane).
This seems to be a general organizational problem, where the details
of the data plane operations are mixed with general descriptions of
the control plane operations needed to support the data plane
operations.  It would be clearer if the data plane specifications and
the control plane specifications were separated (e.g., into adjacent
paragraphs), making it more explicit what information is passed from
the control plane to the data plane.

3.2.3 BUM traffic originated from a multi-homed site on a leaf AC

The first paragraph introduces various matters that aren't discussed
in the rest of the document, or at least aren't much discussed.  If I
understand it right, these considerations don't introduce anything
unexpected other than that an AC which is multi-homed (i.e., connects
to more than one PE) must, for any single EVI, be consistently a Root
or a Leaf on all of those PEs.  If I'm correct, this paragraph could
be made much easier to understand by stating just that and avoiding
details.

However, there may be more involved than that.  E.g., "there is no
forwarding among subnets" may be an additional requirement.  It's hard
to tell, because there are only two occurrences of "forwarding among
subnets", and it's not at all clear what that term is intended to
cover.

3.2.4 BUM traffic originated from a multi-homed site on a root AC

I think the critical point of this paragraph is omitted: "... but no
Leaf label is added".  Compare with section 3.2.2.

3.3 E-TREE Traffic Flows for EVPN

        - Ethernet known unicast from Root to Roots & Leaf
        - Ethernet known unicast from Leaf to Root
        - Ethernet BUM traffic from Root to Roots & Leafs
        - Ethernet BUM traffic from Leaf to Roots

The grammar of these is not good.  I think you mean "Known unicast
Ethernet from ... to ...", or better "Known unicast traffic from
... to ...".

   In the case where unicast flows need not be supported,
   the L2VPN PEs can avoid performing any MAC learning function. 

I think you want s/unicast/known unicast/ -- there may be situations
where unicast traffic exists, and it could be handled as known unicast
traffic, but the implementation can tolerate handling all of it as
unknown traffic to avoid MAC learning.

OTOH, the choice of supporting scenario 3 requires the choice of MAC
learning, since scenario 3 prevents handling should-be-known unicast
traffic as BUM traffic.  That dependency should be noted somewhere.

3.3.1 E-Tree with MAC Learning

I see here much use of "Ethernet Segments".  It seems that it has the
same functional meaning as "ACs".  If so, only one term should be used
consistently.  If not, does the distinction need to be explained?

   For the scenario
   described in section 2.1 (or possibly section 2.2), these routes are
   imported only by PEs with at least one Root site in the EVI ...

What is the condition on "possibly in section 2.2"?  (Is this a
distinction between alternatives A and B?)

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

This is introducing one of a pair of alternatives (the other one being
described in the following paragraphs).  I think the reader should be
warned in advance what the two alternatives are and what it depends on
(viz., the number of Roots).  That is, a top-down structure.

   If the number of Roots is large, P2MP tunnels originated at the PEs
   with Leaf sites may be used and thus there will be no need to use the
   modified PMSI tunnel attribute in section 5.2 for composite tunnel
   type.

The wording here is not quite right; I think it allows some ambiguity.
Perhaps

   If the number of Roots is large, P2MP tunnels originated at the PEs
   with Leaf sites may be used (and thus there will be no need to use
   the composite tunnel type values of the modified PMSI tunnel
   attribute in section 5.2).

3.3.2 E-Tree without MAC Learning

Similarly, I suggest

   Just as in the previous section, if the number of PEs with root
   sites are only a few and thus ingress replication is desired from
   leaf PEs to these root PEs, then the composite tunnel values
   defined in section 5.2 should be used.

4 Operation for PBB-EVPN

   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. Just like the EVPN
   case, the new E-TREE Extended Community defined in section [5.1] is
   advertised with each MAC Advertisement route.

I don't understand the distinctions here, but is "MAC Advertisement
route" correct?  There are two uses of "MAC" and 12 uses of "B-MAC" in
this section.

4.1 Known Unicast Traffic

   The ingress PE cross-checks this flag with the status of
   the originating site, and if both are a Leaf, then the packet is not
   forwarded.

I think this can be simplified to

   The ingress PE also checks the status of the originating site, and
   if both are a Leaf, then the packet is not forwarded.

4.2 BUM Traffic

   it updates its egress filtering (based on the
   source B-MAC address), as follows:

The stated algorithm has some important properties.  One is that if a
frame arrives, but its B-MAC address is unknown, then the frame is
forwarded.  That is, traffic not from a known Leaf is assumed to be
from a Root.  This may not be a problem, but it seems like it is an
important property of this specification, and the implementor should
be aware of it.  (OTOH, perhaps this is a generic property of
PBB-EVPN, in which case it need not be stated here.)

Another property is that if a B-MAC changes from being a Leaf to being
a Root (by whatever means that might happen), it seems that the new
advertisements of the B-MAC as a Root will *not* remove it from the
list of blocked B-MACs of any Leaf that has seen that B-MAC advertised
as a Leaf.  Unless there is some consideration that I'm not aware of,
I think you want to revise this algorithm in this regard.

4.3 E-Tree without MAC Learning

   For PBB-EVPN, the handling of such traffic is per
   section 4.2 without C-MAC learning part of it at both ingress and
   egress PEs.  

This could be phrased better.  And is the "non-C-MAC learning" mode of
operation of PBB-EVPN defined in the PBB-EVPN specification?  If not,
I think you might need to describe it in more detail here.

5.1 E-Tree Extended Community

   It is used for leaf indication of known unicast and BUM
   traffic.    

It's probably worth specifying that it indicates that the frame's
*origin* is a Leaf.

   The label value is encoded in the high-order 20 bits of the
   Leaf Label field.

This sentence seems to be in the wrong place, since the case described
in this paragraph doesn't use the Label Value field.  It seems to me
that it would be better to incorporate this information into the value
layout:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type=0x06     | Sub-Type=0x05 | Flags(1 Octet)|  Reserved=0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Reserved=0   |           Leaf Label                  |0 0 0 0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2 PMSI Tunnel Attribute

   Composite tunnel type is advertised by the root
   PE to simultaneously indicate a non-ingress replication tunnel ...

There's a certain ambiguity here, as I first read it as "... a
(non-ingress) replication tunnel ..." -- but of course, there is no
"egress replication".  What is meant is "... a non-(ingress
replication) tunnel ...", which I think would be better expressed as
"... a non-ingress-replication tunnel ...".

   When this Composite Tunnel bit is set, the "tunnel identifier" field
   would begin with a three-octet label, followed by the actual tunnel
   identifier for the transmit tunnel.

Probably better s/would begin/begins/.  (The clause of the condition
"Composite Tunnel bit is set" does not use the subjunctive mood, so
you don't use the subjunctive mood in the consequent clause.)

It might help to add a figure

         +---------------------------------+
         |  Flags (1 octet)                |
         +---------------------------------+
         |  Tunnel Type (1 octet)          |
         +---------------------------------+
         |  P2MP MPLS Label (3 octets)     |
         +---------------------------------+
         |  Ingress Replication MPLS Label |
         |  (3 octets)                     |
         +---------------------------------+
         |  Tunnel Identifier (variable)   |
         +---------------------------------+

And s/1 octets/1 octet/ -- even though RFC 6514 makes that mistake!

   PEs that don't understand the
   new meaning of the high-order bit would treat the tunnel type as an
   undefined tunnel type and would treat the PMSI tunnel attribute as a
   malformed attribute [RFC6514].

It might be worth noting that this processing is why the composite
tunnel bit is allocated in the Tunnel Type field rather than the Flags
field.

8.1 Considerations for PMSI Tunnel Types

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

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

   The allocation policy for values 0x00 to 0x7A is IETF Review
   [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].  

This structure allows the high-order bit to modify the interpretation
of the other bits.  However, section 5.2 says, "... the high-order bit
of the tunnel type field (Composite Tunnel bit) is set while the
remaining low-order seven bits indicate the tunnel type as before."

I think what you intended is to change the "P-Multicast Service
Interface Tunnel (PMSI Tunnel) Tunnel Types" registry to only specify
the low-order seven bits of the Tunnel Type field, with the high-order
bit of Tunnel Type being the Composite Tunnel bit.  Conceptualized
that way, the registry changes to:

   Value          Meaning                            Reference
   0x00-0x7A      (as before)
   0x7B-0x7E      Reserved for Experimental Use      this document
   0x7F           Reserved                           this document

This implies that the octet values 0x80 to 0xFF are subdivided into
assigned, unassigned, experimental, and reserved groups in the
parallel way.

9.1  Normative References

   [MEF6.1] Metro Ethernet Forum, "Ethernet Services Definitions - Phase
   2", MEF 6.1, April 2008.

Can we get a URL for this?

[EOF]