Subject: Re: [PWE3] Re: Bridge or

From: "Cheng-Yin Lee" <[email-masked]>
Date: 5 Dec 2002 23:36:23 -0500

I think we have come a long way on this thread from
http://www1.ietf.org/mail-archive/working-groups/pwe3/current/msg03154.html

[Note: LAN refers to an Ethernet/802.3 LAN below.]

We are talking about LAN (or bridged LAN - see clarification later)
emulation instead of Ethernet "wire" emulation. Eric, Danny, thanks for
taking into
consideration the concerns raised earlier on emulating Ethernet "wire".
There are only a couple more issues.

Eric Rosen wrote:
> > > But I'm still puzzled as to whether there is an actual issue here that needs
> > > resolution.

I thought Juergen articulated this quite clearly in a previous email.
Here's another attempt :
(a) If PWE3 WG is defining Ethernet emulation (i.e. taking into
account the client/Ethernet MAC layer requirements), then the NSPs
functions required should be defined in this WG,
(b) if PWE3 WG is simply encapsulating and transporting Ethernet frames
over the PSN (without taking into account the essential client layer
requirements), then NSP functions required are out of scope. In this
case,  
the required NSPs functions including PAUSE frames should not be
specified in
draft-ietf-pwe3-ethernet-encap-01.txt, and all PWE3 documents should not
state that PWE3 is working
on Ethernet emulation. [I believe we have agreed to rule out the option
of emulating Ethernet "wire"].

To the PWE3 WG, are we doing (a) or (b)?

====================================================================================

Further comments to Eric & Muneyoshi below:

Paraphrasing from 802.1d to discuss LAN and bridged LAN emulation:
The Ethernet/802.3 service emulation allows the
interconnection of stations or stations attached to separate LANs  in
different remote sites, as if there were attached to a single LAN.
The stations are unaware of their attachment to a  single LAN or a
Bridged LAN when using the MAC Service. [Hence,
as far as _data_ traffic is concerned, there is no difference between
emulating a LAN or a Bridged LAN].
The presence of the emulation devices and the tunnels used to  provide
this feature can lead to differences in Quality of Service provided by
the MAC sublayer; it is only because of such differences that this
service emulation is not fully transparent to  (_data_) traffic from
stations.

Control traffic is an artifact and can be handled as appropriate, e.g.
if a device participates in STP, then it processes the STP BPDUs,
if a device does not participate in STP, then it doesn't process the STP
BPDUs. As for PAUSE frames, since it is specified to be terminated by
another
station connected to a station on a full-duplex/2 station network, it
should be terminated accordingly.

> > > Well, I think that draft does a couple of things:
> > > 1. It specifies the pseudowire encapsulation for ethernet frames.
> >
> > Agreed.
It specifies the encapsulation for ethernet frames over PSN (I think it
is not necessary to use the term pseudowire here, the term seems to be a
moving target)

Eric Rosen wrote:
> > > 2. It specifies  how one uses a pseudowire  in order to emulate  a LAN which
> > >    has exactly  two MACs on it.  However,  the PW is not  itself an emulated
> > >    LAN, as the emulation includes the  NSP functionality, but the NSP is not
> > >    part of the PW.
The PW as defined above simply encapsulates the Ethernet frame and
transport it over the PSN.

> > > Other documents, in the PPVPN WG,  specify how to use pseudowires to emulate
> > > a LAN which has more than two MACs on it.
> > > In  both cases,  I think  it is  probably correct  to say  that the  PEs are
> > > connected via an  emulated LAN,
This sounds to me inconsistent with the above PW definition, which says
the PW btwn the PEs is not an emulated LAN.
> > > while the CEs are  connected via an emulated bridged LAN.
As far as data traffic is concerned, there should be no difference
between emulating a LAN or a bridged LAN.

Muneyoshi Suzuki wrote:
> > Interesting. If the NSPs emulate a LAN:
> >
> > (1) It must explicitly addressed in section 3 of the draft.
Agree.  So it sounds like NSP functions are going to be defined in 
this draft and in  PWE3 WG.

> > (2) Functions of the NSP must be decoupled into LAN and Bridge functions,
> > because, it support VLAN tagging, but this is a part of MAC Relay Entity,
> > especially the E-ISS sub-layer defined in section 7 of IEEE 802.1Q.
My personal opinion is if we let 802.1d/q do the job (especially for
multipoint) instead 
of having another parallel function for 802.1q/QinQ functions in
IP/MPLS, we would not need to parallel IEEE specs in the IETF.

> > > (In the two-party case, I guess the PE has to be regarded as a
> > > vestigial  bridge, since it  does provide  the MAC  service, even though it
> > > doesn't do any address lookups.)
> >
> > Agreed.
Eric, I am glad we are agreeing on this (as well as not emulating
Ethernet
"wire"). Yes, the learning bridge function is not present in this case.

thanks
cheng-yin