Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 23 Aug 2014 20:47:12 +0000

SFC,

Please find below the email notice of a new revision of draft-merged-sfc-architecture.

Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02&url1=draft-merged-sfc-architecture-00

We still expect further changes to the document; but we also believe that this revision captures the key points and addresses the key open items, as planned in Toronto.

The key objective being to create a single document basis for the SFC architecture.

SFC Chairs,

We believe that this revision fulfills the next steps agreed in Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf).

This revision, while we expect changes, is now close enough that we think it makes sense for the WG to take it as the basis for the WG document to address the deliverable.

draft-merged-sfc-architecture-02 addressed the key points -- and we believe is ready to start a poll for adoption. Can you please initiate that WG adoption call for draft-merged-sfc-architecture-02?

Thanks,

Carlos & Joel.

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <[email-masked]<mailto:[email-masked]>>, Carlos Pignataro <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, Carlos Pignataro <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-merged-sfc-architecture-02.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

Name: draft-merged-sfc-architecture
Revision: 02
Title: Service Function Chaining (SFC) Architecture
Document date: 2014-08-22
Group: Individual Submission
Pages: 26
URL:            http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt
Status:         https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architecture-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02

Abstract:
  This document describes an architecture for the specification,
  creation, and ongoing maintenance of Service Function Chains (SFC) in
  a network.  It includes architectural concepts, principles, and
  components used in the construction of composite services through
  deployment of SFCs.  This document does not propose solutions,
  protocols, or extensions to existing protocols.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 25 Aug 2014 10:06:54 -0700

A couple of points about SFF definition. You mention "one or more 
connected service functions"

But in our implementation we have two types of SFFs that do not have SFs:

- A SFF that maps from one overlay to another, say, VXLAN to GRE
- A SFF that only has a classifier (no SFs in itself)

Where would they fit or how to to make sure the architecture can predict 
their usage?

thanks,

