Re: [Int-area] draft-bonica-intarea-frag-fragile-01

> On Mar 7, 2018, at 9:13 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> 
> Joe,
> 
> About middle-box reassembly,  it should probably also mention Virtual Fragment
> Reassembly where the middlebox gathers fragments but does not reassemble
> them.

That’s part of what I was referring to in my other post. 

Joe

> Then, when all fragments have been received the middlebox performs
> any transformations then releases the fragments. Several cisco webpages talk
> about this.
> 
> Thanks - Fred
> 
>> -----Original Message-----
>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch
>> Sent: Wednesday, March 07, 2018 8:52 AM
>> To: Ron Bonica <rbonica@juniper.net>
>> Cc: int-area@ietf.org
>> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
>> 
>> 
>> 
>>> On Mar 7, 2018, at 7:39 AM, Ron Bonica <rbonica@juniper.net> wrote:
>>> 
>>> Joe,
>>> 
>>> Your "Two Truths" are in line with the recommendations in Section 7 of draft-bonica-intarea-frag-fragile-01. The draft recommends
>> that upper-layer protocols avoid doing things that cause fragmentation. It does not recommend the deprecation of fragmentation.
>> 
>> Understood, but without #2 being included and explicitly co-reinforced there is an implication to router designers that I would hope
>> can be avoided.
>> 
>> Joe
>> 
>> 
>>> 
>>>                                                                                  Ron
>>> 
>>> .
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:touch@strayalpha.com]
>>>> Sent: Tuesday, March 6, 2018 9:57 PM
>>>> To: Ole Troan <otroan@employees.org>
>>>> Cc: Tom Herbert <tom@herbertland.com>; Ron Bonica
>>>> <rbonica@juniper.net>; int-area@ietf.org
>>>> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
>>>> 
>>>> 
>>>> 
>>>>> On Mar 6, 2018, at 11:16 AM, Ole Troan <otroan@employees.org> wrote:
>>>>> 
>>>>> Joe,
>>>>> 
>>>>>> Agreed but note that draft tunnels will update that RFC in some important
>>>> ways.
>>>>> 
>>>>> With other concerns than those raised in e.g. 4459 and 7597?
>>>> 
>>>> draft-tunnels corrects an error in 4459 that deals with the details, not the
>>>> overall recommendation (AFAIR, at least).
>>>> 
>>>>> Unfortunately there are cases where there are no other choice than to do
>>>> fragmentation/reassembly on tunnel endpoints, but still the
>>>> recommendation holds.
>>>>> It is so problematic, that it is strongly recommended to engineer the
>>>> network to avoid that happening.
>>>> 
>>>> IMO, there are two truths:
>>>> 
>>>> 1) use of IP fragmentation SHOULD be avoided where possible, largely
>>>> because it has reliability issues (ICMP blocking, NATs won’t tunnel frags and
>>>> fail to [as required if they act on transport info] reassemble, etc.)
>>>> 
>>>> 2) support for IP fragmentation MUST remain required, as MUST (IMO) NAT
>>>> reassembly before transport rewriting
>>>> 
>>>> Yeah, I know a lot of devices fail the MUSTs in #2, but the requirements
>>>> ought to set the goal, not describe the (sorry) current state.
>>>> 
>>>> #2 has to persist until we deprecate IP-in-IP tunneling (including tunnel-
>>>> mode IPsec), as well as any IP-in-X*-in-IP for zero or more intermediate
>>>> layers X where no layer supports fragmentation and reassembly
>>>> 
>>>> I’ve been working to fix the need for IP frag by developing support for that in
>>>> UDP, but it doesn’t mean we should be ready to outlaw it.
>>>> 
>>>> I’m not sure what this doc does to add to this scene, though - it might be
>>>> useful if the authors could explain how it affects 1 and 2 above and what else
>>>> it adds in a *brief* post.
>>>> 
>>>> Joe
>> 
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area