ietf
[Top] [All Lists]

Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

2017-03-30 10:11:52
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(_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
    
    





<Prev in Thread] Current Thread [Next in Thread>