Re: New Version: draft-ietf-tsvwg-rfc6040update-shim-01
Bob Briscoe <[email protected]> Tue, 30 May 2017 23:42:03 +0100
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1704015187065745074==
Content-Type: multipart/alternative;
boundary="------------D67289CC16037EEECB3751CA"
Content-Language: en-GB
This is a multi-part message in MIME format.
--------------D67289CC16037EEECB3751CA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi l2tpext list,
This is a plea for help on a short subsection of a short draft that
updates L2TP (amongst other tunnel protocols).
In the Transport Area WG (tsvwg) we have been working on defining
propagation of the ECN field between IP headers separated by shim header(s):
draft-ietf-tsvwg-rfc6040update-shim
L2TP is one such protocol (when the payload of the L2 protocol is IP,
and the outer PSN is IP). This is particularly relevant at the moment,
because of the low latency (L4S) work based on ECN and because
deployment of ECN has finally taken off {Note 1}.
I presented this tunnelling work in intarea just under a year ago. Since
then tsvwg has adopted the draft and asked that we include specific
update text for each affected tunnel protocol. I just posted my first
attempt at L2TP update text:
draft-ietf-tsvwg-rfc6040update-shim-01
<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01>
*Specific questions:**
*
Prize for the best answer to all 3 questions: you get to become a
co-author (if you want :)
*Q1.* L2TP is meant for all sorts of outers and inners, so it is not
clear where to define behaviour for the special (but very common) case
of IP as the L2 payload and IP and as the PSN. That is:
IP : [UDP] : L2TP : L2-specific-sublayer :
L2 : IP
I decided on updating S.4.5 of RFC3931 <Specific%20questions:>, but
suggestions for a better place are welcome.
*
**Q2**.* L2TP is usually extended not updated. However, in this case,
compliance with RFC6040 is non-optional, so I think update rather than
extension is appropriate. Reason: Although RFC6040 is non-optional it
includes a compatibility mode that defines what has to happen when a
tunnel endpoint doesn't support ECN propagation.
Pls read the (short) draft and, if you disagree, suggest how an
extension can be non-optional.
*
**Q3.* The tunnel initiator needs to check that the other end supports
ECN propagation. I have proposed an Attribute Value Pair (AVP) for this
that is effectively just a boolean choice from each end (Yes or
silence). I expected to find an AVP with per-control-connection flags
for tunnel endpoint capabilities that I could just extend with one more
flag, but there doesn't seem to be such a thing already in L2TP. Did I
miss it?
Cheers
Bob
{Note 1}: ~70% of Web servers, ~50% of Apple client devices on fixed or
WiFi access, and now increasing router deployment of ECN is appearing.
On 30/05/17 22:49, Bob Briscoe wrote:
> David (as doc shepherd) and the tsvwg list,
>
> As requested, I have added specific text that updates the other
> relevant RFCs under IETF change control (GRE and L2TP). I have also
> explained the position in each case for specs not under IETF change
> control.
>
> I will now go to the relevant WGs (intarea and lt2pext) and ask them
> to improve my first attempt.
>
> I'll cc you and this list as appropriate.
>
> Cheers
>
>
>
> Bob
>
> PS. I have also said
>
> the rules in [RFC6040] for
> propagating the ECN field MUST be applied
>
> whereas before it said "SHOULD". And added an explanation for why
> "MUST" is appropriate:
>
> The above is written as a 'MUST' because RFC 6040 allows
> a compatibility mode for the encapsulator in cases where the
> decapsulator does not (or cannot) support ECN propagation.
>
>
>
>
>
>
> On 30/05/17 22:36, [email protected] wrote:
>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> has been successfully submitted by Bob Briscoe and posted to the
>> IETF repository.
>>
>> Name: draft-ietf-tsvwg-rfc6040update-shim
>> Revision: 01
>> Title: Propagating Explicit Congestion Notification Across IP
>> Tunnel Headers Separated by a Shim
>> Document date: 2017-05-30
>> Group: tsvwg
>> Pages: 10
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>> Htmlized:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>>
>> Abstract:
>> RFC 6040 on "Tunnelling of Explicit Congestion Notification" made
>> the
>> rules for propagation of ECN consistent for all forms of IP in IP
>> tunnel. This specification extends the scope of RFC 6040 to include
>> tunnels where two IP headers are separated by at least one shim
>> header that is not sufficient on its own for packet forwarding.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
--------------D67289CC16037EEECB3751CA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi l2tpext list,<br>
<br>
This is a plea for help on a short subsection of a short draft that
updates L2TP (amongst other tunnel protocols).<br>
<br>
In the Transport Area WG (tsvwg) we have been working on defining
propagation of the ECN field between IP headers separated by shim
header(s):<br>
draft-ietf-tsvwg-rfc6040update-shim<br>
<br>
L2TP is one such protocol (when the payload of the L2 protocol is
IP, and the outer PSN is IP). This is particularly relevant at the
moment, because of the low latency (L4S) work based on ECN and
because deployment of ECN has finally taken off {Note 1}.<br>
<br>
I presented this tunnelling work in intarea just under a year ago.
Since then tsvwg has adopted the draft and asked that we include
specific update text for each affected tunnel protocol. I just
posted my first attempt at L2TP update text:<br>
<a moz-do-not-send="true"
href="https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01">draft-ietf-tsvwg-rfc6040update-shim-01</a><br>
<br>
<b>Specific questions:</b><b><br>
</b><br>
Prize for the best answer to all 3 questions: you get to become a
co-author (if you want :)<br>
<br>
<b>Q1.</b> L2TP is meant for all sorts of outers and inners, so it
is not clear where to define behaviour for the special (but very
common) case of IP as the L2 payload and IP and as the PSN. That is:<br>
IP : [UDP] : L2TP : L2-specific-sublayer
: L2 : IP<br>
<br>
I decided on updating <a moz-do-not-send="true"
href="Specific%20questions:">S.4.5 of RFC3931</a>, but suggestions
for a better place are welcome.<br>
<b><br>
</b><b>Q2</b><b>.</b> L2TP is usually extended not updated. However,
in this case, compliance with RFC6040 is non-optional, so I think
update rather than extension is appropriate. Reason: Although
RFC6040 is non-optional it includes a compatibility mode that
defines what has to happen when a tunnel endpoint doesn't support
ECN propagation. <br>
<br>
Pls read the (short) draft and, if you disagree, suggest how an
extension can be non-optional.<br>
<b><br>
</b><b>Q3.</b> The tunnel initiator needs to check that the other
end supports ECN propagation. I have proposed an Attribute Value
Pair (AVP) for this that is effectively just a boolean choice from
each end (Yes or silence). I expected to find an AVP with
per-control-connection flags for tunnel endpoint capabilities that I
could just extend with one more flag, but there doesn't seem to be
such a thing already in L2TP. Did I miss it?<br>
<br>
<br>
Cheers<br>
<br>
<br>
Bob<br>
<br>
{Note 1}: ~70% of Web servers, ~50% of Apple client devices on fixed
or WiFi access, and now increasing router deployment of ECN is
appearing.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 30/05/17 22:49, Bob Briscoe wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">David
(as doc shepherd) and the tsvwg list,
<br>
<br>
As requested, I have added specific text that updates the other
relevant RFCs under IETF change control (GRE and L2TP). I have
also explained the position in each case for specs not under IETF
change control.
<br>
<br>
I will now go to the relevant WGs (intarea and lt2pext) and ask
them to improve my first attempt.
<br>
<br>
I'll cc you and this list as appropriate.
<br>
<br>
Cheers
<br>
<br>
<br>
<br>
Bob
<br>
<br>
PS. I have also said
<br>
<br>
the rules in [RFC6040] for
<br>
propagating the ECN field MUST be applied
<br>
<br>
whereas before it said "SHOULD". And added an explanation for why
"MUST" is appropriate:
<br>
<br>
The above is written as a 'MUST' because RFC 6040 allows
<br>
a compatibility mode for the encapsulator in cases where the
<br>
decapsulator does not (or cannot) support ECN propagation.
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 30/05/17 22:36, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:
<br>
<blockquote type="cite">A new version of I-D,
draft-ietf-tsvwg-rfc6040update-shim-01.txt
<br>
has been successfully submitted by Bob Briscoe and posted to the
<br>
IETF repository.
<br>
<br>
Name: draft-ietf-tsvwg-rfc6040update-shim
<br>
Revision: 01
<br>
Title: Propagating Explicit Congestion Notification
Across IP Tunnel Headers Separated by a Shim
<br>
Document date: 2017-05-30
<br>
Group: tsvwg
<br>
Pages: 10
<br>
URL:
<a class="moz-txt-link-freetext" href="https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt">https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt</a><br>
Status:
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/">https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/</a>
<br>
Htmlized:
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01">https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01</a>
<br>
Htmlized:
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01">https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01</a><br>
Diff:
<a class="moz-txt-link-freetext" href="https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01">https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01</a>
<br>
<br>
Abstract:
<br>
RFC 6040 on "Tunnelling of Explicit Congestion Notification"
made the
<br>
rules for propagation of ECN consistent for all forms of IP
in IP
<br>
tunnel. This specification extends the scope of RFC 6040 to
include
<br>
tunnels where two IP headers are separated by at least one
shim
<br>
header that is not sufficient on its own for packet
forwarding.
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time
of submission
<br>
until the htmlized version and diff are available at
tools.ietf.org.
<br>
<br>
The IETF Secretariat
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
________________________________________________________________
Bob Briscoe <a class="moz-txt-link-freetext" href="http://bobbriscoe.net/">http://bobbriscoe.net/</a></pre>
</body>
</html>
--------------D67289CC16037EEECB3751CA--
--===============1704015187065745074==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
L2tpext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/l2tpext
--===============1704015187065745074==--