Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

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

On 2019-01-15 11:04, Tom Herbert wrote:
> Hello. I have a couple of comments:
> 
>>From the draft:
> "Middle boxes SHOULD process IP fragments in a manner that is
> compliant with RFC 791 and RFC 8200.  In many cases, middle boxes must
> maintain state in order to achieve this goal."
> 
> This requirement is confusing to me on several accounts. 

Me too. I think the root of the problem is the word "compliant". To
be compliant with the IP model, middleboxes should not exist. I think
what the text is trying to say is more like:

"Middle boxes SHOULD process IP fragments in a manner that is
consistent with RFC 791 and RFC 8200."

That's a requirement for effective transparency, not for compliance.

> First of all,
> there are a lot of requirements about fragmentation in both RFC791 and
> RFC8200, including some MUSTs. This requirement seems to be updating
> and possibly relaxing some of those requirements, but is not specific.
> This seems ambiguous as a normative requirement.
> 
> Secondly, the only specified interaction between fragmentation and
> intermediate nodes is that routers can fragment packets in IPv4. Other
> than that, a middlebox that complies with RFC791 and RFC8200 does not
> process or consider fragmentation of packets. Given that, it's unclear
> to me why middle boxes would need to maintain state to be protocol
> compliant. It's possible that the implicit exception of the
> requirement is that middleboxes might perform "in-network reassembly"
> or "virtual reassemlby" which would require state. If that is indeed
> the case then the requirements for the mechanisms should be spelled
> out.
> 
> For stateless load balancing (described in section 4.4), the IPv6 flow
> label obviates the need for DPI. It is sufficient to hash over the
> three tuple <saddr, daddr, flow label> to get good load balancing. All
> major OSes have been updated to set flow labels, and there are devices
> that already support this. IMO, the draft should make using flow label
> for stateless load balancing a SHOULD.

Agreed, and the text would need to be a bit reorganized for that, by
separating the v4 and v6 cases completely. Also things are rather
different for in-transit load balancing (including ECMP and LAG) and
server load balancing, but I don't think that changes the recommendation.
The draft could cite RFC7098 for the server case. In RFC7098, we
assumed that the balancer could revert to the old DPI method if the flow
label is zero, which may lead to a fail if the packet is fragmented.
But for in-transit load balancing of large numbers of flows, the
{source, dest, flow_label} tuple will provide entropy even if the
flow label is zero.

  Brian
 
> 
> Tom
> 
> On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern <[e-mail]> wrote:
>>
>> I have re-read this document.  I think it is a useful document that
>> captures that state of a complex tradeoff and makes effective
>> recommendations. I support publishing it as a BCP.
>>
>> If the authors make further additions, adding a mention of ECMP as a
>> particular case of stateless load balancers might further improve the
>> document.
>>
>> Yours,
>> Joel
>>
>> On 1/14/19 1:13 PM, Wassim Haddad wrote:
>>> Dear all,
>>>
>>> This email starts an Int-Area WG Last Call on the latest version of "IP Fragmentation Considered Fragile” draft:
>>>
>>> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05
>>>
>>> Please respond to this email to support the document and/or send comments by 2019-01-28.
>>>
>>> Please indicate if you are personally aware of any IPR that applies to draft-ietf-intarea-frag-fragile-xx?
>>> If so, has this IPR been disclosed in compliance with IETF IPR rules?
>>>
>>>
>>> Regards,
>>>
>>> Juan & Wassim
>>> _______________________________________________
>>> Int-area mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/int-area
>>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>