new

Joe,

My apologies: my comments were probably misleading. Certainly, this
document is simply RFC1981 to Std, and hence recommending RFC4821 would
be kind of ou of scope, here.

That say, one might wonder to what extent, and for the general Internet,
RFC1981 can be considered succesful (given the filtering of ICMP
messages). -- i.e., at this point in time you wouldn't rely on RFC1981
(icmp-based pmtud) for path-mtu discovery.

What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years.

While I'm all in favour of PLMTUD. It doesn't seem like a complete solution.
PMTUD on the other hand supports all protocols on top of IP.

If by "supports" you mean "doesn't work", then yes. That's why we now
have PLPMTUD.

PLMTUD is unfortunately not a (complete) replacement of PMTUD.
Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example.

See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2

(yes, that doc has expired while we're preparing the 04 update, which
should be issued shortly)

Is this the paragraph you are referring to?

   PLPMTUD requires a separate,
   direct control channel from the egress to the ingress that provides
   positive feedback; the direct channel is not blocked by policy
   filters and the positive feedback ensures fail-safe operation if
   feedback messages are lost [RFC4821].
I'm very much in favour of working on better ways of doing Path MTU discovery.
A blanket statement of "use "PLMTUD" seems very premature though.
   An extension to Path MTU Discovery defined in this document can be
   found in [RFC4821].  It defines a method for Packetization Layer Path
   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
   ICMP messages to a host is not assured.

RFC1981 has 70 citations:
http://www.arkko.com/tools/allstats/citations-rfc1981.html

Could you expand on your view of how this pertains to advancing RFC1981?

Dear Authors,
I am requesting your clarification regarding usage of Adj-SID in SRH h=
eader.

As per draft, the segment list  is the list of 128 bit IPv6 addre=
ss.
Whether it means it is global ipv6 address or can be link local addres=
s also.
As per “OSPFv3 Extensions for Segm=
ent Routing” draft, the Adj-SID can be link local address.
In section 7.1,

    0   &nbs=
p;            &=
nbsp;  1          &n=
bsp;        2    &nb=
sp;            =
  3
    0 1 2 3 4 5 6 7 8 9 0 1=
 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+
   |    &nbs=
p;          Type  &n=
bsp;         |   &nb=
sp;          Length  =
;         |
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+
   | Flags   &nbs=
p;     |     Weight  &nbs=
p; |            =
; Reserved          |
   +-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+
   |    &nbs=
p;            &=
nbsp; SID/Label/Index (variable)       &=
nbsp;          |
   +------------------------=
---------------------------------------+

Examples:

       =
     A 32 bit global index defining the offset in the S=
ID/Label
       =
     space advertised by this router - in this case the=
 V and L
       =
     flags MUST NOT be set.

       =
     A 24 bit local label where the 20 rightmost bits a=
re used
       =
     for encoding the label value - in this case the V =
and L
       =
     flags MUST be set.

       =
     16 octet IPv6 address - in this case the V-flag MU=
ST be set.
       =
     The L-flag MUST be set for link-local IPv6 addr=
ess and MUST
       =
     NOT be set for IPv6 global unicast address.

If Link local address is Link local, how we can use this address in SR=
H header, 
since IPv6 destination address should not be link local address as per=
 IPv6 protocol.

If Adj-Sid is global ipv6 address, means we need to consider “gl=
obal ipv6 interface address” of the neighbor on the link?<=
/pre>

Regards,
Veerendranath

Dear Authors,
I am requesting your clarification regarding usage of Adj-SID in SRH h=
eader.
=C2=A0
As per draft, the segment list =C2=A0is the list of 128 bit IPv6 addre=
ss.
Whether it means it is global ipv6 address or can be link local addres=
s also.
As per =E2=80=9COSPFv3 Extensions for Se=
gment Routing=E2=80=9D draft, the Adj-SID can be link local address.=

In section 7.1,
=C2=A0

=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 3
=C2=A0=C2=A0=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1=
 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Type=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Length=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0 | Flags=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 Weight=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Reserved=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 SID/Label/Index (variable)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 +----------------------------=
