[Dime] Diameter load, Annex A.10 Addition and removal of nodes

"Trottin, Jean-Jacques (Nokia - FR)" <jean-jacques.trottin@nokia.com> Wed, 16 March 2016 12:48 UTC

Return-Path: <jean-jacques.trottin@nokia.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DBD12D93C for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 05:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGIvKTFOBPrW for <dime@ietfa.amsl.com>; Wed, 16 Mar 2016 05:48:24 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7A212D93A for <dime@ietf.org>; Wed, 16 Mar 2016 05:48:23 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5091B7F6559B4 for <dime@ietf.org>; Wed, 16 Mar 2016 12:48:20 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2GCmM3A023909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dime@ietf.org>; Wed, 16 Mar 2016 12:48:22 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2GCm55p024343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Wed, 16 Mar 2016 13:48:21 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.143]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 16 Mar 2016 13:48:12 +0100
From: "Trottin, Jean-Jacques (Nokia - FR)" <jean-jacques.trottin@nokia.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: Diameter load, Annex A.10 Addition and removal of nodes
Thread-Index: AdF/ghiqhuqXd3o+RLOeSo/blpHgQw==
Date: Wed, 16 Mar 2016 12:48:11 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D29D4D17F5@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D4D17F5FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/3S0yBo-_jZhKCY_YZrvUBg-4mCw>
Subject: [Dime] Diameter load, Annex A.10 Addition and removal of nodes
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2016 12:48:27 -0000

Hi all


This is about draft-ietf-dime-load-01: section  A.10. Addition and removal of Nodes
For node addition, we have:
   When a Diameter node is added, the new node will start by advertising
   its load.  Downstream nodes will need to factor the new load
   information into load balancing decisions.  The downstream nodes
   should attempt to ensure a smooth increase of the traffic to the new
   node, avoiding an immediate spike of traffic to the new node.  It
   should be determined if this use case is in the scope of the load
   control mechanism.

I propose  to remove the "It should be determined......"  sentence and instead to have an explanation. I propose to replace it  with the following text:

The handling of such a smooth increase is implementation specific but it can take into account the evolution of load information received from the new node and from the other nodes.

I have a similar proposal for the node removal case where current  text is:

   When removing a node in a controlled way (e.g. for maintenance
   purpose, so outside a failure case), it might be appropriate to
   progressively reduce the traffic to this node by routing traffic to
   other nodes.  Simple load information (load percentage) would be not
   sufficient.  It should be determined if this use case is in the scope
   of the load control mechanism.

I propose to replace the two last sentences ("Simple load information .... . It should be determined....) by the following text:

The handling of the node removal is implementation specific but it can take into account the evolution of the load information received from the node to be removed.


Thank you for your feedback.

Best regards

JJacques