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. On Thu, Jun 19, 2014 at 3:22 AM, Xuxiaohu <xuxia...@huawei.com> wrote: > Hi Robert, > >> -----Original Message----- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Robert Raszuk >> Sent: Wednesday, June 18, 2014 8:06 PM >> To: Xuxiaohu >> Cc: <spring@ietf.org> >> Subject: Re: [spring] FW: New Version Notification for >> draft-xu-spring-sfc-use-case-01.txt >> >> 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. > > 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 > >> Therefor I do question need for this set of new drafts. >> >> Best, >> R. >> >> >> >> >> >> On Wed, Jun 18, 2014 at 9:50 AM, Xuxiaohu <xuxia...@huawei.com> wrote: >> > 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 >> >> _______________________________________________ >> 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
