Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

I will. As I mentioned I like very much how FORCES does that.

Igor

-----Original Message-----
From: Leeyoung [mailto:leeyoung@huawei.com] 
Sent: Wednesday, July 16, 2014 12:14 PM
To: Igor Bryskin; Ramon Casellas; pce@ietf.org
Subject: RE: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi Igor,

Thanks for pointing out a good use-case for this work. I agree with that we need a mechanism that can "incrementally" be updated to PCE. As you indicated, the sensitivity of optical lambda channels with respect to timing has become more important in path computation. 

We will certainly add this discussion into the draft. Would you be able help  define the necessary mechanisms? 

Thanks,
Young

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Wednesday, July 16, 2014 8:18 AM
To: Ramon Casellas; pce@ietf.org
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Young,

One important advantage of publishing TE information directly onto PCE(s) is the ability to do so in an incremental way. Consider, for example, a WDM LSP is being set up. The only change that is happening on each of the involved links is one lambda channel is changing its priority level availability (e.g. from 7 to 6). If one uses IGP-TE in the network to update TEDs, each of the involved nodes has no choice but to regenerate two TE-Link TLVs in their entirety (one for inbound and one for outbound link) and flood two TE LSAs. However, if one uses a reliable protocol, such as PCEP or BGP-LS, each node can just republish  onto PCE(s) a short update with what exactly has changed (the same way, for example, as FORCES protocol is doing). This would make the life of PCE much easier (much less processing), which means that the updates can be sent as often as needed, which means that the TED on PCE would be much more up-to-date, especially when many changes are happening with the network state at the same time (as in case of network failure restoration procedures). I suggest you add these considerations and define the necessary mechanisms in your draft.

Cheers,
Igor

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: Wednesday, July 16, 2014 2:31 AM
To: pce@ietf.org
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

El 16/07/2014 0:48, Leeyoung escribió:
> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Daniele 
> Ceccarelli
> Sent: Tuesday, July 15, 2014 10:16 AM
> To: Zhangxian (Xian); Leeyoung; pce@ietf.org
> Cc: Greg Bernstein; Zhenghaomian
> Subject: Re: [Pce] New Version Notification for 
> draft-lee-pce-transporting-te-data-00.txt
>
>
> In the intro you say that participating in IGP is cumbersome for a number of reasons (significant traffic load, need for multiple IGP implementations), but I think one of the main reasons which IMHO should be added is "time". IGPs can take time to converge and the PCE is often asked to quickly provide new paths upon failures. A simple, dedicated, update from the nodes detecting the failure to the PCE would be much more efficient also in dealing with this issue.
>
>

> Personally, I think this architectures would be extremely helpful in an SDN hierarchical environment (maybe I'm going a bit off topic...) where topology updates need to be sent from a child SDN controller to a parent SDN controller and where running an IGP between controllers would be extremely complex if not impossible.

Ramon> I also find this option quite interesting, for the reasons stated
above, IGP convergence, simplicity, etc.; some implementors have played with this in the past, e.g. for example http://tools.ietf.org/id/draft-zhang-pce-hierarchy-extensions-02.txt and several research papers, with Notification extensions, which can, simply, wrap LSAs as a straightforward option. I am just worried that, when this was discussed, we got some off-line feedback that it did not seem to be appropriate to extend PCEP for such purposes, and that PCEP it was a request/response protocol for path computations, not for TE dissemination.

Much like the discussions we had with stateful extensions, it would be great to know whether the WG thinks it is a good idea or not :) Thanks R.

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce