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

Qiaobing Xie <Qiaobing.Xie@motorola.com> Fri, 22 February 2008 23:55 UTC

Return-Path: <rserpool-bounces@ietf.org>
X-Original-To: ietfarch-rserpool-archive@core3.amsl.com
Delivered-To: ietfarch-rserpool-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854853A692A; Fri, 22 Feb 2008 15:55:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.179
X-Spam-Level:
X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ55Yq0xjjZH; Fri, 22 Feb 2008 15:55:01 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E64E3A68B4; Fri, 22 Feb 2008 15:55:01 -0800 (PST)
X-Original-To: rserpool@core3.amsl.com
Delivered-To: rserpool@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8E53A68B4 for <rserpool@core3.amsl.com>; Fri, 22 Feb 2008 15:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Np7c0jSCSA4 for <rserpool@core3.amsl.com>; Fri, 22 Feb 2008 15:55:00 -0800 (PST)
Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 31A963A67FB for <rserpool@ietf.org>; Fri, 22 Feb 2008 15:55:00 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: Qiaobing.Xie@motorola.com
X-Msg-Ref: server-4.tower-153.messagelabs.com!1203724495!12287636!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 12204 invoked from network); 22 Feb 2008 23:54:55 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 22 Feb 2008 23:54:55 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1MNstwV011545; Fri, 22 Feb 2008 16:54:55 -0700 (MST)
Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m1MNssJg023583; Fri, 22 Feb 2008 17:54:54 -0600 (CST)
Received: from [10.187.86.40] ([10.187.86.40]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m1MNsrQF023571; Fri, 22 Feb 2008 17:54:53 -0600 (CST)
Message-ID: <47BF60CD.8080502@motorola.com>
Date: Fri, 22 Feb 2008 17:54:53 -0600
From: Qiaobing Xie <Qiaobing.Xie@motorola.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <4714E8DC.7040000@ericsson.com> <47B9B0EF.40302@ericsson.com>
In-Reply-To: <47B9B0EF.40302@ericsson.com>
X-CFilter-Loop: Reflected
Cc: rserpool@ietf.org
Subject: Re: [Rserpool] AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13
X-BeenThere: rserpool@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Server Pooling <rserpool.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rserpool@ietf.org>
List-Help: <mailto:rserpool-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rserpool-bounces@ietf.org
Errors-To: rserpool-bounces@ietf.org

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

_______________________________________________
rserpool mailing list
rserpool@ietf.org
http://www.ietf.org/mailman/listinfo/rserpool