Re: [Idr] IDR interim 25 September, -car type 2 - split to separate document?

[Robert Raszuk <[e-mail]>]

Hi Jeff,

> Presuming you're talking about "color" when you say RD...

Sorry for not being clear ... I did mean RD but my question was generalized
to CT draft.

Thx,
R.


On Fri, Sep 29, 2023 at 5:37 PM Jeffrey Haas <[e-mail]> wrote:

> Robert,
>
>
> On Sep 29, 2023, at 9:59 AM, Robert Raszuk <[e-mail]> wrote:
>
> Hi Jeff,
>
> Aggregation is possible in type 1.
>>
>
> Well the entire purpose of using RD is to transport prefixes disjointly.
>
> I understand that ABR could originate prefixes with its own RD but how
> does it know which prefixes it should aggregate and which not in type 1 ?
>
>
> Presuming you're talking about "color" when you say RD...
>
>
> Do you assume that prefixes with the same color in type 1 will always be
> aggregatable irrespective of other path attributes ?
>
>
> I'm assuming nothing at the moment as I find the current text ambiguous.
> As I noted in my next reply to DJ, if they're not aggregatable, that's
> likely an operational consideration.  Spelling out how aggregation should
> work is important.
>
> Further, if the idea is that for a given aggregate destination the desired
> behavior is that there is only ever one color assigned to the LCM
> throughout the domain, how is that enforced?
>
>
> Then last to me Type 2 is the proposal which addresses many previous
>> attempts to define separate next-hop SAFI (Ilya and I had one such attempt:
>> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-nh-cost-01)
>> and as I recall we were not alone in trying to define it.
>>
>>
>> This broadens the scope from color aware routing even past the "for srv6"
>> justification.
>>
>
> I was assuming the entire purpose of carrying infrastructure routes
> separately from service routes is the scope. Color is a nice add on -
> optional in fact. Tomorrow it can be topology id, yet in few weeks flex
> algo ID etc ...
>
>
> No, it wasn't in scope for the adoptions.  The fact that the format was
> general purpose enough for future discussions was clear from the beginning,
> but considered out of scope for the use case for the adoption - routes with
> color.
>
>
>
> Minimally, we got through a few years of process covering just type 1 for
>> color-aware use cases.  Type 2 shows up literally at WGLC time.
>>
>
> Well I get this. But since the very first version there was a Type
> defined. If so there is a purpose for the type.
>
> And don't you think less RFCs is better ?
>
>
> I think clear RFCs are better.
>
>
> Is it scope creep, but desired scope creep?  Then it likely will push out
>> the RFC publication time as we go through similar review for the new
>> functionality. If it's not fundamental and it's important to ship -car type
>> 1, splitting it out as an extension is an easy option.
>>
>
> Well the spec is experimental. I think the comment above is more towards
> standards track documents. In my understanding experimental drafts are much
> more flexible in accommodating new ideas and additions. Besides there seems
> to be good support for Type 2 already.
>
>
> If this was independent submissions track, "go for it".  It isn't - it's
> an IDR working group document.  We're not going to say "ship whatever you
> want because it has the experimental label on it".  The specifications have
> to be clear enough for multiple parties to implement the experiment.
> That's what we're trying to refine for this discussion.
>
> -- Jeff
>
>