Subject: [Rserpool] Download ENRP Namespace Data from Mentor Peer

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 7 Oct 2003 11:56:53 +0200

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-masked]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 07 Oct 2003 17:45:30 -0500

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,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE/go3u32BbsHYPLWURAknPAJ42XRQpaXrSFW3LrqF8adIwmLk2bgCfWXe5
> k4Itbpl91bsu4lDM+SmdZV8=
> =WWTk
> -----END PGP SIGNATURE-----
>

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 07 Oct 2003 17:45:30 -0500

Hi, Thomas,

regards,
-Qiaobing