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

[Stewart Bryant]

On 17/03/2017 21:56, Bob Hinden wrote:

Hi Stewart,

Thanks for the detailed review.  I am responding after reading the email thread 
that resulted, some issues were closed.

Several of the reviews have suggested significant changes to this document.  
The working group was trying to make a few changes to bring it into alignment 
with some changes to rfc2460bis (based on updating documents).  It was not 
attempting a major rewrite when advancing it to Internet Standard.  The 
alternative that the working group discussed was to file errata on RFC1981 and 
leave it to a future document update.


That might be the way to go.

At the end of the day it is an IESG decision, but I was somewhat 
disquieted by the number of issues and

comments raised across the set of reviewers.

When we elevate a document to standard we are saying that it represents 
a fully baked idea that has no
significant defects. The question given the level of comments is does 
this meet that bar?




I don’t think many of these changes can be done and still advance it to 
Internet Standard. If we can’t advance the current document, then the w.g. may 
want to just do the errata and withdraw the advancement request.  Of course, if 
people want to work on a revision of IPv6 Path MTU Discovery, it would be 
welcomed, but it won’t be able to advanced to Internet Standard.
Given the level of discussion, I would think that the WG should 
seriously consider a revised version clearing

up the full set of issues raised in discussion.

Responses in line

Best Regards

Stewart



Comments below.

Thanks,
Bob



On Feb 9, 2017, at 7:19 AM, Stewart Bryant  wrote:

Reviewer: Stewart Bryant
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Stewart Bryant
Review Date: 9/Feb/2017
IETF LC End Date: 1/Mar/2017
IESG Telechat date: unknown

Summary: This draft is on the right track but has open issues,
described in the review.

This review together with the lengthy discussion on the IETF list
suggest that this draft has a number of issues that need to be
addressed  before publication.

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 think this was closed in the email thread.

OK




Major issues:

Nits points out a number of faults with the document, but the only
one of substance is:

The text has a lot of RFC2119 language, but no RFC2119 declaration.

The document could use a thorough RFC2119 scrub

Based on in an earlier another review, our AD suggested an update to Shepard 
Writeup instead of adding something to the document.  It says:

This document is an update to RFC1981 that was published prior to
RFC2119 being published.  Consequently while it does use "should/must"
style language in upper and lower case, the document does not cite the
RFC2119 definitions.  Since the changes in this update were very
limited, the w.g. concluded to not change any of this language.

This is really an IESG decision.




The document lists the three original authors one with an affiliation

change, but no email addresses. Has this been agreed with the
original
authors, and have arrangements been put in place for the RFC editor
to process auth48?

I contacted the original authors and they didn’t express any interest in being 
involved in this update.  They haven’t participated in the IETF for many years. 
 I can contact them during AUTH48, or the AD can override this requirement for 
this document.


So long as you have an arrangement in place that is acceptable to the 
RFC Editor and IESG.



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.


I think this is out of scope.


So long as PMTU is bound to the five tuple (which I think it is), then 
the mechanism works, but given the
prevalence of ECMP (pretty much every packet going across the core will 
be sujected to it) I don't think

I agree that a discussion is out of scope.





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 think this was closed in the email thread.


It was ruled out of scope on the basis that tunnel were out of scope, 
but this tunnel type does need
some special consideration, 

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

[Bob Hinden]

Hi Stewart,

Thanks for the detailed review.  I am responding after reading the email thread 
that resulted, some issues were closed.

Several of the reviews have suggested significant changes to this document.  
The working group was trying to make a few changes to bring it into alignment 
with some changes to rfc2460bis (based on updating documents).  It was not 
attempting a major rewrite when advancing it to Internet Standard.  The 
alternative that the working group discussed was to file errata on RFC1981 and 
leave it to a future document update.

I don’t think many of these changes can be done and still advance it to 
Internet Standard. If we can’t advance the current document, then the w.g. may 
want to just do the errata and withdraw the advancement request.  Of course, if 
people want to work on a revision of IPv6 Path MTU Discovery, it would be 
welcomed, but it won’t be able to advanced to Internet Standard.

Comments below.

Thanks,
Bob


