Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt
"Susan Hares" <shares@ndzh.com> Mon, 16 July 2012 21:50 UTC
Return-Path: <shares@ndzh.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 7EC5321F875D; Mon, 16 Jul 2012 14:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 VqrRZ1qFO3hH; Mon, 16 Jul 2012 14:50:57 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1121F875A; Mon, 16 Jul 2012 14:50:56 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=63.133.198.20;
Received: from SKH2012HPLT (unverified [63.133.198.20]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 3458822-1945496 for multiple; Mon, 16 Jul 2012 17:51:40 -0400
From: Susan Hares <shares@ndzh.com>
To: 'Ahmed Bashandy' <bashandy@cisco.com>, idr@ietf.org, rtgwg@ietf.org
References: <20120708140543.21354.82768.idtracker@ietfa.amsl.com> <4FFB2330.4020809@cisco.com>
In-Reply-To: <4FFB2330.4020809@cisco.com>
Date: Mon, 16 Jul 2012 17:51:39 -0400
Message-ID: <000c01cd639d$2e3f0630$8abd1290$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CD637B.A7392600"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJaU3tI8rbwHuAvE5KejGfrXR6iaAFyCLallgcCZBA=
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Cc: "'Maciek Konstantynowicz (mkonstan)'" <mkonstan@cisco.com>
Subject: Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.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: Mon, 16 Jul 2012 21:50:58 -0000
Ahmed: Can provide a short comparison of this BGP frr with past attempts for BGP FRR? If you wish a list of the BGP FRR drafts, please let me know. sue From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Ahmed Bashandy Sent: Monday, July 09, 2012 2:30 PM To: idr@ietf.org List; rtgwg@ietf.org Cc: Maciek Konstantynowicz (mkonstan) Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Hi, The draft proposes a new method for BGP FRR. The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back All comments are most welcomed Thanks Ahmed -------- Original Message -------- Subject: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt Date: Sun, 8 Jul 2012 07:05:43 -0700 From: <mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org> To: <mailto:bashandy@cisco.com> <bashandy@cisco.com> CC: <mailto:naikumar@cisco.com> <naikumar@cisco.com>, <mailto:mkonstan@cisco.com> <mkonstan@cisco.com> A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt has been successfully submitted by Ahmed Bashandy and posted to the IETF repository. Filename: draft-bashandy-bgp-frr-vector-label Revision: 00 Title: BGP FRR Protection against Edge Node Failure Using Vector Labels Creation date: 2012-07-07 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-00.txt Status: http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-vector-label Htmlized: http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector-label-00 Abstract: Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "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/m to one of the other edge routers that advertised P/m, 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 or complicating provisioning effort. 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) re-routing traffic without waiting for re-convergence must not cause loops, (4) provisioning effort should be kept at minimum, and (5) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the label stack on the packet must allow the repair PEj to correctly forward the packet and (7) there must not be any need to perform more than one label lookup on any edge or core router during steady state The IETF Secretariat
- [Idr] Fwd: New Version Notification for draft-bas… Ahmed Bashandy
- Re: [Idr] Fwd: New Version Notification for draft… Robert Raszuk
- Re: [Idr] Fwd: New Version Notification for draft… Susan Hares
- Re: [Idr] Fwd: New Version Notification for draft… Ahmed Bashandy
- Re: [Idr] Fwd: New Version Notification for draft… Ahmed Bashandy
- Re: [Idr] Fwd: New Version Notification for draft… Robert Raszuk
- Re: [Idr] Fwd: New Version Notification for draft… Ahmed Bashandy
- Re: [Idr] Fwd: New Version Notification for draft… Robert Raszuk
- Re: [Idr] Fwd: New Version Notification for draft… Ahmed Bashandy
- Re: [Idr] Fwd: New Version Notification for draft… Robert Raszuk
- Re: [Idr] Fwd: New Version Notification for draft… Ahmed Bashandy