Hi Alvaro and Robert, Thanks to both for your review. I am in agreement that https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 needs to be refreshed. Please see inline <Satya>
From: Idr <[email protected]> on behalf of Robert Raszuk <[email protected]> Date: Thursday, June 22, 2023 at 11:58 AM To: Alvaro Retana <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Idr] [bess] Request for IDR WG review of draft-ietf-bess-ebgp-dmz-02 Hi, > I agree that the use case presented should be addressed, but I don't think > the document is ready for WGLC, Indeed. In fact it is clear by now that https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 needs to be rewritten to accommodate both 4 octet ASNs (instead of proposing use of AS_TRANS) as well as define support for transitive community use. <Satya> Yes, we should accommodate the 4-byte ASNs. Regarding the transitivity, please see below. On the last one inspection of the IANA registry reveleas subtype 0x04 as "Juniper Transitive Link Bandwidth" and the date 25th April 2023. [cid:ii_lj7i5vi70] Interesting especially that I do not recall any discussions in IDR about this this year ... <Satya> I also did not notice this, although as per earlier conversations with Juniper folks, I was aware that LB is implemented as transitive there. On the other hand, Cisco, Arista etc. have implemented it as per the above draft i.e. optional non-transitive. Also, as per the draft, when the next-hop is reset, the received LB should be removed. This imposition, however, does allow regenerating a new LB that will be associated with the new advertised next-hop and that’s what is done in some of the implementations that I know of. Therefore, the transitivity requirement that you mention here really only applies to a case where the next-hop is unchanged when advertising the BGP update across the EBGP boundary. Despite this divergence in already deployed implementations, in order that implementations work with each other, we will require some specified procedures with knobs etc. In fact, we have an offline thread initiated on this. Cheers, R. On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana <[email protected]<mailto:[email protected]>> wrote: Hi! I took a look at this document. I agree that the use case presented should be addressed, but I don't think the document is ready for WGLC, or even necessary (see below). In fact, I'm having a hard time understanding how it can progress if it depends on an expired draft, the proposed changes are not specific, etc. The meat of the document (beyond the explanation of the use case) is (from §1): The new use-case mandates that the router calculates the aggregated link-bandwidth, regenerate the DMZ link bandwidth extended community, and advertise it to EBGP peers. I-D.ietf-idr-link-bandwidth expired in 2018. I have seen no indication from the authors that it will be refreshed. I know that implementations exist, but that is orthogonal to the need to reference this document as Normative. <Satya> I think we should refresh the above. We had requested a refresh in 2018 when draft-ietf-bess-ebgp-dmz was published. It was refreshed. The rest of the document is mostly dedicated to describing the use case, but the description of the actions is loose (at best); for example, there is no specification about how "the router calculates the aggregated link-bandwidth". Yes, we can all guess/assume what it means, but that needs to be documented. <Satya> Ack. We can put a text in the document, mentioning this. Assuming that I-D.ietf-idr-link-bandwidth is revived, the use case from this document could be covered there. In fact, there is already a hint to the ability to regenerate the community based on received information (from §3): Alternatively CEs of the site, when advertising IP routes to PE1 and PE2, could add the link bandwith community to these advertisements, in which case PE1 and PE2, when originating VPN-IP routes, would use the bandwidth value from the IP routes they received from the CEs to construct the link bandwidth community carried by these VPN-IP routes. In summary, given that this document depends on I-D.ietf-idr-link-bandwidth, I believe that the aggregate behavior can be "merged" into it. <Satya> Yes, although regeneration is hinted, the distinguishing aspect is the aggregation in our draft. We can certainly merge both (need to discuss with other authors) and list it as a use-case just as you mentioned. But important thing now is to make the original draft active. Alvaro. Best, --Satya On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) ([email protected]<mailto:[email protected]>) wrote: Hi IDR WG The BESS chairs would like to request review of draft-ietf-bess-ebgp-dmz-02 (draft-ietf-bess-ebgp-dmz-02 - Cumulative DMZ Link Bandwidth and load-balancing<https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/>), for which we are considering starting a working group last call. Please could you review the draft and post any comment to the BESS mailing list ([email protected]<mailto:[email protected]>) by 25th June 2023. Thanks Matthew and Stephane _______________________________________________ BESS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
