RE: Download ENRP Namespace Data from Mentor Peer

Hi Thomas and Qiaobing,

As Qiaobing pointed out there are many possible race conditions that can
occur depending on who the home ENRP server for the PE is and who the mentor
peer server for the new ENRP server is.  That being the case, the
PEER_NAME_UPDATE would seem to make more sense if the PE that changes its
information or deregisters is homed to the ENRP server acting as the mentor.
In any event, everything will get straightened out eventually, but I could
go so far as suggesting that:


Upon receiving the final PEER_NAME_TABLE_RESPONSE from the mentor peer, the
new ENRP server SHOULD initiate the audit and synchronization procedures to
account for any race conditions that may be existed during the initial name
space transfer.


This is probably more along the lines of a best practice or an
implementation note, and perhaps it doesn't belong in the protocol draft.

Aron

Xie Qiaobing-QXIE1 wrote:
> Hi, Thomas,
> 
> The issue you discuss here is simply a race condition between
> ASAP and ENRP. Since ASAP and ENRP are two separately protocols,
> there will be a lot of race conditions that could occur in
> operation. And we realize this situation from very beginning. Our
> strategy has been to allow the discrepancies to occur and to rely
> on the auditing and re-sync procedures to bring the name servers
> back to consistency. The reasoning is simply - it would be too
> expensive to address the race conditions one by one and it
> wouldn't make much sense either if we only address one race
> condition without fixing the others... So my view is to stay with
> the overall design strategy and let the auditing and re-sync
> procedures to take care of the inconsistency.           
> 
> regards,
> -Qiaobing
> 
> Thomas Dreibholz wrote:
>> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Hi all,
>> 
>> when an ENRP server requests a namespace copy from a mentor peer
>> by multiple PEER_NAME_TABLE_REQUEST / PEER_NAME_TABLE_RESPONSE
>> cycles during startup, the mentor peer must also transmit
>> PEER_NAME_UPDATES to the requesting name server. Otherwise,
>> namespace inconsistency can be caused. 
>> 
>> Example without PEER_NAME_UPDATE:
>> 1. PEER_NAME_TABLE_RESPONSE with information about PE1.
>> 2. PE1 updates its policy parameters or deregisters.
>> 3. PEER_NAME_TABLE_REQUEST -> PEER_NAME_TABLE_RESPONSE with
>> remaining parts of the namespace. => The requesting nameserver
>> still has PE1's old data. 
>> 
>> Example with PEER_NAME_UPDATE:
>> 1. PEER_NAME_TABLE_RESPONSE with information about PE1.
>> 2a. PE1 updates its policy parameters or deregisters. 2b.
>> PEER_NAME_UPDATE for PE1. The new name server can update the PE1
>> entry or remove it. 
>> 3. PEER_NAME_TABLE_REQUEST -> PEER_NAME_TABLE_RESPONSE with
>> remaining parts of the namespace. 
>> 
>> Therefore, section 4.2.3 of the ENRP draft should be extended by
>> requiring the mentor peer to send PEER_NAME_UPDATEs and the new
>> nameserver to handle these messages.
>> 
>> Best regards
>> - --
>> ======================================================================
>>  = Dipl.-Inform. Thomas Dreibholz
>> 
>>  University of Essen,                            Room ES210
>>  Inst. for Experimental Mathematics              Ellernstraße 29
>>  Computer Networking Technology Group            D-45326
>> Essen/Germany 
>> -
>>  -----------------------------------------------------------------------
>>  E-Mail:     [email protected] Homepage:  
>> http://www.exp-math.uni-essen.de/~dreibh
>> ======================================================================
>> =  
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.2 (GNU/Linux)
>> 
>> iD8DBQE/go3u32BbsHYPLWURAknPAJ42XRQpaXrSFW3LrqF8adIwmLk2bgCfWXe5
>> k4Itbpl91bsu4lDM+SmdZV8= =WWTk
>> -----END PGP SIGNATURE-----
>> 
>> _______________________________________________
>> rserpool mailing list
>> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool
> 
> 
> _______________________________________________
> rserpool mailing list
> [email protected] https://www1.ietf.org/mailman/listinfo/rserpool