Subject: Re: [L2tpext] New Version: draft-ietf-tsvwg-rfc6040update-shim-01

From: Bob Briscoe <[email-masked]>
Date: Tue, 30 May 2017 23:42:03 +0100

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-masked] 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/

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 30 May 2017 23:49:50 +0100

Hi l2tpext list,
[repeating previous post, but with self-explanatory subject line]

*Specific questions:**
*

Cheers

Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 30 May 2017 18:51:46 -0700

I am a little confused by the double negative in "non-optional".
Do you mean "mandatory"? If so, why not just say that?

The lack of a capabilities AVP that you were looking for is mainly
because it hasn't been needed so far. You are welcome to submit a
draft with something like that. Generally speaking, adding a simple
binary AVP is easy and simpler to handle.

I have no problem with the new suggested AVP, but can you explain
why is it important to know if the remote supports or not this
extension? Can't a tunnel end deduce this information by observing
the IP header received?

Regarding the extension vs update question: if it is an update,
then why negotiate support? Wouldn't ECN propagation be mandated
by this update?

There is no section for L2TPv2 (RFC2661) or any further suggestion
on how to handle it. I'm not saying that it is necessary, but since
it is mentioned earlier in the document, you may want to add a few
words. Note that things are a bit more complicated in v2 because
it transports PPP packets, which may include IP packets (or portions
of PPP packets if using Multilink). I have no issue punting on L2TPv2
details.

-Ignacio

At 15:49 5/30/2017, Bob Briscoe wrote:

>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):
>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:
>    <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01>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 <Specific%20questions:>S.4.5 of RFC3931, 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.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 31 May 2017 03:47:57 +0100

Ignacio,

Thanks for your rapid response.

> Do you mean "mandatory"? If so, why not just say that?
Yes, mandatory.
That language was not in the draft; only in my email.
> binary AVP is easy and simpler to handle.
Good.
> extension? Can't a tunnel end deduce this information by observing
I'm afraid not. It is critical for the ingress (in each direction) to 
check that the egress decap will correctly propagate the outer ECN field 
into the forwarded payload protocol. Otherwise explicit congestion 
signals added by a node within the tunnel could just get stripped at 
decap. With congestion feedback black-holed, the load would continue to 
increase until overload and tail drop.

BTW, the forwarded ECN field after decap has to be a combination of the 
ECN fields in the outer and inner IP headers (RFC6040 gives a 4x4 matrix 
of all the combinations of the two 2-bit ECN codepoints). So I am 
interested to know whether this might present problems for L2TP 
implementations (ECN propagation on decap has been implemented OK in 
Linux for similar structures like VXLAN).

> then why negotiate support? Wouldn't ECN propagation be mandated
Unfortunately, a mandatory update still has to cope with the above 
incremental deployment problem.
> of PPP packets if using Multilink). I have no issue punting on L2TPv2
* Given you say L2TPv2 is more complicated cos it transports PPP 
packets, that seems to imply that L2TPv3 does not transport PPP, which 
doesn't sound right?

I don't fully understand the relationship between L2TPv2 & v3 (I have 
come across L2TP a lot in an operational context, but never really 
studied it as a protocol until now).

* Is there still a lot of L2TPv2 around?

* Would it be believable that a L2TPv2 implementation might be updated 
for ECN support but not updated to L2TPv3?

Cheers

Bob

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 31 May 2017 16:44:28 +0000

Hi, Bob,

Adding on a couple of bits on top of Ignacio's response.

L2TPv2, RFC 2661, transports only PPP (and multi protocols within it, including of course IP) and runs over UDP. In contrast, L2TPv3 transports directly a variety of protocols (Ethernet, HDLC, etc.) and runs directly over IP protocol 115 or over UDP. RFC 3931 is the base L2TPv3 specification but needs a protocol companion document. Some of those protocols are finished, e.g. RFC 4719 but others like PPP or "raw" IP are in Internet-Drafts.

By the way you can find example of capabilities in subsections of Section 5.1.1 of https://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-08

I do not understand however why "Update", or what that implies to a compliant implementation. Many features of L2TP are specified in various WGs, not "Updating" the base specs.

Thanks,

Sent from my iPad

On May 30, 2017, at 10:48 PM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:

Ignacio,

I have no problem with the new suggested AVP, but can you explain
why is it important to know if the remote supports or not this
extension? Can't a tunnel end deduce this information by observing
the IP header received?
I'm afraid not. It is critical for the ingress (in each direction) to check that the egress decap will correctly propagate the outer ECN field into the forwarded payload protocol. Otherwise explicit congestion signals added by a node within the tunnel could just get stripped at decap. With congestion feedback black-holed, the load would continue to increase until overload and tail drop.

BTW, the forwarded ECN field after decap has to be a combination of the ECN fields in the outer and inner IP headers (RFC6040 gives a 4x4 matrix of all the combinations of the two 2-bit ECN codepoints). So I am interested to know whether this might present problems for L2TP implementations (ECN propagation on decap has been implemented OK in Linux for similar structures like VXLAN).

Regarding the extension vs update question: if it is an update,
then why negotiate support? Wouldn't ECN propagation be mandated
by this update?
Unfortunately, a mandatory update still has to cope with the above incremental deployment problem.

* Given you say L2TPv2 is more complicated cos it transports PPP packets, that seems to imply that L2TPv3 does not transport PPP, which doesn't sound right?

I don't fully understand the relationship between L2TPv2 & v3 (I have come across L2TP a lot in an operational context, but never really studied it as a protocol until now).

* Would it be believable that a L2TPv2 implementation might be updated for ECN support but not updated to L2TPv3?

Cheers

Bob

-Ignacio

Hi l2tpext list,

Specific questions:

Cheers

Bob

_______________________________________________
L2tpext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/l2tpext

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 31 May 2017 23:11:50 +0100

Carlos,

On 31/05/17 17:44, Carlos Pignataro (cpignata) wrote:
> L2TPv2, RFC 2661, transports only PPP (and multi protocols within it, 
> including of course IP) and runs over UDP. In contrast, L2TPv3 
> transports directly a variety of protocols (Ethernet, HDLC, etc.) and 
> runs directly over IP protocol 115 or over UDP. RFC 3931 is the base 
> L2TPv3 specification but needs a protocol companion document. Some of 
> those protocols are finished, e.g. RFC 4719 but others like PPP or 
> "raw" IP are in Internet-Drafts.
Yup, got all that. Thanks.

I just didn't understand the implication of Ignacio's email that 
updating the v2 protocol (that solely supports PPP) could be more 
complex than updating the v3 protocol that I thought supported PPP and 
many more protocols. It implied (to me) that maybe v3 doesn't support 
PPP in some way.

>
> By the way you can find example of capabilities in subsections of 
> Section 5.1.1 of 
> https://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-08
>
> I do not understand however why "Update", or what that implies to a 
> compliant implementation. Many features of L2TP are specified in 
> various WGs, not "Updating" the base specs.
By my understanding of the word extension, if a implementation that is 
compliant with RFC3931 does not implement an extension, it is still 
compliant with RFC3931. Is this how the word "extension" is used in L2TP 
land?

Whereas, if one IP header encapsulates another, if the ECN field were 
processed in any way other than RFC6040, it would be invalid (unless 
another RFC were written to update RFC6040). Therefore, whenever L2TP is 
tunnelling IP in IP, it is mandatory to comply with RFC6040. So I am 
asking the L2TPext WG for advice on how you guys would make a mandatory 
update to L2TP, rather than 'just' an optional extension.

Bob

>> check that the egress decap will correctly propagate the outer ECN 
>> field into the forwarded payload protocol. Otherwise explicit 
>> congestion signals added by a node within the tunnel could just get 
>> stripped at decap. With congestion feedback black-holed, the load 
>> would continue to increase until overload and tail drop.
>>
>> BTW, the forwarded ECN field after decap has to be a combination of 
>> the ECN fields in the outer and inner IP headers (RFC6040 gives a 4x4 
>> matrix of all the combinations of the two 2-bit ECN codepoints). So I 
>> am interested to know whether this might present problems for L2TP 
>> packets, that seems to imply that L2TPv3 does not transport PPP, 
>> which doesn't sound right?
>>
>> * Would it be believable that a L2TPv2 implementation might be 
>> updated for ECN support but not updated to L2TPv3?
>>
>> Cheers
>>
>>
>> Bob
>>
>>>
>>> -Ignacio
>>>
>>>
>>>> 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:
>>>> 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:
>>>> I decided on updating <Specific%20questions:>S.4.5 of RFC3931, but 
>>>> 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.
>>>>
>>>> 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.
>>
>> -- 
>> [email-masked] <mailto:[email-masked]>

---

From: Ignacio Goyret <[email-masked]>
Date: Wed, 31 May 2017 16:55:47 -0700

At 15:11 5/31/2017, Bob Briscoe wrote:

>>I do not understand however why "Update", or what that implies to
>>a compliant implementation. Many features of L2TP are specified in
>By my understanding of the word extension, if a implementation that
>is compliant with RFC3931 does not implement an extension, it is
>still compliant with RFC3931. Is this how the word "extension" is
>used in L2TP land?
>
>Whereas, if one IP header encapsulates another, if the ECN field
>were processed in any way other than RFC6040, it would be invalid
>(unless another RFC were written to update RFC6040). Therefore,
>whenever L2TP is tunnelling IP in IP, it is mandatory to comply
>with RFC6040. So I am asking the L2TPext WG for advice on how you
>guys would make a mandatory update to L2TP, rather than 'just' an
>optional extension.

I'm not sure you will get much traction for a "mandatory" update
because it would immediately invalidate any compliant deployed code
out there.

This goes back to the question of why negotiate it if it is mandatory.

Real life says that there will be some L2TP deployments that will
support ECN and some that won't, thus, the negotiation is needed
to maintain interoperability.

But if the negotiation is required, then this can't be an update
since it must allow for LCCEs that don't support ECN (which it must,
because some deployments may choose (or may have to) stay with
their non-ECN supporting code for a variety of reasons).

Yes, I know: it is sort of a circular argument but hopefully you
see what I mean.

-Ignacio

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 1 Jun 2017 05:02:00 +0100

Ignacio,

> because it would immediately invalidate any compliant deployed code
I'm not asking for permission to make something mandatory. RFC6040 (or 
its predecessors {Note 1}) is already mandatory.
draft-ietf-tsvwg-rfc6040update-shim is just the "messenger", telling 
L2TP implementers that RFC6040 is already mandatory.

A mandatory update wouldn't invalidate any compliant deployed code, 
because the only way that deployed code could be compliant would be to 
already comply with RFC6040 or its predecessors. There is no other RFC 
that says how to construct an ECN field during tunnelling. The standards 
track predecessors of RFC6040 pre-dated L2TPv3 by 3.5 years. And the 
experimental track predecessor of ECN tunnelling pre-dated L2TPv2.

The ECN field is in the main IP header (v4 and v6). It cannot be 
omitted. When an L2TPv3 implementation creates an outer IP header during 
encap, or forwards an IP header after decap, it has to set the new ECN 
fields to some value. One would hope that an implementer would try to 
find a spec to follow, rather than guessing this value. There is only 
one RFC that says how to construct the ECN field during tunnelling 
(RFC6040 or its predecessors). If an implementer has not complied with 
one of these, she has not complied with the Internet Protocol.

draft-ietf-tsvwg-rfc6040update-shim is not changing the technical effect 
of the ECN tunnelling spec [RFC6040]. All it is really doing is:

a) Typing "Updates: 3931" at the top of a proposed RFC. This would 
ideally have been typed at the top of the original ECN RFC [RFC3168]. 
This flags to L2TP implementers that they need to take note of the 
standards track update to IP tunnelling that happened in 2001. Because, 
like you say, real life dictates there will be some L2TP implementations 
that don't do it right.

b) and helping to do it right, by providing the L2TP negotiation 
machinery (that is also already mandatory for any tunnelling of IP in IP).

{Note 1}: The predecessors of RFC6040 are RFC3168 and RFC4301. They all 
have the same technical effect - the deltas between them  merely altered 
trivia like handling combinations of ECN fields that wouldn't normally 
be expected and other tinkering round the edges.

> This goes back to the question of why negotiate it if it is mandatory.

The standards action that is mandatory is compliance with RFC6040, which 
made it mandatory to negotiate (or use configuration).

Specifically, RFC6040 made it mandatory for a tunnel ingress to check 
for (or be configured for) whether the egress supported ECN decap. In 
the predecessors to RFC6040, negotiation was only specified for IPsec. 
The only other type of tunnel considered was an RFC2003 tunnel, where no 
negotiation of tunnel set up process had been defined, so negotiation 
wasn't discussed for that case.

> their non-ECN supporting code for a variety of reasons).

As above, the update is to make negotiation mandatory.

I hope this helps clarify.

Cheers

Bob