Further reply Part 2 On Thursday 24 June 2010 at 16:17:10 Robin Whittle sent: > >> Does your concrete proposal involve new application protocols, > >> or can existing protocols work with IP addresses, with the stack > >> somehow implementing whatever is required so the application can > >> assume that an IP address is both an Identifier and Locator? > > > > For this separate uses of IDs and locators new application > > protocols or amendments of exiting ones are needed. > > OK - so applications need to be rewritten and do more work. I think > there's no way anyone would be interested in adopting such a system, > since - as with other CEE architectures - the benefits for each > adoptor and for routing scalability only occur after almost everyone > has adopted it.
This is a long term proposal. Whoever thinks globally and with a time perspective might consider adopting it. > Requiring changes to host stacks is a real barrier to adoption. > Requiring applications to be rewritten is far worse. See: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ I am striving to offer the best solution I know of. With or without change requirements. For the sake of better networking. > > >> This involves ensuring that a packet is never received by a host > >> which does not have the Identity implied by the application's > >> destination IP address. > > > > Yes, an important feature. Destination identifier. > > It can only be achieved, as far as I know, by B doing a secure lookup > of A's Identifier to get A's Locator - and then sending the packet to > that Locator. Much like DNS to IP address resolution. > (Or some alternative by which number servers send the > first packet and reliably and securely inform B what A's Locator is.) Yes, inicast is collectively reliable and collectively secure method. > > >> Does your proposal provide a facility similar to today's anycast > >> and to round-robin DNS, where one DNS name resolves to multiple > >> IP addresses, meaning multiple hosts or sets of anycast hosts? > > > > Anycasting is a matter of naming and recognition of service types. > > It is not about naming nodes or their location. Service type > > naming is a different aspect of the architecture. > > I am not sure what you mean by this, but it does not seem to accord > with my understanding of anycast being multiple hosts in multiple > locations all around the Net, with the same IP address. Then, the > interdomain routing system (without any extra elaboration for this > purpose) causes the packet to be sent to the "closest" such host. > ("Closest" with BGP is not necessarily physically or topologically > close.) But why are anycast hosts/nodes interchangeable? Because they perform same type of service. And that is what their IP address represents. > > > A node identifier may resolve to multiple locators, which would be > > used in a round-robin fashion or with some preference. But those > > locators would be each of the same node. > > At present a FQDN can resolve to multiple IP addresses, each of which > combines the functions of Identifier and Locator for the particular > host in the round-robin group. Then the session begins and continues > with one of these hosts, and is maintained with this IP address. > > With your proposal, an Identifier can have multiple locators, each > for a different node. Nope. An identifier may resolve to multiple locators of the same node. > But this seems to violate the concept of an > Identifier being specific to each physical node. Then, your > applications need to keep track of specific Identifier-Locator pairs, > since each pair with a different Locator refers to a different node - > and for session continuation, the session always needs to be with the > node specified by this pair. > > You could do FQDN round-robin to Identifier, and then for each > Identifier, have a single node, with one or more Locators. That > would work fine, I think. You're right. That's what it is by design. > > >> How would your proposal handle multihoming and mobility? > > > > Every "home" of a node may supply it with a locator. Locators may > > come and go. Sessions are maintained with identifiers. > > Yes, but you have to organise a secure and efficient way to tell a > distant node B that A has now got a new Locator. A says this with a packet with the new locator. B can verify by doing inicast. And the effecient way is that A and B keep session identifiers, which may be secret to others. > > >> Is there any RRG proposed architecture which matches or > >> resembles your plan? > > > > Matching – no. Resembling – I guess no. Others are welcome to > > match. > > Your proposal seems to be a host-based system along the lines of the > Core Edge Elimination architectures (the architectures which really > do implement Locator/Identifier Separation): > > GLI-Split > ILNP - Identifier-Locator Network Protocol > Name-Based Sockets > RANGI > > > >> Also, how would your analysis of the goals and proposed > >> architectures differ from mine?: > >> > >> http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html > > > > I have not read all the writings there. Maybe in the course of > > this discussion I could answer. Or you could help me do so. > > Other than Tony and Lixia's: > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation > > my msg06219 is the only attempt anyone has made for writing what they > would like to see as an RRG Recommendation. Unlike Tony and Lixia's > document, my attempt covers mobility and includes a proper > description of goals and critiques of all proposals (or at least > descriptions of why they can't be considered proper proposals). Brave. > I understand that your plan would make life easy for the routing > system, compared to the additional mechanisms needed for LISP, Ivip > or IRON. Well, inicast resolution through ID servers does add a layer into the routing of system. But I appreciate your assessment. > However, it is not clear to me why you want to place the extra > workload on nodes (AKA each communicating host), with the delays > required at each node which is part of a two-way communication, and > the need for complex security arrangements so each node can learn of > a new Locator for the other node ASAP. End-to-end. > It is not clear how you handle mobility, since that would require all > communicating nodes of a mobile node to instantly know its new > Locator, the moment it acquires a Locator in a new network. Not instantly, but with the next step of communication. And having a session cookie eases things a lot. > This can > happen in a split second, when one radio network goes down and > another is chosen - or even on the same radio network when the node > communicates with a new radio tower (even if the node hasn't moved - > the network can make this happen) which uses a different base-station > controller which uses a different IP gateway. For instance, I > understand that in Beijing, in one 3G network, there are multiple IP > gateways in the whole city. Your node can discover its new Locator > quickly, but how can it securely communicate this to all its > correspondent nodes in time not to lose any packets from them? If > there are 50 correspondent nodes, then that is 50 secure messages > which need to be sent out and acknowledged. That is a lot of work > for a 3G handset, and it would chew up expensive radio bandwidth. > Also, what if both nodes in a communication get new Locators at the > same time? There's no way either can know the new locator of the > other, since it can't receive the update message, which would be sent > to its old Locator. Re-initate the session. Just like with IP addresses. > These last two paragraphs are critiques which apply to the other CEE > architectures too. > > > If you write up your proposal in sufficient detail and read the other > CEE architectures, I think you may find some points of commonality. Agree. > Whatever it is you are proposing, it is a Loc/ID Separation (CEE) > architecture - and I oppose such architectures for the reasons > mentioned in my msg06219 and in my recent message: > > http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html > > - Robin > > The approach of having an address represent other things, than location, causes a great deal of trouble in the routing sytem. Toni _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
