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

[Lucy Yong <lucyyong@huawei.com>]

Hi Don,

See Below.

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Don Fedyk
Sent: Friday, June 30, 2006 1:29 PM
To: Lucy Yong; Igor Bryskin; ccamp@ops.ietf.org; gels@rtg.ietf.org
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

Hi Lucy 

See comments inline.
> -----Original Message-----
> From: Lucy Yong [mailto: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.
> 
Correct

> 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?
Either model is appropriate. It comes down to a Network providers
requirements to manage the network and the resources. For many reasons
initial PBT services are static from a source/destination view point.
In some cases we will be starting from a centralized management system.
However, the aspects of GMPLS signaling and control allow a range of
static to dynamic paths even though the endpoints are static. The real
issues related to dynamic control are much like L1VPNs and some of
Igor's comments.  If the service has an identifiable UNI a more dynamic
model may be developed but right now we specifying the provider
operations. 

[Lucy] On demand request from customer space could be implemented in two
ways also, embedded network intelligence or management plane driven.
Somehow, I think this is the architecture design issue not strictly related
to on demand request from customer. Basically, how we want to build an end
to end forwarding path, rely on network intelligence or network management
system?

Regards,
Don 

> 
> Best Regards,
> Lucy Yong
>