Changes between Initial Version and Version 1 of Ticket #42


Ignore:
Timestamp:
21/04/10 11:46:55 (10 years ago)
Author:
luigi@…
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #42

    • Property Summary changed from On the SMR mechanism (from D. Papadimitriou's review) to On the SMR mechanism
  • Ticket #42 – Description

    initial v1  
     1'''This ticket groups together co-related issues concerning the SMR mechanism raised by D. Papadimitriou and Y. Rekhter in their respective reviews .'''
     2
     3
     4'''From D. Papadimitriou's review:'''
     5
    16Section 6.5.2 is this technique mandatory or not (this is not
    27specified in the text). Point 5 results in obvious situations where
     
    1924control of SMR and Map-Request messages in a more systematic way to
    2025prevent ETR overloads.
     26
     27'''From Y. Rekhter's review:'''
     28
     29Section 6.5.2 Solicited-Map-Request
     30
     31 Since the xTRs don't keep track of remote ITRs that have cached their
     32 mappings, they can not tell exactly who needs the new mapping
     33 entries. So an xTR will solicit Map-Requests from sites it is
     34 currently sending encapsulated data to, and only from those sites.
     35
     36"currently" needs to be quantified. E.g., if the local xTR detected
     37change in the mapping at time T1, and sends the encapsulated data to a
     38particlar remote xTR at time T2, what is the max allowable (T2-T1) ?
     39Is it 1 sec, 1 min, 1 hour, 1 day ?
     40
     41What is the meaning of "solicit Map-Requests from sites" ? Does it
     42mean soliciting it from all the xTRs of a given site ? If yes, then
     43how would it determine all such xTRs ? And if no, and it means just
     44one xTR of a given site, then how would Solicited-Map-Request work in
     45the scenario where an xTR-A sends encapsulated data to xTR-B of a
     46given (remote) site, but that site uses some other xTR, xTR-C, to send
     47the data to xTR-A, and it is xTR-C that needs the new mapping ?
     48 
     49 The remote xTR retransmits the Map-Request slowly until it gets a
     50
     51"slowly" needs to be quantified.
     52
     53 The ETRs at the site with the changed mapping will reply to the
     54 Map-Request with a Map-Reply message provided the Map-Request nonce
     55 matches the nonce from the SMR. The Map-Reply messages SHOULD be rate
     56 limited. This is important to avoid Map-Reply implosion.
     57
     58Is the implication that during this procedure, normal new Map-Requests
     59will not be replied to in the usual way, since they won't have the
     60nonce?
     61 
     62 with an EID destination to the mapping database system. Since the
     63 mapping database system is more secure to reach an authoritative ETR,
     64
     65What is the justification for this assumption about the mapping
     66database's security?
     67