Subject: [sfc] Map-Assisted SFC Proxy using LISP

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 5 Nov 2015 02:03:24 +0000

Hi,

Legacy service function support is obviously important in the SFC WG. I would like to request the authors of this draft to read draft-song-sfc-legacy-sf-mapping<http://tools.ietf.org/id/draft-song-sfc-legacy-sf-mapping-06.txt>. I think there is a lot of overlapping between these two drafts.

BR,
-Haibin

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Nov 2015 15:22:55 +0000

Haibin,

After reading your draft, I feel that it would benefit from splitting the notion of "non-transparent legacy service function" into separate distinctions based on the OSI model.

The service function may be "transparent" at L2, L3, L4, in which case you could, indeed, manipulate the MAC header to your advantage.  Such service functions would forward traffic at L2, either through MAC bridging and/or via a 2-member port-based VLAN.

Other service functions may be "transparent" at L3 and L4, only.   Such service functions may forward traffic based on IP forwarding tables which are populated statically or dynamically.

Theoretically, there are service functions may be "transparent" at L3, only (e.g., port translation without address translation), but I can't think of any practical examples (I'm excluding service functions that originate their own sympathetic flows in this analysis).

Lastly, we have service functions that are not "transparent" at all, such as those that perform SNAPT.   You do cover this case by explicitly excluding it, which is fine, I think.

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Songhaibin (A)
Sent: Wednesday, November 4, 2015 9:03 PM
To: [email-masked]
Subject: [sfc] Map-Assisted SFC Proxy using LISP

Hi,

BR,
-Haibin