Subject: [sfc] Proposed SFC Architecture - SFC Proxy

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Aug 2014 13:12:30 -0400

In the recent discussion on the SFC Proxy, Carlos and I understood that 
the current text is unclear.  We need to fix it.

It turned out that even he and I had different perspectives on what it 
meant.  He has persuaded me that the cleanest approach is not the one I 
suggested earlier on the list.
So I am writing a bit of text to fix the proxy description (and then we 
will fix any other dangling references.)  Since the group is considering 
adoption of the document, we wanted to make sure that the proposal is 
one other folks can live with.

The approach is to treat the SFC Proxy as a logical element between the 
SFF and the SF.  When the SFF wants to send a packet to an SF which 
requires proxy support, the packet goes instead to the proxy.  The proxy 
does what is necessary, works with the SF however it needs to, and when 
the packet comes back puts things back together and hands them back to 
the SFF.

Just as we do not specify the delivery mechanism between the SFF and the 
SF, we will not specify the delivery mechanism between the SFF and the 
SFC Proxy or between the SFC Proxy and the SF.

I hope this is understandable and acceptable to folks.
Thank you,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 14 Aug 2014 18:08:37 +0000

Joel,

That approach sounds reasonable to me.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, August 14, 2014 1:13 PM
To: [email-masked]
Subject: [sfc] Proposed SFC Architecture - SFC Proxy

In the recent discussion on the SFC Proxy, Carlos and I understood that the current text is unclear.  We need to fix it.

It turned out that even he and I had different perspectives on what it meant.  He has persuaded me that the cleanest approach is not the one I suggested earlier on the list.
So I am writing a bit of text to fix the proxy description (and then we will fix any other dangling references.)  Since the group is considering adoption of the document, we wanted to make sure that the proposal is one other folks can live with.

The approach is to treat the SFC Proxy as a logical element between the SFF and the SF.  When the SFF wants to send a packet to an SF which requires proxy support, the packet goes instead to the proxy.  The proxy does what is necessary, works with the SF however it needs to, and when the packet comes back puts things back together and hands them back to the SFF.

Just as we do not specify the delivery mechanism between the SFF and the SF, we will not specify the delivery mechanism between the SFF and the SFC Proxy or between the SFC Proxy and the SF.

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 15 Aug 2014 01:08:08 +0000

Hi Joel,

The proposed approach looks understandable and acceptable to me. Thanks for this work.

Best regards,
Xiaohu

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Mon, 18 Aug 2014 18:35:30 +0000

Joel,

The approach you proposing is OK with me.

Andrew

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Aug 2014 17:15:26 -0500

Hi Joel,

When reading Section 4.6 on SFC Proxy, I got confused. I think that
the proxy function is explained in somewhat reverse order. It starts
by the traffic received from an SFF. Why? How does the SFF forward the
traffic to the proxy instead of to the SF?

I hope you can shed some light into this.

Regards,

Behcet

On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern <[email-masked]> wrote:
> In the recent discussion on the SFC Proxy, Carlos and I understood that the
> current text is unclear.  We need to fix it.
>
> So I am writing a bit of text to fix the proxy description (and then we will
> fix any other dangling references.)  Since the group is considering adoption
> of the document, we wanted to make sure that the proposal is one other folks
> can live with.
>
> The approach is to treat the SFC Proxy as a logical element between the SFF
> and the SF.  When the SFF wants to send a packet to an SF which requires
> proxy support, the packet goes instead to the proxy.  The proxy does what is
> necessary, works with the SF however it needs to, and when the packet comes
> back puts things back together and hands them back to the SFF.
>
> Just as we do not specify the delivery mechanism between the SFF and the SF,
> we will not specify the delivery mechanism between the SFF and the SFC Proxy
> or between the SFC Proxy and the SF.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Aug 2014 18:25:00 -0400

Traffic arrives at the SFF from elsewhere (a prior SFF or the ingress 
classifier.)
The SFF determines where to send it.  It hinks, in this case, that it is 
sending it to an SF.  However, the local information which tells the SFF 
how to do that (which is not specified by the architecture, and may or 
may not be in scope for the WG) actually directs it to send the traffic 
to the proxy.  The proxy takes care of the actual interaction with the 
legacy service function.  And then delivers the resulting packet back to 
the SFF, with the SFC encapsulation, as if it were an SFC-compliant 
service function.

Yours,
Joel

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Aug 2014 10:55:07 -0500

On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern <[email-masked]> wrote:
> sending it to an SF.  However, the local information which tells the SFF how
> to do that (which is not specified by the architecture, and may or may not
> be in scope for the WG) actually directs it to send the traffic to the
> proxy.  The proxy takes care of the actual interaction with the legacy
> service function.  And then delivers the resulting packet back to the SFF,
> with the SFC encapsulation, as if it were an SFC-compliant service function.
>

Sorry but I still don't understand.

Why not start with SFC-unaware SF?

Isn't this where the need for proxy arises?

Regards,

Behcet
>>> the
>>> will
>>> SFF
>>> SF,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Aug 2014 12:00:04 -0400

You ask "why not start with the SFC-unaware SF?".
The reason is that one of the points of the proxy is to send a packet to 
that SFC_unaware SF in such a way that the SF can understand the packet, 
evne though it does not understand the SFC encapsulation.
So we have to start with a packet arriving with the SFC encapsulation. 
And talk about the transforms necessary to deliver that to the 
SFC-unaware SF.
The problem to be dealt with is to avoid demanding modification of the 
existing SFC-unaware SF, so that SFC is deployable.

Yours,
Joel

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Aug 2014 11:52:04 -0500

I have a feeling that proxy is introduced to deal with packets coming
from specific attachment circuits such as VLANs, tunnel-based circuits
like GRE, VXLAN, etc. Proxy is not necessarily SF specific. So these
attachment circuits may contains various SFs such as firewalls, DPI,
LI, etc.

On Wed, Aug 20, 2014 at 11:00 AM, Joel M. Halpern <[email-masked]> wrote:
> So we have to start with a packet arriving with the SFC encapsulation. And
> talk about the transforms necessary to deliver that to the SFC-unaware SF.
>>> how
>>>>> proxy support, the packet goes instead to the proxy.  The proxy does
>>>>> what
>>>>> is

---

From: "Zarny, Myo" <[email-masked]>
Date: Wed, 20 Aug 2014 12:59:58 -0400

SFP itself should be SF chain specific. It is to proxy in front of non-SFC header-speaking SFs.

SFP could be handling VXLAN, GRE, etc. (whatever the transport encap mechanism) but it does need to strip off the SF header before forwarding the remaining traffic to be consumed by the SF.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: 20 August 2014 12:52 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] Proposed SFC Architecture - SFC Proxy

I have a feeling that proxy is introduced to deal with packets coming from specific attachment circuits such as VLANs, tunnel-based circuits like GRE, VXLAN, etc. Proxy is not necessarily SF specific. So these attachment circuits may contains various SFs such as firewalls, DPI, LI, etc.

On Wed, Aug 20, 2014 at 11:00 AM, Joel M. Halpern <[email-masked]> wrote:
> The reason is that one of the points of the proxy is to send a packet 
> to that SFC_unaware SF in such a way that the SF can understand the 
> packet, evne though it does not understand the SFC encapsulation.
> And talk about the transforms necessary to deliver that to the SFC-unaware SF.
>> On Tue, Aug 19, 2014 at 5:25 PM, Joel M. Halpern 
>> <[email-masked]>
>> wrote:
>>>
>>> The SFF determines where to send it.  It hinks, in this case, that 
>>> it is sending it to an SF.  However, the local information which 
>>> tells the SFF how to do that (which is not specified by the 
>>> architecture, and may or may not be in scope for the WG) actually 
>>> directs it to send the traffic to the proxy.  The proxy takes care 
>>> of the actual interaction with the legacy service function.  And 
>>> then delivers the resulting packet back to the SFF, with the SFC 
>>> encapsulation, as if it were an SFC-compliant service function.
>>>
>>
>>>> the proxy function is explained in somewhat reverse order. It 
>>>> starts by the traffic received from an SFF. Why? How does the SFF 
>>>> forward the traffic to the proxy instead of to the SF?
>>>>
>>>> On Thu, Aug 14, 2014 at 12:12 PM, Joel M. Halpern 
>>>> <[email-masked]>
>>>> wrote:
>>>>>
>>>>>
>>>>> In the recent discussion on the SFC Proxy, Carlos and I understood 
>>>>> that the current text is unclear.  We need to fix it.
>>>>>
>>>>> It turned out that even he and I had different perspectives on 
>>>>> what it meant.  He has persuaded me that the cleanest approach is 
>>>>> not the one I suggested earlier on the list.
>>>>> So I am writing a bit of text to fix the proxy description (and 
>>>>> then we will fix any other dangling references.)  Since the group 
>>>>> is considering adoption of the document, we wanted to make sure 
>>>>> that the proposal is one other folks can live with.
>>>>>
>>>>> The approach is to treat the SFC Proxy as a logical element 
>>>>> between the SFF and the SF.  When the SFF wants to send a packet 
>>>>> to an SF which requires proxy support, the packet goes instead to 
>>>>> the proxy.  The proxy does what is necessary, works with the SF 
>>>>> however it needs to, and when the packet comes back puts things 
>>>>> back together and hands them back to the SFF.
>>>>>
>>>>> Just as we do not specify the delivery mechanism between the SFF 
>>>>> and the SF, we will not specify the delivery mechanism between the 
>>>>> SFF and the SFC Proxy or between the SFC Proxy and the SF.
>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Aug 2014 13:05:33 -0400

