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

[Ron Bonica <[e-mail]>]

Hi Mikael,

Thanks for your careful review. Responses inline.

                           Ron

> -----Original Message-----
> From: Mikael Abrahamsson <[e-mail]>
> Sent: Tuesday, March 6, 2018 4:57 AM
> To: Ron Bonica <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
> 
> On Mon, 5 Mar 2018, Ron Bonica wrote:
> 
> > Folks,
> >
> > Please review draft-bonica-intarea-frag-fragile-01 and provide comments.
> > The URL is
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dbonica-2Dintarea-2Dfrag-2Dfragile-
> 2D01&d=DwIBAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=rEnXuPqkshyKZKBjvbX5C4azFkl4x3umDYP-
> M8MPk9k&s=fzVLPQb705xxBUc4zque37mctCX2lPbU4hREEMOtsjU&e=.
> 
> I like it.
> 
> 4.6. There are cases where this "misconfiguration" is due to vendor default
> not being changed. I do not equate "misconfiguration" with "didn't change
> default configuration". Some others might. It might also be due to "hardware
> limitation". Generally, I do not like the "filtering" (I have opposed to this in
> other drafts), as for me "filtering" conveys intent. If there is no intent, there
> is no filtering, but instead there is "dropping"
> or some other word.

Agree. I have expanded this text in the next draft version.

> 
> 4.7 Can we please have 4.7 that describes cases where ICMP PTB are never
> emitted because of misconfiguration? For instance intermediate L2 switch
> that has lower MTU than the L3 nodes connected to it, or mismatched
> MTU/MRU on two nodes connected to each other.

I have added this text in Section 7.2 saying that network devices must be configured so that they emit ICMP PTBs when required to do so.

> 
> 5.1. Can we have some kind of strong recommendation that hosts enable
> PLMTUD for TCP?
> 
While I agree with this recommendation, I am not sure if the INT AREA is empowered to make it. Wouldn't such a recommendation have to come from the TSV area?


> 6. "IP encapsulations". Shouldn't this be "some packet-in-packet
> encapsulations"? Or does "IP encapsulations" mean "anything encapsulated
> in IP"? 6.3 talks about this as well, I think it's worthwile to put in a sentence
> that whatever is said in this document, probably applies to all kinds of
> encapsulations.

I have changed the term "IP encapsulations" to "Packet-in-packet encapsulations"
> 
> 6.1. Err, last paragraph, aren't we getting ahead of ourselves here? I guess
> this is because of Geoff Hustons claims? That last paragraph is in dispute (I'd
> say, from talking to other people involved in DNS).
> 

I will defer to Geoff on this one.

> 7.2. I strongly believe we need more text here. It should be something along
> the lines of:
> 
> "As per RFC4890, network operators MUST assure proper operation of
> PMTUD by making sure that PTB packets are emitted by all equipment when
> it can't fit a packet into a smaller MTU link, and that large MTU packets are
> not silently discarded due to misconfiguration. Network operators MUST
> NOT filter ICMP PTB packets."

Agree. It is in the next version

> 
> ...
> 
> As a last comment, do we know documents that tell application developers
> how to do what this document recommends in 5.2? If someone developers
> applications that use UDP for instance, how do they know what the
> operating system PMTUD is at any given time, to avoid the host stack
> fragmenting the packet? I've been interacting with people who had this
> specific problem, and it wasn't easy to figure out exactly how to do what
> is being said in this text (which I agree should be done).
> 
If I understand you correctly, such documentation would be available on per-OS basis.

> Generally, I think the IETF should strongly recommend application/protocol
> developers to not rely on IP fragmentation, generally. So the ones listed
> in 6 (and I imagine there are more of them), should change the way the
> protocol is done. This includes DNS. So all working groups should be put
> on notice to start working on this problem if they don't already have a
> solution for it.
> 

This draft is intended to bring the IETF community to the conclusion that you have drawn.

                                                      Ron

> --
> Mikael Abrahamsson    email: [e-mail]