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?
Thanks!
Cheers,
Jeff
On 3/30/17, 07:44, "ietf on behalf of Brian E Carpenter"
<ietf-bounces(_at_)ietf(_dot_)org on behalf of
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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