Subject: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

From: Tom Taylor <[email-masked]>
Date: Tue, 15 Jul 2014 15:47:39 -0400

Section 3.3 of the problem statement has this to say about SFC metadata:

<quote>

    Data plane metadata provides the ability to exchange information
    between logical classification points and service functions (and vice
    versa) and between service functions.  As such metadata is not used
    as forwarding information to deliver packets along the service
    overlay.

</quote>

However, the definition of the SFF in the architecture document seems to 
contradict this, unless one assumes that the SFC encapsulation has more 
information than just SFC metadata.

<quote>

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

</quote>

Is this just a matter of adjusting the text, or is there a conflict of 
views buried here?

Tom Taylor

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Jul 2014 15:57:53 -0400

The expectation and intention is that the piece of the SFC Encapsulation 
used for this is the identification of the service path.  I believe 
there is other text in the architecture that reinforces the problem 
statement point that metadata is not used for the forwarding description 
in the absence of a classifier.

Yours,
Joel

On 7/15/14, 3:47 PM, Tom Taylor wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Henry Fourie <[email-masked]>
Date: Tue, 15 Jul 2014 20:50:45 +0000

Tom,
  Both are correct, although not sufficiently explicit.
The SFC encapsulation (or SFC headers: SCH/NSH) carries both steering information
(Service Path ID) and service metadata.

The SFF uses the steering information to deliver the packet to the correct SF
and the metadata is then processed by the SF. The SFF does not use the metadata
for steering. 

 - Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Tuesday, July 15, 2014 12:48 PM
To: [email-masked]
Subject: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

<quote>

</quote>

<quote>

</quote>

Tom Taylor

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Wed, 16 Jul 2014 08:44:32 +0000

I do have a different view. On what ground shall we exclude metadata from forwarding decision in a PS draft? Even in an architecture draft, it is not quite proper to exclude this explicitly. Actually, the metadata can contain some predefined information useful for path selection without involving a complex classifier in a SFF. I am not saying it must be so, but it is too rush to exclude this in either PS or arch draft.

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, July 16, 2014 3:58 AM
To: Tom Taylor; [email-masked]
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

The expectation and intention is that the piece of the SFC Encapsulation used for this is the identification of the service path.  I believe there is other text in the architecture that reinforces the problem statement point that metadata is not used for the forwarding description in the absence of a classifier.

Yours,
Joel

On 7/15/14, 3:47 PM, Tom Taylor wrote:
> However, the definition of the SFF in the architecture document seems 
> to contradict this, unless one assumes that the SFC encapsulation has 
> more information than just SFC metadata.
>
> <quote>
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 16 Jul 2014 12:36:22 +0000

Hongyu,

I agree regarding the optional use of metatadata for forwarding..   For a new flow, next SFF selection by an SFF SFF MUST be based on the chain ID and MAY be based on metadata and/or locally known policy.   Next SFI selection by an SFF MUST be based on the chain ID and service function index within the chain and MAY be based on metadata and/or locally known policy.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Hongyu Li (Julio)
Sent: Wednesday, July 16, 2014 4:45 AM
To: Joel M. Halpern; Tom Taylor; [email-masked]
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, July 16, 2014 3:58 AM
To: Tom Taylor; [email-masked]
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Jul 2014 08:45:04 -0400

I see a major interoperability problem with this suggested flexibility.
First, there are two possible readings of this "may" relative to SFF
capabilities.  One view is that all SFF MUST be able to use metadata for
such forwarding, although some cases may not need to use it.  That is a
major requirement on SFF implementation.
Another view is that the ability to use metadata at SFF to influence
forwarding is an optional capability.
If so, the question is then how the orchestration and management will be
able to set up the chain IDs and metadata usage.  Given that some SFF 
may not be able to use metadata for the decision, and some may do so in 
ill-defined fashions, I do not see how the control component can know 
what to do.  If the metadata based behavior is not actually needed, then 
allowing for it complicates the system for no benefit.

Hence this looks like it would require that all SFF be able to support 
metadata based classification.

I would also note that one of the reasons that the architecture allows 
for re-classification is that such a construction makes it clear where 
additional information (metadata, packet contents, etc.)

Keeping the SFF function itself relatively simple seems a big win. 
Requiring the SFF to have multiple capabilities including, as some have 
suggested, stateful forwarding, metadata based forwarding, and remote 
synchronization, seems like it will create something that is very 
difficult to implement or deploy.

Yours,
Joel

On 7/16/14, 8:36 AM, Ron Parker wrote:
> Hongyu,
>
> I agree regarding the optional use of metatadata for forwarding..
> For a new flow, next SFF selection by an SFF SFF MUST be based on the
> chain ID and MAY be based on metadata and/or locally known policy.
> Next SFI selection by an SFF MUST be based on the chain ID and
> service function index within the chain and MAY be based on metadata
> and/or locally known policy.
>
> Ron
>
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Hongyu Li (Julio) Sent: Wednesday, July 16, 2014 4:45 AM
> To: Joel M. Halpern; Tom Taylor; [email-masked] Subject: Re: [sfc]
> Inconsistency regarding role of SFC metadata in forwarding?
>
> I do have a different view. On what ground shall we exclude metadata
> from forwarding decision in a PS draft? Even in an architecture
> draft, it is not quite proper to exclude this explicitly. Actually,
> the metadata can contain some predefined information useful for path
> selection without involving a complex classifier in a SFF. I am not
> saying it must be so, but it is too rush to exclude this in either PS
> or arch draft.
>
> Hongyu
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Joel M. Halpern Sent: Wednesday, July 16, 2014 3:58 AM To:
> Tom Taylor; [email-masked] Subject: Re: [sfc] Inconsistency regarding
> role of SFC metadata in forwarding?
>
> The expectation and intention is that the piece of the SFC
> Encapsulation used for this is the identification of the service
> path.  I believe there is other text in the architecture that
> reinforces the problem statement point that metadata is not used for
> the forwarding description in the absence of a classifier.
>
> Yours, Joel
>
>> between logical classification points and service functions (and
>> vice versa) and between service functions.  As such metadata is not
>> used as forwarding information to deliver packets along the
>> service overlay.
>>
>> </quote>
>>
>> However, the definition of the SFF in the architecture document
>> seems to contradict this, unless one assumes that the SFC
>> encapsulation has more information than just SFC metadata.
>>
>> <quote>
>>
>> Is this just a matter of adjusting the text, or is there a conflict
>> of views buried here?
>>
>> Tom Taylor
>>
>> _______________________________________________ sfc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 16 Jul 2014 13:03:41 +0000

Joel,

Yes, you are correct that if the MAY is not universally implemented in some particular deployment, then it will not be feasible.    But that doesn't mean it isn't a worthwhile aspect of the architecture.    In 3gpp core networks for example, we may want to constrain the SFI selection based on the APN.   Metadata is an ideal way to communicate the APN membership to all of the involved entities.

In general, the solution should be as simple as the problem domain and no simpler.    Service Function Chaining already exists in multiple forms.   The premise of this WG is that those forms are inadequate.   My read on that the inadequacy is along the lines of reliability, scale, flexibility, and yes, ease of deployment.    I'm trying to keep in mind that the architecture/solution fits the needs of the problem space first, and then is as simple as possible, second.     

I also think that a major assumption that you and I may differ on and which may flavor our viewpoints is regarding orchestration.   While the term is somewhat ambiguous, I generally take it to mean strong centralized control.   You've mentioned in a number of messages that particular architectural choices would have a negative ramification on orchestration.     But when I look at some of those same architectural choices, I see them, instead, as having negative ramifications on a fully distributed approach.    I may have mischaracterized your viewpoint, and I am certainly not casting aspersions on your viewpoint.   I'm just trying identify the source of some of these disagreements.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2014 8:45 AM
To: Ron Parker; Hongyu Li (Julio); Tom Taylor; [email-masked]
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

