1 / 7

Additional Inter AS option for BGP/MPLS IP VPN IETF-64

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

oralee
Download Presentation

Additional Inter AS option for BGP/MPLS IP VPN IETF-64

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. Next steps • WG interest in this option? • Draft updated with additional data plane option? draft-kulmala-l3vpn-interas-option-d-01.txt

More Related