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

[Daniele Ceccarelli <[e-mail]>]

Hi authors,

I agree with Xian, very interesting draft.

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.

The three architecture options seem to be a reasonable list of all the possibilities. Since the draft is presented in the PCE WG i guess you are proposing extensions to the PCEP but I think it could be worth listing in each case a comparison with existing solutions to show pros and cons, e.g. "Nodes send local TE information directly to all PCEs" is something that might be achieved via SNMP traps or "Nodes send local TE information to PCEs via an intermediary (publish/subscribe)server" reminds me the BGP route reflector.

One further question: is the goal of the draft defining something that gets rid of routing or that somehow enhances the routing? If the latter, could you please describe how?

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.

BR
Daniele


> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Zhangxian (Xian)
> Sent: martedì 15 luglio 2014 09:11
> To: Leeyoung; [e-mail]
> Cc: Greg Bernstein; Zhenghaomian
> Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-
> te-data-00.txt
> 
> Hi, Young and authors,
> 
>     Thank you for putting forward such a draft. This reminds me to check if
> draft-ietf-pce-questions touches upon this issue and I find the following
> description (in Section 3):
> 
> ＂
>    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.
> ＂
>    So, indeed this draft discusses something interesting. Would be good to
> hear how other PCErs think about this.
> 
>    BTW, by browsing through the content, it seems that there are no
> extensions included so far. Since the document type is standard track, I
> wonder if the intention is to include PCEP extensions in the future or the
> draft actually meant to be informational only?
> 
> Regards,
> Xian
> 
> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Leeyoung
> Sent: 2014年7月3日 5:51
> To: [e-mail]
> Cc: Greg Bernstein; Zhenghaomian
> Subject: [Pce] FW: New Version Notification for draft-lee-pce-transporting-
> te-data-00.txt
> 
> Hi,
> 
> We have just published a new PCE draft concerning alternative ways of
> transporting TE data that may not depend on IGP-TE or BGP-LS.
> 
> The motivation for this work is a timely update of TE data directly from nodes
> to PCE(s) to support scenarios like:
> 
> (i) networks that do not support IGP-TE or BGP-LS but want to implement
> PCE.
> (ii) applications that require accurate and timely TE data that current
> convergence time associated with flooding is not justified.
> (iii) reduction of node OH processing of flooding mechanisms (esp. optical
> transport networks where there are large amounts of traffic data and
> constraints due to OTN/WSON/Flexi-grid, etc. Note that also BGP-LS is not
> supported in optical transport networks today)
> 
> Your comment will always be appreciated.
> 
> Thanks,
> Young (on behalf of other co-authors)
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, July 02, 2014 4:32 PM
> To: Greg Bernstein; Dhruv Dhody; Greg Bernstein; Zhenghaomian; Dhruv
> Dhody; Leeyoung; Leeyoung; Zhenghaomian
> Subject: New Version Notification for draft-lee-pce-transporting-te-data-
> 00.txt
> 
> 
> A new version of I-D, draft-lee-pce-transporting-te-data-00.txt
> has been successfully submitted by Young Lee and posted to the IETF
> repository.
> 
> Name:		draft-lee-pce-transporting-te-data
> Revision:	00
> Title:		PCEP Extensions in Support of Transporting Traffic
> Engineering Data
> Document date:	2014-07-02
> Group:		Individual Submission
> Pages:		20
> URL:            http://www.ietf.org/internet-drafts/draft-lee-pce-transporting-
> te-data-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-lee-pce-transporting-te-
> data/
> Htmlized:       http://tools.ietf.org/html/draft-lee-pce-transporting-te-data-00
> 
> 
> Abstract:
>    In order to compute and provide optimal paths, Path Computation
>    Elements (PCEs) require an accurate and timely Traffic Engineering
>    Database (TED). Traditionally this TED has been obtained from a link
>    state routing protocol supporting traffic engineering extensions.
>    This document discusses possible alternatives to TED creation. This
>    document gives architectural alternatives for these enhancements and
>    their potential impacts on network nodes, routing protocols, and
>    PCE.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce