1. Dynamic P2P with BGP Route Servers BFD for data-plane verification Magnus Bergroth NORDUnet

2. Dynamic P2P and routers today Dynamic P2P links has two end points that normally terminates in a aggregation router at each site. On logical interface per destination site. eBGP are configured over the logical interface to each site. Reachability is advertised after the P2P link is up and BGP is established.

3. Drawbacks Full mesh of BGP sessions. Extensive amount of configuration. BGP sessions over short lived P2P links are most of the time down and causes alarms.

4. BGP over P2P P2P dynamic Site A Site B Dataplane Controlplane Controlplane shared with dataplane Dataplane reachability detected when controlplane goes down

5. Multihop BGP over General IP General IP P2P dynamic Site A Site B Dataplane Control plane 130.242.0/24 Next-hop 10.0.0.0 193.10.0/24 Next-hop 10.0.0.1 10.0.0.0/31 10.0.0.1/31 eBGP between loopbacks

6. Advertise with BFD condition General IP P2P dynamic Site A Site B Dataplane Control plane 130.242.0/24 Next-hop 10.0.0.0 Condition 10.0.0.1/32 193.10.0/24 Next-hop 10.0.0.1 Condition 10.0.0.0/32 10.0.0.0/31 10.0.0.1/31 eBGP between loopbacks Static route 10.0.0.1/32 Next-hop 10.0.0.1 BFD Static route 10.0.0.0/32 Next-hop 10.0.0.0 BFD

7. Route server General IP P2P dynamic Site A Site B Route server Dataplane Control plane Site C Simplify the BGP setup Only one BGP session per site Route server with one outgoing RIB per site, steering using communities

8. Route server General IP P2P dynamic Site A Site B Route server Dataplane Control plane Site C lo0.1 10.0.0.1 lo0.1 10.0.0.2 lo0.1 10.0.0.3 130.242.0/24 Next-hop 10.0.0.1 Condition 10.0.0.2/32 add community site_B Condition 10.0.0.3/32 add community site_C Static route 10.0.0.2/32 Next-hop 10.2 BFD 10.1 10.3 10.0 Static route 10.0.0.3/32 Next-hop 10.3 BFD 10.2 10.4 10.5 Logical interface per site BFD per site Community per site

9. draft-ietf-idr-rs-bfd-01 Created for route-servers at IXP Client routers verifies connectivity of dataplane with BFD Bidirectional Forwarding Detection, RFC5880. Client routers communicates reachability northbound to the Routeserver, via Link- State and TE Information using BGP (BGP-LS): Routeserver stores Per peer: Next-Hop Information Base (NHIB) reachability for all next-hops Edoardo found

10. 1.Site A send that it will communicate with Site B. 2.Route server updates NHIB with nexthop from Site A and send to Site B via BGP-LS. 3.Site B automatically setup a BFD session towards Site A 4.Site B updates it’s NHIB and advertise to Route-server via BGP-LS 5.If Site B advertise reachability to Site A will the Route server include it’s routes from Site A in the BGP advertise to Site B. 6.If Site B advertise _no_ reachability will the route server remove the prefixes from Site A in it’s advertisement. General IP P2P dynamic Site A Site B Route server Dataplane Control plane 180.0.0.0/8 NHIB: Node: B NHIB: Node: A NHIB: Node: A Link: B -> A BFD status BFD 180.0.0.0/8 NHIB: Node: A 180.0.0.0/8 NHIB: Node: A 1 2 5 3 4

11. Benefits Only one BGP session with the Route- server. Minimize the router configuration. The BGP session will always be up. Connectivity to new sites are added by adding communities to advertised prefixes. Prefixes are learned via BGP only when the Data-plane(dynamic P2P) is up. Fast detection when the dynamic P2P are teared down. No risk of black holing

12. Status Still a draft Quagga and Bird are working on implementation. The draft suggest a dataplane to be consider permanent down after 24hours. This needs to be configurable to be tested for ever. The Routeserver init state is that the dataplane is working. For dynamic P2P is this not the case. Requeste has been made for the two above to be changed.

13. Questions?