Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

From: "Jmh.direct" <[email-masked]>
Date: Mon, 21 Apr 2014 19:36:23 -0400

Without some firm of proxy any existing function will, if used in sfc, lose tge transport header and the sfc specific header.

Yours,
Joel

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: RE: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01 
From: "Zarny, Myo" <[email-masked]> 
To: "'Joel M. Halpern'" <[email-masked]>,"[email-masked]'" <[email-masked]> 
CC:  

Hi Joel,
 
Not sure about the comment about the need for proxying as a requirement for SFC. Not all service functions are of proxying kind. Even load balancers don't have to proxy--DSR for example. Firewalls perform permit/deny; they don’t proxy. Likewise with IDS/IPS. Etc. Etc. Shouldn’t we assume that service chains will consist of proxying and non-proxying kinds? Besides, I don’t read that the draft requires proxying, do you?
 
I’m not saying service function nodes can’t partake in SFC implementations—no need to stifle innovation. But do we need to require that service function nodes MUST understand SFC headers, for example? What happens to those that don’t? Are they all legacy? For many users who have invested in non-SFC-understanding equipment, that’s practically a non-starter. And it will likely slow adoption, IMO.
 
Regards,
 
-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: 21 April 2014 6:22 PM
To: Zarny, Myo [Tech]; [email-masked]'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01
 
I would prefer not to state that as a requirement.
Where practical, we do indeed want (even need) to support existing service funciton implementations.
But there will be some service functions which can not be proxied and which can not be placed into the middle of service chains.  Trying to solve 100% of the cases, if possible at all, will likely dramatically slow the work down.
 
Yours,
Joel M. Halpern
 
On 4/21/14, 6:03 PM, Zarny, Myo wrote:
> I like the requirements listed in 3.1.2.
>
> Shouldn’t we also call this out?
>
> ·SFC solutions SHOULD not require any service functions to participate
> in the implementation of SFCs.
>
> That is, service function nodes (LBs, proxys, FWs, etc.) need not
> understand anything about SFCs; they could just be performing as they
> are today. We could have service functions that partake in SFC
> implementations but they don’t need to be required to.
>
> Regards,
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* 18 April 2014 6:30 PM
> *To:* [email-masked]
> *Subject:* [sfc] Call for adoption of
> draft-haeffner-sfc-use-case-mobility-01
>
> Dear WG:
>
> This message begins a two week call for WG adoption of the document
> http://www.ietf.org/id/draft-haeffner-sfc-use-case-mobility-01.txt
> ending 2nd May 2014.
>
> Please respond to the SFC mailing list with any statements of approval
> or disapproval.
>
> Please note:
>
> 1.This is not WG Last Call. The document is not final, and the WG is
> expected to modify the document’s content until there is WG consensus
> that the content is solid. Therefore, please don’t oppose adoption
> just because you want to see changes to its content.
>
> 2.If you have objections to adoption of the document, please state
> your reasons why, and explain what it would take to address your concerns.
>
> 3.If you have issues with the content, by all means raise those issues
> and we can begin a dialog about how best to address them.
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 22 Apr 2014 09:52:18 -0400

I feel like the proxying you’re talking about is for some other SFC participating/enabling nodes.

My original comment was on service function nodes (like FWs, LBs), not SFC enabling nodes like forwarding or classification nodes. As far as I can see, the draft doesn’t—correctly IMO—require “proxying” service functions only (since it includes firewalls as one of the possible service functions).

Regards,

From: Jmh.direct [mailto:[email-masked]]
Sent: 21 April 2014 7:36 PM
To: Zarny, Myo [Tech]; [email-masked]; [email-masked]
Subject: RE: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01
Importance: Low

Yours,
Joel

-------- Original message --------
Subject: RE: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01
From: "Zarny, Myo" <[email-masked]<mailto:[email-masked]>>
To: "'Joel M. Halpern'" <[email-masked]<mailto:[email-masked]>>,"[email-masked]'" <[email-masked]<mailto:[email-masked]>>
CC:

Hi Joel,

Regards,

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: 21 April 2014 6:22 PM
To: Zarny, Myo [Tech]; [email-masked]'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

Yours,
Joel M. Halpern

