Re: Next steps on advancing core IPv6 specifications to full Internet standard

[Mark Smith <[e-mail]>]

On 22 November 2016 at 21:02, Tim Chown <[e-mail]> wrote:
> Hi,
>
> On 22 Nov 2016, at 03:22, Hemant Singh <[e-mail]> wrote:
>
> <snip>
>
>
> So there’s a lot of vagueness about the whole SRH “insertion” issue, partly
> in the spring WG, partly in 6man, and implementation(s) doing things that
> are not (as yet, or perhaps never will be?) documented in the IETF.
>

This draft is well and truly doing it, despite the title.

"Encapsulations for In-situ OAM Data"
https://tools.ietf.org/html/draft-brockners-inband-oam-transport-02


"3.1.2.  Procedure at the Ingress Edge to Insert the In-situ
               OAM Header"


Imagine if one of those inserted EHs wasn't stripped at the edge of
the OAM domain, because of an implementation bug or configuration
error.

These OAM EH inserted packets arrive at your network and breaks the
application you're providing to a paying customer somewhere across the
Internet. This paying customer is the one that constructed and
originated the packet, and is identified by the source address.

So you contact the customer identified by the source address asking
them why are they inserting and sending OAM EHs to you. The say 'no,
we are not, and send a packet capture to prove it.

Since you're in Australia, and they're in Europe (or the US), there
are now many different networks between them and you. How do you work
out who is inserting these EHs and then not removing them?

You spend days and weeks contacting *all* the ASNs between you and
your customer (10 perhaps?), asking them if they're (a) inserting
these EHs, (b) if they are, can they determine if their equipment is
configured to remove them, and if it is (c) tell them they've got a
bug and need to contact their vendor. While they're waiting for their
vendor to fix the bug, they're probably not going to be very keen to
switch off this wonderful feature that is working fine for them ...
because they' actually don't suffer from any consequences of the EHs
they've added but not removed.

So you call up your customer, after they've suffered from a number of
weeks of lost service from you. "Do you want the good news or bad
news?" "The good news is we've found out where these EHs that are
breaking your connections to us. The bad news is that while the people
who are doing it have asked their vendor for a fix, they're refusing
to switch it off, so you'll have to put up with it for the next 3 to 6
months."

Customer says, "Unfortunately, I realise that it isn't your fault,
however we can't put up with it for that long. We're going to have to
cancel your service and go with somebody else."

Now imagine if the one customer impacted was instead 10s of 1000s of
non-technical, residential customers - like the ones Google, Netflix
and Facebook have. Most of the above becomes impractical, and if this
problem persists for more than a few days, it'll likely cost you 10s
of 1000s of customers.

I've had experience troubleshooting issues over the Internet that have
effected my residential broadband customers (e.g., getting bogon
filter routes removed from remote networks because we'd been allocated
those addresses officially). That was a walk in the park compared to
what the above scenario would be like - my customers could identify
the website that they were trying to access.

Silent insertion, meaning non-attributable insertion, and failed
removal will be a nightmare to troubleshoot if those packets make it
onto the Internet - and they will, just like RFC1918 addressed packets
do. People who believe removal will always be performed successfully
are living in the fantasy that devices always perform perfectly, never
partially failing and programmers write perfect, bug free code.


Regards,
Mark.