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

From: Thomas Morin <[email-masked]>
Date: Tue, 19 Jan 2016 09:51:03 +0100

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

---

From: "HENDERICKX, Wim (Wim)" <[email-masked]>
Date: Tue, 19 Jan 2016 13:29:23 +0000

As a co-author I believe this doc is mature and stable for final WG review.
Not aware of IPR related to the draft

On 19/01/16 00:51, "BESS on behalf of Thomas Morin" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>BESS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bess

---

From: John E Drake <[email-masked]>
Date: Tue, 19 Jan 2016 16:31:01 +0000

Support.  I'm not aware of any undisclosed IPR.

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Thomas Morin
> Sent: Tuesday, January 19, 2016 3:51 AM
> To: BESS; [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).
> 
> *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
>

---

From: "RABADAN, Jorge (Jorge)" <[email-masked]>
Date: Tue, 19 Jan 2016 18:33:38 +0000

As co-author, I fully support this document for publication. 
Not aware of any relevant IPR.

Thank you.
Jorge

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 25 Jan 2016 05:40:29 +0000

Support publication of this document as a co-author and I am not aware of
any IPR that hasn¹t been disclosed.

Cheers,
Ali

---

From: "Luay" <[email-masked]>
Date: Mon, 25 Jan 2016 05:25:06 -0600

Support

Thanks,
Luay

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Thomas Morin
Sent: Tuesday, January 19, 2016 2:51 AM
To: BESS; [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.

*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

---

From: Wen Lin <[email-masked]>
Date: Mon, 25 Jan 2016 14:46:30 +0000

Fully support as a co-author. I am not aware of any un-disclosed IPR.

Thanks,
Wen

>applies
>whether

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 25 Jan 2016 15:07:11 +0000

Fully support as co-author, no IRP that I am aware of.

Thanks,
	Jim Uttaro

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Wen Lin
Sent: Monday, January 25, 2016 9:47 AM
To: EXT - [email-masked]; 'BESS'; [email-masked]
Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree

Thanks,
Wen

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Mon, 25 Jan 2016 18:38:31 +0000

Support as co-author. I'm not aware of any IPR beyond what has already
been disclosed.

Thanks,
Samer

---

From: Poorna Pushkala B <[email-masked]>
Date: Tue, 26 Jan 2016 19:04:55 +0000

Hi

In section 5.1 of version 3 of the draft, the subtype is mentioned as “0x05”, whereas the figure below shows it as “0x04”.
Can the authors kindly fix it? Thanks.

Regards
Poorna

5.1 <https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-03#section-5.1> E-TREE Extended Community

   This Extended Community is a new transitive Extended Community having
   a Type field value of 0x06 (EVPN) and the Sub-Type 0x05. 

        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                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 28 Jan 2016 01:26:29 +0000

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

Additionally, why is 32K mentioned? I can understand the 64k part.

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

   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?

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

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.

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.

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.

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. 

   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.

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.

   The E-TREE Extended Community is encoded as an 8-octet value as
   follows:

        0                   1                   2                   3

I assume the octect after the flags octet is also reserved=0. Better mark it as "Reserved=0".

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?

Thanks.
Jeffrey

> To: BESS <[email-masked]>; [email-masked]

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Sun, 31 Jan 2016 16:13:58 +0000

Support publication of this draft.
It is a good document for the Etree framework to EVPN.

Thanks,
―Satya

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 1 Feb 2016 02:53:18 +0000

Thanks. This has already been noted and IANA section has been updated
accordingly.

Cheers,
Ali 

On 1/26/16, 11:04 AM, "BESS on behalf of Poorna Pushkala B"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi
>
>In section 5.1 of version 3 of the draft, the subtype is mentioned as
>³0x05², whereas the figure below shows it as ³0x04².
>5.1 
><https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-03#section-5.1>
>E-TREE Extended Community
>
>>>draft-ietf-bess-evpn-etree

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 1 Feb 2016 07:03:36 +0000

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

>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

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

>Should "egress" be "ingress" in the above paragraph? Or simply removed?

Nice catch! It is ³ingress². It is now corrected.

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

>   the same VLAN does have the same root/leaf designation on all

That¹s fine. It makes it more clear.

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

>I suppose an "only" word should be added at the end of the above sentence.

Agreed.

>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

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