Re: [Rserpool] ASAP Handle Resolution Option

"Ong, Lyndon" <Lyong@Ciena.com> Wed, 19 November 2008 14:58 UTC

Return-Path: <rserpool-bounces@ietf.org>
X-Original-To: rserpool-archive@megatron.ietf.org
Delivered-To: ietfarch-rserpool-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB253A6B9A; Wed, 19 Nov 2008 06:58:59 -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 9C9B03A6B9A for <rserpool@core3.amsl.com>; Wed, 19 Nov 2008 06:58:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level:
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599]
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 PxEKU5M1kHz5 for <rserpool@core3.amsl.com>; Wed, 19 Nov 2008 06:58:56 -0800 (PST)
Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 71F883A6B57 for <rserpool@ietf.org>; Wed, 19 Nov 2008 06:58:56 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAIO4I0k/dicV/2dsb2JhbADTB4J5
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 19 Nov 2008 09:58:52 -0500
Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD9484C7A@mdmxm03.ciena.com>
In-Reply-To: <49241C3E.2060901@dhdt.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Rserpool] ASAP Handle Resolution Option
Thread-Index: AclKT1nyJh3I1sJeQKKpf0x8tDOriAAB61OA
References: <49241C3E.2060901@dhdt.de>
Importance: normal
From: "Ong, Lyndon" <Lyong@Ciena.com>
Priority: normal
To: Dirk Hoffstadt <hoffstadt@dhdt.de>, rserpool@ietf.org
Subject: Re: [Rserpool] ASAP Handle Resolution Option
X-BeenThere: rserpool@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Server Pooling <rserpool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rserpool>, <mailto:rserpool-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rserpool>
List-Post: <mailto:rserpool@ietf.org>
List-Help: <mailto:rserpool-request@ietf.org?subject=help>
List-Subscribe: <https://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 Folks,

Not to pass judgement one way or another on the handle resolution
option, but I don't see our A-Ds favoring the creation of a new item on
our charter.  I believe the most likely direction forward on this is as
an individual draft rather than a Working Group activity.

I will check with Lars and Magnus, though.

Best regards,

Lyndon



-----Original Message-----
From: rserpool-bounces@ietf.org [mailto:rserpool-bounces@ietf.org] On
Behalf Of Dirk Hoffstadt
Sent: Wednesday, November 19, 2008 6:02 AM
To: rserpool@ietf.org
Subject: [Rserpool] ASAP Handle Resolution Option

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

What about the draft draft-dreibholz-rserpool-asap-hropt-03
(http://tools.ietf.org/html/draft-dreibholz-rserpool-asap-hropt-03) on
the ASAP Handle Resolution option to specify the requested number of PE
entries to be selected? I think this is a quite useful extension and
should also be moved forward.

In our deployed RSerPool pool for SimProcTC, we do not need the PU-side
handle resolution cache. Therefore, on a handle resolution, the ENRP
server should exactly select one PE entry for the SimProcTC PU. ASAP as
defined in RFC 5352 lacks of the possibility to specify this. The handle
resolution option allows the PU to exactly tell this information to the
ENRP server. So, the ENRP  server can exactly select the one PE entry
for our SimProcPC PU -- while it can provide more entries to PUs
actually making use of the PU-side cache. I see a clear need for
standardization of such an option, since its functionality is IMHO
mandatory for efficient handle resolution.

- --
Best regards,
Dirk Hoffstadt
- ------------------------------------------------------------------
M.Sc. Dirk Hoffstadt
DH Datentechnik
45219 Essen Germany
E-Mail: hoffstadt@dhdt.de
Internet: http://www.dhdt.de PGP-PublicKey:
https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
- ------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJJJBw+AAoJEAl0PP0XKTexS1oH/0V820ZYdH+vLZA8KbaNNY/7
XgJBXwL4D1FGVZUbhUSQtQpBxOB1dV95Wa5eU/c2gRd+TupmUXQB7BpBC/VEGqi+
wCrxmUpIpubSuVZfaZ341ZDnotgsBoXszjaPQWDTzR6UhOG7k67dalBgN53j2B66
qvGuryvRacGVhYT9QM3D5mftNPcUP7dzAJn7ioDBkfVAFkFercPwC8SrPFU/6Dan
XCEhVzvS394+vIGN0EohDjsqMIDjQKQZ8NBAYgmXnm70Znyo4sSogHDH9i0QvzDE
jWtz7QeBlu7bHrzare2EMNElKiq/v0FX4jUe+TszD+dbP3BE0ijo+FWez0kpaas=
=Xreh
-----END PGP SIGNATURE-----
_______________________________________________
rserpool mailing list
rserpool@ietf.org
https://www.ietf.org/mailman/listinfo/rserpool

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