Subject: The Goldilocks Point

From: Tony Whyman <[email-masked]>
Date: Wed, 28 Oct 2020 09:38:27 +0000

I have only recently starting looking at the CRH and am wondering why 
the call for adoption has been put on hold and what is being done to 
move the process along? I cannot see an objection strong enough to have 
caused this delay.

I started going down this path by looking at the SRH. I find the idea 
behind segment routing attractive and the SRH is a well thought out way 
to implement it.

However, in the environment that I am coming from we have a low 
bandwidth data link that is a system bottleneck and which cannot be 
readily avoided. An industry mainstay is a VHF wireless data 
communications system that uses a shared 25KHz channel (nominal data 
rate 32K with D8PSK modulation) and p-CSMA for controlling channel 
access. A single channel is often shared by several aircraft in range of 
a given Ground Station and, at most, only about 4 or 5 discrete 
frequencies are available for multi-channel working. All the remaining 
channel in the aviation band are reserved (and fully used) for voice 
communications.

Header size is a big issue for the civil aviation community and the 
problem that I have with the SRH is that while the final segment does 
need to be expressed as a full 16 byte IPv6 Address, 16 bytes is 
over-kill for the other segment ids. Some sort of compression scheme 
seems to be needed here.

To me, the CRH appears to be complimentary to the SRH and tries to do 
the same thing but with a smaller header - which is good. But while the 
SRH seems to big, the current CRH seems to small in that it makes every 
segment id small.

What I would like to see is something that is more in the middle, 
neither too big nor too small, and the Goldilocks  Point that I am 
looking for would seem to be a CRH variant where SID[0] is a full 16 
bytes while the other segment ids are 16 or 32 bit identifiers - a CRH 
that becomes an SRH for the final segment.

Is it possible to use the current delay profitably and to create a 
family of Routing Headers supporting segment routing? i.e.

Type 4 - the SRH

Type 5 - CRH-16

Type 6 - CRH-32

Type 7 - CRH-16 with a 16 byte SID[0]

Type 8 - CRH-32 with a 16 byte SID [0]

Tony Whyman

MWA

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 28 Oct 2020 10:48:13 +0100

Hi Tony,

> But while the SRH seems to big, the current CRH seems to small in that it
> makes every segment id small.

Perhaps this proposal could be of interest to you:
https://tools.ietf.org/html/draft-decraene-spring-srv6-vlsid-04

Aside please observe that SRH and uSID proposals have solved the
compression/size issue well before CRH was even written up. I recommend you
go via SPRINT WG list archives and browse the history of all proposals in
this space before evaluating CRH and how useful it might be.

Best,
Robert.

On Wed, Oct 28, 2020 at 10:38 AM Tony Whyman <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 28 Oct 2020 07:08:33 -0700

On Wed, Oct 28, 2020 at 2:48 AM Robert Raszuk <[email-masked]> wrote:
> Aside please observe that SRH and uSID proposals have solved the compression/size issue well before CRH was even written up. I recommend you go via SPRINT WG list archives and browse the history of all proposals in this space before evaluating CRH and how useful it might be.
>
Robert.

It's not just the compression of segment identifiers in CRH that's
appealing, it's the fact that CRH *just* contains a segment list. It's
a simple data plane protocol. It doesn't contain flags, it doesn't
contain TLVs that any high speed device would just be ignoring anyway,
it doesn't include an HMAC thereby unnecessarily replicating the
functionality of AH (much less breaking AH like SRv6 does).

My understanding is that there is a design team working on compression
for segment routing. If possible, can we ask them to present their
findings in 6man meeting?

Tom

> Best,
> Robert.
>
>
> On Wed, Oct 28, 2020 at 10:38 AM Tony Whyman <[email-masked]> wrote:
>>