Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 6 Jun 2016 16:57:11 +0000

Hi Thomas,

Is there anything else you need from me or other co-authors to progress
this daft? The WG LC was completed before last IETF.

Regards,
Ali 

On 5/24/16, 12:18 AM, "Ali Sajassi (sajassi)" <[email-masked]> wrote:

>
>Hi Thomas,
>
>Can you please progress this draft. The WG LC was completed on 3/29 and
>all comments except a single optional comment were addressed before the
>last IETF. The single optional comment was addressed couple of weeks ago
>and the draft was re-published then.
>
>Regards,
>Ali
>
>
>On 5/11/16, 10:30 PM, "BESS on behalf of Ali Sajassi (sajassi)"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>
>>Hi Thomas,
>>
>>I just made the final edits to evpn-etree draft and published it as
>>rev05.
>>
>>Regards,
>>Ali
>>
>>On 3/29/16, 2:49 AM, "[email-masked]" <[email-masked]>
>>wrote:
>>
>>>Hi everyone,
>>>
>>>This WG Last Call is now closed and the document will move to the next
>>>steps toward publication.
>>>
>>>The modification mentioned below will be incorporated in next release.
>>>
>>>Best,
>>>
>>>-Thomas
>>>
>>>
>>>
>>>2016-03-15, Ali Sajassi (sajassi):
>>>>
>>>> Jeffrey,
>>>>
>>>>
>>>>
>>>> On 2/1/16, 2:41 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]>
>>>>wrote:
>>>>
>>>>> Ali,
>>>>>
>>>>> One more question about PBB-EVPN.
>>>>>
>>>>> For the regular EVPN, section 3.3.2 talks about a situation where the
>>>>> only traffic is BUM. There is no need for mac learning in that
>>>>>situation.
>>>>>
>>>>> For PBB-EVPN, I assume this is also possible. With this, there is no
>>>>>need
>>>>> to advertise per-ES B-mac addresses - a single pair of global
>>>>>root/leaf
>>>>> B-mac addresses are enough.
>>>>>
>>>>> Perhaps this can be mentioned for parity/completeness. Of course,
>>>>>this
>>>>>is
>>>>> not a big deal and either way it's fine - but I do want to ask to
>>>>>confirm
>>>>> my understanding.
>>>>
>>>> We’ll do.
>>>>
>>>> Cheers,
>>>> Ali
>>>>
>>>>>
>>>>> Jeffrey
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
>>>>>> Sent: Monday, February 01, 2016 2:04 AM
>>>>>> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; EXT -
>>>>>> [email-masked] <[email-masked]>; BESS
>>>>>><[email-masked]>;
>>>>>> [email-masked]
>>>>>> 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-masked] on behalf of [email-masked]> 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-masked]] On Behalf Of Thomas
>>>>>>>>Morin
>>>>>>>> Sent: Tuesday, January 19, 2016 3:51 AM
>>>>>>>> To: BESS <[email-masked]>;
>>>>>>>>[email-masked]
>>>>>>>> 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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> BESS mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> BESS mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/bess
>>>>>
>>>>
>>>
>>>
>>>________________________________________________________________________
>>>_
>>>_
>>>_______________________________________________
>>>
>>>Ce message et ses pieces jointes peuvent contenir des informations
>>>confidentielles ou privilegiees et ne doivent donc
>>>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>>recu ce message par erreur, veuillez le signaler
>>>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>>electroniques etant susceptibles d'alteration,
>>>Orange decline toute responsabilite si ce message a ete altere, deforme
>>>ou falsifie. Merci.
>>>
>>>This message and its attachments may contain confidential or privileged
>>>information that may be protected by law;
>>>they should not be distributed, used or copied without authorisation.
>>>If you have received this email in error, please notify the sender and
>>>delete this message and its attachments.
>>>As emails may be altered, Orange is not liable for messages that have
>>>been modified, changed or falsified.
>>>Thank you.
>>>
>>
>>_______________________________________________
>>BESS mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/bess
>

---

From: Thomas Morin <[email-masked]>
Date: Wed, 8 Jun 2016 12:12:54 +0200

Hi Ali,

I haven't started yet the shepherd write-up, but it's on my todo list.

I will do a shepherd review along with the write-up, which may lead to 
resolving points with authors, but I can't tell before I get to do it.

