3.1.Improved routing scalability Itlacks naming the two aspects in the first place: memory consumption andCPU-performance (update churn). Only thereafter it makes sense to requestindependency from the internet user population. Why is the control planementioned specifically? I don’t understand. It is neither necessary norcorrect. 3.2.Scalable support for traffic engineering BadEnglish: The solutions should also be scalable also wrt detouring routes. ( andnot wrt to traffic engineering). 3.3.Scalable support for multi-homing Itwouldn’t be bad to mention that multi-homing is just a particular aspect ofmultipath. 3.4.Scalable support for mobility Weshould also mention support of PRIVACY (where is the roaming user at thismoment). Privacy can always be supported (i.e. by any solution) by employing ahome agent who will or who will not relay. We may need to deal with bothoptions. The current text fosters the belief that some solution mayprovide both concurrently. 3.5.Simplified renumbering Thebest of all is not mentioned: solutions which do not require any renumbering. 3.6.Decoupling location and identification Ihave strong doubts that this community has fully understood what loc/id-splitmay mean. 3.7.First-class elements Halfof this paragraph is used to explain this weir headline. Whatis really intended here, should be expressed simpler and without this climbim. 3.8.Routing quality A lot of words in order to get to the term“stretch”. Ihave my own suspicion why this term had been invented (and why it has beenadopted). I can imagine that routing quality may also mean different aspects(QoS,…) 3.9.Routing security Nocomment to this place holder phrase. 3.10. Deployability The first sentence can be deleted (blabla only). Any solution which required a flag day is out from thebeginning. 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:-)
Furthermore I miss 3.11: The solution should also enable Moore's Law as addressed in RFC4984 Heiner -----Ursprüngliche Mitteilung----- Von: Tony Li <[email protected]> An: [email protected] Verschickt: Di., 19. Okt. 2010, 18:24 Thema: [rrg] Last call: Design goals Hi all, I'd like to issue a last call for the design goals document: http://tools.ietf.org/html/draft-irtf-rrg-design-goals-02 As I'm expecting some discussion, I'd like to make this a bit longer than usual. Therefore, the last call will close in two weeks. Thanks, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
