Hi Jeff, Many thanks for the confirmation and detailed explanation / review. We will move forward with the new code point for EVPN.
With respect to your comment in the last paragraph, your understanding is correct - primary use case for this attribute is for it to be carried in Type 1 route within and across EVPN domains. It would not be stripped at the domain border. Will update the text to make sure this is clear. Thanks, Neeraj On Wed, Nov 11, 2020 at 12:09 PM Jeffrey Haas <[email protected]> wrote: > Neeraj, > > Thanks for reminding me to comment on the draft's Link Bandwidth > procedures. > > The existing link bandwidth feature, defined in an expired Internet-Draft, > is a non-transitive extended community. > > Part of the comments I'd given at prior BESS sessions at the microphone > was that Juniper has used a similar code point with the transitive > behavior. This does create an interoperability problem between the > published non-transitive and Juniper's transitive extended community. > > Part of that discussion was with regards to whether this was motivation > for Juniper to help clean up that situation. I believe that based on the > text in your current draft that making using of the transitive code point > used by Juniper is likely not a good fit for your EVPN use case. Based on > that, I believe the request in the Internet-Draft for a new transitive code > point is appropriate and I have no objections or further concerns. > > By using split code points for general purpose BGP link bandwidth and EVPN > link bandwidth, we accommodate not only load balancing at the EVPN level, > but help avoid confusion when EVPN routes' nexthops may recursively resolve > in some situations across other BGP transport routes that may have their > own link bandwidth available. Exactly how that interaction in recursive > resolution is implemented will likely be somewhat vendor dependent as it > currently is for existing BGP use cases of link-bandwidth. > > Section 4.2 notes that the signaling may be used in an inter-as > situation. If my reading of the draft is correct, then the expected use > case is primarily to add the new EVPN link bandwidth route on Type 1 > routes. If so, containing the scoping of the distribution of those routes > is mostly limited to a set of EVPN domains that interact with each other. > You may wish to consider whether guidance for stripping this new Extended > Community at such domain borders is necessary or not. > > Thanks for addressing my concerns. > > -- Jeff > > > On Oct 14, 2020, at 2:24 PM, Neeraj Malhotra <[email protected]> > wrote: > Hi John, Jeff, > > FYI - latest revision of this draft corrects the BW attribute to be > transitive inline with Ali's explanation below: > https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt > <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-07.txt__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M7uc4hpSk$>. > Please do let us know if there are any further concerns. > > 4.2. EVPN Link Bandwidth Extended Community > > > > A new EVPN Link Bandwidth extended community is defined to signal > > local ES link bandwidth to remote PEs. This extended-community is > > defined of type 0x06 (EVPN). IANA is requested to assign a sub-type > > value of 0x10 for the EVPN Link bandwidth extended community, of type > > 0x06 (EVPN). EVPN Link Bandwidth extended community is defined as > > transitive. > > > > Link bandwidth extended community described in [BGP-LINK-BW] for > > layer 3 VPNs was considered for re-use here. This Link bandwidth > > extended community is however defined in [BGP-LINK-BW] as optional > > non-transitive. Since it is not possible to change deployed behavior > > of extended-community defined in [BGP-LINK-BW], it was decided to > > define a new one. In inter-AS scenarios, link-bandwidth needs to be > > signaled to eBGP neighbors. When signaled across AS boundary, this > > attribute can be used to achieve optimal load-balancing towards > > source PEs from a different AS. This is applicable both when next- > > hop is changed or unchanged across AS boundaries. > > > > Thanks, > > Neeraj > > > On Thu, Jul 30, 2020 at 11:14 PM Ali Sajassi (sajassi) <sajassi= > [email protected]> wrote: > >> John, Jeff: >> >> >> >> During the presentation of draft-ietf-bess-evpn-unequal-lb -03 at the >> BESS WG meeting, you had a question/concern regarding why we are defining a >> new EC if we are doing conditional transitive. First, I’d like to make a >> correction to the preso by saying that the transitivity is not conditional >> and we will correct this in the next rev of the draft. So, the EC is simply >> transitive at all time. Given the EC defined in >> draft-ietf-idr-link-bandwidth-07.txt is non-transitive, we cannot use this >> EC for our application. That’s why we are defining a new one. >> >> >> >> Cheers, >> >> Ali >> >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!WpGNLTp80vY1SOBO7xUowqXjTj64Jwdl9QBfcynQ1zzzTYjC43p-e0M78itEAgE$> >> > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
