Re: The Goldilocks Point

[Tom Herbert <[e-mail]>]

On Wed, Oct 28, 2020 at 2:48 AM Robert Raszuk <[e-mail]> wrote:
>
> 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.
>
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 <[e-mail]> wrote:
>>
>> 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
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------