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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 3 Aug 2014 21:18:42 +0000

SFCers,

After Toronto, Joel and I have been working on resolving the key open discussion items, and incorporating all the input and feedback received thus into this document as the vehicle for a single SFC Architecture item to progress.

While we are still working on the document, we wanted to get a version out early to the WG to test the resolution to key open items, see what we might still be missing, and iterate.

Please review and let us know.

Thanks,

Carlos & Joel.

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-merged-sfc-architecture-01.txt
Date: August 3, 2014 at 5:15:58 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-01.txt
has been successfully submitted by Carlos Pignataro and posted to the
IETF repository.

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

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: Xuxiaohu <[email-masked]>
Date: Mon, 4 Aug 2014 08:17:55 +0000

Hi Carlos and Joel,

This revision looks much better. Thanks a lot for your excellent work.

However, it seems there are still a few places which may need further improvements.

1.    The following definition of network components looks a bit confused, IMHO. There is an analogy between the PE and the SFF. For PE,  it doesn't separately define the function of performing the VRF lookup/forwarding and the function of performing the tunnel encapsulation/decapsulation work. Hence it seems better to allow the SFF to be interpreted flexibly as a function or a device according to the specific context, just like the term of PE. In other words, there is no need for introduce the following term of Network Components. Otherwise, if you prefer to interpret the SFF as a function only, it seems better to give the device containing the SFF (as a function) a name, which would be useful for solution description.
4.5<http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.5>.  Network Components
   Underneath the SFF, there are components responsible for performing
   the overlay encapsulation/de-capsulation and forwarding of packets on
   the overlay network.  They may consult the SFC encapsulation or the
   inner payload of an incoming packet only in the necessary cases to
   achieve optimal forwarding in the network.

2.    The following definition of network service is never used in the whole doc. Therefore, why not remove it?

   Network Service:  An offering provided by an operator that is

        delivered using one or more service functions.  This may also be

        referred to as a composite service.  The term "service" is used

        to denote a "network service" in the context of this document.

3.    I think it' better to change the word "and" in the following sentence to "and/or". In other word, the SFC encapsulation could play the role of SFP selection, metadata sharing or both. In some cases where the SFP selection role has been accomplished somewhere else (see 4.3.1<http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.3.1>.  Transport Derived SFF), the only possible role of the SFC encapsulation is metadata-sharing. In some cases where no metadata is required to be shared, the only possible role of the SFC encapsulation is SFP selection.

"   The SFC encapsulation enables service function path selection and the

   sharing of metadata/context information.

4.    It seems that SF instance is a well understood term. Unfortunately, it has been removed.

5.    s/SDC/SFC

"Alternatively, a service provider may decide to exclude legacy

   service functions from an SDC domain.

6.    s/SF functions/SFs

according to the ordered set of SF functions

Best regards,
Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, August 04, 2014 5:19 AM
To: [email-masked]
Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 4 Aug 2014 14:39:29 +0000

Hi Xiaohu,

On Aug 4, 2014, at 4:17 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos and Joel,

Many thanks!

1.    The following definition of network components looks a bit confused, IMHO. There is an analogy between the PE and the SFF. For PE,  it doesn’t separately define the function of performing the VRF lookup/forwarding and the function of performing the tunnel encapsulation/decapsulation work. Hence it seems better to allow the SFF to be interpreted flexibly as a function or a device according to the specific context, just like the term of PE. In other words, there is no need for introduce the following term of Network Components. Otherwise, if you prefer to interpret the SFF as a function only, it seems better to give the device containing the SFF (as a function) a name, which would be useful for solution description.

I am not sure I understand this point. As you can see from Figure 3, the SFF interfaces down with the network overlay. That's what this paragraph is describing.

Maybe we should rename it to "Network Overlay and Network Components"?

We purposely are describing terms not used in this specific document, but that can be used in other documents, and that are necessary to understand SFC even when not used. You will remember that the WG (or pre-WG) had long discussions during chartering on what was a services and a network service. We do not want to lose the output of that.

3.    I think it’ better to change the word “and” in the following sentence to “and/or”. In other word, the SFC encapsulation could play the role of SFP selection, metadata sharing or both. In some cases where the SFP selection role has been accomplished somewhere else (see 4.3.1<http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.3.1>.  Transport Derived SFF), the only possible role of the SFC encapsulation is metadata-sharing. In some cases where no metadata is required to be shared, the only possible role of the SFC encapsulation is SFP selection.

