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

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 2 Mar 2015 18:15:38 +0000

> On Feb 26, 2015, at 12:30 PM, Dave Dolson <[email-masked]> 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 do, since it effect it acts a node identifier within a path, and _logically_ you have two firewalls.   There are, as others have pointed out, other ways to handle this (multiple network locators, metadata) but I believe that the index use is straightforward should a service want to use it as such.  If they can’t or don’t want to, I think multiple locators will be used.  They need to be mutually exclusive.

> 
> 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 Spirals
>>>> 
>>>> 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
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc