Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]

[Tom Herbert <[e-mail]>]

On Wed, May 13, 2020 at 1:12 PM Robert Raszuk <[e-mail]> wrote:
>
> John,
>
> May I add one more perspective to this.
>
> 6man just standardized SRH. Why SRH content can not be filled by controller and used for the very same purpose as authors intend to use CRH for ?
>
> Oh one may say there is no compression there ... If so I recommend to take a look at uSID and vSID proposals.
>

Robert,

Thanks for the pointer. Comparing vSID and CRH, it's pretty obvious
that vSID is more flexible, however it is also signficantly more
complex in allowing different variable length SID within the same
packet. The question is whether the complexity of vSID is justified
and will it lead to feasible implementation? Considering that routing
headers will often be processed in the fast path, I believe the answer
tends to be "no" for these sort of things. History has taught us that
when it come to defining network headers, simpler is better for
efficiency, feasibility, and inter-operability. This is precisely why
I like CRH header, it is an incredibly simple format and doesn't
contain a bunch of fields like flags, tags, TLVs, or variable length
SIDs that the WG would need to spend a lot of time on defining to be
correct, but would probably never be used in the real world. I believe
CRH will be a necessary and sufficient protocol format for the
problem.

Tom

> Is it in good interest of anyone deploying segment routing to have to deal with N different non interoperable headers ? Does it make anyone's life easier ?
>
> Kind regards,
> Robert.
>
> PS. So my own side observation lead me to believe it is not about "too early to ask for adoption" ... it is actually "way too late"
>
> On Wed, May 13, 2020 at 10:01 PM John Scudder <jgs=[e-mail]> wrote:
>>
>> I’m a little confused about this conversation and I’d like to ask the chairs for clarification. My actual questions are at the end of this long(ish) message, and can be summarized as (1) does 6man require consent from SPRING before defining routing headers, and (2) what criteria are the chairs using to decide when an adoption call is OK?
>>
>> It seems to me there are at least two, only vaguely related, conversations going on. One of them is a debate about the assertion that 6man can’t even consider taking up CRH unless SPRING approves it. The other is a more free-wheeling line of questioning about “what is CRH for anyway”?
>>
>> I presume both of these relate to Ron’s request for an adoption call. Here’s what the minutes from the interim have:
>>
>> > Bob: Thank you Ron. I think it's too early for adoption call.
>> >
>> > Ron: What is needed to get to adoption call.
>> >
>> > Bob: I can't answer right now.
>> >
>> > Ron: Can I ask on list?
>> >
>> > Bob: OK.
>> >
>> > Ole: Related to what's going on in spring.
>>
>> Too bad we have no audio recording, but that’s not too far from my recollection. Anyway, I don’t think I’ve seen this answered on list yet, so I’m asking again.
>>
>> Regarding the SPRING-related process stuff:
>>
>> I have quite a bit of history with how SPRING was chartered; I was one of the original co-chairs and helped write the charter, god help me. I can tell you for certain there was no intent that SPRING should have exclusive ownership of source routing in the IETF, the name isn’t a power-grab, it’s a clever backronym, as we do in the IETF. If one entity in the IETF were to take charge of all source routing, that sounds more like a new area than a WG. But don’t take my word for it, go read the various iterations of the charter. As anyone who’s looked at the Segment Routing document set can tell, Segment Routing is one, very specific, way of doing source routing. As Ketan and others have pointed out, it’s a pile of architecture plus the bits and pieces to instantiate that architecture. That is fine, but the idea that merely because a technology might be used to instantiate part of that architecture, it’s owned by SPRING, is overreach. Just because a sandwich is a filling between two pieces of starch, doesn’t mean every filling between two pieces of starch is a sandwich. [1]
>>
>> But at any rate, the question for the chairs is: do you think 6man needs SPRING’s permission in order to consider adopting CRH? Does 6man need permission from SPRING for all routing headers, or just some, and if it’s just some, what characterizes them?
>>
>> Regarding the more general “what is CRH for anyway” stuff:
>>
>> This seems to me to be exactly the kind of discussion one would normally have in the context of an adoption call. Why is it not being had in that context? To rewind back to the interim, if it’s still “too early for adoption call”, what has to happen for it not to be too early?
>>
>> Thanks,
>>
>> —John
>>
>> [1] https://cuberule.com
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------