Re: draft-fedyk-gmpls-ethernet-pbt-00.txt

["Igor Bryskin" <ibryskin@movaz.com>]

Hi Don,

I think the authors put a very good effort to clarify some of the issues wrt
using GMPLS control plane for dynamic provisioning of the TE Ethernet
tunnels.

I have a question though. GMPLS requires 32-bit TE names (e.g. TE RTR IDs)
as part of identifies of tunnel edges. So, one needs to resolve MAC
addresses to TE names  to figure out what new tunnels must be established or
existing could be used in order to forward Ethernet traffic between a S-MAC:
D-MAC pair. In other words, each edge controller needs to maintain a table
providing an association between TE names and MAC addresses supported by
them. One attractive way is to use some auto-discovery mechanism for
populating such tables. In fact, this problem looks to me identical to one
that we have, for example, in L1VPNs, where there is a need to maintain a
table associating PE TE names with the port information supported by them.
We have agreed that some auto-discovery mechanism is a MUST, and we are
arguing whether it should be BGP-based or OSPF-based or any of them.

It would be good if your draft would provide some of your views on such
mechanism and, more generally, on which routing protocols should be
supported by GMPLS controllers managing Ethernet switches. Obviously, IGP-TE
is going to be required to enable path computation. But how about BGP?

Thanks,
Igor

----- Original Message ----- 
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <ccamp@ops.ietf.org>; <gels@rtg.ietf.org>
Sent: Friday, June 23, 2006 8:02 AM
Subject: draft-fedyk-gmpls-ethernet-pbt-00.txt


Hi

We've posted a new version of our draft on GMPLS control of Ethernet,
http://www.ietf.org/internet-drafts/draft-fedyk-gmpls-ethernet-pbt-00.tx
t

We believe this draft to be of interest to the CCAMP community in
addition to those that follow GELS, hence this posting.
The draft has a fairly detailed explanation of the data plane aspects to
be clear on what aspects of Ethernet we were proposing to apply GMPLS
to. This will be removed as we move closer to a true control plane
specification.

So please have a look at the draft and send us comments. We will be
happy to clarify any data plane aspects but would prefer
critique/commentary be constrained to the control plane aspects in line
with the IETF scope.

Thanks,
Don & co.