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

From: Leeyoung <[email-masked]>
Date: Wed, 2 Jul 2014 21:50:33 +0000

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: [email-masked] [mailto:[email-masked]] 
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

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 15 Jul 2014 07:10:52 +0000

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:[email-masked]] On Behalf Of Leeyoung
Sent: 2014年7月3日 5:51
To: [email-masked]
Cc: Greg Bernstein; Zhenghaomian
Subject: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi, 

Thanks,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

Abstract:

The IETF Secretariat

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 15 Jul 2014 15:15:35 +0000

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

> From: Pce [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
> Sent: martedì 15 luglio 2014 09:11
> To: Leeyoung; [email-masked]
> 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):
> 
> ＂
>    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
> 
> 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.
> 
> (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)
> 
> 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
>

---

From: Leeyoung <[email-masked]>
Date: Tue, 15 Jul 2014 22:37:03 +0000

Hi Xian,

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

Regards,
Young

-----Original Message-----
From: Zhangxian (Xian) 
Sent: Tuesday, July 15, 2014 2:11 AM
To: Leeyoung; [email-masked]
Cc: Greg Bernstein; Zhenghaomian
Subject: RE: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi, Young and authors, 

$B|~(B
$B|~(B

YOUNG>> Indeed, I think what you quoted is in the spirit of this draft in light of draft-ietf-pce-questions. 

YOUNG>> We intended this draft to be protocol enhancement. For 00 version, we did not have time to put this aspect. But, we will definitely add details in the revision. 

Regards,
Xian

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: 2014$BG/(B7$B7n(B3$BF|(B 5:51
To: [email-masked]
Cc: Greg Bernstein; Zhenghaomian
Subject: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi, 

Thanks,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

Abstract:

The IETF Secretariat

---

From: Leeyoung <[email-masked]>
Date: Tue, 15 Jul 2014 22:48:16 +0000

Hi Danielle,

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

Regards,
Young

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

Hi authors,

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

YOUNG>> Agree. 

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. 

YOUNG>> This point is very valid point. 

BR
Daniele

> 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):
> 
> ＂
>    So, indeed this draft discusses something interesting. Would be 
> good to hear how other PCErs think about this.
> 
> 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
> 
> Subject: [Pce] FW: New Version Notification for 
> draft-lee-pce-transporting- te-data-00.txt
> 
> Hi,
> 
> The motivation for this work is a timely update of TE data directly 
> from nodes to PCE(s) to support scenarios like:
> 
> (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)
> 
> Subject: New Version Notification for 
> draft-lee-pce-transporting-te-data-
> 00.txt
> 
> 
> 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
>

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 16 Jul 2014 08:30:55 +0200

> 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 con…

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.

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.

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 16 Jul 2014 13:18:20 +0000

Young,

One important advantage of publishing TE information directly onto PCE(s) is the ability to do so in an incremental way. Consider, for example, a WDM LSP is being set up. The only change that is happening on each of the involved links is one lambda channel is changing its priority level availability (e.g. from 7 to 6). If one uses IGP-TE in the network to update TEDs, each of the involved nodes has no choice but to regenerate two TE-Link TLVs in their entirety (one for inbound and one for outbound link) and flood two TE LSAs. However, if one uses a reliable protocol, such as PCEP or BGP-LS, each node can just republish  onto PCE(s) a short update with what exactly has changed (the same way, for example, as FORCES protocol is doing). This would make the life of PCE much easier (much less processing), which means that the updates can be sent as often as needed, which means that the TED on PCE would be much more up-to-date, especially when many changes are happening with the network state at the same time (as in case of network failure restoration procedures). I suggest you add these considerations and define the necessary mechanisms in your draft.

Cheers,
Igor

---

From: Leeyoung <[email-masked]>
Date: Wed, 16 Jul 2014 16:06:09 +0000

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-masked]] On Behalf Of Ramon Casellas
Sent: Wednesday, July 16, 2014 1:31 AM
To: [email-masked]
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

El 16/07/2014 0:48, Leeyoung escribió:
> draft-lee-pce-transporting-te-data-00.txt
>
>

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. 

>    and state in the network, including the LSP state discussed in

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.

---

From: Leeyoung <[email-masked]>
Date: Wed, 16 Jul 2014 16:14:23 +0000

Hi Igor,

Thanks for pointing out a good use-case for this work. I agree with that we need a mechanism that can "incrementally" be updated to PCE. As you indicated, the sensitivity of optical lambda channels with respect to timing has become more important in path computation. 

We will certainly add this discussion into the draft. Would you be able help  define the necessary mechanisms? 

Thanks,
Young

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, July 16, 2014 8:18 AM
To: Ramon Casellas; [email-masked]
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Young,

Cheers,
Igor

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 16 Jul 2014 16:17:49 +0000

I will. As I mentioned I like very much how FORCES does that.

Igor

-----Original Message-----
From: Leeyoung [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2014 12:14 PM
To: Igor Bryskin; Ramon Casellas; [email-masked]
Subject: RE: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi Igor,

Thanks,
Young

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Wednesday, July 16, 2014 8:18 AM
To: Ramon Casellas; [email-masked]
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Young,

Cheers,
Igor

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 17 Jul 2014 03:58:22 +0000

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" <[email-masked]> wrote:
> 
> Hi, 
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Jul 2014 22:04:56 +0530

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

---

From: Leeyoung <[email-masked]>
Date: Thu, 17 Jul 2014 16:42:14 +0000

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:[email-masked]] 
Sent: Thursday, July 17, 2014 11:35 AM
To: Jeff Tantsura
Cc: Leeyoung; [email-masked]; 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 <[email-masked]> wrote:
> -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
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 17 Jul 2014 17:55:51 +0000

Hi,
In my opinion the only advantage of BGP-LS vs. PCEP as a means of publishing of TE information is an ability to use reflectors to optimize the publishing said information onto more than one PCE. However, I can think of many alternatives to do such optimization in a BGP-free way. There are also disadvantages of BGP-LS vs.  PCEP, the biggest of which IMO is a lack of BGP deployment in transport networks.

Igor

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, July 17, 2014 12:42 PM
To: Dhruv Dhody; Jeff Tantsura
Cc: [email-masked]; Greg Bernstein; Zhenghaomian
Subject: Re: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Hi Jeff,

Thanks,
Young

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

Hi Jeff,

Dhruv

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 18 Jul 2014 07:39:52 +0200

> 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…

Young, all

As much as I am ok with the approach of using PCEP, I am not sure what 
you say is always the case. I would guess that the common, 
straightforward source of link-state information for BGP-LS is the 
IGP-TE, but it does not preclude other sources, including, as per 
draft-ietf-idr-ls-distribution direct, static and unknown.

Also, regarding incremental updates, I don't see why they are not 
possible with BGP-LS, but I would need to re-read the draft again to be 
sure. Can an incremental update consist of a  BGP update message with 
MP_REACH attribute listing just the descriptors of the link/node and the 
link state attribute just encode the TE attributes that have changed? I 
may be wrong, but is it stated somewhere that all TLVs need to be listed 
at each update?

Thanks
Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 18 Jul 2014 07:59:53 +0200

El 18/07/2014 7:39, Ramon Casellas escribió:
>> 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.
>
> Young, all
>
That said, re-reading the draft again, the actual text still clearly 
shows a heavy dependency on the IGP, e.g.

* $3.2.1.4 "IGP Router ID: opaque value.  This is a mandatory TLV" lists 
IS-IS and OSPFv2/v3

* $3.2.2, "Although the encodings for 'Link Descriptor' TLVs were 
originally defined for IS-IS, the TLVs can carry data sourced either by 
IS-IS or OSPF"

* $3.5 "The main source of TE information is the IGP,"

etc. etc.

Of course, e.g. assigning a router ID to a node does not mean that an 
instance is actually running, so I guess BGP-LS could be decoupled from 
the IGP instance (although using similar encodings and modulo some text 
adjustments) thus mitigating convergence issues?

Thanks,
R.

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 18 Jul 2014 12:23:24 +0000

Hi Ramon,

With respect to incremental updates, with PCEP we have pretty much green field. For example, we can introduce a new PCE message "TE link update". The header of the message may have a flag indicating whether the contents of the message contain full TE link info (e.g. when the data is published onto PCE for the first time) or just incremental update, i.e. TE link info, as it is currently known to PCE, must be modified to reflect TLVs found in the message. Specifically, if we are talking about fully configured WDM layer network in a stable state, the only changes that are happening with the network TE state are priority levels at which individual lambda channels are available after a WDM connection/LSP is set up or torn down. So, instead of re-generating, re-flooding, re-processing, etc. the TE Link LSAs carrying the link states in their entirety, the nodes experiencing the changes can send short PCEP messages carrying just the modified lambda channel information and nothing else. We will have, of course, to introduce some mechanism to synchronize PCE with the nodes if/when the TE link data gets out-of-sync, which is easy to do.

I am not sure how you can achieve the described above with BGP-LS. My understanding is that the BGP message should carry the entire link state information ( LS stands for Link State) and usually for multiple links in the same message. The likely source for said information is IGP-TE, which cannot provide incremental updates in principal. Also my understanding is that BGP-LS does require BGP and IGP, while PCEP solution requires neither, just PCEP, which is already a necessity if one uses PCEs in the network.

Cheers,
Igor

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Friday, July 18, 2014 1:40 AM
To: [email-masked]
Subject: Re: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

Young, all

Thanks
Ramon