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

Ahmed Bashandy <bashandy@cisco.com> Fri, 14 November 2014 21:41 UTC

Return-Path: <bashandy@cisco.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 4899C1A8731 for <idr@ietfa.amsl.com>; Fri, 14 Nov 2014 13:41:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.094
X-Spam-Level:
X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 OKJGu7HemTEN for <idr@ietfa.amsl.com>; Fri, 14 Nov 2014 13:41:37 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FBE1A86E6 for <idr@ietf.org>; Fri, 14 Nov 2014 13:41:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6517; q=dns/txt; s=iport; t=1416001296; x=1417210896; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=HT7BbHBEKW67SMONTzJTEnnh0awhBc+uMGKB0C79ZRY=; b=POkzXK8ucuT34y4pygfOvysSlxhNNLMjFHyXDXHyhirwXWeKZ25PrqGV njUi0eYlBLJSMwPKx8zISXLyBzBYFgLVw4HxsoCM/xsLFYkUJgg7uSNIt fRQGV8DdclsjStNAD1KwCT2SeUrIyPLGvqq3PtT9hpDHqtCu3B4zRNHBh M=;
X-IronPort-AV: E=Sophos; i="5.07,387,1413244800"; d="scan'208,217"; a="47493301"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 14 Nov 2014 21:41:34 +0000
Received: from [10.21.112.61] (sjc-vpn2-61.cisco.com [10.21.112.61]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAELfTml029710; Fri, 14 Nov 2014 21:41:31 GMT
Message-ID: <546676FA.8020005@cisco.com>
Date: Fri, 14 Nov 2014 13:41:14 -0800
From: Ahmed Bashandy <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Jeff Tantsura <jeff.tantsura@ericsson.com>, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com>, "idr@ietf.org" <idr@ietf.org>
References: <D08AB1D4.79199%jeff.tantsura@ericsson.com>
In-Reply-To: <D08AB1D4.79199%jeff.tantsura@ericsson.com>
Content-Type: multipart/alternative; boundary="------------060809050307000200080602"
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/tjCT6KglzrV_r9bIws7EZBG8hNI
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 21:41:39 -0000

Hi,

There is a use case for sending the SRGB of a router in ISIS (e.g. ti-lfa)
What is the use case of having a BGP speaker send its SRGB to its peer 
in a BGP-only deployment?

Ahmed

On 11/13/2014 7:10 PM, Jeff Tantsura wrote:
> Hi,
>
> In BGP-LS-SR SRGB is encoded in SR Capabilities TLV (1034).
> However today it comes from an IGP, e.g. Is ISIS case from SR 
> Capabilities sub-TLV of Router Capability TLV, so BGP only case should 
> be added.
>
> Cheers,
> Jeff
>
> From: <Henderickx>, Wim Henderickx <wim.henderickx@alcatel-lucent.com 
> <mailto:wim.henderickx@alcatel-lucent.com>>
> Date: Thursday, November 13, 2014 at 4:24 PM
> To: "idr@ietf.org <mailto:idr@ietf.org>" <idr@ietf.org 
> <mailto:idr@ietf.org>>
> Subject: [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.
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr