RE: Frameformat in a l2cs gmpls rnvironment.

[Dimitri.Papadimitriou@alcatel.be]

hi richard

> I fully agree with Juergen's comments. The key question that's still not
> clear in my mind here is, what is the real motivation for this work?

motivations are detailed in section 4 - this said, i need some
clarification from your side to provide a more detailed answer to your
initial question

> Is it to simply support dynamic VLAN provisioning for Ethernet based on
> shortest/TE paths using GMPLS instead of using OSS?

among other - yes

> Or is it to develop an alternative CO-PS solution (to say ATM or MPLS)
> using the Ethernet frame structure, regardless of whether or not the
> Ethernet forwarding behaviour (and hardware) needs to be modified?

this is not an objective

however, and this is where the whole difficulty of the exercise stands, as
the DT was not chartered to specifically detail the data plane
behaviour/fowarding behaviour there is indeed a whole spectrum of such
behaviour that can sustain these requirements - reason why this work item
(even if we get a consensus as part of this WG) requires consultation of
the IEEE as stated in section 7.1

> If the scope of the proposal does not prevent the Ethernet forwarding
> behaviour being modified resulting in "the switching hardware, the filter
> and relay, etc. are totally different new dataplane switch", then this
seems
> to be contradictory to an earlier comment from Dimitri that said "the
> definition of any data plane behaviour is outside of the scope of the DT
> charter and the document it produced".

and this statement still holds as the DT work is concerned - note: some
individuals have expressed opinions in terms of data plane support but this
is not part of the scope of the present DT charter but these is a logical
consequence of initiating such a work item within a community of engineers

> This also raises questions regarding the role of the IEEE and what the
> applications/goals/benefits of the new Ethernet forwarding behaviour will
> be.

indeed - this is the reason why the document has explicitly stated that
consultation with the IEEE must be ensured to progress with this item

> If on the other hand the goal is to use the Ethernet data plane as it
stands
> today based on MAC address learning/switching, but to replace manual/OSS
> VLAN provisioning with a GMPLS CP, it seems to me that there is a
> fundamental difference between this proposal and all other GMPLS
solutions.
> In all the GMPLS solutions I'm aware of, the label signalled via GMPLS
(e.g.
> ATM VPI/VCI, WDM wavelength, etc.) is also used for forwarding in the
data
> plane. However in this case, data plane forwarding is not based on a
label
> (VLAN ID) but on an address, i.e. the destination MAC address. Instead,
the
> label is used to restrict the broadcast domain (e.g. to a P2P path),
which
> (following MAC flooding/learning) results in the packets belonging to a
> particular VLAN following the same path. Although the result is
effectively
> the same, the fact that forwarding is not based on the label signalled
using
> GMPLS may cause complications. For example, when a failure occurs, in
> addition to re-routing or switching over to backup paths, the MAC
> databases/tables of all effected nodes must be purged on a per VLAN
basis.

indeed, flushing and re-learning aspects must be addressed - and this is
the kind of feedback we expect to receive from the IEEE

> Looking at section 4, I agree that one obvious benefit (as mentioned in
> section 4) would be the ability to dynamically calculate loop-free
> shortest/TE paths, which would allow operators to switch off spanning
tree.
> However as Juergen points out, this is one of the goals for the TRILL WG
> (although the solution proposed is different), so I would like to
understand
> what the common/opposing goals are. Another example from section 4 is the
> point about improving scalability by introducing IP addressing with GMPLS
> rather relying on MAC addresses, which are not hierarchical. This point
is
> only valid if the control plane is being used to carry Ethernet
addresses.

i do not understand this last statement - would you clarify ? -

> So, this might be a valid point when comparing the TRILL solution to the
> GMPLS solution for example, but is not valid when comparing a standard
802.1
> Ethernet network to a GMPLS L2-LSP network. The reason being that both
> solutions are still based on data plane learning using MAC addresses and
are
> therefore both subject to the same data plane scaling issues, i.e. for
the
> solution to scale to large numbers of Ethernet customers, MAC-in-MAC
> encapsulation will be required.

indeed MAC-in-MAC is currently under definition to solve such kind of
problems, however the present approach does not intend to be used for
establishing an LSP per pair of MAC SA-DA when the #Ethernet terminating
hosts >> #network nodes;

also to clarify a specific point in the context of the present discussion,
this work item is not intended to solve ALL the specific issues and
problems related to the use of an Ethernet data plane in any operational
conditions; this document has simply identified several scenario where the
use of GMPLS protocol suite may be considered in order to facilitate (some
of the) Ethernet network operations

> Therefore, what will the benefits of using L2-LSPs with MAC-in-MAC be
> compared to encapsulating Ethernet in MPLS PWs?

some of the TRILL WG objectives are indeed overlapping with the present
effort however the respective approaches are not identical; TRILL does not
intend to make use of any signaling mechanism/source-routing protocol;
TRILL is intended to specifically cover "CAMPUS" networks (even if its
scope could be larger) by defining an "intermediate" technology between IP
and Ethernet to circumvent the drawbacks of the latter (in particular wrt
to 802.1d and related)

concerning the differences between the present work item and Ethernet over
PW/MPLS, i refer you to the introduction of the document under discussion

i hope this clarifies (at least some of your doubts)

thanks,
- dimitri.