Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Satoru Matsushima <[e-mail]>]

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.


> 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
>  
> 发件人: [e-mail] [mailto:[e-mail]] 代表 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring