[Idr] Fwd: New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt
Ahmed Bashandy <bashandy@cisco.com> Fri, 28 October 2011 18:16 UTC
Return-Path: <bashandy@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2021F8A56 for <idr@ietfa.amsl.com>; Fri, 28 Oct 2011 11:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI8J2ob5jD0g for <idr@ietfa.amsl.com>; Fri, 28 Oct 2011 11:15:59 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CFA4E21F85B5 for <idr@ietf.org>; Fri, 28 Oct 2011 11:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=7593; q=dns/txt; s=iport; t=1319825760; x=1321035360; h=message-id:date:from:mime-version:to:cc:subject; bh=tKQ3O0yHgjwofpktHgAU3KKRDVcLKIrgNOFK1rDvakA=; b=FML9Usc+XEbhIVXk+EDPfJGjiIooBPqjmMrtfEkKxy8GJyZjch4MVkcL Hyl/TgZzKYFfOD5VtY6KPXQJvBFKnN+19yQ8axh8bNivg0a9K1ZIIJcAr xHO/zc3WvvqSQ8p5T7Rd/9NYX0Fs1N3KxFMmKKGNCuR6lCEMJ6B1Di/ei A=;
X-Files: signature.asc : 251
X-IronPort-AV: E=Sophos; i="4.69,419,1315180800"; d="asc'?scan'208,217"; a="10979609"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Oct 2011 18:15:59 +0000
Received: from [128.107.163.125] (dhcp-128-107-163-125.cisco.com [128.107.163.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9SIFwgG020429; Fri, 28 Oct 2011 18:15:59 GMT
Message-ID: <4EAAF15E.7080505@cisco.com>
Date: Fri, 28 Oct 2011 11:15:58 -0700
From: Ahmed Bashandy <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15
MIME-Version: 1.0
To: idr@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigBADF45C695E1C205FB8A7BFC"
Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Oct 2011 18:16:00 -0000
Hi, this is a new version of the draft. It just has editorial changes. I only got one comment from Rob Shakir. His primary concern is that the draft requires allocating multiple prefixes to each PE to be used as BGP Next-hops. This may be a problem for deployments with constrained address space, such as deployments that do not use private addresses as BGP next-hops in BGP_free cores We are working to address Rob's concern All additional comments are most welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-bgp-edge-node-frr-01.txt Date: Fri, 28 Oct 2011 10:50:31 -0700 From: internet-drafts@ietf.org To: bashandy@cisco.com CC: bashandy@cisco.com A new version of I-D, draft-bashandy-bgp-edge-node-frr-01.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. Filename: draft-bashandy-bgp-edge-node-frr Revision: 01 Title: Scalable BGP FRR Protection against Edge Node Failure Creation date: 2011-10-26 WG ID: Individual Submission Number of pages: 17 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it desirable for a penultimate hop route "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/p to one of the other edge routers that advertised P/p, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes,(3) there should be no special router (or group of routers) that handles restoring traffic, and (4) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (5) the penultimate hop router must swap the label advertised by the failed edge router PEi for the prefix P/p with the label advertised for the same prefix by the edge router PEj before re-tunneling the packet to PEj The IETF Secretariat
- [Idr] Fwd: New Version Notification for draft-bas… Ahmed Bashandy