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

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Wed, 25 Jun 2014 01:36:59 +0000

Thanks for the detailed comments! . Responses/comments inline.

Surendra.

From: Dave Hood <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 11, 2014 5:42 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] Gen rqts comments on draft-ietf-sfc-dc-use-cases-00

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?
SK> If you have suggested text for this, we will review and update.

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.

SK> This is an extension of GR1. We could include network element and workload to make the context of ingress/egress specific.

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?
SK> Our intent is to give them logical equivalence while capturing the challenges with virtual SNs and the virtual environment, for SFC to address, in order to not diminish all that flexibility and dyanamism.

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.
SK> Basically, there should not be any assumption about the SNs being L3 hop away to the SFC infra – classifier, service function forwarder (borrowing terms from the arch draft) etc.

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.
SK> This is not suggesting how the topology should be or whether there should be dynamic instantiation of SNs, which are left to the implementations and solutions. The key here is that SFCs be constructible on an overlay while still allowing underlay legacy methods to exist.

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.
SK> I agree, 'derive' as used may be misleading. We will update it.
No, it does not preclude physical boxes. Physical boxes could use overlay or underlay and still base tenant identification on the topology. With overlays and the ability to carry metadata, tenant identification can be passed to the SN.

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?
SK> Good point about in band vs. out of band. This is specifically on the in band communication. Implementations can choose how to use such a mechanism but having such a mechanism enables many use cases.

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?
SK> Branching seems to address the use cases in a simple fashion. If there are nested use cases that cannot be addressed, it would good to bring them up in this forum and update the draft as needed.

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?
SK> By virtue of the overlay and steering, this falls right in the SFC architecture domain. Open to hearing the broader view point.

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.
SK> Will update to use "prior to". Yes, implementations may grow/shrink the SN pool.

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?
SK> Traceroute in the data path is beneficial, as it traverses the same path as a packet would, in exposing SFC path issues.

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.
SK> Please not that VLAN stitching is not precluded. With proxy's in SFC, VLAN stitching is still valuable to support the legacy SNs. With overlay based method and metadata passing, there is obvious value to be had in SFC.

Dave