Closed suehares closed 4 months ago
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:
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.
status-08: Resolved, closed
o T: Transitive bit, applicable to speakers that change the
BGP CAR next hop
+ T bit set to indicate TLV is transitive. An unrecognized
transitive TLV MUST be propagated by a speaker that
changes the 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
Each of these sentences needs a period at the end of the text.
Status: We should discuss this point and close issue G2.
Here's what I understand for your text as answers to my text:
Upon discussion with DJ and Swadesh, this issue is close.
Status: Closed with the text change of: " If present, LCM-EC contains the 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 (Section 2.4), route resolution (Section 2.5), AIGP calculation (Section 2.6)and steering (Section 3).
The LCM-EC MAY be used for filtering of BGP CAR routes and/or for applying routing policies for the intent, when present."
Status: Closed with new text addition.
Old text: (-06)/ If multiple instances of same type are encountered, all but the first instance MUST be ignored. / New text (-07)/
-08-Status: Resolved closed -07-Status: Technical change OK, suggesting one more editorial change
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]. /
New text:/ While the requirements and design principles generally apply to any transport, the logical analysis based on the network design in this section focuses on MPLS / SR-MPLS transport since the scaling constraints are specifically relevant to these technologies. BGP CAR SAFI is used here, however the considerations can apply to [RFC8277] or [RFC8669] used with MPLS/SR-MPLS./
Editorial change suggested for -07 text. New text:/ BGP CAR SAFI is used here, but the considerations can apply to [RFC8277] or [RFC8669] used with MPLS/SR-MPLS./
Content: G1-6 Section 7.1.1 needs clarity in the split between assignment and BGP CAR procedures -08-Status: resolved, closed -07-Status: Split Ok, need editorial changes below
Change 1: Text (-07):/ The intent-aware transport path to the SRv6 locator of the egress PE is provided by underlay IP routing, such as IGP Flex-Algo [RFC9350] within a domain, and as specified in this document BGP CAR across multiple IGP domains or BGP ASNs./ New text:/ The intent-aware transport path to the SRv6 locator of the egress PE is provided by underlay IP routing. Underly IP routing can include IGP Flex-Algo [RFC9350] within a domain, and BGP CAR [this document] across multiple IGP domains or BGP ASNs./
Change 2: Text (-07):/
Content: Section 7.1.2 Non-route Service SID -08-Status: Edit-1(good), Edit-2(unresolved), Edit-3 (unresolved) -08-next steps: Talk to authors, and close. -07-Status: Split done, needs further editing of text (3 edits suggested)
Changes to -07 text: Edit 1: Why: Grammatical - Remove commas that do not add to clarity. -07 text: / 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./
New text: / 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./
Edit 2: Why: indentation does not aid readability: -07 text:/ BGP CAR distribution of SRv6 locator underlay route:
BGP CAR MAY also provide the underlay intent-aware inter-domain route to resolve the intent-aware SRv6 transport SID advertised with the (E, C) BGP CAR route as follows:
New text:/ BGP CAR distribution of SRv6 locator underlay route:
BGP CAR MAY also provide the underlay intent-aware inter-domain
route to resolve the intent-aware SRv6 transport SID advertised
with the (E, C) BGP CAR route as follows:
* An egress domain BR has a SRv6 locator prefix that covers the SRv6
transport SID allocated by the egress BR for the (E, C) BGP CAR
route. The egress domain BR advertises an IP Prefix Type-2 CAR
route for the SRv6 locator prefix, and the route is distributed
across BGP hops in the underlay towards ingress PEs. This
distribution is the same as the previous Section 7.1.1 case. The
route may also be summarized in another CAR type-2 route prefix./
/ Edit 3: -07-text:/
Content: 7.2.1 Hop by Hop IPv6 Forwarding for SR 09-status: Resolved, cleared -08-Status:: Edit-1(ok), Edit-2 (ok), Edit-3(ok), Edit-4(ok) -07-Status: Change made, 4 Technical edits needed.
Edit 1: Section 7.2 - Introduction to 7.2.1 Why: Need clear indication that only some BGP peers are installing prefix
-07-text:/Since an SRv6 locator (or summary) is an IPv6 prefix, it will be installed into the IPv6 forwarding table on a BGP router, such as an ABR or ASBR, for packet forwarding. There is no need to allocate and install per-PE SIDs on each BGP hop with this approach./
New text:/Since an SRv6 locator (or summary) is an IPv6 prefix, it will be installed into the IPv6 forwarding table on a BGP router operating as ABR or ASBR to provide packet forwarding. With this approach, there is no need to allocate and install per-PE SIDs on each BGP hop./
Edit 2 (section 7.2 main header) Why: Forward reference needs to be clearly stated
-07 text:/ A few options to forward packets for BGP SRv6 prefixes described in ([I-D.agrawal-spring-srv6-mpls-interworking] also apply to BGP CAR as follows:/ New text:/ A few options to forward packets for BGP SRv6 prefixes described in ([I-D.agrawal-spring-srv6-mpls-interworking] also apply to BGP CAR. These options are described in sections 7.2.1 and 7.2.2. /
Edit 3 (section 7.2.1) Why: Grammar - Sentence needs to establish reason for the bullet points.
-07 text:/This option employs hop by hop IPv6 lookup and forwarding on both BRs and P nodes in a domain, along the path of propagation of BGP CAR routes./ New text:/ This option employs hop-by-hop IPv6 lookup and forwarding on both BRs and P nodes in a domain along the path of propagation of BGP CAR routes. This option's procedures includes the following: /
Edit 4 (section 7.2.1) Why: Sentence Grammer (comma and textual support for sub-bullet points) -07 text:/
Content: G1-9 Section 7.2.2 Encapsulation between BRs for BGP SRv6 -08-Status: Edit-1 (ok), Edit-2 (ok), Edit-3 (OK), Comment Resolve, closed -07-Status: Changes made, need 3 Technical Edits
Edit-1 Why: Grammar - Bullet points need a sentence to introduce.
-07 text:/ In this design, IPv6 lookup and forwarding for BGP SRv6 prefixes are only done on BGP BRs./ new text:/In this design, IPv6 lookup and forwarding for BGP SRv6 prefixes are only done on BGP BRs. This option includes the following procedures: /
Edit-2 Why: Technical clarity because via RRs or directly is normative rather than informative.
-07 text: / BGP route distribution is enabled between BRs (via RRs, or directly if single-hop eBGP)./ New text: / BGP route distribution is enabled between BRs via RRs, or directly if single-hop eBGP./
Edit-3 (optional) Why: Grammar and clarity
I have rewritten the sentence to provide clarity (optional acceptance).
-07 text:/ o A common SID may be shared by multiple BGP SRv6 prefixes, avoiding per-PE SID allocation and installation on any BGP hop./ New text:/ Multiple BGP SRv6 prefixes may share a common SID avoiding per-PE SID allocation and installation on any BGP hop./
status: closed, textual change made.
-07-Status: Closed upon discussion.
Status: Section 7.3 reference of section 8 is added. Section 2.5 reference is a bit opaque.
Next step: Discuss with authors why section 2.5 is not more direct.
-07 Text includes in section 7.3:/ Note: If infrastructure routes such as SRv6 locator routes are carried in both BGP-IP [RFC 4271] / BGP-LU [RFC8277, RFC4798], and BGP CAR, Section 8 describes the path selection preference between them../
-07 text includes in section 2.5: / The color-aware route (N, C1) may be provided by BGP CAR itself in a hierarchical transport routing design. In such cases, based on the procedures described above, recursive resolution may occur over the same or different CAR route type. Section 7.1.2 describes a scenario where CAR Type-1 route resolves over CAR Type-2./
Section 7.1.2 points to Section 7.1.1 which then points to section 8.
Why isn't a more direct approach for section 2.5 appropriate for section 2.
After discussion with DJ and Swadesh, it appears -07.text takes the right approach. This issue (G1-11 is closed).
-08-Status: Resolved, Closed. -07-Status: No change in -07 text Next step: Discuss with editors. Was this edit just missed?
Change required: Old text (-06):/ 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 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]. All examples use MPLS transport as the transport, but other transports could be used (e.g. SRv6)./
Context: Section 9, Sequence of actions, unclear procedure -08-Status: Edit-1 (ok), closed after Discussion with DJ
-07-Status: Completed the requested renumbering of items and consistent use of Color-EC and LCM-EC. -07-Needs work: 1 edits in the procedure -07-Needs discussion: Discuss the completeness of the description of the VPN procedures with error handling.
Edit 1: Why: This run-on sentence does not clearly specify that the differences between RFC4364 and CAR NLRIs.
Old text:/ VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows same VPN semantics as defined in [RFC4364], the difference being that the advertised routes carry CAR NLRI and associated non-key TLVs defined in Section 2.9.2 and Section 2.9.3 of this document./
New text:/ VPN CAR distribution for (RD, V, CC) requires a new SAFI that follows the VPN semantics defined in [RFC4364] and also supports the distribution of routes with the CAR NLRI with the associated non-key TLVs fields defined in Section 2.9.2 and Section 2.9.3 of this document./
Discussion point: Errors that might occur with [RFC4364] support with CAR NLRI + non-key fields.
DR# The text states that error handling related to CAR NLRI applies to this SAFI NLRIs.
-08-Status: Resolved, closed. -07-Status: Needs revised text (see Edit-1) Next step: Discuss revised text with authors
Edit-1: status: Clarity of text -07 text:/ When color-aware routes propagate across a color domain boundary, there is typically no need for coordinating color assignments to be identical, since the IP prefix is unique in the transport network, and hence provides a unique and non-conflicting scope for the color in an (E, C) route. /
New text:/ When color-aware routes propagate across a color domain boundary, there is typically no need for coordinating color assignments to be identical since the IP prefix is unique in the transport network. This unique IP prefix provides a unique and non-conflicting scope for the color in an (E, C) route. /
Status: completed, close item.
content: draft-ietf-mpls-seamless-mpls - is declared DEAD in datatracker. -08-status: Resolved -07-status: Need to resolve Next step: Discuss with editors
DJ# Removed the reference from draft
Additional Editorials: G1-2a, G1-5, G1-6, G1-7, G1-8, G1-9, G1-12, G1-13, G1-14,
Closed: G1-1, G1-2, G1-3, G1-4, G1-10, G1-11, G1-15, G1-16
Open issues: G1-7 (Edits 2 +3), G13 (discussion) Closed: G1-1, G1-2, G1-3, G1-4, G1-5, G1-6, G1-7, G1-8, G1-9, G1-10, G1-11, , G1-12, G1-13, G1-14,G1-15, G1-16
All issues resolved, closing issue
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.