Subject: [L2tpext] Re: Last Call: 'Transport of Ethernet Frames over L2TPv3' to Proposed Standard (draft-ietf-l2tpext-pwe3-ethernet)

From: Jari Arkko <[email-masked]>
Date: Mon, 03 Jul 2006 12:31:20 +0300

Authors, WG,

Do we have answers / suggested text for Dan's issues below?
If possible, I would like to get an agreed resolution to this
by Wednesday, before the next IESG telechat.

Thanks,

--Jari

Romascanu, Dan (Dan) wrote:

>I have a few questions related to the use of the terms Ethernet and VLAN
>in this I-D: 
>
>1. The I-D speaks about 'Ethernet' but does not provide any reference.
>What version of the Ethernet standard is targeted here? The latest
>approved version of the Ethernet standard is IEEE Std 802.3-2005, but
>the IEEE 802.3 WG also has in works an extension of the frame size as
>IEEE 802.3as. One cannot talk about Ethernet PDU and MTU without a
>proper reference. 
>2. The I-D speaks about 'Ethernet VLAN'. Strictly speaking there is no
>such thing, Virtual LANs are being defined by IEEE 802.1 and not only
>for Ethernet. However accepting terminology license based on the
>de-facto reality that most if not all VLANs run over Ethernet, there
>still is a need to specify if the document refers to IEEE 802.1Q VLANs
>(one 12-bit tag) or IEEE 802.1ad which accommodate multiple tags and
>introduce the concepts of Customer VLAN and Service VLAN. Maybe the
>VLANs referred in this I-D are transparent to the type of VLANs that are
>being connected, but even so there should be text explaining this. 
>
>Dan
>
>
>
>
> 
> 
>
>  
>
>>-----Original Message-----
>>From: The IESG [mailto:[email-masked]] 
>>Sent: Monday, June 12, 2006 6:07 PM
>>To: IETF-Announce
>>Cc: [email-masked]
>>Subject: Last Call: 'Transport of Ethernet Frames over 
>>L2TPv3' to Proposed Standard (draft-ietf-l2tpext-pwe3-ethernet) 
>>
>>The IESG has received a request from the Layer Two Tunneling 
>>Protocol Extensions WG to consider the following document:
>>
>>- 'Transport of Ethernet Frames over L2TPv3 '
>>   <draft-ietf-l2tpext-pwe3-ethernet-07.txt> as a Proposed Standard
>>
>>The IESG plans to make a decision in the next few weeks, and 
>>solicits final comments on this action.  Please send any 
>>comments to the [email-masked] or [email-masked] mailing lists 
>>by 2006-06-26.
>>
>>The file can be obtained via
>>http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-pwe3-et
>>hernet-07.txt
>>
>>
>>_______________________________________________
>>IETF-Announce mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ietf-announce
>>
>>    
>>
>
>
>
>  
>

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Javi <[email-masked]>
Date: Wed, 28 Jun 2006 09:26:37 +0200

If so, you may need too many resources over the IP link between the 
LCCEs, it wouldn't be efficient.

If that is the only way to manage L2 timers with pseudo-wires and 
L2TPv3, I have no clear it is a good idea to transport L2 frames over IP 
networks.

Javi

Ignacio Goyret escribió:
> At 20:51 6/27/2006 +0200, Javi wrote:
>   
>> I have a question related to transport of HDLC frames over L2TPv3 (RFC 4349):
>>
>> HDLC identifies a number of timers that may be used by an HDLC link (which
>> is operating in the reliable ABM Mode) to provide reliable data transmission,
>> such as the Acknowledgement Timer (T1).
>>
>> How are these timers managed in transport of HDLC frames over L2TPv3 and PWEs?.
>> The transport over IP may result in an expiration of the timers.
>>
>> Javi 
>>     
>
> I would expect the timers to work the same way as they do over a regular
> point to point link.
>
> Depending on the quality of the link between the LCCEs, the expiration times
> may need tweaking though.
>
> -Ignacio
>

---

From: Javi <[email-masked]>
Date: Thu, 13 Jul 2006 12:22:20 +0200

Another question related to transport of HDLC (or LAPB) frames over L2TPv3:

HDLC identifies a number of timers that may be used by an HDLC link 
(which is operating in the reliable ABM Mode) to provide reliable data 
transmission, such as the Acknowledgement Timer (T1).

According RFC 4349 (HDLCPWs over L2TPv3), depending on the quality of 
the link between the LCCEs, the HDLC expiration times may need tweaking 
though.

If so, it may need a PSN with excellent QoS or to change HDLC timers in 
HDLC terminales (Remote System for RFC 4349), but the last, changing all 
terminals, is not a viable solution, I think.

Javi

---

From: Javi <[email-masked]>
Date: Fri, 30 Jun 2006 09:30:05 +0200

And another question. Terminals have usually setup a value for the L2 
timers. If you need "tweaking though" them, it would have to be done in 
all the terminals, which doesn't seem rasonable. And, generally,  L2 
timers negotiation is not implemented. Which is the solution of 
L2TPv3+PWE then?

-Javi

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 24 Jul 2006 11:04:17 -0700

>timers negotiation is not implemented. Which is the solution of 

The solution is to make sure the network between the LCCEs is properly
engineered so you won't have to worry about HDLC timers.

If the network does not have any SLAs of any kind, the network response
may be random. In situations like these, your only choice may be to adjust
the appropriate HDLC timers, thus the comment on the draft.

HTH,
-Ignacio