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

["Kent Leung (kleung)" <[e-mail]>]

I think that would be a good compromise. If that would swing some of the 5.4.1 folks over, then I'm in favor of such an idea.

Kent
 
-----Original Message-----
From: Dave Dolson [mailto:[e-mail]] 
Sent: Tuesday, July 25, 2017 6:55 PM
To: Kent Leung (kleung) <[e-mail]>; Reinaldo Penno (repenno) <[e-mail]>; Joel M. Halpern <[e-mail]>; Ron Parker <[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

Are the 5.4.2 folks willing to consider using the lower bit for odd/even pairs instead of the upper bit?

David Dolson
Sandvine
  Original Message
From: Kent Leung (kleung)
Sent: Tuesday, July 25, 2017 6:32 PM
To: Reinaldo Penno (repenno); Joel M. Halpern; Ron Parker; Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc: [e-mail]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet


It seems enough time has elapsed for folks to chime in their preferences on the solution option.

I believe that communication between two endpoints is based on flow traffic from source to destination. A service path dictates which service functions are applied for the traffic. Technically, a flow is terminated at the receiving endpoint. So, the service path ended at the last hop. Communication may be uni-directional (one flow) or bi-directional (two flows). RFC 7665 describes SFC as steering of traffic flows through service functions. My interpretation is that the service path is associated with the flow. A new flow going in the reverse direction should be treated with a new service path (set up to handle that flow) and not continuation of the same service path (set up to handle original flow) in the forward direction. Seems logical to me from that perspective.

The service path ID is used to identify the service path and the service index is used to identify the location within the service path as stated in current NSH draft:

" NSH contains a Service Path Identifier (SPI) and a Service Index (SI).  The SPI is, as per its name, an identifier" of the service path.

"The Service Index provides an indication of location within a service path."

Given that both options support asymmetric and symmetric SFCs, has anyone change their mind on selecting an option to go forth? Based on the feedback, it seems that we all agree to choose one solution instead of allowing multiple options for addressing reverse packet generation scenario. Now, what should we need to do to achieve that? Rock-paper-scissor? :)

Current count as Joel is OK with either option.

Sect 5.4.1 (one service path ID, service index indicates flow direction):

-       (4) Dave, Joel, Ron, Kyle

Sect 5.4.2 (two service path IDs, each indicate flow direction):

-       (7) Sumandra, Jim, Kent, Renaldo, Roberta, Paul, Joel

Kent

<snip>