Subject: RE: How many Routing Headers?

From: Tony Whyman <[email-masked]>
Date: Tue, 27 Oct 2020 00:13:12 +0000

Yes, that is the problem, except that only the last datalink has low bandwidth.

-------- Original message --------From: Ron Bonica <[email-masked]> Date: 26/10/2020  22:56  (GMT+00:00) To: Tony Whyman <[email-masked]>, Bob Hinden <[email-masked]> Cc: IPv6 List <[email-masked]> Subject: RE: How many Routing Headers? Tony,I think that the CRH alone may offer a solution to the problem. But before I make that claim, let me make sure that I understand the problem......- You are sending a packet along the path A->B->C->D- All links are low speed, so packet overhead is an important issue- The endpoint, D, is a device on an aircraft. It knows enough about IPv6 to ignore an RH with Segments Left equal to 0. - When A sends the packet, it knows that the penultimate segment is C. But it doesn't know D's IPv6 address. So, Node A relies on Node C to do the late binding.Am I understanding the problem correctly?                                                                                                       RonJuniper Business Use Only-----Original Message-----From: ipv6 <[email-masked]> On Behalf Of Tony WhymanSent: Monday, October 26, 2020 12:38 PMTo: Bob Hinden <[email-masked]>Cc: IPv6 List <[email-masked]>Subject: Re: How many Routing Headers?[External Email. Be cautious of content]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 fullIPv6 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.TonyOn 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 <[email-masked]> 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>> [email-masked]>> Administrative Requests: >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv>> 6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrA>> QPG9jVAcN6e7I$>> ----------------------------------------------------------------------------------------------------------------------------------------IETF IPv6 working group mailing [email-masked] Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrAQPG9jVAcN6e7I$--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Tue, 27 Oct 2020 00:50:17 +0000

Hi Tony,

I think that CRH can solve your problem without any other Routing headers. In this case, Node A needs to know:

  *   That the packet needs to visit Nodes B, C, and D, in that order
  *   Node B's IPv6 address
  *   The SID's associated with C and D

It encodes all of these in the packet.

Node B needs to know the IPv6 address associated with Node C. It copies that IPv6 address from the CRH-FIB to the IPv6 Destination Address and decrements Segments Left to 1.

Only Node C needs to know the IPv6 address associated with Node D. It copies that IPv6 address from the CRH-FIB to the IPv6 Destination Address and decrements Segments Left to 0.

Let's say that the IPv6 address associated with Node D can be either 2001:db8::dead:beef or 2001:db8::bad:cafe, depending upon some condition. So long as Node C can learn which address represents Node D at the moment, it can install that information in the CRH-FIB associated with Node D.

Node D receives the packet with the correct IPv6 Destination address. It ignores the CRH because Segments Left is equal to 0.

Would this solution work for you?

                                                                                      Ron

Juniper Business Use Only
From: Tony Whyman <[email-masked]>
Sent: Monday, October 26, 2020 8:13 PM
To: Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: RE: How many Routing Headers?

[External Email. Be cautious of content]

-------- Original message --------
From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: 26/10/2020 22:56 (GMT+00:00)
To: Tony Whyman <[email-masked]<mailto:[email-masked]>>, Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: RE: How many Routing Headers?

Tony,

I think that the CRH alone may offer a solution to the problem. But before I make that claim, let me make sure that I understand the problem......

- You are sending a packet along the path A->B->C->D
- All links are low speed, so packet overhead is an important issue
- The endpoint, D, is a device on an aircraft. It knows enough about IPv6 to ignore an RH with Segments Left equal to 0.
- When A sends the packet, it knows that the penultimate segment is C. But it doesn't know D's IPv6 address. So, Node A relies on Node C to do the late binding.

Am I understanding the problem correctly?

                                                                                                       Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Whyman
Sent: Monday, October 26, 2020 12:38 PM
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: How many Routing Headers?

[External Email. Be cautious of content]

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 <[email-masked]<mailto:[email-masked]>> 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
>> [email-masked]<mailto:[email-masked]>
>> Administrative Requests:
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv>
>> 6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrA
>> QPG9jVAcN6e7I$
>> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrAQPG9jVAcN6e7I$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrAQPG9jVAcN6e7I$>
--------------------------------------------------------------------

---

From: Tony Whyman <[email-masked]>
Date: Tue, 27 Oct 2020 10:46:51 +0000

Ron,

Thank you for your description of how the CRB works. The problem I have 
with it is that it is that I believe that it is infeasible, in my 
example, to configure node C with the IPv6 Address associated with node D.

If you ask Google "how many commercial aircraft are there", you get the 
answer

"In 2018, there were 29,398 airliners in service: 26,935 passenger 
transports and 2,463 freighters, while 2,754 others were stored."

True, this will have a taken a hit this year,  but you get the picture - 
we may even end up with more aircraft given a recent trend to flying in 
small business jets and for obvious reasons. And, of course, this is 
before we get on to General Aviation, military aircraft in civilian 
controlled airspace, finally, but by no means least - drones.

Each aircraft has the potential for many end nodes. The architecture 
varies between aircraft type and the actual equipage can depend on 
regional mandates and airline preferences - there are potentially 100s 
of thousands of end nodes, each of which could need to have an SID 
assigned to them (forget CRH-16, we are in to CRH-32 territory here).

Configuring every "node C" that may be deployed with an appropriate 
CRH-FIB would be a major configuration management challenge. Aircraft 
change hands all the time (and have their network identity changed), new 
aircraft are being brought into service and the daily churn to such a 
database would be large. The Operational Requirement requires a 99% 
probability for the availability of end-to-end communication between an 
individual aircraft and Air Traffic Control. Most of the budget for this 
goes on the usual threats of system failures and assumes countermeasures 
for DoS attacks. There just isn't the headroom here to add in the 
probability of human error resulting in CRH-FIB mis-configuration. It 
would just be another <expletive deleted> thing to go wrong and no one 
would want to go there.

When I looked at the CRB draft, my thought was that this was a really 
useful way of compressing an SRH - but only as long as the set of 
Segment End Nodes is relatively small and stable. In my case, that is 
true of the intermediate nodes, but not the final destination.

Some might argue - why not use the CRH in an outer header of an 
encapsulated packet with the full destination address in the inner 
header. My response is that this sort of defeats the object of 
compression. There is also a mobility issue here - but it's best to put 
that in a separate EMail.

Otherwise, what I am really after here is a CRH variant that allows the 
final destination SID (SID[0]) to be a full 16 bytes, with the remaining 
SIDs being 16-bit or 32-bit as appropriate.

Tony

