Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent,

FWIW, there was an attempt to define this term in https://tools.ietf.org/html/draft-boucadair-sfc-requirements-06. Below an excerpt from that draft:

==
   o  Service Function Loop: If a Service Function Chain is structured
      to not invoke Service Functions multiple times, a loop is the
      error that occurs when the same Service Function is invoked
      several times when handling data bound to that Service Function
      Chain.  In other words, a loop denotes an error that occurs when a
      packet handled by a Service Function, forwarded onwards, and
      arrives once again at that Service Function while this is not
      allowed by the Service Function Chain it is bound to.

   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.
==

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Kent Leung (kleung)
Envoyé : lundi 17 juillet 2017 15:37
À : Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc : sfc@ietf.org
Objet : Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Why can't there be stats for per SPI and more granular stats for per SPI/SI? They seem to serve different purposes. The former is providing counters for all flows in each service path. The latter is provide counters for all flows served at each hop in the service path.

Can you explain the "spiral" scenario and how that pertains to usefulness of having per service path stats? Thanks.

Kent

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Monday, July 17, 2017 3:01 PM
To: Roberta Maglione (robmgl) <robmgl@cisco.com<mailto:robmgl@cisco.com>>; James N Guichard <james.n.guichard@huawei.com<mailto:james.n.guichard@huawei.com>>
Cc: Kent Leung (kleung) <kleung@cisco.com<mailto:kleung@cisco.com>>; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Strictly, stats should be per SPI and SI, in order to support the so-called spiral.
But I can see how folks might find the lazy implementation to be useful.

From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com]
Sent: Monday, July 17, 2017 11:00 AM
To: James N Guichard
Cc: Dave Dolson; Kent Leung (kleung); sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

I agree on the operational aspect: having different SPI's for each direction simplifies the troubleshooting procedures, as statistics on the packets counters for each direction on each SF, can be displayed just based on SPI.
Regards,
Roberta

Inviato da iPad

Il giorno 15 lug 2017, alle ore 01:09, James N Guichard <james.n.guichard@huawei.com<mailto:james.n.guichard@huawei.com>> ha scritto:
Yes understood but I was assuming no manipulation of the SI and my point was more from an operational perspective; if I use the same path ID in both directions then I cannot immediately tell in which direction the packets are flowing unless I go one step deeper and look at the SI leading to a correlation of SPI + SI to be able to figure out my traffic matrix. Not so if the SPI is uni-directional.

Jim

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Friday, July 14, 2017 2:51 PM
To: James N Guichard <james.n.guichard@huawei.com<mailto:james.n.guichard@huawei.com>>; Kent Leung (kleung) <kleung@cisco.com<mailto:kleung@cisco.com>>; sfc@ietf.org<mailto:sfc@ietf.org>
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

There is not actually forwarding ambiguity, since SFF forwarding depends on *both* SPI and SI.
So for example, there is no ambiguity in forwarding to use SI in the range [0,127] of up-link and range [128,255] for down-link, on the same SPI.
The limitation is ~127 SFs per path instead of ~255.

As I see it, Kent's question is one of aesthetics. Do folks like the same SPI used for two directions?

Personally, I find use of a single SPI to be more elegant,  consuming only one path ID instead of two. (section 5.4.1).
It may make debugging easier as well.

Also, for what it's worth, we demonstrated this method of section 5.4.1 at a previous IETF hackathon.

-Dave

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard
Sent: Friday, July 14, 2017 2:25 PM
To: Kent Leung (kleung); sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent,

[personal opinion ...] I have always assumed that the service path ID would be uni-directional given that it would be difficult to avoid collision in all forwarding scenarios. If you look at a basic SFC a-b-c and the service index is set to 255 at the classifiers a & c (which imho will be the normal practice) then at b you would have a conflict if the same service path ID is used in both directions.

Jim

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Kent Leung (kleung)
Sent: Friday, July 14, 2017 1:58 PM
To: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi. We are working on a revision for this draft. There were 4 proposed solution options in section 5. During some discussions, most folks seem to favor the use of algorithmic method in section 5.4. However, there are 2 sub-options. One is based on same Service Path ID and using Service Index to determine flow direction (sect. 5.4.1). The other is based on setting high order bit on Serve Path ID, which determines flow direction (sect. 5.4.2). There are mixed opinions. One reason is that there may be the assumption the Service Path ID is uni-directional. No explicit wording of that nature has been encountered in the RFCs, maybe we missed something?

If Serve Path ID is required to be uni-directional, then the answer is easy (=> 5.4.2). We would like to solicit WG comments to get rough consensus and revised the next version with that solution. This problem is critical to address for Service Function that generate packet in reverse direction, especially security service functions as mentioned in draft-wang-sfc-ns-use-cases.

Thanks.

Kent
_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc