Subject: [RRG] LISP and IP Interworking

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 30 Nov 2007 13:59:16 -0800

Hi,

The LISP team has been thinking about some of the ways IP and LISP can
work together.  We've written a document that talks about some
approaches to this.  It can be found at:

http://www.1-4-5.net/~dmm/draft-lewis-lisp-interworking-00.txt 

The abstract is below:

   This document describes various methods for interworking between the
   Internet and an Internet in which Endpoint Identifiers are separated
   from to Routing Locators using the Locator/ID Separation Protocol
   (LISP).  Existing Internet hosts that do not participate in the LISP
   system must still be able to reach sites numbered from this EID
   prefixes.  This new draft describes mechanisms which might be used to
   provide reachability between these types of sites.  A new network
   element, the Proxy Tunnel Router may also be deployed to act as a
   transitional LISP Ingress Tunnel Router for a subnetwork which does
   not implement LISP but which requires communication to devices that
   are addressed from LISP prefixes.

We're going to present an overview of this draft during the LISP
portion of the RRG meeting in Vancouver.  Comments welcome!

-Darrel

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Dec 2007 11:56:24 +1300

Darrel,

There's something I don't understand about your model.
You assert that the DFZ only contains routes for RLOCs.
But today the DFZ only contains routes for EIDs, in reality.
Don't you need to either operate with two co-existing
DFZs (DFZ-old with EID routes, and DFZ-new with RLOC routes),
or distinguish the two kinds of routes within a single
DFZ?

The PTRs will act as interworking units between DFZ-old
and DFZ-new, and I guess that as this gets deployed, DFZ-old
will fragment and be reduced to stubs.

Hmm. It's beginning to seem familiar. Change the captions
and it's page 7 of http://www.cs.auckland.ac.nz/~brian/layers.pdf,
or I have misunderstood your model completely.

     Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 4 Dec 2007 19:17:20 -0600

Thus spake "Brian E Carpenter" <[email-masked]>
> or distinguish the two kinds of routes within a single

Since currently IP addresses are both, that's only one potential way of 
looking at it.  The other is that the DFZ currently only contains RLOCs 
which are also abused into being EIDs.  If something LISPy is implemented, 
the new EID space (except perhaps in highly aggregated form) will never show 
up in the DFZ.

There is an outstanding question whether there's any way to get leaf ASes 
currently putting their RLOCs in the DFZ to remove them from BGP, turn them 
into EIDs, and map them to RLOCs they get from their upstreams.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Dec 2007 10:28:49 +1300

On 2007-12-05 14:17, Stephen Sprunk wrote:
> which are also abused into being EIDs.  If something LISPy is 
> implemented, the new EID space (except perhaps in highly aggregated 
> form) will never show up in the DFZ.
> 
> There is an outstanding question whether there's any way to get leaf 
> ASes currently putting their RLOCs in the DFZ to remove them from BGP, 
> turn them into EIDs, and map them to RLOCs they get from their upstreams.

That will be forced on them by their transit providers, surely? Whoever
is the first recipient of their BGP4 advertisements can suppress
them.

    Brian

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 5 Dec 2007 13:59:53 -0800

> From: Brian E Carpenter [mailto:[email-masked]] 
<snip>
> Don't you need to either operate with two co-existing DFZs 
> (DFZ-old with EID routes, and DFZ-new with RLOC routes), or 
> distinguish the two kinds of routes within a single DFZ?
> 

I'm not sure I completely follow the above.  There is only one DFZ, this
is the global routing table of today.  When LISP sites are added, their
EIDs may not be found in the DFZ.  The draft defines those as LISP-Non
Routable, or 'LISP-NR' sites.

One way to provide reachability to those LISP-NR sites is to have Proxy
Tunnel Routers that take LISP-NR EIDs, summarize them, and announce
these summaries into the DFZ.  This should lead to far fewer routing
entries compared to just having LISP-NR sites redistribute their EIDs
into the DFZ themselves.  Note that this will increase stretch to
connections between non-LISP sites and LISP-NR sites - depending on how
widespread PTRs are deployed.

Lets say for example new LISP sites are allocated prefixes (EIDs) from
223.0.0.0/8.  Hundreds of sites have subnets of various lengths are
allocated from within this range.  The PTR, however, only has to
announce 223.0.0.0/8.  Traffic engineering to LISP-NR sites is handled
via the LISP system. PTRs encapsulate then send towards those site's
RLOCs.

> The PTRs will act as interworking units between DFZ-old and 
> DFZ-new, and I guess that as this gets deployed, DFZ-old will 
> fragment and be reduced to stubs.

I think your DFZ-new above is the LISP mapping system.  So there is the
global routing table, the DFZ, and a mapping system.  The Mapping System
does not follow topology, it follows allocations.  The mapping system
does not imply reachability, it merely holds subscription time
interconnection mapping data.  Thus the mapping system should have much
different scaling characteristics than the current global DFZ (your
DFZ-old above).

> 
> Hmm. It's beginning to seem familiar. Change the captions and 
> it's page 7 of http://www.cs.auckland.ac.nz/~brian/layers.pdf,

I think we've not reached an understanding yet! Thanks for your
comments. 

-Darrel

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 6 Dec 2007 17:55:55 -0600

>> currently putting their RLOCs in the DFZ to remove them from BGP, turn 
>> them into EIDs, and map them to RLOCs they get from their upstreams.
>

Call me a cynic, but "follow the money" applies.  I'm paying my transit 
provider for bandwidth, and if necessary I'll pay them to accept my routes 
and advertise them to customers and peers.  In markets with competition, the 
price will tend towards zero because it costs the transit provider close to 
nothing and sales types will agree to anything to get their commission on 
the bandwidth.

So, my transit isn't going to filter my route.  However, their customers and 
peers may.  If the majority do, I have to change my strategy; if it's a 
minority, I can depend on _their_ customers forcing them to stop because my 
web site (or whatever) works on all their competitors' networks.

S

---

From: Scott Brim <[email-masked]>
Date: Fri, 7 Dec 2007 15:01:02 -0800

Excerpts from Brian E Carpenter at 10:28:49 +1300 on Thu 6 Dec 2007:
> > There is an outstanding question whether there's any way to get
> > leaf ASes currently putting their RLOCs in the DFZ to remove them
> > from BGP, turn them into EIDs, and map them to RLOCs they get from
> > their upstreams.
> 
> That will be forced on them by their transit providers, surely?
> Whoever is the first recipient of their BGP4 advertisements can
> suppress them.
> 
>     Brian

But why would an AS force its customers to move to LISP?  Business
models are still incomplete.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Dec 2007 13:14:54 +1300

Darrel,

> Routable, or 'LISP-NR' sites.

I think there's inevitable confusion caused by LISP's use of the term
"EID" to refer to addresses (or rather prefixes) that are in fact
locators, but ones that it is desired not to route globally. The fact
is that the current Internet uses such prefixes for global routing.
That's what I mean by saying that today's DFZ contains nothing but
EIDs in the LISP sense of the term. In the LISP theory, tomorrow's
DFZ contains nothing but RLOCs, i.e. locators that it is desired
to route globally. I'm trying to understand how your model allows
a highly stepwise change from today's DFZ to LISP's DFZ without
any connectivity failures along the way (and we're presumably talking
about a process that will take at least ten years, overlapping
with IPv6 deployment).
> these summaries into the DFZ. 

Which DFZ? The DFZ starts out containing 100% EID prefixes, summarized
as much as BGP4 policies allow. I can only interpret your statement as
referring to some new DFZ running in parallel to that old one.

> This should lead to far fewer routing
> I think your DFZ-new above is the LISP mapping system.

No, it's the DFZ that the LISP map points into. I don't understand
how that can fail to be logically disjoint from the existing DFZ,
which contains routes to unmapped prefixes.

     Brian

> So there is the

---

From: Scott Brim <[email-masked]>
Date: Tue, 11 Dec 2007 14:42:06 -0500

Excerpts from Brian E Carpenter on Sun, Dec 09, 2007 01:14:54PM +1300:
>>> Don't you need to either operate with two co-existing DFZs (DFZ-old with 
>>> EID routes, and DFZ-new with RLOC routes), or distinguish the two kinds 
>>> of routes within a single DFZ?
>>>
> EIDs in the LISP sense of the term. 

Well, clearly you're not confused by it :-).  

If you look in the definition of EID in the LISP draft ...

  The host obtains a destination EID the same way it obtains an
  destination address today, for example through a DNS lookup or SIP
  exchange.  The source EID is obtained via existing mechanisms used
  to set a hosts "local" IP address.

... the overlap is clear.  If we called it an "address", we've seen
that that causes more confusion!  And I don't think you really meant
to imply it, but an EID doesn't refer to a prefix, it's a single
identifier.  "EID Prefix" is what you want to compare there.

The fundamental difference between EIDs and current "addresses" is
routing scope.  In Lixia's terms, EIDs are globally *deliverable* in
the DFZ but not globally *routed* in it.  Therefore the current
Internet is not "nothing but EIDs" in the LISP sense.  Addresses used
now are globally routed.

The point of this whole effort is to enable things like more
multihoming while also making Internet routing work better, for
example by taking prefixes out of global routing.  

I think that might be the disconnect.  I suspect you are thinking of
the current Internet and thinking we are sticking a new DFZ in the
middle of it.  Rather, we are taking current Internet routing and
limiting it.  There is and will only be one (public) DFZ.  The
proposal is to take routes out of it.  That doesn't create a new DFZ.

> In the LISP theory, tomorrow's

The prefix that is being PTRed is removed from direct DFZ routing, and
is available via PTRs.  It's just as if I changed my site's
connectivity from one AS to another.  Of course this can be done
carefully, so I'm available via PTRs and also via my current
provider, so I don't understand your concern about loss of
connectivity..

Does any of this help?

swb

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2007 13:06:23 +1300

Everyone,

Scott and I had a chat about this today over some software
quaintly referred to as "the telephone."

I don't disagree with anything below. My concern is that
in the long term, we might see a swamp appearing in the
LISP-based DFZ, just as we've seen a swamp appearing in the
pure-BGP-based DFZ in the past (and as the large scale usage
of IPv6 "PI" prefixes would cause in the pure-BGP4+-based
IPv6 DFZ). So I'm suggesting, somewhat clumsily, that we
need to design things in a way that would allow us to recurse
the whole model if and when a swamp appears. Conceptually,
I find that easier to think about in terms of multiple DFZs.
I could be quite wrong, of course.

That being said, it still appears that a complete map is
needed in any case, so the problems that have been discussed
wrt distribution and caching of maps are not significantly
affected.

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Dec 2007 16:21:01 -0800

> I could be quite wrong, of course.

I don't see why we can't "recurse one more time". The main LISP spec  
indicates that after prepending a header for Loc/ID split purposes,  
you can prepend one more the TE-ITR to TE-ETR purposes. So if the  
first Loc/ID split infrastructure runs level-0 LISP-ALT, the TE-based  
infrastructure can run, another LISP-ALT at level-1. Where the BGP- 
core today, level-0, and level-1 never connect to each other.

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2007 13:34:41 +1300

On 2007-12-12 13:21, Dino Farinacci wrote:
> indicates that after prepending a header for Loc/ID split purposes, you 
> can prepend one more the TE-ITR to TE-ETR purposes. So if the first 
> Loc/ID split infrastructure runs level-0 LISP-ALT, the TE-based 
> infrastructure can run, another LISP-ALT at level-1. Where the BGP-core 
> today, level-0, and level-1 never connect to each other.

Bingo. I certainly hope that *one* more time would be enough.
I guess I'm arguing for a level number in the map entries, as future
proofing if we have to add levels later.

     Brian

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Dec 2007 16:35:41 -0800

>> I don't see why we can't "recurse one more time". The main LISP  
>> spec indicates that after prepending a header for Loc/ID split  
>> purposes, you can prepend one more the TE-ITR to TE-ETR purposes.  
>> So if the first Loc/ID split infrastructure runs level-0 LISP-ALT,  
>> the TE-based infrastructure can run, another LISP-ALT at level-1.  
>> Where the BGP-core today, level-0, and level-1 never connect to  
>> each other.
>

Now that you agree, where do you want to sign the papers.  ;-)

Dino