> On Feb 9, 2017, at 7:19 AM, Stewart Bryant  wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-6man-rfc1981bis-04
> Reviewer: Stewart Bryant
> Review Date: 9/Feb/2017
> IETF LC End Date: 1/Mar/2017
> IESG Telechat date: unknown
> 
> Summary: This draft is on the right track but has open issues,
> described in the review.
> 
> This review together with the lengthy discussion on the IETF list
> suggest that this draft has a number of issues that need to be
> addressed  before publication.
> 
> 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 think this was closed in the email thread.


> Major issues:
> 
> Nits points out a number of faults with the document, but the only
> one of substance is:
> 
> The text has a lot of RFC2119 language, but no RFC2119 declaration.
> 
> The document could use a thorough RFC2119 scrub

Based on in an earlier another review, our AD suggested an update to Shepard 
Writeup instead of adding something to the document.  It says:

   This document is an update to RFC1981 that was published prior to
   RFC2119 being published.  Consequently while it does use "should/must"
   style language in upper and lower case, the document does not cite the
   RFC2119 definitions.  Since the changes in this update were very
   limited, the w.g. concluded to not change any of this language.


> 
> The document lists the three original authors one with an affiliation
> 
> change, but no email addresses. Has this been agreed with the
> original
> authors, and have arrangements been put in place for the RFC editor
> to process auth48?

I contacted the original authors and they didn’t express any interest in being 
involved in this update.  They haven’t participated in the IETF for many years. 
 I can contact them during AUTH48, or the AD can override this requirement for 
this document.

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

I think this is out of scope.


> 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 think this was closed in the email thread.

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

I think this was closed in the email thread.

> 
> ==
> 
>  Note: if the original packet contained a Routing header, the
>  Routing header should be used to determine the location of the
>  destination address within the original packet.  If Segments
> Left
>  is equal to zero, the destination address is in 

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

[Joe Touch]

On 2/16/2017 1:29 PM, Stewart Bryant wrote:
>
>
> On 16/02/2017 18:49, Joe Touch wrote:
>>
>> On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>>>
>>> On 14/02/2017 23:00, Templin, Fred L wrote:
 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.
>>> In that case there really needs to be a note about MPLS.
>> IMO, this doc shouldn't be discussing tunneling as any different from
>> any other link.
>>
>>> You can fragment into an IP tunnel, but not an MPLS tunnel, because
>>> you cannot fragment the payload as you can in IPv4 and you cannot
>>> fragment MPLS.
>> There's no such thing as an "MPLS tunnel";
>
> In the MPLS world an "MPLS tunnel" is a common name for an MPLS LSP that
> is used to carry some payload such as IP.

MPLS just adds the label tags; there's no length field.  It's only a
tunnel when it goes over some other encapsulation layer, e.g., IP or
Ethernet.

>
>> at best, it's "MPLS over X",
>> e.g., MPLS over ethernet. MPLS doesn't indicate a message length so
>> while it can't support fragmentation it would never need it either. It
>> would be the next layer down (e.g., Ethernet, ATM, etc.) that might have
>> needed fragmentation.  If that can't be supported, then the addition of
>> MPLS would just reduce the effective MTU of the MPLS-over-X link.
>
> It was of course IPv6 over MPLS that concerned me.

IPv6 over MPLS isn't yet a tunnel. It would be IPv6 over MPLS over IPv6,
presumably (IPv6 over IPv4 isn't guaranteed to work because IPv4 EMTU_R
is only 576, and for an IPv6 tunnel it would be required to be at least
1280+encaps).

An IPv6 packet can traverse an IPv6 over MPLS over Ethernet tunnel (with
a 1500B payload) as long as the MPLS headers are smaller than 1500-1280
bytes.

An IPv6 packet can traverse an IPv6 over MPLS over IPv6 tunnel as long
as the MPLS + added IPv6 headers are smaller than 1500-1280 bytes.
However, if the arriving (transit) packet is larger than
1280-MPLS-IPv6ecaps, the MPLS tunnel ingress would need to do source
fragmentation inside the tunnel (with the egress doing reassembly).

