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

[Tom Herbert <[e-mail]>]

On Tue, May 12, 2020 at 2:44 PM Mark Smith <[e-mail]> wrote:
>
>
>
> 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.

Mark,

So that would basically be per link IP-IP encapsulation . That
presumes that every possible node in the path understands and
processes the encapsulation and also there would be considerable
processing overhead at every intermediate node as opposed to just the
ingress and egress points. I think this approach would be a hard sell.

Tom

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