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

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

Hi John,

Thanks for the quick response. Please see replies to your remaining comments inline:


> -----Original Message-----
> From: John Scudder <[e-mail]>
> Sent: Friday, January 24, 2025 12:26 AM
> To: Dongjie (Jimmy) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: AD review of draft-ietf-idr-cpr-04
> 
> Hi Jie,
> 
> Thanks for the quick work! I have a few further comments, below.
> 
> > On Jan 23, 2025, at 3:53 AM, Dongjie (Jimmy) <[e-mail]>
> wrote:
> >
> > Thanks a lot for your review and suggestions. We just uploaded a new
> revision to incorporate them.
> 
> [… trimmed …]
> 
> 1.
> 
> > +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.
> 
> Isn’t there also a difference in which routers have to handle the state in the
> control plane and install it in the FIB? That’s not automatically implicit in the
> use of a different AFI/SAFI.

Yes there is difference in how the states are handled in control plane and data plane with the use of different AFI/SAFIs. For this draft we can add some text to talk about the cost introduced to the IPv6 unicast address family. 

While IMO the cost is not due to changing from hierarchical model to flat model, as the colored prefix would serve as an aggregation of all VPN SIDs with the same intent. The cost comes from the introduction of intent-awareness to routing in general. 


> 
> 2. I think this rewrite is in the right direction:
> 
>    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 which belong to
>    the same trusted domain.
> 
> The repeated use of the word “domain” is confusing, though. It’s not your
> fault, it’s the fault of the entire networking field overusing the word… but
> how about something like:
> 
> NEW:
>    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-autonomous system
>    networks which belong to
>    the same trusted domain (in the sense used by Section 8 of [RFC8402]).
> 
> Similarly, perhaps
> 
> OLD:
>    different operators which makes them belonging to the same trusted
>    domain.
> 
> NEW:
>    different operators which makes them belong to the same trusted
>    domain (in the sense used by Section 8 of [RFC8402]).

The suggested text looks good, will use it in next update, thanks!

> 
> 3. Following from the previous item, I wonder if it would be OK to replace
> “network domain” with “autonomous system” throughout the document. If
> you are carefully avoiding saying “autonomous system” because it’s too
> limiting and you can cite at least one case where it would be wrong, it's fine
> to stay as it is now, but otherwise I think being more specific will help… and
> this is an IDR document, after all, and BGP’s main unit of hierarchy is still the
> autonomous system and not the vague “network domain”.

Sounds reasonable, we will go through the document and replace network domain with autonomous system when possible. 

Thanks again!

-Jie


> —John