This Internet-Draft is no longer active. Unofficial copies of old Internet-Drafts can be found here:
http://tools.ietf.org/id/draft-bashandy-bgp-edge-node-frr.
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)
datatracker.ietf.org