On 27/10/2020 00:50, Ron Bonica wrote:
>
> Hi Tony,
>
> I think that CRH can solve your problem without any other Routing 
> headers. In this case, Node A needs to know:
>
>   * Node B’s IPv6 address
>   * The SID’s associated with C and D
>
> Node B needs to know the IPv6 address associated with Node C. It 
> copies that IPv6 address from the CRH-FIB to the IPv6 Destination 
> Address and decrements Segments Left to 1.
>
> Only Node C needs to know the IPv6 address associated with Node D. It 
> copies that IPv6 address from the CRH-FIB to the IPv6 Destination 
> Address and decrements Segments Left to 0.
>
> Let’s say that the IPv6 address associated with Node D can be either 
> 2001:db8::dead:beef or 2001:db8::bad:cafe, depending upon some 
> condition. So long as Node C can learn which address represents Node D 
> at the moment, it can install that information in the CRH-FIB 
> associated with Node D.
>
> Node D receives the packet with the correct IPv6 Destination address. 
> It ignores the CRH because Segments Left is equal to 0.
>
> *From:* Tony Whyman <[email-masked]>
> *Sent:* Monday, October 26, 2020 8:13 PM
> *To:* Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>
> *Cc:* IPv6 List <[email-masked]>
> *Subject:* RE: How many Routing Headers?
>
> *[External Email. Be cautious of content]*
>
> From: Ron Bonica <[email-masked] <mailto:[email-masked]>>
>
> To: Tony Whyman <[email-masked] 
> <mailto:[email-masked]>>, Bob Hinden 
> <[email-masked] <mailto:[email-masked]>>
>
> Cc: IPv6 List <[email-masked] <mailto:[email-masked]>>
>
> I think that the CRH alone may offer a solution to the problem. But 
> before I make that claim, let me make sure that I understand the 
> problem......
>
> - The endpoint, D, is a device on an aircraft. It knows enough about 
> IPv6 to ignore an RH with Segments Left equal to 0.
> - When A sends the packet, it knows that the penultimate segment is C. 
> But it doesn't know D's IPv6 address. So, Node A relies on Node C to 
> do the late binding.
>
> From: ipv6 <[email-masked] <mailto:[email-masked]>> On 
> Behalf Of Tony Whyman
> To: Bob Hinden <[email-masked] <mailto:[email-masked]>>
> Cc: IPv6 List <[email-masked] <mailto:[email-masked]>>
> 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.
>
> 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
>
>
> > 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 
> <[email-masked] 
> <mailto:[email-masked]>> 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)".
> >>
> >> "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
> >>
> >>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> Administrative Requests:
> >> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv 
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv>
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrAQPG9jVAcN6e7I$ 
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrAQPG9jVAcN6e7I$>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 11:58:28 +0000

Hi all,
Tony, sorry to intrude into you discussion.
But why you need to know addresses of everything in the universe on node C?
C-D looks like neighbors. Number of neighbors should be very limited. Anyway, you need some protocol to populate neighbor table on C, or else forwarding would not be possible.

By the way, CRH (of cSRH - does not matter) could not be mapped to IPv6 address 1:1.
Some local table is needed anyway. It could be "neighbor table" as Ron pointed out.
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Tony Whyman
Sent: 27 октября 2020 г. 13:47
To: Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: How many Routing Headers?

Ron,

Thank you for your description of how the CRB works. The problem I have with it is that it is that I believe that it is infeasible, in my example, to configure node C with the IPv6 Address associated with node D.

If you ask Google "how many commercial aircraft are there", you get the answer

"In 2018, there were 29,398 airliners in service: 26,935 passenger transports and 2,463 freighters, while 2,754 others were stored."

True, this will have a taken a hit this year,  but you get the picture - we may even end up with more aircraft given a recent trend to flying in small business jets and for obvious reasons. And, of course, this is before we get on to General Aviation, military aircraft in civilian controlled airspace, finally, but by no means least - drones.

Each aircraft has the potential for many end nodes. The architecture varies between aircraft type and the actual equipage can depend on regional mandates and airline preferences - there are potentially 100s of thousands of end nodes, each of which could need to have an SID assigned to them (forget CRH-16, we are in to CRH-32 territory here).

Configuring every "node C" that may be deployed with an appropriate CRH-FIB would be a major configuration management challenge. Aircraft change hands all the time (and have their network identity changed), new aircraft are being brought into service and the daily churn to such a database would be large. The Operational Requirement requires a 99% probability for the availability of end-to-end communication between an individual aircraft and Air Traffic Control. Most of the budget for this goes on the usual threats of system failures and assumes countermeasures for DoS attacks. There just isn't the headroom here to add in the probability of human error resulting in CRH-FIB mis-configuration. It would just be another <expletive deleted> thing to go wrong and no one would want to go there.

When I looked at the CRB draft, my thought was that this was a really useful way of compressing an SRH - but only as long as the set of Segment End Nodes is relatively small and stable. In my case, that is true of the intermediate nodes, but not the final destination.

Some might argue - why not use the CRH in an outer header of an encapsulated packet with the full destination address in the inner header. My response is that this sort of defeats the object of compression. There is also a mobility issue here - but it's best to put that in a separate EMail.

Otherwise, what I am really after here is a CRH variant that allows the final destination SID (SID[0]) to be a full 16 bytes, with the remaining SIDs being 16-bit or 32-bit as appropriate.

Tony

-        That the packet needs to visit Nodes B, C, and D, in that order
-        Node B's IPv6 address
-        The SID's associated with C and D

                                                                                      Ron

Juniper Business Use Only
From: Tony Whyman <[email-masked]><mailto:[email-masked]>
Sent: Monday, October 26, 2020 8:13 PM
To: Ron Bonica <[email-masked]><mailto:[email-masked]>; Bob Hinden <[email-masked]><mailto:[email-masked]>
Cc: IPv6 List <[email-masked]><mailto:[email-masked]>
Subject: RE: How many Routing Headers?

-------- Original message --------
From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: 26/10/2020 22:56 (GMT+00:00)
To: Tony Whyman <[email-masked]<mailto:[email-masked]>>, Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: RE: How many Routing Headers?

Tony,

                                                                                                       Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Whyman
Sent: Monday, October 26, 2020 12:38 PM
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: How many Routing Headers?

Bob,

Tony

---

From: Tony Whyman <[email-masked]>
Date: Tue, 27 Oct 2020 12:03:13 +0000

On 27/10/2020 10:46, Tony Whyman wrote:
>
> Ron,
>
> Thank you for your description of how the CRB works. The problem I 
> have with it is that it is that I believe that it is infeasible, in my 
<snip>
> compression. There is also a mobility issue here - but it's best to 
> put that in a separate EMail.

And this I shall do.

One thing that interests me about the Segment Routing paradigm is how it 
seems to fit well with node mobility and multilink and is the topic I 
would also like to get some feedback on.

Our addressing model for an aircraft assigns each one a unique Mobile 
Network Prefix (MNP) and all nodes on board are allocated an IPv6 
Address using that MNP (no real surprises here). The problem is, of 
course, that the MNP is not related to network topology.

There are already several existing global and regional terrestrial 
communications services available for aircraft air/ground 
communications, as well as the global Inmarsat satcom service. An 
aircraft could at a given time, be using any one of those services, or 
perhaps several concurrently in a multilink scenario. If you try and 
route an (uplink) packet from an ATC Centre to an aircraft, how do you 
know how to forward it,  the packet's destination address has an MNP as 
its prefix?

Mobile IPv6 is perhaps one answer and has been looked at several times 
and written into an older version (1st and 2nd editions) of what is 
known in the civil aviation as the ATN/IPS technical manual. I don't 
want to end up writing a critique of Mobile IPv6 in this post, but lets 
just leave it as our exacting mobility environment including multilink 
exposes sufficient issues with Mobile IPv6 that have resulted in a less 
than enthusiastic uptake of the ATN/IPS so far.

We are now working on the 3rd edition, and the objective is to end up 
with a specification that really does lead through to full scale 
deployment. We need to replace the CLNP based ATN/OSI. It has seen 
almost 20 years of service in some parts of the world and we also know 
its limitations too well now. Rather than fix them, the move is to 
finally put in place support for a service based on IPv6.

The model I have for using the SRH (or the CRH if possible). is to see 
it as allowing for the expression of a series of policy rules that are 
used to forward a packet along a path that leads to a node that has full 
or partial visibility of which Air/Ground Communication services are 
available. From there, it can be forwarded to an appropriate Ground 
Station and so.

In a simple example, you may have a scenario where the sender (e.g. an 
Airline) has a policy that says:

* a packet containing message X should preferably be uplinked using a 
terrestrial VHF digital air/ground communications service operated by 
ARINC (under a commercial contract) but,

* if the destination aircraft is not available via ARINC, forward the 
packet on to the Inmarsat SATCOM service and see if they can uplink it.

That kind of policy can be expressed by a two segment SRH header. The 
first SID (in processing order) identifies the policy rule (as above) 
and the second SID is the MNP relative IPv6 address of the destination node.

The source node is in the airline domain and sets the initial packet 
destination to the IPv6 Address of a segment router operated by ARINC 
(some might include this IPv6 Address as the first segment id in a three 
segment id list).

When it arrives at the ARINC router (formally an SR Segment Endpoint 
Node), the router will look at the next segment id (the one that 
expresses the policy). To implement this policy, it must do a look ahead 
to the next segment id (the MNP relative IPv6 Address) in order to 
determine the MNP of the final destination.

* If the ARINC service knows about this aircraft (i.e. it has logged on 
to their service) then the packet destination address is set to an IPv6 
Address that is routeable and the route takes you to an SR Segment 
Endpoint Node which is associated with the aircraft at its current 
location on the ARINC network. Segments left is decremented. When the 
packet arrives at the next SR Segment Endpoint Node, the SRH isagain  
processed, the final destination IPv6 Address becomes the packet's 
destination and it should now be at a point where it can be forwarded 
directly to its destination. The assumption here is that the SR Segment 
Endpoint Node is either a proxy at the Ground Station used for uplink or 
is the "Airborne Router" on the aircraft itself.

* Alternatively, if the aircraft is not logged on to the ARINC network, 
the SID semantic is to forward the packet to Inmarsat. The DA is set to 
the IPv6 Address of a segment router operated by Inmarsat and it is sent 
on its way . The next segment count is not decremented. At Inmarsat, the 
next Segment ID still identifies the policy rule but here, it is simply 
interpreted as:

   - if the aircraft is logged on to Imarsat, forward as above, or otherwise

   - Discard the packet and return an ICMPv6 to report the event if 
appropriate.

This seems to give a useful policy based framework. If ARINC and 
Inmarsat were able to arrive at a commercial agreement to exchange 
aircraft connectivity and dynamic QoS information then more nuances 
could be added to the interpretation of the policy rules.

The above description also glosses over how the (e.g.) ARINC SR 
determines the IPv6 Address used for the DA of a logged on aircraft and 
how it is then routed to the aircraft.

In a simple regional service provider, PMIPv6 might be sufficient for 
mobility management. In such a case, the IPv6 Address is the "Home 
Address " assigned to the aircraft in the local PMIPv6 Domain and normal 
PMIP procedures are used to forward the packet to the destination aircraft.

In a more complex global service, a simple PMIPv6 approach is unlikely 
to be sufficient - which is why ideas such as AERO are being promoted by 
Boeing. The LISP folks are also pushing their approach and a final 
decision has yet to be made. What I am talking about here is the overall 
framework.

It also exposes why I want to have the full MNP relative IPv6 Address as 
SID[0]. There has to be a lookahead to the next segment when the SRH is 
processed for a policy SID. If the final destination IPv6 address was 
buried in an inner header, this wouldn't really work.

Tony Whyman

MWA

---

From: Tony Whyman <[email-masked]>
Date: Tue, 27 Oct 2020 12:06:45 +0000

Because node D is the final destination and, in principle, could be any 
node in the universe. In an EMail branching off this thread, I have 
tried to explain the model of operations that I am thinking about.

On 27/10/2020 11:58, Vasilenko Eduard wrote:
> C-D looks like neighbors. Number of neighbors should be very limited. 
> Anyway, you need some protocol to populate neighbor table on C, or 
> else forwarding would not be possible.
>
> By the way, CRH (of cSRH – does not matter) could not be mapped to 
> IPv6 address 1:1.
>
> Some local table is needed anyway. It could be “neighbor table” as Ron 
> pointed out.
>
> Eduard
>
> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *Tony Whyman
> *Sent:* 27 октября 2020 г. 13:47
> *Subject:* Re: How many Routing Headers?
>
> Ron,
>
> True, this will have a taken a hit this year,  but you get the picture 
> - we may even end up with more aircraft given a recent trend to flying 
> in small business jets and for obvious reasons. And, of course, this 
> is before we get on to General Aviation, military aircraft in civilian 
> change hands all the time (and have their network identity changed), 
> new aircraft are being brought into service and the daily churn to 
> such a database would be large. The Operational Requirement requires a 
> 99% probability for the availability of end-to-end communication 
> between an individual aircraft and Air Traffic Control. Most of the 
> budget for this goes on the usual threats of system failures and 
> assumes countermeasures for DoS attacks. There just isn't the headroom 
> here to add in the probability of human error resulting in CRH-FIB 
> mis-configuration. It would just be another <expletive deleted> thing 
> to go wrong and no one would want to go there.
>
> Otherwise, what I am really after here is a CRH variant that allows 
> the final destination SID (SID[0]) to be a full 16 bytes, with the 
> remaining SIDs being 16-bit or 32-bit as appropriate.
>
> Tony
>
>     -That the packet needs to visit Nodes B, C, and D, in that order
>
>     -Node B’s IPv6 address
>
>     -The SID’s associated with C and D
>
>     Only Node C needs to know the IPv6 address associated with Node D.
>     It copies that IPv6 address from the CRH-FIB to the IPv6
>     Destination Address and decrements Segments Left to 0.
>
>     Let’s say that the IPv6 address associated with Node D can be
>     either 2001:db8::dead:beef or 2001:db8::bad:cafe, depending upon
>     some condition. So long as Node C can learn which address
>     represents Node D at the moment, it can install that information
>     in the CRH-FIB associated with Node D.
>
>     Node D receives the packet with the correct IPv6 Destination
>     address. It ignores the CRH because Segments Left is equal to 0.
>
>     <mailto:[email-masked]>
>     *To:* Ron Bonica <[email-masked]>
>     <mailto:[email-masked]>; Bob Hinden <[email-masked]>
>     <mailto:[email-masked]>
>     *Cc:* IPv6 List <[email-masked]> <mailto:[email-masked]>
>     I think that the CRH alone may offer a solution to the problem.
>     But before I make that claim, let me make sure that I understand
>     the problem......
>
>     - The endpoint, D, is a device on an aircraft. It knows enough
>     about IPv6 to ignore an RH with Segments Left equal to 0.
>     - When A sends the packet, it knows that the penultimate segment
>     is C. But it doesn't know D's IPv6 address. So, Node A relies on
>     Node C to do the late binding.
>
>     From: ipv6 <[email-masked] <mailto:[email-masked]>>
>     On Behalf Of Tony Whyman
>     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.
>
>     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.
>
>     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
>
>
>     > 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
>     >
>     >
>     >> 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)".
>     >>
>     >> "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".
>     >>
>     >> 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.
>     >>
>     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
>     >>
>     >>
>     >>
>     >>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 13:59:05 +0000

