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. > > 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. > > 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. > > 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. Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
