Thank you Suresh for the review! And thank you Christian for the quick response & update. I have balloted a no-obj position for this draft on today's IESG telechat.
Jari On Nov 20, 2013, at 11:47 AM, Suresh Krishnan <suresh.krish...@ericsson.com> wrote: > 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, christian.jacque...@orange.com 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 > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