Hi Tony,
How I have understood you:
- you have the Backbone (ARINC) network
- access (SATCOM) network
- and number of Gateways (SR Segment Endpoint Node) that has full routing information for both networks. Gateways could distribute the data plane load.
If final destination is not connected to Backbone, then traffic should be forwarded to any gateway - it would find the final destination (or drop the traffic).

But what if you would have additional access network (Starlink)?
It is probably additional gateway in your architecture.
But how ordinary node in backbone would understand where to forward traffic?
It has 2 different gateways now to choose.

1. This approach would not scale above 1 Carrier. It would need gateways that should know all routing information for all carriers involved (and for all objects registered).
2. This approach would have some scalability issues for gateways (it should know all routes from all domains). Not a big problem now, because current scalability of many vendors (2M FIB for IPv6) is less than 0.5M planes that you would like to connect. But what if other objects would be connected too? (ships, cars). The single gateway that has knowledge about everything in the world could be the huge problem in the future. It is difficult to aggregate in mobile case - routes would be very specific (/64?).
3. Additionally, architecture blocks direct short cut between access networks. It may be not so big problem now, but what about the future?
4. It is not possible to choose closest gateway in the backbone. If gateways would be distributed around the Earth, then average additional latency just for backbone part would statistically close to 5us*Square(4*pi*R^2/N)/2. N - is the number of gateways. R=6371km (Earth). If gateway distribution would be not equal (it is guaranteed) - expect much worse latency for some geographies.

Conclusion: you need the backbone knowledge about optimal paths for all objects.
It could be split for realms/domain/VPNs for not to keep all information in every backbone PE.

Answering your original question:
SRv6 is the some sort of tunneling technology (IPv6 header is inside IPv6 header) with many additional nice features.
You could do it as many times as you wish.
Everybody knows in the industry that "any networking problem could be resolved by additional overlay layer".

Eduard
> Sent: 27 октября 2020 г. 15:03
> To: [email-masked]
> Subject: Re: How many Routing Headers? - and the mobility problem
> 
> 
> seems to fit well with node mobility and multilink and is the topic I would also
> like to get some feedback on.
> 
> Our addressing model for an aircraft assigns each one a unique Mobile Network
> Prefix (MNP) and all nodes on board are allocated an IPv6 Address using that
> MNP (no real surprises here). The problem is, of course, that the MNP is not
> related to network topology.
> 
> communications services available for aircraft air/ground communications, as
> well as the global Inmarsat satcom service. An aircraft could at a given time, be
> using any one of those services, or perhaps several concurrently in a multilink
> scenario. If you try and route an (uplink) packet from an ATC Centre to an
> aircraft, how do you know how to forward it,  the packet's destination address
> has an MNP as its prefix?
> 
> Mobile IPv6 is perhaps one answer and has been looked at several times and
> written into an older version (1st and 2nd editions) of what is known in the civil
> aviation as the ATN/IPS technical manual. I don't want to end up writing a
> critique of Mobile IPv6 in this post, but lets just leave it as our exacting mobility
> environment including multilink exposes sufficient issues with Mobile IPv6 that
> have resulted in a less than enthusiastic uptake of the ATN/IPS so far.
> 
> We are now working on the 3rd edition, and the objective is to end up with a
> specification that really does lead through to full scale deployment. We need to
> replace the CLNP based ATN/OSI. It has seen almost 20 years of service in some
> parts of the world and we also know its limitations too well now. Rather than fix
> them, the move is to finally put in place support for a service based on IPv6.
> 
> The model I have for using the SRH (or the CRH if possible). is to see it as
> allowing for the expression of a series of policy rules that are used to forward a
> packet along a path that leads to a node that has full or partial visibility of which
> Air/Ground Communication services are available. From there, it can be
> forwarded to an appropriate Ground Station and so.
> 
> * a packet containing message X should preferably be uplinked using a terrestrial
> VHF digital air/ground communications service operated by ARINC (under a
> commercial contract) but,
> 
> * if the destination aircraft is not available via ARINC, forward the packet on to
> the Inmarsat SATCOM service and see if they can uplink it.
> 
> That kind of policy can be expressed by a two segment SRH header. The first SID
> (in processing order) identifies the policy rule (as above) and the second SID is
> the MNP relative IPv6 address of the destination node.
> 
> The source node is in the airline domain and sets the initial packet destination to
> the IPv6 Address of a segment router operated by ARINC (some might include
> this IPv6 Address as the first segment id in a three segment id list).
> 
> When it arrives at the ARINC router (formally an SR Segment Endpoint Node),
> the router will look at the next segment id (the one that expresses the policy). To
> implement this policy, it must do a look ahead to the next segment id (the MNP
> relative IPv6 Address) in order to determine the MNP of the final destination.
> 
> * If the ARINC service knows about this aircraft (i.e. it has logged on to their
> service) then the packet destination address is set to an IPv6 Address that is
> routeable and the route takes you to an SR Segment Endpoint Node which is
> associated with the aircraft at its current location on the ARINC network.
> Segments left is decremented. When the packet arrives at the next SR Segment
> Endpoint Node, the SRH isagain processed, the final destination IPv6 Address
> becomes the packet's destination and it should now be at a point where it can
> be forwarded directly to its destination. The assumption here is that the SR
> Segment Endpoint Node is either a proxy at the Ground Station used for uplink
> or is the "Airborne Router" on the aircraft itself.
> 
> * Alternatively, if the aircraft is not logged on to the ARINC network, the SID
> semantic is to forward the packet to Inmarsat. The DA is set to the IPv6 Address
> of a segment router operated by Inmarsat and it is sent on its way . The next
> segment count is not decremented. At Inmarsat, the next Segment ID still
> identifies the policy rule but here, it is simply interpreted as:
> 
>    - Discard the packet and return an ICMPv6 to report the event if appropriate.
> 
> This seems to give a useful policy based framework. If ARINC and Inmarsat were
> able to arrive at a commercial agreement to exchange aircraft connectivity and
> dynamic QoS information then more nuances could be added to the
> interpretation of the policy rules.
> 
> The above description also glosses over how the (e.g.) ARINC SR determines the
> IPv6 Address used for the DA of a logged on aircraft and how it is then routed to
> the aircraft.
> 
> In a simple regional service provider, PMIPv6 might be sufficient for mobility
> management. In such a case, the IPv6 Address is the "Home Address " assigned
> to the aircraft in the local PMIPv6 Domain and normal PMIP procedures are used
> to forward the packet to the destination aircraft.
> 
> In a more complex global service, a simple PMIPv6 approach is unlikely to be
> sufficient - which is why ideas such as AERO are being promoted by Boeing. The
> LISP folks are also pushing their approach and a final decision has yet to be
> made. What I am talking about here is the overall framework.
> 
> It also exposes why I want to have the full MNP relative IPv6 Address as SID[0].
> There has to be a lookahead to the next segment when the SRH is processed for
> a policy SID. If the final destination IPv6 address was buried in an inner header,
> this wouldn't really work.
> 
> Tony Whyman
> 
> MWA
> 
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Tony Whyman <[email-masked]>
Date: Tue, 27 Oct 2020 14:52:44 +0000

