Here's a proposed change: OLD
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. NEW While "local-bias" MUST be supported along with Geneve encapsulation, the use of the Ethernet option-TLV is required if not using local-bias and instead following procedures used by EVPN MPLS. This allows implementations that implement only local bias to skip sending/implementing the TLV. Or are you trying to RECOMMEND that implementations also implement the EVPN MPLS procedures in addition to local bias? If so, I would word the text as: While "local-bias" MUST be supported along with Geneve encapsulation and that doesn't require the use of the Ethernet option-TLV, it is RECOMMENDED that Geneve implementations also implement the same procedures used by EVPN MPLS. On Sat, Dec 17, 2022 at 6:33 PM Anoop Ghanwani <an...@alumni.duke.edu> wrote: > Sami, > > Why is it recommended to carry the TLV if local bias is in use? (I > understand the need for it if we're not using local bias.) > > Anoop > > On Sat, Dec 17, 2022 at 2:06 PM Boutros, Sami <sbout...@ciena.com> wrote: > >> I’m not sure what tightening you are recommending, I am out of ideas of >> how to tighten this, may be you can propose something. >> >> >> >> It is quite clear to me and to the authors, and I hope to everyone else, >> how the TLV can be used for SH as a mechanism similar to local bias, as >> well it can be used when ETREE support is needed. >> >> >> >> Thanks, >> >> >> Sami >> >> *From: *Anoop Ghanwani <an...@alumni.duke.edu> >> *Date: *Saturday, December 17, 2022 at 1:25 PM >> *To: *Boutros, Sami <sbout...@ciena.com> >> *Cc: *Boutros, Sami <sboutros=40ciena....@dmarc.ietf.org>, UTTARO, JAMES >> <ju1...@att.com>, Rabadan, Jorge (Nokia - US/Mountain View) < >> jorge.raba...@nokia.com>, Bocci, Matthew (Nokia - GB) < >> matthew.bo...@nokia.com>, bess@ietf.org <bess@ietf.org>, >> draft-ietf-bess-evpn-gen...@ietf.org < >> draft-ietf-bess-evpn-gen...@ietf.org> >> *Subject: *Re: [bess] [**EXTERNAL**] RE: CORRECTION WG Last Call, IPR >> and Implementation Poll for *draft-ietf-bess-evpn-geneve-03* >> >> 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 >> >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
