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) <[email protected]>
Sent: Tuesday, October 5, 2021 11:58 PM
To: Robert Raszuk <[email protected]>; Ron Bonica <[email protected]>
Cc: James Guichard <[email protected]>; SPRING WG
<[email protected]>; [email protected]
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"
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>
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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
