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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
