draft-ietf-bess-ebgp-dmz defines the 90+% of delpyments of draft-ietf-idr-link-bandwidth and those, who have deployed and are operating the networks with it do care about implementation semantics and interoperability.
It seems we all OK to progress the draft in IDR? As I said - I’d prefer not to merge the drafts and keep encoding separate from the main use case. I do envision different encodings and use cases in the future, the structure set will allow for innovation and iterations at max speed with minimum interdependescies.. This will also simplify RFI/RFQ process for the users of the technology. Section 3.4 of draft-ietf-idr-link-bandwidth is also clearly states that the computational semantics are out of scope, so this is in line. Name: the name of the draft is "Cumulative DMZ Link Bandwidth and load-balancing”, which is exactly what the draft defines, so this addresses Xiaohu’ comment. So far I have been speaking for myself and not my co-authors - please do speak up. Thanks, Jeff > On Jul 21, 2025, at 18:34, Tiger Xu <[email protected]> wrote: > > I agree with Robert’s opinion. The current value of draft-ietf-bess-ebgp-dmz > is to illustrate multiple use cases of the link-bandwidth attribute, IMHO. > Therefore, it’d be better to merge this draft into the link-bandwidth draft > as a use case section, or process it independently by renaming it as a use > case draft if needed. > > Best regards, > Xiaohu > > 发件人: Robert Raszuk <[email protected]> > 日期: 星期日, 2025年7月20日 23:59 > 收件人: Jeff Tantsura <[email protected]> > 抄送: IETF IDR WG <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]>, BESS <[email protected]>, > [email protected] <[email protected]> > 主题: [Idr] Re: [bess] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 > August, 2025) > > Jeff, > > If you look at section 3 of draft-ietf-idr-link-bandwidth it very well > allows for cumulative update of transitive Link Bandwidth Extended Community. > > It is up to the operator's configuration to make it cumulative or not. > > So with that what exactly is the value draft-ietf-bess-ebgp-dmz brings to the > table ? Currently it is Informational and relies on encoding defined in IDR > doc so if you want to proceed why would you not change the category to BCP > and move on ? > > Thx, > Robert > > > On Sun, Jul 20, 2025 at 3:19 PM Jeff Tantsura <[email protected] > <mailto:[email protected]>> wrote: >> Hi, >> >> I’d like to bring up a couple of points and suggestion of how to proceed. My >> experience is based on deploying BGP link bandwidth on 10.000+ BGP routers. >> >> >> Let’s establish the role of draft-ietf-bess-ebgp-dmz: >> >> As IETF we care about interoperability and stability of already deployed >> technologies, while draft-ietf-idr-link-bandwidth defines the community >> encoding, actual mass deployment (at hyperscale), and I would argue by far >> most deployments of the technology use cumulative approach, as described in >> draft-ietf-bess-ebgp-dmz draft. There’s quite some non BGP related tech that >> relies on that particular behaviour, standardization of this behaviour is >> rather important to preserve interoperability. There’s at least 4 >> implementations of draft-ietf-bess-ebgp-dmz >> I’m familiar with and perhaps more, I’m not aware of. >> >> When draft-ietf-idr-link-bandwidth had been refreshed co-authors of both >> drafts have had numerous discussions of how to proceed and the agreement >> reached was as follows: >> >> -draft-ietf-idr-link-bandwidth progresses in IDR and defines the encoding >> and transitivity, if another type of community is ever needed to encode BW >> related information, it would follow the same steps, thought another >> standard track document. >> >> -draft-ietf-bess-ebgp-dmz progresses in BESS as the main use case and if in >> the future, different type of >> computation is needed, another document would follow. >> >> >> My proposal: >> >> >> Progress >> draft-ietf-idr-link-bandwidth in IDR, it is ready for the WGLC >> >> Move >> draft-ietf-bess-ebgp-dmz to IDR >> Remove transitivity language and add references >> draft-ietf-idr-link-bandwidth as needed. >> Progress draft-ietf-bess-ebgp-dmz in IDR, it is ready for the WGLC. >> >> >> New work related to the technology (either new encodings or new computation >> types) would be addressed in new IDR >> drafts. >> >> Thanks, >> Jeff >> >>> On Jul 18, 2025, at 01:27, <[email protected] >>> <mailto:[email protected]>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Jeff, and folks, >>> >>> (cc-ing BESS and BESS chairs) >>> >>> Speaking as BESS chair, we think that there could be value to merge >>> draft-ietf-bess-ebgp-dmz and draft-ietf-idr-link-bandwidth. >>> >>> draft-ietf-bess-ebgp-dmz is currently informational and covers two things: >>> Allowing non-transitive LBW to be sent over eBGP: I think the LBW IDR draft >>> covers this in 3.1: >>> “Note: Implementations MAY provide a configuration option to send non- >>> transitive Link Bandwidth extended communities on external BGP >>> sessions.” >>> >>> Allowing some maths on the LBW of contributing multipaths and advertising >>> the computed value: the current IDR draft introduces this in 3.4. These >>> maths are essentially a local behavior, we can give an example, but likely >>> this doesn’t require standardization. >>> >>> Based on that draft-ietf-bess-ebgp-dmz becomes more a use case draft rather >>> than a draft which is specifying some new behavior and as BESS chairs, we >>> want to avoid this. draft-ietf-bess-ebgp-dmz will require significant text >>> rework if it needs to move forward as it makes some assumptions about IDR >>> LBW draft which are not true anymore. >>> >>> >>> We would like to hear opinions of both working group. >>> >>> Brgds, >>> >>> Stephane, Matthew, Jeffrey (BESS chairs) >>> >>> >>> From: Jeffrey Haas <[email protected] <mailto:[email protected]>> >>> Sent: Thursday, July 17, 2025 7:46 PM >>> To: idr <[email protected] <mailto:[email protected]>> >>> Cc: [email protected] >>> <mailto:[email protected]> >>> Subject: [Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, >>> 2025) >>> >>> This is a reminder that WGLC is in progress for link bandwidth. Please >>> respond to the list whether you think the document is ready to be advanced >>> for publication. >>> >>> -- Jeff (shepherding chair) >>> >>> >>>> On Jul 11, 2025, at 11:01 AM, Jeffrey Haas <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/ >>>> >>>> This begins the working group last call for the link bandwidth extended >>>> community draft. Thanks to the authors for working their way through the >>>> substantive items that have been obstacles to interoperability over the >>>> years. >>>> >>>> This last call ends a week after IETF 123 to give the working group time >>>> to review and also take advantage of the focus time that IETF meeting >>>> weeks bring to our work. >>>> >>>> An item in particular we'd like to request particular attention to from >>>> the working group's review are the procedures covering default behaviors >>>> and interactions with deployments with mixed transitivities. The current >>>> draft text works to try to accommodate maximal backward compatibility with >>>> various deployment scenarios, but such text is tricky. >>>> >>>> For purposes of the shepherd's report and according to IETF BCP 78/79, the >>>> authors are requested to declare whether they are aware of any undisclosed >>>> IPR covering this draft. Members of the working group are similarly >>>> obligated to report any they are aware of as well. >>>> >>>> -- Jeff (for the IDR Chairs) >>>> _______________________________________________ >>>> Idr mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >> _______________________________________________ >> BESS mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
