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

[Lucy Yong <lucyyong@huawei.com>]

Don,

Thank you for writing this draft. It is very informative.

PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) without a
Spanning tree control plane.  As a result, this data plane does not have
knowledge of how to forwarding the traffic anymore. The purpose of the draft
is to suggest building a new control plane which can build forwarding path
for all kinds of service requests as mentioned in document.

Building a new control plane for Ethernet network sounds great!! The draft
mentions in several places a desire of some level of administrative
management in building forwarding path. I would like to ask a basic
question:

The network with this new control plane should have the intelligence of
routing and traffic engineering to allow the network building forwarding
path automatically; or
The network should not have that intelligence, forwarding path should be
selected by the network management system, network only needs signaling
capability to build forwarding path.

Which model do you pursue for PBT, why?

Best Regards,
Lucy Yong
 


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Don Fedyk
Sent: Monday, June 26, 2006 10:50 AM
To: Igor Bryskin; ccamp@ops.ietf.org; gels@rtg.ietf.org
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

 

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
>
> Thanks Don,
> 
> See in-line.
> 
> Igor
> 
> ----- Original Message -----
> From: "Don Fedyk" <dwfedyk@nortel.com>
> 
<snip>
> 
> 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
> 
To be clear on this the association is made statically up front in the
current document. No new Eth-LSPs are set up due to the arrival of an
new D-MAC. There is a static binding of a Customer Port to a Ethernet
LSP. There is a static binding of the Eth-LSP to a destination switch.
At the ingress provider node and a destination provider node typically a
PW identifier or a PPB I-SID is used to mux/demux the packet on the
Eth-LSP. You could also have a dedicated Eth-LSP with no multiplexer.

Regards,
Don 

(text below is consistent with this if we do what you are alluding to in
the future)

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