On 10/02/2017 23:20, Stewart Bryant wrote: > > > On 10/02/2017 03:25, Brian E Carpenter wrote: >> Stewart, >> >> 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, but it seems that in
It's faulty by the standard of RFC4890 (which is Informational). > 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 arguable 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. > > 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. 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. >> ... >>> It is concerning that the draft does not talk in any detail about >>> how modern ECMP works, i.e. using the five tuple, and noting that >>> the PMTU may be different depending on the transport layer port >>> numbers. >> Has this problem been analysed for, say, IPv4? And does the real world >> contain ECMP setups with different MTUs on different paths? > > I don't know if anyone has looked. Since the mechanism is > self-correcting albeit > with some disruption to user traffic it looks to the application and the > application > user, just like the Internet not working for a few moments. > > In a well managed SP network there should not be, but neither should there > be asymmetric path costs, but there are. The less well manage private > networks are less well managed. > > >> >>> Given that a very large fraction of packets will traverse an MPLS >>> network at some point, I am surprised that there is no text talking >>> about the importance of providing support for this feature in the >>> MPLS domain. RFC3988 talks to this point, but is only experimental. >> I don't understand. How does the fact that there might be some MPLS >> segments along the path affect end-to-end PMTUD? > > The point that RFC3988 makes is that MPLS looks like a single hop to IP > and the > PE has to fragment or has to reply with an ICMP error message to support > PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to > result > in the right response at the end node. > > My point is that the draft is silent on the subject, and perhaps it > should not be. Well, in general it's silent on tunnels. They have to emulate links, as stated in section 2. I still don't see why an MPLS tunnel is a special case. > > However your question make me ask a further question. The draft is also > silent > on NATs. Is there any advice needed for people designing and configuring > NATs? Yes, for NAT64/NAT46 - in RFC6145. For NAT66, the advice is "don't". >> >>> ====== >>> >>> If flows [I-D.ietf-6man-rfc2460bis] are in use, an implementation >>> could use the flow id as the local representation of a path. Packets >>> sent to a particular destination but belonging to different flows may >>> use different paths, with the choice of path depending on the flow >>> id. This approach will result in the use of optimally sized packets >>> on a per-flow basis, providing finer granularity than PMTU values >>> maintained on a per-destination basis. >>> >>> SB> How widely is flow-id supported in networks? I thought that the >>> SB> current position was that it was unreliable as an ECMP indicator >>> SB> and thus routers tended to glean information from the packet themselves. >> This is future-proofing. Agreed, usage today is limited. >> >> (But it would be better to call it the Flow Label for consistency with other >> recent RFCs.) > > Well the question is whether it is simply limited today, or broken today > in a manner that > is irrecoverable? Nothing's broken. It's just underused. > I don't know, but I do know that the mainstream ECMP > approach is the five-tuple. Sure, but see RFC6438 for some of the difficulties that causes with IPv6. > There is something akin to the flow label being > deployed in MPLS. However > what distinguishes the MPLS Entropy Label is that it is inserted (and > removed) by the > service provider and is therefore trusted by the service provider. Exactly the same for ECMP tunnels, in RFC6438. Guess what, my co-author was from a provider. Brian >> >> I think your other comments are all valuable. > Thank you. > > Stewart > . > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
