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

[Jeffrey Haas <[e-mail]>]

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 <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