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

[Templin, Fred L]

Hi Stewart,

> *If*  you care about packet loss

I can say that, for air traffic communications at least, we do care very
much about packet loss.

> then your only option is to probe the path with with
> synthetic data that exactly mimics the live data

Yes, that is exactly correct - so, the probing must be on a per
(session,destination) basis and not just per-destination.

> or not to probe at all and live with the 1280

That is the case for tunnels for sure, but many tunneling specs have
been published with an "optimistic" outlook assuming that the
network can support as much as 1500 minus the length of the 
encapsulation headers. Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmentation to
guarantee that - at a minimum - packets up to 1280 will get through.

> As I said 1280 is pretty close to 1496 which is all most networks
> will give you in practice.

Still, I wish for the day that we may eventually see larger path MTUs.
It seems that the only way for sources to safely discover them
however is to employ per-session RFC4821.

Thanks - Fred
fred.l.temp...@boeing.com

> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> Sent: Tuesday, February 14, 2017 8:45 AM
> To: Templin, Fred L <fred.l.temp...@boeing.com>; Stewart Bryant 
> <stewart.bry...@gmail.com>; Brian E Carpenter
> <brian.e.carpen...@gmail.com>; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> Fred
> *If*  you care about packet loss, then your only option is to probe the
> path with with
> synthetic data that exactly mimics the live data, or not to probe at all
> and live
> with the 1280. As I said 1280 is pretty close to 1496 which is all most
> networks
> will give you in practice.
> 
> When I think about the people asking for fast re-route to minimise
> packet loss, it seems
> very strange to deliberately induce loss to try to stretch the MTU by 15%.
> 
> - Stewart
> 
> 
> On 14/02/2017 16:25, Templin, Fred L wrote:
> > Hi Stewart,
> >
> >> -----Original Message-
> >> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> >> Sent: Tuesday, February 14, 2017 8:13 AM
> >> To: Templin, Fred L <fred.l.temp...@boeing.com>; Brian E Carpenter 
> >> <brian.e.carpen...@gmail.com>; Stewart Bryant
> >> <stew...@g3ysx.org.uk>; gen-art@ietf.org
> >> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> >> 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.temp...@boeing.com
> >
> >>> 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.temp...@boeing.com
> >>>
> >>>> - 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 bl

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

[Templin, Fred L]

Hi Ole,

> -Original Message-
> From: otr...@employees.org [mailto:otr...@employees.org]
> Sent: Tuesday, February 14, 2017 11:17 AM
> To: Templin, Fred L <fred.l.temp...@boeing.com>
> Cc: Stewart Bryant <stewart.bry...@gmail.com>; Brian E Carpenter 
> <brian.e.carpen...@gmail.com>; gen-art@ietf.org; 6man WG
> <i...@ietf.org>; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> Fred,
> 
> >> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose 
> >> of the minimum MTU was to give space for tunnel
> headers
> >> (1500-1280).
> >
> > But, if non-tunnel links set a 1280 MTU which is perfectly OK with the 
> > standard then
> > there is no space for headers. Given the issues with classical PMTUD then 
> > (plus the
> > non-applicability of RFC4821 for tunnels) the only solution for tunnels is 
> > fragmentation.
> > I'll let Joe step in if he wants to.
> 
> You are correct. "Does not work for IP tunnels without fragmenting the outer 
> header" is what I should have written.
> Of course it appears IPv6 fragments have a order of magnitude higher drop 
> probability than ICMP PMTUD messages.

Right. Depending on the encapsulation, however, fragmentation might occur as
some mid-layer between the outer and inner IP headers. For example, a UDP
encapsulation that includes its own fragmentation control fields. In that way,
the network would only see UDP/IP packets - it would not see IPv6 fragments.

GUE is an example UDP encapsulation that include its own fragmentation
control fields:

https://datatracker.ietf.org/doc/draft-herbert-gue-extensions/

> Pick your poison.

As far as RFC 2473 is concerned, you are right. Other encapsulations that
can do the fragmentation at a mid-layer between the inner and outer
IP headers should be OK.

Thanks - Fred

> Best regards,
> Ole


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Templin, Fred L]

Hi Ole,

> -Original Message-
> From: otr...@employees.org [mailto:otr...@employees.org]
> Sent: Tuesday, February 14, 2017 10:33 AM
> To: Stewart Bryant <stewart.bry...@gmail.com>
> Cc: Templin, Fred L <fred.l.temp...@boeing.com>; Brian E Carpenter 
> <brian.e.carpen...@gmail.com>; gen-art@ietf.org; 6man WG
> <i...@ietf.org>; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> Stewart,
> 
> > *If*  you care about packet loss, then your only option is to probe the 
> > path with with
> > synthetic data that exactly mimics the live data, or not to probe at all 
> > and live
> > with the 1280. As I said 1280 is pretty close to 1496 which is all most 
> > networks
> > will give you in practice.
> 
> Yes, but sending at 1280 does not work for IP tunnels. The whole purpose of 
> the minimum MTU was to give space for tunnel headers
> (1500-1280).

But, if non-tunnel links set a 1280 MTU which is perfectly OK with the standard 
then
there is no space for headers. Given the issues with classical PMTUD then (plus 
the
non-applicability of RFC4821 for tunnels) the only solution for tunnels is 
fragmentation.
I'll let Joe step in if he wants to.

Thanks - Fred

> > When I think about the people asking for fast re-route to minimise packet 
> > loss, it seems
> > very strange to deliberately induce loss to try to stretch the MTU by 15%.
> 
> Please show the data that there is significant loss. The measurements I have 
> found has not shown that.
> If not, then let's please leave that argument on the shelf.
> 
> (And please don't read me wrong, I think we should get DNS fixed, that we 
> should fix the IP tunnelling protocols, and that we should
> get IP fragmentation deprecated).
> 
> But right here, right now. PMTUD is for many problems the only solution on 
> the table.
> We as a community can choose not to elevate the standard of course, and that 
> will of course not have any big consequence.
> Are you afraid that elevating 1981, will hinder people from working on new 
> and better solutions?
> 
> Best regards,
> Ole

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Templin, Fred L]

