Re: Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN
"Carlos Pignataro (cpignata)" <[email protected]> Wed, 31 May 2017 16:44:28 +0000
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <[email protected]> |
--===============6553722146479087359== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_B00A68856EB143618412C408F23DC5E0ciscocom_" --_000_B00A68856EB143618412C408F23DC5E0ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, inclu= ding of course IP) and runs over UDP. In contrast, L2TPv3 transports direct= ly 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 nee= ds 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 complia= nt 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 protected]<mailto:ietf@= bobbriscoe.net>> wrote: Ignacio, Thanks for your rapid response. On 31/05/17 02:51, Ignacio Goyret wrote: I am a little confused by the double negative in "non-optional". Do you mean "mandatory"? If so, why not just say that? Yes, mandatory. That language was not in the draft; only in my email. 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. Good. 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 th= e forwarded payload protocol. Otherwise explicit congestion signals added b= y a node within the tunnel could just get stripped at decap. With congestio= n 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 al= l the combinations of the two 2-bit ECN codepoints). So I am interested to = know whether this might present problems for L2TP implementations (ECN prop= agation on decap has been implemented OK in Linux for similar structures li= ke 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 incremen= tal deployment problem. 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. * Given you say L2TPv2 is more complicated cos it transports PPP packets, t= hat 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 -Ignacio At 15:49 5/30/2017, Bob Briscoe wrote: Hi l2tpext list, [repeating previous post, but with self-explanatory subject line] 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 propagati= on 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 t= he outer PSN is IP). This is particularly relevant at the moment, because o= f 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 th= en tsvwg has adopted the draft and asked that we include specific update te= xt for each affected tunnel protocol. I just posted my first attempt at L2T= P update text: <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01>draf= t-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 wh= ere 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 suggesti= ons 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 a= ppropriate. Reason: Although RFC6040 is non-optional it includes a compatib= ility mode that defines what has to happen when a tunnel endpoint doesn't s= upport ECN propagation. Pls read the (short) draft and, if you disagree, suggest how an extension c= an be non-optional. Q3. The tunnel initiator needs to check that the other end supports ECN pro= pagation. I have proposed an Attribute Value Pair (AVP) for this that is ef= fectively just a boolean choice from each end (Yes or silence). I expected = to find an AVP with per-control-connection flags for tunnel endpoint capabi= lities 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 WiF= i access, and now increasing router deployment of ECN is appearing. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ _______________________________________________ L2tpext mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/l2tpext --_000_B00A68856EB143618412C408F23DC5E0ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body dir=3D"auto"> <div><span></span></div> <div> <div>Hi, Bob,</div> <div><br> </div> <div>Adding on a couple of bits on top of Ignacio's response. <br> <br> L2TPv2, RFC 2661, transports only PPP (and multi protocols within it, inclu= ding of course IP) and runs over UDP. In contrast, L2TPv3 transports direct= ly 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. </div> <div><br> </div> <div>By the way you can find example of capabilities in subsections of Sect= ion 5.1.1 of <a href=3D"https://tools.ietf.org/html/draft-ietf-l2tpext= -l2tp-ppp-08">https://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-08</a= ></div> <div><br> </div> <div>I do not understand however why "Update", or what that impli= es to a compliant implementation. Many features of L2TP are specified in va= rious WGs, not "Updating" the base specs. </div> <div><br> </div> <div>Thanks,<br> <br> <div>Sent from my iPad</div> </div> <div><br> On May 30, 2017, at 10:48 PM, Bob Briscoe <<a href=3D"mailto:ietf@bobbri= scoe.net">[email protected]</a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div><span>Ignacio,</span><br> <span></span><br> <span>Thanks for your rapid response.</span><br> <span></span><br> <span>On 31/05/17 02:51, Ignacio Goyret wrote:</span><br> <blockquote type=3D"cite"><span>I am a little confused by the double negati= ve in "non-optional".</span><br> </blockquote> <blockquote type=3D"cite"><span>Do you mean "mandatory"? If so, w= hy not just say that?</span><br> </blockquote> <span>Yes, mandatory.</span><br> <span>That language was not in the draft; only in my email.</span><br> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>The lack of a capabilities AVP that you wer= e looking for is mainly</span><br> </blockquote> <blockquote type=3D"cite"><span>because it hasn't been needed so far. You a= re welcome to submit a</span><br> </blockquote> <blockquote type=3D"cite"><span>draft with something like that. Generally s= peaking, adding a simple</span><br> </blockquote> <blockquote type=3D"cite"><span>binary AVP is easy and simpler to handle.</= span><br> </blockquote> <span>Good.</span><br> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>I have no problem with the new suggested AV= P, but can you explain</span><br> </blockquote> <blockquote type=3D"cite"><span>why is it important to know if the remote s= upports or not this</span><br> </blockquote> <blockquote type=3D"cite"><span>extension? Can't a tunnel end deduce this i= nformation by observing</span><br> </blockquote> <blockquote type=3D"cite"><span>the IP header received?</span><br> </blockquote> <span>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 i= nto the forwarded payload protocol. Otherwise explicit congestion signals a= dded by a node within the tunnel could just get stripped at decap. With congestion feedback black-holed, th= e load would continue to increase until overload and tail drop.</span><br> <span></span><br> <span>BTW, the forwarded ECN field after decap has to be a combination of t= he 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 interest= ed to know whether this might present problems for L2TP implementations (ECN propagation on decap has been imple= mented OK in Linux for similar structures like VXLAN).</span><br> <span></span><br> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>Regarding the extension vs update question:= if it is an update,</span><br> </blockquote> <blockquote type=3D"cite"><span>then why negotiate support? Wouldn't ECN pr= opagation be mandated</span><br> </blockquote> <blockquote type=3D"cite"><span>by this update?</span><br> </blockquote> <span>Unfortunately, a mandatory update still has to cope with the above in= cremental deployment problem.</span><br> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>There is no section for L2TPv2 (RFC2661) or= any further suggestion</span><br> </blockquote> <blockquote type=3D"cite"><span>on how to handle it. I'm not saying that it= is necessary, but since</span><br> </blockquote> <blockquote type=3D"cite"><span>it is mentioned earlier in the document, yo= u may want to add a few</span><br> </blockquote> <blockquote type=3D"cite"><span>words. Note that things are a bit more comp= licated in v2 because</span><br> </blockquote> <blockquote type=3D"cite"><span>it transports PPP packets, which may includ= e IP packets (or portions</span><br> </blockquote> <blockquote type=3D"cite"><span>of PPP packets if using Multilink). I have = no issue punting on L2TPv2</span><br> </blockquote> <blockquote type=3D"cite"><span>details.</span><br> </blockquote> <span>* Given you say L2TPv2 is more complicated cos it transports PPP pack= ets, that seems to imply that L2TPv3 does not transport PPP, which doesn't = sound right?</span><br> <span></span><br> <span>I don't fully understand the relationship between L2TPv2 & v3 (I = have come across L2TP a lot in an operational context, but never really stu= died it as a protocol until now).</span><br> <span></span><br> <span>* Is there still a lot of L2TPv2 around?</span><br> <span></span><br> <span>* Would it be believable that a L2TPv2 implementation might be update= d for ECN support but not updated to L2TPv3?</span><br> <span></span><br> <span>Cheers</span><br> <span></span><br> <span></span><br> <span>Bob</span><br> <span></span><br> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>-Ignacio</span><br> </blockquote> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>At 15:49 5/30/2017, Bob Briscoe wrote:</spa= n><br> </blockquote> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Hi l2tpext list,</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>[repeating previous post, but with self-exp= lanatory subject line]</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>This is a plea for help on a short subsecti= on of a short draft that updates L2TP (amongst other tunnel protocols).</sp= an><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>In the Transport Area WG (tsvwg) we have be= en working on defining propagation of the ECN field between IP headers sepa= rated by shim header(s):</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span> draft-ietf-tsvwg-rfc6040u= pdate-shim</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>L2TP is one such protocol (when the payload= of the L2 protocol is IP, and the outer PSN is IP). This is particularly r= elevant at the moment, because of the low latency (L4S) work based on ECN a= nd because deployment of ECN has finally taken off {Note 1}.</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>I presented this tunnelling work in intarea= just under a year ago. Since then tsvwg has adopted the draft and asked th= at we include specific update text for each affected tunnel protocol. I jus= t posted my first attempt at L2TP update text:</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span> <<a href=3D"https://to= ols.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01">https://tools.iet= f.org/html/draft-ietf-tsvwg-rfc6040update-shim-01</a>>draft-ietf-tsvwg-r= fc6040update-shim-01</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Specific questions:</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Prize for the best answer to all 3 question= s: you get to become a co-author (if you want :)</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Q1. L2TP is meant for all sorts of outers a= nd inners, so it is not clear where to define behaviour for the special (bu= t very common) case of IP as the L2 payload and IP and as the PSN. That is:= </span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span> IP &nbs= p;: [UDP] : L2TP &nbs= p; : L2-specific-sublayer : = L2 : IP</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>I decided on updating <Specific%20questi= ons:>S.4.5 of RFC3931, but suggestions for a better place are welcome.</= span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Q2. L2TP is usually extended not updated. H= owever, in this case, compliance with RFC6040 is non-optional, so I think u= pdate 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 suppor= t ECN propagation.</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Pls read the (short) draft and, if you disa= gree, suggest how an extension can be non-optional.</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Q3. The tunnel initiator needs to check tha= t the other end supports ECN propagation. I have proposed an Attribute Valu= e Pair (AVP) for this that is effectively just a boolean choice from each e= nd (Yes or silence). I expected to find an AVP with per-control-connection flags for tunnel endpoint capabili= ties 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?</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Cheers</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>Bob</span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span></span><br> </blockquote> </blockquote> <blockquote type=3D"cite"> <blockquote type=3D"cite"><span>{Note 1}: ~70% of Web servers, ~50% of Appl= e client devices on fixed or WiFi access, and now increasing router deploym= ent of ECN is appearing.</span><br> </blockquote> </blockquote> <span></span><br> <span>-- </span><br> <span>________________________________________________________________</spa= n><br> <span>Bob Briscoe &nb= sp; = <a href=3D"http://bobbrisco= e.net/">http://bobbriscoe.net/</a></span><br> <span></span><br> <span>_______________________________________________</span><br> <span>L2tpext mailing list</span><br> <span><a href=3D"mailto:[email protected]">[email protected]</a></span><br> <span><a href=3D"https://www.ietf.org/mailman/listinfo/l2tpext">https://www= .ietf.org/mailman/listinfo/l2tpext</a></span><br> </div> </blockquote> </div> </body> </html> --_000_B00A68856EB143618412C408F23DC5E0ciscocom_-- --===============6553722146479087359== 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 --===============6553722146479087359==--