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

["Templin, Fred L" <[e-mail]>]

Hi Stewart,

> -----Original Message-----
> From: Stewart Bryant [mailto:[e-mail]]
> Sent: Tuesday, February 14, 2017 8:13 AM
> To: Templin, Fred L <[e-mail]>; Brian E Carpenter <[e-mail]>; Stewart Bryant
> <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
[e-mail]

> > 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
> > [e-mail]
> >
> >> - 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
> >>> [e-mail]
> >>>
> >>>> -----Original Message-----
> >>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Stewart Bryant
> >>>> Sent: Friday, February 10, 2017 2:21 AM
> >>>> To: Brian E Carpenter <[e-mail]>; Stewart Bryant <[e-mail]>; [e-mail]
> >>>> Cc: [e-mail]; [e-mail]; [e-mail]
> >>>> 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
> >>>> [e-mail]
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >
>