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

[Tom Herbert <[e-mail]>]

On Tue, Apr 2, 2019 at 8:06 AM Mikael Abrahamsson <[e-mail]> wrote:
>
> 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...
>
Mikael,

This is solved with proper use of the IPv6 flow label for ECMP instead
of devices continuing to try to find 5 tuples buried deep within
packets. DPI is only going to become harder as more headers and
functionality are added (e.g. segment routing header will be another
problem, deep headers will exceed parsing buffers, and it's impossible
to find the 5 tuple for a fragment and still be stateless). Since IOAM
is used in a limited domain, the requirement should be that all
routers in the domain support ECMP routing using flow label (note that
is a less stringent requirement than all routers having to support
IOAM).

Tom

> > ...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]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------