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 <https://tools.ietf.org/html/rfc8402#section-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. 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. > > 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 > <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 > <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
