RE: Layer 2 Switching Caps LSPs

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Dimitri,

> >  Let me make it clear: IEEE does not permit translation of 
> the VLAN ID in
> > the Core-provider bridge (S-VLAN aware bridge) as well as 
> Legacy bridges
> > (C-VLAN aware bridge).
> 
> for your information as extracted from the last 802.1ad document
> (15-12-2004): i do want to mention this because the notion of VLAN_ID
> translation exist at the IEEE as well (note: in the above i 
> did mention the
> PWE3 doc)
> 
> "8.6.1 Ingress
> Change subclause 8.6.1 as follows. After the existing note, add the
> following note:
> NOTE 2?A Service-VLAN aware Bridge considers a received frame to be
> untagged if the initial octets of the MAC user data do not compose a
> Service VLAN tag header.
> Change the following paragraph as follows:
> An S-VLAN aware Bridge Port may implement a manageable VID Translation
> Table that specifies a value to be substituted for each of 
> the possible
> 4094 VID values assigned or received as specified above.

I am fully aware of 802.1d work, and I think you are misusing the VID Translation concept. The reason to permit VID translation in 802.1ad is for Inter-Area hand-off, in which a second operator may use a different VLAN for the same service than the first operator.

For sake of argument let's even assume each bridge operates like a single area, so that you could do VLAN swapping at every node (Aka Inter-area). One problem that you would have is that in an 802.1ad bridge all VLANs have the same meaning in all ports. In other words, you can have only 4000 entries in your VLAN switching table for an entire 802.1ad device. This is equivalent to a per-platform label space. So each 802.1ad bridge can't support more than 4000 LSPs (not matter how many ports it has). And as I said before this creates scalability issue. Unless you want people to use a different non-standard 802.1ad bridge. In that case you need to define proper architecture as a brand new transport technology, including  data-plane, control-plane and management plane and explain why it is better than other transport technologies like MPLS or provider bridge networks (aka, Q in Q).

> 
> > To answer your PWE3 question:
> >
> >    A PE that supports ETH PW, has 2 disjoint and distinct 
> components: An
> > IEEE 802.1D Ethernet Bridging component followed by an PW 
> IWF. The 802.1D
> > performs the switching based on VLAN ID (and possibly MAC address),
> 
> so now switching based on the VLAN ID becomes possible (while 
> only possibly
> on the MAC address) ? why not in the scope of the present 
> document then ?
> 
> > followed by a PW IWF that performs ETH PW processing. The 
> first component
> > (802.1D bridge) is not allowed to change the VLAN ID, because IEEE
> standards
> > does not permit that. The VLAN ID May only be changed in the PW IWF,
> since
> > it is outside the scope of IEEE.
> 
> ... so ETH processing within the context of the PW allows 
> such operation as
> i did pointed out (that was not defined by the IEEE - my 
> whole point -),
> and the question is why the same couldn't happen in the 
> present context ?

Because what you are proposing is not a simple Interworking function,
at the edge of standard transport technology. What you are proposing
is a new transport technology that requires proper architecture, and
comparison to other existing technologies to justify it.


> knowing that "bridging" is not a pre-requisite
> 
> > concerning the second point, the issue of merging has also 
> to be refined
> > from what you say as you can maintain two different LSPs on 
> a link that
> > share a common label (in the frame mode) - as briefly explained in
> section
> > 2.4.3 of RFC 3209 - this said the above operation is also 
> not excluded if
> > one desires maintaining separate labels
> 
> > What? SE is for Multicast application !!!!!!!! not what we 
> are talking
> > about.
> 
> SE Style is used among other for make-before-break; sharing, 
> MP2P, etc.
> that are not related to multicast (see RFC 3209)

I don't see the relevance of SE to what we are talking. I may be missing
something, but does GMPLS support SE?

-Shahram

> 
> 
>