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

From: <[email-masked]>
Date: Thu, 26 Feb 2015 13:42:43 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 09:41:10 -0500

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
>
> “               A.  Service Functions MAY be invoked multiple times in
>
>                     forwarding loops. »
> Reading the current draft-quinn-sfc-nsh, I don’t see how this is met.
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: <[email-masked]>
Date: Thu, 26 Feb 2015 14:52:31 +0000

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
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 10:02:28 -0500

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

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Feb 2015 16:20:58 +0000

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

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 26 Feb 2015 16:30:30 +0000

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

-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

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:
>> 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
>>
>>> (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)
>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Feb 2015 16:42:40 +0000

Surely the responsibility of the SFC infrastructure is to deliver packets
to the SF where said SF ³does it thing². It seems to me that if you want
different behavior each time you visit a given SF then you need to provide
it context within the metadata so it can perform the right task.

On 2/26/15, 11:30 AM, "Ron Parker" <[email-masked]> wrote:

>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
>
>
>--> 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.
>
>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.
>
>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.
>
>themselves handle revisiting.  But metadata clearly allows for a range of
>behaviors that will work.  And the path index handles the SFF needs
>> 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
>>

---

From: Ron Parker <[email-masked]>
Date: Thu, 26 Feb 2015 16:46:51 +0000

Agree that metadata is one way to handle this, implying that SF-foo in my example knew that for this particular chain it was invoked in a spiral and therefore its first invocation needed to insert metadata so that its subsequent invocations could do the right thing.

There is also an implication on RSP construction and binding -- the same instance of SFF-foo likely needs to be selected at each position that it occurs within the SFP.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 11:43 AM
To: Ron Parker; 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

Surely the responsibility of the SFC infrastructure is to deliver packets to the SF where said SF ³does it thing². It seems to me that if you want different behavior each time you visit a given SF then you need to provide it context within the metadata so it can perform the right task.

On 2/26/15, 11:30 AM, "Ron Parker" <[email-masked]> wrote:

>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}.
>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
>
>
>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 
>> 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).
>>
>>>> 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)
>>>>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Feb 2015 16:52:02 +0000

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.

   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

-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

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Feb 2015 16:54:43 +0000

I think using metadata is more complicated than using the path Index.
You'd have to arrange for it to be set properly by neighbors. It just makes it someone else's problem, which is a more difficult problem.

On the other hand, the Index is already guaranteed to be unique at each link in the chain.

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 11:47 AM
To: Jim Guichard (jguichar); 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

   Ron

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 26 Feb 2015 17:18:15 +0000

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:

>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).
>
>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:
>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
>
>
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 26 Feb 2015 17:21:35 +0000

Hi Dave,

Yes of course and I did not mean to imply that the index is not relevant.
The point is that the SPI/SI is used to steer the traffic and then if an
SF wishes to do something different at each service hop then the metadata
can provide the necessary context.

On 2/26/15, 11:54 AM, "Dave Dolson" <[email-masked]> wrote:

>You'd have to arrange for it to be set properly by neighbors. It just
>makes it someone else's problem, which is a more difficult problem.
>
>To: Jim Guichard (jguichar); Dave Dolson; Joel M. Halpern;
>[email-masked]; [email-masked]
>Agree that metadata is one way to handle this, implying that SF-foo in my
>example knew that for this particular chain it was invoked in a spiral
>and therefore its first invocation needed to insert metadata so that its
>subsequent invocations could do the right thing.
>
>There is also an implication on RSP construction and binding -- the same
>instance of SFF-foo likely needs to be selected at each position that it
>occurs within the SFP.
>
>   Ron
>
>
>To: Ron Parker; Dave Dolson; Joel M. Halpern;
>[email-masked]; [email-masked]
>different behavior each time you visit a given SF then you need to
>provide it context within the metadata so it can perform the right task.
>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Feb 2015 17:30:03 +0000

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" ?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 12:35:40 -0500

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

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 26 Feb 2015 17:37:59 +0000

