RE: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

[Andrew Alston <[e-mail]>]

Hi Brian,

> My understanding is that this could only happen if the SR domain was itself a
> VPN, so the SR packets would be payload as far as the non-SR routers were
> concerned, and hence not problematic. Certainly the "open Internet"
> scenario needs to be excluded. (Apart from anything else, the Internet is
> partially opaque to extension headers [RFC7872], so it won't work anyway in
> the general case.)

The observations in RFC7872 are interesting - though I must note that in tests we did recently - and I've since conducted subsequent tests with other networks, we found a surprising lack of drops of packets with extension headers.  As a stated on the spring list, in a test of CRH [draft-bonica-6man-comp-rtg-hdr-09] we were able to steer across multiple nodes in our own network, out across the open internet, into another network, and then fairly deeply into the other network.   The packets were sourced from Kenya and destined for the netherlands and we were passing through multiple asn's that had no knowledge CRH or anything to do with the test we were running.  I've since completed similar tests to other networks, again, not connected, in various parts of the world - and maybe I've just been lucky, but to my surprise every test run so far has been 100% successful.  Now, I am NOT disputing that there are networks out there that may be dropping packets with extension headers - I just need to clarify that in the tests we've done so far - its not a behavior that I have seen, hence, I have to wonder how common this is.  It may be well worth re-conducting the research done in RFC7872 and see just how much the situation described in that document still holds true 3 and a half years later when the v6 adoption on the internet has advanced and become slightly more mature (not nearly as much advancement as I'd like, but things have changed)

Btw - if anyone on this list is interested in conducting some research and potentially publishing an update to RFC7872 in some form - please contact me - I'd be happy to put some resource into this - its useful data.

> 
> I agree that the definition of "SR domain" could be clarified further; in fact
> Darren Dukes and I spent some time discussing the domain boundary last
> Friday after the IETF ended.
> 

And this Brian is my entire point - I to spoke to various people about the definition of an SR domain following the incident that occurred in 6man and being told to read an rfc I had read, in an effort to understand if perhaps I was just being dense, or if that current definition was fairly open to interpretation, since as you say, there are implications, but what is implied and what is stated explicitly are far from the same thing.    The understandings and interpretations of what an SR domain were - came back surprisingly varied - or in the words of one individual - "I asked that two  years ago, I still have no idea as to the real answer".
Basically what I am saying is - when we are facing an issue where a draft document wishes to openly and without apology announce violations of a published RFC arrived at by community consensus, and furthermore, advocate for further violations of said RFC, while I have very strong problems with this - in the absence of updating the original document - at the very minimum, it is prudent to ensure there is no ambiguity about the conditions under which such blatant violations occur.  Right now - with that definition as it stands - there is a LOT of ambiguity and a lot is open to interpretation.  Lack of clarity and leaving things open to interpretation - leads to breakage - leads to incompatibility - and leads to operational headaches.

Thanks

Andrew