Hi Jim, Well read. This static proxy is the base mechanism that matches current state of the art. It has the same scaling limitations as NSH (state in the fabric), but does not require separate encapsulations for traffic engineering and service chaining. With this integrated solution, the same encapsulation can combine TE and service segments.
The static and dynamic proxies can support multiple service chains by using different SID values and interfaces to differentiate the chains. The dynamic proxy thus caches the received SRH on a per chain basis. (see sections 5.1 and 5.2) Furthermore, the other proxy mechanisms described in this draft aim at addressing the scaling issues by removing state from the proxy. We also expect that services will be eventually updated with native SR support. The proposed model enables these SR-native services to be transparently combined with proxied ones or segments of any other type in the same encapsulation. I hope that answers your questions. Thanks, Francois On 18 Oct 2017, at 20:04, James N Guichard <james.n.guich...@huawei.com<mailto:james.n.guich...@huawei.com>> wrote: Hi Francois, Reading through the description for static proxy I am given to believe that the cache is preconfigured with the appropriate SR stack to be applied to traffic coming back from the service; if this is correct presumably this means that you can only support a single service-chain so that the correct SR stack can be pushed back on to the packet; is this correct? I note that you then describe a dynamic proxy that caches the received SR stack for a given flow so that it can be reapplied to the traffic coming back from the service; again, if you want to share that service across multiple service chains, is the assumption that you will cache the received SR stack on a per-packet basis so that you reapply the correct outgoing SR stack? Thanks, Jim -----Original Message----- From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Francois Clad (fclad) Sent: Wednesday, October 18, 2017 10:47 AM To: spring@ietf.org<mailto:spring@ietf.org> Subject: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt Hello, We have just submitted draft-clad-spring-segment-routing-service-chaining-00. Any feedback is welcome. Regards, Francois On 06/10/2017, 21:32, "internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote: A new version of I-D, draft-clad-spring-segment-routing-service-chaining-00.txt has been successfully submitted by Francois Clad and posted to the IETF repository. Name: draft-clad-spring-segment-routing-service-chaining Revision: 00 Title: Segment Routing for Service Chaining Document date: 2017-10-06 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-clad-spring-segment-routing-service-chaining-00.txt Status: https://datatracker.ietf.org/doc/draft-clad-spring-segment-routing-service-chaining/ Htmlized: https://tools.ietf.org/html/draft-clad-spring-segment-routing-service-chaining-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-clad-spring-segment-routing-service-chaining-00 Abstract: This document defines data plane functionality required to implement service segments and achieve service chaining with MPLS and IPv6, as described in the Segment Routing architecture. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. The IETF Secretariat _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
