Subject: [RAM] Architectural comments on draft-farinacci-lisp-00

From: Pekka Nikander <[email-masked]>
Date: Thu, 15 Feb 2007 10:34:21 +0200

I finally had time to properly read draft-farinacci-lisp-00.  To me,  
it is intriguing work from deployment and implementation point of  
view.  However, it also seems to bear wider architectural  
similarities to what would be proxied SHIM6 or HIP, or any other  
proxied host-based identifier/locator split architecture.

 From an architectural point of view, I would divide the proposed  
mechanism into four different aspects:

   1. Placement of the identifier / locator mapping function
   2. Encapsulating of data packets
   3. State creating between mapping points, i.e., the "protocol"
   4. Trust models and security mechanisms

Continuing from this architectural viewpoint, at least to me, the  
main feature of LISP is to place the identifier / locator mapping  
function into separate boxes in the network, not at the hosts.   
However, as I tied to outline in draft-nikander-ram-generix- 
proxying-00.txt, also host-based approaches allow such placement by  
"stretching" the stack into a wire.  In the case of the EIDs being  
routable (as for LISP 1 or 1.5), there is also considerable freedom  
in placing the proxies in the network; see Section 7 of the draft.

Considering the other aspects, LISP and any SHIM6/HIP based proxied  
approach are pretty similar.  Both encapsulate the data packets  
somehow, at least conceptually*).  Both need to create appropriate  
mapping state between the mapping points, and resynchronise the state  
in the case of mobility or state loss.  Both need some mechanism for  
securing against traffic stealing, black-holing, and flooding.

*) When ESP is used with HIP, actually no explicit encapsulation is  
needed since the ESP SPI can be used for demultiplexing the traffic  
at the decapsulating end.

The differences are in details.  The following table attempts to  
capture the crux.

Approach | Encapsulation | Protocol | Security
---------+---------------+----------+------------------
LISP     | IP tunnel     | ICMP/new | not defined yet
SHIM6    | Context tag   | SHIM6    | HBA / CGA + RR
HIP      | IPsec ESP     | HIP BE   | ORCHID + RR

Looking at the details, I don't see any fundamental differences in  
encapsulation.  IP tunnelling could be easily used for SHIM6 and HIP,  
too.  Basically, what SHIM6 and HIP provide are optimised tunnelling,  
i.e., headers that are optimised to carry the minimum amount of  
information needed so that the receiving end (ETR in LISP  
terminology) can re-create the original packet.  If tunnelling (with  
all its known drawbacks) is considered to be a better encapsulation  
method that what is currently defined for SHIM6 or HIP, it would be a  
no-brainer to adjust SHIM6 and/or HIP accordingly.

Looking at the protocols, SHIM6 and HIP base exchange carry known  
similarities; the SHIM6 protocol was inspired by HIP.  The biggest  
advances of SHIM6 to HIP are its ability for late binding and lighter  
cryptographic operations.  However, the LHIP proposal provides  
similar properties for HIP too, rendering the fundamental differences  
between SHIM6 and HIP to the ULID formats.  Currently the proposed  
LISP protocol is very simple, but I expect it to grow considerably  
more complex once all the security issues are solved.

So, to me, the biggest differences are in trust models and security.   
That, in turn, are hard to comment in detail at the moment, for two  
reasons:

  1. There is no detailed spec for proxying SHIM6 and/or HIP

  2. The LISP spec is missing the security details

Now, based on my earlier work, starting from the late Homeless Mobile  
IPv6 proposal (which was killed due to security considerations),  
through MIPv6 security, HIP, and some aspects of SHIM6 security  
design, my gut feeling is that once security is added to LISP, we end  
up with a very similar design to current SHIM6 and HIP, with a four- 
way handshake that uses certain cryptographic bindings and return  
routability.  But of course I may be completely wrong here; it may be  
easier to provide security in the network side, at least if you can  
assume S-BGP or similar.  But then, can you assume that such a  
security framework would be there?

Anyway, if I happen to be right in my security gut feeling, I don't  
see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP.  Both  
HIP and SHIM6 are much more mature at the date that LISP.  If/when  
proxying is added to them, they should be able to allow similar  
network-based implementation and TE characteristics that LISP do.

--Pekka Nikander

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Feb 2007 19:20:41 -0800

> I finally had time to properly read draft-farinacci-lisp-00.  To  
> me, it is intriguing work from deployment and implementation point  
> of view.  However, it also seems to bear wider

