Subject: [spring] FW: New Version Notification for draft-xu-spring-sfc-use-case-01.txt

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Jun 2014 02:28:14 +0000

Hi all,

This document describes a service function chaining use case for SPRING. Any comments are welcome.

Best regards,
Xiaohu/Robin/Himanshu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 18, 2014 10:24 AM
> To: Lizhenbin; Xuxiaohu; Himanshu C. Shah; Xuxiaohu; Himanshu Shah;
> Lizhenbin
> Subject: New Version Notification for draft-xu-spring-sfc-use-case-01.txt
> 
> 
> A new version of I-D, draft-xu-spring-sfc-use-case-01.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-spring-sfc-use-case
> Revision:	01
> Title:		Service Function Chaining Use Case for SPRING
> Document date:	2014-06-18
> Group:		Individual Submission
> Pages:		6
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-spring-sfc-use-case-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-xu-spring-sfc-use-case/
> Htmlized:       http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-xu-spring-sfc-use-case-01
> 
> Abstract:
>    This document describes a particular use case for SPRING where the
>    Segment Routing mechanism is leveraged to realize the service path
>    layer functionality of the Service Function Chaining (i.e, steering
>    traffic through the service function path).
> 
> 
> 
> 
> 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: Robert Raszuk <[email-masked]>
Date: Wed, 18 Jun 2014 08:58:34 +0200

Hello Xu,

I have the following concern regarding your proposal.

The draft says:

   In addition, they have allocated and advertised
   segment IDs (SID) for the service functions they are offering.  For
   example, SN1 allocates and advertises an SID, i.e., SID(SF1) for
   service function SF1 while SN2 allocates and advertises an SID, i.e.,
   SID(SF2) for service function SF2.

However practically service function will never be global. Service
function will in vast majority of practical services cases at least
context based + customer based.

So If you are going to allocate per customer context a SID it means
that core network transport plane IGPs (which should be as lean as
possible) now becomes very quickly polluted with a lot of customer
information and customer state.

Without that you need to describe on what other fields SR SF nodes may
demux incoming traffic to different contexts.

My personal preference would be to keep all of this per customer
application service info outside of IGPs (no matter how well they can
scale today).

Best regards,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Jun 2014 07:50:02 +0000

Hi Robert,

Thanks a lot for your comments. Please see my response inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Wednesday, June 18, 2014 2:59 PM
> To: Xuxiaohu
> Cc: <[email-masked]>
> Subject: Re: [spring] FW: New Version Notification for
> draft-xu-spring-sfc-use-case-01.txt
> 
> Hello Xu,
> 
> However practically service function will never be global. Service function will in
> vast majority of practical services cases at least context based + customer based.

Service function (SF) SIDs are locally significant. In the MPLS-SR case, the SF SIDs are just local MPLS labels. Besides the SF SID, each SF would have an SF ID which is unique within the SFC-enabled domain. Therefore, each service node which is offering a given SF needs to allocate a locally significant SF SID (e.g., an MPLS label) for that SF and then advertise it (see http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-01).

> So If you are going to allocate per customer context a SID it means that core
> network transport plane IGPs (which should be as lean as
> possible) now becomes very quickly polluted with a lot of customer information
> and customer state.

Why does the SF SID need to be on the basis of per customer context? Shouldn't the customer context be carried somewhere else (e.g., in the SFC metadata). See the following text quoted from http://tools.ietf.org/html/draft-quinn-sfc-nsh-02#page-9) 

   Network shared context: metadata relevant to any network node such as
   the result of edge classification.  For example, application
   information, identity information or tenancy information can be
   shared using this context header.

> Without that you need to describe on what other fields SR SF nodes may demux
> incoming traffic to different contexts.
> 
> My personal preference would be to keep all of this per customer application
> service info outside of IGPs (no matter how well they can scale today).

If you don't want to use IGP to realize the service function auto-discovery, you can use other auto-discovery mechanisms, e.g., DNS.

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Jun 2014 14:05:35 +0200

Xu,

If you do not demux based on the segment ID to a particular service
context (and do that based on external information like metadata) then
your set of documents brings really nothing new and it just renames
Segment Node to be also called Service Node with bunch of new
terminology.

Therefor I do question need for this set of new drafts.

Best,
R.

On Wed, Jun 18, 2014 at 9:50 AM, Xuxiaohu <[email-masked]> wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 19 Jun 2014 01:22:06 +0000

Hi Robert,

> From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
> Sent: Wednesday, June 18, 2014 8:06 PM
> To: Xuxiaohu
> Cc: <[email-masked]>
> If you do not demux based on the segment ID to a particular service context
> (and do that based on external information like metadata) then your set of
> documents brings really nothing new and it just renames Segment Node to be
> also called Service Node with bunch of new terminology.

