IETF Logo Mail Archive

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

"Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com> Fri, 14 November 2014 00:24 UTC

Return-Path: <wim.henderickx@alcatel-lucent.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 517741A000B for <idr@ietfa.amsl.com>; Thu, 13 Nov 2014 16:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.493
X-Spam-Level:
X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 MO-b1j7bXfmD for <idr@ietfa.amsl.com>; Thu, 13 Nov 2014 16:24:16 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A7B1A00A8 for <idr@ietf.org>; Thu, 13 Nov 2014 16:24:16 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A4DD8C3444E1A for <idr@ietf.org>; Fri, 14 Nov 2014 00:24:10 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sAE0OELh002743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <idr@ietf.org>; Fri, 14 Nov 2014 01:24:14 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 01:24:14 +0100
From: "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-keyupate-idr-bgp-prefix-sid-00
Thread-Index: AQHP/6FRyL/+EehQB0CLIQaNW4v8gA==
Date: Fri, 14 Nov 2014 00:24:14 +0000
Message-ID: <D08A6F7D.1096E7%wim.henderickx@alcatel-lucent.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.5.141003
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_D08A6F7D1096E7wimhenderickxalcatellucentcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/1lYrvM5hmBW56xid_xnCv9UnqfU
Subject: [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:24:18 -0000

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.

v2.23.0 | Report a Bug | By Email