Subject: Comment to draft-ietf-l2tpext-eth-00.txt

From: Mitsuru Higashiyama <[email-masked]>
Date: Tue, 02 Jan 2001 00:30:44 +0900

Hello,

I cannot help saying that the proposal "draft-ietf-l2tpext-eth-00.txt"
lacks something. I have told this point at San Diego meeting. 
I think this proposal is missing the generality and flexibility to
use widely.

Below are my considerations from this proposal.

1. Modeling

There is no explanation how uses and apply this protocol to real
networks. In other words, we need the modeling section in the proposal.

As my understanding from San Diego presentation, the model may be 
LAN to LAN connection rather than remote access.

      [LAN A]                         [LAN B]
         |                               |
         |                               |
 [Host]--+                               +--[Host]
 [Host]--+                               +--[Host]
 [Host]--+                               +--[Host]
 [Host]--+         +-----------+         +--[Host]
         +--[LAC]--| Internet  |--[LNS]--+
         |         +-----------+         |
         :                               :

The Ethernet over L2TP focus LAN to LAN transparent connectibility. 
To achieve LAN to LAN connectibility, we should consider STP and 
filtering. If you think about bellow scenario:

      [LAN A]                         [LAN B]
         |                               |
         |                               |
         |         +-----------+         |
         +--[LAC]--| Internet  |--[LNS]--+
         |         +-----------+         |
 [Host]--+                               +--[Host]
 [Host]--+                               +--[Host]
 [Host]--+                               +--[Host]
 [Host]--+         +-----------+         +--[Host]
         +--[LAC]--| Internet  |--[LNS]--+
         |         +-----------+         |
         :                               :

There are two or more connections between LANs. Because today's network
is required the redundancy usually. My idea is that we should allow
using
STP or Link Aggregation technologies in the model of Ethernet over L2TP.

Second problem is the filtering. If you think about traffic between 
LAN A and B, does all traffics on LAN A and B are exchanged via WAN link
?
No, we will use normal filtering process known as IEEE 802.1D static and 
dynamic filtering. We need IEEE 802.1D filtering on the LAN to LAN model
to avoid traffic overflow.

From these two problems (redundancy and filtering), the LAC and LNS
should be Bridge entity and follow to IEEE 802.1D.

Let's remember OSI seventh layer model, what is the device which connect
LAN to LAN transparently on the layer 2. The answer is "Bridge".

2. Flexibility and extendibility

Today, VLAN and CoS are popular and are used widely.  I require allowing
to carry VLAN Tagged frames on EoL2TP. It may add flexibility and
extendibility to EoL2TP.

3. BCP

At the first, I agree to allow L2TP as one of solutions to connect LAN
to
LAN. We can provide variety with EoL2TP.

But, to think about EoL2TP is not experimental draft but standard
proposal,
we have to add some functions and process to the LAC and LNS entities
such
as STP. 

Draft-ietf-l2tpext-eth-00.txt said that "using BCP might not be feasible
since the Ethernet client may not support BCP. Furthermore, the service
type approach has less protocol overhead than using BCP." 
Do we still say that ?

In addition, I can say "Ethernet client may not support L2TP". 
And the "overhead" said in this draft is not BCP overhead but Bridging
device overhead. And it required into EoL2TP as same as BCP.

I request to remove this sentence from draft-ietf-l2tpext-eth-00.txt.

Best regards,
Mitsuru
-----------
Mitsuru Higashiyama
Anritsu Corporation

---

From: Suhail Nanji <[email-masked]>
Date: Tue, 9 Jan 2001 15:34:28 -0800 (PST)

Sorry for the late response, but I just got back from vacation.  Please
find my comments inline below.

Suhail

>          +--[LAC]--| Internet  |--[LNS]--+

The goal when doing Ethernet over L2TP was similar to PPP over L2TP - to
divorce the Layer 2 termination of Ethernet frames from their processing
(ie, bridging, PPPoE, routing, etc).  It was not envisioned as a method to
connect Remote Bridges.  Thus, any bridging functionality would exist on
the LNS only.  The LAC simply shuttles the Ethernet frames between the
client endpoint and the tunneled session.

Given this, I think there should be a restriction added to the draft which
limits the EoL2TP LAC to the leaf of a network topology.  This would
obviate the duplicate packets and possible other problems which may result
from having redundant paths as in the diagram below.  To this end a
modeling or topology section is a great idea.

>       [LAN A]                         [LAN B]

Give there is no bridging protocol processing on the EoL2TP LAC, I think
there does not need to be a mention of STP.  A reference to optional filtering could
be included.

> to carry VLAN Tagged frames on EoL2TP. It may add flexibility and

Agreed, good point.

> I request to remove this sentence from draft-ietf-l2tpext-eth-00.txt.

This reference to BCP is there to highlight the cases where the LAC is
sending/receiving Ethernet frames from a direct LAN connection or a CPE
device which uses an encapsulation other than BCP/PPP to send/receive
Ethernet frames to/from the LAC (ie, RFC1483).  If BCP/PPP were used in
these cases, the LAC would have to create a virtual BCP/PPP endpoint in the
LAC for the LNS to communicate with.  Based on the LAC implementation, this
could be awkward and cumbersome to do in the LAC.  Also, there would
be a performance hit on the LAC for the BCP/PPP processing.  I think the
sentence in the draft is valid and should remain.  However, it would be
helpful to expanded upon this point to make it clear in the draft.

---

From: Suhail Nanji <[email-masked]>
Date: Mon, 15 Jan 2001 11:52:07 -0800 (PST)

Mitsuru Higashiyama writes:
> Hello Suhail,

Konichiwa, Higashiyama-san

> 
> ----- Original Message ----- 
> From: "Suhail Nanji" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, January 10, 2001 8:34 AM
> Subject: Re: Comment to draft-ietf-l2tpext-eth-00.txt
> 
> 
> > 
> I see. You may explain that:
> If LAC does not have filtering process, LAC should be locate on the leaf of 
> a network topology and be avoided packets forwarding which are sended
> another node as possible as you can.
>   
> > 
> > > 
> > > 
> > >       [LAN A]                         [LAN B]
> > >          |                               |
> > >          |                               |
> > >          |         +-----------+         |
> If the device is the BCP/PPP endpoint, it is not nesesaly to create L2TP
> session any more. I can not understand what you say.
> Do you assume the case of IP service and Ethernet Service are carry
> over same LNS in same time ?

EoL2TP defines a Service Type for an L2TP session.  Other sessions may
carry PPP or other payloads.  I am not sure if this answers your question.

> 
>     LNS ----------------- LAC (IP/L2TP)
>         |
>        +------------------- LAC (Ether/L2TP)
> 
> 
> > 
> > > 
> > > Best regards,
> > > Mitsuru
> > > -----------
> > > Mitsuru Higashiyama
> > > Anritsu Corporation
> 
> --
>  Mitsuru Higashiyama <[email-masked]>
>  ANRITSU CORPORATION, NETWORK SOLUTIONS
>  Phone: 046-296-6621 Fax: 0462-25-8387
>