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

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

Thanks Don,

See in-line.

Igor

----- Original Message ----- 
From: "Don Fedyk" <dwfedyk@nortel.com>
To: "Igor Bryskin" <ibryskin@movaz.com>; <ccamp@ops.ietf.org>;
<gels@rtg.ietf.org>
Sent: Monday, June 26, 2006 9:52 AM
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt


Hi Igor

Please see inline text.
> -----Original Message-----
> From: Igor Bryskin [mailto: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.
The short answer is we have not specified this.

Here is the long answer:
We have two name spaces Provider and Customer.

GMPLS and IP addressing allows us to specify a provider port connection
using the Control plane to resolve the Connection.  The ports also have
Provider MAC addresses. You are quite right in that this is highly
analogous to the L1VPN where we have Provider Port Indexes(PPI) and
VPN-Provider port indexes(VPN-PPI). The labels assigned to the
connection provider tunnel are associated with the PPI and we can
multiplex multiple PPIs on a particular tunnel.  (I don't think your
question is about this.)

In the customer space Equivalent to the Customer port Index(CPI) in
L1VPN, we have native Ethernet MAC addresses. We also have a provider
Mac address that is analogous to a VPN-PPI.  However this part of our
table is all MAC addresses. We have not specified the service aspects.
The options are:

-A simple point to point connection that is analogous to L1VPN Basic
mode.

-A more dynamic service that signals a MAC address and resolves it to a
Provider PBT connection or establishes a provider connection.  (I
believe this is your question. )

One difference in the Ethernet case point to point is that a provider
node can behave as an E-Wire or an (E-LAN point to point segment in out
case) so the provider is a wire but it optionally supports MAC learning
as an edge function.
I'll make a note to clarify this next iteration.

> 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.
True that had occurred to us as well. But given there is an in band
mechanism in 802.1 (unknown broadcast and mac learning) we have a
mechanism that is inherent in the Customer LAN/VLAN.

> 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.

So you have two questions: Do we need Auto-discovery; and if so should
it be IGP based or BGP based.
In the simple mode we have specified so far MAC Learning on the edge is
all we need.  So no auto discovery.


IB>> Well, MAC Learning tells edge switch which port an Ethernet packet
destined to a particular D-MAC should be sent out. However, it does not tell
the TE name of the edge switch (on the opposite side of the network)
supporting this D-MAC. So how the ingress switch can tell (without
auto-discovery or configuration) which of (new or existing) Eth-LSPs could
be used for the packet forwarding?

Thanks,
Igor

However if we ever get to on demand
signaling on the connections from the customer space then an auto
discovery function would be desirable.

As to IGP or BGP, very similar to the L1VPN case. We have discussed
keeping the Optical code base and the Ethernet code base development
based on the same architecture.  I don't see much difference here we
could develop either it depends on customer demand for such a feature.
Currently out of scope for us.

Regards,
Don

>
> 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
>
<snip>