Subject: Re: [RAM] Incremental Deployment of LISP

From: [email-masked] (Noel Chiappa)
Date: Thu, 29 Mar 2007 15:28:59 -0400 (EDT)

> From: [email-masked]

    > Yes, and isn't this the origin task of any routing protocol to
    > advertise WHERE some user is located ? (rather than the task of DNS ?),
    > i.e. to communicate to the rest of the internet "I have reachability to
    > this or that user ?"

"[saying] where some user is" and "communicating ... I have reachability to
this or that" are two entirely different things - or rather, they can be, and
have been for many decades now in most networking designs, separated into two
different tasks.

It's a general law of system design that as systems grow, it's usually the
case that a single mechanism A that did both X and Y needs to get separated
into two separate mechanisms B and C, one each for X and Y - which means that
it would be an extremely bad idea to go in the reverse direction as a system
got larger.

In other words, trying to do both:
- finding out where some user/computer/etc is, and
- finding out if/how to get there
in a single mechanism would be a really bad idea.

"All problems in computer science can be solved with another level of
indirection" - variously attributed to Butler Lampson and David Wheeler.

	Noel

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

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 29 Mar 2007 12:35:47 -0700

> in a single mechanism would be a really bad idea.

The DNS won't work, and deploying some other infrastructure (X.500?   
Something Else?) to handle lookups is a nonstarter, IMHO.

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

         Words that come from a machine have no soul.

                       -- Duong Van Ngo

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Mar 2007 16:56:58 +0200

> Something Else?) to handle lookups is a nonstarter, IMHO.

Lookups are a non-starter because of the lookup latency and what you do 
with a packet on a cache miss (it's important to say why they're a 
non-starter, Roland ;-).  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.  This goes to my earlier question of 
whether size matters.  Can a router keep this table in fast memory?  
OTOH, there's an argument to be made that with only PA addresses in the 
routing table you can "borrow" space from today's PI entries.

Eliot

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 08:41:09 -0700

Eliot, 

> Lookups are a non-starter because of the lookup latency and 
> what you do with a packet on a cache miss (it's important to
> say why they're a non-starter, Roland ;-).

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.

Fred
[email-masked]

---

From: David R Oran <[email-masked]>
Date: Fri, 30 Mar 2007 12:46:19 -0400

On Mar 30, 2007, at 11:41 AM, Templin, Fred L wrote:

> FQDN-to-locator resolution before a session starts,
What triggers this?

> and the

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 09:50:22 -0700

> > FQDN-to-locator resolution before a session starts,

Client resolves a FQDN for a service, and ITR 1) resolves a
FQDN for the ETR, then 2) resolves the FQDN for the service,
then 3) returns the results of the latter to the client.

Yes - this means that I expect the client's DNS server to
be co-located with the ITR.

Fred

---

From: David R Oran <[email-masked]>
Date: Fri, 30 Mar 2007 12:55:52 -0400

> then 3) returns the results of the latter to the client.
Ah, so you propose host changes? That's what I didn't understand.
That certaily falls into one category of approaches (HIP, Shim6,  
etc.) but has nothing to do with LISP. Sorry if I thought from the  
subject line we were still tlakng about LISP, or similar approaches  
that only touch routers.

What I still don't see is what triggers step (1). Are you proposing  
DNS snooping? Seems like it...

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 10:02:44 -0700

> subject line we were still tlakng about LISP, or similar approaches  

No, I'm not assuming host changes at all; I am only assuming
changes for routers (ITRs and ETRs) the same as for LISP.
 
> DNS snooping? Seems like it...

I am talking here about a "two-faced" DNS server - one that
acts as an ordinary DNS server inside the site and acts as
a DNS client outside of the site.

Fred

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Mar 2007 19:19:06 +0200

Hi Fred,
> mapping can be done then before any packets are sent.

Sorry, Yes.  I had my head in LISP, where really there is no end host 
interaction.  I think that's a good thing, in as much as it becomes 
deployable faster due to a smaller set of processors being touched.  But 
in a context, say, like HIP, you would want to do that exact resolution 
for a HIT.

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 10:26:22 -0700

> in a context, say, like HIP, you would want to do that exact
resolution

I guess what I have in mind could be considered something
of a middle ground between LISP and HIP (although the
terminology would be closer to that of LISP). Things in
the real world are rarely either one way or the other;
they are usually "shades of gray" between black-and-white.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 30 Mar 2007 11:03:34 -0700

> changes for routers (ITRs and ETRs) the same as for LISP.

Note that I am specifically not meaning to make any statement
about what kind of platform should be considered as a "router".
But, I do believe that the ITR should be located as close to
the end host as possible.

Fred

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 31 Mar 2007 06:53:21 +1200

On 31/03/2007, at 5:19 AM, Eliot Lear wrote:

> Sorry, Yes.  I had my head in LISP, where really there is no end  
> host interaction.  I think that's a good thing, in as much as it  
> becomes deployable faster due to a smaller set of processors being  
> touched.  But in a context, say, like HIP, you would want to do  
> that exact resolution for a HIT.
>
> Eliot

And in fact, that's what the HIP documents say and the  
implementations try... of course, most of the time there's no answer  
at the moment.  But it works when there is, and doesn't delay  
communication noticeably when there isn't.

Andrew

---

From: Ross Callon <[email-masked]>
Date: Fri, 30 Mar 2007 16:47:08 -0400

>in a context, say, like HIP, you would want to do that exact resolution 

This is beginning to hint at something that I have wondered about
for a while:

It seems to me that there could be cases where a router (perhaps
in a private network, or a CE router, or perhaps even a PE router)
receives some packets that already use a PA address, and some
that are using a PI address and that need to be encapsulated.
For example this might occur because deployment of LISP is not
precisely equally rapid in each private network, or is not equally
rapid in each site within a larger private network.

How is a router supposed to know which packets are using an
address that is available in the global BGP top-level routing table
(such as a PA address), and which packets are using an address
that needs to be mapped?

For those routers that are in the default-free core of the Internet
this might be easy: If you have a route, then use it. Else map.
Of course these routers are probably large enough that the ratio
between the speed of the data plane and the speed of the
control plane is so large (perhaps in many cases a factor of
10,000 or greater) that you don't want them receiving any
control packets specific to LISP, or at least any one control
packet that they do receive better correspond to at least
10,000 data packets, on average. To me this implies that you
want to push the mapping function outside of the default free
core of the Internet.

However, for many routers they will have a default route, and
will not have the full global BGP routing table. I am thinking that
the routers where you might want to do LISP will mostly (or
perhaps entirely?) have a default route for most remote
locations. Thus, if a packet has a destination address that
matches the default route it *might* be a PA address and
*might* be a PI address.

Is the thought to partition the address space? The only other
solution that I have thought of is to have strictly controlled
topology (so that there is a clear boundary where the mapping
is done).

Thanks, Ross

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 31 Mar 2007 00:45:25 -0700

> be co-located with the ITR.

And I would expect the DNS server would have to be a configured  
locator address or else the ITR can't reach it. Which means the DNS  
servers need to be allocated out of PA space.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 31 Mar 2007 00:58:12 -0700

> (such as a PA address), and which packets are using an address

If it is not in the FIB, then the DA is an EID and needs to be  
mapped. If it's in the FIB, you can route it to it's destination.  
This *could* be a default setting at the start.

> want to push the mapping function outside of the default free

If you use DHTs or Push, you don't cross the control-plane and data- 
plane. When you use LISP 1 and 1.5, and can push the ETRs close to  
the edges where the host systems will be, then the number of mapping  
requests is spread out for the site.

> matches the default route it *might* be a PA address and

It doesn't matter which one it is. If either is in the BGP core  
routing table it can be routed. If a site uses a PI and wants to  
withdraw it permanently from the BGP core, it then deploys an ETR.

The advantage of copying the inner DA to the outer DA is that you can  
find the ETR when the route is withdrawn or you find the host when it  
is not. A protocol unreachable from a host can tell an ITR that the  
EID is to not be mapped.

> topology (so that there is a clear boundary where the mapping

Not partition one address space, but create a new one, the EID  
address space. But keep the DNS A records associate with the new  
address space. And the existing address space in the BGP core are the  
Locators.

Dino

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 31 Mar 2007 12:46:57 +0200

El 30/03/2007, a las 22:47, Ross Callon escribió:

>> deployable faster due to a smaller set of processors being touched.  
>> But in a context, say, like HIP, you would want to do that exact 
>> resolution for a HIT.
>>
>> Eliot
>

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

> topology (so that there is a clear boundary where the mapping

yes, this is what HIP people have done, they defined a prefix for the 
ORCHIDs which are the identifier.

probably hip people can expand on this one, but i think it was mostly 
for allowing transparent support for upper layers

Regards, marcelo

---

From: Eliot Lear <[email-masked]>
Date: Sat, 31 Mar 2007 12:48:08 +0200

El 30/03/2007, a las 22:47, Ross Callon escribi=F3:

>> Sorry, Yes.  I had my head in LISP, where really there is no end host=20=

>> interaction.  I think that's a good thing, in as much as it becomes=20=

>> deployable faster due to a smaller set of processors being touched. =20=

>> But in a context, say, like HIP, you would want to do that exact=20
>> resolution for a HIT.
>>
>> Eliot
>

in LISP 1 doesn't matter, since both identifiers and locators are=20
routable
So, if you do have an alternative locator for ab.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]

Hi Ross,
> (such as a PA address), and which packets are using an address

I guess the way I would tackle this problem is by first attempting to 
find a mapping.  Failing that I would fall back on the global routing 
table as it is today.  To me this says, "Assume things are the way they 
are today (baseline) unless told differently".  That's safe.   Remember 
when BGP4 was deployed.  CIDR was out there first.  Well, here we would 
have this table populated first (except for test cases).  There are two 
prices for doing it this way:

    * A mandatory extra lookup in an additional table
    * Wide distribution of the mapping table through some as of yet
      undetermined means.  This thing will need to be MORE reliable and
      scale more broadly than the root servers.

Given this, I don't think it matters where the address space comes from.

Eliot

the identifier, then=20

similar in LISP 1.5

In LISP 2 and 3 the issue you are considering needs to be considered=20
imho

probably it will induce additional latency, since you probably want to=20=

if you have all the identifier to locator database available, then you=20=

can check on it to verify if the destination is a identifier and which=20=

are the locators

if you don't have it, well, then you need to make a query and find out,=20=

> topology (so that there is a clear boundary where the mapping

yes, this is what HIP people have done, they defined a prefix for the=20
ORCHIDs which are the identifier.

probably hip people can expand on this one, but i think it was mostly=20
for allowing transparent support for upper layers

Regards, marcelo

---

From: Eliot Lear <[email-masked]>
Date: Sat, 31 Mar 2007 12:48:08 +0200

Hi Ross,

Eliot

---

From: David Conrad <[email-masked]>
Date: Sat, 31 Mar 2007 19:53:10 +0100

Eliot,

On Mar 30, 2007, at 3:56 PM, 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... :-)

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.

> 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.

Rgds,
-drc

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Mar 2007 21:57:26 -0400

At 12:46 PM 3/31/2007 +0200, marcelo bagnulo braun wrote:
>...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

I agree. In LISP 1.0 and 1.5 this particular point doesn't seem to be
an issue, since you route on the IDs (until you are directed to map to
something else).

>In LISP 2 and 3 the issue you are considering needs to be considered imho
>
>in LISP 3 it depends whether you are using the push or pull model

I think that I am assuming that you need a pull model (to get the mapping
table) for two reasons (the second is the BIG one):

  - One is that part of the point of LISP is to make it easier for sites
to use PI addresses. If we make it easier for sites to use PI addresses,
presumably many will actually do this. This implies that the mapping
table is likely to grow considerably more quickly than the current
routing table.

  - For performance reasons, I am assuming that we need to push the
encapsulation / decapsulation function relatively close to the edge
(note, this is NOT due to the performance of the actual encapsulation,
which should be possible to do at line rate -- at least if you are willing
to update many or most deployed routers -- this is due to performance
of the control plane). If you push this into large enterprises, then the
granularity of your forwarding tableFrom [email-masked] Sat Mar 31 23:15:32 2007
Date: Sat, 31 Mar 2007 21:57:26 -0400
To: marcelo bagnulo braun <[email-masked]>
From: Ross Callon <[email-masked]>
Subject: Re: [RAM] Incremental Deployment of LISP
Cc: "Templin, Fred L" <[email-masked]>, [email-masked]

At 12:46 PM 3/31/2007 +0200, marcelo bagnulo braun wrote:
>...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

I agree. In LISP 1.0 and 1.5 this particular point doesn't seem to be
an issue, since you route on the IDs (until you are directed to map to
something else).

>In LISP 2 and 3 the issue you are considering needs to be considered imho
>
>in LISP 3 it depends whether you are using the push or pull model

I think that I am assuming that you need a pull model (to get the mapping
table) for two reasons (the second is the BIG one):

  - One is that part of the point of LISP is to make it easier for sites
to use PI addresses. If we make it easier for sites to use PI addresses,
presumably many will actually do this. This implies that the mapping
table is likely to grow considerably more quickly than the current
routing table.

  - For performance reasons, I am assuming that we need to push the
encapsulation / decapsulation function relatively close to the edge
(note, this is NOT due to the performance of the actual encapsulation,
which should be possible to do at line rate -- at least if you are willing
to update many or most deployed routers -- this is due to performance
of the control plane). If you push this into large enterprises, then the
granularity of your forwarding table for destinations inside large
enterprises on the opposite side of the world is much finer than the
current IP forwarding table for the same destinations. This means that
you probably can't store the entire mapping table all at once in one
place.

>...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
>

Actually, if you are in the core of the Internet and have the full BGP
forwarding table (and NO default route) then you probably do know
which addresses are PA, and don't need to do the lookup (which in
a terabit router is a relief). For other routers (and of course there are
lots of routers in many places that are still quite large, but not in the
default-free core), then this would seem to suggest that you are
essentially doing cache-based routing, even if the cache is only to
determine whether or not you need to map a PI address to a PA
address. To me this is relatively more scary than the alternative of
partitioning the address space -- although I admit that partitioning
all of the address space may be rather difficult to get people to
agree to do (it would seem to imply a lot of renumbering).

>probably hip people can expand on this one, but i think it was mostly for 
>allowing transparent support for upper layers

I could see an approach where existing PI addresses continue to be
in the global IP routing table, and only *new* PI addresses come from
the special space. Thus only the new PI addresses would be mapped,
and we would be able to know that we need to do this because the
special part of the IP address space (whether IPv4 or IPv6) is well
known.

Ross

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Mar 2007 23:14:28 -0400

Ross

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Mar 2007 23:14:28 -0400

>This *could* be a default setting at the start.

But I have a default route, so I can always route the packet
-- until it gets to the default free core of the Internet. [If the
default route doesn't count as "a route", then I can never
route the packet (unless it starts in the default free core of
the Internet).]

>...

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.

>is not. A protocol unreachable from a host can tell an ITR that the

So the encapsulating router near the source copies the DA into the
DA of the extra IP header, and puts its address as the SA of the
extra IP header. If the destination doesn't understand LISP, it *might*
send back an ICMP protocol unreachable and the encapsulating
router knows to send the next packet without encapsulation (and if
the destination doesn't have a router that understands LISP, its
address better be in the global routing table, which makes sense).
Of course this protocol unreachable is very likely handled by
the control plane of the encapsulating router, and therefore
contributes to my performance concern with deploying LISP in PE
routers.

If the ICMP protocol unreachable is lost due to a random event, then
another packet is sent, the next protocol unreachable gets through,
and we are fine. However, if the ICMP protocol unreachable is lost
due to permanent reasons -- such as there is a network in the path
that has a policy of not allowing them, then either there is a problem,
or the encapsulating router has to somehow notice that packets
aren't getting through without getting any indication of this (presumably
the source host will notice that it doesn't get a reply, but I am not clear
on how it would tell the encapsulating router to stop encapsulating,
since the source host is not on the path of the encapsulated packet,
and therefore does not necessarily know which =flowed
Cc: "Templin, Fred L" <[email-masked]>, [email-masked]

>This *could* be a default setting at the start.

But I have a default route, so I can always route the packet
-- until it gets to the default free core of the Internet. [If the
default route doesn't count as "a route", then I can never
route the packet (unless it starts in the default free core of
the Internet).]

>...

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.

>is not. A protocol unreachable from a host can tell an ITR that the

So the encapsulating router near the source copies the DA into the
DA of the extra IP header, and puts its address as the SA of the
extra IP header. If the destination doesn't understand LISP, it *might*
send back an ICMP protocol unreachable and the encapsulating
router knows to send the next packet without encapsulation (and if
the destination doesn't have a router that understands LISP, its
address better be in the global routing table, which makes sense).
Of course this protocol unreachable is very likely handled by
the control plane of the encapsulating router, and therefore
contributes to my performance concern with deploying LISP in PE
routers.

If the ICMP protocol unreachable is lost due to a random event, then
another packet is sent, the next protocol unreachable gets through,
and we are fine. However, if the ICMP protocol unreachable is lost
due to permanent reasons -- such as there is a network in the path
that has a policy of not allowing them, then either there is a problem,
or the encapsulating router has to somehow notice that packets
aren't getting through without getting any indication of this (presumably
the source host will notice that it doesn't get a reply, but I am not clear
on how it would tell the encapsulating router to stop encapsulating,
since the source host is not on the path of the encapsulated packet,
and therefore does not necessarily know which router is doing the
encapsulation). Perhaps one answer is to tell people not to set
policies to drop ICMP protocol unreachable messages.

So, a site decides to withdraw its route from the BGP core and deploys
either an ETR, or for performance and redundancy deploys a number of
them. Its route is withdrawn. On the other side of the world there is a
system that sends a packet to this site. In the past that packet would
have followed the default route until it gets to the default free core of the
Internet, then it would have been routed via the specific route to the PI
address to the destination site. Now since nothing has changed on the
other side of the world, I assume that this still follows the default route
until it gets to the default free core of the Internet. Is this correct? When
the packet gets to the default free core, there is no route. Thus the
packet could be mapped at that router (which is probably a big one), or
it gets routed to some system somewhere (not necessarily anywhere
close to the actual destination), which sends a redirect somewhere. If
the latter, then the packet would have needed to be encapsulated by a
system that knows how to handle the redirect (assuming that this
system is NOT the source host -- the encapsulation provides the
address of the system that is going to handle the redirect). To me this
implies that the proposal only allows LISP speakers to talk to the
system which has withdrawn its address from the global routing system
(which is reasonable). Then in the "prior to withdrawal" case the first
packet caused a protocol unreachable message, resulting in the
exchange discussed above resulting in "normal" (no encapsulation)
exchange. In the "after withdrawal" case the first packet had the
encapsulation (assuming that the old cache entry that says "do not
encapsulate" has timed out) and thus wherever the packet is routed,
the redirect has a place to be sent that will know how to handle it.

If I am following this correctly, when the route is withdrawn, the first
router in the default free core of the Internet either needs to do a lookup
into the mapping function, already have the entire mapping table, or
have some other place to forward the packet (which might be a bank
of big servers that send redirects to the encapsulating routers, or
might be the alternate topology for PI addresses from LISP 1.5). I
suppose that the first router in the core of the Internet could also
send some form of destination unreachable to the encapsulation
router, which would then know to do the lookup into a distributed
lookup function. Of course some of these options imply a control
plane load on the first router in the default free core, and some do
not.

Perhaps we need a terminology distinction between "a PI address
which is in the global routing table -- just like now", and "a PI
address that is not in the global routing table, but needs to be
mapped to a PA address". Perhaps "Routable PI" (RPI) and
"Nonroutable PI" (NPI)?

>address space. And the existing address space in the BGP core are the

I think that I am beginning to understand this better.

Is your EID space just the "Nonroutable PI" space that I was just
proposing? I think that some people would use the term "EID" to
mean something other than an IP address which is routable within
a site but is not routable globally.

Thanks, Ross

router is doing the
encapsulation). Perhaps one answer is to tell people not to set
policies to drop ICMP protocol unreachable messages.

So, a site decides to withdraw its route from the BGP core and deploys
either an ETR, or for performance and redundancy deploys a number of
them. Its route is withdrawn. On the other side of the world there is a
system that sends a packet to this site. In the past that packet would
have followed the default route until it gets to the default free core of the
Internet, then it would have been routed via the specific route to the PI
address to the destination site. Now since nothing has changed on the
other side of the world, I assume that this still follows the default route
until it gets to the default free core of the Internet. Is this correct? When
the packet gets to the default free core, there is no route. Thus the
packet could be mapped at that router (which is probably a big one), or
it gets routed to some system somewhere (not necessarily anywhere
close to the actual destination), which sends a redirect somewhere. If
the latter, then the packet would have needed to be encapsulated by a
system that knows how to handle the redirect (assuming that this
system is NOT the source host -- the encapsulation provides the
address of the system that is going to handle the redirect). To me this
implies that the proposal only allows LISP speakers to talk to the
system which has withdrawn its address from the global routing system
(which is reasonable). Then in the "prior to withdrawal" case the first
packet caused a protocol unreachable message, resulting in the
exchange discussed above resulting in "normal" (no encapsulation)
exchange. In the "after withdrawal" case the first packet had the
encapsulation (assuming that the old cache entry that says "do not
encapsulate" has timed out) and thus wherever the packet is routed,
the redirect has a place to be sent that will know how to handle it.

If I am following this correctly, when the route is withdrawn, the first
router in the default free core of the Internet either needs to do a lookup
into the mapping function, already have the entire mapping table, or
have some other place to forward the packet (which might be a bank
of big servers that send redirects to the encapsulating routers, or
might be the alternate topology for PI addresses from LISP 1.5). I
suppose that the first router in the core of the Internet could also
send some form of destination unreachable to the encapsulation
router, which would then know to do the lookup into a distributed
lookup function. Of course some of these options imply a control
plane load on the first router in the default free core, and some do
not.

Perhaps we need a terminology distinction between "a PI address
which is in the global routing table -- just like now", and "a PI
address that is not in the global routing table, but needs to be
mapped to a PA address". Perhaps "Routable PI" (RPI) and
"Nonroutable PI" (NPI)?

>address space. And the existing address space in the BGP core are the

I think that I am beginning to understand this better.

Is your EID space just the "Nonroutable PI" space that I was just
proposing? I think that some people would use the term "EID" to
mean something other than an IP address which is routable within
a site but is not routable globally.

Thanks, Ross

---

From: Roland Dobbins <[email-masked]>
Date: Sat, 31 Mar 2007 20:24:30 -0700

> route the packet (unless it starts in the default free core of

Multihomed endpoint networks don't typically take (or are offered)  
default.

                       -- Duong Van Ngo

---

From: Ross Callon <[email-masked]>
Date: Sat, 31 Mar 2007 23:39:51 -0400

At 08:24 PM 3/31/2007 -0700, Roland Dobbins wrote:

>>...But I have a default route, so I can always route the packet

But multihomed endpoint networks *do* receive packets that were
transmitted from networks that are not multihomed.

This part of the discussion relates to packets that are coming
from somewhere, with a destination that is in the multihomed
network. The source might be in a single-homed network.

Ross