Thanks for reading and commenting on the draft Pekka.

> architectural similarities to what would be proxied SHIM6 or HIP,  
> or any other proxied host-based identifier/locator split architecture.

It's interesting you say that, but here is an observation. It is  
certainly true that LISP could be performed in the hosts, but it  
would be unlikely that SHIM6 or HIP would be in the network. The  
point of LISP, is that it stays in the network so there are  
absolutely no changes to the host implementations.

I'm sure you didn't miss this but it should be emphasized. I think it  
will take far less time to widely deploy LISP then it would either  
SHIM6 or HIP. Just less things to touch as well as LISP being a much  
simpler solution.

>   4. Trust models and security mechanisms

Yep, but I guess this is true for all candidate solutions. You need  
to say more to differentiate them.

> function into separate boxes in the network, not at the hosts.

Correct.

> "stretching" the stack into a wire.  In the case of the

Yes, any proposal can be tweaked to look like other ones. The gem in  
the rough is what the original intention was for the design (and  
actually sticking to it).

> EIDs being routable (as for LISP 1 or 1.5), there is also  
> considerable freedom in placing the proxies in the network; see  
> Section 7 of the draft.

Yep, because you don't want to change the numerous intra-domain  
routers. LISP is also trying to optimize on the number of changes to  
routers as well. Even the amount of code in the ones that will do LISP.

To be able to get to a solution that bears fruit relatively soon, we  
must have incremental deployment. And the less changes you have to  
make, the faster and easier we will get to the fruit.

> encapsulation.  IP

Encapsulation shouldn't be a subject of debate. It certainly isn't  
the interesting part and if you had n proposals with n encapsulations  
that would be problematic. We should just pick one that is already  
supported.

> tunnelling could be easily used for SHIM6 and HIP, too.  Basically,  
> what SHIM6 and HIP provide are optimised tunnelling, i.e., headers  
> that are optimised to carry the minimum amount of information  
> needed so that the receiving end (ETR in LISP terminology) can re- 
> create the original packet.  If tunnelling (with all its known  
> drawbacks) is considered to be a better encapsulation method that  
> what is currently defined for SHIM6 or HIP, it would be a no- 
> brainer to adjust SHIM6 and/or HIP accordingly.

Hmm, I don't see this. And you said it, the devil is in the details.  
So I have no idea what you mean by adjusting SHIM6/HIP accordingly.  
You mean accordingly to LISP?

It is true you can run LISP in the host and doing so requires host  
changes. So the important aspects of the design is *just not the  
architecture* but all the things that need to happen to get it  
deployed, working, and easy to manage.

>  2. The LISP spec is missing the security details

And do you know why? Because security in and of itself is not hard,  
it's that the security mechanism that are in the toolbox are way too  
heavy weight. I have talked to 100s of people in the last 3 months  
about how to secure LISP, and even the security experts can't give me  
a simple way to do what I want to do. The ISP community is saying  
"don't put any in because no matter how hard you try it will be too  
complex to manage".

I get comments like:

"if you put security in LISP, do it without a PKI"

"try to do it with no state and no 3-way handshake"

"don't depend on a third-party"

"we really don't need it at all"

"worry about it later, give me bits to play with first"

So that doesn't leave very many tools left in the toolbox. And shared  
symmetric configured keys is a non-starter. We do that for routing  
protocols because it is easy and localized to a subnet.

> Now, based on my earlier work, starting from the late Homeless  
> Mobile IPv6 proposal (which was killed due to security  
> considerations), through MIPv6 security, HIP, and some aspects of  
> SHIM6 security design, my gut feeling is that once security is  
> added to LISP, we end up with a very similar design to current  
> SHIM6 and HIP, with a four-way handshake that uses certain

Ha ha, you are probably right. Hence why we didn't include it in the  
-00 draft. But the authors don't want security to kill the draft. We  
want to get prototype deployment experience so we can learn much more  
about the problem then just talking about it. We are trying to figure  
something for the -01 draft though.

> cryptographic bindings and return routability.  But of course I may  
> be completely wrong here; it may be easier to provide security in  
> the network side, at least if you can assume S-BGP or similar.  But  
> then, can you assume that such a security framework would be there?

S-BGP is too heavy-weight as well, in my opinion.

> network-based implementation and TE characteristics that LISP do.

I believe LISP with security can get deployed sooner than if SHIM6/ 
HIP did not have security. Just less things to touch.

