Re: New Version Notification for draft-tian-spring-srv6-deployment-consideration-00.txt

[Gyan Mishra <[e-mail]>]

Hi Robin

Here are some details related to existing Inter domain MPLS which has come a long ways since inception decades ago.  

Inter AS options A, B, C & CSC
https://tools.ietf.org/html/rfc4364#section-10

Inter AS option AB
https://datatracker.ietf.org/doc/draft-mapathak-interas-ab/

Inter AS Option A:  Back to back VRF native IP.  Subinterface VRF per customer VPN. LSP terminates on each ASBR PE router.  No BGP-LU (labeled switched unicast) which requires importing of loopback FEC of all PEs between each AS.  Simple and works if isolation is required between providers.  Does not scale. Multicast Is simple as MVPN profiles do not need to match as PIM over the NNI inter AS link glues the two MVPN domains together.

Inter AS Option B: Segmented LSP with single VPNV4 BGP session over inter AS link.  Highly scalable.  RT filtering is enabled by default on all PEs so has to be disabled on ASBR PE. Retain RT policy applied can filter and RTs and don’t have to accept all RTs. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  No BGP-LU (labeled switched unicast) which requires importing of loopback FEC of all PEs between each AS. 

Inter AS Option C: End to End LSP with BGP-LU (label switched unicast) enabled on inter AS link data plane path.  All SP PE loopback FEC destinations  must be exchanged imported between SPs and iBGP-LU PE to RR for SP loops exchanged to have label binding when advertised over eBGP LU inter AS. VPNV4 peering next-hop-unchanged for control plane update so end to end LSP can build between any to any PE between SPs. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  Option C offloads the ASBR PE having to maintain the L3 VPN FIB.

Inter AS Option AB Hybrid of Option A and B with single control plane VPNV4 peer as is with Option B and VRF data plane isolation sub interfaces per customer VRF.  Scales well as control plane is provided via single BGP peer. AB provides additional security with VRF isolation feature.  No importing of PE FEC loopback as this is a segmented LSP with 3 segments. Multicast MVPN profiles must match between SPs as recursive-FEC and this the LMDT(labeled multicast distribution tree) is end to end and not a segmented LSP as is with unicast.  For MVPN BGP-LU needs to be enabled for mLDP peer to come up for LDP router-id label binding.ASBR PE must maintain all the L3 VPN FIBs.  

Of the 4 inter AS options available today with MPLS Option A very simple and seamless and works well if you have a minimal number of VRFs.  Option B and AB both are highly scalable and AB works well if security is a concern.  Option C is a good option for enterprises as well as service providers that have a close trust relationship.

In your introduction section can you provide some details I have mentioned of the existing MPLS inter domain options.  As you mentioned the importing of millions of prefixes that would only be with Option C and it would only be a million if each provider had a million PE loopback to import. 

As far as SR-MPLS since it’s reusing the MPLS IPv4 dataplane to provide BGP IPV4 IPV6 VPNV4 VPNV6 services for inter AS would that still have to use the traditional mpls inter as options.

As for SRv6 since it uses the IPv6 data plane as far as inter domain that can be stitched with SRv6 using Option B style but IPv6 dataplane in place of the MPLS topmost label. Then all BGP services IPV4 IPV6 VPNV4 VPNV6 would ride on top.  I guess you could do Option C style and advertise the PE FEC loopbacks between domains for an end to end SID list similar to an end to end LSP do the PSP PHP would not happen until you hit the last or next to last node in the chain of domains.

My guess is with both SRv6 and SR-MPLS you could literally take all for inter AS options and use them as the bottom service BGP label would be the same it’s just that you are swapping out the MPLS topmost label MPLS IPv4 data plane with SRv6 IPv6 data plane.

Thank you 

Gyan

Sent from my iPhone

> On Nov 8, 2019, at 11:38 AM, Lizhenbin <[e-mail]> wrote:
> 
> Hi All,
> Until now there has been 7 SRV6 deployments in China. It is very typical for Chinese operators to deploy services crossing multiple IP network domains. 
> It is complex and time-consuming to use the traditional ways such as inter-AS VPN based on MPLS. With SRV6, complexity of the service provision can 
> be reduced greately.
> The following draft proposed the advantages of SRv6 and incremental deployment guidance. Then details of two SRv6 deployment cases from China Telecom 
> and China Unicom are decribed. Hope it will be helpful for reference. 
> 
> Best Regards,
> Zhenbin (Robin)  
> 
> 
> 
> ________________________________________
> 发件人: [e-mail] [[e-mail]]
> 发送时间: 2019年11月4日 21:39
> 收件人: Lizhenbin; Feng Zhao; Xiaoyaqun; Jichun Ma; Pengshuping (Peng Shuping); Chongfeng Xie; Hui Tian; Tong Li
> 主题: New Version Notification for draft-tian-spring-srv6-deployment-consideration-00.txt
> 
> A new version of I-D, draft-tian-spring-srv6-deployment-consideration-00.txt
> has been successfully submitted by Shuping Peng and posted to the
> IETF repository.
> 
> Name:           draft-tian-spring-srv6-deployment-consideration
> Revision:       00
> Title:          SRv6 Deployment Consideration
> Document date:  2019-11-04
> Group:          Individual Submission
> Pages:          13
> URL:            https://www.ietf.org/internet-drafts/draft-tian-spring-srv6-deployment-consideration-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-tian-spring-srv6-deployment-consideration/
> Htmlized:       https://tools.ietf.org/html/draft-tian-spring-srv6-deployment-consideration-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-tian-spring-srv6-deployment-consideration
> 
> 
> Abstract:
>   SRv6 has significant advantages over SR-MPLS and has attracted more
>   and more attention and interest from network operators and verticals.
>   Smooth network migration towards SRv6 is a key focal point and this
>   document provides network migration guidance and recommendations on
>   solutions in various scenarios.  Deployment cases with SRv6 are also
>   introduced.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------