suehares
commented
4 months ago G1-01 review of -07 text:
Status: Needs update to text -07-text status: After discussion with authors, this comment is closed.
The following text in section 2.5 -07 does not specifically indicate the TEA procedures in RFC9012 section 6 apply to BGP CAR routes (AFI/SAFI = 1/83 or 2/83) or VPN CAR routes (AFI/SAFI = 1/84, 2/84).
It does state:
- recursive resolution (section 8) applies to car routes,
- BGP CAR route can be advertised with TEA or Tunnel Encapsulation EC per section 6.
Are you also allow VPN CAR routes (SAFI 84) to be associated with TEA or Tunnel Encapsulation EC per section 6?
Section in 2.5: "A BGP CAR route may recursively resolve over a BGP route that carries TEA and follows Section 6 of [RFC9012] for validation. In this case, procedures of section 8 of [RFC9012] apply to BGP CAR routes, using color precedence as specified above for resolution. Among other options, a BGP CAR BR may also advertise a BGP CAR route to an ingress BR with a specific BGP next hop per color, with a TEA or Tunnel Encapsulation EC, as per Section 6 of [RFC9012]."
Upon discussion with DJ and Swadesh, this issue is closed.
G1 - Editorial on Procedure
G1-1 - Clarity in section 2.5 - BGP CAR Route Resolution*
Old Text:/ A BGP CAR route may recursively resolve over a BGP route carrying Tunnel Encapsulation attribute (TEA). In this case, procedures of section 8 of [RFC9012] apply to BGP CAR routes, using color precedence as specified above for resolution. Among other options, a BGP CAR BR may advertise a BGP CAR route to an ingress BR with a specific BGP next hop per color, with a TEA or Tunnel Encapsulation EC, as per Section 6 of [RFC9012]. /
Problem:
Do you want to support all tunnel types for TEA or just some?
For example, how are you going to handle draft-ietf-idr-sr-policy-safi-00?
If you support draft-ietf-idr-sr-policy-safi-00, the text may be a problem.
G1-2 - Section 2.9.2, T-bit procedures + section 2.11 error handling
Old Text in section 2.9.2 / o T: Transitive bit, applicable to speakers that change the BGP CAR next hop
T bit unset to indicate TLV is non-transitive. An unrecognized non-transitive TLV MUST NOT be propagated by a speaker that changes next hop
/ Old text in section 2.11 /
Problem: The correction for the T-bit is good, but you changed:
-05 Old text:/ Speaker modifying the BGP next hop /
to -06 text/ If a speaker that performs encapsulation to the BGP next hop /
Question to ask yourself:
G1-3 - Technical Section 2.9.4 -
2.5 Old text:/ For a CAR route, Color-EC color takes precedence over the route's effective intent color (LCM-EC if present (Section 2.9.4), or else NLRI color). /
2.9.4 Old text:/ If present, LCM-EC is the effective intent of a BGP CAR route.
LCM-EC Color is used instead of the Color in CAR route NLRI for procedures described in earlier sections such as route validation, resolution, AIGP calculation and steering.
The LCM-EC MAY be used for filtering of BGP CAR routes and/or for applying routing policies for the intent, when present. /
The technology is correct, but the procedure in section 2.9.4 leaves the reader lost. One of thre choices might be made: a) add effective color to the definitions wiht the text from 2.5. b) repeat the definition from 2.5 in 2.9.4, or c) refer back to section 2.5.
G1-4- Section 2.11, Propagation of multiple instances in non-key TLV handling
Old text:/
Need to specify what "Ignored means".
Why: What does "ignored" mean?
It is not processed and not forwarded in packet?
Is it not processed and forwarded in Update packets sent?
G1-5 - Section 5 claims need to be reduced to what is in text
Old text:/ While the requirements and design principles generally apply to any transport, the analysis in this section focusses on MPLS / SR-MPLS transport since the scaling constraints are specifically relevant to these technologies. BGP CAR SAFI is used here, however the considerations apply to any BGP SAFI that's used with MPLS/SR-MPLS, such as [RFC8277] or [RFC8669]. / Error: This is a big claim to indicate any BGP SAFI.
Correction: I suspect you many to either BGP CAR SAFI with either Type 1 or Type 2, and BGP CAR VPN SAFI.
If you are doing theoretical proof in the text, then you must state theoretical proof.
Your theoretical proofs, must either stay to the diagrams or provide theoretical proof of the claims.
G1-6 Section 7.1.1 needs clarity in split between assignment and BGP CAR procedures
Old text:/ The SRv6 Service SID that is advertised with a service route is allocated by an egress PE from a routed intent-aware locator prefix (Section 3.3 of [RFC8986]). Service steering at an ingress PE is via resolution of the Service SID signaled with the service route ([RFC9252]).
The intent-aware transport path to the locator of the egress PE is provided by underlay IP routing, such as IGP Flex-Algo [RFC9350] within a domain, and BGP-CAR across multiple IGP domains or BGP ASNs.
An SRv6 locator is assigned for a given intent or color. This locator prefix is distributed using BGP-CAR to ingress PEs in a remote domain. The locator prefix may also be summarized on a border node along the path and a summary route distributed to ingress PEs. An IP Prefix CAR route (Type-2) is defined for this purpose described in Section 2.9.3 and Section 8.
The SRv6 locator may be shared with an IGP Flex-Algo, or may be assigned specific to BGP CAR for a given intent. A BGP CAR advertised SRv6 locator prefix may also be used for resolution of the SRv6 service SID advertised for best effort connectivity. /
New Text: / The SRv6 Service SID that is advertised with a service route is allocated by an egress PE from a routed intent-aware locator prefix (Section 3.3 of [RFC8986]). Service steering at an ingress PE is via resolution of the Service SID signaled with the service route ([RFC9252]).
An SRv6 locator prefix is assigned for a given intent or color.
The SRv6 locator may be shared with an IGP Flex-Algo, or may be assigned specific to BGP CAR for a given intent.
Transport Path: The intent-aware transport path to the locator of the egress PE is provided by underlay IP routing, such as IGP Flex-Algo [RFC9350] within a domain, and BGP-CAR across multiple IGP domains or BGP ASNs.
Procedures for BGP CAR technology (BGP CAR SAFI and VPN CAR SAFI): The SRv6 locator prefix is distributed using BGP-CAR to ingress PEs in a remote domain.
The locator prefix may also be summarized on a border node along the path and a summary route distributed to ingress PEs. An IP Prefix CAR route (Type-2) is defined for this purpose described in Section 2.9.3 and Section 8.
A BGP CAR advertised SRv6 locator prefix may also be used for resolution of the SRv6 service SID advertised for best effort connectivity. /
G1-7: Section 7.1.2 Non-routed Service SID
Problem: text needs to clearly differentiate between: a) Who node assigns of SIDs b) BGP Procedures c) and traffic forwarding.
I've provided an example below.
Old text:/ The SRv6 Service SID allocated by an egress PE is not routed. The service route is advertised by the egress PE with a Color Extended- Community C ([RFC9252] section 5).
The intent-aware path within an egress domain is provided by an SR-TE or similar policy to the egress PE (E, C) [RFC9256]. This (E, C) policy is distributed into the multi-domain network from egress BRs using a BGP-CAR Type-1 route, towards ingress PEs in other domains. This signaling is the same as for SR-MPLS, as described in earlier sections.
The (E, C) BGP CAR Type-1 route is advertised from a BR with an SRv6 transport SID allocated from a locator assigned for the intent C. An SR-PCE or local configuration may ensure multiple BRs in the egress domain that originate the (E, C) route advertise the same SRv6 transport SID.
An ingress PE in a remote domain steers a received service route with Color C via this (E, C) BGP CAR route, as described in Section 3.
Additionally, the ingress PE resolves the SRv6 transport SID received in the (E, C) CAR route via another underlay intent-aware route. BGP-CAR may also provide the underlay intent-aware inter-domain reachability to this SRv6 transport SID:
An egress domain BR advertises an IP Prefix Type-2 CAR route for the locator prefix that covers the SRv6 transport SID allocated by the egress BR for this (E, C) route. This IP Prefix CAR route is distributed across BGP hops in the underlay towards ingress PEs similar to previous case and may be summarized.
Thus, the colored service route resolves via the Type-1 CAR route, which in turn carries a SRv6 transport SID that resolves via the Type-2 CAR route. Multiple Type-1 routes may resolve via a single Type-2 route.
Note: This is the typical resolution order as the Type-2 route provides intent-aware reachability to the BRs that advertise the Type-1 specific routes for each egress PE. However, there can be use-cases where a Type-2 route may resolve via a Type-1 route.
An ingress PE via the recursive resolution above builds the packet encapsulation that contains the SRv6 Service SID and the received (E, C) route's SRv6 transport SID in the SID-list.
Appendix C.3 contains an example that illustrates the control plane distribution, recursive resolution and forwarding behaviors described above.
Note: An SR-policy may also be defined for multi-domain end to end [RFC9256], independent of BGP CAR. In that case, both BGP CAR and SR-TE inter-domain paths may be available at an ingress PE for an (E, C) route (Section 1.2). /
New Text (Suggested rewrite):/ Egress PE assigns Non-routed SIDs The SRv6 Service SID allocated by an egress PE is not routed.
BGP Procedures:
The service route is advertised by the egress PE with a Color Extended- Community C (Color-EC C)(per [RFC9252] section 5).
Type-1 route distributes underlay path:
The intent-aware path within an egress domain is provided by an SR-TE or similar policy to the egress PE (E, C) [RFC9256]. This (E, C) policy is distributed into the multi-domain network from egress BRs using a BGP-CAR Type-1 route, towards ingress PEs in other domains. This signaling is the same as for SR-MPLS, as described in earlier sections.
The (E, C) BGP CAR Type-1 route is advertised from a BR with an SRv6 transport SID allocated from a locator assigned for the intent C. An SR-PCE or local configuration may ensure multiple BRs in the egress domain that originate the (E, C) route advertise the same SRv6 transport SID.
Service Route traffic steer to Type-1 Route:
An ingress PE in a remote domain steers a received service route with Color C via this (E, C) BGP CAR route, as described in Section 3.
SRv6 Transport SID resolution via second route
Additionally, the ingress PE resolves the SRv6 transport SID received in the (E, C) CAR route via another underlay intent-aware route. BGP-CAR MAY also provide the underlay intent-aware inter-domain reachability to this SRv6 transport SID via:
A CAR type-2 route (IP Prefix) for an locator prefix that covers the SRv6 transport SID allocated by the egress BR for this (E,C) route.
This CAR type-2 route would be announced by a BR in the egress domain, and distributed via the BGP CAR in the underlay toward the ingress PEs. This distribution is similar to previous case and may be summarized in another CAR type-2 route prefix.
Thus, the colored service route resolves via the Type-1 CAR route, which in turn carries a SRv6 transport SID that resolves via the Type-2 CAR route. Multiple Type-1 routes may resolve via a single Type-2 route.
Note: This is the typical resolution order as the Type-2 route provides intent-aware reachability to the BRs that advertise the Type-1 specific routes for each egress PE. However, there can be use-cases where a Type-2 route may resolve via a Type-1 route.
Traffic forwarding: An ingress PE via the recursive resolution above builds the packet encapsulation that contains the SRv6 Service SID and the received (E, C) route's SRv6 transport SID in the SID-list.
Appendix C.3 contains an example that illustrates the control plane distribution, recursive resolution and forwarding behaviors described above.
Note: An SR-policy may also be defined for multi-domain end to end [RFC9256], independent of BGP CAR. In that case, both BGP CAR and SR-TE inter-domain paths may be available at an ingress PE for an (E, C) route (Section 1.2). /
G1-8 Section 7.2.1 Hop by Hop IPv6 Forwarding for BGP SRv6
Section 7.2.1 is a set of bullet items rather than a procedure. This procedure needs to be broken into:
a) Forwarding characteristics b) BGP actions c) Scaling
Sub-headings within the text would be helpful for the reader.
G1-9 Section 7.2.2 Encapsulation between BRs for BGP SRv6
Section 7.2.2 is a set of bullet items rather than a procedure. This procedure needs to be broken into:
a) Forwarding characteristics b) BGP actions c) Scaling
Sub-headings within the text would be helpful for the reader.
G1-10 Section 7.3, Remove text - it smells like marketing and will get a negative response.
Change "provides significant operational advantages" to "provides the following benefits".
See comments on section 5. Benefits you theoretical know. If you want to state "significant operational advantages", you will need to prove it with specific results from real world deployments.
G1-11 Section 8 needs references to sections 2.5 and 7.3*
Why isn't this procedure referenced in section 2.5 and section 7.3?
It does not have to be explained but it should be referenced with something like:
New text:/ Note: If routers carry service routes in both BGP-IP [RFC 4271], BGP-LU [RFC8277], and BGP CAR routes (BGP CAR SAFI and VPN CAR SAFI), Section 8 describes the preference between BGP CAR routes.
Section 8 Text: / As described in Section 7.3, infrastructure prefixes are intended to be carried in CAR SAFI instead of SAFIs that also carry service routes such as BGP-IP (RFC 4271) and BGP-LU (RFC 8277). However, if such routes are also distributed in these SAFIs, a router may receive both BGP CAR SAFI paths and IP/LU SAFI paths. By default, CAR SAFI transport path is preferred over BGP IP or BGP-LU SAFI path. /
G1-12 Section 9, sentence 1.
Old text:/ This section illustrates the extension of BGP CAR to address the VPN intent-aware routing requirement stated in Section 6.1.2 of [I-D.hr-spring-intentaware-routing-using-color], using MPLS transport as an example. /
New text: / This section describes the extension of BGP CAR to address the VPN intent-aware routing requirement stated in Section 6.1.2 of [I-D.hr-spring-intentaware-routing-using-color]. All examples in this section using MPLS transport as the transport, but other transports could be used (e.g. SRv6). /
G1-13 Section 9 sequence of actions, unclear procedure.
Three things need to be fixed:
a. Either renumber the actions 1-6a to sequential numbers or explain why you have 2a, 4a, and 6a. b. Use the abbreviations (Color-EC and LCM-EC) consistently across the text. See #3 in the sequence for the Color-EC. c. Explain where you are removing and adding color
G1-14 - section 11, paragraph 2
Old text:/ When color-aware routes propagate across a color domain boundary, there is typically no need for coordinating color assignments, since the IP prefix is unique in the transport network, and hence makes the color scope also unique and non-conflicting. The color only needs to be re-mapped into a local color assigned for the same intent (which is carried in the LCM-EC). /
Warning Security review danger: Assuming not conflict make get you in real trouble. It would be good to check this with the person doing your security early review.
G1-15 Informative references:
Old text:/ [I-D.wang-idr-cpr] Wang, H., Dong, J., Talaulikar, K., hantao, Chen, R., Xie, J., and X. Chen, "BGP Colored Prefix Routing (CPR) for SRv6 based Services", Work in Progress, Internet-Draft, draft-wang-idr-cpr-03, 20 October 2023, https://datatracker.ietf.org/doc/html/draft-wang-idr-cpr- 03. / New text:/ [I-D.ietf-idr-cpr] Wang, H., Dong, J., Talaulikar, K., hantao, Chen, R., Xie, J., and X. Chen, "BGP Colored Prefix Routing (CPR) for SRv6 based Services", Work in Progress, Internet-Draft, draft-wang-idr-cpr-03, 20 October 2023, https://datatracker.ietf.org/doc/html/draft-wang-idr-cpr- 03. /
G1-16: Dead Internet Draft
This Internet draft is dead. Is it being revised?
[I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, Internet-Draft, draft-ietf-mpls-seamless- mpls-07, 28 June 2014, https://datatracker.ietf.org/doc/html/draft-ietf-mpls- seamless-mpls-07.