BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery

1. BoD and MD-VPN service status in GÉANTSA3 – Network Service Delivery LHCOPN and LHCONE joint meeting – Pasadena (US) 3-4 December 2013 Brian Bach Mortensen/NORDUnet, SA3 Activity Leader

2. ObjectivesNetwork Service Delivery – SA3 • To ensure that the GÉANT service area is able to deliver multi-domain connectivity services and monitoring according to requirements from NRENs and their users. • To ensure that service deployment footprints are transitioned in place from GN3 and increased in GN3plus. • To ensure dependable roadmaps are provided for the multi-domain connectivity services. • To ensure that connectivity services are properly integrated with service management systems, as developed in SA4. • To deliver “best of breed” BoD provisioning systems for NRENs’ operations teams.

3. Connectivity servicesProblem statement • Independent NRENs => 37 • Regional networks hidden behind NRENs • Campus/research attached to NREN/Reg. • Building customs solutions • But it’s a long command chain •  slow provisioning •  performance issue hard to solve •  last mile networks are not 24/7 • Clearly not scalable • Turn around time much too slow • Network Service Delivery activity is a “partnership” between NRENs to mediate the above mentioned problems

4. Network Service Solutions2 different approaches • Bandwidth on Demand • Guaranteed bandwidth (obviously) • Point to point connectivity • Flexible resource allocation • Production service on the GÉANT backbone • Accessible through 27 GEANT pops • 10 NRENs involved • Multi Domain Virtual Private Network • Best effort service (as of speaking) • Point to point • Multipoint • Piloting effort – no production (as of speaking) • 17 NRENs involved

5. BoD Service overview • BoDservice is using AutoBahn provisioning tool in the GÉANT backbone • Currently running NSI1.1 • We have chosen to make a clean slate redesign of our IDM to support NSI2.0 • Currently testing of latest draft is ongoing (r107) • Expected release of AutoBahn v3.0 March • Rollout immediately after! • Continuously engaging with “new” NRENs to widen the service footprint

6. BoD Signaling and control flow sd • Resource allocation is dealt with at a layer on top of the backbones • Above local management systems • E.g. above Junos space in the GÉANT backbone • Reservation request are then communicated down through the management system • Introduces additional SW layer that needs to be tested • However, to keep networks manageable its important not to make hacks that short cuts the local management system • Taking our results back to vendor Domain A CP MN M1 L1 X X X

7. MDVPN Service overview • A joint service delivered by NRENs and GÉANT backbone • GEANT provides VPN transport service • NRENs use the GÉANT VPN transport service • NRENs can provision as many VPNs as they want • Regional and campus networks connect via their NREN • Resilience may be increased due usage of “cross border” fibers • Once service is configure in network • Only configuration at the provider edge is necessary VPN provider and VPN transit provider VPN provider VPN transit provider VPN transport provider

8. MDVPN Service overview (cont) • MDVPN service is an “umbrella” service: • L3VPN • P2P-L2VPN • MP-L2VPN (VPLS) • Based on • MPLS • BGP/MPLS IP Virtual Private Networks (VPNs) • RFC4364 • BGP-LU • Carrying label information in BGP-4 • RFC3107 • Available in many routers in the NREN footprint VPN provider and VPN transit provider VPN provider VPN transit provider VPN transport provider

9. Proof of concept 15th,June2013 • Proof of concept demonstrated on SAT3 test-bed • Pioneer, DFN, NORDUnet, RENATER, AMRES, LITnet, FCCN, FUnet… • Being deployed in the backbone and interconnecting the first 6 NRENs during this week • Potentially a production service spring/summer 2014

10. Service footprint • MD-VPN footprint • Combining the footprint of MD-VPN and BoDwhen possible and needed (p2p) • NSI2.0 in some domains and BGP-LU in others • An NREN connected to both services may choose to provision service using any of the above methods • Regional networks (not) likely to deploy BoD

11. Bridging BoD and MDVPN BoDDOMAINS MDVPN DOMAINS NSI NSI L1 NREN A NREN C X PROXY NREN X X X NREN B U U U U

12. Traffic engineering • Converged networks carry BoD and MD-VPN traffic on the same data plane…. • So the main difference is the ability to guarantee the BW • However few converged networks use traffic engineering capabilities AFAIK • Instead they use utilization monitoring and netflow dumps to do “what” if analysis on their networks • Policing of ingress traffic according to signaled bandwidth should be applied • Its done in the GÉANT backbone • Prioritization of research traffic over plain IP traffic • BoDconfigure through southbound API in each domain • MDVPN could use RSVP-TE or other methods available

13. Service operations and testing • Assuring service is available through various methods: • Passive monitoring • Exported through local monitoring instance • Typically simple information • Utilization • Packet Drop • CMon (SA4 activity) • Active monitoring (service assurance) • Control plane monitoring (NSI) • Ethernet OAM (BoD & MDVPN) • MPLS OAM (MDVPN) • Testing service provisioning speed and bandwidth should be ongoing tests as well for both services

14. Network Service DeliveryService Catalogue piloting In service piloting ? Open Call piloting

15. Network Service Delivery Q&A

17. But what about campus networks? • Going back to users located in campus networks • Small CE/PE required in order to provide tunneling service • Invite many “small” users • Advertise the services to end users • “Demo pack” installed in the labs • MDVPN usage example (L3VPN, L2VPN, BoD) • exceed the critical mass • Allow the end users to test the service – not wait until they request it • Examples • Juniper SRX100 • Delivers MPLS based service(s) to your desk • Juniper ACX100 • MPLS based services • Rack mounted (no fans) • LDP DoD support VPN1 VPN2 BoD VPN1 VPN2 BoD

18. MDVPN a efficient solution … • A set of services useful for end users • Cover a wide scope of user needs:from the long-term infrastructure with intensive network usage to quick point-to-point for a conference demonstration • Scientist DMZ concept • Allow to access the highest network performance • Security is required within international collaboration context (patent, medical data) • Cost Reduction for international collaboration at site level • VPN is deployed much more faster • Based on MPLS and BGP standard • easy to configure • It's flexible and quick to deploy • No Cost in terms of CAPEX • OPEX cost reduction for NREN and DANTE • A service that you can not find in commercial ISP offer/portfolio because multi-domain

19. What to monitor • Underlying principle behind this Multi-Domain VPN technology • The LSP is extended from a PE up to the remote PE in another domain Monitoring is decentralized: • monitor SDPs and SSPs state • Labeled unicast BGP peering • Multi-hop BGP VPNv4 peering Peerings to be monitored # of peering BGP reduction VPN Route Reflector (VR) label exchange (BGP protocol) in MDVPN service for L3VPN and L2VPN (Kompella)

20. MDVPNStatistics Monitoring • The VPN transport provider (GÉANT) is not able to distinguish the different VPNs. • At GÉANT level, only SSP availability and usage (throughput statistics) will be provided. • The traffic carried by a particular VPN instance can be monitored, at least at interface (SDP) level. It is up to the NREN to provide statistics on their SDP • NRENs and GÉANT cannot provide a general view of VPN usage, so it will be on the responsibility of end users to manage this. • The list of the different statistics that should be collected at SSP level and at SDP level is not totally specified.