“   The SFC encapsulation enables service function path selection and the

OK. I think this makes sense, but let me think it through a bit more. Thanks.

We scrubbed through "instance", and right now the doc only says things like "for instance, ", and not "SF instance.

5.    s/SDC/SFC

“Alternatively, a service provider may decide to exclude legacy

Ack. Thanks! Done.

6.    s/SF functions/SFs

Many thanks again!

Carlos.

Best regards,
Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Monday, August 04, 2014 5:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

SFCers,

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 4 Aug 2014 15:12:14 +0000

Xiaohu,

Please find an additional follow-up inline.

Hi Carlos and Joel,

Sorry I misunderstood where you were asking for the "and/or" to be inserted on this comment.

Section 4.1 clearly says:
   The SFC encapsulation provides explicit information used to identify
   the SFP.

And that's, to me, the key issue we want to preserve on the SFC Encapsulation.

If there is potential ambiguity in that first sentence, I'd suggest braking it up in two:

   The SFC encapsulation enables service function path selection. It also enables the
   potential sharing of metadata and/or context information.

Thanks,

Carlos.

5.    s/SDC/SFC

6.    s/SF functions/SFs

Best regards,
Xiaohu

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Dave Hood <[email-masked]>
Date: Mon, 4 Aug 2014 17:01:03 +0000

This document would be greatly improved by everywhere distinguishing class from instance, for example in the use of the acronyms SF, SFF, SFP. This distinction would permit some of the text to be removed or simplified.

One case where the instance terminology needs to be particularly clear is the discussion of symmetric traffic, in which the SF *instances* need to be the same, not just the SF *classes.* In the hybrid case, for example, the order may not be as important as assuring that particular instances be traversed in the return path. Likewise, if we don't care which instances are used, it's pretty much irrelevant whether return traffic happens to traverse the reversed sequence of SF classes as the forward direction. And if a flow needs to traverse the same SF twice, it matters whether it needs to be the same SF instance, or merely the same class.

A bit of taxonomy would help to clarify the terms: that an SFC [instance] represents a policy about which SF [classes] are applied to a flow, that an SFP [instance] represents an SFC constrained by some level of implementation considerations, as described in 2.3. The SFC is then nailed down by the rendered service path.

We also confuse network levels. An SFC domain is defined to be a network, but SFC encap is said not to be used for [infrastructure-level] network forwarding. Among other instances, see eg 4.3 item 1 "arrives ... from the network".

>From this perspective, the principle that the [SFC overlay] network is topologically independent from the [infrastructure-level] network is understandable, but needs to be refined: the overlay cannot do anything that is impossible in the underlay network. Perhaps 4.1 states the principle better: the SFC overlay network is independent of the underlying transport infrastructure (and if this is a key architectural principle, surely it belongs in clause 3; but see 4.3.1).

An SFC proxy is said to be a logical element. But all SFs are logical elements, are they not? The distinction needs to be more carefully drawn (or abandoned). A proxy is itself an SF, in composition with the non-SFC capable SF.

Lots more nits, but these are the main points I notice as I read through this.

Dave

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 6 Aug 2014 09:48:09 +0000

Hi Carlos,

In the case where the service path selection role is realized by other means than the service path information contained in the SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando-l3vpn-service-chaining-04, http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the role of metadata sharing.

Best regards,
Xiaohu

Thanks,

Carlos.

5.    s/SDC/SFC

6.    s/SF functions/SFs

Best regards,
Xiaohu

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 6 Aug 2014 15:30:01 +0000

Hi Xiaohu,

I understand what you are saying, but those individual I-Ds don't even target SFC.

>From an SFC Architecture document, we ought to align the editing of the architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>, which says: "Generic SFC Encapsulation: ... service-level data plane encapsulation format that: ... specifies the Service Function Path". That parses unambiguously to me.

Thanks,

Carlos.

On Aug 6, 2014, at 5:48 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

