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
> 