Greetings:
The IDR WG has reached consensus to adopt draft-xu-idr-fare-08. The authors
should submit the draft as draft-ietf-idr-fare-00.
In this discussion, there were a few notable comments:
1. (Robert Raszuk): This draft allows finer granularity weighted load balancing
for static (or
very slow-changing) discrepancies in bandwidth asymmetry across CLOS topology
paths.
Shipping implementations lack support for cumulative bw and minimum bw
advertisements among ECMP links.
2. (Shraddha Hedge)
"I believe that ability to send multiple bandwidth communities is useful. In a
traditional MPLS VPN network, there is a BGP overlay and IGP underlay.
* The BGP-carried link bandwidth is used to load-balance traffic based on
external bandwidth availability, and
* the IGP bandwidth based on internal network bandwidth availability so [it
is] possible to apply two levels of bandwidth-based load-balancing.
In a DC network BGP plays the role of underlay transport. Many times the
service prefixes are injected into the fabric in DC.
Carrying two different bandwidth values is useful to appropriately balance the
traffic based on external and internal bandwidth availability."
draft-xu-idr-fare proposes a path bandwidth community, which is a good starting
point for the WG to work on.
3. [Stephane Litowski] - erroneous assumptions about RFC10005
(draft-ietf-bess-ebgp-dmz) are wrong (likely outdated)
* RFC10005 supports transitive community,
* draft-xu-idr-fare link states RFC10005 carries external link BW, but
the actual definition from RFC has a wider scope:
"The Link Bandwidth Extended Community is defined as a BGP extended
community that carries the bandwidth information of a router (represented by
BGP next hop) that is connecting to a remote network. ".
4. [Jeff Tantsura and Stephane Litowski] statements that implementations of
draft-ietf-bess-ebgp-dmz
(Cumulus, FRR, EOS, IOS-* ) plus the policy in those implementations is
sufficient for AI Clusters or hyperscale DCs.
* Suggestion that FARE's single-session three-stage MIN-Then-SUM does not
require an extended community.
* Only the five-stage case carries two differently scoped values; RFC 10005
Sections 3.1 and 4 already provides two communities on one prefix.
* Publish additional use cases as separate drafts, building on top of
existing encodings, that complement it rather than creating ambiguity.
[Robert, Shradda, authors and others do not agree with Jeff and Stephane]
The chairs note there is a problem and interest in developing a standardized
solution. We have suggested clarifications prior to publication to the authors
to correct erroneous assumptions.
IDR will WG LC this work in IDR and BESS to keep alignment with
draft-ietf-bess-ebgp-dmz.
Cheers, Sue
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
