Subject: Re: [PWE3] Re: Bridge or

From: Danny McPherson <[email-masked]>
Date: Wed, 04 Dec 2002 00:04:19 -0700

> LAN products support MAC frame forwarding as well as Bridge protocols
> such as STP/RSTP/MSTP and GARP/GMRP/GVRP and MAC control protocols
> such as PAUSE and LCAP. Handling rules for these protocols in a Bridge
> or LAN are completely different. Therefore, to verify conformity with
> existing LAN products, semantics must be clarified first.

Semantics was probably a bad choice of words, though I do believe
a large part of the issue here is a misalignment in *terminology*.  
 
> Otherwise, why can we claim that the PW conforms with existing LAN
> standards?

It's important to remember that it's not necessarily a goal for PWE3 
to provide exact faithfulness to that of the native protocol (the FW 
document suggests PWE3 emulates "essential attributes" of a service).  
As such, with keeping the above in mind, Juergen is correct in stating
that "PWE3 defines the transport of L1/L2 client signals over a PSN
(paraphrased)".

I believe the latter of your concern here was regarding the term used 
to define the "native protocol" (or "service") itself and do agree 
aligning terminology certainly makes sense.  You folks were OK with 
"(Ethernet) LAN Emulation" or "Bridged (Ethernet) LAN Emulation", just 
not "Bridge Emulation", correct?  I think we can work with this...?

That being said, as Eric stated, while a PW does include NSP functionality
for the service that's being emulated, the NSP is NOT part of the PW.
 
Now, back to the first issue:

I believe the initial concerns were triggered by Section 3.1.6
of the Ethernet encapsulation draft, where it states that the PAUSE 
frames MUST NOT be transmitted across a PW (paraphrased).  If I'm
not mistaken, that text was added quite a while ago in order to 
suggest [to naive implementers] that it doesn't make sense to forward 
IEEE802 flow-control frames across a PW/PSN.  

Being that the "MAC Entity", which resides within the NSP function, 
provides PAUSE frame termination, perhaps removing the current text 
and clarifying by employing additional NSP-specific terms will ease 
your concerns?  If so, perhaps you could provide some text here?

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.

And we're certainly not providing the "medium connection", between 
"Medium Dependent Interfaces"!

-danny