Subject: [sfc] Comments on draft-ww-sfc-control-plane-04

From: Dave Dolson <[email-masked]>
Date: Fri, 29 May 2015 20:42:27 +0000

Authors of draft-ww-sfc-control-plane,

I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

I have some very high-level suggestions:

1.       I believe the "F" interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information.

Call these F1 and F2, I suppose. My reasons are that (a) as a general principle, interfaces should not have multiple purposes and (b) F1 and F2 could be communicating to different control-plane managers.

2.       A control interface is required to SF components. Call it C3. This interface is required to (a) inform the SF about bidirectional chains (i.e., which Path IDs are paired) and (b) inform the SF about semantics of types of meta-data. C3 should also be connected to the SFC Proxy.

I propose:

4.5  C3 Interface

   A service function may need information about the service paths
   passing through it, and may need information about specific meta-data
   types attached to packets on the paths.

   Some types of SF might be agnostic about the paths traversing them, but
   most transport-layer-flow-aware devices will require this configuration.

   When bidirectional chains are deployed, the C3 interface provisions
   each SF with each path identifier/path index pair that will pass through.
   Each such pair is associated with an opposite-direction pair of
   identifier/index.

   Meta-data is for the benefit of SFs. The C3 interface informs the SF
   about the semantics of the meta-data, which would otherwise have
   opaque meaning. Meta-data attributes include "scope" (per-packet, per-flow
   or per host), "mandatory" (must be understood), "bidirectional" (same
   value may be used in both directions), "is_qualifier" (indicates a
   distinct routing domain).

I think there is quite a bit to explore, but I believe this starts the discussion.
Thoughts?

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: "Huangyong (Oliver)" <[email-masked]>
Date: Sat, 30 May 2015 01:06:21 +0000

Hello Dave,

        Thank you for your detailed consideration on the draft.  I agree that the SF should support the capability of bidirectional chains. For example, the NAT SF may provide the new allocated address/port to the controller.  You mentioned the control plane should inform SF bidirectional chain (which path id are paired).  I have question why not the SFC forwarding system handle the paired chain itself?

        Performance mornitoring is a basic capability which should exist in all interfaces C1,C2,C3.

        Mohamed have developed a new version of this draft and made a big promotion. In the new draft, C3,C4 are introduced for SF and SF proxy separately.  I think it may cover the related scenario.  I attached it in this email,  please check it.

        Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are representative of Huawei on this draft. Please contact more detail to them.   Thank you very much!

BR
Oliver

---------------------------
Huangyong (Oliver)
Network research, Huawei

From: Dave Dolson [mailto:[email-masked]]
Sent: Saturday, May 30, 2015 4:42 AM
To: [email-masked]; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Comments on draft-ww-sfc-control-plane-04

I propose:

4.5  C3 Interface

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Sat, 30 May 2015 12:13:59 +0000

I will review the document later, but I can quickly answer your question.
> I have question why not the SFC forwarding system handle the paired chain itself?

Here is the very simple example that indicates the problem:
 - An SF firewall has a policy to respond to not-permitted incoming connections with TCP RST
(rather than allowing the connection to reach the protected host).
 - Therefore when a TCP SYN packet arrives at the SF firewall with NSH encapsulation
having path ID x and Path Index y, it must be able to insert the response into the path that is
the bidirectional complement, an NSH encapsulation having path ID x' and path index y' to send
the packet back to the source, following the reverse path.

I hope that shows why the paths need to be paired?

I believe that most flow-stateful devices will require the pairing information.

-Dave

________________________________
From: Huangyong (Oliver) [[email-masked]]
Sent: Friday, May 29, 2015 9:06 PM
To: Dave Dolson; [email-masked]; Hongyu Li (Julio); Qin Wu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

Hello Dave,

BR
Oliver

I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

1.      I believe the “F” interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information.

I propose:

4.5  C3 Interface

David Dolson

---

From: Joel Halpern <[email-masked]>
Date: Sat, 30 May 2015 14:33:05 -0400

Clearly, there are cases where a service funtion will originate packets.
I would strongly hope that the service function is not required to know 
the details of the service function path identification inorder to do so.
My assumption has been that to support this need (both for bidirectional 
cases, and for others), there would be a classifier in place to apply 
the necessary headers.  That classifier could be colocated with the SFF, 
or could be colocated with the service function itself.

Thus, if one wants to deploy a service function and the ability to add 
path information, I would expect a service funciton with colocated 
classifier.  Arguably this is only a descriptive difference.  But that 
description keeps much clearer what functionality we are discussing, and 
where it may exist.

Yours,
Joel

On 5/30/15 8:13 AM, Dave Dolson wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Dave Dolson <[email-masked]>
Date: Sat, 30 May 2015 20:45:49 +0000

If, in the general case, every SF requires a co-located classifier, doesn't that lead to the question of why an SFC data-plane protocol (NSH) is required? Every SF could choose the next hop with a classifier.

But no, I think we all see the benefits of avoiding classification in the SF.
Telling the SF about some aspects of the encapsulation goes a long way.
‎

David Dolson
Senior Software Architect, Sandvine Inc.
  Original Message
From: Joel Halpern
Sent: Saturday, May 30, 2015 2:33 PM
To: [email-masked]
Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 May 2015 16:57:14 -0400

I don't see any indication that every SF requires a classifier.  There 
are some functions that need it.  But most functions are not generating 
packets nor changing the path the packets are on.

Yours,
Joel