Subject: Re: [PWE3] Re: Bridge or

From: Eric Rosen <[email-masked]>
Date: Tue, 03 Dec 2002 12:59:44 -0500

> It seems to me, draft-ietf-pwe3-ethernet-encap-01.txt specifies refence
> model and protocol for Ethernet MAC frame transport over GRE/LSP tunnel. 
> It does not emulate anything. 

Well, I think that draft does a couple of things: 

1. It specifies the pseudowire encapsulation for ethernet frames. 

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.

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, while the CEs are  connected via an emulated
bridged LAN.  (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.) 

But I'm still puzzled as to whether there is an actual issue here that needs
resolution.

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Wed, 04 Dec 2002 13:43:30 +0900

> 1. It specifies the pseudowire encapsulation for ethernet frames. 

Agreed.

> bridged LAN.  

Interesting. If the NSPs emulate a LAN:

(1) It must explicitly addressed in section 3 of the draft.

(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.

(3) The NSP must not terminate PAUSE frame, so section 3.1.5 in the draft
is incorrect.

(4) The VC type in LDP signaling must have the following parameters
to identify the LAN segment to be emulated by the NSPs.

	1BASE5
	10BROAD36
	10BASE2
	10BASE5
	10BASE-F
	10BASE-FB
	10BASE-FL
	10BASE-FP
	10BASE-T
	100BASE-FX
	100BASE-T
	100BASE-T2
	100BASE-T4
	100BASE-TX
	100BASE-X
	1000BASE-CX
	1000BASE-LX
	1000BASE-SX
	1000BASE-T
	1000BASE-X
	10GBASE-SR
	10GBASE-SW
	10GBASE-LX4
	10GBASE-LR
	10GBASE-LW
	10GBASE-ER
	10GBASE-EW

> (In the two-party case, I guess the PE has to be regarded as a

Agreed.

> But I'm still puzzled as to whether there is an actual issue here that needs

I hope this helps to further clarification.

Thanks,

Muneyoshi Suzuki

---

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.

> > > But I'm still puzzled as to whether there is an actual issue here that needs

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.

> > > 1. It specifies the pseudowire encapsulation for ethernet frames.
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)

> > >    LAN, as the emulation includes the  NSP functionality, but the NSP is not
The PW as defined above simply encapsulates the Ethernet frame and
transport it over the PSN.

> > > 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.

> > (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.

> > 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.

> > > doesn't do any address lookups.)
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

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 06 Dec 2002 15:58:12 +0900

Cheng-Yin,

> of emulating Ethernet "wire"].

I fully agree with this.

> is not necessary to use the term pseudowire here, the term seems to be a

Exactly.

> IP/MPLS, we would not need to parallel IEEE specs in the IETF.

Needless to say, the IETF should not develop new LAN/Bridge protocol,
but the IETF should refer the IEEE work if it is needed.

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 06 Dec 2002 17:05:57 +0000

> but the IETF should refer the IEEE work if it is needed.

That is why we partitioned the system into a pseudo wire defined by PWE3
(which just transports things that it is given), and an NSP + Forwarder
which is defined by an expert in the media technolgy (in this case IEEE
+ IETF PPVPN) and which performs more complex functions.

Stewart

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Mon, 09 Dec 2002 14:39:07 +0900

Stewart,

> + IETF PPVPN) and which performs more complex functions.

Agreed. It seems to me, "NSP function" described in draft-ietf-pwe3-
ethernet-encap-01.txt consists of the following two functions (precisely, 
protocol entities in IEEE/ITU-T terminology)

(1)MAC function (entity) that terminates Ethernet LAN between CE and PE,
and is defined in IEEE 802.3-2002.

(2)MAC Relay function (entity) that forwards Ethernet MAC flames,
and is defined in IEEE 802.1D-1998, .1t-2001, and .1w-2001.
If VLAN tagging is performed, it also must conforms with IEEE 802.1Q-1998,
.1u-2001, and 802.1v-2001.

Then these protocols specifications for these functions (entities) are
out of scope of PWE3 protocol specification, it may define "PSN tunnel"
and "PW termination" functions.

The following text is extracted from the draft, and comments in-line.

>   The "NSP" function includes packet processing needed to translate the
>   Ethernet packets that arrive at the CE-PE interface to/from the
>   Ethernet packets that are applied to the PW termination point. Such

I think "Ethernet packets" may be "Ethernet MAC frames."

>   functions may include stripping, overwriting or adding VLAN tags,

In my understanding, 802.1Q specifies VLAN tag stripping and adding,
but I think, overwriting is not defined.

>   physical port multiplexing and demultiplexing, PW-PW bridging, 

I don't understand "physical port" in the above. Is it an Ethernet port 
to CE or PW port to PE? If it is an Ethernet port, what is "multiplexing
and demultiplexing" of Ethernet? If it is a PW port, multiplexing and 
demultiplexing function should be reside in "PW termination" function.

>   L2 encapsulation, shaping, policing, etc.

I also don't understand "L2 encapsulation" Does it encapsulate to Ethernet
frame or PSN tunnel packet? If it is PSN tunnel encapsulation, it should 
be reside in "PW termination" function.

>   The points to the left of A, including the physical layer between the
>   CE and PE, and any adaptation (NSP) functions between it and the PW
>   terminations, are outside of the scope of PWE3 and are not defined
>   here.

Right.

And the following is extracted from Danny's mail.

> We should also clarify other NSP functions such as handling CRC errors, 
> framing errors, runt conditions, etc.., and equally, PW functions that 
> result in PW "generalized bit errors" (e.g., out-of-order packets, packet 
> loss, etc..), as Akiva suggests.

I think the above functions are belongs to the "PW termination", if CRC
and framing errors in the above mean errors in PSN tunnel.

Thanks,

Muneyoshi Suzuki

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 9 Dec 2002 23:21:53 -0500

Stewart, Muneyoshi,

> > + IETF PPVPN) and which performs more complex functions.
I think IEEE is the expert in the (Ethernet) media technology and PPVPN
would have more to do with Virtual Private LAN site discovery than media
technology.
 
> and "PW termination" functions.
The question then is in which WG should some of these "NSP functions"
(e.g. what to do with MAC control frames) be clarified, if these "NSP
functions" are out of scope of PWE3 WG.

> and framing errors in the above mean errors in PSN tunnel.
Agree these functions belong to PW termination (as I understand, this is
in agreement with G.805/G.809 as well), and should be clarified in PWE3.

thanks
cheng-yin