Re: Other use cases for header insertion (was Re: Header Insertion and TI-FA)

[Mark Smith <[e-mail]>]

Hi Tom,

On Tue, 12 May 2020, 10:27 Tom Herbert, <[e-mail]> wrote:

> On Mon, May 11, 2020 at 1:37 PM Mark Smith <[e-mail]> wrote:
> >
> >
> >
> > On Tue, 12 May 2020, 00:50 Tom Herbert, <[e-mail]> wrote:
> >>
> >> On Mon, May 11, 2020 at 5:58 AM Ron Bonica
> >> <rbonica=[e-mail]> wrote:
> >> >
> >> > Folks,
> >> >
> >> >
> >> >
> >> > Happy Monday!
> >> >
> >> >
> >> >
> >> > As I was painting this weekend, I remembered that the use-case for
> IPv6 Header insertion is TI-LFA. This made the following questions come to
> mind:
> >> >
> >>
> >> Ron,
> >>
> >> There is at least one other use case for IPv6 Header insertion, that
> >> being IOAM. For example, an operator may wish to collect per packet
> >> statistics as packets traverse its network. An ingress router would
> >> insert headers containing IOAM, routers would annotate the
> >> information, and the egress router is expected to consume and remove
> >> the headers.
> >
> >
> >
> > Have a review of this draft. EH insertion is not proposed for IOAM.
> >
> > Deployment Considerations for In-situ OAM with IPv6 Options
> >
> https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-deployment-02
> >
> Mark,
>
> For IOAM the assumption is that not all packets are necessarily
> annotated for measurement and that both annotated and non-annotated
> packets need to follow the same path in order for the the measurements
> to be useful.



I think that can be accommodated.

The presence of an IOAM header in a packet is the selector of whether IOAM
processing occurs, and whether an IOAM header is present when the packet
leaves the node.

i.e. for packet with IOAM header when it arrives at IOAM node.

1. packet is link-layer decapsulated (including IPv6 virtual-link layer
(tunnel) decap)
2. As packet has IOAM header, IOAM info and packet passed to IOAM function
to process/update IOAM information.
3. Once IOAM processing complete, packet's IP DA is looked up, determining
egress interface and link-layer encapsulation.
4. The packet is link-layer encapsulated (possibly in IPv6 virtual
link-layer/tunnel) with the IOAM header between the link-layer header and
the IP packet, and sent on its way.

for a non-IOAM packet, (standard IP forwarding, just showing for
completeness)

1. packet is link-layer decapsulated.
2. As packet is vanilla IP, packet bypasses the IOAM function.
3. packet's IP DA is looked up, determining egress interface and link-layer
encapsulation.
4. packet is link-layer encapsulated, and sent on its way.

The information produced by IP DA lookups in both cases is the same, so
packets with or without IOAM headers will follow the same path through the
network if they have the same DA.


> <snip>
>


> >> This use case makes me think the WG should consider how to make header
> >> insertion safe and viable.
> >
> >
> > There's a need for a layer 2.5 local networking protocol that has
> smaller headers (and smaller addressing) than IPv6, that won't cause
> problems if it leaks because it is not the Internet's protocol, because all
> this EH insertion debate and pain is caused by people wanting to use IPv6,
> but not wanting to pay the IPv6 internetworking protocol overhead. They're
> trying to have their cake and eat it too.
>
> I think we need to keep an open mind. While I agree that the SR use
> case hasn't been well explained why EH insertion is needed, I don't
> think we can preclude that there might not be other use cases where it
> makes sense.
>

I don't think it will ever make sense to me, and I've thought about the
idea of insertion verses encapsulation since the invention of 802.1Q in
around the early 2000s, verses the Eth-in-Eth tunelling pre-standard
solution Cisco I had deployed.

802.1Q violates the purpose of the FCS, which is a path integrity check
between the frame's original source and its final destination.


> >
>


> <snip>
>
> A lot of people thought NAT was a hack too :-)


It still is, and I've thought that for nearly 25 years.

Here's my 3 part, 4500 word essay, from an operators point of view, on the
trouble with NAT, based on my AusNOG presentation on that topic in the
previous year.

https://blog.apnic.net/2016/10/25/trouble-nat-part-1/
https://blog.apnic.net/2016/10/26/trouble-nat-part-2/
https://blog.apnic.net/2016/10/27/trouble-nat-part-3/

Slides if that is TL;DR:

https://www.ausnog.net/sites/default/files/ausnog-2016/presentations/1.2_Mark_Smith_AusNOG2016.pdf

Getting rid of NAT is why I've spent so much of my own time on IPv6 here in
the IETF.


My concern is if we
> dismiss protocols becasue we view them as hacks without giving serious
> consideration to how they might be made to work reasonably,



I've given it serious consideration. It's not about whether it can be made
to work, to me it is about how hard it is going to be to fix it when it
breaks.

I consider EH insertion or EH removal so bad that I would much rather
deploy IPv6 with NAT, because at least with NAT, in one of the packet
directions, the NAT device overwrites the packets' source address with its
own. I can troubleshoot broken NAT much easier than I'll be able to
troubleshoot anonymous EH insertion or removal.


perhaps in
> a limited domain, people will deploy these hacks anyway and in  fact
> may end up doing things the are far worse (like the aforemention hacks
> where intermediate nodes are mucking with TCP payload).
>

I don't think we are obligated to accommodate and facilitate special cases
that comes along, even if there is a level of popularity.

IPv6 is supposed to be the general purpose Internet and internetworking
protocol. Being general purpose means good enough for the majority of
cases, may not be good enough for special cases.

If those special cases can't compromise their requirements to suit IPv6,
then they shouldn't use IPv6. They should come up with something different
that is much more tailored and specialised that better suits their
requirements.


Regards,
Mark.


> Tom
>
> >
> > Regards,
> > Mark.
> >
> >>
> >> Tom
> >> >
> >> >
> >> > How does TI-LFA work when the original packet already contains a
> routing header? Will it insert a second, so that the packet has two routing
> headers?
> >> > How does TI-LFA work when the node directly upstream of the link
> (i.e., the PLR) is not a segment endpoint? Will it insert an routing
> header? Is that consistent with 8200?
> >> >
> >> >
> >> >
> >> >
>                                                    Ron
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Juniper Business Use Only
> >> >
> >> > --------------------------------------------------------------------
> >> > IETF IPv6 working group mailing list
> >> > [e-mail]
> >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> > --------------------------------------------------------------------
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
>