IANA, Please make the following updates to these registries in the "Border Gateway Protocol (BGP) Parameters” registry group at <https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml>.
a) Please add “NLRI” to the two values below (in the "BGP CAR NLRI Types” registry): OLD: 1 Color-Aware Route 2 IP Prefix NEW: 1 Color-Aware Route NLRI 2 IP Prefix NLRI b) Please add “TLV” to the three values below and hyphenate “Label-Index” (in the "BGP CAR NLRI TLV Types” registry). OLD: 1 Label 2 Label Index 3 SRv6 SID NEW: 1 Label TLV 2 Label-Index TLV 3 SRv6 SID TLV Thank you, Kaelin Foody RFC Production Center > On Nov 4, 2025, at 11:36 AM, Swadesh Agrawal (swaagraw) <[email protected]> > wrote: > > Hi Kaelin, > > Changes look good to me. > > Regards > Swadesh > > > Cisco Confidential > From: Kaelin Foody <[email protected]> > Date: Tuesday, November 4, 2025 at 8:15 AM > To: Dhananjaya Rao (dhrao) <[email protected]> > Cc: John Scudder <[email protected]>, Ketan Talaulikar > <[email protected]>, [email protected] > <[email protected]>, Swadesh Agrawal (swaagraw) <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, Hares Susan <[email protected]>, > [email protected] <[email protected]> > Subject: Re: [AD] AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for your > review > > Hi John and Dhananjaya, > > Thank you both for your quick replies and approvals. We have marked your > approvals on the AUTH48 status page for this document. > > We will await approval from Swadesh prior to moving forward with the > publication process. > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9871 > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. > > — FILES (please refresh): — > > The updated files have been posted here: > https://www.rfc-editor.org/authors/rfc9871.txt > https://www.rfc-editor.org/authors/rfc9871.pdf > https://www.rfc-editor.org/authors/rfc9871.html > https://www.rfc-editor.org/authors/rfc9871.xml > > Diff files showing changes between the last and current version: > https://www.rfc-editor.org/authors/rfc9871-lastdiff.html > https://www.rfc-editor.org/authors/rfc9871-lastrfcdiff.html (side by side) > > Diff files showing changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9871-auth48diff.html > https://www.rfc-editor.org/authors/rfc9871-auth48rfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9871-diff.html > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (side by side) > > Thank you, > > Kaelin Foody > RFC Production Center > > > On Nov 3, 2025, at 10:18 PM, Dhananjaya Rao (dhrao) <[email protected]> wrote: > > > > Hi John, > > > > Thank you for the quick review. > > > > Kaelin, the latest version is good for me too. Thank you for the updates. > > > > Regards, > > -Dhananjaya > > > > > > Cisco Confidential > > From: John Scudder <[email protected]> > > Date: Tuesday, November 4, 2025 at 2:34 AM > > To: Kaelin Foody <[email protected]>, Ketan Talaulikar > > <[email protected]> > > Cc: Dhananjaya Rao (dhrao) <[email protected]>, [email protected] > > <[email protected]>, Swadesh Agrawal (swaagraw) > > <[email protected]>, [email protected] <[email protected]>, > > [email protected] <[email protected]>, Hares Susan <[email protected]>, > > [email protected] <[email protected]> > > Subject: Re: [AD] AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for > > your review > > > > Hi Kaelin and all, > > > > I’ve reviewed the changes to Sections 2.1, 2.9.2.3, 2.11, 7.2.2 and > > Appendices C.3 and D. They look fine. > > > > Thanks, > > > > —John > > > > On Nov 3, 2025, at 11:12 AM, Ketan Talaulikar <[email protected]> wrote: > > > > > > [External Email. Be cautious of content] > > > > > > Hi Kaelin, > > > > I am a contributor on this document and will prefer John Scudder who was > > the responsible AD for this document when it was approved by the IESG to do > > the AD approval. John, can you please? > > > > Thanks, > > Ketan > > > > > > On Mon, Nov 3, 2025 at 11:08 AM Kaelin Foody <[email protected]> > > wrote: > > Hi Ketan* and Dhananjaya, > > > > * Ketan - As AD, please review and let us know if you approve the changes > > to Sections 2.1, 2.9.2.3, 2.11, 7.2.2 and Appendices C.3 and D. > > You may view the updates here: > > https://www.rfc-editor.org/authors/rfc9871-auth48diff.html. > > > > > > Dhananjaya - Thank you for your reply and for those additional updates. > > > > We will await approvals from each party listed on the AUTH48 status page > > for this document prior to moving forward with the publication process. > > > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9871 > > > > Please review the document carefully to ensure satisfaction as we do not > > make changes once it has been published as an RFC. > > > > — FILES (please refresh): — > > > > The updated files have been posted here: > > https://www.rfc-editor.org/authors/rfc9871.txt > > https://www.rfc-editor.org/authors/rfc9871.pdf > > https://www.rfc-editor.org/authors/rfc9871.html > > https://www.rfc-editor.org/authors/rfc9871.xml > > > > Diff files showing changes between the last and current version: > > https://www.rfc-editor.org/authors/rfc9871-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9871-lastrfcdiff.html (side by side) > > > > Diff files showing changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9871-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9871-auth48rfcdiff.html (side by side) > > > > Diff files showing all changes: > > https://www.rfc-editor.org/authors/rfc9871-diff.html > > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (side by side) > > > > Thank you, > > > > Kaelin Foody > > RFC Production Center > > > > > On Oct 30, 2025, at 3:29 AM, Dhananjaya Rao (dhrao) <[email protected]> > > > wrote: > > > > > > Hi Kaelin, > > > > > > Thanks for the updates. > > > > > > Please check the attached xml file which has a few minor edits to fix > > > inconsistencies between T-RR and S-RR terms and improve readability. > > > > > > The rest looks good. > > > > > > Regards, > > > -Dhananjaya > > > > > > From: Kaelin Foody <[email protected]> > > > Date: Thursday, October 23, 2025 at 1:20 AM > > > To: Dhananjaya Rao (dhrao) <[email protected]> > > > Cc: [email protected] <[email protected]>, Swadesh > > > Agrawal (swaagraw) <[email protected]>, [email protected] > > > <[email protected]>, [email protected] <[email protected]>, > > > [email protected] <[email protected]>, [email protected] <[email protected]>, > > > [email protected]<[email protected]> > > > Subject: Re: AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for your > > > review > > > > > > Hi Dhananjaya, > > > > > > Thank you for your reply. We have updated the document accordingly to > > > reflect these most recent updates. We have one follow-up note: > > > > > > We have updated the text below to Option B. Please review and confirm > > > that this update is correct and accurately reflects your meaning. > > > > > > > 1) Is this sentence in the abstract meant to be a list of two or three > > > > items? Please review and let us know how to update. If it is a list of > > > > two items, we > > > > would add a colon or em dash (see Option A). If it is a list of three > > > > items, we would add an additional comma (see Option B). > > > > > > > > Original: > > > > > > > > It defines non-key TLV types for MPLS label stack, Label Index and > > > > SRv6 SIDs. > > > > > > > > Current: > > > > > > > > It defines non-key TLV types for the MPLS label stack, SR-MPLS Label > > > > Index and > > > > Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). > > > > > > > > > > > > Option A (this document defines two non-key TLV types for the MPLS > > > > label stack): > > > > > > > > It defines non-key TLV types for the MPLS label stack: SR-MPLS label > > > > index and > > > > Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). > > > > > > > > Option B (this document defines three non-key TLV types): > > > > > > > > It defines non-key TLV types for the MPLS label stack, SR-MPLS label > > > > index, > > > > and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). > > > > > > > > DR# This is correct. > > > > > > > > > Upon careful review, please contact us with any further updates or with > > > your approval of the document in its current form. We will await > > > approvals from each party listed on the AUTH48 status page for this > > > document prior to moving forward with the publication process. > > > > > > The AUTH48 status page for this document is available here: > > > https://www.rfc-editor.org/auth48/rfc9871 > > > > > > Please review the document carefully to ensure satisfaction as we do not > > > make changes once it has been published as an RFC. > > > > > > — FILES (please refresh): — > > > > > > The updated files have been posted here: > > > https://www.rfc-editor.org/authors/rfc9871.txt > > > https://www.rfc-editor.org/authors/rfc9871.pdf > > > https://www.rfc-editor.org/authors/rfc9871.html > > > https://www.rfc-editor.org/authors/rfc9871.xml > > > > > > Diff files showing changes between the last and current version: > > > https://www.rfc-editor.org/authors/rfc9871-lastdiff.html > > > https://www.rfc-editor.org/authors/rfc9871-lastrfcdiff.html (side by side) > > > > > > Diff files showing changes made during AUTH48: > > > https://www.rfc-editor.org/authors/rfc9871-auth48diff.html > > > https://www.rfc-editor.org/authors/rfc9871-auth48rfcdiff.html (side by > > > side) > > > > > > Diff files showing all changes: > > > https://www.rfc-editor.org/authors/rfc9871-diff.html > > > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (side by side) > > > > > > All the best, > > > > > > Kaelin Foody > > > RFC Production Center > > > > > > > On Oct 16, 2025, at 9:43 AM, Dhananjaya Rao (dhrao) <[email protected]> > > > > wrote: > > > > > > > > Hi Kaelin, > > > > > > > > Thank you for the review of the updates. Please see inline (DR#). > > > > > > > > From: Kaelin Foody <[email protected]> > > > > Date: Saturday, October 11, 2025 at 2:35 AM > > > > To: Dhananjaya Rao (dhrao) <[email protected]> > > > > Cc: [email protected] <[email protected]>, Swadesh > > > > Agrawal (swaagraw) <[email protected]>, [email protected] > > > > <[email protected]>,[email protected] <[email protected]>, > > > > [email protected] <[email protected]>, [email protected] <[email protected]>, > > > > [email protected]<[email protected]> > > > > Subject: Re: AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for > > > > your review > > > > > > > > Hi Dhananjaya, > > > > > > > > Thank you for your response and for the updated XML file. We have > > > > updated our files per your requests. A few follow-up questions: > > > > > > > > 1) Is this sentence in the abstract meant to be a list of two or three > > > > items? Please review and let us know how to update. If it is a list of > > > > two items, we > > > > would add a colon or em dash (see Option A). If it is a list of three > > > > items, we would add an additional comma (see Option B). > > > > > > > > Original: > > > > > > > > It defines non-key TLV types for MPLS label stack, Label Index and > > > > SRv6 SIDs. > > > > > > > > Current: > > > > > > > > It defines non-key TLV types for the MPLS label stack, SR-MPLS Label > > > > Index and > > > > Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). > > > > > > > > > > > > Option A (this document defines two non-key TLV types for the MPLS > > > > label stack): > > > > > > > > It defines non-key TLV types for the MPLS label stack: SR-MPLS label > > > > index and > > > > Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). > > > > > > > > Option B (this document defines three non-key TLV types): > > > > > > > > It defines non-key TLV types for the MPLS label stack, SR-MPLS label > > > > index, > > > > and Segment Routing over IPv6 (SRv6) Segment Identifiers (SIDs). > > > > > > > > DR# This is correct. > > > > > > > > 2) FYI, we have updated the artwork in Section 9 to include line breaks > > > > and indentation > > > > as requested; please review and let us know if this format is > > > > acceptable or if additional updates are needed. > > > > > > > > DR# It looks good. > > > > > > > > 3) Thank you for your updates to the terminology below. We see various > > > > forms of these remain in Section 2.11; should these be updated as well? > > > > > > > > > 20) <!-- [rfced] Terminology: Please review the following questions > > > > > we have regarding > > > > > the terminology used in this document. > > > > > > > > > > a) We note different capitalization of the terms below. Please review > > > > > and let > > > > > us know each term should appear for consistency. > > > > > > > > > > NLRI Type vs. NLRI type > > > > >> DR# fixed inline > > > > > > > > > > NLRI Length vs. NLRI length > > > > >> DR# fixed inline > > > > > > > > > > Key Length vs. Key length vs. key length > > > > >> DR# fixed inline with Key length > > > > > > > > Section 2.11: > > > > > > > > The CAR NLRI definition encodes NLRI length and key length > > > > explicitly. The NLRI length MUST be relied upon... > > > > > > > > A sender MUST ensure that the NLRI and key lengths are the number of > > > > actual bytes encoded in the NLRI and key fields, respectively, > > > > regardless of content being encoded. > > > > > > > > Given the NLRI length and Key length MUST be valid, failures in the > > > > following checks result in 'AFI/SAFI disable' or 'session reset': > > > > > > > > * The minimum NLRI length MUST be at least 2, as key length and NLRI > > > > type are required fields. > > > > > > > > DR# This should be “.. NLRI Length MUST be atleast 2, as Key Length > > > > and NLRI Type are required fields” > > > > DR# The rest should be okay. > > > > > > > > * The Key Length MUST be at least 2 less than NLRI Length. > > > > > > > > > > > > 4) We were unable to find responses to the questions below in the XML > > > > file. Kindly review and let us know how we may update accordingly: > > > > > > > > a) Appendix D: We suggest adding a space between the > > > > number and the units throughout the descriptions of Cases A, B, and C. > > > > Please let us know if this update is acceptable. A few examples: > > > > > > > > Original: ~86MB > > > > ~27.5MB > > > > ~339MB > > > > > > > > Suggested: ~86 MB > > > > ~27.5 MB > > > > ~339 MB > > > > > > > > DR# This should be fine. > > > > > > > > b) We note different forms of "BGP LU" and "BGP IP" are used throughout > > > > the document. Should these > > > > terms appear with or without a hyphen? > > > > > > > > Examples: > > > > > > > > BGP LU > > > > BGP-LU > > > > > > > > DR# BGP-LU > > > > > > > > BGP-IP > > > > BGP IP > > > > > > > > DR# BGP-IP > > > > > > > > BGP LU/IP > > > > BGP IP/LU > > > > > > > > DR# BGP-IP/BGP-LU > > > > > > > > c) We note different uses of the terms below. For consistency, we plan > > > > to update the item > > > > on the left of the arrow to the term on the right. Please review and > > > > let us know if these updates > > > > would be acceptable. > > > > > > > > Non-Key TLVs -> non-key TLVs > > > > > > > > DR# Right now, only specific references to the Non-Key TLV fields are > > > > capitalized. So we could leave them as is. > > > > > > > > multi-protocol -> multiprotocol (for consistency with RFC 4760) > > > > > > > > DR# This is fine. > > > > > > > > data-plane -> data plane > > > > control-plane -> control plane > > > > > > > > DR# Sounds good. > > > > > > > > d) The terms "border router" and "transport RR" appear throughout the > > > > document > > > > after their abbreviations "BR" and "TRR" are introduced. For > > > > consistency, may > > > > we update to use the abbreviations (after they are first introduced)? > > > > > > > > DR# yes. > > > > > > > > We look forward to hearing from you. You may find the updated files > > > > below: > > > > > > > > Thank you again. > > > > > > > > Regards, > > > > -Dhananjaya > > > > > > > > — FILES (please refresh): — > > > > > > > > The updated files have been posted here: > > > > https://www.rfc-editor.org/authors/rfc9871.txt > > > > https://www.rfc-editor.org/authors/rfc9871.pdf > > > > https://www.rfc-editor.org/authors/rfc9871.html > > > > https://www.rfc-editor.org/authors/rfc9871.xml > > > > > > > > The relevant diff files have been posted here: > > > > https://www.rfc-editor.org/authors/rfc9871-auth48diff.html (AUTH48 > > > > changes only) > > > > https://www.rfc-editor.org/authors/rfc9871-auth48rfcdiff.html (AUTH 48 > > > > changes side by side) > > > > https://www.rfc-editor.org/authors/rfc9871-diff.html (all changes) > > > > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (all changes > > > > side by side) > > > > > > > > The AUTH48 status page for this document is available here: > > > > https://www.rfc-editor.org/auth48/rfc9871 > > > > > > > > Thank you, > > > > > > > > Kaelin Foody > > > > RFC Production Center > > > > > > > > > > > > > On Oct 6, 2025, at 10:50 AM, Dhananjaya Rao (dhrao) <[email protected]> > > > > > wrote: > > > > > > > > > > Hi Kaelin and team, > > > > > > > > > > Thank you very much for your comments. We have updated the attached > > > > > xml file with inline responses to some of the comments and questions > > > > > as well as the content edits in the xml. > > > > > Please let us know if the changes are sufficient. > > > > > > > > > > Regards, > > > > > -Dhananjaya > > > > > > > > > > > > > > > From: [email protected] <[email protected]> > > > > > Date: Friday, September 26, 2025 at 3:49 AM > > > > > To: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh Agrawal > > > > > (swaagraw) <[email protected]> > > > > > Cc: [email protected] <[email protected]>, > > > > > [email protected] <[email protected]>, [email protected] > > > > > <[email protected]>,[email protected] <[email protected]>, > > > > > [email protected] <[email protected]>, [email protected] > > > > > <[email protected]> > > > > > Subject: Re: AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for > > > > > your review > > > > > > > > > > Authors, > > > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > > necessary) the following questions, which are also in the source file. > > > > > > > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear > > > > > in > > > > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > > > > > > > > > > 2) <!-- [rfced] Section 1.1. Terminology: We have made the following > > > > > changes in > > > > > this section; please review and let us know if any adjustments are > > > > > needed. > > > > > > > > > > a) We have updated the text below to clarify the order of preference: > > > > > > > > > > Original: > > > > > If several such paths exist, a preference scheme is used to select > > > > > the best > > > > > path (for example, IGP Flex-Algo preferred over SR Policy preferred > > > > > over BGP CAR. > > > > > > > > > > Current: > > > > > If several such paths exist, a preference scheme is used to select > > > > > the best > > > > > path (for example, IGP Flex-Algo is preferred over SR Policy, and > > > > > SR Policy > > > > > is preferred over BGP CAR). > > > > > > > > > > > > > > > b) We have updated "trust domain" to "trusted domain" in the text > > > > > below > > > > > for consistency with RFC 8402. > > > > > > > > > > Original: > > > > > In an SR deployment, the transport network is within a trust domain > > > > > as per > > > > > [RFC8402]. > > > > > > > > > > Current: > > > > > In an SR deployment, the transport network is within a trusted > > > > > domain as per > > > > > [RFC8402]. > > > > > --> > > > > > > > > > > > > > > > 3) <!-- [rfced] Section 1.1. (Abbreviations): We have the following > > > > > questions regarding the abbreviations list in this section. > > > > > > > > > > a) We were unable to find the term "BGP-LU" or "BGP Labeled Unicast > > > > > SAFI" > > > > > mentioned in RFC 8277. Is it the correct reference for this term? > > > > > > > > > > In addition, we also note the following different uses of this term > > > > > throughout > > > > > this document. Please review and let us know how to update for > > > > > consistency. > > > > > > > > > > BGP IP/LU > > > > > BGP LU > > > > > BGP-IP/LU(Labeled Unicast) > > > > > BGP LU/IP > > > > > > > > > > Original: > > > > > * BGP-LU: BGP Labeled Unicast SAFI [RFC8277]. > > > > > > > > > > > > > > > b) We were unable to find the term "BGP-IP" or "BGP IPv4/IPv6 Unicast > > > > > AFI/SAFIs" > > > > > in RFCs 4271 and 4760. How may we update? > > > > > > > > > > Original: > > > > > * BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs [RFC4271], [RFC4760]. > > > > > > > > > > > > > > > c) FYI - We have already made the following updates to this section. > > > > > Please > > > > > review. > > > > > > > > > > i) We have separated this list item into two separate entries for > > > > > clarity and > > > > > have updated their definitions for consistency with RFC 4760: > > > > > > > > > > Original: > > > > > > > > > > * AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers. > > > > > > > > > > Current: > > > > > > > > > > AFI: Address Family Identifier > > > > > > > > > > SAFI: Subsequent Address Family Identifier > > > > > > > > > > ii) We have added list entries for the following terms so that they do > > > > > not need to be expanded when they appear in figures or other list > > > > > items. > > > > > > > > > > ABR: Area Border Router > > > > > ASBR: Autonomous System Border Router > > > > > RD: Route Distinguisher > > > > > --> > > > > > > > > > > > > > > > 4) <!-- [rfced] Section 2.1: For consistency with the rest of the > > > > > list items in > > > > > this section, what definition/content should appear for "BGP Next > > > > > Hop"? > > > > > > > > > > Original: > > > > > * BGP Next Hop. > > > > > --> > > > > > > > > > > > > > > > 5) <!-- [rfced] Please clarify the last two points; we suggest making > > > > > them > > > > > complete sentences and consistent with one another. More specifically, > > > > > what is the outcome of the "if" clause in the final list item below > > > > > (the > > > > > item that begins with "Another example is:")? > > > > > > > > > > Original: > > > > > * A BGP color-aware route (E2, C1) with next hop N may be resolved > > > > > over a color-aware route (N, C2): i.e., the local policy maps > > > > > the > > > > > resolution of C1 over a different color C2. > > > > > > > > > > - For example, in a domain where resource R is known to not be > > > > > present, the inter-domain intent C1="low delay and avoid R" > > > > > may > > > > > be resolved over an intra-domain path of intent C2="low > > > > > delay". > > > > > > > > > > - Another example is: if no (N, C1) path is available and the > > > > > user has > > > > > allowed resolution to fallback to a C2 path. > > > > > > > > > > Perhaps: > > > > > - For example, in a domain where resource R is known to not be > > > > > present, the inter-domain intent C1="low delay and avoid R" > > > > > may > > > > > be resolved over an intra-domain path of intent C2="low > > > > > delay". > > > > > > > > > > - For another example, if no (N, C1) path is available, and > > > > > the user has > > > > > allowed resolution to fallback to a C2 path, then ... [what > > > > > outcome occurs]? > > > > > --> > > > > > > > > > > > > > > > 6) <!-- [rfced] How may we clarify how the content in parentheses > > > > > relates to > > > > > the rest of the sentence? > > > > > > > > > > Original: > > > > > For CAR route resolution, Color-EC color if present takes > > > > > precedence > > > > > over the route's intent color (LCM-EC if present (Section 2.9.5), > > > > > or > > > > > else NLRI color). > > > > > > > > > > Perhaps: > > > > > If present, Color-EC color takes precedence over the route's > > > > > intent color > > > > > (which, if present, is LCM-EC (see Section 2.9.5) or else NLRI > > > > > color) for > > > > > CAR route resolution. > > > > > --> > > > > > > > > > > > > > > > 7) <!-- [rfced] What is the subject of "or appropriately incremented" > > > > > in the text below? > > > > > > > > > > Original: > > > > > The value set (or appropriately incremented) in the AIGP TLV > > > > > corresponds to the metric associated with the underlying intent of > > > > > the color. > > > > > > > > > > Perhaps: > > > > > The value that is set (or appropriately incremented) in the AIGP > > > > > TLV > > > > > corresponds to the metric associated with the underlying intent of > > > > > the color. > > > > > --> > > > > > > > > > > > > > > > 8) <!-- [rfced] FYI - We adjusted these list items to make them > > > > > parallel > > > > > and consistent. Please review and let us know any further updates. > > > > > > > > > > Original: > > > > > BGP CAR SRv6 SID TLV definitions provide the following benefits: > > > > > > > > > > * Native encoding of SIDs avoids robustness issue caused by > > > > > overloading of MPLS label fields. > > > > > > > > > > * Simple encoding to signal Unique SIDs (non-transposition), > > > > > maintaining BGP update prefix packing. > > > > > > > > > > * Highly efficient transposition scheme (12-14 bytes saved per > > > > > NLRI), also maintaining BGP update prefix packing. > > > > > > > > > > Current: > > > > > BGP CAR SRv6 SID TLV definitions provide the following benefits: > > > > > > > > > > * The native encoding of SIDs avoids robustness issues caused by > > > > > the > > > > > overloading of MPLS label fields. > > > > > > > > > > * The simple encoding to signal Unique SIDs (non-transposition) > > > > > maintains BGP update prefix packing. > > > > > > > > > > * The highly efficient transposition scheme (12-14 bytes saved per > > > > > NLRI) also maintains BGP update prefix packing. > > > > > --> > > > > > > > > > > > > > > > 9) <!-- [rfced] May we update the list below as follows for > > > > > consistency? > > > > > Is it intentional that the first "must" is lowercase, or should it be > > > > > the > > > > > all-caps requirement keyword "MUST" (which is used in the other > > > > > bullet point)? > > > > > > > > > > Original: > > > > > Given NLRI length and Key length MUST be valid, failures in > > > > > following > > > > > checks result in 'AFI/SAFI disable' or 'session reset': > > > > > > > > > > * Minimum NLRI length (must be atleast 2, as key length and NLRI > > > > > type are required fields). > > > > > > > > > > * Key Length MUST be at least two less than NLRI Length. > > > > > > > > > > Perhaps: > > > > > Given the NLRI length and Key length MUST be valid, failures in > > > > > the following > > > > > checks result in 'AFI/SAFI disable' or 'session reset': > > > > > > > > > > * The minimum NLRI length MUST be at least 2, as key length and > > > > > NLRI > > > > > type are required fields. > > > > > > > > > > * The Key Length MUST be at least 2 less than NLRI Length. > > > > > --> > > > > > > > > > > > > > > > 10) <!-- [rfced] FYI, for clarity, we added the word 'steering' twice > > > > > and changed 'path' to 'paths'. Please review whether this conveys > > > > > this intended meaning. > > > > > > > > > > Original: > > > > > All the steering variations described in [RFC9256] are applicable > > > > > to BGP > > > > > CAR color-aware path: on-demand steering, per- destination, > > > > > per-flow, > > > > > color-only steering. > > > > > > > > > > Current: > > > > > All the steering variations described in [RFC9256] are applicable > > > > > to BGP > > > > > CAR color-aware paths: on-demand steering, per-destination > > > > > steering, > > > > > per-flow steering, and color-only steering. > > > > > --> > > > > > > > > > > > > > > > 11) <!-- [rfced] What is the subject of "may be shared" in the text > > > > > below? > > > > > > > > > > Original: > > > > > - If MPLS/SR-MPLS transport, the route will carry label/prefix- > > > > > SID allocated by the next hop, may be shared. > > > > > --> > > > > > > > > > > > > > > > 12) <!--[rfced] Will it be clear to the reader what "color CP" and > > > > > "color CPT" > > > > > mean here? If not, please provide text to explain. We note that some > > > > > other > > > > > examples use "color C1" and "color C2". > > > > > > > > > > Current: > > > > > * Provider publishes to customer that intent 'low-delay' is mapped > > > > > to color CP on its inbound peering links. > > > > > > > > > > * Within its infrastructure, provider maps intent 'low-delay' to > > > > > color CPT. > > > > > --> > > > > > > > > > > > > > > > 13) <!-- [rfced] FYI - Section 9: We have updated this artwork > > > > > (containing > > > > > numbered items) to to an ordered list. Please review. If you prefer to > > > > > have the "[(V, CC)" portions aligned vertically, we can insert line > > > > > breaks (as shown in 'Perhaps' below). For example (showing only two > > > > > items): > > > > > > > > > > Original: > > > > > 1. CE2 sends to PE2 : [(V, CC), Label L1] via CE2 with > > > > > LCM-EC (CP) > > > > > as per peering agreement > > > > > 2. PE2 installs in VRF A: [(V, CC), L1] via CE2 > > > > > which resolves on (CE2, > > > > > CP) > > > > > or connected OIF > > > > > > > > > > Current: > > > > > 1. CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) > > > > > as > > > > > per peering agreement. > > > > > > > > > > 2. PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on > > > > > (CE2, CP) or connected Outgoing Interface (OIF). > > > > > > > > > > Perhaps: > > > > > 1. CE2 sends to PE2: > > > > > [(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peering > > > > > agreement. > > > > > > > > > > 2. PE2 installs in VRF A: > > > > > [(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected > > > > > Outgoing Interface (OIF). > > > > > --> > > > > > > > > > > > > > > > 14) <!-- [rfced] Is citing Section 9 of RFC 4364 correct here? We > > > > > note "L3VPN" > > > > > does not appear in RFC 4364. ("L3" appears only once in Section 14; > > > > > zero instances of "layer 3".) > > > > > > > > > > Original: > > > > > Example use-cases are intent-aware L3VPN CsC ([RFC4364] Section 9) > > > > > and SRv6 > > > > > over a provider network. > > > > > > > > > > Current: > > > > > Example use cases are intent-aware L3VPN Carriers' Carriers > > > > > (Section 9 of > > > > > [RFC4364]) and SRv6 over a provider network. > > > > > --> > > > > > > > > > > > > > > > 15) <!-- [rfced] Appendix A.7: Is there text missing in the example > > > > > below? For > > > > > instance, what does "nearest" refer to? > > > > > > > > > > Original: > > > > > Example-1: Anycast with forwarding to nearest > > > > > --> > > > > > > > > > > > > > > > 16) <!-- [rfced] Appendix D: We have made several updates for clarity > > > > > and > > > > > readability. Please carefully review and let us know if any additional > > > > > updates are needed. > > > > > > > > > > a) FYI, we made this sentence into a list. May we change "4k bytes" > > > > > to "4000 bytes" for clarity? (It seems fine for other instances of > > > > > '4k' to remain in this document, as they are not followed by the word > > > > > 'bytes'.) > > > > > > > > > > Original: > > > > > Scenarios considered are ideal packing (maximum number of routes > > > > > packed to update message limit of 4k bytes), practical deployment > > > > > case with average packing (5 routes share set of BGP path > > > > > attributes > > > > > and hence packed in single update message) and worst-case of no > > > > > packing (each route in separate update message). > > > > > > > > > > Current: > > > > > > > > > > The packing scenarios considered are as follows: > > > > > > > > > > * the ideal case (where the maximum number of routes are packed to > > > > > the update message limit of 4k bytes), > > > > > > > > > > * the practical case of average packing (where 5 routes share a > > > > > set > > > > > of BGP path attributes, and hence are packed in a single update > > > > > message), and > > > > > > > > > > * the worst case of no packing (where each route is in a separate > > > > > update message). > > > > > > > > > > > > > > > b) Table 5: FYI, we updated the title and made other slight > > > > > adjustments to > > > > > the table. > > > > > > > > > > Original: > > > > > Figure 18: Summary of ideal, practical and no-packing BGP data in > > > > > each case > > > > > > > > > > Current: > > > > > Table 5: Summary of the Ideal, Practical, and Worst Cases of > > > > > Packing BGP Data > > > > > > > > > > > > > > > c) To avoid using an RFC number as an adjective, may we update the > > > > > various instances of "[RFC8277] style" as follows? > > > > > > > > > > Original: > > > > > > > > > > It compares total BGP > > > > > data on the wire for CAR SAFI and [RFC8277] style encoding in MPLS > > > > > label (CASE A), SR extension with MPLS (per-prefix label index in > > > > > Prefix-SID attribute) [RFC8669] (CASE B) and SRv6 SID (CASE C) > > > > > cases. > > > > > > > > > > |RFC-8277 style | > > > > > | NLRI | > > > > > > > > > > > > > > > No degradation from RFC8277 like encoding > > > > > > > > > > CAR SAFI encoding more efficient by 88% in best case and 71% in > > > > > average > > > > > case over RFC8277 style encoding > > > > > > > > > > SAFI 128 8277 style encoding with label in NLRI > > > > > > > > > > Perhaps: > > > > > > > > > > It compares total BGP data on the wire for CAR SAFI and encoding > > > > > as specified > > > > > in [RFC8277] in the following: an MPLS label (CASE A), an SR > > > > > extension with MPLS > > > > > (per-prefix label index in Prefix-SID attribute; see [RFC8669]) > > > > > (CASE B), and > > > > > an SRv6 SID (CASE C). > > > > > > > > > > | NLRI as | > > > > > | per RFC 8277 | > > > > > > > > > > No degradation from encoding as specified in [RFC8277]. > > > > > > > > > > CAR SAFI encoding is more efficient by 88% in the best case and > > > > > 71% in the > > > > > average case over the encoding as specified in [RFC8277] (which > > > > > precludes > > > > > packing). > > > > > > > > > > SAFI 128 encoded per RFC 8277 with label in NLRI > > > > > --> > > > > > > > > > > > > > > > 17) <!--[rfced] Appendix D: We suggest adding a space between the > > > > > number and the units throughout the descriptions of Cases A, B, and C. > > > > > Please let us know if this update is acceptable. A few examples: > > > > > > > > > > Original: ~86MB > > > > > ~27.5MB > > > > > ~339MB > > > > > > > > > > Suggested: ~86 MB > > > > > ~27.5 MB > > > > > ~339 MB > > > > > --> > > > > > > > > > > > > > > > 18) <!-- [rfced] Formatting: > > > > > > > > > > a) FYI, we add line breaks in the artwork so it fits within > > > > > 72-character line > > > > > limit. Specifically, please review the artworks in Appendices C.1, > > > > > C.2, and > > > > > C.3 titled "Packet Forwarding" and let us know if the line breaks > > > > > should be > > > > > changed. > > > > > > > > > > In addition, please consider whether any artwork elements should be > > > > > tagged as > > > > > sourcecode or a different element. > > > > > > > > > > > > > > > b) Please review whether any of the notes in this document > > > > > should be in the <aside> element. It is defined as "a container for > > > > > content that is semantically less important or tangential to the > > > > > content that surrounds it" > > > > > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > > > > --> > > > > > > > > > > > > > > > 19) <!-- [rfced] FYI, we added expansions for abbreviations upon > > > > > first use > > > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > > > expansion in the document carefully to ensure correctness. > > > > > > > > > > Autonomous Systems (ASes) > > > > > VPN Routing and Forwarding (VRF) > > > > > Provider Edge (PE) > > > > > Customer Edge (CE) > > > > > Segment Routing over MPLS (SR-MPLS) > > > > > Label Switched Paths (LSPs) > > > > > Network Layer Reachability Information (NLRI) > > > > > Network Function Virtualization (NFV) > > > > > Segment Routing Global Block (SRGB) > > > > > Outgoing Interface (OIF) > > > > > end-to-end (E2E) > > > > > Longest Prefix Match (LPM) > > > > > pseudowire (PW) > > > > > Penultimate Segment Pop (PSP) > > > > > --> > > > > > > > > > > > > > > > 20) <!-- [rfced] Terminology: Please review the following questions > > > > > we have regarding > > > > > the terminology used in this document. > > > > > > > > > > a) We note different capitalization of the terms below. Please review > > > > > and let > > > > > us know each term should appear for consistency. > > > > > > > > > > Label Index vs. label index > > > > > > > > > > Label vs. label > > > > > > > > > > Color value vs. color value > > > > > > > > > > NLRI Type vs. NLRI type > > > > > > > > > > NLRI Length vs. NLRI length > > > > > > > > > > Key Length vs. Key length vs. key length > > > > > > > > > > > > > > > b) "Flex Algo" appears in various forms. Please review and let us know > > > > > how to update for consistency: > > > > > > > > > > Flex-Algo vs. Flex Algo vs. FlexAlgo > > > > > > > > > > Flex Algo 128 vs. Flex-Algo 128 vs. Flex-Algo FA128 vs. FA 128 vs. > > > > > FA128 > > > > > > > > > > > > > > > c) How should "prefix" be capitalized in the different instances > > > > > below? > > > > > > > > > > BGP CAR IP Prefix routes vs. BGP CAR IP prefix route > > > > > > > > > > CAR IP prefix route vs. CAR IP Prefix route > > > > > > > > > > IP Prefix vs. IP prefix > > > > > > > > > > > > > > > d) We note different use of hyphens and quotation marks in the > > > > > instances > > > > > below. How would you like these items to be stylized for consistency? > > > > > > > > > > low-delay vs. 'low-delay' vs. "low-delay" vs. "low delay" > > > > > > > > > > low-cost vs. low cost > > > > > --> > > > > > > > > > > > > > > > 21) <!-- [rfced] Terminology: We have already updated (or plan to > > > > > update) the > > > > > terms below for consistency. Please review and let us know any > > > > > objections. > > > > > > > > > > a) We note different uses of the terms below. For consistency, we > > > > > plan to > > > > > update the item on the left of the arrow to the term on the right. > > > > > > > > > > Non-Key TLVs -> non-key TLVs > > > > > > > > > > multi-protocol -> multiprotocol (for consistency with RFC 4760) > > > > > > > > > > Label Index TLV -> Label-Index TLV (for consistency with RFC 8669) > > > > > > > > > > data-plane -> data plane > > > > > > > > > > control-plane -> control plane > > > > > > > > > > SR policy, SR-policy, SR-Policy -> SR Policy (for consistency with > > > > > RFC 9256) > > > > > > > > > > > > > > > b) The terms "border router" and "transport RR" appear throughout the > > > > > document > > > > > after their abbreviations "BR" and "TRR" are introduced. For > > > > > consistency, may > > > > > we update to use the abbreviations (after they are first introduced)? > > > > > > > > > > > > > > > c) We note "Extended Community" and "Local Color Mapping" are > > > > > hyphenated > > > > > differently throughout this document (some examples below). For > > > > > consistency > > > > > with RFCs 9012 and 9256, may we update these instances to "Extended > > > > > Community" > > > > > and "Local Color Mapping" (no hyphens)? > > > > > > > > > > Local-Color-Mapping Extended-Community (LCM-EC) > > > > > Local Color Mapping (LCM) Extended Community > > > > > Local Color Mapping Extended-Community > > > > > > > > > > Route Target (RT) Extended-Communities > > > > > Transitive Opaque Extended-Community > > > > > BGP Extended-Community > > > > > > > > > > > > > > > d) FYI - We have already updated the terms below as follows for > > > > > consistency > > > > > with their relevant RFCs. > > > > > > > > > > RT-Constrain -> RT Constrain (per RFC 4684) > > > > > Prefix-SID Attribute -> Prefix-SID attribute (per RFC 8669) > > > > > BGP Prefix-SID Attribute -> BGP Prefix-SID attribute (per RFC 8669) > > > > > SRv6 service SID -> SRv6 Service SID (per RFC 9252) > > > > > SR Domain -> SR domain (per RFC 8402) > > > > > END behavior -> End behavior (per RFC 8986) > > > > > Route Target (RT) Extended-Communities -> Route Target (RT) Extended > > > > > Communities (per RFC 4360) > > > > > AIGP Attribute -> AIGP attribute (per RFC 7311) > > > > > > > > > > e) Is the term "CAR color-aware path" (3 instances) necessary, or > > > > > should > > > > > it simply be "CAR path" (10 instances)? > > > > > > > > > > Section 1.2 > > > > > - V/v is steered on BGP CAR color-aware path > > > > > - V/v is steered on a BGP CAR color-aware path that is itself > > > > > ... > > > > > > > > > > Section 3: > > > > > All the steering variations described in [RFC9256] are > > > > > applicable to BGP CAR color-aware paths: on-demand steering, ... > > > > > --> > > > > > > > > > > > > > > > 22) <!-- [rfced] Please review the "Inclusive Language" portion of > > > > > the online > > > > > Style Guide > > > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > > > and let us know if any changes are needed. Updates of this nature > > > > > typically > > > > > result in more precise language, which is helpful for readers. > > > > > > > > > > a) For example, please consider whether "native" should be updated in > > > > > the > > > > > instances below: > > > > > > > > > > Section 2.7. Native MultiPath Capability > > > > > > > > > > Native support for multiple transport encapsulations (e.g., MPLS, > > > > > SR, SRv6, IP) > > > > > > > > > > Native encoding of SIDs avoids robustness issue... > > > > > > > > > > Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: > > > > > is natively > > > > > steered hop by hop along IPv6 routed path... > > > > > > > > > > Encapsulated service traffic is natively steered along IPv6 routed > > > > > path... > > > > > > > > > > > > > > > b) In addition, please consider whether "traditional" should be > > > > > updated for clarity. > > > > > While the NIST website > > > > > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > > > > > indicates that this term is potentially biased, it is also ambiguous. > > > > > "Tradition" is a subjective term, as it is not the same for everyone. > > > > > There are 4 instances currently: > > > > > > > > > > If a color-aware path is not > > > > > available, local policy may map to a traditional routing/TE > > > > > path (e.g., BGP LU, RSVP-TE, IGP/LDP). > > > > > > > > > > Intra-domain resolution: > > > > > BGP CAR route maps to an intra-domain color-aware path (e.g., > > > > > SR Policy, IGP Flex-Algo, BGP CAR) or a traditional > > > > > routing/TE > > > > > path (e.g., RSVP-TE, IGP/LDP, BGP-LU). > > > > > > > > > > * Local policy may map the CAR route to traditional mechanisms > > > > > that > > > > > are unaware of color or that provide best-effort, such as > > > > > RSVP-TE, > > > > > IGP/LDP, BGP LU/IP (e.g., Appendix A.3.2) for brownfield > > > > > scenarios. > > > > > > > > > > However, to be compatible > > > > > with traditional operational usage, the CAR IP Prefix route is > > > > > allowed to be without color for best-effort. > > > > > --> > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > Kaelin Foody and Alice Russo > > > > > RFC Production Center > > > > > > > > > > > > > > > On Sep 25, 2025, [email protected] wrote: > > > > > > > > > > *****IMPORTANT***** > > > > > > > > > > Updated 2025/09/25 > > > > > > > > > > RFC Author(s): > > > > > -------------- > > > > > > > > > > Instructions for Completing AUTH48 > > > > > > > > > > Your document has now entered AUTH48. Once it has been reviewed and > > > > > approved by you and all coauthors, it will be published as an RFC. > > > > > If an author is no longer available, there are several remedies > > > > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > > > > > > > You and you coauthors are responsible for engaging other parties > > > > > (e.g., Contributors or Working Group) as necessary before providing > > > > > your approval. > > > > > > > > > > Planning your review > > > > > --------------------- > > > > > > > > > > Please review the following aspects of your document: > > > > > > > > > > * RFC Editor questions > > > > > > > > > > Please review and resolve any questions raised by the RFC Editor > > > > > that have been included in the XML file as comments marked as > > > > > follows: > > > > > > > > > > <!-- [rfced] ... --> > > > > > > > > > > These questions will also be sent in a subsequent email. > > > > > > > > > > * Changes submitted by coauthors > > > > > > > > > > Please ensure that you review any changes submitted by your > > > > > coauthors. We assume that if you do not speak up that you > > > > > agree to changes submitted by your coauthors. > > > > > > > > > > * Content > > > > > > > > > > Please review the full content of the document, as this cannot > > > > > change once the RFC is published. Please pay particular attention > > > > > to: > > > > > - IANA considerations updates (if applicable) > > > > > - contact information > > > > > - references > > > > > > > > > > * Copyright notices and legends > > > > > > > > > > Please review the copyright notice and legends as defined in > > > > > RFC 5378 and the Trust Legal Provisions > > > > > (TLP – https://trustee.ietf.org/license-info). > > > > > > > > > > * Semantic markup > > > > > > > > > > Please review the markup in the XML file to ensure that elements of > > > > > content are correctly tagged. For example, ensure that <sourcecode> > > > > > and <artwork> are set correctly. See details at > > > > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > > > > > > > * Formatted output > > > > > > > > > > Please review the PDF, HTML, and TXT files to ensure that the > > > > > formatted output, as generated from the markup in the XML file, is > > > > > reasonable. Please note that the TXT will have formatting > > > > > limitations compared to the PDF and HTML. > > > > > > > > > > > > > > > Submitting changes > > > > > ------------------ > > > > > > > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > > > > the parties CCed on this message need to see your changes. The parties > > > > > include: > > > > > > > > > > * your coauthors > > > > > > > > > > * [email protected] (the RPC team) > > > > > > > > > > * other document participants, depending on the stream (e.g., > > > > > IETF Stream participants are your working group chairs, the > > > > > responsible ADs, and the document shepherd). > > > > > > > > > > * [email protected], which is a new archival mailing > > > > > list > > > > > to preserve AUTH48 conversations; it is not an active discussion > > > > > list: > > > > > > > > > > * More info: > > > > > > > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > > > > > > > * The archive itself: > > > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > > > > > > > * Note: If only absolutely necessary, you may temporarily opt out > > > > > of the archiving of messages (e.g., to discuss a sensitive > > > > > matter). > > > > > If needed, please add a note at the top of the message that you > > > > > have dropped the address. When the discussion is concluded, > > > > > [email protected] will be re-added to the CC list > > > > > and > > > > > its addition will be noted at the top of the message. > > > > > > > > > > You may submit your changes in one of two ways: > > > > > > > > > > An update to the provided XML file > > > > > — OR — > > > > > An explicit list of changes in this format > > > > > > > > > > Section # (or indicate Global) > > > > > > > > > > OLD: > > > > > old text > > > > > > > > > > NEW: > > > > > new text > > > > > > > > > > You do not need to reply with both an updated XML file and an explicit > > > > > list of changes, as either form is sufficient. > > > > > > > > > > We will ask a stream manager to review and approve any changes that > > > > > seem > > > > > beyond editorial in nature, e.g., addition of new text, deletion of > > > > > text, > > > > > and technical changes. Information about stream managers can be > > > > > found in > > > > > the FAQ. Editorial changes do not require approval from a stream > > > > > manager. > > > > > > > > > > > > > > > Approving for publication > > > > > -------------------------- > > > > > > > > > > To approve your RFC for publication, please reply to this email > > > > > stating > > > > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > > > > as all the parties CCed on this message need to see your approval. > > > > > > > > > > > > > > > Files > > > > > ----- > > > > > > > > > > The files are available here: > > > > > https://www.rfc-editor.org/authors/rfc9871.xml > > > > > https://www.rfc-editor.org/authors/rfc9871.html > > > > > https://www.rfc-editor.org/authors/rfc9871.pdf > > > > > https://www.rfc-editor.org/authors/rfc9871.txt > > > > > > > > > > Diff file of the text: > > > > > https://www.rfc-editor.org/authors/rfc9871-diff.html > > > > > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (side by > > > > > side) > > > > > > > > > > This diff file uses an altered original to show the changes in > > > > > Section 1.1 and the moved text (Acknowledgements and Contributors): > > > > > https://www.rfc-editor.org/authors/rfc9871-alt-diff.html > > > > > > > > > > Diff of the XML: > > > > > https://www.rfc-editor.org/authors/rfc9871-xmldiff1.html > > > > > > > > > > > > > > > Tracking progress > > > > > ----------------- > > > > > > > > > > The details of the AUTH48 status of your document are here: > > > > > https://www.rfc-editor.org/auth48/rfc9871 > > > > > > > > > > Please let us know if you have any questions. > > > > > > > > > > Thank you for your cooperation, > > > > > > > > > > RFC Editor > > > > > > > > > > -------------------------------------- > > > > > RFC9871 (draft-ietf-idr-bgp-car-16) > > > > > > > > > > Title : BGP Color-Aware Routing (CAR) > > > > > Author(s) : D. Rao, Ed., S. Agrawal, Ed. > > > > > WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > > > > > > > > > > > <rfc9871-rfcedresponse.xml> > > > > > > > > > > > > > On Oct 6, 2025, at 10:50 AM, Dhananjaya Rao (dhrao) <[email protected]> > > > > > wrote: > > > > > > > > > > Hi Kaelin and team, > > > > > > > > > > Thank you very much for your comments. We have updated the attached > > > > > xml file with inline responses to some of the comments and questions > > > > > as well as the content edits in the xml. > > > > > Please let us know if the changes are sufficient. > > > > > > > > > > Regards, > > > > > -Dhananjaya > > > > > > > > > > > > > > > From: [email protected] <[email protected]> > > > > > Date: Friday, September 26, 2025 at 3:49 AM > > > > > To: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh Agrawal > > > > > (swaagraw) <[email protected]> > > > > > Cc: [email protected] <[email protected]>, > > > > > [email protected] <[email protected]>, [email protected] > > > > > <[email protected]>,[email protected] <[email protected]>, > > > > > [email protected] <[email protected]>, [email protected] > > > > > <[email protected]> > > > > > Subject: Re: AUTH48: RFC-to-be 9871 <draft-ietf-idr-bgp-car-16> for > > > > > your review > > > > > > > > > > Authors, > > > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > > necessary) the following questions, which are also in the source file. > > > > > > > > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear > > > > > in > > > > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > > > > > > > > > > 2) <!-- [rfced] Section 1.1. Terminology: We have made the following > > > > > changes in > > > > > this section; please review and let us know if any adjustments are > > > > > needed. > > > > > > > > > > a) We have updated the text below to clarify the order of preference: > > > > > > > > > > Original: > > > > > If several such paths exist, a preference scheme is used to select > > > > > the best > > > > > path (for example, IGP Flex-Algo preferred over SR Policy preferred > > > > > over BGP CAR. > > > > > > > > > > Current: > > > > > If several such paths exist, a preference scheme is used to select > > > > > the best > > > > > path (for example, IGP Flex-Algo is preferred over SR Policy, and > > > > > SR Policy > > > > > is preferred over BGP CAR). > > > > > > > > > > > > > > > b) We have updated "trust domain" to "trusted domain" in the text > > > > > below > > > > > for consistency with RFC 8402. > > > > > > > > > > Original: > > > > > In an SR deployment, the transport network is within a trust domain > > > > > as per > > > > > [RFC8402]. > > > > > > > > > > Current: > > > > > In an SR deployment, the transport network is within a trusted > > > > > domain as per > > > > > [RFC8402]. > > > > > --> > > > > > > > > > > > > > > > 3) <!-- [rfced] Section 1.1. (Abbreviations): We have the following > > > > > questions regarding the abbreviations list in this section. > > > > > > > > > > a) We were unable to find the term "BGP-LU" or "BGP Labeled Unicast > > > > > SAFI" > > > > > mentioned in RFC 8277. Is it the correct reference for this term? > > > > > > > > > > In addition, we also note the following different uses of this term > > > > > throughout > > > > > this document. Please review and let us know how to update for > > > > > consistency. > > > > > > > > > > BGP IP/LU > > > > > BGP LU > > > > > BGP-IP/LU(Labeled Unicast) > > > > > BGP LU/IP > > > > > > > > > > Original: > > > > > * BGP-LU: BGP Labeled Unicast SAFI [RFC8277]. > > > > > > > > > > > > > > > b) We were unable to find the term "BGP-IP" or "BGP IPv4/IPv6 Unicast > > > > > AFI/SAFIs" > > > > > in RFCs 4271 and 4760. How may we update? > > > > > > > > > > Original: > > > > > * BGP-IP: BGP IPv4/IPv6 Unicast AFI/SAFIs [RFC4271], [RFC4760]. > > > > > > > > > > > > > > > c) FYI - We have already made the following updates to this section. > > > > > Please > > > > > review. > > > > > > > > > > i) We have separated this list item into two separate entries for > > > > > clarity and > > > > > have updated their definitions for consistency with RFC 4760: > > > > > > > > > > Original: > > > > > > > > > > * AFI/SAFI: BGP Address-Family/Sub-Address-Family Identifiers. > > > > > > > > > > Current: > > > > > > > > > > AFI: Address Family Identifier > > > > > > > > > > SAFI: Subsequent Address Family Identifier > > > > > > > > > > ii) We have added list entries for the following terms so that they do > > > > > not need to be expanded when they appear in figures or other list > > > > > items. > > > > > > > > > > ABR: Area Border Router > > > > > ASBR: Autonomous System Border Router > > > > > RD: Route Distinguisher > > > > > --> > > > > > > > > > > > > > > > 4) <!-- [rfced] Section 2.1: For consistency with the rest of the > > > > > list items in > > > > > this section, what definition/content should appear for "BGP Next > > > > > Hop"? > > > > > > > > > > Original: > > > > > * BGP Next Hop. > > > > > --> > > > > > > > > > > > > > > > 5) <!-- [rfced] Please clarify the last two points; we suggest making > > > > > them > > > > > complete sentences and consistent with one another. More specifically, > > > > > what is the outcome of the "if" clause in the final list item below > > > > > (the > > > > > item that begins with "Another example is:")? > > > > > > > > > > Original: > > > > > * A BGP color-aware route (E2, C1) with next hop N may be resolved > > > > > over a color-aware route (N, C2): i.e., the local policy maps > > > > > the > > > > > resolution of C1 over a different color C2. > > > > > > > > > > - For example, in a domain where resource R is known to not be > > > > > present, the inter-domain intent C1="low delay and avoid R" > > > > > may > > > > > be resolved over an intra-domain path of intent C2="low > > > > > delay". > > > > > > > > > > - Another example is: if no (N, C1) path is available and the > > > > > user has > > > > > allowed resolution to fallback to a C2 path. > > > > > > > > > > Perhaps: > > > > > - For example, in a domain where resource R is known to not be > > > > > present, the inter-domain intent C1="low delay and avoid R" > > > > > may > > > > > be resolved over an intra-domain path of intent C2="low > > > > > delay". > > > > > > > > > > - For another example, if no (N, C1) path is available, and > > > > > the user has > > > > > allowed resolution to fallback to a C2 path, then ... [what > > > > > outcome occurs]? > > > > > --> > > > > > > > > > > > > > > > 6) <!-- [rfced] How may we clarify how the content in parentheses > > > > > relates to > > > > > the rest of the sentence? > > > > > > > > > > Original: > > > > > For CAR route resolution, Color-EC color if present takes > > > > > precedence > > > > > over the route's intent color (LCM-EC if present (Section 2.9.5), > > > > > or > > > > > else NLRI color). > > > > > > > > > > Perhaps: > > > > > If present, Color-EC color takes precedence over the route's > > > > > intent color > > > > > (which, if present, is LCM-EC (see Section 2.9.5) or else NLRI > > > > > color) for > > > > > CAR route resolution. > > > > > --> > > > > > > > > > > > > > > > 7) <!-- [rfced] What is the subject of "or appropriately incremented" > > > > > in the text below? > > > > > > > > > > Original: > > > > > The value set (or appropriately incremented) in the AIGP TLV > > > > > corresponds to the metric associated with the underlying intent of > > > > > the color. > > > > > > > > > > Perhaps: > > > > > The value that is set (or appropriately incremented) in the AIGP > > > > > TLV > > > > > corresponds to the metric associated with the underlying intent of > > > > > the color. > > > > > --> > > > > > > > > > > > > > > > 8) <!-- [rfced] FYI - We adjusted these list items to make them > > > > > parallel > > > > > and consistent. Please review and let us know any further updates. > > > > > > > > > > Original: > > > > > BGP CAR SRv6 SID TLV definitions provide the following benefits: > > > > > > > > > > * Native encoding of SIDs avoids robustness issue caused by > > > > > overloading of MPLS label fields. > > > > > > > > > > * Simple encoding to signal Unique SIDs (non-transposition), > > > > > maintaining BGP update prefix packing. > > > > > > > > > > * Highly efficient transposition scheme (12-14 bytes saved per > > > > > NLRI), also maintaining BGP update prefix packing. > > > > > > > > > > Current: > > > > > BGP CAR SRv6 SID TLV definitions provide the following benefits: > > > > > > > > > > * The native encoding of SIDs avoids robustness issues caused by > > > > > the > > > > > overloading of MPLS label fields. > > > > > > > > > > * The simple encoding to signal Unique SIDs (non-transposition) > > > > > maintains BGP update prefix packing. > > > > > > > > > > * The highly efficient transposition scheme (12-14 bytes saved per > > > > > NLRI) also maintains BGP update prefix packing. > > > > > --> > > > > > > > > > > > > > > > 9) <!-- [rfced] May we update the list below as follows for > > > > > consistency? > > > > > Is it intentional that the first "must" is lowercase, or should it be > > > > > the > > > > > all-caps requirement keyword "MUST" (which is used in the other > > > > > bullet point)? > > > > > > > > > > Original: > > > > > Given NLRI length and Key length MUST be valid, failures in > > > > > following > > > > > checks result in 'AFI/SAFI disable' or 'session reset': > > > > > > > > > > * Minimum NLRI length (must be atleast 2, as key length and NLRI > > > > > type are required fields). > > > > > > > > > > * Key Length MUST be at least two less than NLRI Length. > > > > > > > > > > Perhaps: > > > > > Given the NLRI length and Key length MUST be valid, failures in > > > > > the following > > > > > checks result in 'AFI/SAFI disable' or 'session reset': > > > > > > > > > > * The minimum NLRI length MUST be at least 2, as key length and > > > > > NLRI > > > > > type are required fields. > > > > > > > > > > * The Key Length MUST be at least 2 less than NLRI Length. > > > > > --> > > > > > > > > > > > > > > > 10) <!-- [rfced] FYI, for clarity, we added the word 'steering' twice > > > > > and changed 'path' to 'paths'. Please review whether this conveys > > > > > this intended meaning. > > > > > > > > > > Original: > > > > > All the steering variations described in [RFC9256] are applicable > > > > > to BGP > > > > > CAR color-aware path: on-demand steering, per- destination, > > > > > per-flow, > > > > > color-only steering. > > > > > > > > > > Current: > > > > > All the steering variations described in [RFC9256] are applicable > > > > > to BGP > > > > > CAR color-aware paths: on-demand steering, per-destination > > > > > steering, > > > > > per-flow steering, and color-only steering. > > > > > --> > > > > > > > > > > > > > > > 11) <!-- [rfced] What is the subject of "may be shared" in the text > > > > > below? > > > > > > > > > > Original: > > > > > - If MPLS/SR-MPLS transport, the route will carry label/prefix- > > > > > SID allocated by the next hop, may be shared. > > > > > --> > > > > > > > > > > > > > > > 12) <!--[rfced] Will it be clear to the reader what "color CP" and > > > > > "color CPT" > > > > > mean here? If not, please provide text to explain. We note that some > > > > > other > > > > > examples use "color C1" and "color C2". > > > > > > > > > > Current: > > > > > * Provider publishes to customer that intent 'low-delay' is mapped > > > > > to color CP on its inbound peering links. > > > > > > > > > > * Within its infrastructure, provider maps intent 'low-delay' to > > > > > color CPT. > > > > > --> > > > > > > > > > > > > > > > 13) <!-- [rfced] FYI - Section 9: We have updated this artwork > > > > > (containing > > > > > numbered items) to to an ordered list. Please review. If you prefer to > > > > > have the "[(V, CC)" portions aligned vertically, we can insert line > > > > > breaks (as shown in 'Perhaps' below). For example (showing only two > > > > > items): > > > > > > > > > > Original: > > > > > 1. CE2 sends to PE2 : [(V, CC), Label L1] via CE2 with > > > > > LCM-EC (CP) > > > > > as per peering agreement > > > > > 2. PE2 installs in VRF A: [(V, CC), L1] via CE2 > > > > > which resolves on (CE2, > > > > > CP) > > > > > or connected OIF > > > > > > > > > > Current: > > > > > 1. CE2 sends to PE2: [(V, CC), Label L1] via CE2 with LCM-EC (CP) > > > > > as > > > > > per peering agreement. > > > > > > > > > > 2. PE2 installs in VRF A: [(V, CC), L1] via CE2, which resolves on > > > > > (CE2, CP) or connected Outgoing Interface (OIF). > > > > > > > > > > Perhaps: > > > > > 1. CE2 sends to PE2: > > > > > [(V, CC), Label L1] via CE2 with LCM-EC (CP) as per peering > > > > > agreement. > > > > > > > > > > 2. PE2 installs in VRF A: > > > > > [(V, CC), L1] via CE2, which resolves on (CE2, CP) or connected > > > > > Outgoing Interface (OIF). > > > > > --> > > > > > > > > > > > > > > > 14) <!-- [rfced] Is citing Section 9 of RFC 4364 correct here? We > > > > > note "L3VPN" > > > > > does not appear in RFC 4364. ("L3" appears only once in Section 14; > > > > > zero instances of "layer 3".) > > > > > > > > > > Original: > > > > > Example use-cases are intent-aware L3VPN CsC ([RFC4364] Section 9) > > > > > and SRv6 > > > > > over a provider network. > > > > > > > > > > Current: > > > > > Example use cases are intent-aware L3VPN Carriers' Carriers > > > > > (Section 9 of > > > > > [RFC4364]) and SRv6 over a provider network. > > > > > --> > > > > > > > > > > > > > > > 15) <!-- [rfced] Appendix A.7: Is there text missing in the example > > > > > below? For > > > > > instance, what does "nearest" refer to? > > > > > > > > > > Original: > > > > > Example-1: Anycast with forwarding to nearest > > > > > --> > > > > > > > > > > > > > > > 16) <!-- [rfced] Appendix D: We have made several updates for clarity > > > > > and > > > > > readability. Please carefully review and let us know if any additional > > > > > updates are needed. > > > > > > > > > > a) FYI, we made this sentence into a list. May we change "4k bytes" > > > > > to "4000 bytes" for clarity? (It seems fine for other instances of > > > > > '4k' to remain in this document, as they are not followed by the word > > > > > 'bytes'.) > > > > > > > > > > Original: > > > > > Scenarios considered are ideal packing (maximum number of routes > > > > > packed to update message limit of 4k bytes), practical deployment > > > > > case with average packing (5 routes share set of BGP path > > > > > attributes > > > > > and hence packed in single update message) and worst-case of no > > > > > packing (each route in separate update message). > > > > > > > > > > Current: > > > > > > > > > > The packing scenarios considered are as follows: > > > > > > > > > > * the ideal case (where the maximum number of routes are packed to > > > > > the update message limit of 4k bytes), > > > > > > > > > > * the practical case of average packing (where 5 routes share a > > > > > set > > > > > of BGP path attributes, and hence are packed in a single update > > > > > message), and > > > > > > > > > > * the worst case of no packing (where each route is in a separate > > > > > update message). > > > > > > > > > > > > > > > b) Table 5: FYI, we updated the title and made other slight > > > > > adjustments to > > > > > the table. > > > > > > > > > > Original: > > > > > Figure 18: Summary of ideal, practical and no-packing BGP data in > > > > > each case > > > > > > > > > > Current: > > > > > Table 5: Summary of the Ideal, Practical, and Worst Cases of > > > > > Packing BGP Data > > > > > > > > > > > > > > > c) To avoid using an RFC number as an adjective, may we update the > > > > > various instances of "[RFC8277] style" as follows? > > > > > > > > > > Original: > > > > > > > > > > It compares total BGP > > > > > data on the wire for CAR SAFI and [RFC8277] style encoding in MPLS > > > > > label (CASE A), SR extension with MPLS (per-prefix label index in > > > > > Prefix-SID attribute) [RFC8669] (CASE B) and SRv6 SID (CASE C) > > > > > cases. > > > > > > > > > > |RFC-8277 style | > > > > > | NLRI | > > > > > > > > > > > > > > > No degradation from RFC8277 like encoding > > > > > > > > > > CAR SAFI encoding more efficient by 88% in best case and 71% in > > > > > average > > > > > case over RFC8277 style encoding > > > > > > > > > > SAFI 128 8277 style encoding with label in NLRI > > > > > > > > > > Perhaps: > > > > > > > > > > It compares total BGP data on the wire for CAR SAFI and encoding > > > > > as specified > > > > > in [RFC8277] in the following: an MPLS label (CASE A), an SR > > > > > extension with MPLS > > > > > (per-prefix label index in Prefix-SID attribute; see [RFC8669]) > > > > > (CASE B), and > > > > > an SRv6 SID (CASE C). > > > > > > > > > > | NLRI as | > > > > > | per RFC 8277 | > > > > > > > > > > No degradation from encoding as specified in [RFC8277]. > > > > > > > > > > CAR SAFI encoding is more efficient by 88% in the best case and > > > > > 71% in the > > > > > average case over the encoding as specified in [RFC8277] (which > > > > > precludes > > > > > packing). > > > > > > > > > > SAFI 128 encoded per RFC 8277 with label in NLRI > > > > > --> > > > > > > > > > > > > > > > 17) <!--[rfced] Appendix D: We suggest adding a space between the > > > > > number and the units throughout the descriptions of Cases A, B, and C. > > > > > Please let us know if this update is acceptable. A few examples: > > > > > > > > > > Original: ~86MB > > > > > ~27.5MB > > > > > ~339MB > > > > > > > > > > Suggested: ~86 MB > > > > > ~27.5 MB > > > > > ~339 MB > > > > > --> > > > > > > > > > > > > > > > 18) <!-- [rfced] Formatting: > > > > > > > > > > a) FYI, we add line breaks in the artwork so it fits within > > > > > 72-character line > > > > > limit. Specifically, please review the artworks in Appendices C.1, > > > > > C.2, and > > > > > C.3 titled "Packet Forwarding" and let us know if the line breaks > > > > > should be > > > > > changed. > > > > > > > > > > In addition, please consider whether any artwork elements should be > > > > > tagged as > > > > > sourcecode or a different element. > > > > > > > > > > > > > > > b) Please review whether any of the notes in this document > > > > > should be in the <aside> element. It is defined as "a container for > > > > > content that is semantically less important or tangential to the > > > > > content that surrounds it" > > > > > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > > > > --> > > > > > > > > > > > > > > > 19) <!-- [rfced] FYI, we added expansions for abbreviations upon > > > > > first use > > > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > > > expansion in the document carefully to ensure correctness. > > > > > > > > > > Autonomous Systems (ASes) > > > > > VPN Routing and Forwarding (VRF) > > > > > Provider Edge (PE) > > > > > Customer Edge (CE) > > > > > Segment Routing over MPLS (SR-MPLS) > > > > > Label Switched Paths (LSPs) > > > > > Network Layer Reachability Information (NLRI) > > > > > Network Function Virtualization (NFV) > > > > > Segment Routing Global Block (SRGB) > > > > > Outgoing Interface (OIF) > > > > > end-to-end (E2E) > > > > > Longest Prefix Match (LPM) > > > > > pseudowire (PW) > > > > > Penultimate Segment Pop (PSP) > > > > > --> > > > > > > > > > > > > > > > 20) <!-- [rfced] Terminology: Please review the following questions > > > > > we have regarding > > > > > the terminology used in this document. > > > > > > > > > > a) We note different capitalization of the terms below. Please review > > > > > and let > > > > > us know each term should appear for consistency. > > > > > > > > > > Label Index vs. label index > > > > > > > > > > Label vs. label > > > > > > > > > > Color value vs. color value > > > > > > > > > > NLRI Type vs. NLRI type > > > > > > > > > > NLRI Length vs. NLRI length > > > > > > > > > > Key Length vs. Key length vs. key length > > > > > > > > > > > > > > > b) "Flex Algo" appears in various forms. Please review and let us know > > > > > how to update for consistency: > > > > > > > > > > Flex-Algo vs. Flex Algo vs. FlexAlgo > > > > > > > > > > Flex Algo 128 vs. Flex-Algo 128 vs. Flex-Algo FA128 vs. FA 128 vs. > > > > > FA128 > > > > > > > > > > > > > > > c) How should "prefix" be capitalized in the different instances > > > > > below? > > > > > > > > > > BGP CAR IP Prefix routes vs. BGP CAR IP prefix route > > > > > > > > > > CAR IP prefix route vs. CAR IP Prefix route > > > > > > > > > > IP Prefix vs. IP prefix > > > > > > > > > > > > > > > d) We note different use of hyphens and quotation marks in the > > > > > instances > > > > > below. How would you like these items to be stylized for consistency? > > > > > > > > > > low-delay vs. 'low-delay' vs. "low-delay" vs. "low delay" > > > > > > > > > > low-cost vs. low cost > > > > > --> > > > > > > > > > > > > > > > 21) <!-- [rfced] Terminology: We have already updated (or plan to > > > > > update) the > > > > > terms below for consistency. Please review and let us know any > > > > > objections. > > > > > > > > > > a) We note different uses of the terms below. For consistency, we > > > > > plan to > > > > > update the item on the left of the arrow to the term on the right. > > > > > > > > > > Non-Key TLVs -> non-key TLVs > > > > > > > > > > multi-protocol -> multiprotocol (for consistency with RFC 4760) > > > > > > > > > > Label Index TLV -> Label-Index TLV (for consistency with RFC 8669) > > > > > > > > > > data-plane -> data plane > > > > > > > > > > control-plane -> control plane > > > > > > > > > > SR policy, SR-policy, SR-Policy -> SR Policy (for consistency with > > > > > RFC 9256) > > > > > > > > > > > > > > > b) The terms "border router" and "transport RR" appear throughout the > > > > > document > > > > > after their abbreviations "BR" and "TRR" are introduced. For > > > > > consistency, may > > > > > we update to use the abbreviations (after they are first introduced)? > > > > > > > > > > > > > > > c) We note "Extended Community" and "Local Color Mapping" are > > > > > hyphenated > > > > > differently throughout this document (some examples below). For > > > > > consistency > > > > > with RFCs 9012 and 9256, may we update these instances to "Extended > > > > > Community" > > > > > and "Local Color Mapping" (no hyphens)? > > > > > > > > > > Local-Color-Mapping Extended-Community (LCM-EC) > > > > > Local Color Mapping (LCM) Extended Community > > > > > Local Color Mapping Extended-Community > > > > > > > > > > Route Target (RT) Extended-Communities > > > > > Transitive Opaque Extended-Community > > > > > BGP Extended-Community > > > > > > > > > > > > > > > d) FYI - We have already updated the terms below as follows for > > > > > consistency > > > > > with their relevant RFCs. > > > > > > > > > > RT-Constrain -> RT Constrain (per RFC 4684) > > > > > Prefix-SID Attribute -> Prefix-SID attribute (per RFC 8669) > > > > > BGP Prefix-SID Attribute -> BGP Prefix-SID attribute (per RFC 8669) > > > > > SRv6 service SID -> SRv6 Service SID (per RFC 9252) > > > > > SR Domain -> SR domain (per RFC 8402) > > > > > END behavior -> End behavior (per RFC 8986) > > > > > Route Target (RT) Extended-Communities -> Route Target (RT) Extended > > > > > Communities (per RFC 4360) > > > > > AIGP Attribute -> AIGP attribute (per RFC 7311) > > > > > > > > > > e) Is the term "CAR color-aware path" (3 instances) necessary, or > > > > > should > > > > > it simply be "CAR path" (10 instances)? > > > > > > > > > > Section 1.2 > > > > > - V/v is steered on BGP CAR color-aware path > > > > > - V/v is steered on a BGP CAR color-aware path that is itself > > > > > ... > > > > > > > > > > Section 3: > > > > > All the steering variations described in [RFC9256] are > > > > > applicable to BGP CAR color-aware paths: on-demand steering, ... > > > > > --> > > > > > > > > > > > > > > > 22) <!-- [rfced] Please review the "Inclusive Language" portion of > > > > > the online > > > > > Style Guide > > > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > > > and let us know if any changes are needed. Updates of this nature > > > > > typically > > > > > result in more precise language, which is helpful for readers. > > > > > > > > > > a) For example, please consider whether "native" should be updated in > > > > > the > > > > > instances below: > > > > > > > > > > Section 2.7. Native MultiPath Capability > > > > > > > > > > Native support for multiple transport encapsulations (e.g., MPLS, > > > > > SR, SRv6, IP) > > > > > > > > > > Native encoding of SIDs avoids robustness issue... > > > > > > > > > > Service traffic encapsulated with SRv6 Service SID B:C11:2:DT4:: > > > > > is natively > > > > > steered hop by hop along IPv6 routed path... > > > > > > > > > > Encapsulated service traffic is natively steered along IPv6 routed > > > > > path... > > > > > > > > > > > > > > > b) In addition, please consider whether "traditional" should be > > > > > updated for clarity. > > > > > While the NIST website > > > > > <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > > > > > indicates that this term is potentially biased, it is also ambiguous. > > > > > "Tradition" is a subjective term, as it is not the same for everyone. > > > > > There are 4 instances currently: > > > > > > > > > > If a color-aware path is not > > > > > available, local policy may map to a traditional routing/TE > > > > > path (e.g., BGP LU, RSVP-TE, IGP/LDP). > > > > > > > > > > Intra-domain resolution: > > > > > BGP CAR route maps to an intra-domain color-aware path (e.g., > > > > > SR Policy, IGP Flex-Algo, BGP CAR) or a traditional > > > > > routing/TE > > > > > path (e.g., RSVP-TE, IGP/LDP, BGP-LU). > > > > > > > > > > * Local policy may map the CAR route to traditional mechanisms > > > > > that > > > > > are unaware of color or that provide best-effort, such as > > > > > RSVP-TE, > > > > > IGP/LDP, BGP LU/IP (e.g., Appendix A.3.2) for brownfield > > > > > scenarios. > > > > > > > > > > However, to be compatible > > > > > with traditional operational usage, the CAR IP Prefix route is > > > > > allowed to be without color for best-effort. > > > > > --> > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > Kaelin Foody and Alice Russo > > > > > RFC Production Center > > > > > > > > > > > > > > > On Sep 25, 2025, [email protected] wrote: > > > > > > > > > > *****IMPORTANT***** > > > > > > > > > > Updated 2025/09/25 > > > > > > > > > > RFC Author(s): > > > > > -------------- > > > > > > > > > > Instructions for Completing AUTH48 > > > > > > > > > > Your document has now entered AUTH48. Once it has been reviewed and > > > > > approved by you and all coauthors, it will be published as an RFC. > > > > > If an author is no longer available, there are several remedies > > > > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > > > > > > > You and you coauthors are responsible for engaging other parties > > > > > (e.g., Contributors or Working Group) as necessary before providing > > > > > your approval. > > > > > > > > > > Planning your review > > > > > --------------------- > > > > > > > > > > Please review the following aspects of your document: > > > > > > > > > > * RFC Editor questions > > > > > > > > > > Please review and resolve any questions raised by the RFC Editor > > > > > that have been included in the XML file as comments marked as > > > > > follows: > > > > > > > > > > <!-- [rfced] ... --> > > > > > > > > > > These questions will also be sent in a subsequent email. > > > > > > > > > > * Changes submitted by coauthors > > > > > > > > > > Please ensure that you review any changes submitted by your > > > > > coauthors. We assume that if you do not speak up that you > > > > > agree to changes submitted by your coauthors. > > > > > > > > > > * Content > > > > > > > > > > Please review the full content of the document, as this cannot > > > > > change once the RFC is published. Please pay particular attention > > > > > to: > > > > > - IANA considerations updates (if applicable) > > > > > - contact information > > > > > - references > > > > > > > > > > * Copyright notices and legends > > > > > > > > > > Please review the copyright notice and legends as defined in > > > > > RFC 5378 and the Trust Legal Provisions > > > > > (TLP – https://trustee.ietf.org/license-info). > > > > > > > > > > * Semantic markup > > > > > > > > > > Please review the markup in the XML file to ensure that elements of > > > > > content are correctly tagged. For example, ensure that <sourcecode> > > > > > and <artwork> are set correctly. See details at > > > > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > > > > > > > * Formatted output > > > > > > > > > > Please review the PDF, HTML, and TXT files to ensure that the > > > > > formatted output, as generated from the markup in the XML file, is > > > > > reasonable. Please note that the TXT will have formatting > > > > > limitations compared to the PDF and HTML. > > > > > > > > > > > > > > > Submitting changes > > > > > ------------------ > > > > > > > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > > > > > the parties CCed on this message need to see your changes. The parties > > > > > include: > > > > > > > > > > * your coauthors > > > > > > > > > > * [email protected] (the RPC team) > > > > > > > > > > * other document participants, depending on the stream (e.g., > > > > > IETF Stream participants are your working group chairs, the > > > > > responsible ADs, and the document shepherd). > > > > > > > > > > * [email protected], which is a new archival mailing > > > > > list > > > > > to preserve AUTH48 conversations; it is not an active discussion > > > > > list: > > > > > > > > > > * More info: > > > > > > > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > > > > > > > * The archive itself: > > > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > > > > > > > * Note: If only absolutely necessary, you may temporarily opt out > > > > > of the archiving of messages (e.g., to discuss a sensitive > > > > > matter). > > > > > If needed, please add a note at the top of the message that you > > > > > have dropped the address. When the discussion is concluded, > > > > > [email protected] will be re-added to the CC list > > > > > and > > > > > its addition will be noted at the top of the message. > > > > > > > > > > You may submit your changes in one of two ways: > > > > > > > > > > An update to the provided XML file > > > > > — OR — > > > > > An explicit list of changes in this format > > > > > > > > > > Section # (or indicate Global) > > > > > > > > > > OLD: > > > > > old text > > > > > > > > > > NEW: > > > > > new text > > > > > > > > > > You do not need to reply with both an updated XML file and an explicit > > > > > list of changes, as either form is sufficient. > > > > > > > > > > We will ask a stream manager to review and approve any changes that > > > > > seem > > > > > beyond editorial in nature, e.g., addition of new text, deletion of > > > > > text, > > > > > and technical changes. Information about stream managers can be > > > > > found in > > > > > the FAQ. Editorial changes do not require approval from a stream > > > > > manager. > > > > > > > > > > > > > > > Approving for publication > > > > > -------------------------- > > > > > > > > > > To approve your RFC for publication, please reply to this email > > > > > stating > > > > > that you approve this RFC for publication. Please use ‘REPLY ALL’, > > > > > as all the parties CCed on this message need to see your approval. > > > > > > > > > > > > > > > Files > > > > > ----- > > > > > > > > > > The files are available here: > > > > > https://www.rfc-editor.org/authors/rfc9871.xml > > > > > https://www.rfc-editor.org/authors/rfc9871.html > > > > > https://www.rfc-editor.org/authors/rfc9871.pdf > > > > > https://www.rfc-editor.org/authors/rfc9871.txt > > > > > > > > > > Diff file of the text: > > > > > https://www.rfc-editor.org/authors/rfc9871-diff.html > > > > > https://www.rfc-editor.org/authors/rfc9871-rfcdiff.html (side by > > > > > side) > > > > > > > > > > This diff file uses an altered original to show the changes in > > > > > Section 1.1 and the moved text (Acknowledgements and Contributors): > > > > > https://www.rfc-editor.org/authors/rfc9871-alt-diff.html > > > > > > > > > > Diff of the XML: > > > > > https://www.rfc-editor.org/authors/rfc9871-xmldiff1.html > > > > > > > > > > > > > > > Tracking progress > > > > > ----------------- > > > > > > > > > > The details of the AUTH48 status of your document are here: > > > > > https://www.rfc-editor.org/auth48/rfc9871 > > > > > > > > > > Please let us know if you have any questions. > > > > > > > > > > Thank you for your cooperation, > > > > > > > > > > RFC Editor > > > > > > > > > > -------------------------------------- > > > > > RFC9871 (draft-ietf-idr-bgp-car-16) > > > > > > > > > > Title : BGP Color-Aware Routing (CAR) > > > > > Author(s) : D. Rao, Ed., S. Agrawal, Ed. > > > > > WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > > > > > > > > > > > <rfc9871-rfcedresponse.xml> > > > > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
