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:*[email protected] [mailto:[email protected]] *On Behalf > Of *Ahmed Bashandy > *Sent:* Monday, July 09, 2012 2:30 PM > *To:* [email protected] List; [email protected] > *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: * > > > > <[email protected]> <mailto:[email protected]> > > *To: * > > > > <[email protected]> <mailto:[email protected]> > > *CC: * > > > > <[email protected]> <mailto:[email protected]>, <[email protected]> > <mailto:[email protected]> > > > > 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 > > > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
