[Idr] Re: AD review of draft-ietf-idr-cpr-04

["Dongjie (Jimmy)" <[e-mail]>]

Hi John,

Thanks a lot for your review and suggestions. We just uploaded a new revision to incorporate them. 

And please see inline for some replies:

-----Original Message-----
From: John Scudder <[e-mail]> 
Sent: Thursday, January 23, 2025 5:29 AM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-idr-cpr-04

Hi Authors, WG,

Thanks for your patience as I completed this review.

I’ve supplied my questions and comments in the form of an edited copy of the draft. Minor editorial suggestions I’ve made in place without further comment, more substantive questions and comments are done in-line and prefixed with “jgs:”. You can use your favorite diff tool to review them; I’ve attached the iddiff output for your convenience if you’d like to use it. I’ve also pasted a traditional diff below in case you want to use it for in-line reply.

Thanks,

—John

--- draft-ietf-idr-cpr-04.txt	2025-01-22 13:37:20
+++ draft-ietf-idr-cpr-04-jgs-comments.txt	2025-01-22 16:22:13
@@ -129,17 +129,24 @@
    statements and requirements for inter-domain intent-aware routing.
 
    The inter-domain path can be established using either MPLS or IP data
-   plane.  In MPLS-based networks, the traditional inter-domain approach
+   plane.  In MPLS-based networks, the usual inter-domain approach
    is to establish an end-to-end LSP based on the BGP Labeled Unicast
    (BGP-LU) mechanism as defined in [RFC8277].  Each domain or area
    border node needs to perform label swapping for the end-to-end BGP-LU
    LSP, and encapsulate the label stack which is used for the intra-
    domain LSP within the subsequent network domain or area.
++--
+jgs: I had a hard time knowing what the preceding means, starting with 
+"Each domain or area". AFAIK, each domain's *ingress border node* needs 
+to label-swap the e2e LSP and *impose* (or push) the label stack used 
+within its own domain. I don't think this is usually called "encapsulate"
+in the MPLS terminology, and in any case, this doesn't come through clearly.
++--

[Jie] It has been updated with the text you suggested, thanks. 

 
-   While in IP-based networks, the IP reachability information can be
+   In IP-based networks, the IP reachability information can be
    advertised to network nodes in different domains using BGP, so that
    all the domain or area border nodes can obtain the routes to the IP
-   prefixes of the destination node in other domains.  With the
+   prefixes of the destination nodes in other domains.  With the
    introduction of SRv6 [RFC8402] [RFC8754] [RFC8986], BGP services are
    assigned with SRv6 Service SIDs [RFC9252], which are routable in the
    network according to its SRv6 locator prefix.  Thus, the inter-domain @@ -186,11 +193,31 @@
    plane, the dedicated transport label or SID for the inter-domain path
    is not needed, so that the encapsulation efficiency could be
    optimized.
++--
+jgs: I have a hard time understanding the final sentence above, 
+starting "In the data plane". I guess maybe you mean by using a flat 
+model you eliminate one layer of abstraction and thus you eliminate a 
+label or SID from the header. OK. A more understandable (to me!) 
+rewrite might be, "In the data plane, a dedicated transport label or 
+SID for the inter-domain path is not needed, resulting in a smaller 
+encapsulation than with other options."

[Jie] It has been updated with most of the text you suggested, and "smaller encapsulation overhead" is used. 
[Jie] The elimination of the transport label or SID is because of the reachability of IP prefixes, more specifically the reachability of SRv6 Service SIDs in this case. 
 

+I wonder if you should add the disclosure that "This comes at the cost 
+of larger control and forwarding plane state than a more hierarchical 
+model would require", though. That is, assuming I am not mistaken about 
+that. I do agree that in some deployments, the added overhead will be acceptable.

[Jie] I agree that with this approach, additional colored prefixes needs to be advertised in IPv6 Unicast and the forwarding states needs to be installed on routers. While the same cost would be required in other intent-based routing mechanisms, the difference is in which AFI/SAFI such information is distributed. This is analyzed in the operational considerations section. 

++--
+
    The existing IPv6 Address Family and Color Extended Community could
    be reused for the advertisement of IPv6 Colored Prefixes without new
    BGP extensions, thus this mechanism is easy to interoperate and can
    be deployed incrementally in multi-domain networks.
++--
+jgs: Please see my comment in the Security Considerations section 
+regarding compliance with the RFC 8402 architecture. I think it would 
+be wise (in addition to updating the SecCons section) to add a 
+paragraph here explaining/emphasizing how your proposal fits into the 8402 model.
++--

[Jie] The beginning of the operational consideration section says that CPR can be used in multi-domain scenarios where these domains belong to the same operator, or there is trust model between these domains. It means these domains belong to the same trusted domain, so this still complies with RFC 8402. We've added some text about the same trusted domain when "multiple domains" is mentioned. 

 
 2.  BGP CPR
 
@@ -376,11 +403,35 @@
    performed, then the intra-domain color-aware paths in each network
    domain which the CPR route is resolved to are used for forwarding the
    SRv6 service traffic.
++--
+jgs: I found the above difficult to follow for a few reasons. Rather 
+than provide specific critiques, let me offer a rewrite for you to consider.
 
+NEW:
+   With the CPR routing mechanism, the ingress PE node which receives
+   the SRv6 service routes follows the behavior of SRv6 shortest path
+   forwarding (refer to Section 5 and 6 of [RFC9252]).  The SRv6 service
+   SID carried in the service route is used as the destination address
+   in the outer IPv6 header that encapsulates the service packet.  If the
+   corresponding CPR route has been received and installed, longest
+   prefix matching of SRv6 service SIDs to the Colored Prefixes is
+   performed.  The next hop found as a result of this prefix matching
+   will be an intra-domain color-aware path and will be used for 
+   forwarding the SRv6 service traffic, until it reaches the next ingress
+   PE and the process repeats, or until it reaches its destination.
+
+Is that accurate? It does neglect the corner case where the ingress PE 
+is also the egress PE and there is no intra-domain component of the 
+forwarding on that leg, but I think that's OK.