Hi Stewart,

> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> Sent: Tuesday, February 14, 2017 8:13 AM
> To: Templin, Fred L <fred.l.temp...@boeing.com>; Brian E Carpenter 
> <brian.e.carpen...@gmail.com>; Stewart Bryant
> <stew...@g3ysx.org.uk>; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> 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.temp...@boeing.com

> > 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.temp...@boeing.com
> >
> >> - 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.temp...@boeing.com
> >>>
> >>>> -Original Message-
> >>>> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Stewart Bryant
> >>>> Sent: Friday, February 10, 2017 2:21 AM
> >>>> To: Brian E Carpenter <brian.e.carpen...@gmail.com>; Stewart Bryant 
> >>>> <stew...@g3ysx.org.uk>; gen-art@ietf.org
> >>>> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> >>>> 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 migh

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

[Templin, Fred L]

HI Stewart,

> -Original Message-
> From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
> Sent: Tuesday, February 14, 2017 1:51 AM
> To: Templin, Fred L <fred.l.temp...@boeing.com>; Brian E Carpenter 
> <brian.e.carpen...@gmail.com>; Stewart Bryant
> <stew...@g3ysx.org.uk>; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> Hi Fred
> 
> Looks like a good point on RFC4821.

OK.

> 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.)

You briefly mentioned the authorship in your earlier post. As you well
know, the corporate affiliation of two of the authors no longer exists.

Thanks - Fred
fred.l.temp...@boeing.com

> - 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.temp...@boeing.com
> >
> >> -Original Message-
> >> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Stewart Bryant
> >> Sent: Friday, February 10, 2017 2:21 AM
> >> To: Brian E Carpenter <brian.e.carpen...@gmail.com>; Stewart Bryant 
> >> <stew...@g3ysx.org.uk>; gen-art@ietf.org
> >> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> >> 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

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

[Templin, Fred L]

Hi Ole,

> -Original Message-
> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of otr...@employees.org
> Sent: Saturday, February 11, 2017 2:59 PM
> To: C. M. Heard 
> Cc: 6man WG ; IETF ; Gen-ART 
> ; Suresh Krishnan ;
> Stewart Bryant ; draft-ietf-6man-rfc1981bis@ietf.org
> Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
> 
> > How does this work for UDP?
> >
> > Sending packets no larger than 1280 bytes is always an option, and in
> > the case of UDP-based request-response protocols such as DNS that do
> > not have connection state, it may be the only feasible option.
> 
> Yes, but DNS tend to use IP fragmentation that suffers an order of magnitude 
> worse fate than ICMP messages. ;-)
> 
> > Anyway, the point I was trying to make was not to argue about better
> > or worse methods but rather to dispute the statement that PMTUD is
> > essential for avoiding black holes. I don't believe that it is. The
> > draft itself explicitly says that "IPv6 nodes are not required to
> > implement Path MTU Discovery."
> 
> That's correct. But it then must restrict itself to sending packets at the 
> minimum MTU size.
> You cannot implement RFC2473 (IP in IP) without PMTUD for example.

Right, but RFC2473 also has other problems, e.g., integrity.

Thanks - Fred

> [...]
> 
> > What criteria for advancement to IS do you think are not met by this 
> > document?
> >
> > I do not dispute that the document has met the formal criteria for IS in 
> > Section
> > 2.2 of RFC 6410. I would argue, however, that its failure to provide a 
> > complete
> > solution for environments where delivery of ICMP messages is not assured
> > constitutes a significant technical omission for today's Internet, and I 
> > note
> > that per RFC 2026 Section 4.1.1, even a PS "should have no known technical
> > omissions." What I am asking the community, and the IESG, is whether it is
> > wise to advance a document with known technical omissions; it seems to me
> > that the Gen-ART reviewer has raised much the same question.
> 
> For IPv6, because of the removal of fragmentation by intermediate nodes, 
> failure to provide a path where ICMP message delivery is
> assured is a considered a configuration error.
> 
> From 
> http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf:
> 
> "We observed that for IPV4 between 4% and 6% of the paths between the vantage 
> points and our experimental setup filter ICMP PTB
> packets. For IPV6 this was between 0.77% and 1.07%. Furthermore, we found 
> that when IPV4 Domain Name System (DNS) servers do
> not act on the receipt of ICMP PTB packets, between 11% and 14% of the 
> answers from these DNS servers are lost. For IPV6 DNS
> servers this was between 40% and 42%. Lastly, we found that for IPV4 
> approximately 6% of the paths between the vantage points and
> our experimental setup filter IP fragments. For IPV6 this was approximately 
> 10%."
> 
> From that data it looks like we have been quite successful. ICMPv6 PMTUD is 
> treated a lot better (about a 1% loss) than its IPv4
> counterpart.
> Unless better data exists I tend to conclude that the claim that the Internet 
> breaks PTUMD for IPv6 is a myth.
> 
> Fragmentation on the other hand...
> And please don't get me wrong, I think we have a big job to do on MTU issues. 
> I just don't see data showing that PMTUD isn't doing
> what it was designed to do.
> 
> Best regards,
> Ole
> 
> 


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Templin, Fred L]

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.temp...@boeing.com

> -Original Message-
> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Stewart Bryant
> Sent: Friday, February 10, 2017 2:21 AM
> To: Brian E Carpenter ; Stewart Bryant 
> ; gen-art@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
> 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