Subject: [lisp] #42: On the SMR mechanism (from D. Papadimitriou's review)

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 20 Apr 2010 08:32:13 -0000

#42: On the SMR mechanism (from D. Papadimitriou's review)
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  minor                          |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
 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.

-- 
Ticket URL: <http://64.170.98.42/wg/lisp/trac/ticket/42>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 11:46:55 -0000

#42: On the SMR mechanism
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  minor                          |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
Description changed by luigi@…:

> control of SMR and Map-Request messages in a more systematic way to

New description:

 '''This ticket groups together co-related issues concerning the SMR
 mechanism raised by D. Papadimitriou and Y. Rekhter in their respective
 reviews .'''

 '''From D. Papadimitriou's review:'''

 '''From Y. Rekhter's review:'''

 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?

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/42#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 12:26:00 -0000

New description:

 '''This is Comment 34'''

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/42#comment:2>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues