|
Hi Dale,
Having someone who doesn’t have EVPN background to read this document thoroughly and comments on it, helps greatly with the overall readability of this document. So, thank you for your comments. I tried
to address all your comments. Please see inline for my replies.
Reviewer: Dale Worley
Review result: On the Right Track
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
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.
I modified both the abstract and the introduction to say:
”… and how such a solution can offer a more efficient implementation of these functions than that of [RFC7796].”
I also added the following sentence to the introduction:
"Since this document specifies a solution based on [RFC7432], it requires the readers to have the knowledge of [RFC7432] as prerequisite."
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.
Now, there is, because it compares it with [RF7796] and section 3.1 describes why this solution is more efficient than [RFC7796].
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?
Based on someone else’s comment, the text has already been modified to spell out EVPN and [RFC7432]. The abstract now says:
"This document discusses how those functional requirements can be met with a solution based on Ethernet VPN (EVPN) [RFC7432] with some extensions and how such a solution can offer a more efficient implementation of these functions than
that of [RFC7796].”
Similar modifications has been made to the introduction section.
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"?
I have got rid off the word “scope” and have changed both the abstract and introduction to:
"This document makes use of the most significant bit of the PMSI tunnel type governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly."
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.
Made them all consistent now.
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.
Both MEF 6.1 and RFC7387 (referenced in this document) allow for multiple roots in an E-TREE which itself is defined as a rooted-multipoint service.
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.
1st paragraph of section 1 (Introduction) explicitly says that:
"Root ACs can communicate with all other ACs. Leaf ACs can communicate with Root ACs but not with other Leaf ACs.”
In order to make it even more clear, I am changing it to the following:
"Root ACs can communicate with all other ACs (both Root and Leaf ACs). Leaf ACs can communicate with Root ACs but not with other Leaf ACs."
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.
Change the 1st paragraph of the introduction to:
"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, a customer site that is typically represented by an Attachment Circuits (AC) (but may also
be represented by a MAC address) is labeled as either a Root or a Leaf site. Root sites can communicate with all other customer sites (both Root and Leaf sites). However, Leaf sites can communicate with Root sites but not with other Leaf sits. In this document
unless explicitly mentioned otherwise, a site is always represented by an AC.”
Also changed the 1st sentence of section 2.3 to:
"In this scenario, a customer Root or Leaf site is represented by a MAC address and a PE may receive traffic from both Root AND Leaf sites on a single Attachment Circuit (AC) of an EVI."
(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 ...".
Done.
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.)
Modified the 2nd para of section 1 to:
“… The document identifies the functional components of an overall solution to emulate E-Tree services in MPLS networks in addition to multipoint-to-multipoint Ethernet LAN (E-LAN) services specified
in [RFC7432] and [RFC7623]."
[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 ..."?
Done.
"[802.1ah]" appears to be a reference, but there is no entry in
section 9 for it.
Added a reference in section 9.
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.
Modified the text to make it very clear:
"This document discusses how the functional requirements for E-Tree service can be met with a solution based on (PBB-)EVPN (i.e., [RFC7432] and [RFC7623]) with some extensions and how such a solution can offer a more efficient implementation
of these functions than that of [RFC7796]."
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.
Modified the text and removed “scope”:
"This document makes use of the most significant bit of the PMSI tunnel type governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly. Section 2 discusses E-TREE scenarios."
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 ...".
Change it to the following in both the Introduction section and the Abstract:
"This document makes use of the most significant bit of the "Tunnel Type" field (in PMSI Tunnel Attribute) governed by the IANA registry created by RFC7385, and hence updates RFC7385 accordingly."
Section 2 discusses E-TREE scenarios.
What the proper capitalization of "E-Tree"?
Yes, it should be “E-Tree”. I have made the change throughout the document.
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.)
Yes, they were missing. I have already taken care of it.
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.
Change it to the following to make it more clear:
"- Either Leaf or Root site(s) per PE
- Either Leaf or Root site(s) per Attachment Circuit (AC)
- Either Leaf or Root site(s) per MAC address”
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.
I think with the changes already made, the above sentence is accurate. Basically, a Root AC corresponds to an AC which is connected to Root endpoint(s) and a Leaf AC corresponds to an AC connected to Leaf endpoint(s).
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.
Removed the term “concurrently”.
+---------+ +---------+
| 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) +---+
+---------+ +---------+
The connection among MAC VRFs is very well understood. It is not point-to-point but rather multipoint-to-point from each MAC-VRF (e.g., a single downstream label is advertised by the PE to all other PE devices for its MAC-VRF). I am afraid
representing a P2P connection between MAC-VRF may cause confusions.
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 ...".
Changed it to:
"In this 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."
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).
Changed it to “prevent”.
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.
The current text is reading fine to me. However, if you have specific changes in mind, please let me know.
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.
Added the following paragraph to section 2.1:
"For this scenario, if it is desired to use only a single RT per EVI (just like E-LAN services in [RFC7432]), then the approach B in scenario 2 (described below) needs to be used."
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.
Added the following paragraph to section 2.3:
"For this scenario, the approach B in scenario 2 (described above) is used in order to allow for single RT usage by service providers.”
Also added the following paragraph at the end of the section 2.3:
“In conclusion, the approach B in scenario 2 is the recommended approach across all the above three scenarios and the corresponding solution is detailed in the following sections."
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"?
“MAC-VRF and bridge tables”. I will remove “,” :
“… if MAC-VRF and bridge tables used per VLAN are to remain consistent with [RFC7432] (section 6)."
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?
That is described in [RFC7432] which I made it prerequisite for this document.
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?
The last paragraph that I added to section 2.3 should now make it clear:
“In conclusion, the approach B in scenario 2 is the recommended approach across all the above three scenarios and the corresponding solution is detailed in the following sections."
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 ...".
Changed it to “either” “or”.
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?
It is implied mechanism of RFC7432 and that’s why it says “per [RFC7432].
There seems to be no description of the techniques to be used in this
case.
Now there is with the addition of the two paragraphs described above to this section.
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.
It has already been addressed in. Added the following sentence to the end of 1st para in section 1.
"In this document unless explicitly mentioned otherwise, a site is always represented by an AC."
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.
Changed the 1st para of section 3 to:
"[RFC7432] defines the notion of Ethernet Segment Identifier (ESI) MPLS label used for split-horizon filtering of BUM traffic at the egress PE. Such egress filtering capabilities can be leveraged in provision of E-Tree services as it will
be seen shortly for BUM traffic. For know unicast traffic, additional extensions to [RFC7432] is needed (i.e., a new BGP Extended Community for leaf indication described in section 5.1) in order to enable ingress filtering as described in detail in the following
sections."
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".
The paragraph is talking about know unicast filtering. I read it again and it is very clear (at least to me :-).
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.
Changed the paragraph to:
"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. This is done by advertising a leaf indication flag (via an Extended
Community) along with each of its MAC/IP Advertisement routes learned from a leaf site. 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."
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.
The modified paragraph above should cover this.
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."
Done.
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.
OK. Change it to:
"In this specification, the support for filtering BUM (Broadcast, Unknown, and Multicast) traffic does not include ingress filtering because it is not possible to do so, due to the multi-destination nature of BUM traffic."
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.
Good catch! I changed “that” to “when"
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?
Added the following sentences to the end of 1st paragraph of section 3.2:
"This Leaf label allows for disposition PE (e.g., egress PE) to perform the necessary egress filtering function in data-plane similar to ESI label in [RFC7432]. The allocation of the Leaf label is on a per PE basis (e.g., independent of
ESI and EVI) as descried in the following sections."
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.
Changed the sentence to:
"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 in MPLS encapsulated BUM packets just like ESI label for ingress replication
procedures defined in [RFC7432]."
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.
It is now described in terminology section.
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
...".
Split-horizion group means the member of that group cannot send packets to each other.
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.
Changed the sentence to:
"Other mechanisms for identifying root or leaf sites such the use of source MAC address of the receiving frame are optional. The scenarios below are described in context of Root/Leaf AC; however, they can be extended to Root/Leaf MAC address
if needed."
The acronym "ES" us used a lot in this section, meaning "Ethernet
segment". Is "Ethernet segment" related to "AC"?
Terminology section now provides the definition of an Ethernet Segment.
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"?
They are capitalized if they are used as adjectives. Went through the doc to make sure that’s the case.
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 original text is correct but I’ll change it to the following for better clarification:
"corresponding to all EVIs on the PE where each EVI has at least one Leaf site."
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.
This term is borrowed from [RFC7432] and there is no shorter term :-(
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."
Correct! I will change it to the following since RT’s are carried by the route and not EVIs:
"Multiple Ethernet A-D per ES routes will need to be advertised if the number of Route Targets (RTs) that need to be carried exceed the limit on a single route per [RFC7432]."
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.
The entire paragraph in section 3.2.1 is about advertisement of Leaf label in control 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.
It is important to mention that there is no forwarding among subnets. This sentence itself is the conclusion of some of the discussions among the co-author.
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.
Changed it to:
"In this scenario, both the ingress and egress PE devices follows the procedure defined in [RFC7432] for adding and/or processing an ESI MPLS label - i.e., existing procedures for BUM traffic in [RFC7432] are sufficient and there is no
need to add a Leaf label.”
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 ...".
Changed it to:
“ - Known unicast traffic from Root to Roots & Leaf
- Known unicast traffic from Leaf to Root
- BUM traffic from Root to Roots & Leafs
- BUM traffic from Leaf to Roots"
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.
Changed it to:
"In the case where only multicast and broadcast flows need to be supported, the L2VPN PEs can avoid performing any MAC learning function."
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?
Ethernet Segments and ACs are different. An AC corresponds to an Ethernet tag (e.g., VLAN ID) on a port (Ethernet Segment). Now that both Ethernet Segment and Ethernet tag are defined in terminology and the association between Ethernet
tag and AC is made in the introduction section, there should be no ambiguity.
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?)
Modified the sentence to the following for better clarity:
"For scenarios where two different RTs are used per EVI (one to designate Root site and another to designate Leaf site), the MAC/IP Advertisement routes are imported only
by PEs with at least one Root site in the EVI - i.e., a PE with only Leaf sites will not import these routes."
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.
Modified the paragraph to:
“To support multicast/broadcast from Leaf to Root sites, either ingress replication tunnels from each Leaf PE or a P2MP tree rooted at each Leaf PE can be used. The following two paragraphs describes
when each of these tunneling schemes can be used and how to signal them.”
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).
Modified it to:
“If the number of Roots is large, P2MP tunnels (e.g., mLDP or RSVP-TE) originated at the PEs with Leaf sites may be used and thus there will be no need to use the modified PMSI tunnel attribute and the composite tunnel type values
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.
Modified it to:
"Just as in the previous section, if the number of Root PEs are only a few and thus ingress replication is desired from Leaf PEs to these root PEs, then the modified PMSI attribute and the composite tunnel type 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.
The precise statement should be: “… with each EVPN MAC/IP Advertisement route.”
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.
Done.
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.)
It is a generic property of PBB-EVPN.
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.
Added the following bullet to the list of bullets:
"- If the EVPN MAC/IP Advertisement route indicates that the advertised B-MAC has changed its designation from a Leaf to a Root and the local Ethernet Segment is a Leaf, then the source B-MAC address is removed from the B-MAC list
corresponding to the local Ethernet Segment used for egress filtering - i.e., to unblock traffic from that B-MAC address."
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.
Changed it to:
"For PBB-EVPN, the handling of such traffic is per section 4.2 without the need for C-MAC learning (in data-plane) in I-component (C-bridge table) of PBB-EVPN PEs (at both ingress and egress PEs)."
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.
Added the sentence:
"It indicates that the frame is originated from a Leaf site."
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:
Changed the sentence to:
"The value of the 20-bit MPLS label is encoded in the high-order 20 bits of the Leaf Label field.”
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 ...".
Done.
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.)
Done.
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) |
+---------------------------------+
Done.
And s/1 octets/1 octet/ -- even though RFC 6514 makes that mistake!
Done.
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.
Done.
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.
I have already changed it to:
"Value Meaning Reference
0x0C-0x7A Unassigned
0x7B-0x7E Experimental this document
0x7F Reserved this document
0x80-0xFA Reserved for Composite tunnel this document
0xFB-0xFE Experimental [RFC7385]
0xFF Reserved [RFC7385]
"
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?
Done.
Thanks,
Ali
[EOF]
|