90 likes | 265 Views
Additional Inter AS option for BGP/MPLS IP VPN IETF-64. draft-kulmala-l3vpn-interas-option-d-01.txt. Marko Kulmala Ville Hallivuori Martin Halstead Jyrki Soini. Service Provider Requirements for Inter-AS MPLS/BGP VPNs. VPNs spanning multiple SP domains
E N D
Additional Inter AS option for BGP/MPLS IP VPNIETF-64 draft-kulmala-l3vpn-interas-option-d-01.txt Marko Kulmala Ville Hallivuori Martin Halstead Jyrki Soini draft-kulmala-l3vpn-interas-option-d-01.txt
Service Provider Requirements for Inter-AS MPLS/BGP VPNs VPNs spanning multiple SP domains • Maintain separate SP administrative domains • Hide VPN topology information • Allow for policy mediation • Change Diffserv/EXP settings if applicable • Route Target/Route Distinguisher separation and admission control at the AS border • Operational maintenance separation for VPN Lifecycle administration. • Per SP traffic engineering. • Load balancing and path optimization. • Possible need for multi-hop E-BGP based VPN service extensions. Single SP with multiple ASes • Segment network for increased scalability • Separate core and regional access network IGP routing domains • Minimize number of LSPs across the multi-AS core. • Traffic engineering scalability. • Allow for large numbers of VPNs that span multiple sub-ASes. draft-kulmala-l3vpn-interas-option-d-01.txt
Do we need an additional option? • Multi-AS Option a) • RD, RT, PE addresses separated at the AS border. • Per VPN IP based filtering and diffserv re-marking possible. • Route capping and/or summarization available per VPN. • Fits existing operational processes for ‘on-net VPN services. • Supports traffic load balancing and inter-provider path optimization. • Scaling issues associated to per VRF Attachment Circuit BGP sessions. • Layer 2 separation may be difficult, especially when no direct connectivity between ASBRs • Difficult to support enterprise QoS transparency - dependant on L2 media. • Multi-AS Option b) • Scaling of ASBR control and data plane. • Support for enterprise QoS Transparency. • Requires agreement and coordination of Route Target values across SPs • Trust required between SPs as MPLS based ‘global’ interface exposures. • No per VPN IP packet handling capability at the ASBR • Loss of per VPN packet filtering • Loss of per VPN Diffserv remarking • No per VPN route capping and/or summarization. • Operational process separation issues. • Difficult to support traffic load balancing and inter-provider path optimization. • Multi-AS Option c) • Scalability (questionable) • RD, RT, PE addresses need to be visible to SPs • Incremental trust model to ‘Option b’ • Other attributes as per ‘Option b’ draft-kulmala-l3vpn-interas-option-d-01.txt
Additional Option Overview • Combination of options a) and b) • MPLS based data plane between ASBRs • Single MP-eBGP peering between ASBRs • ASBR has a minimum of a VRF per VPN • Optional VRF based IP look-up. • Hierarchical RT allocation policy. • Per VRF route capping. • Per VRF address aggregation. • Per VRF diffserv and EXP bit remarking. • Hides intra-AS topologies. • Allows load balancing and path optimization. • Allows enterprise QoS transparency • Trust model of Option B remains – specifically MPLS based data plane. draft-kulmala-l3vpn-interas-option-d-01.txt
VRF 2 @ ASBR1 VRF3 @ ASBR2 VRF1 @ PE1 VRF4@ PE2 CE1 CE2 AS 1 AS 2 Operation Pop label, IP lookup VRF2 -> next hop=PE1, Push label=A • Filters VPN-IPv4 routes via VRF based RT import • Installs R1 to VRF2 • VRF based export of VPN-IPv4 route via MP-eBGP • Filters VPN-IPv4 routes with RT values • Installs R1 to VRF3 • Makes normal IP route lookup • Exports VPN-IPv4 with I-BGP Pop label, IP lookup VRF3 -> next hop=ASBR1, Push label=M Pop label, IP lookup VRF1 Push label=N VPN-IPv4=RD1+R1 Next-hop=PE1 Route-target=RT1 Label=A Label=A SRC=R2.1 DST=R1.1 VPN-IPv4=RD2+R1 Next-hop=ASBR1 Route-target=RT2 Label=M Label=N SRC=R2.1 DST=R1.1 R1 SRC=R2.1 DST=R1.1 Label=M SRC=R2.1 DST=R1.1 VPN-IPv4=RD3+R1 Next-hop=ASBR2 Route-target=RT3 Label=N R1 SRC=R2.1 DST=R1.1 draft-kulmala-l3vpn-interas-option-d-01.txt
Operation summary • ASBR installs VPN-IPv4 routes into ‘non AC’ based VRFs. • ASBR re-advertises VPN-IPv4 routes by re-exporting them from VRF RIBs • BGP next hop is set to the ASBR • RDs are replaced with RDs configured in ASBR VRFs • RTs are replaced with export Route Targets configured in ASBR VRFs • Route Target values advertised inter-ASBR are separated from Route Target values advertised intra-AS. • Route Distinguisher values do not pass from PE to PE across ASes. draft-kulmala-l3vpn-interas-option-d-01.txt
Next steps • WG interest in this option? • Draft updated with additional data plane option? draft-kulmala-l3vpn-interas-option-d-01.txt