> > On Wed, 11 Sep 2019, 14:21 Satoru Matsushima, <satoru.matsush...@gmail.com> > wrote: >>> >>>> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima, >>>> <satoru.matsush...@gmail.com> wrote: >>>> Hi Aijun, >>>> >>>>> >>>>> >>>>> But the concept of SRv6+ is more clear than the SRv6(topology/service >>>>> instruction separation; >>>>> >>>> >>>> The SR architecture never require such things. See RFC8402: >>>> >>>> “Abstract >>>> >>>> Segment Routing (SR) leverages the source routing paradigm. A node steers >>>> a packet through an ordered list of instructions, called "segments". A >>>> segment can represent any instruction, topological or service based.” >>>> >>>> “3.1.3. SRv6 >>>> >>>> When SR is used over the IPv6 data plane: >>>> >>>> o A Prefix-SID is an IPv6 address. >>>> o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node >>>> addresses are not SRv6 SIDs by default.” >>>> >>>> >>>>> different instruction carried in different IPv6 EH). It conforms to >>>>> RFC8200 as well, seems will be less resisted within 6man WG. >>>>> >>>> >>>> SRH conforms RFC8200. >>> >>> >>> >>> This SPRING WG draft does not. >> >> My point was on SRH. Good to see you have no comment on that. > > > Packet structures aren't protocol definitions.
Huh? Interesting. I never thought like that thorough witness on lots of design work and discussion in IETF to define bits-n-bytes over the wire. —satoru > > >> >>> >>> >>> draft-ietf-spring-srv6-network-programming-01 >>> >>> >>> >>> >>> It is referring to the ID which has not been adopted by 6man, has been >>> ignoring many of the points brought up about it by 6man, and has proposed >>> Information status. >>> >>> >>> draft-voyer-6man-extension-header-insertion-05 >>> >>> >>> I would think that a Standards Track ID/RFC cannot depend on an >>> Informational ID/RFC for any formal functionality. >> >> Fine. >> —satoru >> >>> >>>> >>>> >>>>> Will such enhancements accelerate the deployment of SR related >>>>> technologies in service provider network? Anyway it is called SRv6+ J. >>>>> >>>> >>>> SRH has already accelerated SRv6 deployments. >>>> >>>> Best regards, >>>> —satoru >>>> >>>>> We have our own solutions for the similar scenarios that the SR >>>>> technologies aims to solve, but will also keep eye on the advance of >>>>> SR/SRv6/SRv6+ technologies. >>>>> >>>>> >>>>> >>>>> Best Regards. >>>>> >>>>> >>>>> >>>>> Aijun Wang >>>>> >>>>> China Telecom >>>>> >>>>> >>>>> >>>>> 发件人: spring-boun...@ietf.org [mailto:spring-boun...@ietf.org] 代表 Robert >>>>> Raszuk >>>>> 发送时间: 2019年9月11日 1:34 >>>>> 收件人: Sander Steffann >>>>> 抄送: Ron Bonica; SPRING WG List; Andrew Alston; James Guichard; Shraddha >>>>> Hegde; Rob Shakir; Zafar Ali (zali); Voyer, Daniel >>>>> 主题: Re: [spring] Going back to the original question for the Spring WG >>>>> (was: Re: Beyond SRv6.) >>>>> >>>>> >>>>> >>>>> Hi Sander, >>>>> >>>>> >>>>> >>>>> You keep saying SRv6 is complex. But it is only as complex as you are >>>>> going to make it or as you will need it to be. >>>>> >>>>> >>>>> >>>>> No one is mandating you to do any network programming or to use multiple >>>>> TLVs. If you just need to use SR for basic TE you insert one or two SIDs >>>>> and you are done. If you want to also enable L3VPN you configure it in >>>>> pretty much identical way regardless if this is SRv6 or SRv6+. >>>>> >>>>> >>>>> >>>>> I know I am not going to convince you, but just for the record it is worh >>>>> to note that what get's send on the wire is only the information what you >>>>> as the vendor need. The fact that spec has prepared encoding to also be >>>>> useful for not only you but other operators does not make the solution >>>>> "complex". Otherwise we will end up with protocol per customer which >>>>> would be pretty bad I am afraid. >>>>> >>>>> >>>>> >>>>> See many people say BGP is complex .... and it is the same here - BGP is >>>>> as complex as you require it to be. You can enable BGP 1/1 with 4 lines >>>>> of config. But if you need other address families if you need fancy >>>>> policy you have all required tools for that on your keyboard. >>>>> >>>>> >>>>> >>>>> - - - >>>>> >>>>> >>>>> >>>>> Now point about SRv6+ ... see writing a drafts for it easy, Further even >>>>> writing interop draft with SRv6 is also not that complex - day or two and >>>>> you submit. But please tell me why any vendor who has been working in >>>>> open IETF process on any new service for over 5 years now would have to >>>>> put a lot of development resources on the table to develop data plane and >>>>> control plane enhancements for essentially subset of functionality at >>>>> best ? >>>>> >>>>> >>>>> >>>>> It is nothing about anyone's good will or not ... it is all about limited >>>>> resources. Features and extensions are not added to any vendor based on >>>>> the RFC translation engine. It is pretty difficult and painful process. >>>>> So without huge market demand behind it I would be highly surprised if >>>>> any vendor who committed to SRv6 already would now take real on support >>>>> for SRv6+. >>>>> >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> R. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Sep 10, 2019 at 6:21 PM Sander Steffann <san...@steffann.nl> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> > No. And that is why I want SRv6+ to move forward, to avoid getting >>>>> > trapped in the SRv6 walled garden. >>>>> > >>>>> > The way IETF works (at least in vast majority of WGs) is that if you do >>>>> > not like a specific element of a solution or if something is missing >>>>> > from any solution during WG process - you contribute to it to either >>>>> > fix it or to make sure the WG product is the best possible. >>>>> > >>>>> > So nothing prevented you for all the years IETF has been dealing with >>>>> > SRv6 process to take an active part in its standardization. >>>>> > >>>>> > Asking for adoption of solution which brings nothing new to already >>>>> > shipping solution of SR-MPLS when it would travel over IPv4 or IPv6 is >>>>> > at best counterproductive. >>>>> >>>>> No, something that today can do the same as SR-MPLS but over IPv6, with >>>>> lots of space for future expansion, is something I like to see. Using >>>>> IPv6 instead of MPLS already gives the benefit of unifying transport >>>>> technologies. I'm not waiting for something feature packed with so many >>>>> knobs and "special" (read: header insertion, bit shifting etc) that it >>>>> will be much harder to work with. >>>>> >>>>> > It is like now you would be asking to adopt some individual drafts >>>>> > which woke up and defined new data plane and new control plane for >>>>> > services you are running in your network - and call those MPLS+, >>>>> > L2VPN+, L3VPN+ and mVPN+ without any new functionality. >>>>> >>>>> That "without any new functionality" isn't exactly true either… >>>>> >>>>> > Would it make sense ? >>>>> >>>>> If those data plane and control plane drafts provide an easier way to do >>>>> those things? Most definitely yes. >>>>> >>>>> It's the measuring progress by how many features and "cool" things are >>>>> added that is a problem here. Progress also include making technology >>>>> easier to manage, easier to understand, easier to debug, more accessible >>>>> to average network engineers. >>>>> >>>>> Antoine de Saint Exupéry was right: “Perfection is achieved, not when >>>>> there is nothing more to add, but when there is nothing left to take >>>>> away.” >>>>> >>>>> Cheers, >>>>> Sander >>>>> >>>>> _______________________________________________ >>>>> 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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
