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

[YongLucy 73674 <lucyyong@huawei.com>]

Don,

Thank you for the response.
You bring the right points. A network needs to serve long term and short term connections. Thus, some connections need to plan ahead and some can be requested on demand. Current network seems to maintain two TEs for the purpose.
PCE based architecture brings an oppurtunity to hybrid them into one. However, this is out of scope of PCE WG job now. Maybe the PBT control plane is a good place to develop this hybrid structure.

When and where will your draft be discussed. I did not see on the agendas.
Hope we can discuss more on this in the meeting.

Best Regards,
Lucy Yong


*******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *******************************************************************************************

----- Original Message -----
From: Don Fedyk <dwfedyk@nortel.com>
Date: Friday, June 30, 2006 2:44 pm
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

> Hi Lucy 
> 
> <snip>
> > > 
> > > 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?
> 
> Let me paraphrase your comment. Does the network have the intelligence
> for path creation or does the intelligent lie in the management 
> system? 
> I assume by network intelligence you meant he typical TE database? 
> Well, this is just my opinion, we know when path holding times are 
> longand network fill is a concern that centralized management 
> systems can
> add extra policy type operations that we do not have in today's 
> typicalTE network database.   
> We also know that when path turnaround times are short or there is 
> amplebandwidth that any reasonable path will do network 
> intelligence of today
> TE database is quite adequate. This leads me to believe that initial
> path requests will have  more centralized path control but path
> maintenance operations are logically handled be the network (eg
> rerouting, reversion etc). BTW centralized path control  may need 
> a PCE
> system not necessarily a management system. 
> 
> Of course the other interpretation of your question is do we 
> augment the
> network with more intelligence? In some ways we proposed to do 
> this for
> optical systems but uptake on augmenting the TE database has been slow
> going.  
> 
> I don't think that PBT is special in this regard I think that 
> generallythese questions are applicable to any of the GMPLS 
> systems. 
> 
> Regards,
> Don 
> > 
> > Regards,
> > Don 
> > 
> > > 
> > > Best Regards,
> > > Lucy Yong
> > >  
> > 
> > 
> > 
> > 
> > 
> > 
> 
>