Subject: [sfc] legacy service function support

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 15 May 2014 08:34:19 +0000

Dear guys,

Problems on how to support legacy service function instances, especially non-transparent service function instances become important.
In the following draft
http://tools.ietf.org/id/draft-song-sfc-legacy-sf-mapping-01.txt
we describe some mapping methods for the terminating node (SFE in our draft) to terminate the SFC header and then send the packet to service function instance and then re-encapsulate SFC header to the original packet after receiving that packet from the service function instance.

But for non-transparent SFIs, using a mapping mechanism to identify the original SFC header become more complicated. One way might be using the control plane to get the packet header mapping relationship and then notify the terminating node (SFE), which helps SFE to identify the original SFC header. Any other thoughts on this?

Another concern is about whether there is per packet meta data. If there is, we need to identify each packet for the decapsulation and re-encapsulation. And for each packet, we need a way to identify it. 

But if there are SFIs doing packet combination or fragmentation, then what shall we do with the SFC header in the terminating node (SFE)? Combine the meta data part or what?

I also noticed that a new section 7 of http://tools.ietf.org/id/draft-quinn-sfc-arch-05.txt has a brief introduction of legacy SFI support. And in another architecture draft http://tools.ietf.org/id/draft-jiang-sfc-arch-01.txt, it also mentions about legacy service function support. I think people agree that the legacy SFI support is in scope of the architecture and the next step work.

Best Regards!
-Haibin