Subject: Re: [lisp] Questions on Map-Resolver operation

From: [email-masked] (Noel Chiappa)
Date: Thu, 19 May 2011 14:39:03 -0400 (EDT)

> From: Ravi Bhagavatula <[email-masked]>

    > - An MR which receives an Encapsulated Map Request (EMR) will send a
    > non-authoritative Map-Reply to the iTR ONLY if (a) it has up-to-date info
    > w.r.t to the mapping database, (b) it is operating in a caching mode, and
    > (c) it has the requested eid-to-rloc mapping

I _think_ that is correct, but I'm a bit out of the loop about how MR mapping
caching works now, so hopefully someone else can confirm (in particular, when
does an MR request that the Map-Reply come to it versus when does the Map-Reply
go directly to the requesting ITR - presumably it only does the former if it is
caching, and we accept the slight delay in getting the mapping back to the
original ITR, caused by sending it via the MR).

    > - Ditto for a Negative Map-Reply when it doesn't have the eid-to-rloc mapping.
    > - In all other cases, the MR would forward the request to the MS. This
    > request would be sent over the ALT if it exists. Else, the MR would need
    > to be told how to get to the MS, and the request is forwarded accordingly
    > - The MS would re-encapsulate the request onto the appropriate eTRs.

I think that all sounds correct (repeat caveat about being a bit out of date).

    >> there are circumstances in which a single mapping request can return
    >> multiple mappings, which is in the case where there are nested mappings.
    >> (E.g. 10/8 to one RLOC, and 10.1/16 to another. I think we decided to
    >> allow that, right?)
    >> A request for 10.2.x.y has to return both mappings, because if it only
    >> returns the 10/8 one, a later packet to 10.1.a.b will go to the wrong ETR.

    > AFAIK, the only situation wherein we would have multiple RLOCs associated
    > with a given EID is when these RLOCs have different priorities/weights
    > associated with them.

We seem to be having a miscommunication. I am not speaking of a single EID
mapping to multiple ETRs' RLOCs (which does indeed happen in the case you
mention, along with others - e.g. multiple ingress points, either for
redundancy/reliability, or for optimal ingress vis-a-vis the sender).

I am talking about cases where a Map-Request is sent for a single EID, and for
proper operation, the Map-Reply _must_ contaim multiple _mappings_ (i.e. more
than one {EID -> RLOC(s)} tuple).

    > Why would 10.2.x.y/32 in your example [above] return 10.0.0.0/8 and
    > 10.1.0.0/16 (since 10.2.x.y/32 is not a part of the 10.1.0.0/16 net)?

It would have to return the _mappings_ for both 10/8 and 10.1/16 to prevent the
following scenario: An ITR requests a mapping for 10.2.x.y. The request is
forwarded to one of the ETRs which is authoritative for 10/8, which returns a
{10/8 -> RLOC_set_1} mapping to the ITR. Some time later the ITR needs to send
a packet to 10.1.a.b, looks in its local cache of mappings, finds the 10/8
entry, says 'oh, that works', and uses it to send the packet - unaware that
there is also a {10.1/16 -> RLOC_set_2} mapping in existence out there, one
which it does not have, _and has no way to know it needs to ask for_.

The only way to deal with this (other than some complex mechanism) is to either
i) not allow nested mappings (which I guess we decide to allow in part because
how do you prevent people from doing it), or ii) treat all the mappings of a
nested mapping as an atomic set which always get sent, stored, discarded etc as
an indivisible unit. (You can't even send them in separate packets because what
happens if one packet gets lost? There is no mechanism to notice that.)

    > To rephrase my original question, is there any merit in allowing only 1
    > Record in an EMR for a given requested EID (as the MS would only need to
    > replicate the entire message, not a part of the message) when it sends it
    > out to the eTR.

EMR is potentially ambiguous - did you mean Encapsulated Map-Request, or
Encapsulated Map-Reply (although I guess Map-Replies are never encapsulated -
or are they, as a way of making MR caching work - I forget the details of how
that works)?

