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

[Reshma Das <[e-mail]>]

Hi Med,
Thank for reviewing the document.
Please find all changes published in the latest version.
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-21.txt

Thanks & Regards,
Reshma Das




Juniper Business Use Only

From: [e-mail] <[e-mail]>
Date: Wednesday, November 12, 2025 at 6:31 AM
To: Reshma Das <[e-mail]>, 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 and changes made in -20. I think that we are almost there.

Please see inline.

Cheers,
Med

De : Reshma Das <[e-mail]>
Envoyé : jeudi 30 octobre 2025 05:06
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; Reshma Das <dreshma=[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,

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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Thursday, October 16, 2025 at 1:55 AM
To: Reshma Das <dreshma=[e-mail]<mailto:dreshma=[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:dreshma=[e-mail]>>
Envoyé : samedi 11 octobre 2025 02:25
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Date: Thursday, October 9, 2025 at 3:05 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452*diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a__;Iw!!NEt6yMaO-gk!Emy_JNCW-84RMp6RzU0ZSQIPFwJGhG-hj_HwgN9GENcYQBuHFOsuzwz2XmkRc0vBIgD6zIdACle3PwEAwRTrKkSPWrg$>]

# 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://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452*diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a__;Iw!!NEt6yMaO-gk!Emy_JNCW-84RMp6RzU0ZSQIPFwJGhG-hj_HwgN9GENcYQBuHFOsuzwz2XmkRc0vBIgD6zIdACle3PwEAwRTrKkSPWrg$>]
[Med] ACK

# 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://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452*diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a__;Iw!!NEt6yMaO-gk!Emy_JNCW-84RMp6RzU0ZSQIPFwJGhG-hj_HwgN9GENcYQBuHFOsuzwz2XmkRc0vBIgD6zIdACle3PwEAwRTrKkSPWrg$>]
[Med] This is great. I was hoping to see that clarification under the field definition itself:
CURRENT:
    Local Administrator sub-field:
             Bandwidth value (bytes per sec) encoded as 4 octets
             in IEEE 754 32-bit floating point format.

# 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.
[Med] OK.

# 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.""
[Med] This is clear and direct to the point. Thanks.

# 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://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452*diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a__;Iw!!NEt6yMaO-gk!Emy_JNCW-84RMp6RzU0ZSQIPFwJGhG-hj_HwgN9GENcYQBuHFOsuzwz2XmkRc0vBIgD6zIdACle3PwEAwRTrKkSPWrg$>]
[Med] ACK

# 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://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/891dc1adefe39affe00197c0bbaf134530337452*diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a__;Iw!!NEt6yMaO-gk!Emy_JNCW-84RMp6RzU0ZSQIPFwJGhG-hj_HwgN9GENcYQBuHFOsuzwz2XmkRc0vBIgD6zIdACle3PwEAwRTrKkSPWrg$>]
[Med] ACK.


____________________________________________________________________________________________________________
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.