Hi Stewart, > -----Original Message----- > From: Stewart Bryant [mailto:stewart.bryant@xxxxxxxxx] > Sent: Tuesday, February 14, 2017 8:13 AM > To: Templin, Fred L <Fred.L.Templin@xxxxxxxxxx>; Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; Stewart Bryant > <stewart@xxxxxxxxxxxx>; gen-art@xxxxxxxx > Cc: ipv6@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-6man-rfc1981bis.all@xxxxxxxx > Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04 > > > > On 14/02/2017 15:50, Templin, Fred L wrote: > > > >> As to you first point remember that the convergence process disrupts the > >> traffic flow as it does so, and that this will repeat every 10 mins as > >> it tries to re-optimise. > > Yes, you are right. So, even in the case of RFC1981bis it might not be a > > good idea to store discovered MTUs in the network layer when there > > is ECMP in the path. (Which could be any time at all.) > > Yes, I think if you really care about disruption due to packet loss your > best bet is > to go with the minimum supported MTU. > > Forwarding performance is not a issue these days, and core link are over > provisioned > so you have to wonder how important the efficiency gain is in practice. > The efficiency > gain produced by this protocol in most networks (1276 vs 1496) is only > about 15% anyway. So, that would leave us with RFC4821 plus per {session,destination} probing instead of just per-destination probing. Or, just stick with the IPv6 minMTU (1280)? Thanks - Fred fred.l.templin@xxxxxxxxxx > > You briefly mentioned the authorship in your earlier post. As you well > > know, the corporate affiliation of two of the authors no longer exists. > My concern was that some authors cannot take part in Auth48 due to not > providing > active email addresses. > > - Stewart > > > > > Thanks - Fred > > fred.l.templin@xxxxxxxxxx > > > >> - Stewart > >> > >> > >> On 10/02/2017 15:38, Templin, Fred L wrote: > >>> Hi, about ECMP I think RFC1981bis should be OK even if ECMP is used in the > >>> network as long as ICMP PTBs are not blocked. RFC1981bis will eventually > >>> converge to the minimum MTU of all paths in the multipath, and so it is > >>> still OK to store the MTU in the network layer where it would be shared > >>> by all flows. > >>> > >>> ECMP does present challenges for RFC4821, however. If a first transport > >>> session discovers a large MTU and shares it with a second transport > >>> session, the second session may take a very different path where there > >>> is a smaller MTU and encounter a black hole. IMHO, it might be a good > >>> idea to file an erratum to RFC4821 explaining how ECMP might cause > >>> problems if discovered MTUs are shared between sessions. > >>> > >>> Thanks - Fred > >>> fred.l.templin@xxxxxxxxxx > >>> > >>>> -----Original Message----- > >>>> From: ipv6 [mailto:ipv6-bounces@xxxxxxxx] On Behalf Of Stewart Bryant > >>>> Sent: Friday, February 10, 2017 2:21 AM > >>>> To: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; Stewart Bryant <stewart@xxxxxxxxxxxx>; gen-art@xxxxxxxx > >>>> Cc: ipv6@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-6man-rfc1981bis.all@xxxxxxxx > >>>> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04 > >>>> > >>>> > >>>> > >>>> 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 > >>>> 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. > >>>> > >>>> 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 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. > >>>> > >>>> 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? > >>>> > >>>>>> ====== > >>>>>> > >>>>>> 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? I don't know, but I do know that the mainstream ECMP > >>>> approach > >>>> is the five-tuple. 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. > >>>> > >>>>> I think your other comments are all valuable. > >>>> Thank you. > >>>> > >>>> Stewart > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@xxxxxxxx > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > > >