datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

Scalable BGP FRR Protection against Edge Node Failure
draft-bashandy-bgp-edge-node-frr-03

Document type: Expired Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2013-01-17 (latest revision 2012-07-16)
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: Expired
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found here:
http://www.ietf.org/archive/id/draft-bashandy-bgp-edge-node-frr-03.txt

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. 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) provisioning overhead should be kept at minimum, (4) re-routing traffic without waiting for re-convergence must not cause loops, and (4) 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

Authors

Ahmed Bashandy <bashandy@cisco.com>
Burjiz Pithawala <bpithaw@cisco.com>
Keyur Patel <keyupate@cisco.com>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)