> Please write something along these lines - I think it would be a good > contribution to the RRG and would stimulate further constructive > discussions. > > - Robin
I came to this group with a clear vision on network architecture. What I liked here were the well defined design goals. I agree more input is relevant. Things that I envision: [Slow down for reading.] Naming node, not interface, with locator, identifier. Strict topology following by locator, that is, every next hop towards a node within a routing domain to be inscribed. Next hop inscriptions – neighbor identifiers. This implies variable locator size. Intra-domain routing then becoming piece of cake: locator longest prefix match. This implies a starting node in every routing domain. Binding of routing domain identifier with locator. In a role-based architecture: locator role implies routing domain ID role (roles realized as header options). Then, inter-domain routing based not on intra-domain locator( prefixe)s, but on domain identifiers only. Routing domain IDs then forming paths (No reinventing the wheel.). Node identification system: bidirectional numerical DNS-like system. Bidirectional means a node identified knows locator of its parent and the parent knows locator of its child. These acquaintance IDs forming fully qualified node number sequence – the node identifier. I enjoy this part, quoting other people: Node mobility is dynamic multihoming. Having node identification system, a node roams with locators coming and going, and is discoverable through its identifier. Cheer everyone On 29.03.2010 at 03:09:50 Robin Whittle sent: > Short version: Tony Stoev wrote, in part: > > > If you want to tell the world what to do with the > > IP routing system, act now. > > I agree - and suggest he and other people write some > Recommendation text they would most like everyone to > agree with. > > > > Hi Tony, > > You wrote: > > > I hope this is the end of personal feud here. > > I think RRG participants are unlikely to be happy with a > Recommendation which was made by the co-chairs alone, without any > attempt at seeking consensus - especially if the final document > represents the Recommendation as arising from the group itself. > Their intention to write the Recommendation themselves only emerged > when I asked them to clarify their plans on 7th March. > > Also, some people - me at least - think that the co-chairs could have > done a much better job of supporting discussions in the last three > years. Discussion of "proposals" was generally banned or discouraged > - but they did not do much to suggest why this was being done or to > lead whatever kind of "architectural" discussion they wanted. Except > for two very early drafts, (draft-irtf-rrg-design-goals-01) they did > not seriously pursue the creation of a "list of prioritized design > goals" as required by the Charter. > > Furthermore, as I wrote a few days ago (msg06373) the co-chairs seem > to seriously misunderstand Ivip and at least some of the other > proposals. > > Still, even if there is no Recommendation - or no Recommendation > which arises from the participants - I think some important work has > been done, with several proposals being designed, refined and > documented in a manner which is of lasting value. > > > > This working group has a charter to produce recommendation. > > If you want to tell the world what to do with the IP routing system, act > > now. > > I agree. I did so with the Ivip proposal, by critiquing all the > other proposals, and by writing some text of what I consider to be an > ideal Recommendation: > > http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html > > The only think I would change about that is my assessment of > IRON-RANGER, which has been significantly redesigned in the last > week. I think it is an interesting CES architecture which probably > could be made to scale well. > > You have been participating in the mailing list for nearly a year, > but looking through some of your messages, I don't have a clear idea > of what you think should be done to solve the routing scaling problem. > > I suggest you and others write to the list with your own preferred > text for what you suggest would be a good Recommendation. > > Since there is no agreed set of goals, I suggest that you begin with > your goals and non-goals and your arguments for these. For instance, > are you keen for an architectural upgrade to include new support for > Mobility? Mobility is part of the problem the RRG is supposed to be > tackling - but it has received little attention, since most work has > been focused on portability, multihoming and TE for non-mobile networks. > > Then I suggest you refer to each of the proposals, giving reasons why > you favour them or not. Perhaps you wholly support one of them, or > have qualified support for several of them. Perhaps you support an > alternative architecture which is different from those in the proposals. > > I don't think it is good enough to simply discuss a preferred > architecture. I think that for any Recommendation (from an > individual or from the RRG as a group) to have credibility, it must > provide detailed reasons for rejecting all the other proposals. > Without this - and without those arguments being clear and based on a > good understanding of all the proposals - a Recommendation for any > one architecture would be incomplete and would not contribute to > constructive discussion. > > > Please write something along these lines - I think it would be a good > contribution to the RRG and would stimulate further constructive > discussions. > > - Robin > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
