IETF Logo Mail Archive

Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

Xuxiaohu <xuxiaohu@huawei.com> Fri, 14 November 2014 00:50 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A81A1A2A for <idr@ietfa.amsl.com>; Thu, 13 Nov 2014 16:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.344
X-Spam-Level:
X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-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 erXWECaglCgq for <idr@ietfa.amsl.com>; Thu, 13 Nov 2014 16:50:19 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7801A1A10 for <idr@ietf.org>; Thu, 13 Nov 2014 16:50:18 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOT56874; Fri, 14 Nov 2014 00:50:17 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Nov 2014 00:50:16 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 08:50:13 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-keyupate-idr-bgp-prefix-sid-00
Thread-Index: AQHP/6FRyL/+EehQB0CLIQaNW4v8gJxfR0rw
Date: Fri, 14 Nov 2014 00:50:13 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD533@NKGEML512-MBS.china.huawei.com>
References: <D08A6F7D.1096E7%wim.henderickx@alcatel-lucent.com>
In-Reply-To: <D08A6F7D.1096E7%wim.henderickx@alcatel-lucent.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.137.86]
Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD533NKGEML512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/4GSBh0s50J5fRgzjTNIk4xH46n4
Subject: Re: [Idr] draft-keyupate-idr-bgp-prefix-sid-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 00:50:22 -0000


发件人: Idr [mailto:idr-bounces@ietf.org] 代表 Henderickx, Wim (Wim)
发送时间: 2014年11月14日 8:24
收件人: idr@ietf.org
主题: [Idr] draft-keyupate-idr-bgp-prefix-sid-00

The new BGP-Prefix-SID Label Index attribute avoids to pack routes in a single BGP update. I believe the authors did this for backward compatibility with RFC3107, etc +  the environment this is meant for does not need to scale to Millions of prefixes with this attribute. The result is that BGP NLRI(s) cannot be grouped in a single BGP update packet since the index is unique per prefix. We should clarify this because some environments might not cope with this very well.

Also I believe the solution should accommodate the ability to add multiple label blocks since we will never know up front how many prefixes we will allocate and things change, so operationally I believe this will be required.

[Xiaohu] Concur that it’s worthwhile to accommodate the ability to add multiple incontinuous label blocks on a given SR node. BTW, even given that each SR node is configured with only a single label block, how could one BGP router know the label block of another so as to establish an explicit path by using an MPLS label stack? It seems that there is no mention about the advertisement of the label block of each SR node.

Best regards,
Xiaohu

v2.23.0 | Report a Bug | By Email