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

Igor Bryskin <IBryskin@advaoptical.com> Fri, 18 July 2014 12:23 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 6649E1B299B for <pce@ietfa.amsl.com>; Fri, 18 Jul 2014 05:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 p-gB1NQ0QpIZ for <pce@ietfa.amsl.com>; Fri, 18 Jul 2014 05:23:32 -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 194651B2970 for <pce@ietf.org>; Fri, 18 Jul 2014 05:23:32 -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 s6ICNPVL019595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 08:23:25 -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; Fri, 18 Jul 2014 08:23:25 -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; Fri, 18 Jul 2014 08:23:24 -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; Fri, 18 Jul 2014 08:23:24 -0400
From: Igor Bryskin <IBryskin@advaoptical.com>
To: Ramon Casellas <ramon.casellas@cttc.es>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt
Thread-Index: AQHPlj0OW9iC/jQJM0KZkUiukoKBKZuNTqlggBZgLwCAASHRAIAAAgoAgADZRQCAACXS0A==
Date: Fri, 18 Jul 2014 12:23:24 +0000
Message-ID: <70b47c3d8f444787850dfcefad98ec24@ATL-SRV-MBX1.advaoptical.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729BFEDB7@dfweml706-chm.china.huawei.com> <1E72B0BE-4FC9-4875-AF3B-A053E5B9843E@ericsson.com> <CAB75xn69TAeLWLgKv8yQOasiSHiMSiNE6rb5EUJE1Qb_3u-VEg@mail.gmail.com> <7AEB3D6833318045B4AE71C2C87E8E1729C01FA1@dfweml706-chm.china.huawei.com> <53C8B328.3080804@cttc.es>
In-Reply-To: <53C8B328.3080804@cttc.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.222.2.208]
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-18_02:2014-07-18,2014-07-18,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/6ymbx5gYBzW9rQrmtY3Rhd-liCM
Subject: Re: [Pce] FW: 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: Fri, 18 Jul 2014 12:23:34 -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:pce-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: Friday, July 18, 2014 1:40 AM
To: pce@ietf.org
Subject: Re: [Pce] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

El 17/07/2014 18:42, Leeyoung escribió:
> 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.

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

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce