RE: Layer 2 Switching Caps LSPs

[Dimitri.Papadimitriou@alcatel.be]

sharam,

> sharam, i have explained in a previous thread taking translation
operation
> allowed on VLAN IDs (see PWE3 encaps document for inst.) and here
assuming
> that the inverse translation is performed at the egress you are
retrieving
> the value when leaving the network

>  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. The translation
shall occur prior to application of the Enable Ingress Filtering parameter
and the other constituent functions of the Forwarding Process specified
below. The default configuration of the table shall retain the original VID
value. A C-VLAN aware Bridge shall not translate VIDs."

> 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 ?
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)