Hi Robert, Thanks a lot for your comments. Please see my response inline.
> -----Original Message----- > From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert > Raszuk > Sent: Wednesday, June 18, 2014 2:59 PM > To: Xuxiaohu > Cc: <spring@ietf.org> > Subject: Re: [spring] FW: New Version Notification for > draft-xu-spring-sfc-use-case-01.txt > > 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. 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 > Best regards, > R. > > > > > > > On Wed, Jun 18, 2014 at 4:28 AM, Xuxiaohu <xuxia...@huawei.com> wrote: > > Hi all, > > > > This document describes a service function chaining use case for SPRING. Any > comments are welcome. > > > > Best regards, > > Xiaohu/Robin/Himanshu _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
