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

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 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
>
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>