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

The current architecture and the current NSH document both avoid any 
discussion of or implication of using a MASK applied to the SP-ID.  It 
is a large field because of the range of use cases that were requested 
to be supported (some of which use a large number of service function paths.

Evne this use is compatible with using the full SP-ID and SI as the 
lookup keys for the forwarding decision.

Yours,
Joel

On 7/14/17 4:28 PM, Sumandra Majee wrote:
> Fundamentally it is all about how divide up the SPI+SI space.
> 
> However, we like the service path SPI to be unique per direction. If the 
> forward and reverse path reversing the order of traversal then use a bit 
> flag (simple algorithmic) to derive the reverse SPI. This is sort of how 
> our implementation works today.
> 
> While we are at SPI bitfield allocation topic, 24 bit is quite a lot, 
> apologies if it has been disused earlier.
> 
> I am sure implementers would use many of those bits for various other 
> things, in that case SFF needs to know the MASK flag to separate out 
> forwarding table pointer.
> 
> SPI-fwding-tablePtr = SP & MASK
> 
> *From: *sfc <sfc-bounces@ietf.org> on behalf of Dave Dolson 
> <ddolson@sandvine.com>
> *Date: *Friday, July 14, 2017 at 11:50 AM
> *To: *James N Guichard <james.n.guichard@huawei.com>, "Kent Leung 
> (kleung)" <kleung@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
> *Subject: *Re: [sfc] 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
> *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
> 