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

Hi Ramon,

Thanks for posting your comments and interest in this work. Please see in-line for my response. 

Regards,
Young

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: Wednesday, July 16, 2014 1: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.

YOUNG>> Good point. There is always timing issue. I think timing for this work is mature than in the past. I have seen a real market need for this work at least from a transport network perspective. As on-line path computation needs are ripe, the convergence time has become a key issue to deal with in the environment that require a faster and accurate resource information to provide dynamic paths and elastic paths. 

YOUNG>> Echo to what Xian quoted on PCE Questions from draft-ietf-pce-questions, I believe it deserves to discuss this extension and bounce off people's opinion. 

>    It has also been proposed that the PCE Communication Protocol (PCEP)
>    [RFC5440] could be extended to serve as an information collection
>    protocol to supply information from network devices to a PCE.  The
>    logic is that the network devices may already speak PCEP and so the
>    protocol could easily be used to report details about the resources
>    and state in the network, including the LSP state discussed in
>    Sections 14 and 15.

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