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

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Jul 2014 12:35:47 -0400

There has been a lot of discussion among the many authors of various 
archtiecture document proposals, and other commenters on these documents.
Carlos and I have tried to pull together what we think is a viable 
document based on the available input and issues.  We hope that it will 
help carry the working group forward.

(While the chairs requested that we try to do this, they did not decide 
what we picked, and the working group gets to decide if it is useful. 
Similarly while we took input from multiple places, we are to blame for 
any errors, confusions, etc.  The various other author teams have NOT 
agreed that this represents their work.  it is merely the best Carlos 
and I could manage.)

We look forward to discussion on the list, and in Toronto.

Yours,
Joel (and Carlos)

-------- Original Message --------
Subject: New Version Notification for draft-merged-sfc-architecture-00.txt
Date: Thu, 03 Jul 2014 06:32:22 -0700
From: [email-masked]
To: Joel Halpern <[email-masked]>, Carlos Pignataro 
<[email-masked]>, "Joel M. Halpern" <[email-masked]>, "Carlos 
Pignataro" <[email-masked]>

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

Name:		draft-merged-sfc-architecture
Revision:	00
Title:		Service Function Chaining (SFC) Architecture
Document date:	2014-07-03
Group:		Individual Submission
Pages:		22
URL: 
http://www.ietf.org/internet-drafts/draft-merged-sfc-architecture-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-merged-sfc-architecture/
Htmlized:       http://tools.ietf.org/html/draft-merged-sfc-architecture-00

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.

The IETF Secretariat

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 3 Jul 2014 21:59:10 +0000

Hi Joel,

One question as it pertains to our ODL implementation.

Can a SFC aware function be reached/shared by more than one SFF?

So, imagine in figure 3 another NF + SFF (in a completely different
Service Node/device) but also capable of using the SFC-aware Function.

I¹m not advocating for it since it brings quite a few complications (M:N
relationship) but I also want to clear things up in the beginning.

Thanks,

Reinaldo

On 7/3/14, 9:35 AM, "Joel M. Halpern" <[email-masked]> wrote:

>Htmlized:       
>http://tools.ietf.org/html/draft-merged-sfc-architecture-00
>
>
>Abstract:
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Jul 2014 18:04:14 -0400

I suppose that a given SF might be reachable by multiple SFF. 
presumably on different chains.  The architecture does not,as far as I 
can tell, either require or prohibt such construction.  Presumably, 
specific solutions (such as the one the WG adopts) may have more to say 
on the topic.

I can imagine constructions where these is easy (if the SF<->SFF 
interface is a single power, and the SF always sends packets back on the 
port it arrives on, for example) and others where this would get quite 
complicated.

Yours,
Joel

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 4 Jul 2014 09:37:44 +0000

Hi Joel,

I have some comments as follows:

1. It said "..The SFC encapsulation enables service function path selection and the sharing of metadata/context information... " I wonder whether it would be more efficient and flexible by decoupling the service function path selection and the metadata convey functionalities by using different encapsulation headers. Since this framework draft is more or less related to the NSH draft (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the NSH as example for illustration: First, it seems the information (e.g., service path identifier information) contained in the SFC encapsulation (e.g., NSH) except the metadata is not interesting to SFs, and therefore it seems unnecessary to convey that information to the (SFC-aware) SFs, especially for those externally attached SFs. As for the O(AM) bit, I wonder whether the SFC OAM message must be forwarded to the SF. In other words, why can't the SFF process the OAM packets on behalf of the SF with the help of some health-check like mechanism between SFFs and SFs. As for the Service Index information, I wonder whether Service index MUST be decremented by service functions (see the corresponding description in the NSH draft). In other words, why can't it be decremented by the SFF on behalf of the SF; Second, the metadata is optional rather than mandatory. In a word, compared to the SFC-unware SF, it seems that the only additional mandatory requirement on the SFC-aware SF is to be capable of processing metadata. 

2. in Figure 3: Service Function Chain Architecture Components, it doesn't illustrate the relationship between those components as shown in the Figure and service nodes. I wonder whether the following figure could demonstrate the relationship correctly, e.g., SFF, NF and SFC proxy are three mandatory components of service nodes, while SFC-aware SFs could either be embedded on service nodes (e.g., SF X in the following figure) or be physically attached to service nodes (e.g., SF Y in the following figure).

  +----------------+                        +----------------+
  |   SFC-aware    |                        |  SFC-unaware   |
  |Service Function X|                        |Service Function|
  +-------+--------+                        +-------+--------+
          |                                         |
    SFC Encapsulation                       No SFC Encapsulation
  +-------+-----------------------------------------+-------------+
  |       |           SFC Encapsulation        +---------+        |
  |       +------------------+   +-------------|SFC Proxy|        |
  |                           \ /              +---------+        |
  |                    +-------+--------+      +----------------+ |
  |                    |   SF Forwarder |      |   SFC-aware    | |
  |                    |      (SFF)     +------+Service Function Y| |
  |                    +-------+--------+      +-------+--------+ |
  |                            |                                  |
  |                    SFC Encapsulation                          |
  |                            |                                  |
  |                    +-------+--------+                         |
  |                    |  SFC Network   |                         |
  |                    | Forwarder (NF) |                         |
  |                    +----------------+      Service Node       |
  |                            |                                  |
  +---------------------------------------------------------------+
3. If my understanding of the relationship as mentioned above is correct, I suggest updating the following definition

   "SFC Network Forwarder (NF):  SFC network forwarders provide network
        connectivity for service function forwarders (SFF) and service
        functions (SF)."
by
   "SFC Network Forwarder (NF):  SFC network forwarders provide network
        connectivity for service nodes."

4. According to the description about Transport Derived SFF in section 4.3.1, it seems that the SFC approach as described in (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an instantiation of such Transport Derived SFF model. Is my understanding of the Transport Derived SFF concept correct?

5. in the definition of SFC proxy (in section 4.5), it seems that partial functionalities of SFC proxy are overlapped with that of SFF, see below:

   o  Identifies the required SF to be applied based on information
      carried in the SFC encapsulation.

   o  Selects the appropriate outbound local attachment circuit through
      which the next SF for this SFP is reachable.  This information is
      derived from the SFC encapsulation or from local configuration.
      Examples of a local attachment circuit include, but are not
      limited to, VLANs, IP-in-IP, L2TPv3, GRE, VXLAN.

   o  Applies the required SFC encapsulation.  The determination of the
      encapsulation details may be inferred by the local attachment
      circuit through which the packet and/or frame was received, or via
      packet classification, or other local policy.  In some cases,
      packet-ordering or modification by the SF may necessitate
      additional classification in order to re-apply the correct SFC
      encapsulation.

   o  Imposes the appropriate SFC encapsulation based on the
      identification of the SFC to be applied.

IMHO, the only necessary functionality of SFC proxy is to remove the header containing metadata before forwarding the packet to the SFC-unware SF and while adding that header when receiving the packet returned from the SFC-unware SF.

6.  "Architecturally, the SFC Proxy along with an SFC-unaware Service
   Function make up an SF"   ----s/make up an SF/make up an SFC-aware SF 

Best regards,
Xiaohu

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Friday, July 04, 2014 12:36 AM
> To: [email-masked]
> Subject: [sfc] Fwd: New Version Notification for
> draft-merged-sfc-architecture-00.txt
> 
> Carlos and I have tried to pull together what we think is a viable document based
> on the available input and issues.  We hope that it will help carry the working
> group forward.
> 
> (While the chairs requested that we try to do this, they did not decide what we
> picked, and the working group gets to decide if it is useful.
> Similarly while we took input from multiple places, we are to blame for any
> errors, confusions, etc.  The various other author teams have NOT agreed that
> this represents their work.  it is merely the best Carlos and I could manage.)
> 
> has been successfully submitted by Carlos Pignataro and posted to the IETF
> repository.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 04 Jul 2014 14:47:20 -0400

I need to think about your other questions, but I wanted to highlight 
confusion around yoru question 2.  What you have drawn as Service Node 
is exactly the opposite of what we intended.  So we need help with 
better wording.

The Service Node is simply the housing for Service Functions.  For a 
dedicate (physical, ...) service function this would be the device.  For 
a virtual service function this would be the platform and hypervisor 
hosting the service function(s).

Yours,
Joel

On 7/4/14, 5:37 AM, Xuxiaohu wrote:
> 1. It said "..The SFC encapsulation enables service function path selection and the sharing of metadata/context information... " I wonder whether it would be more efficient and flexible by decoupling the service function path selection and the metadata convey functionalities by using different encapsulation headers. Since this framework draft is more or less related to the NSH draft (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the NSH as example for illustration: First, it seems the information (e.g., service path identifier information) contained in the SFC encapsulation (e.g., NSH) except the metadata is not interesting to SFs, and therefore it seems unnecessary to convey that information to the (SFC-aware) SFs, especially for those externally attached SFs. As for the O(AM) bit, I wonder whether the SFC OAM message must be forwarded to the SF. In other words, why can't the SFF process the OAM packets on behalf of the SF with the help of some health-che
 ck like m
echanism between SFFs and SFs. As for the Service Index information, I wonder whether Service index MUST be decremented by service functions (see the corresponding description in the NSH draft). In other words, why can't it be decremented by the SFF on behalf of the SF; Second, the metadata is optional rather than mandatory. In a word, compared to the SFC-unware SF, it seems that the only additional mandatory requirement on the SFC-aware SF is to be capable of processing metadata.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 4 Jul 2014 20:28:33 +0000

Joel, Xiaohu,

Would this help clarify?

Old:
  Service Node (SN):  Element within an SFC-enabled domain that hosts
       one or more service functions and has one or more network
       locators associated with it for reachability and service
       delivery.

New:
  Service Node (SN):  Element within an SFC-enabled domain that hosts
       one or more service functions (SFs) and has one or more network
       locators associated with it for reachability and service
       delivery. The Service Node is simply the housing for Service Functions,
       and can be a dedicated device for a physical SF, or a VM for a virtual SF.

Thanks,

Carlos.

On Jul 4, 2014, at 2:47 PM, Joel M. Halpern <[email-masked]> wrote:

> I need to think about your other questions, but I wanted to highlight confusion around yoru question 2.  What you have drawn as Service Node is exactly the opposite of what we intended.  So we need help with better wording.
> 
> The Service Node is simply the housing for Service Functions.  For a dedicate (physical, ...) service function this would be the device.  For a virtual service function this would be the platform and hypervisor hosting the service function(s).
> 
> Yours,
> Joel
>

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sat, 5 Jul 2014 00:34:15 +0000

I have some comments inline.

On 7/4/14 11:47 AM, "Joel M. Halpern" <[email-masked]> wrote:

>> 1. It said "..The SFC encapsulation enables service function path
>>selection and the sharing of metadata/context information... " I wonder
>>whether it would be more efficient and flexible by decoupling the
>>service function path selection and the metadata convey functionalities
>>by using different encapsulation headers. Since this framework draft is
>>more or less related to the NSH draft
>>(http://tools.ietf.org/html/draft-quinn-sfc-nsh-02),
SK> there is a rev-03 btw.

>>Let me take the NSH as example for illustration: First, it seems the
>>information (e.g., service path identifier information) contained in the
>>SFC encapsulation (e.g., NSH) except the metadata is not interesting to
>>SFs, and therefore it seems unnecessary to convey that information to
>>the (SFC-aware) SFs, especially for those externally attached SFs.
SK> Not sure I understand this. That ID is the one identifying the SF
forwarding state and is needed in order to keep the traffic on a certain
SFC, or SFP to be specific. Moreover that ID may be correlate to the
metadata. That ID also allows for state-less SFF implementation. So, that
ID is absolutely necessary.

>>As for the O(AM) bit, I wonder whether the SFC OAM message must be
>>forwarded to the SF. In other words, why can't the SFF process the OAM
>>packets on behalf of the SF with the help of some health-che
> ck like m
>echanism between SFFs and SFs.
SK> There are benefits to having OAM sent up to the SFs, depending on how
OAM is implemented. If not anything, it verifies the path through the SFs.

>As for the Service Index information, I wonder whether Service index MUST
>be decremented by service functions (see the corresponding description in
>the NSH draft). In other words, why can't it be decremented by the SFF on
>behalf of the SF; Second, the metadata is optional rather than mandatory.
>In a word, compared to the SFC-unware SF, it seems that the only
>additional mandatory requirement on the SFC-aware SF is to be capable of
>processing metadata.
SK> SFF MUST decrement-able by the SFF. That wording needs to be updated
as far as I can tell

>>
>> 2. in Figure 3: Service Function Chain Architecture Components, it
>>doesn't illustrate the relationship between those components as shown in
>>the Figure and service nodes. I wonder whether the following figure
>>could demonstrate the relationship correctly, e.g., SFF, NF and SFC
>>proxy are three mandatory components of service nodes, while SFC-aware
>>SFs could either be embedded on service nodes (e.g., SF X in the
>>following figure) or be physically attached to service nodes (e.g., SF Y
>>in the following figure).
>>
SK> I would not draw it this way. However, NF+SFF+SF could potentially be
in the same box, irrespective of what we call it. A firewall with
forwarding capability that also hosts an SFF and a host of security SFs,
is an example I can think of. So, that boundary depends on the
implementation.

>> 3. If my understanding of the relationship as mentioned above is
>>correct, I suggest updating the following definition
>>
>> 4. According to the description about Transport Derived SFF in section
>>4.3.1, it seems that the SFC approach as described in
>>(http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an
>>instantiation of such Transport Derived SFF model. Is my understanding
>>of the Transport Derived SFF concept correct?
>>
>> 5. in the definition of SFC proxy (in section 4.5), it seems that
>>partial functionalities of SFC proxy are overlapped with that of SFF,
>>see below:
>>
>> IMHO, the only necessary functionality of SFC proxy is to remove the
>>header containing metadata before forwarding the packet to the
>>SFC-unware SF and while adding that header when receiving the packet
>>returned from the SFC-unware SF.
>>
>>>document based
>>>IETF

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 7 Jul 2014 02:32:25 +0000

Hi Joel,

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Saturday, July 05, 2014 2:47 AM
> To: Xuxiaohu; [email-masked]
> Subject: Re: [sfc] Fwd: New Version Notification for
> I need to think about your other questions, but I wanted to highlight confusion
> around yoru question 2.  What you have drawn as Service Node is exactly the
> opposite of what we intended.  So we need help with better wording.
> 
> The Service Node is simply the housing for Service Functions.  For a dedicate
> (physical, ...) service function this would be the device.  For a virtual service
> function this would be the platform and hypervisor hosting the service
> function(s).

For the housing for service functions, it seems better to simply call it as service function node. For the device on which SFF and NF are mandatory components while SFC proxy and SF are optional component, it looks more important to the description of SFC architecture since it's the totally new device type (note that the service function nodes could be legacy service function nodes). Therefore we need to give it a name. I strongly believe "service node" is a very appropriate name for such device. SFs could either be embedded on such "service node" or be attached to such "service node". To some extent, the attached SF could be looked as an external service interface board of such "service node".

Best regards,
Xiaohu

> > selection and the sharing of metadata/context information... " I
> > wonder whether it would be more efficient and flexible by decoupling
> > the service function path selection and the metadata convey
> > functionalities by using different encapsulation headers. Since this
> > framework draft is more or less related to the NSH draft
> > (http://tools.ietf.org/html/draft-quinn-sfc-nsh-02), Let me take the
> > NSH as example for illustration: First, it seems the information
> > (e.g., service path identifier information) contained in the SFC
> > encapsulation (e.g., NSH) except the metadata is not interesting to
> > the (SFC-aware) SFs, especially for those externally attached SFs. As
> > for the O(AM) bit, I wonder whether the SFC OAM message must be
> echanism between SFFs and SFs. As for the Service Index information, I wonder
> whether Service index MUST be decremented by service functions (see the
> corresponding description in the NSH draft). In other words, why can't it be
> decremented by the SFF on behalf of the SF; Second, the metadata is optional
> rather than mandatory. In a word, compared to the SFC-unware SF, it seems
> that the only additional mandatory requirement on the SFC-aware SF is to be
> capable of processing metadata.
> >
> > 2. in Figure 3: Service Function Chain Architecture Components, it doesn't
> illustrate the relationship between those components as shown in the Figure and
> service nodes. I wonder whether the following figure could demonstrate the
> relationship correctly, e.g., SFF, NF and SFC proxy are three mandatory
> components of service nodes, while SFC-aware SFs could either be embedded
> on service nodes (e.g., SF X in the following figure) or be physically attached to
> service nodes (e.g., SF Y in the following figure).
> >
> |
> >    |                    SFC Encapsulation
> |
> |
> >    |                    |  SFC Network   |
> |
> >    |                    | Forwarder (NF) |
> |
> |
> > 4. According to the description about Transport Derived SFF in section 4.3.1, it
> seems that the SFC approach as described in
> (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) is an instantiation of
> such Transport Derived SFF model. Is my understanding of the Transport
> Derived SFF concept correct?
> >
> > 5. in the definition of SFC proxy (in section 4.5), it seems that partial
> functionalities of SFC proxy are overlapped with that of SFF, see below:
> >
> > IMHO, the only necessary functionality of SFC proxy is to remove the header
> containing metadata before forwarding the packet to the SFC-unware SF and
> while adding that header when receiving the packet returned from the
> SFC-unware SF.
> >
> >> document based on the available input and issues.  We hope that it
> >> will help carry the working group forward.
> >>
> >> (While the chairs requested that we try to do this, they did not
> >> decide what we picked, and the working group gets to decide if it is useful.
> >> Similarly while we took input from multiple places, we are to blame
> >> for any errors, confusions, etc.  The various other author teams have
> >> NOT agreed that this represents their work.  it is merely the best
> >> Carlos and I could manage.)
> >>
> >> <[email-masked]>, "Joel M. Halpern" <[email-masked]>,
> >> "Carlos Pignataro" <[email-masked]>
> >>
> >>
> >> 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.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 06 Jul 2014 22:40:42 -0400

It is not clear to me that the archtiecture requires a physical device 
which must house both an NF and an SFF.  Certainly it permits such a 
device.  But there clearly are devices which provide NF without SFF. 
And it seems likely that some solutions will allow for SFF without NF.

Yours,
Joel

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 7 Jul 2014 03:16:57 +0000

> Sent: Monday, July 07, 2014 10:41 AM
> It is not clear to me that the archtiecture requires a physical device which must
> house both an NF and an SFF.  Certainly it permits such a device.  But there

I agree NF and SFF could be implemented on separate devices in theory. However, I'm not sure whether it will be implemented in that way in reality.

> clearly are devices which provide NF without SFF.

Sure, that device which provides NF w/o SFF is called as tunnel encapsulator/decapsualtor.

> And it seems likely that some solutions will allow for SFF without NF.

Did you mean that SFF would receive unencapsulated traffic with the NSH as the outermost header?

BTW, it seems that there are some functionality overlapping (i.e., overlay encap/decap) between SFF and NF:

      "If there is
       another hop in the SFP, the SFF, encapsulates the traffic in the
       appropriate network transport and delivers it to the NF for
       delivery to the next SFF along the path... When traffic arrives at
       the SFF after the last SF has finished servicing it, SFF fails to
       find the next SF or knows from the service forwarding state that
       the SFC is complete.  SFF removes the SFC encapsulation and
       delivers the packet to an NF for forwarding..."

" ...This component (NF) is responsible for performing the overlay
   encapsulation/de-capsulation and forwarding of packets on the overlay
   network..."

In addition, according to the following statement "However, the SFC encapsulation is not a transport
   encapsulation itself: it is not used to forward packets within the
   network fabric.  The SFC encapsulation therefore, relies on an outer
   network transport." The SFC encapsulation just mean the NSH, if so, when a packet with SFC encapsulation is received from SFF, should the NF be responsible for encapsulating it with the appropriate transport header? If so, how could the NF determine that appropriate transport header? By reading the path id information in the SFC encapsulation? If so, it seems conflict with the following description:

" NF forwarding 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. "

Best regards,
Xiaohu

> >> confusion around yoru question 2.  What you have drawn as Service
> >> Node is exactly the opposite of what we intended.  So we need help with
> better wording.
> >>
> >> dedicate (physical, ...) service function this would be the device.
> >> For a virtual service function this would be the platform and
> >> hypervisor hosting the service function(s).
> >
> > For the housing for service functions, it seems better to simply call it as service
> function node. For the device on which SFF and NF are mandatory components
> while SFC proxy and SF are optional component, it looks more important to the
> description of SFC architecture since it's the totally new device type (note that
> the service function nodes could be legacy service function nodes). Therefore
> we need to give it a name. I strongly believe "service node" is a very appropriate
> name for such device. SFs could either be embedded on such "service node" or
> be attached to such "service node". To some extent, the attached SF could be
> looked as an external service interface board of such "service node".
> >
> > Best regards,
> > Xiaohu
> >
> >> Yours,
> >> Joel
> >>
> >>> SFs, and therefore it seems unnecessary to convey that information
> >>> to the (SFC-aware) SFs, especially for those externally attached
> >>> SFs. As for the O(AM) bit, I wonder whether the SFC OAM message must
> >>> be forwarded to the SF. In other words, why can't the SFF process
> >>> the OAM packets on behalf of the SF with the help of some health-che
> >>   ck like m
> >> echanism between SFFs and SFs. As for the Service Index information,
> >> I wonder whether Service index MUST be decremented by service
> >> functions (see the corresponding description in the NSH draft). In
> >> other words, why can't it be decremented by the SFF on behalf of the
> >> SF; Second, the metadata is optional rather than mandatory. In a
> >> word, compared to the SFC-unware SF, it seems that the only
> >>> doesn't
> >> illustrate the relationship between those components as shown in the
> >> Figure and service nodes. I wonder whether the following figure could
> >> demonstrate the relationship correctly, e.g., SFF, NF and SFC proxy
> >> are three mandatory components of service nodes, while SFC-aware SFs
> >> could either be embedded on service nodes (e.g., SF X in the
> >> following figure) or be physically attached to service nodes (e.g., SF Y in the
> following figure).
> >>>
> >>>     |                           \ /              +---------+
> >>>     |                    |   SF Forwarder |      |   SFC-aware
> |
> >> |
> >>>     |                    +-------+--------+
> >> instantiation of such Transport Derived SFF model. Is my
> >> understanding of the Transport Derived SFF concept correct?
> >>>
> >>> partial
> >>> header
> >> containing metadata before forwarding the packet to the SFC-unware SF
> >> and while adding that header when receiving the packet returned from
> >> the SFC-unware SF.
> >>>
> >>>      Function make up an SF"   ----s/make up an SF/make up an
> SFC-aware
> >> SF
> >>>
> >>> Best regards,
> >>> Xiaohu
> >>>
> >>>
> >>>> There has been a lot of discussion among the many authors of
> >>>> various archtiecture document proposals, and other commenters on
> >>>> these
> >> documents.
> >>>> for any errors, confusions, etc.  The various other author teams
> >>>> have NOT agreed that this represents their work.  it is merely the
> >>>> best Carlos and I could manage.)
> >>>>
> >>>> has been successfully submitted by Carlos Pignataro and posted to
> >>>> the IETF repository.
> >>>>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 7 Jul 2014 08:39:11 +0000

Hi Surendra,

> From: Surendra Kumar (smkumar) [mailto:[email-masked]]
> Sent: Saturday, July 05, 2014 8:34 AM
> To: Joel M. Halpern; Xuxiaohu; [email-masked]

Thanks for pointing out this revision. 

> >>information (e.g., service path identifier information) contained in
> >>the SFC encapsulation (e.g., NSH) except the metadata is not
> >>interesting to SFs, and therefore it seems unnecessary to convey that
> >>information to the (SFC-aware) SFs, especially for those externally attached
> SFs.
> forwarding state and is needed in order to keep the traffic on a certain SFC, or
> SFP to be specific. Moreover that ID may be correlate to the metadata. That ID
> also allows for state-less SFF implementation. So, that ID is absolutely necessary.

I have no doubt that the path ID information is necessary for the SFF. I'm just wondering what's meaning of that path ID information to the SF. 

> SK> There are benefits to having OAM sent up to the SFs, depending on
> SK> how

Suppose the SF is an SFC-unware SF, could we still perform SF OAM functions (e.g.., SF availability check) on that SFC-unware SF? For example, could the SFF or the SF proxy process the OAM messages on behalf of the SFC-unware SF?

> >As for the Service Index information, I wonder whether Service index
> >MUST be decremented by service functions (see the corresponding
> >description in the NSH draft). In other words, why can't it be
> rather than mandatory.
> >additional mandatory requirement on the SFC-aware SF is to be capable
> >of processing metadata.

"Service Index (SI): provides location within the service path.  
       Service index MUST be decremented by service functions or proxy nodes  
       after performing required services" ---quoted from -03 version of NSH draft.

Did you agree that the service index MUST be decremented by the SFF, rather than the SF?

> >>doesn't illustrate the relationship between those components as shown
> >>in the Figure and service nodes. I wonder whether the following figure
> >>following figure) or be physically attached to service nodes (e.g., SF
> >>Y in the following figure).
> >>
> SK> I would not draw it this way. However, NF+SFF+SF could potentially
> SK> be
> in the same box, irrespective of what we call it. A firewall with forwarding

I think we should define a term for such box which contains SFF and NF components at least. SFs could be embedded on such box or be attached to such box.

Best regards,
Xiaohu

> capability that also hosts an SFF and a host of security SFs, is an example I can
> think of. So, that boundary depends on the implementation.
> 
> 
> >> 4. According to the description about Transport Derived SFF in
> >>section 4.3.1, it seems that the SFC approach as described in