[Idr] Re: Opsdir early review of draft-ietf-idr-cpr-02

[Susan Hares <[e-mail]>]

Comments as shepherd:

I’ve suggested text to resolve the two comments from Dan Romascanu.  See Below.

Sue

PS – I’ve loaded the comments on draft-ietf-idr-cpr into a github repository:


From: Dongjie (Jimmy) <jie.dong=[e-mail]>
Sent: Wednesday, June 5, 2024 1:08 PM
To: Dan Romascanu <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: Opsdir early review of draft-ietf-idr-cpr-02

Hi Dan, Thanks a lot for your review and comments, please see some replies inline: > -----Original Message----- > From: Dan Romascanu via Datatracker > Sent: Friday, May 31, 2024 10
External (jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzQyMzFhZDcxNDFkMGVmODY3ZGY5ZGYxZTU4N2NjYWMyLzE3MTc2MDczMTcuODk=#key=868d8f0d9ce53bd73a384bc91b37cdd6>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>


Hi Dan,



Thanks a lot for your review and comments, please see some replies inline:



> -----Original Message-----

> From: Dan Romascanu via Datatracker <[e-mail]<mailto:[e-mail]>>

> Sent: Friday, May 31, 2024 10:08 PM

> To: [e-mail]<mailto:[e-mail]>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> Subject: Opsdir early review of draft-ietf-idr-cpr-02

>

> Reviewer: Dan Romascanu

> Review result: Has Issues

>

> Thus is an early OPS-DIR review of draft-ietf-idr-cpr-02.

>

> The document aims Informational Status.It describes a mechanism to advertise

> IPv6 prefixes in BGP which are associated with Color Extended Communities to

> establish end-to-end intent-aware paths for SRv6 services. Such IPv6 prefixes are

> called "Colored Prefixes", and this mechanism is called Colored Prefix Routing

> (CPR).

>

> Operators that have under their responsibility multi-services networks running

> BGP should be familiar with this document.

>

> From and Operational and Manageability point of view this document is Almost

> Ready. I found two issues that require clarifications.

>

> Operational Considerations are described in Section 4. I found two places where

> clarifications are needed:

>

> 1. The first paragraph is unclear to me. What does the sentence 'While an

> operator may prefer a BGP-based solution for the reasons described there.'

> mean? I guess that this is related to the previous statement (' ... the inter-domain

> intent-aware routing may be achieved with SR Policy across multiple domains,

> and services with specific intent can be steered to SR Policy at the ingress domain

> based on Color') with the intention of defining an exception, but the grammatical

> inconsistency makes the statement vague.

> Clarification is needed.



Sorry for the confusion caused by this text. Actually "the reasons described there" means the reasons described in [I-D.hr-spring-intentaware-routing-using-color], which is referred to in the first half of this sentence.



We can break this into shorter sentences to make this clearer.



Sue (Shepherd)  suggested New text: /

  As described in section 5 of  [I-D.hr-spring-intentaware-routing-using-color],

the inter-domain intent-aware routing may be achieved by creating a logical tunnel

defined by a SR Policy across multiple domains, and  steering traffic for services with

specific intent (signaled by Color) into the ingress of the tunnel.  The logical inter-domain tunnel defined by an

 SR Policy may be established by BGP with the intent being signaled by

 Color Extended Community (Color-EC) or Color in the Tunnel Encaps Attribute

(TEA-ColorTLV).  This document proposes an alternate solution to signal

intent by utilizing specific methods of assigning as the sub-locators of the

node's base SRv6 locator.  /



>

> 2. The following paragraph reads:

>

> > There may be multiple inter-domain links between network domains,. A

>    border node may receive CPR routes from multiple peering border

>    nodes.  Then the border node may take the attributes of the inter-

>    domain links and/or the attributes of the received CPR routes into

>    consideration to select the best path for specific Colored Prefixes

>    to better meet the intent.  The detailed mechanism is up to the

>    operator's policy.

>

> The first sentence seems incomplete. Moreover, what if the network domains

> belong to different operators with different policies? Operator's policies need to

> be somehow synchronized. How?



Thanks for catching this nit. Either the comma in the first sentence should be removed, or the period is removed and an "and” is added to the beginning of the next sentence.



The operator's policy here refers to the mechanism used to select the best path from multiple received CPR routes. Yes the policy used in different domains needs to be consistent. Some coordination between the domains is needed, this is similar to the coordination of the color-mapping policy. We can add some text to make it clear.



Sue (Shepherd)  Suggested new text:/

There may be multiple inter-domain links between network domains

directly or via tunnels (SR Policy tunnels).  A BGP speaker may receive

CPR routes from multiple AS BGP speakers via EBGP.  The local policy of

a BGP speaker may take the attributes of the inter-domain links and the attributes of

the received CPR routes into consideration when selecting the best path

for specific Colored Prefixes to better meet the intent.  The local policy of

a BGP speaker is outside the scope of this document.



In a multiple-domain environment, the policy of BGP speakers in

multiple domains needs to be consistent.  /



Sue: Do you have additional comments on the policy?





Best regards,

Jie