Re: 6MAN WG Last Call: <draft-ietf-6man-oversized-header-chain-04>

[Brian E Carpenter <[e-mail]>]

On 20/08/2013 16:02, Fernando Gont wrote:
> Hi, Mike
> 
> On 08/19/2013 09:58 PM, C. M. Heard wrote:
>> My main question is why this draft is not better integrated with 
>> draft-wkumari-long-headers-01 and draft-bonica-6man-frag-deprecate, 
>> which have overlapping or at least related subject matter.
> 
> Because what's in draft-ietf-6man-oversized-header-chain is what the wg
> agreed upon over time.

And because taking baby steps when playing with such a basic aspect
of the protocol seems wiser. I don't think the topics overlap; saying
that the header chain must not be fragmented seems straightforward and
non-controversial. The other drafts are more contentious.

   Brian

> For instance, some earlier version of
> draft-ietf-6man-oversized-header-chain enforced an upper limit t the
> size of the extension header length (1280 bytes, at the time) but such
> limit was removed from the document in responses to wg consensus.
> 
> 
>> The thrust of draft-wkumari-long-headers-01 is the claim that 
>> operators have a requirement to filter at Layer 3 and Layer 4, at 
>> line rate, in the network, and that in order to be able to do that, 
>> the entire header chain needs to appear within a relatively short 
>> initial segment of the IPv6 datagram -- the draft suggests 128 
>> bytes.  This is MUCH shorter that the "within the first fragment" 
>> constraint specified by draft-ietf-6man-oversized-header-chain.
> 
> And it was agred by this wg that this limit would be an operational BCP,
> but not a protocol update. That's thy these items are kept in different
> documents.
> 
> 
> 
> 
>> There is also a strong hint (though not an explicit statement) in 
>> draft-wkumari-long-headers-01 that entities that do in-network 
>> line-rate filtering need to see layer 3 and 4 information in ALL 
>> datagrams, which is at the heart of the subject matter of 
>> draft-bonica-6man-frag-deprecate.
> 
> The wg discussed this, and I seem to recall that the outcome was that we
> were not ready to ban the use of fragmentation, but rather that we
> should move away from it.
> 
> Cheers,