From nobody Fri Sep 2 02:56:43 2016 Return-Path: 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 29BDA12B026 for ; Fri, 2 Sep 2016 02:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Vbar8A7Xo5LT for ; Fri, 2 Sep 2016 02:56:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D801D12D7CD for ; Fri, 2 Sep 2016 02:56:39 -0700 (PDT) X-AuditID: c1b4fb30-ea88e980000009f9-39-57c94cd5e578 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 92.C2.02553.5DC49C75; Fri, 2 Sep 2016 11:56:38 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.244]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0301.000; Fri, 2 Sep 2016 11:56:37 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgA== Date: Fri, 2 Sep 2016 09:56:36 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> In-Reply-To: <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7me41n5PhBgt/8FjM7V3BZrGhiceB yWPJkp9MHqve9rEGMEVx2aSk5mSWpRbp2yVwZdx+NImloE274s2DzWwNjFuVuhg5OSQETCQW HnrD1MXIxSEksJ5RYu+1mcwQzmJGiTNT7zGDVLEJ2ElcOv2CCcQWEfCVON55mgXEFhawlti+ dzczRNxG4sOPDVA1ThIL/+1h7GLk4GARUJFYtD4WJMwL1Pr+6gVWEFtIYC+jxPMnjiA2J1B5 /97FYK2MAmIS30+tAbOZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQtiKEu1PGxgh6nUkFuz+ xAZha0ssW/iaGWKvoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKKUbQ4tTgpN93ISC+1KDO5 uDg/Ty8vtWQTIzAaDm75bbCD8eVzx0OMAhyMSjy8CSYnwoVYE8uKK3MPMUpwMCuJ8BZ7nQwX 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwLhaUbE6t4dn mduTq5a7Fv4s3TnvP6/V7xWrWSS40udunVIt0PGvbF/x7qa00jvdHnndbDxLrs+qm5A363az 64eIee5PfXyk1lzUsvYXvd74n/3AxKIUh0sdnh/fenzect3vTm3/y9Tle7N7Hy8N+mn3QXvT r5Jzv67+qDpYyrP8yv9jzPeiCtqUWIozEg21mIuKEwGGEwi+ggIAAA== Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 09:56:42 -0000 Hello Steve, Thanks for the proposal. I still think the text is a bit misleading: "The calculated LOAD value MUST reflect the sending Diameter nodes=20 capacity relative to the maximum available capacity for the sending=20 Diameter node." I think it should be: "The calculated LOAD value MUST reflect the sending Diameter node=20 capacity relative to the maximum available capacity for a sending=20 Diameter node." Reasoning: a node may have a very limited maximum capacity, but the key poi= nt is precisely to provide a LOAD value relative to the maximum value A nod= e may have.=20 I hope this clarifies Thanks /MCruz -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: martes, 30 de agosto de 2016 5:59 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] Proposed resolutions of LOAD discussion Maria Cruz, Thanks for your comments. See my replies inline. Regards, Steve On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > Hello Steve, > > Thanks for the proposals, see below > Best regards > /MCruz > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: martes, 16 de agosto de 2016 16:50 > To: dime@ietf.org > Subject: [Dime] Proposed resolutions of LOAD discussion > > All, > > I have outlined proposed solutions for the issues raised in the discussio= n around the Diameter Load draft. > > Please let me know if I've missed anything from the discussion. > > Regards, > > Steve > > Primary Issues: > > 1) Use of DNS SRV weighted value as format for LOAD value. > > This was discussed and agreed to early in the process. It has the advant= age that Diameter nodes can use a combination of values received via the DN= S SRV interface and dynamic values received through the Diameter LOAD inter= face. While I agree that it isn't as intuitive as a straight percentage va= lue, I don't see this as compelling enough of a reason to change a decision= the working group has already made. > [MCruz] I still think using SRV values is error prone and anti-intuitive,= but I can live with this if you really think it is not possible to re-eval= uate this now. SRD> I haven't seen any argument that using the SRV values doesn't=20 work. As such, I prefer to not change this at this stage of the process. > > 2) Need to add wording that the calculated LOAD value needs to be based o= n overall available capacity. > > I agree with Maria Cruz's comment that we need to add wording indicating = that the calculated LOAD value needs to reflect available capacity. To thi= s end, I propose adding the following to section 6.1 (this is based on word= ing proposed by Maria Cruz): > > The calculated LOAD value MUST reflect the Diameter nodes capacity relati= ve to the total available capacity across the Diameter nodes to which reque= sts can be routed. This could be either a set of Diameter endpoints or a s= et of Diameter agents, depending on the type of the LOAD report. The metho= d for determining the total available capacity is outside of the scope of t= his document. > > Note: The LOAD value should be calculated in a way that reflects the= available load independently of the weight of each > server. This allows the Diameter node that routes a request, includ= ing nodes doing server selection and agents routing > requests, to accurately compare values from different nodes. Any sp= ecific LOAD value needs to identify the same > amount of available capacity, regardless the Diameter node that calc= ulates the value. > > The mechanism used to calculate the LOAD value that fulfills this require= ment is an implementation decision. > > > [MCruz] Some comments to proposed text: > " The calculated LOAD value MUST reflect the Diameter nodes capacity rela= tive to the total available capacity across the Diameter nodes to which req= uests can be routed. ": I think it may be misleading what is the "total ava= ilable capacity across nodes". > See proposal: > " The calculated LOAD value MUST reflect each Diameter node capacity rela= tive to the maximum available capacity for a Diameter node to which request= s can be routed." SRD> This wording could imply that the LOAD value carries load=20 information for multiple Diameter nodes. How about the following: "The calculated LOAD value MUST reflect the sending Diameter nodes=20 capacity relative to the maximum available capacity for the sending=20 Diameter node." > > 3) Wording in Appendix A. > > Before we reword Appendix A, we need to decide if it is still needed. > It was valuable in helping to generate the solution but I'm not convinced= it is still needed in the document. Is there objection to removing this s= ection? > > [MCruz] I prefer this to remain, it provides some hints that may be valua= ble for first time readers. SRD> I'd like to hear other opinions on this as there is work required=20 to make the section consistent with the mechanism defined. Implementors=20 will still have access to this information by reviewing the history of=20 the process of writing the specification. SRD> Are there schedule pressures in 3GPP to get this to RFC state? If=20 so, it will be faster to just remove this section. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Sep 15 08:57:09 2016 Return-Path: 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 58F8912B0CF for ; Tue, 13 Sep 2016 14:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.13 X-Spam-Level: X-Spam-Status: No, score=-104.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 2Lua_f8UqSZg for ; Tue, 13 Sep 2016 14:42:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1C812B0C9 for ; Tue, 13 Sep 2016 14:42:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4DBFAB80B89; Tue, 13 Sep 2016 14:42:13 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160913214213.4DBFAB80B89@rfc-editor.org> Date: Tue, 13 Sep 2016 14:42:13 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 15 Sep 2016 08:57:07 -0700 Cc: dime@ietf.org, holger+ietf@freyther.de, rfc-editor@rfc-editor.org Subject: [Dime] [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 21:42:24 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803 -------------------------------------- Type: Editorial Reported by: Holger Freyther Section: 3.2 Original Text ------------- Example-Request ::= < Diameter Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Corrected Text -------------- ::= < Diameter-Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Notes ----- I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. header = "" But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:". command-def = "<" command-name ">" "::=" diameter-message but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Sep 15 10:08:53 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A380012B2F9; Thu, 15 Sep 2016 10:08:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147395933062.21865.8206917163680004450.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2016 10:08:50 -0700 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com Subject: [Dime] dime - Not having a session at IETF 97 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:08:51 -0000 Jouni Korhonen, a chair of the dime working group, indicated that the dime working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Sep 15 10:24:16 2016 Return-Path: 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 F0ABF12B216 for ; Thu, 15 Sep 2016 10:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qnpWFuhjsmu5 for ; Thu, 15 Sep 2016 10:24:13 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4EB12B15A for ; Thu, 15 Sep 2016 10:23:49 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u82so60595196ywc.2 for ; Thu, 15 Sep 2016 10:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=J6TeV/tKE+rd+jERxb3TZLObRsm6bwQc2UwsTdisvRg=; b=msKNMAoAjgcAxZbDDObpmB3Br5ekTRVHPACGipG4bq/cQx4nR5Yf9/9/jlFGYuGGlV TupSe/h0yq8bfpWFfzdngYBtYjFZgju4eO/XnrHRrTGJiJOxs5bYlBehtAUO+rOLgtaZ LmhW/EaYd+5C1ZJ7RDDjdU5E5sqP6PerzRmZdNMnj2slkI/5UwxGFRVPomBuhkF4BmXy kymGZd+t9ZtA6ATwoLEbQM+2dmu6vtoJYuYCD2Qv4A9qJcY+T/OPqQ/yt0zx/tjyzWm2 jfUzZwl7B7QtFGNm+0Jlduhe2igxyzQTF14zZEYEnvUg1UgtB3hh6FRyg86LDXBjc3nE 3zoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J6TeV/tKE+rd+jERxb3TZLObRsm6bwQc2UwsTdisvRg=; b=F3pKjRuFJ+2aUyYZvzF7U4sfpLudGIXEF7TiN3lda+vmN8n2b20BBpTE9Ay2vVkhda z2jTK5IOXBHhiftRhRqbzioDRa4UTiHEdkhHM2bfd50fEp6jenrduDgZNsZ5LkSbVrWO u/GCFcEbumM6QdskhDVVlOYyWEwRVe6HOzxxQmUaldBE3sDTwsYs/4Nuwh07S8Jt+ExQ 9zDcbq1cKGP/rjmTvw0p/7OomqnHss0lpnyq08mjHeCTJ8Ag1Bx8WxL0cF15m0/1Fend poFCqMNwtFPZT77y+4x4T9q7PlPKwsGL7W/Zbnv0O6tqNIUAJlGzPGT+acLpzSbqqaOs SuLg== X-Gm-Message-State: AE9vXwPLYIScE8n9qCbbKWKA/RNP7ZzH1h6QCa8Ua2+Lwkh0qb/GlLHXAk0q18yYEPoYRzNotM2oSbGNxvhC7Q== X-Received: by 10.129.132.204 with SMTP id u195mr9794821ywf.105.1473960228439; Thu, 15 Sep 2016 10:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.95.67 with HTTP; Thu, 15 Sep 2016 10:23:48 -0700 (PDT) From: jouni korhonen Date: Thu, 15 Sep 2016 10:23:48 -0700 Message-ID: To: "dime@ietf.org" Content-Type: multipart/alternative; boundary=001a114f0740d451cc053c8f1b41 Archived-At: Subject: [Dime] DIME will not meet in IETF97 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 17:24:15 -0000 --001a114f0740d451cc053c8f1b41 Content-Type: text/plain; charset=UTF-8 Folks, chairs had a short exchange of thought and concluded that we do not need to meet in IETF97. Instead we try to progress everything on the mailing list and offline. The growing pile of action point chairs have on their table are: * draft-ietf-dime-agent-overload-06 -> proto write-up * 3GPP LS -> finalize and send * draft-ietf-dime-doic-rate-control-03 -> new quick WGLC#2 * draft-ietf-dime-load-02 -> new revision (Steve) and then WGLC#2 - Jouni --001a114f0740d451cc053c8f1b41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

chairs had= a short exchange of thought and concluded that we do not need to meet in I= ETF97. Instead we try to progress everything on the mailing list and offlin= e.

The growing pile of action point chairs have = on their table are:
* draft-ietf-dime-agent-overload-06 -> proto writ= e-up
* 3GPP LS -> finalize and send
* draft-ie= tf-dime-doic-rate-control-03 -> new quick WGLC#2
* draft-ietf-dime-lo= ad-02 -> new revision (Steve) and then WGLC#2

- Jouni
--001a114f0740d451cc053c8f1b41-- From nobody Fri Sep 16 13:47:18 2016 Return-Path: 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 0452112B028 for ; Fri, 16 Sep 2016 13:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cjAd-nyKD5ue for ; Fri, 16 Sep 2016 13:47:16 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F0C12B027 for ; Fri, 16 Sep 2016 13:47:15 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t67so93079215ywg.3 for ; Fri, 16 Sep 2016 13:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=uJlXWQAHvpzAsn+iBv9a4+EJ1sgBmx1vGQjOH77qEZA=; b=a1MpTED9mXzwEIePFN2FfBHw7pXafLDa8YHoLYQLlW9wWXfBTdrbWYxwxzUp61NiDO 6R3n+wGXd7h0/QE2w5I8OUbem1Ktkoar897DObIa8YSbcVY2mFfKVIq3sEXRKFh5UZKv PSRDb4gMzvNtlX0XW4nqSyVADEHVW6uYOJV1omDEvNlgtVMBwxMEiGLVWG4f1c8mjOHC k8rJ7ow/KCzK/1cWuXnQqGIArUG1yKnC0SMYz4ps8W+6VCG20yx0fntRZh6/fS6TfSxH RCBqVQcCgmfdukSnHfevSmOuGJMv5oITr5auYCvERBVLC/E1YTLBk0uJ2lYWiuPliKfB 2a+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uJlXWQAHvpzAsn+iBv9a4+EJ1sgBmx1vGQjOH77qEZA=; b=fjWEN9LrdjqxHYAFdEyIr/NEmOjkGVqDhNPzh1CGn6CxNgDxH50JK8ggTs/4JO/xHh lBedw8Topj87cJUZZKlPio+yGthAdTXFMoRVJawoewRTCJcLIhBWjVU9NBoCnxsl28i7 pN6VpTm0B+lKfxGdBjSMzxM/vPZw7QJRnh5BdegzSmY1LCT25NK1pS11bD533XjMA09l AOlUf8qGcUuZqroSSHBWbXzPCAEiaEQGrESeg8zyx9R/1sfoZMo5qvHP9ZsoFH6E2uZo Cik7BF4PldmRjBA26uAQU6P4ceG215s9hu6UI6f2tbujeQ09PY/GvwgZl4E43SG3U+Zc LzwA== X-Gm-Message-State: AE9vXwOOrRjsRECq3YAtVfgBVw7TJWteEITbgz5Hcoi6oiubDv+rpzagFoPFbRsRu46F8S+kCgiDvNnhFMbhTw== X-Received: by 10.129.73.135 with SMTP id w129mr11973153ywa.288.1474058834833; Fri, 16 Sep 2016 13:47:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.95.67 with HTTP; Fri, 16 Sep 2016 13:47:14 -0700 (PDT) In-Reply-To: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> References: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> From: jouni korhonen Date: Fri, 16 Sep 2016 13:47:14 -0700 Message-ID: To: "dime@ietf.org" Content-Type: multipart/alternative; boundary=001a114dd0943a98de053ca6111a Archived-At: Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2016 20:47:18 -0000 --001a114dd0943a98de053ca6111a Content-Type: text/plain; charset=UTF-8 Folks, I updated the draft LS based on the input. See below and comment. - Jouni ------------------------------------------------------------------------------- The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query regarding the IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/). The IETF DIME WG has discussed both options raised in the LS from 3GPP SA5: 1) Is IETF RFC 4006 planned to be updated in order to rely on IETF RFC 6733 as the new Diameter Base protocol? 2) If not, are there any recommendations from IETF on how to address the implicit reference to IETF RFC 3588 as Diameter Base Protocol for 3GPP SA5 Diameter Online charging through use of IETF RFC 4006? and the decision was made to update of the IETF RFC 4006 as per the option 1). The aim of this update is to align the Diameter Credit-Control application specification with the IETF RFC 6733, fix existing known issues in the current specification and comply with the recommendations given in the IETF RFC 7423 on the design of Diameter application. The time line for the completion of the RFC 4006 update is set to November 2017. As a reminder, the IETF RFC 6733 does not define a new Diameter base protocol but is a new version of the specification defining the Diameter base protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the IETF RFC 2223: Obsoleted-by To be used to refer to the newer document(s) that replaces the older document. In the present case, any document using the IETF RFC 3588 as reference for the Diameter base protocol should be updated to refer to the new IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WGs to follow this recommendation in their specifications when applicable. The same recommendation will apply for the revision of the IETF RFC 4006 when published by the IETF as for any new RFC obsoleting an old RFC. ------------------------------------------------------------------------------- On Fri, Aug 5, 2016 at 10:41 AM, Jouni Korhonen wrote: > Folks, > > Lionel and I have been drafting a reply LS to 3GPP SA5 (and CC CT3/CT4). > This is the current draft. Comments are welcome. One question is (Lionel > favours, I disagree ;) whether we should repeat the two questions 3GPP > asked from us or assume they can look it up from the origial LS. > > - Jouni & Lionel > > ------------------------------------------------------------------------- > The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query regarding > the IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/). > > The IETF DIME WG has discussed both options raised in the LS from 3GPP SA5 > and the decision was made to update of the IETF RFC 4006 (the option 1). > The aim of this update is to align the Diameter Credit-Control application > specification with the IETF RFC 6733, fix existing known issues in the > current specification and comply with the recommendations given in the IETF > RFC 7423 on the design of Diameter application. The time line for the > completion of the RFC 4006 update is set to November 2017. > > As a reminder, the IETF RFC 3588 does not define a new Diameter base > protocol but is a new version of the specification defining the Diameter > base protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as > defined in the IETF RFC 2223: > > Obsoleted-by > > To be used to refer to the newer document(s) that replaces the > older document. > > In the present case, any document using the IETF RFC 3588 as reference for > the Diameter base protocol should be updated to refer to the new IETF RFC > 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP > WGs to follow this recommendation in their specifications when applicable. > ------------------------------------------------------------------------- > > > > --001a114dd0943a98de053ca6111a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I updated = the draft LS based on the input. See below and comment.

- Jouni

-------------------------------= ------------------------------------------------
The IETF DIME WG thanks= the 3GPP SA5 WG for their LS and query regarding the
IETF RFC 4006 (https://datatracker.iet= f.org/liaison/1470/).

The IETF DIME WG has discussed both option= s raised in the LS from 3GPP SA5:
1) Is IETF RFC 4006 planned to be upda= ted in order to rely on IETF RFC 6733
=C2=A0=C2=A0 as the new Diameter B= ase protocol?
2) If not, are there any recommendations from IETF on how = to address the
=C2=A0=C2=A0 implicit reference to IETF RFC 3588 as Diame= ter Base Protocol for 3GPP
=C2=A0=C2=A0 SA5 Diameter Online charging thr= ough use of IETF RFC 4006?=C2=A0=C2=A0

and the decision was made to= update of the IETF RFC 4006 as per the
option 1). The aim of this upda= te is to align the Diameter Credit-Control
application specification wit= h the IETF RFC 6733, fix existing known issues
in the current specificat= ion and comply with the recommendations given in
the IETF RFC 7423 on th= e design of Diameter application. The time line for
the completion of th= e RFC 4006 update is set to November 2017.

As a reminder, the IETF R= FC 6733 does not define a new Diameter base protocol
but is a new versio= n of the specification defining the Diameter base protocol.
The IETF RFC= 3588 is obsoleted by the IETF RFC 6733, as defined in the IETF
RFC 2223= :

=C2=A0=C2=A0 Obsoleted-by

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To= be used to refer to the newer document(s) that replaces the
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 older document.

In the present case, any docum= ent using the IETF RFC 3588 as reference for
the Diameter base protocol = should be updated to refer to the new IETF RFC
6733. Therefore, as a gen= eral guideline, the IETF DIME WG recommends 3GPP
WGs to follow this reco= mmendation in their specifications when applicable.
The same recommendat= ion will apply for the revision of the IETF RFC 4006
when published by t= he IETF as for any new RFC obsoleting an old RFC.
----------------------= ---------------------------------------------------------


On Fri, Aug 5, = 2016 at 10:41 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
Folks,

Lionel and I have been drafting a reply LS to 3GPP SA5 (and CC CT3/CT4). Th= is is the current draft. Comments are welcome. One question is (Lionel favo= urs, I disagree ;) whether we should repeat the two questions 3GPP asked fr= om us or assume they can look it up from the origial LS.

- Jouni & Lionel

-----------------------------------------------------------------= --------
The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query regarding th= e IETF RFC 4006 (https://datatracker.ietf.org/liaison= /1470/).

The IETF DIME WG has discussed both options raised in the LS from 3GPP SA5 = and the decision was made to update of the IETF RFC 4006 (the option 1). Th= e aim of this update is to align the Diameter Credit-Control application sp= ecification with the IETF RFC 6733, fix existing known issues in the curren= t specification and comply with the recommendations given in the IETF RFC 7= 423 on the design of Diameter application. The time line for the completion= of the RFC 4006 update is set to November 2017.

As a reminder, the IETF RFC 3588 does not define a new Diameter base protoc= ol but is a new version of the specification defining the Diameter base pro= tocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in t= he IETF RFC 2223:

=C2=A0 =C2=A0Obsoleted-by

=C2=A0 =C2=A0 =C2=A0 To be used to refer to the newer document(s) that repl= aces the
=C2=A0 =C2=A0 =C2=A0 older document.

In the present case, any document using the IETF RFC 3588 as reference for = the Diameter base protocol should be updated to refer to the new IETF RFC 6= 733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WG= s to follow this recommendation in their specifications when applicable. -----------------------------------------------------------------= --------




--001a114dd0943a98de053ca6111a-- From nobody Mon Sep 19 05:44:32 2016 Return-Path: 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 6925012B3C1 for ; Mon, 19 Sep 2016 05:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, 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 yVK2B_Bkx3at for ; Mon, 19 Sep 2016 05:44:26 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECBC12B34A for ; Mon, 19 Sep 2016 05:43:56 -0700 (PDT) Received: from BL2FFO11FD063.protection.gbl (10.173.160.31) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Mon, 19 Sep 2016 12:43:55 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BL2FFO11FD063.mail.protection.outlook.com (10.173.161.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Mon, 19 Sep 2016 12:43:54 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id u8JCSo2V046698; Mon, 19 Sep 2016 08:43:54 -0400 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by preapdm3.corp.sprint.com with ESMTP id 25h03617d4-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Sep 2016 08:43:54 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Sep 2016 08:43:52 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1210.000; Mon, 19 Sep 2016 07:43:52 -0500 From: "Bertz, Lyle T [CTO]" To: jouni korhonen , "dime@ietf.org" Thread-Topic: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. Thread-Index: AQHSEFuGIjXFj+AZy0+sNW2EYRo4QaCAxjJg Date: Mon, 19 Sep 2016 12:43:52 +0000 Message-ID: References: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.123.104.24] Content-Type: multipart/alternative; boundary="_000_ce1a508e435c41f998fda190dc68bc43plswe13m04adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(438002)(189002)(199003)(377454003)(24454002)(19300405004)(356003)(76176999)(54356999)(50986999)(7906003)(5001770100001)(7736002)(7846002)(97736004)(2906002)(19625215002)(11100500001)(8676002)(86362001)(81166006)(81156014)(106466001)(24736003)(106116001)(8936002)(2900100001)(4546004)(19580405001)(19580395003)(512874002)(2501003)(2950100001)(87936001)(68736007)(16236675004)(626004)(92566002)(189998001)(33646002)(19617315012)(102836003)(3846002)(790700001)(107886002)(84326002)(108616004)(5660300001)(7696004)(5250100002)(6116002)(586003)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB009; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD063; 1:YIA/eRk7TBffThgLUd70RcHQddZ5cHRveg47YCmnhUn0q/TQWTE419enySINSS9LlDJ9vvpY6hdQrbPYow6lT2Tv1LlgXc2bkjKPjSDBddIgDcGwIQMFJWGpkzokDBR6GnvFk6Jh1NS9mVXFiFmBXzGissS+2FHMWUuY3M23hn/RyERMJBw44NKlweLDVRgnxSVriD3a5VQShW9WR+jo+ym38z6WDgjzXcHtOU+7hSGDMgpi6b9kyzowmGd0VAwPvdcgmEQG072Ya/CgfQJP/ycuq80zPoVlMod0gLdkT1Ucs4uzYNdOrG9ExIS7H3aGggXGqcueQ0APfBqF+c8QiHjGFX/nJqZr3T2aIyn/GsGDiyQUW9GOvtcElNTXHYJkhfueax+wPs3f+OXKc1ob4JdGiR0G987CnwsUZG9WR4mEMPv7Pap6iypyooOXqc1JTHnLKdl3ael3nLt+ls1KrI6qtcd+mKEYYNW1eGf9jH2OuGMUrNxu7flwdnKiprNm9h37qONDAKxF9NHKSyiUf/XNnEsKqgfZlSlnhrX7pLSDCpK+x+iSGGp6glvoKxog X-MS-Office365-Filtering-Correlation-Id: e0417228-c907-4881-03ab-08d3e08a9df1 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB009; 2:qw/vfvGop2Qu/0BtFQ0ApYDxXPnSIA6r0jx2iUZaN4OxzbA5PQxMnqioYfd87AlWzCC+Kd+mOY/rZUZ+kZ/4FwaYuBjd7vQqHAV5fTygQ0NKtRmxCTtWf+E05EqGcqrke9/Zi4MmkTG+XIgXzjt55zZmgkPxCJhLgDBlXpbrmPLzUe37SSwvlwhyn6rBJLay; 3:U1s2PHSovGWsM4xp4NmPRQjUDdSRqu7JVEc3nDLt1YTmmK+EZOQ4kN9bZUZFzFQxt1IdjWov/QVCWT7RFKJpUWk8hv6tHJbmngWAaePgqemBgdYkM+zJ/RLQKSIQlurWjb+AhYuOTQROMp2tfvpnNYc205qZkmYlM/O9NT9smFF2V3GuwxV9x1d7N3sOuiaWANXcZrhUJ7WQ9GgiZ7cta4C/iYa0V4FSrffFm5jiM5nSm2bkHskOdnWLzs2hrgVWxM9T4TtFDXCrx2RfNN7TKA==; 25:7NUvJ/7ppzJiYkOBkAbnKulOGm47okADuKJK/sdhQ85PjHfY/kUcnby2AyYi7jXp+ZTeCZyCWM6sKKEj8CkSSvNl1NZJT28O0M9EtCg3E7dAtjS4vRHKDCza5WXt78B6GAGRLYXHDB6Av+WMFGxYTS6e44TT92Zc0p/hwnmQPSJY0TzA4+qOfsF+xwGebHCTra3+dWEtxWIgigzH8f8X92KtF1LbQf6BzW00WRuL7x1zZquK7Sfn1+u/6yHkL8ASiqM7dZhhN9SOyoNAmU+XJfoVYs75Lm8jvdRqiPGDMD3KkGLJQ0FVJbbYE6fyvEJIqRUhKwvAm4v2qkDpBYr5dLtvqQvISgM7Gt8eTd2IW1v8ulPyjxgL9kx1YPMDNx3mXDzlwHkHmLDO9qzV8JzHE6vzJz0Ms11WecabIwVdjY4XjxamM+YtOBt3ubG4Jr1g X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2FFO11HUB009; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB009; 31:HxLW2oLA1WhLWXdbwI2ga9w6qVHdipfRDKExsCqNoBB5ZjnBWIQvOfeVLIKfVtIY8ImZ+hqxjZLFY830t8maRmHHMCw2QHChPia1EB9p1rfnQCCXOxWf5CECsdAa4Au7eu9Tzt9Jg2h/EXDOenDkwrAMOvUOJPfrnVYAYW+VhyEYY+/4FzCLwDOBZUCYe5GoO8msP/IYSgAv0pYs/j7rgemLqWOoY6Wo/bhWqR1lGcc=; 20:4+3bJCu/DF0SyU1qlhvyxHVQshsYBx6GQvy6FXPojRFV0rhq3dD2B7AfVzlszrZapzE6nvXfJv4JX5LFzVwnQFINm1jKqPNuRUQplDB5+n1IeHJlI7udkkJV8L+BeF1gBZsxI24pumilMkFpo9zHRUtH8FNvpMMpK58K2WNS4ZS7Hlzup8v1JaxrLoWdMXk5Xv+gnHVFjSKEgNFahdiqglwkHqoOsi5D6DhQEiSTwSfCna0kt8IOwtPaPkfm0JHhTrdqlpJfdX40k3v9PGCkS9fF7/+lIaz6jvex2HObkCP4sCB6pU7oLq4r03WavAal5dM5eeqyK8FXKckJGRkfM45rIcfygPk+06ON+w7p/+owK5XIwQCNuj4J4oAq6TbDW9WOVUvNNNQHlcGcQVlS8tfG1XMAWxU1uzbZ3lyBvYE0awtzMaDiOtvid8VB2e5h/Cvx4PuaxIxJcb9uhc18QPGLz/3HOzQ5Pw2Nm2MR0gBKl3YYQSeyT2EopOCgPcp6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(209352067349851)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(13024025)(13023025)(13015025)(13017025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BL2FFO11HUB009; BCL:0; PCL:0; RULEID:; SRVR:BL2FFO11HUB009; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB009; 4:AO7tKThcOr3kb7bUH5sX7nCLh4XXDX1Qos2fTNBm0AOXc11ApVo5fxcoGX1VdEb0ZKKrGjd8JKigI3r2z3bhRDBgb6GHQ9430v4zP0g3ePLDf+FfojgMvsw9pxf3lrwFU5X8nhq+EO6DHsyzZXe3QMMc2PX5HziNvz26b7wqo6mZn1grMSRTWtpjd3KOzuAwY2o9zVBPHZTXoOnmCLb5DwSYqqv/5B4hl9ntK54r0UmOKy4XguZXIGYZrYMrU2CqngGQ6PzPF3FZj8G3TkyviALsIxYKjvhfjZkavd7mOMZWV6kDv97weH33Xdb+mdaH4nGrjuN1BehOPbSJQyPdd6LoWr+81tfHv82FeQHB19UaVlQtcgX2V+TqWJIG1Np0OwxBAfwA+x/QlKC4YXOgroy5ULAn6FfPiAX0kBvNEYitvKkU66jSviciys6lsdnZdBxqbf6mrCbcNF2EhYwQXUlw2AU+Xm9F1PO9JiFS8g1Ddf+CqNoiompxJQHXsLxzcESvCTvWfb4DJD8u0n1hCnFsgOmc2JXRkq2FQEr5G5+v5prlHWbTC+IkfBsyBxXoE0cZ5WQa2JEEPNXaynTeK5HaAZATib9BnhiIyMG9Blo= X-Forefront-PRVS: 0070A8666B X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2FFO11HUB009; 23:PJK+qONeY2mlvfmw8sJyU41rqE1hm7Zy1DAxtIWd?= =?us-ascii?Q?bjhO23SNTyyz+zGbaEmCwhqC3RMyM/rTWupWSI/oO9yhVx1B+SNqTdY+YAEF?= =?us-ascii?Q?r33GyHOJsK1+b8LEfmcO6nmcREm7/NsUMXWKADFSzf7c2nKTH4eGZgVDPnzc?= =?us-ascii?Q?3Eyfe/4rzd0ztTwbYVpsO6TQxxNfG2hKuAIswngExqcrNgZzJYOtlGdTevme?= =?us-ascii?Q?6OFHklC/7v/doGBPiY/1VMoiQV3EVmjADZin6TFmk83cUdq8KtcvZ813JCGi?= =?us-ascii?Q?786npqM/xxvZud0lKAuh0cCr9ihHFsK2EKO/hdzlZfxVSBoDZODjnWK6Mmuv?= =?us-ascii?Q?YJENDz2wnkK6kSp/magMPC1y7OGpHyqAioX2vQqdCNhTK8sVKO2jm6jPj2kU?= =?us-ascii?Q?mCWu/D5nvDAQLRO0cfYRZgfrw3kCM1vjE4NI33SMuLwCJg1i3VPrXFRcpEV5?= =?us-ascii?Q?IFuIdggS6KCPJWh/F0cdvaJMHXU2oFA8fghTjBZU5eV7Wo7egoRSA9ouLNAo?= =?us-ascii?Q?L/EFoi+LqCwc3sSWy/Tl1XT5rvmqHiwqIAhHD9ksuxUgXsfH7BJ8MiL6pd94?= =?us-ascii?Q?e6P3pkfwmYPDpzjf4h+ligNos/EYXqfOqVW2ahb9DmvLjSIx+1Goc+rW7d9L?= =?us-ascii?Q?vRNSThpf61GRAOdKeod4pIodhi7Yw60NnXUvFS7+PaQzTTM16U63+nWXeEmM?= =?us-ascii?Q?CxkLFTRSGVdodqj5QqYmAyDlqEZLhhHkUEjYU2FFMBtIy4Mi5mw2TN9URS9+?= =?us-ascii?Q?Nfu3CGlJVqVx6RszLbgoy29JI/VbpwkPyWuFW5FefTxoefUpCzIvkO3jOfTl?= =?us-ascii?Q?+T79YPe25Y5ZEhL7bi1Z08C3wv0oLMLRGKwVfyqd42syRfVhxiWwgb7QC+KQ?= =?us-ascii?Q?4pZtWzvyGXhJm8Fq6lcTS/IC1nhHO6Gy46po0LRsqnyAmc5qdbtv7mbvFInQ?= =?us-ascii?Q?JsJRuALi3n3Ug13kEupDsKMKa6x/29XAIBKAomUayBNr+1qxHlMJSBlPWeQk?= =?us-ascii?Q?0ZHd/VwJpVqNh6AUD36crU3qLWe5UhZI86fScwz9vTjJ2VmwTbSbvLYbvDt1?= =?us-ascii?Q?tp/Tz7vTfTYEXxwHXo5n6LdGez8rZSaHI+mI2t7qFwf8w3scIIIqijo381Cz?= =?us-ascii?Q?TbKuFqvR9Zz2DaYYWsvNlu7yD2i08KCXRvtdDf48oHWJYoNeJcKmY0iomHCP?= =?us-ascii?Q?/kgfUPDiLLr0SMvjxGs3IILKieT01VDQVDk5AdsNDf70TjaA0D1nFF5EOt9A?= =?us-ascii?Q?QAYtHl80sgR+6IIuN5WU5x5yoxxz5mxFuHU4ue0vYthmbpG+mnR3GmRJ8lHk?= =?us-ascii?Q?JiP1mgwLwbsqsdCKQ3IgD/P9aQxvlXe16Q4+M7FrkXVF?= X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11HUB009; 6:nayEcJZfBBAoj5EtL2fiXlwJEkmq3tzisXR2Mb8nf3kmblDRbYWvDpEZ5Wk2Sy50sa/jIz1ItYM1WpiWiaj8jhtz95TeUyqsLQRl71ajj74i4J2ttk1/WoP2x3blYdsKcunwYWmoSgIQb44DsUlDTStFf7OZfmZq96ESS1fxgqThSBYlbRLH1LiYjVCrg9yzbA19RMGpcm3TqTqZaoe6F1A8p+p3yD3wp43HMiqj8j3nj5/aW2D3BAghumjOfPbZaizBwLkyXv7Mgx8wjCHrGSg8oPUxNfFuaz0l/mRNhFcaVYpImb0aK+SwkW+4Ldke+Or4RguPD/b1H5AGe8i7xw==; 5:8yEjrhCGLpczcfv4l8H98X1BPG6HM1Tsx+K+ot/bOto2MUQsQlA4d1vKdVbjbbMUsse7npztGmG4JYzLFAOUeqgGiVwoFLUQbd/bY8twR9rFFV0dqwFj4OFdFCmxg1T2ys45tbbaBhsWMFIiVjfDkg==; 24:7YL7BjmSew7hvxkTQw4RJqCPFjcogd7TpOTE1Xt1HGXvt3cm6LlIbdBAI49yeDJh8jeig88aI59HJMLu68xwg3wbbNhCXa4bUiRVGsS4aMM=; 7:wdtn8K4TlN0m8RbM4GqFojo2HPEkRV0z2USP1tt/CCSUArsi/I8TgzPpQdntxnB9ZnxoP5IPJosFrTIsbMzKHGXkucXirdBC9SGbYty7zvYZ3LFh7209f5kzKRxqK5VaK03QdBfL9bk+k0jGVnDOs3nhOWGAu/8g7wD5z0+RnvvkLmFwDCGAvExIGHP/pS7+pgZOzL1K62ok8Icm9CStMWTv2R+czBZh6Cg81JlvgngRFm9zwOcpqJUwYFhXPUk61FPy0WOCxHxU7846sQKUZpD8wRZUDnoM9jzL4g7qZRlFdl0Rqm7Z/z1qc5bo7OiJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2016 12:43:54.8674 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB009 Archived-At: Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 12:44:31 -0000 --_000_ce1a508e435c41f998fda190dc68bc43plswe13m04adsprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBsb29rcyBmaW5lLg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2Ygam91bmkga29yaG9uZW4NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVy IDE2LCAyMDE2IDM6NDcgUE0NClRvOiBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVd IGRyYWZ0IHJlcGx5IExTIHRvIDNHUFAgU0E1IG9uIFJGQyA0MDA2Li4NCg0KRm9sa3MsDQpJIHVw ZGF0ZWQgdGhlIGRyYWZ0IExTIGJhc2VkIG9uIHRoZSBpbnB1dC4gU2VlIGJlbG93IGFuZCBjb21t ZW50Lg0KLSBKb3VuaQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgSUVURiBESU1FIFdH IHRoYW5rcyB0aGUgM0dQUCBTQTUgV0cgZm9yIHRoZWlyIExTIGFuZCBxdWVyeSByZWdhcmRpbmcg dGhlDQpJRVRGIFJGQyA0MDA2IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24v MTQ3MC8pLg0KDQpUaGUgSUVURiBESU1FIFdHIGhhcyBkaXNjdXNzZWQgYm90aCBvcHRpb25zIHJh aXNlZCBpbiB0aGUgTFMgZnJvbSAzR1BQIFNBNToNCjEpIElzIElFVEYgUkZDIDQwMDYgcGxhbm5l ZCB0byBiZSB1cGRhdGVkIGluIG9yZGVyIHRvIHJlbHkgb24gSUVURiBSRkMgNjczMw0KICAgYXMg dGhlIG5ldyBEaWFtZXRlciBCYXNlIHByb3RvY29sPw0KMikgSWYgbm90LCBhcmUgdGhlcmUgYW55 IHJlY29tbWVuZGF0aW9ucyBmcm9tIElFVEYgb24gaG93IHRvIGFkZHJlc3MgdGhlDQogICBpbXBs aWNpdCByZWZlcmVuY2UgdG8gSUVURiBSRkMgMzU4OCBhcyBEaWFtZXRlciBCYXNlIFByb3RvY29s IGZvciAzR1BQDQogICBTQTUgRGlhbWV0ZXIgT25saW5lIGNoYXJnaW5nIHRocm91Z2ggdXNlIG9m IElFVEYgUkZDIDQwMDY/DQoNCmFuZCB0aGUgZGVjaXNpb24gd2FzIG1hZGUgdG8gdXBkYXRlIG9m IHRoZSBJRVRGIFJGQyA0MDA2IGFzIHBlciB0aGUNCm9wdGlvbiAxKS4gVGhlIGFpbSBvZiB0aGlz IHVwZGF0ZSBpcyB0byBhbGlnbiB0aGUgRGlhbWV0ZXIgQ3JlZGl0LUNvbnRyb2wNCmFwcGxpY2F0 aW9uIHNwZWNpZmljYXRpb24gd2l0aCB0aGUgSUVURiBSRkMgNjczMywgZml4IGV4aXN0aW5nIGtu b3duIGlzc3Vlcw0KaW4gdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiBhbmQgY29tcGx5IHdpdGgg dGhlIHJlY29tbWVuZGF0aW9ucyBnaXZlbiBpbg0KdGhlIElFVEYgUkZDIDc0MjMgb24gdGhlIGRl c2lnbiBvZiBEaWFtZXRlciBhcHBsaWNhdGlvbi4gVGhlIHRpbWUgbGluZSBmb3INCnRoZSBjb21w bGV0aW9uIG9mIHRoZSBSRkMgNDAwNiB1cGRhdGUgaXMgc2V0IHRvIE5vdmVtYmVyIDIwMTcuDQoN CkFzIGEgcmVtaW5kZXIsIHRoZSBJRVRGIFJGQyA2NzMzIGRvZXMgbm90IGRlZmluZSBhIG5ldyBE aWFtZXRlciBiYXNlIHByb3RvY29sDQpidXQgaXMgYSBuZXcgdmVyc2lvbiBvZiB0aGUgc3BlY2lm aWNhdGlvbiBkZWZpbmluZyB0aGUgRGlhbWV0ZXIgYmFzZSBwcm90b2NvbC4NClRoZSBJRVRGIFJG QyAzNTg4IGlzIG9ic29sZXRlZCBieSB0aGUgSUVURiBSRkMgNjczMywgYXMgZGVmaW5lZCBpbiB0 aGUgSUVURg0KUkZDIDIyMjM6DQoNCiAgIE9ic29sZXRlZC1ieQ0KDQogICAgICBUbyBiZSB1c2Vk IHRvIHJlZmVyIHRvIHRoZSBuZXdlciBkb2N1bWVudChzKSB0aGF0IHJlcGxhY2VzIHRoZQ0KICAg ICAgb2xkZXIgZG9jdW1lbnQuDQoNCkluIHRoZSBwcmVzZW50IGNhc2UsIGFueSBkb2N1bWVudCB1 c2luZyB0aGUgSUVURiBSRkMgMzU4OCBhcyByZWZlcmVuY2UgZm9yDQp0aGUgRGlhbWV0ZXIgYmFz ZSBwcm90b2NvbCBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZlciB0byB0aGUgbmV3IElFVEYgUkZD DQo2NzMzLiBUaGVyZWZvcmUsIGFzIGEgZ2VuZXJhbCBndWlkZWxpbmUsIHRoZSBJRVRGIERJTUUg V0cgcmVjb21tZW5kcyAzR1BQDQpXR3MgdG8gZm9sbG93IHRoaXMgcmVjb21tZW5kYXRpb24gaW4g dGhlaXIgc3BlY2lmaWNhdGlvbnMgd2hlbiBhcHBsaWNhYmxlLg0KVGhlIHNhbWUgcmVjb21tZW5k YXRpb24gd2lsbCBhcHBseSBmb3IgdGhlIHJldmlzaW9uIG9mIHRoZSBJRVRGIFJGQyA0MDA2DQp3 aGVuIHB1Ymxpc2hlZCBieSB0aGUgSUVURiBhcyBmb3IgYW55IG5ldyBSRkMgb2Jzb2xldGluZyBh biBvbGQgUkZDLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpPbiBGcmksIEF1ZyA1LCAyMDE2 IGF0IDEwOjQxIEFNLCBKb3VuaSBLb3Job25lbiA8am91bmkubm9zcGFtQGdtYWlsLmNvbTxtYWls dG86am91bmkubm9zcGFtQGdtYWlsLmNvbT4+IHdyb3RlOg0KRm9sa3MsDQoNCkxpb25lbCBhbmQg SSBoYXZlIGJlZW4gZHJhZnRpbmcgYSByZXBseSBMUyB0byAzR1BQIFNBNSAoYW5kIENDIENUMy9D VDQpLiBUaGlzIGlzIHRoZSBjdXJyZW50IGRyYWZ0LiBDb21tZW50cyBhcmUgd2VsY29tZS4gT25l IHF1ZXN0aW9uIGlzIChMaW9uZWwgZmF2b3VycywgSSBkaXNhZ3JlZSA7KSB3aGV0aGVyIHdlIHNo b3VsZCByZXBlYXQgdGhlIHR3byBxdWVzdGlvbnMgM0dQUCBhc2tlZCBmcm9tIHVzIG9yIGFzc3Vt ZSB0aGV5IGNhbiBsb29rIGl0IHVwIGZyb20gdGhlIG9yaWdpYWwgTFMuDQoNCi0gSm91bmkgJiBM aW9uZWwNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhlIElFVEYgRElNRSBXRyB0aGFua3MgdGhlIDNH UFAgU0E1IFdHIGZvciB0aGVpciBMUyBhbmQgcXVlcnkgcmVnYXJkaW5nIHRoZSBJRVRGIFJGQyA0 MDA2IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQ3MC8pLg0KDQpUaGUg SUVURiBESU1FIFdHIGhhcyBkaXNjdXNzZWQgYm90aCBvcHRpb25zIHJhaXNlZCBpbiB0aGUgTFMg ZnJvbSAzR1BQIFNBNSBhbmQgdGhlIGRlY2lzaW9uIHdhcyBtYWRlIHRvIHVwZGF0ZSBvZiB0aGUg SUVURiBSRkMgNDAwNiAodGhlIG9wdGlvbiAxKS4gVGhlIGFpbSBvZiB0aGlzIHVwZGF0ZSBpcyB0 byBhbGlnbiB0aGUgRGlhbWV0ZXIgQ3JlZGl0LUNvbnRyb2wgYXBwbGljYXRpb24gc3BlY2lmaWNh dGlvbiB3aXRoIHRoZSBJRVRGIFJGQyA2NzMzLCBmaXggZXhpc3Rpbmcga25vd24gaXNzdWVzIGlu IHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gYW5kIGNvbXBseSB3aXRoIHRoZSByZWNvbW1lbmRh dGlvbnMgZ2l2ZW4gaW4gdGhlIElFVEYgUkZDIDc0MjMgb24gdGhlIGRlc2lnbiBvZiBEaWFtZXRl ciBhcHBsaWNhdGlvbi4gVGhlIHRpbWUgbGluZSBmb3IgdGhlIGNvbXBsZXRpb24gb2YgdGhlIFJG QyA0MDA2IHVwZGF0ZSBpcyBzZXQgdG8gTm92ZW1iZXIgMjAxNy4NCg0KQXMgYSByZW1pbmRlciwg dGhlIElFVEYgUkZDIDM1ODggZG9lcyBub3QgZGVmaW5lIGEgbmV3IERpYW1ldGVyIGJhc2UgcHJv dG9jb2wgYnV0IGlzIGEgbmV3IHZlcnNpb24gb2YgdGhlIHNwZWNpZmljYXRpb24gZGVmaW5pbmcg dGhlIERpYW1ldGVyIGJhc2UgcHJvdG9jb2wuIFRoZSBJRVRGIFJGQyAzNTg4IGlzIG9ic29sZXRl ZCBieSB0aGUgSUVURiBSRkMgNjczMywgYXMgZGVmaW5lZCBpbiB0aGUgSUVURiBSRkMgMjIyMzoN Cg0KICAgT2Jzb2xldGVkLWJ5DQoNCiAgICAgIFRvIGJlIHVzZWQgdG8gcmVmZXIgdG8gdGhlIG5l d2VyIGRvY3VtZW50KHMpIHRoYXQgcmVwbGFjZXMgdGhlDQogICAgICBvbGRlciBkb2N1bWVudC4N Cg0KSW4gdGhlIHByZXNlbnQgY2FzZSwgYW55IGRvY3VtZW50IHVzaW5nIHRoZSBJRVRGIFJGQyAz NTg4IGFzIHJlZmVyZW5jZSBmb3IgdGhlIERpYW1ldGVyIGJhc2UgcHJvdG9jb2wgc2hvdWxkIGJl IHVwZGF0ZWQgdG8gcmVmZXIgdG8gdGhlIG5ldyBJRVRGIFJGQyA2NzMzLiBUaGVyZWZvcmUsIGFz IGEgZ2VuZXJhbCBndWlkZWxpbmUsIHRoZSBJRVRGIERJTUUgV0cgcmVjb21tZW5kcyAzR1BQIFdH cyB0byBmb2xsb3cgdGhpcyByZWNvbW1lbmRhdGlvbiBpbiB0aGVpciBzcGVjaWZpY2F0aW9ucyB3 aGVuIGFwcGxpY2FibGUuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSByZWNp cGllbnQocykuIEFueSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0K --_000_ce1a508e435c41f998fda190dc68bc43plswe13m04adsprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgbG9va3MgZmluZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ am91bmkga29yaG9uZW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMTYsIDIw MTYgMzo0NyBQTTxicj4NCjxiPlRvOjwvYj4gZGltZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0RpbWVdIGRyYWZ0IHJlcGx5IExTIHRvIDNHUFAgU0E1IG9uIFJGQyA0MDA2Li48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+SSB1cGRhdGVkIHRoZSBkcmFmdCBMUyBiYXNlZCBvbiB0aGUgaW5w dXQuIFNlZSBiZWxvdyBhbmQgY29tbWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIEpvdW5pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NClRoZSBJRVRGIERJTUUgV0cgdGhhbmtzIHRoZSAzR1BQIFNBNSBXRyBmb3IgdGhl aXIgTFMgYW5kIHF1ZXJ5IHJlZ2FyZGluZyB0aGU8YnI+DQpJRVRGIFJGQyA0MDA2ICg8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQ3MC8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xNDcwLzwvYT4pLjxicj4NCjxicj4NClRoZSBJRVRG IERJTUUgV0cgaGFzIGRpc2N1c3NlZCBib3RoIG9wdGlvbnMgcmFpc2VkIGluIHRoZSBMUyBmcm9t IDNHUFAgU0E1Ojxicj4NCjEpIElzIElFVEYgUkZDIDQwMDYgcGxhbm5lZCB0byBiZSB1cGRhdGVk IGluIG9yZGVyIHRvIHJlbHkgb24gSUVURiBSRkMgNjczMzxicj4NCiZuYnNwOyZuYnNwOyBhcyB0 aGUgbmV3IERpYW1ldGVyIEJhc2UgcHJvdG9jb2w/PGJyPg0KMikgSWYgbm90LCBhcmUgdGhlcmUg YW55IHJlY29tbWVuZGF0aW9ucyBmcm9tIElFVEYgb24gaG93IHRvIGFkZHJlc3MgdGhlPGJyPg0K Jm5ic3A7Jm5ic3A7IGltcGxpY2l0IHJlZmVyZW5jZSB0byBJRVRGIFJGQyAzNTg4IGFzIERpYW1l dGVyIEJhc2UgUHJvdG9jb2wgZm9yIDNHUFA8YnI+DQombmJzcDsmbmJzcDsgU0E1IERpYW1ldGVy IE9ubGluZSBjaGFyZ2luZyB0aHJvdWdoIHVzZSBvZiBJRVRGIFJGQyA0MDA2PyZuYnNwOyZuYnNw OyA8YnI+DQo8YnI+DQphbmQgdGhlIGRlY2lzaW9uIHdhcyBtYWRlIHRvIHVwZGF0ZSBvZiB0aGUg SUVURiBSRkMgNDAwNiBhcyBwZXIgdGhlIDxicj4NCm9wdGlvbiAxKS4gVGhlIGFpbSBvZiB0aGlz IHVwZGF0ZSBpcyB0byBhbGlnbiB0aGUgRGlhbWV0ZXIgQ3JlZGl0LUNvbnRyb2w8YnI+DQphcHBs aWNhdGlvbiBzcGVjaWZpY2F0aW9uIHdpdGggdGhlIElFVEYgUkZDIDY3MzMsIGZpeCBleGlzdGlu ZyBrbm93biBpc3N1ZXM8YnI+DQppbiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uIGFuZCBjb21w bHkgd2l0aCB0aGUgcmVjb21tZW5kYXRpb25zIGdpdmVuIGluPGJyPg0KdGhlIElFVEYgUkZDIDc0 MjMgb24gdGhlIGRlc2lnbiBvZiBEaWFtZXRlciBhcHBsaWNhdGlvbi4gVGhlIHRpbWUgbGluZSBm b3I8YnI+DQp0aGUgY29tcGxldGlvbiBvZiB0aGUgUkZDIDQwMDYgdXBkYXRlIGlzIHNldCB0byBO b3ZlbWJlciAyMDE3Ljxicj4NCjxicj4NCkFzIGEgcmVtaW5kZXIsIHRoZSBJRVRGIFJGQyA2NzMz IGRvZXMgbm90IGRlZmluZSBhIG5ldyBEaWFtZXRlciBiYXNlIHByb3RvY29sPGJyPg0KYnV0IGlz IGEgbmV3IHZlcnNpb24gb2YgdGhlIHNwZWNpZmljYXRpb24gZGVmaW5pbmcgdGhlIERpYW1ldGVy IGJhc2UgcHJvdG9jb2wuPGJyPg0KVGhlIElFVEYgUkZDIDM1ODggaXMgb2Jzb2xldGVkIGJ5IHRo ZSBJRVRGIFJGQyA2NzMzLCBhcyBkZWZpbmVkIGluIHRoZSBJRVRGPGJyPg0KUkZDIDIyMjM6PGJy Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7IE9ic29sZXRlZC1ieTxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUbyBiZSB1c2VkIHRvIHJlZmVyIHRvIHRoZSBuZXdlciBkb2N1 bWVudChzKSB0aGF0IHJlcGxhY2VzIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBvbGRlciBkb2N1bWVudC48YnI+DQo8YnI+DQpJbiB0aGUgcHJlc2VudCBjYXNlLCBhbnkg ZG9jdW1lbnQgdXNpbmcgdGhlIElFVEYgUkZDIDM1ODggYXMgcmVmZXJlbmNlIGZvcjxicj4NCnRo ZSBEaWFtZXRlciBiYXNlIHByb3RvY29sIHNob3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyIHRvIHRo ZSBuZXcgSUVURiBSRkM8YnI+DQo2NzMzLiBUaGVyZWZvcmUsIGFzIGEgZ2VuZXJhbCBndWlkZWxp bmUsIHRoZSBJRVRGIERJTUUgV0cgcmVjb21tZW5kcyAzR1BQPGJyPg0KV0dzIHRvIGZvbGxvdyB0 aGlzIHJlY29tbWVuZGF0aW9uIGluIHRoZWlyIHNwZWNpZmljYXRpb25zIHdoZW4gYXBwbGljYWJs ZS48YnI+DQpUaGUgc2FtZSByZWNvbW1lbmRhdGlvbiB3aWxsIGFwcGx5IGZvciB0aGUgcmV2aXNp b24gb2YgdGhlIElFVEYgUkZDIDQwMDY8YnI+DQp3aGVuIHB1Ymxpc2hlZCBieSB0aGUgSUVURiBh cyBmb3IgYW55IG5ldyBSRkMgb2Jzb2xldGluZyBhbiBvbGQgUkZDLjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXVnIDUsIDIwMTYgYXQgMTA6NDEgQU0sIEpvdW5pIEtv cmhvbmVuICZsdDs8YSBocmVmPSJtYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmpvdW5pLm5vc3BhbUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPkZvbGtzLDxicj4NCjxicj4NCkxpb25lbCBhbmQgSSBoYXZlIGJlZW4gZHJh ZnRpbmcgYSByZXBseSBMUyB0byAzR1BQIFNBNSAoYW5kIENDIENUMy9DVDQpLiBUaGlzIGlzIHRo ZSBjdXJyZW50IGRyYWZ0LiBDb21tZW50cyBhcmUgd2VsY29tZS4gT25lIHF1ZXN0aW9uIGlzIChM aW9uZWwgZmF2b3VycywgSSBkaXNhZ3JlZSA7KSB3aGV0aGVyIHdlIHNob3VsZCByZXBlYXQgdGhl IHR3byBxdWVzdGlvbnMgM0dQUCBhc2tlZCBmcm9tIHVzIG9yIGFzc3VtZSB0aGV5IGNhbiBsb29r IGl0DQogdXAgZnJvbSB0aGUgb3JpZ2lhbCBMUy48YnI+DQo8YnI+DQotIEpvdW5pICZhbXA7IExp b25lbDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaGUgSUVURiBESU1FIFdHIHRo YW5rcyB0aGUgM0dQUCBTQTUgV0cgZm9yIHRoZWlyIExTIGFuZCBxdWVyeSByZWdhcmRpbmcgdGhl IElFVEYgUkZDIDQwMDYgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlh aXNvbi8xNDcwLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bGlhaXNvbi8xNDcwLzwvYT4pLjxicj4NCjxicj4NClRoZSBJRVRGIERJTUUgV0cgaGFzIGRpc2N1 c3NlZCBib3RoIG9wdGlvbnMgcmFpc2VkIGluIHRoZSBMUyBmcm9tIDNHUFAgU0E1IGFuZCB0aGUg ZGVjaXNpb24gd2FzIG1hZGUgdG8gdXBkYXRlIG9mIHRoZSBJRVRGIFJGQyA0MDA2ICh0aGUgb3B0 aW9uIDEpLiBUaGUgYWltIG9mIHRoaXMgdXBkYXRlIGlzIHRvIGFsaWduIHRoZSBEaWFtZXRlciBD cmVkaXQtQ29udHJvbCBhcHBsaWNhdGlvbiBzcGVjaWZpY2F0aW9uIHdpdGggdGhlIElFVEYgUkZD IDY3MzMsDQogZml4IGV4aXN0aW5nIGtub3duIGlzc3VlcyBpbiB0aGUgY3VycmVudCBzcGVjaWZp Y2F0aW9uIGFuZCBjb21wbHkgd2l0aCB0aGUgcmVjb21tZW5kYXRpb25zIGdpdmVuIGluIHRoZSBJ RVRGIFJGQyA3NDIzIG9uIHRoZSBkZXNpZ24gb2YgRGlhbWV0ZXIgYXBwbGljYXRpb24uIFRoZSB0 aW1lIGxpbmUgZm9yIHRoZSBjb21wbGV0aW9uIG9mIHRoZSBSRkMgNDAwNiB1cGRhdGUgaXMgc2V0 IHRvIE5vdmVtYmVyIDIwMTcuPGJyPg0KPGJyPg0KQXMgYSByZW1pbmRlciwgdGhlIElFVEYgUkZD IDM1ODggZG9lcyBub3QgZGVmaW5lIGEgbmV3IERpYW1ldGVyIGJhc2UgcHJvdG9jb2wgYnV0IGlz IGEgbmV3IHZlcnNpb24gb2YgdGhlIHNwZWNpZmljYXRpb24gZGVmaW5pbmcgdGhlIERpYW1ldGVy IGJhc2UgcHJvdG9jb2wuIFRoZSBJRVRGIFJGQyAzNTg4IGlzIG9ic29sZXRlZCBieSB0aGUgSUVU RiBSRkMgNjczMywgYXMgZGVmaW5lZCBpbiB0aGUgSUVURiBSRkMgMjIyMzo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7T2Jzb2xldGVkLWJ5PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg VG8gYmUgdXNlZCB0byByZWZlciB0byB0aGUgbmV3ZXIgZG9jdW1lbnQocykgdGhhdCByZXBsYWNl cyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBvbGRlciBkb2N1bWVudC48YnI+DQo8YnI+ DQpJbiB0aGUgcHJlc2VudCBjYXNlLCBhbnkgZG9jdW1lbnQgdXNpbmcgdGhlIElFVEYgUkZDIDM1 ODggYXMgcmVmZXJlbmNlIGZvciB0aGUgRGlhbWV0ZXIgYmFzZSBwcm90b2NvbCBzaG91bGQgYmUg dXBkYXRlZCB0byByZWZlciB0byB0aGUgbmV3IElFVEYgUkZDIDY3MzMuIFRoZXJlZm9yZSwgYXMg YSBnZW5lcmFsIGd1aWRlbGluZSwgdGhlIElFVEYgRElNRSBXRyByZWNvbW1lbmRzIDNHUFAgV0dz IHRvIGZvbGxvdyB0aGlzIHJlY29tbWVuZGF0aW9uDQogaW4gdGhlaXIgc3BlY2lmaWNhdGlvbnMg d2hlbiBhcHBsaWNhYmxlLjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZv bnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpUaGlzIGUtbWFpbCBt YXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29u dGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS48YnI+ DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_ce1a508e435c41f998fda190dc68bc43plswe13m04adsprintcom_-- From nobody Mon Sep 19 10:02:00 2016 Return-Path: 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 3D91F12B461 for ; Mon, 19 Sep 2016 10:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 k_uWpJsx4d2Q for ; Mon, 19 Sep 2016 10:01:56 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 E8A1D12B45F for ; Mon, 19 Sep 2016 10:01:56 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:50848 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bm1x1-004LOf-Mu; Mon, 19 Sep 2016 10:01:56 -0700 To: Maria Cruz Bartolome , "dime@ietf.org" References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> From: Steve Donovan Message-ID: <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> Date: Mon, 19 Sep 2016 12:01:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 17:01:58 -0000 Maria Cruz, I think we are saying the same thing. My original has an unfortunate typo and should have read as follows: "The calculated LOAD value MUST reflect the sending Diameter node's capacity relative to the maximum available capacity for the sending Diameter node." In thinking about this, the word sending might also not be clear enough. We might want to use the reporting node instead. This would change it to the following: "The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the reporting Diameter node." Regards, Steve On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > Hello Steve, > > Thanks for the proposal. > I still think the text is a bit misleading: > > "The calculated LOAD value MUST reflect the sending Diameter nodes > capacity relative to the maximum available capacity for the sending > Diameter node." > > I think it should be: > "The calculated LOAD value MUST reflect the sending Diameter node > capacity relative to the maximum available capacity for a sending > Diameter node." > > Reasoning: a node may have a very limited maximum capacity, but the key point is precisely to provide a LOAD value relative to the maximum value A node may have. > > I hope this clarifies > Thanks > /MCruz > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: martes, 30 de agosto de 2016 5:59 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > Maria Cruz, > > Thanks for your comments. See my replies inline. > > Regards, > > Steve > > On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: >> Hello Steve, >> >> Thanks for the proposals, see below >> Best regards >> /MCruz >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: martes, 16 de agosto de 2016 16:50 >> To: dime@ietf.org >> Subject: [Dime] Proposed resolutions of LOAD discussion >> >> All, >> >> I have outlined proposed solutions for the issues raised in the discussion around the Diameter Load draft. >> >> Please let me know if I've missed anything from the discussion. >> >> Regards, >> >> Steve >> >> Primary Issues: >> >> 1) Use of DNS SRV weighted value as format for LOAD value. >> >> This was discussed and agreed to early in the process. It has the advantage that Diameter nodes can use a combination of values received via the DNS SRV interface and dynamic values received through the Diameter LOAD interface. While I agree that it isn't as intuitive as a straight percentage value, I don't see this as compelling enough of a reason to change a decision the working group has already made. >> [MCruz] I still think using SRV values is error prone and anti-intuitive, but I can live with this if you really think it is not possible to re-evaluate this now. > SRD> I haven't seen any argument that using the SRV values doesn't > work. As such, I prefer to not change this at this stage of the process. >> 2) Need to add wording that the calculated LOAD value needs to be based on overall available capacity. >> >> I agree with Maria Cruz's comment that we need to add wording indicating that the calculated LOAD value needs to reflect available capacity. To this end, I propose adding the following to section 6.1 (this is based on wording proposed by Maria Cruz): >> >> The calculated LOAD value MUST reflect the Diameter nodes capacity relative to the total available capacity across the Diameter nodes to which requests can be routed. This could be either a set of Diameter endpoints or a set of Diameter agents, depending on the type of the LOAD report. The method for determining the total available capacity is outside of the scope of this document. >> >> Note: The LOAD value should be calculated in a way that reflects the available load independently of the weight of each >> server. This allows the Diameter node that routes a request, including nodes doing server selection and agents routing >> requests, to accurately compare values from different nodes. Any specific LOAD value needs to identify the same >> amount of available capacity, regardless the Diameter node that calculates the value. >> >> The mechanism used to calculate the LOAD value that fulfills this requirement is an implementation decision. >> >> >> [MCruz] Some comments to proposed text: >> " The calculated LOAD value MUST reflect the Diameter nodes capacity relative to the total available capacity across the Diameter nodes to which requests can be routed. ": I think it may be misleading what is the "total available capacity across nodes". >> See proposal: >> " The calculated LOAD value MUST reflect each Diameter node capacity relative to the maximum available capacity for a Diameter node to which requests can be routed." > SRD> This wording could imply that the LOAD value carries load > information for multiple Diameter nodes. How about the following: > > "The calculated LOAD value MUST reflect the sending Diameter nodes > capacity relative to the maximum available capacity for the sending > Diameter node." > >> 3) Wording in Appendix A. >> >> Before we reword Appendix A, we need to decide if it is still needed. >> It was valuable in helping to generate the solution but I'm not convinced it is still needed in the document. Is there objection to removing this section? >> >> [MCruz] I prefer this to remain, it provides some hints that may be valuable for first time readers. > SRD> I'd like to hear other opinions on this as there is work required > to make the section consistent with the mechanism defined. Implementors > will still have access to this information by reviewing the history of > the process of writing the specification. > > SRD> Are there schedule pressures in 3GPP to get this to RFC state? If > so, it will be faster to just remove this section. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 19 10:12:21 2016 Return-Path: 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 73A0812B445 for ; Mon, 19 Sep 2016 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 88vOErIeYlw3 for ; Mon, 19 Sep 2016 10:12:18 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 71EC112B495 for ; Mon, 19 Sep 2016 10:11:51 -0700 (PDT) X-AuditID: c1b4fb25-5405a9800000793b-54-57e01c553824 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 93.AB.31035.55C10E75; Mon, 19 Sep 2016 19:11:49 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.167]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Mon, 19 Sep 2016 19:11:48 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgIAbDa6AgAAihBA= Date: Mon, 19 Sep 2016 17:11:46 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> In-Reply-To: <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7qG6ozINwg/kdihZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGf13fzAWLLGquPyjl6WBcZ9eFyMnh4SAiUTT 4xfMXYxcHEIC6xklbs/5xArhLGGU6Nq4gw2kik3ATuLS6RdMILaIgK/E8c7TLCC2sIC1xPa9 u5kh4jYSH35sgKrxk9j1YweYzSKgKrH0wAtWEJsXqPfxtivsEAt2MkksPvkWrIhTwEmiffIt sCJGATGJ76fWgMWZBcQlbj2ZzwRxqoDEkj3nmSFsUYmXj/+xQthKEj82XGKBqNeRWLD7ExuE rS2xbOFrZojFghInZz5hmcAoMgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjY73Uoszk4uL8 PL281JJNjMCIOLjlt+oOxstvHA8xCnAwKvHwJry/Hy7EmlhWXJl7iFGCg1lJhDde+kG4EG9K YmVValF+fFFpTmrxIUZpDhYlcV6zlUDVAumJJanZqakFqUUwWSYOTqkGxnDee27db24JHVie XWjIufbYImOWRjktraA1G6cpOfxu+e7z8dy2RXqtOr/y5X72GCZsWcR+JGgDz+cq/9ncqlc7 TmxzLq/1sdJZeXGzmPtamZWJ/LZ+jAczE5/JWe9WeyJmfG5PTLxALEfn5akrZr3I6fScwfvV 9Iy+PteH8MK6TrW8lT4blViKMxINtZiLihMBPIiiS4QCAAA= Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 17:12:20 -0000 Hello Steve, Thanks for the clarification I still think the last part of the sentence is misleading: "... relative to= the maximum available capacity for the reporting Diameter node ". It should be "... relative to the maximum available capacity for a reportin= g Diameter node". The reasoning is that it should be relative to the maximum capacity not of = that particular reporting node, but any of the nodes. That is, if we use SR= V to provide the load value, the maximum load is 65535, but a particular no= de may just have a maximum capacity of e.g. 4000. Then the load value of th= is reporting node should be relative not to 4000 but to 65535, and it shoul= d be done the same for all nodes, in a way that the load is then comparable= by the reacting node. Is my point clearer now? The NOTE you wrote clarified that point in fact. Best regards /MCruz -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: lunes, 19 de septiembre de 2016 19:02 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] Proposed resolutions of LOAD discussion Maria Cruz, I think we are saying the same thing. My original has an unfortunate typo = and should have read as follows: "The calculated LOAD value MUST reflect the sending Diameter node's capacit= y relative to the maximum available capacity for the sending Diameter node.= " In thinking about this, the word sending might also not be clear enough. W= e might want to use the reporting node instead. This would change it to th= e following: "The calculated LOAD value MUST reflect the reporting Diameter node's capac= ity relative to the maximum available capacity for the reporting Diameter n= ode." Regards, Steve On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > Hello Steve, > > Thanks for the proposal. > I still think the text is a bit misleading: > > "The calculated LOAD value MUST reflect the sending Diameter nodes=20 > capacity relative to the maximum available capacity for the sending=20 > Diameter node." > > I think it should be: > "The calculated LOAD value MUST reflect the sending Diameter node=20 > capacity relative to the maximum available capacity for a sending=20 > Diameter node." > > Reasoning: a node may have a very limited maximum capacity, but the key p= oint is precisely to provide a LOAD value relative to the maximum value A n= ode may have. > > I hope this clarifies > Thanks > /MCruz > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: martes, 30 de agosto de 2016 5:59 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > Maria Cruz, > > Thanks for your comments. See my replies inline. > > Regards, > > Steve > > On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: >> Hello Steve, >> >> Thanks for the proposals, see below >> Best regards >> /MCruz >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: martes, 16 de agosto de 2016 16:50 >> To: dime@ietf.org >> Subject: [Dime] Proposed resolutions of LOAD discussion >> >> All, >> >> I have outlined proposed solutions for the issues raised in the discussi= on around the Diameter Load draft. >> >> Please let me know if I've missed anything from the discussion. >> >> Regards, >> >> Steve >> >> Primary Issues: >> >> 1) Use of DNS SRV weighted value as format for LOAD value. >> >> This was discussed and agreed to early in the process. It has the advan= tage that Diameter nodes can use a combination of values received via the D= NS SRV interface and dynamic values received through the Diameter LOAD inte= rface. While I agree that it isn't as intuitive as a straight percentage v= alue, I don't see this as compelling enough of a reason to change a decisio= n the working group has already made. >> [MCruz] I still think using SRV values is error prone and anti-intuitive= , but I can live with this if you really think it is not possible to re-eva= luate this now. > SRD> I haven't seen any argument that using the SRV values doesn't > work. As such, I prefer to not change this at this stage of the process. >> 2) Need to add wording that the calculated LOAD value needs to be based = on overall available capacity. >> >> I agree with Maria Cruz's comment that we need to add wording indicating= that the calculated LOAD value needs to reflect available capacity. To th= is end, I propose adding the following to section 6.1 (this is based on wor= ding proposed by Maria Cruz): >> >> The calculated LOAD value MUST reflect the Diameter nodes capacity relat= ive to the total available capacity across the Diameter nodes to which requ= ests can be routed. This could be either a set of Diameter endpoints or a = set of Diameter agents, depending on the type of the LOAD report. The meth= od for determining the total available capacity is outside of the scope of = this document. >> >> Note: The LOAD value should be calculated in a way that reflects t= he available load independently of the weight of each >> server. This allows the Diameter node that routes a request, incl= uding nodes doing server selection and agents routing >> requests, to accurately compare values from different nodes. Any = specific LOAD value needs to identify the same >> amount of available capacity, regardless the Diameter node that ca= lculates the value. >> >> The mechanism used to calculate the LOAD value that fulfills this requir= ement is an implementation decision. >> >> >> [MCruz] Some comments to proposed text: >> " The calculated LOAD value MUST reflect the Diameter nodes capacity rel= ative to the total available capacity across the Diameter nodes to which re= quests can be routed. ": I think it may be misleading what is the "total av= ailable capacity across nodes". >> See proposal: >> " The calculated LOAD value MUST reflect each Diameter node capacity rel= ative to the maximum available capacity for a Diameter node to which reques= ts can be routed." > SRD> This wording could imply that the LOAD value carries load > information for multiple Diameter nodes. How about the following: > > "The calculated LOAD value MUST reflect the sending Diameter nodes=20 > capacity relative to the maximum available capacity for the sending=20 > Diameter node." > >> 3) Wording in Appendix A. >> >> Before we reword Appendix A, we need to decide if it is still needed. >> It was valuable in helping to generate the solution but I'm not convince= d it is still needed in the document. Is there objection to removing this = section? >> >> [MCruz] I prefer this to remain, it provides some hints that may be valu= able for first time readers. > SRD> I'd like to hear other opinions on this as there is work required > to make the section consistent with the mechanism defined.=20 > Implementors will still have access to this information by reviewing=20 > the history of the process of writing the specification. > > SRD> Are there schedule pressures in 3GPP to get this to RFC state? =20 > SRD> If > so, it will be faster to just remove this section. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 19 10:47:06 2016 Return-Path: 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 C5AB612B135 for ; Mon, 19 Sep 2016 10:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WoD1r8bNjnJl for ; Mon, 19 Sep 2016 10:47:01 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B45512B12D for ; Mon, 19 Sep 2016 10:47:01 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id q2so33018432pfj.3 for ; Mon, 19 Sep 2016 10:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=j0iOp4rFIVatPCwlYOLBqG0ilUCA7JgbTQLY8PPoi4w=; b=QVRJPZp6lMOLSo+8y1qmKLS52ZD8gHnXj/9PAgXrPMc4JmjcuQF77atGEZg2g9J/le 3ZGL7WGxpIru+Yvpi0HTwxjVDI6WjZrYcpN4kAxCipQ5N1LkIy0lP0MCkWRopC3oNhEl ifcEb5rE/I1c2oI7bQhqr4SGxJwqOInRvPVegPVMDGzIuXqBZ9Z4X5we1V4FUF9fBHTA URfIO0fHYfrl3lJiQRtjQay3NjTY/vcvzU6ZCKHImbQeVMUJ0P2znE3JKphxV7oTBynT T6DujAdQ9lYI0+j/mt5UAsct8ys/jFSA6hdIhIFdzTxO3Q4eBwJ3wBXmcIo2994S1pCE 1LZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=j0iOp4rFIVatPCwlYOLBqG0ilUCA7JgbTQLY8PPoi4w=; b=N/neZ0AjnYOuYxGH21aEm6aOYgHgaH4IHjNDpGvEknRxVenWRWhcF2Aj7tLqUjfqbU CgFKpbMPJgWrr9+NVf1pfqdLXZc2OoDM8rFMnFuPvRNSYEfGmh2ZHJ1T+l45oIdlWpaa wE149tf1U2sMQtJmcpfpPWu1+OGOeIdZVaBUANe5amjKzuWQoIia1ShE1Lte87RBXUrq C5Q/oyIUqJETODWa6MLlwbjyQX7OXJnWNgdv61wZhTUoAhta4OzheVTgkQfET4Bg2bX1 JPLXVw1+EJ0Nw//5dnOrdZrEPgqepktE0lwut6zNY82r638uPnNJu/Tovx2GLfQUUNq2 1I0g== X-Gm-Message-State: AE9vXwMrV7EgZnQu1/DhlS0ckEXYqnmAaEzWjELz6VxKXt/7dNLPYHgksT+de7Y8u+XkBw== X-Received: by 10.98.68.148 with SMTP id m20mr49430758pfi.0.1474307221043; Mon, 19 Sep 2016 10:47:01 -0700 (PDT) Received: from ?IPv6:2601:647:4200:e520:51f6:e092:3a5d:beb4? ([2601:647:4200:e520:51f6:e092:3a5d:beb4]) by smtp.gmail.com with ESMTPSA id an11sm33095392pac.26.2016.09.19.10.47.00 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 10:47:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Mon, 19 Sep 2016 10:46:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> To: "dime@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 17:47:04 -0000 Everybody happy with the text? - Jouni > On 16 Sep 2016, at 13:47, jouni korhonen = wrote: >=20 > Folks, >=20 > I updated the draft LS based on the input. See below and comment.=20 >=20 > - Jouni >=20 > = --------------------------------------------------------------------------= ----- > The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query = regarding the > IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/). >=20 > The IETF DIME WG has discussed both options raised in the LS from 3GPP = SA5: > 1) Is IETF RFC 4006 planned to be updated in order to rely on IETF RFC = 6733 > as the new Diameter Base protocol? > 2) If not, are there any recommendations from IETF on how to address = the > implicit reference to IETF RFC 3588 as Diameter Base Protocol for = 3GPP > SA5 Diameter Online charging through use of IETF RFC 4006? =20 >=20 > and the decision was made to update of the IETF RFC 4006 as per the=20 > option 1). The aim of this update is to align the Diameter = Credit-Control > application specification with the IETF RFC 6733, fix existing known = issues > in the current specification and comply with the recommendations given = in > the IETF RFC 7423 on the design of Diameter application. The time line = for > the completion of the RFC 4006 update is set to November 2017. >=20 > As a reminder, the IETF RFC 6733 does not define a new Diameter base = protocol > but is a new version of the specification defining the Diameter base = protocol. > The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the = IETF > RFC 2223: >=20 > Obsoleted-by >=20 > To be used to refer to the newer document(s) that replaces the > older document. >=20 > In the present case, any document using the IETF RFC 3588 as reference = for > the Diameter base protocol should be updated to refer to the new IETF = RFC > 6733. Therefore, as a general guideline, the IETF DIME WG recommends = 3GPP > WGs to follow this recommendation in their specifications when = applicable. > The same recommendation will apply for the revision of the IETF RFC = 4006 > when published by the IETF as for any new RFC obsoleting an old RFC. > = --------------------------------------------------------------------------= ----- >=20 >=20 > On Fri, Aug 5, 2016 at 10:41 AM, Jouni Korhonen = wrote: > Folks, >=20 > Lionel and I have been drafting a reply LS to 3GPP SA5 (and CC = CT3/CT4). This is the current draft. Comments are welcome. One question = is (Lionel favours, I disagree ;) whether we should repeat the two = questions 3GPP asked from us or assume they can look it up from the = origial LS. >=20 > - Jouni & Lionel >=20 > = ------------------------------------------------------------------------- > The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query = regarding the IETF RFC 4006 = (https://datatracker.ietf.org/liaison/1470/). >=20 > The IETF DIME WG has discussed both options raised in the LS from 3GPP = SA5 and the decision was made to update of the IETF RFC 4006 (the option = 1). The aim of this update is to align the Diameter Credit-Control = application specification with the IETF RFC 6733, fix existing known = issues in the current specification and comply with the recommendations = given in the IETF RFC 7423 on the design of Diameter application. The = time line for the completion of the RFC 4006 update is set to November = 2017. >=20 > As a reminder, the IETF RFC 3588 does not define a new Diameter base = protocol but is a new version of the specification defining the Diameter = base protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as = defined in the IETF RFC 2223: >=20 > Obsoleted-by >=20 > To be used to refer to the newer document(s) that replaces the > older document. >=20 > In the present case, any document using the IETF RFC 3588 as reference = for the Diameter base protocol should be updated to refer to the new = IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG = recommends 3GPP WGs to follow this recommendation in their = specifications when applicable. > = ------------------------------------------------------------------------- >=20 >=20 >=20 >=20 From nobody Mon Sep 19 11:34:45 2016 Return-Path: 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 801B112B145 for ; Mon, 19 Sep 2016 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 2xt6TXEmWiRJ for ; Mon, 19 Sep 2016 11:34:42 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 2EF8B12B4B3 for ; Mon, 19 Sep 2016 11:34:42 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:52515 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bm3Oo-001KHM-2E; Mon, 19 Sep 2016 11:34:41 -0700 To: Maria Cruz Bartolome , "dime@ietf.org" References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> From: Steve Donovan Message-ID: <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> Date: Mon, 19 Sep 2016 13:34:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 18:34:44 -0000 Actually, looking at it again, I think the following wording is needed: "The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the set of Diameter nodes that are potential receiving nodes for the future messages covered by the LOAD report." We probably need some words on what the set of Diameter nodes comprises, as it is different for HOST reports and PEER reports. Does this work? Steve On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > Hello Steve, > > Thanks for the clarification > I still think the last part of the sentence is misleading: "... relative to the maximum available capacity for the reporting Diameter node ". > > It should be "... relative to the maximum available capacity for a reporting Diameter node". > > The reasoning is that it should be relative to the maximum capacity not of that particular reporting node, but any of the nodes. That is, if we use SRV to provide the load value, the maximum load is 65535, but a particular node may just have a maximum capacity of e.g. 4000. Then the load value of this reporting node should be relative not to 4000 but to 65535, and it should be done the same for all nodes, in a way that the load is then comparable by the reacting node. > Is my point clearer now? > The NOTE you wrote clarified that point in fact. > > Best regards > /MCruz > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: lunes, 19 de septiembre de 2016 19:02 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > Maria Cruz, > > I think we are saying the same thing. My original has an unfortunate typo and should have read as follows: > > "The calculated LOAD value MUST reflect the sending Diameter node's capacity relative to the maximum available capacity for the sending Diameter node." > > In thinking about this, the word sending might also not be clear enough. We might want to use the reporting node instead. This would change it to the following: > > "The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum available capacity for the reporting Diameter node." > > Regards, > > Steve > > On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: >> Hello Steve, >> >> Thanks for the proposal. >> I still think the text is a bit misleading: >> >> "The calculated LOAD value MUST reflect the sending Diameter nodes >> capacity relative to the maximum available capacity for the sending >> Diameter node." >> >> I think it should be: >> "The calculated LOAD value MUST reflect the sending Diameter node >> capacity relative to the maximum available capacity for a sending >> Diameter node." >> >> Reasoning: a node may have a very limited maximum capacity, but the key point is precisely to provide a LOAD value relative to the maximum value A node may have. >> >> I hope this clarifies >> Thanks >> /MCruz >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: martes, 30 de agosto de 2016 5:59 >> To: Maria Cruz Bartolome; dime@ietf.org >> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >> >> Maria Cruz, >> >> Thanks for your comments. See my replies inline. >> >> Regards, >> >> Steve >> >> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: >>> Hello Steve, >>> >>> Thanks for the proposals, see below >>> Best regards >>> /MCruz >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: martes, 16 de agosto de 2016 16:50 >>> To: dime@ietf.org >>> Subject: [Dime] Proposed resolutions of LOAD discussion >>> >>> All, >>> >>> I have outlined proposed solutions for the issues raised in the discussion around the Diameter Load draft. >>> >>> Please let me know if I've missed anything from the discussion. >>> >>> Regards, >>> >>> Steve >>> >>> Primary Issues: >>> >>> 1) Use of DNS SRV weighted value as format for LOAD value. >>> >>> This was discussed and agreed to early in the process. It has the advantage that Diameter nodes can use a combination of values received via the DNS SRV interface and dynamic values received through the Diameter LOAD interface. While I agree that it isn't as intuitive as a straight percentage value, I don't see this as compelling enough of a reason to change a decision the working group has already made. >>> [MCruz] I still think using SRV values is error prone and anti-intuitive, but I can live with this if you really think it is not possible to re-evaluate this now. >> SRD> I haven't seen any argument that using the SRV values doesn't >> work. As such, I prefer to not change this at this stage of the process. >>> 2) Need to add wording that the calculated LOAD value needs to be based on overall available capacity. >>> >>> I agree with Maria Cruz's comment that we need to add wording indicating that the calculated LOAD value needs to reflect available capacity. To this end, I propose adding the following to section 6.1 (this is based on wording proposed by Maria Cruz): >>> >>> The calculated LOAD value MUST reflect the Diameter nodes capacity relative to the total available capacity across the Diameter nodes to which requests can be routed. This could be either a set of Diameter endpoints or a set of Diameter agents, depending on the type of the LOAD report. The method for determining the total available capacity is outside of the scope of this document. >>> >>> Note: The LOAD value should be calculated in a way that reflects the available load independently of the weight of each >>> server. This allows the Diameter node that routes a request, including nodes doing server selection and agents routing >>> requests, to accurately compare values from different nodes. Any specific LOAD value needs to identify the same >>> amount of available capacity, regardless the Diameter node that calculates the value. >>> >>> The mechanism used to calculate the LOAD value that fulfills this requirement is an implementation decision. >>> >>> >>> [MCruz] Some comments to proposed text: >>> " The calculated LOAD value MUST reflect the Diameter nodes capacity relative to the total available capacity across the Diameter nodes to which requests can be routed. ": I think it may be misleading what is the "total available capacity across nodes". >>> See proposal: >>> " The calculated LOAD value MUST reflect each Diameter node capacity relative to the maximum available capacity for a Diameter node to which requests can be routed." >> SRD> This wording could imply that the LOAD value carries load >> information for multiple Diameter nodes. How about the following: >> >> "The calculated LOAD value MUST reflect the sending Diameter nodes >> capacity relative to the maximum available capacity for the sending >> Diameter node." >> >>> 3) Wording in Appendix A. >>> >>> Before we reword Appendix A, we need to decide if it is still needed. >>> It was valuable in helping to generate the solution but I'm not convinced it is still needed in the document. Is there objection to removing this section? >>> >>> [MCruz] I prefer this to remain, it provides some hints that may be valuable for first time readers. >> SRD> I'd like to hear other opinions on this as there is work required >> to make the section consistent with the mechanism defined. >> Implementors will still have access to this information by reviewing >> the history of the process of writing the specification. >> >> SRD> Are there schedule pressures in 3GPP to get this to RFC state? >> SRD> If >> so, it will be faster to just remove this section. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 19 11:45:18 2016 Return-Path: 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 97F0212B4DC for ; Mon, 19 Sep 2016 11:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pgoV3OU8jDrV for ; Mon, 19 Sep 2016 11:45:14 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 CBF6112B13B for ; Mon, 19 Sep 2016 11:45:13 -0700 (PDT) X-AuditID: c1b4fb30-b73ff70000000cb2-cf-57e03237a015 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id CE.F4.03250.73230E75; Mon, 19 Sep 2016 20:45:12 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.167]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Mon, 19 Sep 2016 20:45:07 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgIAbDa6AgAAihBD///dngIAAIdpg Date: Mon, 19 Sep 2016 18:45:06 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> In-Reply-To: <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7tK6F0YNwg72v+Czm9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Mnqf/WIu2Ohe8WLKWrYGxnbLLkZODgkBE4nD k+YwdTFycQgJrGeUeHr3KwuEs4RR4mPbYTaQKjYBO4lLp18wgdgiAr4SxztPs4DYwgLWEtv3 7maGiNtIfPixAaomSqJn9kqwXhYBVYlHyw+B2bxAvQ/mbYRasJVZoqnzLliCU8BJYsm/dWA2 o4CYxPdTa8AGMQuIS9x6Mp8J4lQBiSV7zjND2KISLx//Y4WwlSR+bLjEAlGvI7Fg9yc2CFtb YtnC18wQiwUlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6 eaklmxiBEXFwy2+DHYwvnzseYhTgYFTi4U14fz9ciDWxrLgy9xCjBAezkgjvOd0H4UK8KYmV ValF+fFFpTmpxYcYpTlYlMR5zVYCVQukJ5akZqemFqQWwWSZODilGhg1Fs+J8uuaJji3YU/A DpWjM5yDrgdfO5NmIh1zp1LUUpuVTfdSnK1aYnjkvBvtW32jjDtvHJ7ieM/9mY6yXLPweav5 21QS2OTestW4sxs8WvFZQGvBC6NwoY9eFW8ez72a7qYxqz0sZLLqxc2X4jQYjwvoLgpdv8iX Y/GmQ3mbt5sWfjVfoarEUpyRaKjFXFScCADzJs9OhAIAAA== Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 18:45:17 -0000 Hello Steve, See proposal: "The calculated LOAD value MUST reflect the reporting Diameter node's capac= ity relative to the maximum capacity for a Diameter node in the group of no= des the messages are load balanced". I removed "available" because it may be misinterpreted as "available at a m= oment in time", what is not right, it is just the maximum capacity it is of= fered, it can be reached. "for a Diameter node": in order to indicate that it is the maximum capacity= of "any" of the Diameter nodes, what a Diameter node is normally offering.= =20 But we can limit that to the group of nodes that are receivers of messages,= i.e. the load-balancing group. Does it make sense to you? Thanks Steve -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: lunes, 19 de septiembre de 2016 20:35 To: Maria Cruz Bartolome; dime@ietf.org Subject: Re: [Dime] Proposed resolutions of LOAD discussion Actually, looking at it again, I think the following wording is needed: "The calculated LOAD value MUST reflect the reporting Diameter node's capac= ity relative to the maximum available capacity for the set of Diameter node= s that are potential receiving nodes for the future messages covered by the= LOAD report." We probably need some words on what the set of Diameter nodes comprises, as= it is different for HOST reports and PEER reports. Does this work? Steve On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > Hello Steve, > > Thanks for the clarification > I still think the last part of the sentence is misleading: "... relative = to the maximum available capacity for the reporting Diameter node ". > > It should be "... relative to the maximum available capacity for a report= ing Diameter node". > > The reasoning is that it should be relative to the maximum capacity not o= f that particular reporting node, but any of the nodes. That is, if we use = SRV to provide the load value, the maximum load is 65535, but a particular = node may just have a maximum capacity of e.g. 4000. Then the load value of = this reporting node should be relative not to 4000 but to 65535, and it sho= uld be done the same for all nodes, in a way that the load is then comparab= le by the reacting node. > Is my point clearer now? > The NOTE you wrote clarified that point in fact. > > Best regards > /MCruz > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: lunes, 19 de septiembre de 2016 19:02 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > Maria Cruz, > > I think we are saying the same thing. My original has an unfortunate typ= o and should have read as follows: > > "The calculated LOAD value MUST reflect the sending Diameter node's capac= ity relative to the maximum available capacity for the sending Diameter nod= e." > > In thinking about this, the word sending might also not be clear enough. = We might want to use the reporting node instead. This would change it to = the following: > > "The calculated LOAD value MUST reflect the reporting Diameter node's cap= acity relative to the maximum available capacity for the reporting Diameter= node." > > Regards, > > Steve > > On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: >> Hello Steve, >> >> Thanks for the proposal. >> I still think the text is a bit misleading: >> >> "The calculated LOAD value MUST reflect the sending Diameter nodes=20 >> capacity relative to the maximum available capacity for the sending=20 >> Diameter node." >> >> I think it should be: >> "The calculated LOAD value MUST reflect the sending Diameter node=20 >> capacity relative to the maximum available capacity for a sending=20 >> Diameter node." >> >> Reasoning: a node may have a very limited maximum capacity, but the key = point is precisely to provide a LOAD value relative to the maximum value A = node may have. >> >> I hope this clarifies >> Thanks >> /MCruz >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: martes, 30 de agosto de 2016 5:59 >> To: Maria Cruz Bartolome; dime@ietf.org >> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >> >> Maria Cruz, >> >> Thanks for your comments. See my replies inline. >> >> Regards, >> >> Steve >> >> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: >>> Hello Steve, >>> >>> Thanks for the proposals, see below >>> Best regards >>> /MCruz >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: martes, 16 de agosto de 2016 16:50 >>> To: dime@ietf.org >>> Subject: [Dime] Proposed resolutions of LOAD discussion >>> >>> All, >>> >>> I have outlined proposed solutions for the issues raised in the discuss= ion around the Diameter Load draft. >>> >>> Please let me know if I've missed anything from the discussion. >>> >>> Regards, >>> >>> Steve >>> >>> Primary Issues: >>> >>> 1) Use of DNS SRV weighted value as format for LOAD value. >>> >>> This was discussed and agreed to early in the process. It has the adva= ntage that Diameter nodes can use a combination of values received via the = DNS SRV interface and dynamic values received through the Diameter LOAD int= erface. While I agree that it isn't as intuitive as a straight percentage = value, I don't see this as compelling enough of a reason to change a decisi= on the working group has already made. >>> [MCruz] I still think using SRV values is error prone and anti-intuitiv= e, but I can live with this if you really think it is not possible to re-ev= aluate this now. >> SRD> I haven't seen any argument that using the SRV values doesn't >> work. As such, I prefer to not change this at this stage of the process= . >>> 2) Need to add wording that the calculated LOAD value needs to be based= on overall available capacity. >>> >>> I agree with Maria Cruz's comment that we need to add wording indicatin= g that the calculated LOAD value needs to reflect available capacity. To t= his end, I propose adding the following to section 6.1 (this is based on wo= rding proposed by Maria Cruz): >>> >>> The calculated LOAD value MUST reflect the Diameter nodes capacity rela= tive to the total available capacity across the Diameter nodes to which req= uests can be routed. This could be either a set of Diameter endpoints or a= set of Diameter agents, depending on the type of the LOAD report. The met= hod for determining the total available capacity is outside of the scope of= this document. >>> >>> Note: The LOAD value should be calculated in a way that reflects= the available load independently of the weight of each >>> server. This allows the Diameter node that routes a request, in= cluding nodes doing server selection and agents routing >>> requests, to accurately compare values from different nodes. An= y specific LOAD value needs to identify the same >>> amount of available capacity, regardless the Diameter node that = calculates the value. >>> >>> The mechanism used to calculate the LOAD value that fulfills this requi= rement is an implementation decision. >>> >>> >>> [MCruz] Some comments to proposed text: >>> " The calculated LOAD value MUST reflect the Diameter nodes capacity re= lative to the total available capacity across the Diameter nodes to which r= equests can be routed. ": I think it may be misleading what is the "total a= vailable capacity across nodes". >>> See proposal: >>> " The calculated LOAD value MUST reflect each Diameter node capacity re= lative to the maximum available capacity for a Diameter node to which reque= sts can be routed." >> SRD> This wording could imply that the LOAD value carries load >> information for multiple Diameter nodes. How about the following: >> >> "The calculated LOAD value MUST reflect the sending Diameter nodes=20 >> capacity relative to the maximum available capacity for the sending=20 >> Diameter node." >> >>> 3) Wording in Appendix A. >>> >>> Before we reword Appendix A, we need to decide if it is still needed. >>> It was valuable in helping to generate the solution but I'm not convinc= ed it is still needed in the document. Is there objection to removing this= section? >>> >>> [MCruz] I prefer this to remain, it provides some hints that may be val= uable for first time readers. >> SRD> I'd like to hear other opinions on this as there is work=20 >> SRD> required >> to make the section consistent with the mechanism defined. >> Implementors will still have access to this information by reviewing=20 >> the history of the process of writing the specification. >> >> SRD> Are there schedule pressures in 3GPP to get this to RFC state? >> SRD> If >> so, it will be faster to just remove this section. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 19 11:59:07 2016 Return-Path: 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 2B40A12B4D8 for ; Mon, 19 Sep 2016 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 H-UTa9YH8WmB for ; Mon, 19 Sep 2016 11:59:04 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0406F12B1D6 for ; Mon, 19 Sep 2016 11:59:04 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 64E21C0407; Mon, 19 Sep 2016 20:59:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 3FA331A0069; Mon, 19 Sep 2016 20:59:02 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0301.000; Mon, 19 Sep 2016 20:59:02 +0200 From: To: Jouni , "dime@ietf.org" Thread-Topic: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. Thread-Index: AQHR70GraMlGrjHkmkGf62JtggdC/KB8tvcAgASEooCAADWbQA== Date: Mon, 19 Sep 2016 18:59:01 +0000 Message-ID: <17142_1474311542_57E03576_17142_6918_1_6B7134B31289DC4FAF731D844122B36E01FB9D9E@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 18:59:06 -0000 I'm fine too. Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoy=E9=A0: lundi 19 septembre 2016 19:47 > =C0=A0: dime@ietf.org > Objet=A0: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. >=20 > Everybody happy with the text? >=20 > - Jouni >=20 >=20 > > On 16 Sep 2016, at 13:47, jouni korhonen wrote: > > > > Folks, > > > > I updated the draft LS based on the input. See below and comment. > > > > - Jouni > > > > ---------------------------------------------------------------------- > > --------- The IETF DIME WG thanks the 3GPP SA5 WG for their LS and > > query regarding the IETF RFC 4006 > > (https://datatracker.ietf.org/liaison/1470/). > > > > The IETF DIME WG has discussed both options raised in the LS from 3GPP = SA5: > > 1) Is IETF RFC 4006 planned to be updated in order to rely on IETF RFC = 6733 > > as the new Diameter Base protocol? > > 2) If not, are there any recommendations from IETF on how to address the > > implicit reference to IETF RFC 3588 as Diameter Base Protocol for 3G= PP > > SA5 Diameter Online charging through use of IETF RFC 4006? > > > > and the decision was made to update of the IETF RFC 4006 as per the > > option 1). The aim of this update is to align the Diameter > > Credit-Control application specification with the IETF RFC 6733, fix > > existing known issues in the current specification and comply with the > > recommendations given in the IETF RFC 7423 on the design of Diameter > > application. The time line for the completion of the RFC 4006 update is= set to > November 2017. > > > > As a reminder, the IETF RFC 6733 does not define a new Diameter base > > protocol but is a new version of the specification defining the Diamete= r base > protocol. > > The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the > > IETF RFC 2223: > > > > Obsoleted-by > > > > To be used to refer to the newer document(s) that replaces the > > older document. > > > > In the present case, any document using the IETF RFC 3588 as reference > > for the Diameter base protocol should be updated to refer to the new > > IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG > > recommends 3GPP WGs to follow this recommendation in their specificatio= ns > when applicable. > > The same recommendation will apply for the revision of the IETF RFC > > 4006 when published by the IETF as for any new RFC obsoleting an old RF= C. > > ---------------------------------------------------------------------- > > --------- > > > > > > On Fri, Aug 5, 2016 at 10:41 AM, Jouni Korhonen > wrote: > > Folks, > > > > Lionel and I have been drafting a reply LS to 3GPP SA5 (and CC CT3/CT4)= . This > is the current draft. Comments are welcome. One question is (Lionel favou= rs, I > disagree ;) whether we should repeat the two questions 3GPP asked from us= or > assume they can look it up from the origial LS. > > > > - Jouni & Lionel > > > > ---------------------------------------------------------------------- > > --- The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query > > regarding the IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/= ). > > > > The IETF DIME WG has discussed both options raised in the LS from 3GPP = SA5 > and the decision was made to update of the IETF RFC 4006 (the option 1). = The > aim of this update is to align the Diameter Credit-Control application > specification with the IETF RFC 6733, fix existing known issues in the cu= rrent > specification and comply with the recommendations given in the IETF RFC 7= 423 > on the design of Diameter application. The time line for the completion o= f the > RFC 4006 update is set to November 2017. > > > > As a reminder, the IETF RFC 3588 does not define a new Diameter base > protocol but is a new version of the specification defining the Diameter = base > protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined= in the > IETF RFC 2223: > > > > Obsoleted-by > > > > To be used to refer to the newer document(s) that replaces the > > older document. > > > > In the present case, any document using the IETF RFC 3588 as reference = for > the Diameter base protocol should be updated to refer to the new IETF RFC > 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP > WGs to follow this recommendation in their specifications when applicable. > > ---------------------------------------------------------------------- > > --- > > > > > > > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Sep 19 12:21:20 2016 Return-Path: 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 C0D4E12B4E3 for ; Mon, 19 Sep 2016 12:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] 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 n-k2kwLB87aw for ; Mon, 19 Sep 2016 12:21:17 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A8112B015 for ; Mon, 19 Sep 2016 12:21:17 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 19 Sep 2016 15:21:16 -0400 From: Dave Dolson To: "lionel.morand@orange.com" , Jouni , "dime@ietf.org" Thread-Topic: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. Thread-Index: AQHR70GrXGVt+Nt0EkuX481hGuyqjqB9G4wAgASEooCAABQhgP//wxgQ Date: Mon, 19 Sep 2016 19:21:15 +0000 Message-ID: References: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> <17142_1474311542_57E03576_17142_6918_1_6B7134B31289DC4FAF731D844122B36E01FB9D9E@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <17142_1474311542_57E03576_17142_6918_1_6B7134B31289DC4FAF731D844122B36E01FB9D9E@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 19:21:20 -0000 +1 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Monday, September 19, 2016 2:59 PM To: Jouni; dime@ietf.org Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. I'm fine too. Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoy=E9=A0: lundi 19 septembre 2016 19:47 > =C0=A0: dime@ietf.org > Objet=A0: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. >=20 > Everybody happy with the text? >=20 > - Jouni >=20 >=20 > > On 16 Sep 2016, at 13:47, jouni korhonen wrote= : > > > > Folks, > > > > I updated the draft LS based on the input. See below and comment. > > > > - Jouni > > > > ---------------------------------------------------------------------- > > --------- The IETF DIME WG thanks the 3GPP SA5 WG for their LS and > > query regarding the IETF RFC 4006 > > (https://datatracker.ietf.org/liaison/1470/). > > > > The IETF DIME WG has discussed both options raised in the LS from 3GPP = SA5: > > 1) Is IETF RFC 4006 planned to be updated in order to rely on IETF RFC = 6733 > > as the new Diameter Base protocol? > > 2) If not, are there any recommendations from IETF on how to address th= e > > implicit reference to IETF RFC 3588 as Diameter Base Protocol for 3G= PP > > SA5 Diameter Online charging through use of IETF RFC 4006? > > > > and the decision was made to update of the IETF RFC 4006 as per the > > option 1). The aim of this update is to align the Diameter > > Credit-Control application specification with the IETF RFC 6733, fix > > existing known issues in the current specification and comply with the > > recommendations given in the IETF RFC 7423 on the design of Diameter > > application. The time line for the completion of the RFC 4006 update is= set to > November 2017. > > > > As a reminder, the IETF RFC 6733 does not define a new Diameter base > > protocol but is a new version of the specification defining the Diamete= r base > protocol. > > The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the > > IETF RFC 2223: > > > > Obsoleted-by > > > > To be used to refer to the newer document(s) that replaces the > > older document. > > > > In the present case, any document using the IETF RFC 3588 as reference > > for the Diameter base protocol should be updated to refer to the new > > IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG > > recommends 3GPP WGs to follow this recommendation in their specificatio= ns > when applicable. > > The same recommendation will apply for the revision of the IETF RFC > > 4006 when published by the IETF as for any new RFC obsoleting an old RF= C. > > ---------------------------------------------------------------------- > > --------- > > > > > > On Fri, Aug 5, 2016 at 10:41 AM, Jouni Korhonen > wrote: > > Folks, > > > > Lionel and I have been drafting a reply LS to 3GPP SA5 (and CC CT3/CT4)= . This > is the current draft. Comments are welcome. One question is (Lionel favou= rs, I > disagree ;) whether we should repeat the two questions 3GPP asked from us= or > assume they can look it up from the origial LS. > > > > - Jouni & Lionel > > > > ---------------------------------------------------------------------- > > --- The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query > > regarding the IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/= ). > > > > The IETF DIME WG has discussed both options raised in the LS from 3GPP = SA5 > and the decision was made to update of the IETF RFC 4006 (the option 1). = The > aim of this update is to align the Diameter Credit-Control application > specification with the IETF RFC 6733, fix existing known issues in the cu= rrent > specification and comply with the recommendations given in the IETF RFC 7= 423 > on the design of Diameter application. The time line for the completion o= f the > RFC 4006 update is set to November 2017. > > > > As a reminder, the IETF RFC 3588 does not define a new Diameter base > protocol but is a new version of the specification defining the Diameter = base > protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined= in the > IETF RFC 2223: > > > > Obsoleted-by > > > > To be used to refer to the newer document(s) that replaces the > > older document. > > > > In the present case, any document using the IETF RFC 3588 as reference = for > the Diameter base protocol should be updated to refer to the new IETF RFC > 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP > WGs to follow this recommendation in their specifications when applicable= . > > ---------------------------------------------------------------------- > > --- > > > > > > > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 19 12:49:27 2016 Return-Path: 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 72AFF12B036 for ; Mon, 19 Sep 2016 12:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JyYs2QcYdrnE for ; Mon, 19 Sep 2016 12:49:24 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1DF12B02B for ; Mon, 19 Sep 2016 12:49:23 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g192so162324454ywh.1 for ; Mon, 19 Sep 2016 12:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eY+uyQhQsgM1sSgHsHozQUEXX0vJ2k+fkIJetnvqHh4=; b=CNuc1Piy/R/UGK/oRm7i4/1/M1Wcp4ZDCkrV3lfQz64buXUW9lq3DPliOrO0UlpzrE urFhiIRP45Y9s2Wm5a8JmgFItHD5lRM9SO4EB/8u+mbWJgLVDL4q0vZb6I7akFjRRd8X PKhpRtJAVWy3l8iHX0+HxKD3F4ZyQcfoE3XvpQGasPqDpx8Sy9AyOyZriKEq99TEhWBJ QATIy11rXyuKtzLqHa6/7PoK0PXJYwv39SpBkOynTnHNNVjx3WPldZMx9blAHYsmG+3u U183ceZe97MgQe5ZeFx5B+tJEoSCsN4Q2Vp7M171fu9NEtFaOBYs/kK+5IPnDP9j0USK 9zzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eY+uyQhQsgM1sSgHsHozQUEXX0vJ2k+fkIJetnvqHh4=; b=VHsNMDYb1HCd4rxfey1tJOpeK1TlW0ybu59jITOBVhU3WD1QaRjl7HKWzbbTS5j6Xi jMnkqSDDc8VVucPvZlqalElySt7iPPlk3vIM1cWFelzoJrDG2490wN2/tGzzdm1A9FK0 uvibum2BBUv9dIxftaZ8W0ClgoTLlGDw24XbZDaSEerQDbli6DeHpkwrYTyZa/Kvcfd0 amuRIuCVZ/gY4+6WRP3TFhw7imzMxkazqL639o97Aw+X/ttLIo0SaxhqYnUSdbuUn84+ 1vyDK19uiqxV8kdc3UI5HM3WRhcMotyIYAbcw62WMgqp+91d41FIKjEbwrBBrocjLQXM Rbwg== X-Gm-Message-State: AE9vXwOa9mYy458kM81G3Usv1PtXRwUU1j04dCUkFtp+eDVzQZ6y0/596Blis+/jajpF6k7Ctp+BygbEBHJR+g== X-Received: by 10.129.109.66 with SMTP id i63mr27154437ywc.171.1474314563096; Mon, 19 Sep 2016 12:49:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.95.67 with HTTP; Mon, 19 Sep 2016 12:49:22 -0700 (PDT) In-Reply-To: References: <15d3fa95-db4d-d3c5-273c-8d4419e1b156@gmail.com> <17142_1474311542_57E03576_17142_6918_1_6B7134B31289DC4FAF731D844122B36E01FB9D9E@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: jouni korhonen Date: Mon, 19 Sep 2016 12:49:22 -0700 Message-ID: To: Dave Dolson Content-Type: multipart/alternative; boundary=001a114db3c2d22e7f053ce19ba8 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 19:49:26 -0000 --001a114db3c2d22e7f053ce19ba8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok. I think we can move forward send this reply to 3GPP. - Jouni On Mon, Sep 19, 2016 at 12:21 PM, Dave Dolson wrote: > +1 > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of > lionel.morand@orange.com > Sent: Monday, September 19, 2016 2:59 PM > To: Jouni; dime@ietf.org > Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. > > I'm fine too. > > Lionel > > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > > Envoy=C3=A9 : lundi 19 septembre 2016 19:47 > > =C3=80 : dime@ietf.org > > Objet : Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006.. > > > > Everybody happy with the text? > > > > - Jouni > > > > > > > On 16 Sep 2016, at 13:47, jouni korhonen > wrote: > > > > > > Folks, > > > > > > I updated the draft LS based on the input. See below and comment. > > > > > > - Jouni > > > > > > ---------------------------------------------------------------------= - > > > --------- The IETF DIME WG thanks the 3GPP SA5 WG for their LS and > > > query regarding the IETF RFC 4006 > > > (https://datatracker.ietf.org/liaison/1470/). > > > > > > The IETF DIME WG has discussed both options raised in the LS from 3GP= P > SA5: > > > 1) Is IETF RFC 4006 planned to be updated in order to rely on IETF RF= C > 6733 > > > as the new Diameter Base protocol? > > > 2) If not, are there any recommendations from IETF on how to address > the > > > implicit reference to IETF RFC 3588 as Diameter Base Protocol for > 3GPP > > > SA5 Diameter Online charging through use of IETF RFC 4006? > > > > > > and the decision was made to update of the IETF RFC 4006 as per the > > > option 1). The aim of this update is to align the Diameter > > > Credit-Control application specification with the IETF RFC 6733, fix > > > existing known issues in the current specification and comply with th= e > > > recommendations given in the IETF RFC 7423 on the design of Diameter > > > application. The time line for the completion of the RFC 4006 update > is set to > > November 2017. > > > > > > As a reminder, the IETF RFC 6733 does not define a new Diameter base > > > protocol but is a new version of the specification defining the > Diameter base > > protocol. > > > The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in th= e > > > IETF RFC 2223: > > > > > > Obsoleted-by > > > > > > To be used to refer to the newer document(s) that replaces the > > > older document. > > > > > > In the present case, any document using the IETF RFC 3588 as referenc= e > > > for the Diameter base protocol should be updated to refer to the new > > > IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG > > > recommends 3GPP WGs to follow this recommendation in their > specifications > > when applicable. > > > The same recommendation will apply for the revision of the IETF RFC > > > 4006 when published by the IETF as for any new RFC obsoleting an old > RFC. > > > ---------------------------------------------------------------------= - > > > --------- > --001a114db3c2d22e7f053ce19ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok. I think we can move forward send this re= ply to 3GPP.

