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

From: Sumandra Majee <[email-masked]>
Date: Fri, 14 Jul 2017 20:28:50 +0000

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 <[email-masked]> on behalf of Dave Dolson <[email-masked]>
Date: Friday, July 14, 2017 at 11:50 AM
To: James N Guichard <[email-masked]>, "Kent Leung (kleung)" <[email-masked]>, "[email-masked]" <[email-masked]>
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:[email-masked]] On Behalf Of James N Guichard
Sent: Friday, July 14, 2017 2:25 PM
To: Kent Leung (kleung); [email-masked]
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:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Friday, July 14, 2017 1:58 PM
To: [email-masked]<mailto:[email-masked]>
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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Jul 2017 16:37:45 -0400

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:
> 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.
> 
> *From: *sfc <[email-masked]> on behalf of Dave Dolson 
> <[email-masked]>
> *Date: *Friday, July 14, 2017 at 11:50 AM
> *To: *James N Guichard <[email-masked]>, "Kent Leung 
> (kleung)" <[email-masked]>, "[email-masked]" <[email-masked]>
> *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.
> 
> Personally, I find use of a single SPI to be more elegant,  consuming 
> only one path ID instead of two. (section 5.4.1).
> 
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *James N Guichard
> *Sent:* Friday, July 14, 2017 2:25 PM
> *To:* Kent Leung (kleung); [email-masked]
> *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:[email-masked]] *On Behalf Of *Kent Leung (kleung)
> *Sent:* Friday, July 14, 2017 1:58 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 17 Jul 2017 12:39:51 +0000

On Jul 14, 2017, at 4:28 PM, Sumandra Majee <[email-masked]<mailto:[email-masked]>> 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.

I do as well.  It's simple and allows an operator to easily troubleshoot a path.