[Idr] Re: Jim Guichard's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS)

[Reshma Das <[e-mail]>]

Hi Jim Guichard,

Thank you for reviewing the document.
Please find my reply inline RD>

Thanks & Regards,
Reshma Das




Juniper Business Use Only
From: Jim Guichard via Datatracker <[e-mail]>
Date: Tuesday, October 21, 2025 at 5:40 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: Jim Guichard's Discuss on draft-ietf-idr-link-bandwidth-19: (with DISCUSS)
[External Email. Be cautious of content]


Jim Guichard 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!BXKRDMhoZtHULJ8koHp4-QwVIeSqUC7TaFe-QKq3NMjNnZg05T5d4N6tM6YeGHSX8Pi_g7WXpKfJkAc$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!BXKRDMhoZtHULJ8koHp4-QwVIeSqUC7TaFe-QKq3NMjNnZg05T5d4N6tM6YeGHSX8Pi_g7WXpKfJkAc$>
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!BXKRDMhoZtHULJ8koHp4-QwVIeSqUC7TaFe-QKq3NMjNnZg05T5d4N6tM6YeGHSX8Pi_g7WXpN1Zn0I$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!BXKRDMhoZtHULJ8koHp4-QwVIeSqUC7TaFe-QKq3NMjNnZg05T5d4N6tM6YeGHSX8Pi_g7WXpN1Zn0I$>



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors for this document. I do have a DISCUSS I would like to
have clarified. Section 2 of the document has:

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.

This text is very confusing. The first sentence seems to say that whatever
value is carried in this field does not matter. Why would the ASN not be
carried? What happens if someone sets the value to an arbitrary 2-byte value
that happens to be an ASN value that they do not represent?

Also, if the ASN cannot be represented as a 2-byte value but you specify that a
4-octet value is out of scope, why is RFC6793 quoted as that RFC adds BGP
support for a 4-octet ASN  number?
RD> I would like to point you to Jeffs reply<https://mailarchive.ietf.org/arch/msg/idr/inJK_mowTUP-JlY7gDwyPmPVkmk/> to a similar comment that details the format of extended community.
Based on various review comments we have reworded this section, please check the new text GitHub-ASNUM<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/pull/21/commits/4461d3def20e589987be61e38e7b88ac2f08ffbd#diff-483d4c38615bf145bb86c3b6a77bdae817e0b0f15c616c5df65039377016e59a>.

   Also, RFC 6793 is referenced as it reserves the two-octet AS number 'AS_TRANS'. Quoting from RFC 6793:
  "AS_TRANS can be used to represent non-mappable four-octet AS numbers   as two-octet AS numbers in AS path information that is encoded with two-octet AS numbers."