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

Hi Jeff,

I have a similar comment with Dhruv. I am wondering how BGP-LS packages together TE information. Wouldn't it require IGP-TE to give TE link-state information to BGP-LS speaker, then BGP-LS packages them into a summary TE-info? If this is the case, I am not sure how convergence time of BGP-LS can improve that of IGP-TE? Please correct me if my understanding is not wrong. 

Thanks,
Young

-----Original Message-----
From: Dhruv Dhody [mailto:dhruv.ietf@gmail.com] 
Sent: Thursday, July 17, 2014 11:35 AM
To: Jeff Tantsura
Cc: Leeyoung; pce@ietf.org; Greg Bernstein; Zhenghaomian
Subject: Re: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi Jeff,

I agree with some of the operational benefits listed for BGP, but I was wondering what is your thoughts w.r.t the convergence time for BGP-LS? Since its dependent on IGP-TE, wouldn't it suffer from the same convergence delay?

Dhruv

On Thu, Jul 17, 2014 at 9:28 AM, Jeff Tantsura <jeff.tantsura@ericsson.com> wrote:
> Hi,
>
> While i find BGP-LS much more suitable for the distribution of TE data due to:
> -BGP is well understood (operations/ troubleshooting, etc); sync, HA 
> issues had be solved -Policies framework is comprehensive -BGP infra 
> in most cases is already in place -RR construct provides hierarchy 
> -many more to mention
>
> For the cases where BGP is not wanted (perceived as too complex/ doesn't support data types needed)/ PCE infra has been deployed and practices well understood it would make sense to use it.
>
> >From use cases prospective i think it only addresses (i), the rest could be addressed similarly well by BGP,  optical extensions are to come.
>
> Regards,
> Jeff
>
>> On Jul 2, 2014, at 2:51 PM, "Leeyoung" <leeyoung@huawei.com> wrote:
>>
>> 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> 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
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce