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

[Reshma Das <[e-mail]>]

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


Get Outlook for Mac <https://aka.ms/GetOutlookForMac>



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.


# 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.”


# 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.”


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

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


# 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."

# 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 ? Can you please clarify?


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


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.


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

Cheers,
Med