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

["Susan Hares" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Ahmed Bashandy
Sent: Monday, July 09, 2012 2:30 PM
To: [e-mail] List; [e-mail]
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:[e-mail]> <[e-mail]>


To: 

 <mailto:[e-mail]> <[e-mail]>


CC: 

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