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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