> --Pekka Nikander

Thanks again,
Dino

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 16 Feb 2007 09:27:39 +0200

Hi Dino,

> absolutely no changes to the host implementations.

As I try to argue in the generix draft, and as I alleged later in my  
previous message, I do believe that it is perfectly reasonable to  
implement SHIM6 or even HIP in the network, requiring no changes to  
the host implementations.  As I argued in the arch-d list already  
earlier, I do see here two almost orthogonal (i.e. mutually  
independent) dimensions:

1. A "vertical" one, i.e., where in the stack the we do the mapping.   
Upper or lower, layering wise.  To me, this is more architectural  
then the other one.

2. A "horizontal" one, i.e., where in the host-network dimension.  In  
core, edge, host.  To me, this one is more an implementation  
dimension than the "vertical" dimension.

I say that these are _almost_ orthogonal since the lower in the stack  
the mapping is done, the easier it is to apply the mechanism deep in  
the network.  However, I don't consider LISP, SHIM6, and HIP being  
that different in this sense.  "Vertically", they are almost at the  
same location, perhaps LISP being at the lowest and HIP at the  
highest position in the stack.  However, I believe the difference is  
small enough so that it does not really limit the implementation  
options: I do believe that SHIM6 (and perhaps also HIP) could be  
implemented deep in the network, similar to LISP 1.  We did a limited  
demonstration of that (with HIP) over two years ago, in a real but  
specific (3GPP) environment.  So, I have some foundation for my  
belief, even though I have to admit that AFAIK nobody has worked out  
the details for the fully generic case.

> I'm sure you didn't miss this but it should be emphasized. I think  
> it will take far less time to widely deploy LISP then it would  
> either SHIM6 or HIP.

If we were to implement SHIM6 or HIP in the hosts, I would agree.   
But with proxied SHIM6 or HIP, I don't see any necessary differences.

> Just less things to touch as well as LISP being a much simpler  
> solution.

I don't believe that LISP would end up simpler, at least compared to  
SHIM6, in the end of the day when all details have been worked out.   
As you know, each new proposal is initially simpler than the existing  
ones, and grows more complex (than it initially is) as the details  
are fleshed out.

If we measure the complexity in terms of LoC (in the C programming  
language), I believe that all these three proposals add the order of  
10000 LoC into realistic implementations.  We have reported those  
numbers for HIP for a number of years now; I haven't seen numbers for  
SHIM6 but I believe they are pretty similar; maybe slightly smaller  
than for HIP, but not much.  LISP might get along with slightly less  
(e.g. 3000-4000 LoC once the security is there) due to employing  
existing tunnelling, but I wouldn't expect any orders of magnitude  
smaller complexity.  But again, I may be completely wrong here; I'm  
very interested in seeing your numbers once you've got the prototype  
ready.

So, to me, the current "simplicity" of LISP (compared to SHIM6 and  
HIP) is a result of two factors: First, it is still at the idea  
level, without sufficient details.  Second, it is using constructions  
that are familiar to the operator community (such as tunnelling and  
ICMP) while the other proposals use more specialised (and more  
optimised!) constructions.  As I argued above, I don't believe there  
will be any significant complexity differences in terms of  
implementation or specification complexity, once all the details will  
be there.  And, as I argue separately (both above and below), I don't  
believe there will be any significant differences in the terms of  
deployment complexity, either.

<For brevity, I'm skipping below things we seem to agree upon. In  
many cases I fully agree with you, e.g., what comes to the importance  
of deployment.>

>> proxying-00.txt, also host-based approaches allow such placement  
>> by "stretching" the stack into a wire.  In the case of the
>
> Yes, any proposal can be tweaked to look like other ones. The gem  
> in the rough is what the original intention was for the design (and  

I think I have to strongly disagree here.  I don't believe the  
question is about tweaking.  I believe that the question is about the  
implementation ("horizontal") dimension rather than the architectural  
("vertical") dimension.  To me, the real differences lie in security  
constructions, and there in the underlying trust model, and in the  
identifiers.  In LISP, the identifier differences lead to your very  
nice LISP 1, 1.5, 2, 3 genera construction, which I appreciate very  
much.  It is _very_ nicely worked out.  But a similar set of  
identifier structures can be applied also to SHIM6 (which is at level  
1 currently) and to HIP (which is at level 1.5 or 2 currently).

> routers. LISP is also trying to optimize on the number of changes  
> to routers as well. Even the amount of code in the ones that will  
> do LISP.

I don't see any real difference here between LISP and SHIM6 (and  
maybe HIP), since the same identifier genera (1, 1.5, 2, 3) can also  
be applied in all two (or three) cases.

