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

[Greg Mirsky <[e-mail]>]

Hi Francois,
thank you for the clarification. It is still not clear how a node selects
which flavor of CSID to use on the next compressed CSID that may happen
also be in the next CSID container. As I understand it, a CSID container
must use the same flavor of compression but CSID containers with different
compression flavors in the same SRH are allowed. Is that correct
understanding?

Regards,
Greg

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <[e-mail]>
wrote:

> Hi Greg,
>
>
>
> A node that supports this draft in its entirety can instantiate SRv6 SIDs
> (e.g., End and End.X SIDs) with any of the three C-SID flavors.
>
>
>
> In particular, a node can instantiate multiple SRv6 SIDs bound to
> different C-SID flavors, possibly with different C-SID lengths. It can also
> instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.
>
>
>
> As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986,
> upon receiving an IPv6 packet with a destination address matching a FIB
> entry that represents one of these locally instantiated SIDs, the node
> processes the packet according to the behavior (and flavor(s)) (i.e.
> pseudocode) of that SID.
>
>
>
> RFC 8754 and 8986 have already standardized these mechanisms and the C-SID
> draft only leverages the same SRv6 dataplane to introduce new endpoint
> flavors for compression.
>
>
>
>
>
> Francois
>
>
>
> *From: *spring <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Tuesday, 5 October 2021 at 23:37
> *To: *Robert Raszuk <[e-mail]>
> *Cc: *Ron Bonica <rbonica=[e-mail]>, James Guichard <
> [e-mail]>, SPRING WG <[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: [spring] WG Adoption call for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>
> 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
>
>