=> 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)
In order to implement the Ethernet VLAN L2SC of your draft, what kind of Hardware is needed?Can you reuse existing standard hardware or you need a different hardware?
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)
The ETH OAM defined in IEEE assumes Connectionless behavior. For example the loopback or trace-route assumes that every intermediate node knows how to send the reply back to the ingress. Since GMPLS createsa Connection-oriented network, I am not sure how it can reuse ETH OAM !!!!!
- 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
How can you reach 2^32 ? And if it is not VLAN stitching, then could you simply explain the operation? aren't you sending label request from downstream to upstream? I am confused !!!!!!!!!!
-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