Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Hi all, Yes,+1 to traffic steering and OAM. As mentioned by Mach, Zafar and others, OAM is very important for SR to be deployed in a production network, and there are many works of OAM have been done. They should be added to Charter so that SR can be developed well since the fundamental SR

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Hi All, I could not agree more with Dan. As indicated by the text quoted by Dan from the Spring charter [https://datatracker.ietf.org/wg/spring/about/], SR Policy specification is not only part of the current Spring Charter; it is the basis of "source routing" and is the heart of the Spring

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

+1 to traffic steering and OAM. I'd like to see operational statistics/traffic accounting get some much deserved attention(in the context of SRTE policies and other SR paths) On Mon, Mar 19, 2018 at 7:23 AM Dongjie (Jimmy) wrote: > Hi all, > > > > I totally agree with

Re: [spring] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Hi, I’m worrying that MPLS based SFCs may slowdown implementations of NSH. Vendors have usually a limited bandwidth to implement new features especially when the dataplane is involved. I would personally prefer to get the resources allocated to NSH rather than MPLS based SFCs. This is not just

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-, This is really a matter of taste. Jim, whatever scheme we use for identifying service chains, there are requirements/constraints/new practices/new OAM procedures that need to be supported/honored for service chaining purposes. Those are not simple nor complex in MPLS vs. NSH over MPLS.

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

Hi all, I totally agree with Mach, Jeff and others that there is work to be done in OAM as there are more requirements to use SR for both existing and emerging applications. SR-TE is another important area. The current SR-TE mainly focuses on steering traffic to particular SR paths, while TE

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med, When I say simply, I am speaking as an operator. The operations, systems, tools, institutional knowledge etc… in this space is around MPLS. There is a simpler path to creating simple chains by using MPLS instead of introducing a new encap. Thanks, Jim

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Re-, I’m afraid that you cannot ‘simply’ re-use MPLS for chaining purposes without any code upgrade. NSH does provide the simple functionality you need; that is the information to identify a chain + avoid infinite loops. This is known as: MD Type 0x2 with length is 0x2. Of course you can

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Med, We run an MPLS network so there is no NSH deployed anywhere. I want to create simple chains that we can make available to our WAN customers and I want to keep it simple from a technology and operations POV.. At this point I do not see the need to introduce NSH for what we

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi Jim, Perhaps I missed your point, but I’m not asking to disallow whatever transport encapsulation scheme deployed in a network for SFC purposes. What I’m saying is: * the IETF has defined a generic SFC architecture and went with a transport-agnostic approach that can be deployed in

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Where I get a little lost in this discussion is assuming that there must be one encap for SFC chains.. IMO SFC should define encap agnostic behaviors, NSH is an encap that has tons of functionality but if a simple chain is needed why is it that an existing encap should be disallowed by the

Re: [spring] [**EXTERNAL**] Re: SPRING - rechartering discussion

[DV] see inlines From: spring on behalf of "Shah, Himanshu" Date: Sunday, March 18, 2018 at 9:23 PM To: Jeff Tantsura , Daniel Bernier , Bruno Decraene , "spring@ietf.org"

Re: [spring] SPRING - rechartering discussion

Yes, OAM, please! There has been some discussion recently about where new SR-related work should be done :-) I wonder whether a task for the WG would be to provide clearer coordination of the related work in other WGs. Maybe that is a "cookbook", maybe it is just a WG wiki. But it seems to

Re: [spring] SPRING - rechartering discussion

Martin H, On 2018-03-18 00:19, Martin Horneffer wrote: Hello Bruno, Martin, Rob, and whole WG, as with many bigger protocols that actually make their way into production networks, I get the strong feeling that SPRING is not done with the conclusion of the core documents. As the technology

Re: [spring] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Hi all, Wim has a point here. For all these proposals, a new behavior is needed to be followed by SFC-aware nodes. What differs is the channel used to signal a chain and to supply additional data for SFC purposes. Leveraging on existing code/capabilities is good for a vendor/implementer,

Re: [spring] SPRING - rechartering discussion

Hi all, I completely agree with Ali and Martin here, OAM is very important tool for a technology to be deployed in a production network, we see more and more requirements in this area. I support the idea to add the OAM milestone to the new charter. Best regards, Mach 发件人：Zafar Ali (zali)