Again, all these cases are discussed in draft-ietf-intarea-tunnels but
none have relevance IMO to this doc.

Joe

___
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

[Joe Touch]

On 2/16/2017 11:59 AM, Brian E Carpenter wrote:
> On 17/02/2017 04:59, Stewart Bryant wrote:
>>
>> On 14/02/2017 23:00, Templin, Fred L wrote:
>>> 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.
>> In that case there really needs to be a note about MPLS.
>>
>> You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
>> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.
> I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
> of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
> tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
> fragments and re-assemble them at the other end - if it's an avian carrier 
> tunnel
> it might have to use several pigeons per packet*. None of this matters to the 
> IPv6
> nodes concerned; the physical MTU of the tunnel technology is irrelevant 
> except
> to the tunnel end points.
There are too many systems that try to optimize the link MTU to
represent the size of the payload of the link source, rather than the
reassembly limit of the link receiver.

It's trying to make PMTUD work multiple layers down rather than stopping
at the IP layer (which I think is where it should stop).

Joe

___
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

[Brian E Carpenter]

On 17/02/2017 04:59, Stewart Bryant wrote:
> 
> 
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> 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.
> 
> In that case there really needs to be a note about MPLS.
> 
> You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
> cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.

I'm confused. A tunnel end point that accepts IPv6 packets MUST accept packets
of 1280 bytes (or shorter) and MUST emit them. How it gets them through the
tunnel is irrelevant - if it's an ATM tunnel it has to chop them into 48 byte
fragments and re-assemble them at the other end - if it's an avian carrier 
tunnel
it might have to use several pigeons per packet*. None of this matters to the 
IPv6
nodes concerned; the physical MTU of the tunnel technology is irrelevant except
to the tunnel end points.

   Brian

*In RFC 6214, we didn't consider this, but we should have.

___
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

[Joe Touch]

On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>
>
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> 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.
>
> In that case there really needs to be a note about MPLS.

IMO, this doc shouldn't be discussing tunneling as any different from
any other link.

> You can fragment into an IP tunnel, but not an MPLS tunnel, because
> you cannot fragment the payload as you can in IPv4 and you cannot
> fragment MPLS.

There's no such thing as an "MPLS tunnel"; at best, it's "MPLS over X",
e.g., MPLS over ethernet. MPLS doesn't indicate a message length so
while it can't support fragmentation it would never need it either. It
would be the next layer down (e.g., Ethernet, ATM, etc.) that might have
needed fragmentation.  If that can't be supported, then the addition of
MPLS would just reduce the effective MTU of the MPLS-over-X link.

Joe

___
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

[Stewart Bryant]

On 14/02/2017 23:00, Templin, Fred L wrote:

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.


In that case there really needs to be a note about MPLS.

You can fragment into an IP tunnel, but not an MPLS tunnel, because you 
cannot fragment the payload as you can in IPv4 and you cannot fragment MPLS.


Stewart

___
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

[Joe Touch]

Hi, Brian,


On 2/15/2017 1:26 PM, Brian E Carpenter wrote:
> On 16/02/2017 10:12, Joe Touch wrote:
>> Brian (et al.),
>>
>>
>> On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
 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
>> PMTUD is an optimization to avoid fragmentation.
>>
>> Without it, you use fragmentation (which has overheads and other
>> consequences, notably for IPv4).
> In IPv6, you don't even know you *need* fragmentation without PMTUD,
> since only the source is allowed to fragment. (That was one of the
> many failure modes for 6to4, which is why the only safe approach was
> to use 1280 always.) 
A compliant IPv6 source can send 1500 byte packets that a source without
PMTUD, which would need to be fragmented based on the assumption that
the path MTU is at its required minimum of 1280.

A compliant IPv6 source can send larger packets, which would work if the
receiver supported larger reassembly limits than 1500. There is no
currently standard mechanism to determine the receiver reassembly limit
in IPv6, but this IS supported in TCP.

Joe

___
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

[Brian E Carpenter]

On 16/02/2017 10:12, Joe Touch wrote:
> Brian (et al.),
> 
> 
> On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>>> 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
> PMTUD is an optimization to avoid fragmentation.
> 
> Without it, you use fragmentation (which has overheads and other
> consequences, notably for IPv4).