I see a major interoperability problem with this suggested flexibility.
First, there are two possible readings of this "may" relative to SFF capabilities.  One view is that all SFF MUST be able to use metadata for such forwarding, although some cases may not need to use it.  That is a major requirement on SFF implementation.
Another view is that the ability to use metadata at SFF to influence forwarding is an optional capability.
If so, the question is then how the orchestration and management will be able to set up the chain IDs and metadata usage.  Given that some SFF may not be able to use metadata for the decision, and some may do so in ill-defined fashions, I do not see how the control component can know what to do.  If the metadata based behavior is not actually needed, then allowing for it complicates the system for no benefit.

Hence this looks like it would require that all SFF be able to support metadata based classification.

I would also note that one of the reasons that the architecture allows for re-classification is that such a construction makes it clear where additional information (metadata, packet contents, etc.)

Keeping the SFF function itself relatively simple seems a big win. 
Requiring the SFF to have multiple capabilities including, as some have suggested, stateful forwarding, metadata based forwarding, and remote synchronization, seems like it will create something that is very difficult to implement or deploy.

Yours,
Joel

On 7/16/14, 8:36 AM, Ron Parker wrote:
> Next SFI selection by an SFF MUST be based on the chain ID and service 
> function index within the chain and MAY be based on metadata and/or 
> locally known policy.
>
> Ron
>
>
> from forwarding decision in a PS draft? Even in an architecture draft, 
> it is not quite proper to exclude this explicitly. Actually, the 
> metadata can contain some predefined information useful for path 
> Encapsulation used for this is the identification of the service path.  
> I believe there is other text in the architecture that reinforces the 
> problem statement point that metadata is not used for the forwarding 
> description in the absence of a classifier.
>
> Yours, Joel
>
>> forwarder to one or more connected service functions via information 
>> carried in the SFC encapsulation.
>>
>> </quote>
>>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 17 Jul 2014 23:11:41 +0000

Ron, 

You said:

   For a new flow, next SFF selection by an SFF SFF MUST be based on the chain ID and MAY be based on metadata and/or locally known policy.   Next SFI selection by an SFF MUST be based on the chain ID and service function index within the chain and MAY be based on metadata and/or locally known policy.

[Linda] "next SFI selection" criteria can even be based on packet size, like an AntiDos system detects a threat (packet size=57) and needs to steer all packets with size = 57 to Security Scrubbing Center.  The next SFF selection can also be based on something else or in combination of Chain ID (like traffic metrics, etc). 

My point is that Chain ID is only to identify the Chain, but the selection criteria can be based on various factors.   

Linda

---

From: Ron Parker <[email-masked]>
Date: Thu, 17 Jul 2014 23:16:47 +0000

Linda,

I think that what you describe is more of a dynamic chain assignment.   A particular chain either does or does not include a Service Function to perform Security Scrubbing Center.   The ingress classifier may have taken your packet size into account to choose an abstract chain that did, indeed, include your Security Scrubbing Center.   But once selected and barring reclassification, the SFF's are obligated to respect the chain assignment selected by the ingress classifier.   Thus, the SFF's have freedom, with possible policy constraints, to choose any instance of any particular service function within the chain, but not to shift to a different chain that describes a different sequence of service functions.

   Ron

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, July 17, 2014 7:12 PM
To: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor; [email-masked]
Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Ron, 

You said:

Linda

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Jul 2014 08:47:19 -0400

I believe that the architecture draft would refer to this (inserting a scrubber into the chain) as branching as it would technically be a new chain (all SFIs of an SF would be the same and interchangeable).

From: [email-masked]<[email-masked]>
To: Linda Dunbar<[email-masked]>,Hongyu Li (Julio)<[email-masked]>,Joel M. Halpern<[email-masked]>,Tom Taylor<[email-masked]>,[email-masked]<[email-masked]>
Sent: Thursday, July 17, 2014
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Linda,

   Ron

-----Original Message-----

From: Linda Dunbar [mailto:[email-masked]] Sent: Thursday, July 17, 2014 7:12 PMTo: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor; [email-masked]: RE: [sfc] Inconsistency regarding role of SFC metadata in forwarding?Ron, You said:   For a new flow, next SFF selection by an SFF SFF MUST be based on the chain ID and MAY be based on metadata and/or locally known policy.   Next SFI selection by an SFF MUST be based on the chain ID and service function index within the chain and MAY be based on metadata and/or locally known policy.[Linda] "next SFI selection" criteria can even be based on packet size, like an AntiDos system detects a threat (packet size=57) and needs to steer all packets with size = 57 to Security Scrubbing Center.  The next SFF selection can also be based on something else or in combination of Chain ID (like traffic metrics, etc). My point is that Chain ID is only to identify the Chain, but the selection criteria can be based on various factors.   Linda_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Fri, 18 Jul 2014 12:52:43 +0000

