Additional implications: o Node (IP) address changes at mobility. (It is not fixed, globally unique...)
o Intra-domain routing is done based on node addresses, not on PoA (interface) addresses o There's nothing like PoA (interface) address in the scenario. Gone. This is no problem, since the same information is with the sub-layer node address, e.g., MAC address. Regards, DY On Mon, Mar 29, 2010 at 5:35 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 IPv4 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. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
