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

[Ron Bonica <[e-mail]>]

Folks,

We appear to dancing around the meaning of the words "solution", "behavior", and "flavor".  While this dance is semantically elegant, it is neither productive nor uplifting.

A better way to determine whether NEXT-C-SID and REPLACE-C-SID are both needed is with a tiny bit more analysis. Specifically:


  *   Determine whether NEXT-C-SID and a REPLACE-C-SID yield the same compression efficiency. That is, update Table 12 through 15 in the analysis document, replacing the CSID column with a CSID NEXT-C-SID and a CSID REPLACE-C-SID column.
  *   Determine whether NEXT-C-SID and a REPLACE-C-SID are compatible with one another. That is, provide an example where an SR path contains 8 segments. Odd numbered segments use NEXT-C-SID and even numbered segments use REPLACE-C-SID. What does the packet look like when it arrives at the first segment. How does it change at each subsequent segments. (Yes, I know that you recommend against doing this for "operational simplicity". But we aren't trying to determine if it is simple. We are trying to determine if NEXT-C-SID and a REPLACE-C-SID work well together at all.)
  *   Determine whether both are needed. That is, describe a use case where one works well and another does not.

I think that this will be much more productive than arguing about "flavors". That is, unless the flavor is "pumpkin spice".

                                                                                                                 Ron




Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[e-mail]>
Sent: Tuesday, October 5, 2021 11:58 PM
To: Robert Raszuk <[e-mail]>; Ron Bonica <[e-mail]>
Cc: James Guichard <[e-mail]>; SPRING WG <[e-mail]>; [e-mail]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Adding to this Robert, indeed SRv6 defines many behaviors.  The question asked about a single 'behavior' could really only be interpreted as asking about single 'solution', as you understood, since a single 'behavior' in SRv6 is non-sensical.  The requirements draft section 4.2 alone requires multiple behaviors be supported, and multiple compression levels in 4.4.4.

Darren

On 2021-10-05, 4:24 PM, "spring" <[e-mail]<mailto:[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]<mailto:[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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/__;!!NEt6yMaO-gk!SJ05xMMUQP04gjOLjvjfnHc9s-g4_SlxXHnM2QzJtLZoAQhHpySsp2ZWQ7k9cvUw$> ).

                                                                                 Ron