Hi, Thanks for the draft. I am the assigned OPSDIR reviewer to conduct an "early" review of this draft. General comments: There are lots of abbreviations in the draft. I'd suggest to add them in the the terminology section. For example, I'd assume BR means Border Router, but there might be different guessing. In this draft, it says E is globally unique, which makes E-C in that order unique. Can you please explain a bit more about the second unique? I suppose it's possible to have two different source nodes, E1 and E2, all reach destination E with color C, correct? The draft has an informative reference to [I-D.hr-spring-intentaware-routing-using-color], which is an important problem statement for this solution. Will the problem statement draft progress as well? Even so, to improve the readability of the bgp-car draft, I'd suggest adding some text for a brief introduction of the problem. IP Prefix NLRI was added in version -02. The use case is where a unique routable IP prefix is assigned a given intent or color. In other words, the IP is overloaded with a color. The same can be achieved using an IP with a color. I'm not totally convinced that this type 2 NLRI is needed. Please clearly specify when it should be used. Please consider adding a section for operation considerations. There are pieces of information about operation and deployment scattered in the document, please consider group them together. There are quite some sentences missing "." at the end. Please do an editorial pass and fix them. Detailed comments with line # from idnits: 478 The value set (or appropriately incremented) in the AIGP TLV 479 corresponds to the metric associated with the underlying intent of 480 the color. For example, when the color is associated with a low- 481 latency path, the metric value is set based on the delay metric. 483 Information regarding the metric type used by the underlying intra- 484 domain mechanism can also be set. comment: This statement lacks a clear definition how the metric should be set. 486 If BGP CAR routes traverse across a discontinuity in the transport 487 path for a given intent, add a penalty in accumulated IGP metric 488 (value by user policy). For instance, when color C1 path is not 489 available, and route resolves via color C2 path (e.g., Appendix A.3). How about the case where encapsulations are different? For example, SR policy in one AS and IGP-FlexAlgo in the other AS vs. SR Policy in both ASes. Section 2.7 504 The (E, C) route inherently provides availability of redundant paths 505 at every hop, identical to BGP-LU or BGP IP. "every hop" is a bit confusing here since it may mean an IGP hop within an AS. To my understanding, this section means ECMP or backup paths can provide protection in case of failure within an AS domain without impact other ASes. "Path Availability" as the section title is not very clear. How about something like "Inherent Path Protection"? 513 BGP ADD-PATH should be enabled for BGP CAR to signal multiple next 514 hops through a transport RR. I'd suggest to change to "SHOULD be enabled". 526 The BGP CAR solution seamlessly supports this (rare) scenario while I'd suggest adding a small paragraph explaining why this is a rare but useful case. I would guess the tow domains used to belong to different administrators, now they're trying to merge under one admin domain. nits: personally I don't like how "(rare)" with parentheses is used here, but I'd leave this to the authors. 806 NLRI instead of the BGP Prefix SID attribute. The BGP Prefix SID 807 Attribute SHOULD be omitted from the labeled color-aware routes when 808 the attribute is being used to only convey the Label Index TLV. Add a reference to Appendix D? 848 BGP CAR SRv6 SID TLV definitions provide the following benefits: 850 * Native encoding of SIDs avoids robustness issue caused by 851 overloading of MPLS label fields. 853 * Simple encoding to signal Unique SIDs (non-transposition), 854 maintaining BGP update prefix packing 856 * Highly efficient transposition scheme (12-14 bytes saved per 857 NLRI), also maintaining BGP update prefix packing minor: I don't think the text belongs to the encoding section. Maybe part of "Operation Considerations"? 1019 * If multiple instances of same type are encountered, all but the 1020 first instance MUST be ignored. 1022 * If multiple instances of same type are encountered, all but the 1023 first instance MUST be ignored. nits: please remove the repetition. 1025 * A TLV is not considered malformed because of failing any semantic 1026 validation of its Value field. Q: When should a TLV be considered malformed? and how should it be handled? 1033 3. Service route Automated Steering on Color-Aware path nits: Service Route Automated Steering on Color-Aware Path Please check to make sure all section titles are consistent. 1044 destination, per-flow, CO-only. For brevity, in this revision, we 1045 refer the reader to the [RFC9256] text. nits: maybe change to something like "For brevity, please refer to [RFC9256] section X for detail."? 1047 Salient property: Seamless integration of BGP CAR and SR Policy. minor: personally I don't think this sentence belong to this section. 1055 4. Intents The section title and content don't seem to match. I don't quite understand the purpose of this section. 1085 A separate document will analyze the BGP CAR supports for 3, 5 and 6. Any reference? 1097 5.1. (E, C) Subscription and Filtering Q: how is this subscription sent between routers? 1115 * If A does not have (E2, C1), it will advertise F (E2, C1) to its 1116 peer B I suppose it meant to be "If A does not have subscription of (E2, C1)" 1124 On-demand filtering procedures are outside the scope of this 1125 document. what's "on-demand filtering"? 1138 Two key principles used to address the scaling requirements are a 1139 hierarchical network and routing design, and on-demand route 1140 subscription and filtering. Q: on-demand filtering is claimed to be out of the scope. (line #1124) 1342 Note: E1 does not need the BGP CAR (451, C1) route Q: what's the benefit? 1545 7. Routing Convergence comments: Maybe section 2.7 and 7 should be put together somehow, but I'll leave this to the authors. 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | NLRI Length | Key Length | NLRI Type |Prefix Length | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Q: what's value of the NLRI Type here? 1664 service route is advertised by the egress PE with a Color Ext-Comm C. nits: "Color Ext-Comm" is only used here once while "Color Extended-Community" elsewhere. Nits: this section 9.2.1 and 9.2.2 needs some editorial work. For example, each bullet point should be a sentence finished with a ".". 1796 CAR SAFI may also be used for best-effort routes in addition to 1797 intent-aware routes. Q: Should a color be specified here? or use the IP Prefix NLRI Type 2? 2008 This extension defines a new SAFI within a BGP and therefore does not it should be two new SAFIs: BGP CAR/83 and BGP VPN CAR/84 2307 The examples use MPLS/SR for the transport data plane. Scenarios 2308 specific to other encapsulations will be added in subsequent 2309 versions. nits: this should be removed. Thanks, Yingzhen