Re: [spring] New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt
Hi Francois, Thank you for these clarifications; couple of comments inline.. From: Francois Clad (fclad) [mailto:fc...@cisco.com] Sent: Thursday, October 19, 2017 12:43 PM To: James N Guichard <james.n.guich...@huawei.com> Cc: spring@ietf.org Subject: Re: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt 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 Jim> I did not mention NSH as I was not interested in a comparison but seeing as you bring it up :) ... NSH theoretically can be used for both traffic engineering and service chaining; the former just requires a path that consists of SFFs so the implication that NSH forces a different encapsulation to satisfy the traffic engineering use case is simply not true. 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) Jim> okay, thank you for the clarification Jim 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
Re: [spring] New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt
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
Re: [spring] New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt
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 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" <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. The IETF Secretariat ___ 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