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

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Mikael,

Thanks - please find some notes inline ("... FB").

-----Original Message-----
From: Mikael Abrahamsson <[e-mail]> 
Sent: Montag, 1. April 2019 13:16
To: Frank Brockners (fbrockne) <[e-mail]>
Cc: Mark Smith <[e-mail]>; C. M. Heard <[e-mail]>; 6man WG <[e-mail]>; [e-mail]
Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)

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-deploym
> ent-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?

...FB: There is obviously no easy answer. Couple of thoughts:
* IOAM is considered a "domain specific" feature (see draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domain should be IOAM capable.  And IMHO,  we should add a statement to draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation of IOAM MUST ensure "C1".
* That said, there can be situations, where C1 cannot be achieved, e.g. consider a network which does ECMP scheduling based on packet length. 
* What one could consider - and which is one suggested deployment model - is that by default IOAM data fields are added to _all_ customer packets. The decapsulating node would decide whether the IOAM information contained in a packet would be used (and exported) or not. That way one would not need to deal with the situation that some traffic carries IOAM while other does not - and might thus be treated differently. 

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?

...FB: The comparison to MPLS is interesting. How often do MPLS packets leak and cause harm? For IOAM, draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment model similar to what we do for MPLS: Unless an interface is explicitly configured for IOAM, packets with IOAM data fields MUST be dropped. Hence leakage would only occur, if we have a clearly misbehaving router which violates this rule. Similar to you, I'd also greatly appreciate any pointers to research on how common MPLS leaked packets are.

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.

...FB: Yes - this is a trade-off. In some deployments, it might not be feasible to deploy IOAM in the underlay (e.g. v6) - but you still want to use it to measure the overlay (e.g. with NSH) - hence we're defining encapsulations for several "tunnel" protocols. 

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?

...FB: One idea that Shwetha came up with to identify the source AS of a leaked packet, would be to add a new new IOAM E2E option - as proposed in section 5.1.1 bullet 2 of draft-ioametal-ippm-6man-ioam-ipv6-deployment-01.

Cheers, Frank

-- 
Mikael Abrahamsson    email: [e-mail]