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

[Mark Smith <[e-mail]>]

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

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.

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.

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