Subject: Re: [rrg] Toni Stoev's proposal for Loc/ID separation

From: Toni Stoev <[email-masked]>
Date: Sat, 3 Jul 2010 09:54:47 +0300

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 8 Jul 2010 12:24:18 -0400

Hi;

Did you ever send to the list a summary of the results of your various  
straw polls ? If not,
I think you should, both for our benefit, and to get it on the record.

Regards
Marshall

On Jun 10, 2010, at 5:18 PM, RJ Atkinson wrote:

> Hi,
>
> Here is a terminology straw poll for the Routing RG.
> As usual, I'm running this using Doodle.  The poll
> lasts 1 week from the date/time of this email note.
>
> Here is the poll URL:
> 	<http://www.doodle.com/dqfyfaigxuggs922>
>
>
> My thanks to Noel Chiappa, Dino Farinacci, & Joel Halpern
> (in alphabetical order) for providing corrections
> to earlier draft versions of these definitions.
>
>
>
> A few quick notes:
> -------------------
> - As before, I can't edit the statements during the poll,
>  because it obfuscates the meaning of votes that occurred
>  before the edit occurred.
> - The "A" terms are pretty widely used today.
> - The B through E terms are not uncommon today,
>  but are a bit newer than ancient terms like
>  "bridge" or "router".
>
>
>
> A1) A "node" is either a host or a router.
>
> A2) A "router" is any device that forwards packets at the
>  Network Layer (e.g. IPv4, IPv6) of the Internet Architecture.
>
> A3) A "host" is a device that can send/receive packets
>  to/from the network, but does not forward packets.
>
> A4) A "bridge" is a device that forwards packets at the
>  Link Layer (e.g. Ethernet) of the Internet Architecture.
>  An Ethernet switch or Ethernet hub are examples of bridges.
>
>
> B) An "Address" is an object that combines aspects of identity
>  with topological location.  IPv4 and IPv6 addresses are
>  current examples.
>
>
> C) A "Locator" is a structured topology-dependent name that
>  is not used for node identification, and is not a path.
>  Two related meanings are current, depending on the class
>  of things being named:
> 	1) The topology-dependent name of a node's interface.
> 	2) The topology-dependent name of a single subnetwork
> 	   OR topology-dependent name of a group of related
> 	   subnetworks that share a single aggregate.   An
> 	   IP routing prefix is a current example of this last.
>
>
> D) An "Identifier" is a topology-independent name for a logical
>  node. Depending upon instantiation, a "logical node" might be
>  a single physical device, a cluster of devices acting as a
>  single node, or a single virtual partition of a single physical
>  device.  An OSI End System Identifier (ESID) is an example of
>  an identifier.  A Fully-Qualified Domain Name that precisely
>  names one logical node is another example. (Note well that not
>  all FQDNs meet this definition.)
>
>
> E) Various other names (i.e. other than addresses, locators,
>  or identifiers), each of which has the sole purpose of
>  identifying a component of a logical system or physical device,
>  might exist at various protocol layers in the Internet Architecture.
>
>
> EOF
>
>
>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Tony Li <[email-masked]>
Date: Thu, 8 Jul 2010 12:02:03 -0700

On Jul 8, 2010, at 9:24 AM, Marshall Eubanks wrote:

> Hi;
> 
> Did you ever send to the list a summary of the results of your various straw polls ? If not,

Hi Marshall,

Please see: http://www.ietf.org/mail-archive/web/rrg/current/msg06994.html

Tony