Subject: [lisp] Issue Title (number): SMR handling (42)

From: Darrel Lewis <[email-masked]>
Date: Fri, 6 Aug 2010 15:43:05 -0700

Issue Title (number):  SMR handling (42)
Draft Section: 6.5.2
Issue Description: SMR Mechanism

Comments:

From Demitri:

Section 6.5.2 is this technique mandatory or not (this is not
specified in the text). Point 5 results in obvious situations where
the ETR may never stop sending SMR messages. As there is no means a
way to prevent that ITR use “old mappings” this result in a deadlock
situation (a non-cooperating ITR prevents ETR to stop sending SMR
messages).

Section 6.5.2 states “So an xTR will solicit Map-Requests from sites
it is currently sending encapsulated data to, and only from those
sites.” Thus instead of keeping track of ITR, ETR keep track of the
encapsulated traffic ITR send. The mechanism is often cited but never
explained e.g. over which time period is the ETR expected to determine
the set of communicating ITR’s ?

Section 6.5.2 states “Map request” shall be rate limited … rather
unclear: assume a single ETR sends one SMR message to 10 different
ITRs how the 10 ITR will individually rate limit a single Map Request
in response to this SMR message. It is thus worth specifying the flow
control of SMR and Map-Request messages in a more systematic way to
prevent ETR overloads. 

From Yakov (his comment 34)

Section 6.5.2 Solicited-Map-Request

   Since the xTRs don't keep track of remote ITRs that have cached their
   mappings, they can not tell exactly who needs the new mapping
   entries. So an xTR will solicit Map-Requests from sites it is
   currently sending encapsulated data to, and only from those sites.

"currently" needs to be quantified. E.g., if the local xTR detected
change in the mapping at time T1, and sends the encapsulated data to a
particlar remote xTR at time T2, what is the max allowable (T2-T1) ?
Is it 1 sec, 1 min, 1 hour, 1 day ?

What is the meaning of "solicit Map-Requests from sites" ? Does it
mean soliciting it from all the xTRs of a given site ? If yes, then
how would it determine all such xTRs ? And if no, and it means just
one xTR of a given site, then how would Solicited-Map-Request work in
the scenario where an xTR-A sends encapsulated data to xTR-B of a
given (remote) site, but that site uses some other xTR, xTR-C, to send
the data to xTR-A, and it is xTR-C that needs the new mapping ?

   The remote xTR retransmits the Map-Request slowly until it gets a

"slowly" needs to be quantified.

   The ETRs at the site with the changed mapping will reply to the
   Map-Request with a Map-Reply message provided the Map-Request nonce
   matches the nonce from the SMR. The Map-Reply messages SHOULD be rate
   limited. This is important to avoid Map-Reply implosion.

Is the implication that during this procedure, normal new Map-Requests
will not be replied to in the usual way, since they won't have the
nonce?

   with an EID destination to the mapping database system. Since the
   mapping database system is more secure to reach an authoritative ETR,

What is the justification for this assumption about the mapping
database's security? 

Response:

Dear Yakov-

Thank you for your contribution to draft-ietf-lisp-06.txt. The draft authors
have reviewed your comments above and have attempted to changed the draft's
text accordingly.   The text now indicates that SMRs can have a global or 
per SMR destination rate-limiters.  We also added text that we hope 
clarifies the Solicit Map Request procedures. We believe these changes 
have resolved  this issue, but if you feel that further changes are 
warranted please bring this issue to the LISP working group mailing 
list, [email-masked], for further discussion. 

	Thanks!
	Darrel, for the LISP document authors