Subject: [sfc] commment on draft merged-sfc-architecture-01

From: Lucy yong <[email-masked]>
Date: Mon, 11 Aug 2014 18:51:48 +0000

Hi Joel and Carlos,

Here are some comments beside the comments others already stated.

SFC definition in this version:

  Service Function Chain (SFC):  A service Function chain defines an
        abstract set of service functions and their ordering constraints
        that must be applied to packets and/or frames selected as a
        result of classification.  The implied order may not be a linear
        progression as the architecture allows for nodes that copy to
        more than one branch, and also allows for cases where there is
        flexibility in the order in which services need to be applied.
        The term service chain is often used as shorthand for service
        function chain.

In previous version:
Service Function Chain (SFC):  A service Function chain defines an
        ordered set of service functions that must be applied to packets
        and/or frames selected as a result of classification.  The
        implied order may not be a linear progression as the
        architecture allows for nodes that copy to more than one branch.
        The term service chain is often used as shorthand for service
        function chain.

Comment: I am not sure why it has been changed and what use case drives the order flexibility. Don't see the rest of architecture change to allow/describe this. When such flexibility applies, does it mean that SFC is just a set of SFs? Could you explain?

Comments: Service Function Definition in section 1.3 is too long. Last paragraph in the definition does not belong to SF definition. Suggest giving shorter definition and have the SF description in section 4.2.

Section 2.
...it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities...

Comment:  Suggest using "dynamic selection of those SFs". "ordering" make confusion here.

Section 2.1

SFCs can start from the origination point of the service function
   graph (i.e.: node 1 in Figure 1), or from any subsequent node in the
   graph.
Comment:  Add a note that a node in graph represents an abstract Service Function.

Section 2.3

State that a SF may apply part of zero, one, or multiple SFPs that associate to a single SFC.

Section 4.1
The SFC encapsulation provides explicit information used to identify
   the SFP. However, ...
Comment: remove this sentence and combine the rest of paragraph (however, ...) with previous paragraph.

Regards/Thanks,
Lucy

---

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

Lucy,
     The reason we added ordering flexibility in the SFC definition is 
that we understood that to be part of what folks were requesting on the 
mailing list.  I don't much care one way or the other.  It is undeniable 
that there are many cases where there is flexibility in the order in 
which services are applied without loss of generality.  (In some 
contexts you can apply charging either before or after optimization, for 
example.)  Whether we should allow that is up to the WG.

Yours,
Joel

On 8/11/14, 2:51 PM, Lucy yong wrote:
>          ordered set of service functions that must be applied topackets
>
> Comment: I am not sure why it has been changed and what use case drives
> the order flexibility. Don’t see the rest of architecture change to
> allow/describe this. When such flexibility applies, does it mean that
> SFC is just a set of SFs? Could you explain?
>
...

---

From: Lucy yong <[email-masked]>
Date: Mon, 11 Aug 2014 20:26:11 +0000

Joel,

I missed such discussion on the list for sure. If this is allowed, how does the architecture reflect to it? Should we say that an SFC could be a set of SFs that traffic MUST pass through, but the sequence of SFs traffic traverse does not matter. This let a SFF to select any rest of SFs (traffic not passes over yet) in a SFC? Should the arch add that too?

I do not see the charter text stating this as SFC but agree some use case that the order may not matter to the customer, or say traffic. 

Thanks,
Lucy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 2:08 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] commment on draft merged-sfc-architecture-01

Lucy,
     The reason we added ordering flexibility in the SFC definition is that we understood that to be part of what folks were requesting on the mailing list.  I don't much care one way or the other.  It is undeniable that there are many cases where there is flexibility in the order in which services are applied without loss of generality.  (In some contexts you can apply charging either before or after optimization, for
example.)  Whether we should allow that is up to the WG.

Yours,
Joel

On 8/11/14, 2:51 PM, Lucy yong wrote:
> Comment: I am not sure why it has been changed and what use case 
> drives the order flexibility. Don't see the rest of architecture 
> change to allow/describe this. When such flexibility applies, does it 
> mean that SFC is just a set of SFs? Could you explain?
>
...

---

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

An SFC can include order constraints.  That is clearly necessary.
As currently described, an SFC would consist of a list of abstract 
service functions, with ordering constraints where desired.  Exactly how 
flexible that is is left largely up to the control systems, as the 
definition of SFC and the representations for it are not really our space.

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Mon, 11 Aug 2014 21:01:08 +0000

Joel,

Your last sentence is interesting. The merged arch did define SFC in section 1.3 and further describe it in section 2.

Maybe we at least make the architecture clear if a SFP in a SFC can be a set of SFs w/ order flexible or not if the SFC is order flexible. IMO: it should not. Thus, it is pure control plane implementation.
 
Thanks,
Lucy 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 3:34 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] commment on draft merged-sfc-architecture-01

An SFC can include order constraints.  That is clearly necessary.
As currently described, an SFC would consist of a list of abstract service functions, with ordering constraints where desired.  Exactly how flexible that is is left largely up to the control systems, as the definition of SFC and the representations for it are not really our space.

Yours,
Joel

On 8/11/14, 4:26 PM, Lucy yong wrote:
>       The reason we added ordering flexibility in the SFC definition 
> is that we understood that to be part of what folks were requesting on 
> the mailing list.  I don't much care one way or the other.  It is 
> undeniable that there are many cases where there is flexibility in the 
> order in which services are applied without loss of generality.  (In 
> some contexts you can apply charging either before or after 
> optimization, for

---

From: Lucy yong <[email-masked]>
Date: Mon, 11 Aug 2014 21:37:52 +0000

Further clarify my suggestion below. I mean that the set of SFs selected for an order flexible SFC should be ordered in data plane.
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, August 11, 2014 4:01 PM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] commment on draft merged-sfc-architecture-01

Joel,

 
Thanks,
Lucy 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, August 11, 2014 3:34 PM
To: Lucy yong; [email-masked]
Subject: Re: [sfc] commment on draft merged-sfc-architecture-01

Yours,
Joel

>> mean that SFC is just a set of SFs? Could you explain?

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