Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

From: "Jmh.direct" <[email-masked]>
Date: Thu, 26 Feb 2015 14:04:40 -0500

The fireawall sets the metadata for tge firewall to use.  The absence of the metadata serves as the indicator that this is the first time.  Rules for this sort of thing are set / agreed by theservice functions.  That is out of scope for the working group but week can provide a registry to help.

Control is probably by application provisioning or other control protocols.  We might want to work on that space once we finish our deliverables.

Yours,
Joel

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: RE: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 
From: Dave Dolson <[email-masked]> 
To: "Jmh.direct" <[email-masked]>,"[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]> 
CC: "[email-masked]" <[email-masked]> 

Sure, but going from the generic to the specific, take my example of the firewall with different sets of rules depending on location in the chain.

I’m hearing that meta-data can be used by the firewall to select which rule set to apply, meaning the meta-data is inspected upon packet arrival and used to select the rule set.

(Is that what folks meant to say?)

So which elements set the meta-data for the firewall to use?

And which rules determine the meta-data values to be applied by those elements?

-Dave

From: Jmh.direct [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 1:20 PM
To: Dave Dolson; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Importance: Low

Instruction comes from the sevice function design.  Some header structures augment that with control mapping ibformation to indicate which metadata field has which use.

Gor TLV based metadat we probably eant a registry with very easy entry creation.

Yours,

Joel

Sent from my Samsung smartphone on AT&T

-------- Original message --------
Subject: RE: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 
From: Dave Dolson <[email-masked]> 
To: "Joel M. Halpern" <[email-masked]>,"Reinaldo Penno (repenno)" <[email-masked]>,Ron Parker <[email-masked]>,"[email-masked]" <[email-masked]>,"[email-masked]" <[email-masked]> 
CC: "Ben Wright ([email-masked])" <[email-masked]> 

What are the mechanics of using meta-data?
Which element sets it, and how is it instructed to do so?

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 12:36 PM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; [email-masked]; [email-masked]
Cc: Ben Wright ([email-masked])
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Personally, I would prefer that the firewall use metadata rather than 
path-index.  My reasoning is that if functions get added before or after 
the firewall, operations would prefer not to have to change the 
configuration of the firewall SF itself.

Having said that, I don't see any way to stop you from using the path index.

Yours,
Joel

On 2/26/15 12:30 PM, Dave Dolson wrote:
> For the sake of argument, suppose I have a firewall SF, and I want to use
> it more than once in a chain. (Maybe I want to book-end the chain with ingress
> and egress rules.)
>
> Do you agree it would be sufficient to use the Path Index to select which of
> the ingress or egress rule sets should be used?
>
> I'm probably missing something; I don't understand how the context headers
> define functionality. Maybe the device could communicate with itself
> (e.g., the ingress portion sending a tag to the egress portion)
> by sending state in the packet. Is that what you are mean by "contextual info" ?
>
>
>
> -----Original Message-----
> From: Reinaldo Penno (repenno) [mailto:[email-masked]]
> Sent: Thursday, February 26, 2015 12:18 PM
> To: Dave Dolson; Ron Parker; Joel M. Halpern; [email-masked]; [email-masked]
> Cc: Ben Wright ([email-masked])
> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
> Agreed on all points. I thought I was missing something so before writing
> this email I retested our implementation and it worked off the bat. The
> RSP constructed has the the same (SFF, SF) tuple but different indexes.
>
> The same SF is visited multiple times until the path ends.  If the SF
> wants contextual info across visits than context headers are the way to
> go.
>
>
> On 2/26/15, 8:52 AM, "Dave Dolson" <[email-masked]> wrote:
>
>> Maybe naively, I thought the service functions would be provisioned with
>> a table:
>>
>> E.g., for element foo:
>> Path | Path Index | Next Hop  | Function
>> 123 |  4         |   SF-bar  | first behavior
>> 123 |  2         | SF-foobar | second behavior
>>
>>
>> The Function is clearly implementation specific. Maybe it points to a
>> configuration set or a policy set. I think completely out of scope here.
>>
>> I suggest that this is not a problem for the wire protocol, rather for
>> the configuration model (netconf or whatever).
>>
>> It becomes very much vendor-specific if the behaviors are complex
>> configurations of specialized features.
>>
>> If a person were manually configuring chains, I don't think they'd have a
>> conceptual problem, because they'd have a diagram they need to implement:
>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}
>>
>> If we wanted to standardize it, we could maybe make the Function simply a
>> label that means something to the device--an indirection to a
>> configuration set.
>>
>> -Dave
>>
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
>> Sent: Thursday, February 26, 2015 11:31 AM
>> To: Dave Dolson; Joel M. Halpern; [email-masked];
>> [email-masked]
>> Cc: Ben Wright ([email-masked])
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> Hi, Dave.
>>
>> I agree that on the wire, this is the way it would work.
>>
>> But, when composing the chain, it seems like information would be lacking
>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>>   It is completely implicit that since SF-foo appears twice, it perhaps
>> should perform some different duty when index = 0 vs when index = 2.
>>
>> At first, I thought that an alternative way to handle this would be to
>> use multiple logical identities for SF-foo.  In this case, the chain
>> above would be expressed as {SF-foo-first-behavior, SF-bar,
>> SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>> the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>> second flavor of chain says that the same instance of SF-foo-* must be
>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>> (which may not be required, but should be possible to force as such).
>>
>> I guess what I'm saying is that spiraling has a subtlety to it that isn't
>> yet adequately addressed and that I don't have a specific proposal to
>> solve it, either.
>>
>>    Ron
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
>> Sent: Thursday, February 26, 2015 11:21 AM
>> To: Joel M. Halpern; [email-masked]; [email-masked]
>> Cc: Ben Wright ([email-masked])
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> If I may try to put it simply, I've always thought of it this way:
>> --> Each node in the chain selects the context for processing and the
>> next hop on the basis of BOTH path ID and Index, while decrementing the
>> index for the next hop.
>>
>> That behavior supports spiraling.
>>
>>
>>
>> -Dave
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>> Sent: Thursday, February 26, 2015 10:02 AM
>> To: [email-masked]; [email-masked]
>> Cc: Ben Wright ([email-masked])
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> There are two different aspects of Spirals.
>>
>> One of the two aspects is enabling a packet that repeatedly arrives at
>> the same SFF to get the correct services provided each time it arrives,
>> and to go to the correct next SFF each time it arrives.  The Service Path
>> Index, used by the SFF to select service functions and next SFF, provides
>> that capability.
>>
>> The other aspect is how the Service Functions themselves handle spirals.
>>   To a large degree, that depends upon the individual service function.
>>   I normally assume that it would use packet context (as described in the
>> text you quote) to determine what to do.
>>
>> Since I would prefer that service functions are independent of the
>> underlying service function chaining infrastructure, and are not
>> sensitive to how many functions are before or after them in the chain, I
>> would personally prefer that they not use the path index for that.  I
>> would recommend that if the packet does not carry enough context that the
>> service function could and should use metadata to carry its needed state
>> information.  But neither I personally nor the SFC Working Group get to
>> tell folks how to build their service functions.  So they may come up
>> with other methods for addressing their needs.  Which is also fine.
>>
>> Thus, I would not expect this document to discuss how service functions
>> themselves handle revisiting.  But metadata clearly allows for a range of
>> behaviors that will work.  And the path index handles the SFF needs
>> relative to spirals, which is what we need to handle.
>>
>> Yours,
>> Joel
>>
>> On 2/26/15 9:52 AM, [email-masked] wrote:
>>> Re-,
>>>
>>> Spiral is not mentioned in the draft, but SF loop is.
>>>
>>> I'm asking the question because I don't get from the draft how spirals
>>> could work (that is a SF invoked several time in the context of the same
>>> SFC).
>>>
>>> Before proposing text, I would like to understand first how it works.
>>> If you can provide an example, this will be even great.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Joel M. Halpern [mailto:[email-masked]] Envoyé : jeudi 26
>>>> février 2015 15:41 À : BOUCADAIR Mohamed IMT/OLN; [email-masked] Cc :
>>>> Ben Wright ([email-masked]) Objet : Re: [sfc]
>>>> draft-quinn-sfc-nsh: Support of SF Spiralsgt;>>>

>>>> The SF Spirals requirement is one of the key drivers for the index.
>>>> The index allows one to tell where one is in the spiral, and also to
>>>> break a loop if one has a loop instead of a spiral.
>>>>
>>>> Is there text that we could add that would help make this clear,
>>>> since your earlier question about the path index suggests that it is
>>>> not as clear as it should be?
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 2/26/15 8:42 AM, [email-masked] wrote:
>>>>> Hi Paul, all,
>>>>>
>>>>> There were a discussion in the mailing list
>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>>> an excerpt from
>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>>> the conclusions of that discussion were recorded)
>>>>>
>>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>>> which
>>>>>
>>>>>          data is handled by a Service Function, forwarded onwards,
>>>>> and
>>>>>
>>>>>          arrives once again at that Service Function.
>>>>>
>>>>>          *  Note that some Service Functions support built-in
>>>>> functions to
>>>>>
>>>>>             accommodate spirals; these service-specific functions may
>>>>>
>>>>>             require that the data received in a spiral should differ
>>>>> in a
>>>>>
>>>>>             way that will result in a different processing decision
>>>>> than
>>>>>
>>>>>             the original data.  This document does not make such
>>>>>
>>>>>             assumption.
>>>>>
>>>>>          *  A Service Function Chain may involve one or more Service
>>>>>
>>>>>             Function Spirals.
>>>>>
>>>>>          *  Unlike Service Function loop, spirals are not considered
>>>>> as
>>>>>
>>>>>             errors."
>>>>>
>>>>> And this companion requirement:
>>>>>
>>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>>
>>>>>                       the same Service Function Chain (denoted as SF
>>>>>
>>>>>                       Spiral), but the solution MUST prevent infinite
>>>>>
>>>>>                       forwarding loops. »
>>>>>
>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>>
>>>>> Can you please clarify whether this is supported and how?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Med
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>>
>> _______________________________________________
>> sfc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sfc
>
>