Presentation on theme: "BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery LHCOPN and LHCONE joint meeting – Pasadena (US) 3-4 December 2013 Brian Bach Mortensen/NORDUnet,"— Presentation transcript:
BoD and MD-VPN service status in GÉANT SA3 – Network Service Delivery LHCOPN and LHCONE joint meeting – Pasadena (US) 3-4 December 2013 Brian Bach Mortensen/NORDUnet, SA3 Activity Leader
2 Connect | Communicate | Collaborate Objectives Network 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 Connect | Communicate | Collaborate Connectivity services Problem 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 Connect | Communicate | Collaborate Network Service Solutions 2 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 Connect | Communicate | Collaborate BoD Service overview BoD service 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 Connect | Communicate | Collaborate BoD Signaling and control flow 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 sd L1 X X CP M1 MN X X X X Domain A
7 Connect | Communicate | Collaborate MDVPN Service overview VPN provider VPN transport provider VPN provider and VPN transit provider VPN transit provider 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
8 Connect | Communicate | Collaborate MDVPN Service overview (cont) VPN provider VPN transport provider VPN provider and VPN transit provider VPN transit provider 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
9 Connect | Communicate | Collaborate Proof of concept 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 Connect | Communicate | Collaborate Service footprint MD-VPN footprint Combining the footprint of MD-VPN and BoD when 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 Connect | Communicate | Collaborate Bridging BoD and MDVPN NSI MDVPN DOMAINS BoD DOMAINS NREN A NREN X NREN C NREN B U U L1 X X X X X X NSI PROXY U U U U U U
12 Connect | Communicate | Collaborate 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 BoD configure through southbound API in each domain MDVPN could use RSVP-TE or other methods available
13 Connect | Communicate | Collaborate 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 Connect | Communicate | Collaborate Network Service Delivery Service Catalogue In service piloting Open Call piloting ?
17 Connect | Communicate | Collaborate 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 BoD VPN1 VPN2 BoD VPN1 VPN2
18 Connect | Communicate | Collaborate 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 Connect | Communicate | Collaborate 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 label exchange (BGP protocol) in MDVPN service for L3VPN and L2VPN (Kompella) # of peering BGP reduction VPN Route Reflector (VR) Peerings to be monitored Monitoring is decentralized: monitor SDPs and SSPs state Labeled unicast BGP peering Multi-hop BGP VPNv4 peering
20 Connect | Communicate | Collaborate MDVPN Statistics 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.