Re: How many Routing Headers?

Bob,

The header size is a perfectly good point and a motivation for my 
looking at the CRH in the first place. My primary interest is in the 
ICAO domain, and the segment routing paradigm looks to be a good fit 
with the way the network operates. However, our air/ground datalinks 
have a low data rate and header size is a big issue. The downside of 
segment routing is the size of the SRH, hence my interest in the CRH. On 
the other hand, the final segment in the list will often be a IPv6 
Address on an aircraft and it just isn't feasible to compress that to a 
16-bit or 32-bit SID.

Using a CRH with an SRH seems to be one way out of the problem. 
Alternatively, a variant of the CRH where the final segment was a full 
IPv6 Address, while all other segments were identified by shorter SIDs, 
would also be interesting. Maybe if there are too many problems with 
multiple routing headers, this sort of mixed approach might be the best 
solution.

I know that encapsulation of the end-to-end packet may also be an 
alternative. However, there is potentially useful information in the 
segment list that is lost if that is in an outer header discarded before 
the packet is uplinked to an aircraft. Encapsulation just makes the 
header size problem worse if segment routing is applied to downlink packets.

Tony

On 26/10/2020 15:38, Bob Hinden wrote:
> Tony,
>
> An issue with multiple routing headers is the percentage of headers to payload could get very high.    Perhaps not a terrible problem for packets with a lot of data, but not great for a TCP acknowledgement.   The goal is to carry data, I think we start to reach the limits of datagram packet switching if the headers get too large.
>
> Bob
>
>
>> On Oct 23, 2020, at 6:47 AM, Tony Whyman <tony.whyman@mccallumwhyman.com> wrote:
>>
>> Reading through draft-bonica-6man-comp-rtg-hdr-23 "The IPv6 Compact Routing Header (CRH)" led me to the thought: why should there only be one Routing Header per packet header?
>>
>> RFC8200 states "Each extension header should occur at most once, except for the  Destination Options header, which should occur at most twice (once  before a Routing header and once before the upper-layer header)".
>>
>> At least this is "should" rather than "must" and the text goes on to say that
>>
>> "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only.  Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation".
>>
>> I read this as a strong steer in the direction of only a single Routing Header per packet while stopping short of actual declaring this to be an error. That is unless a subsequent specification explicitly allows for more than one Routing Header.
>>
>> However, I can see scenarios where a CRH could be preceded or more likely followed by a Segment Routing Header (SRH). For example, I want a packet to visit two intermediate routers (from a small set of routers) before it is delivered to its final destination. The intermediate routers have well known IPv6 Addresses and it is easy enough to assign consistent SIDs to them and configure them into all nodes that need to known these SIDs.
>>
>> On the other hand, the final segment IPv6 Address is not necessarily well known in advance and may be any valid IPv6 Address. It is not realistic to define an SID for such an IPv6 Address.
>>
>> So, why not use a CRH to identify the intermediate routers (by SID) and then follow it by an SRH containing the Final Destination? I can't see any reason as to why this should not work.
>>
>> I read RFC 8200 as saying that if the specification for a Routing Header allows that Routing Header to be used with another routing header, the specification of that Routing Header should say so. Hence, I propose that the next draft of draft-bonica-6man-comp-rtg-hdr-23 should include such a statement.
>>
>> Tony Whyman
>>
>> MWA
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------