Subject: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

From: "Francois Clad (fclad)" <[email-masked]>
Date: Wed, 18 Oct 2017 14:46:42 +0000

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, "[email-masked]" <[email-masked]> 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

---

From: James N Guichard <[email-masked]>
Date: Wed, 18 Oct 2017 18:04:26 +0000

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:[email-masked]] On Behalf Of Francois Clad (fclad)
Sent: Wednesday, October 18, 2017 10:47 AM
To: [email-masked]
Subject: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

Hello,

Any feedback is welcome.

Regards,
Francois

    

    Abstract:

    
    
    The IETF Secretariat

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Thu, 19 Oct 2017 16:43:29 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Francois,

Thanks,

Jim

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Francois Clad (fclad)
Sent: Wednesday, October 18, 2017 10:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

Hello,

Any feedback is welcome.

Regards,
Francois

On 06/10/2017, 21:32, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

   Abstract:

   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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: James N Guichard <[email-masked]>
Date: Thu, 19 Oct 2017 16:59:05 +0000

Hi Francois,

Thank you for these clarifications; couple of comments inline..

From: Francois Clad (fclad) [mailto:[email-masked]]
Sent: Thursday, October 19, 2017 12:43 PM
To: James N Guichard <[email-masked]>
Cc: [email-masked]
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.

Jim> okay, thank you for the clarification

Jim

Thanks,
Francois

Hi Francois,

Thanks,

Jim

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Francois Clad (fclad)
Sent: Wednesday, October 18, 2017 10:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] FW: New Version Notification for draft-clad-spring-segment-routing-service-chaining-00.txt

Hello,

Any feedback is welcome.

Regards,
Francois

   Abstract:

   The IETF Secretariat