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

Ramon Casellas <ramon.casellas@cttc.es> Fri, 18 July 2014 05:40 UTC

Return-Path: <ramon.casellas@cttc.es>
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 D6FE21A064E for <pce@ietfa.amsl.com>; Thu, 17 Jul 2014 22:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.044
X-Spam-Level: ***
X-Spam-Status: No, score=3.044 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] autolearn=no
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 SNu5H079rqKB for <pce@ietfa.amsl.com>; Thu, 17 Jul 2014 22:40:04 -0700 (PDT)
Received: from navarro.puc.rediris.es (unknown [IPv6:2001:720:418:ca01::139]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6159C1A0646 for <pce@ietf.org>; Thu, 17 Jul 2014 22:40:04 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ramon.casellas@cttc.es>) id 1X80tl-0001qp-Ii for pce@ietf.org; Fri, 18 Jul 2014 07:40:02 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id A1DA81FDF1 for <pce@ietf.org>; Fri, 18 Jul 2014 07:39:58 +0200 (CEST)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <53C8B328.3080804@cttc.es>
Date: Fri, 18 Jul 2014 07:39:52 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: pce@ietf.org
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>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C01FA1@dfweml706-chm.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -1.0 (-)
X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.1418]
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/WCFMizP_k5BDXIKDeqJeByVe16c
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 05:40:06 -0000

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