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

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

-----Original Message-----
From: Mikael Abrahamsson <[e-mail]> 
Sent: Dienstag, 2. April 2019 08:06
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 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...

...FB2: Given that IOAM is a domain specific feature - I expect that folks initially start to use it in domains (like e.g. a DC) where all boxes are IOAM capable and can trace the packet appropriately - or per Tom's note, can be configured so that one would do ECMP based on addresses and flow-label.  There are chips with pretty deep parsing capability (up to a few hundred bytes). 

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

...FB2: There are quite a few folks with hardware background that co-author the IOAM drafts. Parsing capability differs between chips, as does the ability to deal with new/flexible headers and the ability to modify data in the extension headers. So the unfortunate answer to that question is "it depends" (what information do you gather, how large is your domain, what are the capabilities of your hardware/software forwarder, etc.), but I do expect that for specific deployment domains (e.g. DC, Enterprise) - but also for overlay networks / VPNs - we'll see an increasing amount of chips that are well suited for processing large extension header.

Cheers, Frank

-- 
Mikael Abrahamsson    email: [e-mail]