Hi Mikael,
Thanks for your careful review. Responses inline.
Ron
> -----Original Message-----
> From: Mikael Abrahamsson <swm...@swm.pp.se>
> Sent: Tuesday, March 6, 2018 4:57 AM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: int-area@ietf.org
> 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: swm...@swm.pp.se
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
