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

From: Terry Manderson <[email-masked]>
Date: Sun, 1 May 2011 17:09:05 -0700

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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 May 2011 17:05:27 +0300

The document is in a very good shape. I have one comment, however.

On page 5 there is an example which is confusing to me. The text says
"...an ITR should prefer querying an ETR learned through the ALT
network..." The use of term "querying" doesn't look accurate. If the ITR
is querying the ETR it should know the RLOC of ETR. How else it would
query it?  But if it knew the RLOC of the ETR  then it had the mapping
for the EID to RLOC in its cache, right? As the ITR is trying to resolve
the EID to RLOC it can not know the  mapping, but should act as if it
was the first hop ALT router and forward the unencapsulated Map-Request
on to the distributed mapping database in the same way  as Map-Resolver
would have done. The RLOCs of ETRs are not distributed over the ALT, but
the EID-prefixes.

Best regards
Hannu    

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Terry Manderson
Sent: Monday, May 02, 2011 3:09 AM
To: [email-masked]
Subject: [lisp] last call for draft-ietf-lisp-ms-08

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.

Cheers
Terry

_______________________________________________
lisp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Vince Fuller <[email-masked]>
Date: Tue, 3 May 2011 14:10:37 -0700

> would have done. The RLOCs of ETRs are not distributed over the ALT, but

I agree that this paragraph is poorly worded and propose that it be
re-written as follows:

  Note that an ITR may be configured to both use a Map-Resolver
  and to participate in a LISP+ALT logical network. In such a
  situation, the ITR should use send Map-Requests through the
  ALT network for any EID-prefix is learned via ALT BGP.
  Such a configuration is expected to be very rare, since there
  is little benefit to using a Map-Resolver if an ITR is already
  using LISP+ALT. There would be, for example, no need for such
  an ITR to send a Map-Request to a possibly non-existent EID
  (and rely on Negative Map-Replies) if it can consult the ALT
  database to verify that an EID-prefix is present before sending
  that Map-Request.

Does this resolve your concerns? If so, I will include this change in
draft-ietf-lisp-ms-09.

	--Vince

---

From: Vince Fuller <[email-masked]>
Date: Tue, 3 May 2011 15:07:18 -0700

> I agree that this paragraph is poorly worded and propose that it be

One of my colleagues, Gregg Schudel, pointed out several typos in my
proposed text. Here is the revised version:

  situation, the ITR should send Map-Requests through the
  ALT network for any EID-prefix learned via ALT BGP.

	Thanks,
	--Vince

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 6 May 2011 15:27:02 +0300

This resolves very well my concerns.

Thank you

Best regards
Hannu 

-----Original Message-----
From: ext Vince Fuller [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2011 1:07 AM
To: Flinck, Hannu (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [lisp] last call for draft-ietf-lisp-ms-08

	Thanks,
	--Vince

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2011 18:26:09 -0400

This draft is clear and well-written. I do have a few questions (and
typos):

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.

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?

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?

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.

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.

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

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

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?

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

Looking forward to your responses,
Alia