%% You should probably cite draft-bashandy-bgp-edge-node-frr-03 instead of this revision. @techreport{bashandy-bgp-edge-node-frr-02, number = {draft-bashandy-bgp-edge-node-frr-02}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-bashandy-bgp-edge-node-frr/02/}, author = {Ahmed Bashandy and Burjiz and Keyur Patel}, title = {{Scalable BGP FRR Protection against Edge Node Failure}}, pagetotal = 21, year = 2012, month = mar, day = 5, 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) there should be no special router (or group of routers) that handles restoring traffic or the need for one router to store the forwarding table of another router, (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 repairing core router must swap the label stack advertised by the failed edge router PEi for the prefix P/m with the label stack advertised for the same prefix by the edge router PEj before re- tunneling the packet to PEj}, }