[Jie] Thanks for the text, we used most of it as is in the updated draft. 


++--
+
+
 3.  Encapsulation and Forwarding Processes
 
    This section describes the encapsulation and forwarding process of
    data packets which are matched with the corresponding CPR route.
+   
+   The topology of Figure 1 is used in each example.
 
 
 
@@ -424,7 +475,36 @@
    BR23->BR31: (PE1, PE3:CL1.DT::)(C-pkt)
    BR31->P3  : {(BR31, P3)(PE3; SL=1)}(PE1, PE3:CL1.DT::)(C-pkt)
    P3  ->PE3 : {(BR31, PE3)}(PE1, PE3:CL1.DT::)(C-pkt)
++--
+jgs: Sometimes you refer to ASBR11, sometimes to BR11, etc. Is there 
+some significance to referring to ASBR vs. BR? If so, please help me understand.
+If not, please pick one terminology and stick with it (including the 
+terminology used in Figure 1, so either follow the labels used in 
+Figure 1, or redraw Figure 1).

[Jie] BR was used to shorten the length of the lines of encapsulation examples. All of the BRs have been replaced by ASBR in the latest update. 


++--
++--
+jgs: The representation of IPv6 and SRH in section 6 of [RFC8754] has 
+no use of {curly braces}. This notation is also not used in RFC 8986. I 
+don't know what it means when you use it. Please add an explanation.
+If it's meant to indicate an outer vs. inner encapsulation, the 
+convention used in RFC 8986 seems to be that no additional braces, 
+parentheses, etc are used, e.g. S. 5.1 of that RFC has,
 
+   After the H.Encaps behavior, P1' and P2' respectively look like:
+
+      (T, S1) (S3, S2, S1; SL=2) (A, B2)
+      (T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)
+      
+So following that example you'd simply get rid of the braces and not 
+replace them with anything.

[Jie] Agreed, the braces have been removed. 


++--
++--
+jgs: What is .DT? I don't see such a thing defined in RFC 8986, only a 
+zoo of End.DTn, viz DT4, DT6, DT46, DT2U and DT2M. If you mean .DT6, 
+please use the whole notation. If you mean something different, help me 
+understand or let me know where the notation is defined.
++--

[Jie] The intention was to refer to all DT-style SRv6 service SIDs. It seems this is confusing. We have updated them with DT6 as one example. 


+
    In some network domains, SRv6 Flex-Algo may be used to provide
    intent-aware intra-domain paths.  The encapsulation is similar to the
    case with SRv6 Policy.
@@ -513,11 +593,24 @@
    ingress PE nodes along the border nodes, it is required that the
    route aggregation be disabled for IPv6 unicast routes which carry the
    color extended community.
++--
+jgs: Echoing my earlier comment on the Introduction, it seems to me 
+that the implications of the last clause (that the routes that carry 
+the CEC can't be aggregated) is fairly major in terms of scaling, since 
+it means every PE must have its loopback advertised everywhere within the domain.
+I don't necessarily need this to be directly spoken to here, but I'd 
+like a confirmation that I've understood correctly.
++--

[Jie] Your understanding is correct, additional colored prefixes needs to be advertised. While as I mentioned in early reply, this cost is required as long as intent-based routing is introduced, as information of color-aware paths needs to be added to BGP. 


    All the border nodes and the ingress PE nodes need to install the
    Colored locator prefixes into the RIB and FIB.  For transit domains
    which support the CPR mechanism, the border nodes can use the tuple
    (N, C) to resolve the CPR routes to intent-aware intra-domain paths.
++--
+jgs: I can guess that C is color, and after I read a few more lines 
+down I can work out that N is next hop, but please define them here, as 
+in "... tuple (N, C) where N is next hop and C is color, to resolve..."
++--

[Jie] OK, the definition of N and C is added. Actually their definition appears in 2.3 for the first time. 


    For transit domains which do not support the CPR mechanism, the
    border nodes would ignore the color extended community and resolve
    the CPR routes over a best-effort intra-domain path to the next-hop @@ -587,12 +680,25 @@
    prefixes.  Thus it is considered that the impact is acceptable.
 
    As the CPR routes are distributed across multiple network domains,
++--
+jgs: I am concerned by the above clause. Consider RFC 8402 Section 8:
+
+   By default, SR operates within a trusted domain.  Traffic MUST be
+   filtered at the domain boundaries.
+
+One trusted domain, with filtering at the boundary. Not "multiple 
+network domains".
+
+If the RFC 8402 architectural requirement no longer applies in this 
+context, please help me see why. If your proposal actually complies 
+with the RFC 8402 architecture, please add language that makes this clear.
++--

[Jie] We have added text to explain that these multiple domains belong to the same trusted domain. 

Many thanks, 
Jie


    the mapping relationship between the intent and the IPv6 Colored
    Prefixes are observable to BGP nodes in those network domains. it is
-   possible for a man-in-the-middle attacker to identify packets
+   possible for an on-path attacker to identify packets
    associated with a particular intent.  While this is similar to other
    intent-based mechanisms, as the packets will also be encapsulated
-   with necessary information to represent and fulfil the intent.
+   with necessary information to represent and fulfill the intent.
 
    The security considerations as described in [RFC4271] [RFC4272] and
    [RFC8754] apply to this document.