Re: Comments on the L2 VPN framework and solutions documents

Norm,

> Another way to put it:  My diagram is the only way that a standard
> bridge CAN interface to the full meshes within the layering model
> shared by IEEE 802 and IETF.  I should be more careful in my claims:
> It's the only way that has been presented, to date, to IEEE 802.1,
> and has received a lot of support.

I carefully red this thread in this week, but I'm increasingly confused.

I think intention of Eric's model shown in the below is that the 
Interface means a MSAP and the VPLS Forwarder provides an logical entity 
that is compatible with a MAC entity. This is very clear architecture 
for me, while it has loop/blackhole or flaky PEs problems.

>           |      |     |     |  
>           |      |     |     |       
>       |---|------|-----|-----|----|  
>       |  -|------|-----|-----|--- |  
>       |       VPLS Forwarder      |    == MAC entity
>       |  ----------|------------- |  
>     ..|..............................  MSAP
>       |            | Interface    | 
>       |  ----------|------------  |  
>       |  |       Bridge        |  |
>       |  -|--------|---------|--  | 
>       |---|--------|---------|----|
>           |        |         | 
>           |        | Access  | 
>           |        | Networks| 
   
Regarding your reply, I understand that the point "A" in the following 
model means a MSAP. However, I'm not sure what the right part is. 
Could you clarify the following points?

>             |===========================================--------+
>             |                   |          | forwarding |       |
>             |                   |          |  function  +---    |
>    E  i   --+                   | untagged +  VPLS 100  |       |
>    t  n     |      Provider     |          | for BPDUs  +---    |  P  r
>    h  t     |       Bridge      |          |------------|       |  s  o
>    e  e     |                   |          |            +---    |  e  u
>    r  r   --+                   |          | forwarding |       |  u  t
>    n  f     |     Each "+" in   |  VLAN 26 +  function  +---    |  d  i
>    e  a     |    the border of  |          |  VPLS 200  |       |  o  n
>    t  c     |     this block    |   mux-   |            +---    |  w  g
>       e   --+   represents one  +  demux   |------------|       |  i
>       s     |     bridge port   | function |            +---    |  r  f
>             |                   |          |            |       |  e  u
>             |                   |          |            +---    |  s  n
>           --+                   |          | forwarding |       |     c
>             |                   | VLAN 589 +  function  +---    |  i  t
>             |                   |          |  VPLS 300  |       |  n  i
>             |                   |          |            +---    |     o
>           --+                   |          |            |       |     n
>             |===========================================--------+
>                                 A          B            C

(1) Could you clarify what the mistake is in the Eric's model, and
and how your model resolved it? 

(2) Could you clarify what the right part from "A" means? I my understanding
it must be a MAC entity or a part of a MAC relay entity that distributed PEs.

(3) Could you clarify why the above model is consistent with the following 
Mick's interpretation of the Bridge protocol architecture.

> An IEEE Bridge connects to a LAN, or more properly an instance of the MAC
> Service. The functionality of multiplexing and demultiplexing VLANs to and
> from distinguishable packet formats on the LAN is an imbedded function of
> the Bridge. Further the multiplexing/demultiplexing of certain control
> protocols to and from the LAN is independent of the VLAN mux/demux. This can
> be important from the protocol efficiency/scaleability point of view since
> VLAN mux/demux is limited to associating each whole frames with a given
> VLAN. Frames that are not VLAN associated can convey information that has
> been aggregated for a number of VLANs (e.g. GVRP) or information that is the
> same and applies to all VLANs (is this media working etc. etc.).

> Accordingly the IEEE Bridge
> model does not include the possibility of any of the VLANs or the control
> protocols accessed through a single M-SAP (point of attachment to the MAC
> Service) being separately supported with methods that can lead to
> independent/different connectivity/reachability/failure, i.e. data path ==
> control path.

Thanks,


Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.