Re: AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13
Qiaobing Xie <[email protected]> Fri, 22 Feb 2008 17:54:53 -0600
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
Hi, Magnus, Let me to try to give an answer to the questions. Magnus Westerlund wrote: > Hi, > > I think the update provided in November solved most of the issues for > ENRP. However, there are still a few that I am missing answers or > resolution to. It might be that I am missing some explanation email to > these issues. Please help me ensure that we take care of all the issues. > > Magnus Westerlund skrev: > >> ENRP: >> >> E4. Section 2.3: What I don't understand is why the Pool Entry format >> isn't a TLV in itself with the sub TLVs so that one can skip all the PEs >> to the next Pool Entry. >> For the integrity of the pool, the receiver MUST NOT skip a Pool Entry. For this reason, TLV is not use for the Pool Entry for compactness of the message (we are more concerned about the size of the message here: ENRP_HANDLE_TABLE_RESPONSE message is potentially the biggest msg in the protocol). >> E6. TAKEOVER: I am bit frightened that a malicious server that ignore >> ENRP_PRESENCE message can force a takeover. No one can protest a single >> bit. I also find it strange that there is no "R"eject bit in the >> ENRP_INIT_TAKEOVER_ACK. If two servers that initiated takeover at the >> sametime reach each other there are no way to indicate that you are the >> looser and I reject your initiation because I am the winner. See also >> below. >> Firstly, we assume that mutual trust among servers are ensured. We also have the tie-break algorithm that is based on the "when sense a competition, alway back-off" principle and the server IDs give a deterministic order to break any tie. Full details of this is given in Section 3.5.1. >> >> E22, section 3.10.2: How long is the TAKEOVER_ACKS valid? I guess there >> is an assumption that the Initiating server will send an enforcement as >> soon as it has received ACKs from all other. >> Yes, the enforcement is the sending of the ENRP_TAKEOVER_SERVER message by the Initiating server, as specified in the following text: " Once the initiating server has received the ENRP_INIT_TAKEOVER_ACK message from all of its currently known peers (except for the target server), it MUST consider that it has won the arbitration and MUST proceed to complete the take-over, following the steps described in Section 3.5.2. 3.5.2. Take-over Target Peer Server The initiating ENRP server MUST first send, via an announcement, an ENRP_TAKEOVER_SERVER message to inform all its active peers that the take-over is enforced. " >> >> E25. Section 5: Well known Port registration for ENRP? >> Yes. regards, -Qiaobing