Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)

[Mikael Abrahamsson <[e-mail]>]

On Thu, 28 Mar 2019, Frank Brockners (fbrockne) wrote:

>
> FYI - A new draft including Mark's comments below just got posted:
> https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-deployment-01

I watched the tech deep dive video recording in conjunction with this. 
This is a really hard problem to solve with all those factors to take into 
account. Some random thoughts:

There seems to be overlap of this problem space with SRv6, these seem to 
have almost identical properties. They insert something, the forwarding 
devices need to interact with it and it needs to be stripped before it 
leaves the domain.

Though, in the SRv6 space the forwarding information is in the header, 
whereas for the IOAM space the forwarding device should actually ignore 
whatever is in the IOAM header as the desire is for it to treat packets 
identically regardless if they have the header or not. Considering how 
routers forward packets based on 5-tuple (or even deeper), what's the 
thinking been on this so far?

The MTU issue should be the least problematic, recommendations on using a 
considerable higher MTU on the internal links compared to the external 
links is identical to what has been used for encapsulation networks for a 
long time. We use 9180 IP MTU on the internal links and external links are 
9000 MTU. This leaves room for several layers of encap without affecting 
the customer visible MTU.

I like the fact that the IOAM information is attached to the real packet 
being forwarded as opposed to just using test traffic.

I think the C1-C6 requirements make a lot of sense, but following them is 
hard. I have myself run networks that ran IPv4 and IPv6 Internet packets 
native (no encap) internally, and only encapsulated VPN overlay packets. 
It'd of course be nice to support IOAM also for those deployment 
scenarios, but then it becomes harder to assure no leakage (C5) and 
identifying the leaker. Otoh when doing MPLS if you leak labeled packets 
they are probably dropped at the other end (do we have research on this?). 
So leaking IOAM enabled packets might be less of a disaster compared to 
other encaps?

Doing IOAM only based on some other forwarding scheme (MPLS, SRv6 etc) and 
embedding meaning into whatever forwarding information is used for that 
might help (IOAM information lives within that forwarding plane), but also 
makes IOAM less deployable for other networks that just run native.

Reading https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 and 
considering the C5 requirement, how do I as an end receiver of a packet 
with an IOAM header in it identify even what operator to contact about 
these leaked packets? It looks like the namespace/identifier is 
operator-internal, but how do I identify what operator it is?

-- 
Mikael Abrahamsson    email: [e-mail]