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

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

Hi Med. Thanks for clarifying with the MPTCP example.

In general, draft-wang-sfc-ns-use-cases covers the two fundamental use cases in sects 4.3.1 and 4.3.2. The solution for the former is documented in draft-penno-sfc-packet, which puts the generated packet for "reverse flow direction" in the correct reverse SPI/SI. The latter is when SF initiates a new flow, which is not the problem statement addressed by draft-penno-sfc-packet, AFAIK. I think the right solution for this particular scenario would be using internal classifier or external classifier.

The MPTCP MP_JOIN example seems to map to the SF initiated flow use case. Perhaps an internal classifier in SF would map associated subflows to a common service path used by the MPTCP session. Just a thought for implementation option.

Are you asking to expand the scope of this draft beyond injected new packet to include the initiated connection use case? I'll let other authors chime in if that's the case.

Kent

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, July 26, 2017 11:36 PM
To: Kent Leung (kleung) <[e-mail]>
Cc: [e-mail]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Kent Leung (kleung) [mailto:[e-mail]] Envoyé : mercredi 
> 26 juillet 2017 18:08 À : BOUCADAIR Mohamed IMT/OLN Cc : [e-mail] 
> Objet : RE: [sfc] clarification on Service Path ID for 
> draft-penno-sfc- packet
> 
> Hi Mohamed. See comments below.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> Sent: Wednesday, July 26, 2017 4:22 AM
> To: Kent Leung (kleung) <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [sfc] clarification on Service Path ID for 
> draft-penno-sfc- packet
> 
> Re-,
> 
> I do have the following comments:
> 
> * I do agree with Reinaldo with regards to unidirectional SPIs.
> 
> KL> OK. One more for unidirectional SPI.
> 
> 
> * 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.
> 
> KL> There are various use cases when SF generates packet. See
> https://tools.ietf.org/html/draft-wang-sfc-ns-use-cases-03#page-14. We 
> believe this draft is helpful in understanding various scenarios and 
> want to pursue informational track. If you or others want to help, 
> please let us know. The NOP is dealing with asymmetric SFC.

[Med] Thanks for the pointer. draft-wang-sfc-ns-use-cases mixes various functions of a "firewall": TCP proxy, NAT, stateful filtering, etc.  
My main comment is that the packet generated by an SF may be blocked by other stateful SFs because no mapping will be matching packets from the SF. I would expect such details to be included in the sfc-packet draft.  

> 
> 
> * 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.
> 
> KL> Agree. See draft mentioned above.

[Med] I would expect this to be discussed in the sfc-packet draft since this have an implication on the solution to be recommended (if we need such reco). Typically, how algorithmic approaches solves the issue for this particular case should be discussed. 

> 
> 
> * 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.
> 
> KL> Agree. See Option #2 in the reference above. Let us know if that's
> clear.

[Med] Idem as above. I would expect this to be covered in the sfc-packet I-D. 

> 
> 
> * 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.
> 
> KL> The draft-penno-sfc-packet is dealing with this use case, 
> KL> "generate
> packets in the reverse flow direction destined to the source of the 
> current in-process packet/flow." So the dest IP address is the source 
> IP address of the received packet.

[Med] This may be intuitive but this cannot be generalized to all SFs. Let's consider the example of an MPTCP proxy that receives an ADD_ADDR from a client, the MPTCP proxy can send back an MP_JOIN to the address conveyed in ADD_ADDR, not the source IP address of the initial packet. 

 A packet that is NAT'ed needs to be
> addressed as an independent topic.
> 

[Med] Why NAT should be treated as a special SF?

> 
> Given that, I'm less for an algorithmic approach but for control-based 
> approach at the SFC-aware SF and/or classifier.
> 
> KL> The control plane option (sect. 5.1) does require controller/SF
> interface.

[Med] Yes. That interface can leverage on existing interface to provision other non-SFC SF features. Further, as mentioned above, packets generated by an SF may or may not be stamped with an NSH header.  

 There are additional operational responsibility on SF to
> maintain state for reverse path, controller to ensure consistency 
> between SF and SFF for SPIs, timing window when SPIs are configured, 
> etc. It seems algorithmic method avoids chances for problems to be 
> encountered in deployment.

[Med] I disagree. See the example I cited above. The algorithmic approach may work with some assumptions on the SFs; those assumptions are not generic.  

 Simple is better in terms there's only one touch point
> (automatic) vs. two touch points (control).

[Med] I cannot argue that it is simple at this stage.

> 
> Thanks for your feedback.
> 
> Kent
> 
> 
> 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