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

[Tom Herbert <[e-mail]>]

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. This is one of the motivations for hacking the the TCP
payload, it doesn't change how the packet is routed since ECMP should
be unaffected. It also works equivalently in IPv4 and does invoke any
external mechnisms like MPLS, additional routing information, or link
layer addressing.

> My suggestion for that draft was the "IP-in-IPv6 encapsulation with ULA" section.
>
> If the IOAM nodes are a link-layer adjacent and contiguous through the IOAM domain, which I think will be likely in a lot of deployments, then the outer tunnel addressing could be Link-Local Addresses, and the IPv6 tunnels are implicit as LLAs are required for all IPv6 interfaces.
>
> An even lower overhead option in this scenario is to carry the IOAM header directly after the link-layer header, similar to how the MPLS label stack is encoded after the link-layer header, before the IP header.
>
> That would mean defining an IOAM link-layer type value for the IOAM header, however there aren't many link-layers, and an Ethertype for the IOAM header is already being defined:
>
> "Ethernet Encapsulation for In-situ OAM Data"
> https://tools.ietf.org/html/draft-weis-ippm-ioam-eth-02
>
> I'll email Frank again about this as I haven't heard anything since I emailed him before.
>
>>
>> The big difference between this use case and SR is that
>> there's no source routing involved so the ingress router doesn't
>> necessarily know what the egress router is, hence the ingress router
>> wouldn't know the right destination address to use in encapsulation.
>
>
> The model to have in mind is how packets are mapped onto MPLS LSPs and how packets are mapped onto link-layer next hops. Destination address route table lookup specifying next IPv6 hop and corresponding link-layer encapsulation and next hop link-layer address. In this case the outer IPv6 tunnels between IOAM nodes are virtual link-layers.
>
>
>>
>> I believe that this is currently being developed and maybe even being
>> deployed, but not under the auspices of IETF. Frankly, figuring out
>> how to do header insertion in a sensible and standard way would be a
>> step up from some of the methods being proposed. The most egregious
>> proposal I've seen was one in which the ingress router would place the
>> IOAM information in the TCP payload and then use diff serv bits to
>> indicate the TCP payload is modified. Of course the day a network
>> fails to remove the inserted information this completely breaks TCP!
>>
>> 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.

>
> MPLS framing is an example of something that suits requirement ("MPLS" here is not implying the "MPLS Family" of protocols (RSVP, LDP etc.) that are apparently the actual cause of the problem that SR is trying to solve). There could be other options.
>
> So people need to either accept the IPv6 overhead trade-off to get the commodity benefits of IPv6, or be willing to deploy a lower overhead local network protocol to carry that local information in their network.
>
> EH insertion is a hack and will always be a hack, and anything that tries to work around its issues will also going to be a hack. Decommodified IPv6 due to hacks is not commodity IPv6.

A lot of people thought NAT was a hack too :-) 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, 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).

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