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.
