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

[Mikael Abrahamsson <[e-mail]>]

On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote:

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

Yes, I think this is the only way. Is there a risk that intermediate 
routers would not be IOAM capable? I think the C1 requirement is really 
really hard to fulfil and I'm also afraid that adding the IOAM header will 
actually make ECMP stop working on some platforms (because they would not 
have the capability to look deep enough into the packet to find L4 
information, so it'll go back to 2 tuple ECMP instead of 5 tuple.

But this question can only be answered by people with deep NPU 
knowledge...

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

When it comes to "cause harm" I imagine there are (at least) two ways to 
cause harm, one is privacy/secrecy/security loss and the other one is 
actual operational loss.

I know of bugs where labeled packets went the wrong way and caused them to 
be lost, I've also seen bugs where bugs caused traffic to "hop" between 
VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this 
though.

Depending on the deployment scenario, it might make sense to make IOAM 
packets not valid for non-IOAM aware devices (basically encap entire 
packet/payload), but that might be a problem for intermediate non-IOAM 
nodes then. This would affect the ECMP requirement. I can see cases where 
one would operationally turn on IOAM for some customers traffic and then 
see the problem go away because now ECMP changed.

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

Yes, that'd solve that problem.

How much has the silicon people been involved so far in the design of the 
headers? What is the current thinking of amount of data going into the 
IOAM header? Considering things like trace options etc it seems to me the 
header can grow quite large? To satisfy the ECMP requirement what about 
putting the IOAM information as a trailer behind the regular payload? Or 
is there a problem for the hw to manipulate information that far into the 
packet (I also imagine this will considerably lower the forwarding 
performance of IOAM packets on IOAM aware platforms).

-- 
Mikael Abrahamsson    email: [e-mail]