a) Please do not use SFP as an abbreviation for SFC Proxy.  We already 
have SFP meaning something else entirely.

b) The SFC Proxy described in the archtiecture is not for the problem of 
handling transport mechanisms between SFF.  THe assumption of the work 
as described in the charter is that adjacent SFF will have a transport 
in common, and that the SFC Encapsulation provides a means for the SFF 
to get the needed information independent of the various transports.

c) The existing diagrams and text is very clear about the SFC Proxy 
being about support for SFC-unaware service functions.  If we ned other 
kinds of transforming functions, please spell out the problems, but do 
not re-purpose things which are solving important and distinct problems 
already.

Yours,
Joel

---

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 21 Aug 2014 01:15:04 +0000

SFC Proxy is used for translation between the legacy service functions and SFF. Since all service functions are middle boxes, so the traffic is not started from a SF instance. 

I agree that the architecture draft should not specify any detail of the SFC proxy translation process. You can look at the following draft for more details on the translation.
http://tools.ietf.org/html/draft-song-sfc-legacy-sf-mapping-02

Best Regards!
-Haibin

> Sent: Thursday, August 21, 2014 12:52 AM
> To: Joel M. Halpern
> Cc: [email-masked]
> I have a feeling that proxy is introduced to deal with packets coming from
> specific attachment circuits such as VLANs, tunnel-based circuits like GRE,
> VXLAN, etc. Proxy is not necessarily SF specific. So these attachment circuits
> may contains various SFs such as firewalls, DPI, LI, etc.
> 
> 
>

---

From: Nicolas BOUTHORS <[email-masked]>
Date: Fri, 22 Aug 2014 07:53:47 +0000

I understand and support this proposal when it comes to "legacy" SF working still as transparent middleboxes. 

There are however many Legacy SF which are not transparent, in which case I can see two options
1) consider that such Legacy SF always in effect terminate a chain
2) introduce the concept of Re-classification of the modified traffic, to identify the target chain and restore forwarding

The latter would seem preferable as it would also allow room for relaying metadata.

I am not sure if this should be seen as part of an SF-Proxy, or as an SFF function for "non transparent SF".

Nicolas

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 22 Aug 2014 09:44:20 -0400

Nicolas, the architecture already has provision for reclassification.
And we have been quite careful not to specify what techniques the proxy 
will or can use to do its job.  In the abstract it can use any technique 
up to and including intuition (if only we could make that work) to do 
its job.  So the architecture does not require that the legacy 
SFC-unaware service function be transparent.  Many likely techniques for 
building the proxy require specific kinds of transparency.

That is why we are not specifying how the proxy works.  My expectation 
is that there will be a range of proxy techniques, each used with a 
subset of sfc-unaware SFs.  Yes, deployment will be somewhat harder. 
Working around limitations is harder.

Also, I expect that there are some (I hope a very small portion) 
sfc-unaware SFs that are sufficiently difficult that the only practical 
solution will be for the vendor to upgrade their system.  But that is 
also not for the WG to mandate.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 27 Aug 2014 23:35:52 +0000

Joel, 

Agree with your description of SFC Proxy. 

Does the term "we" in your sentence below means this architecture draft? Or SFC as a whole? 

 " Just as we do not specify the delivery mechanism between the SFF and the SF, we will not specify the delivery mechanism between the SFF and the SFC Proxy or between the SFC Proxy and the SF."

Linda

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 27 Aug 2014 20:17:03 -0400

"We" means "this document", and I should probably have written it that way.
While I have opinions on what the work group can add value by doing 
later, it is not the job of this document to be prescriptive around that.

Yours,
Joel