In einer eMail vom 20.10.2010 18:35:01 Westeuropäische Sommerzeit schreibt [email protected]:
Hi Heiner, Thank you very much for commenting. > 3.1. Improved routing scalability > It lacks naming the two aspects in the first place: memory consumption and CPU-performance (update churn). Only thereafter it makes sense to request independency from the internet user population. Why is the control plane mentioned specifically? I don’t understand. It is neither necessary nor correct. The control plane subsumes the memory, bandwidth and CPU required for routing, both within individual systems and network-wide. We distinguish from the data plane, which is the transit traffic. There are similar scalability issues in the data plane, but the argument there is much more challenging to make and is not widely accepted. Ok.I thought RIB=Control-, FIB=Data-plane and that using the term control-plane wouldn’t get us any further. Nevertheless the issues should be mentioned and specified: The current enormous size of the Internet ( number of DFZ-routers =x, number of RIB-entries = y, number of FIB-entries=z). The continuing growth wrt size and tighter meshing(FIB-growth-factor=350,000 / 310,000=1,13).The expiration of IPv4 addresses (number of unused addresses= n) > 3.2. Scalable support for traffic engineering > Bad English: The solutions should also be scalable also wrt detouring routes. ( and not wrt to traffic engineering). By detour routes, I'm assuming that you're talking about FRR and similar technologies. This would seem to be an independent issue and I don't think we have any agreement that this is an inter-domain issue. But for multihoming there is agreement. And multihoming is just a special case of alternate routing, i.e.FRR (if seen logically; I know according to IETF terminology these are completely different animals). My guess is: FRR is enabled intra-domain, hence there is a demand for it, intra-domain-wide. FRR is not enabled inter-domain, hence there is no demand for it, inter-domain wide. . > 3.3. Scalable support for multi-homing > It wouldn’t be bad to mention that multi-homing is just a particular aspect of multipath. Sorry, I'm not seeing your point. Does multi-path support affect our design goals? See above > 3.4. Scalable support for mobility > We should also mention support of PRIVACY (where is the roaming user at this moment). Privacy can always be supported (i.e. by any solution) by employing a home agent who will or who will not relay. We may need to deal with both options. The current text fosters the belief that some solution > may provide both concurrently. Agreed. Added a comment: "Mechanisms that help to provide more efficient and scalable mobility support are desired, especially when they can be coupled with security, _especially privacy_, and support topological changes at a high-rate." > 3.5. Simplified renumbering > The best of all is not mentioned: solutions which do not require any renumbering. Fair enough. Added. > 3.6. Decoupling location and identification > I have strong doubts that this community has fully understood what loc/id-split may mean. This doesn't seem like a document where we should be educating them. Agreed:-) > 3.7. First-class elements > Half of this paragraph is used to explain this weir headline. > What is really intended here, should be expressed simpler and without this climbim. Please propose text. I realize that my background is unique, but I know of no better way to accurately and concisely describe this in polite and professional language. Saying that "the architecture can't be a kludge" or "no cheesy hacks" doesn't seem to be appropriate. ;-) I did read 3.7 a few more times. I assume it is much more general i.e.not just about tunnels. Myself, I cannot even find another example for what may be meant. Also, if I were asked to come up with a first example, I would never have pointed to tunnels > 3.8. Routing quality > A lot of words in order to get to the term “stretch”. > I have my own suspicion why this term had been invented (and why it has been adopted). I can imagine that routing quality may also mean different aspects (QoS,…) If you would care to propose text, I would be happy to replace the current definition. This is taken from the academic literature, where they wanted a metric to evaluate routing quality. Personally, I don't consider it to be a very practical measure, as it ignores policy and the granularity is poor. A stretch of 2 is simply disastrous. I cannot propose text immediately because it needs more discussion up front. Quality routing may I cannot propose text immediately because it needs more discussion up front. Quality routing may address a) the applied algorithms, or b) the selection of first-class paths and links (QoS-paths/links). Ad a) (only) : It is up to the provisioned information and up to the algorithm itself how good or bad is the resulting routing technology. 1. Imho, it is NOT quality routing if the second best route is – eventually- completely out of scope. 2. My suspicion: “Stretch” was introduced by Dima while judging his own hyperbolic concept in comparison with the status quo. Shortest path means shortest path, and any longer path should be as short as possible and as long as necessary. Going from A to B via C, rather than directly from A to B, means stretch 2 (which wouldn’t be such disastrous:-).Thinking about concepts with some conceptually built-in stretch factor >1: (1)FEDERAL EXPRESS: All parcels are sent to Memphis,TE, then forwarded (2)PNNI with its logical group nodes’ topologies. We may say: The concept itself should not enforce longer routes. Comments? 3.We are far off from better routing which e.g. might enable state-less p2mp /mp2mp, or scoped broadcast.4.We are far off proper dealing with loops: crankback means loop. Eventually crankback provides the only available route ! Quality routing may mean “better routing” > 3.9. Routing security > No comment to this place holder phrase. Your sarcasm is not constructive. If you dislike the content, please propose alternate text. The text is ok. I should have written “sentence” instead of “phrase”. > 3.10. Deployability > The first sentence can be deleted (blabla only). > Any solution which required a flag day is out from the beginning. > Yes, incremental deployability is definitely required. > However, I think that ALL solutions can provide this (all the so far displayed as well as all not-yet born solutions:-) Clearly, this is not the case. It is very clear that one can propose a solution that there are non-deployable flag-day solutions. While they are not going to fall into anyone's definition of common sense, it is incumbent on us to be clear about the requirements anyway. In fact, in the past, this was a significant point of discussion. Agreed. > Furthermore I miss 3.11: > The solution should also enable Moore's Law as addressed in RFC4984 I'm sorry, I don't understand your point. As has been argued in 4984, Moore's Law is not the only constraint that we must work with. DRAM latency, for example, is NOT subject to Moore's Law. Care to propose text? Will think about some text. Regards, Tony Heiner
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
