Repeated typo: .... IPv4 ....
(Perhaps, I like IPv6... :-)) Regards, DY On Mon, Mar 29, 2010 at 5:27 PM, Dae Young KIM <[email protected]> wrote: > Typo: > > The number space of IPv6 is already huge enough > > should read > > .... IPv6 ..... > > Regards, > DY > > > > On Mon, Mar 29, 2010 at 5:25 PM, Dae Young KIM <[email protected]> wrote: >> Toni, >> >> This is one of the descriptions I'd like the most in this mailing >> list. Wonderful. >> >> Question: Is LINP based on the ideas you describe? Hope so. Otherwise... >> >> I might have the same views as yours, but the parts I like the most include: >> >> - Name the node, not the interface. >> >> - Do inter-domain routing by use of domain IDs. >> >> To go a little bit further, a picture I have would be: >> >> - Use FQDN as the name for your content/application/node... >> >> - Use IP address to name to nodes; Redefine the meaning of the IP >> address, it names the node, not the interface. >> >> - In the intra-domain routing, this nod (IP) address would be used >> just like now with OSPF. >> >> - Use domain IDs in inter-domain routing. >> >> In this way, >> >> - except redefinition of the meaning of IP address, >> >> - nearly nothing changes; >> >> o (Possibly extended) DNS can be used as before. >> o Existing hosts may not be changed, keeping their IPvX >> addresses, perhaps only one is enough >> o OSPF works just the same >> o Basic operations of BGP can be kept with new formatting >> based on domain IDs. If current ASN infra is not appropriate, then >> maybe design new numbering scheme for domains. >> o Multi-homing will be inherent, now that nodes are named, >> not the interface. >> o Mobility is just dynamic multi-homing, perhaps a bit too fast. >> >> - one important implication is: >> >> o Now that inter-domain routing is done by use of domain IDs, >> host IP addresses need not be globally unique. They can be local. We >> don't even need IPv6. The number space of IPv6 is already huge enough >> for any local domains. Of course, there might be additional benefits >> for using IPv6. They can choose to use IPv6, no problem. They are >> local anyway. >> >> I've been away from this ML for long, and do we have any proposals >> close to my idea or to your idea? I might like to support such a >> proposal. >> >> Regards, >> DY >> >> >> >> On Mon, Mar 29, 2010 at 4:46 PM, Toni Stoev <[email protected]> wrote: >>>> 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 >>> >> > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
