Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08

From: Terry Manderson <[email-masked]>
Date: Mon, 20 Jun 2011 20:55:47 -0700

We, the Co-Chairs, are calling the LC closed for this item.

It was held open beyond the end date to ensure adequate time was given for
substantive review.

The write-up will commence soon.

Thanks
Terry

On 2/05/11 10:09 AM, "Terry Manderson" <[email-masked]> wrote:

> All,
> 
> The authors of draft-ietf-lisp-ms-08 have requested a work group last call.
> 
> Here starts the last call for this document, Joel and I will end the last
> call on Monday the 16th May, 2011.
> 
> Please review the draft and provide any last comments.
> 
> Cheers
> Terry
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Vince Fuller <[email-masked]>
Date: Thu, 23 Jun 2011 15:15:31 -0700

> a) When an ETR sends a Map-Register to a Map Server, does the ETR have
> to include all the RLOCs associated with the EID-prefix and
> specifically even those not associated with that particular ETR?  From
> what I understood from the draft, the RLOCs are used to either forward
> Map-Requests to the ETR as indicated in Sec. 3
>   "Intermediate ALT routers forward Map-Requests to the Map-Server
>   that advertises a particular EID-prefix and the Map-Server forwards
>   them to the owning ETR, which responds with Map-Reply messages."
> 
> or, as specified in Sec 4.4, to directly provide the RLOCs in a Map-Reply:
>    "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 don't see any language that explicitly defines what set of RLOCs
> should be included.

The full list of RLOCs is returned in a Map-Reply from an ETR to an ITR.
An ETR is not required to supply the full set of RLOCs when it registers
with a Map-Server; the ETR need only need provide those RLOCs that it wishes
the MS to use when forwarding a Map-Request to the ETR.

> b) What does a Map-Server do when it gets Map-Register messages from
> different ETRs for the same EID-prefix?  This seems to me to be a
> likely case where for resiliency there could be 2 ETRs and each would
> register with two Map-Servers.  Even if all the RLOCs are supposed to
> be included, what happens when there is a chance and one ETR is
> (temporarily) out of sync with the other?

Each ETR for a particular EID-prefix is expected to register with all of
the Map-Servers that publish that prefix into the mapping database. When
a Map-Server receives an Encapsulated Map-Request for that prefix, it sends
to one of the registered ETRs. The exact process that it uses for distributing
the Map-Request load among multiple registered ETRs is not specified but
round robin would be a reasonable choice. If one ETR has out-of-date
information relative to the others, then yes, temporary inconsistencies
may result, just as is the case with any other distributed database (i.e.
multi-homed sites connected via BGP).

> c) If an ETR is supposed to send all the RLOCs associated with an
> EID-prefix in a Map-Register message, then how is the R-bit for each
> locator record specified by the Map-Server?  Does the Map-Server
> confirm reachability to each of the RLOCs specified before sending any
> Map-Replies?

I will have to defer to Dino to answer this detail.

> d) The Map-Server is described in the Introduction as:
>    "a Map-Server, which learns authoritative EID-to-RLOC mappings from
>    an ETR and publish them in the database."
> I found this confusing, since the mapping service seems to me to be
> about determining which ETR (or proxy) to ask for the EID-to-RLOC
> mapping and is providing an lookup service to get to the ETR and not
> necessarily the full RLOC mapping.

Please suggest alternative text.

> e) For clarification, why does a Map-Resolver return a Map-Reply for
> EID-prefixes in its local database?  I could see doing that if the ETR
> had requested proxying, but if not - why is there a potential
> difference in what is returned for a local Map-Request versus a remote
> one?  As I understand it, in the remote case, the Map-Request is
> unencapsulated (as per Sec 4.4 (1)) and is therefore handed to the ETR.

A single device may act as both a Map-Server and a Map-Resolver. In such
a situation, a Map-Resolver will consult its local database to see if it
is also configured as a Map-Server for the EID-prefix being requested.

> f) Further, the appropriate behavior of a Map-Resolver when proxying
> is requested is NOT specified anywhere.

Please provide suggested text to describe this behavior.

> g) On p.6, a negative LISP Map-Reply is sent, but the details of the
> action selected is not defined anywhere.  I assume that the draft
> means to specify as natively forward, but as written I did not find it
> clear (perhaps because I didn't have the Map-Reply packet format
> memorized).

I will reword this section to reference the action codes defined in the
LISP base document.

> h) What is the purpose of frequently (1/min) resending the
> Map-Register message?  It is only verifying that the ETR still owns
> the EID-prefix?  If it is verifying liveness - why is that ETR special
> compared to others whose RLOCs are also given.  Why not depend on the
> underlying routing to be sure of liveness?

It is a simple keepalive mechanism between an MS and an ETR to ensure that
not only is the ETR reachable but that it both responsive and wants the MS
to continue to publish its EID prefixes in the mapping database. Underlying
routing would not accomplish this.
> 
> i) typo on p.8 item (1), 3rd line:  "mapaping" -> "mapping"
> 
> j) typo in 2nd paragraph, last sentence in Sec 4.1:
>    "Using the Map-Resolver greatly reduces both the complexity of the
>    ITR implementation the costs associated with its operation."
>                      ^^
>                      and

Thanks, fixed in -09.

	--Vince
	(for the other co-authors)

---

From: Vince Fuller <[email-masked]>
Date: Thu, 23 Jun 2011 15:26:21 -0700

> is requested is NOT specified anywhere.

A Map Resolver doesn't act as a proxy; a Map Server may. If a Map Server
is acting as a proxy, then it returns a Map-Reply on behalf of a registered
ETR that has requested proxy service.

	--Vince

---

From: Alia Atlas <[email-masked]>
Date: Fri, 24 Jun 2011 04:21:18 -0400

Vince,

Thanks for the response.  My comments are in-line.

> the MS to use when forwarding a Map-Request to the ETR.

OK - my concern is that a Map-Server may implement both types of actions - as
a Map-Resolver and a Map-Server.  ("A single device may implement one or both
types of operation.")

In Sec 4.4, it says that Map-Resolver may use "its local database of
mapping entries (statically configured, cached, or learned from
associated ETRs)".  However, I saw no discussion of how a Map-Resolver
might learn mappings from associated ETRs.  I therefore assumed that
"learned from associated ETRs" is via the Map-Register messages that
an ETR would send.

I don't know how an ETR would know whether its Map-Server is serving
as a Map-Resolver as well, except via manual configuration.

Therefore, I think it would be very useful to add explicitly

"When an ETR sends a Map-Register message to a Map-Server, the ETR
MUST include at least one locator, but need not include the full
locator-set.  These records, stored by a Map-Server, should be used
for directing Map-Requests and SHOULD NOT be used in a Map-Resolver
operation."

in Sec 4.2

> multi-homed sites connected via BGP).

Ok - makes sense.  Thanks for the clarification.

> I will have to defer to Dino to answer this detail.

Ok - I think I meant the Map-Resolver operation here.

> Please suggest alternative text.

"a Map-Server, which learns the authoritative ownership of EID-prefixes by ETRs
from those ETRs and publishes those EID-prefixes in the database."

Feel free to word-smith

> is also configured as a Map-Server for the EID-prefix being requested.

Do you mean configured to proxy-reply?  Is that the only case where you think
a Map-Resolver should respond itself?  Could you clearly state that?  It seems
like a Map-Resolver could have lots of things in its local database (cached,
statically configured, etc.) as per Sec 4.4.

> Please provide suggested text to describe this behavior.

Here's the start of text to go towards the end of Sec. 4.2:

"When an ETR sets the proxy-map-request bit in its Map-Register, the ETR
MUST include complete locator-set(s) in the included record.   The ETR MUST
set the L-bit associated with at least one locator; this will be used
by the Map-Server
to verify reachability and to forward Map-Requests when proxying is
not feasible.

An ETR SHOULD be able to provide Map-Replies even when it has
requested proxying.  When an
ETR's registration is removed by the  Map-Server, of course no more proxying
is done by the Map-Server.  If a Map-Server can no longer reach the source RLOC
from which the ETR sent the most recent Map-Register message, then the
Map-Server
should pause in proxying until reachability is restored.

When a Map-Server sends a proxied Map-Reply in response to a Map-Request,
as specified in [LISP], it clears the Authoritative bit in  the
message and clears the L
bits associated with each locator.  To properly set the R-bits
associated with each locator, a Map-Server
SHOULD determine if it has a current valid route to the specified RLOC
and set the
R-bit for that locator to 1 if so and 0 otherwise.  To determine the
Record TTL to be sent in
a proxied Map-Reply, the Record TTL that is included in the
Map-Register message should be
decreased by the number of seconds since the last Map-Register message
was received.  This is to
better support mechanisms such as Clock Sweep [LISP]"

I do have two open questions around the correct behavior.
   i) Should the Record TTL just be set to what is sent instead of
being decremented?  If an ETR is
      doing Clock Sweep, shouldn't that ETR also send out updated
Map-Register messages?

  ii) How should overlapping prefixes be handled?  I.e. does an ETR
send a Map-Register with all the
     EID-prefixes and then the Map-Server determines which need to be
sent in response to a Map-Request?
     Should a Map-Server just send the whole record that was
registered for any match within it?  I can see the
     argument both ways and would, naturally, like to know your thoughts.

> I will reword this section to reference the action codes defined in the

Thanks - the problem with not having this all embedded in memory already.

> routing would not accomplish this.

Ok - seems a bit heavy-weight to me, but it does work for that.  If
you wanted to
add that first sentence in, I'd cheer :-)

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 24 Jun 2011 04:23:00 -0400

> ETR that has requested proxy service.

True - but the logic is specified for a Map Resolver to consult its
local database...

I've sent you copious text that I think describes the proxying behavior

Alia