ENRP server takeover procedure
Silverton Aron-C1710C <[email protected]>
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Hello,
I have the following suggested changes to the procedure for taking-over a
failed peer server. In particular, the Take-over Target Peer Server
procedure in Section 4.10.2. I believe that this change will simplify the
procedure by removing at least one message and eliminating a possible race
condition that exists when the aggressor, i.e., the server initiating the
take-over, fails between the PEER_TAKEOVER_SERVER message and the
PEER_OWNERSHIP_CHANGE message(s).
As the procedure is written today, a peer server will remove the failed peer
from it's peer list upon receiving the PEER_TAKEOVER_SERVER message from the
initiating server, but it will not update it's PE list until one or more
PEER_OWNERSHIP_CHANGE messages are received. This creates a period of time
when an ENRP server has PEs marked as being owned by another server which is
no longer a peer. These orphaned PEs will not be resolved until an audit
takes place or the PE realizes that its home server is no longer alive and
looks for a new one. I think that we can avoid the delay and simplify the
entire exchange as follows:
4.10.2 Take-over Target Peer Server
The initiating ENRP server SHOULD first send, via an announcement, a
PEER_TAKEOVER_SERVER message to inform all its active peers that the
take-over is enforced. The target server's ID MUST be filled in the
message. The initiating server SHOULD then remove the target server
from its internal peer list.
Then it SHOULD examine its local copy of the namespace and claim
ownership of each of the PEs originally owned by the target server,
by following these steps:
1. mark itself as the home ENRP server of each of the PEs originally
owned by the target server;
2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the
PEs. This will trigger the PE to adopt the initiating server as
its new home ENRP server;
When a peer receives the PEER_TAKEOVER_SERVER message from the initiating
server, it SHOULD update its local peer list and PE cache by following
these steps:
1. remove the target server from its internal peer list;
2. update the home ENRP server of each PE in its local copy of the
namespace to be the sender of the message, i.e., the initiating
server.
The PEER_OWNERSHIP_CHANGE exchanges are not needed in this procedure.
Regards,
Aron
Aron J. Silverton
Senior Staff Research Engineer
Motorola Labs, Networks and Infrastructure Research
Motorola, Inc.
Telephone: 847-576-8747
Fax: 847-576-3240
mailto:[email protected]