Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

[Suresh Krishnan <[e-mail]>]

Hi Mike,

On Feb 10, 2017 11:30 PM, "C. M. Heard" <[e-mail]> wrote:

On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > or declared it as historic and wrote a new text from a clean start?
> > >
> > > I don't see that. It's a stable, widely deployed, interoperable
> > > mechanism. That is rather orthogonal to the issue that has been
raised,
> > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > across the Internet.
> >
> > I will not debate whether it is faulty or not,
>
> It's faulty by the standard of RFC4890 (which is Informational).
>
> > but it seems that in practice the Internet breaks the mechanism.
> > However it breaks it is a way that seems disruptive to some user
> > traffic. The document is really guidance one how hosts might use
> > ICMP for optimization, and arguabl[y] need not be a standard at all.
>
> I think that's a mischaracterisation of the mechanism (and the draft).
> PMTUD is not an optimisation. Without it, you get black holes.

Actually, no. You do not have to use PMTUD to avoid black holes.
Other options include:

- Send packets no larger than 1280 bytes (this is always an option)
- Use PLPMTUD (for transports that do their own packetization and
  that can detect packet loss)


How does this work for UDP?


> > My remark about heritage is that this vintage draft is very much a
> > product of its time, and really needs modernizing, and after
> > modernizing ought to look quite different, and thus maybe we
> > should employ a procedure other than a simple replacement.

I am afraid that I have to agree with this. Classic PMTUD by itself
is today not enough, but it can be a very useful optimization to
augment other techniques.


OK.


> It's proposed for Internet Standard. That means it must replace the
> PS document and must specify the same thing, plus corrections,
> minus unused features.

All true, and my conclusion is that is it should not be promoted to IS.


What criteria for advancement to IS do you think are not met by this
document?

I would have no problem with republishing at PS to correct the errata
and aid the eventual advance of RFC 4821 (PLPMTUD).

If this document does go forward, the words in Appendix B (Changes
Since RFC 1981) relating to RFC 4821 should be removed, since
there was no mention of RFC 4821 in RFC 1981.


Not sure I understand your concern. This is a change log since RFC1981. And
it is a fact that the reference to RFC4821 was added into this draft. Can
you clarify?

Thanks
Suresh