Hi, Mike.

I agree that this is branching.   Is the new branch described as a new chain?   I’m not sure.   But, branching, in the architecture, occurs via reclassification.   I think Linda’s case is supported, but only if the branch point is a classifier.   I was trying to point out that the SFF function, as I envision it, is not allowed to branch (although and SFF and classifier could certainly be co-located).

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 18, 2014 8:47 AM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Linda Dunbar<[email-masked]<mailto:[email-masked]>>,Hongyu Li (Julio)<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>,Tom Taylor<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 17, 2014
Subject: Re: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Linda,

  Ron

-----Original Message-----

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, July 17, 2014 7:12 PM
To: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Ron,

You said:

Linda

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

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Jul 2014 09:26:20 -0400

the draft reads, "typically performed by a classification function co-resident with a service function", which does not exclude the SFF from reclassifying.  The implication is that a classifier is anything that performs a classification function, thus if a classification function were co-resident with an SFF function, it could analogously perform the branching function.

The new branch isn't directly described as a new chain, but the example provided is only possible if it is a new chain per the definition of a chain.

To be clear, I was agreeing with you and trying to point out the terminology used in the arch draft to describe what Linda is suggesting.  I, personally, find it important to try to normalize the language used in discussions to prevent people from arguing about points on which they agree (as entertaining as that might be).

Of course, this is assuming I'm interpreting the draft properly and have not missed some text that limits the location of branching points or some other crucial bit of information.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 18, 2014
Subject: RE: [sfc] Inconsistency regarding role of SFC metadata in forwarding?

Hi, Mike.

I agree that this is branching.   Is the new branch described as a new chain?   I’m not sure.   But, branching, in the architecture, occurs via reclassification.  
 I think Linda’s case is supported, but only if the branch point is a classifier.   I was trying to point out that the SFF function, as I envision it, is not allowed to branch (although and SFF and classifier could certainly be co-located).
 
   Ron

From: sfc [mailto:[email-masked]]
On Behalf Of [email-masked]

I believe that the architecture draft would refer to this (inserting a scrubber into the chain) as branching as it would technically be a new chain (all
 SFIs of an SF would be the same and interchangeable).

To: Linda Dunbar<[email-masked]>,Hongyu Li (Julio)<[email-masked]>,Joel M. Halpern<[email-masked]>,Tom
 Taylor<[email-masked]>,[email-masked]<[email-masked]>

Linda,

I think that what you describe is more of a dynamic chain assignment.   A particular chain either does or does not include a Service Function to perform Security Scrubbing Center.   The ingress classifier may have taken your packet size into account to choose
 an abstract chain that did, indeed, include your Security Scrubbing Center.   But once selected and barring reclassification, the SFF's are obligated to respect the chain assignment selected by the ingress classifier.   Thus, the SFF's have freedom, with possible
 policy constraints, to choose any instance of any particular service function within the chain, but not to shift to a different chain that describes a different sequence of service functions.

  Ron

-----Original Message-----

To: Ron Parker; Hongyu Li (Julio); Joel M. Halpern; Tom Taylor; 
[email-masked]

Ron, 

You said:

  For a new flow, next SFF selection by an SFF SFF MUST be based on the chain ID and MAY be based on metadata and/or locally known policy.   Next SFI selection by an SFF MUST be based on the chain ID and service function index within the chain and MAY be based
 on metadata and/or locally known policy.

[Linda] "next SFI selection" criteria can even be based on packet size, like an AntiDos system detects a threat (packet size=57) and needs to steer all packets with size = 57 to Security Scrubbing Center. The next SFF selection can also be based on something
 else or in combination of Chain ID (like traffic metrics, etc). 

Linda

sfc mailing list

[email-masked]