Hi Haibin, Actually my comments were in regards to non transparent SF (your section 3.2).
And honestly I am not consider those as legacy. IMO even modern service nodes should not be forced to "handle" SF headers. So much more focus should be made to make the solutions well understood as those directly have great impact on the entire network control plane side. Simply stating removing all the packet/flow state from the network is not possible. Cheers, R. On Wed, Apr 23, 2014 at 9:06 AM, Songhaibin (A) <[email protected]> wrote: > Hi, > > > -----Original Message----- >> From: sfc [mailto:[email protected]] On Behalf Of Robert Raszuk >> Sent: Tuesday, April 22, 2014 3:28 PM >> To: Xuxiaohu >> Cc: [email protected]; Ron Parker; [email protected] >> Subject: Re: [sfc] 答复: Why Transport Dependence is deemed as a >> problem?//re: I-D Action: draft-ietf-sfc-problem-statement-04.txt >> >> > [Xiaohu] Your observation is correct. The SF proxy must strip the NSH >> > and the >> SR header before sending the packets to the directly attached legacy service >> functions. When the packets was returned by service functions, the SF proxy >> must reimpose those headers on the packets. Meanwhile, the SF proxy must >> decrease the service index value by 1. >> > >> >> Good so we agree on that point. >> >> What actually worries me a bit that to "reimpose" you need to do full >> classification again - just like you do it on all ingress nodes. >> >> Moreover how you reimpose could be also a function of service product. > > Actually we have a draft to talk about the legacy support. First, things have > to be classified according to whether the legacy service function instance is > transparent or not. Then if it is transparent, you can use different fields > in the packet to map to service header and then retrieval it again. If not, > things become much more complicated. Here is the link for the draft. > https://datatracker.ietf.org/doc/draft-song-sfc-legacy-sf-mapping/ > > BR, > -Haibin > >> >> >> > >> > That actually means that network needs to carry the state pretty much out >> > of >> band. Such state could be carried within routing protocols (today BGP is used >> for that in L3VPN case) or by new overlay control plane - same as is used to >> carry the metadata. >> > >> > >> > [Xiaohu] Did you mean that the metadata should be transferred through the >> control plane? >> >> >> How else would you carry it ? It's not data plane after all. Of course >> perhaps >> your definition of control plane = routing protocols, but I did not mean >> that. >> >> Control plane is just a information overlay of some form. Just like IN >> networks >> in well known telephone networks :) >> >> Cheers, >> R. >> >> _______________________________________________ >> sfc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
