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 <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. > > > My point was on SRH. Good to see you have no comment on that. > Packet structures aren't protocol definitions. > > > 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 >> <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
