RE: Layer 2 Switching Caps LSPs

[Ali Sajassi <sajassi@cisco.com>]

At 01:09 AM 1/29/2005 +0100, Dimitri.Papadimitriou@alcatel.be 
wrote:

> indeed the L2LSP approach does not target the
> two below listed category of equipment (i.e. .1q bridges and IP/MPLS
> LSRs) - so what is the exact question/issue from this perspective ?

So the question I'd like to ask is what type of end-user applications you
have in mind that would require the VLANs to be stitched together this
way? 

> now the point is not only in reducing the
> overhead - but on the underlying operations when those are not required

In this case, I'd like to know the details of how maintainability (OAM)
and reliability (redundancy) aspects of the operations are addressed
?

> - on the other side it could be interesting
> that you extend a bit on the scalability of EoMPLS - to which scaling
> dimensions are you referring here ?

To number of connections which is independent from number of VLANs. BTW,
when talking about VLAN stitching, you are only limited to 4K VLANs per
interface (4K connections) even if that interface is 10GE, so why do you
want to impose such limitations in the aggregation (and/or core)
networks.

-Ali


> ps: concerning the last point i suggest a
> further reading of RFC 3945 (this could also help sorting the question on
> how GMPLS applies to packet LSPs)
>
> Ali Sajassi <sajassi@cisco.com>
> 01/28/2005 15:49 PST
>
> To: Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari
> <Shahram_Davari@pmc-sierra.com>
> cc: Shahram Davari
> <Shahram_Davari@pmc-sierra.com>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan
> <dallan@nortelnetworks.com>, "'dpapadimitriou@psg.com'"
> <dpapadimitriou@psg.com>, "'Adrian Farrel'"
> <adrian@olddog.co.uk>, ccamp@ops.ietf.org
> bcc: 
> Subject: RE: Layer 2 Switching Caps
> LSPs
>
>
> There are two categories of Ethernet switches out
> there:
>
> 1) pure L2 switches - existing IEEE (.1q)
> bridges
> 2) L2/L3 switches - capable of both bridging and MPLS/IP
> switching (including support for EoMPLS)
>
> Considering the current L2/L3 switches can support PtP
> Ethernet services end-to-end in a scalable way using EoMPLS, then the
> question is why do we need yet another alternate mechanism to provide the
> same end service without any obvious benefit. Is saving a few byte in the
> header the primary objective in here ? 
> It should be noted that the proposed use of GMPLS control
> plane is not compatible with either of the above two category of switches
> and thus cannot be leveraged by them. 
>
> -Ali