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:[email protected]] On Behalf Of Ramon Casellas Sent: Wednesday, July 16, 2014 1:31 AM To: [email protected] 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:[email protected]] On Behalf Of Daniele > Ceccarelli > Sent: Tuesday, July 15, 2014 10:16 AM > To: Zhangxian (Xian); Leeyoung; [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
