Subject: Re: [RAM] Incremental Deployment of LISP

From: Eliot Lear <[email-masked]>
Date: Sun, 01 Apr 2007 18:54:46 +0200

Hi Dave,

>> Lookups are a non-starter because of the lookup latency and what you 
>> do with a packet on a cache miss
>
> I wonder if the folks who argued against moving from HOSTS.TXT to the 
> DNS used the same rationale... :-)

Remember, with LISP we're talking about ROUTERS switching PACKETs and 
not END HOSTS establishing a communication (be it UDP, TCP, SCTP, or 
whatever).  Again, at the end host level you're correct, and this is 
precisely what HIP does.  If that's what you want, then you're half way 
home because the HIP people have running code and a head start on a 
bunch of problems in that space.
>
> More seriously, the vast majority of people and processes already have 
> to deal with lookup latency on the initiation of an Internet 
> transaction since IP addresses aren't generally used by people or 
> applications.
>
> As for what to do with cache misses, you do the same thing you do with 
> any datagram-based system: you buffer and when you can't buffer you 
> drop based on some algorithm and assume the packet will be 
> retransmitted.  If you have the mapping service at the edge, you don't 
> need to use static RAM, but instead can use cheap commodity DRAM and 
> have a really big cache.

Whether you use SRAM, DRAM, SDRAM, or good old core memory is not my 
concern.  My concern is latency in establishing a connection when 
everything is in a nominal state, particularly due to an off-the-box lookup.

>> We want something that is akin to the RADB (perhaps a big table that 
>> can be diffed periodically), but to be sure is administered easily by 
>> end systems.
>
> I don't think this is what we want.  I could see an argument for a 
> dynamic table of identifier to locator mappings similar to the routing 
> table being propagated by flooding.  I could even see an argument for 
> something done along the lines of P2P file sharing apps like 
> BitTorrent.  I could (of course) see a pull based mechanism that has 
> characteristics similar to the DNS.  But something like the 
> centralized, largely static RADB?  The security model is wrong.  
> People forget to update it.  Who would run/maintain it?  Etc.

If you are going to do an ID/Locator split at all you had better have 
answers to this basic question: how do you establish authority for the 
mapping?  Yes, you can do it with DNS, but that will produce 
unacceptable latency.  I won't accept that a DHT will solve this problem 
until I see a DHT that solves this problem without the "and magic 
happens here" part.  The reason people didn't update the RADB was simply 
because it didn't matter and there was no programmatic operational tie 
to anything going on with the routing system.

And yes, you do want to worry about security, so the authority had 
better sign the updates prior to distribution.  Then distribution itself 
becomes less of a concern.

Eliot

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Eliot Lear <[email-masked]>
Date: Sun, 01 Apr 2007 18:58:00 +0200

Ross Callon wrote:
> I am worried about a full PUSH due to the potential size of the
> mapping table (see the email that I just sent). If you can deploy
> LISP very close to the host then I agree that this particular
> problem goes away.

While I think that's a reasonable fear, I believe there are solutions to 
this through incremental updates, etc.  If it turns out that the cost of 
having a redundant connection is that you need a beefier router, I can 
live with that because it places the cost of multihoming on the parties 
who are enjoying the benefits, which is a substantial change from today.

Eliot

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 02 Apr 2007 11:39:19 +0900

Eliot Lear <[email-masked]> writes:
> precisely what HIP does.  If that's what you want, then you're half
> way home because the HIP people have running code and a head start on
> a bunch of problems in that space.

Indeed. In end host solutions, something very like HIP seems to be the way
to go. However, cost-benefit analysis of that remains to be seen.

> unacceptable latency.  I won't accept that a DHT will solve this
> problem until I see a DHT that solves this problem without the "and
> magic happens here" part.  The reason people didn't update the RADB
> was simply because it didn't matter and there was no programmatic
> operational tie to anything going on with the routing system.
>
> better sign the updates prior to distribution.  Then distribution
> itself becomes less of a concern.

I don't think anyone _has_ working push model that scales. DNS is pull; DHT
is pull; BGP is push (but doesn't scale too well).

Authenticating 'push' traffic even for current prefix updates is a hard
problem [1]; doing that for 'push' of whole identifier space (or just those few
millions of PI-ish multihomed prefixes people envision in future) sounds
quite hard. (Think few crypto ops per prefix, if you want to be really
paranoid, and at router bootup needing to go through the whole prefix space
- no thanks :-> And if you delay it, you open yourself up for all sorts of
funny resource exhaustion attacks..)

I've been thinking on this topic quite a lot, and only conclusions I've
reached is that you can either get

- one-level lookup hierarchy (say, global DHT), or
- security, or
- push model.

And not easily more than one of those. DNS for example is multilevel pull
hierarchy with some security in it (DNSSec); most DHTs are pull models
without security. BGP has global hierarchy and push model but it doesn't
scale.

For what it's worth, I think that some sort of multilevel model with decent
security is the thing to go for, with the most global levels being possibly
push model, the rest obviously pull as you don't want to push end host
state (or even possibly customer PI address state) onward.

Cheers,

-Markus

[1] Meaning, authenticating for example cryptographically signed per-prefix
updates, not the raw data traffic itself. TCP-MD5, or IPsec works perfectly
well for traffic but gives no guarantee of the original origin of the
update.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 07:43:01 +0200

> is pull; BGP is push (but doesn't scale too well).

DNS demonstrates that the difference between push and pull isn't so far 
as one might think.  Consider the case when a primary server for a zone 
sends out a notify for a zone.  Is that push or pull?  I'm not worried 
about push or pull.  I believe we can crack this nut, if the rest of 
LISP works out well.

> problem [1];

I really can't stress this enough that has to be a different problem, or 
the game is really over.  For one, you do not need to sign each prefix 
separately.  An authority needs to sign an update which may contain many 
mappings.  Second, the number of updates required in a period of time 
has to be considerably smaller - BY SEVERAL ORDERS OF MAGNITUDE - or we 
would have failed in our primary engineering objective of better scaling 
the routing system.

So, start by thinking about updates no more than once an hour and work 
that are signed by an authority.  In such a circumstance you can even 
use a combination of push and pull, where SPs pull and then push to 
their customers, or customers themselves pull from SPs who are pushed 
updates.  Either will scale, and most of the technology exists for both.

> state (or even possibly customer PI address state) onward.

That is one perfectly feasible possibility.

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 1 Apr 2007 23:24:10 -0700

> I think this heavily depends on what scenario you are considering
>
> in LISP 1 doesn't matter, since both identifiers and locators are  
> routable
> So, if you do have an alternative locator for the identifier, then  
> tunnel, else, forward directly
>
> similar in LISP 1.5
>
> In LISP 2 and 3 the issue you are considering needs to be  
> considered imho
>
> probably it will induce additional latency, since you probably want  
> to check if the dest address is an identifier.
>
> in LISP 3 it depends wheter you are using the push or pull model
>
> if you have all the identifier to locator database available, then  
> you can check on it to verify if the destination is a identifier  
> and which are the locators
>
> if you don't have it, well, then you need to make a query and find  
> out, which will take additional delay

You are right non Marcelo. I think taking the high-road by doing a  
LISP-push model gives you the best of all worlds. We still can  
incrementally deploy tunneling and by augmenting LISP-CAs and LISP- 
peering routers we can get EID-to-RLOC integrity, DOS-protection, and  
non-routable IDs.

Mark Handley and I are working on a proposal. Give us some time to  
get it written down.

Dino

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 02 Apr 2007 15:29:54 +0900

Eliot Lear <[email-masked]> writes:
> DNS demonstrates that the difference between push and pull isn't so
> far as one might think.  Consider the case when a primary server for a
> zone sends out a notify for a zone.  Is that push or pull?  I'm not
> worried about push or pull.  I believe we can crack this nut, if the
> rest of LISP works out well.

What is the rest of LISP? A method for tunnelling packets? I think the
wheel's fairly round already on that front. 

For me, on LISP front, the worrying part is that the early parts seem
mostly useless (yay, we have _extra_ state all over, but no concrete gain,
as global routing state just bloats more), and the hypothetical later parts
(which haven't been specified too exactly) require _everyone_ you chat with
to be LISP-enabled or they're also not very useful. Is the assumption that
the routers all over suddenly one day turn LISP-enabled so someone will
bother using actually (normally) non-routable EIDs?

I think LISP 1.5+ is about as deployable as NIMROD+MPLS :-> (and less so
than IPv6)

> I really can't stress this enough that has to be a different problem,
> or the game is really over.  For one, you do not need to sign each
> prefix separately.  An authority needs to sign an update which may
> contain many mappings.  Second, the number of updates required in a
> period of time has to be considerably smaller - BY SEVERAL ORDERS OF
> MAGNITUDE - or we would have failed in our primary engineering
> objective of better scaling the routing system.

I think you missed my point; if you want the updates to be signed near
source of the change (i.e. by someone trusted by the owner of the prefix,
and therefore 'near' them in some trust hierarchy or whatever trust model
you envision for this), you cannot aggregate them.

Certainly, for just bulking the updates, you can just
authenticate/encrypt/whatever them between two routers but there isn't
significant gain to be seen there (your can only trust that yes, your
neighbor received the data from somewhere).

Anyway, I can see the number of prefixes dropping by one or two orders of
magnitude at most by this effort, if that; just doing the geographical
routing for continually expanding internet _will_ require fairly large
locator-space routing table for the RIDs. 

> updates.  Either will scale, and most of the technology exists for

'signed by an authority', which is that? From your earlier part of your
comment, I assume you have some sort of central 'Internet Routing
Authority' in mind, as otherwise you cannot have signed updates that can be
bulked (because each router/AS will have their own set of key material,
which they won't be keen to share). I like the IRA abbreviation too, maybe
it could be new department of DHS ;-)

More seriously though, if you assume you can really reduce the number of
prefixes by order(s) of magnitude, I suppose you'd want to go for
multi-level location mechanism, or otherwise allow for propagation time of
hours on changes to the RID-space?

For that, even current BGP would work. What my comment was aimed at was the
more general locator-id, or RID+EID lookup, in which you CANNOT keep the
amount of data down, and you will wind up with insane amount of data you
will need to NOT move (i.e. have it be only on-demand, or pull), or the
game is lost.. Certainly some points in the middle (e.g. SPs for example)
can cache the pulled data, but essentially push isn't viable for the
RID+EID case.

I don't see RID-only stuff as interesting, because I'd say the currently
existing technologies work on that front; however, for the EID+RID, I'm not
so sure about the DNS (or especially the DHT). And my doubts are mostly in
the trust/threat models, not in the actual scalability. DNS-based solution
would most likely scale; however, it would be vulnerable to number of
attacks. And no, DNSSec doesn't answer most of those problems - DNSSec
poses more questions than it provides answers if you are looking for really
sensible trust model for your effort.

Cheers,

-Markus

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 1 Apr 2007 23:36:55 -0700

> I think LISP 1.5+ is about as deployable as NIMROD+MPLS :-> (and  

We could deploy LISP today on the MBGP topology. That would be an  
example of LISP 1.5, that is AFI=ipv4,SAFI=multicast.

And if you set up a static GRE tunnel topology, either doing static  
EID-prefix configuration or distributing it via BGP on a completely  
different (much smaller) AS topology, that would be another example.

Dino

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 07:36:57 -0700

Eliot,

On Apr 1, 2007, at 9:54 AM, Eliot Lear wrote:
>>> Lookups are a non-starter because of the lookup latency and what  
>>> you do with a packet on a cache miss
>> I wonder if the folks who argued against moving from HOSTS.TXT to  
>> the DNS used the same rationale... :-)
> Remember, with LISP we're talking about ROUTERS switching PACKETs  
> and not END HOSTS establishing a communication (be it UDP, TCP,  
> SCTP, or whatever).

The routers won't need to switch packets until an end host tries to  
establish communication.

> My concern is latency in establishing a connection when everything  
> is in a nominal state, particularly due to an off-the-box lookup.

The normal state will be a lookup in local cache.  Yes, the initial  
state will require an off-the-box lookup which has increased  
latency.  The cost of this additional latency at communication  
initiation is what you pay for increased scalability, flexibility,  
and updatability.  You only fetch what you need when you need it.   
Contrast this to the RADB model which requires all the mapping data  
to be propagated globally regardless of any usage patterns.  How big  
is this table going to be (that is, how many end points will their be  
in the routing system)?  Yes, you can propagate diffs, but you still  
have to propagate the initial table to do the diffs against.  How  
long will that initial table download take?

> Yes, you can do it with DNS, but that will produce unacceptable  
> latency.

You make this assertion like it is axiomatic.  What is your  
definition of acceptable?

Rgds,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 17:44:27 +0200

Dave,

>> whatever).

Right.  All I'm saying is that a router can't do an off box lookup.  
It's just a non-starter (see below).

>
>> My concern is latency in establishing a connection when everything is 
>> in a nominal state, particularly due to an off-the-box lookup.
>
> state will require an off-the-box lookup which has increased latency.  
> The cost of this additional latency at communication initiation is 
> what you pay for increased scalability, flexibility, and 
> updatability.  You only fetch what you need when you need it.  
> Contrast this to the RADB model which requires all the mapping data to 
> be propagated globally regardless of any usage patterns.  How big is 
> this table going to be (that is, how many end points will their be in 
> the routing system)?  Yes, you can propagate diffs, but you still have 
> to propagate the initial table to do the diffs against.  How long will 
> that initial table download take?

At least initially the table + RIB is likely to not be much larger than 
the RIB itself.  Over time I would expect table+RIB to actually shrink 
for LISP versus what it would have been with the additional 
multihoming.  This is why I asked all those questions earlier about 
whether size matters.  If it's simply rate of transactions and not size, 
life is pretty good for LISP.
>
>> Yes, you can do it with DNS, but that will produce unacceptable latency.
>
> You make this assertion like it is axiomatic.  What is your definition 
> of acceptable?

An order of magnitude or three under 1 ms.  And buffering the packet is 
also a non-starter.

Eliot

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 08:56:11 -0700

Eliot,

On Apr 2, 2007, at 8:44 AM, Eliot Lear wrote:
> An order of magnitude or three under 1 ms.

Why?

> And buffering the packet is also a non-starter.

Why?

Rgds,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 18:19:28 +0200

>> An order of magnitude or three under 1 ms.

Because we shouldn't engineer delay into the system, and second, because 
that is what matches existing behavior today.  Want to take a guess as 
to which applications need that 1ms and which don't?  I sure as heck 
don't want to be there.
>> And buffering the packet is also a non-starter.

First because that's not what routers should be for.  Routers are for 
*delivering* packets not *storing* them. Moreover, it's not just one 
packet- it's going to be a train of packets, more likely.  People keep 
talking as if we're talking about a single packet, presuming that in 
each case a conversation is beginning.  That may be a false assumption.  
Beyond that, the caching semantics and "active conversations" are quite 
a lot of hair that I believe you should demonstrate need prior to imposing.

Regards,

Eliot

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 10:14:06 -0700

Eliot,

On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote:
>> [latency]
> Because we shouldn't engineer delay into the system,

There are already numerous delays engineered into the system.

> and second, because that is what matches existing behavior today.

How long does it take for a router that takes full routes when it  
initially started to be able to forward packets?  A system based on a  
pull model would be able to avoid this delay.

> Want to take a guess as to which applications need that 1ms and  
> which don't?

Why 1ms?  Why not 10ms or 0.1ms?  None of these numbers appear to be  
backed up by any empirical evidence.

> I sure as heck don't want to be there.

Name one application that can't tolerate a delay on initial start  
up.  Realistically, since we're talking about a datagram based  
network with best effort delivery, the additional latency that would  
exist in an on-demand pull-based model would be lost in the noise of  
initial communication establishment.

>> [buffering]
> First because that's not what routers should be for.  Routers are  
> for *delivering* packets not *storing* them.

Good thing we don't need ARP.

Routers already buffer.

> Moreover, it's not just one packet- it's going to be a train of  
> packets, more likely.

Last I checked, TCP-based traffic outweighed all other traffic  
significantly.

> People keep talking as if we're talking about a single packet,  
> presuming that in each case a conversation is beginning.  That may  
> be a false assumption.

Yes, there can be cases where the first packet in a transaction is  
actually a set of packets, in which case, the router has the choice  
of buffering or dropping until the mapping can be performed.

In an ideal world, I would agree that it would be really nice to have  
the entire mapping table local.  However, I believe this simply won't  
scale.  You're moving the routing table thrash problem from a  
smallish set of really well connected core routers down to every edge  
system (for some value of the variable "edge").  You can "solve" this  
problem somewhat by artificially constraining how frequently the  
table changes, but you're the one who is saying we shouldn't engineer  
delays into the system.

Rgds,
-drc

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 10:19:18 -0700

David/Eliot,

This goes back to what I said in an earlier message:

+ You seem to be assuming that the mapping will be driven by
+ the first packet out the door; I'm not assuming that at all.
+ For inter-site communications, there will always be an initial
+ FQDN-to-locator resolution before a session starts, and the
+ mapping can be done then before any packets are sent.

So, I really don't see a reason to be worried about new delay
models at all.

Fred
[email-masked]

> -----Original Message-----
> From: David Conrad [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 10:14 AM
> To: Eliot Lear
> Cc: [email-masked]
> Subject: Re: [RAM] Incremental Deployment of LISP
> 
> Eliot,
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Apr 2007 10:22:37 -0700

> There are already numerous delays engineered into the system.

David, let me try this to see how Eliot will react.

Eliot, (like Fred Templin's idea), what if the host pointed it's DNS  
server address to a router, say the ITR router.

So when the host does a DNS lookup, the router intercepts it (not  
really intercepts it because the UDP packet is addressed to the  
router), sends it on but also adds a request record for say a RLOC  
RR. The ITR will have to make the request come from the ITR's source  
address so the reply returned can get the RLOC RR stored in the EID- 
to-RLOC mapping cache by the ITR. Then the ITR can return the A  
record reply to the host.

All this happens before the first TCP SYN is sent by the host.

There is increased latency, but the host doesn't really know any  
differently.

So question to beg is will IT managers feel comfortable pointing DNS  
server addresses to this map-n-encap routers.

Dino

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Apr 2007 10:38:11 -0700

> Good thing we don't need ARP.

A somewhat common and successful router implementation used to drop  
all transit packets that required ARP requests.  Doing otherwise  
requires possibly unbounded storage requirements and simplifies DoS  
attacks.

Buffering user packets to cover mapping delay will have the same  
impact and be fundamentally unsolvable (modulo some LRU techniques)  
unless the mapping is very highly distributed, preferably co-located  
in the host itself.

Tony

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 10:41:33 -0700

On Apr 2, 2007, at 10:22 AM, Dino Farinacci wrote:

> So question to beg is will IT managers feel comfortable pointing  
> DNS server addresses to this map-n-encap routers.

I don't think the network operations staff will necessarily be  
overjoyed with this new responsibility, and it also strikes me as a  
great DoS vector.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

         Words that come from a machine have no soul.

                       -- Duong Van Ngo

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Apr 2007 10:43:52 -0700

On Apr 2, 2007, at 8:44 AM, Eliot Lear wrote:

> All I'm saying is that a router can't do an off box lookup.  It's  
> just a non-starter (see below).

Assuming a pull model, there's no real reason that a router can't  
implement a cache of mappings, even if the lookup is off-box.  If you  
trigger the mapping based on a DNS request, as Fred has suggested,  
then the cache can be pre-populated before the first data packet  
arrives.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Apr 2007 10:45:24 -0700

> overjoyed with this new responsibility, and it also strikes me as a  

The same DOS vector we have today to DNS servers or a new one?

Dino

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 10:50:15 -0700

On Apr 2, 2007, at 10:43 AM, Tony Li wrote:

> implement a cache of mappings, even if the lookup is off-box.  If  
> you trigger the mapping based on a DNS request, as Fred has  
> suggested, then the cache can be pre-populated before the first  
> data packet arrives.

What about IP communications which don't involve DNS lookups?  A fair  
amount of VoIP is done this way, for example.

                       -- Duong Van Ngo

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 10:57:18 -0700

> The same DOS vector we have today to DNS servers or a new one?

Mostly the same ones, with the added bonus that they can now  
potentially disrupt routing.  And of course this scheme is going to  
involve a pretty substantial increase in the number of DNS lookups,  
as well.  Not to mention the face that, absent universal DNSSEC  
deployment, the potential for other forms of abuse could well  
increase if we rely on the DNS for this lookup functionality.

Why all the interest in the DNS for this?  Why not just do it in the  
routing protocols or in some fancy new in-band (from the point of the  
network infrastructure) mechanism?

DNS wasn't designed to do this, and the global DNS won't scale for  
this/isn't reliable enough for this/isn't politically or  
operationally feasible for this; so now we want to collapse DNS  
functionality into the routers?

Without rehashing all the same arguments, it appears that a pretty  
good case has been made that the DNS isn't right for this  
application.  Which seems to indicate the need for Something Else.

                       -- Duong Van Ngo

---

From: McTim <[email-masked]>
Date: Mon, 2 Apr 2007 21:01:37 +0300

> amount of VoIP is done this way, for example.

Won't this change significantly with more widespread ENUM usage?

-- 
Cheers,

McTim
$ whois -h whois.afrinic.net mctim

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 11:03:58 -0700

I'll add to what Dino said that everything works best when
the host, the DNS server and the ITR all occur on the same
physical platform (or, "enclave" as some call it).

Fred

> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 10:23 AM
> To: David Conrad
> Cc: [email-masked]

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 11:05:27 -0700

> Won't this change significantly with more widespread ENUM usage?

In some cases, yes, assuming ENUM is in fact widely deployed.  In the  
case of various semi-closed proprietary overlay systems (such as many  
of the more popular ones in use today), it's not clear that this  
would be the case.

                       -- Duong Van Ngo

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 20:18:11 +0200

Dino Farinacci wrote:
> router), sends it on but also adds a request record for say a RLOC RR. 
> The ITR will have to make the request come from the ITR's source 
> address so the reply returned can get the RLOC RR stored in the 
> EID-to-RLOC mapping cache by the ITR. Then the ITR can return the A 

The host knows when the conversation will start, and buffering the 
latency in the host is far more practical because it can react better if 
it doesn't like it.  This is HIP, btw.  I have no problems with it.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 20:18:32 +0200

Dave,
> Name one application that can't tolerate a delay on initial start up.

False assumption from the get go.  Why do you think it's only at the 
startup of the application?  How is a *router* to know this?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 20:20:55 +0200

Tony Li wrote:
> then the cache can be pre-populated before the first data packet arrives.
>
I think the only issue is how the router knows all of this under LISP.  
As long as it doesn't need to know that "an application is starting" I 
think that's fine.

Eliot

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 11:27:17 -0700

Roland,

On Apr 2, 2007, at 10:57 AM, Roland Dobbins wrote:
> Why all the interest in the DNS for this?

Personally, I typically use the DNS merely as an example of a pull- 
based model.  It has many of the attributes we'd probably like to  
have if we go this route, from caching semantics to security (of a  
sort).  I'd be happy with an alternative pull-based mechanism.   
However, with that said:

> Why not just do it in the routing protocols or in some fancy new in- 
> band (from the point of the network infrastructure) mechanism?

There is nothing stopping us from coming up with an entirely new  
protocol, other than perhaps time.  We know where the DNS's warts  
are.  When you come up with a new protocol, you usually have to spend  
a bit of time discovering its warts.

> DNS wasn't designed to do this,

The DNS was designed to be a fairly generic network based key/value  
lookup system.  The lookup of a locator value given an identifier key  
is well within the model PVM had in mind (so he says) when he  
proposed the DNS protocol.

> and the global DNS won't scale for this/isn't reliable enough for  
> this/isn't politically or operationally feasible for this;

Irrelevant.  We're talking about the DNS protocol, not necessarily  
the DNS as it has been implemented.  However, with that said:

- the global DNS has scaled to 60,000,000 names in a single zone and  
I have personal experience with implementations that can deal with an  
order of magnitude more.

- the reliability of the DNS depends on its implementation from the  
root down the specific branch the series of labels you are interested  
in reside.  The root is extremely reliable.  There is nothing  
indicating a specific branch of the root can't be equally or more  
reliable.

- politics aren't an issue since presumably, any sort of tree used  
for this sort of functionality would be found in the .ARPA TLD which  
is defined by the IAB

- operationally, there exist over 100,000,000 names in the DNS.  It  
would seem to be operationally feasible.

It is worth noting that the DNS protocol is used both for ENUM  
(public and infrastructure) as well as for RFID, both of which have  
scaling and reliability characteristics beyond what is found in the  
existing DNS.

> so now we want to collapse DNS functionality into the routers?

What is being discussed is a way of on-demand fetching a mapping.   
The DNS protocol can be used for this function, but it doesn't have  
to be.  However, if it isn't, you're going to have to solve many of  
the problems the DNS has solved.

> application.  Which seems to indicate the need for Something Else.

Propose something.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 11:30:56 -0700

Fred,

> physical platform (or, "enclave" as some call it).

I'd agree with "DNS server" and "ITR", however assuming the DNS  
server has to be numbered out of locator space instead of identifier  
space, putting the host on the same physical platform means you lose  
one of the big advantages of ID/LOC separation: the ability to  
transparently "renumber".  There is a tradeoff there,  on one hand,  
the larger the scope of identifier addressability, the less impact a  
renumbering event has.  On the other hand, the smaller the scope of  
identifier addressability, the more fine grained the control in stuff  
like multi-homing policy.

Rgds,
-drc

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 11:32:21 -0700

> the DNS as it has been implemented.  However, with that said:

I said this before, but I'm not worried about scaling issues
at all. This could be implemented by putting only FQDNs for
ITRs in the global DNS and keeping FQDNs for services in site
specific name resolution services.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 11:39:46 -0700

David,

> transparently "renumber".

No; I'm assuming the {host/DNS server/ITR} could be deeply
embedded within an enterprise/site and not necessarily with
a globally routeable locator. The locator could be re-written
as packets make their way out of the site and finally pop out
with a globally routable locator when the packet emerges into
the DFZ. So, it could go:

  ident->loc(L1)->loc(L2)-> ... ->loc(Ln)->loc(global)

where "loc(Li)" are locators that are valid only within a
local scope within the enterprise/site.

Folks who are interested in this thread should really
check out IPvLX (http://ipblx.net).

Fred

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Apr 2007 20:41:45 +0200

David Conrad wrote:
>> Want to take a guess as to which applications need that 1ms and which 
>> don't?
>

Actually, this is my point.  We have very little data in terms of what 
applications would be impacted, and so the best behavior we can have is 
the behavior we have today.  Any variation from that requires 
understanding what those tradeoffs are going to be and I think that's a 
Hard Problem.  However...

> scale.  You're moving the routing table thrash problem from a smallish 
> set of really well connected core routers down to every edge system 
> (for some value of the variable "edge").  You can "solve" this problem 
> somewhat by artificially constraining how frequently the table 
> changes, but you're the one who is saying we shouldn't engineer delays 
> into the system.
I take your point that you are concerned about LISP scaling.  I think 
there is work to do to show that it would, and in that respect I agree 
with those concerns.

To be clear a mapping update offers no routing delay per-se.  And the 
whole point of the exercise is to engineer something the provisioned 
mapping is relatively static while the routing table remains stable or 
improves on the performance curve over time.  You seem to think that 
this mapping will be huge.  I don't know.  I guess that it will scale 
with the number of multihomed end points.  I imagine that each entry in 
this table saves some space somewhere in the RIB.  I further envision 
that either big multihomed enterprise h/w or PE h/w will perform the 
mapping.

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 11:42:46 -0700

> check out IPvLX (http://ipblx.net).

Umm - make that "http://ipvlx.net".

Thanks - Fred

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 11:44:10 -0700

Eliot,

On Apr 2, 2007, at 11:18 AM, Eliot Lear wrote:
> False assumption from the get go.

I used bad terminology (I meant protocol), but fair enough.

> Why do you think it's only at the startup of the application?

Well, that's the most common time a new end point/locator mapping  
would be needed.

> How is a *router* to know this?

It, of course, doesn't.  However, at some point, the router will see  
a packet with a destination end point identifier it hasn't seen  
before, at which point it would do need to do an off-box lookup. It  
can then buffer that packet until it receives a response or drop it  
on the floor, assuming the source will retransmit like any protocol  
that assumes it lives on a best effort datagram infrastructure.

At that point, unless the router has been restarted or has run out of  
cache and had to reuse a cache slot, the router knows when it has  
seen a request for the same end point identifier.  Assuming the  
mapping has a TTL, the router can refresh the entry before the TTL  
expires if it determines it is likely the mapping would be used again.

Thus, the latency hit would occur only the first time the router sees  
the destination end point identifier or when the mapping has been  
dumped from the cache.

Rgds,
-drc

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 11:49:32 -0700

On Apr 2, 2007, at 11:44 AM, David Conrad wrote:

> Thus, the latency hit would occur only the first time the router  
> sees the destination end point identifier or when the mapping has  
> been dumped from the cache.

What about dynamism on the part of the destination endpoint and/or  
communications models which involve dynamic multiple destination  
endpoints?

                       -- Duong Van Ngo

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 11:57:18 -0700

Roland,

> communications models which involve dynamic multiple destination  

I assume mappings have a TTL like the DNS RRset TTL.  As I said in  
the note you took this from:

>> Assuming the mapping has a TTL, the router can refresh the entry  
>> before the TTL expires if it determines it is likely the mapping  
>> would be used again.

Refreshing the mapping would handle the dynamism you're mentioning  
(if I understand the question).  Since the TTL would be assigned by  
the destination owner (albeit likely clamped by policy by the  
source), high levels of dynamic behavior could be supported -- _much_  
higher than would be reasonably possible in a push based model.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Apr 2007 12:13:11 -0700

Eliot,

> And the whole point of the exercise is to engineer something the  
> provisioned mapping is relatively static

Perhaps this is part of the disconnect.  I am not making the  
assumption that the mapping is relatively static (however, I suspect  
this gets into the definition of 'relatively static').

> while the routing table remains stable or improves on the  
> performance curve over time.

I am assuming this (otherwise, as you say, what's the point?).

> You seem to think that this mapping will be huge.  I don't know.  I  
> guess that it will scale with the number of multihomed end points.

No.

My assumptions is that the mapping table will be approximately equal  
to the number of network attachment edge points.  That is, the end  
state is that you have a locator numbered core interconnecting an  
identifier numbered edge.  The mapping service translates the non- 
aggregatable identifier universe into the highly aggregateable  
locator universe.

> I imagine that each entry in this table saves some space somewhere  
> in the RIB.  I further envision that either big multihomed  
> enterprise h/w or PE h/w will perform the mapping.

Simplifying a bit, I am assuming at every service provider/customer  
boundary (for some value of the variable "service provider"), there  
is a mapping device (what Dino calls an ITR) and that each one of  
those ITRs will require at least one mapping entry (more if they are  
multi-homed, which I expect to become the norm as opposed to the  
exception as more and more services depend on reliable IP service).

The goal of the mapping is to ensure the RIB/FIB scales with the  
number of service providers, not the number of network attachment  
edge points.

Rgds,
-drc

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 12:13:48 -0700

On Apr 2, 2007, at 11:57 AM, David Conrad wrote:

> high levels of dynamic behavior could be supported -- _much_ higher  
> than would be reasonably possible in a push based model.

This is actually the first intrinsically desirable property which has  
been identified out of this whole subtopic, IMHO.

Very interesting.

                       -- Duong Van Ngo

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Apr 2007 13:15:24 -0700

PreFrom [email-masked] Mon Apr 02 16:16:03 2007
Date: Mon, 2 Apr 2007 22:15:19 +0200 (CEST)
From: Roger Jorgensen <[email-masked]>
To: David Conrad <[email-masked]>
Subject: Re: [RAM] LISP and the Global Internet Architecture
Cc: "Fleischman, Eric" <[email-masked]>, [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---226418608-1458046043-1175544919=:1566
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mux1.uit.no id
	l32KFKfk046780

On Mon, 2 Apr 2007, David Conrad wrote:
<snip>
> To clarify, I'd argue that the vast majority of end users couldn't care=
 less=20
> whether they had IPv4, IPv6, NSAPs, or lima beans for addresses.  What =
end=20
> users care about is continued accessibility to network services of vari=
ous=20
> flavors and kinds.  Until this can be provided over IPv6, with no need =
for=20
> any significant end user (or end user supporting organization) configur=
ation=20
> changes, IPv6 will remain dead in the water.

That=B4s all so true. I work for an organization/company owned=20
indirect by the state and our only goal is to provide electronic=20
infrastructure so there can be widespread use of what the world know as=20
Telemedicine. We have so much trouble with IPv4 due to every possible=20
reason and how they would react to IPv6...no idea.

Bottom line, our end-users, doctors working with patients everyday only=20
care about onecedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

On Apr 2, 2007, at 10:50 AM, Roland Dobbins wrote:
> What about IP communications which don't involve DNS lookups?  A  
> fair amount of VoIP is done this way, for example.

I suspect that you can guess how I feel about applications that  
choose to do referrals by IP address.

Tony

 singel thing, to be able to communicate with the hospitals=
=20
and other they need in their daily work.
IPv6 are faaaar from ready for those users even tho most of our problems=20
with be solved with IPv6. Problems like NAT, double NAT and tripple NAT,=20
conflicting IP addresses due to every hospital/county have their own=20
network using RFC1918 addresses...

--=20

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------
---226418608-1458046043-1175544919=:1566
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

---226418608-1458046043-1175544919=:1566--

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Apr 2007 13:15:24 -0700

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Apr 2007 13:20:33 -0700

On Apr 2, 2007, at 11:30 AM, David Conrad wrote:

> server has to be numbered out of locator space instead of  
> identifier space, putting the host on the same physical platform  
> means you lose one of the big advantages of ID/LOC separation: the  
> ability to transparently "renumber".

That's only an issue if there are other hosts dependent on that "DNS  
server" functionality.   If one was to co-locate everything, then you  
can effectively morph LISP into being a purely host-based solution.   
This has wonderful benefits for scalability.

Tony

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 13:22:37 -0700

> choose to do referrals by IP address.

I largely share those sentiments, but that doesn't negate the fact  
that a) they exist, b) people like/use them, and c) therefore they  
must be taken into account, heh.

                       -- Duong Van Ngo

---

From: Tony Li <[email-masked]>
Date: Mon, 2 Apr 2007 13:26:15 -0700

> must be taken into account, heh.

Then you'll have no issues with the fact that there may be a mapping  
delay for those applications.

Tony

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 2 Apr 2007 13:34:46 -0700

On Apr 2, 2007, at 1:26 PM, Tony Li wrote:

> Then you'll have no issues with the fact that there may be a  
> mapping delay for those applications.

I won't, but the users may well, depending upon the length of the  
delay and its effect on the applications - we can't just arbitrarily  
impose a delay without some stab at quantifying it and gaining an  
understanding of its potential impact to things which users rely  
upon, IMHO.

I'm concerned that there may be some fairly negative impact to some  
VoIP systems, other things like SCADA and/or HVAC systems (which  
oughtn't to be running across the Internet, anyways, but that's a  
different discussion), medical imaging systems (same), etc.

                       -- Duong Van Ngo

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Apr 2007 14:03:34 -0700

I have been operating under the following assumptions:

 1) LISP 1 - locators and identifers are globally routable
    IPv4 addresses.
 2) LISP 1.5 - locators are globally routable IPv4 addresses,
    and identifiers are IPv6 addresses that are routeable on
    a global IPv6 infrastructure, e.g., the 6Bone.
 3) LISP 2/3 - locators are globally routable IPv4 addresses,
    and identifiers are IPv6 addresses that are routeable
    only within the local enterprise/site. IPv6 ULAs (RFC4193)
    provide a natural addressing mechanism for this.

Comments?

Fred

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 02 Apr 2007 14:52:01 -0700

Dino,

> example of LISP 1.5, that is AFI=ipv4,SAFI=multicast.

This would be an good example to illustrate that LISP 1.5 offer
*no* reduction of the volume of routing information.  To the contrary,
this example would illustrate how LISP 1.5 would result in increasing
volume of routing information. 
  
Yakov.

---

From: Bruce Curtis <[email-masked]>
Date: Mon, 2 Apr 2007 18:57:17 -0500

> [email-masked]

   If sites follow RFC 2182 then they will have at least one  
secondary DNS server that won't have the same mapping as the primary  
DNS server.  So the FQDN-to-locator resolution may not always have  
the same mapping as  the packets to the destination site that follow.

   For customers of at least one company, Akamai, the FQDN-to-locator  
resolution mapping will likely always be different than the mapping  
for the destination site.

>> table changes, but you're the one who is saying we shouldn't

---
Bruce Curtis                         [email-masked]
Certified NetAnalyst II                701-231-8527
North Dakota State University

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Apr 2007 21:43:22 -0700

>     provide a natural addressing mechanism for this.

The spec indicates each variant can be used for IPv4 and IPv6. So one  
variant is not more IPv6 or IPv4 centric then the other.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Apr 2007 21:45:20 -0700

> volume of routing information.

It reduces the unicast FIB. And the number of routers that have to  
store the additional routes.

Furthermore, the EID-prefix space can aggregate better than today's  
BGP core since it is not based on topology.

Dino

---

From: Eliot Lear <[email-masked]>
Date: Tue, 03 Apr 2007 13:10:28 +0200

Dave,
> identifier numbered edge.  The mapping service translates the 
> non-aggregatable identifier universe into the highly aggregateable 
> locator universe.

I don't see why we should assume this.  Take the common case where you 
have a gazillion residential DSL connections.  Why don't they just 
continue to use the PA space and let the SPs handle any LISP.  The PE or 
something close to it still needs to do LISP, but they need to do BGP 
today, so that doesn't particularly bother me IFF the update times on 
LISP are several orders of magnitudes below that of the routing space.
>
>> I imagine that each entry in this table saves some space somewhere in 
>> the RIB.  I further envision that either big multihomed enterprise 
>> h/w or PE h/w will perform the mapping.
>
> boundary (for some value of the variable "service provider"), there is 
> a mapping device (what Dino calls an ITR) and that each one of those 
> ITRs will require at least one mapping entry (more if they are 
> number of service providers, not the number of network attachment edge 
> points.

Nice goal.  I do not see how we get there.  This having been said, 
O(DSLAMs) seems considerably smaller than O(network attachment points).

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Apr 2007 13:39:50 +0200

On 2007-04-02 20:49, Roland Dobbins wrote:
> communications models which involve dynamic multiple destination endpoints?

You're in extreme danger of reinventing shim6.

The choice there was to send the packet and defer the mapping - which
of course assumes the ID can be used as a locator. Strangely enough,
LISP 1.0 seems to assume the same...

      Brian

---

From: Russ White <[email-masked]>
Date: Tue, 03 Apr 2007 08:47:37 -0400

> It reduces the unicast FIB. And the number of routers that have to store
> the additional routes.

If the size of the unicast FIB table is the "real" problem, can we open
up the solution space to all possible solutions that can accomplish this?

> Furthermore, the EID-prefix space can aggregate better than today's BGP
> core since it is not based on topology.

I don't see why or how this would be true. It may be somewhat true in
the current, hosts nailed to the floor, provider/enterprise model of
things for the big I Internet. But for the rest of the world, I'm not
certain this is true at all.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Apr 2007 09:39:43 -0700

Eliot,

On Apr 3, 2007, at 4:10 AM, Eliot Lear wrote:
> I don't see why we should assume this.  Take the common case where  
> you have a gazillion residential DSL connections.

Good example.

> Why don't they just continue to use the PA space and let the SPs  
> handle any LISP.

Because multi-homing with PA is hard and annoying.

My assumption is that people are going to be more and more dependent  
on Internet connectivity in the future (not only for data, but also  
VoIP, TV/movies-over-Internet, home security monitoring, home  
automation, etc).  With dependency comes demand for increased  
reliability.  I believe this demand for reliability will drive  
increased requirements for multi-homing, particularly in the  
residential markets and particularly via multiple high speed wireless  
providers.

A locator/ID split solution would allow _anyone_ to be provider  
independent and to multi-home without having to know BGP.  I can  
easily imagine Internet service becoming commodity in the sense that  
customers change providers rapidly as costs/load/performance shifts.   
Try doing that with PA.

> Nice goal.  I do not see how we get there.

The reason the RIB/FIB currently tends to scale to the number of  
network attachment points is because having your own PI address space  
gives you two major advantages (no need to renumber when you change  
providers and (relatively) easy multi-homing) over PA space.  If you  
provide these advantages via a mechanism that doesn't require folks  
to know BGP and which makes multi-homing as simple as calling up  
another provider and saying "I want service from you too", I believe  
there will be a natural tendency away from everybody wanting PI space.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Apr 2007 09:46:48 -0700

Tony,

On Apr 2, 2007, at 1:20 PM, Tony Li wrote:
> at's only an issue if there are other hosts dependent on that "DNS  
> server" functionality.   If one was to co-locate everything, then  
> you can effectively morph LISP into being a purely host-based  
> solution.

Maybe it's me, but I don't really see a demand for host-based  
solutions.  I see a demand for "site"-based solutions.

Rgds,
-drc

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Apr 2007 09:55:10 -0700

> solutions.

Not host-based; *platform* based (where, a platform is a
router and its attached hosts).

A vehicle could be a platform.

An airplane could be a platform.

*My laptop could be a platform if it acted as both a
router and a host.*

> I see a demand for "site"-based solutions.

A platform is a site unto itself.

Fred

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Apr 2007 10:37:10 -0700

At 9:46 AM -0700 4/3/07, David Conrad wrote:
>>>I'd agree with "DNS server" and "ITR", however assuming the DNS server has to be numbered out of locator space instead of identifier space, putting the host on the same physical platform means you lose one of the big advantages of ID/LOC separation: the ability to transparently "renumber".
>>at's only an issue if there are other hosts dependent on that "DNS server" functionality.   If one was to co-locate everything, then you can effectively morph LISP into being a purely host-based solution.
>
>Maybe it's me, but I don't really see a demand for host-based solutions.  I see a demand for "site"-based solutions.

Then you don't see a demand for real mobility.  For an end-node which changes
points of attachment frequently, the current system uses a kludge (a tunnel
back to a "home" network, so that the node can pretend to be at some putative
usual place in the network topology).  That forces the node into making
local next-hop decisions, as it will always have at least two interfaces (tunnel
and local access network) which have very different latency characteristics,
are in different parts of the topology, and may have different reachability. 
Devices which have the capability to attach  using multiple different technologies
(wired+wireless, multiple radios, plus tunnel interfaces) are also increasingly
typical, and if they aren't the majority now, they will be by the time anything
this group is discussing deploys.

If we can define and get deployment for a  system which allows a flow to pass
from end-to-end using a stable identifier as  a target,  even if one or both
of the end-nodes is not attached to its putatively usual place in its "home" network,
that is a very big win.  My concern with many of the jack-up discussions to
date is that they appear to aim at interconnecting private address realms
at a level that would end up perpetuating the kind of tunneling that is already
a problem now.  For folks who don't like ICE and friends now, this kind of jack-up
is only going to make things worse, as there will be yet another set of opaque
middle boxes in the network that the end-nodes will be hard-pressed to discover
but cannot ignore.

			regards,
				Ted Hardie

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Apr 2007 21:18:14 +0300

>  If you provide these advantages via a mechanism that doesn't require
> folks to know BGP and which makes multi-homing as simple as calling up
Yes. But until the details are worked out its unclear to me what the
costs associated with the separation actually are. What other things
would an end-site/border router need in the place of current
mechanisms? Would they need another protocol for pushing mappings
around the globe? Would this be less, more, or equal to the complexity
of running BGP? What would the security mechanisms be that
an end site would need to show the rest of the world that its
identifiers are now at a new location?

Jari

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Apr 2007 13:26:16 -0700

Ted,

On Apr 3, 2007, at 10:37 AM, Ted Hardie wrote:
> Then you don't see a demand for real mobility.

Sure I do.  "Sites" can be mobile (e.g., an airplane, a soldier, a  
laptop).  I haven't wanted to go into detail discussing mobility  
aspects because (in my experience) (a) people get distracted and (b)  
MobileIP fans get unhappy.

> My concern with many of the jack-up discussions to
> a problem now.

So, it is difficult to have your cake and eat it too.

If folks are going to insist that applications need to use network  
topology, they have to be exposed to that topology.  One solution to  
the problem ICE is trying to solve is to configure the node with the  
locator addresses obtained from the ISP(s).  You gain control over  
the use of network topology but lose the ability to painlessly change  
ISPs and simple multi-homing.

How important is the sort of hackery ICE is attempting to address?

Rgds,
-drc

---

From: Tony Li <[email-masked]>
Date: Tue, 3 Apr 2007 14:02:30 -0700

> solutions.  I see a demand for "site"-based solutions.

Interesting.  I've only seen a rejection of host-by-host managed  
solutions.  I haven't seen anything that required a site based  
solution.  It seems to me that some site-managed host based solution  
is NOT out of the question.  Data?

Tony

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Apr 2007 14:16:52 -0700

At 1:26 PM -0700 4/3/07, David Conrad wrote:
>If folks are going to insist that applications need to use network topology, they have to be exposed to that topology. 

Absolutely, and the mic time I've used whining should probably have been
better focused on just that point:  nodes actually make decisions now by
inference or heuristics that would be made better and more easily with
actually information on the topology.  If we give them that information,
things will get better.  Obviously, that goal has different scaling characteristics
and requires more work than some of the ones asserted on this list.

>One solution to the problem ICE is trying to solve is to configure the node with the locator addresses obtained from the ISP(s). 

That doesn't work now, because most of the time the node is behind a NAT that
is sharing a single global locator among multiple nodes.  With v6 address
pools it is possible, as the node could be assigned a global locator assigned
from the ISP.  Indeed, that does happen in some environments now; those
addresses are used for the media path once they have been identified by the node.
In either case, there are two things that frustrate this being fully effective.
The first is that in many deployments there are still  at least two addresses
to choose between, as the locally assigned address used for media is not
the address used for communication to the SIP proxy. That address is a tunnel
interface back to the "home" network.  What application layer mobility SIP has
derives from the consistent proxy address for signalling being available when
the locally assigned IP addresses (for media) change.  The second is the
point I made in a previous post--that NATs or firewalls do not allow packets
through to target end hosts until the flow has been enabled by action by the
target (the "connectivity check" in ICE being the hook for that).  If we don't
deal with that somehow, having globally reachable addresses doesn't
result in true local reachability no matter what.

>You gain control over the use of network topology but lose the ability to painlessly change ISPs and simple multi-homing.

If I can associate an identifier with multiple points of attachment (either
simultaneously or serially at short timescales) that could improve.  But
we have to recognize that some of the existing mechanisms for application
layer mobility/agility will have to change and provide for them.  If we
don't, we'll either have breakage or yet another failure to launch.

>How important is the sort of hackery ICE is attempting to address?

Assuming you mean the end result, rather than the specific mechanism,
as important as VoIP.
			regards,
				Ted

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Apr 2007 18:18:37 -0700

Jari,

On Apr 3, 2007, at 11:18 AM, Jari Arkko wrote:
> costs associated with the separation actually are.

What are the costs associated with not doing the separation?  There  
are at least some who say "too high".

> What other things would an end-site/border router need in the place  
> of current mechanisms?

First cut:
- a way of (securely) creating the identifier/locator mapping
- a way of (securely) modifying the identifier/locator mapping
- a way of doing a lookup in and/or obtaining the identifier/locator  
mapping
- a way of determining reachability and next hop for the destination  
locator(s)
- in the case of multi-homed sites, a way of determining which of a  
set of destination locators is "best"
- a way of (securely?) determining destination locator failure
- a way of coping with "legacy" addresses (this is the hardest part)

> Would they need another protocol for pushing mappings around the  
> globe?

Obviously there needs to be some way of obtaining the mapping.  If a  
push model is used, a new protocol (or modification to an existing  
protocol like BGP) will almost certainly be necessary.  If a pull  
model is used, DNS might be an option.  If DNS is not used, a new  
protocol will almost certainly be necessary.

> Would this be less, more, or equal to the complexity of running BGP?

That would likely depend on the protocol, I suppose.  If the DNS is  
used, I'd argue it would be less complex.

> What would the security mechanisms be that an end site would need  
> to show the rest of the world that its

That would likely depend on the protocol, I suppose.  If the DNS is  
used, DNSSEC can be used to ensure the mapping data published by the  
identifier prefix zone manager hasn't been modified.  The mechanism  
used to modify the identifier prefix zone could be anything from  
ssh'ing into the DNS server and using emacs/vi to modify the zone to  
a nice GUI SSL encrypted web interface.  Not rocket science.

Of course, this is just one aspect of "security" and I suppose the  
various other aspects would need to be explored to determine if they  
need to be addressed.

However, as I said in Amsterdam, "There Ain't No Such Thing As A Free  
Lunch".  There will be costs to _any_ approach taken.  It isn't  
sufficient to determine the costs of a single approach as any cost  
must be judged relative to the costs of other approaches.  Outside of  
some form of LOC/ID separation and PI to Everyone, what other  
approaches are being actively explored?

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Apr 2007 18:24:14 -0700

Tony,

On Apr 3, 2007, at 2:02 PM, Tony Li wrote:
> solution.  It seems to me that some site-managed host based  
> solution is NOT out of the question.  Data?

I was speaking only of my experience.  In the various discussions  
I've had, I've only had a few folks indicate they thought a host- 
based solution (that is, a solution that requires host-level  
configuration) was the right way to go.  I suppose a site-managed  
host based solution would be workable, albeit I personally would be  
concerned about the additional complexity (management and/or  
software) this would imply.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 3 Apr 2007 18:39:46 -0700

Ted,

On Apr 3, 2007, at 2:16 PM, Ted Hardie wrote:
>> topology, they have to be exposed to that topology.
> actually information on the topology.

Right.  I guess one of my questions is why folks feel it necessary to  
jump through the various inference and/or heuristic hoops in order to  
determine topology.  Can it be assumed these reasons might go away in  
the future?

Probably not, I know...

> the address used for communication to the SIP proxy.

I'm not sure I fully understand.  Wouldn't the application be  
configured to provide the appropriate referral address for  
topologically sensitive transport?  Or are you saying the routing/ 
addressing architecture should do this for those applications that care?

> The second is the

I think it would be a mistake to try to come up with an network  
routing/addressing architecture that attempts to defeat  
administratively defined policy.  This is called an "arms race" and  
we'll lose.

> Assuming you mean the end result, rather than the specific mechanism,

No, I meant the reason folks go and write protocols that making  
dealing with NAT hard are doing so for some set of reasons.  Are  
those reasons permanent?  How much of the hackery due to the desire  
to bypass administratively defined policy (e.g., tunnel everything  
through HTTP because nobody blocks HTTP)?

Rgds,
-drc

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Apr 2007 21:46:23 -0700

At 6:39 PM -0700 4/3/07, David Conrad wrote:
>Right.  I guess one of my questions is why folks feel it necessary to jump through the various inference and/or heuristic hoops in order to determine topology.  Can it be assumed these reasons might go away in the future?
>
>Probably not, I know...

Probably not.  Certainly passing media packets through a proxy in a "home"
network results in significantly degraded performance compared to passing
them directly, so the tunnel interface vs. locally assigned IP interface is
likely to be significant as long as Mobile IP in its current form is with us.

If you're dealing with a host that is attached in multiple ways (wireline and 802.11
in laptops,  for example), it may get less important if the capabilities
of the two links are perceived as commonly the same.  That's not the case now,
and I'm not sure that it will be the case even if the link speeds are equal, as
there are situations where the actual topology is different with different attachment
types.  Unless the end-node gets this information somehow from the routing
system, it has to infer it to know whether a specific attachment is useful
for reaching a particular peer/server/multicast group.

>I'm not sure I fully understand.  Wouldn't the application be configured to provide the appropriate referral address for topologically sensitive transport?  Or are you saying the routing/addressing architecture should do this for those applications that care?

If it were always something that could be configured, things would be easy (or
at least easier).  At the moment, there are lots of places where determining
the appropriate address to use is a matter for discovery.

>I think it would be a mistake to try to come up with an network routing/addressing architecture that attempts to defeat administratively defined policy.  This is called an "arms race" and we'll lose.

It's not the intent here to defeat administratively defined policy.  The problem is
that the current mechanism using NATs is using a tool that is not really policy driven;
it's using a side-effect of the working of NATs, in effect, to get a policy result.  Getting
rid of NATs would likely push this into firewalls, but those are at least policy
devices.  Those could be upgraded in multiple ways to achieve the same ends
without mucking with reachability to do it.

>No, I meant the reason folks go and write protocols that making dealing with NAT hard are doing so for some set of reasons.  Are those reasons permanent?  How much of the hackery due to the desire to bypass administratively defined policy (e.g., tunnel everything through HTTP because nobody blocks HTTP)?

I don't think I understand you here.  Some applications-layer decisions clearly are
made for the reasons you cite ; lots of uses of HTTP as a substrate are because
the designers believe HTTP gets through firewalls (with deep packet inspection
lots of those folks also later get nasty surprises). 

But most of the jiggery-pokery around NATs seems to be related to the
many-to-few nature of common v4 NATs combined with the fact that NATs are
placed administratively without any necessary relation to the routing system. 
You can't know, in particular, how many layers of NATs are between you and an
intended peer, and you can't know which directions they "face" without
corkscrewing around a lot.   My personal reaction to that has been to try
to imagine ways to make the context transitions which might replace these
in an id/locator split world as obvious as possible.  Using the same bit-pattern
on both sides of the split, in particular, worries me greatly.  But I suspect
I am now very far off your question; can you clarify?

				regards,
					Ted

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Apr 2007 10:54:04 +0300

David,
> - a way of coping with "legacy" addresses (this is the hardest part)

Thanks for the list.

> must be judged relative to the costs of other approaches.

Exactly -- that's why I asked about the costs. I realize very well that
there are
costs with the current path we are on, but I also want to see the costs
associated with a new design. As you say, its the relation of the costs
between the different approaches that counts. (And we should be saying
"costs" in quotes, really, because we're not talking about money directly.)

> Outside of some form of LOC/ID separation and PI to Everyone, what
> other approaches are being actively explored?

I think research on routing algorithms is needed, too.

We already have host-based approaches which in my opinion are going to
be needed at the SOHO end of the scale, and for very dynamic situations.

Other than that, I don't see a lot of things that could change the situation
in any fundamental way. Do you? But in addition we need to maintain,
tune, and
engineer our current systems better. And remember that it takes a long
time to deploy something until it has an actual effect, e.g., in
the table size. The efforts that I see in the short-term space include

- hardware improvements and new types of designs (vendors are already
  doing this)
- small BGP improvements that might affect, say, how well it deals with
  dynamics (rtgarea and idr are going to look at this)
- operational practices

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Apr 2007 14:22:18 +0200

On 2007-04-04 03:24, David Conrad wrote:
> I was speaking only of my experience.  In the various discussions I've 
> had, I've only had a few folks indicate they thought a host-based 
> solution (that is, a solution that requires host-level configuration) 
> was the right way to go.  I suppose a site-managed host based solution 
> would be workable, albeit I personally would be concerned about the 
> additional complexity (management and/or software) this would imply.

There's no doubt that for the host-based solution I know best, shim6,
a serious sized site would need policy control of some kind - most
likely based on pushing an RFC3484-like address selection policy,
which could be used indirectly to control exit router selection.
For a SOHO site, I doubt that would be needed. For a large site,
PI would work better.

The point is that in all cases the end user couldn't care less. There
might be a couple of boxes to check but most likely the config
would be default. The IT department would have to do some config,
of course.

I think the real question is how much control the corporate IT
department needs and how much control the ISP needs.

     Brian

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 4 Apr 2007 12:54:29 -0700

I'm not tracking with you here, David. If LISP truly offers an
EID-locator split as claimed, why would the address space the end user
uses (the EID) affect the address space the ISPs doing Internet routing
use (the locator)? That is, LISP promises to decouple local addressing
issues from global addressing issues. If so, then what is to stop your
SOHO from switching ISPs while retaining your original PA addresses --
or do you need to internally switch to a private address space (e.g.,
Net10) to get such decoupling?

-----Original Message-----

<snip>

My assumption is that people are going to be more and more dependent on
Internet connectivity in the future (not only for data, but also VoIP,
TV/movies-over-Internet, home security monitoring, home automation,
etc).  With dependency comes demand for increased reliability.  I
believe this demand for reliability will drive increased requirements
for multi-homing, particularly in the residential markets and
particularly via multiple high speed wireless providers.

A locator/ID split solution would allow _anyone_ to be provider
independent and to multi-home without having to know BGP.  I can easily
imagine Internet service becoming commodity in the sense that  
customers change providers rapidly as costs/load/performance shifts.   
Try doing that with PA.

<snip>

---

From: David Conrad <[email-masked]>
Date: Wed, 4 Apr 2007 14:48:05 -0700

Eric,

On Apr 4, 2007, at 12:54 PM, Fleischman, Eric wrote:
> If LISP truly offers an
> EID-locator split as claimed,

To be clear, I'm talking about generic locator/id splits, not  
necessarily the specific instantiation of that split that is LISP  
(that is, I haven't thought deeply enough about LISP to see where it  
doesn't fit the model that I have in my head if anywhere, so I can't  
claim to speak about LISP specifically).

> why would the address space the end user
> use (the locator)?

It doesn't.  That's the point.

> That is, LISP promises to decouple local addressing issues from  
> global addressing issues.

Right.

> If so, then what is to stop your

Because by definition, PA address space is connectivity based.  You  
get it from your ISP and must return it to that ISP when you change  
ISPs.

> Net10) to get such decoupling?

EID space is, by definition, decoupled from locator space (and  
locator space is, of course, provider aggregatable).

Rgds,
-drc

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 7 Apr 2007 18:03:16 +0200

El 02/04/2007, a las 8:24, Dino Farinacci escribió:

>> In LISP 2 and 3 the issue you are considering needs to be considered 
>> imho
>>
>> you can check on it to verify if the destination is a identifier and 
>> which are the locators
>>
> LISP-push model gives you the best of all worlds.

by push model, we are talking about destributing the ID to locator 
mapping database to all LISP routers?

are you thinking in using a protocol for that distribution, like BGP 
for instance?

There have been a few proposals on this area before, which were very 
interesting imho, but i guess some people though they were too complex

regards, marcelo

>  We still can incrementally deploy tunneling and by augmenting 
> LISP-CAs and LISP-peering routers we can get EID-to-RLOC integrity, 
> DOS-protection, and non-routable IDs.
>
> Mark Handley and I are working on a proposal. Give us some time to get 
> it written down.
>
> Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 7 Apr 2007 19:37:32 -0700

> mapping database to all LISP routers?

I would say all high-level routers and not to every LISP ITR (or ETR).

> are you thinking in using a protocol for that distribution, like  
> BGP for instance?

A new protocol more optimized perhaps for flooding that has  
authentication built-in.

> There have been a few proposals on this area before, which were  
> very interesting imho, but i guess some people though they were too  
> complex

We can start simple. This doesn't need to be complex and if we keep  
policy out of it ;-) we can keep it easier. Please note, this  
protocol would be there to distribute EID-RLOC mappings and not the  
reachability status of the RLOCs.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 8 Apr 2007 10:50:51 +0200

El 08/04/2007, a las 4:37, Dino Farinacci escribió:

> I would say all high-level routers

i am not sure what do you mean by high level router... could you expand?

>  and not to every LISP ITR (or ETR).
>

but the ITR are the ones than need the information (hence the ones that 
should have it), right?

Of course, in addition, routers making TE would also benefit from it, 
so it makes sense to pass it to them also (but they are ITRs after all, 
right?)

> A new protocol more optimized perhaps for flooding that has 

what is the motivation for a newte pays its isp by load, then i guess that maybe the 
conflict of interests could be avoided, since the incentives seem to 
lead isps to attract traffic, otoh, if the end site pays flat rate, i 
can see an incentive for the isp to divert as much traffic as possible 
to the alternative isp.

regards, marcelo

>  Consider PPVPNs, for example.
>
> Of course, it is optional.  Having the ITR be the CE box (or one of 
> many) is also an viable alternative.
>
> Tony
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 8 Apr 2007 10:50:51 +0200

> A new protocol more optimized perhaps for flooding that has 

what is the motivation for a new protocol?

i mean, BGP does seem to provide what is needed, and it is well known 
by the community

do you think that BGP is lacking some of the required capabilities?

note that for globally distributing the ID to locator mapping 
information, you would just need to enable another instance of BGP with 
maybe some extensions, that would carry the id to loc mapping to all 
the routers running this new instance. I think that from a deployment 
perspective, this is much better than designing a new protocol, since 
it would only require configure existent routers (maybe some software 
patch) but not deploying a new protocol (I think this would go along 
with the general LISP policy of minor changes rather than new 
protocols, doesn't it?)

> policy out of it ;-) we can keep it easier

but probably the complex part of policy is to provide enough 
information and flexibility to allow for local configurations, so this 
needs to be build in the protocol from scratch, just as BGP has it.

> . Please note, this protocol would be there to distribute EID-RLOC 
> mappings and not the reachability status of the RLOCs.
>

of course, fully agree

 protocol?

i mean, BGP does seem to provide what is needed, and it is well known 
by the community

do you think that BGP is lacking some of the required capabilities?

note that for globally distributing the ID to locator mapping 
information, you would just need to enable another instance of BGP with 
maybe some extensions, that would carry the id to loc mapping to all 
the routers running this new instance. I think that from a deployment 
perspective, this is much better than designing a new protocol, since 
it would only require configure existent routers (maybe some software 
patch) but not deploying a new protocol (I think this would go along 
with the general LISP policy of minor changes rather than new 
protocols, doesn't it?)

> policy out of it ;-) we can keep it easier

but probably the complex part of policy is to provide enough 
information and flexibility to allow for local configurations, so this 
needs to be build in the protocol from scratch, just as BGP has it.

> . Please note, this protocol would be there to distribute EID-RLOC 
> mappings and not the reachability status of the RLOCs.
>

of course, fully agree

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 9 Apr 2007 10:44:54 +0200

> router), sends it on but also adds a request record for say a RLOC RR.

this basically means that:

- The router that will forward the packet should also be configured as 
the DNS server for those hosts that use such router to send packets to 
a given destination (i.e. the default router is also the DNS server) 
(this has some difficulties, because you would need to configure the 
DNS servers to different hosts depending on the default router they 
use.. in addition, more complexity will arise when you want to support 
fault tolerance when the default router fails)
- The router also needs a DNS alg, to interpret the DNS query sent by 
the host and create the additional DNS query to ask for the RLOC RR

right?

regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Apr 2007 07:58:28 -0700

> a given destination (i.e. the default router is also the DNS server)

That's right.
 
> use..

This isn't a problem if the host will always use the same
default router, e.g., when the default router is co-located
on the same physical platform as the host.

> in addition, more complexity will arise when you want 
> to support 

When the host and default router both reside on the same
physical platform, then there is no real point in worrying
about fault tolerance anyway. Hence, there is no additional
complexity.

> the host and create the additional DNS query to ask for the RLOC RR

I'm not sure that "DNS alg" is the right way to call it,
but it would appear as an ordinary DNS server to hosts on
the inside and as an ordinary DNS client to the network on
the outside.
 
> right?

Right, and this also goes with what Tony said about having
the ITR be co-located on the CE box.

Fred

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Apr 2007 16:35:10 +0200

> on the same physical platform as the host.

but you said in the previous mail that a platform could a site, like a 
plane

in this case, a platform can have multiple routers and running an IGP.
In the case that the the internal routing changes, then it is complex 
to make sure that the router is still the DNS server, if you see what i 
mean

> about fault tolerance anyway. Hence, there is no additional

maybe i don't understand what is your definition of platform

I am thinking that we are talking about a host in a site that is served 
by a set of routers, some of them doing the map and encap. In this 
case, the router doing the map and encap is also the DNS. If you have 
an IGP and dynamic routing, there is some compelxity added because of 
this requirement that the DNS server is colocated with the map and 
encap router AFAICT

> the inside and as an ordinary DNS client to the network on

right, but it must be able to interpret the DNS queries it receives and 
generate additional queries based on that. (in any case, i called this 
way in the P-shim6 proposal, but i may agree with you that this is not 
the best name)

Regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Apr 2007 09:01:45 -0700

> but you said in the previous mail that a platform could a 
> site, like a plane

Yes.

> in this case, a platform can have multiple routers and running an IGP.

Yes.

> to make sure that the router is still the DNS server, if you 

I am thinking that normal IGP routing occurs between
routers that are internal to a platform, and map&encaps
occurs at the platform boundary routers. If there are
multiple platform boundary routers, then there is a need
for coordination between the boundary routers. That is a
good reason to locate the map&encaps function as close to
the end user devices as possible; preferrably on the end
devices themselves.
 
> this requirement that the DNS server is colocated with the map and 

I am using the terms "platform" and "site" pretty much
synonymously, only that a platform is a special kind of site
that has "bounded" characteristics. By "bounded", I mean that
all nodes within a platform tend to stay connected and move
around together as a unit.

About sites, a plane is a site; a subnetwork within a plane
is also a site; an end user device within a subnetwork within
a plane is also a site.(Remember that an end user device can
also connect an arbitrarily-complex network, or contain an
arbitrarily complex network of internal virtual nodes.) As
someone once said (and as I have said on a number of occasions
w/o realizing it had already been said by others):

  "It's turtles all the way down".
 
Pushing the map&encaps function to the sites of finest
granularity possible (i.e., preferrably on the end user
devices themselves) addresses the issue of coordination
between multiple site border routers.
 
> way in the P-shim6 proposal, but i may agree with you that 

My knowledge of (P)shim6 is very limited; the name I have
been using is IPvLX.

Thanks - Fred

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 10 Apr 2007 18:14:21 +0200

El 10/04/2007, a las 18:01, Templin, Fred L escribió:

> for coordination between the boundary routers.

exactly, this is  one form of added complexity that i was mentioning

>  That is a

but then, you have an end host solution and this is not what we are 
looking for here AFAIU (we already have several of those, and they seem 
to lack something, hence here we are...)

> around together as a unit.

ok

> between multiple site border routers.

agree, but again, AFAIU, we are into router based solutions here.

regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Apr 2007 09:17:52 -0700

> to lack something, hence here we are...)

No; it is a router-based solution. That the router may
connect *very* closely to the end host is immaterial,
and AFAICT incremental deployment is already underway...

Fred

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Apr 2007 11:32:27 -0700

On Apr 10, 2007, at 9:14 AM, marcelo bagnulo braun wrote:

> looking for here AFAIU (we already have several of those, and they  
> seem to lack something, hence here we are...)

Just so that we're all on the same page, what is it that they are  
lacking?

My read is that they lack scalable manageability.  Putting a  
middlebox solution in place is not so much to shift the complexity  
off the hosts, but to centralize the management of the mechanisms,  
turning an O(n) problem into an O(1) problem.

Thus, pushing the heavy lifting to the host while centralizing the  
management should still be an acceptable strategy to folks.

Tony

---

From: Russ White <[email-masked]>
Date: Tue, 10 Apr 2007 14:48:54 -0400

> Just so that we're all on the same page, what is it that they are lacking?

I think the main objection will be on the management side of things....
OTOH, I think most of the host based solution objections presume
something like shim6, which is not the only possible host based solution.

IMHO, we should look at the full range of solutions on the host and in
the network, and try to understand the tradeoffs vis-a-vis the problem
(and maybe we actually need a problem statement someplace?).... I can
see a solution where you move DNS type services closer to the default
router, perhaps even into the default router (what, after all, is SAF
all about?), and using host based solutions to solve the rest of the puzzle.

:-)

Russ

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Tue, 10 Apr 2007 21:59:57 +0200

> Just so that we're all on the same page, what is it that they are  lacking?

yes this seems a good excersise

>
> My read is that they lack scalable manageability.

not sure i understand what you mean...

do you think that exposing n PA locators/addresses to end hosts is 
acceptable or this is part of the management problem (in the sense that 
you need to configure and manage n prefixes in every host)

i don't know if this is really a management problem since it seems easy 
to extend the autoconf mechanisms to configure n addresses instead of 1

I think that the problems may be that:
- once you expose the n locators to the host, you transfer to the hosts 
themsleves the part of the path selection, in particular the selection 
of the exit path/ingress path. this seems to change the power balance 
from todays situation. In particular, policing now is up the hosts. 
Note that it would be easy to define some automatic mechanism to 
distribute RFC3484 policy table through the hosts, but what it seems to 
be lacking is a central mechanism to _enforce_ that policy i.e. the 
final decision is still up to the end hosts.

Besides, exposing n locators to the multihomed site allow the end site 
to have much more control on what path to use for a given packet and 
the ISPs cannot longer influence the path of packets tunning BGP. So 
again, here there is a change in the power balance, from the isps to 
the end site.

So, i see that there are two changes in the balance of power:
- the hosts have the decision of what exit path to use for their 
packets and there is no centralized way to enforce site wide policy
- the site has tighther control on the path used for its packets and 
the ISPs have less control on the traffic of their multihomed customers

finally, if you expose the n locators/addresses to the hosts, you 
increase provider captivity, since you increase the cost of renumbering

So, for me, they key issue is whether the hosts are configured with the 
n PA locators or not.
If the n prefixes are in reduced set of boxes, then, these boxes have 
the power to control the locators, hence they can enforce the policy.

So probably, if we want to explore other part of the solution space 
different than previous solutions, we should limit ourselves to 
solutions that do not expose n PA prefices to the hosts and only a 
limited set of boxes have the PA address information.

regards, marcelo

>  Putting a  middlebox solution in place is not so much to shift the 
> complexity  off the hosts, but to centralize the management of the 
> mechanisms,  turning an O(n) problem into an O(1) problem.
>

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Apr 2007 13:24:00 -0700

> acceptable or this is part of the management problem (in the sense  
> that you need to configure and manage n prefixes in every host)

Yes, that's part of the management problem.  I think that most folks  
are trying to get *away* from managing individual hosts, just so we  
don't turn entire city-sized populations into sysadmins.

> i don't know if this is really a management problem since it seems  
> easy to extend the autoconf mechanisms to configure n addresses  
> instead of 1

Yes, you could do that, but then there's policy on top of that, as  
you write below.

> - once you expose the n locators to the host, you transfer to the  
> hosts themsleves the part of the path selection, in particular the  
> selection of the exit path/ingress path. this seems to change the  
> power balance from todays situation. In particular, policing now is  
> up the hosts. Note that it would be easy to define some automatic  
> mechanism to distribute RFC3484 policy table through the hosts, but  
> what it seems to be lacking is a central mechanism to _enforce_  
> that policy i.e. the final decision is still up to the end hosts.
>
> Besides, exposing n locators to the multihomed site allow the end  
> site to have much more control on what path to use for a given  
> packet and the ISPs cannot longer influence the path of packets  
> tunning BGP. So again, here there is a change in the power balance,  
> from the isps to the end site.
>
> - the site has tighther control on the path used for its packets  
> and the ISPs have less control on the traffic of their multihomed  
> customers

Yup, those are the management problems that I was getting at.  I'm  
more concerned about the former than the latter.

> increase provider captivity, since you increase the cost of  

I'm not really buying that.  It seems that if you have autoconf  
mechanisms in place, the costs of adding or changing locators should  
be incremental.

> So, for me, they key issue is whether the hosts are configured with  
> the n PA locators or not.
> If the n prefixes are in reduced set of boxes, then, these boxes  
> have the power to control the locators, hence they can enforce the  
> policy.
>

By your analysis above, this seems overly restrictive.  Shouldn't we  
bound the solution space by the manageability concerns?  If there was  
a solution that did distribute PA prefixes but retained centralized  
path control, wouldn't that be acceptable?

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2007 09:20:42 +0200

> and AFAICT incremental deployment is already underway...

One of the trickiest problems we saw in the shim6 variant
of this is exit router selection, when different routers
are connected to different ISPs. That breaks any 1:1
relationship between hosts and exit routers, and pretty
much requires some additional mechanism.

I think that has to be added to the list of management
gaps.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Apr 2007 02:05:02 -0700

Sorry for the delay on this response.

>>>> You are right non Marcelo. I think taking the high-road by doing  
>>>> a LISP-push model gives you the best of all worlds.
>>>
>>> by push model, we are talking about destributing the ID to  
>>> locator mapping database to all LISP routers?
>>

I mean a set of routers at the highest level of a hierarchy.

> but the ITR are the ones than need the information (hence the ones  
> that should have it), right?
>
> Of course, in addition, routers making TE would also benefit from  
> it, so it makes sense to pass it to them also (but they are ITRs  
> after all, right?)

If they have the storage capacity sure, but when they don't they have  
to be cache based and send queries for the mapping they need. There  
are only two ways to do this.

> what is the motivation for a new protocol?

Because there isn't anything out there that can flood (without doing  
other things) as well as authenticate bindings.

> i mean, BGP does seem to provide what is needed, and it is well  
> known by the community

Every BGP router may not be an ITR/ETR or high-level router. So you  
are storing the information in places you don't need it. That means  
everyone is paying the cost.

If we are worried about power, FIB size and line-card costs, we need  
to move this state to the edges in lesser expensive memories.

> do you think that BGP is lacking some of the required capabilities?

Yep. Plus it has more than we want. And many have shown that BGP is  
not an efficient flooding protocol.

> information, you would just need to enable another instance of BGP  
> with maybe some extensions, that would

That was a possibility we considered with LISP 1.5. That is, to  
change less protocols and have a non-topological aggregation benefit  
as Vince has outlined a number of times.

> carry the id to loc mapping to all the routers running this new  
> instance. I think that from a deployment perspective, this is much  
> better than designing a new protocol, since it would only require  
> configure existent routers (maybe some software patch) but not  
> deploying a new protocol (I think this would go along with the  
> general LISP policy of minor changes rather than new protocols,  
> doesn't it?)

A new protocol can start simple. We made this decision with MSDP. We  
decided it was better to not put the frequency of multicast source  
discovery in BGP, and I stand by that decision today being a good one.

BGP already does too many things. And if you want to tweak it to  
optimize one thing it may have negative effect on other things.

>>> very interesting imho, but i guess some people though they were  
>>> too complex
>>
>> We can start simple. This doesn't need to be complex and if we  
>> keep policy out of it ;-) we can keep it easier
>
> information and flexibility to allow for local configurations, so  
> this needs to be build in the protocol from scratch, just as BGP  
> has it.

Not convinced yet the policy has to be as advanced as BGP.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Apr 2007 11:35:35 +0200

> mechanisms in place, the costs of adding or changing locators should 

but the problem is not changing the IP configured in interfaces, 
because, you can use autconf mechanims

The problem is that PA addresses, if exposed to the intra site domain, 
may end up in various configurations, like filters, ACL applications 
and so on. There seems to be little chance that there will be automatic 
autconf for these other usages.

So, i would say that one option to get rid of PA addresses is just to 
avoid having them present in the intra domain

I know it may be overly restricitve as you mention, but this seems to 
clearly solve all these problems. BAsically, these seems to be one of 
the advantages that people find in NAT, so maybe it would be a good 
approach try to keep such feature while solving the problems of NAT 
(like restoring the end to end identifier seen by the endpoints)

> path control, wouldn't that be acceptable?

i guess so, if you include in management centralized path control (and 
enforcement), avoiding provider captivity. Another issue that comes 
into play here, is the deployment phase i.e. how do deal with 
hosts/sites that do not support the new protocol and only run legacy 
IP.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Apr 2007 11:58:23 +0200

El 11/04/2007, a las 11:05, Dino Farinacci escribió:
>> so it makes sense to pass it to them also (but they are ITRs after 
>> all, right?)
>

so are you envisioning an hybrid system that has both the push and pull 
models? In such scheme there would be these mesh of high level routers 
that exchange the whole loc id mapping database and then smaller 
routers that use the pull model to query these high level routers?

the new protocol would then run between these high level routers, is 
that it?

> to move this state to the edges in lesser expensive memories.

i think i didn't explained myself properly

I am not saying to use the BGP instance used today to exchange routing 
information to also exchange loc/id mapping information.

What i am saying is using the BGP protocol for that, meaning to create 
a _new_ instance of BGP and run it for instance between the high level 
routers that you mention above. In this case, these high level routers 
would run two instances of BGP. On instance of BGP, that would 
distribute routing information as it is done today. Another instance of 
BGP would be used to distribute the id loc mapping information

> not an efficient flooding protocol.

i don't know about that... i mean, BGP as a protocol seems to be quite 
simple and eficient and it is already out there

I mean, i do agree that BGP does provide some features that may not be 
needed for an id loc mapping protocol, but i am not sure this 
outwiegths the benefits of being a protocol already available in 
deployed routers

> That was a possibility we considered with LISP 1.5.

i don't think this is similar than LISP 1.5, please see below...

>  That is, to change less protocols and have a non-topological 
> aggregation benefit as Vince has outlined a number of times.
>

I am not saying to overload BGP with additional information, but to run 
a different instance of BGP to distribute other information. It is 
similar to the considerations being made about the differences between 
the DNS protocol and the DNS system. I am not proposing to use current 
BGP system (the instace of BGP used to currently distribute routing 
information) but to build another instance of the BGP protocol to 
distribute the id loc mapping information. Re use the BGP protocol not 
the current BGP routing system

>> this needs to be build in the protocol from scratch, just as BGP has 
>> it.
>

policy seems to be one of the key features that are missing in 
available solutions, so i  would put quite some focus on that

Regards, marcelo

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Apr 2007 03:00:55 -0700

> So, i would say that one option to get rid of PA addresses is just  
> to avoid having them present in the intra domain

Well the thought for LISP was to have the ETRs be the only routers in  
the domain to have global routable PA addresses assigned to their  
loopback interfaces. All other interface addresses can be link-local  
(for IPv6) or private addresses (for IPv4). With the added benefit of  
protecting your router resources at your site because they are not  
routable (so no one from outside can direct packets to them).

The same would be true if you used PI addresses at the site which  
were not injected into  the BGP core (not routable).

And actually, as deployed today, the ETR addresses that are part of  
PA space could be the only locators advertised in the core today and  
all other PA addresses from the course block *would not* have to be  
advertised. So if you advertise a single /24 today into the core, you  
*could* instead advertise a single /30 and protect your other routers  
the same you would do with the above two other addressing cases. The  
ISP aggregation of such site blocks would not have to change.

Comments about this to the operators lurking in on this list?

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Apr 2007 12:22:59 +0200

El 11/04/2007, a las 12:00, Dino Farinacci escribió:

> loopback interfaces.

yes i like this clean separation
i would like to explore more what are the results of taking this 
approach of leaving the PA (topology dependent) addresses outside the 
site

> All other interface addresses can be link-local (for IPv6)

or even better ULAs (i guess they were defined for that)

>  or private addresses (for IPv4). With the added benefit of protecting 
> your router resources at your site because they are not routable (so 
> no one from outside can direct packets to them).
>
> The same would be true if you used PI addresses at the site which were 
> not injected into  the BGP core (not routable).
>
> And actually, as deployed today, the ETR addresses that are part of PA 
> space could be the only locators advertised in the core today and all 
> other PA addresses from the course block *would not* have to be 

agree with this approach

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Apr 2007 12:45:52 +0200

> or even better ULAs (i guess they were defined for that)

Definitely. That way they can be used in site-wide MIBs
and config scripts (and there is no pesky id-loc split for
site operations people to be confused by).

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Apr 2007 09:35:16 -0700

Brian,

> much requires some additional mechanism.

Isn't this pretty much the same issue as what if there are
multiple NATs and/or multiple stateful firewalls at the site
border? The issue then becomes one of how to coordinate the
stateful site border devices, since state has to be shared
among them.

Is this a solved problem?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Apr 2007 09:36:05 -0700

> (for IPv6) or private addresses (for IPv4).  

Sounds like there is some agreement here, and the same
is true for ISATAP and IPvLX also.

Fred

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 11 Apr 2007 18:56:26 +0200

> stateful site border devices, since state has to be shared

i guess that the difference here is that we are actually designing a 
fault tolerance solution, so it is a non starter if you introduce a 
single point of failure, meaning that any solution must provide this 
capability from the start (which is not the case of NAT and firewalls)

> Is this a solved problem?

I have tried to provide such support in the proxy-shim6 approach, but 
it does introduce additional complexity

In particular, you need to be capable of restoring the ID to locator 
mapping information in the backup box, which implies or either that you 
distribute the id loc mapping information about all ongoing 
communications from the primary box to all backup boxes when the 
communication starts or that you have a mechanism to restore such 
information when the primary is down. Such mechanism for restoring the 
information should provide the means to retrieve the locators 
associated to the destiantion identifier

Regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Apr 2007 10:14:27 -0700

Comment inline below: 

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Wednesday, April 11, 2007 9:56 AM
> To: Templin, Fred L
> Cc: Brian E Carpenter; [email-masked]
> Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP
> 
> 

But, the further out toward the edges we locate the ITR the
more it becomes a fate-sharing situation, e.g., the ITR is
available IFF the physical platform itself is still intact.
The physical platform could then still be multihomed (perhaps
even to many different providers) but the appearance to nodes
on the inside looking for a way out would be as a single ITR.
 
> associated to the destiantion identifier

If there is no way to ensure that the host will always stick
with the same ITR (which I'm not yet convinced of), then it
would have to be something like a site-local resolution
service keyed off the destination IP address, right?

Fred

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Apr 2007 12:18:45 -0700

> so are you envisioning an hybrid system that has both the push and  
> pull models? In such scheme there would be these mesh of high level  
> routers that exchange the whole loc id mapping database and then  
> smaller routers that use the pull model to query these high level  
> routers?

Yes, I think something like that.

> the new protocol would then run between these high level routers,  
> is that it?

Yes, which will be trusted. As well as having a registration  
procedure that is pub/priv key protected for the ETRs to register EID- 
to-RLOC mappings.

I think we have a good demarcation design where the LISP-00 ID can  
use various means to obtain the mappings. I can see any or all of the  
following:

o Static
o ICMP
o DNS
o Push-only
o Push-n-pull
o Pull with new database

We can try them all out and start pruning what we think we don't  
like. But the pruning happens after *implementation*. That is we  
obtain rough consensus and running code.  ;-)  I think I heard that  
once before.  ;-)

It would be really nice if folks on this list could pick one to focus  
on. You can use me as a focal point so we don't duplicate effort.

Whadaya think?

> I am not saying to use the BGP instance used today to exchange  
> routing information to also exchange loc/id mapping information.

Yes, I understood what you said. And I realize this new instance  
would carry less stuff.

> What i am saying is using the BGP protocol for that, meaning to  
> create a _new_ instance of BGP and run it for instance between the  
> high level routers that you mention above. In this case, these high  
> level routers would run two instances of BGP. On instance of BGP,  
> that would distribute routing information as it is done today.  
> Another instance of BGP would be used to distribute the id loc  
> mapping information

Yes, and there could be a good possibility that any given router may  
not run both instances. We might want to make that a goal. Definitely  
at the high-level system deployment (note I didn't say routers,  
because we could have low-cost, fast, linux systems do this).

>> Yep. Plus it has more than we want. And many have shown that BGP  
>> is not an efficient flooding protocol.
>>
>
> i don't know about that... i mean, BGP as a protocol seems to be  
> quite simple and eficient and it is already out there

We would have to turn off best-path selection. Many attributes  
wouldn't apply to this new NLRI type, etc.

> I mean, i do agree that BGP does provide some features that may not  
> be needed for an id loc mapping protocol, but i am not sure this  

Marcelo, I think it's definitely something to consider. I don't want  
to give the wrong impression I'm against BGP.

>>> information, you would just need to enable another instance of  
>>> BGP with maybe some extensions, that would
>>

I know, because we wouldn't be routing EIDs. But if we didn't want to  
drop packets in the ITR, the ITR could encapsulate to one of the high- 
level routers that would have the mapping and then it would "re- 
encapsulate" (versus recursive encapsulate as the LISP ID states) to  
the site's ETR.

This increases stretch that we *could* stick with, or the ETR could  
send the mapping to the ITR via an ICMP EID-to-RLOC Reply.

I really think we have a lot of options (maybe too many ;-)).

> I am not saying to overload BGP with additional information, but to  
> run a different instance of BGP to distribute other information. It  
> is similar to the considerations being made about the differences  
> between the DNS protocol and the DNS system. I am not proposing to  
> use current BGP system (the instace of BGP used to currently  
> distribute routing information) but to build another instance of  
> the BGP protocol to distribute the id loc mapping information. Re  
> use the BGP protocol not the current BGP routing system

Yes, understand. Lixia made the same suggestion using the DNS  
protocol. That is use DNS the protocol as your query/reply protocol  
but don't run it on UDP 53.

But I have to beg the question, why people think this is the long  
pole in the tent? That is designing a straight-forward protocol  
shouldn't be hard or time consuming.

> available solutions, so i  would put quite some focus on that

Well I was thinking of access control. But in terms of locator  
selection, that is where I think there needs to be focus. Can you  
tell me if what LISP proposes with using priorities and weights per  
locator is not sufficient. It should be familiar to you. ;-)  And I  
did run it by both large-site enterprise types and ISP types.

Thanks,
Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Apr 2007 13:11:33 -0700

Dino,
 
> It would be really nice if folks on this list could pick one 
> to focus on.

Earlier on, you seemed skeptical of DNS but so far that
seems to be the one folks are most interested in discussing.
DNS+static should also be considered, though, since resolvers
can be pre-populated by network management, manual config, etc.
(Oh - and, please don't forget IPvLX.)

Thanks - Fred

---

From: Peter Schoenmaker <[email-masked]>
Date: Wed, 11 Apr 2007 20:01:12 -0400

On Apr 11, 2007, at 6:00 AM, Dino Farinacci wrote:

> Well the thought for LISP was to have the ETRs be the only routers  
> in the domain to have global routable PA addresses assigned to  
> their loopback interfaces. All other interface addresses can be  
> link-local (for IPv6) or private addresses (for IPv4). With the  
> added benefit of protecting your router resources at your site  
> because they are not routable (so no one from outside can direct  
> packets to them).
>
> PA space could be the only locators advertised in the core today  
> and all other PA addresses from the course block *would not* have  
> to be advertised. So if you advertise a single /24 today into the  
> core, you *could* instead advertise a single /30 and protect your  
> other routers the same you would do with the above two other  
> addressing cases. The ISP aggregation of such site blocks would not  
> have to change.
>

I hope ultimately customers use PI addresses that are not injected  
into the BGP core.  This seems like the ultimate solution, to give  
every host a unique identifier.  link-local/private addresses are  
only an interim step.

peter

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Apr 2007 15:08:08 -0700

> (Oh - and, please don't forget IPvLX.)

I still think it is not architecturally good from for routing to  
depend on DNS-53. That is, adding new RR records to the existing DNS  
infrastructure to support a Loc/ID split. Plus, you will need to  
secure EID-to-RLOC mappings. The DNSSEC RFC indicates that KEY RR  
records are for securing DNS proper and not for securing other  
protocols.

Using DNS as a request/reply protocol is fine. But there isn't much  
to it and we could do our own request/reply protocol.

To follow your line of thinking, which has been suggested by a few  
folks is to:

o Point hosts to routers who are DNS-53 servers.
o When the A record reply is returned to the router, it can use the A  
record as
   an EID query to another database.
o When the RLOC comes back, the router returns the DNS response to  
the host.
o The host emits packet to A record, the router has mapping for it  
and can
   encapsulate to the RLOC.

But not everything uses DNS! Don't forget SIP, don't forget debug  
tools people use with IP and IPv6 addresses only and no names.

So I wouldn't want to have a mechanism for every type of application  
directory service we have. Other examples of directory services is  
AIM, Skype, and BitTorrent, which are very application specific.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Apr 2007 15:18:46 -0700

> In particular, you need to be capable of restoring the ID to  
> locator mapping information in the backup box, which implies or  
> either that you distribute the id loc mapping information about all  
> ongoing communications from the primary box to all backup boxes  
> when the communication starts or that you have a mechanism to  
> restore such information when the primary is down. Such mechanism  
> for restoring the information should provide the means to retrieve  
> the locators associated to the destiantion identifier

The way we spec'ed this in the LISP draft is to have both ETRs  
configure the IP addresses of all loopback addresses among them. So a  
packet that enters one of them can respond with an ICMP reply for all  
locators. On packet egress from the site, the chosen exit ITR would  
do the mapping independently of the other. So there is no need for  
synchronization.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Apr 2007 11:27:30 +0200

> on the inside looking for a way out would be as a single ITR.

i am not following you...
The whole point of a multihoming solution is to be able to connect to 
multiple providers and provide fault tolerance. The actual difficullt 
part is to preserve established communications after an outage, when a 
different ISP is used

So i don't think we are in a fate sharing situation

actually, i would expect that in a site/platform there will be multiple 
ITRs connecting to different ISPs and that communication must be 
preserved if the ITR used for the communication goes down and the 
communication is rerouted through an alternative ITR and ISP

I think that any solution must not introduce any new single point of 
failures.

> service keyed off the destination IP address, right?

this in one option, since you need to restore state that was already 
available in the site, so you can have it replicated at the momento of 
the creation of the state. the other option is to allow to restore the 
information retrieving the information from outside the site (from 
where it came initially)

the benefit of the second approach is that if you already need a 
service to retrieve the ID loc mapping information, you can use it as 
well to support this, so you don't need additional intra site 
replicating services/protocols

but both approaches are possible, afaict

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Apr 2007 12:00:05 +0200

El 11/04/2007, a las 21:18, Dino Farinacci escribió:

> Yes, which will be trusted. As well as having a registration procedure 
> that is pub/priv key protected for the ETRs to register EID-to-RLOC 
> mappings.
>

So are you using a trust model that is based on a closed set of 
participants that trust each other rather than a mean to certify that 
the actual information about binding is correct?

> I think we have a good demarcation design where the LISP-00 ID can use 
> various means to obtain the mappings. I can see any or all of the 
> following:
>
> o Static

i don't think we should preclude this one, but i don't think it is 
general enough to solve our problems (i would leave it as a corner case 
for testing and exceptions)

> o ICMP

My take on this one is that much needs to change from its current form 
to be secured. In particular you will need a few more message exchange 
to achieve this.

Besides, you need a valid ID to locator mapping (with at least one 
working locator) to actually send the initial request, so this needs to 
be complemented with an additional mechanism. In LISP 1, the mechanism 
is the identity, since the identifier is also a valid locator.
In HIP is the DNS, where you can obtain the locators and the identifier 
from the DNS query (note that this requires a fqdn, since there is no 
id to locator mapping service)
In shim6, is both of them

> o DNS

not sure what do you mean here...

the DNS as used in HIP? i.e. using the DNS to obtain both the 
identifier and the locator set associated to a fqdn
or the DNS system to retrieve identifier to locator mapping, like for 
instance using ULAs as identifiers and using the DNS reverse tree entry 
for the ULA for retrieving the locators associated with this 
identifier?

the DNS as a generic protocol independent of the current DNS system to 
make a directory service for retrieving Id to locator mapping?

In any case, in order to answer this question, i guess that an 
important previous question is how do you think the identifier 
namespace will be? I mean, it seems that DNS type of approach will not 
scale to support an 128 bit unstrucutred identifier namespace. OTOH, if 
you are thinking of using ULAs or PI addresses as identifier, then this 
may work

> o Push-n-pull

i like your argument that it is good not to require every ITR to have 
the full database, even in a push model. I think we should continue 
exploring this solution space

> o Pull with new database

again, i think this is closely related with the characteristics of the 
identifier namespace. If we have an existnet protocol like the DNS that 
can provide this feature, i don't see the need for this.

> We can try them all out and start pruning what we think we don't like. 
> But the pruning happens after *implementation*. That is we obtain 
> rough consensus and running code.  ;-)  I think I heard that once 
> before.  ;-)
>
...
> to give the wrong impression I'm against BGP.

maybe the push and pull approach could be based on BGP+DNS...

> drop packets in the ITR, the ITR could encapsulate to one of the 
> high-level routers that would have the mapping and then it would 
> "re-encapsulate" (versus recursive encapsulate as the LISP ID states) 
> to the site's ETR.
>

something similar like a default route for EIDs?

you may end up with a similar concept of the DFZ but for routers that 
know how to map identifiers...

> send the mapping to the ITR via an ICMP EID-to-RLOC Reply.

yes, i think this additional stretch could be acceptable for a few 
initial packets

>> distribute routing information) but to build another instance of the 
>> BGP protocol to distribute the id loc mapping information. Re use the 
>> BGP protocol not the current BGP routing system
>
> But I have to beg the question, why people think this is the long pole 
> in the tent? That is designing a straight-forward protocol shouldn't 
> be hard or time consuming.

imho, established well known protocols that have already been tested 
and are stable are better choice than new protocols, that need to 
mature. Of course, this only if we don't overload existent usages. For 
that reason, i think that if we can reuse the protocol but maybe not 
the actual current system, seems the best tradeoff (of course if the 
protocols do provide the required functionality, which is not at all 
clear yet)

> selection, that is where I think there needs to be focus. Can you tell 
> me if what LISP proposes with using priorities and weights per locator 
> is not sufficient.

I would like isps and end site users to reply to this

i mean having a draft describing the needs in term of policy and TE 
from mutlihomed end sites and isps would be a great help in order to 
design a solution that suit their needs...

Regards, marcelo

>  It should be familiar to you. ;-)  And I did run it by both 
> large-site enterprise types and ISP types.
>
> Thanks,
> Dino
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Apr 2007 12:07:01 +0200

El 12/04/2007, a las 0:08, Dino Farinacci escribió:

> Using DNS as a request/reply protocol is fine. But there isn't much to 
> it and we could do our own request/reply protocol.
>
> o When the RLOC comes back, the router returns the DNS response to the 
> host.
> o The host emits packet to A record, the router has mapping for it and 
> can
>   encapsulate to the RLOC.
>

> tools people use with IP and IPv6 addresses only and no names.

yes i agree

imho, what you described above is an optimization for a very common case

but you need to cope with the  general case when packets passing by the 
ITR are not preceeded by a DNS query which AFICT can happne in at least 
4 situations:
- when the host is not using the DNS and it uses directly ip addresses
- when the cache of the ITR was cleaned but the host still caches the 
id asocicated to a fqdn
- referrals and callbacks
- when the communication is rerouted because of a failure thorugh an 
alternative router that is different to the one that made the initial 
resolution

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 12 Apr 2007 12:15:10 +0200

El 12/04/2007, a las 0:18, Dino Farinacci escribió:

>> mapping information in the backup box, which implies or either that 
>> you distribute the id loc mapping information about all ongoing 
>> information when the primary is down. Such mechanism for restoring 
>> the information should provide the means to retrieve the locators 
> locators. On packet egress from the site, the chosen exit ITR would do 
> the mapping independently of the other. So there is no need for 
> synchronization.
>

i don't understand this...

i have sent this question a while ago that described this exact 
situation, maybe you can describe how LISP deals with this 
situation....

I assume we are using LISP1

Consider that we have a host A in a site a that has EID EIDA (which is 
globally routable in order to be able to bootstrap the initial 
EID-to-RLOC mapping) and RLOCA which is a different address. Suppose 
that site

We have another host B located in a different site b that has a another 
locator RLOCB. Suppose that both site a and site b has multiple ISPs 
(at least two and they have several TR, for fault tolerance reasons)

Suppose now that host B initiates a communication with Host A

Host B sends a packet to host A
The packet contains EIDA as dest add and EIDB as src addr
The packet is processed by an ITRB1 close to site b
Since we are in LISP1, the packet is forwarded as it is

the packet reaches the ETRA1 close to site a and the ETR sends a ICMP 
packet back to the ITRB1 with the RLOCA information and the mapping 
between EIDA and RLOC is stored in ITRB1.

Now bad things start :-)

First there is a failure and EIDA is no longer reachable
No problem with that, since ITRB1 has the information about alternative 
locators for host A, it will start sending tunneled packets using RLOCA 
as dest address in the outer header and the communication is preserved 
through this outage.

However, now a second bad thing happens, which is that ITRB1 fails

I assume that it is possible in LISP, that an alternative ITR ITRB2 is 
used for site B, so packets are rerouted to that backup ITRB1 for site 
b.

But the problem is that packets that host b is sending contain EIDA as 
destiantion address which is unfortunatelly unreachable at this time. 
this was not a problem before because ITRB1 had the alternative locator 
information, but it has failed. The backup router ITRB1 does not 
contain the alternative locator information for EIDa (i.e. RLOCA), so 
how can the communication survive this outage?

I mean, i guess that fault tolerance is the key feature and the LISP 
boxes cannot become a single point of failure, so i guess it should be 
possible to survive this type of situations

regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Apr 2007 09:19:27 -0700

Marcelo,

> information retrieving the information from outside the site (from 

What about the possibility of having the host stick with
the same ITR it chose to do the mapping on a per-session
basis? That way, if the ITR fails then the sessions in
progress via that ITR fail, but new sessions can choose
alternate ITRs.

If that seems too onerous, then we have the requirement to
restore state via either site-local information or global
information. But, in the case of DNS, would restoring state
via global information require a fully-populated in6.arpa?
Seems like a dead end in terms of scalability, doesn't it?

Fred

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Apr 2007 21:27:51 -0700

>>> so are you envisioning an hybrid system that has both the push  
>>> and pull models? In such scheme there would be these mesh of high  
>>> level routers that exchange the whole loc id mapping database and  
>>> then smaller routers that use the pull model to query these high  
>>> level routers?
>>
>> procedure that is pub/priv key protected for the ETRs to register  
>> EID-to-RLOC mappings.
>>
>
> participants that trust each other rather than a mean to certify  
> that the actual information about binding is correct?

Yes.

>> use various means to obtain the mappings. I can see any or all of  
>> the following:
>>
>> o Static
>
> general enough to solve our problems (i would leave it as a corner  
> case for testing and exceptions)

May be adequate in TE-ITRs.

>> o ICMP
>
> My take on this one is that much needs to change from its current  
> form to be secured. In particular you will need a few more message  
> exchange to achieve this.

I realize that. That we can fix. Not worried about it too much.

> working locator) to actually send the initial request, so this  
> needs to be complemented with an additional mechanism. In LISP 1,  
> the mechanism is the identity, since the identifier is also a valid  
> locator.

I don't understand your point here.

> or the DNS system to retrieve identifier to locator mapping, like  
> for instance using ULAs as identifiers and using the DNS reverse  
> tree entry for the ULA for retrieving the locators associated with  
> this identifier?

The way we have been talking about it. Using DNS store mappings.

> the DNS as a generic protocol independent of the current DNS system  
> to make a directory service for retrieving Id to locator mapping?

Right.

> namespace will be? I mean, it seems that DNS type of approach will  
> not scale to support an 128 bit unstrucutred identifier namespace.  
> OTOH, if you are thinking of using ULAs or PI addresses as  
> identifier, then this may work

What will? 128-bits is a lot of addresses. Shouldn't even try.

>> o Push-only
>> o Push-n-pull
>
> i like your argument that it is good not to require every ITR to  
> have the full database, even in a push model. I think we should  
> continue exploring this solution space

Okay, sounds good.

>> o Pull with new database
>>
>
> again, i think this is closely related with the characteristics of  
> the identifier namespace. If we have an existnet protocol like the  
> DNS that can provide this feature, i don't see the need for this.

How you pull and what you pull don't have to be related. I personally  
like prefixes where the size of the prefix is based on the number of  
systems you need assign IDs to.

> maybe the push and pull approach could be based on BGP+DNS...

Could.

>> I know, because we wouldn't be routing EIDs. But if we didn't want  
>> to drop packets in the ITR, the ITR could encapsulate to one of  
>> the high-level routers that would have the mapping and then it  
>> would "re-encapsulate" (versus recursive encapsulate as the LISP  
>> ID states) to the site's ETR.
>>
>

Yes, I think it is very likely that many ITRs (for ease of  
management) will have a single EID entry that looks like this:

	0.0.0.0/0 -> {locator1, locator2}

> you may end up with a similar concept of the DFZ but for routers  
> that know how to map identifiers...

Right.

>> This increases stretch that we *could* stick with, or the ETR  
>> could send the mapping to the ITR via an ICMP EID-to-RLOC Reply.
>>
>

It's the price to pay for scaling.

>> protocol. That is use DNS the protocol as your query/reply  
>> protocol but don't run it on UDP 53.
>>
> imho, established well known protocols that have already been  
> tested and are stable are better choice than new protocols, that  
> need to mature. Of course, this only if we don't overload existent  
> usages. For that reason, i think that if we can reuse the protocol  
> but maybe not the actual current system, seems the best tradeoff  
> (of course if the protocols do provide the required functionality,  
> which is not at all clear yet)

I've seen it good and bad both ways. But I have found you take the  
good from the past and leave the bad in the past.  ;-)

> from mutlihomed end sites and isps would be a great help in order  
> to design a solution that suit their needs...

Good idea. Let's see if I can draft some people.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Apr 2007 13:14:53 +0200

> progress via that ITR fail, but new sessions can choose

this would be much easier problem to solve and would deal with many 
common situations. But for the last few years, the focus of the work on 
multihoming seemd to be preserving established communications through 
outages (since this is provided by current bgp based multihoming 
solution)

so, i am assuming that this is still a required capability. If this is 
not the case, then we have a much wider range of approaches that are 
acceptable

> via global information require a fully-populated in6.arpa?

well, fully populated for those who have eid that differ from locators 
(or with multiple locators)

> Seems like a dead end in terms of scalability, doesn't it?

why do you say this?
from the figures that D. Conrad send to ml about the current number of 
entries in the DNS, the system seems to scale pretty well and doesn't 
seem to be having big problems to deal with the current size...

but maybe some DNS experts could comment on this one...

Regards, marcelo

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 13 Apr 2007 10:35:34 -0700

Dino,

> It reduces the unicast FIB. 

Any *empirical* evidences to support the above claim would be greatly
appreciated.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 13 Apr 2007 10:38:27 -0700

Dino,

> It reduces the unicast FIB. 

Does that mean that the size of RIB is not a problem ?

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2007 10:44:22 -0700

> Any *empirical* evidences to support the above claim would be greatly

The point is that the PI prefixes which are in the core today can be  
removed because they will be routed on another, smaller topology, to  
be used to probe for locator replies.

So there is evidence that if you use the "no network <prefix>"  
command in BGP, the neighbor router does not store <prefix> in it's  
RIB or FIB. Therefore there is a reduction.

> Does that mean that the size of RIB is not a problem ?

Less is always better from many perspectives.

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 16 Apr 2007 05:36:15 -0700

Dino,

> be used to probe for locator replies.

Would that still reduce the unicast FIB on the routers that participate
in the "smaller topology" ?

Yakov.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Apr 2007 06:32:42 -0700

I am wondering where 6to4 fits on the LISP continuum.
Correct me if I am wrong, but with 6to4 the identifer
to locator mapping comes from a single DNS lookup. The
identifer is not routeable over the core, but the ETR
locator is embedded in the identifier address so the
ETR discovery comes "for free".

Is 6to4 an example of LISP 2? Is it good enough to be
considered as a long-term solution, or is it just a
baby-step to a fully jacked-up LISP deployment?

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Apr 2007 16:59:42 +0200

On 2007-04-16 15:32, Templin, Fred L wrote:
> Is 6to4 an example of LISP 2? 

Well, it was conceived rather differently, on a model
where there is exactly one IPv4 core, exactly one native
IPv6 cloud, and a large number of IPv6 islands wishing to
communicate with the IPv6 cloud over the IPv4 core.

If you use it otherwise, it is not a method that will
limit expansion of the IPv6 DFZ, and it does absolutely
nothing for the IPv4 DFZ.

> Is it good enough to be

I'd rather view it as a subversive technology that
has a finite scope of applicability. Of course, within
that scope, the 6to4 mapping is a perfectly fine one
for an IPv6-over-IPv4 implementation of LISP. But I
doubt it can be the only mapping in use.

      Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Apr 2007 08:22:58 -0700

Brian,

> has a finite scope of applicability.

I was somewhat surprised to see the word "subversive" here,
but that would be consistent with my emerging understanding
of how new Internet architectures move forward (or don't).

Can we count on Microsoft Vista and others to be vehicles
for carrying new Internet architectures forward?

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Apr 2007 09:09:44 -0700

> in the "smaller topology" ?

It could a bit because of the better aggregation. But, again, the  
result is a smaller FIB in more routers. Only the LISP routers will  
have the same or smaller FIB than a core router. Plus, if the FIB is  
on-demand, then the size is based on current usage.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Apr 2007 09:28:07 -0700

> I am wondering where 6to4 fits on the LISP continuum.

Well, it can work serially. Here is the scenario I am referring to:

o An IPv6 packet is received by an ITR.
o The DA is an EID so a mapping lookup is done to yield a locator in  
the 2002::/16
   range.
o The ITR prepends a IPv6 header.
o The platform specific code in the router will try to resolve a next- 
hop and find
   out there is no IPv6 next-hop for the outer DA. So it resolves the  
address to
   an IPv4 address which follows the 2002 bits. The ITR prepends an  
IPv4 header.
o The ITR sends the packet out the interface where the IPv4 DA is  
resolved to.

> ETR discovery comes "for free".

The EID in DNS could be a 2002::/16 prefix, but it shouldn't assume  
the address
itself or the IPv4 embedded in it is routable.

> Is 6to4 an example of LISP 2? Is it good enough to be

Well you can put 2002 addresses in DNS. So from a LISP point of view,  
it just a
mapping lookup on a string of bits.

> baby-step to a fully jacked-up LISP deployment?

If you used IPv6 addresses as EIDs and IPv4 addresses as locators,  
then the 6to4 step would be an extra one you would not need. And I  
wouldn't want to use it because it adds an additional 20 bytes to the  
packet (as described from the sequence above).

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 15 Apr 2007 00:41:31 +0200

>> the actual information about binding is correct?

but considering current BGP attacks, this model seems to have serious 
limitations, especially, if you want to have a wider deployment, where 
even smaller sites want to deploy an ID loc split solution....

> May be adequate in TE-ITRs.

agree

>> working locator) to actually send the initial request, so this needs 
>> to be complemented with an additional mechanism. In LISP 1, the 
>> mechanism is the identity, since the identifier is also a valid 
>> locator.
>

that if you move from LISP 1 the identifier is no longer routable as it 
is and you need some additional infrastrcutre to solve the initila EID 
to locator mapping
in LISP 1.5 it seems that this is achieved through this alternative 
routing infrastrucutre that is used to route packets containing 
idnetifiers. Actually this is part of the EID to locator resolution 
system in this case.

For the other two flavoers of LISP, the EID is not routable per se, so 
you will need to obtain the locators associated to a identifier 
somehow, before starting the communication, so you cannot get them from 
getting ICMP messages back as reply to the first packet (at least for 
the initiator)

You could get them from the DNS, along with the EID, when resolving the 
fqdn, but this only works for hosts having fqdn and there are 
additional situations when you need to solve the eid to locator mapping 
when you don't have the possibility of using the fqdn as i mentioned in 
another email recently

>> instance using ULAs as identifiers and using the DNS reverse tree 
>> entry for the ULA for retrieving the locators associated with this 
>> identifier?
>

not sure i understand what you mean here...
let me ask a few clarifying questions:
- what EIDs are you assuming? 128 bits long? 32 bits long? IPv4 
addresses? unstructured 128 bits? IPv6 addresses? which ones? globally 
routable v6 addresses? ULAs? other?
- what do you think we shouldn't even try? using the DNS reverse tree 
seems possible for doing EID to loc mapping whne the EID are ULAs or 
globally routable addresses, since they are structured imho

> systems you need assign IDs to.

ok, at least, you are assuming that IDs will be aggrgegatable in the 
sense that you can assign a block of them to an organization

regards, marcelo

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Apr 2007 08:46:48 -0700

Dino,

> o An IPv6 packet is received by an ITR.

OK; either that, or the ITR resolves a FQDN and gets back a
6to4 address.

> o The DA is an EID so a mapping lookup is done to yield a locator in  

OK.

> o The ITR prepends a IPv6 header.

Huh? 6to4 prepends IPv4 headers; not IPv6.

>    an IPv4 address which follows the 2002 bits. The ITR prepends an  

So, now you have IPv6-in-IPv6-in-IPv4? 6to4 is only for
IPv6-in-IPv4.

> o The ITR sends the packet out the interface where the IPv4 DA is  

I don't know what you mean by this; my understanding is
that the ITR would simply launch the IPv6-in-IPv4 packet
into the network and let IPv4 routing steer it to the
correct ETR. 

> itself or the IPv4 embedded in it is routable.

Not the way 6to4 works; in 6to4, the embedded IPv4 address
is indeed routable.

> packet (as described from the sequence above).

AFAICT, there is no difference between LISP and 6to4 in this
regard. LISP encapsulates IPvX-in-IPvY, but for 6to4 it just
so happens that X=6 and Y=4.

Thanks - Fred

---

From: Jari Arkko <[email-masked]>
Date: Sat, 21 Apr 2007 10:02:49 +0300

Dino, Marcello,

> protocols do provide the required functionality, which is not at all

At this time, I think its much more interesting to talk about the
properties of the mapping system and protocol than to make a
decision on reuse vs. new protocol. Push vs. pull, dynamics,
security properties, trust model, scalability requirements,
aggregated vs. flat, etc. that you talked about in the rest of
this thread are the important questions now. Of course, its
useful to think about what the real-world implementation of
the concepts could be, e.g., a new BGP instance, but lets
not get hang up on the protocol selection just yet.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 21 Apr 2007 14:13:15 -0700

> not get hang up on the protocol selection just yet.

Jari, I understand your point, but what are we waiting for?

Dino

---

From: Tony Li <[email-masked]>
Date: Sat, 21 Apr 2007 15:15:55 -0700

> Jari, I understand your point, but what are we waiting for?

I don't think that Jari is suggesting that we wait.  I think that  
he's suggesting that we think first at the conceptual level and work  
through the problems that we can see there before we dive into the  
details.

The solution space is pretty large and implementing each and every  
point in the solution space is probably not the most efficient (or  
quickest) approach to getting to the solution that we want.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Mon, 23 Apr 2007 07:28:33 +0300

Tony, Dino,

> I don't think that Jari is suggesting that we wait.  I think that he's
> suggesting that we think first at the conceptual level and work

Right. And I don't think we should wait, either -- if you have a mapping
system please write it up in a draft & implement & test. We need that
level of concreteness to understand whether our ideas really work
or not. I was merely suggesting that we do not use a lot of energy
on the list to debate whether the protocol is new or reused. There
are other, more worthy topics to be debated...

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 22 Apr 2007 21:48:55 -0700

> are other, more worthy topics to be debated...

Okay, sure.

Dino

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Apr 2007 08:19:43 -0700

Don't know if this will be of interest, but I am planning
to put out an update to IPvLX RSN and that should give new
details for at least one mapping scheme proposal.

Fred

> Sent: Sunday, April 22, 2007 9:49 PM
> To: Jari Arkko
> Cc: Tony Li; [email-masked]
> Subject: Re: ID/loc mapping distribution protocol (was Re: 
> [RAM] IncrementalDeployment of LISP
>