On 8/23/14 1:47 PM, Carlos Pignataro (cpignata) wrote:
> Full set of diffs from -00 (IETF90) to -02 (now) can be seen here: 
> http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-02&url1=draft-merged-sfc-architecture-00
>
> We still expect further changes to the document; but we also believe 
> that this revision captures the key points and addresses the key open 
> items, as planned in Toronto.
>
> We believe that this revision fulfills the next steps agreed in 
> Toronto (http://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf).
>
> This revision, while we expect changes, is now close enough that we 
> think it makes sense for the WG to take it as the basis for the WG 
> document to address the deliverable.
>
> draft-merged-sfc-architecture-02 addressed the key points -- and we 
> believe is ready to start a poll for adoption. Can you please initiate 
> that WG adoption call for draft-merged-sfc-architecture-02?
>
> Thanks,
>
> Carlos & Joel.
>
>
> Begin forwarded message:
>
>> *From: *<[email-masked] <mailto:[email-masked]>>
>> *Subject: * *New Version Notification for 
>> draft-merged-sfc-architecture-02.txt*
>> *Date: *August 22, 2014 at 12:59:13 PM EDT
>> *To: *Joel Halpern <[email-masked] 
>> <mailto:[email-masked]>>, Carlos Pignataro <[email-masked] 
>> <mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked] 
>> <mailto:[email-masked]>>, Carlos Pignataro <[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
>> Name:draft-merged-sfc-architecture
>> Revision:02
>> Title:Service Function Chaining (SFC) Architecture
>> Document date:2014-08-22
>> Group:Individual Submission
>> Pages:26
>> URL: 
>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-02.txt
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 25 Aug 2014 19:14:49 +0000

Reinaldo,

Thanks for the comment, good set of points. It does seem that the definition itself might be unnecessarily overly restrictive.

We could say "zero or more" or we could say "typically one or more", but I think it is better to spell out the function. Here's one more comprehensive proposal:

Old:
   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation.

New:
   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as for delivering traffic to
        a classifier or mapping out traffic to another SFF (in the same or
        different type of overlay).

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <[email-masked]<mailto:[email-masked]>> wrote:

A couple of points about SFF definition. You mention "one or more connected service functions"

Where would they fit or how to to make sure the architecture can predict their usage?

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

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

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

---

From: "Guy Meador III (meadorg)" <[email-masked]>
Date: Mon, 25 Aug 2014 20:13:46 +0000

Carlos,

While you are contemplating refinements to the definition of SFF, it would seem that SFF handling of traffic received from associated SF instances should also be mentioned here, too. Thoughts?

-Guy

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 25 Aug 2014 20:18:33 +0000

Guy,

Sure -- perhaps add ", handling traffic coming back from the SF"?

Thanks,

Carlos.

---

From: "Guy Meador III (meadorg)" <[email-masked]>
Date: Mon, 25 Aug 2014 20:20:51 +0000

That works, thanks.

On Aug 25, 2014, at 4:18 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
 wrote:

---

From: Naiming Shen <[email-masked]>
Date: Mon, 25 Aug 2014 13:36:11 -0700

Carlos,

One of the function of SFF could be to "de-encapsulate" the SFC, it can be the case of the last
hop on the SFC list, there may not be any SF associated with the SFF, but only to remove the service
transport and NSH header and to forward the packet normally.

Otherwise, after the last SF/SFF service function, service header and transport is removed,
the packet could route through the original "classifier" device again and it has no information
that packet has already gone through the SFC defined. This can cause looping. This of course
depends on where the location of the last SFF in the topology. One way to solve this can
be to define the SFC last item being the SFF which is the next-hop of the classifier device in
normal routing/forwarding to make sure the classifier device will to see this packet in original
format(without NSH and transport) twice.

thanks.
- Naiming

On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" <[email-masked]> wrote:

> On Aug 25, 2014, at 1:06 PM, Reinaldo Penno <[email-masked]> wrote:
> 
>>>> From: <[email-masked]>
>>>> To: Joel Halpern <[email-masked]>, Carlos Pignataro <[email-masked]>, "Joel M. Halpern" <[email-masked]>, Carlos Pignataro <[email-masked]>
>>>> 
>>>> 
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>> 
>>>> The IETF Secretariat
>>>> 
>>> 
>>> 
>>>

---

From: Naiming Shen <[email-masked]>
Date: Mon, 25 Aug 2014 13:47:29 -0700

> normal routing/forwarding to make sure the classifier device will to see this packet in original

typo, "… will not see this …"

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 25 Aug 2014 16:42:41 -0700

New definition looks good, leaves door open to naked SFFs.

thanks,

On 8/25/14 12:14 PM, Carlos Pignataro (cpignata) wrote:
> Reinaldo,
>
> Thanks for the comment, good set of points. It does seem that the 
> definition itself might be unnecessarily overly restrictive.
>
> We could say "zero or more" or we could say "typically one or more", 
> but I think it is better to spell out the function. Here's one more 
> comprehensive proposal:
>
> Old:
>>> that this revision captures the key points and addresses the key 
>>> open items, as planned in Toronto.
>>>
>>> believe is ready to start a poll for adoption. Can you please 
>>> initiate that WG adoption call for draft-merged-sfc-architecture-02?
>>>
>>> Thanks,
>>>
>>> Carlos & Joel.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> *Subject: **New Version Notification for 
>>>> <mailto:[email-masked]>>, "Joel M. Halpern" 
>>>> <[email-masked] <mailto:[email-masked]>>, Carlos 
>>>> Pignataro <[email-masked] <mailto:[email-masked]>>
>>>>
>>>>
>> [email-masked] <mailto:[email-masked]>

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Tue, 26 Aug 2014 00:57:54 +0000

Hi Carlos,

For the new definition, not sure “delivering traffic to a classifier” is the best way to say. In case the classifier is inside the current SFF, it is better to say the SFF re-/classify the traffic than deliver it to a classifier. In case the classifier is in the next SFF, the current SFF would only forward the traffic to the next SFF, without knowing or caring about if there is a classifier there.

Cheers,
Hongyu

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, August 26, 2014 3:15 AM
To: Reinaldo Penno (repenno)
Cc: [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt

Reinaldo,

Old:

New:

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

The IETF Secretariat

sfc mailing list

---

From: Alla Goldner <[email-masked]>
Date: Tue, 26 Aug 2014 11:12:53 +0000

Dear all,

I have the following comment:
“
If there are multiple choices, the SFF needs to preserve the property
   that all packets of a given flow are handled the same way, since the
   SF may well be stateful.
“

A service may need additional levels of “persistency” on top of a flow (e.g. – all flows related to the same subscriber /session due to e.g. security reasons, all flows related to the same application instance).

I believe it should also be reflected.

Best regards,

Alla Goldner
Director of Mobile Technologies and Standards
Allot Communications
Tel +972 9 7619251
Cell +972 54 2493985
Fax +972 9 7443626
[email-masked]<mailto:[email-masked]>
www.allot.com<http://www.allot.com/>

[291X55_signature (2)]

From: sfc [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Tuesday, August 26, 2014 3:58 AM
To: Carlos Pignataro (cpignata); Reinaldo Penno (repenno)
Cc: [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt

Hi Carlos,

Cheers,
Hongyu

Cc: [email-masked]<mailto:[email-masked]>

Reinaldo,

Old:

New:

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

The IETF Secretariat

sfc mailing list

##############################################################################################
This message is intended only for the designated recipient(s).It may contain confidential or proprietary information.
If you are not the designated recipient, you may not review, copy or distribute this message.
If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. 
Thank you.
##############################################################################################

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Aug 2014 22:47:37 +0000

Naiming,

You are right -- this is covered in Section 4.3, under "Terminating SFPs", we can massage the definition some more.

THanks,

Carlos.

On Aug 25, 2014, at 4:47 PM, Naiming Shen <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 25, 2014, at 1:36 PM, Naiming Shen <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

thanks.
- Naiming

On Aug 25, 2014, at 12:14 PM, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:

Reinaldo,

Old:

New:

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Aug 2014 22:56:39 +0000

Hi, Hongyu,

Thanks for this comment. Functionally, the Classifier is an architectural component different and separated from the SFF. This architecture does not prevent an implementation of a classifier and SFF in a discrete element and the delivery via an internal interface. But I believe architecturally is important to separate the functions of SFF versus the functions of a Classifier, instead of saying that a classifier can be "inside an SFF" or be "the next SFF".

Thanks,

Carlos.

On Aug 25, 2014, at 8:57 PM, Hongyu Li (Julio) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Cheers,
Hongyu

Reinaldo,

Old:

New:

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

The IETF Secretariat

sfc mailing list

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Aug 2014 22:58:13 +0000

Thank you, Guy.

On Aug 25, 2014, at 4:20 PM, Guy Meador III (meadorg) <[email-masked]<mailto:[email-masked]>> wrote:

That works, thanks.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Aug 2014 23:07:32 +0000

Alla,

That's a good callout. How about adding the following following the sentence you quoted?

"Additionally, the SFF may preserve the handling of packets based on other properties on top of a flow, such as a subscriber, session, or application instance identification."

Thanks,

Carlos.

On Aug 26, 2014, at 7:12 AM, Alla Goldner <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Best regards,

Alla Goldner

Hi Carlos,

Cheers,
Hongyu

Reinaldo,

Old:

New:

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

The IETF Secretariat

sfc mailing list

________________________________
This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you.

---

From: Alla Goldner <[email-masked]>
Date: Wed, 27 Aug 2014 03:46:17 +0000

Dear Carlos,

Thanks, I am fine with such a correction.

Best regards,

Alla Goldner

[291X55_signature (2)]

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Wednesday, August 27, 2014 2:08 AM
To: Alla Goldner
Cc: Hongyu Li (Julio); Reinaldo Penno (repenno); [email-masked]
Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-02.txt

Alla,

Thanks,

Carlos.

Dear all,

"
"

A service may need additional levels of "persistency" on top of a flow (e.g. - all flows related to the same subscriber /session due to e.g. security reasons, all flows related to the same application instance).

Best regards,

Alla Goldner

Hi Carlos,

For the new definition, not sure "delivering traffic to a classifier" is the best way to say. In case the classifier is inside the current SFF, it is better to say the SFF re-/classify the traffic than deliver it to a classifier. In case the classifier is in the next SFF, the current SFF would only forward the traffic to the next SFF, without knowing or caring about if there is a classifier there.

Cheers,
Hongyu

Reinaldo,

Old:

New:

WG, Reinaldo,

Thoughts?

Thanks,

Carlos.

thanks,

SFC Chairs,

Thanks,

Carlos & Joel.

Begin forwarded message:

Abstract:

The IETF Secretariat

sfc mailing list

---

From: Naiming Shen <[email-masked]>
Date: Wed, 27 Aug 2014 12:33:49 -0700

Carlos,

> You are right -- this is covered in Section 4.3, under "Terminating SFPs", we can massage the definition some more.

That would be good. Although looking at the Section 4.3 the "Terminating SFPs" paragraph, it's more about the
last SFF will strip the NSH transport/header then forwarding; I'm thinking more in the area with the last SFF can be
optionally inserted just for preventing the service looping in the network and there is no SF associated with it.

thanks.
- Naiming

> 
> THanks,
> 
> Carlos.
> 
> On Aug 25, 2014, at 4:47 PM, Naiming Shen <[email-masked]> wrote:
> 
>>