>> If tunnelling (with all its known drawbacks) is considered to be a  
>> better encapsulation method that what is currently defined for  
>> SHIM6 or HIP, it would be a no-brainer to adjust SHIM6 and/or HIP  
>> accordingly.
>
> Hmm, I don't see this. And you said it, the devil is in the  
> details. So I have no idea what you mean by adjusting SHIM6/HIP  
> accordingly. You mean accordingly to LISP?

Sorry for being obscure.  What I meant is that if we think that  
tunnelling is a better method for encapsulation than the SHIM6  
context tag or the encapsulation flexibility in HIP, both SHIM6 and  
HIP could be easily adjusted to use tunnelling.

> [W.r.t LISP security design] I get comments like:

> "if you put security in LISP, do it without a PKI"

Check for both SHIM6 and HIP.

> "try to do it with no state and no 3-way handshake"

I believe that is pretty impossible, or alternatively would increase  
the packet size to an unbearable level.  For an old paper on the  
topic (not addressing it directly but laying some theoretical  
foundation), consider our 1997 paper on "stateless connections".   
(Sorry, I'm offline while writing this but it can be found on my  
publications page.)

> "don't depend on a third-party"

Check for both SHIM6 and HIP.

> "we really don't need it at all"

Now, that is an interesting argument.  It may be true, depending on  
your trust model.  Certainly, a single ISP or a mutually fully  
trusting ISP coalition could deploy a LISP-like structure without any  
security.  But then, what would be the functional difference from  
using properly configured, dynamic MPLS tunnels?

> "worry about it later, give me bits to play with first"

That is the attitude that, IMHO, has brought us with the current DDoS  
problems.

> HIP did not have security. Just less things to touch.

I think this is the crux of our disagreement.  I appreciate your  
opinion, but I don't believe it to be _necessarily_ true.  But then,  
someone needs to figure out exactly how to proxy SHIM6 or HIP in the  
generic case.  There may be details there that I cannot foresee and  
make such proxying approach much more complex than I currently  
think.  But then, as I said, I believe adding security to LISP makes  
it clearly more complex than it currently looks like.

The other part of the argument would be the other potential  
architectural benefits from the different approaches.  That we  
haven't touched yet.  But I think it also warrants distinct messages  
instead of burying it here.

--Pekka Nikander

---

From: JFCM <[email-masked]>
Date: Fri, 16 Feb 2007 02:49:52 +0100

LISP is intended for IPv4 as well and supports multiple encapsulation 
for unlimited successive addressing capacity.

As a selfish user my main need is not many more network address (I 
have already mine) it is stability, simplicity in installation and a 
very large number of standardizable local addresses (plug and play, 
access grids, etc). I feel that LISP gives this to me through 
successive possibility of  addressing encapsulation. I see here a 
good chance to promote NATs to the point to get rid of them in 
transforming them into smart standalone gateways exchanges, speaking 
LISP with the global network and IPv4 or IPv6 or other environment 
with the local network?

Not to change anything in the existing system, I proposed to 
structure the IPv6 address payload and supposed that an internat IPv8 
could be a grassroots intermediary patch. LISP seems to elegantly 
address all this, including you say an interoperability with SHIM6 and HIP.?

jfc

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 17 Feb 2007 11:09:54 -0500

>From below.  LISP has plenty of details for me to get going here.  It is
simple and will work, the authors all have implemented specs and
architecture that works in practice running today and not in theory. It
also does not preclude further research and debates on HIP, SHIM6, etc.
The issues you state below are all theoretical abstractions, and
interesting and I now believe should be in the IRTF. LISP is a reality
sandwich presented that will solve in my view the RAM ID from the IAB
and add much other value and avoid hosts for "now" messing with ID / Loc
split, which we are not going to solve in the year 2007 on this list
IMHO.

