Hi, Folks:
We should think first what we want do via these technologies. >From my perspective, the main aim of the SR(Segment Routing) is to assure the >E2E performance of key application, which is lacked via the traditional >distributed protocol (although RSVP-TE has tried to accomplish this aim, but >it is not widely deployed for the dynamic adjustment). With the help of SDN controller in the network, it is possible for the operator to fulfill the overall adjustments for their network, for the following scenarios: 1) E2E performance assurance for the key applications. 2) Maximize the links efficiency within the network. 3) Eliminate the temporary congestion within the network. 4) Consider not only MPLS, but also Native IP network (IPv4/IPv6 or their coexistence) SR technologies solely can’t fulfill the above requirements. Considering that SR should also depend on the SDN Controller/PCE to get the overall situation of network, calculate the optimal path end to end, we think there are some other simple way to accomplish the above goals. We call the solution to meet the above requirements as CCDR(Centrally Control Dynamic Routing). The key steps of this solution are the followings: 1) Build multi-BGP sessions for the key application traffic and the normal traffic. 2) Populate the different prefixes via the different BGP sessions. 3) Manipulate the path to the different BGP nexthop dynamically(via PCEP protocol). Based on the above procedures, we can get the following effects: 1. Adjust the path for different traffic on demand. 2. Eliminate the needs to keep the complex states as RSVP-TE 3. Does not carry the path information on every packet of the assured application as done in SR. 4. Same solution for the IPv4, IPv6, even the coexistence of them 5. Same solution for the intra domain and inter domain traffic. 6. Do not change the forward behavior of devices. Large amounts of deployed routers can be reused/Only the control plane needs to be updated. 7. Can even apply to the MPLS network in future, based on the same philosophy. The detail solution can be found at the following documents: draft- <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> ietf <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> -teas-native- <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> ip <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> -scenarios <https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/> (Scenario and Simulation Results) <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> draft-ietf <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> -teas- <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> pce <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> -native- <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> ip <https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/> (Solution document) <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> draft-ietf <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> - <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> pce <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> - <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> pcep <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> -extension-native- <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> ip <https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/> (PCEP extension) More comments and thoughts are welcome. If necessary, I can make one summary presentation on the coming IETF meeting in SPRING wg. Best Regards. Aijun Wang China Telecom 发件人: spring-boun...@ietf.org [mailto:spring-boun...@ietf.org] 代表 Gyan Mishra 发送时间: 2019年9月8日 15:20 收件人: Robert Raszuk 抄送: SPRING WG List; 6...@ietf.org; Ron Bonica; Srihari Sangli; Rob Shakir; Zafar Ali (zali); Tarek Saad 主题: Re: [spring] Beyond SRv6. As an operator of a Tier 1 provider with massive mpls networks I think our traditional bread and butter “mpls” will be around for a very very long time as is IPv4 if not longer. Most all service provider cores run greater then or equal to MTU 9000 mpls cores to account for mpls overhead shims being tacked on plus edge overhead from possible GRE tunneling or IPSEC so in general making the core the maximum Jumbo MTU supported by most vendors at 9216 is what is generally done out in the field. So for SRv6 support of multiple or many EH insertions is really a non issue for most operators. >From reading through all the discussion threads the SR insertion is two fold >one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up >requiring double EH insertions on the Ingress PE tunnel head end SRv6 source >node and then second scenario being a possible EH insertions occurrence on >intermediate nodes. I have not read through the drafts or RFC regarding >Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA >and is not the traditional MPLS FRR link/node/path protection that adds an >additional mpls shim so not sure why an EH insertion needs to occur for >Ti-LFA. Can someone clarify that use case for me. Also the EH insertion on >intermediate node what is the use case or reason for that. My guess is it’s >for special use case of stitching SRv6 domains together. Please clarify.. I do agree with some of the other operators on the marketing hype and push for SR-MPLS and SRv6 is not for every service provider as goes the mantra ..”if it’s not broken..don’t try to fix it..leave it alone” and I think you can definitely say that for MPLS as it has had a SOLID run for service providers since the 90’s ever since ATM and frame relay were put to rest so I don’t think that it’s going away any time soon. I think it would be a serious mistake and sad state of affairs for vendors to push SR-MPLS and SRv6 and stop development and support of MPLS as that would really pigeon hole all operators into one technology which does not fit the bill for every use case out there. The mention of SR-MPLS pulling support for IPv6 and forcing operators to go with SRv6 is a wrong move for vendors and would really limit operators with flexibility to chose based on their use case to stay with traditional mpls or go with with SR-MPLS or SRv6 only if necessary with their unique use case warrants. I think SR-MPLS and SRv6 should be marketed by vendors and the industry as yet another tool in our operator “design toolbox” to use as we see fit or not use but not be forced into it. There are particular use cases for SR-MPLS for migration from existing LDP and the downside of having state maintained in the core is not a downside as the P and PE nodes have to be provisioned anyway so their is no savings in pulling mpls LDP/mLDP with SR-MPLS “Sr-prefer” and ditching LDP. I think the major use case for SR-MPLS and SRv6 is coloring per-vrf TE feature for L3 VPNs steering without adding complexity of adding ibgp loopback egress PE FEC next hop to traffic engineer L3 VPN traffic. That is a unique use case and not every major service provider has that requirement so if you don’t their really is no need to jump on the SR band wagon and you can stay put with the tried and true mpls that has been around for decades and is not going away any time soon. SRv6 has a more ubiquitous all encompassing use case that could serve for MPLS core replacement or on the public internet or for enterprise network traffic engineering of flows between data centers or access to data center and an alternative to SD WAN application based routing solutions. But here as well the use case benefit has to exist. Nobody wants to be forced into it if it’s unnecessary added complexity. My 2 1/2 cents Regards, Gyan Mishra Verizon Communications Cell- 301 502-1347 Sent from my iPhone On Sep 6, 2019, at 10:17 AM, Robert Raszuk <rob...@raszuk.net> wrote: I don't think so. In OAM packets are on purpose made huge - even up to MTU to make sure real customer packets can go through or to detect and diagnose MTU issues. So adding SRH to it is nothing one can call inefficient. Wrong tree :) Cheers, R. On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli <ssan...@juniper.net> wrote: On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net said > Not really. Only SR OAM packets may need it. Is that a real problem ? Thanks for clarification. Like Ron pointed out before, its inefficient encoding. srihari… _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