Eduard,

Firstly, I have tried to give a flavour of what I am working on rather 
than writing a very long post trying to describe everything in detail. I 
am also not proposing a solution that necessarily works for everyone or 
the general internet. This is industry specific.

The key to understanding where I am coming from is to recognise the way 
that the commercial relationships work today in aviation data 
communications. The example I gave reflects the way the ACARS service 
works today (and has largely done so for decades).

1. An airline contracts an air/ground service provider (usually ARINC or 
SITA) to provide them with data communications to their aircraft. For a 
regional carrier this is limited to their region of operations. A global 
carrier needs a worldwide service.

2. ARINC and SITA operate overlapping wireless communication services in 
the VHF aviation frequency band. ARINC traditionally dominate the North 
American market while SITA operates in the rest of the world. They both 
have regional partners and are increasingly penetrating into each 
other's traditional market area.

3. VHF is line of sight and does not cover oceanic airspace. Nor is it 
deployed where not many aircraft fly. The Inmarsat SATCOM service has to 
be used in these areas.

4. The traditional payment model is that the airline pays for a VHF 
communications service from ARINC or SITA rather than pay as you go, 
while the SATCOM is an extra on top of the basic service. Airlines are 
notoriously tight fisted and tend to limit their use of SATCOM to only 
the most essential messages.

5. The contractual relationship is that ARINC/SITA buy a service from 
Inmarsat on behalf of their airline customers.

The example I posted earlier represents this model of operations 
transcribed into an IPv6 environment and a segment routing model. ACARS 
messages are, today, exchanged between airlines and their service 
provider (ARINC or SITA), typically according to RFC 2351 (the SITA 
RFC). Here, the message processor relies on media advisories to know how 
to forward each message. That is ACARS messages downlinked regularly by 
each aircraft to report where it is located.

Media advisories are received both via the service provider's own VHF 
network and via SATCOM and the Inmarsat message processor.

The ARINC/SITA message processor also implements each airline's 
specified policy in terms of which messages can be sent via which 
air/ground services.

Transcribing this into the IPv6 segmenting routing world replaces RFC 
2351 with the first segment, and the ARINC/SITA message processor with a 
segment router, which implements the sender's policy when it comes to 
air/ground network selection. I am using an SID instead of the ACARS 
message type.

Behind the scenes, something similar to the media advisory is needed to 
make an SR model work. Hint: have a look at Fred's OMNI internet draft.

You make the point about how does it scale?

The answer is that at this level, only limited scaleability is required. 
A new entrant to the market is either going to take on a role similar to 
Inmarsat's and sell its service to ARINC and SITA (as a wholesale 
service) or market direct  to the end users, in which case, it is 
setting up a parallel network.

Perhaps it is a regional operator selling only to regional airlines 
operating in its own area, in which case it probably has no interaction 
with the other service providers and may not even bother with the SR model.

Alternatively, it might, for example, sell a service using its own 
network in its own region and buy a service from a SATCOM operator such 
as Inmarsat to extend its area of operations. The SR model applies but 
in a manner that is no more complex than I have described.

The simple example I gave in the previous post is not necessarily the 
only way we may have of using segment routing, but it is a good way of 
illustrating how it may be used.

Hopefully, this gives you some extra background.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Oct 2020 15:59:53 +0100

Le 27/10/2020 à 15:52, Tony Whyman a écrit :
> 2351 with the first segment,

And, putting ACARS messages on IPv6 is probably a good idea and easy to 
achieve, provided IPv6-over-that-VHF exists.

Alex

  and the ARINC/SITA message processor with a
>> - and number of Gateways (SR Segment Endpoint Node) that has full 
>> routing information for both networks. Gateways could distribute the 
>> data plane load.
>> If final destination is not connected to Backbone, then traffic should 
>> be forwarded to any gateway - it would find the final destination (or 
>> drop the traffic).
>>
>> 1. This approach would not scale above 1 Carrier. It would need 
>> gateways that should know all routing information for all carriers 
>> involved (and for all objects registered).
>> 2. This approach would have some scalability issues for gateways (it 
>> should know all routes from all domains). Not a big problem now, 
>> because current scalability of many vendors (2M FIB for IPv6) is less 
>> than 0.5M planes that you would like to connect. But what if other 
>> objects would be connected too? (ships, cars). The single gateway that 
>> has knowledge about everything in the world could be the huge problem 
>> in the future. It is difficult to aggregate in mobile case - routes 
>> would be very specific (/64?).
>> 3. Additionally, architecture blocks direct short cut between access 
>> networks. It may be not so big problem now, but what about the future?
>> 4. It is not possible to choose closest gateway in the backbone. If 
>> gateways would be distributed around the Earth, then average 
>> additional latency just for backbone part would statistically close to 
>> 5us*Square(4*pi*R^2/N)/2. N - is the number of gateways. R=6371km 
>> (Earth). If gateway distribution would be not equal (it is guaranteed) 
>> - expect much worse latency for some geographies.
>>
>> SRv6 is the some sort of tunneling technology (IPv6 header is inside 
>> IPv6 header) with many additional nice features.
>>> Network
>>> communications, as
>>> with a
>>> terrestrial
>>> packet on to
>>> first SID
>>> destination to
>>> Node),
>>> Inmarsat were
>>> determines the
>>> mobility

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 27 Oct 2020 16:07:05 +0100

Le 27/10/2020 à 15:52, Tony Whyman a écrit :
> Eduard,
> 
> Firstly, I have tried to give a flavour of what I am working on
> rather than writing a very long post trying to describe everything in
> detail. I am also not proposing a solution that necessarily works for
> everyone or the general internet. This is industry specific.
> 
> The key to understanding where I am coming from is to recognise the
> way that the commercial relationships work today in aviation data 
> 1. An airline contracts an air/ground service provider (usually ARINC
> or SITA) to provide them with data communications to their aircraft.
> For a regional carrier this is limited to their region of operations.
> A global carrier needs a worldwide service.
> 
> 2. ARINC and SITA operate overlapping wireless communication services
> in the VHF aviation frequency band. ARINC traditionally dominate the
> North American market while SITA operates in the rest of the world.
> They both have regional partners and are increasingly penetrating
> into each other's traditional market area.
> 
> 3. VHF is line of sight and does not cover oceanic airspace. Nor is
> it deployed where not many aircraft fly. The Inmarsat SATCOM service
> has to be used in these areas.
> 
>  while the SATCOM is an extra on top of the basic service. Airlines
> are notoriously tight fisted and tend to limit their use of SATCOM to
> only the most essential messages.
> 
> transcribed into an IPv6 environment and a segment routing model.
> ACARS messages are, today, exchanged between airlines and their
> service provider (ARINC or SITA), typically according to RFC 2351
> (the SITA RFC). Here, the message processor relies on media
> advisories to know how to forward each message. That is ACARS
> messages downlinked regularly by each aircraft to report where it is
> located.
> 
>  2351 with the first segment, and the ARINC/SITA message processor
> with a segment router, which implements the sender's policy when it
> comes to air/ground network selection. I am using an SID instead of
> the ACARS message type.
> 
> Behind the scenes, something similar to the media advisory is needed
> to make an SR model work. Hint: have a look at Fred's OMNI internet
> draft.
> 

I am not sure where does it need to scale?  Is it the number of 2
(Inmarsat and ARINC) that needs to grow up to maybe 20?  Have people
witnessed difficulty in managing 3?

 From the descriptions I read in the emails here about the existing
relationships about the few airlines and connectivity operators, it
seems as most relationships are mostly frozen and there is no growth.

In such a system using simple text files to reflect topologies is
probably enough appropriate.  That might amount for policies.

I think that routing headers and more dynamic message exchanges might be
needed when the overall system is more open and in need of more dynamicity.

Alex

> 
> The answer is that at this level, only limited scaleability is
> required. A new entrant to the market is either going to take on a
> role similar to Inmarsat's and sell its service to ARINC and SITA (as
> a wholesale service) or market direct  to the end users, in which
> case, it is setting up a parallel network.
> 
> operating in its own area, in which case it probably has no
> interaction with the other service providers and may not even bother
> with the SR model.
> 
> network in its own region and buy a service from a SATCOM operator
> such as Inmarsat to extend its area of operations. The SR model
> applies but in a manner that is no more complex than I have
> described.
> 
>  only way we may have of using segment routing, but it is a good way
> of illustrating how it may be used.
> 
>> Hi Tony, How I have understood you: - you have the Backbone (ARINC)
>> network - access (SATCOM) network - and number of Gateways (SR
>> Segment Endpoint Node) that has full routing information for both
>> networks. Gateways could distribute the data plane load. If final
>> destination is not connected to Backbone, then traffic should be
>> forwarded to any gateway - it would find the final destination (or
>>  drop the traffic).
>> 
>> But what if you would have additional access network (Starlink)? It
>> is probably additional gateway in your architecture. But how
>> ordinary node in backbone would understand where to forward 
>> traffic? It has 2 different gateways now to choose.
>> 
>>  involved (and for all objects registered). 2. This approach would
>> have some scalability issues for gateways (it should know all
>> routes from all domains). Not a big problem now, because current
>> scalability of many vendors (2M FIB for IPv6) is less than 0.5M
>> planes that you would like to connect. But what if other objects
>> would be connected too? (ships, cars). The single gateway that has
>> knowledge about everything in the world could be the huge problem 
>>  would be very specific (/64?). 3. Additionally, architecture
>> blocks direct short cut between access networks. It may be not so
>> big problem now, but what about the future? 4. It is not possible
>> to choose closest gateway in the backbone. If gateways would be
>> distributed around the Earth, then average additional latency just
>> for backbone part would statistically close to 
>> (Earth). If gateway distribution would be not equal (it is
>> guaranteed) - expect much worse latency for some geographies.
>> 
>> Conclusion: you need the backbone knowledge about optimal paths for
>>  all objects. It could be split for realms/domain/VPNs for not to
>> keep all information in every backbone PE.
>> 
>> Answering your original question: SRv6 is the some sort of
>> tunneling technology (IPv6 header is inside IPv6 header) with many
>> additional nice features. You could do it as many times as you
>> wish. Everybody knows in the industry that "any networking problem
>> could be resolved by additional overlay layer".
>> 
>> Eduard
>>> -----Original Message----- From: ipv6
>>> [mailto:[email-masked]] On Behalf Of Tony Whyman Sent: 27
>>> октября 2020 г. 15:03 To: [email-masked] Subject: Re: How many
>>> Routing Headers? - and the mobility problem
>>> 
>>> 
>>>> Thank you for your description of how the CRB works. The
>>>> problem I have with it is that it is that I believe that it is
>>>> infeasible, in my example, to configure node C with the IPv6
>>>> Address associated with node D.
>>>> 
>>> <snip>
>>>> Some might argue - why not use the CRH in an outer header of
>>>> an encapsulated packet with the full destination address in the
>>>> inner header. My response is that this sort of defeats the
>>>> object of compression. There is also a mobility issue here -
>>>> but it's best to put that in a separate EMail.
>>> And this I shall do.
>>> 
>>> One thing that interests me about the Segment Routing paradigm is
>>> how it seems to fit well with node mobility and multilink and is
>>> the topic I would also like to get some feedback on.
>>> 
>>> Our addressing model for an aircraft assigns each one a unique
>>> Mobile Network Prefix (MNP) and all nodes on board are allocated
>>> an IPv6 Address using that MNP (no real surprises here). The
>>> problem is, of course, that the MNP is not related to network
>>> topology.
>>> 
>>> There are already several existing global and regional
>>> terrestrial communications services available for aircraft
>>> air/ground communications, as well as the global Inmarsat satcom
>>> service. An aircraft could at a given time, be using any one of
>>> those services, or perhaps several concurrently in a multilink 
>>> scenario. If you try and route an (uplink) packet from an ATC
>>> Centre to an aircraft, how do you know how to forward it,  the
>>> packet's destination address has an MNP as its prefix?
>>> 
>>> Mobile IPv6 is perhaps one answer and has been looked at several
>>>  times and written into an older version (1st and 2nd editions)
>>> of what is known in the civil aviation as the ATN/IPS technical
>>> manual. I don't want to end up writing a critique of Mobile IPv6
>>> in this post, but lets just leave it as our exacting mobility 
>>> environment including multilink exposes sufficient issues with
>>> Mobile IPv6 that have resulted in a less than enthusiastic uptake
>>> of the ATN/IPS so far.
>>> 
>>> We are now working on the 3rd edition, and the objective is to
>>> end up with a specification that really does lead through to full
>>> scale deployment. We need to replace the CLNP based ATN/OSI. It
>>> has seen almost 20 years of service in some parts of the world
>>> and we also know its limitations too well now. Rather than fix 
>>> The model I have for using the SRH (or the CRH if possible). is
>>> to see it as allowing for the expression of a series of policy
>>> rules that are used to forward a packet along a path that leads
>>> to a node that has full or partial visibility of which Air/Ground
>>> Communication services are available. From there, it can be 
>>> In a simple example, you may have a scenario where the sender
>>> (e.g. an Airline) has a policy that says:
>>> 
>>> * a packet containing message X should preferably be uplinked
>>> using a terrestrial VHF digital air/ground communications service
>>> operated by ARINC (under a commercial contract) but,
>>> 
>>> * if the destination aircraft is not available via ARINC, forward
>>> the packet on to the Inmarsat SATCOM service and see if they can
>>> uplink it.
>>> 
>>> That kind of policy can be expressed by a two segment SRH header.
>>> The first SID (in processing order) identifies the policy rule
>>> (as above) and the second SID is the MNP relative IPv6 address of
>>> the destination node.
>>> 
>>> The source node is in the airline domain and sets the initial
>>> packet destination to the IPv6 Address of a segment router
>>> operated by ARINC (some might include this IPv6 Address as the
>>> first segment id in a three segment id list).
>>> 
>>> When it arrives at the ARINC router (formally an SR Segment
>>> Endpoint Node), the router will look at the next segment id (the
>>> one that expresses the policy). To implement this policy, it must
>>> do a look ahead to the next segment id (the MNP relative IPv6
>>> Address) in order to determine the MNP of the final destination.
>>> 
>>> * If the ARINC service knows about this aircraft (i.e. it has
>>> logged on to their service) then the packet destination address
>>> is set to an IPv6 Address that is routeable and the route takes
>>> you to an SR Segment Endpoint Node which is associated with the
>>> aircraft at its current location on the ARINC network. Segments
>>> left is decremented. When the packet arrives at the next SR 
>>> Segment Endpoint Node, the SRH isagain processed, the final
>>> destination IPv6 Address becomes the packet's destination and it
>>> should now be at a point where it can be forwarded directly to
>>> its destination. The assumption here is that the SR Segment
>>> Endpoint Node is either a proxy at the Ground Station used for
>>> uplink or is the "Airborne Router" on the aircraft itself.
>>> 
>>> * Alternatively, if the aircraft is not logged on to the ARINC 
>>> network, the SID semantic is to forward the packet to Inmarsat.
>>> The DA is set to the IPv6 Address of a segment router operated by
>>> Inmarsat and it is sent on its way . The next segment count is
>>> not decremented. At Inmarsat, the next Segment ID still 
>>>  Inmarsat were able to arrive at a commercial agreement to
>>> exchange aircraft connectivity and dynamic QoS information then
>>> more nuances could be added to the interpretation of the policy
>>> rules.
>>> 
>>> determines the IPv6 Address used for the DA of a logged on
>>> aircraft and how it is then routed to the aircraft.
>>> 
>>> In a simple regional service provider, PMIPv6 might be sufficient
>>> for mobility management. In such a case, the IPv6 Address is the
>>> "Home Address " assigned to the aircraft in the local PMIPv6
>>> Domain and normal PMIP procedures are used to forward the packet
>>> to the destination aircraft.
>>> 
>>> In a more complex global service, a simple PMIPv6 approach is 
>>> unlikely to be sufficient - which is why ideas such as AERO are
>>> being promoted by Boeing. The LISP folks are also pushing their
>>> approach and a final decision has yet to be made. What I am
>>> talking about here is the overall framework.
>>> 
>>> It also exposes why I want to have the full MNP relative IPv6
>>> Address as SID[0]. There has to be a lookahead to the next
>>> segment when the SRH is processed for a policy SID. If the final
>>> destination IPv6 address was buried in an inner header, this
>>> wouldn't really work.
>>> 
>>> Tony Whyman
>>> 
>>> MWA
>>> 
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Tony Whyman <[email-masked]>
Date: Tue, 27 Oct 2020 16:18:54 +0000

> witnessed difficulty in managing 3?
The point is not so much about how many service providers exist, it is 
about how many do you traverse from the source node to its destination 
on board an aircraft.
> seems as most relationships are mostly frozen and there is no growth.
I think some in the industry would not agree with that. We are living in 
an exceptional period, but the number of new airlines entering the 
market has, in recent years, been growing rapidly. There are around 
5,000 airlines and many more aircraft operators (to use the generic 
term). Also the number of air movements and aircraft has been growing 
rapidly. Drones are an even bigger growth area.
> probably enough appropriate.  That might amount for policies.
My point is that the topology is not arbitrarily complex and that 
observation is useful in that we can constrain the problem rather than 
having to make it open ended.
Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 27 Oct 2020 16:42:41 +0000

Tony et al, in the AERO/OMNI paradigm the CRH is added as an extension to the
RFC2473 encapsulation header used for traversing the (multi-segment) OMNI link.
When the RFC2473-encapsulated packet reaches the ultimate OMNI link segment,
the RFC2473 header is removed and the final destination ipv6 address is determined
by looking at the IPv6 destination address in the (now-decapsulated) IPv6 packet
with the CRH itself already having been discarded along with the RFC2473 header.
Am I missing the point you are concerned with?

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Tony Whyman
Sent: Monday, October 26, 2020 5:13 PM
To: Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: [EXTERNAL] RE: How many Routing Headers?

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

-------- Original message --------
From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: 26/10/2020 22:56 (GMT+00:00)
To: Tony Whyman <[email-masked]<mailto:[email-masked]>>, Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: RE: How many Routing Headers?

Tony,

                                                                                                       Ron

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Whyman
Sent: Monday, October 26, 2020 12:38 PM
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: How many Routing Headers?

Bob,

Tony

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 18:29:32 +0000

> Hopefully, this gives you some extra background.
[Ed: ] O Yea! Very complicated organizational and political challenge.

One box solution to stitch networks has an advantage:
it is possible to start BGP session from every router (on the plane) to this gateway (or list of gateways for redundancy),
Then organize EVPN over this BGP session.
Data Plane could be VxLAN to avoid any requirements to underlay networks. It could be migrated to SR-MPLS or SRH/CRH when underlay networks would be ready.
Done.

