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

From: <[email-masked]>
Date: Fri, 29 Apr 2016 15:18:07 +0000

Re-,

Please see inline.

Cheers,
Med

De : Dave Dolson [mailto:[email-masked]]
Envoyé : vendredi 29 avril 2016 16:24
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: draft-ietf-sfc-control-plane -- C3 interface

[..]

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."

[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?

[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."
[Med] Thank you for the clarification. What would be the added value of providing that information (X complementary of Y) if we assume that two classification rules are installed to handle both directions?

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).
[DD] I disagree that C2 has anything to do with this. Instead, C1 must be used to provide consistent classification.
[Med] The example I have in mind is an a statefull NAT that is attached to a given SFF while the Classifier hasn't the visibility on the full forwarding path. The classifier in such case has no means to force that the same SF instance will be invoked for both direction. Wouldn't C2 be involved in such case?

[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."
[Med] What is specific in this case compared to configuring two classification rules; one for each direction? Is there something the classifier is supposed to do?

...

[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:
   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.

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?
[Med] "Supply" is intentional here as this covers both cases: (1) add a new information to a packer (e.g., a new TLV), (2) update the context of an existing TLV.

Regarding this paragraph, I think it would be cleaner if this behavior actually requires the C2 interface into the SF.

[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.
[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.
[Med] I re-confirm that the initial case we wanted to cover by this text is an SFF servicing a group of SFs that are embedded in a distinct physical node. This scenario suppose that once an SF is consumed it sends back the packet to the SFF that may undertake another hook to another SF in that node and so on. The packet is not handed from an SF to another one without soliciting the external SFF. That's sub-optimal, I agree. The text is currently silent whether the distinct locators are configured using the C2 interface (assuming that a distinct management interface is used between the control element and an SFC-aware SF).

---

From: Dave Dolson <[email-masked]>
Date: Fri, 29 Apr 2016 21:33:37 +0000

Med,
Please see inline [DD2]

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 29, 2016 11:18 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é : vendredi 29 avril 2016 16:24
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: 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."
[Med] Thank you for the clarification. What would be the added value of providing that information (X complementary of Y) if we assume that two classification rules are installed to handle both directions?
[DD2] Please see the new https://tools.ietf.org/html/draft-penno-sfc-packet-03, which discusses the need for symmetric path information.  Section 5.1 talks about using the control plane to provide this information. If this approach is taken, the C3 interface would provide the information.

NEW:
[DD2] OK, I see your point, but this is different than my concern, which is that if the SF needs to know about related forward/reverse paths, then the C3 interface has this responsibility.

[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."
[Med] What is specific in this case compared to configuring two classification rules; one for each direction? Is there something the classifier is supposed to do?
[DD2] I hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains why SFs need to know this.

...

OLD:

NEW:
[DD2] I think we agree on the purpose. But if it is configuration about how to modify packets, I think you should say so; otherwise one might think it is about supplying information out-of-band in the control-plane. Would you change "... it needs to supply for a given SFC." to "... it needs to attach to packets 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.
[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.
[Med] I re-confirm that the initial case we wanted to cover by this text is an SFF servicing a group of SFs that are embedded in a distinct physical node. This scenario suppose that once an SF is consumed it sends back the packet to the SFF that may undertake another hook to another SF in that node and so on. The packet is not handed from an SF to another one without soliciting the external SFF. That's sub-optimal, I agree. The text is currently silent whether the distinct locators are configured using the C2 interface (assuming that a distinct management interface is used between the control element and an SFC-aware SF).
[DD2] If you wish the text to be silent on which interface, then you should move it out of section "3.3.3 C3: Interface between SFC Control Plane & SFC-aware SFs".
[DD2] But again, I think you should avoid discussing how an SF can be configured to send traffic directly to another SF, which I don't think is architecturally correct. There needs to be a (co-located) SFF to connect them.