- Jouni

On Mon, Sep 19, 2016 at 12:21 PM, D= ave Dolson <ddolson@sandvine.com> wrote:
+1

-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.org] On Behalf Of lionel= .morand@orange.com
Sent: Monday, September 19, 2016 2:59 PM
To: Jouni; dime@ietf.org
Subject: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006..

I'm fine too.

Lionel

> -----Message d'origine-----
> De=C2=A0: DiME [mailto:dime-b= ounces@ietf.org] De la part de Jouni
> Envoy=C3=A9=C2=A0: lundi 19 septembre 2016 19:47
> =C3=80=C2=A0: dime@ietf.org
> Objet=C2=A0: Re: [Dime] draft reply LS to 3GPP SA5 on RFC 4006..
>
> Everybody happy with the text?
>
> - Jouni
>
>
> > On 16 Sep 2016, at 13:47, jouni korhonen <jouni.nospam@gmail.com> wrote:
> >
> > Folks,
> >
> > I updated the draft LS based on the input. See below and comment.=
> >
> > - Jouni
> >
> > ------------------------------------------------------------= ----------
> > --------- The IETF DIME WG thanks the 3GPP SA5 WG for their LS an= d
> > query regarding the IETF RFC 4006
> > (https://datatracker.ietf.org/liaison/1470/= ).
> >
> > The IETF DIME WG has discussed both options raised in the LS from= 3GPP SA5:
> > 1) Is IETF RFC 4006 planned to be updated in order to rely on IET= F RFC 6733
> >=C2=A0 =C2=A0 as the new Diameter Base protocol?
> > 2) If not, are there any recommendations from IETF on how to addr= ess the
> >=C2=A0 =C2=A0 implicit reference to IETF RFC 3588 as Diameter Base= Protocol for 3GPP
> >=C2=A0 =C2=A0 SA5 Diameter Online charging through use of IETF RFC= 4006?
> >
> > and the decision was made to update of the IETF RFC 4006 as per t= he
> > option 1). The aim of this update is to align the Diameter
> > Credit-Control application specification with the IETF RFC 6733, = fix
> > existing known issues in the current specification and comply wit= h the
> > recommendations given in the IETF RFC 7423 on the design of Diame= ter
> > application. The time line for the completion of the RFC 4006 upd= ate is set to
> November 2017.
> >
> > As a reminder, the IETF RFC 6733 does not define a new Diameter b= ase
> > protocol but is a new version of the specification defining the D= iameter base
> protocol.
> > The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined i= n the
> > IETF RFC 2223:
> >
> >=C2=A0 =C2=A0 Obsoleted-by
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0To be used to refer to the newer docume= nt(s) that replaces the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0older document.
> >
> > In the present case, any document using the IETF RFC 3588 as refe= rence
> > for the Diameter base protocol should be updated to refer to the = new
> > IETF RFC 6733. Therefore, as a general guideline, the IETF DIME W= G
> > recommends 3GPP WGs to follow this recommendation in their specif= ications
> when applicable.
> > The same recommendation will apply for the revision of the IETF R= FC
> > 4006 when published by the IETF as for any new RFC obsoleting an = old RFC.
> > ------------------------------------------------------------= ----------
> > ---------

--001a114db3c2d22e7f053ce19ba8-- From nobody Mon Sep 19 15:01:01 2016 Return-Path: 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 43B9012B55F for ; Mon, 19 Sep 2016 15:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 svWNUpW25thh for ; Mon, 19 Sep 2016 15:00:57 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F5412B55B for ; Mon, 19 Sep 2016 15:00:56 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 6E1C7C035B; Tue, 20 Sep 2016 00:00:55 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 32304120055; Tue, 20 Sep 2016 00:00:55 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0301.000; Tue, 20 Sep 2016 00:00:55 +0200 From: To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982JsHJ6KECqOEaXB6jDMNvt0KBZVduAgAd+u4CABRrdAIAbLnKAgAACxgCAABclgIAAAu4AgABR9dA= Date: Mon, 19 Sep 2016 22:00:54 +0000 Message-ID: <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 22:00:59 -0000 Hi, I was wondering if we could simplify in a way that would be understandable = for anyone outside the current discussion. Is something missing in the following text? "The calculated LOAD value MUST indicate the relative capacity of a Diamete= r node to process or forward subsequent request messages. The method for de= termining the total available capacity is outside of the scope of this docu= ment. NOTE: When the reporting node is not a server, the LOAD value reflects not = only the capacity of the reporting node but also the total capacity of the = Diameter nodes to which requests can be forwarded." Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Barto= lome > Envoy=E9=A0: lundi 19 septembre 2016 20:45 > =C0=A0: Steve Donovan; dime@ietf.org > Objet=A0: Re: [Dime] Proposed resolutions of LOAD discussion >=20 > Hello Steve, >=20 > See proposal: >=20 > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum capacity for a Diameter node in the grou= p of > nodes the messages are load balanced". >=20 > I removed "available" because it may be misinterpreted as "available at a > moment in time", what is not right, it is just the maximum capacity it is= offered, > it can be reached. > "for a Diameter node": in order to indicate that it is the maximum capaci= ty of > "any" of the Diameter nodes, what a Diameter node is normally offering. > But we can limit that to the group of nodes that are receivers of message= s, i.e. > the load-balancing group. >=20 > Does it make sense to you? > Thanks Steve >=20 > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: lunes, 19 de septiembre de 2016 20:35 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Proposed resolutions of LOAD discussion >=20 > Actually, looking at it again, I think the following wording is needed: >=20 > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum available capacity for the set of Diamet= er > nodes that are potential receiving nodes for the future messages covered = by the > LOAD report." >=20 > We probably need some words on what the set of Diameter nodes comprises, = as > it is different for HOST reports and PEER reports. >=20 > Does this work? >=20 > Steve >=20 > On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > > Hello Steve, > > > > Thanks for the clarification > > I still think the last part of the sentence is misleading: "... relativ= e to the > maximum available capacity for the reporting Diameter node ". > > > > It should be "... relative to the maximum available capacity for a repo= rting > Diameter node". > > > > The reasoning is that it should be relative to the maximum capacity not= of that > particular reporting node, but any of the nodes. That is, if we use SRV t= o provide > the load value, the maximum load is 65535, but a particular node may just= have > a maximum capacity of e.g. 4000. Then the load value of this reporting no= de > should be relative not to 4000 but to 65535, and it should be done the sa= me for > all nodes, in a way that the load is then comparable by the reacting node. > > Is my point clearer now? > > The NOTE you wrote clarified that point in fact. > > > > Best regards > > /MCruz > > > > -----Original Message----- > > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > Sent: lunes, 19 de septiembre de 2016 19:02 > > To: Maria Cruz Bartolome; dime@ietf.org > > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > > > Maria Cruz, > > > > I think we are saying the same thing. My original has an unfortunate t= ypo and > should have read as follows: > > > > "The calculated LOAD value MUST reflect the sending Diameter node's > capacity relative to the maximum available capacity for the sending Diame= ter > node." > > > > In thinking about this, the word sending might also not be clear enough= . We > might want to use the reporting node instead. This would change it to the > following: > > > > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum available capacity for the reporting Dia= meter > node." > > > > Regards, > > > > Steve > > > > On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > >> Hello Steve, > >> > >> Thanks for the proposal. > >> I still think the text is a bit misleading: > >> > >> "The calculated LOAD value MUST reflect the sending Diameter nodes > >> capacity relative to the maximum available capacity for the sending > >> Diameter node." > >> > >> I think it should be: > >> "The calculated LOAD value MUST reflect the sending Diameter node > >> capacity relative to the maximum available capacity for a sending > >> Diameter node." > >> > >> Reasoning: a node may have a very limited maximum capacity, but the key > point is precisely to provide a LOAD value relative to the maximum value = A node > may have. > >> > >> I hope this clarifies > >> Thanks > >> /MCruz > >> > >> -----Original Message----- > >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >> Sent: martes, 30 de agosto de 2016 5:59 > >> To: Maria Cruz Bartolome; dime@ietf.org > >> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >> > >> Maria Cruz, > >> > >> Thanks for your comments. See my replies inline. > >> > >> Regards, > >> > >> Steve > >> > >> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > >>> Hello Steve, > >>> > >>> Thanks for the proposals, see below > >>> Best regards > >>> /MCruz > >>> > >>> -----Original Message----- > >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > >>> Sent: martes, 16 de agosto de 2016 16:50 > >>> To: dime@ietf.org > >>> Subject: [Dime] Proposed resolutions of LOAD discussion > >>> > >>> All, > >>> > >>> I have outlined proposed solutions for the issues raised in the discu= ssion > around the Diameter Load draft. > >>> > >>> Please let me know if I've missed anything from the discussion. > >>> > >>> Regards, > >>> > >>> Steve > >>> > >>> Primary Issues: > >>> > >>> 1) Use of DNS SRV weighted value as format for LOAD value. > >>> > >>> This was discussed and agreed to early in the process. It has the ad= vantage > that Diameter nodes can use a combination of values received via the DNS = SRV > interface and dynamic values received through the Diameter LOAD interface. > While I agree that it isn't as intuitive as a straight percentage value, = I don't see > this as compelling enough of a reason to change a decision the working gr= oup > has already made. > >>> [MCruz] I still think using SRV values is error prone and anti-intuit= ive, but I > can live with this if you really think it is not possible to re-evaluate = this now. > >> SRD> I haven't seen any argument that using the SRV values doesn't > >> work. As such, I prefer to not change this at this stage of the proce= ss. > >>> 2) Need to add wording that the calculated LOAD value needs to be bas= ed > on overall available capacity. > >>> > >>> I agree with Maria Cruz's comment that we need to add wording indicat= ing > that the calculated LOAD value needs to reflect available capacity. To t= his end, I > propose adding the following to section 6.1 (this is based on wording pro= posed > by Maria Cruz): > >>> > >>> The calculated LOAD value MUST reflect the Diameter nodes capacity > relative to the total available capacity across the Diameter nodes to whi= ch > requests can be routed. This could be either a set of Diameter endpoints= or a set > of Diameter agents, depending on the type of the LOAD report. The method= for > determining the total available capacity is outside of the scope of this > document. > >>> > >>> Note: The LOAD value should be calculated in a way that reflec= ts the > available load independently of the weight of each > >>> server. This allows the Diameter node that routes a request, = including > nodes doing server selection and agents routing > >>> requests, to accurately compare values from different nodes. = Any > specific LOAD value needs to identify the same > >>> amount of available capacity, regardless the Diameter node that > calculates the value. > >>> > >>> The mechanism used to calculate the LOAD value that fulfills this > requirement is an implementation decision. > >>> > >>> > >>> [MCruz] Some comments to proposed text: > >>> " The calculated LOAD value MUST reflect the Diameter nodes capacity > relative to the total available capacity across the Diameter nodes to whi= ch > requests can be routed. ": I think it may be misleading what is the "total > available capacity across nodes". > >>> See proposal: > >>> " The calculated LOAD value MUST reflect each Diameter node capacity > relative to the maximum available capacity for a Diameter node to which > requests can be routed." > >> SRD> This wording could imply that the LOAD value carries load > >> information for multiple Diameter nodes. How about the following: > >> > >> "The calculated LOAD value MUST reflect the sending Diameter nodes > >> capacity relative to the maximum available capacity for the sending > >> Diameter node." > >> > >>> 3) Wording in Appendix A. > >>> > >>> Before we reword Appendix A, we need to decide if it is still needed. > >>> It was valuable in helping to generate the solution but I'm not convi= nced it is > still needed in the document. Is there objection to removing this sectio= n? > >>> > >>> [MCruz] I prefer this to remain, it provides some hints that may be v= aluable > for first time readers. > >> SRD> I'd like to hear other opinions on this as there is work > >> SRD> required > >> to make the section consistent with the mechanism defined. > >> Implementors will still have access to this information by reviewing > >> the history of the process of writing the specification. > >> > >> SRD> Are there schedule pressures in 3GPP to get this to RFC state? > >> SRD> If > >> so, it will be faster to just remove this section. > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Sep 19 15:07:43 2016 Return-Path: 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 8C37C12B006 for ; Mon, 19 Sep 2016 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yi7wgasmr5Mu for ; Mon, 19 Sep 2016 15:07:38 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1070712B562 for ; Mon, 19 Sep 2016 15:07:14 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 841252021F; Tue, 20 Sep 2016 00:07:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 46C171A005D; Tue, 20 Sep 2016 00:07:12 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0301.000; Tue, 20 Sep 2016 00:07:12 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982JsHJ6KECqOEaXB6jDMNvt0KCBkwsQ Date: Mon, 19 Sep 2016 22:07:11 +0000 Message-ID: <17142_1474322832_57E06190_17142_11002_1_6B7134B31289DC4FAF731D844122B36E01FBA733@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> In-Reply-To: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 22:07:42 -0000 =20 > Primary Issues: >=20 > 1) Use of DNS SRV weighted value as format for LOAD value. >=20 > This was discussed and agreed to early in the process. It has the advant= age that > Diameter nodes can use a combination of values received via the DNS SRV > interface and dynamic values received through the Diameter LOAD interface. > While I agree that it isn't as intuitive as a straight percentage value, = I don't see > this as compelling enough of a reason to change a decision the working gr= oup > has already made. [LM] ok to keep DNS SRV weighted value type. >=20 > 2) Need to add wording that the calculated LOAD value needs to be based on > overall available capacity. >=20 > I agree with Maria Cruz's comment that we need to add wording indicating = that > the calculated LOAD value needs to reflect available capacity. To this e= nd, I > propose adding the following to section 6.1 (this is based on wording pro= posed > by Maria Cruz): >=20 > The calculated LOAD value MUST reflect the Diameter nodes capacity relati= ve to > the total available capacity across the Diameter nodes to which requests = can be > routed. This could be either a set of Diameter endpoints or a set of Dia= meter > agents, depending on the type of the LOAD report. The method for determi= ning > the total available capacity is outside of the scope of this document. >=20 > Note: The LOAD value should be calculated in a way that reflects the = available > load independently of the weight of each > server. This allows the Diameter node that routes a request, includi= ng nodes > doing server selection and agents routing > requests, to accurately compare values from different nodes. Any spe= cific > LOAD value needs to identify the same > amount of available capacity, regardless the Diameter node that calcu= lates > the value. >=20 > The mechanism used to calculate the LOAD value that fulfills this require= ment is > an implementation decision. [LM] see other email. >=20 > 3) Wording in Appendix A. >=20 > Before we reword Appendix A, we need to decide if it is still needed. > It was valuable in helping to generate the solution but I'm not convinced= it is still > needed in the document. Is there objection to removing this section? [LM] if it is only for information, we can just remove them. If someone ide= ntifies important aspects that need to be kept, it would mean that the body= is not self-consistent. If we keep it, we will have to ensure that the con= tent is correct, even if informative, as the appendix is reviewed during IE= TF LC as any other part of the document and it would be painful to trigger = useless discussions on a pure informative part. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 20 00:32:34 2016 Return-Path: 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 1D6C912B648 for ; Tue, 20 Sep 2016 00:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EUi-nBj41nv4 for ; Tue, 20 Sep 2016 00:32:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3A6E812B544 for ; Tue, 20 Sep 2016 00:32:29 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-26-57e0e60bb77a Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 74.51.02458.B06E0E75; Tue, 20 Sep 2016 09:32:27 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.167]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Tue, 20 Sep 2016 09:32:25 +0200 From: Maria Cruz Bartolome To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgIAbDa6AgAAihBD///dngIAAIdpggAAXyQCAAMB+8A== Date: Tue, 20 Sep 2016 07:32:25 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ny73swfhBqf6jC3m9q5gs7i9PdNi QxOPA7PHkiU/mTxanp1k81j1to81gDmKyyYlNSezLLVI3y6BK+PJ/T2sBR+TKia//8XUwLjP r4uRk0NCwERi9Zq/bF2MXBxCAusZJWZ/Oc0C4SxhlHj/dCozSBWbgJ3EpdMvmEASIgJtjBLd k+azgCSEBawltu/dDVYkImAj8eHHBiYIO0ti1oz3YDaLgKpE0+M97CA2r4CvxKcHi1khNvxg kXh5eA07iMMp0Mko8WfOHrAORgExie+n1oDZzALiEreezGeCOFZAYsme88wQtqjEy8f/WCFs RYmPr/YxQtTrSdyYOoUNwtaWWLbwNTPEZkGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFaNo cWpxcW66kZFealFmcnFxfp5eXmrJJkZgnBzc8ttqB+PB546HGAU4GJV4eBPe3w8XYk0sK67M PcQowcGsJMLb//RBuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFes5VA1QLpiSWp2ampBalFMFkm Dk6pBsZlqZMOsT8ydHneuyh+8VxL+x2iD5mj+N5ws36xsnr6RGI9eyVPUfTy7ypLpYuUHSKO tR/7MvHt5P/ssYXym9VnHD+z0OWzwvZw2VPK7LvF2BOvn5+q+OZQZKz/Vg7LqbfXBZmpW7/S uPD8r0f9Zsmf4W3m2n/rs9LXyzFn6V7JLlty6EegaYkSS3FGoqEWc1FxIgDZXzeWjwIAAA== Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 07:32:33 -0000 Hello Lionel, We need to clarify "relative to what". This is the part we are rephrasing. Anyway, I will keep NOTE by Steve: Note: The LOAD value should be calculated in a way that reflects the available load independently of the weight of each server. This allows the Diameter node that routes a request, including nodes doing server selection and agents routing requests, to accurately compare values from different nodes. Any specific LOAD value needs to identify the same amount of available capacity, regardless the Diameter node that calculates the value. The mechanism used to calculate the LOAD value that fulfils this requirement is an implementation decision. Cheers /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: martes, 20 de septiembre de 2016 0:01 To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org Subject: RE: [Dime] Proposed resolutions of LOAD discussion Hi, I was wondering if we could simplify in a way that would be understandable = for anyone outside the current discussion. Is something missing in the following text? "The calculated LOAD value MUST indicate the relative capacity of a Diamete= r node to process or forward subsequent request messages. The method for de= termining the total available capacity is outside of the scope of this docu= ment. NOTE: When the reporting node is not a server, the LOAD value reflects not = only the capacity of the reporting node but also the total capacity of the = Diameter nodes to which requests can be forwarded." Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Barto= lome > Envoy=E9=A0: lundi 19 septembre 2016 20:45 > =C0=A0: Steve Donovan; dime@ietf.org > Objet=A0: Re: [Dime] Proposed resolutions of LOAD discussion >=20 > Hello Steve, >=20 > See proposal: >=20 > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum capacity for a Diameter node in the grou= p of > nodes the messages are load balanced". >=20 > I removed "available" because it may be misinterpreted as "available at a > moment in time", what is not right, it is just the maximum capacity it is= offered, > it can be reached. > "for a Diameter node": in order to indicate that it is the maximum capaci= ty of > "any" of the Diameter nodes, what a Diameter node is normally offering. > But we can limit that to the group of nodes that are receivers of message= s, i.e. > the load-balancing group. >=20 > Does it make sense to you? > Thanks Steve >=20 > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: lunes, 19 de septiembre de 2016 20:35 > To: Maria Cruz Bartolome; dime@ietf.org > Subject: Re: [Dime] Proposed resolutions of LOAD discussion >=20 > Actually, looking at it again, I think the following wording is needed: >=20 > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum available capacity for the set of Diamet= er > nodes that are potential receiving nodes for the future messages covered = by the > LOAD report." >=20 > We probably need some words on what the set of Diameter nodes comprises, = as > it is different for HOST reports and PEER reports. >=20 > Does this work? >=20 > Steve >=20 > On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > > Hello Steve, > > > > Thanks for the clarification > > I still think the last part of the sentence is misleading: "... relativ= e to the > maximum available capacity for the reporting Diameter node ". > > > > It should be "... relative to the maximum available capacity for a repo= rting > Diameter node". > > > > The reasoning is that it should be relative to the maximum capacity not= of that > particular reporting node, but any of the nodes. That is, if we use SRV t= o provide > the load value, the maximum load is 65535, but a particular node may just= have > a maximum capacity of e.g. 4000. Then the load value of this reporting no= de > should be relative not to 4000 but to 65535, and it should be done the sa= me for > all nodes, in a way that the load is then comparable by the reacting node= . > > Is my point clearer now? > > The NOTE you wrote clarified that point in fact. > > > > Best regards > > /MCruz > > > > -----Original Message----- > > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > Sent: lunes, 19 de septiembre de 2016 19:02 > > To: Maria Cruz Bartolome; dime@ietf.org > > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > > > Maria Cruz, > > > > I think we are saying the same thing. My original has an unfortunate t= ypo and > should have read as follows: > > > > "The calculated LOAD value MUST reflect the sending Diameter node's > capacity relative to the maximum available capacity for the sending Diame= ter > node." > > > > In thinking about this, the word sending might also not be clear enough= . We > might want to use the reporting node instead. This would change it to th= e > following: > > > > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum available capacity for the reporting Dia= meter > node." > > > > Regards, > > > > Steve > > > > On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > >> Hello Steve, > >> > >> Thanks for the proposal. > >> I still think the text is a bit misleading: > >> > >> "The calculated LOAD value MUST reflect the sending Diameter nodes > >> capacity relative to the maximum available capacity for the sending > >> Diameter node." > >> > >> I think it should be: > >> "The calculated LOAD value MUST reflect the sending Diameter node > >> capacity relative to the maximum available capacity for a sending > >> Diameter node." > >> > >> Reasoning: a node may have a very limited maximum capacity, but the ke= y > point is precisely to provide a LOAD value relative to the maximum value = A node > may have. > >> > >> I hope this clarifies > >> Thanks > >> /MCruz > >> > >> -----Original Message----- > >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >> Sent: martes, 30 de agosto de 2016 5:59 > >> To: Maria Cruz Bartolome; dime@ietf.org > >> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >> > >> Maria Cruz, > >> > >> Thanks for your comments. See my replies inline. > >> > >> Regards, > >> > >> Steve > >> > >> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > >>> Hello Steve, > >>> > >>> Thanks for the proposals, see below > >>> Best regards > >>> /MCruz > >>> > >>> -----Original Message----- > >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > >>> Sent: martes, 16 de agosto de 2016 16:50 > >>> To: dime@ietf.org > >>> Subject: [Dime] Proposed resolutions of LOAD discussion > >>> > >>> All, > >>> > >>> I have outlined proposed solutions for the issues raised in the discu= ssion > around the Diameter Load draft. > >>> > >>> Please let me know if I've missed anything from the discussion. > >>> > >>> Regards, > >>> > >>> Steve > >>> > >>> Primary Issues: > >>> > >>> 1) Use of DNS SRV weighted value as format for LOAD value. > >>> > >>> This was discussed and agreed to early in the process. It has the ad= vantage > that Diameter nodes can use a combination of values received via the DNS = SRV > interface and dynamic values received through the Diameter LOAD interface= . > While I agree that it isn't as intuitive as a straight percentage value, = I don't see > this as compelling enough of a reason to change a decision the working gr= oup > has already made. > >>> [MCruz] I still think using SRV values is error prone and anti-intuit= ive, but I > can live with this if you really think it is not possible to re-evaluate = this now. > >> SRD> I haven't seen any argument that using the SRV values doesn't > >> work. As such, I prefer to not change this at this stage of the proce= ss. > >>> 2) Need to add wording that the calculated LOAD value needs to be bas= ed > on overall available capacity. > >>> > >>> I agree with Maria Cruz's comment that we need to add wording indicat= ing > that the calculated LOAD value needs to reflect available capacity. To t= his end, I > propose adding the following to section 6.1 (this is based on wording pro= posed > by Maria Cruz): > >>> > >>> The calculated LOAD value MUST reflect the Diameter nodes capacity > relative to the total available capacity across the Diameter nodes to whi= ch > requests can be routed. This could be either a set of Diameter endpoints= or a set > of Diameter agents, depending on the type of the LOAD report. The method= for > determining the total available capacity is outside of the scope of this > document. > >>> > >>> Note: The LOAD value should be calculated in a way that reflec= ts the > available load independently of the weight of each > >>> server. This allows the Diameter node that routes a request, = including > nodes doing server selection and agents routing > >>> requests, to accurately compare values from different nodes. = Any > specific LOAD value needs to identify the same > >>> amount of available capacity, regardless the Diameter node tha= t > calculates the value. > >>> > >>> The mechanism used to calculate the LOAD value that fulfills this > requirement is an implementation decision. > >>> > >>> > >>> [MCruz] Some comments to proposed text: > >>> " The calculated LOAD value MUST reflect the Diameter nodes capacity > relative to the total available capacity across the Diameter nodes to whi= ch > requests can be routed. ": I think it may be misleading what is the "tota= l > available capacity across nodes". > >>> See proposal: > >>> " The calculated LOAD value MUST reflect each Diameter node capacity > relative to the maximum available capacity for a Diameter node to which > requests can be routed." > >> SRD> This wording could imply that the LOAD value carries load > >> information for multiple Diameter nodes. How about the following: > >> > >> "The calculated LOAD value MUST reflect the sending Diameter nodes > >> capacity relative to the maximum available capacity for the sending > >> Diameter node." > >> > >>> 3) Wording in Appendix A. > >>> > >>> Before we reword Appendix A, we need to decide if it is still needed. > >>> It was valuable in helping to generate the solution but I'm not convi= nced it is > still needed in the document. Is there objection to removing this sectio= n? > >>> > >>> [MCruz] I prefer this to remain, it provides some hints that may be v= aluable > for first time readers. > >> SRD> I'd like to hear other opinions on this as there is work > >> SRD> required > >> to make the section consistent with the mechanism defined. > >> Implementors will still have access to this information by reviewing > >> the history of the process of writing the specification. > >> > >> SRD> Are there schedule pressures in 3GPP to get this to RFC state? > >> SRD> If > >> so, it will be faster to just remove this section. > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 20 07:50:06 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E34B412B8FB; Tue, 20 Sep 2016 07:44:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147438269788.29110.11365958556409982905.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 07:44:57 -0700 Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2016 07:50:01 -0700 Cc: Georg Mayer , Gonzalo Camarillo , Joel Jaeggli , Diameter Maintenance and Extensions Discussion List , 3GPP TSG CT WG3 <3GPP_TSG_CT_WG3@LIST.ETSI.ORG>, 3GPP TSG CT WG4 <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Subject: [Dime] New Liaison Statement, "Reply to the LS to IETF for clarification on RFC 4006 for Diameter base protocol" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 14:44:58 -0000 Title: Reply to the LS to IETF for clarification on RFC 4006 for Diameter base protocol Submission Date: 2016-09-20 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1493/ From: "Lionel Morand" To: maryse.gardella@nokia.com Cc: Benoit Claise ,Lionel Morand ,Joel Jaeggli ,Jouni Korhonen ,Diameter Maintenance and Extensions Discussion List ,Gonzalo Camarillo ,Stephen Farrell ,Georg Mayer ,3GPP TSG CT WG4 <3GPP_TSG_CT_WG4@LIST.ETSI.ORG>,3GPP TSG CT WG3 <3GPP_TSG_CT_WG3@LIST.ETSI.ORG> Response Contacts: Jouni Korhonen ,Lionel Morand Technical Contacts: Purpose: In response Referenced liaison: LS to IETF for clarification on RFC 4006 for Diameter Base Protocol (https://datatracker.ietf.org/liaison/1470/) Body: The IETF DIME WG thanks the 3GPP SA5 WG for their LS and query regarding the IETF RFC 4006 (https://datatracker.ietf.org/liaison/1470/). The IETF DIME WG has discussed both options raised in the LS from 3GPP SA5: 1) Is IETF RFC 4006 planned to be updated in order to rely on IETF RFC 6733 as the new Diameter Base protocol? 2) If not, are there any recommendations from IETF on how to address the implicit reference to IETF RFC 3588 as Diameter Base Protocol for 3GPP SA5 Diameter Online charging through use of IETF RFC 4006? and the decision was made to update of the IETF RFC 4006 as per the option 1). The aim of this update is to: - align the Diameter Credit-Control application specification with the IETF RFC 6733, - fix existing known issues in the current specification, - comply with the recommendations given in the IETF RFC 7423 on the design of Diameter application. The time line for the completion of the RFC 4006 update is set to November 2017. As a reminder, the IETF RFC 6733 does not define a new Diameter base protocol but is a new version of the specification defining the Diameter base protocol. The IETF RFC 3588 is obsoleted by the IETF RFC 6733, as defined in the IETF RFC 2223: Obsoleted-by To be used to refer to the newer document(s) that replaces the older document. In the present case, any document using the IETF RFC 3588 as reference for the Diameter base protocol should be updated to refer to the new IETF RFC 6733. Therefore, as a general guideline, the IETF DIME WG recommends 3GPP WGs to follow this recommendation in their specifications when applicable. The same recommendation will apply for the revision of the IETF RFC 4006 when published by the IETF as for any new RFC obsoleting an old RFC. Attachments: No document has been attached From nobody Wed Sep 21 10:57:34 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8277412BC11; Wed, 21 Sep 2016 10:57:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147448064952.14438.5383559803975593841.idtracker@ietfa.amsl.com> Date: Wed, 21 Sep 2016 10:57:29 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 17:57:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Credit-Control Application Authors : Lyle Bertz David Dolson Yuval Lifshitz Harri Hakala Leena Mattila Juha-Pekka Koskinen Marco Stura John Loughney Filename : draft-ietf-dime-rfc4006bis-00.txt Pages : 113 Date : 2016-09-21 Abstract: This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 21 13:29:10 2016 Return-Path: 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 B1DD212BF63 for ; Wed, 21 Sep 2016 13:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9gUk4x-Y4Uyl for ; Wed, 21 Sep 2016 13:29:06 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB0F12BE97 for ; Wed, 21 Sep 2016 13:29:05 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id E422CA0258; Wed, 21 Sep 2016 22:29:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id B8C621A0051; Wed, 21 Sep 2016 22:29:03 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0301.000; Wed, 21 Sep 2016 22:29:03 +0200 From: To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982JsHJ6KECqOEaXB6jDMNvt0KBZVduAgAd+u4CABRrdAIAbLnKAgAACxgCAABclgIAAAu4AgABR9dCAAIRugIAChMwQ Date: Wed, 21 Sep 2016 20:29:02 +0000 Message-ID: <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 20:29:09 -0000 Hi Maria Cruz, "Relative" could also be simply understood as the fact that it is not an ab= solute value but a value defined in comparison of arbitrary values fixing a= finite range ("0-65535"). At least it is how I have interpreted so far. And I thought that the remaining point was on how to calculate to determine= this value. I think that the clarification could be that this value reflects either the= capacity of the reporting node (when processing the request and generating= the answer e.g. server) or its forwarding capacity (when acting as an rela= y/proxy). And the forwarding case obviously depends on the upstream load ca= pacity. And this this what I have tried to summarize in: "The calculated LOAD value MUST indicate the relative capacity of a Diamete= r node to process or forward subsequent request messages. The method for de= termining the total available capacity is outside of the scope of this docu= ment. NOTE: When the reporting node is not a server, the LOAD value reflects not = only the capacity of the reporting node but also the total capacity of the = Diameter nodes to which requests can be forwarded." > -----Message d'origine----- > De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] > Envoy=E9=A0: mardi 20 septembre 2016 09:32 > =C0=A0: MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org > Objet=A0: RE: [Dime] Proposed resolutions of LOAD discussion >=20 > Hello Lionel, >=20 > We need to clarify "relative to what". This is the part we are rephrasing. >=20 > Anyway, I will keep NOTE by Steve: >=20 > Note: The LOAD value should be calculated in a way that reflects the ava= ilable > load independently of the weight of each server. This allows the Diamete= r node > that routes a request, including nodes doing server selection and agents = routing > requests, to accurately compare values from different nodes. Any specifi= c LOAD > value needs to identify the same amount of available capacity, regardles= s the > Diameter node that calculates the value. > The mechanism used to calculate the LOAD value that fulfils this requirem= ent is > an implementation decision. >=20 >=20 > Cheers > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: martes, 20 de septiembre de 2016 0:01 > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > Subject: RE: [Dime] Proposed resolutions of LOAD discussion >=20 > Hi, >=20 > I was wondering if we could simplify in a way that would be understandabl= e for > anyone outside the current discussion. >=20 > Is something missing in the following text? >=20 > "The calculated LOAD value MUST indicate the relative capacity of a Diame= ter > node to process or forward subsequent request messages. The method for > determining the total available capacity is outside of the scope of this > document. >=20 > NOTE: When the reporting node is not a server, the LOAD value reflects no= t only > the capacity of the reporting node but also the total capacity of the Dia= meter > nodes to which requests can be forwarded." >=20 > Lionel >=20 > > -----Message d'origine----- > > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz > > Bartolome Envoy=E9=A0: lundi 19 septembre 2016 20:45 =C0=A0: Steve Dono= van; > > dime@ietf.org Objet=A0: Re: [Dime] Proposed resolutions of LOAD > > discussion > > > > Hello Steve, > > > > See proposal: > > > > "The calculated LOAD value MUST reflect the reporting Diameter node's > > capacity relative to the maximum capacity for a Diameter node in the > > group of nodes the messages are load balanced". > > > > I removed "available" because it may be misinterpreted as "available > > at a moment in time", what is not right, it is just the maximum > > capacity it is offered, it can be reached. > > "for a Diameter node": in order to indicate that it is the maximum > > capacity of "any" of the Diameter nodes, what a Diameter node is normal= ly > offering. > > But we can limit that to the group of nodes that are receivers of messa= ges, i.e. > > the load-balancing group. > > > > Does it make sense to you? > > Thanks Steve > > > > -----Original Message----- > > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > Sent: lunes, 19 de septiembre de 2016 20:35 > > To: Maria Cruz Bartolome; dime@ietf.org > > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > > > Actually, looking at it again, I think the following wording is needed: > > > > "The calculated LOAD value MUST reflect the reporting Diameter node's > > capacity relative to the maximum available capacity for the set of > > Diameter nodes that are potential receiving nodes for the future > > messages covered by the LOAD report." > > > > We probably need some words on what the set of Diameter nodes > > comprises, as it is different for HOST reports and PEER reports. > > > > Does this work? > > > > Steve > > > > On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > > > Hello Steve, > > > > > > Thanks for the clarification > > > I still think the last part of the sentence is misleading: "... > > > relative to the > > maximum available capacity for the reporting Diameter node ". > > > > > > It should be "... relative to the maximum available capacity for a > > > reporting > > Diameter node". > > > > > > The reasoning is that it should be relative to the maximum capacity > > > not of that > > particular reporting node, but any of the nodes. That is, if we use > > SRV to provide the load value, the maximum load is 65535, but a > > particular node may just have a maximum capacity of e.g. 4000. Then > > the load value of this reporting node should be relative not to 4000 > > but to 65535, and it should be done the same for all nodes, in a way th= at the > load is then comparable by the reacting node. > > > Is my point clearer now? > > > The NOTE you wrote clarified that point in fact. > > > > > > Best regards > > > /MCruz > > > > > > -----Original Message----- > > > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > > Sent: lunes, 19 de septiembre de 2016 19:02 > > > To: Maria Cruz Bartolome; dime@ietf.org > > > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > > > > > Maria Cruz, > > > > > > I think we are saying the same thing. My original has an > > > unfortunate typo and > > should have read as follows: > > > > > > "The calculated LOAD value MUST reflect the sending Diameter node's > > capacity relative to the maximum available capacity for the sending > > Diameter node." > > > > > > In thinking about this, the word sending might also not be clear > > > enough. We > > might want to use the reporting node instead. This would change it to > > the > > following: > > > > > > "The calculated LOAD value MUST reflect the reporting Diameter > > > node's > > capacity relative to the maximum available capacity for the reporting > > Diameter node." > > > > > > Regards, > > > > > > Steve > > > > > > On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > > >> Hello Steve, > > >> > > >> Thanks for the proposal. > > >> I still think the text is a bit misleading: > > >> > > >> "The calculated LOAD value MUST reflect the sending Diameter nodes > > >> capacity relative to the maximum available capacity for the sending > > >> Diameter node." > > >> > > >> I think it should be: > > >> "The calculated LOAD value MUST reflect the sending Diameter node > > >> capacity relative to the maximum available capacity for a sending > > >> Diameter node." > > >> > > >> Reasoning: a node may have a very limited maximum capacity, but the > > >> key > > point is precisely to provide a LOAD value relative to the maximum > > value A node may have. > > >> > > >> I hope this clarifies > > >> Thanks > > >> /MCruz > > >> > > >> -----Original Message----- > > >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > >> Sent: martes, 30 de agosto de 2016 5:59 > > >> To: Maria Cruz Bartolome; dime@ietf.org > > >> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > >> > > >> Maria Cruz, > > >> > > >> Thanks for your comments. See my replies inline. > > >> > > >> Regards, > > >> > > >> Steve > > >> > > >> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > > >>> Hello Steve, > > >>> > > >>> Thanks for the proposals, see below Best regards /MCruz > > >>> > > >>> -----Original Message----- > > >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve > > >>> Donovan > > >>> Sent: martes, 16 de agosto de 2016 16:50 > > >>> To: dime@ietf.org > > >>> Subject: [Dime] Proposed resolutions of LOAD discussion > > >>> > > >>> All, > > >>> > > >>> I have outlined proposed solutions for the issues raised in the > > >>> discussion > > around the Diameter Load draft. > > >>> > > >>> Please let me know if I've missed anything from the discussion. > > >>> > > >>> Regards, > > >>> > > >>> Steve > > >>> > > >>> Primary Issues: > > >>> > > >>> 1) Use of DNS SRV weighted value as format for LOAD value. > > >>> > > >>> This was discussed and agreed to early in the process. It has the > > >>> advantage > > that Diameter nodes can use a combination of values received via the > > DNS SRV interface and dynamic values received through the Diameter LOAD > interface. > > While I agree that it isn't as intuitive as a straight percentage > > value, I don't see this as compelling enough of a reason to change a > > decision the working group has already made. > > >>> [MCruz] I still think using SRV values is error prone and > > >>> anti-intuitive, but I > > can live with this if you really think it is not possible to re-evaluat= e this now. > > >> SRD> I haven't seen any argument that using the SRV values doesn't > > >> work. As such, I prefer to not change this at this stage of the pro= cess. > > >>> 2) Need to add wording that the calculated LOAD value needs to be > > >>> based > > on overall available capacity. > > >>> > > >>> I agree with Maria Cruz's comment that we need to add wording > > >>> indicating > > that the calculated LOAD value needs to reflect available capacity. > > To this end, I propose adding the following to section 6.1 (this is > > based on wording proposed by Maria Cruz): > > >>> > > >>> The calculated LOAD value MUST reflect the Diameter nodes capacity > > relative to the total available capacity across the Diameter nodes to > > which requests can be routed. This could be either a set of Diameter > > endpoints or a set of Diameter agents, depending on the type of the > > LOAD report. The method for determining the total available capacity > > is outside of the scope of this document. > > >>> > > >>> Note: The LOAD value should be calculated in a way that > > >>> reflects the > > available load independently of the weight of each > > >>> server. This allows the Diameter node that routes a > > >>> request, including > > nodes doing server selection and agents routing > > >>> requests, to accurately compare values from different > > >>> nodes. Any > > specific LOAD value needs to identify the same > > >>> amount of available capacity, regardless the Diameter node > > >>> that > > calculates the value. > > >>> > > >>> The mechanism used to calculate the LOAD value that fulfills this > > requirement is an implementation decision. > > >>> > > >>> > > >>> [MCruz] Some comments to proposed text: > > >>> " The calculated LOAD value MUST reflect the Diameter nodes > > >>> capacity > > relative to the total available capacity across the Diameter nodes to > > which requests can be routed. ": I think it may be misleading what is > > the "total available capacity across nodes". > > >>> See proposal: > > >>> " The calculated LOAD value MUST reflect each Diameter node > > >>> capacity > > relative to the maximum available capacity for a Diameter node to > > which requests can be routed." > > >> SRD> This wording could imply that the LOAD value carries load > > >> information for multiple Diameter nodes. How about the following: > > >> > > >> "The calculated LOAD value MUST reflect the sending Diameter nodes > > >> capacity relative to the maximum available capacity for the sending > > >> Diameter node." > > >> > > >>> 3) Wording in Appendix A. > > >>> > > >>> Before we reword Appendix A, we need to decide if it is still neede= d. > > >>> It was valuable in helping to generate the solution but I'm not > > >>> convinced it is > > still needed in the document. Is there objection to removing this sect= ion? > > >>> > > >>> [MCruz] I prefer this to remain, it provides some hints that may > > >>> be valuable > > for first time readers. > > >> SRD> I'd like to hear other opinions on this as there is work > > >> SRD> required > > >> to make the section consistent with the mechanism defined. > > >> Implementors will still have access to this information by > > >> reviewing the history of the process of writing the specification. > > >> > > >> SRD> Are there schedule pressures in 3GPP to get this to RFC state? > > >> SRD> If > > >> so, it will be faster to just remove this section. > > >>> _______________________________________________ > > >>> DiME mailing list > > >>> DiME@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________ > ________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 21 15:35:14 2016 Return-Path: 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 EE39B12B6BF for ; Wed, 21 Sep 2016 15:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 RorPWGLZ7E6D for ; Wed, 21 Sep 2016 15:35:03 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 5D1E412C076 for ; Wed, 21 Sep 2016 15:35:02 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:57293 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bmq6R-0006Im-Mj; Wed, 21 Sep 2016 15:35:01 -0700 To: lionel.morand@orange.com, Maria Cruz Bartolome , "dime@ietf.org" References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <1f007c4e-fb10-a065-2f7a-013a4dfc49d4@usdonovans.com> Date: Wed, 21 Sep 2016 17:34:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 22:35:06 -0000 Lionel, I'm not okay with the note. It should also just be the capacity of the agent in that specific case. Regards, Steve On 9/21/16 3:29 PM, lionel.morand@orange.com wrote: > Hi Maria Cruz, > > "Relative" could also be simply understood as the fact that it is not an absolute value but a value defined in comparison of arbitrary values fixing a finite range ("0-65535"). At least it is how I have interpreted so far. > > And I thought that the remaining point was on how to calculate to determine this value. > I think that the clarification could be that this value reflects either the capacity of the reporting node (when processing the request and generating the answer e.g. server) or its forwarding capacity (when acting as an relay/proxy). And the forwarding case obviously depends on the upstream load capacity. > > And this this what I have tried to summarize in: > > "The calculated LOAD value MUST indicate the relative capacity of a Diameter node to process or forward subsequent request messages. The method for determining the total available capacity is outside of the scope of this document. > > NOTE: When the reporting node is not a server, the LOAD value reflects not only the capacity of the reporting node but also the total capacity of the Diameter nodes to which requests can be forwarded." > >> -----Message d'origine----- >> De : Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] >> Envoyé : mardi 20 septembre 2016 09:32 >> À : MORAND Lionel IMT/OLN; Steve Donovan; dime@ietf.org >> Objet : RE: [Dime] Proposed resolutions of LOAD discussion >> >> Hello Lionel, >> >> We need to clarify "relative to what". This is the part we are rephrasing. >> >> Anyway, I will keep NOTE by Steve: >> >> Note: The LOAD value should be calculated in a way that reflects the available >> load independently of the weight of each server. This allows the Diameter node >> that routes a request, including nodes doing server selection and agents routing >> requests, to accurately compare values from different nodes. Any specific LOAD >> value needs to identify the same amount of available capacity, regardless the >> Diameter node that calculates the value. >> The mechanism used to calculate the LOAD value that fulfils this requirement is >> an implementation decision. >> >> >> Cheers >> /MCruz >> >> -----Original Message----- >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: martes, 20 de septiembre de 2016 0:01 >> To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org >> Subject: RE: [Dime] Proposed resolutions of LOAD discussion >> >> Hi, >> >> I was wondering if we could simplify in a way that would be understandable for >> anyone outside the current discussion. >> >> Is something missing in the following text? >> >> "The calculated LOAD value MUST indicate the relative capacity of a Diameter >> node to process or forward subsequent request messages. The method for >> determining the total available capacity is outside of the scope of this >> document. >> >> NOTE: When the reporting node is not a server, the LOAD value reflects not only >> the capacity of the reporting node but also the total capacity of the Diameter >> nodes to which requests can be forwarded." >> >> Lionel >> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz >>> Bartolome Envoyé : lundi 19 septembre 2016 20:45 À : Steve Donovan; >>> dime@ietf.org Objet : Re: [Dime] Proposed resolutions of LOAD >>> discussion >>> >>> Hello Steve, >>> >>> See proposal: >>> >>> "The calculated LOAD value MUST reflect the reporting Diameter node's >>> capacity relative to the maximum capacity for a Diameter node in the >>> group of nodes the messages are load balanced". >>> >>> I removed "available" because it may be misinterpreted as "available >>> at a moment in time", what is not right, it is just the maximum >>> capacity it is offered, it can be reached. >>> "for a Diameter node": in order to indicate that it is the maximum >>> capacity of "any" of the Diameter nodes, what a Diameter node is normally >> offering. >>> But we can limit that to the group of nodes that are receivers of messages, i.e. >>> the load-balancing group. >>> >>> Does it make sense to you? >>> Thanks Steve >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: lunes, 19 de septiembre de 2016 20:35 >>> To: Maria Cruz Bartolome; dime@ietf.org >>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >>> >>> Actually, looking at it again, I think the following wording is needed: >>> >>> "The calculated LOAD value MUST reflect the reporting Diameter node's >>> capacity relative to the maximum available capacity for the set of >>> Diameter nodes that are potential receiving nodes for the future >>> messages covered by the LOAD report." >>> >>> We probably need some words on what the set of Diameter nodes >>> comprises, as it is different for HOST reports and PEER reports. >>> >>> Does this work? >>> >>> Steve >>> >>> On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: >>>> Hello Steve, >>>> >>>> Thanks for the clarification >>>> I still think the last part of the sentence is misleading: "... >>>> relative to the >>> maximum available capacity for the reporting Diameter node ". >>>> It should be "... relative to the maximum available capacity for a >>>> reporting >>> Diameter node". >>>> The reasoning is that it should be relative to the maximum capacity >>>> not of that >>> particular reporting node, but any of the nodes. That is, if we use >>> SRV to provide the load value, the maximum load is 65535, but a >>> particular node may just have a maximum capacity of e.g. 4000. Then >>> the load value of this reporting node should be relative not to 4000 >>> but to 65535, and it should be done the same for all nodes, in a way that the >> load is then comparable by the reacting node. >>>> Is my point clearer now? >>>> The NOTE you wrote clarified that point in fact. >>>> >>>> Best regards >>>> /MCruz >>>> >>>> -----Original Message----- >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: lunes, 19 de septiembre de 2016 19:02 >>>> To: Maria Cruz Bartolome; dime@ietf.org >>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >>>> >>>> Maria Cruz, >>>> >>>> I think we are saying the same thing. My original has an >>>> unfortunate typo and >>> should have read as follows: >>>> "The calculated LOAD value MUST reflect the sending Diameter node's >>> capacity relative to the maximum available capacity for the sending >>> Diameter node." >>>> In thinking about this, the word sending might also not be clear >>>> enough. We >>> might want to use the reporting node instead. This would change it to >>> the >>> following: >>>> "The calculated LOAD value MUST reflect the reporting Diameter >>>> node's >>> capacity relative to the maximum available capacity for the reporting >>> Diameter node." >>>> Regards, >>>> >>>> Steve >>>> >>>> On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: >>>>> Hello Steve, >>>>> >>>>> Thanks for the proposal. >>>>> I still think the text is a bit misleading: >>>>> >>>>> "The calculated LOAD value MUST reflect the sending Diameter nodes >>>>> capacity relative to the maximum available capacity for the sending >>>>> Diameter node." >>>>> >>>>> I think it should be: >>>>> "The calculated LOAD value MUST reflect the sending Diameter node >>>>> capacity relative to the maximum available capacity for a sending >>>>> Diameter node." >>>>> >>>>> Reasoning: a node may have a very limited maximum capacity, but the >>>>> key >>> point is precisely to provide a LOAD value relative to the maximum >>> value A node may have. >>>>> I hope this clarifies >>>>> Thanks >>>>> /MCruz >>>>> >>>>> -----Original Message----- >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: martes, 30 de agosto de 2016 5:59 >>>>> To: Maria Cruz Bartolome; dime@ietf.org >>>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >>>>> >>>>> Maria Cruz, >>>>> >>>>> Thanks for your comments. See my replies inline. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: >>>>>> Hello Steve, >>>>>> >>>>>> Thanks for the proposals, see below Best regards /MCruz >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>> Donovan >>>>>> Sent: martes, 16 de agosto de 2016 16:50 >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] Proposed resolutions of LOAD discussion >>>>>> >>>>>> All, >>>>>> >>>>>> I have outlined proposed solutions for the issues raised in the >>>>>> discussion >>> around the Diameter Load draft. >>>>>> Please let me know if I've missed anything from the discussion. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> Primary Issues: >>>>>> >>>>>> 1) Use of DNS SRV weighted value as format for LOAD value. >>>>>> >>>>>> This was discussed and agreed to early in the process. It has the >>>>>> advantage >>> that Diameter nodes can use a combination of values received via the >>> DNS SRV interface and dynamic values received through the Diameter LOAD >> interface. >>> While I agree that it isn't as intuitive as a straight percentage >>> value, I don't see this as compelling enough of a reason to change a >>> decision the working group has already made. >>>>>> [MCruz] I still think using SRV values is error prone and >>>>>> anti-intuitive, but I >>> can live with this if you really think it is not possible to re-evaluate this now. >>>>> SRD> I haven't seen any argument that using the SRV values doesn't >>>>> work. As such, I prefer to not change this at this stage of the process. >>>>>> 2) Need to add wording that the calculated LOAD value needs to be >>>>>> based >>> on overall available capacity. >>>>>> I agree with Maria Cruz's comment that we need to add wording >>>>>> indicating >>> that the calculated LOAD value needs to reflect available capacity. >>> To this end, I propose adding the following to section 6.1 (this is >>> based on wording proposed by Maria Cruz): >>>>>> The calculated LOAD value MUST reflect the Diameter nodes capacity >>> relative to the total available capacity across the Diameter nodes to >>> which requests can be routed. This could be either a set of Diameter >>> endpoints or a set of Diameter agents, depending on the type of the >>> LOAD report. The method for determining the total available capacity >>> is outside of the scope of this document. >>>>>> Note: The LOAD value should be calculated in a way that >>>>>> reflects the >>> available load independently of the weight of each >>>>>> server. This allows the Diameter node that routes a >>>>>> request, including >>> nodes doing server selection and agents routing >>>>>> requests, to accurately compare values from different >>>>>> nodes. Any >>> specific LOAD value needs to identify the same >>>>>> amount of available capacity, regardless the Diameter node >>>>>> that >>> calculates the value. >>>>>> The mechanism used to calculate the LOAD value that fulfills this >>> requirement is an implementation decision. >>>>>> >>>>>> [MCruz] Some comments to proposed text: >>>>>> " The calculated LOAD value MUST reflect the Diameter nodes >>>>>> capacity >>> relative to the total available capacity across the Diameter nodes to >>> which requests can be routed. ": I think it may be misleading what is >>> the "total available capacity across nodes". >>>>>> See proposal: >>>>>> " The calculated LOAD value MUST reflect each Diameter node >>>>>> capacity >>> relative to the maximum available capacity for a Diameter node to >>> which requests can be routed." >>>>> SRD> This wording could imply that the LOAD value carries load >>>>> information for multiple Diameter nodes. How about the following: >>>>> >>>>> "The calculated LOAD value MUST reflect the sending Diameter nodes >>>>> capacity relative to the maximum available capacity for the sending >>>>> Diameter node." >>>>> >>>>>> 3) Wording in Appendix A. >>>>>> >>>>>> Before we reword Appendix A, we need to decide if it is still needed. >>>>>> It was valuable in helping to generate the solution but I'm not >>>>>> convinced it is >>> still needed in the document. Is there objection to removing this section? >>>>>> [MCruz] I prefer this to remain, it provides some hints that may >>>>>> be valuable >>> for first time readers. >>>>> SRD> I'd like to hear other opinions on this as there is work >>>>> SRD> required >>>>> to make the section consistent with the mechanism defined. >>>>> Implementors will still have access to this information by >>>>> reviewing the history of the process of writing the specification. >>>>> >>>>> SRD> Are there schedule pressures in 3GPP to get this to RFC state? >>>>> SRD> If >>>>> so, it will be faster to just remove this section. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _________________________________________________________________ >> ________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou >> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le >> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, Orange decline toute >> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; they should not be distributed, used >> or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this >> message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Thu Sep 22 08:14:22 2016 Return-Path: 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 615BA12DA4B for ; Thu, 22 Sep 2016 02:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 OYkT2NJ5JraW for ; Thu, 22 Sep 2016 02:01:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB9812DA9B for ; Thu, 22 Sep 2016 02:01:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 502D3B81064; Thu, 22 Sep 2016 02:01:55 -0700 (PDT) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160922090155.502D3B81064@rfc-editor.org> Date: Thu, 22 Sep 2016 02:01:55 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 22 Sep 2016 08:14:21 -0700 Cc: zbigniew.rapnicki@computaris.com, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Technical Errata Reported] RFC6733 (4808) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 09:01:59 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4808 -------------------------------------- Type: Technical Reported by: Zbigniew Rapnicki Section: 1.1.3 Original Text ------------- This document obsoletes RFC 3588 but is fully backward compatible with that document. Corrected Text -------------- This document obsoletes RFC 3588. Notes ----- When comparing the BNF for the answer messages CEA, DPA, DWA, RAA, STA and ASA it can be seen that FAILED-AVP avp is no longer marked with the * which means it can be present only once in the diameter message. Previous specification (rfc3588) defines multiple FAILED-AVP avp usage in a single diameter message. Similar case is for Vendor-Specific-Application-Id AVP definition. Previous specification allows multiple usage of Vendor-Id avp in a single message while the new specification defines it as a single mandatory AVP: rfc3588: ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } rfc6733: ::= < AVP Header: 260 > { Vendor-Id } [ Auth-Application-Id ] [ Acct-Application-Id ] How this facts applies to the sentence about fully backward compatibility in the section 1.1.3? Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Sep 23 05:33:04 2016 Return-Path: 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 354CE12B5FD for ; Fri, 23 Sep 2016 05:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7tQldy6TxDFC for ; Fri, 23 Sep 2016 05:32:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4B5D912B0C8 for ; Fri, 23 Sep 2016 05:32:59 -0700 (PDT) X-AuditID: c1b4fb30-f60a598000000cb2-6f-57e520f9b151 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 73.BC.03250.9F025E75; Fri, 23 Sep 2016 14:32:57 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.167]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Fri, 23 Sep 2016 14:32:56 +0200 From: Maria Cruz Bartolome To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgIAbDa6AgAAihBD///dngIAAIdpggAAXyQCAAMB+8IACSoEAgAK/cYA= Date: Fri, 23 Sep 2016 12:32:54 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921A4CD4D5@ESESSMB101.ericsson.se> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7ge5PhafhBlf/ylvM7V3BZnF7e6bF hiYeB2aPJUt+Mnm0PDvJ5rHqbR9rAHMUl01Kak5mWWqRvl0CV8bW1ttMBR+7GSsWPlzJ0sDY kd/FyMkhIWAiseFJL1MXIxeHkMB6RokHi7exQDhLGCW6V35gAaliE7CTuHT6BViViEAbUGLS fLCEsIC1xPa9u5lBbBEBG4kPPzYwQdhlEvMX7AKrYRFQlTjbtRGshlfAV+L/6ufMEBv2sEk8 O7OWDcThFOhilFjefJwVpIpRQEzi+6k1YJOYBcQlbj2ZzwRxrIDEkj3nmSFsUYmXj/+xQthK Eiu2X2KEqNeTuDF1ChuErS2xbOFrqM2CEidnPmGZwCgyC8nYWUhaZiFpmYWkZQEjyypG0eLU 4qTcdCMjvdSizOTi4vw8vbzUkk2MwEg5uOW3wQ7Gl88dDzEKcDAq8fA+ePw4XIg1say4MvcQ owQHs5IIL4/U03Ah3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4 OKUaGPlKb3yN26O9OFj9wkKX5P0yt4O4GVo4fh5Pm5DUMCFbMzFb/2WrfQPP7IX/anVdp12a unjvob98NoVSmwtOmv8REgp+Lrw90mFpSXnz1ZflCcWXt9q61PgvK/qT/f19YonQzbXmBwSu XDGKOFC2bwpfquOO3jkTPjNNrO0NftBQaxXab3DxmxJLcUaioRZzUXEiAAV5WzKQAgAA Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 12:33:03 -0000 Hello all, The importance of the "relative" value is not only to provide a value in a = range from 0-65535, but that this value is coordinated with the different n= odes among which the request could be load-balanced. The 0-65535 could identify a capacity value for a single Diameter node, but= if it does not take into account rest of nodes it will be useless. As we explained, for an small node, its maximum of capacity (i.e. 65535) co= uld mean a very little capacity compared to a "big" server, even when that = server indicates an e.g. low capacity value (e.g. 1000).=20 Then, it is key to explain that, and it was what we agreed to include in th= e doc. Then, my proposal would be the following: "The calculated LOAD value MUST reflect the reporting Diameter=20 node's capacity relative to the maximum capacity of a Diameter node=20 in the group of nodes the messages are load balanced. Note: The LOAD value should be calculated in a way that reflects the =20 available load independently of the weight of each server. This=20 allows the Diameter node that routes a request, including nodes doing=20 server selection and agents routing requests, to accurately compare=20 values from different nodes. Any specific LOAD value needs to=20 identify the same amount of available capacity, regardless the Diameter no= de that calculates the value. The mechanism used to calculate the LOAD value that fulfils this requireme= nt is an implementation decision." I hope this could get agreeable. Best regards /MCruz -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: mi=E9rcoles, 21 de septiembre de 2016 22:29 To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org Subject: RE: [Dime] Proposed resolutions of LOAD discussion Hi Maria Cruz, "Relative" could also be simply understood as the fact that it is not an ab= solute value but a value defined in comparison of arbitrary values fixing a= finite range ("0-65535"). At least it is how I have interpreted so far. And I thought that the remaining point was on how to calculate to determine= this value. I think that the clarification could be that this value reflects either the= capacity of the reporting node (when processing the request and generating= the answer e.g. server) or its forwarding capacity (when acting as an rela= y/proxy). And the forwarding case obviously depends on the upstream load ca= pacity. And this this what I have tried to summarize in: "The calculated LOAD value MUST indicate the relative capacity of a Diamete= r node to process or forward subsequent request messages. The method for de= termining the total available capacity is outside of the scope of this docu= ment. NOTE: When the reporting node is not a server, the LOAD value reflects not = only the capacity of the reporting node but also the total capacity of the = Diameter nodes to which requests can be forwarded." > -----Message d'origine----- > De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] > Envoy=E9=A0: mardi 20 septembre 2016 09:32 =C0=A0: MORAND Lionel IMT/OLN;= =20 > Steve Donovan; dime@ietf.org Objet=A0: RE: [Dime] Proposed resolutions=20 > of LOAD discussion >=20 > Hello Lionel, >=20 > We need to clarify "relative to what". This is the part we are rephrasing= . >=20 > Anyway, I will keep NOTE by Steve: >=20 > Note: The LOAD value should be calculated in a way that reflects the =20 > available load independently of the weight of each server. This=20 > allows the Diameter node that routes a request, including nodes doing=20 > server selection and agents routing requests, to accurately compare=20 > values from different nodes. Any specific LOAD value needs to=20 > identify the same amount of available capacity, regardless the Diameter = node that calculates the value. > The mechanism used to calculate the LOAD value that fulfils this=20 > requirement is an implementation decision. >=20 >=20 > Cheers > /MCruz >=20 > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: martes, 20 de septiembre de 2016 0:01 > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > Subject: RE: [Dime] Proposed resolutions of LOAD discussion >=20 > Hi, >=20 > I was wondering if we could simplify in a way that would be=20 > understandable for anyone outside the current discussion. >=20 > Is something missing in the following text? >=20 > "The calculated LOAD value MUST indicate the relative capacity of a=20 > Diameter node to process or forward subsequent request messages. The=20 > method for determining the total available capacity is outside of the=20 > scope of this document. >=20 > NOTE: When the reporting node is not a server, the LOAD value reflects=20 > not only the capacity of the reporting node but also the total=20 > capacity of the Diameter nodes to which requests can be forwarded." >=20 > Lionel >=20 > > -----Message d'origine----- > > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20 > > Bartolome Envoy=E9=A0: lundi 19 septembre 2016 20:45 =C0=A0: Steve Dono= van;=20 > > dime@ietf.org Objet=A0: Re: [Dime] Proposed resolutions of LOAD=20 > > discussion > > > > Hello Steve, > > > > See proposal: > > > > "The calculated LOAD value MUST reflect the reporting Diameter=20 > > node's capacity relative to the maximum capacity for a Diameter node=20 > > in the group of nodes the messages are load balanced". > > > > I removed "available" because it may be misinterpreted as "available=20 > > at a moment in time", what is not right, it is just the maximum=20 > > capacity it is offered, it can be reached. > > "for a Diameter node": in order to indicate that it is the maximum=20 > > capacity of "any" of the Diameter nodes, what a Diameter node is=20 > > normally > offering. > > But we can limit that to the group of nodes that are receivers of messa= ges, i.e. > > the load-balancing group. > > > > Does it make sense to you? > > Thanks Steve > > > > -----Original Message----- > > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > Sent: lunes, 19 de septiembre de 2016 20:35 > > To: Maria Cruz Bartolome; dime@ietf.org > > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > > > Actually, looking at it again, I think the following wording is needed: > > > > "The calculated LOAD value MUST reflect the reporting Diameter=20 > > node's capacity relative to the maximum available capacity for the=20 > > set of Diameter nodes that are potential receiving nodes for the=20 > > future messages covered by the LOAD report." > > > > We probably need some words on what the set of Diameter nodes=20 > > comprises, as it is different for HOST reports and PEER reports. > > > > Does this work? > > > > Steve > > > > On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > > > Hello Steve, > > > > > > Thanks for the clarification > > > I still think the last part of the sentence is misleading: "... > > > relative to the > > maximum available capacity for the reporting Diameter node ". > > > > > > It should be "... relative to the maximum available capacity for a=20 > > > reporting > > Diameter node". > > > > > > The reasoning is that it should be relative to the maximum=20 > > > capacity not of that > > particular reporting node, but any of the nodes. That is, if we use=20 > > SRV to provide the load value, the maximum load is 65535, but a=20 > > particular node may just have a maximum capacity of e.g. 4000. Then=20 > > the load value of this reporting node should be relative not to 4000=20 > > but to 65535, and it should be done the same for all nodes, in a way=20 > > that the > load is then comparable by the reacting node. > > > Is my point clearer now? > > > The NOTE you wrote clarified that point in fact. > > > > > > Best regards > > > /MCruz > > > > > > -----Original Message----- > > > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > > Sent: lunes, 19 de septiembre de 2016 19:02 > > > To: Maria Cruz Bartolome; dime@ietf.org > > > Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > > > > > Maria Cruz, > > > > > > I think we are saying the same thing. My original has an=20 > > > unfortunate typo and > > should have read as follows: > > > > > > "The calculated LOAD value MUST reflect the sending Diameter=20 > > > node's > > capacity relative to the maximum available capacity for the sending=20 > > Diameter node." > > > > > > In thinking about this, the word sending might also not be clear=20 > > > enough. We > > might want to use the reporting node instead. This would change it=20 > > to the > > following: > > > > > > "The calculated LOAD value MUST reflect the reporting Diameter=20 > > > node's > > capacity relative to the maximum available capacity for the=20 > > reporting Diameter node." > > > > > > Regards, > > > > > > Steve > > > > > > On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > > >> Hello Steve, > > >> > > >> Thanks for the proposal. > > >> I still think the text is a bit misleading: > > >> > > >> "The calculated LOAD value MUST reflect the sending Diameter=20 > > >> nodes capacity relative to the maximum available capacity for the=20 > > >> sending Diameter node." > > >> > > >> I think it should be: > > >> "The calculated LOAD value MUST reflect the sending Diameter node=20 > > >> capacity relative to the maximum available capacity for a sending=20 > > >> Diameter node." > > >> > > >> Reasoning: a node may have a very limited maximum capacity, but=20 > > >> the key > > point is precisely to provide a LOAD value relative to the maximum=20 > > value A node may have. > > >> > > >> I hope this clarifies > > >> Thanks > > >> /MCruz > > >> > > >> -----Original Message----- > > >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > > >> Sent: martes, 30 de agosto de 2016 5:59 > > >> To: Maria Cruz Bartolome; dime@ietf.org > > >> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > > >> > > >> Maria Cruz, > > >> > > >> Thanks for your comments. See my replies inline. > > >> > > >> Regards, > > >> > > >> Steve > > >> > > >> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > > >>> Hello Steve, > > >>> > > >>> Thanks for the proposals, see below Best regards /MCruz > > >>> > > >>> -----Original Message----- > > >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 > > >>> Donovan > > >>> Sent: martes, 16 de agosto de 2016 16:50 > > >>> To: dime@ietf.org > > >>> Subject: [Dime] Proposed resolutions of LOAD discussion > > >>> > > >>> All, > > >>> > > >>> I have outlined proposed solutions for the issues raised in the=20 > > >>> discussion > > around the Diameter Load draft. > > >>> > > >>> Please let me know if I've missed anything from the discussion. > > >>> > > >>> Regards, > > >>> > > >>> Steve > > >>> > > >>> Primary Issues: > > >>> > > >>> 1) Use of DNS SRV weighted value as format for LOAD value. > > >>> > > >>> This was discussed and agreed to early in the process. It has=20 > > >>> the advantage > > that Diameter nodes can use a combination of values received via the=20 > > DNS SRV interface and dynamic values received through the Diameter=20 > > LOAD > interface. > > While I agree that it isn't as intuitive as a straight percentage=20 > > value, I don't see this as compelling enough of a reason to change a=20 > > decision the working group has already made. > > >>> [MCruz] I still think using SRV values is error prone and=20 > > >>> anti-intuitive, but I > > can live with this if you really think it is not possible to re-evaluat= e this now. > > >> SRD> I haven't seen any argument that using the SRV values=20 > > >> SRD> doesn't > > >> work. As such, I prefer to not change this at this stage of the pro= cess. > > >>> 2) Need to add wording that the calculated LOAD value needs to=20 > > >>> be based > > on overall available capacity. > > >>> > > >>> I agree with Maria Cruz's comment that we need to add wording=20 > > >>> indicating > > that the calculated LOAD value needs to reflect available capacity. > > To this end, I propose adding the following to section 6.1 (this is=20 > > based on wording proposed by Maria Cruz): > > >>> > > >>> The calculated LOAD value MUST reflect the Diameter nodes=20 > > >>> capacity > > relative to the total available capacity across the Diameter nodes=20 > > to which requests can be routed. This could be either a set of=20 > > Diameter endpoints or a set of Diameter agents, depending on the=20 > > type of the LOAD report. The method for determining the total=20 > > available capacity is outside of the scope of this document. > > >>> > > >>> Note: The LOAD value should be calculated in a way that=20 > > >>> reflects the > > available load independently of the weight of each > > >>> server. This allows the Diameter node that routes a=20 > > >>> request, including > > nodes doing server selection and agents routing > > >>> requests, to accurately compare values from different=20 > > >>> nodes. Any > > specific LOAD value needs to identify the same > > >>> amount of available capacity, regardless the Diameter=20 > > >>> node that > > calculates the value. > > >>> > > >>> The mechanism used to calculate the LOAD value that fulfills=20 > > >>> this > > requirement is an implementation decision. > > >>> > > >>> > > >>> [MCruz] Some comments to proposed text: > > >>> " The calculated LOAD value MUST reflect the Diameter nodes=20 > > >>> capacity > > relative to the total available capacity across the Diameter nodes=20 > > to which requests can be routed. ": I think it may be misleading=20 > > what is the "total available capacity across nodes". > > >>> See proposal: > > >>> " The calculated LOAD value MUST reflect each Diameter node=20 > > >>> capacity > > relative to the maximum available capacity for a Diameter node to=20 > > which requests can be routed." > > >> SRD> This wording could imply that the LOAD value carries load > > >> information for multiple Diameter nodes. How about the following: > > >> > > >> "The calculated LOAD value MUST reflect the sending Diameter=20 > > >> nodes capacity relative to the maximum available capacity for the=20 > > >> sending Diameter node." > > >> > > >>> 3) Wording in Appendix A. > > >>> > > >>> Before we reword Appendix A, we need to decide if it is still neede= d. > > >>> It was valuable in helping to generate the solution but I'm not=20 > > >>> convinced it is > > still needed in the document. Is there objection to removing this sect= ion? > > >>> > > >>> [MCruz] I prefer this to remain, it provides some hints that may=20 > > >>> be valuable > > for first time readers. > > >> SRD> I'd like to hear other opinions on this as there is work=20 > > >> SRD> required > > >> to make the section consistent with the mechanism defined. > > >> Implementors will still have access to this information by=20 > > >> reviewing the history of the process of writing the specification. > > >> > > >> SRD> Are there schedule pressures in 3GPP to get this to RFC state? > > >> SRD> If > > >> so, it will be faster to just remove this section. > > >>> _______________________________________________ > > >>> DiME mailing list > > >>> DiME@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________ > ________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Sep 23 07:39:16 2016 Return-Path: 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 9C2E012B448 for ; Fri, 23 Sep 2016 07:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 8XfnaaV2L11w for ; Fri, 23 Sep 2016 07:39:13 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 26B7612B3BA for ; Fri, 23 Sep 2016 07:39:13 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:53979 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bnRd6-003NjH-1w; Fri, 23 Sep 2016 07:39:12 -0700 To: Maria Cruz Bartolome , "lionel.morand@orange.com" , "dime@ietf.org" References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4CD4D5@ESESSMB101.ericsson.se> From: Steve Donovan Message-ID: <3d8ec922-5d31-45b4-2ed1-4a9ddf6829e5@usdonovans.com> Date: Fri, 23 Sep 2016 09:39:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <087A34937E64E74E848732CFF8354B921A4CD4D5@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 14:39:16 -0000 Maria Cruz, I'm mostly okay with your proposal. My concern is that all nodes in the group of Diameter nodes need to express their load using the maximum capacity of the SAME node in the group. Your wording implies that individual nodes in the group could choose different nodes maximum capacity in its calculations. I also think it works if the maximum total capacity of the group is used. One other option would be to base this on transactions per second rather than capacity. It might be late to consider this, but we could base it on the TPS a node is currently able to handle. The primary issue with this approach is that not all transactions consume the same resources. Assuming we don't want to switch over to TPS, I propose the following modification of Maria Cruz's wording: "The calculated LOAD value MUST reflect the reporting Diameter node's capacity relative to the maximum capacity of a Diameter node in the group of nodes the messages are load balanced. All nodes in the group MUST use the same nodes maximum capacity when calculating it's own LOAD value. Note: The LOAD value should be calculated in a way that reflects the available load independently of the weight of each server. This allows the Diameter node that routes a request, including nodes doing server selection and agents routing requests, to accurately compare values from different nodes. Any specific LOAD value needs to identify the same amount of available capacity, regardless the Diameter node that calculates the value." Regards, Steve On 9/23/16 7:32 AM, Maria Cruz Bartolome wrote: > Hello all, > > The importance of the "relative" value is not only to provide a value in a range from 0-65535, but that this value is coordinated with the different nodes among which the request could be load-balanced. > The 0-65535 could identify a capacity value for a single Diameter node, but if it does not take into account rest of nodes it will be useless. > As we explained, for an small node, its maximum of capacity (i.e. 65535) could mean a very little capacity compared to a "big" server, even when that server indicates an e.g. low capacity value (e.g. 1000). > Then, it is key to explain that, and it was what we agreed to include in the doc. > > Then, my proposal would be the following: > > "The calculated LOAD value MUST reflect the reporting Diameter > node's capacity relative to the maximum capacity of a Diameter node > in the group of nodes the messages are load balanced. > > Note: The LOAD value should be calculated in a way that reflects the > available load independently of the weight of each server. This > allows the Diameter node that routes a request, including nodes doing > server selection and agents routing requests, to accurately compare > values from different nodes. Any specific LOAD value needs to > identify the same amount of available capacity, regardless the Diameter node that calculates the value. > > The mechanism used to calculate the LOAD value that fulfils this requirement is an implementation decision." > > I hope this could get agreeable. > Best regards > /MCruz > > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: miércoles, 21 de septiembre de 2016 22:29 > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > Subject: RE: [Dime] Proposed resolutions of LOAD discussion > > Hi Maria Cruz, > > "Relative" could also be simply understood as the fact that it is not an absolute value but a value defined in comparison of arbitrary values fixing a finite range ("0-65535"). At least it is how I have interpreted so far. > > And I thought that the remaining point was on how to calculate to determine this value. > I think that the clarification could be that this value reflects either the capacity of the reporting node (when processing the request and generating the answer e.g. server) or its forwarding capacity (when acting as an relay/proxy). And the forwarding case obviously depends on the upstream load capacity. > > And this this what I have tried to summarize in: > > "The calculated LOAD value MUST indicate the relative capacity of a Diameter node to process or forward subsequent request messages. The method for determining the total available capacity is outside of the scope of this document. > > NOTE: When the reporting node is not a server, the LOAD value reflects not only the capacity of the reporting node but also the total capacity of the Diameter nodes to which requests can be forwarded." > >> -----Message d'origine----- >> De : Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] >> Envoyé : mardi 20 septembre 2016 09:32 À : MORAND Lionel IMT/OLN; >> Steve Donovan; dime@ietf.org Objet : RE: [Dime] Proposed resolutions >> of LOAD discussion >> >> Hello Lionel, >> >> We need to clarify "relative to what". This is the part we are rephrasing. >> >> Anyway, I will keep NOTE by Steve: >> >> Note: The LOAD value should be calculated in a way that reflects the >> available load independently of the weight of each server. This >> allows the Diameter node that routes a request, including nodes doing >> server selection and agents routing requests, to accurately compare >> values from different nodes. Any specific LOAD value needs to >> identify the same amount of available capacity, regardless the Diameter node that calculates the value. >> The mechanism used to calculate the LOAD value that fulfils this >> requirement is an implementation decision. >> >> >> Cheers >> /MCruz >> >> -----Original Message----- >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >> Sent: martes, 20 de septiembre de 2016 0:01 >> To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org >> Subject: RE: [Dime] Proposed resolutions of LOAD discussion >> >> Hi, >> >> I was wondering if we could simplify in a way that would be >> understandable for anyone outside the current discussion. >> >> Is something missing in the following text? >> >> "The calculated LOAD value MUST indicate the relative capacity of a >> Diameter node to process or forward subsequent request messages. The >> method for determining the total available capacity is outside of the >> scope of this document. >> >> NOTE: When the reporting node is not a server, the LOAD value reflects >> not only the capacity of the reporting node but also the total >> capacity of the Diameter nodes to which requests can be forwarded." >> >> Lionel >> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz >>> Bartolome Envoyé : lundi 19 septembre 2016 20:45 À : Steve Donovan; >>> dime@ietf.org Objet : Re: [Dime] Proposed resolutions of LOAD >>> discussion >>> >>> Hello Steve, >>> >>> See proposal: >>> >>> "The calculated LOAD value MUST reflect the reporting Diameter >>> node's capacity relative to the maximum capacity for a Diameter node >>> in the group of nodes the messages are load balanced". >>> >>> I removed "available" because it may be misinterpreted as "available >>> at a moment in time", what is not right, it is just the maximum >>> capacity it is offered, it can be reached. >>> "for a Diameter node": in order to indicate that it is the maximum >>> capacity of "any" of the Diameter nodes, what a Diameter node is >>> normally >> offering. >>> But we can limit that to the group of nodes that are receivers of messages, i.e. >>> the load-balancing group. >>> >>> Does it make sense to you? >>> Thanks Steve >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: lunes, 19 de septiembre de 2016 20:35 >>> To: Maria Cruz Bartolome; dime@ietf.org >>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >>> >>> Actually, looking at it again, I think the following wording is needed: >>> >>> "The calculated LOAD value MUST reflect the reporting Diameter >>> node's capacity relative to the maximum available capacity for the >>> set of Diameter nodes that are potential receiving nodes for the >>> future messages covered by the LOAD report." >>> >>> We probably need some words on what the set of Diameter nodes >>> comprises, as it is different for HOST reports and PEER reports. >>> >>> Does this work? >>> >>> Steve >>> >>> On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: >>>> Hello Steve, >>>> >>>> Thanks for the clarification >>>> I still think the last part of the sentence is misleading: "... >>>> relative to the >>> maximum available capacity for the reporting Diameter node ". >>>> It should be "... relative to the maximum available capacity for a >>>> reporting >>> Diameter node". >>>> The reasoning is that it should be relative to the maximum >>>> capacity not of that >>> particular reporting node, but any of the nodes. That is, if we use >>> SRV to provide the load value, the maximum load is 65535, but a >>> particular node may just have a maximum capacity of e.g. 4000. Then >>> the load value of this reporting node should be relative not to 4000 >>> but to 65535, and it should be done the same for all nodes, in a way >>> that the >> load is then comparable by the reacting node. >>>> Is my point clearer now? >>>> The NOTE you wrote clarified that point in fact. >>>> >>>> Best regards >>>> /MCruz >>>> >>>> -----Original Message----- >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: lunes, 19 de septiembre de 2016 19:02 >>>> To: Maria Cruz Bartolome; dime@ietf.org >>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >>>> >>>> Maria Cruz, >>>> >>>> I think we are saying the same thing. My original has an >>>> unfortunate typo and >>> should have read as follows: >>>> "The calculated LOAD value MUST reflect the sending Diameter >>>> node's >>> capacity relative to the maximum available capacity for the sending >>> Diameter node." >>>> In thinking about this, the word sending might also not be clear >>>> enough. We >>> might want to use the reporting node instead. This would change it >>> to the >>> following: >>>> "The calculated LOAD value MUST reflect the reporting Diameter >>>> node's >>> capacity relative to the maximum available capacity for the >>> reporting Diameter node." >>>> Regards, >>>> >>>> Steve >>>> >>>> On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: >>>>> Hello Steve, >>>>> >>>>> Thanks for the proposal. >>>>> I still think the text is a bit misleading: >>>>> >>>>> "The calculated LOAD value MUST reflect the sending Diameter >>>>> nodes capacity relative to the maximum available capacity for the >>>>> sending Diameter node." >>>>> >>>>> I think it should be: >>>>> "The calculated LOAD value MUST reflect the sending Diameter node >>>>> capacity relative to the maximum available capacity for a sending >>>>> Diameter node." >>>>> >>>>> Reasoning: a node may have a very limited maximum capacity, but >>>>> the key >>> point is precisely to provide a LOAD value relative to the maximum >>> value A node may have. >>>>> I hope this clarifies >>>>> Thanks >>>>> /MCruz >>>>> >>>>> -----Original Message----- >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: martes, 30 de agosto de 2016 5:59 >>>>> To: Maria Cruz Bartolome; dime@ietf.org >>>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion >>>>> >>>>> Maria Cruz, >>>>> >>>>> Thanks for your comments. See my replies inline. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: >>>>>> Hello Steve, >>>>>> >>>>>> Thanks for the proposals, see below Best regards /MCruz >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve >>>>>> Donovan >>>>>> Sent: martes, 16 de agosto de 2016 16:50 >>>>>> To: dime@ietf.org >>>>>> Subject: [Dime] Proposed resolutions of LOAD discussion >>>>>> >>>>>> All, >>>>>> >>>>>> I have outlined proposed solutions for the issues raised in the >>>>>> discussion >>> around the Diameter Load draft. >>>>>> Please let me know if I've missed anything from the discussion. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> Primary Issues: >>>>>> >>>>>> 1) Use of DNS SRV weighted value as format for LOAD value. >>>>>> >>>>>> This was discussed and agreed to early in the process. It has >>>>>> the advantage >>> that Diameter nodes can use a combination of values received via the >>> DNS SRV interface and dynamic values received through the Diameter >>> LOAD >> interface. >>> While I agree that it isn't as intuitive as a straight percentage >>> value, I don't see this as compelling enough of a reason to change a >>> decision the working group has already made. >>>>>> [MCruz] I still think using SRV values is error prone and >>>>>> anti-intuitive, but I >>> can live with this if you really think it is not possible to re-evaluate this now. >>>>> SRD> I haven't seen any argument that using the SRV values >>>>> SRD> doesn't >>>>> work. As such, I prefer to not change this at this stage of the process. >>>>>> 2) Need to add wording that the calculated LOAD value needs to >>>>>> be based >>> on overall available capacity. >>>>>> I agree with Maria Cruz's comment that we need to add wording >>>>>> indicating >>> that the calculated LOAD value needs to reflect available capacity. >>> To this end, I propose adding the following to section 6.1 (this is >>> based on wording proposed by Maria Cruz): >>>>>> The calculated LOAD value MUST reflect the Diameter nodes >>>>>> capacity >>> relative to the total available capacity across the Diameter nodes >>> to which requests can be routed. This could be either a set of >>> Diameter endpoints or a set of Diameter agents, depending on the >>> type of the LOAD report. The method for determining the total >>> available capacity is outside of the scope of this document. >>>>>> Note: The LOAD value should be calculated in a way that >>>>>> reflects the >>> available load independently of the weight of each >>>>>> server. This allows the Diameter node that routes a >>>>>> request, including >>> nodes doing server selection and agents routing >>>>>> requests, to accurately compare values from different >>>>>> nodes. Any >>> specific LOAD value needs to identify the same >>>>>> amount of available capacity, regardless the Diameter >>>>>> node that >>> calculates the value. >>>>>> The mechanism used to calculate the LOAD value that fulfills >>>>>> this >>> requirement is an implementation decision. >>>>>> >>>>>> [MCruz] Some comments to proposed text: >>>>>> " The calculated LOAD value MUST reflect the Diameter nodes >>>>>> capacity >>> relative to the total available capacity across the Diameter nodes >>> to which requests can be routed. ": I think it may be misleading >>> what is the "total available capacity across nodes". >>>>>> See proposal: >>>>>> " The calculated LOAD value MUST reflect each Diameter node >>>>>> capacity >>> relative to the maximum available capacity for a Diameter node to >>> which requests can be routed." >>>>> SRD> This wording could imply that the LOAD value carries load >>>>> information for multiple Diameter nodes. How about the following: >>>>> >>>>> "The calculated LOAD value MUST reflect the sending Diameter >>>>> nodes capacity relative to the maximum available capacity for the >>>>> sending Diameter node." >>>>> >>>>>> 3) Wording in Appendix A. >>>>>> >>>>>> Before we reword Appendix A, we need to decide if it is still needed. >>>>>> It was valuable in helping to generate the solution but I'm not >>>>>> convinced it is >>> still needed in the document. Is there objection to removing this section? >>>>>> [MCruz] I prefer this to remain, it provides some hints that may >>>>>> be valuable >>> for first time readers. >>>>> SRD> I'd like to hear other opinions on this as there is work >>>>> SRD> required >>>>> to make the section consistent with the mechanism defined. >>>>> Implementors will still have access to this information by >>>>> reviewing the history of the process of writing the specification. >>>>> >>>>> SRD> Are there schedule pressures in 3GPP to get this to RFC state? >>>>> SRD> If >>>>> so, it will be faster to just remove this section. >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _________________________________________________________________ >> ________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not >> be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Fri Sep 23 09:01:54 2016 Return-Path: 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 0553B12B984 for ; Fri, 23 Sep 2016 09:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 agRml4ALOqiY for ; Fri, 23 Sep 2016 09:01:46 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74D512B925 for ; Fri, 23 Sep 2016 09:01:45 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 321754033E; Fri, 23 Sep 2016 18:01:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id EC8F51C0075; Fri, 23 Sep 2016 18:01:43 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0301.000; Fri, 23 Sep 2016 18:01:43 +0200 From: To: Steve Donovan , Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982JsHJ6KECqOEaXB6jDMNvt0KBZVduAgAd+u4CABRrdAIAbLnKAgAACxgCAABclgIAAAu4AgABR9dCAAIRugIAChMwQgAKGJwCAACNDgIAANcvg Date: Fri, 23 Sep 2016 16:01:43 +0000 Message-ID: <8890_1474646504_57E551E8_8890_8904_1_6B7134B31289DC4FAF731D844122B36E01FBF899@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4CD4D5@ESESSMB101.ericsson.se> <3d8ec922-5d31-45b4-2ed1-4a9ddf6829e5@usdonovans.com> In-Reply-To: <3d8ec922-5d31-45b4-2ed1-4a9ddf6829e5@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 16:01:51 -0000 Hi, I have to admit that I'm lost. Maybe not the last time. And I really have some doubts that people reading the proposed text will be= able to understand something. First of all, it is not only about "loadbalance". You may have a single age= nt in front of a single server and the load value reported by the agent nee= ds to reflect the capacity to process incoming requests as well as the agen= t capacity to forward the requests towards the server. And the last one dep= ends on the server capacity. If there is more than one server, the "forward= ing capacity" depends on the whole capacity of the server farm. Is the above summary correct? Is there something missing? Now, I don't understand the following assertion: "all nodes in the group of= Diameter nodes need to express their load using the maximum capacity of th= e SAME node in the group." Could you please clarify? regards, Lionel > -----Message d'origine----- > De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com] > Envoy=E9=A0: vendredi 23 septembre 2016 16:39 > =C0=A0: Maria Cruz Bartolome; MORAND Lionel IMT/OLN; dime@ietf.org > Objet=A0: Re: [Dime] Proposed resolutions of LOAD discussion >=20 > Maria Cruz, >=20 > I'm mostly okay with your proposal. My concern is that all nodes in the = group of > Diameter nodes need to express their load using the maximum capacity of t= he > SAME node in the group. Your wording implies that individual nodes in th= e group > could choose different nodes maximum capacity in its calculations. >=20 > I also think it works if the maximum total capacity of the group is used. >=20 > One other option would be to base this on transactions per second rather = than > capacity. It might be late to consider this, but we could base it on the= TPS a > node is currently able to handle. The primary issue with this approach i= s that not > all transactions consume the same resources. >=20 > Assuming we don't want to switch over to TPS, I propose the following > modification of Maria Cruz's wording: >=20 > "The calculated LOAD value MUST reflect the reporting Diameter node's > capacity relative to the maximum capacity of a Diameter node in the group= of > nodes the messages are load balanced. All nodes in the group MUST use the > same nodes maximum capacity when calculating it's own LOAD value. >=20 > Note: The LOAD value should be calculated in a way that reflects the av= ailable > load independently of the weight of each server. This allows the Diamete= r node > that routes a request, including nodes doing server selection and agents = routing > requests, to accurately compare values from different nodes. Any specifi= c LOAD > value needs to identify the same amount of available capacity, regardles= s the > Diameter node that calculates the value." >=20 >=20 > Regards, >=20 > Steve >=20 > On 9/23/16 7:32 AM, Maria Cruz Bartolome wrote: > > Hello all, > > > > The importance of the "relative" value is not only to provide a value i= n a range > from 0-65535, but that this value is coordinated with the different nodes= among > which the request could be load-balanced. > > The 0-65535 could identify a capacity value for a single Diameter node,= but if it > does not take into account rest of nodes it will be useless. > > As we explained, for an small node, its maximum of capacity (i.e. 65535= ) could > mean a very little capacity compared to a "big" server, even when that se= rver > indicates an e.g. low capacity value (e.g. 1000). > > Then, it is key to explain that, and it was what we agreed to include i= n the doc. > > > > Then, my proposal would be the following: > > > > "The calculated LOAD value MUST reflect the reporting Diameter node's > > capacity relative to the maximum capacity of a Diameter node in the > > group of nodes the messages are load balanced. > > > > Note: The LOAD value should be calculated in a way that reflects the > > available load independently of the weight of each server. This > > allows the Diameter node that routes a request, including nodes doing > > server selection and agents routing requests, to accurately compare > > values from different nodes. Any specific LOAD value needs to > > identify the same amount of available capacity, regardless the Diamete= r node > that calculates the value. > > > > The mechanism used to calculate the LOAD value that fulfils this requi= rement > is an implementation decision." > > > > I hope this could get agreeable. > > Best regards > > /MCruz > > > > -----Original Message----- > > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > > Sent: mi=E9rcoles, 21 de septiembre de 2016 22:29 > > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > > Subject: RE: [Dime] Proposed resolutions of LOAD discussion > > > > Hi Maria Cruz, > > > > "Relative" could also be simply understood as the fact that it is not a= n absolute > value but a value defined in comparison of arbitrary values fixing a fini= te range > ("0-65535"). At least it is how I have interpreted so far. > > > > And I thought that the remaining point was on how to calculate to deter= mine > this value. > > I think that the clarification could be that this value reflects either= the capacity > of the reporting node (when processing the request and generating the ans= wer > e.g. server) or its forwarding capacity (when acting as an relay/proxy). = And the > forwarding case obviously depends on the upstream load capacity. > > > > And this this what I have tried to summarize in: > > > > "The calculated LOAD value MUST indicate the relative capacity of a Dia= meter > node to process or forward subsequent request messages. The method for > determining the total available capacity is outside of the scope of this > document. > > > > NOTE: When the reporting node is not a server, the LOAD value reflects = not > only the capacity of the reporting node but also the total capacity of the > Diameter nodes to which requests can be forwarded." > > > >> -----Message d'origine----- > >> De : Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] > >> Envoy=E9 : mardi 20 septembre 2016 09:32 =C0 : MORAND Lionel IMT/OLN; > >> Steve Donovan; dime@ietf.org Objet : RE: [Dime] Proposed resolutions > >> of LOAD discussion > >> > >> Hello Lionel, > >> > >> We need to clarify "relative to what". This is the part we are rephras= ing. > >> > >> Anyway, I will keep NOTE by Steve: > >> > >> Note: The LOAD value should be calculated in a way that reflects the > >> available load independently of the weight of each server. This > >> allows the Diameter node that routes a request, including nodes doing > >> server selection and agents routing requests, to accurately compare > >> values from different nodes. Any specific LOAD value needs to > >> identify the same amount of available capacity, regardless the Diamet= er > node that calculates the value. > >> The mechanism used to calculate the LOAD value that fulfils this > >> requirement is an implementation decision. > >> > >> > >> Cheers > >> /MCruz > >> > >> -----Original Message----- > >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > >> Sent: martes, 20 de septiembre de 2016 0:01 > >> To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > >> Subject: RE: [Dime] Proposed resolutions of LOAD discussion > >> > >> Hi, > >> > >> I was wondering if we could simplify in a way that would be > >> understandable for anyone outside the current discussion. > >> > >> Is something missing in the following text? > >> > >> "The calculated LOAD value MUST indicate the relative capacity of a > >> Diameter node to process or forward subsequent request messages. The > >> method for determining the total available capacity is outside of the > >> scope of this document. > >> > >> NOTE: When the reporting node is not a server, the LOAD value > >> reflects not only the capacity of the reporting node but also the > >> total capacity of the Diameter nodes to which requests can be forwarde= d." > >> > >> Lionel > >> > >>> -----Message d'origine----- > >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz > >>> Bartolome Envoy=E9 : lundi 19 septembre 2016 20:45 =C0 : Steve Donova= n; > >>> dime@ietf.org Objet : Re: [Dime] Proposed resolutions of LOAD > >>> discussion > >>> > >>> Hello Steve, > >>> > >>> See proposal: > >>> > >>> "The calculated LOAD value MUST reflect the reporting Diameter > >>> node's capacity relative to the maximum capacity for a Diameter node > >>> in the group of nodes the messages are load balanced". > >>> > >>> I removed "available" because it may be misinterpreted as "available > >>> at a moment in time", what is not right, it is just the maximum > >>> capacity it is offered, it can be reached. > >>> "for a Diameter node": in order to indicate that it is the maximum > >>> capacity of "any" of the Diameter nodes, what a Diameter node is > >>> normally > >> offering. > >>> But we can limit that to the group of nodes that are receivers of mes= sages, > i.e. > >>> the load-balancing group. > >>> > >>> Does it make sense to you? > >>> Thanks Steve > >>> > >>> -----Original Message----- > >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >>> Sent: lunes, 19 de septiembre de 2016 20:35 > >>> To: Maria Cruz Bartolome; dime@ietf.org > >>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >>> > >>> Actually, looking at it again, I think the following wording is neede= d: > >>> > >>> "The calculated LOAD value MUST reflect the reporting Diameter > >>> node's capacity relative to the maximum available capacity for the > >>> set of Diameter nodes that are potential receiving nodes for the > >>> future messages covered by the LOAD report." > >>> > >>> We probably need some words on what the set of Diameter nodes > >>> comprises, as it is different for HOST reports and PEER reports. > >>> > >>> Does this work? > >>> > >>> Steve > >>> > >>> On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > >>>> Hello Steve, > >>>> > >>>> Thanks for the clarification > >>>> I still think the last part of the sentence is misleading: "... > >>>> relative to the > >>> maximum available capacity for the reporting Diameter node ". > >>>> It should be "... relative to the maximum available capacity for a > >>>> reporting > >>> Diameter node". > >>>> The reasoning is that it should be relative to the maximum capacity > >>>> not of that > >>> particular reporting node, but any of the nodes. That is, if we use > >>> SRV to provide the load value, the maximum load is 65535, but a > >>> particular node may just have a maximum capacity of e.g. 4000. Then > >>> the load value of this reporting node should be relative not to 4000 > >>> but to 65535, and it should be done the same for all nodes, in a way > >>> that the > >> load is then comparable by the reacting node. > >>>> Is my point clearer now? > >>>> The NOTE you wrote clarified that point in fact. > >>>> > >>>> Best regards > >>>> /MCruz > >>>> > >>>> -----Original Message----- > >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >>>> Sent: lunes, 19 de septiembre de 2016 19:02 > >>>> To: Maria Cruz Bartolome; dime@ietf.org > >>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >>>> > >>>> Maria Cruz, > >>>> > >>>> I think we are saying the same thing. My original has an > >>>> unfortunate typo and > >>> should have read as follows: > >>>> "The calculated LOAD value MUST reflect the sending Diameter node's > >>> capacity relative to the maximum available capacity for the sending > >>> Diameter node." > >>>> In thinking about this, the word sending might also not be clear > >>>> enough. We > >>> might want to use the reporting node instead. This would change it > >>> to the > >>> following: > >>>> "The calculated LOAD value MUST reflect the reporting Diameter > >>>> node's > >>> capacity relative to the maximum available capacity for the > >>> reporting Diameter node." > >>>> Regards, > >>>> > >>>> Steve > >>>> > >>>> On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > >>>>> Hello Steve, > >>>>> > >>>>> Thanks for the proposal. > >>>>> I still think the text is a bit misleading: > >>>>> > >>>>> "The calculated LOAD value MUST reflect the sending Diameter nodes > >>>>> capacity relative to the maximum available capacity for the > >>>>> sending Diameter node." > >>>>> > >>>>> I think it should be: > >>>>> "The calculated LOAD value MUST reflect the sending Diameter node > >>>>> capacity relative to the maximum available capacity for a sending > >>>>> Diameter node." > >>>>> > >>>>> Reasoning: a node may have a very limited maximum capacity, but > >>>>> the key > >>> point is precisely to provide a LOAD value relative to the maximum > >>> value A node may have. > >>>>> I hope this clarifies > >>>>> Thanks > >>>>> /MCruz > >>>>> > >>>>> -----Original Message----- > >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >>>>> Sent: martes, 30 de agosto de 2016 5:59 > >>>>> To: Maria Cruz Bartolome; dime@ietf.org > >>>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >>>>> > >>>>> Maria Cruz, > >>>>> > >>>>> Thanks for your comments. See my replies inline. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Steve > >>>>> > >>>>> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > >>>>>> Hello Steve, > >>>>>> > >>>>>> Thanks for the proposals, see below Best regards /MCruz > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve > >>>>>> Donovan > >>>>>> Sent: martes, 16 de agosto de 2016 16:50 > >>>>>> To: dime@ietf.org > >>>>>> Subject: [Dime] Proposed resolutions of LOAD discussion > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have outlined proposed solutions for the issues raised in the > >>>>>> discussion > >>> around the Diameter Load draft. > >>>>>> Please let me know if I've missed anything from the discussion. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Steve > >>>>>> > >>>>>> Primary Issues: > >>>>>> > >>>>>> 1) Use of DNS SRV weighted value as format for LOAD value. > >>>>>> > >>>>>> This was discussed and agreed to early in the process. It has > >>>>>> the advantage > >>> that Diameter nodes can use a combination of values received via the > >>> DNS SRV interface and dynamic values received through the Diameter > >>> LOAD > >> interface. > >>> While I agree that it isn't as intuitive as a straight percentage > >>> value, I don't see this as compelling enough of a reason to change a > >>> decision the working group has already made. > >>>>>> [MCruz] I still think using SRV values is error prone and > >>>>>> anti-intuitive, but I > >>> can live with this if you really think it is not possible to re-evalu= ate this now. > >>>>> SRD> I haven't seen any argument that using the SRV values doesn't > >>>>> work. As such, I prefer to not change this at this stage of the pr= ocess. > >>>>>> 2) Need to add wording that the calculated LOAD value needs to be > >>>>>> based > >>> on overall available capacity. > >>>>>> I agree with Maria Cruz's comment that we need to add wording > >>>>>> indicating > >>> that the calculated LOAD value needs to reflect available capacity. > >>> To this end, I propose adding the following to section 6.1 (this is > >>> based on wording proposed by Maria Cruz): > >>>>>> The calculated LOAD value MUST reflect the Diameter nodes > >>>>>> capacity > >>> relative to the total available capacity across the Diameter nodes > >>> to which requests can be routed. This could be either a set of > >>> Diameter endpoints or a set of Diameter agents, depending on the > >>> type of the LOAD report. The method for determining the total > >>> available capacity is outside of the scope of this document. > >>>>>> Note: The LOAD value should be calculated in a way that > >>>>>> reflects the > >>> available load independently of the weight of each > >>>>>> server. This allows the Diameter node that routes a > >>>>>> request, including > >>> nodes doing server selection and agents routing > >>>>>> requests, to accurately compare values from different > >>>>>> nodes. Any > >>> specific LOAD value needs to identify the same > >>>>>> amount of available capacity, regardless the Diameter > >>>>>> node that > >>> calculates the value. > >>>>>> The mechanism used to calculate the LOAD value that fulfills this > >>> requirement is an implementation decision. > >>>>>> > >>>>>> [MCruz] Some comments to proposed text: > >>>>>> " The calculated LOAD value MUST reflect the Diameter nodes > >>>>>> capacity > >>> relative to the total available capacity across the Diameter nodes > >>> to which requests can be routed. ": I think it may be misleading > >>> what is the "total available capacity across nodes". > >>>>>> See proposal: > >>>>>> " The calculated LOAD value MUST reflect each Diameter node > >>>>>> capacity > >>> relative to the maximum available capacity for a Diameter node to > >>> which requests can be routed." > >>>>> SRD> This wording could imply that the LOAD value carries load > >>>>> information for multiple Diameter nodes. How about the following: > >>>>> > >>>>> "The calculated LOAD value MUST reflect the sending Diameter > >>>>> nodes capacity relative to the maximum available capacity for the > >>>>> sending Diameter node." > >>>>> > >>>>>> 3) Wording in Appendix A. > >>>>>> > >>>>>> Before we reword Appendix A, we need to decide if it is still need= ed. > >>>>>> It was valuable in helping to generate the solution but I'm not > >>>>>> convinced it is > >>> still needed in the document. Is there objection to removing this se= ction? > >>>>>> [MCruz] I prefer this to remain, it provides some hints that may > >>>>>> be valuable > >>> for first time readers. > >>>>> SRD> I'd like to hear other opinions on this as there is work > >>>>> SRD> required > >>>>> to make the section consistent with the mechanism defined. > >>>>> Implementors will still have access to this information by > >>>>> reviewing the history of the process of writing the specification. > >>>>> > >>>>> SRD> Are there schedule pressures in 3GPP to get this to RFC state? > >>>>> SRD> If > >>>>> so, it will be faster to just remove this section. > >>>>>> _______________________________________________ > >>>>>> DiME mailing list > >>>>>> DiME@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/dime > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dime > >> > _________________________________________________________________ > >> ________________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > >> que les pieces jointes. Les messages electroniques etant susceptibles > >> d'alteration, Orange decline toute responsabilite si ce message a ete = altere, > deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not > >> be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > >> delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > >> been modified, changed or falsified. > >> Thank you. > > > > > _________________________________________________________________ > ________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Sep 23 23:04:45 2016 Return-Path: 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 765D312B800; Fri, 23 Sep 2016 23:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 R5lO7HodeEnr; Fri, 23 Sep 2016 23:04:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D302312B7F2; Fri, 23 Sep 2016 23:04:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C6F41B81120; Fri, 23 Sep 2016 23:04:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160924060442.C6F41B81120@rfc-editor.org> Date: Fri, 23 Sep 2016 23:04:42 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7966 on Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 06:04:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7966 Title: Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements Author: H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay Status: Informational Stream: IETF Date: September 2016 Mailbox: Hannes.tschofenig@gmx.net, jouni.nospam@gmail.com, glenzorn@gmail.com, kervin.pillay@gmail.com Pages: 11 Characters: 22186 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-e2e-sec-req-05.txt URL: https://www.rfc-editor.org/info/rfc7966 DOI: http://dx.doi.org/10.17487/RFC7966 This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs). This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Sep 26 00:01:31 2016 Return-Path: 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 F2D3212B097 for ; Mon, 26 Sep 2016 00:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ITumOfT351hF for ; Mon, 26 Sep 2016 00:01:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9303E12B095 for ; Mon, 26 Sep 2016 00:01:27 -0700 (PDT) X-AuditID: c1b4fb3a-e95069800000099a-ad-57e8c7c5f58d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 44.63.02458.5C7C8E75; Mon, 26 Sep 2016 09:01:25 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Mon, 26 Sep 2016 09:01:12 +0200 From: Maria Cruz Bartolome To: "lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed resolutions of LOAD discussion Thread-Index: AQHR982IgzbA9rocjkqyt2JxmheRAqBZdIeAgAdgD4CABTuhgIAbDa6AgAAihBD///dngIAAIdpggAAXyQCAAMB+8IACSoEAgAK/cYCAAAN0gIAAFxSAgARAGTA= Date: Mon, 26 Sep 2016 07:01:12 +0000 Message-ID: <087A34937E64E74E848732CFF8354B921A4CD87D@ESESSMB101.ericsson.se> References: <17ea1d91-10e9-2431-d523-f3d63ee8233d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4ABD72@ESESSMB101.ericsson.se> <994653cb-5e59-9384-2447-315293a0a86d@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4B0905@ESESSMB101.ericsson.se> <0fc3b83d-e9c8-7300-a124-e96980c0201e@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9D8A@ESESSMB101.ericsson.se> <20a5b717-8bac-e0b7-4591-1a92ec776f51@usdonovans.com> <087A34937E64E74E848732CFF8354B921A4C9E8B@ESESSMB101.ericsson.se> <15039_1474322455_57E06017_15039_2527_3_6B7134B31289DC4FAF731D844122B36E01FBA6CD@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4C9F8B@ESESSMB101.ericsson.se> <27128_1474489743_57E2ED8F_27128_11313_1_6B7134B31289DC4FAF731D844122B36E01FBD499@OPEXCLILM43.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B921A4CD4D5@ESESSMB101.ericsson.se> <3d8ec922-5d31-45b4-2ed1-4a9ddf6829e5@usdonovans.com> <8890_1474646504_57E551E8_8890_8904_1_6B7134B31289DC4FAF731D844122B36E01FBF899@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <8890_1474646504_57E551E8_8890_8904_1_6B7134B31289DC4FAF731D844122B36E01FBF899@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7lO7R4y/CDS4dsbaY27uCzeL29kyL DU08DsweS5b8ZPJoeXaSzWPV2z7WAOYoLpuU1JzMstQifbsErowP00QLLm5nrLh4qY29gfHE ZMYuRk4OCQETic/XH7F1MXJxCAmsZ5RY9fUuWEJIYAmjxOMTQSA2m4CdxKXTL5hAikQE2hgl uifNZwFJCAtYS2zfu5sZxBYRsJH48GMDVFEXo8Tpyy1MIAkWAVWJ9gdn2UFsXgFfid57q5gg 1m3lkJj6/AoLiMMp0M4oceTXQlaQKkYBMYnvp9aAdTMLiEvcejKfCeJYAYkle84zQ9iiEi8f /2OFsJUk1h7ezgJRrydxY+oUNghbW2LZwtfMEJsFJU7OfMIygVFkFpKxs5C0zELSMgtJywJG llWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgZFycMtvqx2MB587HmIU4GBU4uFNuPE8XIg1 say4MvcQowQHs5II7+IdL8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpa kFoEk2Xi4JRqYGzXMpfkKp/KOifzVbfcusdiQu7P/qrpT7N/O5XjXGtxX9GMnIzNDlKOBT+e pRYL6yx9eDJQ8tAht+MXFmjbNatPW2C9wUsu0aBC6ESz2Pkey75l57x3ql2dGHRQSuSH26re N2aHko4r9WzulZv3MKrj13urRYIRRv7/ixyfF/7dtrv02YrEQiWW4oxEQy3mouJEAJdllK2Q AgAA Archived-At: Subject: Re: [Dime] Proposed resolutions of LOAD discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 07:01:31 -0000 Hello, I think we could simplify a bit the text, and keep what I think is key: "The LOAD value should be calculated in a way that reflects the available l= oad independently of the weight of each server, in order to accurately comp= are LOAD values from different nodes. Any specific LOAD value needs to iden= tify the same amount of available capacity, regardless the Diameter node t= hat calculates the value." I think this cover our concerns.=20 And add the following sentence: "The mechanism used to calculate the LOAD value that fulfils this requirem= ent is an implementation decision." Let me know your views Best regards /MCruz =20 -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: viernes, 23 de septiembre de 2016 18:02 To: Steve Donovan; Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] Proposed resolutions of LOAD discussion Hi, I have to admit that I'm lost. Maybe not the last time. And I really have some doubts that people reading the proposed text will be= able to understand something. First of all, it is not only about "loadbalance". You may have a single age= nt in front of a single server and the load value reported by the agent nee= ds to reflect the capacity to process incoming requests as well as the agen= t capacity to forward the requests towards the server. And the last one dep= ends on the server capacity. If there is more than one server, the "forward= ing capacity" depends on the whole capacity of the server farm. Is the above summary correct? Is there something missing? Now, I don't understand the following assertion: "all nodes in the group of= Diameter nodes need to express their load using the maximum capacity of th= e SAME node in the group." Could you please clarify? regards, Lionel > -----Message d'origine----- > De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9=A0: vendr= edi=20 > 23 septembre 2016 16:39 =C0=A0: Maria Cruz Bartolome; MORAND Lionel=20 > IMT/OLN; dime@ietf.org Objet=A0: Re: [Dime] Proposed resolutions of LOAD= =20 > discussion >=20 > Maria Cruz, >=20 > I'm mostly okay with your proposal. My concern is that all nodes in=20 > the group of Diameter nodes need to express their load using the=20 > maximum capacity of the SAME node in the group. Your wording implies=20 > that individual nodes in the group could choose different nodes maximum c= apacity in its calculations. >=20 > I also think it works if the maximum total capacity of the group is used. >=20 > One other option would be to base this on transactions per second=20 > rather than capacity. It might be late to consider this, but we could=20 > base it on the TPS a node is currently able to handle. The primary=20 > issue with this approach is that not all transactions consume the same re= sources. >=20 > Assuming we don't want to switch over to TPS, I propose the following=20 > modification of Maria Cruz's wording: >=20 > "The calculated LOAD value MUST reflect the reporting Diameter node's=20 > capacity relative to the maximum capacity of a Diameter node in the=20 > group of nodes the messages are load balanced. All nodes in the group=20 > MUST use the same nodes maximum capacity when calculating it's own LOAD v= alue. >=20 > Note: The LOAD value should be calculated in a way that reflects the=20 > available load independently of the weight of each server. This=20 > allows the Diameter node that routes a request, including nodes doing=20 > server selection and agents routing requests, to accurately compare=20 > values from different nodes. Any specific LOAD value needs to=20 > identify the same amount of available capacity, regardless the Diameter = node that calculates the value." >=20 >=20 > Regards, >=20 > Steve >=20 > On 9/23/16 7:32 AM, Maria Cruz Bartolome wrote: > > Hello all, > > > > The importance of the "relative" value is not only to provide a=20 > > value in a range > from 0-65535, but that this value is coordinated with the different=20 > nodes among which the request could be load-balanced. > > The 0-65535 could identify a capacity value for a single Diameter=20 > > node, but if it > does not take into account rest of nodes it will be useless. > > As we explained, for an small node, its maximum of capacity (i.e.=20 > > 65535) could > mean a very little capacity compared to a "big" server, even when that=20 > server indicates an e.g. low capacity value (e.g. 1000). > > Then, it is key to explain that, and it was what we agreed to include i= n the doc. > > > > Then, my proposal would be the following: > > > > "The calculated LOAD value MUST reflect the reporting Diameter=20 > > node's capacity relative to the maximum capacity of a Diameter node=20 > > in the group of nodes the messages are load balanced. > > > > Note: The LOAD value should be calculated in a way that reflects the=20 > > available load independently of the weight of each server. This=20 > > allows the Diameter node that routes a request, including nodes=20 > > doing server selection and agents routing requests, to accurately=20 > > compare values from different nodes. Any specific LOAD value needs=20 > > to identify the same amount of available capacity, regardless the=20 > > Diameter node > that calculates the value. > > > >=20 > > > > I hope this could get agreeable. > > Best regards > > /MCruz > > > > -----Original Message----- > > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > > Sent: mi=E9rcoles, 21 de septiembre de 2016 22:29 > > To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > > Subject: RE: [Dime] Proposed resolutions of LOAD discussion > > > > Hi Maria Cruz, > > > > "Relative" could also be simply understood as the fact that it is=20 > > not an absolute > value but a value defined in comparison of arbitrary values fixing a=20 > finite range ("0-65535"). At least it is how I have interpreted so far. > > > > And I thought that the remaining point was on how to calculate to=20 > > determine > this value. > > I think that the clarification could be that this value reflects=20 > > either the capacity > of the reporting node (when processing the request and generating the=20 > answer e.g. server) or its forwarding capacity (when acting as an=20 > relay/proxy). And the forwarding case obviously depends on the upstream l= oad capacity. > > > > And this this what I have tried to summarize in: > > > > "The calculated LOAD value MUST indicate the relative capacity of a=20 > > Diameter > node to process or forward subsequent request messages. The method for=20 > determining the total available capacity is outside of the scope of=20 > this document. > > > > NOTE: When the reporting node is not a server, the LOAD value=20 > > reflects not > only the capacity of the reporting node but also the total capacity of=20 > the Diameter nodes to which requests can be forwarded." > > > >> -----Message d'origine----- > >> De : Maria Cruz Bartolome=20 > >> [mailto:maria.cruz.bartolome@ericsson.com] > >> Envoy=E9 : mardi 20 septembre 2016 09:32 =C0 : MORAND Lionel IMT/OLN;= =20 > >> Steve Donovan; dime@ietf.org Objet : RE: [Dime] Proposed=20 > >> resolutions of LOAD discussion > >> > >> Hello Lionel, > >> > >> We need to clarify "relative to what". This is the part we are rephras= ing. > >> > >> Anyway, I will keep NOTE by Steve: > >> > >> Note: The LOAD value should be calculated in a way that reflects=20 > >> the available load independently of the weight of each server. =20 > >> This allows the Diameter node that routes a request, including=20 > >> nodes doing server selection and agents routing requests, to=20 > >> accurately compare values from different nodes. Any specific LOAD=20 > >> value needs to identify the same amount of available capacity,=20 > >> regardless the Diameter > node that calculates the value. > >> The mechanism used to calculate the LOAD value that fulfils this=20 > >> requirement is an implementation decision. > >> > >> > >> Cheers > >> /MCruz > >> > >> -----Original Message----- > >> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > >> Sent: martes, 20 de septiembre de 2016 0:01 > >> To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org > >> Subject: RE: [Dime] Proposed resolutions of LOAD discussion > >> > >> Hi, > >> > >> I was wondering if we could simplify in a way that would be=20 > >> understandable for anyone outside the current discussion. > >> > >> Is something missing in the following text? > >> > >> "The calculated LOAD value MUST indicate the relative capacity of a=20 > >> Diameter node to process or forward subsequent request messages.=20 > >> The method for determining the total available capacity is outside=20 > >> of the scope of this document. > >> > >> NOTE: When the reporting node is not a server, the LOAD value=20 > >> reflects not only the capacity of the reporting node but also the=20 > >> total capacity of the Diameter nodes to which requests can be forwarde= d." > >> > >> Lionel > >> > >>> -----Message d'origine----- > >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz=20 > >>> Bartolome Envoy=E9 : lundi 19 septembre 2016 20:45 =C0 : Steve=20 > >>> Donovan; dime@ietf.org Objet : Re: [Dime] Proposed resolutions of=20 > >>> LOAD discussion > >>> > >>> Hello Steve, > >>> > >>> See proposal: > >>> > >>> "The calculated LOAD value MUST reflect the reporting Diameter=20 > >>> node's capacity relative to the maximum capacity for a Diameter=20 > >>> node in the group of nodes the messages are load balanced". > >>> > >>> I removed "available" because it may be misinterpreted as=20 > >>> "available at a moment in time", what is not right, it is just the=20 > >>> maximum capacity it is offered, it can be reached. > >>> "for a Diameter node": in order to indicate that it is the maximum=20 > >>> capacity of "any" of the Diameter nodes, what a Diameter node is=20 > >>> normally > >> offering. > >>> But we can limit that to the group of nodes that are receivers of=20 > >>> messages, > i.e. > >>> the load-balancing group. > >>> > >>> Does it make sense to you? > >>> Thanks Steve > >>> > >>> -----Original Message----- > >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >>> Sent: lunes, 19 de septiembre de 2016 20:35 > >>> To: Maria Cruz Bartolome; dime@ietf.org > >>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >>> > >>> Actually, looking at it again, I think the following wording is neede= d: > >>> > >>> "The calculated LOAD value MUST reflect the reporting Diameter=20 > >>> node's capacity relative to the maximum available capacity for the=20 > >>> set of Diameter nodes that are potential receiving nodes for the=20 > >>> future messages covered by the LOAD report." > >>> > >>> We probably need some words on what the set of Diameter nodes=20 > >>> comprises, as it is different for HOST reports and PEER reports. > >>> > >>> Does this work? > >>> > >>> Steve > >>> > >>> On 9/19/16 12:11 PM, Maria Cruz Bartolome wrote: > >>>> Hello Steve, > >>>> > >>>> Thanks for the clarification > >>>> I still think the last part of the sentence is misleading: "... > >>>> relative to the > >>> maximum available capacity for the reporting Diameter node ". > >>>> It should be "... relative to the maximum available capacity for=20 > >>>> a reporting > >>> Diameter node". > >>>> The reasoning is that it should be relative to the maximum=20 > >>>> capacity not of that > >>> particular reporting node, but any of the nodes. That is, if we=20 > >>> use SRV to provide the load value, the maximum load is 65535, but=20 > >>> a particular node may just have a maximum capacity of e.g. 4000.=20 > >>> Then the load value of this reporting node should be relative not=20 > >>> to 4000 but to 65535, and it should be done the same for all=20 > >>> nodes, in a way that the > >> load is then comparable by the reacting node. > >>>> Is my point clearer now? > >>>> The NOTE you wrote clarified that point in fact. > >>>> > >>>> Best regards > >>>> /MCruz > >>>> > >>>> -----Original Message----- > >>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >>>> Sent: lunes, 19 de septiembre de 2016 19:02 > >>>> To: Maria Cruz Bartolome; dime@ietf.org > >>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >>>> > >>>> Maria Cruz, > >>>> > >>>> I think we are saying the same thing. My original has an=20 > >>>> unfortunate typo and > >>> should have read as follows: > >>>> "The calculated LOAD value MUST reflect the sending Diameter=20 > >>>> node's > >>> capacity relative to the maximum available capacity for the=20 > >>> sending Diameter node." > >>>> In thinking about this, the word sending might also not be clear=20 > >>>> enough. We > >>> might want to use the reporting node instead. This would change=20 > >>> it to the > >>> following: > >>>> "The calculated LOAD value MUST reflect the reporting Diameter=20 > >>>> node's > >>> capacity relative to the maximum available capacity for the=20 > >>> reporting Diameter node." > >>>> Regards, > >>>> > >>>> Steve > >>>> > >>>> On 9/2/16 4:56 AM, Maria Cruz Bartolome wrote: > >>>>> Hello Steve, > >>>>> > >>>>> Thanks for the proposal. > >>>>> I still think the text is a bit misleading: > >>>>> > >>>>> "The calculated LOAD value MUST reflect the sending Diameter=20 > >>>>> nodes capacity relative to the maximum available capacity for=20 > >>>>> the sending Diameter node." > >>>>> > >>>>> I think it should be: > >>>>> "The calculated LOAD value MUST reflect the sending Diameter=20 > >>>>> node capacity relative to the maximum available capacity for a=20 > >>>>> sending Diameter node." > >>>>> > >>>>> Reasoning: a node may have a very limited maximum capacity, but=20 > >>>>> the key > >>> point is precisely to provide a LOAD value relative to the maximum=20 > >>> value A node may have. > >>>>> I hope this clarifies > >>>>> Thanks > >>>>> /MCruz > >>>>> > >>>>> -----Original Message----- > >>>>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] > >>>>> Sent: martes, 30 de agosto de 2016 5:59 > >>>>> To: Maria Cruz Bartolome; dime@ietf.org > >>>>> Subject: Re: [Dime] Proposed resolutions of LOAD discussion > >>>>> > >>>>> Maria Cruz, > >>>>> > >>>>> Thanks for your comments. See my replies inline. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Steve > >>>>> > >>>>> On 8/25/16 5:31 PM, Maria Cruz Bartolome wrote: > >>>>>> Hello Steve, > >>>>>> > >>>>>> Thanks for the proposals, see below Best regards /MCruz > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 > >>>>>> Donovan > >>>>>> Sent: martes, 16 de agosto de 2016 16:50 > >>>>>> To: dime@ietf.org > >>>>>> Subject: [Dime] Proposed resolutions of LOAD discussion > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> I have outlined proposed solutions for the issues raised in the=20 > >>>>>> discussion > >>> around the Diameter Load draft. > >>>>>> Please let me know if I've missed anything from the discussion. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Steve > >>>>>> > >>>>>> Primary Issues: > >>>>>> > >>>>>> 1) Use of DNS SRV weighted value as format for LOAD value. > >>>>>> > >>>>>> This was discussed and agreed to early in the process. It has=20 > >>>>>> the advantage > >>> that Diameter nodes can use a combination of values received via=20 > >>> the DNS SRV interface and dynamic values received through the=20 > >>> Diameter LOAD > >> interface. > >>> While I agree that it isn't as intuitive as a straight percentage=20 > >>> value, I don't see this as compelling enough of a reason to change=20 > >>> a decision the working group has already made. > >>>>>> [MCruz] I still think using SRV values is error prone and=20 > >>>>>> anti-intuitive, but I > >>> can live with this if you really think it is not possible to re-evalu= ate this now. > >>>>> SRD> I haven't seen any argument that using the SRV values=20 > >>>>> SRD> doesn't > >>>>> work. As such, I prefer to not change this at this stage of the pr= ocess. > >>>>>> 2) Need to add wording that the calculated LOAD value needs to=20 > >>>>>> be based > >>> on overall available capacity. > >>>>>> I agree with Maria Cruz's comment that we need to add wording=20 > >>>>>> indicating > >>> that the calculated LOAD value needs to reflect available capacity. > >>> To this end, I propose adding the following to section 6.1 (this=20 > >>> is based on wording proposed by Maria Cruz): > >>>>>> The calculated LOAD value MUST reflect the Diameter nodes=20 > >>>>>> capacity > >>> relative to the total available capacity across the Diameter nodes=20 > >>> to which requests can be routed. This could be either a set of=20 > >>> Diameter endpoints or a set of Diameter agents, depending on the=20 > >>> type of the LOAD report. The method for determining the total=20 > >>> available capacity is outside of the scope of this document. > >>>>>> Note: The LOAD value should be calculated in a way that=20 > >>>>>> reflects the > >>> available load independently of the weight of each > >>>>>> server. This allows the Diameter node that routes a=20 > >>>>>> request, including > >>> nodes doing server selection and agents routing > >>>>>> requests, to accurately compare values from different=20 > >>>>>> nodes. Any > >>> specific LOAD value needs to identify the same > >>>>>> amount of available capacity, regardless the Diameter=20 > >>>>>> node that > >>> calculates the value. > >>>>>> The mechanism used to calculate the LOAD value that fulfills=20 > >>>>>> this > >>> requirement is an implementation decision. > >>>>>> > >>>>>> [MCruz] Some comments to proposed text: > >>>>>> " The calculated LOAD value MUST reflect the Diameter nodes=20 > >>>>>> capacity > >>> relative to the total available capacity across the Diameter nodes=20 > >>> to which requests can be routed. ": I think it may be misleading=20 > >>> what is the "total available capacity across nodes". > >>>>>> See proposal: > >>>>>> " The calculated LOAD value MUST reflect each Diameter node=20 > >>>>>> capacity > >>> relative to the maximum available capacity for a Diameter node to=20 > >>> which requests can be routed." > >>>>> SRD> This wording could imply that the LOAD value carries load > >>>>> information for multiple Diameter nodes. How about the following: > >>>>> > >>>>> "The calculated LOAD value MUST reflect the sending Diameter=20 > >>>>> nodes capacity relative to the maximum available capacity for=20 > >>>>> the sending Diameter node." > >>>>> > >>>>>> 3) Wording in Appendix A. > >>>>>> > >>>>>> Before we reword Appendix A, we need to decide if it is still need= ed. > >>>>>> It was valuable in helping to generate the solution but I'm not=20 > >>>>>> convinced it is > >>> still needed in the document. Is there objection to removing this se= ction? > >>>>>> [MCruz] I prefer this to remain, it provides some hints that=20 > >>>>>> may be valuable > >>> for first time readers. > >>>>> SRD> I'd like to hear other opinions on this as there is work=20 > >>>>> SRD> required > >>>>> to make the section consistent with the mechanism defined. > >>>>> Implementors will still have access to this information by=20 > >>>>> reviewing the history of the process of writing the specification. > >>>>> > >>>>> SRD> Are there schedule pressures in 3GPP to get this to RFC state? > >>>>> SRD> If > >>>>> so, it will be faster to just remove this section. > >>>>>> _______________________________________________ > >>>>>> DiME mailing list > >>>>>> DiME@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/dime > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dime > >> > _________________________________________________________________ > >> ________________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations=20 > >> confidentielles ou privilegiees et ne doivent donc pas etre=20 > >> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 > >> ce message par erreur, veuillez le signaler a l'expediteur et le=20 > >> detruire ainsi que les pieces jointes. Les messages electroniques=20 > >> etant susceptibles d'alteration, Orange decline toute=20 > >> responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > >> > >> This message and its attachments may contain confidential or=20 > >> privileged information that may be protected by law; they should=20 > >> not be distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender=20 > >> and delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that=20 > >> have been modified, changed or falsified. > >> Thank you. > > > > > _________________________________________________________________ > ________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or=20 > > privileged > information that may be protected by law; they should not be=20 > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender=20 > > and delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that=20 > > have been > modified, changed or falsified. > > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 27 07:37:53 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC912B209; Tue, 27 Sep 2016 07:37:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147498707204.4543.14013841889888211937.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 07:37:52 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 14:37:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-03.txt Pages : 22 Date : 2016-09-27 Abstract: This document defines a mechanism for conveying of Diameter load information. [RFC7068] describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The Diameter Overload Information Conveyance (DOIC) [RFC7683] solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 28 04:55:15 2016 Return-Path: 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 7976412B3DE for ; Wed, 28 Sep 2016 04:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no 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 vYDIjnkiR7MP for ; Wed, 28 Sep 2016 04:55:14 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 2D8E012B0BE for ; Wed, 28 Sep 2016 04:55:13 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:63665 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bpDSB-001FFl-Lt for dime@ietf.org; Wed, 28 Sep 2016 04:55:13 -0700 From: Steve Donovan To: "dime@ietf.org" Message-ID: Date: Wed, 28 Sep 2016 06:55:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=2.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Dime] New version of LOAD draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 11:55:15 -0000 All, I have made Maria Cruz's suggested change and have posted a new version of the draft. I believe this has all of the changes we have talked about. Steve