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] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[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]>, [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 > > > > > > > > > > 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] <[email protected]> > > > > > > > Date: Friday, September 26, 2025 at 3:49 AM > > > > > > > To: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh Agrawal > > > > > > > (swaagraw) <[email protected]> > > > > > > > Cc: [email protected] <[email protected]>, > > > > > > > [email protected] <[email protected]>, [email protected] > > > > > > > <[email protected]>,[email protected] <[email protected]>, > > > > > > > [email protected] <[email protected]>, 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] <[email protected]> > > > > > > > Date: Friday, September 26, 2025 at 3:49 AM > > > > > > > To: Dhananjaya Rao (dhrao) <[email protected]>, Swadesh Agrawal > > > > > > > (swaagraw) <[email protected]> > > > > > > > Cc: [email protected] <[email protected]>, > > > > > > > [email protected] <[email protected]>, [email protected] > > > > > > > <[email protected]>,[email protected] <[email protected]>, > > > > > > > [email protected] <[email protected]>, 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]
