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

From: <[email-masked]>
Date: Mon, 2 May 2016 06:35:25 +0000

Hi Dave,

Works for me. I fixed this one as you suggested.

Cheers,
Med

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

Med,
Please see inline [DD2]

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

---

From: <[email-masked]>
Date: Mon, 2 May 2016 06:58:34 +0000

Re-,

The text we are discussing is NOT about sending traffic between SFs, but from an SFF to a SF. It assumes 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 directly from an SF to another SF without soliciting the external SFF.

What about making this change to make it clear?

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

NEW:
   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 from the SFF to the appropriate SF must be supported.  Concretely, each SF
           ^^^^^^^^^^^^
   must have a unique locator for unambiguous forwarding. This locator may be
                                                          ^^^^^^^^^^^^^^^^^^^
   configured using this interface.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Cheers,
Med

Med,
Please see inline [DD2]

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

---

From: <[email-masked]>
Date: Mon, 2 May 2016 09:04:38 +0000

Re-,

Ok, I understand better your case. Please find below a text proposal:

NEW:

   The controller may use the C3 interface to specify how the reverse
   path of flows, that are processed for a given direction, is selected
   by the SF.  This feature is useful, for example, for packets
   generated by an SFC-aware SF to ensure these packets are forwarded to
   the corresponding source node with the same set of SFs, involved in
   the forward path, are invoked in the reverse order when forwarding
   back these packets.  Special care should be considered to avoid that
   instructions provided to distinct SFs lead to loops.

Does it solve your concern?

I don't know whether there should be a default behavior when no instruction is provided to the SF (e.g., assume that the same SFF should be used for both directions?).

Cheers,
Med

Med,
Please see inline [DD2]

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

[..]

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

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

---

From: Dave Dolson <[email-masked]>
Date: Mon, 2 May 2016 10:53:06 +0000

Ah, now I get it. Thanks.

From: [email-masked]
Sent: Monday, May 2, 2016 2:58 AM
To: Dave Dolson
Cc: [email-masked]
Subject: RE: draft-ietf-sfc-control-plane -- C3 interface

Re-,

OLD:

NEW:

Cheers,
Med

Med,
Please see inline [DD2]

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

---

From: Dave Dolson <[email-masked]>
Date: Mon, 2 May 2016 10:58:39 +0000

That works, thanks.

From: [email-masked]
Sent: Monday, May 2, 2016 5:04 AM
To: Dave Dolson
Cc: [email-masked]
Subject: RE: draft-ietf-sfc-control-plane -- C3 interface

Re-,

NEW:

I don’t know whether there should be a default behavior when no instruction is provided to the SF (e.g., assume that the same SFF should be used for both directions?).

Cheers,
Med

Med,
Please see inline [DD2]

[..]

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?
[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:
[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?
[DD2] I hope https://tools.ietf.org/html/draft-penno-sfc-packet-03 explains why SFs need to know this.