The locally significant Service Function SID is used to indicate a particular service function instance on a given service node (see http://tools.ietf.org/html/draft-xu-isis-service-function-adv-01). The service node itself is indicated by a node SID (this is not new).

Best regards,
Xiaohu

> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >> Robert Raszuk
> >> function will in vast majority of practical services cases at least context based
> + customer based.
> >
> > Service function (SF) SIDs are locally significant. In the MPLS-SR case, the SF
> SIDs are just local MPLS labels. Besides the SF SID, each SF would have an SF ID
> which is unique within the SFC-enabled domain. Therefore, each service node
> which is offering a given SF needs to allocate a locally significant SF SID (e.g., an
> MPLS label) for that SF and then advertise it (see
> http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-01).
> >
> > Why does the SF SID need to be on the basis of per customer context?
> > Shouldn't the customer context be carried somewhere else (e.g., in the
> > SFC metadata). See the following text quoted from
> > http://tools.ietf.org/html/draft-quinn-sfc-nsh-02#page-9)
> >
> >> Without that you need to describe on what other fields SR SF nodes
> >> may demux incoming traffic to different contexts.
> >>
> >> application service info outside of IGPs (no matter how well they can scale
> today).
> >
> > If you don't want to use IGP to realize the service function auto-discovery, you
> can use other auto-discovery mechanisms, e.g., DNS.
> >
> > Best regards,
> > Xiaohu
> >
> >> Best regards,
> >> R.
> >>
> >>
> >>
> >>
> >>
> >>
> >> > This document describes a service function chaining use case for
> >> > SPRING. Any
> >> comments are welcome.
> >> >
> >> > Best regards,
> >> > Xiaohu/Robin/Himanshu

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Jun 2014 07:59:58 +0200

Hi Xu,

As far as I can see there is no limitation in SR architecture that
service node must be a physical device or that its definition is
limited to be global per device.

Therefor it seems easy to define where needed virtual service node
with its SID or SIDs to indicate its different role in the network
(that includes functional role) even if this is all on the same
device.

The benefit for me is clear - to avoid new protocol extensions
required for what you call SFC use case.

Less complexity is always good.

Best,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 19 Jun 2014 06:17:11 +0000

> Sent: Thursday, June 19, 2014 2:00 PM
> To: Xuxiaohu
> Cc: <[email-masked]>
> As far as I can see there is no limitation in SR architecture that service node must
> be a physical device or that its definition is limited to be global per device.

It doesn't assume that service nodes must be physical devices at all. I don't know what you meant by saying " be global per device ".

> Therefor it seems easy to define where needed virtual service node with its SID
> or SIDs to indicate its different role in the network (that includes functional role)
> even if this is all on the same device.

Sure, it allows multiple service functions are located on the same device.

> The benefit for me is clear - to avoid new protocol extensions required for what
> you call SFC use case.

I don't understand what you meant. Without protocol extensions, how could service functions be discovered in my mind? 

> Less complexity is always good.

Sure.

Best regard,
Xiaohu

> >> context (and do that based on external information like metadata)
> >> then your set of documents brings really nothing new and it just
> >> renames Segment Node to be also called Service Node with bunch of new
> terminology.
> >
> > The locally significant Service Function SID is used to indicate a particular
> service function instance on a given service node (see
> http://tools.ietf.org/html/draft-xu-isis-service-function-adv-01). The service
> node itself is indicated by a node SID (this is not new).
> >
> > Best regards,
> > Xiaohu
> >
> >> SIDs are just local MPLS labels. Besides the SF SID, each SF would
> >> have an SF ID which is unique within the SFC-enabled domain.
> >> Therefore, each service node which is offering a given SF needs to
> >> allocate a locally significant SF SID (e.g., an MPLS label) for that
> >> SF and then advertise it (see
> >> >> So If you are going to allocate per customer context a SID it
> >> >> means that core network transport plane IGPs (which should be as
> >> >> lean as
> >> > Shouldn't the customer context be carried somewhere else (e.g., in
> >> > the SFC metadata). See the following text quoted from

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Jun 2014 08:23:45 +0200

> I don't understand what you meant. Without protocol extensions, how could
> service functions be discovered in my mind?

Via indirection. Do not flood those service functions in IGP. Just
create mapping in the higher abstraction layer (for example in
metadata) between service function and service nodes.

Analogy to BGP next hop :)

Otherwise we will be creating new protocol extensions and even new
data plane type codes when base SR architecture can be used as is for
it.

Thx,
r.