[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: RE: [EXTERNAL] Re: [Last-Call] Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU
From: "Templin (US), Fred L" <Fred.L.Templin () boeing ! com>
Date: 2022-02-03 22:13:15
Message-ID: 1450e9b8bc6f4e29b6b9f59edc2c224c () boeing ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
Hi Joe,
> Why stop at 32 bits? They COULD expand to 128. Or 1024. Or more.
RFC4443 PTB stops at 32 bits and RFC2675 Jumbo Payload stops at 32bits.
So should this.
> If and when we ever get close to 64K, we could easily declare all 1's as indicating \
> the need for an extended value
IP parcels give a reason for link MTUs > 64K, and link designers will start to take \
note.
> IMO, let's not complicate things unnecessarily now.
I understand, but the problem is this document is reserving one of the few scarce HBH
option codes still available. And, once locked in at whatever MTU field size we agree
on it will be impossible to change in the future. It is not complicated to make the \
field sizes 32bits now, which would match RFCs 2675 and 4443.
Fred
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of touch@strayalpha.com
Sent: Thursday, February 03, 2022 1:47 PM
To: last-call@ietf.org
Cc: draft-ietf-6man-mtu-option@ietf.org; ipv6@ietf.org; IETF-Announce \
<ietf-announce@ietf.org>; 6man-chairs@ietf.org
Subject: [EXTERNAL] Re: [Last-Call] Last Call: <draft-ietf-6man-mtu-option-12.txt> \
(IPv6 Minimum Path MTU Hop-by-Hop Option) to Experimental RFC
Why stop at 32 bits? They COULD expand to 128. Or 1024. Or more.
Right now, anything above 1500 is a unicorn outside closed environments (e.g., data \
centers): https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf
A lot of the point of this option is to figure out what number below 1500 works - \
and/or when numbers even below those required for IPv6 minimums are needed.
If and when we ever get close to 64K, we could easily declare all 1's as indicating \
the need for an extended value.
IMO, let's not complicate things unnecessarily now.
Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>
On Feb 3, 2022, at 1:16 PM, Templin (US), Fred L \
<Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
I have a comment - section 5 ("IPv6 Minimum Path MTU Hop-by-Hop Option") sets
aside two 16-bit fields to record MTU values. This places an upper bound limit of
(2**16 - 1) octets on the MTU that can be recorded at each hop, but this will be
too small for IP parcels which can grow to (64 * (2**16 -1)) octets. And, if support
for true jumbos may be needed in the future the fields should probably permit sizes
up to (2**32 -1) octets which would require 32-bit fields.
Fred
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of The IESG
Sent: Thursday, January 27, 2022 4:38 PM
To: IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>
Cc: draft-ietf-6man-mtu-option@ietf.org<mailto:draft-ietf-6man-mtu-option@ietf.org>; \
ipv6@ietf.org<mailto:ipv6@ietf.org>; \
6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>
Subject: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU \
Hop-by-Hop Option) to Experimental RFC
EXT email: be mindful of links/attachments.
The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'IPv6 Minimum Path MTU Hop-by-Hop Option'
<draft-ietf-6man-mtu-option-12.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org<mailto:last-call@ietf.org> mailing lists by 2022-02-10. \
Exceptionally, comments may be sent to iesg@ietf.org<mailto:iesg@ietf.org> instead. \
In either case, please retain the beginning of the Subject line to allow automated \
sorting.
Abstract
This document specifies a new IPv6 Hop-by-Hop option that is used to
record the minimum Path MTU along the forward path between a source
host to a destination host. The recorded value can then be
communicated back to the source using the return Path MTU field in
the option.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/4567/
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
last-call mailing list
last-call@ietf.org<mailto:last-call@ietf.org>
https://www.ietf.org/mailman/listinfo/last-call
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:25060083;
mso-list-type:hybrid;
mso-list-template-ids:-915608676 2052738634 67698691 67698693 67698689 67698691 \
67698693 67698689 67698691 67698693;} @list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi \
Joe,<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">></span><span \
style="font-size:10.0pt"> Why stop at 32 bits? They COULD expand to 128. Or 1024. Or \
more.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">RFC4443 \
PTB stops at 32 bits and RFC2675 Jumbo Payload stops at 32bits.<o:p></o:p></span></p> \
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So \
should this.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">></span><span \
style="font-size:10.0pt"> If and when we ever get close to 64K, we could easily \
declare all 1's as indicating the need for an extended value<o:p></o:p></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt;color:#002060">IP parcels give a \
reason for link MTUs > 64K, and link designers will start to take \
note.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:10.0pt"><o:p> </o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">></span><span \
style="font-size:10.0pt"> IMO, let's not complicate things unnecessarily \
now.<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I \
understand, but the problem is this document is reserving one of the few scarce \
HBH<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">option \
codes still available. And, once locked in at whatever MTU field size we \
agree<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">on \
it will be impossible to change in the future. It is not complicated to make the \
field<o:p></o:p></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">sizes \
32bits now, which would match RFCs 2675 and 4443.<o:p></o:p></span></p> <p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Fred<o:p></o:p></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span \
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> ipv6 \
[mailto:ipv6-bounces@ietf.org] <b>On Behalf Of </b>touch@strayalpha.com<br>
<b>Sent:</b> Thursday, February 03, 2022 1:47 PM<br>
<b>To:</b> last-call@ietf.org<br>
<b>Cc:</b> draft-ietf-6man-mtu-option@ietf.org; ipv6@ietf.org; IETF-Announce \
<ietf-announce@ietf.org>; 6man-chairs@ietf.org<br> <b>Subject:</b> [EXTERNAL] \
Re: [Last-Call] Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum \
Path MTU Hop-by-Hop Option) to Experimental RFC<o:p></o:p></span></p> </div>
</div>
<p class="MsoNormal"><span \
style="font-size:10.0pt;color:#1F497D"><o:p> </o:p></span></p> <p \
class="MsoNormal"><span style="font-size:10.0pt">Why stop at 32 bits? They COULD \
expand to 128. Or 1024. Or more.<o:p></o:p></span></p> <div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Right now, anything above 1500 is \
a unicorn outside closed environments (e.g., data centers):<o:p></o:p></span></p> \
</div> <div>
<p class="MsoNormal"><span style="font-size:10.0pt"><a \
href="https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf \
">https://tma.ifip.org/2018/wp-content/uploads/sites/3/2018/06/tma2018_paper57.pdf</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">A lot of the point of this option \
is to figure out what number below 1500 works - and/or when numbers even below those \
required for IPv6 minimums are needed.<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">If and when we ever get close to \
64K, we could easily declare all 1's as indicating the need for an extended \
value.<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">IMO, let's not complicate things \
unnecessarily now.<o:p></o:p></span></p> </div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">Joe<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span \
style="font-size:10.0pt;color:black">—<o:p></o:p></span></p> <div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:black">Joe Touch, temporal \
epistemologist<o:p></o:p></span></p> <div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:black"><a \
href="http://www.strayalpha.com">www.strayalpha.com</a><o:p></o:p></span></p> </div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">On Feb 3, 2022, at 1:16 PM, \
Templin (US), Fred L <<a \
href="mailto:Fred.L.Templin@boeing.com">Fred.L.Templin@boeing.com</a>> \
wrote:<o:p></o:p></span></p> </div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt">I have a comment - section 5 \
("IPv6 Minimum Path MTU Hop-by-Hop Option") sets<br> aside two 16-bit \
fields to record MTU values. This places an upper bound limit of<br> (2**16 - \
1) octets on the MTU that can be recorded at each hop, but this will be<br> too small \
for IP parcels which can grow to (64 * (2**16 -1)) octets. And, if support<br> for \
true jumbos may be needed in the future the fields should probably permit sizes<br> \
up to (2**32 -1) octets which would require 32-bit fields.<br> <br>
Fred<br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:10.0pt">-----Original Message-----<br>
From: ipv6 [<a href="mailto:ipv6-bounces@ietf.org">mailto:ipv6-bounces@ietf.org</a>] \
On Behalf Of The IESG<br>
Sent: Thursday, January 27, 2022 4:38 PM<br>
To: IETF-Announce <<a \
href="mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a>><br>
Cc: <a href="mailto:draft-ietf-6man-mtu-option@ietf.org">draft-ietf-6man-mtu-option@ietf.org</a>;
<a href="mailto:ipv6@ietf.org">ipv6@ietf.org</a>; <a \
href="mailto:6man-chairs@ietf.org"> 6man-chairs@ietf.org</a><br>
Subject: Last Call: <draft-ietf-6man-mtu-option-12.txt> (IPv6 Minimum Path MTU \
Hop-by-Hop Option) to Experimental RFC<br> <br>
EXT email: be mindful of links/attachments.<br>
<br>
<br>
<br>
<br>
The IESG has received a request from the IPv6 Maintenance WG (6man) to<br>
consider the following document: - 'IPv6 Minimum Path MTU Hop-by-Hop Option'<br>
<draft-ietf-6man-mtu-option-12.txt> as Experimental RFC<br>
<br>
The IESG plans to make a decision in the next few weeks, and solicits final<br>
comments on this action. Please send substantive comments to the<br>
<a href="mailto:last-call@ietf.org">last-call@ietf.org</a> mailing lists by \
2022-02-10. Exceptionally, comments may<br> be sent to <a \
href="mailto:iesg@ietf.org">iesg@ietf.org</a> instead. In either case, please retain \
the beginning<br> of the Subject line to allow automated sorting.<br>
<br>
Abstract<br>
<br>
<br>
This document specifies a new IPv6 Hop-by-Hop option that is used to<br>
record the minimum Path MTU along the forward path between a source<br>
host to a destination host. The recorded value can then be<br>
communicated back to the source using the return Path MTU field in<br>
the option.<br>
<br>
<br>
<br>
<br>
The file can be obtained via<br>
<a href="https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/">https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/</a><br>
<br>
<br>
The following IPR Declarations may be related to this I-D:<br>
<br>
<a href="https://datatracker.ietf.org/ipr/4567/">https://datatracker.ietf.org/ipr/4567/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href="mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a \
href="https://www.ietf.org/mailman/listinfo/ipv6">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:10.0pt"><br>
-- <br>
last-call mailing list<br>
<a href="mailto:last-call@ietf.org">last-call@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/last-call">https://www.ietf.org/mailman/listinfo/last-call</a><o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--===============4582090074170613163==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic