In einer eMail vom 21.10.2010 18:38:38 Westeuropäische Sommerzeit schreibt [email protected]:
Hi Heiner, > 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) This really seems like material for the problem statement, more than the design goals. This is true. But a such compressed repetition wouldn't be bad, particularly as the design goals should respond to these problems. Very easily this or that problem can slip out of focus ( e.g. the RIB size, e.g. the tighter meshing), accordingly this or that design goal. > > 3.2. Scalable support for traffic engineering > > 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. For multi-homing, there's already a separate section. I'm not understanding what changes you're recommending. 1.I can give you an example from my TARA-draft: If you fill the forwarding table t1 with the alternative next hop, temporarily, you will enable fastest alternate routing too. 2.Today I received draft-ietf-rtgwg-ipfrr-notvia-addresses-06.txt. If my BeyondSPF proposal were very poor, then this draft is poorest. Comparably my BeyondSPF-algorithms are lightyears ahead. My thinking is this: Why not apply them inter-domain ?!! > > 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 I'm still not seeing your point. Of course. Eliminating the scalability problem is one thing. Enabling better routing is equally important. > > 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 > 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 Well, as I've commented to a few others, the text here clearly doesn't communicate my intent, but it's the best that I can do at expressing the intent while remaining professional. I welcome alternate text. > > 3.8. Routing quality > 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” A couple of comments: - AFAIK, the reference is the first usage of the term 'stretch' in the literature (2006), and unless someone has an earlier reference, I'm inclined to attribute this to the authors. - Some people make their living on minimizing the bit*miles that their employers have to pay for. For them stretch 2 is fatal. Right. I am totally in favor of stretch 1. And to make that clear to any metric or geometry: The shortest path must be shortest (no diffuse metrics ! ) Heiner Tony
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