>the ingress or egress rule sets should be used?

[RP] Yes. But it is really up to the SF to decide what to do when it looks
up the SI.  From a SFF perspective the tuple SP/SI denotes a network
endpoint. If the SF uses internally a SI as a demux to map to different
policies or rules it is really an implementation detail.

>by sending state in the packet. Is that what you are mean by "contextual

[RP] Precisely. 

>To: Dave Dolson; Ron Parker; Joel M. Halpern;

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 Feb 2015 18:14:20 +0000

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

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 26 Feb 2015 20:18:58 +0000

I think this would be implementation choice.

Fo example traffic comes back to a steering device multiple times (as
implemented today) and the differentiator is either the VLAN, tunnel or
port. This is similar to SF index, and I agree with Dave that what might
the most common way of solving spiraling problem. But my personal opinion
is not to encumber protocol with these detail.

Sumandra

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 26 Feb 2015 20:51:56 +0000

I would agree with that.

An SF trying to figure out what SFCs it is part of and at what location it
is present in each of those SFCs, thus adds severe constraints to how such
an SF can be deployed. An SF limiting itself to service function delivery
alone, aided by the metadata, not only keeps the SF simple, allows for
very flexible deployments as well.

Surendra.

On 2/26/15, 9:35 AM, "Joel M. Halpern" <[email-masked]> wrote:

>>> Maybe naively, I thought the service functions would be provisioned
>>>with
>>> a table:
>>>
>>> E.g., for element foo:
>>>lacking
>>>isn't
>>>Path
>>>I
>>>the
>>>of

---

From: Dave Dolson <[email-masked]>
Date: Fri, 27 Feb 2015 17:08:50 +0000

No chain can be deployed without writing to the forwarding table of each SF in the chain.
In other words, an SF must have a table entry for each occurrence in a chain, keyed by (SPI, SI) pair.

Given that, I think it would be quite useful to add an extra column to the forwarding table defined in section 9.1:

    +-------------------+----------+
    | SPI |  SI |  NH   | Role     |
    +-------------------+----------+
    | 10  |  3  |  SF2  | "Foo"    |
    | 245 |  12 |  SF34 | "ingress"|
    | 40  |  9  |  SF9  | "egress" |
    +-------------------+----------+

Call the new column "Role" or "Function". It is an indirection to anything the SF vendor wishes to permit. In many cases it would be a configuration set.

I think this gives a mechanism for the spiral use cases.

This new column doesn't have any (direct) impact on what appears on the wire, so I can see it might not belong in draft-quinn-sfc-nsh, rather in the configuration model.

Speaking of which, I can't find the above SPI/SI/NH table in draft-penno-sfc-yang. Are these drafts yet to be reconciled?

-----Original Message-----
From: Surendra Kumar (smkumar) [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 3:52 PM
To: Joel M. Halpern; 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

I would agree with that.

Surendra.

On 2/26/15, 9:35 AM, "Joel M. Halpern" <[email-masked]> wrote:

>>> text you quote) to determine what to do.
>>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 27 Feb 2015 12:12:22 -0500

Do you ean SF or SFF?  The table in section 9.1 is an SFF table.  I 
don't understand how adding extra information there would help an SF 
builder.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Fri, 27 Feb 2015 17:55:01 +0000

Ahhh, that's my mistake, being stuck with the mental model of a device with combined SF/SFF features.

Thank you for helping me sort that out.

An SFC-aware SF could have a table like the following, but there is probably no need to standardize it at this level. Maybe at netconf level.

     +-----------+----------+
     | SPI |  SI | Role     |
     +-----------+----------+
     | 10  |  3  | "Foo"    |
     | 245 |  12 | "ingress"|
     | 40  |  9  | "egress" |
     +-----------+----------+

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Friday, February 27, 2015 12:12 PM
To: Dave Dolson; Surendra Kumar (smkumar); 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

Yours,
Joel