In the case where the service path selection role is realized by other means than the service path information contained in the SFC header, such as those approaches as defined in the following docs (http://tools.ietf.org/html/draft-rfernando-l3vpn-service-chaining-04,http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02), the SFC header just needs to accomplish the role of metadata sharing.

Best regards,
Xiaohu

Thanks,

Carlos.

5.    s/SDC/SFC

6.    s/SF functions/SFs

Best regards,
Xiaohu

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 6 Aug 2014 12:45:22 -0400

Carlos,

You truncated some text from the charter. It also says, right after the
text you quoted:

     - communicates context information between nodes that implement
       service functions and Service Function Chains.

This is as much a part of the encapsulation as specifying the Service
Function Path. Thus the text in the architecture document should reflect
that.

Thanks,
Andy

On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>  From an SFC Architecture document, we ought to align the editing of the
> architecture to the WG charter <http://tools.ietf.org/wg/sfc/charters>,
> which says: "Generic SFC Encapsulation: ... service-level data plane
> encapsulation format that: ... specifies the Service Function Path". That
> parses unambiguously to me.
>
>  Thanks,
>
>  Carlos.
>
>  On Aug 6, 2014, at 5:48 AM, Xuxiaohu <[email-masked]> wrote:
>
>   Hi Carlos,
>
>  In the case where the service path selection role is realized by other
> means than the service path information contained in the SFC header, such
> as those approaches as defined in the following docs (
> http://tools.ietf.org/html/draft-rfernando-l3vpn-service-chaining-04,
> http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02), the SFC
> header just needs to accomplish the role of metadata sharing.
>
>  Best regards,
>  Xiaohu
>
>    3.    I think it’ better to change the word “and” in the following
> sentence to “and/or”. In other word, the SFC encapsulation could play the
> role of SFP selection, metadata sharing or both. In some cases where the
> SFP selection role has been accomplished somewhere else (see 4.3.1
> <http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.3.1>.
> Transport Derived SFF), the only possible role of the SFC encapsulation is
> metadata-sharing. In some cases where no metadata is required to be shared,
> the only possible role of the SFC encapsulation is SFP selection.
>
>    *From:* sfc [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Carlos Pignataro (cpignata)
> *Sent:* Monday, August 04, 2014 5:19 AM
> *To:* [email-masked]
> *Subject:* [sfc] Fwd: New Version Notification for
> draft-merged-sfc-architecture-01.txt
>
>
> SFCers,
>
> After Toronto, Joel and I have been working on resolving the key open
> discussion items, and incorporating all the input and feedback received
> thus into this document as the vehicle for a single SFC Architecture item
> to progress.
>
> While we are still working on the document, we wanted to get a version out
> early to the WG to test the resolution to key open items, see what we might
> still be missing, and iterate.
>
>   *From: *<[email-masked]>
>   *Subject: New Version Notification for
> draft-merged-sfc-architecture-01.txt*
>   *Date: *August 3, 2014 at 5:15:58 PM EDT
>   *To: *Joel Halpern <[email-masked]>, Carlos Pignataro <
> [email-masked]>, "Joel M. Halpern" <[email-masked]>, Carlos
> Pignataro <[email-masked]>
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
> Htmlized:
> http://tools.ietf.org/html/draft-merged-sfc-architecture-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-merged-sfc-architecture-01
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 6 Aug 2014 18:34:09 +0000

Andy,

I agree.

I actually truncated a lot (most of) the text from the charter, to minimize the relevant context quoted.

The first sentence in Section 4.1, SFC Encapsulation, currently reads:

   The SFC encapsulation enables service function path selection and the
   sharing of metadata/context information.

I proposed the following, it it is more clear and removes perceived ambiguity:

   The SFC encapsulation enables service function path selection. It also enables the
   sharing of metadata/context information when such metadata exchange is required.

The "when required" is because of Section 4.9 says:

   Some SFCs may not
   require metadata exchange.  SFC infrastructure enables the exchange
   of this shared data along the SFP.

But I think either the existing text or the longer version capture the charter points.

Thanks,

Carlos.

On Aug 6, 2014, at 12:45 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

You truncated some text from the charter. It also says, right after the text you quoted:

This is as much a part of the encapsulation as specifying the Service Function Path. Thus the text in the architecture document should reflect that.

Thanks,
Andy

On Wed, Aug 6, 2014 at 11:30 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xiaohu,

Thanks,

Carlos.

Hi Carlos,

Best regards,
Xiaohu

Thanks,

Carlos.

5.    s/SDC/SFC

6.    s/SF functions/SFs

Best regards,
Xiaohu

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 6 Aug 2014 15:29:54 -0400

Carlos,

Thanks, I prefer the longer version.

Cheers,
Andy

On Wed, Aug 6, 2014 at 2:34 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>  On Aug 6, 2014, at 12:45 PM, Andrew G. Malis <[email-masked]> wrote:
>
>  Carlos,
>
>> While we are still working on the document, we wanted to get a version
>> out early to the WG to test the resolution to key open items, see what we
>> might still be missing, and iterate.
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 7 Aug 2014 01:40:29 +0000

Sounds good, Andy. Thanks.

Updated in our working copy.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Aug 6, 2014, at 3:30 PM, "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Cheers,
Andy

On Wed, Aug 6, 2014 at 2:34 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Andy,

I agree.

   Some SFCs may not

Thanks,

Carlos.

Carlos,

Thanks,
Andy

Thanks,

Carlos.

Hi Carlos,

Best regards,
Xiaohu

Thanks,

Carlos.

5.    s/SDC/SFC

6.    s/SF functions/SFs

Best regards,
Xiaohu

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 7 Aug 2014 02:12:49 +0000

Hi Carlos and SFCers,

I just noticed that the WG charter also says : "...The WG will examine existing identifier schemes, if there is a need for such identifiers in the context of the Generic SFC encapsulation, before defining any new identifier scheme...." Hence, does it mean the SFC approaches as defined in those individual I-Ds, especially the SPRING-based SFC approach (http://www.ietf.org/proceedings/90/slides/slides-90-spring-5.pdf), should be discussed in the SFC WG?

Best regards,
Xiaohu

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Wednesday, August 06, 2014 11:30 PM
To: Xuxiaohu
Cc: [email-masked]
Subject: Re: [sfc] New Version Notification for draft-merged-sfc-architecture-01.txt

Hi Xiaohu,

Thanks,

Carlos.

Hi Carlos,

Best regards,
Xiaohu

Thanks,

Carlos.

5.    s/SDC/SFC

6.    s/SF functions/SFs

Best regards,
Xiaohu

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

---

From: Alla Goldner <[email-masked]>
Date: Mon, 11 Aug 2014 08:56:23 +0000

Dear Carlos, Joel, all,

Thanks for providing this merged architecture document!

According to the model in figure 3 and section 4.5, the network (underlay) components are responsible for:
*         Finding the network path to reach the next SF (next SFF) in the SFP.
*         Encapsulate/de-capsulate the underlay network transport.

Section 4.3 (SFF) contradicts this and says the network encapsulation/de-capsulation is done by the SFF.

I believe that the section 4.3 should be fixed in this regard. The reason is that network transport functions should not necessarily be coupled with the SFF.

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 Carlos Pignataro (cpignata)
Sent: Monday, August 04, 2014 12:19 AM
To: [email-masked]
Subject: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

SFCers,

Thanks,

Carlos & Joel.
Begin forwarded message:

Abstract:

The IETF Secretariat

##############################################################################################
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: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Aug 2014 10:03:01 -0400

I would say instead that we need to fix section 4.5, to make it clear 
that the SFF is responsible for the encaps  decaps, while the network 
uses the outer encapsulation for its forwarding.

Yours,
Joel

On 8/11/14, 4:56 AM, Alla Goldner wrote:
> According to the model in figure 3 and section 4.5, the network
> (underlay) components are responsible for:
>
> •         Finding the network path to reach the next SF (next SFF) in
> the SFP.
>
> •         Encapsulate/de-capsulate the underlay network transport.
>
> Section 4.3 (SFF) contradicts this and says the network
> encapsulation/de-capsulation is done by the SFF.
>
> I believe that the section 4.3 should be fixed in this regard. The
> reason is that network transport functions should not necessarily be
> coupled with the SFF.
>
> 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 *Carlos Pignataro
> (cpignata)
> *Sent:* Monday, August 04, 2014 12:19 AM
> *To:* [email-masked]
> thus into this document as the vehicle for a single SFC Architecture
> item to progress.
>
> out early to the WG to test the resolution to key open items, see what
> we might still be missing, and iterate.
>
> *From: *<[email-masked] <mailto:[email-masked]>>
>
> *Subject: New Version Notification for draft-merged-sfc-architecture-01.txt*
>
> *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:01
> Title:Service Function Chaining (SFC) Architecture
> Document date:2014-08-03
> Group:Individual Submission
> Pages:25
> URL:
> ------------------------------------------------------------------------
> 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: Mon, 11 Aug 2014 14:44:23 +0000

Dear Joel, all,

One of the motivations of SFC is be agnostic to the underlay transport network.
When you couple the SFF with the encapsulation/de-capsulation process it has to be aware of the network transport and it has to be capable to support different types of transport protocols.
For me it doesn't make too much sense and it makes the SFF very complex.
I think that a cleaner architecture is to have the SFF handle the SFC tasks and handle the SFC encapsulations (that is the metadata and SFC headers) but leave the transport to be handled by the network layer which can be any type of network.

Best regards,

Alla Goldner
[email-masked] 
www.allot.com

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 5:03 PM
To: Alla Goldner; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

I would say instead that we need to fix section 4.5, to make it clear that the SFF is responsible for the encaps  decaps, while the network uses the outer encapsulation for its forwarding.

Yours,
Joel

On 8/11/14, 4:56 AM, Alla Goldner wrote:
> discussion items, and incorporating all the input and feedback 
> received thus into this document as the vehicle for a single SFC 
> Architecture item to progress.
>
> Carlos Pignataro <[email-masked] <mailto:[email-masked]>>, 
> "Joel M. Halpern" <[email-masked] <mailto:[email-masked]>>, 
> Carlos Pignataro <[email-masked] <mailto:[email-masked]>>
>
>
> Title:Service Function Chaining (SFC) Architecture Document 
> date:2014-08-03 Group:Individual Submission
> Pages:25
> URL:
> 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
>
> ----------------------------------------------------------------------
> -- 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: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Aug 2014 10:46:24 -0400

That is how we had drawn the figure before.  And described the functions.
The problem is that this creates an interface between a network 
component and the SFF which can not exist visibly.  There is no way I 
know of to ship the packets between those two.

So the Encaps / decaps has to be co-located with the SFF.
This archtiecture tries not to get into the internal structure of the 
logical components or to describe separately components that must be 
co-located.  Some architectures do describe that.

Yours,
Joel

On 8/11/14, 10:44 AM, Alla Goldner wrote:
>> --

---

From: Alla Goldner <[email-masked]>
Date: Mon, 11 Aug 2014 15:22:23 +0000

Dear Joel, all,

SFF and transport network connectivity point need to be co-located (this is not mandatory but makes sense).
This means that a simple L2 connectivity between SFF and the network connectivity point can be used as this interface.
That can be some VLAN or VXLAN or any other L2 protocol. This shouldn't impose a big overhead on the SFF.

Also, the same interface you are talking about should exist also between SFF and SF proxy.
So if we already need to solve it there, we can use it between SFF and network component.

I strongly believe we should decouple network transport functions from the SFF and thus correct the section 4.3.

Best regards,

Alla Goldner

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 5:46 PM
To: Alla Goldner; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

That is how we had drawn the figure before.  And described the functions.
The problem is that this creates an interface between a network component and the SFF which can not exist visibly.  There is no way I know of to ship the packets between those two.

So the Encaps / decaps has to be co-located with the SFF.
This archtiecture tries not to get into the internal structure of the logical components or to describe separately components that must be co-located.  Some architectures do describe that.

Yours,
Joel

On 8/11/14, 10:44 AM, Alla Goldner wrote:
> Director of Mobile Technologies and Standards Allot Communications Tel 
> +972 9 7619251 Cell +972 54 2493985 Fax +972 9 7443626 
> [email-masked] www.allot.com
>
>
>
>
>
>> While we are still working on the document, we wanted to get a 
>> version out early to the WG to test the resolution to key open items, 
>> see what we might still be missing, and iterate.
>>
>> *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]>>
>>
>>
>> http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-01.
>> t
>> xt
>> Status:
> ######################################################################
> ######################## This message is intended only for the 
> designated recipient(s).It may contain confidential or proprietary information.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Aug 2014 11:25:07 -0400

Part of my problem is that the SFF has the information about what the 
next SFF.  (Even if the SFP allows only one next-SFF, it is the current 
SFF who knows what that is.  And if the decision is delegated, it is 
delegated to the SFF. )  But if the Encaps is not part of the SFF, then 
the SFF has no way to express that decision.  Even an Ethernet link does 
not handle it.

I need to check the text on SF Proxy, but I usually think of that as a 
more-specialized SFF, not as something separate from the SFF.

Yours,
Joel

On 8/11/14, 11:22 AM, Alla Goldner wrote:
>> ########################

---

From: Ron Parker <[email-masked]>
Date: Mon, 11 Aug 2014 18:29:21 +0000

Alla,

I'm trying to clarify, in my mind, the distinction of network encapsulation and network transport.   For reasons that Joel states, I feel the transport encapsulation and de-encapsulation must happen at the SFF (i.e., the SFF terminates the transport tunnels).   The networking path followed by those transport tunnels is based on the network switching/routing behavior and need not be visible to the SFF.    In an SDN overlay type of network, the SFF would be the Virtual Tunnel Endpoint (VTEP) in this way of thinking.   

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Monday, August 11, 2014 11:22 AM
To: Joel M. Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

Dear Joel, all,

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] www.allot.com

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 5:46 PM
To: Alla Goldner; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

Yours,
Joel

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 12 Aug 2014 00:40:48 +0000

+1

Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
> Sent: Tuesday, August 12, 2014 2:29 AM
> To: Alla Goldner; Joel M. Halpern; Carlos Pignataro (cpignata); [email-masked]
> I'm trying to clarify, in my mind, the distinction of network encapsulation and
> network transport.   For reasons that Joel states, I feel the transport
> encapsulation and de-encapsulation must happen at the SFF (i.e., the SFF
> terminates the transport tunnels).   The networking path followed by those
> transport tunnels is based on the network switching/routing behavior and need
> not be visible to the SFF.    In an SDN overlay type of network, the SFF would
> be the Virtual Tunnel Endpoint (VTEP) in this way of thinking.
> 
>    Ron
> 
> 
> This means that a simple L2 connectivity between SFF and the network
> connectivity point can be used as this interface.
> Director of Mobile Technologies and Standards Allot Communications Tel +972 9
> 7619251 Cell +972 54 2493985 Fax +972 9 7443626 [email-masked]
> www.allot.com
> 
> 
> 
> 
> 
> The problem is that this creates an interface between a network component and
> the SFF which can not exist visibly.  There is no way I know of to ship the
> packets between those two.
> 
> This archtiecture tries not to get into the internal structure of the logical
> components or to describe separately components that must be co-located.
> Some architectures do describe that.
> 
> Yours,
> Joel
> 
> > When you couple the SFF with the encapsulation/de-capsulation process it has
> to be aware of the network transport and it has to be capable to support
> different types of transport protocols.
> > I think that a cleaner architecture is to have the SFF handle the SFC tasks and
> handle the SFC encapsulations (that is the metadata and SFC headers) but leave
> the transport to be handled by the network layer which can be any type of
> network.
> >
> > Best regards,
> >
> >
> > Alla Goldner
> > I would say instead that we need to fix section 4.5, to make it clear that the SFF
> is responsible for the encaps  decaps, while the network uses the outer
> encapsulation for its forwarding.
> >
> > Yours,
> > Joel
> >

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 12 Aug 2014 01:30:43 +0000

Hi Joel,

> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Monday, August 11, 2014 11:25 PM
> Part of my problem is that the SFF has the information about what the next SFF.
> (Even if the SFP allows only one next-SFF, it is the current SFF who knows what
> that is.  And if the decision is delegated, it is delegated to the SFF. )  But if the
> Encaps is not part of the SFF, then the SFF has no way to express that decision.
> Even an Ethernet link does not handle it.
> 

Fully agree with the above points. That's the reason why I had suggested giving the entity containing the SFF or even the SF proxy components a name (see http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html)

Best regards,
Xiaohu

> > The problem is that this creates an interface between a network component
> and the SFF which can not exist visibly.  There is no way I know of to ship the
> >> When you couple the SFF with the encapsulation/de-capsulation process it
> has to be aware of the network transport and it has to be capable to support
> >> I would say instead that we need to fix section 4.5, to make it clear that the
> SFF is responsible for the encaps  decaps, while the network uses the outer
> >>> After Toronto, Joel and I have been working on resolving the key
> >>> open discussion items, and incorporating all the input and feedback
> >>> version out early to the WG to test the resolution to key open
> >>> items, see what we might still be missing, and iterate.
> >>>
> >>> has been successfully submitted by Carlos Pignataro and posted to
> >>> the IETF repository.
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> -
> >>> 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.
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> -
> >>> --
> >>>
> >>>
> >>>
> #############################################################
> ########
> >> # ######################## This message is intended only for the
> #############################################################
> ########
> >> #
> >> ########################
> >>
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 Aug 2014 22:39:18 -0400

If the encapsulation / decapsulation is part of the job of the SFF, then 
there is no need to discuss or name the node that happens to contain the 
SFF.  Avoiding an extra term keeps things simpler.

Yours,
Joel

On 8/11/14, 9:30 PM, Xuxiaohu wrote:
>> #########
>> #########

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 13 Aug 2014 01:37:06 +0000

> Sent: Tuesday, August 12, 2014 10:39 AM
> To: Xuxiaohu; Alla Goldner; Carlos Pignataro (cpignata); [email-masked]
> If the encapsulation / decapsulation is part of the job of the SFF, then there is no
> need to discuss or name the node that happens to contain the SFF.  Avoiding an
> extra term keeps things simpler.

Agree. It seems fine to just call the node containing the SFF component as an SFF node. BTW, should the SFC proxy be looked as an optional functionality of the SFF component or an optional component of the SFF node? Of course, If you want to deem the SFC proxy as a more-specialized SFF, it seems that Figure 3 should be updated accordingly and it seems better to call it as proxy-enabled SFF or something like that.

Best regards,
Xiaohu

> >> (Even if the SFP allows only one next-SFF, it is the current SFF who
> >> knows what that is.  And if the decision is delegated, it is
> >> delegated to the SFF. )  But if the Encaps is not part of the SFF, then the SFF
> has no way to express that decision.
> >> I need to check the text on SF Proxy, but I usually think of that as
> >> a more-specialized SFF, not as something separate from the SFF.
> >
> > Fully agree with the above points. That's the reason why I had
> > suggested giving the entity containing the SFF or even the SF proxy
> > components a name (see
> > http://www.ietf.org/mail-archive/web/sfc/current/msg02150.html)
> >
> > Best regards,
> > Xiaohu
> >
> >> Yours,
> >> Joel
> >>
> >>> SFF and transport network connectivity point need to be co-located
> >>> (this is not
> >> mandatory but makes sense).
> >>> That can be some VLAN or VXLAN or any other L2 protocol. This
> >>> shouldn't
> >> impose a big overhead on the SFF.
> >>>
> >>> Also, the same interface you are talking about should exist also
> >>> between SFF
> >> and SF proxy.
> >>> So if we already need to solve it there, we can use it between SFF
> >>> and network
> >> component.
> >>>
> >>> I strongly believe we should decouple network transport functions
> >>> from the
> >> SFF and thus correct the section 4.3.
> >>>
> >>> Best regards,
> >>>
> >>> Alla Goldner
> >>> component
> >> and the SFF which can not exist visibly.  There is no way I know of
> >> to ship the packets between those two.
> >>>
> >>>> One of the motivations of SFC is be agnostic to the underlay
> >>>> transport
> >> network.
> >> has to be aware of the network transport and it has to be capable to
> >> support different types of transport protocols.
> >> handle the SFC encapsulations (that is the metadata and SFC headers)
> >> but leave the transport to be handled by the network layer which can
> >> be any type of network.
> >>>>
> >>>> Best regards,
> >>>>
> >>>>
> >>>> Alla Goldner
> >> SFF is responsible for the encaps  decaps, while the network uses the
> >> outer encapsulation for its forwarding.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>> reason is that network transport functions should not necessarily
> >>>>> be coupled with the SFF.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> *Alla Goldner*
> >>>>>
> >>>>> open discussion items, and incorporating all the input and
> >>>>> feedback received thus into this document as the vehicle for a
> >>>>> single SFC Architecture item to progress.
> >>>>>
> >>>>> <mailto:[email-masked]>>, Carlos Pignataro
> >>>>> <[email-masked] <mailto:[email-masked]>>, "Joel M.
> >>>>> Halpern" <[email-masked] <mailto:[email-masked]>>,
> >>>>>       creation, and ongoing maintenance of Service Function Chains
> >>>>> (SFC)
> >> in
> >>>>> -- 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.
> >>>>>
> >>>> 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.
> >>>>
> >>
> >>> 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: Wed, 13 Aug 2014 01:52:03 +0000

Note also that since the SFC Network Forwarder (NF) was removed from revision -01, the "container" effectively equals the SFF only (the "entity containing the SFF" contains only the SFF).

Thanks,

Carlos.

On Aug 11, 2014, at 10:39 PM, Joel M. Halpern <[email-masked]> wrote:

> If the encapsulation / decapsulation is part of the job of the SFF, then there is no need to discuss or name the node that happens to contain the SFF.  Avoiding an extra term keeps things simpler.
> 
> Yours,
> Joel
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 13 Aug 2014 01:52:11 +0000

Hi, Xiaohu,

> Agree. It seems fine to just call the node containing the SFF component as an SFF node. BTW, should the SFC proxy be looked as an optional functionality of the SFF component or an optional componen…

Besides the name in Figure 3, we should look at the overall SFC Proxy text: 
http://tools.ietf.org/html/draft-merged-sfc-architecture-01#section-4.6

Anything in this section that you think does not match what was discussed about the SFC Proxy?

Thanks,

Carlos.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 13 Aug 2014 04:03:13 +0000

Hi Carlos,

> Sent: Wednesday, August 13, 2014 9:52 AM
> To: Xuxiaohu
> Cc: Joel M. Halpern; Alla Goldner; [email-masked]
> >> If the encapsulation / decapsulation is part of the job of the SFF,
> >> then there is no need to discuss or name the node that happens to
> >> contain the SFF.  Avoiding an extra term keeps things simpler.
> >
> > Agree. It seems fine to just call the node containing the SFF component as an
> SFF node. BTW, should the SFC proxy be looked as an optional functionality of
> the SFF component or an optional component of the SFF node? Of course, If
> you want to deem the SFC proxy as a more-specialized SFF, it seems that Figure
> 3 should be updated accordingly and it seems better to call it as proxy-enabled
> SFF or something like that.
> >
> 

If the SFC proxy is deemed as a special SFF, it seems unnecessary to repeat the functionalities of the SFF in the definition of SFC proxy. It just needs to describe the "special" parts compared to the normal SFF, for instance, strip the SFC header before sending the packet to the legacy SF while attaching the SFC header to the packet returned from one local SF before performing a lookup for next SF or SFF.

Best regards,
Xiaohu

> >>>> Part of my problem is that the SFF has the information about what
> >>>> the next
> >> SFF.
> >>>> (Even if the SFP allows only one next-SFF, it is the current SFF
> >>>> who knows what that is.  And if the decision is delegated, it is
> >>>> I need to check the text on SF Proxy, but I usually think of that
> >>>> as a more-specialized SFF, not as something separate from the SFF.
> >>>
> >>>> has to be aware of the network transport and it has to be capable
> >>>> to support different types of transport protocols.
> >>>> handle the SFC encapsulations (that is the metadata and SFC
> >>>> headers) but leave the transport to be handled by the network layer
> >>>> which can be any type of network.
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>>
> >>>>>> Alla Goldner
> >>>> SFF is responsible for the encaps  decaps, while the network uses
> >>>> the outer encapsulation for its forwarding.
> >>>>>>
> >>>>>> Yours,
> >>>>>> Joel
> >>>>>>
> >>>>>>> I believe that the section 4.3 should be fixed in this regard.
> >>>>>>> The reason is that network transport functions should not
> >>>>>>> necessarily be coupled with the SFF.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> *Alla Goldner*
> >>>>>>>
> >>>>>>> has been successfully submitted by Carlos Pignataro and posted
> >>>>>>> to the IETF repository.
> >>>>>>>
> >>>>>>> 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
> >>>>>>>
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> -
> >>>>>>> -
> >>>>>>> It may contain confidential or proprietary information. If you
> >>>>>>> are not the designated recipient, you may not review, copy or
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> -
> >>>>>>> -
> >>>>>>> --
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> designated recipient(s).It may contain confidential or
> >>>>>> proprietary
> >>>> information.
> >>>>> or distribute

---

From: Cathy Zhang <[email-masked]>
Date: Wed, 13 Aug 2014 18:11:38 +0000

Agree with Ron. I think the SFF has two key functionalities. One is doing the transport encapsulation in a way that the packet can be routed/switched through the network to the next SFF or SF Proxy. Given that the network could be of different types(could be L2 or L3, could be various tunnel mechanisms), the transport encapsulation could be different. The other is forwarding the packet to the selected connecting service function instance (A SFF could connect to multiple service function instances of the same type or different types). 

Thanks,
Cathy   

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, August 11, 2014 11:29 AM
To: Alla Goldner; Joel M. Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

Alla,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Alla Goldner
Sent: Monday, August 11, 2014 11:22 AM
To: Joel M. Halpern; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

Dear Joel, all,

Best regards,

Alla Goldner

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 5:46 PM
To: Alla Goldner; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [sfc] Fwd: New Version Notification for draft-merged-sfc-architecture-01.txt

Yours,
Joel