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

Joel,
Both of the algorithmic approaches discussed need to make assumptions about the symmetry of the reverse path. (Same SFs, in reverse order.)

-Dave

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com] 
Sent: Friday, July 14, 2017 4:08 PM
To: Dave Dolson; James N Guichard; Kent Leung (kleung); sfc@ietf.org
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

I find myself torn.  (And speaking personally in all that follows.)

There are actually two issues buried onder here.
Unless the reverse SFP is set up, and is congurent, the forwarding state may not exist.
Congruent reverse is only required when the nature of the SFP is such that reverse traffic must go through the same seqeunce of SFs, albeit in the reverse order, as the forward traffic.  That is not mandatory.  Even if some elements are common (as for example a TCP proxy), that doe snot mean that all are common and that full congruence is required.

To make this clearer, given an SFP that goes through SFFs A, B, and C, there is no requirement that SFF B have forwarding state for any specific SPI / SI to take reverse traffic.

So one of the points is to be explicit that a backwards path needs to be established (by control, routing, magic, ...) from those entities which need to send such reverse packets.  Which means that someone has to be able to determine where that is required.

Now, if we assume that piece of knowledge gets communicated, and the path is established, the quesiton you are asking is how to identify that reverse path.

I take Dave's point that there is a simplicity and efficiency in using the same SPI.  I find it conflicts with my personal view on how SPIs work.  But that is my problem, not the WGs.  The strong argument in favor is in fact that there can only be 64 different SIs in each direction, so there is plenty of room to keep things far enough apart that accidental wrap is not possible.

Net: using the SI grates on my nerves, but is probably sufficiently robust that it is a very reasonable choice.

Yours,
Joel

On 7/14/17 2:50 PM, Dave Dolson wrote:
> 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
> *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
> https://www.ietf.org/mailman/listinfo/sfc
> 