Subject: [sfc] draft-ietf-sfc-control-plane -- C3 interface

From: Dave Dolson <[email-masked]>
Date: Thu, 28 Apr 2016 17:57:27 +0000

Regarding https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.3.3
C3: Interface between SFC Control Plane & SFC-aware SFs

Shouldn't information about bidirectional paths be in scope for C3 ?
E.g., as in section 5.1 of https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt
Maybe add this paragraph:
"This interface informs the SFC-aware SF about the method for handling bidirectional paths,
either by conveying the algorithmic method to use, or by providing forward/reverse path
mapping."
The alternative, in my opinion, is to standardize on an algorithmic method for computing bidirectional paths.

I'm uneasy about C3 carrying information specific to applications, such as
    "a threat-detecting  SF can periodically send the threat characteristics via this
      interface, such as high probability of threat with packet of a
      given size."
This seems like it should be out of scope of C3. Instead I think there would be an application on top of the controller.
Thoughts?

In this paragraph, does "context information" mean metadata? If so, can that be made clear that the SFC is being asked to add metadata to the packet?
   This interface is also used to instruct an SFC-aware SF about any
   context information it needs to supply in the context of a given SFC.

Regarding this paragraph, I think it would be cleaner if this behavior actually requires the C2 interface into the SF.
(Because although the statement is that the SF doesn't have an SFF in the node, it actually does have the SFF behavior. So call it what it is, an SFF.)
  Multiple SFs may be located within the same physical node, and no SFF
   is enabled in that same node, means to unambiguously forward the
   traffic to the appropriate SF must be supported.  Concretely, each SF
   must have a unique locator for unambiguous forwarding.

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: <[email-masked]>
Date: Fri, 29 Apr 2016 06:51:04 +0000

Re-,

Please see inline.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : jeudi 28 avril 2016 19:57
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : draft-ietf-sfc-control-plane -- C3 interface

[Med] Yes. This is actually covered in https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-4.2. The current wording does not recommend how this bidir will be ensured because this is likely to be SF-specific and deployment-specific.

[Med] I'm hesitating to add text about the "algorithmic method" as I don't have a document to cite. Note that some stateful SFs (e.g., NAT) will naturally add a reverse mapping to handle incoming packets without requiring inputs from the CP. What do you mean by "providing forward/reverse path mapping"? Is it SF-specific mapping?

What about adding this NEW text at the end of Section 4.2?

NEW:
   Typically, C2 interface is used to ensure that the same SF instance
   is involved in both directions of a flow (including, to ensure full
   chain symmetry).

[Med] The text you quoted is an example to illustrate how a feedback loop may be useful to adjust SFPs. I do see value in having such information available to the chaining decision engine. Obviously, this text does not exclude that this information can be acquired by another dedicated application on top of a control element.

Thoughts?

[Med] FWIW, context information is mentioned in the WG charter "communicates context information between nodes that implement". What about this change to avoid confusion:

OLD:

NEW:
   This interface is also used to instruct an SFC-aware SF about any
   context information (a.k.a., metadata) it needs to supply
   for a given SFC.

[Med] I do think the current wording is correct. Having an SFF co-located with a set of SFs is deployment-specific according to the SFC architecture RFC.

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Fri, 29 Apr 2016 14:24:15 +0000

Please see inline [DD]

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 29, 2016 2:51 AM
To: Dave Dolson; [email-masked]
Subject: RE: draft-ietf-sfc-control-plane -- C3 interface

Re-,

Please see inline.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : jeudi 28 avril 2016 19:57
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : draft-ietf-sfc-control-plane -- C3 interface

[DD] I agree there is a lack of material to cite...
[DD] What I mean is informing the SF that "path X is the complementary path of path Y". E.g., "Paths 100 (upstream) and 101 (downstream) are pairs. Respond to a path-100 packet on path 101."

NEW:
   Typically, C2 interface is used to ensure that the same SF instance
   is involved in both directions of a flow (including, to ensure full
   chain symmetry).
[DD] I disagree that C2 has anything to do with this. Instead, C1 must be used to provide consistent classification.
[DD] How about adding the generic statement to section 3.3.3, "Some SFs may need to be configured regarding the rules for packet reversal on a path. The controller may use the C3 interface to specify how packets on a path may be placed on the reverse path."

Thoughts?

OLD:

NEW:
   This interface is also used to instruct an SFC-aware SF about any
   context information (a.k.a., metadata) it needs to supply
   for a given SFC.
[DD] Again, is this intended to mean adding information to a packet? Or is "supply" intentionally vague about the delivery mechanism?

[DD] I agree with that statement. However, I think the case being described is when there *is* a co-located SFF, but the text is pretending there isn't. If the following text remains, C3 will need to include all the functionality of C2.

David Dolson