Hi Christian/Med, I checked out the -06 version submitted this morning, and it addresses all my comments. Thanks for taking care of this quickly.
Regards Suresh On 11/19/2013 05:47 AM, [email protected] wrote: > Hello Suresh, > > Thanks for your review. We will update the draft in light of your comments, > but please see inline a few responses. > > [snip] > > * Section 2.1 > > -> Not sure if the word encoded is appropriate here. > > s/hardware-encoded/usually implemented in hardware/ > [CJ] OK. > > -> These two sentences are hard to read and it is not clear what point > they are trying to make. Please consider rewording. > > As such, the current state-of-the-art tends to confirm the said > separation, which rather falls under a tautology. > [CJ] What is meant by this sentence is that data and control planes have > always been separated from an implementation standpoint, hence the tautology: > commercial routers use a (S/W-based) routing engine for route computation > purposes, while packet forwarding functions are usually H/W encoded. > > But a somewhat centralized, "controller-embedded", control plane for > the sake of optimized route computation before FIB population is > certainly another story. > [CJ] One of the main arguments of SDN proponents is that (1) the control > plane is separated from the data plane but, more importantly, (2) this > separation assumes a (logically) centralized control plane, which allows the > use of commodity H/W. From an implementation standpoint, this is different > from current router technologies, although there has been some vendors in the > past who tried to promote this kind of design (I remember Newbridge's Vivid > technology at the end of the '90s, for example). I'm not too sure about how > we can possibly re-word this, admittedly. > > * Section 3.1 > > Not sure what this sentence is trying to convey. Can you clarify? > > Some of these features have also been standardized (e.g., DNS-based > routing [RFC1383] that can be seen as an illustration of separated > control and forwarding planes or ForCES ([RFC5810][RFC5812])). > [CJ] What is meant here is that so-called SDN features have been there for > quite some time and some of them have been standardized, hence the couple of > examples above. > > * Section 3.4 > > This direct access to some engines using a vendor-specific could be > beneficial to performance but may increase configuration complexity (in > opposition to the final goal in Section 4.1 of accommodating heterogeneous > network technologies). It may be worthwhile to add some text to the following > paragraph in this regard. > [CJ] Fine by me, we'll add an extra sentence. > > Maintaining hard-coded performance optimization techniques is > encouraged. So is the use of interfaces that allow the direct > control of some engines (e.g., routing, forwarding) without requiring > any in-between adaptation layer (generic objects to vendor-specific > CLI commands for instance). > > * Section 3.5 > > This sentence is ambiguous > > OpenFlow is clearly not the "next big thing" > > Does this mean > > a) OpenFlow is certainly not the "next best thing" (or) > b) It is not clear if OpenFlow will be the "next best thing" > > Can you please clarify? > [CJ] option a is the right one. We'll reword accordingly. > > * Section 3.6 > > This sentence about non-goals is unclear. What are the "respective software > limitations"? > > o Fully flexible software implementations, because the claimed > flexibility will be limited by respective software and hardware > limitations, anyway. > CJ: The sentence means that there are S/W and H/W limitations respectively > that will always restrict the scope of claimed flexibility - another > tautology, if you will. > > * Section 4.5 > > This sentence is long and complex, and the exact point it is trying to make > is not clear. Can you simplify/reword? > > For example: while the deployment of a network solely composed of > OpenFlow switches within a data center environment is unlikely to > raise FIB scalability issues given the current state-of-the-art, data > center networking that relies upon complex, possibly IP-based, QoS- > inferred, interconnect design schemes meant to dynamically manage the > mobility of Virtual Machines between sites is certainly of another > scale. > > CJ: Fair enough. We'll simplify the wording, e.g., "DC networks that may rely > upon OpenFlow switches are unlikely to raise FIB scalability issues. > Conversely, DC interconnect designs that aim at dynamically managing VM > mobility possibly based upon the enforcement of specific QoS policies may > raise scalability issues." > > * Section 4.6 > > Can you clarify what risk is being assessed here? > > o Assessing whether SDN-labeled solutions are likely to obsolete > existing technologies because of hardware limitations. > > CJ: the risk is both technical and economical. From a technical standpoint, > the ability to dynamically provision resources as a function of the services > to be delivered may be incompatible with legacy routing systems because of > H/W limitations. From an economical standpoint, this is about assessing the > impact of deploying SND solutions for the sake of flexibility and automation > on CapEx and OpEx budgets. > > Editorial > ========= > > * Section 3.3 > > s/policiy/policy/ > > CJ: thanks. > > Cheers, > > Christian. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
