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

[Leeyoung <[e-mail]>]

Hi Danielle,

Thanks for posting your comments that are valuable. Please see inline for my comments. 

Regards,
Young

-----Original Message-----
From: Pce [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: Tuesday, July 15, 2014 10:16 AM
To: Zhangxian (Xian); Leeyoung; [e-mail]
Cc: Greg Bernstein; Zhenghaomian
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

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.

YOUNG>> Yes, this is one of the main thrusts of this draft. 

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.

YOUNG>> Agree. 

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?

YOUNG>> I would say that the networks that have implemented IGP-TE, this will be an enhancement. There is no reason to get rid of existing capability. In terms of how to enhance this capability on top of IGP-TE is yet to be discussed as an evolutionary scenario. On the other hand, the most immediate scenario would be green fields or networks that have no IGP-TE or BGP-LS. 

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.

YOUNG>> This point is very valid point. 

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
_______________________________________________
Pce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pce