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

From: [email-masked] (Noel Chiappa)
Date: Thu, 19 May 2011 21:01:31 -0400 (EDT)

> From: Alia Atlas <[email-masked]>

    > 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.

I'm not sure if this is the answer, but there's some stuff I don't recall well
about operation with mobile nodes (where the mobile node contains its own ETR),
where another node (I would assume an MS, but maybe I'm confused) acts as a
proxy ETR for the real ETR to minimize the traffic to the mobile node. Maybe
that's what being alluded to here?

I certainly can't think offhand how an MR would be associated with an ETR -
although an MR would certainly be associated with a group of ITRs, which are
likely also ETRs, so perhaps what's being referred to is the MR knowing the
mappings associated with those xTRs when they are operating in ETR mode?

    > 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?

Again, it's important to remember that being authoritative for a chunk of
EID-space (which is what the ETR and MS communicate about) is _not_ the same
thing as the actual {EID -> RLOC(s)} mapping itself (which is only provided
initially by the ETR, although MRs may cache it - I don't think MS's cache
mappings, except in that proxy-ETR mode I mentioned above for use with mobile
nodes).

So when you say that "local EID-prefixes will always be provided
non-authoritatively by the Map-Resolver" I don't know what that means, because
other than the MS<->ETR registration procedure, nothing in LISP talks about
just plain old "EID-prefixes".

Did you mean 'mappings for EID-prefixes registered with the co-located MS will
always be provided non-authoritatively by the co-located Map-Resolver'? If
that MR is caching mappings, I think the answer is 'yes' (but again, I might
be out of date).

	Noel

---

From: Alia Atlas <[email-masked]>
Date: Fri, 20 May 2011 17:24:11 -0400

Noel,

On Thu, May 19, 2011 at 9:01 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Alia Atlas <[email-masked]>
>
>    > 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?
>

Yes, the current draft specifies that the Map-Resolver always provides
the non-authoritative
mappings for EID-prefixes that have been registered with a co-located MS.

Part of the problem is that I did not find the draft clear in its
separation of behavior of
a Map-Server versus a Map-Resolver and do no understand how a Map-Resolver would
have learned EID-to-RLOC mappings from an ETR....

Having read the current draft quite recently, I feel it is unclear and
underspecified.

Alia