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

["Joel M. Halpern" <[e-mail]>]

Since there are not always two directions, I would prefer not to define 
that bit as always meaning direction.  I do not mind if the bit is used 
by configuration in a directional fashion.  (It is odd, but clearly works.)

Yours,
Joel

On 7/18/17 9:12 AM, Ron Parker wrote:
> I support 5.4.1 (single SPI with direction indicated in SI).   That 
> being said, the approach effectively reduces SI by 1 bit and reallocates 
> that bit to direction.   Is it feasible to instead be explicit by 
> creating an direction bit?   Also, how do we refer to directions?   
> East/West?   North/South?  Left/Right?   Upstream/Downstream?
> 
>     Ron
> 
> *From:* sfc [mailto:[e-mail]] *On Behalf Of *Kent Leung (kleung)
> *Sent:* Tuesday, July 18, 2017 4:54 AM
> *To:* Reinaldo Penno (repenno) <[e-mail]>; Dave Dolson 
> <[e-mail]>; Roberta Maglione (robmgl) <[e-mail]>; 
> James N Guichard <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [sfc] clarification on Service Path ID for 
> draft-penno-sfc-packet
> 
> Hi Reinaldo. I agree we need to get agreement in WG and update the draft 
> soon as folks are unsure what to implement.
> 
> It seems most folks have chimed in. Here’s the latest count. I’m putting 
> names down to make sure the count is accurate.
> 
> Sect 5.4.1 (one service path ID, service index indicates flow direction):
> 
> -(2) Dave, Joel
> 
> Sect 5.4.2 (two service path IDs, each indicate flow direction):
> 
> -(6) Sumandra, Jim, Kent, Renaldo, Roberta, Paul
> 
> Do we have some rough consensus yet? Or wait for more opinions to decide?
> 
> Kent
> 
> *From:* Reinaldo Penno (repenno)
> *Sent:* Monday, July 17, 2017 3:59 PM
> *To:* Kent Leung (kleung) <[e-mail] <mailto:[e-mail]>>; 
> Dave Dolson <[e-mail] <mailto:[e-mail]>>; 
> Roberta Maglione (robmgl) <[e-mail] <mailto:[e-mail]>>; 
> James N Guichard <[e-mail] 
> <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [sfc] clarification on Service Path ID for 
> draft-penno-sfc-packet
> 
> Hi Kent/others,
> 
> this decision is quite important for real deployments, as opposed to 
> demos and related.  I hope as the first step we all agree that we cannot 
> have more than one way of interpreting directionality of paths and 
> associated reverse paths. That would be an interoperability nightmare 
> and reduce the usefulness of NSH considerably.
> 
> So, whatever way it goes the WG needs to embrace it.
> 
> Thanks,
> 
> *From: *sfc <[e-mail] <mailto:[e-mail]>> on 
> behalf of "Kent Leung (kleung)" <[e-mail] <mailto:[e-mail]>>
> *Date: *Monday, July 17, 2017 at 10:36 AM
> *To: *Dave Dolson <[e-mail] <mailto:[e-mail]>>, 
> "Roberta Maglione (robmgl)" <[e-mail] 
> <mailto:[e-mail]>>, James N Guichard 
> <[e-mail] <mailto:[e-mail]>>
> *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> *Subject: *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:[e-mail]]
> *Sent:* Monday, July 17, 2017 3:01 PM
> *To:* Roberta Maglione (robmgl) <[e-mail] 
> <mailto:[e-mail]>>; James N Guichard 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* Kent Leung (kleung) <[e-mail] <mailto:[e-mail]>>; 
> [e-mail] <mailto:[e-mail]>
> *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:[e-mail]]
> *Sent:* Monday, July 17, 2017 11:00 AM
> *To:* James N Guichard
> *Cc:* Dave Dolson; Kent Leung (kleung); [e-mail] <mailto:[e-mail]>
> *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 
> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]]
>     *Sent:* Friday, July 14, 2017 2:51 PM
>     *To:* James N Guichard <[e-mail]
>     <mailto:[e-mail]>>; Kent Leung (kleung)
>     <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *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:[e-mail]] *On Behalf Of *James N Guichard
>     *Sent:* Friday, July 14, 2017 2:25 PM
>     *To:* Kent Leung (kleung); [e-mail] <mailto:[e-mail]>
>     *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:[e-mail]] *On Behalf Of *Kent Leung
>     (kleung)
>     *Sent:* Friday, July 14, 2017 1:58 PM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sfc
>     <https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~>
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>