Ed/
> From: Tony Whyman [mailto:[email-masked]]
> Sent: 27 октября 2020 г. 17:53
> To: Vasilenko Eduard <[email-masked]>; [email-masked]
> Firstly, I have tried to give a flavour of what I am working on rather than writing
> a very long post trying to describe everything in detail. I am also not proposing a
> solution that necessarily works for everyone or the general internet. This is
> industry specific.
> 
> The key to understanding where I am coming from is to recognise the way that
> the commercial relationships work today in aviation data communications. The
> example I gave reflects the way the ACARS service works today (and has largely
> done so for decades).
> 
> SITA) to provide them with data communications to their aircraft. For a regional
> carrier this is limited to their region of operations. A global carrier needs a
> worldwide service.
> 
> 2. ARINC and SITA operate overlapping wireless communication services in the
> VHF aviation frequency band. ARINC traditionally dominate the North American
> market while SITA operates in the rest of the world. They both have regional
> partners and are increasingly penetrating into each other's traditional market
> area.
> 
> 3. VHF is line of sight and does not cover oceanic airspace. Nor is it deployed
> where not many aircraft fly. The Inmarsat SATCOM service has to be used in
> these areas.
> 
> communications service from ARINC or SITA rather than pay as you go, while
> the SATCOM is an extra on top of the basic service. Airlines are notoriously tight
> fisted and tend to limit their use of SATCOM to only the most essential
> messages.
> 
> 5. The contractual relationship is that ARINC/SITA buy a service from Inmarsat
> on behalf of their airline customers.
> 
> The example I posted earlier represents this model of operations transcribed
> into an IPv6 environment and a segment routing model. ACARS messages are,
> today, exchanged between airlines and their service provider (ARINC or SITA),
> typically according to RFC 2351 (the SITA RFC). Here, the message processor
> relies on media advisories to know how to forward each message. That is ACARS
> messages downlinked regularly by each aircraft to report where it is located.
> 
> Media advisories are received both via the service provider's own VHF network
> and via SATCOM and the Inmarsat message processor.
> 
> The ARINC/SITA message processor also implements each airline's specified
> policy in terms of which messages can be sent via which air/ground services.
> 
> air/ground network selection. I am using an SID instead of the ACARS message
> type.
> 
> Behind the scenes, something similar to the media advisory is needed to make
> an SR model work. Hint: have a look at Fred's OMNI internet draft.
> 
> service) or market direct  to the end users, in which case, it is setting up a
> parallel network.
> 
> Perhaps it is a regional operator selling only to regional airlines operating in its
> own area, in which case it probably has no interaction with the other service
> providers and may not even bother with the SR model.
> 
> Alternatively, it might, for example, sell a service using its own network in its
> own region and buy a service from a SATCOM operator such as Inmarsat to
> extend its area of operations. The SR model applies but in a manner that is no
> more complex than I have described.
> 
> The simple example I gave in the previous post is not necessarily the only way
> we may have of using segment routing, but it is a good way of illustrating how it
> may be used.
> 
> > - and number of Gateways (SR Segment Endpoint Node) that has full routing
> information for both networks. Gateways could distribute the data plane load.
> > If final destination is not connected to Backbone, then traffic should be
> forwarded to any gateway - it would find the final destination (or drop the
> traffic).
> >
> > 1. This approach would not scale above 1 Carrier. It would need gateways that
> should know all routing information for all carriers involved (and for all objects
> registered).
> > 2. This approach would have some scalability issues for gateways (it should
> know all routes from all domains). Not a big problem now, because current
> scalability of many vendors (2M FIB for IPv6) is less than 0.5M planes that you
> would like to connect. But what if other objects would be connected too? (ships,
> cars). The single gateway that has knowledge about everything in the world
> could be the huge problem in the future. It is difficult to aggregate in mobile
> case - routes would be very specific (/64?).
> > 3. Additionally, architecture blocks direct short cut between access networks.
> It may be not so big problem now, but what about the future?
> > 4. It is not possible to choose closest gateway in the backbone. If gateways
> would be distributed around the Earth, then average additional latency just for
> backbone part would statistically close to 5us*Square(4*pi*R^2/N)/2. N - is the
> number of gateways. R=6371km (Earth). If gateway distribution would be not
> equal (it is guaranteed) - expect much worse latency for some geographies.
> >
> > SRv6 is the some sort of tunneling technology (IPv6 header is inside IPv6
> header) with many additional nice features.
> >>> have with it is that it is that I believe that it is infeasible, in
> >>> my example, to configure node C with the IPv6 Address associated with
> node D.
> >>>
> >> <snip>
> >> One thing that interests me about the Segment Routing paradigm is how
> >> it seems to fit well with node mobility and multilink and is the
> >> topic I would also like to get some feedback on.
> >>
> >> aircraft could at a given time, be using any one of those services,
> >> or perhaps several concurrently in a multilink scenario. If you try
> >> and route an (uplink) packet from an ATC Centre to an aircraft, how
> >> do you know how to forward it,  the packet's destination address has an MNP
> as its prefix?
> >>
> >> times and written into an older version (1st and 2nd editions) of
> >> what is known in the civil aviation as the ATN/IPS technical manual.
> >> I don't want to end up writing a critique of Mobile IPv6 in this
> >> post, but lets just leave it as our exacting mobility environment
> >> including multilink exposes sufficient issues with Mobile IPv6 that have
> resulted in a less than enthusiastic uptake of the ATN/IPS so far.
> >>
> >> almost 20 years of service in some parts of the world and we also
> >> know its limitations too well now. Rather than fix them, the move is to finally
> put in place support for a service based on IPv6.
> >>
> >> The model I have for using the SRH (or the CRH if possible). is to
> >> see it as allowing for the expression of a series of policy rules
> >> that are used to forward a packet along a path that leads to a node
> >> that has full or partial visibility of which Air/Ground Communication
> >> services are available. From there, it can be forwarded to an appropriate
> Ground Station and so.
> >>
> >> expresses the policy). To implement this policy, it must do a look
> >> ahead to the next segment id (the MNP relative IPv6 Address) in order to
> >> service) then the packet destination address is set to an IPv6
> >> Endpoint Node which is associated with the aircraft at its current location on
> the ARINC network.
> >> Segments left is decremented. When the packet arrives at the next SR
> >> should now be at a point where it can be forwarded directly to its
> >> destination. The assumption here is that the SR Segment Endpoint Node
> >> is either a proxy at the Ground Station used for uplink or is the "Airborne
> Router" on the aircraft itself.
> >>
> >> network, the SID semantic is to forward the packet to Inmarsat. The
> >> DA is set to the IPv6 Address of a segment router operated by
> >> Inmarsat and it is sent on its way . The next segment count is not
> >> decremented. At Inmarsat, the next Segment ID still identifies the policy rule
> but here, it is simply interpreted as:
> >>
> >> IPv6 Address used for the DA of a logged on aircraft and how it is
> >> then routed to the aircraft.
> >>
> >> Address " assigned to the aircraft in the local PMIPv6 Domain and
> >> normal PMIP procedures are used to forward the packet to the destination
> aircraft.
> >>
> >> unlikely to be sufficient - which is why ideas such as AERO are being
> >> promoted by Boeing. The LISP folks are also pushing their approach
> >> and a final decision has yet to be made. What I am talking about here is the
> overall framework.
> >>
> SID[0].
> >> There has to be a lookahead to the next segment when the SRH is

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 27 Oct 2020 18:54:34 +0000

Hi, BGP does have a prominent role in this architecture, but it does not reach all
the way to the airplane and as such is not subject to mobility churn. Our use of
BGP is documented in an rtgwg working group document:

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/

which we should really start pushing for publication on soon.

Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Vasilenko Eduard
> Sent: Tuesday, October 27, 2020 11:30 AM
> To: Tony Whyman <[email-masked]>; [email-masked]
> Subject: RE: How many Routing Headers? - and the mobility problem> 
>