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

[<[e-mail]>]

Re-,

I do have the following comments:

* I do agree with Reinaldo with regards to unidirectional SPIs.

* Assuming by default that the SPI is inherited from the received NSH packet may lead to failures. Consider the example of a chain with NATs and FWs. Because the packet will be generated by an SF (that may not be the ultimate destination of the original packet), no corresponding state will be found in those NATs (non EIM/EIF)/FW. I'm not sure whether "no-op" feature softens the problem. 

* Generating packets by an SF may not be triggered by a received NSH packet. Obviously, inheriting NSH-related information may not be possible in that case. A typical example is a service chain that involves an MPTCP proxy. The proxy can at any time during the connection add new subflows to the source.    

* I don't think that we should assume that SF-generated packets must always be stamped with an NSH header. This is IMHO deployment-specific. Like any other packets generated by a (SFC-unware) node in the forwarding path, packets generated by an SFC-aware SF should be able to fly back without any SFC processing at all, too. Again, this is deployment-specific. 

* Putting aside other aspects, that are btw discussed appropriately in the draft such as metadata cloning, which destination IP address to use to send back the packet? Some complications may arise when NATs are involved.

Given that, I'm less for an algorithmic approach but for control-based approach at the SFC-aware SF and/or classifier.  

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[e-mail]] De la part de Kent Leung (kleung)
> Envoyé : mercredi 26 juillet 2017 00:32
> À : Reinaldo Penno (repenno); Joel M. Halpern; Ron Parker; Dave Dolson;
> Roberta Maglione (robmgl); James N Guichard
> Cc : [e-mail]
> Objet : 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>
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc