Subject: [sfc] comments on draft-song-sfc-legacy-sf-mapping-03

From: Dave Dolson <[email-masked]>
Date: Sat, 8 Nov 2014 15:10:07 +0000

Haibin,
Did you consider, for layer2-transparent devices:

-          Some classes of SF may need to not only modify packets but also inject them (for example a transparent cache sending content from its disk)

-          Some classes of SF may need to inject a packet in the opposite direction of a received packet (for example a firewall responding to a TCP SYN with a RST).

How would the non-SFC-aware layer2-transparent devices behave when injecting or responding to packets within a TCP session?
I believe it is common for these devices to re-use layer2 addresses that were seen earlier on the TCP session.
For example, when responding to a SYN with RST, we would expect the Ethernet source/dest to be reversed.

It seems to me that these behaviors would rule out any sort of per-packet approach because the SFF would not recognize the injected packets.

Furthermore, I don't think your "layer2 MAC address" scheme works in this case, as currently written using the source address.

The VLAN family of approaches seems robust to the above behaviors (if supported by the transparent SF).
The 5-tuple approach also seems fairly robust against those behaviors, assuming state doesn't time out too quickly (e.g., there may be spontaneous TCP retransmissions after several seconds).

The multi-tenant issues with the 5-tuple approach could be addressed by adding more fields to the tuple. E.g., add VLAN to make 6-tuple.

David Dolson
Senior Software Architect
Sandvine

---

From: "Songhaibin (A)" <[email-masked]>
Date: Tue, 11 Nov 2014 07:55:35 +0000

Dave,

Sorry for the late response. See inline.

Best Regards!
-Haibin

From: Dave Dolson [mailto:[email-masked]] 
Sent: Saturday, November 08, 2014 11:10 PM
To: Songhaibin (A)
Cc: [email-masked]
Subject: comments on draft-song-sfc-legacy-sf-mapping-03

Haibin,

[Haibin]This is a very good question. I did consider the former case (although have not documented it in the draft), but indeed have not considered the latter case. 

For the former case, if it is a SFC aware service function instance, then service function instance needs to encapsulate the new packets with the same encapsulation with the related received packets.  If it is a SFC unaware service function instance, then SFC proxy needs to know how to co-relate the new packet with the original packet, and it could be manually configured in the SFC proxy.

>It seems to me that these behaviors would rule out any sort of per-packet approach because the SFF would not recognize the injected packets.

[Haibin] I think when you say SFF, you actually mean SFC proxy.  You are right that SFC proxy would not recognize the injected packets. So you mean with unchanged layer 2 addresses, and new packets generated with SF instance, then SFC proxy cannot tell the packets from each other. Is my understanding right? And here is my consideration for it: First, it depends on whether we allow a per packet meta data in the SFC architecture. If we allow it, then we must solve the problem on how to correlate the metadata with the original packet in a SFC proxy. Second, assume that we allow it, then SFC proxy must write something down (when receive packets from SFF) that can be later to recognize the packet (when receive packets from the SF instance). And it is also possible a SFC proxy could be configured to "know" the SF instances it is attached to. As "MAC address" could not work to recognize the original packet, then SFC proxy needs to use some other additional fields for it IMO.

What do you think?

>Furthermore, I don't think your "layer2 MAC address" scheme works in this case, as currently written using the source address.

[Haibin] Agree.

[Haibin] Assume there is no per packet meta data. Then I agree. By the way, if there is any consensus on whether or not allow per packet meta data in the WG?

>The multi-tenant issues with the 5-tuple approach could be addressed by adding more fields to the tuple. E.g., add VLAN to make 6-tuple.

[Haibin] Right. It could be.

Thank you very much. It is indeed a question that is needed to think carefully and documented in the draft.

Best Regards!
-Haibin

David Dolson