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. On the last one inspection of the IANA registry reveleas subtype 0x04 as "Juniper Transitive Link Bandwidth" and the date 25th April 2023. [image: image.png] Interesting especially that I do not recall any discussions in IDR about this this year ... Cheers, R. On Thu, Jun 22, 2023 at 7:20 PM Alvaro Retana <aretana.i...@gmail.com> 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. > > > 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. > > 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. > > > Alvaro. > > On May 25, 2023 at 5:43:55 AM, Matthew Bocci (Nokia) ( > matthew.bo...@nokia.com) 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 (bess@ietf.org) by 25th June 2023. > > > > Thanks > > > > Matthew and Stephane > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
