Greetings all, We now have received all necessary approvals and are ready to move this document forward in the publication process at this time.
The AUTH48 status page of this document is available at http://www.rfc-editor.org/auth48/rfc9871. Thank you all for your time and attention during AUTH48. All best, Kaelin Foody RFC Production Center > On Nov 12, 2025, at 6:44 PM, Amanda Baber via RT <[email protected]> wrote: > > Hi Kaelin, > > We've replaced "Label Index" with "Label-Index": > > https://www.iana.org/assignments/bgp-parameters > > thanks, > Amanda > > On Tue Nov 11 19:30:18 2025, [email protected] wrote: >> Hi Dhananjaya and Amanda, >> >> Dhananjaya - >> >>> I believe you mean to omit “NLRI” and “TLV” in the specific route/tlv >>> registrations and not in the name of the registry. >>> >>> That is fine by us. In fact, that is how the current entries in the >>> registry are. So then there should be no change required. >>> Kaelin, is that fine by you ? >> >> You are correct; this means the entries will remain the same in the >> registries at <https://www.iana.org/assignments/bgp-parameters/bgp- >> parameters.xhtml#bgp-car-nlri-types> and >> <https://www.iana.org/assignments/bgp-parameters/bgp- >> parameters.xhtml#bgp-car-nlri-tlv-types>. Instead, we will drop “NLRI” >> and “TLV” from these values in Sections 10.2 and 10.3 of the document >> in order to match how they currently appear in the registries. Let us >> know if this works for you. >> >> You may find these changes reflected in the diff here: >> https://www.rfc-editor.org/authors/rfc9871-lastrfcdiff.html. >> >> >> Amanda - >> >> Thanks for the response; we will update the document on our end >> accordingly. Please update the following: >> >>> b) Please hyphenate “Label-Index” (in the "BGP CAR NLRI TLV Types” >>> registry). >> >> OLD: >> >> 2 Label Index >> >> NEW: >> >> 2 Label-Index >> >> >> Thank you, >> >> Kaelin Foody >> RFC Production Center >> >>> On Nov 7, 2025, at 1:14 AM, Dhananjaya Rao (dhrao) <[email protected]> >>> wrote: >>> >>> Hi Amanda, >>> >>> I believe you mean to omit “NLRI” and “TLV” in the specific route/tlv >>> registrations and not in the name of the registry. >>> >>> That is fine by us. In fact, that is how the current entries in the >>> registry are. So then there should be no change required. >>> Kaelin, is that fine by you ? >>> >>> Regards, >>> -Dhananjaya >>> >>> >>> Cisco Confidential >>> From: Amanda Baber via RT <[email protected]> >>> Date: Thursday, November 6, 2025 at 9:06 PM >>> To: [email protected] <[email protected]> >>> Cc: Swadesh Agrawal (swaagraw) <[email protected]>, [email protected] >>> <[email protected]>, [email protected] <rfc-editor@rfc- >>> editor.org>, [email protected] <[email protected]>, >>> [email protected] <[email protected]>, [email protected] <idr- >>> [email protected]>, [email protected] <[email protected]>, Dhananjaya Rao >>> (dhrao) <[email protected]>, [email protected] >>> <[email protected]> >>> Subject: [IANA #1436091] [IANA] Re: AUTH48: RFC-to-be 9871 <draft- >>> ietf-idr-bgp-car-16> for your review >>> >>> Hi, >>> >>> Just double-checking this one: if every entry in a registry will be, >>> e.g., a TLV, we'll often ask authors if they could omit "TLV" from >>> the name of the registration. Would it make sense to omit "NLRI" and >>> "TLV" here? >>> >>> thanks, >>> Amanda >>> >>> On Thu Nov 06 15:24:47 2025, [email protected] wrote: >>>> 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] <rfc- >>>>> editor@rfc- >>>>> editor.org>, Swadesh Agrawal (swaagraw) <[email protected]>, >>>>> idr- >>>>> [email protected] <[email protected]>, [email protected] <idr- >>>>> [email protected]>, Hares Susan <[email protected]>, >>>>> auth48archive@rfc- >>>>> editor.org <[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]>, rfc-editor@rfc- >>>>>> editor.org <[email protected]>, Swadesh Agrawal >>>>>> (swaagraw) >>>>>> <[email protected]>, [email protected] <[email protected]>, idr- >>>>>> [email protected] <[email protected]>, Hares Susan >>>>>> <[email protected]>, [email protected] >>>>>> <auth48archive@rfc- >>>>>> editor.org> >>>>>> 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] >>>>>> editor.org> 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]>, idr- >>>>>>> [email protected] >>>>>>> <[email protected]>, [email protected] <idr- >>>>>>> [email protected]>, >>>>>>> [email protected] <[email protected]>, [email protected] >>>>>>> <[email protected]>, auth48archive@rfc- >>>>>>> editor.org<[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]>, idr- >>>>>>>> [email protected] <[email protected]>,[email protected] <idr- >>>>>>>> [email protected]>, [email protected] <[email protected]>, >>>>>>>> [email protected] <[email protected]>, auth48archive@rfc- >>>>>>>> editor.org<[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] <rfc-editor@rfc- >>>>>>>>> editor.org> >>>>>>>>> Date: Friday, September 26, 2025 at 3:49 AM >>>>>>>>> To: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh >>>>>>>>> Agrawal >>>>>>>>> (swaagraw) <[email protected]> >>>>>>>>> Cc: [email protected] <rfc-editor@rfc- >>>>>>>>> editor.org>, >>>>>>>>> [email protected] <[email protected]>, [email protected] >>>>>>>>> <[email protected]>,[email protected] <[email protected]>, >>>>>>>>> [email protected] <[email protected]>, auth48archive@rfc- >>>>>>>>> editor.org <[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] <rfc-editor@rfc- >>>>>>>>> editor.org> >>>>>>>>> Date: Friday, September 26, 2025 at 3:49 AM >>>>>>>>> To: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh >>>>>>>>> Agrawal >>>>>>>>> (swaagraw) <[email protected]> >>>>>>>>> Cc: [email protected] <rfc-editor@rfc- >>>>>>>>> editor.org>, >>>>>>>>> [email protected] <[email protected]>, [email protected] >>>>>>>>> <[email protected]>,[email protected] <[email protected]>, >>>>>>>>> [email protected] <[email protected]>, auth48archive@rfc- >>>>>>>>> editor.org <[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]
