Sami, I don't believe there was closure on this issue.
I think the text around the option TLV being RECOMMENDED should be tightened so that it's recommended only when needed. The way the draft is currently written, it sounds like it is recommending that the TLV always be carried if multihoming is in use. But this is not necessary or even valuable if Local Bias is in use. On Wed, Jul 13, 2022 at 12:12 AM Anoop Ghanwani <an...@alumni.duke.edu> wrote: > Hi Sami, > > Thanks for updating the doc. > > Regarding this: > >>> > > I find this statement confusing > > > > While "local-bias" MUST be supported along with GENEVE encapsulation, > > the use of the Ethernet option-TLV is RECOMMENDED to follow the same > > procedures used by EVPN MPLS. > > > > > > I'm not sure how it helps to carry an extra TLV when it is known > > that its absence or presence results in identical behavior. > > > > Sami: The new TLV is not there only for local bias! It is there for bum and > leaf/root indications too. So, we can’t simply not carry it. As for the text > above, we are saying setting the ESI label in the TLV will allow us to follow > the same Split horizon behavior of MPLS-EVPN with no need for local bias. It > is true local bias must be supported but this mechanism will work too if > available given that it is optional. > > >>> > > I'm not sure I follow what you're saying. The new TLV is actually not > needed for the Local Bias case because we already know how to make that > case work without it. It is, however, needed for the non-Local Bias case. > What value is to be had by knowing the frame was a BUM frame? Since the > encapsulated frame is an L2 frame, the I/G bit of the address will say if > it B or M (from BUM). And if it was unknown unicast and the address is > unknown at the receiving VTEP, then it will be treated as U, otherwise if > the address is known, it will be forwarded normally (just as happens today > in VXLAN without this TLV). So I'm not understanding what value we get by > carrying this TLV for Local Bias. The statement above says we want to > carry it for consistency. I'm asking why that consistency is important. > > Thanks, > Anoop > > On Mon, May 23, 2022 at 9:38 PM Boutros, Sami <sbout...@ciena.com> wrote: > >> Hi Anoop, >> >> >> >> Please see comments inline below in red. I updated the document with your >> relevant comments and uploaded it >> >> >> >> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-geneve-04.txt >> >> >> >> Thanks, >> >> >> >> Sami >> >> >> >> Technical comments >> >> >> >> Section 4.1 >> >> >> >> I find this statement confusing >> >> >> >> While "local-bias" MUST be supported along with GENEVE encapsulation, >> >> the use of the Ethernet option-TLV is RECOMMENDED to follow the same >> >> procedures used by EVPN MPLS. >> >> >> >> >> >> I'm not sure how it helps to carry an extra TLV when it is known >> >> that its absence or presence results in identical behavior. >> >> >> >> Sami: The new TLV is not there only for local bias! It is there for bum and >> leaf/root indications too. So, we can’t simply not carry it. As for the text >> above, we are saying setting the ESI label in the TLV will allow us to >> follow the same Split horizon behavior of MPLS-EVPN with no need for local >> bias. It is true local bias must be supported but this mechanism will work >> too if available given that it is optional. >> >> >> >> I also find the encoding confusing. Why is the Type=0, instead of >> >> using EVPN-OPTION with a length of 0x1 instead of 0x2? >> >> What does Type=0 indicate? Is this assigned by IANA? >> >> >> >> Sami: Fixed type to be EVPN-OPTION not 0, and yes we request this from IANA >> as per the draft text. >> >> >> >> >> >> Section 6 >> >> >> >> What is inter-AS option B? Can we provide a reference? >> >> >> >> Sami: This is a well-known inter-AS option however it is described in the >> document itself as follow: >> >> “For inter-AS option B, the ASBRs re-advertise these routes >> >> with NEXT_HOP attribute set to their IP addresses as per <xref >> target="RFC4271"/>.</t>” >> >> >> >> >> >> >> >> Section 8 >> >> >> >> Doesn't IANA also need to allocate a codepoint for the >> >> EVPN-OPTION type? >> >> >> >> -- >> >> >> >> Editorial comments >> >> >> >> Entire document >> >> >> >> - 3 of the references listed as drafts are now RFCs. Those should >> >> be fixed both in the reference section and in the text. >> >> >> >> - There are several uses of GENEVE and Geneve in the document. >> >> Recommend replacing GENEVE with Geneve, including in the >> >> abbreviations and terminology section. >> >> >> >> Section 1 >> >> >> >> Change >> >> >> >> This EVPN control plane extension will allow an NVE to express what >> >> Geneve option TLV types it is capable of receiving from, or sending >> >> to, over the Geneve tunnel with its peers. >> >> >> >> To >> >> >> >> This EVPN control plane extension will allow an NVE to express what >> >> Geneve option TLV types it is capable of receiving or sending >> >> over the Geneve tunnel with its peers. >> >> >> >> >> >> Section 4 >> >> >> >> Change >> >> >> >> This document adds an extension to the [I-D.ietf-nvo3-geneve >> >> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-03#ref-I-D.ietf-nvo3-geneve >> [datatracker.ietf.org] >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-03*ref-I-D.ietf-nvo3-geneve__;Iw!!OSsGDw!exKF4W-AN6UMWhBDbmrRhWuKAJWoOMZJXwfAOG8JzpPu08y7cXY41yryLsiyXg$>>] >> >> encapsulation that are relevant to the operation of EVPN. >> >> >> >> To >> >> >> >> This document adds an extension to the [I-D.ietf-nvo3-geneve >> >> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-03#ref-I-D.ietf-nvo3-geneve >> [datatracker.ietf.org] >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-geneve-03*ref-I-D.ietf-nvo3-geneve__;Iw!!OSsGDw!exKF4W-AN6UMWhBDbmrRhWuKAJWoOMZJXwfAOG8JzpPu08y7cXY41yryLsiyXg$>>] >> >> encapsulation that is relevant to the operation of EVPN. >> >> >> >> End >> >> >> >> Section 4.1 >> >> >> >> Change >> >> >> >> [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses >> >> ingress replication to flood unknown unicast traffic to the egress >> >> NVEs, the ingress NVE needs to indicate to the egress NVE that the >> >> Encapsulated packet is a BUM traffic type. >> >> >> >> To >> >> >> >> [I-D.ietf-bess-evpn-overlay] describes when an ingress NVE uses >> >> ingress replication to flood unknown unicast traffic to the egress >> >> NVEs, the ingress NVE needs to indicate to the egress NVE that the >> >> Encapsulated packet is a BUM packet. >> >> >> >> >> >> Change >> >> >> >> For GENEVE, we need a bit to for this purpose. >> >> >> >> To >> >> >> >> For GENEVE, we need a bit for this purpose. >> >> >> >> >> >> Expand first use of AC and add to abbreviations and terminology. >> >> >> >> ecnapsulations -> encapsulations >> >> >> >> >> >> GENVE -> Geneve >> >> >> >> (There are 2 instances of this.) >> >> >> >> >> >> "20- bit MPLS label" -> "20-bit MPLS label" >> >> >> >> >> >> Add figure captions for the 2 figures showing the TLVs. >> >> >> >> Expand first use of ES and ESI and add to abbreviations and terminology. >> >> >> >> Change >> >> >> >> The ESI-label value is encoded in the high-order 20 bits >> >> of the Source-ESI field. >> >> >> >> To >> >> >> >> The ESI-label value is encoded in the high-order 20 bits >> >> of the Source-ID field. >> >> >> >> >> >> Change >> >> >> >> The egress NVEs that make use of ESIs in the data path because they >> >> have a local multi-homed ES or support [RFC8317 >> >> <https://datatracker.ietf.org/doc/html/rfc8317 [datatracker.ietf.org] >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8317__;!!OSsGDw!exKF4W-AN6UMWhBDbmrRhWuKAJWoOMZJXwfAOG8JzpPu08y7cXY41yrtjgdm9A$>>] >> SHOULD advertise >> >> their Ethernet A-D per-ES routes along with the Geneve tunnel sub-TLV >> >> and in addition to the ESI-label Extended Community. >> >> >> >> Remove "and". >> >> >> >> On Tue, Sep 28, 2021 at 8:47 AM Boutros, Sami <sboutros= >> 40ciena....@dmarc.ietf.org> wrote: >> >> I support the publication and not aware of any IPR. >> >> >> >> Thanks, >> >> >> >> Sami >> >> *From: *"UTTARO, JAMES" <ju1...@att.com> >> *Date: *Tuesday, September 28, 2021 at 7:29 AM >> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" < >> jorge.raba...@nokia.com>, "Bocci, Matthew (Nokia - GB)" < >> matthew.bo...@nokia.com>, "bess@ietf.org" <bess@ietf.org> >> *Cc: *"draft-ietf-bess-evpn-gen...@ietf.org" < >> draft-ietf-bess-evpn-gen...@ietf.org> >> *Subject: *[**EXTERNAL**] RE: CORRECTION WG Last Call, IPR and >> Implementation Poll for *draft-ietf-bess-evpn-geneve-03* >> *Resent-From: *<alias-boun...@ietf.org> >> *Resent-To: *<saja...@cisco.com>, <jorge.raba...@nokia.com>, < >> sbout...@ciena.com>, <jdr...@juniper.net>, <aldrin.i...@gmail.com> >> *Resent-Date: *Tuesday, September 28, 2021 at 7:29 AM >> >> >> >> *Support.* >> >> >> >> *Thanks,* >> >> * Jim Uttaro* >> >> >> >> *From:* BESS <bess-boun...@ietf.org> *On Behalf Of *Rabadan, Jorge >> (Nokia - US/Mountain View) >> *Sent:* Tuesday, September 28, 2021 5:04 AM >> *To:* Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; >> bess@ietf.org >> *Cc:* draft-ietf-bess-evpn-gen...@ietf.org >> *Subject:* Re: [bess] CORRECTION WG Last Call, IPR and Implementation >> Poll for *draft-ietf-bess-evpn-geneve-03* >> >> >> >> As co-author, I support this document for publication as standards track >> RFC. >> >> Not aware of any relevant IPR. >> >> >> >> Thanks. >> >> Jorge >> >> >> >> *From: *Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com> >> *Date: *Tuesday, September 28, 2021 at 11:00 AM >> *To: *bess@ietf.org <bess@ietf.org> >> *Cc: *draft-ietf-bess-evpn-gen...@ietf.org < >> draft-ietf-bess-evpn-gen...@ietf.org> >> *Subject: *CORRECTION WG Last Call, IPR and Implementation Poll for >> *draft-ietf-bess-evpn-geneve-03* >> >> Folks >> >> >> >> Please note this WG last call is for version 03 of the draft (not 02 as >> stated in the subject line of the email) >> >> >> >> The link to the draft is: draft-ietf-bess-evpn-geneve-03 - EVPN control >> plane for Geneve >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/__;!!BhdT!3tci5SzjjkNZnS9HTgZ4_0eO7MKI-qOtnFvfS68Ac-DC-0H7t88nFLp5C8I$> >> >> >> >> Apologies for the error. >> >> >> >> Matthew >> >> >> >> *From: *BESS <bess-boun...@ietf.org> on behalf of Bocci, Matthew (Nokia >> - GB) <matthew.bo...@nokia.com> >> *Date: *Tuesday, 28 September 2021 at 09:56 >> *To: *bess@ietf.org <bess@ietf.org> >> *Cc: *draft-ietf-bess-evpn-gen...@ietf.org < >> draft-ietf-bess-evpn-gen...@ietf.org> >> *Subject: *[bess] WG Last Call, IPR and Implementation Poll for >> draft-ietf-bess-evpn-geneve-02 >> >> This email starts a two-week working group last call for >> draft-ietf-bess-evpn-geneve-03 >> [1] >> >> >> >> Please review the draft and send any comments to the BESS list. Also, >> please indicate if you support publishing the draft as a Standards Track >> RFC. >> >> >> >> This poll runs until the 15th October 2021 >> >> >> >> We are also polling for knowledge of any undisclosed IPR that applies to >> this document, 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 an author or a contributor of this document, please >> respond to this email and indicate whether or not you are aware of any >> relevant undisclosed IPR. The document won't progress without answers from >> all the authors and contributors. >> >> There are currently no IPR disclosures. >> >> >> >> In addition, we are polling for knowledge of implementations of this >> draft, per the BESS policy in [2]. >> >> >> >> Thank you, >> >> Matthew & Stephane >> >> >> >> >> >> [1] draft-ietf-bess-evpn-geneve-02 - EVPN control plane for Geneve >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/__;!!BhdT!3tci5SzjjkNZnS9HTgZ4_0eO7MKI-qOtnFvfS68Ac-DC-0H7t88nFLp5C8I$> >> >> [2] >> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw__;!!BhdT!3tci5SzjjkNZnS9HTgZ4_0eO7MKI-qOtnFvfS68Ac-DC-0H7t88nJ1roR2g$> >> >> >> >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess [ietf.org] >> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!OSsGDw!exKF4W-AN6UMWhBDbmrRhWuKAJWoOMZJXwfAOG8JzpPu08y7cXY41yrRQSH3eQ$> >> >>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
