Subject: [sfc] Legacy SF

From: Youjianjie <[email-masked]>
Date: Wed, 13 Jul 2016 06:09:22 +0000

Dear all,

This document provides a mechanism between an SFC proxy and an SFC-unaware service function (herein termed "legacy SF"), to identify the SFC header associated with a packet that is returned from a legacy SF, without an SFC header being explicitly carried in the wired protocol between SFC proxy and legacy SF.

The motivation for supporting legacy SF is that existing service functions don't need to be upgraded to support SFC, removing one barrier to wide adoption of SFC.
https://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-07 

Your comments and suggestions are welcome!

Regards,
Jianjie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2016 09:35:38 -0400

I would describe the document you have provided somewhat differently.
It seems to be a survey of some of the known methods for building and 
operating a legacy SF Proxy.

There is no question that deployments will need such proxies.  The 
architecture identifies them for that reason.

What is unclear to me is whether such a survey is helpful to future 
implementors.   It may be.  On the other hand, the choice of technique 
depends very heavily on the behavior of the legacy SF to be supported.

Yours,
Joel

On 7/13/16 2:09 AM, Youjianjie wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 13 Jul 2016 22:37:13 +0000

Hello,

I agree with Joel¹s comment that it is non exhaustive methods that can be
used by the proxy to map pkts and flows belonging to SFC domain and non
SFC domain. The correlation can be also be made as part of the payload in
case HTTP proxy and other higher order proxy. HTTP proxies has been using
X-FORWARDED-FOR HDR for many years and similar method has already been
used to correlate flows etc.

I have few concerns/questions on the method also.

L2 transparent devices are not required to keep the pkt order at the
egress.  So lets assume a SF1 is connected via VLAN#10 and VLAN#20 for
pathID 0x1234.  If two pkts P1, P2 for two given flows with different HDR
values at the ingress (VLAN#10) is sent to SF1, and SF1 spits out  in
reverse order then what HDR gets put on P2 at egress. For most
implementation narrowing it down to flows etc are almost a requirement to
support correctness.

On 7/13/16, 6:35 AM, "sfc on behalf of Joel M. Halpern"
<[email-masked] on behalf of [email-masked]> wrote:

>> This document provides a mechanism between an SFC proxy and an
>>SFC-unaware service function (herein termed "legacy SF"), to identify
>>the SFC header associated with a packet that is returned from a legacy
>>SF, without an SFC header being explicitly carried in the wired protocol
>>between SFC proxy and legacy SF.
>>
>> The motivation for supporting legacy SF is that existing service
>>functions don't need to be upgraded to support SFC, removing one barrier
>>to wide adoption of SFC.