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

[Ron Parker <[e-mail]>]

Good point on the optionality of this bidirectional concept.

For the bidirectional case, we would ultimately like to know the correlation of the 2 paths.    I'm thinking that this is more, even, than correlating the "forward" SPI and the "reverse" SPI.   It also becomes useful to correlate the position of a particular service function.   A strict presumption of mirrored order for the 2 directions does not always hold.   Lets say in the forward direction we want SF types A, B, C, D but in the reverse direction we want A, D, C, B.   It would be useful to know that SF D appears at the 4th position of the forward flow and the 2nd position of the correlated reverse flow.   This starts to become too heavy to insert into the encapsulation itself.   Instead, this full knowledge can be achieved through control plane distribution and stateful elements (e.g., SFF, SF).

So, the encapsulation can carry all of the correlation information, none of the correlation information, or some of the correlation information.    I'm not so sure "some" is that useful.

   Ron


-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Tuesday, July 18, 2017 9:58 AM
To: Ron Parker <[e-mail]>; Kent Leung (kleung) <[e-mail]>; 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

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://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~
>     
> <https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_
> jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~>
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_j
> Yzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~
>