Subject: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00

From: Dave Hood <[email-masked]>
Date: Mon, 12 May 2014 00:42:18 +0000

A few observations on the proposed requirements:

GR1.   SFC polices MUST be applicable at the edges - network elements as well as the workloads.

A good requirement specifies that 1) someone must do 2) something and 3) there should be a way to confirm whether 1 has done 2 or not. How would we test this requirement?

GR2.   SFC policies MUST be applicable to either Ingress or Egress traffic.

Ingress and egress are not well-defined. From the viewpoint of an SFC, the classifier is always an ingress point, and the conclusion of the service chain is always an egress point.

Bidirectional flows are important, but if this requirement is meant to introduce that topic, it is wide of the mark.

GR3.   SFC MUST support virtual as well as physical SNs.

This is written as if physical SNs were primary, with virtual an afterthought. While recognizing the differences, it is probably better to grant them logical equivalence. Or if one is to be regarded as primary, surely it would be the virtual SN?

GR4.   SFC SHOULD support the ability to mix virtual and physical SNs in the same SFC.
Ok

GR5.   SFC SNs MUST be deployable L2 or L3 hop away from each other or from the SFC starting entity.

Not clear what is actually being asked for here. The first sentence in DB-3 actually states the requirement more crisply.

GR6.   SFC traffic MUST be allowed to follow paths not constrained by the underlying static network topology.

We are always tied to underlying topology, just as a zero-G space environment is still subject to the laws of gravity. Even within a DC, and certainly between DCs, there will always be better ways and worse ways of physically arranging the virtual SNs (ie static network topology constraints).

The problem statement draft describes this better. A reqirement might better be written something along the lines that SFs [do we need SNs in the intended abstraction?] should be nodes in a virtual full-mesh topology, maybe accompanied with a requirement to be able to create new virtual topology nodes (ie instantiate new virtual SNs) on demand (see comment on GR11 below). Admittedly, this goes beyond the implications of the text describing fig 1, but still seems appropriate.

GR7.   SFC SNs MUST be able to derive the tenant identification without being tied to the underlying topology

SNs, rather than SFs? Derive, rather than being told? And the point about underlying topology seems to preclude the continued use of physical boxes with hard wiring that might already be in place.

GR8.   SFCs MUST support the ability to pass metadata among the SNs or between the SNs and the network elements.

It doesn't say so, but presumably the metadata is associated with a particular [set of] flows. As written, this could be done with information conveyed out of band, at the time of flow allocation or per-packet. Are all of these options intended to be left open for later resolution?

GR9.   A composite SFC SHOULD be achievable by way of joining sub SFCs, branching to sub SFCs where necessary.

Is branching the only option? Why not nesting?

GR10.  SFCs SHOULD NOT require SNAT inside the SFs to attract traffic back to them

This seems like a fine-grained requirement that addresses only one small aspect of a larger issue, namely visibility of bidirectional flows. Are we content to chip away at the problem without considering it in its entirety?

GR11.  SFCs SHOULD have the ability to choose SN instances dynamically, at the time of forwarding traffic to them.

The last phrase is at best redundant but probably incorrect (appears to demand just-in-time; why not *prior to* forwarding traffic?).
Also, although it is not justified by the use cases, one might hope for the ability to instantiate or destroy instances of at least some kinds of SN/SF on demand.

GR12.  An OAM mechanism to easily troublshoot as well as validate the paths traversed by the SFCs SHOULD be supported.

Given the expected intelligent controller, would we regard it as a sufficient response for the controller to be able to report its choices? Or would we expect some form of traceroute in the data path itself?

And speaking of intelligent controllers, BTW, the drawbacks clause 4 appears to be written with the intent to preclude the use of VLANs. As to scalability, VLANs might suffice for small to moderate enterprises. The argument is really based on the assumption of manual configuration. Given intelligence in the SFC controller, VLANs are one of many ways in which one could construct a valid solution. If we really intend to preclude VLANs, there needs to be a better argument than is presented.

Dave

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 11 May 2014 21:06:55 -0400

It strikes me that the solution to many of the issue Dave raises would 
be to remove the requirements from this document (as I have suggested in 
other documents).  Describe the use, but don't try to figure out to 
properly describe the requirements in the use case document.

Yours,
Joel

On 5/11/14, 8:42 PM, Dave Hood wrote:
> A good requirement specifies that 1) someone must do 2) something and 3)
> there should be a way to confirm whether 1 has done 2 or not. How would
> we test this requirement?
>
> Ingress and egress are not well-defined. From the viewpoint of an SFC,
> the classifier is always an ingress point, and the conclusion of the
> service chain is always an egress point.
>
> Bidirectional flows are important, but if this requirement is meant to
> introduce that topic, it is wide of the mark.
>
> This is written as if physical SNs were primary, with virtual an
> afterthought. While recognizing the differences, it is probably better
> to grant them logical equivalence. Or if one is to be regarded as
> primary, surely it would be the virtual SN?
>
> Not clear what is actually being asked for here. The first sentence in
> DB-3 actually states the requirement more crisply.
>
> We are always tied to underlying topology, just as a zero-G space
> environment is still subject to the laws of gravity. Even within a DC,
> and certainly between DCs, there will always be better ways and worse
> ways of physically arranging the virtual SNs (ie static network topology
> constraints).
>
> The problem statement draft describes this better. A reqirement might
> better be written something along the lines that SFs [do we need SNs in
> the intended abstraction?] should be nodes in a virtual full-mesh
> topology, maybe accompanied with a requirement to be able to create new
> virtual topology nodes (ie instantiate new virtual SNs) on demand (see
> comment on GR11 below). Admittedly, this goes beyond the implications of
> the text describing fig 1, but still seems appropriate.
>
> SNs, rather than SFs? Derive, rather than being told? And the point
> about underlying topology seems to preclude the continued use of
> physical boxes with hard wiring that might already be in place.
>
> GR8.   SFCs MUST support the ability to pass metadata among the SNs or
> between the SNs and the network elements.
>
> It doesn’t say so, but presumably the metadata is associated with a
> particular [set of] flows. As written, this could be done with
> information conveyed out of band, at the time of flow allocation or
> per-packet. Are all of these options intended to be left open for later
> resolution?
>
> This seems like a fine-grained requirement that addresses only one small
> aspect of a larger issue, namely visibility of bidirectional flows. Are
> we content to chip away at the problem without considering it in its
> entirety?
>
> GR11.  SFCs SHOULD have the ability to choose SN instances dynamically,
> at the time of forwarding traffic to them.
>
> The last phrase is at best redundant but probably incorrect (appears to
> demand just-in-time; why not **prior to** forwarding traffic?).
>
> Also, although it is not justified by the use cases, one might hope for
> the ability to instantiate or destroy instances of at least some kinds
> of SN/SF on demand.
>
> GR12.  An OAM mechanism to easily troublshoot as well as validate the
> paths traversed by the SFCs SHOULD be supported.
>
> Given the expected intelligent controller, would we regard it as a
> sufficient response for the controller to be able to report its choices?
> Or would we expect some form of traceroute in the data path itself?
>
> And speaking of intelligent controllers, BTW, the drawbacks clause 4
> appears to be written with the intent to preclude the use of VLANs. As
> to scalability, VLANs might suffice for small to moderate enterprises.
> The argument is really based on the assumption of manual configuration.
> Given intelligence in the SFC controller, VLANs are one of many ways in
> which one could construct a valid solution. If we really intend to
> preclude VLANs, there needs to be a better argument than is presented.
>
> Dave
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>