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