Subject: Re: [rrg] Locators

From: [email-masked]
Date: Tue, 25 Aug 2009 03:21:55 EDT

Toni,
I think locator means something very specific inside a specific protocol  
(which is LISP). It is not used in other architectures like OSPF, BGP. My  
general understanding of a network is that it consists of nodes and links 
which  have identifiers and attributes. A nodal attribute may be its 
reachability info  but as well some geo-location information which can both be used for 
 determining the next hop (as is done by OSPF,BGP resp. would be done by 
TARA).  So there is no stringent need for a locator, its only model-specific.
I write this to leash myself, because in a first second I intended to write 
 about "mobile locators".
 
Well, on the LISP-mailinglist the issue "mobile node" was raised (and then  
forgotten) which I think is a very important aspect: You may treat it like 
an  exotic service, but you may also treat it as if every single node is 
potentially  mobile. However then there is no doubt: you have to have a stable 
anchor for  mastering the relative distances which can only be the grid of  
the geographical coordinates. 
 
But those are just imaginary locators (no one has ever stumbled over these  
longitude and/or latitude ropes:-) and don't need to be sent messages from  
and to- neither with nor without checksum.
Heiner

In einer eMail vom 24.08.2009 07:37:48 Westeuropäische Normalzeit schreibt  
[email-masked]:

Noel,  Scott, Heiner, thank you for engaging.

Scott Brim wrote:
> Your  local router doesn't have to solve this problem.  It's
>  end-to-end,

So should an end be engaged with remote end's local link  interfaces, like 
sending packets with destination an interface locator, and  why?

> and each of those flows may have a different solution.  
> Some like the weather map may be solved in the application.  

If a problem is left intact in the routing, multiple working groups  are 
needed to solve its effects.

> You might 
> find this  interesting:
> 
>  http://www.ietf.org/mail-archive/web/multipathtcp/current/maillist.html
>  
> (for multipath SCTP see the TSVarea list)

Toni Stoev  wrote:
> "Why should it be simple when it can be complex?" --  Folklore
> 
> You are reading your email off your portable  computer and you have a 
constantly updated weather map on your desktop. You  may be chatting through an 
instant messaging service and may be listening to  live-streamed audio, and 
may start talking on the computer videophone.
>  You move to a different room, so you unplug your network cable, and you 
know a  wireless link will keep those communications running.

That is the easy  case. What if you are in a public place and get public 
globally routable  locators, should the locators be bound to interfaces and 
should the remote  servers take care therefor of your local connectivity?

> Your local  router has to realize the situation and stop transmitting 
communications  packets to the cable interface and start transmitting them to 
the computer's  wireless interface, and any broken sessions have to be 
re-established with  remote servers.
> You are the same person using the same network  services on your same 
computer through your same router, but you experience  service slowdown or even 
need to reinitiate some of the communications.  Why?
> (Re)searcher Toni

The  same
_______________________________________________
rrg mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 25 Aug 2009 14:56:51 +0300

Hi Heiner,

you might find Portland and VL2 research studies interesting though
these are not related to Internet scalability - instead trying to
create better scalability for very large L2 networks. It seems that
both proposals are influenced by locator/identifier studies - one is
network centric and the other is host centric.

http://cseweb.ucsd.edu/~vahdat/papers/portland-sigcomm09.pdf
http://research.microsoft.com/apps/pubs/default.aspx?id=80693

-- patte

On Tue, Aug 25, 2009 at 10:21 AM, <[email-masked]> wrote:
> reachability info but as well some geo-location information which can both
> be used for determining the next hop (as is done by OSPF,BGP resp. would be
> done by TARA). So there is no stringent need for a locator, its only
> model-specific.
> potentially mobile. However then there is no doubt: you have to have a
> stable anchor for mastering the relative distances which can only be the
> grid of the geographical coordinates.
>
>> constantly updated weather map on your desktop. You may be chatting through
>> an instant messaging service and may be listening to live-streamed audio,
>> and may start talking on the computer videophone.
>> computer through your same router, but you experience service slowdown or
>> even need to reinitiate some of the communications. Why?
>>
>> (Re)searcher Toni
>
> The same

---

From: Ran Atkinson <[email-masked]>
Date: Tue, 25 Aug 2009 09:03:33 -0400

Hi,

Folks interested in the matter of Locators really ought to
read IEN-1.  Most of the current multi-homing and mobility
issues were known way back then, and are discussed in IEN-1.

For those unfamiliar, IENs are a document series parallel
to RFCs that were used during the design of the IPv4 Internet.
Early IENs were separate from the RFC series, while most
later IENs were also published as RFCs at the same time.

Cheers,

Ran

For the benefit of folks without web search, here is a URL:
	<http://www.postel.org/ien/pdf/ien001.pdf>