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?
=> what do you mean by end-user in this context ? this said, the first target is to address ethernet terminating hosts but not limited to (it has been pointed during the previous f2f meeting that the initial version covers point-to-point ethernet frame flows)
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
=> concerning ETH OAM it is not addressed as part of this document (ETH OAM is addressed via IEEE and the present document let's the possibility for making of any suitable mechanism it delivers - this is consistent with the approach we have taken here where we specifically address control aspects)
- 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.
=> well this has been already discussed as part of this thread - there is no such "VLAN stitching" operation and with in the next revision (in terms of number) we will have the possibility to reach 2^32
-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