Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[Robert Raszuk <[e-mail]>]

Shraddha & now Jim,

Apologies but this is not what I was pointing at.

I was asking if you are really going to deploy RTC like pull mechanism on
the inter-as boundaries (even under cooperating administration) ?

Especially here in CT proposal RTC pull model will be almost ineffective if
what you request is color and there are a total 5 colors in the game.

So let's make it clear that the current scheme does not provide much for
scale optimization.

The only option I could perhaps see helping with scale (or in different
word uncontrolled spray of unneeded info) would be ORF like extension where
ASN_X could signal ASN_Y which next hops are of specific interest. But then
we run into again into the RD wall where it makes it even less possible to
filter as you would have to wildcard front of the NLRI ,,, not good.

Bottom line is that CT is hard to scale and hard to aggregate.

Sure like Srihari pointed out let's just blast it and not worry about it.
That's an honest answer - but is this good one ?

Many thx,
Robert.


On Tue, Jul 26, 2022 at 5:29 PM Shraddha Hegde <[e-mail]> wrote:

> Robert,
>
>
>
> Pls refer  below section in https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/
>
> 6.1.1.  Transport Network Intent Requirements
>
>
>
> “The requirements described in this document are mostly applicable to
>
>    network under a single administrative domain that are organized into
>
>    multiple network domains.  The requirements are also applicable to
>
>    multi-AS networks with closely cooperating administration.”
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Tuesday, July 26, 2022 11:41 AM
> *To:* Shraddha Hegde <[e-mail]>
> *Cc:* Jeffrey Haas <[e-mail]>; idr@ietf. org <[e-mail]>; Sue
> Hares <[e-mail]>
> *Subject:* Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to
> 7/27/2022) - Operational Differences
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
>
>
>
> Is pull model really going to be deployed inter-as here ?
>
>
>
> Many thx,
>
> R.
>
>
>
> On Tue, Jul 26, 2022, 06:34 Shraddha Hegde <[e-mail]> wrote:
>
> Robert,
>
> As per the current version of
> https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/__;!!NEt6yMaO-gk!GJBkRIbd2z2Uxc4w3M48GhSuxRdU5QPk2ln4S6m0gNzUbsfEIT6hanlUPC7vVD_Kjd1rhwcGLW4F0k72$>
> Ability to aggregate the intent-aware route itself has not been listed as
> a specific requirement.
> While ability to aggregate subscription routes has been listed as a
> requirement.
>
> In case of MPLS forwarding plane, aggregation of intent aware routes is
> not feasible as you need distinct label for each <endpoint, color>. In case
> of SRv6, its feasible to summarize the intent-aware routes but it takes away
> visibility into other granular information such as E2E metric, PE
> reachability etc and such a requirement
> needs more discussion.
>
> A pull model via automatic subscription routes has been listed as a
> scaling requirement for the solution in
> Sec 6.3.2.1 of
> https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/__;!!NEt6yMaO-gk!GJBkRIbd2z2Uxc4w3M48GhSuxRdU5QPk2ln4S6m0gNzUbsfEIT6hanlUPC7vVD_Kjd1rhwcGLW4F0k72$>
> .
> This is a much better scalability option IMO.
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Idr <[e-mail]> On Behalf Of Jeffrey Haas
> Sent: Monday, July 25, 2022 7:45 PM
> To: Robert Raszuk <[e-mail]>
> Cc: idr@ietf. org <[e-mail]>; Sue Hares <[e-mail]>
> Subject: Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022)
> - Operational Differences
>
> [External Email. Be cautious of content]
>
>
> Robert,
>
> On Mon, Jul 25, 2022 at 04:00:32PM +0200, Robert Raszuk wrote:
> > 2.5 min of BGP propagation time for 1.5 million routes (as Jeff
> > stated). Do you think it is not worth to consider an aggregation in such
> a case ?
>
> The 1.5M routes is from the problem statement in SPRING.  I'd suggest you
> take it up with that WG as to whether they think these were intended to be
> aggregatable.
>
> Discussion of what aggregation could look like in a proposal is
> appropriate for IDR.
>
> > > Trolling will result in your posts being put into the moderation queue.
> >
> > Part 3 is about operational differences. Not every difference requires
> > a topology - some do some do not.
> >
> > I quoted sections from both drafts ?
> >
> > I do think this fear of moderation - when just pointing out
> > operational differences and asking clarification questions - simply
> inappropriate.
>
> It's reasonable to ask the authors how they intend to address aggregation.
> It's reasonable to point out text you think supports your thinking.
>
> The following is not reasonable.
>
> "Till that is fixed I recommend that CT draft goes back to the drawing
> board and would not be even accepted as experimental. Its experiment has
> just concluded as a failure."
>
> Seriously.  Stop it.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> [e-mail]
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!ECHaucPlCQgzPUSvACwT0XMDE-oIyExzTyg-OFnep1Tp6WTMEDFBGtqO_t0QbgSod4LHmSUcGA0RJQ$
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!ECHaucPlCQgzPUSvACwT0XMDE-oIyExzTyg-OFnep1Tp6WTMEDFBGtqO_t0QbgSod4LHmSUcGA0RJQ$>
>
>