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

2017-10-19 Thread James N Guichard 
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 
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 
> 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
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" 
> 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

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

2017-10-19 Thread Francois Clad (fclad) 
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 
> 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
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" 
> 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

[spring] Slots requests for SPRING WG session - IETF 100 - Singapore

2017-10-19 Thread Martin Vigoureux 

All,

it is time we start building the SPRING WG agenda for Singapore.
The IETF agenda (still preliminary) is available at:
https://datatracker.ietf.org/meeting/100/agenda.html

The SPRING WG session (1h30) is scheduled on
Wednesday, November 15th, 2017 / Afternoon session II / 15:20-16:50 
(local time)


Please send us your request for a presentation slot, indicating
draft name, speaker, and desired duration (covering presentation and
discussion).

Please send the requests no later than the 30th of October.
Thank you

M

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring