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

[Ahmed Bashandy <[e-mail]>]

The edge-node protecting BGP-FRR solution that I am aware of is the one
described in draft-minto-2547-egress-node-fast-protection and section
5.1.8.4 in draft-ietf-mpls-seamless-mpls

I would be happy to know to learn about other ones

Thanks

Ahmed

On 7/16/2012 2:51 PM, Susan Hares wrote:
>
> 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: *
>
> 	
>
> <[e-mail]> <mailto:[e-mail]>
>
> *To: *
>
> 	
>
> <[e-mail]> <mailto:[e-mail]>
>
> *CC: *
>
> 	
>
> <[e-mail]> <mailto:[e-mail]>, <[e-mail]>
> <mailto:[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
>
>  
>
>  
>