Hi Gyan, Thanks very much for your comments. We will check and reply soon.
Best Regards, Zhenbin (Robin) -------------------------------------------------- 李振斌 Li Zhenbin Mobile: +86-13651017745<tel:+86-13651017745>/+968-91797068<tel:+968-91797068> Email: [email protected]<mailto:[email protected]> 发件人：Gyan Mishra <[email protected]> 收件人：Lizhenbin <[email protected]> 抄 送：Chongfeng Xie <[email protected]>;Feng Zhao <[email protected]>;Hui Tian <[email protected]>;Jichun Ma <[email protected]>;Tong Li <[email protected]>;Xiaoyaqun <[email protected]>;ipv6 <[email protected]>;spring <[email protected]> 时 间：2019-12-09 16:29:35 主题Re: New Version Notification for draft-tian-spring-srv6-deployment-consideration-00.txt Hi Lizhenbin & authors of spring SRv6 deployment considerations draft & Spring WG members Hope all is well. Have you had a chance to review this email thread questions related to your draft on the 7 SRv6 deployments in China related to inter domain SRv6 routing. This will help indeed bridge the gap in questions we have related to SRv6 deployment functionality from a 6MAN IPv6 specification perspective. I had a few more questions regarding China’s seven SRv6 implementations. With the SRv6 implementations how many nodes maximum high water mark in each of the domains and what was your maximum SID list depth and did you run into any MTU issues. What was the MTU of the nodes within the SRv6 domain? In each of the 7 deployments what was the maximum number of EH headers inserted within the domain? Was PSP used to pop the SRH EH header? Did you have any scenarios where USP SRH pop was utilized? What was the reason to use USP over default PSP? With SRv6 qos scheduling is not an issue as with MPLS which requires pipe mode for explicit null label to preserve the topmost label for exp scheduling. Was TI-LFA used for node and path protection and was that one of the SRH eh insertions that occurred? Other then the ingress source PE of the SR domain SRH type 4 eh header insertion and for TI-LFA node and path protection at PLR go to PQ loop free tunnel node we’re there any other cases where SRH eh was With best effort L3 VPN with the PE routers only upgraded to be SRv6 capable - in that scenario only the ingress source PE of the SR domain can perform SRH EH Insertion. Correct? In order for any other node in the SR domain to perform SRH eh insertion all nodes must be upgraded to be SRv6 capable such as in the case of TI-LFA fast reroute capability. Correct? From the draft - L3 VPN over SRv6 best effort there is no SRH - how would that work? I am not following... In the China deployments did you have cases where all the nodes had to be SRv6 capable? In the deployment scenarios how was the binding SID SR policy used to reduce a long SID list of a static explicit route object by selecting nodes along a path based on hardware features? In the deployments how was the binding SID used for TI-LFA fast reroute ar tar PLR junction to the PQ loop free tunnel node? Kinds Regards, Gyan On Sat, Nov 16, 2019 at 1:43 AM Gyan Mishra <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> 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) ________________________________________ 发件人: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] 发送时间: 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<http://tools.ietf.org>. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected]<mailto:[email protected]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (VZ) 13101 Columbia Pike FDC1 3rd Floor Silver Spring, MD 20904 United States Phone: 301 502-1347 Email: [email protected]<mailto:[email protected]> www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