One thing that can be useful to collect right now is any information you 
may have on existing implementations (although this draft was WGLC'd 
before we setup BESS one-implementation policy, this question has been 
part of shepherd write-up question, even if its not considered a gating 
criteria).

Thanks in advance,

-Thomas

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 8 Jun 2016 16:39:03 +0000

Hi Thomas,

I and other co-authors will be looking forward to receiving your write-up
and answer the question regarding existing implementation. From my side, I
have the info and I am sure it is the same for other co-authors. Thanks
for giving the heads-up since some co-authors need to check with their
PLMs before making public statement regarding their implementation.

Regards,
Ali

---

From: John E Drake <[email-masked]>
Date: Thu, 9 Jun 2016 14:33:19 +0000

Thomas,

E-TREE for EVPN (https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-05) will be GA this year.  Root or leaf role can be defined on a port or VLAN basis, and Single-Active and All-Active multi-homing are supported.  E-TREE for PBB-EVPN is on the roadmap.

Yours Irrespectively,

John

> From: BESS [mailto:[email-masked]] On Behalf Of Thomas Morin
> Sent: Wednesday, June 08, 2016 6:13 AM
> To: Ali Sajassi (sajassi); Jeffrey (Zhaohui) Zhang; BESS; draft-ietf-bess-evpn-
> [email-masked]
> I will do a shepherd review along with the write-up, which may lead to resolving points with
> authors, but I can't tell before I get to do it.
> 
> One thing that can be useful to collect right now is any information you may have on
> existing implementations (although this draft was WGLC'd before we setup BESS one-
> implementation policy, this question has been part of shepherd write-up question, even if
> its not considered a gating criteria).
> 
> Thanks in advance,
> 
> -Thomas
> 
> 
> > Is there anything else you need from me or other co-authors to
> > progress this daft? The WG LC was completed before last IETF.
> >
> > Regards,
> > Ali
> >
> >> Can you please progress this draft. The WG LC was completed on 3/29
> >> and all comments except a single optional comment were addressed
> >> before the last IETF. The single optional comment was addressed
> >> couple of weeks ago and the draft was re-published then.
> >>
> >> Regards,
> >> Ali
> >>
> >>
> >>>> This WG Last Call is now closed and the document will move to the
> >>>> next steps toward publication.
> >>>>
> >>>>>> For the regular EVPN, section 3.3.2 talks about a situation where
> >>>>>> the only traffic is BUM. There is no need for mac learning in
> >>>>>> that situation.
> >>>>>>
> >>>>>> For PBB-EVPN, I assume this is also possible. With this, there is
> >>>>>> no need to advertise per-ES B-mac addresses - a single pair of
> >>>>>> global root/leaf B-mac addresses are enough.
> >>>>>>
> >>>>>> this is not a big deal and either way it's fine - but I do want
> >>>>>> to ask to confirm my understanding.
> >>>>>
> >>>>> We’ll do.
> >>>>>
> >>>>> Cheers,
> >>>>> Ali
> >>>>>
> >>>>>>
> >>>>>> Jeffrey
> >>>>>>
> >>>>>>> <[email-masked]>; [email-masked]
> >>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>> I was involved in relevant discussions, and have reviewed once
> >>>>>>>> more for this LC.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>    (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.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> with at
> >>>>>>>>    least one Root site in the EVI. A PE with only Leaf sites
> >>>>>>>> will not
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>>>    when the traffic flows between Root and Leaf sites are
> >>>>>>>> multicast or
> >>>>>>>>    broadcast.
> >>>>>>>>
> >>>>>>>> not IMET routes. Additionally, those rules may not be
> >>>>>>>> recommended, so might as well delete the last sentence.
> >>>>>>>
> >>>>>>> criteria are as described in the previous section.²
> >>>>>>>
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> SHOULD be set to 0 but ignored by the receiving routers.
> >>>>>>>> Therefore, why not set
> >>>>>>> it
> >>>>>>> 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
> >>>>>>>>
> >>>>>>>>> This is not only a call for comments on the document, but also
> >>>>>>>>> a call
> >>>>>>> of
> >>>>>>>>> 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
> >>>>>>>>> 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
> >>>>>>>>>
>

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Fri, 10 Jun 2016 03:56:34 +0000

We will release our code next year in-line with the draft