Opened 9 years ago

Last modified 9 years ago

#42 reopened technical

On the SMR mechanism

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

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
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 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
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?

Change History (5)

comment:1 Changed 9 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 9 years ago by luigi@…

  • Description modified (diff)

comment:3 Changed 9 years ago by luigi@…

  • Resolution set to fixed
  • Status changed from new to resolved

Text has been modified to fix the issue.

comment:4 Changed 9 years ago by luigi@…

  • Status changed from resolved to closed

comment:5 Changed 9 years ago by yakov@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

The new text is still inadequate:

Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending
encapsulated data to for the last minute. In particular, an ETR will
send an SMR an ITR to which it has recently sent encapsulated data.

"recently" in the last sentence above needs to be quantified.

What is the meaning of "solicit Map-Requests from those sites" ? Does it
mean soliciting it from all the xTRs of a given site, or only some ?

Since the

mapping database system is more secure to reach an authoritative ETR,
it will deliver the Map-Request to the authoritative source of the
mapping data.

"more secure" relative to what ? What is the justification for this assumption about the mapping database's security?

Note: See TracTickets for help on using tickets.