Re: AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13

Qiaobing Xie skrev:
> 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).
> 

Okay.


>>> 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.

Okay, that sounds okay.

> 
>>>
>>> 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.
> "
> 

Okay, seems to be no problem.

>>>
>>> E25. Section 5: Well known Port registration for ENRP?
>>>     
> 
> Yes.
> 

Okay, such a registration is missing. And I guess that "Registered" port 
is sufficient for ENRP. But please update the draft to include such a 
request.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------