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

[Dan Romascanu <[e-mail]>]

Thanks for addressing my comments. The proposed edits look good to me.

Regards,

Dan


On Wed, Jun 5, 2024 at 11:04 PM Susan Hares <[e-mail]> wrote:

> 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 <[e-mail]>
>
> > Sent: Friday, May 31, 2024 10:08 PM
>
> > To: [e-mail]
>
> > Cc: [e-mail]; [e-mail]; [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
>
>
>