-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email protected]]
Sent: Monday, February 01, 2016 2:04 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]>; EXT -
[email protected] <[email protected]>; BESS
<[email protected]>;
[email protected]
Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree
Hi Jeffrey,
Thanks for the review. Your comments helps tighten the draft some
more.
I
have updated the draft and will publish it next (rev04). Majority of
the
comments were editorial in nature for better clarifications. Since
the
existing draft (rev03) reflects the consensus regarding our several
rounds
of discussions where we have taken care of the technical items, it
is
consistent with our expectation of not seeing any major issue during
the
LC. Please refer to my replies in line.
Cheers,
Ali
On 1/27/16, 5:26 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang"
<[email protected] on behalf of [email protected]> wrote:
I was involved in relevant discussions, and have reviewed once more
for
this LC.
I support the publication, but with the following
questions/comments.
2.1 Scenario 1: Leaf OR Root site(s) per PE
... If the number of EVIs is very large
(e.g., more than 32K or 64K), then RT type 0 as defined in
[RFC4360]
SHOULD be used; otherwise, RT type 2 is sufficient.
RFC 7153 should be referenced for "Type 2".
Done.
Additionally, why is 32K mentioned? I can understand the 64k part.
Removed 32K since the example is clear enough with 64K
... the MPLS-encapsulated frames MUST be tagged with an
indication of whether they originated from a Leaf AC or not.
Perhaps change the last line to "indication if they originated from
a
Leaf AC"? Packets from a root AC are not tagged with a leaf
indication.
OK. Better yet. It should say ³indication when they originated from
a
leaf
AC².
Other mechanisms for identifying whether an egress AC is a root
or
leaf is beyond the scope of this document.
Should "egress" be "ingress" in the above paragraph? Or simply
removed?
Nice catch! It is ³ingress². It is now corrected.
... This Leaf MPLS label is advertised to other PE devices,
using a new EVPN Extended Community called 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 the
leaf
ACs on the PE.
Perhaps change the last sentence to "... corresponding to all EVIs
that
have leaf sites on the PE."
The second to last sentence of section 3.2.1 says the same thing. I
changed this sentence and removed the 2nd to last sentence.
3.2.3 BUM traffic originated from a multi-homed site on a leaf AC
In this scenario, it is assumed that a multi-homed Ethernet
Segment
(ES) can have a mixed of both leaf and root ACs with each AC
designating a subnet (e.g., a VLAN).
I understand that different VLANs on the same ES could be roots or
leaves. I suppose it's more important to say that for the same
vlan,
different PEs on the same ES must have the same root/leaf
designation.
That¹s given.
Perhaps the first sentence could be reworded as the following to
capture
the above point:
While different ACs (VLANs) on the same ES could have different
root/leaf designation (some being roots and some being leaves),
the same VLAN does have the same root/leaf designation on all
PEs on the same ES.
That¹s fine. It makes it more clear.
For the following:
... the PEs with Leaf sites perform MAC learning in the
data-path over their Ethernet Segments, and advertise
reachability
in
EVPN MAC Advertisement routes which are imported only by PEs
with
at
least one Root site in the EVI. A PE with only Leaf sites will
not
import these routes. PEs with Root and/or Leaf sites may use the
Ethernet A-D routes for aliasing (in the case of multi-homed
segments) and for mass MAC withdrawal per [RFC 7432].
The above seems to contradict with the recommendation in Section
2.2.
If
the context is the scenario described in section 2.1 then that's
fine,
but the text does not have a clear context.
Agreed. Updated the section to indicate the context is section 2.1.
3.3.2 E-Tree without MAC Learning
The PEs implementing an E-Tree service need not perform MAC
learning
when the traffic flows between Root and Leaf sites are multicast
or
broadcast.
I suppose an "only" word should be added at the end of the above
sentence.
Agreed.
The fields of the IMET route are populated per the procedures
defined
in [RFC7432], and the route import rules are as described in
previous
sections.
The route import rules described in previous sections are for MAC
routes,
not IMET routes. Additionally, those rules may not be recommended,
so
might as well delete the last sentence.
Changed the last sentence to ³Š, and the multicast tunnel setup
criteria
are as described in the previous section.²
Section 3.3.1 talks about BUM procedures. That is not specific to
3.3.1
though. Perhaps extract that out to a separate section, and remove
the
BUM text from 3.3.2 as well.
I think it is OK.
The E-TREE Extended Community is encoded as an 8-octet value as
follows:
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=0x04 | Flags(1 Octet)|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | Leaf Label
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I assume the octect after the flags octet is also reserved=0.
Better
mark
it as "Reserved=0".
Agreed.
When it is used with Ethernet A-D per ES route, the leaf flag
SHOULD
be
set to 0 but ignored by the receiving routers. Therefore, why not
set
it
to 1 to be consistent the MAC/IP route case?
Because the flag is used for known unicast traffic and Leaf label
for
BUM
traffic. We don¹t want to mix the two.
Cheers,
Ali
Thanks.
Jeffrey
-----Original Message-----
From: BESS [mailto:[email protected]] On Behalf Of Thomas
Morin
Sent: Tuesday, January 19, 2016 3:51 AM
To: BESS <[email protected]>;
[email protected]
Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree
Hello Working Group,
This email starts a Working Group Last Call on
draft-ietf-bess-evpn-etree [1] which is considered mature and
ready
for
a final working group review.
Please read the document if you haven't read the most recent
version
yet
(-03), and send your comments to the list, no later than *February
the
2nd* (2016-02-02).
This is not only a call for comments on the document, but also a
call
of
support for its publication.
*Coincidentally*, we are also polling for knowledge of any IPR
that
applies to draft-ietf-bess-evpn-etree, to ensure that IPR has been
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879,
3669
and 5378 for more details).
*If* you are listed as a document author or contributor of
draft-ietf-bess-evpn-etree please respond to this email and
indicate
whether or not you are aware of any relevant IPR.
Thank you,
Thomas/Martin
[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree
