Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP)

From: [email-masked] (Noel Chiappa)
Date: Mon, 16 Apr 2007 10:47:04 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > My question was in the context of LISP 1.5.

Dino just mentioned how LISP 1 is a "phase 0 prototype effort", and I suspect
the same is true, in some ways, of many of the lower numbered LISP variants.
My sense is that the one that gets deployed in large-scale operational
service is likely to be LISP 4 or 5 (or more), i.e. one that's not yet
defined.

My guess is that the architectural commonality between LISP 1/1.5/etc and the
eventual deployed stuff is likely to be:

- Hosts and local routers don't need to be modified
- The existing internetwork layer is "jacked up" to become mostly an
	end-end host naming layer
- End-end names are mapped into new locators as they cross the boundary

I think LISP is the first detailed proposal in the last half-decade or so to
propose operating in this particular architectural quadrant (which may well be
the only feasible one to operate in), and I suspect that's why it's getting a
lot of attention. However, the final product may look quite different from the
initial prototypes we have on paper now.

The current discussion seems to be a somewhat unfocussed mix of "can we
operate in this quadrant at all", and details of particular variants, trying
to sort of which particular approach (within the boundary lines above) works;
most of the current discussion is, of course, looking at how to do the
mapping, which is appropriate, because that's probably the hardest part.

	Noel

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Apr 2007 18:31:25 +0200

Hi Noel,
> mapping, which is appropriate, because that's probably the hardest part.

There are two issues.  First, in order to figure out whether "we can 
operate in this quandrant at all", you're of course correct that we need 
to understand the details to some reasonable degree.  But I think there 
is another question that is nagging at each step, which is what 
precisely are the scaling characteristics that we are targeting?  If we 
disagree on those points we will surely disagree on the different 
proposals that make differing assumptions.  And so it's probably not 
unwise to question, for instance, the number of mappings needed.  Now 
seems like a good time for that.

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Apr 2007 10:01:43 -0700

> service is likely to be LISP 4 or 5 (or more), i.e. one that's not yet

But please note, that these are variants and not version numbers.  
That is, each number is using a particular method to do mapping. So  
LISP 1.x was suppose to convey routeable IDs, LISP 2 was suppose to  
convey a pull model and 2.0 is using DNS. And 3.0 is future stuff.

So for instance (and this is not real yet and hasn't been written  
down), this is how I would number the variants:

LISP 1 and 1.5: as documented in draft-00.

LISP 2.x:       uses a pull model where:
     LISP 2.0:   uses DNS with port 53
     LISP 2.1:   uses DNS the protocol on a different port and  
infrastructure
     LISP 2.5:   uses a new and different pull protocol

LISP 3.x:       uses a pull model that does not exist today, where:
     LISP 3.0:   uses DHTs
     LISP 3.1:   considers using Compact (or ROFL) Routing

LISP 4.x:       uses a push model that does not exist today, where:
     LISP 4.0:   uses BGP not on port 179
     LISP 4.1:   uses Mark Handley's DNSpush style
     LISP 4.2:   uses a push-n-pull model, where push happens at high  
levels and
                 lower levels pull from the higher levels

LISP >= 2 means:

o Never routable IDs.
o Could mean packets are dropped while waiting for lookups to complete.

All variants of LISP assume:

o The mapping function does not convey locator reachability status.
o The EID-to-RLOC entries are relatively static, that is they change  
only at
   subscription time events.

> - Hosts and local routers don't need to be modified

ISP routers that don't use LISP for TE won't have to be modified either.

> - End-end names are mapped into new locators as they cross the  

Right.

> initial prototypes we have on paper now.

Definitely. We are trying to draw a line in the sand to start off,  
but the line isn't really that deep.  ;-)

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 16 Apr 2007 13:01:17 -0700

Noel,

> - End-end names are mapped into new locators as they cross the boundary

What you called "end-end names" are not really "end-end names" but
locators. It just the scope of these locators is not the whole
Internet. What you do at the boundaries is mapping of site-wide
locators into the ISP locators. 

Yakov.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 17 Apr 2007 11:07:57 +0200

Yakov,

El 16/04/2007, a las 22:01, Yakov Rekhter escribió:

> locators.

but they can be end to end names, since they can be globally unique. 
OTOH, they cannot be globally routable.

So, they can be global identifiers as Noel mentions,  but also as you 
mention they are locators with a narrower scope (the site). this is 
what basically ULAs are

regards, marcelo

>  It just the scope of these locators is not the whole

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 17 Apr 2007 07:00:31 -0700

Dino,

>   only at subscription time events.
> 
> > My guess is that the architectural commonality between LISP 1/1.5/ 
> > etc and the eventual deployed stuff is likely to be:
> >

If an ISP does not use LISP for TE, then according to the above
none of the ISP's routers have to be modified, which means that such
an ISP does not need to deploy any ITRs/ETRs. And if neither hosts nor 
local routers have to be modified, then none of the local routers
need to be ITRs/ETRs. So, where would the ITRs/ETRs be deployed ?
  
Yakov.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2007 16:24:03 +0200

> need to be ITRs/ETRs. So, where would the ITRs/ETRs be deployed ?
Let's distinguish ITRs and ETRs.  ETRs are only needed by those who 
advertise (through whatever means) LISP-based address space.  ITRs MUST 
be deployed by either ISPs. their "upstreams" (for some value of 
"upstream") or their customers in order to route to PI LISP participants 
whose routes have been withdrawn.  Any one of those three models might 
suit a given situation.  Take for instance a multihomed customer with 
full BGP routing, who is already running an ETR.  Perhaps it makes sense 
for that customer to take on the ITR functionality as well, so that they 
can optimize routing.  OTOH, a large ISP may want to deploy ITRs either 
at the PE or some place nearby for their customers.  Or, a small ISP 
might make use of an upstream ITR.

There are probably other games available, as well.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2007 17:30:11 +0200

Yakov,
> locators into the ISP locators. 

I think this is a great way to look at the engineering problems we are 
targeting.  Scope in the case of LISP indicates the appropriate lookup 
mechanism.  How that scope is determined is something of an open 
question.  For instance, one could say that an address falls within the 
global routing scope if an entry for it exists within the RIB.  One 
could say that an address falls within the global LISP scope (for lack 
of better words) if an EID/RLOC mapping can somehow be determined.

The benefit of such an approach is that it keeps us out of all the 
pitfalls that application developers have warned us for years.  We 
retain transparency, retain the same APIs, and we provide for a 
transition.  Here is the real question: how responsive can the network 
be in the face of a failure, and what is the restoration time from that 
failure?  Therein lies the rub.

By the way, I still believe we should invest more research efforts in 
HIP, and API issues relating to a LOC/ID split that occurs on the host.  
A lot of the standardization would not normally happen under the 
auspices of the IETF, but rather in the IEEE under POSIX.  It'd be sort 
of funny if we made this their problem ;-)  And then funnier when a 
bunch of the same faces showed up there, making it our problem again :-)

Eliot

---

From: [email-masked]
Date: Tue, 17 Apr 2007 18:02:27 +0200

Eliot,

> of better words) if an EID/RLOC mapping can somehow be determined.

I think this is not very different from what I proposed in the
draft on TIDR, where there are a couple of tables: the RIB for
"locator prefixes", and the TIB (i.e. the Tunnel Information Base)
for the "identifier prefixes". It is outside the interdomain
infrastructure when "identifier prefixes" become "locator prefixes".

And it is the presence of the LOCATOR attribute what permits to
say whether a prefix is a "locator prefix" or an "identifier prefix".

When I first wrote the draft on TIDR I had a couple of choices:
either to use the LOCATOR attribute to assign locators to
identifiers, or to use the IDENTIFIERS attribute to specify
which identifiers can be reached through the locator specified
in the BGP update. 

In my draft I selected the first choice because I thought
the LOCATOR attribute provided a smoother deployment. But
I have been thinking more on this topic and now I think
that a new IDENTIFIERS attribute would give additional
benefits with regard to the BGP update processing.

I will try to send a note tomorrow explaining this, to see
if the BGP-based push method that I proposed in the TIDR
draft could be useful.

Regards,
Juanjo

---

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

Dino,

>      LISP 2.0:   uses DNS with port 53

OK - that would be *the* DNS.

>      LISP 2.1:   uses DNS the protocol on a different port and  

Could be a site-specific name resolution service that
looks like DNS, e.g., LLMNR.

>      LISP 2.5:   uses a new and different pull protocol

What about a combination of 2.0 and 2.1, i.e., you
look up the locator in *the* DNS and you look up the
identifier in a site-specific name resolution service?

Fred
[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 Apr 2007 23:22:55 -0700

> need to be ITRs/ETRs. So, where would the ITRs/ETRs be deployed ?

There are ITR/ETRs used for the address separation. Those are  
deployed at sites. And there can be, optionally, TE-ITR/TE-ETR which  
are deployed in ISPs.

Dino