On 31/03/2017 02:11, Jeff Tantsura wrote: > Brian, > > if I understand you correctly: > > If properly worded (improved) draft-voyer explicitly states – the intention is to change the 2460(bis) behavior and to allow header insertion within a controlled domain, and given there’s a valid justification of why encap wouldn’t’ meet the need, you wouldn’t oppose? No, I wouldn't. I might even help; hence my suggested tweak to 2460bis. Note that the tricky bit (in reality and in the text) is a crisp definition of what the domain boundary is and what happens when packets with inserted headers accidentally escape. We did hit that difficulty when trying (and failing) to define local-use rules for stateful use of the flow label. But we were trying to do that in a generic document (in effect, an extension of RFC2460) and failed for essentially the same reasons that led Suresh to his decision on 2460bis. https://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 shows some remnants of that attempt. Brian > > Thanks! > > Cheers, > Jeff > > On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter" <ietf-bounces@xxxxxxxx on behalf of brian.e.carpenter@xxxxxxxxx> wrote: > > On 30/03/2017 15:59, Leddy, John wrote: > > ... > > If this insert/delete of an SRH is prematurely prohibited; What is a recommended solution to the Real World problem above. Not use case, we are implementing. > > > > Again; I’m worried we are eliminating a tool that may prove very helpful, preclude its use in future IETF work and shutdown a path for Innovation in Networking, > > I've tried to say this before but I'm not sure people are getting it: > > RFC2460bis, if approved as is, draws a line in the sand *for interoperability across the whole Internet*. There are reasons for this - PMTUD in any form, any future replacement for the unsuccessful IPsec/AH, and all the problems of deploying extension headers that are understood by some nodes and not by others. > > There is no reason why a subsequent standards-track document cannot allow header insertion (and removal) within finite domains where the above issues do not apply. In fact, an improved version of draft-voyer-6man-extension-header-insertion-00 could become exactly that. > > There doesn't need to be a tussle here. > > Brian Carpenter > > > > >