Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Greg Mirsky <[e-mail]>]

Hi Robert,
as I understand it, you believe everything that is written in the draft. I
hope you can help me find an answer to one simple question:

Can a node that supports this draft in its entirety, i.e., supports all
"flavors" defined in the document, process received SRv6 packet with the
SRH encoded according to the specification?

So far, the proponents of the draft referred to "planning" how flavors of
SRv6 SID compressed. To the best of my understanding, that is is a clear
demonstration of the incompatibility between flavors defined in the CSID
draft. Regardless of what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <[e-mail]> wrote:

> Ron & SPRING WG chairs,
>
> Through this discussion we first have seen a debate if we need one or more
> data planes to compress SIDs in SRv6. WG clearly stated we need one.
>
> Following that we have observed a first terminology shift to see if asking
> how many solutions should be supported will work any better. To that many
> WG members clearly stated that they support one solution.
>
> Well please notice that the draft in question in its introduction states:
>
> Abstract
>
>    This document defines a compressed SRv6 Segment List Encoding in the
>    Segment Routing Header (SRH).  *This solution* does not require any SRH
>    data plane change nor any SRv6 control plane change.  *This solution*
>    leverages the SRv6 Network Programming model.
>
> So based on my understanding of English the entire draft talks about a
> single solution.
>
> Then suddenly a new question popped up: how many behaviours are
> acceptable.
>
> I bet number of folks including myself said "one" keeping in mind previous
> discussions and the definition of "one" meaning based on the SRv6 data
> plane in compliance to [RFC8402], [RFC8754] and [RFC8986].
>
> Interestingly enough the draft in question defines not behaviours but
> flavors as new variants of the already defined behaviors in Standards Track
> RFCs. Namely it defines:
>
> 4.1.  NEXT-C-SID Flavor
> 4.2.  REPLACE-C-SID Flavor
>
> The newly defined behaviour End.XPS is optional.
>
> So if there is anything to ask here is to check if WG is ok with two
> flavors or not. I do not recall that question has ever been asked formally
> during the WG adoption call.
>
> With that let's note that optimal compressed SID size may be different
> network to network. One size does not fit all. Draft says:
>
> 6.1.  C-SID Length
>
>    The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.  A
> *   C-SID length of 16-bit is recommended.*
>
>    The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths.
> *   A C-SID length of 32-bit is recommended.*
>
> While I personally think 8-bit should be an option, if we choose a single
> flavor we will introduce suboptimality for no good reason. Hardware
> capable of supporting any flavor clearly can do LPM on locator. Also
> hardware capable of supporting one flavor can support few other flavors as
> this is pretty much just an offset game.
>
> Kind regards,
> Robert
>
>
>
> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=
> [e-mail]> wrote:
>
>> Pablo,
>>
>>
>>
>> Ae you sure? Please look at the question as Joel asked it (
>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/
>> ).
>>
>>
>>
>>
>> Ron
>>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>