[Idr] Re: Mohamed Boucadair's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Med,

Could you please check the v20 of the draft posted just before the IETF
week and Reshma's responses below to see if they address your concerns?

Thanks
Ketan


On Wed, Oct 29, 2025 at 9:07 PM Reshma Das <dreshma=
[e-mail]> wrote:

> Hi Med,
>
>
>
> I have taken care of most of the updates and merged in GitHub. I will be
> publishing the latest draft.
>
> Please find my reply inline as RD1>
>
>
>
> Thanks & Regards,
>
> Reshma Das
>
>
>
>
>
> Juniper Business Use Only
>
> *From: *[e-mail] <[e-mail]>
> *Date: *Thursday, October 16, 2025 at 1:55 AM
> *To: *Reshma Das <dreshma=[e-mail]>, The IESG <
> [e-mail]>, [e-mail] <
> [e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *RE: Mohamed Boucadair's Discuss on
> draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Reshma,
>
>
>
> Thank you for the follow-up.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Reshma Das <dreshma=[e-mail]>
> *Envoyé :* samedi 11 octobre 2025 02:25
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The
> IESG <[e-mail]>; [e-mail]
> *Cc :* [e-mail]; [e-mail]; [e-mail]
> *Objet :* Re: Mohamed Boucadair's Discuss on
> draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)
>
>
>
>
>
> Hi Med,
>
>
>
> Thank you for reviewing the document and providing comments.
>
> Please find my replies inline:
>
> RD>
>
>
>
> @[e-mail]
> <[e-mail]> Authors,
>
> Please review and provide comments if any, for the suggested text changes.
>
>
>
>
>
> Thanks & Regards,
>
> Reshma Das
>
> Juniper Business Use Only
>
> *From: *Mohamed Boucadair via Datatracker <[e-mail]>
> *Date: *Thursday, October 9, 2025 at 3:05 AM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Mohamed Boucadair's Discuss on
> draft-ietf-idr-link-bandwidth-19: (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-idr-link-bandwidth-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!EzSHa6Wk2Mdhq-I4up1UoFRt4my9vxLnEeFqGrwqeK4LskHRxX2wOxfYtMczQGmobuWh_yty4PVyegA$
> <https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!EzSHa6Wk2Mdhq-I4up1UoFRt4my9vxLnEeFqGrwqeK4LskHRxX2wOxfYtMczQGmobuWh_yty4PVyegA$>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!EzSHa6Wk2Mdhq-I4up1UoFRt4my9vxLnEeFqGrwqeK4LskHRxX2wOxfYtMczQGmobuWh_ytyR9Zf4jk$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!EzSHa6Wk2Mdhq-I4up1UoFRt4my9vxLnEeFqGrwqeK4LskHRxX2wOxfYtMczQGmobuWh_ytyR9Zf4jk$>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Hi Pradosh, Reshma, Satya, Serge, Rafal, and Akshay,
>
> Thank you for the effort put on this specification. Appreciate in
> particular
> the perseverance to push for this spec for 16 years.
>
> Thanks to Jeff for the excellent shepherd write-up and the link to relevant
> work in BESS.
>
> Also, thanks to Tim Chown for the OPSDIR review and the authors for
> engaging.
>
> I support this effort and will definitely ballot “YES”. Till then, I have
> some
> few points to discuss:
>
> # Start with an easy to fix one :-)
>
> OLD:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
> NEW:
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
>
> RD> ACK. I will update the draft with this change.
>
> *[Med] Thanks.*
>
> RD1> Done.  Please find the changes in [GitHub-link
> <https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>
> ]
>
>
> # 32-bit and 16-bit ASNs
>
> CURRENT:
> The value of the Global Administrator subfield in the Value
>    Field SHOULD represent the Autonomous System of the router that
>    attaches the Link Bandwidth Extended Community, but it can be set to
>    any 2-byte value.  If the Autonomous System number cannot be
>    represented in two octets, AS_TRANS [RFC6793], SHOULD be used in the
>    Global Administrator subfield.  The encoding of 4-octet ASN is out of
>    scope of this document.
>
> ## The last sentence seems to contradict the SHOULD in the sentence right
> before.
>
> ## If we only consider 16-bit ASNs, then I don’t see when the second SHOULD
> apply.
>
> ## The value actually used in Global Administrator does not actually matter
> after all, but I understand that this is to be consistent with registering
> the
> community in the two 2-octet community registries.
>
> I think some rearrangement of this text for better clarity is needed.
>
> ## I’m not asking to define a 4-octet ASN extended community as I trust
> this
> was considered by the WG and that there is a reason for only registering
> 16-bit
> ASN extended communities. Maybe add a motivation to justify the design
> (other
> than this was inherited from early version since 2009 :-)).
>
>
>
> RD> Perhaps, as suggested, adding a clarification explaining why the AS
> number is included would be helpful.
>
> I propose the following text:
>
> “The Global Administrator subfield in the Value Field SHOULD be set to the
> Autonomous System (AS) number of the router attaching the Link Bandwidth
> Extended Community, but MAY contain any two-octet value. If the Autonomous
> System number cannot be represented in two octets, AS_TRANS [RFC6793],
> SHOULD be used in the Global Administrator subfield. The encoding of
> four-octet ASNs is out of scope for this document.
>
> The value in the Global Administrator subfield does not affect the use or
> semantics of the Link Bandwidth Extended Community. This approach maintains
> consistency with two-octet community registries and remains operationally
> familiar.”
>
> *[Med] This is better. I suggest “s/The encoding of four-octet ASNs/The
> encoding of the full four-octet ASNs”.*
>
> RD1>  Done.  Please find the changes in [GitHub-link
> <https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>
> ]
>
>
> # Link Value: Static or Dynamic one
>
> CURRENT:
>     Local Administrator sub-field:
>              Bandwidth value (bytes per sec) encoded as 4 octets
>              in IEEE floating point format.
>
> The description needs to be clarified whether the advertised BW is static
> value
> or about available BW. If this is not a static value, the there is
> evidently
> some impact to consider on the stability and need for guards to prevent
> injecting too dynamic values.
>
> May consider updating the Operational Considerations Section with such
> clarification (including, guidance to avoid changing too frequently the
> value).
> That section may also say that how bw is computed/determined is out of
> scope.
>
> RD> I will add the below text to Operational Considerations:
>
> “How the bandwidth value is computed or determined is out of scope of this
> document.
> It is recommended that implementations provide mechanisms to limit the
> churn caused by
> frequently changing bandwidth values because rapid fluctuations could
> impact protocol
> stability and network operations. However, the specific methods for
> achieving this are
> out of scope of this document.”
>
> *[Med] This change is great. However, the definition of “*Bandwidth value*”
> is still not clear about the scope of the bw value that it embeds
> (interface, link, else).*
>
>
>
> RD1> This has been added in the introduction section, please check:
>
> The Link Bandwidth Extended Community carries the bandwidth information of
> a directly connected link or multi-hop/multipath nexthop as advertised by a
> router.
>
> The above review comment has been addressed in [GitHub-link
> <https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>
> ]
>
>
>
> # External Peers
>
> Given the commercial relationships and use of the community to reveal some
> capacity, I guess that as Operational Consideration, the text may say that
> absent an explicit allow policy, the community has to be stripped when
> advertised to an external peer.
>
> The security section includes a mention, but I think a strong behavior is
> needed.
>
> RD> Currently, some implementations provide a configuration option to send
> all extended communities to an EBGP neighbor. This option is not specific
> to any community type. Other implementations, however, advertise attached
> extended communities to EBGP neighbors based on their transitivity.
>
> The intent of this document is to capture all such behaviors observed in
> the field, ensuring that no existing implementation is considered
> non-compliant upon publication of this specification as an RFC. To
> accommodate these implementations, we have advised operators to use
> policies to filter out the Link Bandwidth Extended Community when
> advertising it other domains.
>
> *[Med] Given the sensitiveness of the information, I think that we need
> more than an advice here. This is the kind of feature that operators have
> to enable explicitly for use with external peers. Having a default behavior
> to strip unless there is an explicit policy would be safe from an
> operational standpoint. *
>
>
>
> RD1> Currently, this depends on the transitivity: if the community is
> non-transitive, it is stripped by default. If the community is transitive,
> it requires a policy to be stripped. Regardless of the transitivity, the
> document recommends that the LBWC be stripped when passed to an untrusted
> AS. Additionally, as noted, this document captures current behavior in the
> field and aims to ensure that no existing implementation is considered
> non-compliant upon publication of this specification as an RFC.
>
>
> # Associate a meaning with Zero value
>
> CURRENT:
>    An implementation MAY advertise bandwidth value as zero.
>
> The spec does not specify how zero value is interpreted. Should that mean
> that
> it should be unusable, deprioritized, else?
>
> RD> Zero is a valid value and this has been explicitly mentioned in Error
> handling section. How zero is used is covered in Section 3.2 (Receiver).
> Please note that various implementations currently behave differently, and
> these behaviors have been captured in this section.
>
> Please let me know if any more detail is needed.
>
> *[Med] ACK that zero is a valid value. My comment is that what is the
> meaning for that value? What is the benefit of sending that value compared
> to not sending the attribute at all? I was expecting we can provide some
> guidance on cases where zero value is used.*
>
> RD1> Please review suggested text to be added under sender section:
>
> "An operator may set the Link Bandwidth Extended Community value to zero
> to indicate that the path should not attract traffic, for example during
> maintenance. A bandwidth value of zero signals that the path be
> deprioritized, thereby steering traffic away without withdrawing the
> route.""
>
>
>
> # Unconditional MUST
>
> CURRENT:
>    A BGP receiver MUST be able to process Link Bandwidth Extended
>    Community of both transitive and non-transitive types.
>
> This MUST should be scoped. For example, a speaker that does not support
> the
> attribute won’t process it. Likewise, a policy may be provided to discard
> the
> link information from some peers, etc.
>
> RD> Please review the suggested text:
>
> "A BGP receiver that supports the Link Bandwidth Extended Community MUST
> support processing of both the transitive and non-transitive types."
>
> Regarding policy-based discarding of the LBWC, the receiver is still
> required to receive and process the community, which may later be removed
> by policy."
>
> *[Med] Works for me. Thanks.*
>
> RD1> Done, please check [GitHub-link
> <https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>
> ]
>
>
> # Intended Use
>
> CURRENT:
>    A BGP update with an attached Link Bandwidth Extended Community with
>    a bandwidth value of zero is valid.  When all contributing paths have
>    a non-zero value in the Link Bandwidth Extended Community, the
>    bandwidth values of those paths (or their ratio) can be utilized as
>    weights to enable weighted load-balancing.
>
> Should this be specifically restricted to WLB, not cover other cases that
> impact route selection process?
>
> RD> Whether a device participates in WECMP is a local policy decision even
> when LBWC is attached to a route. This is the intention of stating “LBWC
> can be utilized for WLB”. Do you want us to add some text stating that it
> should not be used in path selection ?
>
> *[Med] Yes. Thanks.*
>
> Can you please clarify?
>
> RD1> Added this part of section 3.2. Please check [GitHub-link
> <https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>
> ]
>
>
> # Conflict?
>
> CURRENT:
> it MAY do any one of the following as its default behavior
>    -remove the Link Bandwidth Extended Community, re-advertise it
>    unchanged, or regenerate it with an appropriate value.
>
> How to reconcile this with the SHOULD part in Section 3.3.2?
>
> RD> Section 3.3.1 covers the case when NH is changed. This allows
> flexibility by specifying that implementations MAY remove, re-advertise
> unchanged, or regenerate the community as default behavior, covering how
> current implementations behave.
>
> In Section 3.3.2, SHOULD NOT recommend a preferred behavior in a more
> specific context for RR or when the NH is unchanged for consistency and
> interoperability.
>
> Since these sections address distinct use cases—namely, Next Hop changes
> in Section 3.3.1 and Next Hop unchanged in Section 3.3.2—the use of MAY in
> Section 3.3.1 and the stronger SHOULD NOT recommendation in Section 3.3.2
> are aligned and do not require reconciliation. This differentiation
> provides necessary flexibility in applicable scenarios while offering
> guidance to ensure optimal interoperability where it is most needed.
>
> *[Med] Thank you for clarifying.*
>
>
> BTW: s/appropriate value/updated value
> RD> ACK
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Retrieve default values
>
> CURRENT:
>    Different implementations MAY use different default values for the
>    transitivity type of the Link Bandwidth Extended Community.
>
> and
>
>    Implementations SHOULD provide a local configuration method to alter
>    their default behavior to the other options with per-session
>    granularity.
>
> For the sake of deterministic behavior and ease network management, there
> is a
> need to retrieve the default used by each impl. This will feed controllers
> and
> so on.
>
> I suggest to add the following for in the both places above:
>
> NEW:
>   Likewise, Implementation SHOULD expose their default value.
>
> RD> ACK, I will add this line.
>
> *[Med] Thanks.*
>
>
> # Inadequate use of normative language: these are examples
>
> OLD:
> For
>    example, implementations MAY exclude the paths with zero value from
>    weighted load balancing formation as long as at least one path with
>    non-zero value exists or they MAY fallback to ECMP.
>
> NEW:
> For
>    example, implementations may exclude the paths with zero value from
>    weighted load balancing formation as long as at least one path with
>    non-zero value exists or they may fallback to ECMP.
>
> RD> In the example above, we are documenting the default behaviors
> observed in various implementations. These behaviors are presented as
> optional, recognized options. Therefore, we have used the normative keyword
> MAY to indicate that these are permissible protocol behaviors. Please let
> me know if any changes are needed for this example. I will review other
> places also for the same.
>
> *[Med] The reference behavior is the policy in the sentence right before
> the text I quested. The text with “For example, ..” is illustrating sample
> policies that can be used. These are not normative. Thanks.*
>
> RD1> Took care of this in, Please check [GitHub-link
> <https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>
> ]
>
>
>
>
> Cheers,
> Med
>
> ____________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
>