In IPv6, you don't even know you *need* fragmentation without PMTUD,
since only the source is allowed to fragment. (That was one of the
many failure modes for 6to4, which is why the only safe approach was
to use 1280 always.) 

> However, it is only *with* PMTUD (and ICMP blocking) that you get black
> holes.

True for v4.

   Brian

___
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

[Joe Touch]

Brian (et al.),


On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>> 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
PMTUD is an optimization to avoid fragmentation.

Without it, you use fragmentation (which has overheads and other
consequences, notably for IPv4).

However, it is only *with* PMTUD (and ICMP blocking) that you get black
holes.

Joe
___
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

[Joe Touch]

Hi, Ole,


On 2/14/2017 10:33 AM, otr...@employees.org wrote:
>> *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).
I'm in the process of revising draft-intarea-tunnels to make this more
clear, as well as to provide a TSV ART review of this doc, but in preface:

There are two IPv6 minimum sizes: link MTU of 1280 and EMTU_R of 1500.

Support for source fragmentation and the difference between these two
values is what gives space for tunnel headers.

No amount of link MTU management can ever avoid source fragmentation
without violating the link MTU minimums in RFC2460.

Joe
___
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,

> *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

[Suresh Krishnan]

> On Feb 14, 2017, at 2:14 PM, otr...@employees.org wrote:
> 
> Stewart,
> 
> 
>> Maybe we could sort this out faster with a short phone call.
> 
> Yes, we can certainly do that!

Let me know if you would like me to call in as well. 

Thanks
Suresh

smime.p7s
Description: S/MIME cryptographic signature
___
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 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

[otroan]

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.

Pick your poison.

Best regards,
Ole



signature.asc
Description: Message signed with OpenPGP
___
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

[otroan]

Stewart,


> Maybe we could sort this out faster with a short phone call.

Yes, we can certainly do that!

> As I read the spec it says hunt for a new upper  limit every 10 mins, won't 
> there be packet as it sends out oversized packets looking for a higher MTU?

Yes.

Best regards,
Ole

> On 14/02/2017 18:33, otr...@employees.org wrote:
>> 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).
>> 
>>> 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



signature.asc
Description: Message signed with OpenPGP
___
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

[Fred Baker]

> On Feb 14, 2017, at 10:33 AM, otr...@employees.org wrote:
> 
>> *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).

I'm confused by that statement. https://tools.ietf.org/html/rfc7676#section-3.2 
indicates that a GRE tunnel on IPv6 and carrying an IPv6 payload works with a 
PMTU of 1280, and AFAIK it is among the larger tunnel headers. What tunnels 
does a PMTU of 1280 not work for?
___
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

[Stewart Bryant]

Ole

Maybe we could sort this out faster with a short phone call.

As I read the spec it says hunt for a new upper  limit every 10 mins, 
won't there be packet as it sends out oversized packets looking for a 
higher MTU?


Stewart


On 14/02/2017 18:33, otr...@employees.org wrote:

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


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

[otroan]

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

> 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


signature.asc
Description: Message signed with OpenPGP
___
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

[Stewart Bryant]

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 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 albei

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

[Stewart Bryant]

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.




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 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
si

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

[Stewart Bryant]

Hi Fred

Looks like a good point on RFC4821.

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.


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

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 <he...@pobox.com>
> Cc: 6man WG <i...@ietf.org>; IETF <i...@ietf.org>; Gen-ART 
> <gen-art@ietf.org>; Suresh Krishnan <suresh.krish...@gmail.com>;
> Stewart Bryant <stew...@g3ysx.org.uk>; 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

[Eggert, Lars]

Hi,

On 2017-2-11, at 7:42, Suresh Krishnan  wrote:
> How does this work for UDP?

See draft-ietf-tsvwg-rfc5405bis (which is in AUTH48), Section 3.2 "Message Size 
Guidelines".

Lars


signature.asc
Description: Message signed with OpenPGP
___
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

[otroan]

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

[...]

> 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





signature.asc
Description: Message signed with OpenPGP
___
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

[C. M. Heard]

On Fri, Feb 10, 2017 at 10:42 PM, Suresh Krishnan  wrote:

> On Feb 10, 2017 11:30 PM, "C. M. Heard"  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?
>

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.

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

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

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?
>

My apologies, I wrote that too hastily, before reading the complete change
log, which contains a description of what changed in each draft as the
document proceeded through the WG process. The comment that I should
have made is that many of those details are not useful to readers of an
archival document. Looking at a diff between RFC 1981 and this draft,
the substantive changes pretty much boil down to these:

  - In Section 1, added a reference to RFC4821 along with a short
summary of what it does.

  - In Section 4, added text to discard an ICMP Packet Too Big message
containing an MTU less than the IPv6 minimum link MTU and removed
the corresponding note specifying actions that were removed from
[I-D.ietf-6man-rfc2460bis].

  - In Section 5.2, removed text regarding RH0 (since it was deprecated
by RFC5095) and removed text 

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

[Suresh Krishnan]

Hi Mike,

On Feb 10, 2017 11:30 PM, "C. M. Heard"  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
___
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

[C. M. Heard]

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)

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

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

Mike Heard

___
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

[Brian E Carpenter]

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 

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

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

[Stewart Bryant]

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

___
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

[Brian E Carpenter]

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.

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

> 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?

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

I think your other comments are all valuable.

Regards
Brian

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

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

[Stewart Bryant]

Reviewer: Stewart Bryant
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Stewart Bryant
Review Date: 9/Feb/2017
IETF LC End Date: 1/Mar/2017
IESG Telechat date: unknown

Summary: This draft is on the right track but has open issues,
described in the review.

This review together with the lengthy discussion on the IETF list
suggest that this draft has a number of issues that need to be
addressed  before publication.

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?
 

Major issues:

Nits points out a number of faults with the document, but the only
one of substance is:

The text has a lot of RFC2119 language, but no RFC2119 declaration.

The document could use a thorough RFC2119 scrub

The document lists the three original authors one with an affiliation

change, but no email addresses. Has this been agreed with the
original
authors, and have arrangements been put in place for the RFC editor 
to process auth48?

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.

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.

==

   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.

==

  Note: if the original packet contained a Routing header, the
  Routing header should be used to determine the location of the
  destination address within the original packet.  If Segments
Left
  is equal to zero, the destination address is in the Destination
  Address field in the IPv6 header.  If Segments Left is greater
  than zero, the destination address is the last address
  (Address[n]) in the Routing header.

SB> So this has the effect that a traffic engineered packet and
SB> a non-traffic engineered packet will have the lower of the 
SB> two PMTUs. This was all harmless when source routing was a
curiosity
SB> as far as mainstream networking was concerned, but may be
SB> more of a problem as a result of the SPRING work.

===


5.3.  Purging stale PMTU information

   Internetwork topology is dynamic; routes change over time.  While
the
   local representation of a path may remain constant, the actual
   path(s) in use may change.  Thus, PMTU information cached by a
node
   can become stale.

   If the stale PMTU value is too large, this will be discovered
almost
   immediately once a large enough packet is sent on the path.  No
such
   mechanism exists for realizing that a stale PMTU value is too
small,
   so an implementation should "age" cached values.  When a PMTU
value
   has not been decreased for a while (on the order of 10 minutes),
the
   PMTU estimate should be set to the MTU of the first-hop link, and
the
   packetization layers should be notified of the change.  This will
   cause the complete Path MTU Discovery process to take place again.

SB> Should that be an RFC2119 SHOULD?
SB> The impact of this advice is going to be a disruption to what
might
SB> be a critical service every 10 mins.
SB> Should there be some advice along the lines of noting the 
SB> importance of service delivery as part of deciding whether to
SB> test for bigger PMTU vs improving efficiency?

===


Minor issues:

   IPv6 defines a standard mechanism for a node to discover the
   PMTU of an arbitrary path.

SB> Do you mean "This document defines ."? Otherwise this needs
SB> a reference.

===

   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer
Path
SB> Rather than have the reader figure out what "It" is, perhaps
SB>