Opened 10 years ago

Last modified 9 years ago

#42 reopened technical

On the SMR mechanism — at Version 2

Reported by: luigi@… Owned by:
Priority: minor Component: draft-ietf-lisp
Severity: - Keywords:

Description (last modified by luigi@…)

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:

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

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 Y. Rekhter's review:
This is 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

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?

Change History (2)

comment:1 Changed 10 years ago by luigi@…

  • Description modified (diff)
  • Summary changed from On the SMR mechanism (from D. Papadimitriou's review) to On the SMR mechanism

comment:2 Changed 10 years ago by luigi@…

  • Description modified (diff)
Note: See TracTickets for help on using tickets.