A Map-Request currently only contains a single mapping request (see the main
LISP spec, section 6.1.2., "Map-Request Message Format" - "a sender MUST only
send Map-Requests containing one record") although the packet format does support
more than one, but this capability is unused at the moment.

As explained above, the Map-Reply _has_ to be able to hold multiple
records/mappings if nested mappings exist.

	Noel

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 May 2011 15:00:43 -0400

Noel & Ravi,

On Thu, May 19, 2011 at 2:39 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Ravi Bhagavatula <[email-masked]>
>
>    > - An MR which receives an Encapsulated Map Request (EMR) will send a
>    > non-authoritative Map-Reply to the iTR ONLY if (a) it has up-to-date info
>    > w.r.t to the mapping database, (b) it is operating in a caching mode, and
>    > (c) it has the requested eid-to-rloc mapping
>

[Alia] The MS draft says:

  "Upon receipt of an Encapsulated Map-Request, a Map-Resolver de-
   capsulates the enclosed message then searches for the requested EID
   in its local database of mapping entries (statically configured,
   cached, or learned from associated ETRs).  If it finds a matching
   entry, it returns a non-authoritative LISP Map-Reply with the known
   mapping."

I did not see any indication from the draft that an ETR is supposed to register
all the RLOCs associated with an EID-prefix, so I am not sure how an MR can
assume it knows the mapping unless it is statically configured or cached.

Also, if a Map-Resolver and Map-Server are co-located, doesn't that mean that
local EID-prefixes will always be provided non-authoritatively by the
Map-Resolver?

Alia

---

From: Ravi Bhagavatula <[email-masked]>
Date: Thu, 19 May 2011 12:38:24 -0700

Thanks a bunch. I guess I missed the part about a single record in the
spec. Getting old, thats what it is...:-(.

And yes, the query was with respect to the Encapsulated Map Requests.

Thanks,
Ravi Bhagavatula
San Jose, CA

On Thu, May 19, 2011 at 11:39 AM, Noel Chiappa <[email-masked]> wrote:
>    > - Ditto for a Negative Map-Reply when it doesn't have the eid-to-rloc mapping.
>    > - In all other cases, the MR would forward the request to the MS. This
>    > request would be sent over the ALT if it exists. Else, the MR would need
>    > to be told how to get to the MS, and the request is forwarded accordingly
>    > - The MS would re-encapsulate the request onto the appropriate eTRs.
>
>    >> there are circumstances in which a single mapping request can return
>    >> multiple mappings, which is in the case where there are nested mappings.
>    >> (E.g. 10/8 to one RLOC, and 10.1/16 to another. I think we decided to
>    >> allow that, right?)
>    >> A request for 10.2.x.y has to return both mappings, because if it only
>    >> returns the 10/8 one, a later packet to 10.1.a.b will go to the wrong ETR.
>
>    > AFAIK, the only situation wherein we would have multiple RLOCs associated
>    > with a given EID is when these RLOCs have different priorities/weights
>    > associated with them.
>
>    > Why would 10.2.x.y/32 in your example [above] return 10.0.0.0/8 and
>    > 10.1.0.0/16 (since 10.2.x.y/32 is not a part of the 10.1.0.0/16 net)?
>
>    > To rephrase my original question, is there any merit in allowing only 1
>    > Record in an EMR for a given requested EID (as the MS would only need to
>    > replicate the entire message, not a part of the message) when it sends it
>    > out to the eTR.
>

---

From: Ravi Bhagavatula <[email-masked]>
Date: Thu, 19 May 2011 16:31:50 -0700

Dear Alia,

> assume it knows the mapping unless it is statically configured or cached.
##RaviB: My understanding of the operation is that the MR knows about
mapping either from its local store (cached, or statically
configured), or from the ALT. If the ALT is up-to-date, the MR does
not have any reason to claim any in-accuracy in the mapping
information. However, I believe, there is always a possibility of the
fact that the MR's view of the mapping could be "lagging behind" the
ALT, and hence the "non-authoritative" Map-Reply.

> local EID-prefixes will always be provided non-authoritatively by the
##RaviB: Again, as I understand it, only if the afore-mentioned 3
conditions are met. If the MR is operating in a non-caching mode
(without an ALT and without any statically configured mappings), it
would promptly forward these requests over to the MS. A co-located
MS/MR is simply a special case of an MR forwarding the request to a
co-located MS.

LISP gurus, do please correct me if I am way off course.

Thanks,
Ravi Bhagavatula