Subject: How many Routing Headers?

From: Tony Whyman <[email-masked]>
Date: Fri, 23 Oct 2020 14:47:03 +0100

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 26 Oct 2020 09:18:29 -0400

Tony

You can have multiple EH headers, however the problem is with multiple
routing headers and which one to process on the source SR node ingress PE
to the SR domain this is doing the initial encapsulation of CE customer
payload that is trying to determine which RH to process so it can perform
process the first Segment.

We had this issue with local protection at PLT junction for TI-LFA and the
solution was to encapsulation at PLR node and decapsulation at merge point
PQ node.

Gyan
On Fri, Oct 23, 2020 at 9:47 AM Tony Whyman <[email-masked]>
wrote:

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

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Tony Whyman <[email-masked]>
Date: Mon, 26 Oct 2020 14:58:50 +0000

Gyan,

If you have to encapsulate in order to use a CRH then you have probably 
ensured that there is very little, if any, advantage to using a CRH 
instead of (e.g.) an SRH.

I take your point about ensuring that the RH processing order is 
unambiguous, hence a clear need for the standard to be clear about how 
multiple RHs are used, if at all. However, the example I was thinking of 
was a simple case where the router processes only the first routing 
header that it finds and stops there unless the segments left count is 
zero, in which case it goes on to the next header, which may or may not 
be an RH.

Tony Whyman

On 26/10/2020 13:18, Gyan Mishra wrote:
> routing headers and which one to process on the source SR node ingress 
> PE to the SR domain this is doing the initial encapsulation of CE 
> customer payload that is trying to determine which RH to process so it 
> can perform process the first Segment.
>
> We had this issue with local protection at PLT junction for TI-LFA and 
> the solution was to encapsulation at PLR node and decapsulation at 
> merge point PQ node.
>
> Gyan
> On Fri, Oct 23, 2020 at 9:47 AM Tony Whyman 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
> /Network Solutions A//rchitect /
>
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
>
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Oct 2020 08:38:34 -0700

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
> 
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 26 Oct 2020 11:45:38 -0400

Very good point Bob!

The Spring WG is charged per the CRH disposition during WG adoption to come
up with a RH compression standard that can be applied and Ron Bonica is on
that design team.

I believe that they plan to have a readout update on IETF 109 from my last
poll on status.

MSD - maximum sid dept is a major issue with SR over IPv6 data plane SRv6
which CRH satisfies issue with its inherent compression technique CRH-16
and CRH-32.  Unfortunately MSD was an after thought with SRv6 and this the
DT is working aggressively to get resolved to make SRv6 viable.

I have asked the design team to make the compression technique native and
part of original specifications and not an add on hack so it does not
impact operators.

Kind Regards

Gyan

On Mon, Oct 26, 2020 at 11:39 AM Bob Hinden <[email-masked]> 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
>
>
> Routing Header (CRH)" led me to the thought: why should there only be one
> Routing Header per packet header?
> >
> 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".
> >
> error. That is unless a subsequent specification explicitly allows for more
> than one Routing Header.
> >
> 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.
> >
> then follow it by an SRH containing the Final Destination? I can't see any
> reason as to why this should not work.
> >
> 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
> >
> >
> >
-- 

*Gyan Mishra*

---

From: Tony Whyman <[email-masked]>
Date: Mon, 26 Oct 2020 16:38:00 +0000

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Oct 2020 12:19:10 -0300

Hello, Tony,

> one Routing Header per packet header?

Because RFC8200 says so, and,
Because a packet can't follow to different paths at the same place -- 
unless you intentionally duplicated the packet at the source, which of 
course would mean that it would be two different packets.

> more than one Routing Header.

So, if you have two EHs... which one you honor?  -- that's like having 
two Destination Addresses...

> any reason as to why this should not work.

Of the top of my head, I'd say that we're getting into a level of 
complexity that would not only be hard to explain, but also hard to justify.

> that the next draft of draft-bonica-6man-comp-rtg-hdr-23 should include 

Speaking as an indivifual participant (who has nothing to do with CRH) 
I'd argue: Please *no* :-)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ron Bonica <[email-masked]>
Date: Mon, 26 Oct 2020 22:56:30 +0000

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]> On Behalf Of Tony Whyman
Sent: Monday, October 26, 2020 12:38 PM
To: 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 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:
>> Administrative Requests: 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>> 6__;!!NEt6yMaO-gk!RJPvmV3ro1z7mCLJfP0HBV7nQzyHWLn9nU7mU46Vx9KxjK8NdrA
>> QPG9jVAcN6e7I$

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 28 Oct 2020 10:17:03 +0000

Hi Tony, you ask some good questions on multiple routing headers, but I'll skip answering those and propose a solution instead based on SRv6 and a single SRH

draf-ietf-spring-6man-network-programming defines a PSP SID flavor.
I believe this is what you are looking for to remove the SRH before sending a packet to the ultimate segment (the aircraft) via the low bandwidth link.

To reduce overhead during the portion of the packet path that is not in the air, draft-filsfilscheng-spring-srv6-srh-comp-sl-enc provides a means of compressing an SRv6 SID list.

With these two pieces you get minimal overhead on the packet path that is not in the air, and no extension header overhead on the link to the aircraft (since the SRH is removed).

Darren

________________________________
From: ipv6 <[email-masked]> on behalf of Tony Whyman <[email-masked]>
Sent: Friday, October 23, 2020 9:47 AM
To: IPv6 List <[email-masked]>
Subject: How many Routing Headers?

Tony Whyman

MWA

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 28 Oct 2020 10:23:28 +0000

Here are the links to the referenced docs.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-24#section-4.16.1
https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01

Thanks
  Darren

________________________________
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Wednesday, October 28, 2020 6:17 AM
To: Tony Whyman <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: How many Routing Headers?

Darren

Tony Whyman

MWA

---

From: Tony Whyman <[email-masked]>
Date: Wed, 28 Oct 2020 14:28:54 +0000

I believe that I may now have found a solution to my problem and I have 
to thank the sender of direct response for pointing this out.

The point that I had overlooked is that RFC 8200 Extension Header rules 
permit an SR router to drop an SRH or replace it with a CRH. My use case 
has a problem with the last segment only and thus it is possible to 
avoid the SRH overhead on the low bandwidth air/ground datalink by the 
simple expedient of discarding the SRH at the last SR Endpoint Node.

In the longer term, in our use case, it will probably be preferable to 
replace the SRH with a semantically equivalent CRH-16 rather than 
discarding it. I have been developing a concept known as Safety Based 
Multilink (SBM) in order to support some known future data link 
applications which have a higher safety classification than the current 
generation. It is believed that these will need to be supported by two 
independent end-to-end networks - between an egress router at an ATC 
Centre and the Airborne Router on board an aircraft. Modified upper 
layer protocols will be required to manage this use case and they will 
need both to explicitly steer packets to either one of the two networks, 
and to know which network was used as the forwarding path for an 
incoming packet.

Again, Segment Routing seems to work well here, with a segment id used 
to identify which end-to-end network is used to transfer each packet. 
However, the model of operations does require that the receiver knows 
which end-to-end network was used and hence there is a need to preserve 
the segment list rather than discard it. Transforming an SRH into a CRH 
should do the job while minimising bandwidth.

Hence, I want to re-iterate the point that I see both SRH and CRH as 
important specifications and would like to see the CRH progressed as 
soon as possible.

Otherwise, many thanks for all the suggestions and comments that I have 
received.

Tony Whyman

MWA

On 23/10/2020 14:47, Tony Whyman wrote:
> 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.
>
> 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.
>
> 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
>
>
>