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

Igor Bryskin <IBryskin@advaoptical.com> Wed, 16 July 2014 13:18 UTC

Return-Path: <IBryskin@advaoptical.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884441B2A08 for <pce@ietfa.amsl.com>; Wed, 16 Jul 2014 06:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHGJrAACu8rz for <pce@ietfa.amsl.com>; Wed, 16 Jul 2014 06:18:29 -0700 (PDT)
Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A201B1B2A8E for <pce@ietf.org>; Wed, 16 Jul 2014 06:18:29 -0700 (PDT)
Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s6GDIML7010200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 09:18:22 -0400
Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 16 Jul 2014 09:18:21 -0400
Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 16 Jul 2014 09:18:21 -0400
Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.0913.011; Wed, 16 Jul 2014 09:18:21 -0400
From: Igor Bryskin <IBryskin@advaoptical.com>
To: Ramon Casellas <ramon.casellas@cttc.es>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt
Thread-Index: AQHPlj0OW9iC/jQJM0KZkUiukoKBKZuNTqlggBNrxMCAAJCFgIAAgz8wgADHYYCAACi2EA==
Date: Wed, 16 Jul 2014 13:18:20 +0000
Message-ID: <2824c54da2f147a4968603e87752824d@ATL-SRV-MBX1.advaoptical.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BFEDB7@dfweml706-chm.china.huawei.com> <C636AF2FA540124E9B9ACB5A6BECCE6B470F6109@SZXEMA512-MBS.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE481273B0E9@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729C01885@dfweml706-chm.china.huawei.com> <53C61C1F.1080904@cttc.es>
In-Reply-To: <53C61C1F.1080904@cttc.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.222.2.134]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-16_05:2014-07-16,2014-07-16,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/wvhmhPDhCMirZDaUwG3WX9nlbDo
Subject: Re: [Pce] New Version Notification for draft-lee-pce-transporting-te-data-00.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jul 2014 13:18:32 -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

-----Original Message-----
From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: Wednesday, July 16, 2014 2:31 AM
To: pce@ietf.org
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:pce-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
> Sent: Tuesday, July 15, 2014 10:16 AM
> To: Zhangxian (Xian); Leeyoung; pce@ietf.org
> 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.

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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce