Re: Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN

Bob Briscoe <[email protected]> Wed, 14 Jun 2017 12:20:30 +0100
Newsgroups gmane.ietf.l2tpext
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============4747671195263767972==
Content-Type: multipart/alternative;
 boundary="------------B75EF603C5DE621DCD489FC7"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------B75EF603C5DE621DCD489FC7
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Ignacio,

On 31/05/17 02:51, Ignacio Goyret wrote:
> 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.
While going back over all the emails in this thread (I am writing up the 
next rev of the draft), the above point raised a couple of questions in 
my mind:

Q1. When you say "portions" of IP packets, does L2TPv2 fragmented these 
as per IP fragmentation so that each 'portion' has an IP header, or are 
they carved up in a PPP-specific way without IP headers on each?

Q2. Does L2TPv3 support PPP in the same way?

Q3. Are there other L2 protocols currently supported by L2TPv3 that can 
carve up IP packets so that there will not be an IP header at the start 
of each payload?

If framing boundaries might be different, I will need to refer to 
section 5.6 of draft-ietf-tsvwg-ecn-encap-guidelines 
<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-08#section-5.6> 
"Reframing and Congestion Markings", but I don't want to add complexity 
if it is not necessary.

Cheers


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--------------B75EF603C5DE621DCD489FC7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Ignacio,<br>
    <br>
    <div class="moz-cite-prefix">On 31/05/17 02:51, Ignacio Goyret
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="">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.</pre>
    </blockquote>
    While going back over all the emails in this thread (I am writing up
    the next rev of the draft), the above point raised a couple of
    questions in my mind:<br>
    <br>
    Q1. When you say "portions" of IP packets, does L2TPv2 fragmented
    these as per IP fragmentation so that each 'portion' has an IP
    header, or are they carved up in a PPP-specific way without IP
    headers on each?<br>
    <br>
    Q2. Does L2TPv3 support PPP in the same way?<br>
    <br>
    Q3. Are there other L2 protocols currently supported by L2TPv3 that
    can carve up IP packets so that there will not be an IP header at
    the start of each payload?<br>
    <br>
    If framing boundaries might be different, I will need to refer to <a
      moz-do-not-send="true"
href="https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-08#section-5.6">section
      5.6 of draft-ietf-tsvwg-ecn-encap-guidelines</a> "Reframing and
    Congestion Markings", but I don't want to add complexity if it is
    not necessary.<br>
    <br>
    Cheers<br>
    <br>
    <br>
    Bob<br>
    <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>

--------------B75EF603C5DE621DCD489FC7--


--===============4747671195263767972==
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

--===============4747671195263767972==--