On 4/21/14, 6:03 PM, Zarny, Myo wrote:
> *To:* [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Apr 2014 10:24:23 -0400

You asked for an added requirement that SFC SHOULD not require any 
changes to an SF for it to be used in SFC service chaining.

While a desirable goal, I expressed concern about it as a requirement.
My point is that structuring SFC so that all existing applications will 
work with it adds significant complexity to SFC.  Settling for 80% (or 
90% if we can) coverage, and recognizing that some applications will 
need to be change to be used as service functions in SFC, will make our 
job achievable.

We can use chain proxies in SFC to enable many existing applications to 
be used in SFC without modification.  This was an example of a tool we 
are likely to need to use to get even 80% coverage.  So I mentioned it 
to be clear that I was not trying to exclude that from our work.

I did not try to itemize what applications would not be supported.  I 
hope that the number of those is small.  But we will find out down the road.

Yours,
Joel

PS: It is always difficult for readers to be sure what we intend when we 
put a "should" in a requirements document.

On 4/22/14, 9:52 AM, Zarny, Myo wrote:
> My original comment was on /service function nodes/ (like FWs, LBs), not
> SFC enabling nodes like forwarding or classification nodes. As far as I
> can see, the draft doesn’t—correctly IMO—require “proxying” service
> functions only (since it includes firewalls as one of the possible
> service functions).
>
> Regards,
>
> *From:*Jmh.direct [mailto:[email-masked]]
> *Sent:* 21 April 2014 7:36 PM
> *To:* Zarny, Myo [Tech]; [email-masked]; [email-masked]
> *Subject:* RE: [sfc] Call for adoption of
> *Importance:* Low
> Without some firm of proxy any existing function will, if used in sfc,
> lose tge transport header and the sfc specific header.
>
> Yours,
>
> Joel
>
>
> From: "Zarny, Myo" <[email-masked] <mailto:[email-masked]>>
> To: "'Joel M. Halpern'" <[email-masked]
> <mailto:[email-masked]>>,"[email-masked]'" <[email-masked]
> <mailto:[email-masked]>>
> CC:
>
> Hi Joel,
>
> Not sure about the comment about the need for proxying as a requirement
> for SFC. Not all service functions are of proxying kind. Even load
> balancers don't have to proxy--DSR for example. Firewalls perform
> permit/deny; they don’t proxy. Likewise with IDS/IPS. Etc. Etc.
> Shouldn’t we assume that service chains will consist of proxying and
> non-proxying kinds? Besides, I don’t read that the draft requires
> proxying, do you?
>
> I’m not saying service function nodes can’t partake in SFC
> implementations—no need to stifle innovation. But do we need to require
> that service function nodes MUST understand SFC headers, for example?
> What happens to those that don’t? Are they all legacy? For many users
> who have invested in non-SFC-understanding equipment, that’s practically
> a non-starter. And it will likely slow adoption, IMO.
>
> Regards,
>
> But there will be some service functions which can not be proxied and
> which can not be placed into the middle of service chains.  Trying to
> solve 100% of the cases, if possible at all, will likely dramatically
> slow the work down.
>
> Yours,
>
> Joel M. Halpern
>
>> *To:[email-masked] <mailto:[email-masked]>
>
>>[email-masked] <mailto:[email-masked]>
>

---

From: "Zarny, Myo" <[email-masked]>
Date: Tue, 22 Apr 2014 11:38:02 -0400

You mean SFC proxies, I see. That clears up a lot.

I'm not proposing that all SFs NOT support SFC capabilities but that they not be required to support them. It may be, as you point out, that SFC solutions are simpler if SFs participate in the chain implementation. But shouldn't we also allow for SFC solutions that don't require SFs to participate? I don't think we need to close the door on that in this use cases document.

Regards,

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: 22 April 2014 10:24 AM
To: Zarny, Myo [Tech]; [email-masked]'
Subject: Re: [sfc] Call for adoption of draft-haeffner-sfc-use-case-mobility-01

You asked for an added requirement that SFC SHOULD not require any changes to an SF for it to be used in SFC service chaining.

While a desirable goal, I expressed concern about it as a requirement.
My point is that structuring SFC so that all existing applications will work with it adds significant complexity to SFC.  Settling for 80% (or 90% if we can) coverage, and recognizing that some applications will need to be change to be used as service functions in SFC, will make our job achievable.

We can use chain proxies in SFC to enable many existing applications to be used in SFC without modification.  This was an example of a tool we are likely to need to use to get even 80% coverage.  So I mentioned it to be clear that I was not trying to exclude that from our work.

I did not try to itemize what applications would not be supported.  I hope that the number of those is small.  But we will find out down the road.

Yours,
Joel

PS: It is always difficult for readers to be sure what we intend when we put a "should" in a requirements document.

On 4/22/14, 9:52 AM, Zarny, Myo wrote:
> My original comment was on /service function nodes/ (like FWs, LBs), 
> not SFC enabling nodes like forwarding or classification nodes. As far 
> as I can see, the draft doesn’t—correctly IMO—require “proxying” 
> service functions only (since it includes firewalls as one of the 
> possible service functions).
>
> Regards,
>
> Not sure about the comment about the need for proxying as a 
> requirement for SFC. Not all service functions are of proxying kind. 
> Even load balancers don't have to proxy--DSR for example. Firewalls 
> perform permit/deny; they don’t proxy. Likewise with IDS/IPS. Etc. Etc.
> implementations—no need to stifle innovation. But do we need to 
> require that service function nodes MUST understand SFC headers, for example?
> who have invested in non-SFC-understanding equipment, that’s 
> practically a non-starter. And it will likely slow adoption, IMO.
>
> Regards,
>