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

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Wed, 21 Feb 2007 23:45:05 -0800

> 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.
>
So I take that in LISPv2 EIDS are not injected anywhere, but are  
rather looked up in DNS.
A question:what if my laptop is behind a firewall connected to a  
router without public interfaces? What is my RLOC in this case?

It seems currently LISP assumes the dest host is always directly  
connected to the ETR, which is probably too restrictive. Also, the  
smaller the number of ETRs, the shorter the routing table is.
If we want to be able to accommodate non-ETR last-hop routers (but  
inside the same network as the ETRs), you need to include besides the  
RLOC, the destRouterID of the last hop routers, and re-encapsulate  
the packets at ETRs.

--Ricardo

>
>
>>>> 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.
>>>>
>>>
>>> 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?
>>>
>> I meant border router at destination network (BGP speaker).
>>
>
> 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.
>>>> 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.
>>>
>> 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.
>>
>
> You don't need to do this. Don't see the value at all.
>
> Dino
>
>
>

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Feb 2007 09:23:23 -0800

> So I take that in LISPv2 EIDS are not injected anywhere, but are  

Right.

> router without public interfaces? What is my RLOC in this case?

The firewall (assuming it's a NAT) will translate the destination  
address inserted by the host to a global address. This global  
address, at this point of the data path, is an EID. When there is a  
ITR downstream (or the NAT itself is an ITR), a new IP header is  
prepended which contain the Locator addresses.

> smaller the number of ETRs, the shorter the routing table is.

No, it does not assume that. The example provided indicated this. But  
if you want your mapping cache to be centralized, the ETR can be a  
your pair of edge CE routers.

> inside the same network as the ETRs), you need to include besides  
> the RLOC, the destRouterID of the last hop routers, and re- 
> encapsulate the packets at ETRs.

In this case, the EID is used to route *inside* the destination site.

Dino

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Thu, 22 Feb 2007 12:09:57 -0800

On Feb 22, 2007, at 9:23 AM, Dino Farinacci wrote:

>>> 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.
>>>
> No, it does not assume that. The example provided indicated this.  
> But if you want your mapping cache to be centralized, the ETR can  
> be a your pair of edge CE routers.
>
But if you don't inject EIDs inside the site (like LISPv2), how are  
you going to route by EID inside the network? The same question for  
the NAT case, how is the NAT box route by EID to the end host?

--Ricardo

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Feb 2007 12:38:07 -0800

> the NAT case, how is the NAT box route by EID to the end host?

The EIDs are already inside the site. A site today which is allocated  
a PI block (or any block for that matter) has their routers, hosts,  
subnets, and routing protocols already configured with addresses in  
that block.

Remember, this is incremental, EIDs are the host addresses you see  
today and inside of
the site is the addressing you see today. Outside of the site, you  
use locators which are the addresses you have in BGP today.

Dino

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Thu, 22 Feb 2007 21:58:16 -0800

On Feb 22, 2007, at 12:38 PM, Dino Farinacci wrote:

>> But if you don't inject EIDs inside the site (like LISPv2), how  
>> are you going to route by EID inside the network? The same  
>> question for the NAT case, how is the NAT box route by EID to the  
>> end host?
>
> The EIDs are already inside the site. A site today which is  
> allocated a PI block (or any block for that matter) has their  
> routers, hosts, subnets, and routing protocols already configured  
> with addresses in that block.
>
So in the long term, EIDs can be any number, not necessarily aligned  
with the network addresses of routers in the network - they reflect  
the ID of the host. So if the goal is to keep session alive while  
moving between networks (like it's mentioned in the draft) routers  
inside the any destination network must be able to route to an  
arbritary EID. Two options: either (1) EIDs are injected in IGP or  
(2) IGP last-hop router address is pushed to e.g. DNS to allow  
routing inside the network...

--Ricardo

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Feb 2007 06:09:03 -0800

> So in the long term, EIDs can be any number, not necessarily  
> aligned with the network addresses of routers in the network - they  
> reflect the ID of the host. So if

Yes, that is correct. We will have two namespaces, an EID namespace  
and a Locator namespace. The Locator namespace are the IP addresses  
and routes we see in the capital-I Internet today. The EID namespace  
are the IP addresses that are assigned to hosts and reside in DNS, as  
we see it today.

The split is actually happening topologically, at the site-to-ISP  
border. Where the inner addresses are EIDs and used within a site,  
and the outer addresses are locators used outside of a source or  
destination site.

I am using the term namespaces because I think this has become the  
defacto term among many people I have talked with.

> the goal is to keep session alive while moving between networks  
> (like it's mentioned in the draft) routers inside the any  
> destination network must be able to

Yes, keeping the session alive while doing "slow moves" between  
sites. I would consider "fast moves" to be a hand-set roaming from  
one part of the topology another part. We are not saying at this  
point how well LISP will work in the fast-move scenarios.

> route to an arbritary EID. Two options: either (1) EIDs are  
> injected in IGP or (2) IGP last-hop router address is pushed to  
> e.g. DNS to allow routing inside the network...

Routers route to an arbitrary EID because they know about subnet the  
EID is part of.
EIDs are not per say injected. That is the host addresses themselves  
are not injected. These EID host addresses are part of a subnet and  
are ARP for like things work today.

We really are not and don't want to change too many things.

> --Ricardo

Thanks for the discussion Ricardo. It allows me to be crystal clear  
about what our intentions are. I hope people find this valuable and  
not noise on the list.

Dino

---

From: JFC Morfin <[email-masked]>
Date: Fri, 23 Feb 2007 17:50:40 +0100

Generally (a text in preparation) there can be identified three main 
address layers in everything the human brain considers.
- fixity. What is plugged in the earth, geography, networks, 
gateways... hardware. Routing.
- mobility. All what (can) move. Logical management, software. Reaching.
- virtuality. at several levels : applications, registries, concepts, 
etc. intellectual/semantic processing?

I proposed an IPv6 solution which would split the IPv6 address 
container in these three areas, structuring a block /3 namespace to 
that end. But LISP is more interesting as it can indifferently work 
for IP4 (and the "a la" existing IPv8 solutions, including NATs) and 
for IPv6 with an off-the-shelf transparent/reversible migration path. 
And it can provide much more flexibility in these three domains and 
any number of sub-domains, and it can support any kind of protocol 
and datagram load.

The main problem is that we have up to now defaulted mobility into 
fixity. This is probably the time where we will split the single 
address into location and identity.

But we still have to accept that fixity/mobility are issues 
concerning ISPs in order to provide access to users. This does not 
really concerns the users, except that they can reach more users. 
What interests the user is his internal virtuality. In only 
associating Interface IDs with MAC or any open possibility, we have 
not yet interested the user. Because nothing has been standardised in 
terms of local addressing. What is for MAC, what is for plug and 
play, what is for direct registry interlinking, etc.

What LISP makes here, is to warranty that any scheme being developed 
and used today, will work for ever, because fixity, mobility, and 
virtualities can each have a full IPv4 or IPv6 addressing space they 
can freely use and privately standardise - in addition, not instead, 
of the ports which can resume their full role. Also because the 
encapsulation/decapsulation step can be associated with a protection 
scheme to proceed in the namespace below.

  And it provides a reasonable scheme to adopt whatever IPv12, IPv24, 
etc. we could devise to address each photon _without_ stopping 
supporting IPv4. So, it is a real warranty of user stability.

jfc

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Fri, 23 Feb 2007 18:54:42 +0100

Hi Dino,
This  draft is very interesting.
 Could you say more on what results  are expected from Lisp1 and Lisp1.5
and do you need a very large deployment (at these stages) to reach 
conclusions ?
It seems that true benefits (at least as far as routing table size is 
concerned)  will
occur only with Lisp2 or am I missing something ?

In Lisp1, where EID are just ordinary IP addresses, do you assume that 
the ITR inserts a Lisp header for all outgoing packets
(in this case what happens if there is no ETR at the destination site ?),
or do you expect that the ITR will be configured with a list of "Lisp 
enabled" foreign prefixes ?

Jean-Jacques

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 Feb 2007 11:15:50 -0800

> This  draft is very interesting.

Thanks, but the word that comes to mind for me is "challenging".  ;-)

> and do you need a very large deployment (at these stages) to reach  

Well, to test for correctness, we don't need a large deployment,  
where "large" here means mass deployment (i.e. 100s of sites). We  
just need to test and understand the different deployment scenarios  
of ITRs and ETRs as well as seeing how the Locator reachability  
design works. And I think while doing this, what I want really  
answered is how much security we really need and last but not least,  
how much EID namespace aggregation we can get.

It would be nice while we deploy if the participating sites could  
actually withdraw some prefixes from the Locator namespace and  
infrastructure. I think this will be hard because they will want non- 
LISP and LISP sites to talk to them.

But I poll the operator community to put some cycles to think about  
this.

Also, the ISPs on their own, can play with TE-ITRs and TE-ETRs in  
their own domains to see if they can withdraw more specifics because  
they are using tunnels instead. I think we can make more progress  
here because this community of people and organizations have similar  
goals/issues.

Just thinking out loud.

> It seems that true benefits (at least as far as routing table size  
> is concerned)  will

Well, I know everyone is focused on reducing routing table size. But  
let's not forget some other features LISP can bring. First, you can  
get site-multihoming where a site can decide how it's packets egress  
and now (which they couldn't do before) how their packets ingress.  
Ditto for provider-multihoming and TE, they possible can have more  
flexibility with tunnels then with longest match routing.

> In Lisp1, where EID are just ordinary IP addresses, do you assume  
> that the ITR

In all variants of LISP, the EIDs are ordinary IP addresses. Of  
course, using this sort of language doesn't really imply that  
Locators are extraordinary. But I get what you are inferring.

> inserts a Lisp header for all outgoing packets

The ITR prepends a header for traffic that is globllay addressed. If  
the destination address is local to the site, the ITR is just a plain- 
ole-router which L2 encaps and sends the packet on it's way toward  
the local destination.

> (in this case what happens if there is no ETR at the destination  

Well, good point. If the outer header is a locator, you will get an  
ICMP unreachable because the ETR is not there. But one first must  
ask, how did you get that Locator. If it was configured, in a LISP 2  
or LISP 3 case, then this could happen.

In a LISP 1 and LISP 1.5 (when globally routable EIDs exist), the  
outer destination address is the host itself. So the host would  
receive the packet. It will send a protocol unreachable because it  
won't know how to decapsulate. So it falls under the same former case.

> or do you expect that the ITR will be configured with a list of  
> "Lisp enabled" foreign prefixes ?

I'm trying to decide if I should implement static EID-prefix routes,  
not sure that is a good thing (it makes things flexible) or bad thing  
(we could cause the issues you raise). Any opinions out there?

Dino

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Feb 2007 17:46:11 +0100

>> the ITR
> In all variants of LISP, the EIDs are ordinary IP addresses. Of course, 
> using this sort of language doesn't really imply that Locators are 
> extraordinary. 

Dino,

This is why I find your terminology completely confusing. You haven't
got an ID/Loc split. You've got two levels of locators (site and global).
The cute thing is that your site locators are structured like global
locators, and can function as such to some extent. That's great, but
if you'd fix your terminology, people would be less confused.
See my message sent February 7 for more.

    Brian

ved: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP
	id l1QHi99F004807 for <[email-masked]>; Mon, 26 Feb 2007 18:44:09 +0100
Date: Mon, 26 Feb 2007 17:46:11 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Dino Farinacci <[email-masked]>
Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00
Cc: [email-masked]

>> the ITR
> In all variants of LISP, the EIDs are ordinary IP addresses. Of course, 
> using this sort of language doesn't really imply that Locators are 
> extraordinary. 

Dino,

This is why I find your terminology completely confusing. You haven't
got an ID/Loc split. You've got two levels of locators (site and global).
The cute thing is that your site locators are structured like global
locators, and can function as such to some extent. That's great, but
if you'd fix your terminology, people would be less confused.
See my message sent February 7 for more.

    Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Feb 2007 11:03:52 -0800

> This is why I find your terminology completely confusing. You haven't

We have to go this way to maintain compatibility of existing deployment.

> got an ID/Loc split. You've got two levels of locators (site and  

Right, and the site addresses are used as EIDs by the hosts for  
transport connection IDs.

> See my message sent February 7 for more.

Okay, will do.

Dino

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 26 Feb 2007 11:57:28 -0800

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
> Sent: Monday, February 26, 2007 11:04 AM
> To: Brian E Carpenter
> Cc: [email-masked]

I agree with Brian's complaint here; LISP is really about multiple
levels of locators and not really an ID/locator split, based on
traditional use of these terms.

> transport connection IDs.

and they are used also as locators by the hosts; hence they are not
really split from the host perspective.  

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Feb 2007 14:03:09 -0800

> traditional use of these terms.

LISP is both, just like GSE is.

Dino

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 26 Feb 2007 15:26:48 -0800

> Sent: Monday, February 26, 2007 2:03 PM
> To: Henderson, Thomas R
> Cc: Brian E Carpenter; [email-masked]

It's not equivalent to GSE, which actually split the IP address into ID
and locator portions.  LISP is an ID/locator separation (the draft title
uses the word separation, but also uses the word "split" internally)
only in the context of a particular address allocation and routing
policy.  Again, this is just terminology, but I think it would be more
precise to define it in terms of multiple locator spaces that are
tunneled over one another, for purposes of core routing scalability.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Feb 2007 00:01:17 -0800

> and locator portions.  LISP is an ID/locator separation (the draft  

Yes, GSE "splits" using a contiguous set of bits. LISP "separates"  
using two addresses in different parts of the packet.

> tunneled over one another, for purposes of core routing scalability.

The problem I have with the purest point of view is that we can't get  
it incrementally deployed if we do that. In LISP, the IP address in  
DNS is used as a connection-id for socket API calls and since we  
don't want to change the host, the host stack has to emit packets  
with this destination address. Having this address be a locator for a  
local scope varies on how wide your scope is. If your ITRs are on  
link with the host, the IP address emitted by the host really doesn't  
locate anything but is used as a key to find a Locator value.

Furthermore, if you change this, you can't do local routing within  
the site. We don't want to force enterprises to renumber their  
subnets or reconfigure their routing protocols just to solve the  
"global problem". If it isn't going to buy them anything, they aren't  
going to change a thing. So we are not even going to attempt a design  
that requests them to do so.

Dino