Ops Dir Review: draft-ietf-rserpool-enrp-19.txt

<Bernard_Aboba@hotmail.com> Thu, 10 April 2008 17:09 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70EC3A6D4A; Thu, 10 Apr 2008 10:09:23 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5963A6D4A; Thu, 10 Apr 2008 10:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.786
X-Spam-Level:
X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 En2KJEXAVUyk; Thu, 10 Apr 2008 10:09:21 -0700 (PDT)
Received: from blu139-omc3-s6.blu139.hotmail.com (blu139-omc3-s6.blu139.hotmail.com [65.55.175.206]) by core3.amsl.com (Postfix) with ESMTP id DB96C3A6C7A; Thu, 10 Apr 2008 10:09:20 -0700 (PDT)
Received: from BLU137-DS3 ([65.55.162.188]) by blu139-omc3-s6.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 10:09:41 -0700
X-Originating-IP: [131.107.0.73]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS3047F4F8898EE7D399F9C93EC0@phx.gbl>
From: Bernard_Aboba@hotmail.com
To: ops-dir@ietf.org, ietf@ietf.org
Subject: Ops Dir Review: draft-ietf-rserpool-enrp-19.txt
Date: Thu, 10 Apr 2008 10:09:20 -0700
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1606
X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606
X-OriginalArrivalTime: 10 Apr 2008 17:09:41.0898 (UTC) FILETIME=[AAA73EA0:01C89B2D]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1765460169=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ops Dir Review RequestI have reviewed this document as part of the Operations and Management
directorate effort.  These comments were primarily written for the
benefit of the O&M area directors.  Document editors and WG chairs
should treat these comments just like any other last call comments. 

1. Is the specification complete?  Can multiple interoperable implementations
be built based on the specification? 

I believe that the specification is complete in terms of client-server operation.  
There appear to be multiple implementations (though I am not familiar with 
the level of interoperability that has been demonstrated). 

2. Is the proposed specification deployable?  If not, how could it be
improved? 

My overall concerns echo those described by Pekka Savola in his review of the 
Rserpool Overview document:
http://www.ietf.org/mail-archive/web/ietf/current/msg51354.html

As noted in Pekka's review, the Rserpool architecture requires changes to applications
as well as deployment of new infrastructure services.  There are also potential interactions
with other load balancing mechanisms, both at the application and network layer. 

The changes are so substantial that I believe it is highly unlikely that Rserpool
will ever be widely deployed. 

3.  Does the proposed approach have any scaling issues that could affect
usability for large scale operation? 

In practice, global as well as local load balancing is an important consideration; 
Rserpool largely focuses on the later concern.   I do have some concerns about
the scalability of the TLS-based security mechanism suggested in Section 6. 

4. Are there any backward compatibility issues? 

Yes.  The Rserpool approach requires applications to be rewritten, so it is not backward
compatible with existing applications.  This is a major limitation, especially given that
other load balancing solutions that do not require application changes have already been widely
deployed. 

5. Do you anticipate any manageability issues with the specification? 

Yes.  As with SHIM6, there will be concerns relating to interactions of Rserpool
with other load balancing mechanisms. 

6. Does the specification introduce new potential security risks or
avenues for fraud?

The security issues are discussed in Section 6, and appear to be adequately
addressed. 


 


From: Seely, Ted A [CTO] 
Sent: Saturday, April 05, 2008 5:59 PM
To: Bernard Aboba 
Subject: Ops Dir Review Request


Hello Bernard, 

As a member of the Operations Directorate you are being asked to review the following IESG work item for it's operational impact. 

IETF Last Call

http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-19.txt

If possible please provide comments and review to the Ops-dir mailing list (ops-dir@ietf.org), preferably before next Wednesday, April 9th if possible.      

Thank you,

Ted 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf