Subject: [lisp] Encapsulated map requests to the Map Resolver

From: "Damian Lezama" <[email-masked]>
Date: Thu, 2 Apr 2009 20:58:07 -0700

Hi,

I’m trying to understand why the map requests sent to a Map Resolver have to
be encapsulated. The ITR has to know in advance the Map Resolver RLOC,
that’s for sure, is it really necessary for the ITR to encapsulate this
message? What will it put in the inner header, an also known Map Resolver
EID?

Thanks,

Damián

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 2 Apr 2009 22:01:28 -0700

> I’m trying to understand why the map requests sent to a Map Resolver  
> have to be encapsulated. The ITR has to know in advance the Map  
> Resolver RLOC, that’s for sure, is it really necessary for the ITR  
> to encapsulate this message? What will it put in the inner header,  
> an also known Map Resolver EID?

It's because a Map-Request is spec'ed out to have a destination  
address set to the EID being sought. To get the Map-Request from the  
ITR to the map-resolver, you need RLOCs in the source and destination  
addresses. Therefore, we encapsulate so the outer header can have RLOCs.

Another reason is to get IPv6 to work over an IPv4 infrastructure.  
That is, if an IPv6 Map-Request is sent for an IPv6 EID and the path  
to the map-resolver does not support IPv6 forwarding, we need to  
encapsulate in a IPv4 header to get the Map-Request to the map-resolver.

In the prototype implementation we have a command like this in the ITR:

	ipv6 lisp itr map-resolver <mr-ipv4-address>

Where IPv6 Map-Requests are sent to the IPv4 address in <mr-ipv4- 
address>.

There is another case why we want to encapsulate Map-Requests. When  
the map-resolver gets the encapsulated Map-Request, we want it to  
strip the outer header and forward what's inside. We want the inner  
packet to not be touched by the map-resolver so we can debug on the  
ALT the source of the Map-Request (which is the ITR).

Dino

---

From: "Damian Lezama" <[email-masked]>
Date: Fri, 3 Apr 2009 10:20:00 -0700

Hi,

Great, clear enough, thanks.

Another issue that I have some doubts about is the role of the ETRs sending
map replies when they do not take part in the ALT topology (they just send
map registers to a Map Server that takes care).

The one in the ALT that knows how to reach the ETR (and therefore can
forward the Map Request to it) already has the mapping, so it can reply
instead of forwarding it to the ETR (in your schema I think this Map Server
has to be also a Map Resolver in order to do that). Can you provide some
practical scenarios where these "no ALT ETRs" replying to the Map Requests
is a requirement? Thanks.

Regards,
Damián

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Thursday, April 02, 2009 10:01 PM
> To: Damian Lezama
> Cc: [email-masked]
> Subject: Re: [lisp] Encapsulated map requests to the Map Resolver
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 3 Apr 2009 18:43:04 -0700

> map registers to a Map Server that takes care).

But it is a authenticated leaf which tells the map-server that it  
should forward Map-Requests to it.

> forward the Map Request to it) already has the mapping, so it can  

The packet format of a Map-Register encodes something that looks like  
a map-cache entry but we do not, at this time, want the map-server to  
proxy reply for the ETRs. The ETRs are the authoritative source of the  
site's mapping and it wants to reply with up to date R-bits so the  
requester knows the current up/down status of each RLOC. Plus the site  
may want to modify the priority and weight per RLOC for policy  
reasons. That all needs to be controlled at and by the site.

Dino