Best,
/jim

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Friday, February 16, 2007 2:28 AM
> To: Dino Farinacci
> Cc: [email-masked]
> Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00
> 
> Hi Dino,
> 
> >> architectural similarities to what would be proxied SHIM6 
> or HIP, or 
> >> any other proxied host-based identifier/locator split architecture.
> >
> > certainly true that LISP could be performed in the hosts, 
> but it would 
> > be unlikely that SHIM6 or HIP would be in the network. The point of 
> > LISP, is that it stays in the network so there are absolutely no 
> > changes to the host implementations.
> 
> As I try to argue in the generix draft, and as I alleged 
> later in my previous message, I do believe that it is 
> perfectly reasonable to implement SHIM6 or even HIP in the 
> network, requiring no changes to the host implementations.  
> As I argued in the arch-d list already earlier, I do see here 
> two almost orthogonal (i.e. mutually
> independent) dimensions:
> 
> Upper or lower, layering wise.  To me, this is more 
> architectural then the other one.
> 
> 2. A "horizontal" one, i.e., where in the host-network 
> dimension.  In core, edge, host.  To me, this one is more an 
> implementation dimension than the "vertical" dimension.
> 
> I say that these are _almost_ orthogonal since the lower in 
> the stack the mapping is done, the easier it is to apply the 
> mechanism deep in the network.  However, I don't consider 
> LISP, SHIM6, and HIP being that different in this sense.  
> "Vertically", they are almost at the same location, perhaps 
> LISP being at the lowest and HIP at the highest position in 
> the stack.  However, I believe the difference is small enough 
> so that it does not really limit the implementation
> options: I do believe that SHIM6 (and perhaps also HIP) could 
> be implemented deep in the network, similar to LISP 1.  We 
> did a limited demonstration of that (with HIP) over two years 
> ago, in a real but specific (3GPP) environment.  So, I have 
> some foundation for my belief, even though I have to admit 
> that AFAIK nobody has worked out the details for the fully 
> generic case.
> 
> > SHIM6 or HIP.
> As you know, each new proposal is initially simpler than the 
> existing ones, and grows more complex (than it initially is) 
> as the details are fleshed out.
> 
> If we measure the complexity in terms of LoC (in the C 
> programming language), I believe that all these three 
> proposals add the order of 10000 LoC into realistic 
> implementations.  We have reported those numbers for HIP for 
> a number of years now; I haven't seen numbers for
> SHIM6 but I believe they are pretty similar; maybe slightly 
> smaller than for HIP, but not much.  LISP might get along 
> with slightly less (e.g. 3000-4000 LoC once the security is 
> there) due to employing existing tunnelling, but I wouldn't 
> expect any orders of magnitude smaller complexity.  But 
> again, I may be completely wrong here; I'm very interested in 
> seeing your numbers once you've got the prototype ready.
> 
> HIP) is a result of two factors: First, it is still at the 
> idea level, without sufficient details.  Second, it is using 
> constructions that are familiar to the operator community 
> (such as tunnelling and
> optimised!) constructions.  As I argued above, I don't 
> believe there will be any significant complexity differences 
> in terms of implementation or specification complexity, once 
> all the details will be there.  And, as I argue separately 
> (both above and below), I don't believe there will be any 
> significant differences in the terms of deployment complexity, either.
> 
> 
> <For brevity, I'm skipping below things we seem to agree 
> upon. In many cases I fully agree with you, e.g., what comes 
> to the importance of deployment.>
> 
> I think I have to strongly disagree here.  I don't believe 
> the question is about tweaking.  I believe that the question 
> is about the implementation ("horizontal") dimension rather 
> than the architectural
> ("vertical") dimension.  To me, the real differences lie in 
> security constructions, and there in the underlying trust 
> model, and in the identifiers.  In LISP, the identifier 
> differences lead to your very nice LISP 1, 1.5, 2, 3 genera 
> construction, which I appreciate very much.  It is _very_ 
> nicely worked out.  But a similar set of identifier 
> structures can be applied also to SHIM6 (which is at level
> I don't see any real difference here between LISP and SHIM6 
> (and maybe HIP), since the same identifier genera (1, 1.5, 2, 
> 3) can also be applied in all two (or three) cases.
> 
> details. 
> Sorry for being obscure.  What I meant is that if we think 
> that tunnelling is a better method for encapsulation than the 
> SHIM6 context tag or the encapsulation flexibility in HIP, 
> both SHIM6 and HIP could be easily adjusted to use tunnelling.
> 
> 
> I believe that is pretty impossible, or alternatively would 
> increase the packet size to an unbearable level.  For an old 
> paper on the topic (not addressing it directly but laying 
> some theoretical  
> (Sorry, I'm offline while writing this but it can be found on 
> my publications page.)
> 
> Now, that is an interesting argument.  It may be true, 
> depending on your trust model.  Certainly, a single ISP or a 
> mutually fully trusting ISP coalition could deploy a 
> LISP-like structure without any security.  But then, what 
> would be the functional difference from using properly 
> configured, dynamic MPLS tunnels?
> 
> That is the attitude that, IMHO, has brought us with the 
> current DDoS problems.
> 
> 
> I think this is the crux of our disagreement.  I appreciate 
> your opinion, but I don't believe it to be _necessarily_ 
> true.  But then, someone needs to figure out exactly how to 
> proxy SHIM6 or HIP in the generic case.  There may be details 
> there that I cannot foresee and make such proxying approach 
> much more complex than I currently think.  But then, as I 
> said, I believe adding security to LISP makes it clearly more 
> complex than it currently looks like.
> 
> architectural benefits from the different approaches.  That 
> we haven't touched yet.  But I think it also warrants 
> distinct messages instead of burying it here.
> 
> --Pekka Nikander
> 
>

---

From: <[email-masked]>
Date: Mon, 19 Feb 2007 12:12:50 +0200

What bothers me about the LISP 1 proposal is that the IDs need be
routable in the RLOC topology for it to work. It still requires
renumbering when changing access providers. From this pespective the
LISP2 seems more attractive.

2 variants of it are offered in the LISP2 presentation. It seems to me
that combined use of the two variants would offer the good properties:
default router should intercept DNS requests (which I do not believe
will add additional latency) AND do lookup for destination EIDs that
were used without a DNS query to begin with (with additional latency and
dropping of first packets).

In scaling the LISP it seems essential that the EIDs are also from an
aggregateable space, so that same set of RLOCs could be shared for big
number of EIDs without requiring EID specific entries in the caches.

Also an interesting variant of the LISP (1.5?) would be to have the EID
be routable, but not necessarily to the destination network, but to a
kind of "EID/RLOC home agent" that could tunnel the packets to the
destination network (that would then do the ICMP setup with the source
network just like in LISP1). So instead of having separate routes to
each and every destination network on the EID space, the network would
have radically fewer number of routes in the EID space to "EID/RLOC home
agent providers" (compare to Mobile IP virtual home networks), where the
destination networks' edge routers would register their RLOCs. In
essence the LISP1.5 would function like "core-proxied route optimized
tunneled Mobile IP with virtual home networks". The kind of EIDs useful
in this variant could have short prefixes and (with IPv6) plenty of bits
left for e.g CGA (think 28 bits for prefix and 100 bits for crypto-id).

	Jarno

>From: ext Bound, Jim [mailto:[email-masked]] 
>Sent: 17 February, 2007 18:10
>To: Pekka Nikander; Dino Farinacci
>Cc: [email-masked]
>Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00
>
>simple and will work, the authors all have implemented specs 
>and architecture that works in practice running today and not 
>in theory. It also does not preclude further research and 
>debates on HIP, SHIM6, etc.
>The issues you state below are all theoretical abstractions, 
>and interesting and I now believe should be in the IRTF. LISP 
>is a reality sandwich presented that will solve in my view the 
>RAM ID from the IAB and add much other value and avoid hosts 
>for "now" messing with ID / Loc split, which we are not going 
>to solve in the year 2007 on this list IMHO.
>
>Best,
>/jim
>
>> the host implementations.
>> As I argued in the arch-d list already earlier, I do see here two 
>> almost orthogonal (i.e. mutually
>> independent) dimensions:
>> 
>dimension.  In 
>the stack 
>> that different in this sense.
>LISP being 
>> at the lowest and HIP at the highest position in the stack.  
>However, 
>> I believe the difference is small enough so that it does not really 
>> limit the implementation
>existing 
>> ones, and grows more complex (than it initially is) as the 
>details are 
>> fleshed out.
>> 
>> (e.g. 3000-4000 LoC once the security is
>expect any 
>> orders of magnitude smaller complexity.  But again, I may be 
>> completely wrong here; I'm very interested in seeing your 
>numbers once 
>> you've got the prototype ready.
>> 
>idea level, 
>> without sufficient details.  Second, it is using constructions that 
>> are familiar to the operator community (such as tunnelling and

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Tue, 20 Feb 2007 00:58:58 -0800

> number of EIDs without requiring EID specific entries in the caches.
I agree with the above points, LISP2 also seems to be the more  
promising in terms of scalability of routing table.

Current draft assumes EIDs inside a network are injected into the  
tunnel routers (ITR/ETR), which may not scale if EIDs are not  
aggregateable.
An alternative approach is to also push this information to DNS.
For instance, the information in DNS can also include (besides the  
ETR's RLOC), the last hop router EID (let's call it destRouterID)  
where the dest host is connected to.
Once the packet reaches the dest network, it's re-encapsulated by the  
ETR with a dest addr=destRouterID, and once it reaches the  
destRouterID using IGP, the outer header is stripped off and the  
packet is finally delivered to the dest host.
This approach might reduce the number of ETRs in each network as well  
as the number of entries in the global routing table.

--Ricardo

---

From: Russ White <[email-masked]>
Date: Tue, 20 Feb 2007 10:50:14 -0500

> For instance, the information in DNS can also include (besides the ETR's
> RLOC), the last hop router EID (let's call it destRouterID) where the
> dest host is connected to.
> ETR with a dest addr=destRouterID, and once it reaches the destRouterID
> using IGP, the outer header is stripped off and the packet is finally
> delivered to the dest host.
> This approach might reduce the number of ETRs in each network as well as
> the number of entries in the global routing table.

Doesn't this just push the state change problem from the distributed
routing database into the distributed naming database? In reality, at
some point we're probably going to face this--the relationship between
names and locations must be handled in real time. Today, the solutions
we have for this relate to state in NATs, and state on the end host. The
question may come down to--should this state be moved into the routing
system? If so, how should it be moved? There are a number of other
problems that swirl around this, such as security, etc, etc....

And, finally--what's the economic and social model for this move, if the
move is determined to be the best option to "solve the problem?"

:-)

Russ

---

From: Vince Fuller <[email-masked]>
Date: Tue, 20 Feb 2007 14:42:39 -0800

> destination networks' edge routers would register their RLOCs.

This is a good summary of the salient difference between LISP1 and LISP1.5.

	--Vince

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Tue, 20 Feb 2007 21:02:03 -0800

On Feb 20, 2007, at 7:50 AM, Russ White wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>> ETR's
>> destRouterID
> routing database into the distributed naming database?
The scheme is the same as LISPv2, it just appends to RLOC the EID of  
the router where the dest host is currently connected to, avoiding of  
doing routing by dest host EID at destination network.
As I understand, EIDs are not topological aggregatable, i.e., my  
laptop can have an EID, which is kept as I move from network to network.

--Ricardo

> In reality, at
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFF2xi2ER27sUhU9OQRAl40AJ4gYRHirzkZzEti8VevKdedJcwepQCeO543
> ew3A0RAnieQ/B9J70JTzMVM=
> =1TMX
> -----END PGP SIGNATURE-----

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Feb 2007 22:28:31 -0800

> LISP2 seems more attractive.

Let me try to clear up some things:

o Routable IDs means the IP address, used as an ID can be used to do  
a lookup
   in a FIB to forward a packet. That does not mean it has to be  
aligned with
   the topology that PA addressing is representing.

   If a site uses PA addresses as EIDs, this isn't much of a problem.  
The site
   can help the core scale by injecting less routes but doesn't have  
renumbering
   benefits because if it cancels it's contract with the ISP that  
assigned the
   PA block used for EIDs, it would have to renumber. However, LISP  
doesn't
   introduce this disadvantage.

   If a site uses PI addresses as EIDs, renumbering can always be  
avoided. But
   starting off PI addresses will be routable because if they are  
being allocated
   today, they are routable. We certainly want to get away from this  
and hence
   using ICMP and not relying on a third-party database  
infrastructure is also
   achievable, LISP 1.5, allows to route EIDs over a separate, non- 
congruent, very
   aggregatable topology which doesn't have the frequency of changes  
that a
   physical connection to an ISP would.

   You have to make tradeoffs, and to get the fast deployment and  
touch as few
   things as possible, LISP 1.5 is quite desirable.

o If the entire world goes to PI addresses as EIDs, then we have no  
choice to use
   a third-party and LISP 2 ala DNS or LISP 3 ala DHTs are the only  
choices.

But please be patient and look at the reason we numbered the variants  
1, 1.5, 2,
and 3. It is in the order of deployment stages. With LISP 1, we have  
to get
experience with the encapsulation (should be no surprises here), ITR  
and ETR placement, how TE will be used, as well as locator  
reachability detection and selection. That is a lot for a first phase.

Once the basic correctness is done, then we can transition to  
forwarding packets on a separate topology using LISP 1.5. There is  
work here because one needs to decide to either do:

o A configured tunnel topology with static EID-prefix routes.
o A configured tunnel topology advertising EID-prefix routes in BGP.
o Use the same Internet topology but a different VRF inside of BGP  
that has
   inter-domain reach.
o Use a different AF/SAFI in BGP for this.

And for LISP 2 and using DNS, since we really want the EID-to-RLOC  
mapping before the host sends any useful packets, we need to snoop on  
the DNS reply. That will probably sit uneasy in some people's minds.

So I was hoping that LISP 3 using DHTs would be a better model.

> 2 variants of it are offered in the LISP2 presentation. It seems to me

4 variants.

> dropping of first packets).

The thought was to intercept DNS replies which had the EID-to-RLOC  
mapping in
the Addtional Info field of the reply. This would be present because  
of the new RR associated with the entry, which the hosts would  
ignore, but the ITR would use. Comments?

> number of EIDs without requiring EID specific entries in the caches.

Absolutely. That is planned and spec'ed in the -00 version.

> network just like in LISP1).

Sure, but is this a community place? Not sure if how many sites would  
use the same box to do this. I think sites would want to put the  
configuration in their own boxes and not rely on a central place.

But the tunnel topology to route these initial packets could be homed  
at each CE router.

> So instead of having separate routes to

That was our intention of LISP 1.5.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Feb 2007 22:30:54 -0800

> tunnel routers (ITR/ETR), which may not scale if EIDs are not  

Not for LISP 2 and 3.

> where the dest host is connected to.

That is the RLOC for the EID. This is LISP 2 when using DNS or LISP 3  
when using, say DHTs.

> Once the packet reaches the dest network, it's re-encapsulated by  
> the ETR with a

You have to be more clear about "dest network". Do you mean  
destination site or last-hop subnet at the destination site?

> dest addr=destRouterID, and once it reaches the destRouterID using  
> IGP, the outer header is stripped off and the packet is finally  
> This approach might reduce the number of ETRs in each network as  
> well as the number of entries in the global routing table.

Agree, but don't understand your re-encapsulated comment.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Feb 2007 22:31:02 -0800

> This is a good summary of the salient difference between LISP1 and  

And we will add it to the next rev of the spec. Thanks!

Dino

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Wed, 21 Feb 2007 10:38:11 -0800

>> tunnel routers (ITR/ETR), which may not scale if EIDs are not  
Is there any LISPv2/3 specification besides the draft?
So if EIDs are not injected in border routers at destination network,  
how do these routers route the packets to the dest host?

> That is the RLOC for the EID. This is LISP 2 when using DNS or LISP  
> 3 when using, say DHTs.
>
I meant border router at destination network (BGP speaker).

> Agree, but don't understand your re-encapsulated comment.
What I meant is that the packet will be encapsulated twice. It's  
encapsulated by the ITR once it leaves the source network. It's  
decapsulated by the ETR border router once it gets to the destination  
network. This same ETR encapsulates again the packet to the  
desRouterID, where the dest host EID is connected to.

--Ricardo

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Feb 2007 22:08:40 -0800

> Is there any LISPv2/3 specification besides the draft?

Not yet.

> So if EIDs are not injected in border routers at destination  
> network, how do these routers route the packets to the dest host?

In LISP 1 they are injected. In LISP 1.5, they are injected into a  
routing protocol that runs on an alternate non-congruent to the  
locator topology.

>>> For instance, the information in DNS can also include (besides  
>>> the ETR's RLOC), the last hop router EID (let's call it  
>>> destRouterID) where the dest host is connected to.
>>
>> That is the RLOC for the EID. This is LISP 2 when using DNS or  
>> LISP 3 when using, say DHTs.
>>

When it is pushed into DNS, the last-hop router's IP address is  
represented as the locator for the EIDs assign to the hosts it is  
decapsulating for.

>>> dest addr=destRouterID, and once it reaches the destRouterID  
>>> using IGP, the outer header is stripped off and the packet is  
>>> finally delivered to the dest host.
> decapsulated by the ETR border router once it gets to the  
> destination network. This same ETR encapsulates again the packet to  
> the desRouterID, where the dest host EID is connected to.

You don't need to do this. Don't see the value at all.

Dino