[Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

[Ahmed Bashandy <[e-mail]>]

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: 	<[e-mail]>
To: 	<[e-mail]>
CC: 	<[e-mail]>, <[e-mail]>



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