-----------------------------------+
=C2=A0
Examples:
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 A 32 bit global index defining the offset in the S=
ID/Label
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 space advertised by this router - in this case the=
 V and L
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 flags MUST NOT be set.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =C2=A0=C2=A0=C2=A0=C2=A0A 24 bit local label where the 20 rightmost bits a=
re used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 for encoding the label value - in this case the V =
and L
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 flags MUST be set.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 16 octet IPv6 address - in this case the V-flag MU=
ST be set.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 The L-flag MUST be set for link-local IPv6 addr=
ess and MUST
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 NOT be set for IPv6 global unicast address.=

=C2=A0
If Link local address is Link local, how we can use this address in SR=
H header, 
since IPv6 destination address should not be link local address as per=
 IPv6 protocol.

=C2=A0
If Adj-Sid is global ipv6 address, means we need to consider =E2=80=9C=
global ipv6 interface address=E2=80=9D of the neighbor on the link?<=
u>
=C2=A0
Regards,
Veerendranath
=C2=A0

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links.
*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).

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
Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Joe Touch
Review Date: February 15, 2017
IETF LC End Date: March 3, 2017
IESG Telechat date: February 28, 2017

Review result: significant issues

NOTE: some of this review is informed by tracking some of the issues raised by others on the IETF list, notably Gorry Fairhurst.

Major issues:

1) the current text is insufficiently realistic about the (in)ability of this mechanism to operate in current networks, regardless of the support for generating ICMPs at routers or PMTUD support at endpoints, due to ICMP filtering for security reasons. [this comment is already being addressed by consensus text]

2) the current text is insufficiently clear on on the difference between the path MTU, which determines the largest supported IPv6 fragment, vs. the effective MTU to receive (EMTU_R), which determines the largest IP packet that can transit between the source and destination. The document should be more explicit throughput about its goal being to manage or avoid IPv6 source fragmentation rather than about source to destination packet maximums, and in specific in clearly referring to maximum fragments or atomic packets rather than maximum packets.

E.g.: see the following text, which is incorrect in its current form:
   Nodes not implementing Path MTU Discovery use the IPv6 minimum link
   MTU defined in [I-D.ietf-6man-rfc2460bis] as the maximum packet size.

The value used by either Path MTU Discovery or its default represents the path MTU, which is the largest IPv6 *fragment* (or atomic packet, see RFC6864) that can be supported on the path between the endpoints. The maximum IP packet size is limited by the effective MTU to receive (EMTU_R) [RFC1122], which is at least 1500 bytes for IPv6 and not necessarily related to the link MTUs. The text should also clearly indicate that there is no ICMP mechanism for determining larger EMTU_R support.

E.g., the following text is also incorrect in its current form:
   The value sent in the TCP MSS option is independent of the PMTU.
   This MSS option value is used by the other end of the connection,
   which may be using an unrelated PMTU value. 

The first sentence is correct because TCP MSS is related to EMTU_R (and needs to account for headers, as per RFC6691), and EMTU_R is not directly related to the PMTU (except that it would never be smaller than the PMTU). The MSS option is calculated from EMTU_R, not PMTU.

In addition, it should be noted that ICMPv6 PTB messages are NOT sent when source fragmentation is enabled.

3. need verification of current support for some features, esp. regarding TCP and NFS interactions
See Gorry's note of 2/14/17

4. the concept of a single path MTU value between two IP addresses does not account for multipath routing, e.g., ECMP (as currently deployed, noted in RFC7690, which should be cited) or BANANA (and its solutions in development) See Fred Templin's posts on this on 2/15/17

Minor issues:

- some of the updates and/or current text could be updated to reflect current terminology or practice. See Gorry Fairhursts's post of 2/14/17

- fragmentation, while considered harmful and costly, is absolutely necessary to support tunnels even in the presence of PMTUD. The text on this issue should reflect this reality.

- the requirement that transports be notified of PTB messages might usefully cite the corresponding IPv4, TCP, and UDP sections of RFC1122

- section 5.4 should cite and include context from RFC6691, especially including a discussion of the impact of variable IP EHs on the interaction between TCP MSS and ICMP PTB

--

Document: draft-ietf-6man-rfc1981bis-04
Reviewer: Joe Touch
Review Date: February 15, 2017
IETF LC End Date: March 3, 2017
IESG Telechat date: February 28, 2017

Review result: significant issues