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

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) <hongyu.li@huawei.com<mailto:hongyu.li@huawei.com>> wrote:

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:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Tuesday, August 26, 2014 3:15 AM
To: Reinaldo Penno (repenno)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-02.txt

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 <repenno@cisco.com<mailto:repenno@cisco.com>> wrote:

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:
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: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Subject: New Version Notification for draft-merged-sfc-architecture-02.txt
Date: August 22, 2014 at 12:59:13 PM EDT
To: Joel Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>, Carlos Pignataro <cpignata@cisco.com<mailto:cpignata@cisco.com>>, "Joel M. Halpern" <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>>, Carlos Pignataro <cpignata@cisco.com<mailto:cpignata@cisco.com>>

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

_______________________________________________

sfc mailing list

sfc@ietf.org<mailto:sfc@ietf.org>

https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc