From Marco.Liebsch@neclab.eu Mon Mar 4 07:19:00 2013 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 A0BB421F88E6 for ; Mon, 4 Mar 2013 07:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRgkjLmxRSb0 for ; Mon, 4 Mar 2013 07:18:59 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5B921F88A2 for ; Mon, 4 Mar 2013 07:18:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 13759103533; Mon, 4 Mar 2013 16:18:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeIY3OlzFK4S; Mon, 4 Mar 2013 16:18:58 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id EBD56103532; Mon, 4 Mar 2013 16:18:48 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 4 Mar 2013 16:17:51 +0100 From: Marco Liebsch To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: Command re-use, implicit capability exchange Thread-Index: Ac4OuQyQ8H4ReiUWQhuKnixoZI/HFAG5AUkwANLr7nA= Date: Mon, 4 Mar 2013 15:17:50 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551DF1E0@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D551D861C@PALLENE.office.hd> <354_1362048090_512F345A_354_82_1_6B7134B31289DC4FAF731D844122B36E13EB13@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <354_1362048090_512F345A_354_82_1_6B7134B31289DC4FAF731D844122B36E13EB13@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Command re-use, implicit capability exchange X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2013 15:19:00 -0000 Hi Lionel, please see inline. >-----Original Message----- >From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >Sent: Donnerstag, 28. Februar 2013 11:41 >To: Marco Liebsch; dime@ietf.org >Subject: RE: Command re-use, implicit capability exchange > >Hi Marco, > >Thank you for reactivating this discussion. > >See below. > >Lionel > >-----Message d'origine----- >De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de >Marco Liebsch Envoy=E9=A0: mardi 19 f=E9vrier 2013 17:24 =C0=A0: dime@ietf= .org Objet=A0: >[Dime] Command re-use, implicit capability exchange > >Hi, > >the latest proposal to enable Diameter to signal group commands re-uses >existing Diameter messages and adds new group-specific AVPs to the command= . > >Can such approach implicitly avoid conflicts with group signaling between = a >group-enabled Diameter node and a Diameter node, which does *not* support >group signaling? When the specification allows each node to assign a sessi= on to >a group and both sides agree to the group, it means implicitly that at lea= st these >two nodes support group operations. > >[LM] ok > >In such case, the new AVPs to assign a session to a group, could be >informational, hence they do not have the M-bit set. Group assignment coul= d >e.g. be done during AAR/AAA when the session ID is built. >In case a receive cannot understand the semantics of the AVPs that are mea= nt to >build the group, the response must not include these AVPs. The originator = of the >AAR implicitly learns that the remote peer does not support group operatio= ns. > >[LM] ok > >In case the remote peer does not want to assign the session to a group for= other >reasons, this needs to be signaled explicitly. > >[LM] ok. > >It's more difficult if group assignment is being done only by the receiver= of a >message and the receiver indicates the group in the response (i.e. AAA). T= he >sender of the AAR may not be able to interpret the group-specific AVPs. > >[LM] The principle given above can be also applied in this case. The clien= t can >ask for group assignment and wait for the answer from the server. This cou= ld be >done using a flag, an empty value in the Group-Session-ID AVP, or any othe= r >suitable solution. That's not the scenario I refer to above. Assume the client sends a single-= session AAR (without group-ID, as it does not support grouping) and the server assi= gns the associated Session ID to a group, letting the client know about the Group I= D in the AAA. The client will ignore the group-ID in the AAA as it does not support group= ing and group operations. The Server will not be aware of this. So, we need to handle thi= s case. What we could mandate is that clients, which support grouping, must include= a Group-ID in any case, even if it's empty. So the server knows about the cli= ent's capability and can assign the session to a group. In case the server receiv= es a request without Group-ID AVP, the server MUST NOT assigned the session to a group. Is that the way out? > >Furthermore, changes in the support of group operations may be possible af= ter >one of the Diameter nodes changed and the existing session context is >transferred to the new Diameter node. That could be after a handover or af= ter a >failover scenario. Here, group re-assignment is needed anyhow, at least in= case >of handover. First handshakes after such relocation of a Diameter node may >require fallback to single session operations e.g. to assign a session to = a new >group. > >[LM] For me there are two steps: the old node has to remove the "transferr= ed" >session from the group-session handled locally and the transferred session= is >assigned to a new Group-session in the new client (if supported). In such = a case, >the old client should notify the server of the change in the group assignm= ent. >After, there is a new group assignment mechanism between the new client an= d >the server, which would be independent of the other one. We could force client and server to re-assign transferred Sessions to group= s in any case. In such case we may run into the abovementioned scenario: The handover targ= et client sends the first message to the server. The server has a user context stored= and assigns the user session to a different group. The associated Group ID is s= ignaled to the target client in the Server's response. The client ignores the Group-ID= . The other scenario is probably less likely: Server change, e.g. during fail= over handling. But here I guess the (redundant) server, which takes over the sessions of t= he failed server, should support the same capabilities, including group operations.=20 marco > >Any thoughts? > >marco > >_______________________________________________ >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, expl= oites ou >copies sans autorisation. Si vous avez recu ce message par erreur, veuille= z le >signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les m= essages >electroniques etant susceptibles d'alteration, France Telecom - Orange dec= line >toute responsabilite si ce message a ete altere, deforme ou falsifie. Merc= i. > >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 del= ete this >message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for messag= es >that have been modified, changed or falsified. >Thank you. From Marco.Liebsch@neclab.eu Mon Mar 4 07:32:37 2013 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 8A6A021F88D6 for ; Mon, 4 Mar 2013 07:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAC96kZocgMK for ; Mon, 4 Mar 2013 07:32:37 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A512521F86F7 for ; Mon, 4 Mar 2013 07:32:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1BA19103533; Mon, 4 Mar 2013 16:32:36 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsh5V5BfZSPS; Mon, 4 Mar 2013 16:32:36 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 014FE103535; Mon, 4 Mar 2013 16:32:26 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 4 Mar 2013 16:32:25 +0100 From: Marco Liebsch To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: Command re-use, setting of Session-ID AVP Thread-Index: Ac4OtcLIuklXVXaaSdK4oRU9fuI7VQG6ncyAANLhxAA= Date: Mon, 4 Mar 2013 15:31:48 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551DF213@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D551D8596@PALLENE.office.hd> <354_1362048301_512F352D_354_94_3_6B7134B31289DC4FAF731D844122B36E13EB53@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <354_1362048301_512F352D_354_94_3_6B7134B31289DC4FAF731D844122B36E13EB53@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Command re-use, setting of Session-ID AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2013 15:32:37 -0000 Hi Lionel, please inline. >-----Original Message----- >From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >Sent: Donnerstag, 28. Februar 2013 11:45 >To: Marco Liebsch; dime@ietf.org >Subject: RE: Command re-use, setting of Session-ID AVP > >Hi Marco, > >I think that the simplest approach would be to use the session-ID as it is= , without >impacts of the concept of group. That is, each message should be first rel= ated to >a given session (identified by the session-id AVP). The group management w= ill be >done using the dedicated new AVPs. Therefore, it is completely transparent= for >nodes not supporting the concept of group, especially proxies that could b= e in >the signaling path. Yes, if we treat grouping AVPs separately and informational, we can enable the Single-Session-Fallback as indicated in the previous mail.=20 Btw "proxy": There was an issue with stateful proxies and group operations,= which has been addressed on the ML some time ago. It was about the case where Dia= meter sessions have been set up via different proxies, hence states are distribut= ed between multiple proxies. A group session termination will allow terminating (a sub= set of the group's) states solely on a single proxy which forwards the group message. Other pro= xies will not see that group message, unless the server keeps a record of the proxy and sends= multiple group session termination commands, one though each proxy. But that causes that t= he Client will receive multiple group session termination requests.. Not really clean. marco > >Regards, > >Lionel > >-----Message d'origine----- >De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de >Marco Liebsch Envoy=E9=A0: mardi 19 f=E9vrier 2013 16:50 =C0=A0: dime@ietf= .org Objet=A0: >[Dime] Command re-use, setting of Session-ID AVP > >Hi, > >the latest proposal to enable Diameter to signal group commands re-uses >existing Diameter messages and adds new group-specific AVPs to the command= . > >How to set the session's mandatory Session-ID? It has a fixed location in = the >message and message parsing may rely on the value of the Session-ID AVP as >key to lookup a particular session's entry in the local database. >Group-Session-ID AVP(s) may follow the mandatory Session-ID. > >Now, the mandatory Session-ID AVP could hold the following values: > >+ All-0 or any other not allocated value: Probably not conform to >+ standard >peers which do not support group operations > >+ Group-Session-ID: Previously agreed with the peer. May conflict with >+ the original >definition of the Session-ID to hold a single session's ID. > >+ Single Session ID of a session which is part of the previously assigned = group. >Would allow fallback to process the command for a single session only. > >Any comments? > >marco > > > >_______________________________________________ >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, expl= oites ou >copies sans autorisation. Si vous avez recu ce message par erreur, veuille= z le >signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les m= essages >electroniques etant susceptibles d'alteration, France Telecom - Orange dec= line >toute responsabilite si ce message a ete altere, deforme ou falsifie. Merc= i. > >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 del= ete this >message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for messag= es >that have been modified, changed or falsified. >Thank you. From Marco.Liebsch@neclab.eu Mon Mar 4 07:42:13 2013 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 0E46B21F8A1C for ; Mon, 4 Mar 2013 07:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v56CsTuOEYD0 for ; Mon, 4 Mar 2013 07:42:12 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1D48521F8A94 for ; Mon, 4 Mar 2013 07:42:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 373FB103535; Mon, 4 Mar 2013 16:42:11 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYcn4pAHlMpJ; Mon, 4 Mar 2013 16:42:11 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1955510352C; Mon, 4 Mar 2013 16:42:01 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 4 Mar 2013 16:42:01 +0100 From: Marco Liebsch To: "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: Command re-use, M-bit of new group AVPs Thread-Index: Ac4OsUNUQpxH1ZzkTIG+jAOQXYHuCQG8FkygANMdZqA= Date: Mon, 4 Mar 2013 15:41:24 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D551DF230@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D551D855F@PALLENE.office.hd> <5841_1362049421_512F398D_5841_1204_10_6B7134B31289DC4FAF731D844122B36E13EC2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <5841_1362049421_512F398D_5841_1204_10_6B7134B31289DC4FAF731D844122B36E13EC2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Command re-use, M-bit of new group AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2013 15:42:13 -0000 Lionel, pleases see inline. >-----Original Message----- >From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >Sent: Donnerstag, 28. Februar 2013 12:04 >To: Marco Liebsch; dime@ietf.org >Subject: RE: Command re-use, M-bit of new group AVPs > >Hi Marco, > >Please see below. > >Regards, > >Lionel > >-----Message d'origine----- >De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de >Marco Liebsch Envoy=E9=A0: mardi 19 f=E9vrier 2013 16:20 =C0=A0: dime@ietf= .org Objet=A0: >[Dime] Command re-use, M-bit of new group AVPs > >Hi, > >the latest proposal to enable Diameter to signal group commands re-uses >existing Diameter messages and adds new group-specific AVPs to the command= . >Examples for new AVPs are a Group-Session-ID AVP and a Group-Session-Actio= n >AVP. >Let's dig into some technical details to assess the approach. > >IMO, the M-bit of the new AVPs must be set and must result in an error >response at a receiver in case the receiver of the group command does not >understand the semantics of the new AVP, hence it does not support group >operations. The sender of the group command must then fall back to signal >individual commands for each session. > >[LM] that could be a guideline when defining a new application reusing exi= sting >commands. Yes. > >The only way to *not* set the M-bit and 'ignore' the new group AVP at such >receiver would be to include sufficient information according to the stand= ard >application, including a single session's Session ID. >That could enable the receiver to process the command for at least one sin= gle >session of the group. This would require adding a single session's Session= -ID into >the typically mandatory Session-ID AVP of the message. >The receiver may send a positive response to the sender of the group messa= ge >and indicate that solely for the included Session ID the command had been >processed successfully. This assumes a standard Diameter peer behaves like >that. >If that works, the sender could omit sending an individual command at leas= t for >the session that had been processed already. > >[LM] Everything related to a single session should remain unchanged. For >instance, creation/termination of each individual session will trigger a s= pecific >exchange between the client and the server. So for all these messages, the >session id assigned to the current session will be used to populate the Se= ssion-Id >AVP. Now, when a request is initiated to impact a group of sessions, the s= ession- >id AVP must be filled with one of the session-id values pertaining to the = group. >So at least, any node will be able to manage individual sessions. Between = clients >and servers, the way to discover that both sides support the group session >management is discussed in another thread. But when both nodes have >discovered that the other end-point supports the mechanism, all the inform= ation >related to the group session management can be done using AVP with the M-b= it >cleared. This will ensure that this mechanism can be also reused over exis= ting >applications if required. > Yes, that's the fallback to a single session, which we described in previou= s mails. In terms of specification, I think we must decide using either mechanism, right? Means, either a new application for group operations, or the optional approach which adds informational group AVPs. The latter probably has to be thoroughly analyzed, in particular w.r.t. proxies on th= e path. marco > >Any comments? > >marco > > > >_______________________________________________ >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, expl= oites ou >copies sans autorisation. Si vous avez recu ce message par erreur, veuille= z le >signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les m= essages >electroniques etant susceptibles d'alteration, France Telecom - Orange dec= line >toute responsabilite si ce message a ete altere, deforme ou falsifie. Merc= i. > >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 del= ete this >message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for messag= es >that have been modified, changed or falsified. >Thank you. From lionel.morand@orange.com Tue Mar 5 02:29:41 2013 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 CBAFD21F8824 for ; Tue, 5 Mar 2013 02:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHeKxzdLA4iC for ; Tue, 5 Mar 2013 02:29:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C103C21F8921 for ; Tue, 5 Mar 2013 02:29:40 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3044632406A; Tue, 5 Mar 2013 11:29:40 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 121F52380CF; Tue, 5 Mar 2013 11:29:40 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 5 Mar 2013 11:29:39 +0100 From: To: Marco Liebsch , "dime@ietf.org" Thread-Topic: Command re-use, M-bit of new group AVPs Thread-Index: Ac4OsUNUQpxH1ZzkTIG+jAOQXYHuCQG8FkygANMdZqAAJ0PtYA== Date: Tue, 5 Mar 2013 10:29:39 +0000 Message-ID: <13310_1362479380_5135C914_13310_289_1_6B7134B31289DC4FAF731D844122B36E148DA2@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <69756203DDDDE64E987BC4F70B71A26D551D855F@PALLENE.office.hd> <5841_1362049421_512F398D_5841_1204_10_6B7134B31289DC4FAF731D844122B36E13EC2B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <69756203DDDDE64E987BC4F70B71A26D551DF230@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D551DF230@PALLENE.office.hd> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Subject: Re: [Dime] Command re-use, M-bit of new group AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2013 10:29:41 -0000 Hi Marco, See below. Regards, Lionel -----Message d'origine----- De=A0: Marco Liebsch [mailto:Marco.Liebsch@neclab.eu]=20 Envoy=E9=A0: lundi 4 mars 2013 16:41 =C0=A0: MORAND Lionel OLNC/OLN; dime@ietf.org Objet=A0: RE: Command re-use, M-bit of new group AVPs Lionel, pleases see inline. >-----Original Message----- >From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] >Sent: Donnerstag, 28. Februar 2013 12:04 >To: Marco Liebsch; dime@ietf.org >Subject: RE: Command re-use, M-bit of new group AVPs > >Hi Marco, > >Please see below. > >Regards, > >Lionel > >-----Message d'origine----- >De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de >Marco Liebsch Envoy=E9=A0: mardi 19 f=E9vrier 2013 16:20 =C0=A0: dime@ietf= .org Objet=A0: >[Dime] Command re-use, M-bit of new group AVPs > >Hi, > >the latest proposal to enable Diameter to signal group commands re-uses >existing Diameter messages and adds new group-specific AVPs to the command. >Examples for new AVPs are a Group-Session-ID AVP and a Group-Session-Action >AVP. >Let's dig into some technical details to assess the approach. > >IMO, the M-bit of the new AVPs must be set and must result in an error >response at a receiver in case the receiver of the group command does not >understand the semantics of the new AVP, hence it does not support group >operations. The sender of the group command must then fall back to signal >individual commands for each session. > >[LM] that could be a guideline when defining a new application reusing exi= sting >commands. Yes. > >The only way to *not* set the M-bit and 'ignore' the new group AVP at such >receiver would be to include sufficient information according to the stand= ard >application, including a single session's Session ID. >That could enable the receiver to process the command for at least one sin= gle >session of the group. This would require adding a single session's Session= -ID into >the typically mandatory Session-ID AVP of the message. >The receiver may send a positive response to the sender of the group messa= ge >and indicate that solely for the included Session ID the command had been >processed successfully. This assumes a standard Diameter peer behaves like >that. >If that works, the sender could omit sending an individual command at leas= t for >the session that had been processed already. > >[LM] Everything related to a single session should remain unchanged. For >instance, creation/termination of each individual session will trigger a s= pecific >exchange between the client and the server. So for all these messages, the >session id assigned to the current session will be used to populate the Se= ssion-Id >AVP. Now, when a request is initiated to impact a group of sessions, the s= ession- >id AVP must be filled with one of the session-id values pertaining to the = group. >So at least, any node will be able to manage individual sessions. Between = clients >and servers, the way to discover that both sides support the group session >management is discussed in another thread. But when both nodes have >discovered that the other end-point supports the mechanism, all the inform= ation >related to the group session management can be done using AVP with the M-b= it >cleared. This will ensure that this mechanism can be also reused over exis= ting >applications if required. > Yes, that's the fallback to a single session, which we described in previous mails. In terms of specification, I think we must decide using either mechanism, right? Means, either a new application for group operations, or the optional approach which adds informational group AVPs. The latter probably has to be thoroughly analyzed, in particular w.r.t. proxies on th= e path. [LM] Right. I think that we could manage to define the AVPs and provide gui= delines on how to set the M-bit depending on the use case (e.g. not set whe= n introduced in existing applications, set in new applications, etc.) About Proxies on the path, please see the other mail on "Command re-use, se= tting of Session-ID AVP" marco > >Any comments? > >marco > > > >_______________________________________________ >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, expl= oites ou >copies sans autorisation. Si vous avez recu ce message par erreur, veuille= z le >signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les m= essages >electroniques etant susceptibles d'alteration, France Telecom - Orange dec= line >toute responsabilite si ce message a ete altere, deforme ou falsifie. Merc= i. > >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 del= ete this >message and its attachments. >As emails may be altered, France Telecom - Orange is not liable for messag= es >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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From trac+dime@trac.tools.ietf.org Wed Mar 6 00:56:53 2013 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 D37EB21F8880 for ; Wed, 6 Mar 2013 00:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+bBbsBgKMBM for ; Wed, 6 Mar 2013 00:56:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E14D321F8555 for ; Wed, 6 Mar 2013 00:56:52 -0800 (PST) Received: from localhost ([127.0.0.1]:41284 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UDA9b-0003JX-3X; Wed, 06 Mar 2013 09:56:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Wed, 06 Mar 2013 08:56:51 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/1#comment:2 Message-ID: <079.7e12e3ac32c6baf0ea973e0ea78c7b51@trac.tools.ietf.org> References: <064.deedbc1cef285da291122078a2c5083f@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <064.deedbc1cef285da291122078a2c5083f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jouni.nospam@gmail.com, lionel.morand@orange.com, Resent-Message-Id: <20130306085652.E14D321F8555@ietfa.amsl.com> Resent-Date: Wed, 6 Mar 2013 00:56:52 -0800 (PST) Resent-From: trac+dime@trac.tools.ietf.org Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] [dime] #1: Section 3.1.2 pointer to the "normal discovery procedures" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 08:56:53 -0000 #1: Section 3.1.2 pointer to the "normal discovery procedures" Changes (by jouni.nospam@gmail.com): * status: new => closed * resolution: => fixed Comment: This seems to have been addressed in revisions after -03.. Currently the text on "normal discovery procedures" is located in Section 3.2.2: 2. If successful, locate and establish a route to a peer in the realm given by the Redirect-Realm AVP, using normal discovery procedures as described in Section 5.2 of [RFC6733]. -- ------------------------------------+---------------------------- Reporter: jouni.nospam@gmail.com | Owner: dime@ietf.org Type: enhancement | Status: closed Priority: trivial | Milestone: Component: realm-based-redirect | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: editorial | ------------------------------------+---------------------------- Ticket URL: dime From jean-jacques.trottin@alcatel-lucent.com Thu Mar 7 04:44:04 2013 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 590E821F8AD8 for ; Thu, 7 Mar 2013 04:44:04 -0800 (PST) X-Quarantine-ID: <8-ofTYEhw59c> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace: References: ...2DC66@FR712WXCHMBA12.zeu.alcatel-lucent.com>\n X-Spam-Flag: NO X-Spam-Score: -9.021 X-Spam-Level: X-Spam-Status: No, score=-9.021 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ofTYEhw59c for ; Thu, 7 Mar 2013 04:44:00 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 79C9021F8AB7 for ; Thu, 7 Mar 2013 04:44:00 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r27ChWV0011345 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Mar 2013 13:43:58 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Mar 2013 13:43:37 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 7 Mar 2013 13:43:37 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAC1zwgAAJKeA= Date: Thu, 7 Mar 2013 12:43:37 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201074D1FFR712WXCHMBA10z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2013 12:44:04 -0000 --_000_E194C2E18676714DACA9C3A2516265D201074D1FFR712WXCHMBA10z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all I am coming back to the REQ2 discussion we had a few weeks ago and for whic= h there is no yet consensus. In parallel, in the context of the 3GPP work about Diameter overload, there= was an email thread on this REQ2 topic. I reformulate hereaftger my last = comment which I did in this 3GPP discussion and which is in the continuity= of the proposal to DIME that Laurent did on Jan 24th and of my Feb 8th c= omment so that DIME List may express their views, in particular for the Or= lando IETF meeting. 1. REQ2 currently only says "The mechanism MUST allow Diameter node= s to support overload control regardless of which Diameter applications the= y support". The word Regardless is ambiguous. An interpretation is to under= stand it as "independent of" the Diameter applications, meaning Diameter ap= plication are not involved in the overload control. This statement may be v= alid for some Diameter applications (it is why there is the word "allow"), = but there are other cases, especially in 3GPP environment, where other Di= ameter applications must be aware of the overload situation, especially whe= n the nodes support a large amount of UEs towards which they have to accu= rately drive the UE behaviour in overload situations. It is why it is proposed to add "The mechanism MUST allow Diameter clients = to be aware of an overload situation". If we have not this statement in REQ2, there is no REQ to which we can ref= er to support these essential 3GPP cases, as the current REQ2 cannot apply.= The current REQ 2 is here incomplete and I think it is not acceptable in i= ts current writing. 2. Besides the case of a DA supporting topology hiding, there are ot= her cases that must be supported a) the mechanism must work with a network where there is no intermedi= ate DA (as described in the overload scenarios of the IEFT draft) and here = it is the end Diameter node that will receive the overload info, and as a= client has to handle this overload situation (cf point1) b) Similar to the above there is the case of networks with intermedia= te DAs with limited functions (eg for routing purposes and without topolog= y hiding) and which are not upgraded for overload support. Here also the me= chanism must support this case, overload being handled (as in a) above) bet= ween server and clients as no identified differences. If this case is exclu= ded, it imposes a high constraint to the operator to have all the DAs to su= pport the mechanism. This case, for me, is not excluded of the draft and re= lies on the REQ 35 that applies. But as this deployment case must be suppor= ted, it means that the mechanism must work when intermediate nodes are not = supporting overload control. It is why we have proposed REQ35 to be with a = MUST instead of a SHOULD (as Laurent wrote in his Jan 24th mail. 3. about the hiding topology DA case, such a DA plus the hidden serve= rs behind will appear as a "global server" to the clients. In this case the= DA will have to support the mechanism in order to define if the "global se= rver" is overloaded and if yes to generate the overload information assoc= iated to this "global server" and transmit it to the clients which then may= act according to point 1) . So the DA case with topology hiding is quite c= ompatible with the point 1 and with the proposed requirement "The mechanis= m MUST allow Diameter clients to be aware of an overload situation " Best regards JJacques De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : vendredi 8 f=E9vrier 2013 15:01 =C0 : dime@ietf.org Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Eric About the REQ2 with the addition of : The mechanism MUST allow Diameter app= lications to be aware of an overload situation. I think it is a central point of discussion. Regarding the usage of Diamete= r in 3GPP environment which is my concern, as Laurent, I consider that the= client at the source of Diameter requests (so not an intermediate DA) ha= s to be involved in an overload situation, not only to reduce the traffic a= s such but on the way it will do it. Quite often in a 3GGP case, the involv= ed Diameter client will have to trigger some behavior towards the mobile t= erminals . Whatever the way overload handling is implemented in the client= and the role of the Diameter stack , the triggering of UE behavior will be= at the application level, which then has to be aware of the overload situa= tion (so the above additional statement in REQ2). A second point behind this statement, is that, if requested, the overload i= nformation must be propagated up to the Diameter client for an accurate han= dling and not to be stopped by an intermediate agent who considers it hand= les the overload by itself and does not need to propagate the overload inf= ormation upstream. I don't say that it is systematic and in 3GPP it will depend of the applica= tion case, it is why we write "must allow". Best regards JJacques --_000_E194C2E18676714DACA9C3A2516265D201074D1FFR712WXCHMBA10z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi = all

 

I a= m coming back to the REQ2 discussion we had a few weeks ago and for which t= here is no yet consensus.

In = parallel, in the context of the 3GPP work about Diameter overload, there wa= s an email thread on this REQ2 topic.  I reformulate hereaftger my last comment which I did in this 3GPP discussion and  w= hich is in the continuity of the proposal to DIME that Laurent did on =  Jan 24th and of my Feb 8th  comment so tha= t DIME List may express their views,  in particular for the Orlando IETF meeting.

 

1.         REQ2 currently only says “The mechanism MUST = allow Diameter nodes to support overload control regardless of which Diameter applications they support”. The word Re= gardless is ambiguous. An interpretation is to understand it as “independent of” the Diameter applications, meaning Diameter application are not involved i= n the overload control. This statement may be valid for some Diameter appli= cations (it is why there is the word “allow”),   but = there are other cases, especially in 3GPP environment, where other Diameter applications must be aware of the overload situation,= especially when the nodes support  a large amount of UEs  toward= s which they have to accurately drive the UE behaviour in overload situatio= ns.

It is why it is proposed to add “The mechanism MUST allow= Diameter clients to be aware of an overload situation”.

 If we have not this statement in REQ2, there is no REQ to= which we can refer to support these essential 3GPP cases, as the current REQ2 cannot apply. The current REQ 2 = is here incomplete and I think it is not acceptable in its current writing.

 

2.       Besides the case of a  DA supporting topology hiding, ther= e are other cases that must be supported

a)       the mechanism must work with a network where there is no interm= ediate DA (as described in the overload scenarios of the IEFT draft) and here  it is the  end Diameter n= ode that will receive the overload info, and as a client has to handle this= overload situation (cf point1)

 

b)       Similar to the above there is the case of networks with interme= diate DAs with limited functions  (eg for routing purposes and without topology hiding) and which are = not upgraded for overload support. Here also the mechanism must support thi= s case, overload being handled (as in a) above) between server and clients = as no identified differences. If this case is excluded, it imposes a high constraint to the operator to have all= the DAs to support the mechanism. This case, for me, is not excluded = of the draft and relies on the REQ 35 that applies. But as this deployment = case must be supported, it means that the mechanism must work when intermediate nodes are not supporting overloa= d control. It is why we have proposed REQ35 to be with a MUST instead of a = SHOULD (as Laurent wrote in his Jan 24th  mail.

 

3.       about the hiding topology DA case, such a DA plus the hidden se= rvers behind will appear as a “global server” to the clients. In this case the DA will have to support the= mechanism in order to define if the “global server” is overloa= ded and if yes to generate   the overload information associated = to this “global server” and transmit it to the clients which then may act according to point 1) . So the DA case with topology hiding i= s quite compatible with the point  1 and with the proposed requirement= “The mechanism MUST allow Diameter clients to be aware of an overloa= d situation “

 

Bes= t regards

 

JJa= cques

 

&nb= sp;

De := TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoy=E9 : vendredi 8 f= =E9vrier 2013 15:01
=C0 : dime@ietf.org
Objet : RE: [Dime] draf= t-ietf-dime-overload-reqs-03: REQ 2

 

= Hi Eric

=  

= About the REQ2 with the addition of : The mechanism MUST allow Diameter applications to be aware of an overload = situation.

= I think it is a central point of discussion. Regarding the usage of = Diameter in 3GPP environment which is my concern, as Laurent,  I consider that the client  at the source of Diamet= er requests  (so not an intermediate DA) has to be involved in an over= load situation, not only to reduce the traffic as such but on the way it wi= ll do it. Quite often in a 3GGP case, the involved Diameter  client will have to trigger some behavior towards the mobil= e terminals . Whatever the way overload handling  is implemented in th= e client and the role of the Diameter stack , the triggering of UE behavior= will be at the application level, which then has to be aware of the overload situation (so the above additional stateme= nt in REQ2).

= A second point behind this statement, is that, if requested, the ove= rload information must be propagated up to the Diameter client for an accurate handling  and not to be stopped by an= intermediate agent who considers it handles the overload by itself  a= nd does not need to propagate the overload information  upstream.=

=  

= I don’t say that it is systematic and in 3GPP it will depend o= f the application case, it is why we write “must allow”.

=  

=  

= Best regards

=  

= JJacques

 

--_000_E194C2E18676714DACA9C3A2516265D201074D1FFR712WXCHMBA10z_-- From jean-jacques.trottin@alcatel-lucent.com Thu Mar 7 03:57:47 2013 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 8901421F8D62 for ; Thu, 7 Mar 2013 03:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfYGfKODd1VF for ; Thu, 7 Mar 2013 03:57:38 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 788EB21F8D5B for ; Thu, 7 Mar 2013 03:57:37 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r27BvZrG029580 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Mar 2013 12:57:35 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Mar 2013 12:57:34 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 7 Mar 2013 12:57:34 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0A== Date: Thu, 7 Mar 2013 11:57:33 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.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: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201074CD3FR712WXCHMBA10z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 X-Mailman-Approved-At: Thu, 07 Mar 2013 07:34:19 -0800 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2013 11:57:47 -0000 --_000_E194C2E18676714DACA9C3A2516265D201074CD3FR712WXCHMBA10z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all I am coming back to the REQ2 discussion we had a few weeks ago and for whic= h there is no yet consensus. In parallel, in the context of the 3GPP work about Diameter overload, ther= e was an email thread on this REQ2 topic. I reformulate here my last comme= nt which I did in this 3GPP discussion and which is in the continuity of = the comments Laurent and I did in Jan 24th and Feb 8th hereafterr mails = so that DIME List may express their views, in particular for the Orlando I= ETF meeting. 1. REQ2 currently only says "The mechanism MUST allow Diameter node= s to support overload control regardless of which Diameter applications the= y support". The word Regardless is ambiguous. An interpretation is to under= stand it as "independent of" the Diameter applications, meaning Diameter ap= plication are not involved in the overload control. This statement may be v= alid for some Diameter applications (it is why there is the word "allow"), = but there are other cases, especially in 3GPP environment, where other Di= ameter applications must be aware of the overload situation, especially whe= n the nodes support a large amount of UEs towards which they have to accu= rately drive the UE behaviour in overload situations. It is why it is proposed to add "The mechanism MUST allow Diameter clients = to be aware of an overload situation". If we have not this statement in REQ2, there is no REQ to which we can ref= er to support these essential 3GPP cases, as the current REQ2 cannot apply.= The current REQ 2 is here incomplete and I think it is not acceptable in i= ts current writing. 2. Besides the case of a DA supporting topology hiding, there are ot= her cases that must be supported a) the mechanism must work with a network where there is no intermedi= ate DA (as described in the overload scenarios of the IEFT draft) and here = it is the end Diameter node that will receive the overload info, and as a= client has to handle this overload situation (cf point1) b) Similar to the above there is the case of networks with intermedia= te DAs with limited functions (eg for routing purposes and without topolog= y hiding) and which are not upgraded for overload support. Here also the me= chanism must support this case, overload being handled (as in a) above) bet= ween server and clients as no identified differences. If this case is exclu= ded, it imposes a high constraint to the operator to have all the DAs to su= pport the mechanism. This case, for me, is not excluded of the draft and re= lies on the REQ 35 that applies. But as this deployment case must be suppor= ted, it means that the mechanism must work when intermediate nodes are not = supporting overload control. It is why we have proposed REQ35 to be with a = MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. 3. about the hiding topology DA case, such a DA plus the hidden serve= rs behind will appear as a "global server" to the clients. In this case the= DA will have to support the mechanism in order to define if the "global se= rver" is overloaded and if yes to generate the overload information assoc= iated to this "global server" and transmit it to the clients which then may= act according to point 1) . So the DA case with topology hiding is quite c= ompatible with the point 1 and with the proposed requirement "The mechanis= m MUST allow Diameter clients to be aware of an overload situation " Best regards JJacques ________________________________ De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : vendredi 8 f=E9vrier 2013 15:01 =C0 : dime@ietf.org Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Eric About the REQ2 with the addition of : The mechanism MUST allow Diameter app= lications to be aware of an overload situation. I think it is a central point of discussion. Regarding the usage of Diamete= r in 3GPP environment which is my concern, as Laurent, I consider that the= client at the source of Diameter requests (so not an intermediate DA) ha= s to be involved in an overload situation, not only to reduce the traffic a= s such but on the way it will do it. Quite often in a 3GGP case, the involv= ed Diameter client will have to trigger some behavior towards the mobile t= erminals . Whatever the way overload handling is implemented in the client= and the role of the Diameter stack , the triggering of UE behavior will be= at the application level, which then has to be aware of the overload situa= tion (so the above additional statement in REQ2). A second point behind this statement, is that, if requested, the overload i= nformation must be propagated up to the Diameter client for an accurate han= dling and not to be stopped by an intermediate agent who considers it hand= les the overload by itself and does not need to propagate the overload inf= ormation upstream. I don't say that it is systematic and in 3GPP it will depend of the applica= tion case, it is why we write "must allow". Best regards JJacques From: dime-bounces@ietf.org [mailto:dime-boun= ces@ietf.org] On Behalf Of THIEBAUT, LAURENT (LAURENT) Sent: jeudi 7 f=E9vrier 2013 20:11 To: Eric McMurry Cc: dime@ietf.org Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hello Eric Thanks for your feedback Trying to reformulate 1) About Req 2: I meant that the mechanisms to carry Diameter overload must= be able to carry this information up to the Diameter peer nodes (Diameter = client/server) 2) Based on your feedback, I understand that indeed having a dedicated requ= irement for emergency is too much. This is why I suggested the rewording of= an informative sentence in Req26 as follows: For example, it may be more beneficial to process messages for existing ses= sions ahead of new sessions, and it is required to give priority to request= s associated with emergency sessions or with high priority users. 3) As long as it is agreed/understood by the Dime group that "the possibili= ty of passing overload information via intermediate agents that do not supp= ort the extension" is required, I am fine. Best Regards Laurent ALCATEL-LUCENT ________________________________ De : Eric McMurry [mailto:emcmurry@computer.org] Envoy=E9 : jeudi 7 f=E9vrier 2013 16:00 =C0 : THIEBAUT, LAURENT (LAURENT) Cc : Ben Campbell; dime@ietf.org Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Laurent, Thanks for the responses. Please see comments inline. Eric On Feb 7, 2013, at 8:10 , "THIEBAUT, LAURENT (LAURENT)" > wrote: Hello all Thanks Eric and Ben. I owe you some further answers and comments (LTH2) and= apologize for being a bit late. Please consider them inline starting with LTH2 and consider they are NOT ai= ming at pushing any solution. Best Regards Laurent ALCATEL-LUCENT -----Message d'origine----- De : Ben Campbell [mailto:ben@nostrum.com] Envoy=E9 : jeudi 31 janvier 2013 00:48 =C0 : Eric McMurry; THIEBAUT, LAURENT (LAURENT) Cc : dime@ietf.org Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi, please see comments inline. (Apologies for the late response--I'm catching up on email after vacation.) On Jan 24, 2013, at 1:04 PM, Eric McMurry > wrote: > Thanks Laurent. > > comments inline. > > > Eric > > > On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" > wrote: > >> >> >> Hello all >> Please find below our remarks on draft draft-ietf-dime-overload-reqs-03 = about Diameter Overload Control Requirements >> >> These remarks address topics we have already addressed over Dime but for= which we think some enhancements to the text is needed. >> We hope to converge quickly as we believe that based on these small enha= ncements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and move= d forward into the IETF standardization process. >> >> 1. REQ 2: The mechanism MUST allow Diameter nodes to support overlo= ad >> control regardless of which Diameter applications they >> support. The mechanism MUST allow Diameter applications >> to be aware of an overload situation. >> We believe that a proper handling of a Diameter server overload is to re= port it at the level of its Diameter client applications in order for them = to take proper decisions. This may mean to send signalling towards non Diam= eter entities. >> This may relate with the comment made by Hannes. > As in the current draft, do you think this requirement can be interpreted= to say that a diameter stack should handle overload without application in= tervention and that implementations of overload control mechanisms are requ= ired to act in that fashion? > > I'm struggling a bit with this since I'm reading it as a requirement on i= mplementations of the overload control mechanism (as opposed to requirement= s on the specification of the mechanism). Is it reasonable to require a st= ack to not handle overload control by itself? My personal opinion is that the draft should not talk about software archit= ecture--just protocol behavior. OTOH, I'm not sure if Laurent meant to refer to the separation between the = Diameter application and stack on a Diameter node, or the client applicatio= n that Diameter is supporting. If the second, I agree putting a few words = to that effect could be useful. (For example, if the Diameter client at a = NAS cannot successfully perform an authorization, it might have to cleanly = reject a network attachment attempt. The details of that rejection would be= out of scope for the overload control mechanism, but the client would stil= l need to Do the Right Thing) [LTH2] This means that the mechanisms to carry Diameter overload shall be a= ble to carry this information up to the Diameter application within the Dia= meter peer node (Diameter client/server) [em] I think I still don't understand the requirement here. It sounds li= ke an implementation detail to me. If we were to require that an overload = control mechanism provide some information to an application above it (note= that application can mean multiple things here), then the overload control= mechanism would have to provide some sort of application level API to comp= ly, right? I think implementations are likely to do this anyways, but it d= oesn't need to be done in an interoperable fashion (that would require spec= ification). I may still be missing your point though. >> >> >> >> >> >> 2. We recommend to add following requirement: >> REQ xx: The overload control mechanism MUST allow networks to properly = support Diameter signalling related with emergency and/or priority users. >> This aspect is mentioned in Req 26 but only as a general guidance while = this is a strong operational requirement. >> "For example, it may be more beneficial to process messages for >> existing sessions ahead of new sessions, or to give priority >> to requests associated with emergency sessions or with high >> priority users." > > What does this mean for a mechanism? How would it be done? This seems to me to be more like a more application specific requirement th= an a generic Diameter requirement. If so, I think that would be better spec= ified in whatever document might exist to specify how a particular applicat= ion might incorporate the overload control mechanism. (For example, in a 3G= PP document.) [LTH2] Even though this is not listed as a requirement with a number "Req x= x", it is important that the definition of the protocol that carries Diamet= er overload information keeps this important guideline in mind. Req 26 states "For example, it **may** be more beneficial to process messag= es for existing sessions ahead of new sessions, or to give priority to requ= ests associated with emergency sessions or with high priority users. ". Wh= ile "may" is OK for the priority for existing sessions, it is too weak for = the "emergency sessions or high priority users". Would following wording within REq26 be acceptable: For example, it may be more beneficial to process messages for existing ses= sions ahead of new sessions, and it is required to give priority to request= s associated with emergency sessions or with high priority users. [em] I think taking out the emergency services example may be a good soluti= on here. The definition of what to do with emergency message is probably b= est left to specifications that deal with that directly. >> >> >> >> >> 3. REQ 35: The mechanism SHOULD provide a method for exchanging >> overload and load information between elements that are >> connected by intermediaries that do not support the >> mechanism. >> We recommend to replace "The mechanism SHOULD provide a method" by "The = mechanism MUSTprovide a method" as it is a key requirement for deployments= especially via intermediate networks. > > Personally, I'm on the fence here. The main issue I have is that any end= to end, or end to information source method that passes through intermedia= ries that don't support the mechanism brings with it an absolute requiremen= t for end to end security. Given the state of end to end security, this wi= ll cause substantial delay to deployment of overload control. There is a m= iddle ground where a mechanism that could support end to end is required to= only be used hop by hop without end to end security in place. That may be= compatible with the suggested change to the requirement but it will have t= o be considered. > > There is also the consideration that a mechanism that requires hop-by-hop= action for overload control could be a reasonable or necessary approach, g= iven the potential complexity of the networks involved and the implications= of that on what the overload information contains. > > At any rate, if the change is made, we must also add the additional secur= ity requirement ensuring that the mechanism is not used without end to end = security (this is implied by REQ 28, but it needs to be made explicit). I think I concur with Eric here--there's a potential for some surprises her= e. I think we need more analysis of the security and architectural implica= tions of true hop-by-hop vs allowing non-adjacent nodes to communicate over= load information. I wonder if we can delegate that to the actual mechanism = work, or a separate document than this one? [LTH2]I'd insist on this as otherwise it prevents Diameter overload informa= tion to be passed via intermediate networks (e.g. IPX) that do not yet supp= ort the Diameter overload information related protocol. Is a Diameter Agent= required to understand all Diameter AVP? Especially when they would not be= tagged as NOT Mandatory? [em] I don't understand the last part of your statement. Are you referrin= g to a piggybacked approach to conveying the overload information? (I unde= rstand you are not advocating any particular solution. I'm just trying to = understand your questions) As to the general point though, as I said earlier, I'm fine with making thi= s a must as long as e2e security is also a must. I don't think there is ag= reement on making e2e security a must though, and I would certainly rather = not do that. Perhaps we can tie that requirement directly to this one. Fo= r example: REQ 35: The mechanism MUST provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism. Any exchange of overload and load information betw= een non-adjacent nodes MUST be encrypted for the full path between t= he non-adjacent nodes and have the source of the information verifi= ed. My preference though is still to leave this as is, so further analysis can = be done as part of the mechanism work. --_000_E194C2E18676714DACA9C3A2516265D201074CD3FR712WXCHMBA10z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = all

 

I a= m coming back to the REQ2 discussion we had a few weeks ago and for which t= here is no yet consensus.

&nb= sp;In parallel, in the context of the 3GPP work about Diameter overload, th= ere was an email thread on this REQ2 topic.  I reformulate here my last comment which I did in this 3GPP discussion and   w= hich is in the continuity of the comments Laurent and I did  in  = Jan 24th and Feb 8th  hereafterr mails so that D= IME List may express their views,  in particular for the Orlando IETF meeting.

 

1.         REQ2 currently only says “The mechanism MUST allow Diameter nodes to supp= ort overload control regardless of which Diameter applications they support= ”. The word Regardless is ambiguous. An interpretation is to understa= nd it as “independent of”= the Diameter applications, meaning Diameter application are not involved i= n the overload control. This statement may be valid for some Diameter appli= cations (it is why there is the word “allow”),   but = there are other cases, especially in 3GPP environment, where other Diameter applications must be aware of the overload situation,= especially when the nodes support  a large amount of UEs  toward= s which they have to accurately drive the UE behaviour in overload situatio= ns.

It is why it is proposed to add “The mechanism MUST allow= Diameter clients to be aware of an overload situation”.

 If we have not this statement in REQ2, there is no REQ to= which we can refer to support these essential 3GPP cases, as the current REQ2 cannot apply. The current REQ 2 = is here incomplete and I think it is not acceptable in its current writing.

 

2.       Besides the case of a  DA supporting topology hiding, ther= e are other cases that must be supported

a)       the mechanism must work with a network where there is no interm= ediate DA (as described in the overload scenarios of the IEFT draft) and here  it is the  end Diameter n= ode that will receive the overload info, and as a client has to handle this= overload situation (cf point1)

 

b)       Similar to the above there is the case of networks with interme= diate DAs with limited functions  (eg for routing purposes and without topology hiding) and which are = not upgraded for overload support. Here also the mechanism must support thi= s case, overload being handled (as in a) above) between server and clients = as no identified differences. If this case is excluded, it imposes a high constraint to the operator to have all= the DAs to support the mechanism. This case, for me, is not excluded = of the draft and relies on the REQ 35 that applies. But as this deployment = case must be supported, it means that the mechanism must work when intermediate nodes are not supporting overloa= d control. It is why we have proposed REQ35 to be with a MUST instead of a = SHOULD (as Lauret wrote in his Jan 24th  mail.

 

3.       about the hiding topology DA case, such a DA plus the hidden se= rvers behind will appear as a “global server” to the clients. In this case the DA will have to support the= mechanism in order to define if the “global server” is overloa= ded and if yes to generate   the overload information associated = to this “global server” and transmit it to the clients which then may act according to point 1) . So the DA case with topology hiding i= s quite compatible with the point  1 and with the proposed requirement= “The mechanism MUST allow Diameter clients to be aware of an overloa= d situation “

 

Bes= t regards

 

JJa= cques

 

De := TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoy=E9 : vendredi 8 f= =E9vrier 2013 15:01
=C0 : dime@ietf.org
Objet : RE: [Dime] draf= t-ietf-dime-overload-reqs-03: REQ 2

 

= Hi Eric

=  

= About the REQ2 with the addition of : The mechanism MUST allow Diameter applications to be aware of an overload = situation.

= I think it is a central point of discussion. Regarding the usage of = Diameter in 3GPP environment which is my concern, as Laurent,  I consider that the client  at the source of Diamet= er requests  (so not an intermediate DA) has to be involved in an over= load situation, not only to reduce the traffic as such but on the way it wi= ll do it. Quite often in a 3GGP case, the involved Diameter  client will have to trigger some behavior towards the mobil= e terminals . Whatever the way overload handling  is implemented in th= e client and the role of the Diameter stack , the triggering of UE behavior= will be at the application level, which then has to be aware of the overload situation (so the above additional stateme= nt in REQ2).

= A second point behind this statement, is that, if requested, the ove= rload information must be propagated up to the Diameter client for an accurate handling  and not to be stopped by an= intermediate agent who considers it handles the overload by itself  a= nd does not need to propagate the overload information  upstream.=

=  

= I don’t say that it is systematic and in 3GPP it will depend o= f the application case, it is why we write “must allow”.

=  

=  

= Best regards

=  

= JJacques

= &nb= sp;

= &nb= sp;

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of THIEBAUT, LAURE= NT (LAURENT)
Sent: jeudi 7 f=E9vrier 2013= 20:11
To: Eric McMurry
Cc: dime@ietf.org
Subject: Re: [Dime] draft-ie= tf-dime-overload-reqs-03: REQ 2

 

 

 

Hello Eric

Thanks for your feedback

 

Trying to reformulate

1) About Req 2: I meant that the mechanisms to carry Diameter overlo= ad must be able to carry this information up to the Diameter peer nodes (Di= ameter client/server)

 

2) Based on your feedback, I understand that indeed havi= ng a dedicated requirement for emergency is too much. This is why I suggested the rewording of an inf= ormative  sentence in Req26 as follows:

For e= xample, it may be more beneficial to process messages for existing sessions= ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with high priority users= . 

=  

3) As long as it is agreed/understood by the Dime group = that “the possibility of passing overload information via intermediate agents that do not suppor= t the extension” is required, I am fine.

 

Best Regards

Laurent
ALCATEL-LU= CENT

De := Eric McMurry [mailto:emcmurry@com= puter.org]
Envoy=E9 : jeudi 7 f=E9= vrier 2013 16:00
=C0 : THIEBAUT, LAURENT= (LAURENT)
Cc : Ben Campbell; dime@ietf.org
Objet : Re: [Dime] draf= t-ietf-dime-overload-reqs-03: REQ 2

 

Hi Laurent,

 

Thanks for the responses.  Please see comments inline.

 

Eric

 

 

On Feb 7, 2013, at 8:10 , "THIEBAUT, LAURENT (LAURENT)" &= lt;laurent.thiebaut@= ALCATEL-LUCENT.COM> wrote:

 

 = ;

 = ;

Hello all

Thank= s Eric and Ben. I owe you some further answers and comments (LTH2) and apol= ogize for being a  bit late.

Pleas= e consider them inline starting with LTH2 and consider they are NOT aiming at pushing any solution.=

 = ;

Best Regards<= /p>

Laurent

ALCATEL-LUCENT

 

-----Message d'origine-----
De : Ben Campbell [mailto:ben@nostrum.com= ] 
Envoy=E9 : jeudi 31 janvier 2013 00:48
=C0 : Eric McMurry; THIEBAUT, LAURENT (LAURENT)
Cc : dim= e@ietf.org
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2<= /span>

 = ;

Hi, p= lease see comments inline.

 = ;

(Apol= ogies for the late response--I'm catching up on email after vacation.)

 = ;

On Ja= n 24, 2013, at 1:04 PM, Eric McMurry <emcmurry@compu= ter.org> wrote:

 = ;

> = Thanks Laurent.

><= /span> 

> = comments inline.

><= /span> 

><= /span> 

> = Eric=

><= /span> 

><= /span> 

> = On Jan 24, 2013, at 9:27 , "THIEBAUT, LAURENT (LAURENT)" <= laurent.thiebaut@ALCATEL-LUCENT.COM> wrote:

><= /span> 

>&= gt; 

>&= gt; 

>&= gt; Hello all

>&= gt; Please find below our remarks on draft draft-ietf-dime-overload-reqs-03= about Diameter Overload Control Requirements

>&= gt; 

>&= gt; These remarks address topics we have already addressed over Dime but fo= r which we think some enhancements to the text is needed.

>&= gt; We hope to converge quickly as we believe that based on these small enh= ancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved forward into the IETF standardization process.

>&= gt; 

>> 1.    REQ 2:   The m= echanism MUST allow Diameter nodes to support overload

>>       &nbs= p;     control regardless of which Diameter application= s they

>>       &nbs= p;     support. The mechanism MUST allow Diameter appli= cations

>> to be aware of an overload situation.<= /font>

>> We believe that a proper handling of a Diamet= er server overload is to report it at the level of its Diameter client applications in order for them to take proper decisions. This may m= ean to send signalling towards non Diameter entities.

>> This may relate with the comment made by Hann= es.<= /p>

> = As in the current draft, do you think this requirement can be interpreted t= o say that a diameter stack should handle overload without application intervention and that implementations of overload control mech= anisms are required to act in that fashion?

><= /span> 

> = I'm struggling a bit with this since I'm reading it as a requirement on imp= lementations of the overload control mechanism (as opposed to requirements on the specification of the mechanism).  Is it reason= able to require a stack to not handle overload control by itself?

 = ;

My pe= rsonal opinion is that the draft should not talk about software architectur= e--just protocol behavior.

 = ;

OTOH,= I'm not sure if Laurent meant to refer to the separation between the Diame= ter application and stack on a Diameter node, or the client application that Diameter is supporting.  If the second, I agr= ee putting a few words to that effect could be useful.  (For example, = if the Diameter client at a NAS cannot successfully perform an authorizatio= n, it might have to cleanly reject a network attachment attempt. The details of that rejection would be out of scope fo= r the overload control mechanism, but the client would still need to Do the= Right Thing)

[LTH2] This means that the mechanisms to carry Diameter = overload shall be able to carry this information up to the Diameter application within the Diameter = peer node (Diameter client/server)  

 

[em]   I think I still don't understand the requirement here. =  It sounds like an implementation detail to me.  If we were to re= quire that an overload control mechanism provide some information to an application above it (note that application= can mean multiple things here), then the overload control mechanism would = have to provide some sort of application level API to comply, right?  = I think implementations are likely to do this anyways, but it doesn't need to be done in an interoperable fashio= n (that would require specification).  I may still be missing your poi= nt though.

 

>&= gt; 

>&= gt; 

>&= gt; 

>&= gt; 

>&= gt; 

>&= gt; = 2.       We recomm= end to add following requirement:

>> REQ xx:  The overload control mechanism = MUST allow networks to properly support Diameter signalling related with emergency and/or priority users.

>> This aspect is mentioned in Req 26 but only a= s a general guidance while this is a strong operational requirement.=

>> “For example, it may be more beneficial= to process messages for=

>>       &nbs= p;     existing sessions ahead of new sessions, or to g= ive priority

>>       &nbs= p;     to requests associated with emergency sessions o= r with high

>>        &nb= sp;    priority users.”

><= /span> 

> = What does this mean for a mechanism?  How would it be done?

 = ;

This = seems to me to be more like a more application specific requirement than a = generic Diameter requirement. If so, I think that would be better specified in whatever document might exist to specify how a part= icular application might incorporate the overload control mechanism. (For e= xample, in a 3GPP document.)<= o:p>

[LTH2] Even though this is not listed as a requirement w= ith a number “Req xx”, it is important that the definition of the protocol that carries Diameter ove= rload information keeps this important guideline in mind.=

Req 26 states “For example, it **may** be more beneficial to process messages for existing se= ssions ahead of new sessions, or to give priority to requests associated wi= th emergency sessions or with high priority users.  ”. While “may” is OK for the priority for existing sessions, it i= s too weak for the “emergency sessions or high prio= rity users”.  

Would following wording within REq26 be acceptable:

For e= xample, it may be more beneficial to process messages for existing sessions= ahead of new sessions, and it is required to give priority to requests associated with emergency sessions or with high priority users= . 

 = ;

 

[em] I think taking out the emergency services example may be a goo= d solution here.  The definition of what to do with emergency message = is probably best left to specifications that deal with that directly.

 

 = ;

>&= gt; 

>&= gt; 

>&= gt; 

>&= gt; 

>&= gt; = 3.    REQ 35:  The mechanism= SHOULD provide a method for exchanging

>>       &nbs= p;     overload and load information between elements t= hat are

>>       &nbs= p;     connected by intermediaries that do not support = the<= /p>

>>       &nbs= p;     mechanism.

>> We recommend to replace “The mechanism = SHOULD provide a method” by “The mechanism MUSTprovide a method= ”  as it is a key requirement for deployments especially via intermediate net= works.

><= /span> 

> = Personally, I'm on the fence here.  The main issue I have is that any = end to end, or end to information source method that passes through intermediaries that don't support the mechanism brings with it an = absolute requirement for end to end security.  Given the state of end = to end security, this will cause substantial delay to deployment of overloa= d control.  There is a middle ground where a mechanism that could support end to end is required to only be use= d hop by hop without end to end security in place.  That may be compat= ible with the suggested change to the requirement but it will have to be co= nsidered.

><= /span> 

> = There is also the consideration that a mechanism that requires hop-by-hop a= ction for overload control could be a reasonable or necessary approach, given the potential complexity of the networks involved and the = implications of that on what the overload information contains.

><= /span> 

> = At any rate, if the change is made, we must also add the additional securit= y requirement ensuring that the mechanism is not used without end to end security (this is implied by REQ 28, but it needs to be made ex= plicit).

 = ;

I thi= nk I concur with Eric here--there's a potential for some surprises here.&nb= sp; I think we need more analysis of the security and architectural implications of true hop-by-hop vs allowing non-adjacent nodes to communic= ate overload information. I wonder if we can delegate that to the actual me= chanism work, or a separate document than this one?

 =

[LTH2]I’d insist on this as otherwise it prevents = Diameter overload information to be passed via intermediate networks (e.g. IPX) that do not yet support the= Diameter overload information related protocol. Is a Diameter Agent requir= ed to understand all Diameter AVP? Especially when they would not be tagged= as NOT Mandatory?<= span style=3D"font-size:10.0pt;font-family:"Courier New"">

 

[em]  I don't understand the last part of your statement. &nbs= p;Are you referring to a piggybacked approach to conveying the overload inf= ormation?  (I understand you are not advocating any particular solution.  I'm just trying to understan= d your questions)

 

As to the general point though, as I said earlier, I'm fine with ma= king this a must as long as e2e security is also a must.  I don't thin= k there is agreement on making e2e security a must though, and I would certainly rather not do that. &nbs= p;Perhaps we can tie that requirement directly to this one.  For examp= le:

 

REQ 35:  The mechanism MUST provide a method for = exchanging

             overlo= ad and load information between elements that are

             connec= ted by intermediaries that do not support the

             mechan= ism.  Any exchange of overload and load information between

      <= span lang=3D"EN-US" style=3D"font-size:10.0pt; font-family:"Courier New";color:blue">     non-adj= acent nodes MUST be encrypted for the full path between the

      <= span lang=3D"EN-US" style=3D"font-size:10.0pt; font-family:"Courier New";color:blue">     non-adj= acent nodes and have the source of the information verified.

 

My preference though is still to leave this as is, so further analy= sis can be done as part of the mechanism work.

--_000_E194C2E18676714DACA9C3A2516265D201074CD3FR712WXCHMBA10z_-- From jean-jacques.trottin@alcatel-lucent.com Thu Mar 7 04:09:25 2013 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 C5DBC21F8D31 for ; Thu, 7 Mar 2013 04:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.021 X-Spam-Level: X-Spam-Status: No, score=-8.021 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GThbwikwLUwG for ; Thu, 7 Mar 2013 04:09:20 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC521F8D10 for ; Thu, 7 Mar 2013 04:09:19 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r27C6bb9030253 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Mar 2013 13:09:18 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 7 Mar 2013 13:09:10 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 7 Mar 2013 13:09:10 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAC1zw Date: Thu, 7 Mar 2013 12:09:10 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201074CEEFR712WXCHMBA10z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-Mailman-Approved-At: Thu, 07 Mar 2013 07:34:19 -0800 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2013 12:09:25 -0000 --_000_E194C2E18676714DACA9C3A2516265D201074CEEFR712WXCHMBA10z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all I am coming back to the REQ2 discussion we had a few weeks ago and for whic= h there is no yet consensus. In parallel, in the context of the 3GPP work about Diameter overload, there= was an email thread on this REQ2 topic. I reformulate here my last commen= t which I did in this 3GPP discussion and which is in the continuity of t= he comments Laurent and I did to DIME in Jan 24th and Feb 8th hereafter m= ails so that DIME List may express their views, in particular for the Orla= ndo IETF meeting. 1. REQ2 currently only says "The mechanism MUST allow Diameter node= s to support overload control regardless of which Diameter applications the= y support". The word Regardless is ambiguous. An interpretation is to under= stand it as "independent of" the Diameter applications, meaning Diameter ap= plication are not involved in the overload control. This statement may be v= alid for some Diameter applications (it is why there is the word "allow"), = but there are other cases, especially in 3GPP environment, where other Di= ameter applications must be aware of the overload situation, especially whe= n the nodes support a large amount of UEs towards which they have to accu= rately drive the UE behaviour in overload situations. It is why it is proposed to add "The mechanism MUST allow Diameter clients = to be aware of an overload situation". If we have not this statement in REQ2, there is no REQ to which we can ref= er to support these essential 3GPP cases, as the current REQ2 cannot apply.= The current REQ 2 is here incomplete and I think it is not acceptable in i= ts current writing. 2. Besides the case of a DA supporting topology hiding, there are ot= her cases that must be supported a) the mechanism must work with a network where there is no intermedi= ate DA (as described in the overload scenarios of the IEFT draft) and here = it is the end Diameter node that will receive the overload info, and as a= client has to handle this overload situation (cf point1) b) Similar to the above there is the case of networks with intermedia= te DAs with limited functions (eg for routing purposes and without topolog= y hiding) and which are not upgraded for overload support. Here also the me= chanism must support this case, overload being handled (as in a) above) bet= ween server and clients as no identified differences. If this case is exclu= ded, it imposes a high constraint to the operator to have all the DAs to su= pport the mechanism. This case, for me, is not excluded of the draft and re= lies on the REQ 35 that applies. But as this deployment case must be suppor= ted, it means that the mechanism must work when intermediate nodes are not = supporting overload control. It is why we have proposed REQ35 to be with a = MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. 3. about the hiding topology DA case, such a DA plus the hidden serve= rs behind will appear as a "global server" to the clients. In this case the= DA will have to support the mechanism in order to define if the "global se= rver" is overloaded and if yes to generate the overload information assoc= iated to this "global server" and transmit it to the clients which then may= act according to point 1) . So the DA case with topology hiding is quite c= ompatible with the point 1 and with the proposed requirement "The mechanis= m MUST allow Diameter clients to be aware of an overload situation " Best regards JJacques ________________________________ De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : vendredi 8 f=E9vrier 2013 15:01 =C0 : dime@ietf.org Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Eric About the REQ2 with the addition of : The mechanism MUST allow Diameter app= lications to be aware of an overload situation. I think it is a central point of discussion. Regarding the usage of Diamete= r in 3GPP environment which is my concern, as Laurent, I consider that the= client at the source of Diameter requests (so not an intermediate DA) ha= s to be involved in an overload situation, not only to reduce the traffic a= s such but on the way it will do it. Quite often in a 3GGP case, the involv= ed Diameter client will have to trigger some behavior towards the mobile t= erminals . Whatever the way overload handling is implemented in the client= and the role of the Diameter stack , the triggering of UE behavior will be= at the application level, which then has to be aware of the overload situa= tion (so the above additional statement in REQ2). A second point behind this statement, is that, if requested, the overload i= nformation must be propagated up to the Diameter client for an accurate han= dling and not to be stopped by an intermediate agent who considers it hand= les the overload by itself and does not need to propagate the overload inf= ormation upstream. I don't say that it is systematic and in 3GPP it will depend of the applica= tion case, it is why we write "must allow". Best regards JJacques ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de THI= EBAUT, LAURENT (LAURENT) Envoy=E9 : jeudi 24 janvier 2013 16:27 =C0 : dime@ietf.org Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hello all Please find below our remarks on draft draft-ietf-dime-overload-reqs-03 abo= ut Diameter Overload Control Requirements These remarks address topics we have already addressed over Dime but for wh= ich we think some enhancements to the text is needed. We hope to converge quickly as we believe that based on these small enhance= ments draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved f= orward into the IETF standardization process. 1. REQ 2: The mechanism MUST allow Diameter nodes to support overload control regardless of which Diameter applications they support. The mechanism MUST allow Diameter applications to be aware of an overload situation. We believe that a proper handling of a Diameter server overload is to repor= t it at the level of its Diameter client applications in order for them to = take proper decisions. This may mean to send signalling towards non Diamete= r entities. This may relate with the comment made by Hannes. 2. We recommend to add following requirement: REQ xx: The overload control mechanism MUST allow networks to properly sup= port Diameter signalling related with emergency and/or priority users. This aspect is mentioned in Req 26 but only as a general guidance while thi= s is a strong operational requirement. "For example, it may be more beneficial to process messages for existing sessions ahead of new sessions, or to give priority to requests associated with emergency sessions or with high priority users." 3. REQ 35: The mechanism SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism. We recommend to replace "The mechanism SHOULD provide a method" by "The mec= hanism MUST provide a method" as it is a key requirement for deployments e= specially via intermediate networks. 4. We recommend to add following requirement REQ yy: The mechanism MUST support a default overload algorithm. This will= facilitate interoperability especially between Networks. 5. REQ 33: There are multiple situations where a Diameter node may be overloaded for some purposes but not others. For example, this can happen to an agent or server that supports multiple applications, or when a server depends on multiple external resources, some of which may become overloaded while others are fully available. The mechanism MUST allow Diameter nodes to indicate overload with sufficient granularity to allow clients to take action based on the overloaded resources without forcing available capacity to go unused. The mechanism MUST support specification of overload information with granularities of at least "Diameter node", "realm", "Diameter application", and "Diameter session", and SHOULD allow extensibility for others to be added in the future. a. We recommend to replace "SHOULD allow extensibility" by "MUST allo= w extensibility" . b. We are not sure that the granularity at Diameter session is really= required and suggest to remove it from this Req 33. Best Regards Laurent ALCATEL-LUCENT --_000_E194C2E18676714DACA9C3A2516265D201074CEEFR712WXCHMBA10z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi = all

 

I a= m coming back to the REQ2 discussion we had a few weeks ago and for which t= here is no yet consensus.

In = parallel, in the context of the 3GPP work about Diameter overload, there wa= s an email thread on this REQ2 topic.  I reformulate here my last comment which I did in this 3GPP discussion and   w= hich is in the continuity of the comments Laurent and I did to DIME in=  Jan 24th and Feb 8th  hereafter mails so = that DIME List may express their views,  in particular for the Orlando IETF meeting.

 

1.         REQ2 currently only says “The mechanism MUST = allow Diameter nodes to support overload control regardless of which Diameter applications they support”. The word Re= gardless is ambiguous. An interpretation is to understand it as “independent of” the Diameter applications, meaning Diameter application are not involved i= n the overload control. This statement may be valid for some Diameter appli= cations (it is why there is the word “allow”),   but = there are other cases, especially in 3GPP environment, where other Diameter applications must be aware of the overload situation,= especially when the nodes support  a large amount of UEs  toward= s which they have to accurately drive the UE behaviour in overload situatio= ns.

It is why it is proposed to add “The mechanism MUST allow= Diameter clients to be aware of an overload situation”.

 If we have not this statement in REQ2, there is no REQ to= which we can refer to support these essential 3GPP cases, as the current REQ2 cannot apply. The current REQ 2 = is here incomplete and I think it is not acceptable in its current writing.

 

2.       Besides the case of a  DA supporting topology hiding, ther= e are other cases that must be supported

a)       the mechanism must work with a network where there is no interm= ediate DA (as described in the overload scenarios of the IEFT draft) and here  it is the  end Diameter n= ode that will receive the overload info, and as a client has to handle this= overload situation (cf point1)

 

b)       Similar to the above there is the case of networks with interme= diate DAs with limited functions  (eg for routing purposes and without topology hiding) and which are = not upgraded for overload support. Here also the mechanism must support thi= s case, overload being handled (as in a) above) between server and clients = as no identified differences. If this case is excluded, it imposes a high constraint to the operator to have all= the DAs to support the mechanism. This case, for me, is not excluded = of the draft and relies on the REQ 35 that applies. But as this deployment = case must be supported, it means that the mechanism must work when intermediate nodes are not supporting overloa= d control. It is why we have proposed REQ35 to be with a MUST instead of a = SHOULD (as Lauret wrote in his Jan 24th  mail.

 

3.       about the hiding topology DA case, such a DA plus the hidden se= rvers behind will appear as a “global server” to the clients. In this case the DA will have to support the= mechanism in order to define if the “global server” is overloa= ded and if yes to generate   the overload information associated = to this “global server” and transmit it to the clients which then may act according to point 1) . So the DA case with topology hiding i= s quite compatible with the point  1 and with the proposed requirement= “The mechanism MUST allow Diameter clients to be aware of an overloa= d situation “

 

Bes= t regards

 

JJa= cques

 

De := TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Envoy=E9 : vendredi 8 f= =E9vrier 2013 15:01
=C0 : dime@ietf.org
Objet : RE: [Dime] draf= t-ietf-dime-overload-reqs-03: REQ 2

 

= Hi Eric

=  

= About the REQ2 with the addition of : The mechanism MUST allow Diameter applications to be aware of an overload = situation.

= I think it is a central point of discussion. Regarding the usage of = Diameter in 3GPP environment which is my concern, as Laurent,  I consider that the client  at the source of Diamet= er requests  (so not an intermediate DA) has to be involved in an over= load situation, not only to reduce the traffic as such but on the way it wi= ll do it. Quite often in a 3GGP case, the involved Diameter  client will have to trigger some behavior towards the mobil= e terminals . Whatever the way overload handling  is implemented in th= e client and the role of the Diameter stack , the triggering of UE behavior= will be at the application level, which then has to be aware of the overload situation (so the above additional stateme= nt in REQ2).

= A second point behind this statement, is that, if requested, the ove= rload information must be propagated up to the Diameter client for an accurate handling  and not to be stopped by an= intermediate agent who considers it handles the overload by itself  a= nd does not need to propagate the overload information  upstream.=

=  

= I don’t say that it is systematic and in 3GPP it will depend o= f the application case, it is why we write “must allow”.

=  

=  

= Best regards

=  

= JJacques

 

De := dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de THIEBAUT, LAURENT (LAURENT)
Envoy=E9 : jeudi 24 jan= vier 2013 16:27
=C0 : dime@ietf.org
Objet : Re: [Dime] draf= t-ietf-dime-overload-reqs-03: REQ 2

 

 

 

Hello all

Please find below our remarks on draft draft-ietf-dime-o= verload-reqs-03 about Diameter Overload Control Requirements

 

These remarks address topics we have already addressed o= ver Dime but for which we think some enhancements to the text is needed.

We hope to converge quickly as we believe that based on = these small enhancements draft-ietf-dime-overload-reqs-03 should be finalized ASAP and moved forwar= d into the IETF standardization process.

 

1.    REQ 2:&nb= sp;  The mechanism MUST allow Diameter nodes to support overload

            con= trol regardless of which Diameter applications they

            sup= port. The mechanism MUST allow Diameter applica= tions

to be aware of an overload situation.

We believe that a proper handling of a Diameter server o= verload is to report it at the level of its Diameter client applications in order for them to take= proper decisions. This may mean to send signalling towards non Diameter en= tities.

This may relate with the comment made by Hannes.

 

 

 

2.       We recommend to add following requirement:

REQ xx:  The overload control mechanism MUST allow netw= orks to properly support Diameter signalling related with emergency and/or = priority users.

This aspect is mentioned in Req 26 but only as a general guidance whil= e this is a strong operational requirement.

“For example, it may be more beneficial to process mes= sages for

            exi= sting sessions ahead of new sessions, or to give priority

            to = requests associated with emergency sessions or with high

            priority users.”

 

 

 

 

3.    REQ 35:&n= bsp; The mechanism SHOULD provide a method for exchan= ging

            ove= rload and load information between elements that are

            con= nected by intermediaries that do not support the

            mec= hanism.

We recommend to replace “The mechanism SHOULD provide a method” by “The mechanism MUST provide a method”  as it is a key r= equirement for deployments especially via intermediate networks.

&nbs= p;

 

 

 

 

4.       We recommend to add following requirement

REQ yy:  The mechanism MUST support a default overload = algorithm. This will facilitate interoperability especially between Network= s.<= /span>

 

 

 

 

5.    REQ 33:&n= bsp; There are multiple situations where a Diameter node may be

            ove= rloaded for some purposes but not others.  For example,<= font size=3D"2" face=3D"Courier New">

            thi= s can happen to an agent or server that supports multiple

            app= lications, or when a server depends on multiple external

            res= ources, some of which may become overloaded while others

            are= fully available.  The mechanism MUST allow Diameter

            nod= es to indicate overload with sufficient granularity to

            all= ow clients to take action based on the overloaded

            res= ources without forcing available capacity to go unused.

            The= mechanism MUST support specification of overload

            inf= ormation with granularities of at least "Diameter node",

            &qu= ot;realm", "Diameter application", and "Diameter session", and

            SHOULD allow extensibility for oth= ers to be added in the<= span lang=3D"EN-GB" style=3D"font-size:10.0pt;font-family:"Courier New= "">

            fut= ure.

a.       We recommend to replace “SHOULD allow extensibility= ” by “MUST all= ow extensibility&= #8221; .

b.       We are not sure that the granularity at Diameter session is really required and su= ggest to remove it from this Req 33.

 

 

Best Regards

Laurent
ALCATEL-LUCENT

 

 

--_000_E194C2E18676714DACA9C3A2516265D201074CEEFR712WXCHMBA10z_-- From ben@nostrum.com Thu Mar 7 13:36:10 2013 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 569A821F8AF2 for ; Thu, 7 Mar 2013 13:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk9sqbgW1Xo2 for ; Thu, 7 Mar 2013 13:36:09 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0070921F85FE for ; Thu, 7 Mar 2013 13:36:08 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r27La635087917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Mar 2013 15:36:06 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_07F925DA-934C-490C-B52B-1E33AA5336D4" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Thu, 7 Mar 2013 15:36:09 -0600 Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2013 21:36:10 -0000 --Apple-Mail=_07F925DA-934C-490C-B52B-1E33AA5336D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jean-Jacques, please see comments inline: On Mar 7, 2013, at 5:57 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi all > =20 > I am coming back to the REQ2 discussion we had a few weeks ago and for = which there is no yet consensus. > In parallel, in the context of the 3GPP work about Diameter overload, = there was an email thread on this REQ2 topic. I reformulate here my = last comment which I did in this 3GPP discussion and which is in the = continuity of the comments Laurent and I did in Jan 24th and Feb 8th = hereafterr mails so that DIME List may express their views, in = particular for the Orlando IETF meeting. > =20 > 1. REQ2 currently only says =93The mechanism MUST allow = Diameter nodes to support overload control regardless of which Diameter = applications they support=94. The word Regardless is ambiguous. An = interpretation is to understand it as =93independent of=94 the Diameter = applications, meaning Diameter application are not involved in the = overload control. This statement may be valid for some Diameter = applications (it is why there is the word =93allow=94), but there are = other cases, especially in 3GPP environment, where other Diameter = applications must be aware of the overload situation, especially when = the nodes support a large amount of UEs towards which they have to = accurately drive the UE behaviour in overload situations. > It is why it is proposed to add =93The mechanism MUST allow Diameter = clients to be aware of an overload situation=94. > If we have not this statement in REQ2, there is no REQ to which we = can refer to support these essential 3GPP cases, as the current REQ2 = cannot apply. The current REQ 2 is here incomplete and I think it is not = acceptable in its current writing. I think some of the issue so far has been in the definition of = "Application". The requirements draft uses the term "Diameter = Application" to refer to the collection of commands and semantics = defined by an application ID, and that can be negotiated during the = capabilities exchange phase of a connection. I don't think that's quite = the same sense that you have in mind--I gather you are thinking in more = of a software architecture/layering sense. We didn't intend the = requirement to assume anything about software architecture and = implementation. Would it make more sense if the requirement said something along the = lines of "... regardless of which Application IDs they support?" As far as the need for the requirement about clients being aware of = overload--I think it makes more sense to state that in terms of the = needed results. What about something to the effect of: "Diameter clients must be able to receive sufficient information to = support graceful behavior in their client applications during an = overload condition"? =20 By "client application", I mean the thing the client does that needs = Diameter in the first place--in your example, it's the "driving UE = behavior" part. (I'm open to suggestions for better words than "client = application") > =20 > 2. Besides the case of a DA supporting topology hiding, there = are other cases that must be supported > a) the mechanism must work with a network where there is no = intermediate DA (as described in the overload scenarios of the IEFT = draft) and here it is the end Diameter node that will receive the = overload info, and as a client has to handle this overload situation (cf = point1) > =20 Agreed. I don't think we ever intended to accept a solution that = _required_ agents. So what if we add a requirement to the effect of: The solution MUST work in the absence of intervening Diameter agents. > b) Similar to the above there is the case of networks with = intermediate DAs with limited functions (eg for routing purposes and = without topology hiding) and which are not upgraded for overload = support. Here also the mechanism must support this case, overload being = handled (as in a) above) between server and clients as no identified = differences. If this case is excluded, it imposes a high constraint to = the operator to have all the DAs to support the mechanism. This case, = for me, is not excluded of the draft and relies on the REQ 35 that = applies. But as this deployment case must be supported, it means that = the mechanism must work when intermediate nodes are not supporting = overload control. It is why we have proposed REQ35 to be with a MUST = instead of a SHOULD (as Lauret wrote in his Jan 24th mail. There have been arguments on both sides of whether 35 should be a MUST = or a SHOULD. I think those leaning towards a SHOULD are thinking that = this may be hard problem to solve in the general case. Putting a SHOULD = there would create a preference for a solution that did solve this, vs a = solution that did not, everything else being equal. I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and = significant requirements for information sharing and among servers = upstream of the agent (e.g. any server may be required to speak for all = servers.)=20 We may also find that a different mechanism is required to bypass an = agent than would normally be used if the agent actually supported = overload control. For example, negotiating support between non-adjacent = nodes may be tricky given existing (and proposed) negotiation = mechanisms. I hope to discuss this as an open issue in Orlando. > =20 > 3. about the hiding topology DA case, such a DA plus the hidden = servers behind will appear as a =93global server=94 to the clients. In = this case the DA will have to support the mechanism in order to define = if the =93global server=94 is overloaded and if yes to generate the = overload information associated to this =93global server=94 and transmit = it to the clients which then may act according to point 1) . So the DA = case with topology hiding is quite compatible with the point 1 and with = the proposed requirement =93The mechanism MUST allow Diameter clients to = be aware of an overload situation =93 My comment to number 2 probably also needs the following for the sake of = completeness: The solution MUST work in the presence of one or more intervening = Diameter Agents, including those that hide the upstream network = topology. Please see my comment to 1 concerning the "MUST allow Diameter = Clients..." part. Also, keep in mind the downstream peer of this "global = server" may also be an agent. [...] Thanks! Ben. --Apple-Mail=_07F925DA-934C-490C-B52B-1E33AA5336D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Jean-Jacques, please = see comments inline:


On Mar 7, 2013, at 5:57 AM, = "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trott= in@alcatel-lucent.com> wrote:

Hi = all
 
I am coming back to the REQ2 discussion we had a few = weeks ago and for which there is no yet consensus.
 In parallel, = in the context of the 3GPP work about Diameter overload, there was an = email thread on this REQ2 topic.  I reformulate here my last = comment which I did in this 3GPP discussion and   which is in the = continuity of the comments Laurent and I did  in  Jan = 24th and Feb 8th  hereafterr mails so that DIME List may = express their views,  in particular for the Orlando IETF = meeting.
 
1.         REQ2 = currently only says =93The mechanism MUST allow Diameter nodes to = support overload control regardless of which Diameter applications = they support=94. The word Regardless is ambiguous. An interpretation is = to understand it as =93independent of=94 the Diameter = applications, meaning Diameter application are not involved in the = overload control. This statement may be valid for some Diameter = applications (it is why there is the word =93allow=94),   but there = are other cases, especially in 3GPP environment, where other = Diameter applications must be aware of the overload situation, = especially when the nodes support  a large amount of UEs =  towards which they have to accurately drive the UE behaviour in = overload situations.
It is why it is proposed to add =93The = mechanism MUST allow Diameter clients to be aware of an overload = situation=94.
 If we have not this statement in REQ2, there is = no REQ to which we can refer to support these essential 3GPP cases, = as the current REQ2 cannot apply. The current REQ 2 is here = incomplete and I think it is not acceptable in its current = writing.

I think some of the issue = so far has been in the definition of "Application". The requirements = draft uses the term "Diameter Application" to refer to the = collection of commands and semantics defined by an application ID, and = that can be negotiated during the capabilities exchange phase of a = connection. I don't think that's quite the same sense that you have in = mind--I gather you are thinking in more of a software = architecture/layering sense. We didn't intend the requirement to assume = anything about software architecture and implementation.

Would it = make more sense if the requirement said something along the lines of = "... regardless of which Application IDs they = support?"

As far as the need for the = requirement about clients being aware of overload--I think it makes more = sense to state that in terms of the needed results. What about something = to the effect of:

"Diameter clients must be able = to receive sufficient information to support graceful behavior in their = client applications during an overload condition"? =  

By "client application", I = mean the thing the client  does that needs Diameter in the first = place--in your example, it's the "driving UE behavior" part. (I'm open = to suggestions for better words than "client = application")

 
2.  =      Besides the case of a  DA supporting = topology hiding, there are other cases that must be = supported
a)       the mechanism must work = with a network where there is no intermediate DA (as described in the = overload scenarios of the IEFT draft) and here  it is the =  end Diameter node that will receive the overload info, and as a = client has to handle this overload situation (cf = point1)
 

Agreed. I don't = think we ever intended to accept a solution that _required_ agents. So = what if we add a requirement to the effect = of:

The solution MUST work in the absence = of intervening Diameter agents.

b)       Similar to the above = there is the case of networks with intermediate DAs with limited = functions  (eg for routing purposes and without topology = hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) = above) between server and clients as no identified differences. If this = case is excluded, it imposes a high constraint to the operator to = have all the DAs to support the mechanism. This case, for me, is = not excluded of the draft and relies on the REQ 35 that applies. But as = this deployment case must be supported, it means that the mechanism = must work when intermediate nodes are not supporting overload control. = It is why we have proposed REQ35 to be with a MUST instead of a = SHOULD (as Lauret wrote in his Jan 24th =  mail.

There have been = arguments on both sides of whether 35 should be a MUST or a SHOULD. I = think those leaning towards a SHOULD are thinking that this may be hard = problem to solve in the general case. Putting a SHOULD there would = create a preference for a solution that did solve this, vs a solution = that did not, everything else being equal.

I = think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and = significant requirements for information sharing and among servers = upstream of the agent (e.g. any server may be required to speak for all = servers.) 

We may also find that a = different mechanism is required to bypass an agent than would normally = be used if the agent actually supported overload control. For example, = negotiating support between non-adjacent nodes may be tricky given = existing (and proposed) negotiation = mechanisms.

I hope to discuss this as an open = issue in Orlando.


 
3.       about the = hiding topology DA case, such a DA plus the hidden servers behind will = appear as a =93global server=94 to the clients. In this case the DA = will have to support the mechanism in order to define if the =93global = server=94 is overloaded and if yes to generate   the overload = information associated to this =93global server=94 and transmit it to = the clients which then may act according to point 1) . So the DA = case with topology hiding is quite compatible with the point  1 and = with the proposed requirement =93The mechanism MUST allow Diameter = clients to be aware of an overload situation = =93

My comment to number 2 probably also = needs the following for the sake of = completeness:

The solution MUST work in the = presence of one or more intervening Diameter Agents, including those = that hide the upstream network = topology.

Please see my comment to 1 = concerning the "MUST allow Diameter Clients..." part. Also, keep in mind = the downstream peer of this "global server" may also be an = agent.

[...]

Thanks!

Ben.


<= /html>= --Apple-Mail=_07F925DA-934C-490C-B52B-1E33AA5336D4-- From jounikor@gmail.com Sun Mar 10 09:30:40 2013 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 AFA8A21F8824 for ; Sun, 10 Mar 2013 09:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-1.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hae+jJN1DKtB for ; Sun, 10 Mar 2013 09:30:40 -0700 (PDT) Received: from mail-da0-x229.google.com (mail-da0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC0221F8826 for ; Sun, 10 Mar 2013 09:30:40 -0700 (PDT) Received: by mail-da0-f41.google.com with SMTP id j17so565115dan.14 for ; Sun, 10 Mar 2013 09:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=g1pK6AJfBy/yuRw+NlW3zi0Cj/sYQSaakVPT/TlVyaM=; b=LPXr01PqTGSWTr6QFbh3+/9B5h9X5wHF5l/vGTJ5ZS1NMoQo2cUuQI0BYnwnyOZ00w ydf3qUX9vFvpYwti2457o1qCFg9wi6bBcrZ5DUIHUnnZXkDbDifZzesirZ0YLgSOJ1yK xhokHmW/yIAaJJXBv2QgtUZGUdgl7as9NC6doKyRx1GYsgwyYfYPtNymLL/HkAvKc8i4 SAGTua8yYz5cTCRqhPjyL0vrUdIwXFXrQ7yUc2lQGFTkOMP/Yqj7hPd08563al1NMvvZ qv9oPAA988t/ifp2zl6LQROiDnrQ/qqqOSmdl1cVZu2JJ9LnqWdn221F+kh1ApwSVMyG yZHQ== X-Received: by 10.68.4.97 with SMTP id j1mr20872582pbj.157.1362933039995; Sun, 10 Mar 2013 09:30:39 -0700 (PDT) Received: from [130.129.134.193] ([130.129.134.193]) by mx.google.com with ESMTPS id is1sm16061368pbc.15.2013.03.10.09.30.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Mar 2013 09:30:39 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <17AE7DE6-BBC1-47BD-AD4F-576A6ABD8831@gmail.com> Date: Sun, 10 Mar 2013 18:30:44 +0200 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sun, 10 Mar 2013 09:31:18 -0700 Subject: [Dime] Presentation slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 16:30:40 -0000 Folks, Those with an agenda slot please send your slides to the chairs by Tuesday noon. From tom.taylor.stds@gmail.com Sun Mar 10 18:57:47 2013 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 460FD21F87BB for ; Sun, 10 Mar 2013 18:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRs99aguPnKO for ; Sun, 10 Mar 2013 18:57:46 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 888D221F8794 for ; Sun, 10 Mar 2013 18:57:46 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo15so3151712pbc.33 for ; Sun, 10 Mar 2013 18:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CypJZQCzburRM/wdm6FOfh/hS1o6mHcgiHWDPJJ6wLE=; b=n0vzM0Obaavx4waYsqZMObQJmGcI3D6Ga3QaBRbOxaWoztiM6B31cLNzvmh1bzHTnJ Q9/51othoJ47dcHZBKhs8B+gXIOzjOM6x6ng8RUPCL09bosyC/1FKjFGHtHAkOyOZY5F 5WmPXy3qAsgZ8xAEYcbVoWuw8g+wiT30Ov4aUx31CyR2F1v3TqaO6PVTkdPuq0jfAW3Y wP+Vwthy+kX7sz0ASnNspQgcLx/X9VT0a0dIOkdkoc+noN9jYG/KXCyJAg4erOnbokXr RImG9HCCwMvvtqgmItzzu6s3MQfqAabrSfSNx7dex+ewrIK4Sf/SOHQYXMOq+eVrBcXP Xv5w== MIME-Version: 1.0 X-Received: by 10.68.11.135 with SMTP id q7mr23821109pbb.5.1362967065994; Sun, 10 Mar 2013 18:57:45 -0700 (PDT) Received: by 10.68.158.44 with HTTP; Sun, 10 Mar 2013 18:57:45 -0700 (PDT) In-Reply-To: <20130311014504.23752.5927.idtracker@ietfa.amsl.com> References: <20130311014504.23752.5927.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 21:57:45 -0400 Message-ID: From: Tom Taylor To: dime@ietf.org Content-Type: multipart/alternative; boundary=bcaec5314799d0297504d79c7f7f Cc: cathy.zhou.zhouqian@huawei.com Subject: Re: [Dime] New Version Notification for draft-zhou-dime-4over6-provisioning-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 01:57:47 -0000 --bcaec5314799d0297504d79c7f7f Content-Type: text/plain; charset=ISO-8859-1 We have submitted this draft to Softwires, but it defines AVPs for provisioning using Diameter. Comments welcome. Tom Taylor and Cathy Zhou On Sun, Mar 10, 2013 at 9:45 PM, wrote: > > A new version of I-D, draft-zhou-dime-4over6-provisioning-00.txt > has been successfully submitted by T. Taylor and posted to the > IETF repository. > > Filename: draft-zhou-dime-4over6-provisioning > Revision: 00 > Title: Attribute-Value Pairs For Provisioning Customer Equipment > Supporting IPv4-Over-IPv6 Transitional Solutions > Creation date: 2013-03-11 > Group: Individual Submission > Number of pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-00.txt > Status: > http://datatracker.ietf.org/doc/draft-zhou-dime-4over6-provisioning > Htmlized: > http://tools.ietf.org/html/draft-zhou-dime-4over6-provisioning-00 > > > Abstract: > During the transition from IPv4 to IPv6, customer equipment may have > to support one of the various transition methods that have been or > are currently being defined for carrying IPv4 packets over IPv6. > Work is currently in progress to enumerate the information that needs > to be provisioned on a customer edge router to support a list of > transition techniques based on tunneling IPv4 in IPv6, with a view to > defining reusable components for a reasonable transition path between > these techniques. To the extent that the provisioning is done > dynamically, AAA support is needed to provide the information to the > network server responsible for passing the information to the > customer equipment. This document specifies Diameter attribute-value > pairs to be used for that purpose. > > > > > The IETF Secretariat > > --bcaec5314799d0297504d79c7f7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We have submitted this draft to Softwires, but it defines AVPs for provisio= ning using Diameter. Comments welcome.

Tom Taylor and Cathy Zhou
=
On Sun, Mar 10, 2013 at 9:45 PM, <= internet-drafts@ietf.org> wrote:

A new version of I-D, draft-zhou-dime-4over6-provisioning-00.txt
has been successfully submitted by T. Taylor and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-zhou-dime-4over6-provisioning
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Attribute-Value Pairs For Provisioning Customer = Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
Creation date: =A0 2013-03-11
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 11
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-zhou-dime-4over6-provisioning
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-zhou-dime-4over6-provisioning-00


Abstract:
=A0 =A0During the transition from IPv4 to IPv6, customer equipment may have=
=A0 =A0to support one of the various transition methods that have been or =A0 =A0are currently being defined for carrying IPv4 packets over IPv6.
=A0 =A0Work is currently in progress to enumerate the information that need= s
=A0 =A0to be provisioned on a customer edge router to support a list of
=A0 =A0transition techniques based on tunneling IPv4 in IPv6, with a view t= o
=A0 =A0defining reusable components for a reasonable transition path betwee= n
=A0 =A0these techniques. =A0To the extent that the provisioning is done
=A0 =A0dynamically, AAA support is needed to provide the information to the=
=A0 =A0network server responsible for passing the information to the
=A0 =A0customer equipment. =A0This document specifies Diameter attribute-va= lue
=A0 =A0pairs to be used for that purpose.




The IETF Secretariat


--bcaec5314799d0297504d79c7f7f-- From ben@nostrum.com Mon Mar 11 07:49:14 2013 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 243FB21F8615 for ; Mon, 11 Mar 2013 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-ZWJ8h0KJ+U for ; Mon, 11 Mar 2013 07:49:13 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8322C21F8546 for ; Mon, 11 Mar 2013 07:49:13 -0700 (PDT) Received: from [10.119.74.122] (65-111-169-199.op-net.com [65.111.169.199] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2BEmx12003698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Mar 2013 09:49:00 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <2D2C8749-2777-49C2-B41E-D82C2B2BE8EC@gmail.com> Date: Mon, 11 Mar 2013 15:48:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BF787ED-E249-4A81-BAF3-B96021D3FF73@nostrum.com> References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> <2D2C8749-2777-49C2-B41E-D82C2B2BE8EC@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 65.111.169.199 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 14:49:14 -0000 (Sorry for the late response--I just found Jouni's message when going = back over threads to prep for the Orlando meeting) HI Jouni, do you have any suggestions on how to improve it? I don't usually think of "throughput" as indicating bandwith or bps. I = think of it in terms of completed transactions, although I think both = measures would qualify. Other areas have used the word "goodput" when discussing overload and = congestions. I gather the intent is to distinguish between "attempted = work" and "successful work". I personally find that usage awkward and = unnecessary. On Feb 21, 2013, at 11:14 PM, Jouni Korhonen = wrote: > >=20 >=20 > I would still argue that "..the mechanism MUST enable throughput.." > could use some rewording. The load in the network might not be about > 'throughput' as in bps but for example about transactions. >=20 > - Jouni >=20 >=20 > On Feb 20, 2013, at 9:38 PM, Eric McMurry = wrote: >=20 >> Req 7 reads: The overload control mechanism and any associated = default >> algorithm(s) MUST ensure that the system remains stable. >> When the offered load drops from above the overall capacity >> of the network to below the overall capacity, the = throughput >> MUST stabilize and become equal to the offered load. Note >> that this also requires that the mechanism MUST allow nodes >> to shed load without introducing oscillations. >>=20 >>=20 >> It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: >>=20 >>=20 >> The overload control mechanism and any associated default >> algorithm(s) MUST ensure that the system remains stable. >> When the offered load drops from above the overall capacity >> of the network to below the overall capacity, the mechanism >> MUST enable throughput to stabilize and become >> equal to the offered load. Note >> that this also requires that the mechanism MUST allow nodes >> to shed load without introducing oscillations. >>=20 >>=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >> _______________________________________________ >> 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 From lionel.morand@orange.com Mon Mar 11 08:58:04 2013 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 BD3CF21F88A2 for ; Mon, 11 Mar 2013 08:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrnUTVzctnGA for ; Mon, 11 Mar 2013 08:57:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D5C2821F8831 for ; Mon, 11 Mar 2013 08:57:57 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D09BB18CAE5 for ; Mon, 11 Mar 2013 16:57:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BB98B4C017 for ; Mon, 11 Mar 2013 16:57:56 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 16:57:56 +0100 From: To: Ben Campbell , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItA= Date: Mon, 11 Mar 2013 15:57:55 +0000 Message-ID: <31620_1363017476_513DFF04_31620_692_1_6B7134B31289DC4FAF731D844122B36E15D21B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pmx-version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.11.150322 x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E15D21BPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 15:58:04 -0000 --_000_6B7134B31289DC4FAF731D844122B36E15D21BPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, For this discussion, it might be useful to refer to the definition given in= the RFC6733: Diameter Client A Diameter client is a Diameter node that supports Diameter client applications as well as the base protocol. Diameter clients are often implemented in devices situated at the edge of a network and provide access control services for that network. Typical examples of Diameter clients include the Network Access Server (NAS) and the Mobile IP Foreign Agent (FA). Proxy Agent or Proxy In addition to forwarding requests and responses, proxies make policy decisions relating to resource usage and provisioning. Typically, this is accomplished by tracking the state of NAS devices. While proxies usually do not respond to client requests prior to receiving a response from the server, they may originate Reject messages in cases where policies are violated. As a result, proxies need to understand the semantics of the messages passing through them, and they may not support all Diameter applications. For further comments, please see below. Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounc= es@ietf.org] De la part de Ben Campb= ell Envoy=E9 : jeudi 7 mars 2013 22:36 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc : DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nige= l (Nigel); Bessis, Thierry (Thierry) Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Jean-Jacques, please see comments inline: On Mar 7, 2013, at 5:57 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > wrote: Hi all I am coming back to the REQ2 discussion we had a few weeks ago and for whic= h there is no yet consensus. In parallel, in the context of the 3GPP work about Diameter overload, ther= e was an email thread on this REQ2 topic. I reformulate here my last comme= nt which I did in this 3GPP discussion and which is in the continuity of = the comments Laurent and I did in Jan 24th and Feb 8th hereafterr mails = so that DIME List may express their views, in particular for the Orlando I= ETF meeting. 1. REQ2 currently only says "The mechanism MUST allow Diameter node= s to support overload control regardless of which Diameter applications the= y support". The word Regardless is ambiguous. An interpretation is to under= stand it as "independent of" the Diameter applications, meaning Diameter ap= plication are not involved in the overload control. This statement may be v= alid for some Diameter applications (it is why there is the word "allow"), = but there are other cases, especially in 3GPP environment, where other Di= ameter applications must be aware of the overload situation, especially whe= n the nodes support a large amount of UEs towards which they have to accu= rately drive the UE behaviour in overload situations. It is why it is proposed to add "The mechanism MUST allow Diameter clients = to be aware of an overload situation". If we have not this statement in REQ2, there is no REQ to which we can ref= er to support these essential 3GPP cases, as the current REQ2 cannot apply.= The current REQ 2 is here incomplete and I think it is not acceptable in i= ts current writing. I think some of the issue so far has been in the definition of "Application= ". The requirements draft uses the term "Diameter Application" to refer to = the collection of commands and semantics defined by an application ID, and = that can be negotiated during the capabilities exchange phase of a connecti= on. I don't think that's quite the same sense that you have in mind--I gath= er you are thinking in more of a software architecture/layering sense. We d= idn't intend the requirement to assume anything about software architecture= and implementation. Would it make more sense if the requirement said something along the lines = of "... regardless of which Application IDs they support?" As far as the need for the requirement about clients being aware of overloa= d--I think it makes more sense to state that in terms of the needed results= . What about something to the effect of: "Diameter clients must be able to receive sufficient information to supp= ort graceful behavior in their client applications during an overload condi= tion"? By "client application", I mean the thing the client does that needs Di= ameter in the first place--in your example, it's the "driving UE behavior" = part. (I'm open to suggestions for better words than "client application") [LM] referring to the definition given above, the second "client applica= tion" seems redundant. The text could simply be: "Diameter clients must be able to receive sufficient information to supp= ort graceful behavior during an overload condition" 2. Besides the case of a DA supporting topology hiding, there are= other cases that must be supported a) the mechanism must work with a network where there is no interm= ediate DA (as described in the overload scenarios of the IEFT draft) and he= re it is the end Diameter node that will receive the overload info, and a= s a client has to handle this overload situation (cf point1) Agreed. I don't think we ever intended to accept a solution that _requir= ed_ agents. So what if we add a requirement to the effect of: The solution MUST work in the absence of intervening Diameter agents. [LM] we could have something even more generic using: "The solution MUST= work in the presence or absence of Diameter agents between Diameter client= s and servers". b) Similar to the above there is the case of networks with interme= diate DAs with limited functions (eg for routing purposes and without topo= logy hiding) and which are not upgraded for overload support. Here also the= mechanism must support this case, overload being handled (as in a) above) = between server and clients as no identified differences. If this case is ex= cluded, it imposes a high constraint to the operator to have all the DAs to= support the mechanism. This case, for me, is not excluded of the draft and= relies on the REQ 35 that applies. But as this deployment case must be sup= ported, it means that the mechanism must work when intermediate nodes are n= ot supporting overload control. It is why we have proposed REQ35 to be with= a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. There have been arguments on both sides of whether 35 should be a MUST o= r a SHOULD. I think those leaning towards a SHOULD are thinking that this m= ay be hard problem to solve in the general case. Putting a SHOULD there wou= ld create a preference for a solution that did solve this, vs a solution th= at did not, everything else being equal. I think I would be willing to accept a MUST there, if we understand that= there may be significant limitations in how much an agent can do and signi= ficant requirements for information sharing and among servers upstream of t= he agent (e.g. any server may be required to speak for all servers.) [LM] I also see the "SHOULD" in REQ35 as a strong indication for solutio= n designers that the preference will be given to the solution that would pr= ovide this feature, not as an absolute constraint. We may also find that a different mechanism is required to bypass an age= nt than would normally be used if the agent actually supported overload con= trol. For example, negotiating support between non-adjacent nodes may be tr= icky given existing (and proposed) negotiation mechanisms. I hope to discuss this as an open issue in Orlando. 3. about the hiding topology DA case, such a DA plus the hidden se= rvers behind will appear as a "global server" to the clients. In this case = the DA will have to support the mechanism in order to define if the "global= server" is overloaded and if yes to generate the overload information as= sociated to this "global server" and transmit it to the clients which then = may act according to point 1) . So the DA case with topology hiding is quit= e compatible with the point 1 and with the proposed requirement "The mecha= nism MUST allow Diameter clients to be aware of an overload situation " My comment to number 2 probably also needs the following for the sake of= completeness: The solution MUST work in the presence of one or more intervening Diamet= er Agents, including those that hide the upstream network topology. [LM] i think that my proposal in comment 2 covers this text, saying that= the part referring explicitly to network topology hiding is not deemed re= quired (as a proxy can do whatever, and topology hiding is only one example= of possible functions provided by the proxy. Please see my comment to 1 concerning the "MUST allow Diameter Clients..= ." part. Also, keep in mind the downstream peer of this "global server" may= also be an agent. [...] Thanks! Ben. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E15D21BPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <60AAE90F18D7684DB5641AF7C7E828E7@adroot.infra.ftgroup> Content-Transfer-Encoding: quoted-printable

Hi,

 

For this discussion, it might be useful to refer to the defi= nition given in the RFC6733:

 =

   Diameter Client

 

      A Diameter c= lient is a Diameter node that supports Diameter client

      applications= as well as the base protocol.  Diameter clients are=

      often implem= ented in devices situated at the edge of a network and

      provide acce= ss control services for that network.  Typical

      examples of = Diameter clients include the Network Access Server

      (NAS) and th= e Mobile IP Foreign Agent (FA).

 = 

   Proxy Agent or Proxy
 
      In addition to for=
warding requests and responses, proxies make
      policy decisions r=
elating to resource usage and provisioning.
      Typically, this is=
 accomplished by tracking the state of NAS
      devices.  Whi=
le proxies usually do not respond to client requests
      prior to receiving=
 a response from the server, they may originate
      Reject messages in=
 cases where policies are violated.  As a
      result, proxies ne=
ed to understand the semantics of the messages
      passing through th=
em, and they may not support all Diameter
      applications.=

 

For further comments, please see below.

 

Regards,

 

Lionel

 

De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoy=E9 : jeudi 7 mars 2013 22:36
=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc : DRAGE, Keith (Keith); dim= e@ietf.org; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2=

 

Hi Jean-Jacques, please see comments inline:

 


On Mar 7, 2013, at 5:57 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"= ; <jean-jacqu= es.trottin@alcatel-lucent.com> wrote:

Hi all
 
I am coming back to the REQ2 discussion we had a few weeks ago and for whic= h there is no yet consensus.
 In parallel, in the context of the 3GPP work about Diameter overload,= there was an email thread on this REQ2 topic.  I reformulate her= e my last comment which I did in this 3GPP discussion and   which is i= n the continuity of the comments Laurent and I did  in  Jan 24th and Feb 8th  hereafterr mails so that DIME L= ist may express their views,  in particular for the Orlando IETF = meeting.
 
1.         REQ2 currently only says R= 20;The mechanism MUST allow Diameter nodes to support overload control rega= rdless of which Diameter applications they support”. The word Re= gardless is ambiguous. An interpretation is to understand it as “= ;independent of” the Diameter applications, meaning Diameter application are not involved in th= e overload control. This statement may be valid for some Diameter appl= ications (it is why there is the word “allow”),   but ther= e are other cases, especially in 3GPP environment, where other Diameter applications must be aware of the overload situation, espec= ially when the nodes support  a large amount of UEs  towards= which they have to accurately drive the UE behaviour in overload situ= ations.
It is why it is proposed to add “The mechanism MUST allow Diameter cl= ients to be aware of an overload situation”.
 If we have not this statement in REQ2, there is no REQ to which we ca= n refer to support these essential 3GPP cases, as the current REQ2 can= not apply. The current REQ 2 is here incomplete and I think it is not accep= table in its current writing.

 

I think some of the issue so far has been in the def= inition of "Application". The requirements draft uses the term &q= uot;Diameter Application" to refer to the collection of commands = and semantics defined by an application ID, and that can be negotiated during the capabilities exchange phase of a connection. I = don't think that's quite the same sense that you have in mind--I gather you= are thinking in more of a software architecture/layering sense. We di= dn't intend the requirement to assume anything about software architecture and implementation.

Would it make more sense if the requirement said something along the lines = of "... regardless of which Application IDs they support?"

 

As far as the need for the requirement about clients= being aware of overload--I think it makes more sense to state that in term= s of the needed results. What about something to the effect of:<= /p>

 

"Diameter clients must be able to receive suffi= cient information to support graceful behavior in their client applications= during an overload condition"?  

 

By "client application", I mean the thing = the client  does that needs Diameter in the first place--in your examp= le, it's the "driving UE behavior" part. (I'm open to suggestions= for better words than "client application")

 

[LM] referring to= the definition given above, the second "client application" seem= s redundant. The text could simply be:

 =

"Diameter clients must be able to receive s= ufficient information to support graceful behavior during an overload condition"

 
2.       Besides the case of a  DA sup= porting topology hiding, there are other cases that must be supported
a)       the mechanism must work with a network wh= ere there is no intermediate DA (as described in the overload scenarios of&= nbsp;the IEFT draft) and here  it is the  end Diameter node that = will receive the overload info, and as a client has to handle this ove= rload situation (cf point1)
 

 

Agreed. I don't think we ever intended to accept a s= olution that _required_ agents. So what if we add a requirement to the effe= ct of:

 

The solution MUST work in the absence of intervening= Diameter agents.

 

[LM] we could hav= e something even more generic using: "The solution MUST work in the pr= esence or absence of Diameter agents between Diameter clients and servers".

=  

b)       Similar to the abo= ve there is the case of networks with intermediate DAs with limited functio= ns  (eg for routing purposes and without topology hiding) and whi= ch are not upgraded for overload support. Here also the mechanism must support this case, overload being handled (as in a) above) between se= rver and clients as no identified differences. If this case is exclude= d, it imposes a high constraint to the operator to have all the DAs to supp= ort the mechanism. This case, for me, is not excluded of the draft and relies on the REQ 35 that applies. But as this d= eployment case must be supported, it means that the mechanism must wor= k when intermediate nodes are not supporting overload control. It is why we=  have proposed REQ35 to be with a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th  mail.

 

There have been arguments on both sides of whether 3= 5 should be a MUST or a SHOULD. I think those leaning towards a SHOULD are = thinking that this may be hard problem to solve in the general case. Puttin= g a SHOULD there would create a preference for a solution that did solve this, vs a solution that did not, everything= else being equal.

 

I think I would be willing to accept a MUST there, i= f we understand that there may be significant limitations in how much an ag= ent can do and significant requirements for information sharing and among s= ervers upstream of the agent (e.g. any server may be required to speak for all servers.) 

 

[LM] I also see t= he "SHOULD" in REQ35 as a strong indication for solution designer= s that the preference will be given to the solution that would provide this feature, not as an absolute constraint.<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family: "Calibri","sans-serif";color:#1F497D">

 

We may also find that a different mechanism is requi= red to bypass an agent than would normally be used if the agent actually su= pported overload control. For example, negotiating support between non-adja= cent nodes may be tricky given existing (and proposed) negotiation mechanisms.

 

I hope to discuss this as an open issue in Orlando.<= o:p>

 

 

 
3.       about the hiding topology DA case, such a= DA plus the hidden servers behind will appear as a “global server= 221; to the clients. In this case the DA will have to support the mech= anism in order to define if the “global server” is overloaded a= nd if yes to generate   the overload information associated to this “global server= 221; and transmit it to the clients which then may act according to po= int 1) . So the DA case with topology hiding is quite compatible with the p= oint  1 and with the proposed requirement “The mechanism MUST allow Diameter clients to be aware of an overload situation “

 

My comment to number 2 probably also needs the follo= wing for the sake of completeness:

 

The solution MUST work in the presence of one or mor= e intervening Diameter Agents, including those that hide the upstream netwo= rk topology.

 

[LM] i think that= my proposal in comment 2 covers this text, saying that the part referring = explicitly to  network topology hiding is not deemed required (as a proxy can do whatever, and topology hiding is only o= ne example of possible functions provided by the proxy.

 

Please see my comment to 1 conc= erning the "MUST allow Diameter Clients..." part. Also, keep in mind the downstream peer of this "global server&q= uot; may also be an agent.

 

[...]

 

Thanks!

 

Ben.

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for me=
ssages 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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E15D21BPEXCVZYM13corpora_-- From ben@nostrum.com Mon Mar 11 09:46:26 2013 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 D21A911E80A3 for ; Mon, 11 Mar 2013 09:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXRxxQdhY2up for ; Mon, 11 Mar 2013 09:46:26 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D016A21F8B84 for ; Mon, 11 Mar 2013 09:46:25 -0700 (PDT) Received: from [10.0.1.14] (dhcp-431a.meeting.ietf.org [130.129.67.26]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2BGkNBp016922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Mar 2013 11:46:24 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Mon, 11 Mar 2013 12:46:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.67.26 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 16:46:26 -0000 Hi Lionel, Those were the definitions I was trying to use, since we've had some = confusion about scenarios where a proxy looks like a server to a client, = or like a client to a server. While those scenarios are real, the proxy = is still not a server or client according to RFC 6733. More inline: [...] > By "client application", I mean the thing the client does that needs = Diameter in the first place--in your example, it's the "driving UE = behavior" part. (I'm open to suggestions for better words than "client = application") > =20 > [LM] referring to the definition given above, the second "client = application" seems redundant. The text could simply be: > =20 > "Diameter clients must be able to receive sufficient information to = support graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the = "application" that a client uses at the edge of the network for its own = customers, to handle things like network attachments. That is, something = distinct from the "Diameter application". But I agree that the = requirement can stand without it. > =20 > 2. Besides the case of a DA supporting topology hiding, there = are other cases that must be supported > a) the mechanism must work with a network where there is no = intermediate DA (as described in the overload scenarios of the IEFT = draft) and here it is the end Diameter node that will receive the = overload info, and as a client has to handle this overload situation (cf = point1) > =20 > =20 > Agreed. I don't think we ever intended to accept a solution that = _required_ agents. So what if we add a requirement to the effect of: > =20 > The solution MUST work in the absence of intervening Diameter agents. > =20 > [LM] we could have something even more generic using: "The solution = MUST work in the presence or absence of Diameter agents between Diameter = clients and servers". I'm happy to combine it that way. I only separated this to follow the = structure of the original email. >=20 >=20 > b) Similar to the above there is the case of networks with = intermediate DAs with limited functions (eg for routing purposes and = without topology hiding) and which are not upgraded for overload = support. Here also the mechanism must support this case, overload being = handled (as in a) above) between server and clients as no identified = differences. If this case is excluded, it imposes a high constraint to = the operator to have all the DAs to support the mechanism. This case, = for me, is not excluded of the draft and relies on the REQ 35 that = applies. But as this deployment case must be supported, it means that = the mechanism must work when intermediate nodes are not supporting = overload control. It is why we have proposed REQ35 to be with a MUST = instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > =20 > There have been arguments on both sides of whether 35 should be a MUST = or a SHOULD. I think those leaning towards a SHOULD are thinking that = this may be hard problem to solve in the general case. Putting a SHOULD = there would create a preference for a solution that did solve this, vs a = solution that did not, everything else being equal. > =20 > I think I would be willing to accept a MUST there, if we understand = that there may be significant limitations in how much an agent can do = and significant requirements for information sharing and among servers = upstream of the agent (e.g. any server may be required to speak for all = servers.)=20 > =20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for = solution designers that the preference will be given to the solution = that would provide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (=46rom a = practical perspective, the distinction between SHOULD and MUST is = smaller when writing a requirements document than for a protocol = specification. The working group can later discover that a requirement = simply won't work, or is not worth the tradeoffs either way.) > =20 > We may also find that a different mechanism is required to bypass an = agent than would normally be used if the agent actually supported = overload control. For example, negotiating support between non-adjacent = nodes may be tricky given existing (and proposed) negotiation = mechanisms. > =20 > I hope to discuss this as an open issue in Orlando. > =20 I've got it in the in-progress slide deck that I am racing to get to the = chairs :-) >=20 >=20 > =20 > 3. about the hiding topology DA case, such a DA plus the hidden = servers behind will appear as a =93global server=94 to the clients. In = this case the DA will have to support the mechanism in order to define = if the =93global server=94 is overloaded and if yes to generate the = overload information associated to this =93global server=94 and transmit = it to the clients which then may act according to point 1) . So the DA = case with topology hiding is quite compatible with the point 1 and with = the proposed requirement =93The mechanism MUST allow Diameter clients to = be aware of an overload situation =93 > =20 > My comment to number 2 probably also needs the following for the sake = of completeness: > =20 > The solution MUST work in the presence of one or more intervening = Diameter Agents, including those that hide the upstream network = topology. > =20 > [LM] i think that my proposal in comment 2 covers this text, saying = that the part referring explicitly to network topology hiding is not = deemed required (as a proxy can do whatever, and topology hiding is only = one example of possible functions provided by the proxy. I agree in general, although there may be some instances of "whatever" = that OC can't work across--for example, a proxy that deliberately hides = overload information. > =20 > Please see my comment to 1 concerning the "MUST allow Diameter = Clients..." part. Also, keep in mind the downstream peer of this "global = server" may also be an agent. Agreed. I intended to write "one or more agents", but somehow failed to = do so. Thanks! Ben.= From lionel.morand@orange.com Mon Mar 11 10:06:45 2013 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 7C23821F8B84 for ; Mon, 11 Mar 2013 10:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goMVet-6A-JF for ; Mon, 11 Mar 2013 10:06:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7D31A21F8B7D for ; Mon, 11 Mar 2013 10:06:43 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DC7F73B4928; Mon, 11 Mar 2013 18:06:42 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B053F35C055; Mon, 11 Mar 2013 18:06:42 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 18:06:42 +0100 From: To: Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHOHnf26il2AlbS+kqf8eXke2n9UJigs//A Date: Mon, 11 Mar 2013 17:06:42 +0000 Message-ID: <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 17:06:45 -0000 Thank you for this answer. One small comment on (not to open a new thread): "I agree in general, although there may be some instances of "whatever" tha= t OC can't work across--for example, a proxy that deliberately hides overlo= ad information." Proxy means "advertising support of application-id X". So it is up to the d= ocumentation using this application to describe what should do the proxy, "= whatever" the functions provided by this proxy. So it is also up to the app= lication designers to figure out what to do with the proxies in the middle,= and this includes system in which OC will be supported. But the general requirement remains: the solution MUST Work in the presence= or absence of Diameter agents between Diameter clients and servers! :) Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: lundi 11 mars 2013 17:46 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); dime@iet= f.org; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, Those were the definitions I was trying to use, since we've had some confus= ion about scenarios where a proxy looks like a server to a client, or like = a client to a server. While those scenarios are real, the proxy is still no= t a server or client according to RFC 6733. More inline: [...] > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") >=20=20 > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: >=20=20 > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. >=20=20 > 2. Besides the case of a DA supporting topology hiding, there are = other cases that must be supported > a) the mechanism must work with a network where there is no interme= diate DA (as described in the overload scenarios of the IEFT draft) and her= e it is the end Diameter node that will receive the overload info, and as= a client has to handle this overload situation (cf point1) >=20=20 >=20=20 > Agreed. I don't think we ever intended to accept a solution that _require= d_ agents. So what if we add a requirement to the effect of: >=20=20 > The solution MUST work in the absence of intervening Diameter agents. >=20=20 > [LM] we could have something even more generic using: "The solution MUST = work in the presence or absence of Diameter agents between Diameter clients= and servers". I'm happy to combine it that way. I only separated this to follow the struc= ture of the original email. >=20 >=20 > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. >=20=20 > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. >=20=20 > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.)=20 >=20=20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) >=20=20 > We may also find that a different mechanism is required to bypass an agen= t than would normally be used if the agent actually supported overload cont= rol. For example, negotiating support between non-adjacent nodes may be tri= cky given existing (and proposed) negotiation mechanisms. >=20=20 > I hope to discuss this as an open issue in Orlando. >=20=20 I've got it in the in-progress slide deck that I am racing to get to the ch= airs :-) >=20 >=20 >=20=20 > 3. about the hiding topology DA case, such a DA plus the hidden ser= vers behind will appear as a "global server" to the clients. In this case t= he DA will have to support the mechanism in order to define if the "global = server" is overloaded and if yes to generate the overload information ass= ociated to this "global server" and transmit it to the clients which then m= ay act according to point 1) . So the DA case with topology hiding is quite= compatible with the point 1 and with the proposed requirement "The mechan= ism MUST allow Diameter clients to be aware of an overload situation " >=20=20 > My comment to number 2 probably also needs the following for the sake of = completeness: >=20=20 > The solution MUST work in the presence of one or more intervening Diamete= r Agents, including those that hide the upstream network topology. >=20=20 > [LM] i think that my proposal in comment 2 covers this text, saying that = the part referring explicitly to network topology hiding is not deemed req= uired (as a proxy can do whatever, and topology hiding is only one example = of possible functions provided by the proxy. I agree in general, although there may be some instances of "whatever" that= OC can't work across--for example, a proxy that deliberately hides overloa= d information. >=20=20 > Please see my comment to 1 concerning the "MUST allow Diameter Clients...= " part. Also, keep in mind the downstream peer of this "global server" may = also be an agent. Agreed. I intended to write "one or more agents", but somehow failed to do = so. Thanks! Ben. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From emcmurry@computer.org Mon Mar 11 13:20:17 2013 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 E112321F8DDE for ; Mon, 11 Mar 2013 13:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqOyydM-HYy1 for ; Mon, 11 Mar 2013 13:20:16 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8B41B21F8DD5 for ; Mon, 11 Mar 2013 13:20:16 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1UF9Ch-000BsO-Bl; Mon, 11 Mar 2013 20:20:15 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 4F0802370E89; Mon, 11 Mar 2013 15:20:14 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18UqMA2j3dND6HNsNWSDXJDW6svl5I2F2U= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omWvOi08BB_i; Mon, 11 Mar 2013 15:20:14 -0500 (CDT) Received: from [192.168.111.226] (unknown [192.168.111.226]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 907772370E82; Mon, 11 Mar 2013 15:20:13 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <8BF787ED-E249-4A81-BAF3-B96021D3FF73@nostrum.com> Date: Mon, 11 Mar 2013 21:20:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D810BDA-A73E-46D8-AB0E-059A54E2CBDE@computer.org> References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> <2D2C8749-2777-49C2-B41E-D82C2B2BE8EC@gmail.com> <8BF787ED-E249-4A81-BAF3-B96021D3FF73@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 20:20:18 -0000 Hi Ben, That was changed after Jouni's comment. It currently reads: The overload control mechanism and any associated default algorithm(s) MUST ensure that the system remains stable. At some point after an overload condition has ended, the mechanism MUST enable capacity to stabilize and become equal to what it would be in the absence of an overload condition. Note that this also requires that the mechanism MUST allow nodes to shed load without introducing non converging oscillations during or after an overload condition. As far as I know, this version addresses all of the comments it has = received. Does that match what you recall Jouni? Thanks! Eric On Mar 11, 2013, at 15:48 , Ben Campbell wrote: > (Sorry for the late response--I just found Jouni's message when going = back over threads to prep for the Orlando meeting) >=20 > HI Jouni, do you have any suggestions on how to improve it? >=20 > I don't usually think of "throughput" as indicating bandwith or bps. I = think of it in terms of completed transactions, although I think both = measures would qualify. >=20 > Other areas have used the word "goodput" when discussing overload and = congestions. I gather the intent is to distinguish between "attempted = work" and "successful work". I personally find that usage awkward and = unnecessary. >=20 > On Feb 21, 2013, at 11:14 PM, Jouni Korhonen = wrote: >=20 >> >>=20 >>=20 >> I would still argue that "..the mechanism MUST enable throughput.." >> could use some rewording. The load in the network might not be about >> 'throughput' as in bps but for example about transactions. >>=20 >> - Jouni >>=20 >>=20 >> On Feb 20, 2013, at 9:38 PM, Eric McMurry = wrote: >>=20 >>> Req 7 reads: The overload control mechanism and any associated = default >>> algorithm(s) MUST ensure that the system remains stable. >>> When the offered load drops from above the overall capacity >>> of the network to below the overall capacity, the = throughput >>> MUST stabilize and become equal to the offered load. Note >>> that this also requires that the mechanism MUST allow nodes >>> to shed load without introducing oscillations. >>>=20 >>>=20 >>> It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: >>>=20 >>>=20 >>> The overload control mechanism and any associated default >>> algorithm(s) MUST ensure that the system remains stable. >>> When the offered load drops from above the overall capacity >>> of the network to below the overall capacity, the mechanism >>> MUST enable throughput to stabilize and become >>> equal to the offered load. Note >>> that this also requires that the mechanism MUST allow nodes >>> to shed load without introducing oscillations. >>>=20 >>>=20 >>> Thanks, >>>=20 >>> Eric >>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 From internet-drafts@ietf.org Mon Mar 11 14:03:02 2013 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 68BB721F8F8A; Mon, 11 Mar 2013 14:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ8OfZ2btDOT; Mon, 11 Mar 2013 14:03:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEC021F9006; Mon, 11 Mar 2013 14:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130311210259.6598.95643.idtracker@ietfa.amsl.com> Date: Mon, 11 Mar 2013 14:02:59 -0700 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:03:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Support for the EAP Re-authentication Protocol = (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-17.txt Pages : 17 Date : 2013-03-11 Abstract: The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-erp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-erp-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-erp-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jean-jacques.trottin@alcatel-lucent.com Mon Mar 11 14:49:49 2013 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 5C3FD21F8F38 for ; Mon, 11 Mar 2013 14:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.355 X-Spam-Level: X-Spam-Status: No, score=-7.355 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrArMVbc0zyi for ; Mon, 11 Mar 2013 14:49:48 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1421F8F33 for ; Mon, 11 Mar 2013 14:49:47 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BLnhpF011122 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 22:49:43 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 22:49:43 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 22:49:43 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TA= Date: Mon, 11 Mar 2013 21:49:42 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 21:49:49 -0000 Dear all I have added some comments starting with [JJ]. Best regards JJacques=20 =20 -----Message d'origine----- De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Envoy=E9=A0: lundi 11 mars 2013 18:07 =C0=A0: Ben Campbell Cc=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); dime@iet= f.org; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) Objet=A0: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thank you for this answer. One small comment on (not to open a new thread): "I agree in general, although there may be some instances of "whatever" tha= t OC can't work across--for example, a proxy that deliberately hides overlo= ad information." Proxy means "advertising support of application-id X". So it is up to the d= ocumentation using this application to describe what should do the proxy, "= whatever" the functions provided by this proxy. So it is also up to the app= lication designers to figure out what to do with the proxies in the middle,= and this includes system in which OC will be supported. But the general requirement remains: the solution MUST Work in the presence= or absence of Diameter agents between Diameter clients and servers! :) Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: lundi 11 mars 2013 17:46 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); dime@iet= f.org; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, Those were the definitions I was trying to use, since we've had some confus= ion about scenarios where a proxy looks like a server to a client, or like = a client to a server. While those scenarios are real, the proxy is still no= t a server or client according to RFC 6733. More inline: [...] > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") > =20 > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: > =20 > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . > =20 > 2. Besides the case of a DA supporting topology hiding, there are = other cases that must be supported > a) the mechanism must work with a network where there is no interme= diate DA (as described in the overload scenarios of the IEFT draft) and her= e it is the end Diameter node that will receive the overload info, and as= a client has to handle this overload situation (cf point1) > =20 > =20 > Agreed. I don't think we ever intended to accept a solution that _require= d_ agents. So what if we add a requirement to the effect of: > =20 > The solution MUST work in the absence of intervening Diameter agents. > =20 > [LM] we could have something even more generic using: "The solution MUST = work in the presence or absence of Diameter agents between Diameter clients= and servers". I'm happy to combine it that way. I only separated this to follow the struc= ture of the original email. [JJ] I am OK with Lionel > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > =20 > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. > =20 > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.)=20 > =20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement =20 > =20 > We may also find that a different mechanism is required to bypass an agen= t than would normally be used if the agent actually supported overload cont= rol. For example, negotiating support between non-adjacent nodes may be tri= cky given existing (and proposed) negotiation mechanisms. > =20 > I hope to discuss this as an open issue in Orlando. > =20 I've got it in the in-progress slide deck that I am racing to get to the ch= airs :-) >=20 >=20 > =20 > 3. about the hiding topology DA case, such a DA plus the hidden ser= vers behind will appear as a "global server" to the clients. In this case t= he DA will have to support the mechanism in order to define if the "global = server" is overloaded and if yes to generate the overload information ass= ociated to this "global server" and transmit it to the clients which then m= ay act according to point 1) . So the DA case with topology hiding is quite= compatible with the point 1 and with the proposed requirement "The mechan= ism MUST allow Diameter clients to be aware of an overload situation " > =20 > My comment to number 2 probably also needs the following for the sake of = completeness: > =20 > The solution MUST work in the presence of one or more intervening Diamete= r Agents, including those that hide the upstream network topology. > =20 > [LM] i think that my proposal in comment 2 covers this text, saying that = the part referring explicitly to network topology hiding is not deemed req= uired (as a proxy can do whatever, and topology hiding is only one example = of possible functions provided by the proxy. I agree in general, although there may be some instances of "whatever" that= OC can't work across--for example, a proxy that deliberately hides overloa= d information. > =20 > Please see my comment to 1 concerning the "MUST allow Diameter Clients...= " part. Also, keep in mind the downstream peer of this "global server" may = also be an agent. Agreed. I intended to write "one or more agents", but somehow failed to do = so. Thanks! Ben. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From lionel.morand@orange.com Mon Mar 11 15:12:38 2013 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 055AE21F86CA for ; Mon, 11 Mar 2013 15:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOQv6ToJrd2S for ; Mon, 11 Mar 2013 15:12:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DE4A021F842C for ; Mon, 11 Mar 2013 15:12:36 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9F3BA22CB1D; Mon, 11 Mar 2013 23:12:35 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7CD04238048; Mon, 11 Mar 2013 23:12:35 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 23:12:35 +0100 From: To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoA== Date: Mon, 11 Mar 2013 22:12:34 +0000 Message-ID: <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.11.213314 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 22:12:38 -0000 Hi JJ, Please see below (keeping only the open points). Regards, Lionel > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") >=20=20 > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: >=20=20 > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a). [LM] Using wording in REQ1: "Diameter clients must be able to use the recei= ved load and overload information to support graceful behavior during an ov= erload condition"=20 Would it be acceptable for everybody even if maybe not perfect for everyone? > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. >=20=20 > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. >=20=20 > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.)=20 >=20=20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement=20=20 [LM] I don't understand! A (hypothetical) solution that would use a dedicat= ed signaling channel between nodes supporting overload control and not invo= lving the DAs would also comply with the general requirement for overload c= ontrol (in theory), right?=20 =20 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Mon Mar 11 16:16:29 2013 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 4DD7111E8138 for ; Mon, 11 Mar 2013 16:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLoSwsArm9Tb for ; Mon, 11 Mar 2013 16:16:28 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62C9011E8139 for ; Mon, 11 Mar 2013 16:16:28 -0700 (PDT) Received: from vpn-cust-10-119-74-106.witopia.net (53-172.111.65.serverpronto.com [65.111.172.53] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2BNGLXT060413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Mar 2013 18:16:23 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_244F7C18-CDBA-437D-83B8-D1BD90D7BFA9" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Mon, 11 Mar 2013 19:16:16 -0400 Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 65.111.172.53 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2013 23:16:29 -0000 --Apple-Mail=_244F7C18-CDBA-437D-83B8-D1BD90D7BFA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I'm separating out the one really contentious issue: On Mar 11, 2013, at 5:49 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>=20 >> By "client application", I mean the thing the client does that needs = Diameter in the first place--in your example, it's the "driving UE = behavior" part. (I'm open to suggestions for better words than "client = application") >>=20 >> [LM] referring to the definition given above, the second "client = application" seems redundant. The text could simply be: >>=20 >> "Diameter clients must be able to receive sufficient information to = support graceful behavior during an overload condition" >>=20 >=20 > I'm okay with that change. I was looking for a word that described the = "application" that a client uses at the edge of the network for its own = customers, to handle things like network attachments. That is, something = distinct from the "Diameter application". But I agree that the = requirement can stand without it. >=20 > [JJ] Initially I used the expression Diameter application. After, from = Lionel's suggestion, we wrote "The mechanism MUST allow Diameter clients = to be aware of an overload situation" to avoid the use of the word = "application", so I do not see why this sentence is not acceptable . On = the other point, I do not understand what is "sufficient information". = The information that the Diameter client must receive is simply the = overload information that will be defined by IETF for the overload = control mechanism (as in point 2 a). It comes down to a difference between requirements and solution. I = don't think any of us know the details of what constitutes "sufficient = information" yet. The idea is, to leave it to the solution development = effort to figure out exactly what that is. Maybe that shows us that the = "sufficient information" is always the OC info sent by the server. But = maybe it will be something else, or maybe it will be a mixture. The = important point is that it "enables graceful behavior". If people = disagree on what the details of what information is sufficient to that = goal, that's even a better reason to not over-constrain the solution in = the requirement document. Imagine a solution with the following properties as a though experiment. 1. When a server becomes overloaded, it sends an overload report. 2. If no agent exists, the overload report goes directly to the client. 3. If an agent exists, it attempts to resolve the overload situation = locally. (For example, it tries to divert load to another server that = has sufficient capacity.) If it's successful, the client _never_ learns = the overload condition happened in the first place. 4. If the agent cannot resolve the load locally, it originates its own = overload report back toward the client. This report describes the = aggregate overload of the agent and the network upstream of it. It is = likely to be significantly different than the report originally sent by = the server, and may include no information whatsoever from the original = report sent by the server. Would an approach like that meet the requirement you have in mind? Would = another approach that guaranteed that the client would see the original = server's overload report be preferable? --Apple-Mail=_244F7C18-CDBA-437D-83B8-D1BD90D7BFA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 jean-jacques.trott= in@alcatel-lucent.com> wrote:


By = "client application", I mean the thing the client  does that needs = Diameter in the first place--in your example, it's the "driving = UE behavior" part. (I'm open to suggestions for better words than = "client application")

[LM] referring to the definition given = above, the second "client application" seems redundant. The text could = simply be:

"Diameter clients must be able to receive sufficient = information to support graceful behavior during an overload = condition"


I'm okay with that change. I was = looking for a word that described the "application" that a client uses = at the edge of the network for its own customers, to handle things = like network attachments. That is, something distinct from the "Diameter = application". But I agree that the requirement can stand without = it.

[JJ] Initially I used the expression Diameter application. = After, from Lionel's suggestion, we wrote "The mechanism MUST allow = Diameter clients to be aware of an overload situation" to avoid the = use of the word "application", so I do not see why this sentence is not = acceptable . On the other point, I do not understand what  is = "sufficient information". The information that the Diameter client must = receive is simply the overload information that will be defined by = IETF for the overload control mechanism (as in point 2 = a).

It comes down to a difference between = requirements and solution.  I don't think any of us know the = details of what constitutes "sufficient information" yet. The idea is, = to leave it to the solution development effort to figure out exactly = what that is. Maybe that shows us that the "sufficient information" is = always the OC info sent by the server. But maybe it will be something = else, or maybe it will be a mixture. The important point is that it = "enables graceful behavior". If people disagree on what the details of = what information is sufficient to that goal, that's even a better reason = to not over-constrain the solution in the requirement = document.

Imagine a solution with the following = properties as a though experiment.

1. When a = server becomes overloaded, it sends an overload report.
2. If = no agent exists, the overload report goes directly to the = client.
3. If an agent exists, it attempts to resolve the = overload situation locally. (For example, it tries to divert load to = another server that has sufficient capacity.) If it's successful, the = client _never_ learns the overload condition happened in the first = place.
4. If the agent cannot resolve the load locally, it = originates its own overload report back toward the client. This report = describes the aggregate overload of the agent and the network upstream = of it. It is likely to be significantly different than the report = originally sent by the server, and may include no information whatsoever = from the original report sent by the = server.

Would an approach like that = meet the requirement you have in mind? Would another approach that = guaranteed that the client would see the original server's overload = report be preferable?

= --Apple-Mail=_244F7C18-CDBA-437D-83B8-D1BD90D7BFA9-- From lionel.morand@orange.com Mon Mar 11 21:44:04 2013 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 E135921F87B1 for ; Mon, 11 Mar 2013 21:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXXNssSLl9Vy for ; Mon, 11 Mar 2013 21:44:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1421F874D for ; Mon, 11 Mar 2013 21:44:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3EFB03245C2; Tue, 12 Mar 2013 05:44:00 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D3AA4C015; Tue, 12 Mar 2013 05:44:00 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 05:43:59 +0100 From: To: Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAtdAIAAbFMX Date: Tue, 12 Mar 2013 04:43:58 +0000 Message-ID: <3578_1363063440_513EB290_3578_4945_1_3F14EB81-C4D3-43B3-BF0C-93437E518A04@orange.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3F14EB81C4D343B3BF0C93437E518A04orangecom_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.12.34524 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 04:44:04 -0000 --_000_3F14EB81C4D343B3BF0C93437E518A04orangecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben Have you see my proposed wording in response to JJ comment? Regards, Lionel Envoy=E9 de mon iPod Le 12 mars 2013 =E0 00:16, "Ben Campbell" > a =E9crit : Hi, I'm separating out the one really contentious issue: On Mar 11, 2013, at 5:49 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > wrote: By "client application", I mean the thing the client does that needs Diame= ter in the first place--in your example, it's the "driving UE behavior" par= t. (I'm open to suggestions for better words than "client application") [LM] referring to the definition given above, the second "client applicatio= n" seems redundant. The text could simply be: "Diameter clients must be able to receive sufficient information to support= graceful behavior during an overload condition" I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a). It comes down to a difference between requirements and solution. I don't t= hink any of us know the details of what constitutes "sufficient information= " yet. The idea is, to leave it to the solution development effort to figur= e out exactly what that is. Maybe that shows us that the "sufficient inform= ation" is always the OC info sent by the server. But maybe it will be somet= hing else, or maybe it will be a mixture. The important point is that it "e= nables graceful behavior". If people disagree on what the details of what i= nformation is sufficient to that goal, that's even a better reason to not o= ver-constrain the solution in the requirement document. Imagine a solution with the following properties as a though experiment. 1. When a server becomes overloaded, it sends an overload report. 2. If no agent exists, the overload report goes directly to the client. 3. If an agent exists, it attempts to resolve the overload situation locall= y. (For example, it tries to divert load to another server that has suffici= ent capacity.) If it's successful, the client _never_ learns the overload c= ondition happened in the first place. 4. If the agent cannot resolve the load locally, it originates its own over= load report back toward the client. This report describes the aggregate ove= rload of the agent and the network upstream of it. It is likely to be signi= ficantly different than the report originally sent by the server, and may i= nclude no information whatsoever from the original report sent by the serve= r. Would an approach like that meet the requirement you have in mind? Would an= other approach that guaranteed that the client would see the original serve= r's overload report be preferable? ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_3F14EB81C4D343B3BF0C93437E518A04orangecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ben

Have you see my proposed wording in response to JJ comment?

Regards,

Lionel

Envoy=E9 de mon iPod

Le 12 mars 2013 =E0 00:16, "Ben Campbell" <ben@nostrum.com> a =E9crit :

Hi,

I'm separating out the one really contentious issue:

On Mar 11, 2013, at 5:49 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&quo= t; <jean-jacq= ues.trottin@alcatel-lucent.com> wrote:


By "client application", I mean the thing the client  does t= hat needs Diameter in the first place--in your example, it's the "driv= ing UE behavior" part. (I'm open to suggestions for better words = than "client application")

[LM] referring to the definition given above, the second "client appli= cation" seems redundant. The text could simply be:

"Diameter clients must be able to receive sufficient information to su= pport graceful behavior during an overload condition"


I'm okay with that change. I was looking for a word that described the &quo= t;application" that a client uses at the edge of the network for its o= wn customers, to handle things like network attachments. That is, some= thing distinct from the "Diameter application". But I agree that the requirement can stand without it.

[JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clie= nts to be aware of an overload situation" to avoid the use of the word= "application", so I do not see why this sentence is not acceptable . On the other point, I do not understand what &nbs= p;is "sufficient information". The information that the Diameter = client must receive is simply the overload information that will be de= fined by IETF for the overload control mechanism (as in point 2 a).

It comes down to a difference between requirements and solution.  I do= n't think any of us know the details of what constitutes "sufficient i= nformation" yet. The idea is, to leave it to the solution development = effort to figure out exactly what that is. Maybe that shows us that the "sufficient information" is always the OC= info sent by the server. But maybe it will be something else, or maybe it = will be a mixture. The important point is that it "enables graceful be= havior". If people disagree on what the details of what information is sufficient to that goal, that's even a better reaso= n to not over-constrain the solution in the requirement document.

Imagine a solution with the following properties as a though experimen= t.

1. When a server becomes overloaded, it sends an overload report.
2. If no agent exists, the overload report goes directly to the client= .
3. If an agent exists, it attempts to resolve the overload situation l= ocally. (For example, it tries to divert load to another server that has su= fficient capacity.) If it's successful, the client _never_ learns the overl= oad condition happened in the first place.
4. If the agent cannot resolve the load locally, it originates its own= overload report back toward the client. This report describes the aggregat= e overload of the agent and the network upstream of it. It is likely to be = significantly different than the report originally sent by the server, and may include no information whats= oever from the original report sent by the server.

Would an approach like that meet the requirement you have in mind? Would an= other approach that guaranteed that the client would see the original serve= r's overload report be preferable?

______________________________________________________________________=
___________________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_3F14EB81C4D343B3BF0C93437E518A04orangecom_-- From nigel.berry@alcatel-lucent.com Tue Mar 12 04:02:50 2013 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 C893821F8962 for ; Tue, 12 Mar 2013 04:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e85Iseir+DNe for ; Tue, 12 Mar 2013 04:02:50 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id BB8CE21F8930 for ; Tue, 12 Mar 2013 04:02:49 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CB27fU017457 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 12:02:47 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 12:02:12 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 12:02:11 +0100 From: "BERRY, Nigel (Nigel)" To: "lionel.morand@orange.com" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "Ben Campbell" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jygxSW8PDeSFK3yPO6PRffLQC6rbYAAAJFTIAAALWlAAAJ4jcAAADMcgAAHEzrAA== Date: Tue, 12 Mar 2013 11:02:10 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 X-Mailman-Approved-At: Tue, 12 Mar 2013 04:34:17 -0700 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 11:12:40 -0000 Hi Lionel, See in line, Kind Regards, Nigel -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: 11 March 2013 22:13 To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thie= rry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi JJ, Please see below (keeping only the open points). Regards, Lionel > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") > > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: > > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" > I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [Nigel] [Nigel] Yes, I do not see the need for more precision especially when "Diam= eter Client Application" remains undefined and vague, so let's use the term= defined, "Diameter Client" this entails the whole box of tricks and all ap= plications supported. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . [LM] Using wording in REQ1: "Diameter clients must be able to use the recei= ved load and overload information to support graceful behavior during an ov= erload condition" Would it be acceptable for everybody even if maybe not perfect for everyone= ? [Nigel] [Nigel] This is fine by me. Do we need to be more precise at this stage? > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. > > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.) > > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement [Nigel] [Nigel] This is a "must" for the normal Client-Server case. In the Proxy ca= se, the Client should also be informed that actions are being taken to subs= ume an overload situation even if the Proxy attempts to take care of this. [LM] I don't understand! A (hypothetical) solution that would use a dedicat= ed signaling channel between nodes supporting overload control and not invo= lving the DAs would also comply with the general requirement for overload c= ontrol (in theory), right? [Nigel] But should we not consider the normal cases before any hypothetical= cases. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From nigel.berry@alcatel-lucent.com Tue Mar 12 04:11:44 2013 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 4DCE621F88C0 for ; Tue, 12 Mar 2013 04:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfrlVqdacwOp for ; Tue, 12 Mar 2013 04:11:43 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC521F8470 for ; Tue, 12 Mar 2013 04:11:42 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CBBFIU013847 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 12:11:37 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 12:11:15 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 12:11:08 +0100 From: "BERRY, Nigel (Nigel)" To: Ben Campbell , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jygxSW8PDeSFK3yPO6PRffLQC6rbYAAAJFTIAAALWlAAAJ4jcAAAMF+AAAGsohEA== Date: Tue, 12 Mar 2013 11:11:07 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_EEAE066A3E3F7F47BB9749EF888F11160161D6FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 X-Mailman-Approved-At: Tue, 12 Mar 2013 04:34:17 -0700 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 11:17:21 -0000 --_000_EEAE066A3E3F7F47BB9749EF888F11160161D6FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, See in line, Kind Regards, Nigel ________________________________ From: Ben Campbell [mailto:ben@nostrum.com] Sent: 11 March 2013 23:16 To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc: lionel.morand@orange.com; DRAGE, Keith (Keith); dime@ietf.org; BERRY, N= igel (Nigel); Bessis, Thierry (Thierry) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi, I'm separating out the one really contentious issue: On Mar 11, 2013, at 5:49 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > wrote: By "client application", I mean the thing the client does that needs Diame= ter in the first place--in your example, it's the "driving UE behavior" par= t. (I'm open to suggestions for better words than "client application") [LM] referring to the definition given above, the second "client applicatio= n" seems redundant. The text could simply be: "Diameter clients must be able to receive sufficient information to support= graceful behavior during an overload condition" I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [Nigel] Are not these the Diameter Clients? [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . It comes down to a difference between requirements and solution. I don't t= hink any of us know the details of what constitutes "sufficient information= " yet. The idea is, to leave it to the solution development effort to figur= e out exactly what that is. Maybe that shows us that the "sufficient inform= ation" is always the OC info sent by the server. But maybe it will be somet= hing else, or maybe it will be a mixture. The important point is that it "e= nables graceful behavior". If people disagree on what the details of what i= nformation is sufficient to that goal, that's even a better reason to not o= ver-constrain the solution in the requirement document. [Nigel] How about "sufficient information to enable a graceful behaviour"? Imagine a solution with the following properties as a though experiment. 1. When a server becomes overloaded, it sends an overload report. 2. If no agent exists, the overload report goes directly to the client. 3. If an agent exists, it attempts to resolve the overload situation locall= y. (For example, it tries to divert load to another server that has suffici= ent capacity.) If it's successful, the client _never_ learns the overload c= ondition happened in the first place. 4. If the agent cannot resolve the load locally, it originates its own over= load report back toward the client. This report describes the aggregate ove= rload of the agent and the network upstream of it. It is likely to be signi= ficantly different than the report originally sent by the server, and may i= nclude no information whatsoever from the original report sent by the serve= r. Would an approach like that meet the requirement you have in mind? Would an= other approach that guaranteed that the client would see the original serve= r's overload report be preferable? [Nigel] We obviously have to bear in mind that a Diameter proxy may be able= to deal with an overload situation of a topology that it is hiding, on the= other hand it might not, so in the normal case the Diameter Client must be= informed of any overload situation pertaining to the Clients it is respons= ible for. --_000_EEAE066A3E3F7F47BB9749EF888F11160161D6FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_EEAE066A3E3F7F47BB9749EF888F11160161D6FR712WXCHMBA11zeu_-- From jean-jacques.trottin@alcatel-lucent.com Tue Mar 12 04:36:14 2013 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 CAE8A21F84CA for ; Tue, 12 Mar 2013 04:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.022 X-Spam-Level: X-Spam-Status: No, score=-9.022 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aWqM6gomazb for ; Tue, 12 Mar 2013 04:36:14 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id BC38121F849A for ; Tue, 12 Mar 2013 04:36:13 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CBU5Bw029224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 12:36:10 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 12:35:28 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 12:35:28 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "BERRY, Nigel (Nigel)" , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAAZNpA= Date: Tue, 12 Mar 2013 11:35:27 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 11:36:14 -0000 -----Message d'origine----- De=A0: BERRY, Nigel (Nigel)=20 Envoy=E9=A0: mardi 12 mars 2013 12:02 =C0=A0: lionel.morand@orange.com; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben= Campbell Cc=A0: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Objet=A0: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, See in line, Kind Regards, Nigel -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: 11 March 2013 22:13 To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thie= rry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi JJ, Please see below (keeping only the open points). Regards, Lionel > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") > =20 > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: > =20 > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [Nigel]=20 [Nigel] Yes, I do not see the need for more precision especially when "Diam= eter Client Application" remains undefined and vague, so let's use the term= defined, "Diameter Client" this entails the whole box of tricks and all ap= plications supported. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . [LM] Using wording in REQ1: "Diameter clients must be able to use the recei= ved load and overload information to support graceful behavior during an ov= erload condition"=20 Would it be acceptable for everybody even if maybe not perfect for everyone= ? [Nigel]=20 [Nigel] This is fine by me. Do we need to be more precise at this stage? > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > =20 > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. > =20 > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.)=20 > =20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement=20 [Nigel] =20 [Nigel] This is a "must" for the normal Client-Server case. In the Proxy ca= se, the Client should also be informed that actions are being taken to subs= ume an overload situation even if the Proxy attempts to take care of this. [LM] I don't understand! A (hypothetical) solution that would use a dedicat= ed signaling channel between nodes supporting overload control and not invo= lving the DAs would also comply with the general requirement for overload c= ontrol (in theory), right?=20 [Nigel] But should we not consider the normal cases before any hypothetical= cases. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From jean-jacques.trottin@alcatel-lucent.com Tue Mar 12 04:36:23 2013 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 6E01E21F849A for ; Tue, 12 Mar 2013 04:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.922 X-Spam-Level: X-Spam-Status: No, score=-8.922 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTFawLjY3afx for ; Tue, 12 Mar 2013 04:36:22 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 454ED21F8702 for ; Tue, 12 Mar 2013 04:36:22 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CBTST8028912 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 12:36:16 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 12:35:24 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 12:35:24 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "lionel.morand@orange.com" , Ben Campbell , "BERRY, Nigel (Nigel)" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+A= Date: Tue, 12 Mar 2013 11:35:23 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 11:36:23 -0000 Hi Lionel I add my remarks with [JJ2]to Nigel'ones. Best regards JJacques=20 =20 -----Message d'origine----- De=A0: BERRY, Nigel (Nigel)=20 Envoy=E9=A0: mardi 12 mars 2013 12:02 =C0=A0: lionel.morand@orange.com; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben= Campbell Cc=A0: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Objet=A0: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, See in line, Kind Regards, Nigel -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: 11 March 2013 22:13 To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thie= rry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi JJ, Please see below (keeping only the open points). Regards, Lionel > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") > =20 > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: > =20 > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [Nigel]=20 [Nigel] Yes, I do not see the need for more precision especially when "Diam= eter Client Application" remains undefined and vague, so let's use the term= defined, "Diameter Client" this entails the whole box of tricks and all ap= plications supported. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . [LM] Using wording in REQ1: "Diameter clients must be able to use the recei= ved load and overload information to support graceful behavior during an ov= erload condition"=20 Would it be acceptable for everybody even if maybe not perfect for everyone= ? [Nigel]=20 [Nigel] This is fine by me. Do we need to be more precise at this stage? [JJ2] My important point in my statement is that a Diameter client which wa= nts to support graceful behavior during an overload condition must receive = the overload information on which it will base its graceful behavior includ= ing a graceful shedding. I have no issue about where load balancing is done= (and in practice DAs have a key role there), but if traffic must be reduce= d (shedding), I have the requirement to allow the Diameter client to be in= formed of this overload situation by receiving the overload information so = to have a graceful behavior with graceful shedding rather than to do the s= hedding in the DA. Otherwise, if this possibility is not offered, I have no= graceful behavior because no overlaod info is given to the client, sheddin= g being done by the DA. Do you consider your new wording covers this requir= ement? If yes, OK, but on my side, I am not yet sure. It is a key point.=20 [JJ2] As I also said, my above statement is also compliant with Ben's exam= ple (cf parallel mail) with an intermediate DA that is doing load balancin= g to other servers and may solve overload without traffic shedding. But, i= f, nevertheless, after load balancing, it remains a global/aggregated ove= rload, in this case, I have the same requirement as above to allow the Dia= meter client to be informed of this overload, so that it can have a grace= ful behavior and shedding. =20 > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > =20 > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. > =20 > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.)=20 > =20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement=20 [Nigel] =20 [Nigel] This is a "must" for the normal Client-Server case. In the Proxy ca= se, the Client should also be informed that actions are being taken to subs= ume an overload situation even if the Proxy attempts to take care of this. [LM] I don't understand! A (hypothetical) solution that would use a dedicat= ed signaling channel between nodes supporting overload control and not invo= lving the DAs would also comply with the general requirement for overload c= ontrol (in theory), right?=20 [Nigel] But should we not consider the normal cases before any hypothetical= cases. [JJ2)] I have not spoken of a dedicated signaling channel; but here we are = entering the solutions space. We can imagine solutions where the overload i= nfo is simply transferred downstream by a DA not supporting the mechanism = =20 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From md3135@att.com Tue Mar 12 04:42:22 2013 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 1221421F8702 for ; Tue, 12 Mar 2013 04:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.772 X-Spam-Level: X-Spam-Status: No, score=-105.772 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTOrfsD49wm4 for ; Tue, 12 Mar 2013 04:42:20 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9D57021F85FC for ; Tue, 12 Mar 2013 04:42:20 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id c941f315.5c550940.36060.00-598.98286.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 12 Mar 2013 11:42:20 +0000 (UTC) X-MXL-Hash: 513f149c552a1546-b127a75bec08c891366d38426d754f385a99d66f Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9941f315.0.36055.00-454.98264.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 12 Mar 2013 11:42:18 +0000 (UTC) X-MXL-Hash: 513f149a7bd56ca3-536e2238c842865e1825532e11462f4fec9a2f93 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2CBgHtY029723; Tue, 12 Mar 2013 07:42:17 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2CBgC0x029692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 07:42:13 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 12 Mar 2013 11:42:04 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Tue, 12 Mar 2013 07:42:03 -0400 From: "DOLLY, MARTIN C" To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "lionel.morand@orange.com" , Ben Campbell , "BERRY, Nigel (Nigel)" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jygxSW8PDeSFK3yPO6PRffLQC6rbYAAAJFTIAAALWlAAAJ4jcAAADMcgAAHEzrAAAKNwiAAAgxmkA= Date: Tue, 12 Mar 2013 11:42:02 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.192.195] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=XMSHv3dE c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=PPgGLIX7qA8A:10 a=r_FGx56wRvQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=NajClncphjEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=m_DA1TXp8z5uMmzMMGUA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=oAXR_kdF8uMA:10 a=wwWfBZ5X0VJVGqjh:21 a=VK5Y1OCDxTb1] X-AnalysisOut: [ec-7:21] Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 11:42:22 -0000 G'day, I really do not understand why we are splitting hairs, not once but twice..= .. Regards, Martin -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of TRO= TTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: Tuesday, March 12, 2013 7:35 AM To: lionel.morand@orange.com; Ben Campbell; BERRY, Nigel (Nigel) Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel I add my remarks with [JJ2]to Nigel'ones. Best regards JJacques=20 =20 -----Message d'origine----- De=A0: BERRY, Nigel (Nigel)=20 Envoy=E9=A0: mardi 12 mars 2013 12:02 =C0=A0: lionel.morand@orange.com; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben= Campbell Cc=A0: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Objet=A0: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, See in line, Kind Regards, Nigel -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Sent: 11 March 2013 22:13 To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thie= rry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi JJ, Please see below (keeping only the open points). Regards, Lionel > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") > =20 > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: > =20 > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" >=20 I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [Nigel]=20 [Nigel] Yes, I do not see the need for more precision especially when "Diam= eter Client Application" remains undefined and vague, so let's use the term= defined, "Diameter Client" this entails the whole box of tricks and all ap= plications supported. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . [LM] Using wording in REQ1: "Diameter clients must be able to use the recei= ved load and overload information to support graceful behavior during an ov= erload condition"=20 Would it be acceptable for everybody even if maybe not perfect for everyone= ? [Nigel]=20 [Nigel] This is fine by me. Do we need to be more precise at this stage? [JJ2] My important point in my statement is that a Diameter client which wa= nts to support graceful behavior during an overload condition must receive = the overload information on which it will base its graceful behavior includ= ing a graceful shedding. I have no issue about where load balancing is done= (and in practice DAs have a key role there), but if traffic must be reduce= d (shedding), I have the requirement to allow the Diameter client to be in= formed of this overload situation by receiving the overload information so = to have a graceful behavior with graceful shedding rather than to do the s= hedding in the DA. Otherwise, if this possibility is not offered, I have no= graceful behavior because no overlaod info is given to the client, sheddin= g being done by the DA. Do you consider your new wording covers this requir= ement? If yes, OK, but on my side, I am not yet sure. It is a key point.=20 [JJ2] As I also said, my above statement is also compliant with Ben's exam= ple (cf parallel mail) with an intermediate DA that is doing load balancin= g to other servers and may solve overload without traffic shedding. But, i= f, nevertheless, after load balancing, it remains a global/aggregated ove= rload, in this case, I have the same requirement as above to allow the Dia= meter client to be informed of this overload, so that it can have a grace= ful behavior and shedding. =20 > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > =20 > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. > =20 > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.)=20 > =20 > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement=20 [Nigel] =20 [Nigel] This is a "must" for the normal Client-Server case. In the Proxy ca= se, the Client should also be informed that actions are being taken to subs= ume an overload situation even if the Proxy attempts to take care of this. [LM] I don't understand! A (hypothetical) solution that would use a dedicat= ed signaling channel between nodes supporting overload control and not invo= lving the DAs would also comply with the general requirement for overload c= ontrol (in theory), right?=20 [Nigel] But should we not consider the normal cases before any hypothetical= cases. [JJ2)] I have not spoken of a dedicated signaling channel; but here we are = entering the solutions space. We can imagine solutions where the overload i= nfo is simply transferred downstream by a DA not supporting the mechanism = =20 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nigel.berry@alcatel-lucent.com Tue Mar 12 05:00:17 2013 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 4128E21F8623 for ; Tue, 12 Mar 2013 05:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.195 X-Spam-Level: X-Spam-Status: No, score=-9.195 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh3WPBW8z7HV for ; Tue, 12 Mar 2013 05:00:16 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7321F8606 for ; Tue, 12 Mar 2013 05:00:15 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CC06CH007864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 13:00:15 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 13:00:05 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 13:00:04 +0100 From: "BERRY, Nigel (Nigel)" To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jygxSW8PDeSFK3yPO6PRffLZhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+CYmvcXMA== Date: Tue, 12 Mar 2013 12:00:04 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 X-Mailman-Approved-At: Tue, 12 Mar 2013 05:03:49 -0700 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 12:00:17 -0000 Hi Lionel, JJ, Appending comments with Nigel1, Kind Regards, Nigel -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: 12 March 2013 11:35 To: lionel.morand@orange.com; Ben Campbell; BERRY, Nigel (Nigel) Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel I add my remarks with [JJ2]to Nigel'ones. Best regards JJacques -----Message d'origine----- De : BERRY, Nigel (Nigel) Envoy=E9 : mardi 12 mars 2013 12:02 =C0 : lionel.morand@orange.com; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben C= ampbell Cc : DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, See in line, Kind Regards, Nigel -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: 11 March 2013 22:13 To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell Cc: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thie= rry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi JJ, Please see below (keeping only the open points). Regards, Lionel > By "client application", I mean the thing the client does that needs Dia= meter in the first place--in your example, it's the "driving UE behavior" p= art. (I'm open to suggestions for better words than "client application") > > [LM] referring to the definition given above, the second "client applicat= ion" seems redundant. The text could simply be: > > "Diameter clients must be able to receive sufficient information to suppo= rt graceful behavior during an overload condition" > I'm okay with that change. I was looking for a word that described the "app= lication" that a client uses at the edge of the network for its own custome= rs, to handle things like network attachments. That is, something distinct = from the "Diameter application". But I agree that the requirement can stand= without it. [Nigel] [Nigel] Yes, I do not see the need for more precision especially when "Diam= eter Client Application" remains undefined and vague, so let's use the term= defined, "Diameter Client" this entails the whole box of tricks and all ap= plications supported. [JJ] Initially I used the expression Diameter application. After, from Lion= el's suggestion, we wrote "The mechanism MUST allow Diameter clients to be = aware of an overload situation" to avoid the use of the word "application",= so I do not see why this sentence is not acceptable . On the other point, = I do not understand what is "sufficient information". The information that= the Diameter client must receive is simply the overload information that w= ill be defined by IETF for the overload control mechanism (as in point 2 a)= . [LM] Using wording in REQ1: "Diameter clients must be able to use the recei= ved load and overload information to support graceful behavior during an ov= erload condition" Would it be acceptable for everybody even if maybe not perfect for everyone= ? [Nigel] [Nigel] This is fine by me. Do we need to be more precise at this stage? [JJ2] My important point in my statement is that a Diameter client which wa= nts to support graceful behavior during an overload condition must receive = the overload information on which it will base its graceful behavior includ= ing a graceful shedding. I have no issue about where load balancing is done= (and in practice DAs have a key role there), but if traffic must be reduce= d (shedding), I have the requirement to allow the Diameter client to be in= formed of this overload situation by receiving the overload information so = to have a graceful behavior with graceful shedding rather than to do the s= hedding in the DA. Otherwise, if this possibility is not offered, I have no= graceful behavior because no overlaod info is given to the client, sheddin= g being done by the DA. Do you consider your new wording covers this requir= ement? If yes, OK, but on my side, I am not yet sure. It is a key point. [Nigel1] I see, your point: is "load shedding" graceful behaviour? I suppose graceful behaviour is everything apart from falling over, in the = sense of being drunk. In that case we should just leave it as "sufficient i= nformation for appropriate action to be taken". [JJ2] As I also said, my above statement is also compliant with Ben's exam= ple (cf parallel mail) with an intermediate DA that is doing load balancin= g to other servers and may solve overload without traffic shedding. But, i= f, nevertheless, after load balancing, it remains a global/aggregated overl= oad, in this case, I have the same requirement as above to allow the Diamet= er client to be informed of this overload, so that it can have a graceful b= ehavior and shedding. [Nigel] Yes, it is important that all scenarios are considered and not just= an appropriate few. > b) Similar to the above there is the case of networks with intermed= iate DAs with limited functions (eg for routing purposes and without topol= ogy hiding) and which are not upgraded for overload support. Here also the = mechanism must support this case, overload being handled (as in a) above) b= etween server and clients as no identified differences. If this case is exc= luded, it imposes a high constraint to the operator to have all the DAs to = support the mechanism. This case, for me, is not excluded of the draft and = relies on the REQ 35 that applies. But as this deployment case must be supp= orted, it means that the mechanism must work when intermediate nodes are no= t supporting overload control. It is why we have proposed REQ35 to be with = a MUST instead of a SHOULD (as Lauret wrote in his Jan 24th mail. > > There have been arguments on both sides of whether 35 should be a MUST or= a SHOULD. I think those leaning towards a SHOULD are thinking that this ma= y be hard problem to solve in the general case. Putting a SHOULD there woul= d create a preference for a solution that did solve this, vs a solution tha= t did not, everything else being equal. > > I think I would be willing to accept a MUST there, if we understand that = there may be significant limitations in how much an agent can do and signif= icant requirements for information sharing and among servers upstream of th= e agent (e.g. any server may be required to speak for all servers.) > > [LM] I also see the "SHOULD" in REQ35 as a strong indication for solution= designers that the preference will be given to the solution that would pro= vide this feature, not as an absolute constraint. I concur, and I'm reasonably okay with either choice. (From a practical per= spective, the distinction between SHOULD and MUST is smaller when writing a= requirements document than for a protocol specification. The working group= can later discover that a requirement simply won't work, or is not worth t= he tradeoffs either way.) [JJ] As I said, the deployment with DAs not supporting the mechanism must n= ot be excluded, so this implies the solution to support this case and drive= s to a MUST in REQ 35. Then we will see if we have a solution fulfilling th= e requirement [Nigel] [Nigel] This is a "must" for the normal Client-Server case. In the Proxy ca= se, the Client should also be informed that actions are being taken to subs= ume an overload situation even if the Proxy attempts to take care of this. [LM] I don't understand! A (hypothetical) solution that would use a dedicat= ed signaling channel between nodes supporting overload control and not invo= lving the DAs would also comply with the general requirement for overload c= ontrol (in theory), right? [Nigel] But should we not consider the normal cases before any hypothetical= cases. [JJ2)] I have not spoken of a dedicated signaling channel; but here we are = entering the solutions space. We can imagine solutions where the overload i= nfo is simply transferred downstream by a DA not supporting the mechanism [Nigel1] Yes, good point! ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From iesg-secretary@ietf.org Tue Mar 12 06:23:50 2013 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 17AD921F8A51; Tue, 12 Mar 2013 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG63gF1nnX3Z; Tue, 12 Mar 2013 06:23:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFAC21F8A84; Tue, 12 Mar 2013 06:23:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130312132347.1190.92966.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 06:23:47 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Support for the EAP Re-authentication Protocol (ERP)' to Proposed Standard (draft-ietf-dime-erp-17.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 13:23:50 -0000 The IESG has approved the following document: - 'Diameter Support for the EAP Re-authentication Protocol (ERP)' (draft-ietf-dime-erp-17.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ Technical Summary The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. Working Group Summary The I-D has been discussed extensively in the DIME WG and has reached the overall working group consensus. The work has been done in a cooperation with the Hokey WG that defined the EAP Re-authentication Protocol solution. Document Quality There are no publicly announced implementations of the protocol. Personnel Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise (bclaise@cisco.com) is the responsible Area Director. From iesg-secretary@ietf.org Tue Mar 12 06:23:50 2013 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 946DF21F8A84 for ; Tue, 12 Mar 2013 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QNBmyiVeBqP; Tue, 12 Mar 2013 06:23:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 774E221F8ABC; Tue, 12 Mar 2013 06:23:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.42 X-IETF-Draft-string: draft-ietf-dime-erp X-IETF-Draft-revision: 17 Message-ID: <20130312132347.1190.72880.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 06:23:47 -0700 Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Support for the EAP Re-authentication Protocol (ERP)' to Proposed Standard (draft-ietf-dime-erp-17.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:23:50 -0000 The IESG has approved the following document: - 'Diameter Support for the EAP Re-authentication Protocol (ERP)' (draft-ietf-dime-erp-17.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-erp/ Technical Summary The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. Working Group Summary The I-D has been discussed extensively in the DIME WG and has reached the overall working group consensus. The work has been done in a cooperation with the Hokey WG that defined the EAP Re-authentication Protocol solution. Document Quality There are no publicly announced implementations of the protocol. Personnel Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise (bclaise@cisco.com) is the responsible Area Director. From ben@nostrum.com Tue Mar 12 06:41:12 2013 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 30F0821F85EE for ; Tue, 12 Mar 2013 06:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZpzideaq970 for ; Tue, 12 Mar 2013 06:41:11 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B63F21F8AC1 for ; Tue, 12 Mar 2013 06:41:11 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CDe9bS060273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 08:40:10 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Tue, 12 Mar 2013 09:40:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 13:41:12 -0000 Hi, further comments inline: On Mar 12, 2013, at 7:35 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: [...] > [LM] Using wording in REQ1: "Diameter clients must be able to use the = received load and overload information to support graceful behavior = during an overload condition"=20 > Would it be acceptable for everybody even if maybe not perfect for = everyone? > [Nigel]=20 > [Nigel] This is fine by me. Do we need to be more precise at this = stage? >=20 > [JJ2] My important point in my statement is that a Diameter client = which wants to support graceful behavior during an overload condition = must receive the overload information on which it will base its graceful = behavior including a graceful shedding. I have no issue about where load = balancing is done (and in practice DAs have a key role there), but if = traffic must be reduced (shedding), I have the requirement to allow the = Diameter client to be informed of this overload situation by receiving = the overload information so to have a graceful behavior with graceful = shedding rather than to do the shedding in the DA. Otherwise, if this = possibility is not offered, I have no graceful behavior because no = overlaod info is given to the client, shedding being done by the DA. Do = you consider your new wording covers this requirement? If yes, OK, but = on my side, I am not yet sure. It is a key point.=20 >=20 > [JJ2] As I also said, my above statement is also compliant with Ben's = example (cf parallel mail) with an intermediate DA that is doing load = balancing to other servers and may solve overload without traffic = shedding. But, if, nevertheless, after load balancing, it remains a = global/aggregated overload, in this case, I have the same requirement = as above to allow the Diameter client to be informed of this overload, = so that it can have a graceful behavior and shedding. =20 >=20 If we understand that a requirement for the client to receive overload = information doesn't mean it has to receive the information that the = server sent, and it doesn't mean it has to receive it at all if an agent = 1) exists, and 2) can handle the condition locally and transparently, = then I'm reasonably okay with that. But I've seen a few comments that = suggest a general preference for handling overload as close to the = client as possible. I'm not opposed to it being possible to do so, but I = don't want to be prevented from taking a "handle it as close to the = server as I can" approach either. Isn't the actual requirement that the "Client is able to behave = gracefully during an overload condition"? I can think of a number of ways to accomplish that off-hand: 1) Direct = client-server connection. 2) Agent completely handles overload without = dropping requests. 3) Agent sends an aggregate overload report to the = client. 4) Agent drops requests locally, and informs client of dropped = requests with an error message. I'm sure there's more. Each of these might be better or worse than the others--but the criteria = should be how well the solution supports graceful client behavior, not = the details of how it accomplishes it. (I recognize that option 4 may = have issues, but those issues can still be measured according to how = well the client can implement graceful behavior.) Going beyond that is = solution, not requirements. [...] > [JJ] As I said, the deployment with DAs not supporting the mechanism = must not be excluded, so this implies the solution to support this case = and drives to a MUST in REQ 35. Then we will see if we have a solution = fulfilling the requirement=20 > [Nigel] =20 > [Nigel] This is a "must" for the normal Client-Server case. In the = Proxy case, the Client should also be informed that actions are being = taken to subsume an overload situation even if the Proxy attempts to = take care of this. >=20 >=20 > [LM] I don't understand! A (hypothetical) solution that would use a = dedicated signaling channel between nodes supporting overload control = and not involving the DAs would also comply with the general requirement = for overload control (in theory), right?=20 >=20 > [Nigel] But should we not consider the normal cases before any = hypothetical cases. > [JJ2)] I have not spoken of a dedicated signaling channel; but here we = are entering the solutions space. We can imagine solutions where the = overload info is simply transferred downstream by a DA not supporting = the mechanism =20 > _ I don't think we can declare either a direct client-server connection = architecture, or an agent based architecture, as the _normal_ case. Both = exist in the wild. I agree the solution should work in the direct = client-server connection case, but if agents can provide additional = value, we should not prejudice the solution effort away from considering = that. Thanks! Ben.= From lionel.morand@orange.com Tue Mar 12 06:59:32 2013 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 76BC821F86AD for ; Tue, 12 Mar 2013 06:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-TgCarGQFBj for ; Tue, 12 Mar 2013 06:59:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DDB0921F869C for ; Tue, 12 Mar 2013 06:59:29 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 06C3222C73E; Tue, 12 Mar 2013 14:59:29 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DA7F44C017; Tue, 12 Mar 2013 14:59:28 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 14:59:28 +0100 From: To: Ben Campbell , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+CAABnGgIAAEw6w Date: Tue, 12 Mar 2013 13:59:26 +0000 Message-ID: <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> In-Reply-To: <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.12.123320 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 13:59:32 -0000 Hi, Honestly, I don't understand why we have to go down each time to the soluti= on space to understand a requirement! Can we try to make it simple when possible? 1/ REQ 2 complement: Based on the different comments, my proposal for the new requirement is the= following:=20 "Diameter clients must be able to use the received load and overload inform= ation to support graceful behavior during an overload condition" And the question is: OK or NOK i.e. can you live with? 2/ REQ 35: With the clarification that the "SHOULD" is strong recommendation for solut= ion designers i.e. if you can meet this requirement, your solution will hav= e greater chances to be selected than a solution without, is it acceptable = to keep the "SHOULD" in the draft? OK or NOK?=20 Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mardi 12 mars 2013 14:40 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc=A0: MORAND Lionel OLNC/OLN; BERRY, Nigel (Nigel); DRAGE, Keith (Keith); = dime@ietf.org; Bessis, Thierry (Thierry) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi, further comments inline: On Mar 12, 2013, at 7:35 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" wrote: [...] > [LM] Using wording in REQ1: "Diameter clients must be able to use the rec= eived load and overload information to support graceful behavior during an = overload condition"=20 > Would it be acceptable for everybody even if maybe not perfect for everyo= ne? > [Nigel]=20 > [Nigel] This is fine by me. Do we need to be more precise at this stage? >=20 > [JJ2] My important point in my statement is that a Diameter client which = wants to support graceful behavior during an overload condition must receiv= e the overload information on which it will base its graceful behavior incl= uding a graceful shedding. I have no issue about where load balancing is do= ne (and in practice DAs have a key role there), but if traffic must be redu= ced (shedding), I have the requirement to allow the Diameter client to be = informed of this overload situation by receiving the overload information s= o to have a graceful behavior with graceful shedding rather than to do the= shedding in the DA. Otherwise, if this possibility is not offered, I have = no graceful behavior because no overlaod info is given to the client, shedd= ing being done by the DA. Do you consider your new wording covers this requ= irement? If yes, OK, but on my side, I am not yet sure. It is a key point.= =20 >=20 > [JJ2] As I also said, my above statement is also compliant with Ben's ex= ample (cf parallel mail) with an intermediate DA that is doing load balanc= ing to other servers and may solve overload without traffic shedding. But,= if, nevertheless, after load balancing, it remains a global/aggregated o= verload, in this case, I have the same requirement as above to allow the D= iameter client to be informed of this overload, so that it can have a gra= ceful behavior and shedding.=20=20=20=20 >=20 If we understand that a requirement for the client to receive overload info= rmation doesn't mean it has to receive the information that the server sent= , and it doesn't mean it has to receive it at all if an agent 1) exists, an= d 2) can handle the condition locally and transparently, then I'm reasonabl= y okay with that. But I've seen a few comments that suggest a general prefe= rence for handling overload as close to the client as possible. I'm not opp= osed to it being possible to do so, but I don't want to be prevented from t= aking a "handle it as close to the server as I can" approach either. Isn't the actual requirement that the "Client is able to behave gracefully = during an overload condition"? I can think of a number of ways to accomplish that off-hand: 1) Direct clie= nt-server connection. 2) Agent completely handles overload without dropping= requests. 3) Agent sends an aggregate overload report to the client. 4) Ag= ent drops requests locally, and informs client of dropped requests with an = error message. I'm sure there's more. Each of these might be better or worse than the others--but the criteria sh= ould be how well the solution supports graceful client behavior, not the de= tails of how it accomplishes it. (I recognize that option 4 may have issues= , but those issues can still be measured according to how well the client c= an implement graceful behavior.) Going beyond that is solution, not requir= ements. [...] > [JJ] As I said, the deployment with DAs not supporting the mechanism must= not be excluded, so this implies the solution to support this case and dri= ves to a MUST in REQ 35. Then we will see if we have a solution fulfilling = the requirement=20 > [Nigel]=20=20 > [Nigel] This is a "must" for the normal Client-Server case. In the Proxy = case, the Client should also be informed that actions are being taken to su= bsume an overload situation even if the Proxy attempts to take care of this. >=20 >=20 > [LM] I don't understand! A (hypothetical) solution that would use a dedic= ated signaling channel between nodes supporting overload control and not in= volving the DAs would also comply with the general requirement for overload= control (in theory), right?=20 >=20 > [Nigel] But should we not consider the normal cases before any hypothetic= al cases. > [JJ2)] I have not spoken of a dedicated signaling channel; but here we ar= e entering the solutions space. We can imagine solutions where the overload= info is simply transferred downstream by a DA not supporting the mechanism= =20=20=20=20 > _ I don't think we can declare either a direct client-server connection archi= tecture, or an agent based architecture, as the _normal_ case. Both exist i= n the wild. I agree the solution should work in the direct client-server co= nnection case, but if agents can provide additional value, we should not pr= ejudice the solution effort away from considering that. Thanks! Ben. ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Tue Mar 12 07:45:17 2013 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 1D44D21F89B5 for ; Tue, 12 Mar 2013 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ2d6-tv9YwL for ; Tue, 12 Mar 2013 07:45:16 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8421F8A84 for ; Tue, 12 Mar 2013 07:44:58 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CEhrnQ067377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 09:43:53 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 12 Mar 2013 10:43:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 14:45:17 -0000 Hi comments inline: On Mar 12, 2013, at 9:59 AM, wrote: > Hi, >=20 > Honestly, I don't understand why we have to go down each time to the = solution space to understand a requirement! > Can we try to make it simple when possible? My solution examples were intended to illustrate that there can be more = than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. >=20 > 1/ REQ 2 complement: >=20 > Based on the different comments, my proposal for the new requirement = is the following:=20 > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >=20 > And the question is: OK or NOK i.e. can you live with? Grudgingly OK, with the provision that this allows but does not require = the information to be sent end-to-end from server to client.=20 I would be _considerably_ happier with something of the form of "The = solution must support graceful client behavior during an overload = condition." >=20 > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for = solution designers i.e. if you can meet this requirement, your solution = will have greater chances to be selected than a solution without, is it = acceptable to keep the "SHOULD" in the draft? >=20 > OK or NOK?=20 >=20 OK. I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable.=20 Have we accepted the requirement(s) about working both with or without = agents? [...] From lionel.morand@orange.com Tue Mar 12 07:53:04 2013 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 2A82921F8A48 for ; Tue, 12 Mar 2013 07:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDdjmQS30njq for ; Tue, 12 Mar 2013 07:53:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 52D9421F81FF for ; Tue, 12 Mar 2013 07:53:03 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6280422C277; Tue, 12 Mar 2013 15:53:02 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2FB5827C064; Tue, 12 Mar 2013 15:53:02 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 15:53:01 +0100 From: To: Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+CAABnGgIAAEw6w///+wYCAABHQkA== Date: Tue, 12 Mar 2013 14:53:00 +0000 Message-ID: <3470_1363099982_513F414E_3470_1300_4_6B7134B31289DC4FAF731D844122B36E15F0C2@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 14:53:04 -0000 Hi Ben, The requirement on DA in the path or not was agreed in a previous mail by t= he people involved in this discussion. About the req2 complement, I think that the strong point is that the client= needs to receive info. So keep the text as it is if OK. For REQ 35, the "SHOULD" seems to better than a "MUST but". It is why I pro= pose to keep the current "SHOULD". And it clearly indicates the preference = for a solution supporting such scenarios. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mardi 12 mars 2013 15:44 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, K= eith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi comments inline: On Mar 12, 2013, at 9:59 AM, wrote: > Hi, >=20 > Honestly, I don't understand why we have to go down each time to the solu= tion space to understand a requirement! > Can we try to make it simple when possible? My solution examples were intended to illustrate that there can be more tha= n one solution approach, and we should be careful not to over-constrain the= solution in the requirements. I did not mean for any of them to be assumed= as the "real" solution. >=20 > 1/ REQ 2 complement: >=20 > Based on the different comments, my proposal for the new requirement is t= he following:=20 > "Diameter clients must be able to use the received load and overload info= rmation to support graceful behavior during an overload condition" >=20 > And the question is: OK or NOK i.e. can you live with? Grudgingly OK, with the provision that this allows but does not require the= information to be sent end-to-end from server to client.=20 I would be _considerably_ happier with something of the form of "The soluti= on must support graceful client behavior during an overload condition." >=20 > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for sol= ution designers i.e. if you can meet this requirement, your solution will h= ave greater chances to be selected than a solution without, is it acceptabl= e to keep the "SHOULD" in the draft? >=20 > OK or NOK?=20 >=20 OK. I would also accept a MUST, with the understanding that there may be limita= tions on what a non-supporting intermediary can do and still be traversable= .=20 Have we accepted the requirement(s) about working both with or without agen= ts? [...] ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Tue Mar 12 08:04:39 2013 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 539BF21F81FF for ; Tue, 12 Mar 2013 08:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VdTapBjjdyE for ; Tue, 12 Mar 2013 08:04:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA3E21F8462 for ; Tue, 12 Mar 2013 08:04:30 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CF4InZ069693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 10:04:20 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <3470_1363099982_513F414E_3470_1300_4_6B7134B31289DC4FAF731D844122B36E15F0C2@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 12 Mar 2013 11:04:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BDC3075-0253-4620-AF18-5B5C46D21E97@nostrum.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <3470_1363099982_513F414E_3470_1300_4_6B7134B31289DC4FAF731D844122B36E15F0C2@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:04:39 -0000 On Mar 12, 2013, at 10:53 AM, wrote: > Hi Ben, >=20 > The requirement on DA in the path or not was agreed in a previous mail = by the people involved in this discussion. >=20 > About the req2 complement, I think that the strong point is that the = client needs to receive info. So keep the text as it is if OK. You've stuck the heart of the "grudging" part of my "OK". At the risk = of further splitting the hair, I think the main point is "graceful = behavior". That is, a requirement to "receive info" without a = requirement to "support graceful behavior" is insufficient. A = requirement to "support graceful behavior" can stand on its own without = any requirements about information flow. >=20 > For REQ 35, the "SHOULD" seems to better than a "MUST but". It is why = I propose to keep the current "SHOULD". And it clearly indicates the = preference for a solution supporting such scenarios. >=20 For the record, I'm okay with "SHOULD". My additional comments were in = anticipation of others' NOK. > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mardi 12 mars 2013 15:44 > =C0 : MORAND Lionel OLNC/OLN > Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); = DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi comments inline: >=20 > On Mar 12, 2013, at 9:59 AM, wrote: >=20 >> Hi, >>=20 >> Honestly, I don't understand why we have to go down each time to the = solution space to understand a requirement! >> Can we try to make it simple when possible? >=20 > My solution examples were intended to illustrate that there can be = more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. >=20 >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement = is the following:=20 >> "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client.=20 >=20 > I would be _considerably_ happier with something of the form of "The = solution must support graceful client behavior during an overload = condition." >=20 >=20 >>=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for = solution designers i.e. if you can meet this requirement, your solution = will have greater chances to be selected than a solution without, is it = acceptable to keep the "SHOULD" in the draft? >>=20 >> OK or NOK?=20 >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable.=20 >=20 > Have we accepted the requirement(s) about working both with or without = agents? >=20 >=20 > [...] >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - 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 = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From lionel.morand@orange.com Tue Mar 12 08:11:31 2013 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 A06D721F8AA1 for ; Tue, 12 Mar 2013 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqLLmmbxWakt for ; Tue, 12 Mar 2013 08:11:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9932B21F8A9E for ; Tue, 12 Mar 2013 08:11:29 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 84E79264A44; Tue, 12 Mar 2013 16:11:18 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5667C27C046; Tue, 12 Mar 2013 16:11:18 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 16:11:17 +0100 From: To: Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+CAABnGgIAAEw6w///+wYCAABHQkP//8+WAgAARYLA= Date: Tue, 12 Mar 2013 15:11:16 +0000 Message-ID: <3474_1363101078_513F4596_3474_3585_12_6B7134B31289DC4FAF731D844122B36E15F117@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <3470_1363099982_513F414E_3470_1300_4_6B7134B31289DC4FAF731D844122B36E15F0C2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0BDC3075-0253-4620-AF18-5B5C46D21E97@nostrum.com> In-Reply-To: <0BDC3075-0253-4620-AF18-5B5C46D21E97@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.12.123320 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:11:31 -0000 Hi Ben, > The requirement on DA in the path or not was agreed in a previous mail by= the people involved in this discussion. >=20 > About the req2 complement, I think that the strong point is that the clie= nt needs to receive info. So keep the text as it is if OK. You've stuck the heart of the "grudging" part of my "OK". At the risk of f= urther splitting the hair, I think the main point is "graceful behavior". T= hat is, a requirement to "receive info" without a requirement to "support g= raceful behavior" is insufficient. A requirement to "support graceful behav= ior" can stand on its own without any requirements about information flow. [LM] this is true for any Diameter peer. You can do a lot of thing without = receiving explicit info. But I think that in this document we have to focus= on what to do when explicit info is available/received. And this requireme= nt is then correct in this context, right? It does not preclude to adopt a = graceful behavior without this info. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: mardi 12 mars 2013 16:04 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, K= eith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 On Mar 12, 2013, at 10:53 AM, wrote: > Hi Ben, >=20 > The requirement on DA in the path or not was agreed in a previous mail by= the people involved in this discussion. >=20 > About the req2 complement, I think that the strong point is that the clie= nt needs to receive info. So keep the text as it is if OK. You've stuck the heart of the "grudging" part of my "OK". At the risk of f= urther splitting the hair, I think the main point is "graceful behavior". T= hat is, a requirement to "receive info" without a requirement to "support g= raceful behavior" is insufficient. A requirement to "support graceful behav= ior" can stand on its own without any requirements about information flow. >=20 > For REQ 35, the "SHOULD" seems to better than a "MUST but". It is why I p= ropose to keep the current "SHOULD". And it clearly indicates the preferenc= e for a solution supporting such scenarios. >=20 For the record, I'm okay with "SHOULD". My additional comments were in anti= cipation of others' NOK. > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mardi 12 mars 2013 15:44 > =C0 : MORAND Lionel OLNC/OLN > Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, K= eith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi comments inline: >=20 > On Mar 12, 2013, at 9:59 AM, wrote: >=20 >> Hi, >>=20 >> Honestly, I don't understand why we have to go down each time to the sol= ution space to understand a requirement! >> Can we try to make it simple when possible? >=20 > My solution examples were intended to illustrate that there can be more t= han one solution approach, and we should be careful not to over-constrain t= he solution in the requirements. I did not mean for any of them to be assum= ed as the "real" solution. >=20 >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement is = the following:=20 >> "Diameter clients must be able to use the received load and overload inf= ormation to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not require t= he information to be sent end-to-end from server to client.=20 >=20 > I would be _considerably_ happier with something of the form of "The solu= tion must support graceful client behavior during an overload condition." >=20 >=20 >>=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK?=20 >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le.=20 >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? >=20 >=20 > [...] >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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, > France Telecom - 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 i= nformation 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Tue Mar 12 08:14:11 2013 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 8013111E80AD for ; Tue, 12 Mar 2013 08:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcyGhpxkB0Q4 for ; Tue, 12 Mar 2013 08:14:10 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5297C11E809C for ; Tue, 12 Mar 2013 08:14:10 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CFE1Gw070773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 10:14:02 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <3474_1363101078_513F4596_3474_3585_12_6B7134B31289DC4FAF731D844122B36E15F117@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 12 Mar 2013 11:13:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <3470_1363099982_513F414E_3470_1300_4_6B7134B31289DC4FAF731D844122B36E15F0C2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <0BDC3075-0253-4620-AF18-5B5C46D21E97@nostrum.com> <3474_1363101078_513F4596_3474_3585_12_6B7134B31289DC4FAF731D844122B36E15F117@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:14:11 -0000 On Mar 12, 2013, at 11:11 AM, wrote: > Hi Ben, >=20 >> The requirement on DA in the path or not was agreed in a previous = mail by the people involved in this discussion. >>=20 >> About the req2 complement, I think that the strong point is that the = client needs to receive info. So keep the text as it is if OK. >=20 > You've stuck the heart of the "grudging" part of my "OK". At the risk = of further splitting the hair, I think the main point is "graceful = behavior". That is, a requirement to "receive info" without a = requirement to "support graceful behavior" is insufficient. A = requirement to "support graceful behavior" can stand on its own without = any requirements about information flow. >=20 > [LM] this is true for any Diameter peer. You can do a lot of thing = without receiving explicit info. But I think that in this document we = have to focus on what to do when explicit info is available/received. = And this requirement is then correct in this context, right? It does not = preclude to adopt a graceful behavior without this info. OK, call it an OK :-) >=20 > Regards, >=20 > Lionel >=20 > -----Message d'origine----- > De : Ben Campbell [mailto:ben@nostrum.com]=20 > Envoy=E9 : mardi 12 mars 2013 16:04 > =C0 : MORAND Lionel OLNC/OLN > Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); = DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 >=20 > On Mar 12, 2013, at 10:53 AM, wrote: >=20 >> Hi Ben, >>=20 >> The requirement on DA in the path or not was agreed in a previous = mail by the people involved in this discussion. >>=20 >> About the req2 complement, I think that the strong point is that the = client needs to receive info. So keep the text as it is if OK. >=20 > You've stuck the heart of the "grudging" part of my "OK". At the risk = of further splitting the hair, I think the main point is "graceful = behavior". That is, a requirement to "receive info" without a = requirement to "support graceful behavior" is insufficient. A = requirement to "support graceful behavior" can stand on its own without = any requirements about information flow. >=20 >>=20 >> For REQ 35, the "SHOULD" seems to better than a "MUST but". It is why = I propose to keep the current "SHOULD". And it clearly indicates the = preference for a solution supporting such scenarios. >>=20 >=20 > For the record, I'm okay with "SHOULD". My additional comments were in = anticipation of others' NOK. >=20 >> Regards, >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : Ben Campbell [mailto:ben@nostrum.com]=20 >> Envoy=E9 : mardi 12 mars 2013 15:44 >> =C0 : MORAND Lionel OLNC/OLN >> Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); = DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) >> Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >>=20 >> Hi comments inline: >>=20 >> On Mar 12, 2013, at 9:59 AM, wrote: >>=20 >>> Hi, >>>=20 >>> Honestly, I don't understand why we have to go down each time to the = solution space to understand a requirement! >>> Can we try to make it simple when possible? >>=20 >> My solution examples were intended to illustrate that there can be = more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. >>=20 >>>=20 >>> 1/ REQ 2 complement: >>>=20 >>> Based on the different comments, my proposal for the new requirement = is the following:=20 >>> "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >>>=20 >>> And the question is: OK or NOK i.e. can you live with? >>=20 >> Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client.=20 >>=20 >> I would be _considerably_ happier with something of the form of "The = solution must support graceful client behavior during an overload = condition." >>=20 >>=20 >>>=20 >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? >>>=20 >>> OK or NOK?=20 >>>=20 >>=20 >> OK. >>=20 >> I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable.=20 >>=20 >> Have we accepted the requirement(s) about working both with or = without agents? >>=20 >>=20 >> [...] >>=20 >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> 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, >> France Telecom - 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 delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >>=20 >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - 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 = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From nigel.berry@alcatel-lucent.com Tue Mar 12 08:33:21 2013 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 EEBC321F8D02 for ; Tue, 12 Mar 2013 08:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.541 X-Spam-Level: X-Spam-Status: No, score=-9.541 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKIpp21ZyMmO for ; Tue, 12 Mar 2013 08:33:21 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 208BB21F8CF3 for ; Tue, 12 Mar 2013 08:33:20 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CFWmVe005025 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 16:33:20 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 16:33:18 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 16:33:15 +0100 From: "BERRY, Nigel (Nigel)" To: Ben Campbell , "lionel.morand@orange.com" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jygxSW8PDeSFK3yPO6PRffLZhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+DnZRZIgIAABWUAgAAMaYD//+QNUA== Date: Tue, 12 Mar 2013 15:33:14 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:33:22 -0000 Hi Lionel, JJ's laptop is on the blink so I will attempt to answer, See in-line, Kind Regards, Nigel -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: 12 March 2013 14:44 To: lionel.morand@orange.com Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keit= h (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi comments inline: On Mar 12, 2013, at 9:59 AM, wrote: > Hi, > > Honestly, I don't understand why we have to go down each time to the solu= tion space to understand a requirement! > Can we try to make it simple when possible? My solution examples were intended to illustrate that there can be more tha= n one solution approach, and we should be careful not to over-constrain the= solution in the requirements. I did not mean for any of them to be assumed= as the "real" solution. [Nigel] I agree with Ben we have to dip our toe in the water of potential s= olutions that deal with all scenarios in order to understand the correct wo= rding of requirements. > > 1/ REQ 2 complement: > > Based on the different comments, my proposal for the new requirement is t= he following: > "Diameter clients must be able to use the received load and overload info= rmation to support graceful behavior during an overload condition" > > And the question is: OK or NOK i.e. can you live with? Grudgingly OK, with the provision that this allows but does not require the= information to be sent end-to-end from server to client. I would be _considerably_ happier with something of the form of "The soluti= on must support graceful client behavior during an overload condition." [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the r= eceived load and overload information to support graceful behavior during a= n overload condition" providing a necessary consequence of graceful behavio= ur may involve drastic load shedding at the client or the active proxy. > > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for sol= ution designers i.e. if you can meet this requirement, your solution will h= ave greater chances to be selected than a solution without, is it acceptabl= e to keep the "SHOULD" in the draft? > > OK or NOK? > OK. I would also accept a MUST, with the understanding that there may be limita= tions on what a non-supporting intermediary can do and still be traversable= . [Nigel] A number of people prefer the "must" so can we compromise on this u= se if Ben can accept this, so we can ensure the Client gets the appropriate= information so it can act if necessary Have we accepted the requirement(s) about working both with or without agen= ts? [Nigel] Ben, I am not sure which Requirement you are referring to but the s= olution has to work with and without Diameter Agents (stateful or not state= ful) involved so any requirement should not disallow these scenarios. [...] From lionel.morand@orange.com Tue Mar 12 08:43:40 2013 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 6940E21F8CDB for ; Tue, 12 Mar 2013 08:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO0je8quS8W1 for ; Tue, 12 Mar 2013 08:43:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC921F8BEB for ; Tue, 12 Mar 2013 08:43:39 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 635CB22CC67; Tue, 12 Mar 2013 16:43:38 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 27D4E238055; Tue, 12 Mar 2013 16:43:38 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 12 Mar 2013 16:43:37 +0100 From: To: "BERRY, Nigel (Nigel)" , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jy6il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+DnZRZIgIAABWUAgAAMaYD//+QNUP//xKXw Date: Tue, 12 Mar 2013 15:43:37 +0000 Message-ID: <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.12.123320 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:43:40 -0000 Almost the end :) Remaining issue: REQ35 > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for sol= ution designers i.e. if you can meet this requirement, your solution will h= ave greater chances to be selected than a solution without, is it acceptabl= e to keep the "SHOULD" in the draft? > > OK or NOK? > OK. I would also accept a MUST, with the understanding that there may be limita= tions on what a non-supporting intermediary can do and still be traversable. [Nigel] A number of people prefer the "must" so can we compromise on this u= se if Ben can accept this, so we can ensure the Client gets the appropriate= information so it can act if necessary [LM] Not so sure about the number of voices for the "MUST"... Have we accepted the requirement(s) about working both with or without agen= ts? [Nigel] Ben, I am not sure which Requirement you are referring to but the s= olution has to work with and without Diameter Agents (stateful or not state= ful) involved so any requirement should not disallow these scenarios. [LM] this requirement was agreed: "The solution MUST work in the presence o= r absence of Diameter agents between Diameter clients and servers" -----Message d'origine----- De=A0: BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com]=20 Envoy=E9=A0: mardi 12 mars 2013 16:33 =C0=A0: Ben Campbell; MORAND Lionel OLNC/OLN Cc=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); dime@iet= f.org; Bessis, Thierry (Thierry) Objet=A0: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, JJ's laptop is on the blink so I will attempt to answer, See in-line, Kind Regards, Nigel -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: 12 March 2013 14:44 To: lionel.morand@orange.com Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keit= h (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi comments inline: On Mar 12, 2013, at 9:59 AM, wrote: > Hi, > > Honestly, I don't understand why we have to go down each time to the solu= tion space to understand a requirement! > Can we try to make it simple when possible? My solution examples were intended to illustrate that there can be more tha= n one solution approach, and we should be careful not to over-constrain the= solution in the requirements. I did not mean for any of them to be assumed= as the "real" solution. [Nigel] I agree with Ben we have to dip our toe in the water of potential s= olutions that deal with all scenarios in order to understand the correct wo= rding of requirements. > > 1/ REQ 2 complement: > > Based on the different comments, my proposal for the new requirement is t= he following: > "Diameter clients must be able to use the received load and overload info= rmation to support graceful behavior during an overload condition" > > And the question is: OK or NOK i.e. can you live with? Grudgingly OK, with the provision that this allows but does not require the= information to be sent end-to-end from server to client. I would be _considerably_ happier with something of the form of "The soluti= on must support graceful client behavior during an overload condition." [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the r= eceived load and overload information to support graceful behavior during a= n overload condition" providing a necessary consequence of graceful behavio= ur may involve drastic load shedding at the client or the active proxy. > > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for sol= ution designers i.e. if you can meet this requirement, your solution will h= ave greater chances to be selected than a solution without, is it acceptabl= e to keep the "SHOULD" in the draft? > > OK or NOK? > OK. I would also accept a MUST, with the understanding that there may be limita= tions on what a non-supporting intermediary can do and still be traversable. [Nigel] A number of people prefer the "must" so can we compromise on this u= se if Ben can accept this, so we can ensure the Client gets the appropriate= information so it can act if necessary Have we accepted the requirement(s) about working both with or without agen= ts? [Nigel] Ben, I am not sure which Requirement you are referring to but the s= olution has to work with and without Diameter Agents (stateful or not state= ful) involved so any requirement should not disallow these scenarios. [...] ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From nigel.berry@alcatel-lucent.com Tue Mar 12 08:59:06 2013 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 5DFA111E80FD for ; Tue, 12 Mar 2013 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjOTZpaOw-px for ; Tue, 12 Mar 2013 08:59:05 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id E9A6A11E80FB for ; Tue, 12 Mar 2013 08:59:04 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CFx1ki010602 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 16:59:02 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 16:59:01 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 16:59:01 +0100 From: "BERRY, Nigel (Nigel)" To: "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: Ac4be8jygxSW8PDeSFK3yPO6PRffLZhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+DnZRZIgIAABWUAgAAMaYD//+QNUP//xKXw//+FKaA= Date: Tue, 12 Mar 2013 15:59:00 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:59:06 -0000 Hi Lionel, See in line, Kind Regards, Nigel -----Original Message----- From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: 12 March 2013 15:44 To: BERRY, Nigel (Nigel); Ben Campbell Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.o= rg; Bessis, Thierry (Thierry) Subject: RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Almost the end :) Remaining issue: REQ35 > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for sol= ution designers i.e. if you can meet this requirement, your solution will h= ave greater chances to be selected than a solution without, is it acceptabl= e to keep the "SHOULD" in the draft? > > OK or NOK? > OK. I would also accept a MUST, with the understanding that there may be limita= tions on what a non-supporting intermediary can do and still be traversable= . [Nigel] A number of people prefer the "must" so can we compromise on this u= se if Ben can accept this, so we can ensure the Client gets the appropriate= information so it can act if necessary [LM] Not so sure about the number of voices for the "MUST"... [Nigel] [Nigel] Can you not check who can not compromise on the use of "must"? Have we accepted the requirement(s) about working both with or without agen= ts? [Nigel] Ben, I am not sure which Requirement you are referring to but the s= olution has to work with and without Diameter Agents (stateful or not state= ful) involved so any requirement should not disallow these scenarios. [LM] this requirement was agreed: "The solution MUST work in the presence o= r absence of Diameter agents between Diameter clients and servers" [Nigel] OK, that's fine. -----Message d'origine----- De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] Envoy=E9 : mardi 12 mars 2013 16:33 =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.= org; Bessis, Thierry (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi Lionel, JJ's laptop is on the blink so I will attempt to answer, See in-line, Kind Regards, Nigel -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com] Sent: 12 March 2013 14:44 To: lionel.morand@orange.com Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, Keit= h (Keith); dime@ietf.org; Bessis, Thierry (Thierry) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hi comments inline: On Mar 12, 2013, at 9:59 AM, wrote: > Hi, > > Honestly, I don't understand why we have to go down each time to the solu= tion space to understand a requirement! > Can we try to make it simple when possible? My solution examples were intended to illustrate that there can be more tha= n one solution approach, and we should be careful not to over-constrain the= solution in the requirements. I did not mean for any of them to be assumed= as the "real" solution. [Nigel] I agree with Ben we have to dip our toe in the water of potential s= olutions that deal with all scenarios in order to understand the correct wo= rding of requirements. > > 1/ REQ 2 complement: > > Based on the different comments, my proposal for the new requirement is t= he following: > "Diameter clients must be able to use the received load and overload info= rmation to support graceful behavior during an overload condition" > > And the question is: OK or NOK i.e. can you live with? Grudgingly OK, with the provision that this allows but does not require the= information to be sent end-to-end from server to client. I would be _considerably_ happier with something of the form of "The soluti= on must support graceful client behavior during an overload condition." [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the r= eceived load and overload information to support graceful behavior during a= n overload condition" providing a necessary consequence of graceful behavio= ur may involve drastic load shedding at the client or the active proxy. > > 2/ REQ 35: > With the clarification that the "SHOULD" is strong recommendation for sol= ution designers i.e. if you can meet this requirement, your solution will h= ave greater chances to be selected than a solution without, is it acceptabl= e to keep the "SHOULD" in the draft? > > OK or NOK? > OK. I would also accept a MUST, with the understanding that there may be limita= tions on what a non-supporting intermediary can do and still be traversable= . [Nigel] A number of people prefer the "must" so can we compromise on this u= se if Ben can accept this, so we can ensure the Client gets the appropriate= information so it can act if necessary Have we accepted the requirement(s) about working both with or without agen= ts? [Nigel] Ben, I am not sure which Requirement you are referring to but the s= olution has to work with and without Diameter Agents (stateful or not state= ful) involved so any requirement should not disallow these scenarios. [...] ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Tue Mar 12 09:56:25 2013 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 BF7C111E8101 for ; Tue, 12 Mar 2013 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD5zCsK6BGFx for ; Tue, 12 Mar 2013 09:56:17 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 439BB11E80EF for ; Tue, 12 Mar 2013 09:56:06 -0700 (PDT) Received: from [10.0.1.2] (dhcp-431a.meeting.ietf.org [130.129.67.26]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2CGsobZ082074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 11:54:51 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Tue, 12 Mar 2013 12:54:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F8F3A9E-846E-433C-8BBF-A8EC9F5F4D38@nostrum.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_6B7134B31289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "BERRY, Nigel (Nigel)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.67.26 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 16:56:25 -0000 On Mar 12, 2013, at 11:33 AM, "BERRY, Nigel (Nigel)" = wrote: >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement = is the following: >> "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client. >=20 > I would be _considerably_ happier with something of the form of "The = solution must support graceful client behavior during an overload = condition." > [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use = the received load and overload information to support graceful behavior = during an overload condition" providing a necessary consequence of = graceful behaviour may involve drastic load shedding at the client or = the active proxy. Agreed. I think people understand that "graceful behavior during an = overload condition" doesn't mean everything always works normally as if = there were no overload. It sometimes means dropped requests, and errors = back to end users . We're trying to avoid things like request retry = storms, users left hanging, poor prioritization, etc. From jouni.nospam@gmail.com Tue Mar 12 10:42:37 2013 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 C4B1311E80F3 for ; Tue, 12 Mar 2013 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfKU79tLc02W for ; Tue, 12 Mar 2013 10:42:30 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDD511E80D2 for ; Tue, 12 Mar 2013 10:42:27 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xa12so92169pbc.22 for ; Tue, 12 Mar 2013 10:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=M406mJiSwv6f8PxCaIkKvXQsspkBYeUzP+JxkjL3KsU=; b=IfXwNepgOMCGnQ/kpPORkN4hSn4zYOw/GiXCTc2iI/SG5VU71TP8dsfSiQ6s7AbRna pA8n6dyoq4uZLT86MjD7lawqaypqXPALZj9tog/JNvG0k5zk+2RNffG6tystGKNyI2Nc IU539vM9vSDI1Da7FY3WboGZcxNKyzN8OtTEUjPRLXT3FAHpFz4htwruZ/0Cr8brAr1b zkoLmJmu9XUyH2Ye+IlnzHDSXOZ61cLAn87T1af00nGBj8rpu3/M3Bbw/N2+GQxrOrqE iPNeKFF7x36GRtExEgQ0A5AyhLZ6AikwvsAWpVj/XiRaUS7rHB4wtZwyrZj4mEAe3S6H 8iNg== X-Received: by 10.68.244.225 with SMTP id xj1mr35371900pbc.119.1363110147068; Tue, 12 Mar 2013 10:42:27 -0700 (PDT) Received: from ?IPv6:2001:df8::64:7551:a8f8:6e64:886d? ([2001:df8:0:64:7551:a8f8:6e64:886d]) by mx.google.com with ESMTPS id na4sm22232218pbc.8.2013.03.12.10.42.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 10:42:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <4D810BDA-A73E-46D8-AB0E-059A54E2CBDE@computer.org> Date: Tue, 12 Mar 2013 19:42:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <695A5745-570C-4A6E-8E9B-179A86401CF6@gmail.com> References: <49EC21B2-3086-4B61-8A8E-A129D9C5D661@computer.org> <2D2C8749-2777-49C2-B41E-D82C2B2BE8EC@gmail.com> <8BF787ED-E249-4A81-BAF3-B96021D3FF73@nostrum.com> <4D810BDA-A73E-46D8-AB0E-059A54E2CBDE@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] overload control requirement 7 on stability X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 17:42:37 -0000 WFM. On Mar 11, 2013, at 10:20 PM, Eric McMurry = wrote: > Hi Ben, >=20 > That was changed after Jouni's comment. It currently reads: >=20 > The overload control mechanism and any associated default > algorithm(s) MUST ensure that the system remains stable. = At > some point after an overload condition has ended, the > mechanism MUST enable capacity to stabilize and become = equal > to what it would be in the absence of an overload = condition. > Note that this also requires that the mechanism MUST allow > nodes to shed load without introducing non converging > oscillations during or after an overload condition. >=20 > As far as I know, this version addresses all of the comments it has = received. Does that match what you recall Jouni? >=20 > Thanks! >=20 > Eric >=20 >=20 > On Mar 11, 2013, at 15:48 , Ben Campbell wrote: >=20 >> (Sorry for the late response--I just found Jouni's message when going = back over threads to prep for the Orlando meeting) >>=20 >> HI Jouni, do you have any suggestions on how to improve it? >>=20 >> I don't usually think of "throughput" as indicating bandwith or bps. = I think of it in terms of completed transactions, although I think both = measures would qualify. >>=20 >> Other areas have used the word "goodput" when discussing overload and = congestions. I gather the intent is to distinguish between "attempted = work" and "successful work". I personally find that usage awkward and = unnecessary. >>=20 >> On Feb 21, 2013, at 11:14 PM, Jouni Korhonen = wrote: >>=20 >>> >>>=20 >>>=20 >>> I would still argue that "..the mechanism MUST enable throughput.." >>> could use some rewording. The load in the network might not be about >>> 'throughput' as in bps but for example about transactions. >>>=20 >>> - Jouni >>>=20 >>>=20 >>> On Feb 20, 2013, at 9:38 PM, Eric McMurry = wrote: >>>=20 >>>> Req 7 reads: The overload control mechanism and any associated = default >>>> algorithm(s) MUST ensure that the system remains stable. >>>> When the offered load drops from above the overall capacity >>>> of the network to below the overall capacity, the = throughput >>>> MUST stabilize and become equal to the offered load. Note >>>> that this also requires that the mechanism MUST allow nodes >>>> to shed load without introducing oscillations. >>>>=20 >>>>=20 >>>> It has been pointed out that the latter part of this implies = requirements directly on nodes implementing the mechanism, instead of on = the mechanism itself. How does this alternate sound: >>>>=20 >>>>=20 >>>> The overload control mechanism and any associated default >>>> algorithm(s) MUST ensure that the system remains stable. >>>> When the offered load drops from above the overall capacity >>>> of the network to below the overall capacity, the mechanism >>>> MUST enable throughput to stabilize and become >>>> equal to the offered load. Note >>>> that this also requires that the mechanism MUST allow nodes >>>> to shed load without introducing oscillations. >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Eric >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >=20 From emcmurry@computer.org Tue Mar 12 14:41:50 2013 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 F39D121F8C1F for ; Tue, 12 Mar 2013 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwS5ktuXfrtK for ; Tue, 12 Mar 2013 14:41:49 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26421F8C1A for ; Tue, 12 Mar 2013 14:41:49 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1UFWxA-000NSC-NA; Tue, 12 Mar 2013 21:41:48 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 0E06223A7050; Tue, 12 Mar 2013 16:41:47 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ac7u771K8gAB2NQSM2wm4vM5JEEzgc0I= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19RuLIYdh11y; Tue, 12 Mar 2013 16:41:46 -0500 (CDT) Received: from time.apple.com (87-231-241-210.rev.numericable.fr [87.231.241.210]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 836F623A703F; Tue, 12 Mar 2013 16:41:45 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 12 Mar 2013 22:41:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_ 6B7134B3 1289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 21:41:50 -0000 I have stated before that I am fine with a MUST provided that the = requirement for end to end security is also added. Traversing = non-supporint elements without this would be folly I believe the best compromise here is to leave it as is, so that more = thought can be put into this without constraining the solution to = something that may be nearly impossible to deploy. It may also be = possible to define the security requirement for specific scenarios where = the risk is higher. This would include a specific requirement (at MUST = level) stating that e2e security is required for traversing = non-supporting elements. I believe that this approach is generally = consistent with what some have been discussing about using a MUST level = on 35 along with constraints. Eric On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > Almost the end :) >=20 > Remaining issue: REQ35 >=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for = solution designers i.e. if you can meet this requirement, your solution = will have greater chances to be selected than a solution without, is it = acceptable to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable. >=20 > [Nigel] A number of people prefer the "must" so can we compromise on = this use if Ben can accept this, so we can ensure the Client gets the = appropriate information so it can act if necessary >=20 > [LM] Not so sure about the number of voices for the "MUST"... >=20 > Have we accepted the requirement(s) about working both with or without = agents? > [Nigel] Ben, I am not sure which Requirement you are referring to but = the solution has to work with and without Diameter Agents (stateful or = not stateful) involved so any requirement should not disallow these = scenarios. >=20 > [LM] this requirement was agreed: "The solution MUST work in the = presence or absence of Diameter agents between Diameter clients and = servers" >=20 >=20 > -----Message d'origine----- > De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com]=20 > Envoy=E9 : mardi 12 mars 2013 16:33 > =C0 : Ben Campbell; MORAND Lionel OLNC/OLN > Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); DRAGE, Keith (Keith); = dime@ietf.org; Bessis, Thierry (Thierry) > Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi Lionel, > JJ's laptop is on the blink so I will attempt to answer, > See in-line, > Kind Regards, > Nigel >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 12 March 2013 14:44 > To: lionel.morand@orange.com > Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, = Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi comments inline: >=20 > On Mar 12, 2013, at 9:59 AM, wrote: >=20 >> Hi, >>=20 >> Honestly, I don't understand why we have to go down each time to the = solution space to understand a requirement! >> Can we try to make it simple when possible? >=20 > My solution examples were intended to illustrate that there can be = more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. > [Nigel] I agree with Ben we have to dip our toe in the water of = potential solutions that deal with all scenarios in order to understand = the correct wording of requirements. >=20 >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement = is the following: >> "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client. >=20 > I would be _considerably_ happier with something of the form of "The = solution must support graceful client behavior during an overload = condition." > [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use = the received load and overload information to support graceful behavior = during an overload condition" providing a necessary consequence of = graceful behaviour may involve drastic load shedding at the client or = the active proxy. >=20 >=20 >>=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for = solution designers i.e. if you can meet this requirement, your solution = will have greater chances to be selected than a solution without, is it = acceptable to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable. > [Nigel] A number of people prefer the "must" so can we compromise on = this use if Ben can accept this, so we can ensure the Client gets the = appropriate information so it can act if necessary >=20 > Have we accepted the requirement(s) about working both with or without = agents? > [Nigel] Ben, I am not sure which Requirement you are referring to but = the solution has to work with and without Diameter Agents (stateful or = not stateful) involved so any requirement should not disallow these = scenarios. >=20 >=20 > [...] >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - 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 = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Wed Mar 13 01:36:11 2013 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 4547221F8D11 for ; Wed, 13 Mar 2013 01:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.022 X-Spam-Level: X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUraOwC9-xem for ; Wed, 13 Mar 2013 01:36:10 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8121F894D for ; Wed, 13 Mar 2013 01:36:09 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-93-51403a7756bf Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B2.22.19728.77A30415; Wed, 13 Mar 2013 09:36:08 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.29]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 09:36:07 +0100 From: Maria Cruz Bartolome To: Eric McMurry , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHOH2pjgxSW8PDeSFK3yPO6PRffLZijQXOg Date: Wed, 13 Mar 2013 08:36:06 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_ 6B7134B3 1289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: 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+NgFnrJLMWRmVeSWpSXmKPExsUyM+JvjW6FlUOgwcTfPBZze1ewWTReecNs 8bTxLKPF7e2ZFqe2PWS0OLSv0oHNo/XZXlaPllW9zB5Llvxk8mh5dpItgCWKyyYlNSezLLVI 3y6BK+PIlFUsBe/CKi6faGJpYLzq2sXIySEhYCJxqv8ZM4QtJnHh3no2EFtI4BCjxNNtKl2M XED2YkaJ03ePMIEk2ATsJC6dfsEEkhARaGKU+PxqEQuIwyywk1Fi8uR77CBVwgLWEq/bLoGN FRGwkXh+/wsThG0ksebpeyCbg4NFQFXi5CIJkDCvgLfE3R0rGSE2X+OVuLY2GsTmFHCQ+LDi GVicEei676fWgI1hFhCXuPVkPhPE1QISS/ach/pAVOLl43+sELaixMdX+xgh6vUkbkydwgZh a0ssW/iaGWKvoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKkT03MTMnvdxoEyMwug5u+a26 g/HOOZFDjNIcLErivOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MGpETgrNzVN3kjTT eN9/wEvp8VuPEgOzkxPU5wqFp9qrWTq9Kayyifm5QC5/zr6il6mMd4WTtC1CFq/+s2d6/MXT P9wdptlrHy6tfdn8dxb/9+q53AuvOC6ULPqfa8//xGLR/1sVjWtYPDOrT3ju5vrxSajroNvq zystvfrPPFjyO8tlx4HER0osxRmJhlrMRcWJAOI1Wvt8AgAA Cc: "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 08:36:11 -0000 Hello all, Trying to summarize a bit, for my own clarification here and agreement. I think latest proposals are: REQ-35: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D REQ-35 (now in draft v.5): REQ 35: The mechanism SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism REQ-35 (proposal): "The solution MUST work in the presence or absence of Diameter agents betw= een Diameter clients and servers" =20 I think there is something to add to reflect everything cover by former req= uirement: REQ-35 (new proposal): "The solution MUST work in the presence or absence of Diameter agents betw= een Diameter clients and servers, regardless whether or not Diameter agents= support the overload control mechanism" Although this may be considered covered by REQ-16: REQ 16: The overload control mechanism is likely to be deployed incrementally. The mechanism MUST support a mixed environment where some, but not all, nodes implement it. But I presume it does not harm to be explicit here, like in former requirem= ent. About the comment by Eric on security (just mail below), we need to check t= hen whether REQ-30 need to be modified, or a new requirement shall apply, r= ight? REQ 30: The mechanism MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the mechanism to detect, or take countermeasures against, malicious nodes. REQ-2 complement: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D First, I could accept the proposal we got now on the table, I do not want t= o keep discussion forever, but... I'd like to propose some enhancements tha= t I think cover all people concerns stated so far, hopefully without rasing= disagreements. Proposal now is:=20 "Diameter clients must be able to use the received load and overload inform= ation to support graceful behavior during an overload condition" I got some comments on this, taking into account the first proposal was: "The mechanism MUST allow Diameter clients to be aware of an overload situa= tion " I think it is better to request that is "the mechanism" the one that should= provide the means for the client to be able to do something, since we are = specifying what the mechanism shall do in other requirements, like: REQ 1: The overload control mechanism MUST provide a communication method for Diameter nodes to exchange load and overload information. Then my -intermediate- proposal would be the following: "The mechanism MUST allow Diameter clients to support graceful behavior dur= ing an overload situation" Where I think "graceful behavior" is raising some concerns, in facts this i= s not specific enough in my opinion. Good requirement writing would avoid m= ultiple interpretations. Then, what about this: New proposal for REQ-2 complement: "The mechanism MUST allow Diameter clients to act during an overload situat= ion in order to improve it while impacts are minimized" Best regards /MCruz -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: martes, 12 de marzo de 2013 22:42 To: lionel.morand@orange.com Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); BERRY, = Nigel (Nigel) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 I have stated before that I am fine with a MUST provided that the requireme= nt for end to end security is also added. Traversing non-supporint element= s without this would be folly I believe the best compromise here is to leave it as is, so that more thoug= ht can be put into this without constraining the solution to something that= may be nearly impossible to deploy. It may also be possible to define the= security requirement for specific scenarios where the risk is higher. Thi= s would include a specific requirement (at MUST level) stating that e2e sec= urity is required for traversing non-supporting elements. I believe that t= his approach is generally consistent with what some have been discussing ab= out using a MUST level on 35 along with constraints. Eric On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > Almost the end :) >=20 > Remaining issue: REQ35 >=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le. >=20 > [Nigel] A number of people prefer the "must" so can we compromise on=20 > this use if Ben can accept this, so we can ensure the Client gets the=20 > appropriate information so it can act if necessary >=20 > [LM] Not so sure about the number of voices for the "MUST"... >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? > [Nigel] Ben, I am not sure which Requirement you are referring to but the= solution has to work with and without Diameter Agents (stateful or not sta= teful) involved so any requirement should not disallow these scenarios. >=20 > [LM] this requirement was agreed: "The solution MUST work in the presence= or absence of Diameter agents between Diameter clients and servers" >=20 >=20 > -----Message d'origine----- > De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] > Envoy=E9 : mardi 12 mars 2013 16:33 > =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES=20 > (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry=20 > (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi Lionel, > JJ's laptop is on the blink so I will attempt to answer, See in-line,=20 > Kind Regards, Nigel >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 12 March 2013 14:44 > To: lionel.morand@orange.com > Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE,=20 > Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi comments inline: >=20 > On Mar 12, 2013, at 9:59 AM, wrote: >=20 >> Hi, >>=20 >> Honestly, I don't understand why we have to go down each time to the sol= ution space to understand a requirement! >> Can we try to make it simple when possible? >=20 > My solution examples were intended to illustrate that there can be more t= han one solution approach, and we should be careful not to over-constrain t= he solution in the requirements. I did not mean for any of them to be assum= ed as the "real" solution. > [Nigel] I agree with Ben we have to dip our toe in the water of potential= solutions that deal with all scenarios in order to understand the correct = wording of requirements. >=20 >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement is = the following: >> "Diameter clients must be able to use the received load and overload inf= ormation to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not require t= he information to be sent end-to-end from server to client. >=20 > I would be _considerably_ happier with something of the form of "The solu= tion must support graceful client behavior during an overload condition." > [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the= received load and overload information to support graceful behavior during= an overload condition" providing a necessary consequence of graceful behav= iour may involve drastic load shedding at the client or the active proxy. >=20 >=20 >>=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le. > [Nigel] A number of people prefer the "must" so can we compromise on=20 > this use if Ben can accept this, so we can ensure the Client gets the=20 > appropriate information so it can act if necessary >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? > [Nigel] Ben, I am not sure which Requirement you are referring to but the= solution has to work with and without Diameter Agents (stateful or not sta= teful) involved so any requirement should not disallow these scenarios. >=20 >=20 > [...] >=20 >=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 que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, 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 be d= istributed, 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 From jean-jacques.trottin@alcatel-lucent.com Wed Mar 13 02:35:28 2013 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 A874521F8D57 for ; Wed, 13 Mar 2013 02:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.305 X-Spam-Level: X-Spam-Status: No, score=-7.305 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKOPxcz+rj4W for ; Wed, 13 Mar 2013 02:35:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1864621F8D42 for ; Wed, 13 Mar 2013 02:35:26 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2D9Ygon012611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Mar 2013 10:35:15 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Mar 2013 10:34:42 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 13 Mar 2013 10:34:42 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Maria Cruz Bartolome , Eric McMurry , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHN+gm56il2AlbS+kqf8eXke2n9UJhYiT/wgAA9NwCACb1OgIAL+fhggAAFGICAAEWB4IAAEQLggADm5qCAKpiX0IAAmeSAgAXxItCAAAc8gIAABa0AgABb5TCAAAXBoIAAytYAgAASW+CAABnGgIAAEw6w///+wYCAAA3MAIAAAuaAgABkDoCAALbVAIAAIGKA Date: Wed, 13 Mar 2013 09:34:42 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_ 6B7134B3 1289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 09:35:28 -0000 HI Maria Cruz Thanks for your feedback: About REQ 35, my understanding was that the existing REQ35 wording was kept= (with still the pending point between MUST and SHOULD as mentioned in a Ni= gel's mail), and that a new sentence "The solution MUST work in the presenc= e or absence of Diameter agents between Diameter clients and servers" would= be added.=20 You propose for REQ35 "The solution MUST work in the presence or absence of= Diameter agents between Diameter clients and servers, regardless whether o= r not Diameter agents support the overload control mechanism".=20 In fact it groups the two sentences with a MUST, so it is OK for me. You mentioned the REQ16 which I also agree. =3D=3D=3D=3D=3D=3D=3D=3D For REQ2=20 About your two proposals "The mechanism MUST allow Diameter clients to support graceful behavior du= ring an overload situation" Or : "The mechanism MUST allow Diameter clients to act during an overload situat= ion in order to improve it while impacts are minimized" They are OK for me, as they are in the line of my proposal: the client bein= g aware of the overload situation, can act accordingly. Your proposals are = more accurate, as indicating client actions. But the last proposal on the table is the one proposed by Lionel aimed to h= ave a compromise : "Diameter clients must be able to use the received load and overload infor= mation to support graceful behavior during an overload condition" Nigel and I were accepting the Lionel's proposal to find a compromise but n= evertheless I prefer your writing and support your proposals that could als= o be a compromise. As a conclusion, I think we are in line, and I support your proposals with = the objective to find a compromise. Best regards JJacques -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de M= aria Cruz Bartolome Envoy=E9=A0: mercredi 13 mars 2013 09:36 =C0=A0: Eric McMurry; lionel.morand@orange.com; dime@ietf.org Cc=A0: DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry= ) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hello all, Trying to summarize a bit, for my own clarification here and agreement. I think latest proposals are: REQ-35: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D REQ-35 (now in draft v.5): REQ 35: The mechanism SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism REQ-35 (proposal): "The solution MUST work in the presence or absence of Diameter agents betw= een Diameter clients and servers" =20 I think there is something to add to reflect everything cover by former req= uirement: REQ-35 (new proposal): "The solution MUST work in the presence or absence of Diameter agents betw= een Diameter clients and servers, regardless whether or not Diameter agents= support the overload control mechanism" Although this may be considered covered by REQ-16: REQ 16: The overload control mechanism is likely to be deployed incrementally. The mechanism MUST support a mixed environment where some, but not all, nodes implement it. But I presume it does not harm to be explicit here, like in former requirem= ent. About the comment by Eric on security (just mail below), we need to check t= hen whether REQ-30 need to be modified, or a new requirement shall apply, r= ight? REQ 30: The mechanism MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the mechanism to detect, or take countermeasures against, malicious nodes. REQ-2 complement: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D First, I could accept the proposal we got now on the table, I do not want t= o keep discussion forever, but... I'd like to propose some enhancements tha= t I think cover all people concerns stated so far, hopefully without rasing= disagreements. Proposal now is:=20 "Diameter clients must be able to use the received load and overload inform= ation to support graceful behavior during an overload condition" I got some comments on this, taking into account the first proposal was: "The mechanism MUST allow Diameter clients to be aware of an overload situa= tion " I think it is better to request that is "the mechanism" the one that should= provide the means for the client to be able to do something, since we are = specifying what the mechanism shall do in other requirements, like: REQ 1: The overload control mechanism MUST provide a communication method for Diameter nodes to exchange load and overload information. Then my -intermediate- proposal would be the following: "The mechanism MUST allow Diameter clients to support graceful behavior dur= ing an overload situation" Where I think "graceful behavior" is raising some concerns, in facts this i= s not specific enough in my opinion. Good requirement writing would avoid m= ultiple interpretations. Then, what about this: New proposal for REQ-2 complement: "The mechanism MUST allow Diameter clients to act during an overload situat= ion in order to improve it while impacts are minimized" Best regards /MCruz -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: martes, 12 de marzo de 2013 22:42 To: lionel.morand@orange.com Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); BERRY, = Nigel (Nigel) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 I have stated before that I am fine with a MUST provided that the requireme= nt for end to end security is also added. Traversing non-supporint element= s without this would be folly I believe the best compromise here is to leave it as is, so that more thoug= ht can be put into this without constraining the solution to something that= may be nearly impossible to deploy. It may also be possible to define the= security requirement for specific scenarios where the risk is higher. Thi= s would include a specific requirement (at MUST level) stating that e2e sec= urity is required for traversing non-supporting elements. I believe that t= his approach is generally consistent with what some have been discussing ab= out using a MUST level on 35 along with constraints. Eric On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > Almost the end :) >=20 > Remaining issue: REQ35 >=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le. >=20 > [Nigel] A number of people prefer the "must" so can we compromise on=20 > this use if Ben can accept this, so we can ensure the Client gets the=20 > appropriate information so it can act if necessary >=20 > [LM] Not so sure about the number of voices for the "MUST"... >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? > [Nigel] Ben, I am not sure which Requirement you are referring to but the= solution has to work with and without Diameter Agents (stateful or not sta= teful) involved so any requirement should not disallow these scenarios. >=20 > [LM] this requirement was agreed: "The solution MUST work in the presence= or absence of Diameter agents between Diameter clients and servers" >=20 >=20 > -----Message d'origine----- > De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] > Envoy=E9 : mardi 12 mars 2013 16:33 > =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES=20 > (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry=20 > (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi Lionel, > JJ's laptop is on the blink so I will attempt to answer, See in-line,=20 > Kind Regards, Nigel >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 12 March 2013 14:44 > To: lionel.morand@orange.com > Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE,=20 > Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi comments inline: >=20 > On Mar 12, 2013, at 9:59 AM, wrote: >=20 >> Hi, >>=20 >> Honestly, I don't understand why we have to go down each time to the sol= ution space to understand a requirement! >> Can we try to make it simple when possible? >=20 > My solution examples were intended to illustrate that there can be more t= han one solution approach, and we should be careful not to over-constrain t= he solution in the requirements. I did not mean for any of them to be assum= ed as the "real" solution. > [Nigel] I agree with Ben we have to dip our toe in the water of potential= solutions that deal with all scenarios in order to understand the correct = wording of requirements. >=20 >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement is = the following: >> "Diameter clients must be able to use the received load and overload inf= ormation to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not require t= he information to be sent end-to-end from server to client. >=20 > I would be _considerably_ happier with something of the form of "The solu= tion must support graceful client behavior during an overload condition." > [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the= received load and overload information to support graceful behavior during= an overload condition" providing a necessary consequence of graceful behav= iour may involve drastic load shedding at the client or the active proxy. >=20 >=20 >>=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le. > [Nigel] A number of people prefer the "must" so can we compromise on=20 > this use if Ben can accept this, so we can ensure the Client gets the=20 > appropriate information so it can act if necessary >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? > [Nigel] Ben, I am not sure which Requirement you are referring to but the= solution has to work with and without Diameter Agents (stateful or not sta= teful) involved so any requirement should not disallow these scenarios. >=20 >=20 > [...] >=20 >=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 que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, 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 be d= istributed, 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From md3135@att.com Wed Mar 13 02:58:43 2013 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 0D3A821F8D65 for ; Wed, 13 Mar 2013 02:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.072 X-Spam-Level: X-Spam-Status: No, score=-106.072 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ7tDtZbFasT for ; Wed, 13 Mar 2013 02:58:41 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D521F8D2E for ; Wed, 13 Mar 2013 02:58:41 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 1dd40415.785e4940.19502.00-583.52522.nbfkord-smmo08.seg.att.com (envelope-from ); Wed, 13 Mar 2013 09:58:41 +0000 (UTC) X-MXL-Hash: 51404dd1061a3218-2d638b582870bb019db07534c9bbe17cd2c92088 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 8cd40415.0.19474.00-482.52457.nbfkord-smmo08.seg.att.com (envelope-from ); Wed, 13 Mar 2013 09:58:35 +0000 (UTC) X-MXL-Hash: 51404dcb01707437-df991317034aabc85b55768a95410637babd6b94 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2D9wWAk018540; Wed, 13 Mar 2013 05:58:32 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2D9wPpu018525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Mar 2013 05:58:26 -0400 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 13 Mar 2013 09:58:09 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.02.0342.003; Wed, 13 Mar 2013 05:58:09 -0400 From: "DOLLY, MARTIN C" To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Maria Cruz Bartolome , Eric McMurry , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHOH2pjgxSW8PDeSFK3yPO6PRffLZijQXOggABewQD//8MAcA== Date: Wed, 13 Mar 2013 09:58:08 +0000 Message-ID: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1_ 6B7134B3 1289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.130.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=DvHhDhD+ c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=0lZaRS35BEgA:10 a=r_FGx56wRvQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=NajClncphjEA:10 a=48vgC7mUAAAA:8 a=z9tbli-vAAAA:8] X-AnalysisOut: [ a=gxZvrgisAAAA:8 a=Z80JlwQ0AAAA:8 a=xgxFxLK2TqnsCzVeqJQA:] X-AnalysisOut: [9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:10 a=] X-AnalysisOut: [3FZX-ydVlcEA:10 a=0MAqpqVwYqEA:10 a=AoswI2wWGMbGXJ8k:21 a=] X-AnalysisOut: [8pk0mh2qHHA0nm8X:21] Cc: "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 09:58:43 -0000 WRT REQ2, this poor dog has been beaten too badly, let's just leave it allo= w :) -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of TRO= TTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: Wednesday, March 13, 2013 5:35 AM To: Maria Cruz Bartolome; Eric McMurry; lionel.morand@orange.com; dime@ietf= .org Cc: DRAGE, Keith (Keith); Bessis, Thierry (Thierry); BERRY, Nigel (Nigel) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 HI Maria Cruz Thanks for your feedback: About REQ 35, my understanding was that the existing REQ35 wording was kept= (with still the pending point between MUST and SHOULD as mentioned in a Ni= gel's mail), and that a new sentence "The solution MUST work in the presenc= e or absence of Diameter agents between Diameter clients and servers" would= be added.=20 You propose for REQ35 "The solution MUST work in the presence or absence of= Diameter agents between Diameter clients and servers, regardless whether o= r not Diameter agents support the overload control mechanism".=20 In fact it groups the two sentences with a MUST, so it is OK for me. You mentioned the REQ16 which I also agree. =3D=3D=3D=3D=3D=3D=3D=3D For REQ2=20 About your two proposals "The mechanism MUST allow Diameter clients to support graceful behavior du= ring an overload situation" Or : "The mechanism MUST allow Diameter clients to act during an overload situat= ion in order to improve it while impacts are minimized" They are OK for me, as they are in the line of my proposal: the client bein= g aware of the overload situation, can act accordingly. Your proposals are = more accurate, as indicating client actions. But the last proposal on the table is the one proposed by Lionel aimed to h= ave a compromise : "Diameter clients must be able to use the received load and overload infor= mation to support graceful behavior during an overload condition" Nigel and I were accepting the Lionel's proposal to find a compromise but n= evertheless I prefer your writing and support your proposals that could als= o be a compromise. As a conclusion, I think we are in line, and I support your proposals with = the objective to find a compromise. Best regards JJacques -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de M= aria Cruz Bartolome Envoy=E9=A0: mercredi 13 mars 2013 09:36 =C0=A0: Eric McMurry; lionel.morand@orange.com; dime@ietf.org Cc=A0: DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry= ) Objet=A0: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Hello all, Trying to summarize a bit, for my own clarification here and agreement. I think latest proposals are: REQ-35: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D REQ-35 (now in draft v.5): REQ 35: The mechanism SHOULD provide a method for exchanging overload and load information between elements that are connected by intermediaries that do not support the mechanism REQ-35 (proposal): "The solution MUST work in the presence or absence of Diameter agents betw= een Diameter clients and servers" =20 I think there is something to add to reflect everything cover by former req= uirement: REQ-35 (new proposal): "The solution MUST work in the presence or absence of Diameter agents betw= een Diameter clients and servers, regardless whether or not Diameter agents= support the overload control mechanism" Although this may be considered covered by REQ-16: REQ 16: The overload control mechanism is likely to be deployed incrementally. The mechanism MUST support a mixed environment where some, but not all, nodes implement it. But I presume it does not harm to be explicit here, like in former requirem= ent. About the comment by Eric on security (just mail below), we need to check t= hen whether REQ-30 need to be modified, or a new requirement shall apply, r= ight? REQ 30: The mechanism MUST NOT depend on being deployed in environments where all Diameter nodes are completely trusted. It SHOULD operate as effectively as possible in environments where other nodes are malicious; this includes preventing malicious nodes from obtaining more than a fair share of service. Note that this does not imply any responsibility on the mechanism to detect, or take countermeasures against, malicious nodes. REQ-2 complement: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D First, I could accept the proposal we got now on the table, I do not want t= o keep discussion forever, but... I'd like to propose some enhancements tha= t I think cover all people concerns stated so far, hopefully without rasing= disagreements. Proposal now is:=20 "Diameter clients must be able to use the received load and overload inform= ation to support graceful behavior during an overload condition" I got some comments on this, taking into account the first proposal was: "The mechanism MUST allow Diameter clients to be aware of an overload situa= tion " I think it is better to request that is "the mechanism" the one that should= provide the means for the client to be able to do something, since we are = specifying what the mechanism shall do in other requirements, like: REQ 1: The overload control mechanism MUST provide a communication method for Diameter nodes to exchange load and overload information. Then my -intermediate- proposal would be the following: "The mechanism MUST allow Diameter clients to support graceful behavior dur= ing an overload situation" Where I think "graceful behavior" is raising some concerns, in facts this i= s not specific enough in my opinion. Good requirement writing would avoid m= ultiple interpretations. Then, what about this: New proposal for REQ-2 complement: "The mechanism MUST allow Diameter clients to act during an overload situat= ion in order to improve it while impacts are minimized" Best regards /MCruz -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: martes, 12 de marzo de 2013 22:42 To: lionel.morand@orange.com Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); BERRY, = Nigel (Nigel) Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 I have stated before that I am fine with a MUST provided that the requireme= nt for end to end security is also added. Traversing non-supporint element= s without this would be folly I believe the best compromise here is to leave it as is, so that more thoug= ht can be put into this without constraining the solution to something that= may be nearly impossible to deploy. It may also be possible to define the= security requirement for specific scenarios where the risk is higher. Thi= s would include a specific requirement (at MUST level) stating that e2e sec= urity is required for traversing non-supporting elements. I believe that t= his approach is generally consistent with what some have been discussing ab= out using a MUST level on 35 along with constraints. Eric On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > Almost the end :) >=20 > Remaining issue: REQ35 >=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le. >=20 > [Nigel] A number of people prefer the "must" so can we compromise on=20 > this use if Ben can accept this, so we can ensure the Client gets the=20 > appropriate information so it can act if necessary >=20 > [LM] Not so sure about the number of voices for the "MUST"... >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? > [Nigel] Ben, I am not sure which Requirement you are referring to but the= solution has to work with and without Diameter Agents (stateful or not sta= teful) involved so any requirement should not disallow these scenarios. >=20 > [LM] this requirement was agreed: "The solution MUST work in the presence= or absence of Diameter agents between Diameter clients and servers" >=20 >=20 > -----Message d'origine----- > De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] > Envoy=E9 : mardi 12 mars 2013 16:33 > =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES=20 > (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry=20 > (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi Lionel, > JJ's laptop is on the blink so I will attempt to answer, See in-line,=20 > Kind Regards, Nigel >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 12 March 2013 14:44 > To: lionel.morand@orange.com > Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE,=20 > Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hi comments inline: >=20 > On Mar 12, 2013, at 9:59 AM, wrote: >=20 >> Hi, >>=20 >> Honestly, I don't understand why we have to go down each time to the sol= ution space to understand a requirement! >> Can we try to make it simple when possible? >=20 > My solution examples were intended to illustrate that there can be more t= han one solution approach, and we should be careful not to over-constrain t= he solution in the requirements. I did not mean for any of them to be assum= ed as the "real" solution. > [Nigel] I agree with Ben we have to dip our toe in the water of potential= solutions that deal with all scenarios in order to understand the correct = wording of requirements. >=20 >>=20 >> 1/ REQ 2 complement: >>=20 >> Based on the different comments, my proposal for the new requirement is = the following: >> "Diameter clients must be able to use the received load and overload inf= ormation to support graceful behavior during an overload condition" >>=20 >> And the question is: OK or NOK i.e. can you live with? >=20 > Grudgingly OK, with the provision that this allows but does not require t= he information to be sent end-to-end from server to client. >=20 > I would be _considerably_ happier with something of the form of "The solu= tion must support graceful client behavior during an overload condition." > [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the= received load and overload information to support graceful behavior during= an overload condition" providing a necessary consequence of graceful behav= iour may involve drastic load shedding at the client or the active proxy. >=20 >=20 >>=20 >> 2/ REQ 35: >> With the clarification that the "SHOULD" is strong recommendation for so= lution designers i.e. if you can meet this requirement, your solution will = have greater chances to be selected than a solution without, is it acceptab= le to keep the "SHOULD" in the draft? >>=20 >> OK or NOK? >>=20 >=20 > OK. >=20 > I would also accept a MUST, with the understanding that there may be limi= tations on what a non-supporting intermediary can do and still be traversab= le. > [Nigel] A number of people prefer the "must" so can we compromise on=20 > this use if Ben can accept this, so we can ensure the Client gets the=20 > appropriate information so it can act if necessary >=20 > Have we accepted the requirement(s) about working both with or without ag= ents? > [Nigel] Ben, I am not sure which Requirement you are referring to but the= solution has to work with and without Diameter Agents (stateful or not sta= teful) involved so any requirement should not disallow these scenarios. >=20 >=20 > [...] >=20 >=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 que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, 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 be d= istributed, 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, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > 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 _______________________________________________ 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 From ben@nostrum.com Wed Mar 13 05:37:04 2013 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 DE15021F8D10 for ; Wed, 13 Mar 2013 05:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJP4rtjyQDzc for ; Wed, 13 Mar 2013 05:37:03 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB6521F8CFA for ; Wed, 13 Mar 2013 05:37:03 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2DCahiF018067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Mar 2013 07:36:44 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Wed, 13 Mar 2013 08:36:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86D0F045-7485-4444-A3A1-9050DCE333D8@nostrum.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1! _ 6B7134B3 1289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 12:37:05 -0000 Hi, Comments inline: On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > HI Maria Cruz >=20 > Thanks for your feedback: >=20 > About REQ 35, my understanding was that the existing REQ35 wording was = kept (with still the pending point between MUST and SHOULD as mentioned = in a Nigel's mail), and that a new sentence "The solution MUST work in = the presence or absence of Diameter agents between Diameter clients and = servers" would be added.=20 > You propose for REQ35 "The solution MUST work in the presence or = absence of Diameter agents between Diameter clients and servers, = regardless whether or not Diameter agents support the overload control = mechanism".=20 >=20 > In fact it groups the two sentences with a MUST, so it is OK for me. >=20 I had expected the requirement to work with or without agents would be a = new, separate requirement. I think that, while it's related to the need = to cross non-supporting agents, it's also distinct in the fact that it = requires the solution to work in a pure client-server deployment as = well. I prefer the separation, but could live with it if people want to = combine them. > You mentioned the REQ16 which I also agree. Req16 does not necessarily imply the ability to cross non-supporting = agents. It could, for example, be interpreted to mean that = non-supporting clients are allowed in parallel with supporting clients. = I would not depend on 16 by itself to get the point across.=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > For REQ2=20 >=20 > About your two proposals > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" > Or : > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" > They are OK for me, as they are in the line of my proposal: the client = being aware of the overload situation, can act accordingly. Your = proposals are more accurate, as indicating client actions. >=20 > But the last proposal on the table is the one proposed by Lionel aimed = to have a compromise : > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >=20 > Nigel and I were accepting the Lionel's proposal to find a compromise = but nevertheless I prefer your writing and support your proposals that = could also be a compromise. >=20 > As a conclusion, I think we are in line, and I support your proposals = with the objective to find a compromise. I am fine with either wording. In the interests of not beating Martin's = dog (see Martin's email), it's probably easier to stick with Lionel's = proposed wording, but I will not object if the consensus is to change to = Maria's. >=20 > Best regards >=20 > JJacques >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Maria Cruz Bartolome > Envoy=E9 : mercredi 13 mars 2013 09:36 > =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org > Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry = (Thierry) > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hello all, >=20 > Trying to summarize a bit, for my own clarification here and = agreement. > I think latest proposals are: >=20 > REQ-35: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > REQ-35 (now in draft v.5): > REQ 35: The mechanism SHOULD provide a method for exchanging > overload and load information between elements that are > connected by intermediaries that do not support the > mechanism >=20 > REQ-35 (proposal): > "The solution MUST work in the presence or absence of Diameter agents = between Diameter clients and servers" >=20 > I think there is something to add to reflect everything cover by = former requirement: >=20 > REQ-35 (new proposal): > "The solution MUST work in the presence or absence of Diameter agents = between Diameter clients and servers, regardless whether or not Diameter = agents support the overload control mechanism" >=20 >=20 > Although this may be considered covered by REQ-16: > REQ 16: The overload control mechanism is likely to be deployed > incrementally. The mechanism MUST support a mixed > environment where some, but not all, nodes implement it. >=20 > But I presume it does not harm to be explicit here, like in former = requirement. >=20 >=20 > About the comment by Eric on security (just mail below), we need to = check then whether REQ-30 need to be modified, or a new requirement = shall apply, right? >=20 > REQ 30: The mechanism MUST NOT depend on being deployed in > environments where all Diameter nodes are completely > trusted. It SHOULD operate as effectively as possible in > environments where other nodes are malicious; this includes > preventing malicious nodes from obtaining more than a fair > share of service. Note that this does not imply any > responsibility on the mechanism to detect, or take > countermeasures against, malicious nodes. >=20 >=20 > REQ-2 complement: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > First, I could accept the proposal we got now on the table, I do not = want to keep discussion forever, but... I'd like to propose some = enhancements that I think cover all people concerns stated so far, = hopefully without rasing disagreements. >=20 > Proposal now is:=20 > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >=20 > I got some comments on this, taking into account the first proposal = was: > "The mechanism MUST allow Diameter clients to be aware of an overload = situation " >=20 > I think it is better to request that is "the mechanism" the one that = should provide the means for the client to be able to do something, = since we are specifying what the mechanism shall do in other = requirements, like: >=20 > REQ 1: The overload control mechanism MUST provide a communication > method for Diameter nodes to exchange load and overload > information. >=20 >=20 > Then my -intermediate- proposal would be the following: > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" >=20 > Where I think "graceful behavior" is raising some concerns, in facts = this is not specific enough in my opinion. Good requirement writing = would avoid multiple interpretations. Then, what about this: >=20 > New proposal for REQ-2 complement: > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" >=20 >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Eric McMurry > Sent: martes, 12 de marzo de 2013 22:42 > To: lionel.morand@orange.com > Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); = BERRY, Nigel (Nigel) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > I have stated before that I am fine with a MUST provided that the = requirement for end to end security is also added. Traversing = non-supporint elements without this would be folly >=20 > I believe the best compromise here is to leave it as is, so that more = thought can be put into this without constraining the solution to = something that may be nearly impossible to deploy. It may also be = possible to define the security requirement for specific scenarios where = the risk is higher. This would include a specific requirement (at MUST = level) stating that e2e security is required for traversing = non-supporting elements. I believe that this approach is generally = consistent with what some have been discussing about using a MUST level = on 35 along with constraints. >=20 > Eric >=20 >=20 > On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: >=20 >> Almost the end :) >>=20 >> Remaining issue: REQ35 >>=20 >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? >>>=20 >>> OK or NOK? >>>=20 >>=20 >> OK. >>=20 >> I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable. >>=20 >> [Nigel] A number of people prefer the "must" so can we compromise on=20= >> this use if Ben can accept this, so we can ensure the Client gets the=20= >> appropriate information so it can act if necessary >>=20 >> [LM] Not so sure about the number of voices for the "MUST"... >>=20 >> Have we accepted the requirement(s) about working both with or = without agents? >> [Nigel] Ben, I am not sure which Requirement you are referring to but = the solution has to work with and without Diameter Agents (stateful or = not stateful) involved so any requirement should not disallow these = scenarios. >>=20 >> [LM] this requirement was agreed: "The solution MUST work in the = presence or absence of Diameter agents between Diameter clients and = servers" >>=20 >>=20 >> -----Message d'origine----- >> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] >> Envoy=E9 : mardi 12 mars 2013 16:33 >> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES=20= >> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry=20= >> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >>=20 >> Hi Lionel, >> JJ's laptop is on the blink so I will attempt to answer, See in-line,=20= >> Kind Regards, Nigel >>=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 12 March 2013 14:44 >> To: lionel.morand@orange.com >> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); = DRAGE,=20 >> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) >> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >>=20 >> Hi comments inline: >>=20 >> On Mar 12, 2013, at 9:59 AM, wrote: >>=20 >>> Hi, >>>=20 >>> Honestly, I don't understand why we have to go down each time to the = solution space to understand a requirement! >>> Can we try to make it simple when possible? >>=20 >> My solution examples were intended to illustrate that there can be = more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. >> [Nigel] I agree with Ben we have to dip our toe in the water of = potential solutions that deal with all scenarios in order to understand = the correct wording of requirements. >>=20 >>>=20 >>> 1/ REQ 2 complement: >>>=20 >>> Based on the different comments, my proposal for the new requirement = is the following: >>> "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >>>=20 >>> And the question is: OK or NOK i.e. can you live with? >>=20 >> Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client. >>=20 >> I would be _considerably_ happier with something of the form of "The = solution must support graceful client behavior during an overload = condition." >> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use = the received load and overload information to support graceful behavior = during an overload condition" providing a necessary consequence of = graceful behaviour may involve drastic load shedding at the client or = the active proxy. >>=20 >>=20 >>>=20 >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? >>>=20 >>> OK or NOK? >>>=20 >>=20 >> OK. >>=20 >> I would also accept a MUST, with the understanding that there may be = limitations on what a non-supporting intermediary can do and still be = traversable. >> [Nigel] A number of people prefer the "must" so can we compromise on=20= >> this use if Ben can accept this, so we can ensure the Client gets the=20= >> appropriate information so it can act if necessary >>=20 >> Have we accepted the requirement(s) about working both with or = without agents? >> [Nigel] Ben, I am not sure which Requirement you are referring to but = the solution has to work with and without Diameter Agents (stateful or = not stateful) involved so any requirement should not disallow these = scenarios. >>=20 >>=20 >> [...] >>=20 >>=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 = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, 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 = 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> 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 > _______________________________________________ > 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 From ben@nostrum.com Wed Mar 13 05:41:07 2013 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 5F22D21F89AA for ; Wed, 13 Mar 2013 05:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HeiVBmX5C0T for ; Wed, 13 Mar 2013 05:41:07 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DC9E421F854C for ; Wed, 13 Mar 2013 05:41:06 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2DCexCx018513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Mar 2013 07:41:00 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> Date: Wed, 13 Mar 2013 08:40:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <952432EB-C72B-48D2-8804-9214EF7E0A99@nostrum.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <8179_1363039955_513E56D3_8179_17231_1! _ 6B7134B3 1289DC4FAF731D844122B36E15D747@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 12:41:07 -0000 Comment inline. (I commented on the other items in response to = Jean-Jacques. On Mar 13, 2013, at 4:36 AM, Maria Cruz Bartolome = wrote: > About the comment by Eric on security (just mail below), we need to = check then whether REQ-30 need to be modified, or a new requirement = shall apply, right? >=20 > REQ 30: The mechanism MUST NOT depend on being deployed in > environments where all Diameter nodes are completely > trusted. It SHOULD operate as effectively as possible in > environments where other nodes are malicious; this includes > preventing malicious nodes from obtaining more than a fair > share of service. Note that this does not imply any > responsibility on the mechanism to detect, or take > countermeasures against, malicious nodes. >=20 I think Eric's concern is distinct from 30. It was not so much a general = security requirement as an observation that crossing non-supporting = nodes has the potential for security problems when you don't have an = end-to-end mechanism to authenticate the overload report. A single = report can effectively shut down a network, so it's important that you = don't accept malicious ones.=20 I think the details of that would be better handled as part of the = solution engineering exercise than in requirements. The other general = requirements to effect of "don't make things worse" should cover it :-) From david@mitton.com Wed Mar 13 06:41:13 2013 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 C052B21F8BE2 for ; Wed, 13 Mar 2013 06:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYYOQi0qKWWI for ; Wed, 13 Mar 2013 06:41:13 -0700 (PDT) Received: from c62.cesmail.net (c62.cesmail.net [216.154.195.54]) by ietfa.amsl.com (Postfix) with ESMTP id 52D8521F8BE0 for ; Wed, 13 Mar 2013 06:41:13 -0700 (PDT) Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c62.cesmail.net with ESMTP; 13 Mar 2013 09:41:12 -0400 Received: from 66.228.80.226 ([66.228.80.226]) by webmail.spamcop.net (Horde MIME library) with HTTP; Wed, 13 Mar 2013 09:41:12 -0400 Message-ID: <20130313094112.jwl9kr6bwokw0w0o-qnivqz@webmail.spamcop.net> Date: Wed, 13 Mar 2013 09:41:12 -0400 From: David Mitton To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) Subject: [Dime] Jabber at Meetings? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 13:41:13 -0000 I'm very disappointed that this is the second IETF meeting where I have experienced no Dime meeting participation in jabber. Looking at the logs it seems to go back several meetings further. Come on, guys. sheesh. Dave. http://www.ietf.org/jabber/logs/dime/ From emcmurry@computer.org Wed Mar 13 15:45:30 2013 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 C7E1111E80E0 for ; Wed, 13 Mar 2013 15:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U3jmtxnMo0P for ; Wed, 13 Mar 2013 15:45:30 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBFF11E809C for ; Wed, 13 Mar 2013 15:45:30 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1UFuQK-000O5E-P8; Wed, 13 Mar 2013 22:45:28 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id C89FC23D1153; Wed, 13 Mar 2013 17:45:26 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/W4AlYHH0JI2YhzuIobk0k12gr10JLuGU= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSU4nJ8XWedd; Wed, 13 Mar 2013 17:45:26 -0500 (CDT) Received: from [192.168.220.43] (87-231-241-210.rev.numericable.fr [87.231.241.210]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 7F76023D114D; Wed, 13 Mar 2013 17:45:25 -0500 (CDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> Date: Wed, 13 Mar 2013 23:45:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <"8179_1363039955_513E56D3_8179_17231_1 _ 6B7134 B3 1289DC4FAF731D844122B36E15D747"@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1499) Cc: "DRAGE, Keith \(Keith\)" , dime@ietf.org, "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2013 22:45:30 -0000 Hi Maria, Comments inline. Thanks, Eric On Mar 13, 2013, at 9:36 , Maria Cruz Bartolome = wrote: > Hello all, >=20 > Trying to summarize a bit, for my own clarification here and = agreement. > I think latest proposals are: >=20 > REQ-35: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > REQ-35 (now in draft v.5): > REQ 35: The mechanism SHOULD provide a method for exchanging > overload and load information between elements that are > connected by intermediaries that do not support the > mechanism >=20 > REQ-35 (proposal): > "The solution MUST work in the presence or absence of Diameter agents = between Diameter clients and servers" >=20 > I think there is something to add to reflect everything cover by = former requirement: >=20 > REQ-35 (new proposal): > "The solution MUST work in the presence or absence of Diameter agents = between Diameter clients and servers, regardless whether or not Diameter = agents support the overload control mechanism" >=20 >=20 I think Ben and JJacques have covered this. This is the first instance = I have seen of combining the new agent/no-agent language with 35 and = they don't really go together. They should remain separate. > Although this may be considered covered by REQ-16: > REQ 16: The overload control mechanism is likely to be deployed > incrementally. The mechanism MUST support a mixed > environment where some, but not all, nodes implement it. >=20 > But I presume it does not harm to be explicit here, like in former = requirement. I agree with Ben that this does not imply what you are reading into it. = Another requirement would be needed to make that clear. >=20 [...] >=20 > REQ-2 complement: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > First, I could accept the proposal we got now on the table, I do not = want to keep discussion forever, but... I'd like to propose some = enhancements that I think cover all people concerns stated so far, = hopefully without rasing disagreements. >=20 > Proposal now is:=20 > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" >=20 > I got some comments on this, taking into account the first proposal = was: > "The mechanism MUST allow Diameter clients to be aware of an overload = situation " >=20 > I think it is better to request that is "the mechanism" the one that = should provide the means for the client to be able to do something, = since we are specifying what the mechanism shall do in other = requirements, like: >=20 > REQ 1: The overload control mechanism MUST provide a communication > method for Diameter nodes to exchange load and overload > information. >=20 >=20 > Then my -intermediate- proposal would be the following: > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" >=20 > Where I think "graceful behavior" is raising some concerns, in facts = this is not specific enough in my opinion. Good requirement writing = would avoid multiple interpretations. Then, what about this: >=20 > New proposal for REQ-2 complement: > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" >=20 >=20 I agree with Martin about the dog, but this is also saying something = different than the last proposal. There are some areas where the = requirements are justifiably intentionally a bit vague, to gove some = roome to the mechanism designers where there are multiple ways to solve = problems. This is one of those cases. The proposal here is too = specific and does not reflect some of the discussion leading up to this = point, namely the parts about overload being handled closer to the = server as appropriate. [...] From jgunn6@csc.com Thu Mar 14 06:26:04 2013 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 57C9511E811D; Thu, 14 Mar 2013 06:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+jrEMTNiCgV; Thu, 14 Mar 2013 06:26:02 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEB511E811F; Thu, 14 Mar 2013 06:26:01 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-15.tower-86.messagelabs.com!1363267527!33123675!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23226 invoked from network); 14 Mar 2013 13:25:27 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-15.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Mar 2013 13:25:27 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (8.13.8/8.13.8) with ESMTP id r2EDOvSH018131; Thu, 14 Mar 2013 09:24:57 -0400 In-Reply-To: <86D0F045-7485-4444-A3A1-9050DCE333D8@nostrum.com> References: <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: Ben Campbell MIME-Version: 1.0 X-KeepSent: 7661F6A3:31D7D4FA-85257B2E:00498952; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Thu, 14 Mar 2013 09:25:24 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 03/14/2013 09:20:01 AM, Serialize complete at 03/14/2013 09:20:01 AM Content-Type: multipart/alternative; boundary="=_alternative 0049BD9985257B2E_=" Cc: dime-bounces@ietf.org, "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 13:26:04 -0000 This is a multipart message in MIME format. --=_alternative 0049BD9985257B2E_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable WRT "gracefully" in Req 2. I thought we agreed to incorporate a reference=20 to REQ 3, e.g., "gracefully (in accordance with Req 3)" Janet This is a PRIVATE message. If you are not the intended recipient, please=20 delete without copying and kindly advise us by e-mail of the mistake in=20 delivery. NOTE: Regardless of content, this e-mail shall not operate to=20 bind CSC to any order or other contract unless pursuant to explicit=20 written agreement or government initiative expressly permitting the use of = e-mail for such purpose. From: Ben Campbell To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"=20 Cc: "BERRY, Nigel \(Nigel\)" , "DRAGE, = Keith \(Keith\)" , "Bessis, Thierry=20 \(Thierry\)" , "dime@ietf.org"=20 Date: 03/13/2013 08:37 AM Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Sent by: dime-bounces@ietf.org Hi, Comments inline: On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"=20 wrote: > HI Maria Cruz >=20 > Thanks for your feedback: >=20 > About REQ 35, my understanding was that the existing REQ35 wording was=20 kept (with still the pending point between MUST and SHOULD as mentioned in = a Nigel's mail), and that a new sentence "The solution MUST work in the=20 presence or absence of Diameter agents between Diameter clients and=20 servers" would be added.=20 > You propose for REQ35 "The solution MUST work in the presence or absence = of Diameter agents between Diameter clients and servers, regardless=20 whether or not Diameter agents support the overload control mechanism".=20 >=20 > In fact it groups the two sentences with a MUST, so it is OK for me. >=20 I had expected the requirement to work with or without agents would be a=20 new, separate requirement. I think that, while it's related to the need to = cross non-supporting agents, it's also distinct in the fact that it=20 requires the solution to work in a pure client-server deployment as well.=20 I prefer the separation, but could live with it if people want to combine=20 them. > You mentioned the REQ16 which I also agree. Req16 does not necessarily imply the ability to cross non-supporting=20 agents. It could, for example, be interpreted to mean that non-supporting=20 clients are allowed in parallel with supporting clients. I would not=20 depend on 16 by itself to get the point across.=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > For REQ2=20 >=20 > About your two proposals > "The mechanism MUST allow Diameter clients to support graceful behavior=20 during an overload situation" > Or : > "The mechanism MUST allow Diameter clients to act during an overload=20 situation in order to improve it while impacts are minimized" > They are OK for me, as they are in the line of my proposal: the client=20 being aware of the overload situation, can act accordingly. Your proposals = are more accurate, as indicating client actions. >=20 > But the last proposal on the table is the one proposed by Lionel aimed=20 to have a compromise : > "Diameter clients must be able to use the received load and overload=20 information to support graceful behavior during an overload condition" >=20 > Nigel and I were accepting the Lionel's proposal to find a compromise=20 but nevertheless I prefer your writing and support your proposals that=20 could also be a compromise. >=20 > As a conclusion, I think we are in line, and I support your proposals=20 with the objective to find a compromise. I am fine with either wording. In the interests of not beating Martin's=20 dog (see Martin's email), it's probably easier to stick with Lionel's=20 proposed wording, but I will not object if the consensus is to change to=20 Maria's. >=20 > Best regards >=20 > JJacques >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de=20 Maria Cruz Bartolome > Envoy=E9 : mercredi 13 mars 2013 09:36 > =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org > Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry=20 (Thierry) > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > Hello all, >=20 > Trying to summarize a bit, for my own clarification here and agreement. > I think latest proposals are: >=20 > REQ-35: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > REQ-35 (now in draft v.5): > REQ 35: The mechanism SHOULD provide a method for exchanging > overload and load information between elements that are > connected by intermediaries that do not support the > mechanism >=20 > REQ-35 (proposal): > "The solution MUST work in the presence or absence of Diameter agents=20 between Diameter clients and servers" >=20 > I think there is something to add to reflect everything cover by former=20 requirement: >=20 > REQ-35 (new proposal): > "The solution MUST work in the presence or absence of Diameter agents=20 between Diameter clients and servers, regardless whether or not Diameter=20 agents support the overload control mechanism" >=20 >=20 > Although this may be considered covered by REQ-16: > REQ 16: The overload control mechanism is likely to be deployed > incrementally. The mechanism MUST support a mixed > environment where some, but not all, nodes implement it. >=20 > But I presume it does not harm to be explicit here, like in former=20 requirement. >=20 >=20 > About the comment by Eric on security (just mail below), we need to=20 check then whether REQ-30 need to be modified, or a new requirement shall=20 apply, right? >=20 > REQ 30: The mechanism MUST NOT depend on being deployed in > environments where all Diameter nodes are completely > trusted. It SHOULD operate as effectively as possible in > environments where other nodes are malicious; this includes > preventing malicious nodes from obtaining more than a fair > share of service. Note that this does not imply any > responsibility on the mechanism to detect, or take > countermeasures against, malicious nodes. >=20 >=20 > REQ-2 complement: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > First, I could accept the proposal we got now on the table, I do not=20 want to keep discussion forever, but... I'd like to propose some=20 enhancements that I think cover all people concerns stated so far,=20 hopefully without rasing disagreements. >=20 > Proposal now is:=20 > "Diameter clients must be able to use the received load and overload=20 information to support graceful behavior during an overload condition" >=20 > I got some comments on this, taking into account the first proposal was: > "The mechanism MUST allow Diameter clients to be aware of an overload=20 situation " >=20 > I think it is better to request that is "the mechanism" the one that=20 should provide the means for the client to be able to do something, since=20 we are specifying what the mechanism shall do in other requirements, like: >=20 > REQ 1: The overload control mechanism MUST provide a communication > method for Diameter nodes to exchange load and overload > information. >=20 >=20 > Then my -intermediate- proposal would be the following: > "The mechanism MUST allow Diameter clients to support graceful behavior=20 during an overload situation" >=20 > Where I think "graceful behavior" is raising some concerns, in facts=20 this is not specific enough in my opinion. Good requirement writing would=20 avoid multiple interpretations. Then, what about this: >=20 > New proposal for REQ-2 complement: > "The mechanism MUST allow Diameter clients to act during an overload=20 situation in order to improve it while impacts are minimized" >=20 >=20 >=20 > Best regards > /MCruz >=20 >=20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of=20 Eric McMurry > Sent: martes, 12 de marzo de 2013 22:42 > To: lionel.morand@orange.com > Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry);=20 BERRY, Nigel (Nigel) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >=20 > I have stated before that I am fine with a MUST provided that the=20 requirement for end to end security is also added. Traversing=20 non-supporint elements without this would be folly >=20 > I believe the best compromise here is to leave it as is, so that more=20 thought can be put into this without constraining the solution to=20 something that may be nearly impossible to deploy. It may also be=20 possible to define the security requirement for specific scenarios where=20 the risk is higher. This would include a specific requirement (at MUST=20 level) stating that e2e security is required for traversing non-supporting = elements. I believe that this approach is generally consistent with what=20 some have been discussing about using a MUST level on 35 along with=20 constraints. >=20 > Eric >=20 >=20 > On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: >=20 >> Almost the end :) >>=20 >> Remaining issue: REQ35 >>=20 >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation for=20 solution designers i.e. if you can meet this requirement, your solution=20 will have greater chances to be selected than a solution without, is it=20 acceptable to keep the "SHOULD" in the draft? >>>=20 >>> OK or NOK? >>>=20 >>=20 >> OK. >>=20 >> I would also accept a MUST, with the understanding that there may be=20 limitations on what a non-supporting intermediary can do and still be=20 traversable. >>=20 >> [Nigel] A number of people prefer the "must" so can we compromise on=20 >> this use if Ben can accept this, so we can ensure the Client gets the=20 >> appropriate information so it can act if necessary >>=20 >> [LM] Not so sure about the number of voices for the "MUST"... >>=20 >> Have we accepted the requirement(s) about working both with or without=20 agents? >> [Nigel] Ben, I am not sure which Requirement you are referring to but=20 the solution has to work with and without Diameter Agents (stateful or not = stateful) involved so any requirement should not disallow these scenarios. >>=20 >> [LM] this requirement was agreed: "The solution MUST work in the=20 presence or absence of Diameter agents between Diameter clients and=20 servers" >>=20 >>=20 >> -----Message d'origine----- >> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] >> Envoy=E9 : mardi 12 mars 2013 16:33 >> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES=20 >> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry=20 >> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >>=20 >> Hi Lionel, >> JJ's laptop is on the blink so I will attempt to answer, See in-line,=20 >> Kind Regards, Nigel >>=20 >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 12 March 2013 14:44 >> To: lionel.morand@orange.com >> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE,=20 >> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) >> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >>=20 >> Hi comments inline: >>=20 >> On Mar 12, 2013, at 9:59 AM, wrote: >>=20 >>> Hi, >>>=20 >>> Honestly, I don't understand why we have to go down each time to the=20 solution space to understand a requirement! >>> Can we try to make it simple when possible? >>=20 >> My solution examples were intended to illustrate that there can be more = than one solution approach, and we should be careful not to over-constrain = the solution in the requirements. I did not mean for any of them to be=20 assumed as the "real" solution. >> [Nigel] I agree with Ben we have to dip our toe in the water of=20 potential solutions that deal with all scenarios in order to understand=20 the correct wording of requirements. >>=20 >>>=20 >>> 1/ REQ 2 complement: >>>=20 >>> Based on the different comments, my proposal for the new requirement=20 is the following: >>> "Diameter clients must be able to use the received load and overload=20 information to support graceful behavior during an overload condition" >>>=20 >>> And the question is: OK or NOK i.e. can you live with? >>=20 >> Grudgingly OK, with the provision that this allows but does not require = the information to be sent end-to-end from server to client. >>=20 >> I would be =5Fconsiderably=5F happier with something of the form of "The= =20 solution must support graceful client behavior during an overload=20 condition." >> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use=20 the received load and overload information to support graceful behavior=20 during an overload condition" providing a necessary consequence of=20 graceful behaviour may involve drastic load shedding at the client or the=20 active proxy. >>=20 >>=20 >>>=20 >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation for=20 solution designers i.e. if you can meet this requirement, your solution=20 will have greater chances to be selected than a solution without, is it=20 acceptable to keep the "SHOULD" in the draft? >>>=20 >>> OK or NOK? >>>=20 >>=20 >> OK. >>=20 >> I would also accept a MUST, with the understanding that there may be=20 limitations on what a non-supporting intermediary can do and still be=20 traversable. >> [Nigel] A number of people prefer the "must" so can we compromise on=20 >> this use if Ben can accept this, so we can ensure the Client gets the=20 >> appropriate information so it can act if necessary >>=20 >> Have we accepted the requirement(s) about working both with or without=20 agents? >> [Nigel] Ben, I am not sure which Requirement you are referring to but=20 the solution has to work with and without Diameter Agents (stateful or not = stateful) involved so any requirement should not disallow these scenarios. >>=20 >>=20 >> [...] >>=20 >>=20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F >>=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, France Telecom - Orange decline toute responsabilite si ce=20 message a ete altere, 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 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, France Telecom - Orange is not liable for=20 messages that have been modified, changed or falsified. >> Thank you. >>=20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --=_alternative 0049BD9985257B2E_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable WRT "gracefully" in Req 2. I thought we agreed to incorporate a reference to REQ 3, e.g., "graceful= ly (in accordance with Req 3)"

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:     =    Ben Campbell <ben@nostru= m.com>
To:     &n= bsp;  "TROTTIN,        JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trot= tin@alcatel-lucent.com>
Cc:     &n= bsp;  "BERRY, Nigel \(Nigel\)" <nigel.berry@alcatel-lucent.com>, "DRAGE,        Keith \(Keith\)" <keith.drage@alcatel-lucent.co= m>, "Bessis,        Thierry \(Thierry\)" <thierry.bessis@alcatel-lucent.com>, "dime@ietf.org" <di= me@ietf.org>
Date:     =    03/13/2013 08:37 AM
Subject:   &nbs= p;    Re: [Dime] draft-iet= f-dime-overload-reqs-03: REQ 2
Sent by:   &nbs= p;    dime-bounces@ietf.or= g



Hi, Comments inline:

On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&quo= t; <jean-jacques.trottin@alcatel-lucent.com> wrote:

> HI Maria Cruz
>
> Thanks for your feedback:
>
> About REQ 35, my understanding was that the existing REQ35 wording was kept (with still the pending point between MUST and SHOULD as mentioned in a Nigel's mail), and that a new sentence "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers" would be added.
> You propose for REQ35 "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardl= ess whether or not Diameter agents support the overload control mechanism".
>
> In fact it groups the two sentences with a MUST, so it is OK for me. >

I had expected the requirement to work with or without agents would be a new, separate requirement. I think that, while it's related to the need to cross non-supporting agents, it's also distinct in the fact that it requires the solution to work in a pure client-server deployment as well. I prefer the separation, but could live with it if people want to combine them.

> You mentioned the REQ16 which I also agree.

Req16 does not necessarily imply the ability to cross non-supporting agents. It could, for example, be interpreted to mean that non-supporting clients are allowed in parallel with supporting clients. I would not depend on 16 by itself to get the point across.

>
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> For REQ2
>
> About your two proposals
> "The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"
> Or :
> "The mechanism MUST allow Diameter clients to act during an overl= oad situation in order to improve it while impacts are minimized"
> They are OK for me, as they are in the line of my proposal: the client being aware of the overload situation, can act accordingly. Your proposals are more accurate, as indicating client actions.
>
> But the last proposal on the table is the one proposed by Lionel aimed to have a compromise :
> "Diameter clients must be able to use the received load and overl= oad information to support graceful behavior during an overload condition"=
>
> Nigel and I were accepting the Lionel's proposal to find a compromise but nevertheless I prefer your writing and support your proposals that could also be a compromise.
>
> As a conclusion, I think we are in line, and I support your proposals with the objective to find a compromise.

I am fine with either wording. In the interests of not beating Martin's dog (see Martin's email), it's probably easier to stick with Lionel's propo= sed wording, but I will not object if the consensus is to change to Maria's.


>
> Best regards
>
> JJacques
>
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org<= tt>] De la part de Maria Cruz Bartolome
> Envoy=E9 : mercredi 13 mars 2013 09:36
> =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org
> Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thie= rry)
> Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>
> Hello all,
>
> Trying to summarize a bit, for my own clarification here and agreement= .
> I think latest proposals are:
>
> REQ-35:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> REQ-35 (now in draft v.5):
>   REQ 35:  The mechanism SHOULD provide a method for exchang= ing
>            overload and load information between elements that are
>            connected by intermediaries that do not support the
>                                   mechanism
>
> REQ-35 (proposal):
> "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"
>
> I think there is something to add to reflect everything cover by former requirement:
>
> REQ-35 (new proposal):
> "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardless whether or not Diameter agents support the overload control mechanism"
>
>
> Although this may be considered covered by REQ-16:
>   REQ 16:  The overload control mechanism is likely to be deployed
>            incrementally.  The mechanism MUST support a mixed
>            environment where some, but not all, nodes implement it.
>
> But I presume it does not harm to be explicit here, like in former requirement.
>
>
> About the comment by Eric on security (just mail below), we need to check then whether REQ-30 need to be modified, or a new requirement shall apply, right?
>
>   REQ 30:  The mechanism MUST NOT depend on being deployed in
>            environments where all Diamet= er nodes are completely
>            trusted.  It SHOULD operate as effectively as possible in
>            environments where other nodes are malicious; this includes
>            preventing malicious nodes from obtaining more than a fair
>            share of service.  Note that this does not imply any
>            responsibility on the mechani= sm to detect, or take
>            countermeasures against, malicious nodes.
>
>
> REQ-2 complement:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> First, I could accept the proposal we got now on the table, I do not want to keep discussion forever, but... I'd like to propose some enhancemen= ts that I think cover all people concerns stated so far, hopefully without rasing disagreements.
>
> Proposal now is:
> "Diameter clients must be able to use the received load and overl= oad information to support graceful behavior during an overload condition"=
>
> I got some comments on this, taking into account the first proposal was:
> "The mechanism MUST allow Diameter clients to be aware of an overload situation "
>
> I think it is better to request that is "the mechanism" the one that should provide the means for the client to be able to do somet= hing, since we are specifying what the mechanism shall do in other requirements, like:
>
>   REQ 1:   The overload control mechanism MUST provide a communication
>            method for Diameter nodes to exchange load and overload
>            information.
>
>
> Then my -intermediate- proposal would be the following:
> "The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"
>
> Where I think "graceful behavior" is raising some concerns, in facts this is not specific enough in my opinion. Good requirement writing would avoid multiple interpretations. Then, what about this:
>
> New proposal for REQ-2 complement:
> "The mechanism MUST allow Diameter clients to act during an overl= oad situation in order to improve it while impacts are minimized"
>
>
>
> Best regards
> /MCruz
>
>
> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org= ] On Behalf Of Eric McMurry
> Sent: martes, 12 de marzo de 2013 22:42
> To: lionel.morand@orange.com
> Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); BERRY, Nigel (Nigel)
> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>
> I have stated before that I am fine with a MUST provided that the requirement for end to end security is also added.  Traversing non-sup= porint elements without this would be folly
>
> I believe the best compromise here is to leave it as is, so that more thought can be put into this without constraining the solution to something that may be nearly impossible to deploy.  It may also be possible to define the security requirement for specific scenarios where the risk is higher.  This would include a specific requirement (at MUST level) stating that e2e security is required for traversing non-supporting element= s.  I believe that this approach is generally consistent with what some have been discussing about using a MUST level on 35 along with constraints.=
>
> Eric
>
>
> On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote:
>
>> Almost the end :)
>>
>> Remaining issue: REQ35
>>
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is strong recommendation for solution designers i.e. if you can meet this requirement, your solution will have greater chances to be selected than a solution without, is it acceptable to keep the "SHOULD" in the draft?
>>>
>>> OK or NOK?
>>>
>>
>> OK.
>>
>> I would also accept a MUST, with the understanding that there may be limitations on what a non-supporting intermediary can do and still be traversable.
>>
>> [Nigel] A number of people prefer the "must" so can we compromise on
>> this use if Ben can accept this, so we can ensure the Client gets the
>> appropriate information so it can act if necessary
>>
>> [LM] Not so sure about the number of voices for the "MUST&quo= t;...
>>
>> Have we accepted the requirement(s) about working both with or without agents?
>> [Nigel] Ben, I am not sure which Requirement you are referring to but the solution has to work with and without Diameter Agents (stateful or not stateful) involved so any requirement should not disallow these scenarios.
>>
>> [LM] this requirement was agreed: "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"
>>
>>
>> -----Message d'origine-----
>> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent= .com]
>> Envoy=E9 : mardi 12 mars 2013 16:33
>> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQ= UES
>> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thier= ry
>> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>>
>> Hi Lionel,
>> JJ's laptop is on the blink so I will attempt to answer, See in-li= ne,
>> Kind Regards, Nigel
>>
>> -----Original Message-----
>> From: Ben Campbell [<= tt>mailto:ben@nostrum.com= ]
>> Sent: 12 March 2013 14:44
>> To: lionel.morand@orange.com
>> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE,
>> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry)
>> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>>
>> Hi comments inline:
>>
>> On Mar 12, 2013, at 9:59 AM, <lionel.morand@orange.com> wrote:
>>
>>> Hi,
>>>
>>> Honestly, I don't understand why we have to go down each time to the solution space to understand a requirement!
>>> Can we try to make it simple when possible?
>>
>> My solution examples were intended to illustrate that there can be more than one solution approach, and we should be careful not to over-co= nstrain the solution in the requirements. I did not mean for any of them to be assumed as the "real" solution.
>> [Nigel] I agree with Ben we have to dip our toe in the water of potential solutions that deal with all scenarios in order to understand the correct wording of requirements.
>>
>>>
>>> 1/ REQ 2 complement:
>>>
>>> Based on the different comments, my proposal for the new requi= rement is the following:
>>> "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition"
>>>
>>> And the question is: OK or NOK i.e. can you live with?
>>
>> Grudgingly OK, with the provision that this allows but does not require the information to be sent end-to-end from server to client.
>>
>> I would be =5Fconsiderably=5F happier with something of the form of "The solution must support graceful client behavior during an overload condition."
>> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition" providing a necessary consequen= ce of graceful behaviour may involve drastic load shedding at the client or the active proxy.
>>
>>
>>>
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is strong recommendation for solution designers i.e. if you can meet this requirement, your solution will have greater chances to be selected than a solution without, is it acceptable to keep the "SHOULD" in the draft?
>>>
>>> OK or NOK?
>>>
>>
>> OK.
>>
>> I would also accept a MUST, with the understanding that there may be limitations on what a non-supporting intermediary can do and still be traversable.
>> [Nigel] A number of people prefer the "must" so can we compromise on
>> this use if Ben can accept this, so we can ensure the Client gets the
>> appropriate information so it can act if necessary
>>
>> Have we accepted the requirement(s) about working both with or without agents?
>> [Nigel] Ben, I am not sure which Requirement you are referring to but the solution has to work with and without Diameter Agents (stateful or not stateful) involved so any requirement should not disallow these scenarios.
>>
>>
>> [...]
>>
>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> 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, France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
>> DiME mailing list
>> DiME@ietf.org
>> <= tt>https://www.ietf.org/mailman/listinfo/dime
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> DiME mailing list
> DiME@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/dime
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> DiME mailing list
> DiME@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/dime
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> DiME mailing list
> DiME@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/dime

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--=_alternative 0049BD9985257B2E_=-- From srdonovan@usdonovans.com Thu Mar 14 06:33:25 2013 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 11B1511E8111; Thu, 14 Mar 2013 06:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRU4ELcB4Lov; Thu, 14 Mar 2013 06:33:21 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) by ietfa.amsl.com (Postfix) with ESMTP id E9CB711E8121; Thu, 14 Mar 2013 06:33:20 -0700 (PDT) Received: from dhcp-1336.meeting.ietf.org ([130.129.19.54]:62185) by biz131.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UG8HW-0006P0-8t; Thu, 14 Mar 2013 06:33:18 -0700 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-15-561223729 From: Steve Donovan In-Reply-To: Date: Thu, 14 Mar 2013 09:33:16 -0400 Message-Id: <4010D5B9-645A-4C18-A85A-A8ABA596E4B3@usdonovans.com> References: <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: Janet P Gunn X-Mailer: Apple Mail (2.1085) 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 Cc: dime-bounces@ietf.org, "BERRY, Nigel \(Nigel\)" , "DRAGE, Keith \(Keith\)" , "Bessis, Thierry \(Thierry\)" , "dime@ietf.org" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 13:33:25 -0000 --Apple-Mail-15-561223729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This was the proposal in the meeting. I don't believe that Eric was = participate and, as such, would not have known. Steve On Mar 14, 2013, at 9:25 AM, Janet P Gunn wrote: > WRT "gracefully" in Req 2. I thought we agreed to incorporate a = reference to REQ 3, e.g., "gracefully (in accordance with Req 3)"=20 >=20 > Janet >=20 > This is a PRIVATE message. If you are not the intended recipient, = please delete without copying and kindly advise us by e-mail of the = mistake in delivery. NOTE: Regardless of content, this e-mail shall not = operate to bind CSC to any order or other contract unless pursuant to = explicit written agreement or government initiative expressly permitting = the use of e-mail for such purpose.=20 >=20 >=20 >=20 > From: Ben Campbell =20 > To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = =20 > Cc: "BERRY, Nigel \(Nigel\)" , = "DRAGE, Keith \(Keith\)" , = "Bessis, Thierry \(Thierry\)" = , "dime@ietf.org" =20 > Date: 03/13/2013 08:37 AM=20 > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2=20 > Sent by: dime-bounces@ietf.org=20 >=20 >=20 >=20 > Hi, Comments inline: >=20 > On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 > > HI Maria Cruz > >=20 > > Thanks for your feedback: > >=20 > > About REQ 35, my understanding was that the existing REQ35 wording = was kept (with still the pending point between MUST and SHOULD as = mentioned in a Nigel's mail), and that a new sentence "The solution MUST = work in the presence or absence of Diameter agents between Diameter = clients and servers" would be added.=20 > > You propose for REQ35 "The solution MUST work in the presence or = absence of Diameter agents between Diameter clients and servers, = regardless whether or not Diameter agents support the overload control = mechanism".=20 > >=20 > > In fact it groups the two sentences with a MUST, so it is OK for me. > >=20 >=20 > I had expected the requirement to work with or without agents would be = a new, separate requirement. I think that, while it's related to the = need to cross non-supporting agents, it's also distinct in the fact that = it requires the solution to work in a pure client-server deployment as = well. I prefer the separation, but could live with it if people want to = combine them. >=20 > > You mentioned the REQ16 which I also agree. >=20 > Req16 does not necessarily imply the ability to cross non-supporting = agents. It could, for example, be interpreted to mean that = non-supporting clients are allowed in parallel with supporting clients. = I would not depend on 16 by itself to get the point across.=20 >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > For REQ2=20 > >=20 > > About your two proposals > > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" > > Or : > > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" > > They are OK for me, as they are in the line of my proposal: the = client being aware of the overload situation, can act accordingly. Your = proposals are more accurate, as indicating client actions. > >=20 > > But the last proposal on the table is the one proposed by Lionel = aimed to have a compromise : > > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" > >=20 > > Nigel and I were accepting the Lionel's proposal to find a = compromise but nevertheless I prefer your writing and support your = proposals that could also be a compromise. > >=20 > > As a conclusion, I think we are in line, and I support your = proposals with the objective to find a compromise. >=20 > I am fine with either wording. In the interests of not beating = Martin's dog (see Martin's email), it's probably easier to stick with = Lionel's proposed wording, but I will not object if the consensus is to = change to Maria's. >=20 >=20 > >=20 > > Best regards > >=20 > > JJacques > >=20 > > -----Message d'origine----- > > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Maria Cruz Bartolome > > Envoy=E9 : mercredi 13 mars 2013 09:36 > > =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org > > Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry = (Thierry) > > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > >=20 > > Hello all, > >=20 > > Trying to summarize a bit, for my own clarification here and = agreement. > > I think latest proposals are: > >=20 > > REQ-35: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > REQ-35 (now in draft v.5): > > REQ 35: The mechanism SHOULD provide a method for exchanging > > overload and load information between elements that are > > connected by intermediaries that do not support the > > mechanism > >=20 > > REQ-35 (proposal): > > "The solution MUST work in the presence or absence of Diameter = agents between Diameter clients and servers" > >=20 > > I think there is something to add to reflect everything cover by = former requirement: > >=20 > > REQ-35 (new proposal): > > "The solution MUST work in the presence or absence of Diameter = agents between Diameter clients and servers, regardless whether or not = Diameter agents support the overload control mechanism" > >=20 > >=20 > > Although this may be considered covered by REQ-16: > > REQ 16: The overload control mechanism is likely to be deployed > > incrementally. The mechanism MUST support a mixed > > environment where some, but not all, nodes implement it. > >=20 > > But I presume it does not harm to be explicit here, like in former = requirement. > >=20 > >=20 > > About the comment by Eric on security (just mail below), we need to = check then whether REQ-30 need to be modified, or a new requirement = shall apply, right? > >=20 > > REQ 30: The mechanism MUST NOT depend on being deployed in > > environments where all Diameter nodes are completely > > trusted. It SHOULD operate as effectively as possible in > > environments where other nodes are malicious; this = includes > > preventing malicious nodes from obtaining more than a = fair > > share of service. Note that this does not imply any > > responsibility on the mechanism to detect, or take > > countermeasures against, malicious nodes. > >=20 > >=20 > > REQ-2 complement: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > First, I could accept the proposal we got now on the table, I do not = want to keep discussion forever, but... I'd like to propose some = enhancements that I think cover all people concerns stated so far, = hopefully without rasing disagreements. > >=20 > > Proposal now is:=20 > > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" > >=20 > > I got some comments on this, taking into account the first proposal = was: > > "The mechanism MUST allow Diameter clients to be aware of an = overload situation " > >=20 > > I think it is better to request that is "the mechanism" the one that = should provide the means for the client to be able to do something, = since we are specifying what the mechanism shall do in other = requirements, like: > >=20 > > REQ 1: The overload control mechanism MUST provide a = communication > > method for Diameter nodes to exchange load and overload > > information. > >=20 > >=20 > > Then my -intermediate- proposal would be the following: > > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" > >=20 > > Where I think "graceful behavior" is raising some concerns, in facts = this is not specific enough in my opinion. Good requirement writing = would avoid multiple interpretations. Then, what about this: > >=20 > > New proposal for REQ-2 complement: > > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" > >=20 > >=20 > >=20 > > Best regards > > /MCruz > >=20 > >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Eric McMurry > > Sent: martes, 12 de marzo de 2013 22:42 > > To: lionel.morand@orange.com > > Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); = BERRY, Nigel (Nigel) > > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > >=20 > > I have stated before that I am fine with a MUST provided that the = requirement for end to end security is also added. Traversing = non-supporint elements without this would be folly > >=20 > > I believe the best compromise here is to leave it as is, so that = more thought can be put into this without constraining the solution to = something that may be nearly impossible to deploy. It may also be = possible to define the security requirement for specific scenarios where = the risk is higher. This would include a specific requirement (at MUST = level) stating that e2e security is required for traversing = non-supporting elements. I believe that this approach is generally = consistent with what some have been discussing about using a MUST level = on 35 along with constraints. > >=20 > > Eric > >=20 > >=20 > > On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > >=20 > >> Almost the end :) > >>=20 > >> Remaining issue: REQ35 > >>=20 > >>> 2/ REQ 35: > >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? > >>>=20 > >>> OK or NOK? > >>>=20 > >>=20 > >> OK. > >>=20 > >> I would also accept a MUST, with the understanding that there may = be limitations on what a non-supporting intermediary can do and still be = traversable. > >>=20 > >> [Nigel] A number of people prefer the "must" so can we compromise = on=20 > >> this use if Ben can accept this, so we can ensure the Client gets = the=20 > >> appropriate information so it can act if necessary > >>=20 > >> [LM] Not so sure about the number of voices for the "MUST"... > >>=20 > >> Have we accepted the requirement(s) about working both with or = without agents? > >> [Nigel] Ben, I am not sure which Requirement you are referring to = but the solution has to work with and without Diameter Agents (stateful = or not stateful) involved so any requirement should not disallow these = scenarios. > >>=20 > >> [LM] this requirement was agreed: "The solution MUST work in the = presence or absence of Diameter agents between Diameter clients and = servers" > >>=20 > >>=20 > >> -----Message d'origine----- > >> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] > >> Envoy=E9 : mardi 12 mars 2013 16:33 > >> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, = JEAN-JACQUES=20 > >> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, = Thierry=20 > >> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ = 2 > >>=20 > >> Hi Lionel, > >> JJ's laptop is on the blink so I will attempt to answer, See = in-line,=20 > >> Kind Regards, Nigel > >>=20 > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: 12 March 2013 14:44 > >> To: lionel.morand@orange.com > >> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); = DRAGE,=20 > >> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > >> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > >>=20 > >> Hi comments inline: > >>=20 > >> On Mar 12, 2013, at 9:59 AM, wrote: > >>=20 > >>> Hi, > >>>=20 > >>> Honestly, I don't understand why we have to go down each time to = the solution space to understand a requirement! > >>> Can we try to make it simple when possible? > >>=20 > >> My solution examples were intended to illustrate that there can be = more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. > >> [Nigel] I agree with Ben we have to dip our toe in the water of = potential solutions that deal with all scenarios in order to understand = the correct wording of requirements. > >>=20 > >>>=20 > >>> 1/ REQ 2 complement: > >>>=20 > >>> Based on the different comments, my proposal for the new = requirement is the following: > >>> "Diameter clients must be able to use the received load and = overload information to support graceful behavior during an overload = condition" > >>>=20 > >>> And the question is: OK or NOK i.e. can you live with? > >>=20 > >> Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client. > >>=20 > >> I would be _considerably_ happier with something of the form of = "The solution must support graceful client behavior during an overload = condition." > >> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to = use the received load and overload information to support graceful = behavior during an overload condition" providing a necessary consequence = of graceful behaviour may involve drastic load shedding at the client or = the active proxy. > >>=20 > >>=20 > >>>=20 > >>> 2/ REQ 35: > >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? > >>>=20 > >>> OK or NOK? > >>>=20 > >>=20 > >> OK. > >>=20 > >> I would also accept a MUST, with the understanding that there may = be limitations on what a non-supporting intermediary can do and still be = traversable. > >> [Nigel] A number of people prefer the "must" so can we compromise = on=20 > >> this use if Ben can accept this, so we can ensure the Client gets = the=20 > >> appropriate information so it can act if necessary > >>=20 > >> Have we accepted the requirement(s) about working both with or = without agents? > >> [Nigel] Ben, I am not sure which Requirement you are referring to = but the solution has to work with and without Diameter Agents (stateful = or not stateful) involved so any requirement should not disallow these = scenarios. > >>=20 > >>=20 > >> [...] > >>=20 > >>=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 que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, France Telecom - Orange decline toute = responsabilite si ce message a ete altere, 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 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > >> Thank you. > >>=20 > >> _______________________________________________ > >> 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 > > _______________________________________________ > > 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 > _______________________________________________ > 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 --Apple-Mail-15-561223729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 This = was the proposal in the meeting.  I don't believe that Eric was = participate and, as such, would not have = known.

Steve

On Mar 14, 2013, = at 9:25 AM, Janet P Gunn wrote:

WRT "gracefully" in Req 2. I thought we agreed to incorporate a reference to REQ 3, e.g., "gracefully (in accordance with Req 3)"

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit = written agreement or government initiative expressly permitting the use of = e-mail for such purpose.



From:   =      Ben Campbell <ben@nostrum.com>
To:   =      "TROTTIN,        JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trott= in@alcatel-lucent.com>
Cc:   =      "BERRY, Nigel \(Nigel\)" <nigel.berry@alcatel-lucent.= com>, "DRAGE,        Keith \(Keith\)" <keith.drage@alcatel-lucent.= com>, "Bessis,        Thierry \(Thierry\)" <thierry.bessis@alcatel-l= ucent.com>, "dime@ietf.org" = <dime@ietf.org>
Date:   =      03/13/2013 08:37 = AM
Subject: =        Re: [Dime] = draft-ietf-dime-overload-reqs-03: REQ 2
Sent by: =        dime-bounces@ietf.org



Hi, Comments inline:

On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trott= in@alcatel-lucent.com> wrote:

> HI Maria Cruz
>
> Thanks for your feedback:
>
> About REQ 35, my understanding was that the existing REQ35 wording was kept (with still the pending point between MUST and SHOULD as = mentioned in a Nigel's mail), and that a new sentence "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers" would be added.
> You propose for REQ35 "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, = regardless whether or not Diameter agents support the overload control mechanism".
>
> In fact it groups the two sentences with a MUST, so it is OK for = me.
>

I had expected the requirement to work with or without agents would be a new, separate requirement. I think that, while it's related to the = need to cross non-supporting agents, it's also distinct in the fact that it requires the solution to work in a pure client-server deployment as = well. I prefer the separation, but could live with it if people want to = combine them.

> You mentioned the REQ16 which I also agree.

Req16 does not necessarily imply the ability to cross non-supporting = agents. It could, for example, be interpreted to mean that non-supporting = clients are allowed in parallel with supporting clients. I would not depend on 16 by itself to get the point across.

>
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> For REQ2
>
> About your two proposals
> "The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"
> Or :
> "The mechanism MUST allow Diameter clients to act during an = overload situation in order to improve it while impacts are minimized"
> They are OK for me, as they are in the line of my proposal: the = client being aware of the overload situation, can act accordingly. Your = proposals are more accurate, as indicating client actions.
>
> But the last proposal on the table is the one proposed by Lionel = aimed to have a compromise :
> "Diameter clients must be able to use the received load and = overload information to support graceful behavior during an overload = condition"
>
> Nigel and I were accepting the Lionel's proposal to find a = compromise but nevertheless I prefer your writing and support your proposals that could also be a compromise.
>
> As a conclusion, I think we are in line, and I support your = proposals with the objective to find a compromise.

I am fine with either wording. In the interests of not beating Martin's dog (see Martin's email), it's probably easier to stick with Lionel's = proposed wording, but I will not object if the consensus is to change to = Maria's.


>
> Best regards
>
> JJacques
>
> -----Message d'origine-----
> De : dime-bounces@ietf.org = [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
> Envoy=E9 : mercredi 13 mars 2013 09:36
> =C0 : Eric McMurry; lionel.morand@orange.com; = dime@ietf.org
> Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry = (Thierry)
> Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>
> Hello all,
>
> Trying to summarize a bit, for my own clarification here and = agreement.
> I think latest proposals are:
>
> REQ-35:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> REQ-35 (now in draft v.5):
>   REQ 35:  The mechanism SHOULD provide a method for = exchanging
>            overload and load = information between elements that are
>            connected by = intermediaries that do not support the
>                                   mechanism
>
> REQ-35 (proposal):
> "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"
>
> I think there is something to add to reflect everything cover by = former requirement:
>
> REQ-35 (new proposal):
> "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardless whether or not Diameter agents support the overload control mechanism"
>
>
> Although this may be considered covered by REQ-16:
>   REQ 16:  The overload control mechanism is likely to be deployed
>            incrementally.  The mechanism MUST support a mixed
>            environment where some, = but not all, nodes implement it.
>
> But I presume it does not harm to be explicit here, like in former requirement.
>
>
> About the comment by Eric on security (just mail below), we need to check then whether REQ-30 need to be modified, or a new requirement = shall apply, right?
>
>   REQ 30:  The mechanism MUST NOT depend on being = deployed in
>            environments where all = Diameter nodes are completely
>            trusted.  It SHOULD operate as effectively as possible in
>            environments where other nodes are malicious; this includes
>            preventing malicious nodes from obtaining more than a fair
>            share of service. =  Note that this does not imply any
>            responsibility on the = mechanism to detect, or take
>            countermeasures against, malicious nodes.
>
>
> REQ-2 complement:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> First, I could accept the proposal we got now on the table, I do = not want to keep discussion forever, but... I'd like to propose some = enhancements that I think cover all people concerns stated so far, hopefully without rasing disagreements.
>
> Proposal now is:
> "Diameter clients must be able to use the received load and = overload information to support graceful behavior during an overload = condition"
>
> I got some comments on this, taking into account the first proposal was:
> "The mechanism MUST allow Diameter clients to be aware of an overload situation "
>
> I think it is better to request that is "the mechanism" the one that should provide the means for the client to be able to do = something, since we are specifying what the mechanism shall do in other = requirements, like:
>
>   REQ 1:   The overload control mechanism MUST provide a communication
>            method for Diameter nodes to exchange load and overload
>            information.
>
>
> Then my -intermediate- proposal would be the following:
> "The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"
>
> Where I think "graceful behavior" is raising some concerns, in facts this is not specific enough in my opinion. Good requirement = writing would avoid multiple interpretations. Then, what about this:
>
> New proposal for REQ-2 complement:
> "The mechanism MUST allow Diameter clients to act during an = overload situation in order to improve it while impacts are minimized"
>
>
>
> Best regards
> /MCruz
>
>
> -----Original Message-----
> From: dime-bounces@ietf.org = [mailto:dime-bounces@ietf.org] On Behalf Of Eric McMurry
> Sent: martes, 12 de marzo de 2013 22:42
> To: lionel.morand@orange.com
> Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry = (Thierry); BERRY, Nigel (Nigel)
> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>
> I have stated before that I am fine with a MUST provided that the requirement for end to end security is also added.  Traversing = non-supporint elements without this would be folly
>
> I believe the best compromise here is to leave it as is, so that = more thought can be put into this without constraining the solution to = something that may be nearly impossible to deploy.  It may also be possible to define the security requirement for specific scenarios where the risk is higher.  This would include a specific requirement (at MUST = level) stating that e2e security is required for traversing non-supporting = elements.  I believe that this approach is generally consistent with what = some have been discussing about using a MUST level on 35 along with = constraints.
>
> Eric
>
>
> On Mar 12, 2013, at 16:43 , lionel.morand@orange.com = wrote:
>
>> Almost the end :)
>>
>> Remaining issue: REQ35
>>
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is strong recommendation for solution designers i.e. if you can meet this = requirement, your solution will have greater chances to be selected than a solution without, is it acceptable to keep the "SHOULD" in the draft?
>>>
>>> OK or NOK?
>>>
>>
>> OK.
>>
>> I would also accept a MUST, with the understanding that there may be limitations on what a non-supporting intermediary can do and = still be traversable.
>>
>> [Nigel] A number of people prefer the "must" so can we compromise on
>> this use if Ben can accept this, so we can ensure the Client = gets the
>> appropriate information so it can act if necessary
>>
>> [LM] Not so sure about the number of voices for the = "MUST"...
>>
>> Have we accepted the requirement(s) about working both with or without agents?
>> [Nigel] Ben, I am not sure which Requirement you are referring to but the solution has to work with and without Diameter Agents = (stateful or not stateful) involved so any requirement should not disallow these scenarios.
>>
>> [LM] this requirement was agreed: "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"
>>
>>
>> -----Message d'origine-----
>> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com]
>> Envoy=E9 : mardi 12 mars 2013 16:33
>> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, = JEAN-JACQUES
>> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry
>> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>>
>> Hi Lionel,
>> JJ's laptop is on the blink so I will attempt to answer, See = in-line,
>> Kind Regards, Nigel
>>
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@nostrum.com]
>> Sent: 12 March 2013 14:44
>> To: lionel.morand@orange.com
>> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE,
>> Keith (Keith); dime@ietf.org; Bessis, Thierry = (Thierry)
>> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>>
>> Hi comments inline:
>>
>> On Mar 12, 2013, at 9:59 AM, <lionel.morand@orange.com> wrote:
>>
>>> Hi,
>>>
>>> Honestly, I don't understand why we have to go down each = time to the solution space to understand a requirement!
>>> Can we try to make it simple when possible?
>>
>> My solution examples were intended to illustrate that there can be more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any of them to be assumed as the "real" solution.
>> [Nigel] I agree with Ben we have to dip our toe in the water of potential solutions that deal with all scenarios in order to understand the correct wording of requirements.
>>
>>>
>>> 1/ REQ 2 complement:
>>>
>>> Based on the different comments, my proposal for the new = requirement is the following:
>>> "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition"
>>>
>>> And the question is: OK or NOK i.e. can you live with?
>>
>> Grudgingly OK, with the provision that this allows but does not require the information to be sent end-to-end from server to client.
>>
>> I would be _considerably_ happier with something of the form of "The solution must support graceful client behavior during an overload condition."
>> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use the received load and overload information to support = graceful behavior during an overload condition" providing a necessary consequence of graceful behaviour may involve drastic load shedding at the client or the active proxy.
>>
>>
>>>
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is strong recommendation for solution designers i.e. if you can meet this = requirement, your solution will have greater chances to be selected than a solution without, is it acceptable to keep the "SHOULD" in the draft?
>>>
>>> OK or NOK?
>>>
>>
>> OK.
>>
>> I would also accept a MUST, with the understanding that there may be limitations on what a non-supporting intermediary can do and = still be traversable.
>> [Nigel] A number of people prefer the "must" so can we compromise on
>> this use if Ben can accept this, so we can ensure the Client = gets the
>> appropriate information so it can act if necessary
>>
>> Have we accepted the requirement(s) about working both with or without agents?
>> [Nigel] Ben, I am not sure which Requirement you are referring to but the solution has to work with and without Diameter Agents = (stateful or not stateful) involved so any requirement should not disallow these scenarios.
>>
>>
>> [...]
>>
>>
>> = ______________________________________________________________________
= >> ___________________________________________________
>>
>> 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, France Telecom - 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, France Telecom - 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<= font size=3D"2">
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime<= font size=3D"2">
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime<= font size=3D"2">
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime<= font size=3D"2">

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime<= font size=3D"2">
_______________________________________________
DiME mailing = list
DiME@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dime

= --Apple-Mail-15-561223729-- From ben@nostrum.com Thu Mar 14 06:35:09 2013 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 7B9471F0D0E for ; Thu, 14 Mar 2013 06:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.977 X-Spam-Level: X-Spam-Status: No, score=-100.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8TXpVEDPmZ0 for ; Thu, 14 Mar 2013 06:35:07 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C34941F0D0D for ; Thu, 14 Mar 2013 06:35:04 -0700 (PDT) Received: from dhcp-643f.meeting.ietf.org (dhcp-643f.meeting.ietf.org [130.129.100.63]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2EDYubN092104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Mar 2013 08:34:57 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Thu, 14 Mar 2013 09:34:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: Janet P Gunn X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 130.129.100.63 is authenticated by a trusted mechanism) Cc: dime@ietf.org, "DRAGE, Keith \(Keith\)" , "BERRY, Nigel \(Nigel\)" , "Bessis, Thierry \(Thierry\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 13:35:09 -0000 Yes, we did. My email was from before that discussion :-) Thanks! Ben. On Mar 14, 2013, at 9:25 AM, Janet P Gunn wrote: > WRT "gracefully" in Req 2. I thought we agreed to incorporate a = reference to REQ 3, e.g., "gracefully (in accordance with Req 3)"=20 >=20 > Janet >=20 > This is a PRIVATE message. If you are not the intended recipient, = please delete without copying and kindly advise us by e-mail of the = mistake in delivery. NOTE: Regardless of content, this e-mail shall not = operate to bind CSC to any order or other contract unless pursuant to = explicit written agreement or government initiative expressly permitting = the use of e-mail for such purpose.=20 >=20 >=20 >=20 > From: Ben Campbell =20 > To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = =20 > Cc: "BERRY, Nigel \(Nigel\)" , = "DRAGE, Keith \(Keith\)" , = "Bessis, Thierry \(Thierry\)" = , "dime@ietf.org" =20 > Date: 03/13/2013 08:37 AM=20 > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2=20 > Sent by: dime-bounces@ietf.org=20 >=20 >=20 >=20 > Hi, Comments inline: >=20 > On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 > > HI Maria Cruz > >=20 > > Thanks for your feedback: > >=20 > > About REQ 35, my understanding was that the existing REQ35 wording = was kept (with still the pending point between MUST and SHOULD as = mentioned in a Nigel's mail), and that a new sentence "The solution MUST = work in the presence or absence of Diameter agents between Diameter = clients and servers" would be added.=20 > > You propose for REQ35 "The solution MUST work in the presence or = absence of Diameter agents between Diameter clients and servers, = regardless whether or not Diameter agents support the overload control = mechanism".=20 > >=20 > > In fact it groups the two sentences with a MUST, so it is OK for me. > >=20 >=20 > I had expected the requirement to work with or without agents would be = a new, separate requirement. I think that, while it's related to the = need to cross non-supporting agents, it's also distinct in the fact that = it requires the solution to work in a pure client-server deployment as = well. I prefer the separation, but could live with it if people want to = combine them. >=20 > > You mentioned the REQ16 which I also agree. >=20 > Req16 does not necessarily imply the ability to cross non-supporting = agents. It could, for example, be interpreted to mean that = non-supporting clients are allowed in parallel with supporting clients. = I would not depend on 16 by itself to get the point across.=20 >=20 > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > For REQ2=20 > >=20 > > About your two proposals > > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" > > Or : > > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" > > They are OK for me, as they are in the line of my proposal: the = client being aware of the overload situation, can act accordingly. Your = proposals are more accurate, as indicating client actions. > >=20 > > But the last proposal on the table is the one proposed by Lionel = aimed to have a compromise : > > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" > >=20 > > Nigel and I were accepting the Lionel's proposal to find a = compromise but nevertheless I prefer your writing and support your = proposals that could also be a compromise. > >=20 > > As a conclusion, I think we are in line, and I support your = proposals with the objective to find a compromise. >=20 > I am fine with either wording. In the interests of not beating = Martin's dog (see Martin's email), it's probably easier to stick with = Lionel's proposed wording, but I will not object if the consensus is to = change to Maria's. >=20 >=20 > >=20 > > Best regards > >=20 > > JJacques > >=20 > > -----Message d'origine----- > > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Maria Cruz Bartolome > > Envoy=E9 : mercredi 13 mars 2013 09:36 > > =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org > > Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry = (Thierry) > > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > >=20 > > Hello all, > >=20 > > Trying to summarize a bit, for my own clarification here and = agreement. > > I think latest proposals are: > >=20 > > REQ-35: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > REQ-35 (now in draft v.5): > > REQ 35: The mechanism SHOULD provide a method for exchanging > > overload and load information between elements that are > > connected by intermediaries that do not support the > > mechanism > >=20 > > REQ-35 (proposal): > > "The solution MUST work in the presence or absence of Diameter = agents between Diameter clients and servers" > >=20 > > I think there is something to add to reflect everything cover by = former requirement: > >=20 > > REQ-35 (new proposal): > > "The solution MUST work in the presence or absence of Diameter = agents between Diameter clients and servers, regardless whether or not = Diameter agents support the overload control mechanism" > >=20 > >=20 > > Although this may be considered covered by REQ-16: > > REQ 16: The overload control mechanism is likely to be deployed > > incrementally. The mechanism MUST support a mixed > > environment where some, but not all, nodes implement it. > >=20 > > But I presume it does not harm to be explicit here, like in former = requirement. > >=20 > >=20 > > About the comment by Eric on security (just mail below), we need to = check then whether REQ-30 need to be modified, or a new requirement = shall apply, right? > >=20 > > REQ 30: The mechanism MUST NOT depend on being deployed in > > environments where all Diameter nodes are completely > > trusted. It SHOULD operate as effectively as possible in > > environments where other nodes are malicious; this = includes > > preventing malicious nodes from obtaining more than a = fair > > share of service. Note that this does not imply any > > responsibility on the mechanism to detect, or take > > countermeasures against, malicious nodes. > >=20 > >=20 > > REQ-2 complement: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >=20 > > First, I could accept the proposal we got now on the table, I do not = want to keep discussion forever, but... I'd like to propose some = enhancements that I think cover all people concerns stated so far, = hopefully without rasing disagreements. > >=20 > > Proposal now is:=20 > > "Diameter clients must be able to use the received load and overload = information to support graceful behavior during an overload condition" > >=20 > > I got some comments on this, taking into account the first proposal = was: > > "The mechanism MUST allow Diameter clients to be aware of an = overload situation " > >=20 > > I think it is better to request that is "the mechanism" the one that = should provide the means for the client to be able to do something, = since we are specifying what the mechanism shall do in other = requirements, like: > >=20 > > REQ 1: The overload control mechanism MUST provide a = communication > > method for Diameter nodes to exchange load and overload > > information. > >=20 > >=20 > > Then my -intermediate- proposal would be the following: > > "The mechanism MUST allow Diameter clients to support graceful = behavior during an overload situation" > >=20 > > Where I think "graceful behavior" is raising some concerns, in facts = this is not specific enough in my opinion. Good requirement writing = would avoid multiple interpretations. Then, what about this: > >=20 > > New proposal for REQ-2 complement: > > "The mechanism MUST allow Diameter clients to act during an overload = situation in order to improve it while impacts are minimized" > >=20 > >=20 > >=20 > > Best regards > > /MCruz > >=20 > >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Eric McMurry > > Sent: martes, 12 de marzo de 2013 22:42 > > To: lionel.morand@orange.com > > Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); = BERRY, Nigel (Nigel) > > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > >=20 > > I have stated before that I am fine with a MUST provided that the = requirement for end to end security is also added. Traversing = non-supporint elements without this would be folly > >=20 > > I believe the best compromise here is to leave it as is, so that = more thought can be put into this without constraining the solution to = something that may be nearly impossible to deploy. It may also be = possible to define the security requirement for specific scenarios where = the risk is higher. This would include a specific requirement (at MUST = level) stating that e2e security is required for traversing = non-supporting elements. I believe that this approach is generally = consistent with what some have been discussing about using a MUST level = on 35 along with constraints. > >=20 > > Eric > >=20 > >=20 > > On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > >=20 > >> Almost the end :) > >>=20 > >> Remaining issue: REQ35 > >>=20 > >>> 2/ REQ 35: > >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? > >>>=20 > >>> OK or NOK? > >>>=20 > >>=20 > >> OK. > >>=20 > >> I would also accept a MUST, with the understanding that there may = be limitations on what a non-supporting intermediary can do and still be = traversable. > >>=20 > >> [Nigel] A number of people prefer the "must" so can we compromise = on=20 > >> this use if Ben can accept this, so we can ensure the Client gets = the=20 > >> appropriate information so it can act if necessary > >>=20 > >> [LM] Not so sure about the number of voices for the "MUST"... > >>=20 > >> Have we accepted the requirement(s) about working both with or = without agents? > >> [Nigel] Ben, I am not sure which Requirement you are referring to = but the solution has to work with and without Diameter Agents (stateful = or not stateful) involved so any requirement should not disallow these = scenarios. > >>=20 > >> [LM] this requirement was agreed: "The solution MUST work in the = presence or absence of Diameter agents between Diameter clients and = servers" > >>=20 > >>=20 > >> -----Message d'origine----- > >> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] > >> Envoy=E9 : mardi 12 mars 2013 16:33 > >> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, = JEAN-JACQUES=20 > >> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, = Thierry=20 > >> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ = 2 > >>=20 > >> Hi Lionel, > >> JJ's laptop is on the blink so I will attempt to answer, See = in-line,=20 > >> Kind Regards, Nigel > >>=20 > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: 12 March 2013 14:44 > >> To: lionel.morand@orange.com > >> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); = DRAGE,=20 > >> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) > >> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > >>=20 > >> Hi comments inline: > >>=20 > >> On Mar 12, 2013, at 9:59 AM, wrote: > >>=20 > >>> Hi, > >>>=20 > >>> Honestly, I don't understand why we have to go down each time to = the solution space to understand a requirement! > >>> Can we try to make it simple when possible? > >>=20 > >> My solution examples were intended to illustrate that there can be = more than one solution approach, and we should be careful not to = over-constrain the solution in the requirements. I did not mean for any = of them to be assumed as the "real" solution. > >> [Nigel] I agree with Ben we have to dip our toe in the water of = potential solutions that deal with all scenarios in order to understand = the correct wording of requirements. > >>=20 > >>>=20 > >>> 1/ REQ 2 complement: > >>>=20 > >>> Based on the different comments, my proposal for the new = requirement is the following: > >>> "Diameter clients must be able to use the received load and = overload information to support graceful behavior during an overload = condition" > >>>=20 > >>> And the question is: OK or NOK i.e. can you live with? > >>=20 > >> Grudgingly OK, with the provision that this allows but does not = require the information to be sent end-to-end from server to client. > >>=20 > >> I would be _considerably_ happier with something of the form of = "The solution must support graceful client behavior during an overload = condition." > >> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to = use the received load and overload information to support graceful = behavior during an overload condition" providing a necessary consequence = of graceful behaviour may involve drastic load shedding at the client or = the active proxy. > >>=20 > >>=20 > >>>=20 > >>> 2/ REQ 35: > >>> With the clarification that the "SHOULD" is strong recommendation = for solution designers i.e. if you can meet this requirement, your = solution will have greater chances to be selected than a solution = without, is it acceptable to keep the "SHOULD" in the draft? > >>>=20 > >>> OK or NOK? > >>>=20 > >>=20 > >> OK. > >>=20 > >> I would also accept a MUST, with the understanding that there may = be limitations on what a non-supporting intermediary can do and still be = traversable. > >> [Nigel] A number of people prefer the "must" so can we compromise = on=20 > >> this use if Ben can accept this, so we can ensure the Client gets = the=20 > >> appropriate information so it can act if necessary > >>=20 > >> Have we accepted the requirement(s) about working both with or = without agents? > >> [Nigel] Ben, I am not sure which Requirement you are referring to = but the solution has to work with and without Diameter Agents (stateful = or not stateful) involved so any requirement should not disallow these = scenarios. > >>=20 > >>=20 > >> [...] > >>=20 > >>=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 que les pieces jointes. Les messages electroniques etant = susceptibles d'alteration, France Telecom - Orange decline toute = responsabilite si ce message a ete altere, 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 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > >> Thank you. > >>=20 > >> _______________________________________________ > >> 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 > > _______________________________________________ > > 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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From lionel.morand@orange.com Thu Mar 14 07:24:58 2013 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 4D94911E814E; Thu, 14 Mar 2013 07:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jQfBWaWPJVG; Thu, 14 Mar 2013 07:24:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B911E80FE; Thu, 14 Mar 2013 07:24:40 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C2A822640F9; Thu, 14 Mar 2013 15:24:39 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A276B27C058; Thu, 14 Mar 2013 15:24:39 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 14 Mar 2013 15:24:39 +0100 From: To: Janet P Gunn , Ben Campbell Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHOILdi6il2AlbS+kqf8eXke2n9UJilPcgw Date: Thu, 14 Mar 2013 14:24:37 +0000 Message-ID: <2298_1363271079_5141DDA7_2298_1086_1_6B7134B31289DC4FAF731D844122B36E16305F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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.197.38.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E16305FPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.5.94520 Cc: "dime-bounces@ietf.org" , "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2013 14:24:58 -0000 --_000_6B7134B31289DC4FAF731D844122B36E16305FPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WFM De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Jan= et P Gunn Envoy=E9 : jeudi 14 mars 2013 14:25 =C0 : Ben Campbell Cc : dime-bounces@ietf.org; BERRY, Nigel (Nigel); DRAGE, Keith (Keith); Bes= sis, Thierry (Thierry); dime@ietf.org Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 WRT "gracefully" in Req 2. I thought we agreed to incorporate a reference t= o REQ 3, e.g., "gracefully (in accordance with Req 3)" Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: Ben Campbell To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Cc: "BERRY, Nigel \(Nigel\)" , "DRAG= E, Keith \(Keith\)" , "Bessis, = Thierry \(Thierry\)" , "dime@ietf.org"= Date: 03/13/2013 08:37 AM Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Sent by: dime-bounces@ietf.org ________________________________ Hi, Comments inline: On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" wrote: > HI Maria Cruz > > Thanks for your feedback: > > About REQ 35, my understanding was that the existing REQ35 wording was ke= pt (with still the pending point between MUST and SHOULD as mentioned in a = Nigel's mail), and that a new sentence "The solution MUST work in the prese= nce or absence of Diameter agents between Diameter clients and servers" wou= ld be added. > You propose for REQ35 "The solution MUST work in the presence or absence = of Diameter agents between Diameter clients and servers, regardless whether= or not Diameter agents support the overload control mechanism". > > In fact it groups the two sentences with a MUST, so it is OK for me. > I had expected the requirement to work with or without agents would be a ne= w, separate requirement. I think that, while it's related to the need to cr= oss non-supporting agents, it's also distinct in the fact that it requires = the solution to work in a pure client-server deployment as well. I prefer t= he separation, but could live with it if people want to combine them. > You mentioned the REQ16 which I also agree. Req16 does not necessarily imply the ability to cross non-supporting agents= . It could, for example, be interpreted to mean that non-supporting clients= are allowed in parallel with supporting clients. I would not depend on 16 = by itself to get the point across. > > =3D=3D=3D=3D=3D=3D=3D=3D > > For REQ2 > > About your two proposals > "The mechanism MUST allow Diameter clients to support graceful behavior d= uring an overload situation" > Or : > "The mechanism MUST allow Diameter clients to act during an overload situ= ation in order to improve it while impacts are minimized" > They are OK for me, as they are in the line of my proposal: the client be= ing aware of the overload situation, can act accordingly. Your proposals ar= e more accurate, as indicating client actions. > > But the last proposal on the table is the one proposed by Lionel aimed to= have a compromise : > "Diameter clients must be able to use the received load and overload info= rmation to support graceful behavior during an overload condition" > > Nigel and I were accepting the Lionel's proposal to find a compromise but= nevertheless I prefer your writing and support your proposals that could a= lso be a compromise. > > As a conclusion, I think we are in line, and I support your proposals wit= h the objective to find a compromise. I am fine with either wording. In the interests of not beating Martin's dog= (see Martin's email), it's probably easier to stick with Lionel's proposed= wording, but I will not object if the consensus is to change to Maria's. > > Best regards > > JJacques > > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de M= aria Cruz Bartolome > Envoy=E9 : mercredi 13 mars 2013 09:36 > =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org > Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) > Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > > Hello all, > > Trying to summarize a bit, for my own clarification here and agreement. > I think latest proposals are: > > REQ-35: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > REQ-35 (now in draft v.5): > REQ 35: The mechanism SHOULD provide a method for exchanging > overload and load information between elements that are > connected by intermediaries that do not support the > mechanism > > REQ-35 (proposal): > "The solution MUST work in the presence or absence of Diameter agents bet= ween Diameter clients and servers" > > I think there is something to add to reflect everything cover by former r= equirement: > > REQ-35 (new proposal): > "The solution MUST work in the presence or absence of Diameter agents bet= ween Diameter clients and servers, regardless whether or not Diameter agent= s support the overload control mechanism" > > > Although this may be considered covered by REQ-16: > REQ 16: The overload control mechanism is likely to be deployed > incrementally. The mechanism MUST support a mixed > environment where some, but not all, nodes implement it. > > But I presume it does not harm to be explicit here, like in former requir= ement. > > > About the comment by Eric on security (just mail below), we need to check= then whether REQ-30 need to be modified, or a new requirement shall apply,= right? > > REQ 30: The mechanism MUST NOT depend on being deployed in > environments where all Diameter nodes are completely > trusted. It SHOULD operate as effectively as possible in > environments where other nodes are malicious; this includes > preventing malicious nodes from obtaining more than a fair > share of service. Note that this does not imply any > responsibility on the mechanism to detect, or take > countermeasures against, malicious nodes. > > > REQ-2 complement: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > First, I could accept the proposal we got now on the table, I do not want= to keep discussion forever, but... I'd like to propose some enhancements t= hat I think cover all people concerns stated so far, hopefully without rasi= ng disagreements. > > Proposal now is: > "Diameter clients must be able to use the received load and overload info= rmation to support graceful behavior during an overload condition" > > I got some comments on this, taking into account the first proposal was: > "The mechanism MUST allow Diameter clients to be aware of an overload sit= uation " > > I think it is better to request that is "the mechanism" the one that shou= ld provide the means for the client to be able to do something, since we ar= e specifying what the mechanism shall do in other requirements, like: > > REQ 1: The overload control mechanism MUST provide a communication > method for Diameter nodes to exchange load and overload > information. > > > Then my -intermediate- proposal would be the following: > "The mechanism MUST allow Diameter clients to support graceful behavior d= uring an overload situation" > > Where I think "graceful behavior" is raising some concerns, in facts this= is not specific enough in my opinion. Good requirement writing would avoid= multiple interpretations. Then, what about this: > > New proposal for REQ-2 complement: > "The mechanism MUST allow Diameter clients to act during an overload situ= ation in order to improve it while impacts are minimized" > > > > Best regards > /MCruz > > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of E= ric McMurry > Sent: martes, 12 de marzo de 2013 22:42 > To: lionel.morand@orange.com > Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry); BERRY= , Nigel (Nigel) > Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > > I have stated before that I am fine with a MUST provided that the require= ment for end to end security is also added. Traversing non-supporint eleme= nts without this would be folly > > I believe the best compromise here is to leave it as is, so that more tho= ught can be put into this without constraining the solution to something th= at may be nearly impossible to deploy. It may also be possible to define t= he security requirement for specific scenarios where the risk is higher. T= his would include a specific requirement (at MUST level) stating that e2e s= ecurity is required for traversing non-supporting elements. I believe that= this approach is generally consistent with what some have been discussing = about using a MUST level on 35 along with constraints. > > Eric > > > On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: > >> Almost the end :) >> >> Remaining issue: REQ35 >> >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation for s= olution designers i.e. if you can meet this requirement, your solution will= have greater chances to be selected than a solution without, is it accepta= ble to keep the "SHOULD" in the draft? >>> >>> OK or NOK? >>> >> >> OK. >> >> I would also accept a MUST, with the understanding that there may be lim= itations on what a non-supporting intermediary can do and still be traversa= ble. >> >> [Nigel] A number of people prefer the "must" so can we compromise on >> this use if Ben can accept this, so we can ensure the Client gets the >> appropriate information so it can act if necessary >> >> [LM] Not so sure about the number of voices for the "MUST"... >> >> Have we accepted the requirement(s) about working both with or without a= gents? >> [Nigel] Ben, I am not sure which Requirement you are referring to but th= e solution has to work with and without Diameter Agents (stateful or not st= ateful) involved so any requirement should not disallow these scenarios. >> >> [LM] this requirement was agreed: "The solution MUST work in the presenc= e or absence of Diameter agents between Diameter clients and servers" >> >> >> -----Message d'origine----- >> De : BERRY, Nigel (Nigel) [mailto:nigel.berry@alcatel-lucent.com] >> Envoy=E9 : mardi 12 mars 2013 16:33 >> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES >> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry >> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >> >> Hi Lionel, >> JJ's laptop is on the blink so I will attempt to answer, See in-line, >> Kind Regards, Nigel >> >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 12 March 2013 14:44 >> To: lionel.morand@orange.com >> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel); DRAGE, >> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) >> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >> >> Hi comments inline: >> >> On Mar 12, 2013, at 9:59 AM, wrote: >> >>> Hi, >>> >>> Honestly, I don't understand why we have to go down each time to the so= lution space to understand a requirement! >>> Can we try to make it simple when possible? >> >> My solution examples were intended to illustrate that there can be more = than one solution approach, and we should be careful not to over-constrain = the solution in the requirements. I did not mean for any of them to be assu= med as the "real" solution. >> [Nigel] I agree with Ben we have to dip our toe in the water of potentia= l solutions that deal with all scenarios in order to understand the correct= wording of requirements. >> >>> >>> 1/ REQ 2 complement: >>> >>> Based on the different comments, my proposal for the new requirement is= the following: >>> "Diameter clients must be able to use the received load and overload in= formation to support graceful behavior during an overload condition" >>> >>> And the question is: OK or NOK i.e. can you live with? >> >> Grudgingly OK, with the provision that this allows but does not require = the information to be sent end-to-end from server to client. >> >> I would be _considerably_ happier with something of the form of "The sol= ution must support graceful client behavior during an overload condition." >> [Nigel] Hi Lionel, I am OK with "Diameter clients must be able to use th= e received load and overload information to support graceful behavior durin= g an overload condition" providing a necessary consequence of graceful beha= viour may involve drastic load shedding at the client or the active proxy. >> >> >>> >>> 2/ REQ 35: >>> With the clarification that the "SHOULD" is strong recommendation for s= olution designers i.e. if you can meet this requirement, your solution will= have greater chances to be selected than a solution without, is it accepta= ble to keep the "SHOULD" in the draft? >>> >>> OK or NOK? >>> >> >> OK. >> >> I would also accept a MUST, with the understanding that there may be lim= itations on what a non-supporting intermediary can do and still be traversa= ble. >> [Nigel] A number of people prefer the "must" so can we compromise on >> this use if Ben can accept this, so we can ensure the Client gets the >> appropriate information so it can act if necessary >> >> Have we accepted the requirement(s) about working both with or without a= gents? >> [Nigel] Ben, I am not sure which Requirement you are referring to but th= e solution has to work with and without Diameter Agents (stateful or not st= ateful) involved so any requirement should not disallow these scenarios. >> >> >> [...] >> >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> 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'altera= tion, France Telecom - 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 d= elete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for mess= ages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> 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 > _______________________________________________ > 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 _______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E16305FPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

WFM

 

De : dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : jeudi 14 mars 2013 14:25
=C0 : Ben Campbell
Cc : dime-bounces@ietf.org; BERRY, Nigel (Nigel); DRAGE, Keith = (Keith); Bessis, Thierry (Thierry); dime@ietf.org
Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2=

 

WRT "gracefully" in Req 2. I th= ought we agreed to incorporate a reference to REQ 3, e.g., "gracefully= (in accordance with Req 3)"

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        Ben Campbell <ben@nostrum.com&= gt;
To:        "TROTTIN,     &nbs= p;  JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel= -lucent.com>
Cc:        "BERRY, Nigel \(Nigel\)"= ; <nigel.berry@alcatel-lucent.com>, "DRAGE,      =  Keith \(Keith\)" <keith.drage@alcatel-lucent.com>, "Bessis,        Thierry \(Thierry\)" <thi= erry.bessis@alcatel-lucent.com>, "dime@ietf.org" <dime@ietf= .org>
Date:        03/13/2013 08:37 AM
Subject:        Re: [Dime] draft-ietf-dime-overlo= ad-reqs-03: REQ 2
Sent by:        dime-bounces@ietf.org




Hi, Comments inline:

On Mar 13, 2013, at 5:34 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)= " <jean-jacques.trottin@alcatel-lucent.com> wrote:

> HI Maria Cruz
>
> Thanks for your feedback:
>
> About REQ 35, my understanding was that the existing REQ35 wording= was kept (with still the pending point between MUST and SHOULD as mentione= d in a Nigel's mail), and that a new sentence "The solution MUST work = in the presence or absence of Diameter agents between Diameter clients and servers" would be added.
> You propose for REQ35 "The solution MUST work in the presence= or absence of Diameter agents between Diameter clients and servers, regard= less whether or not Diameter agents support the overload control mechanism&= quot;.
>
> In fact it groups the two sentences with a MUST, so it is OK for m= e.
>

I had expected the requirement to work with or without agents would be = a new, separate requirement. I think that, while it's related to the need t= o cross non-supporting agents, it's also distinct in the fact that it requi= res the solution to work in a pure client-server deployment as well. I prefer the separation, but could live = with it if people want to combine them.

> You mentioned the REQ16 which I also agree.

Req16 does not necessarily imply the ability to cross non-supporting ag= ents. It could, for example, be interpreted to mean that non-supporting cli= ents are allowed in parallel with supporting clients. I would not depend on= 16 by itself to get the point across.

>
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> For REQ2
>
> About your two proposals
> "The mechanism MUST allow Diameter clients to support gracefu= l behavior during an overload situation"
> Or :
> "The mechanism MUST allow Diameter clients to act during an o= verload situation in order to improve it while impacts are minimized"<= /tt>
> They are OK for me, as they are in the line of my proposal: the cl= ient being aware of the overload situation, can act accordingly. Your propo= sals are more accurate, as indicating client actions.
>
> But the last proposal on the table is the one proposed by Lionel a= imed to have a compromise :
> "Diameter clients must be able to use the received load and o= verload information to support graceful behavior during an overload conditi= on"
>
> Nigel and I were accepting the Lionel's proposal to find a comprom= ise but nevertheless I prefer your writing and support your proposals that = could also be a compromise.
>
> As a conclusion, I think we are in line, and I support your propos= als with the objective to find a compromise.

I am fine with either wording. In the interests of not beating Martin's= dog (see Martin's email), it's probably easier to stick with Lionel's prop= osed wording, but I will not object if the consensus is to change to Maria'= s.


>
> Best regards
>
> JJacques
>
> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@iet= f.org] De la part de M= aria Cruz Bartolome
> Envoy=E9 : mercredi 13 mars 2013 09:36
> =C0 : Eric McMurry; lionel.morand@orange.com; dime@ietf.org > Cc : DRAGE, Keith (Keith); BERRY, Nigel (Nigel); Bessis, Thierry (= Thierry)
> Objet : Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>
> Hello all,
>
> Trying to summarize a bit, for my own clarification here and agree= ment.
> I think latest proposals are:
>
> REQ-35:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> REQ-35 (now in draft v.5):
>   REQ 35:  The mechanism SHOULD provide a method for exc= hanging
>            overload and load informa= tion between elements that are
>            connected by intermediari= es that do not support the
>                   &nb= sp;               mechanism
>
> REQ-35 (proposal):
> "The solution MUST work in the presence or absence of Diamete= r agents between Diameter clients and servers"
>
> I think there is something to add to reflect everything cover by f= ormer requirement:
>
> REQ-35 (new proposal):
> "The solution MUST work in the presence or absence of Diamete= r agents between Diameter clients and servers, regardless whether or not Di= ameter agents support the overload control mechanism"
>
>
> Although this may be considered covered by REQ-16:
>   REQ 16:  The overload control mechanism is likely to b= e deployed
>            incrementally.  The = mechanism MUST support a mixed
>            environment where some, b= ut not all, nodes implement it.
>
> But I presume it does not harm to be explicit here, like in former= requirement.
>
>
> About the comment by Eric on security (just mail below), we need t= o check then whether REQ-30 need to be modified, or a new requirement shall= apply, right?
>
>   REQ 30:  The mechanism MUST NOT depend on being deploy= ed in
>            environments where all Di= ameter nodes are completely
>            trusted.  It SHOULD = operate as effectively as possible in
>            environments where other = nodes are malicious; this includes
>            preventing malicious node= s from obtaining more than a fair
>            share of service.  N= ote that this does not imply any
>            responsibility on the mec= hanism to detect, or take
>            countermeasures against, = malicious nodes.
>
>
> REQ-2 complement:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> First, I could accept the proposal we got now on the table, I do n= ot want to keep discussion forever, but... I'd like to propose some enhance= ments that I think cover all people concerns stated so far, hopefully witho= ut rasing disagreements.
>
> Proposal now is:
> "Diameter clients must be able to use the received load and o= verload information to support graceful behavior during an overload conditi= on"
>
> I got some comments on this, taking into account the first proposa= l was:
> "The mechanism MUST allow Diameter clients to be aware of an = overload situation "
>
> I think it is better to request that is "the mechanism" = the one that should provide the means for the client to be able to do somet= hing, since we are specifying what the mechanism shall do in other requirem= ents, like:
>
>   REQ 1:   The overload control mechanism MUST provide a= communication
>            method for Diameter nodes= to exchange load and overload
>            information.
>
>
> Then my -intermediate- proposal would be the following:
> "The mechanism MUST allow Diameter clients to support gracefu= l behavior during an overload situation"
>
> Where I think "graceful behavior" is raising some concer= ns, in facts this is not specific enough in my opinion. Good requirement wr= iting would avoid multiple interpretations. Then, what about this:
>
> New proposal for REQ-2 complement:
> "The mechanism MUST allow Diameter clients to act during an o= verload situation in order to improve it while impacts are minimized"<= /tt>
>
>
>
> Best regards
> /MCruz
>
>
> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ie= tf.org] On Behalf Of E= ric McMurry
> Sent: martes, 12 de marzo de 2013 22:42
> To: lionel.morand@orange.com
> Cc: DRAGE, Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry)= ; BERRY, Nigel (Nigel)
> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 >
> I have stated before that I am fine with a MUST provided that the = requirement for end to end security is also added.  Traversing non-sup= porint elements without this would be folly
>
> I believe the best compromise here is to leave it as is, so that m= ore thought can be put into this without constraining the solution to somet= hing that may be nearly impossible to deploy.  It may also be possible= to define the security requirement for specific scenarios where the risk is higher.  This would include a sp= ecific requirement (at MUST level) stating that e2e security is required fo= r traversing non-supporting elements.  I believe that this approach is= generally consistent with what some have been discussing about using a MUST level on 35 along with constraints.
>
> Eric
>
>
> On Mar 12, 2013, at 16:43 , lionel.morand@orange.com wrote: >
>> Almost the end :)
>>
>> Remaining issue: REQ35
>>
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is stro= ng recommendation for solution designers i.e. if you can meet this requirem= ent, your solution will have greater chances to be selected than a solution= without, is it acceptable to keep the "SHOULD" in the draft?
>>>
>>> OK or NOK?
>>>
>>
>> OK.
>>
>> I would also accept a MUST, with the understanding that there = may be limitations on what a non-supporting intermediary can do and still b= e traversable.
>>
>> [Nigel] A number of people prefer the "must" so can = we compromise on
>> this use if Ben can accept this, so we can ensure the Client g= ets the
>> appropriate information so it can act if necessary
>>
>> [LM] Not so sure about the number of voices for the "MUST= "...
>>
>> Have we accepted the requirement(s) about working both with or= without agents?
>> [Nigel] Ben, I am not sure which Requirement you are referring= to but the solution has to work with and without Diameter Agents (stateful= or not stateful) involved so any requirement should not disallow these sce= narios.
>>
>> [LM] this requirement was agreed: "The solution MUST work= in the presence or absence of Diameter agents between Diameter clients and= servers"
>>
>>
>> -----Message d'origine-----
>> De : BERRY, Nigel (Nigel) [mailto:nige= l.berry@alcatel-lucent.com]
>> Envoy=E9 : mardi 12 mars 2013 16:33
>> =C0 : Ben Campbell; MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-= JACQUES
>> (JEAN-JACQUES); DRAGE, Keith (Keith); dime@ietf.org; Bessis, T= hierry
>> (Thierry) Objet : RE: [Dime] draft-ietf-dime-overload-reqs-03:= REQ 2
>>
>> Hi Lionel,
>> JJ's laptop is on the blink so I will attempt to answer, See i= n-line,
>> Kind Regards, Nigel
>>
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@nostrum.com]
>> Sent: 12 March 2013 14:44
>> To: lionel.morand@orange.com
>> Cc: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); BERRY, Nigel (Nigel)= ; DRAGE,
>> Keith (Keith); dime@ietf.org; Bessis, Thierry (Thierry) >> Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2
>>
>> Hi comments inline:
>>
>> On Mar 12, 2013, at 9:59 AM, <lionel.morand@orange.com> = wrote:
>>
>>> Hi,
>>>
>>> Honestly, I don't understand why we have to go down each t= ime to the solution space to understand a requirement!
>>> Can we try to make it simple when possible?
>>
>> My solution examples were intended to illustrate that there ca= n be more than one solution approach, and we should be careful not to over-= constrain the solution in the requirements. I did not mean for any of them = to be assumed as the "real" solution.
>> [Nigel] I agree with Ben we have to dip our toe in the water o= f potential solutions that deal with all scenarios in order to understand t= he correct wording of requirements.
>>
>>>
>>> 1/ REQ 2 complement:
>>>
>>> Based on the different comments, my proposal for the new r= equirement is the following:
>>> "Diameter clients must be able to use the received lo= ad and overload information to support graceful behavior during an overload= condition"
>>>
>>> And the question is: OK or NOK i.e. can you live with?
>>
>> Grudgingly OK, with the provision that this allows but does no= t require the information to be sent end-to-end from server to client.=
>>
>> I would be _considerably_ happier with something of the form o= f "The solution must support graceful client behavior during an overlo= ad condition."
>> [Nigel] Hi Lionel, I am OK with "Diameter clients must be= able to use the received load and overload information to support graceful= behavior during an overload condition" providing a necessary conseque= nce of graceful behaviour may involve drastic load shedding at the client or the active proxy.
>>
>>
>>>
>>> 2/ REQ 35:
>>> With the clarification that the "SHOULD" is stro= ng recommendation for solution designers i.e. if you can meet this requirem= ent, your solution will have greater chances to be selected than a solution= without, is it acceptable to keep the "SHOULD" in the draft?
>>>
>>> OK or NOK?
>>>
>>
>> OK.
>>
>> I would also accept a MUST, with the understanding that there = may be limitations on what a non-supporting intermediary can do and still b= e traversable.
>> [Nigel] A number of people prefer the "must" so can = we compromise on
>> this use if Ben can accept this, so we can ensure the Client g= ets the
>> appropriate information so it can act if necessary
>>
>> Have we accepted the requirement(s) about working both with or= without agents?
>> [Nigel] Ben, I am not sure which Requirement you are referring= to but the solution has to work with and without Diameter Agents (stateful= or not stateful) involved so any requirement should not disallow these sce= narios.
>>
>>
>> [...]
>>
>>
>> ______________________________________________________________= ________
>> ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informat= ions
>> confidentielles ou privilegiees et ne doivent donc pas etre di= ffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce me= ssage
>> par erreur, veuillez le signaler a l'expediteur et le detruire= ainsi que les pieces jointes. Les messages electroniques etant susceptible= s d'alteration, France Telecom - Orange decline toute responsabilite si ce = message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or <= /tt>
>> privileged information that may be protected by law; they shou= ld not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the se= nder and delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liabl= e for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/list= info/dime
>
> _______________________________________________
> 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
> _______________________________________________
> 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 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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E16305FPEXCVZYM13corpora_-- From susan.shishufeng@huawei.com Thu Mar 14 21:06:53 2013 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 B27CC11E80EC for ; Thu, 14 Mar 2013 21:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm+uZwo1Z3Pg for ; Thu, 14 Mar 2013 21:06:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4DE11E80E8 for ; Thu, 14 Mar 2013 21:06:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQQ60202; Fri, 15 Mar 2013 04:06:50 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 15 Mar 2013 04:06:10 +0000 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 15 Mar 2013 04:06:49 +0000 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.36]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Fri, 15 Mar 2013 12:06:41 +0800 From: "Shishufeng (Susan)" To: Eric McMurry , Maria Cruz Bartolome Thread-Topic: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 Thread-Index: AQHOILeEZm7wI5F8KE+w+vxwHqOdK5imGr8A Date: Fri, 15 Mar 2013 04:06:40 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F2547F86640@szxeml528-mbx.china.huawei.com> References: <669B2D5ED96A8E4E9FD34C91DFD815B00100DC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1E1E1F38-71DD-4F04-B378-67B6D47BB8A1@computer.org> <47663D47-EE18-45B2-B655-AD3A2893D815@nostrum.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016CA9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <669B2D5ED96A8E4E9FD34C91DFD815B0016F67@FR712WXCHMBA11.zeu.alcatel-lucent.com> <29163_1363016483_513DFB22_29163_2255_1_6B7134B31289DC4FAF731D844122B36E15D1B9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <545_1363021602_513E0F22_545_1058_1_6B7134B31289DC4FAF731D844122B36E15D358@PEXCVZYM13.corporate.adroot.infra.ftgroup> <"8179_1363039955_513E56D3_8179_17231_1 _ 6B7134 B3 1289DC4FAF731D844122B36E15D747"@PEXCVZYM13.corporate.adroot.infra.ftgroup> <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "Bessis, Thierry \(Thierry\)" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 04:06:53 -0000 SGVsbG8gYWxsLA0KDQpUbyBSRVEgMzUsIEkgYWdyZWUgdGhlIG5ldyBwcm9wb3NhbCBjb3VsZCBi ZSBhIHNlcGFyYXRlIHJlcXVpcmVtZW50Lg0KDQpUbyBSRVEgMiwgc2luY2UgdGhlcmUgd2FzIHRv byBtdWNoIGRpc2N1c3Npb24gb24gaXQsIEknbSBub3QgZ29pbmcgdG8gdHJpZ2dlciBvZmYgYW5v dGhlciByb3VuZCBhZ2FpbiBpZiBhbGwgcGVvcGxlIGNhbiBsaXZlIHdpdGggdGhlIGNvbXByb21p c2UgcHJvcG9zYWwgZnJvbSBlaXRoZXIgTGlvbmVsIG9yIE1hcmlhIENydXosIGV2ZW4gYm90aCBv ZiB3aGljaCBzdGlsbCBzZWVtIHZhZ3VlIHRvIG1lLiBCdXQgd2UgbWF5IGhhdmUgdG8ga2VlcCBp biBtaW5kIG9uZSBwb2ludDogVG8gdGhlIGNsaWVudCwgdGhlIGRpZmZlcmVuY2Ugb2YgdGhlIG92 ZXJsb2FkIGluZm9ybWF0aW9uIG9mIHRoZSBzZXJ2ZXJzIGZyb20gdGhlIG9uZSBvZiB0aGUgYWdl bnQgaXMgdGhhdCBpZiB0aGUgY2xpZW50IGtub3dzIHRoZSBzZXJ2ZXJzIGFyZSBvdmVybG9hZGVk LCBpdCBtaWdodCBzdGFydCB0byBzaGVkIG1lc3NhZ2VzIGFuZCBtaXRpZ2F0ZSB0aGUgb3Zlcmxv YWQgb2YgdGhlIHNlcnZlcnMgZnJvbSB0aGUgYmVnaW5uaW5nLCBpLmUuIHRoZSBvcmlnaW5hdG9y IG9mIHRoZSByZXF1ZXN0IG1lc3NhZ2VzOyBXaGlsZSBpZiB0aGUgY2xpZW50IG9ubHkga25vd3Mg dGhhdCB0aGUgYWdlbnQocykgaXMgb3ZlcmxvYWRlZCwgaXQgbWF5IGRlY2lkZSB0byBjb250aW51 ZSB0byByb3V0ZSB0aGUgbWVzc2FnZXMgdG8gdGhlIHNlcnZlcnMgdmlhIGFub3RoZXIgYWdlbnQg b3IgYWdlbnQgZ3JvdXAuIEluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGNsaWVudCBjYW5ub3QgY29u dHJpYnV0ZSBtdWNoIHRvIGhlbHAgdGhlIHNlcnZlcnMgcmVjb3ZlciBmcm9tIG92ZXJsb2FkZWQg c2l0dWF0aW9uLg0KDQpCZXN0IFJlZ2FyZHMsDQpTdXNhbg0KDQotLS0tLdPKvP7Urbz+LS0tLS0N CreivP7IyzogRXJpYyBNY011cnJ5IFttYWlsdG86ZW1jbXVycnlAY29tcHV0ZXIub3JnXSANCrei y83KsbzkOiAyMDEzxOoz1MIxNMjVIDY6NDUNCsrVvP7IyzogTWFyaWEgQ3J1eiBCYXJ0b2xvbWUN CrOty806IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBkaW1lQGlldGYub3JnOyBCRVJSWSwgTmlnZWwg KE5pZ2VsKTsgQmVzc2lzLCBUaGllcnJ5IChUaGllcnJ5KQ0K1vfM4jogUmU6IFtEaW1lXSBkcmFm dC1pZXRmLWRpbWUtb3ZlcmxvYWQtcmVxcy0wMzogUkVRIDINCg0KSGkgTWFyaWEsDQoNCkNvbW1l bnRzIGlubGluZS4NCg0KVGhhbmtzLA0KDQpFcmljDQoNCg0KT24gTWFyIDEzLCAyMDEzLCBhdCA5 OjM2ICwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgPG1hcmlhLmNydXouYmFydG9sb21lQEVSSUNTU09O LkNPTT4gd3JvdGU6DQoNCj4gSGVsbG8gYWxsLA0KPiANCj4gVHJ5aW5nIHRvIHN1bW1hcml6ZSBh IGJpdCwgZm9yIG15IG93biBjbGFyaWZpY2F0aW9uIGhlcmUgYW5kIGFncmVlbWVudC4NCj4gSSB0 aGluayBsYXRlc3QgcHJvcG9zYWxzIGFyZToNCj4gDQo+IFJFUS0zNToNCj4gPT09PT09PT09PT09 PT09PT09PT09PT09PT0NCj4gDQo+IFJFUS0zNSAobm93IGluIGRyYWZ0IHYuNSk6DQo+ICAgUkVR IDM1OiAgVGhlIG1lY2hhbmlzbSBTSE9VTEQgcHJvdmlkZSBhIG1ldGhvZCBmb3IgZXhjaGFuZ2lu Zw0KPiAgICAgICAgICAgIG92ZXJsb2FkIGFuZCBsb2FkIGluZm9ybWF0aW9uIGJldHdlZW4gZWxl bWVudHMgdGhhdCBhcmUNCj4gICAgICAgICAgICBjb25uZWN0ZWQgYnkgaW50ZXJtZWRpYXJpZXMg dGhhdCBkbyBub3Qgc3VwcG9ydCB0aGUNCj4gCQltZWNoYW5pc20NCj4gDQo+IFJFUS0zNSAocHJv cG9zYWwpOg0KPiAiVGhlIHNvbHV0aW9uIE1VU1Qgd29yayBpbiB0aGUgcHJlc2VuY2Ugb3IgYWJz ZW5jZSBvZiBEaWFtZXRlciBhZ2VudHMgYmV0d2VlbiBEaWFtZXRlciBjbGllbnRzIGFuZCBzZXJ2 ZXJzIg0KPiANCj4gSSB0aGluayB0aGVyZSBpcyBzb21ldGhpbmcgdG8gYWRkIHRvIHJlZmxlY3Qg ZXZlcnl0aGluZyBjb3ZlciBieSBmb3JtZXIgcmVxdWlyZW1lbnQ6DQo+IA0KPiBSRVEtMzUgKG5l dyBwcm9wb3NhbCk6DQo+ICJUaGUgc29sdXRpb24gTVVTVCB3b3JrIGluIHRoZSBwcmVzZW5jZSBv ciBhYnNlbmNlIG9mIERpYW1ldGVyIGFnZW50cyBiZXR3ZWVuIERpYW1ldGVyIGNsaWVudHMgYW5k IHNlcnZlcnMsIHJlZ2FyZGxlc3Mgd2hldGhlciBvciBub3QgRGlhbWV0ZXIgYWdlbnRzIHN1cHBv cnQgdGhlIG92ZXJsb2FkIGNvbnRyb2wgbWVjaGFuaXNtIg0KPiANCj4gDQoNCkkgdGhpbmsgQmVu IGFuZCBKSmFjcXVlcyBoYXZlIGNvdmVyZWQgdGhpcy4gIFRoaXMgaXMgdGhlIGZpcnN0IGluc3Rh bmNlIEkgaGF2ZSBzZWVuIG9mIGNvbWJpbmluZyB0aGUgbmV3IGFnZW50L25vLWFnZW50IGxhbmd1 YWdlIHdpdGggMzUgYW5kIHRoZXkgZG9uJ3QgcmVhbGx5IGdvIHRvZ2V0aGVyLiAgVGhleSBzaG91 bGQgcmVtYWluIHNlcGFyYXRlLg0KDQo+IEFsdGhvdWdoIHRoaXMgbWF5IGJlIGNvbnNpZGVyZWQg Y292ZXJlZCBieSBSRVEtMTY6DQo+ICAgUkVRIDE2OiAgVGhlIG92ZXJsb2FkIGNvbnRyb2wgbWVj aGFuaXNtIGlzIGxpa2VseSB0byBiZSBkZXBsb3llZA0KPiAgICAgICAgICAgIGluY3JlbWVudGFs bHkuICBUaGUgbWVjaGFuaXNtIE1VU1Qgc3VwcG9ydCBhIG1peGVkDQo+ICAgICAgICAgICAgZW52 aXJvbm1lbnQgd2hlcmUgc29tZSwgYnV0IG5vdCBhbGwsIG5vZGVzIGltcGxlbWVudCBpdC4NCj4g DQo+IEJ1dCBJIHByZXN1bWUgaXQgZG9lcyBub3QgaGFybSB0byBiZSBleHBsaWNpdCBoZXJlLCBs aWtlIGluIGZvcm1lciByZXF1aXJlbWVudC4NCg0KSSBhZ3JlZSB3aXRoIEJlbiB0aGF0IHRoaXMg ZG9lcyBub3QgaW1wbHkgd2hhdCB5b3UgYXJlIHJlYWRpbmcgaW50byBpdC4gIEFub3RoZXIgcmVx dWlyZW1lbnQgd291bGQgYmUgbmVlZGVkIHRvIG1ha2UgdGhhdCBjbGVhci4NCg0KPiANCg0KWy4u Ll0NCg0KPiANCj4gUkVRLTIgY29tcGxlbWVudDoNCj4gPT09PT09PT09PT09PT09PT09PT09PT09 PT0NCj4gDQo+IEZpcnN0LCBJIGNvdWxkIGFjY2VwdCB0aGUgcHJvcG9zYWwgd2UgZ290IG5vdyBv biB0aGUgdGFibGUsIEkgZG8gbm90IHdhbnQgdG8ga2VlcCBkaXNjdXNzaW9uIGZvcmV2ZXIsIGJ1 dC4uLiBJJ2QgbGlrZSB0byBwcm9wb3NlIHNvbWUgZW5oYW5jZW1lbnRzIHRoYXQgSSB0aGluayBj b3ZlciBhbGwgcGVvcGxlIGNvbmNlcm5zIHN0YXRlZCBzbyBmYXIsIGhvcGVmdWxseSB3aXRob3V0 IHJhc2luZyBkaXNhZ3JlZW1lbnRzLg0KPiANCj4gUHJvcG9zYWwgbm93IGlzOiANCj4gIkRpYW1l dGVyIGNsaWVudHMgbXVzdCBiZSBhYmxlIHRvIHVzZSB0aGUgcmVjZWl2ZWQgbG9hZCBhbmQgb3Zl cmxvYWQgaW5mb3JtYXRpb24gdG8gc3VwcG9ydCBncmFjZWZ1bCBiZWhhdmlvciBkdXJpbmcgYW4g b3ZlcmxvYWQgY29uZGl0aW9uIg0KPiANCj4gSSBnb3Qgc29tZSBjb21tZW50cyBvbiB0aGlzLCB0 YWtpbmcgaW50byBhY2NvdW50IHRoZSBmaXJzdCBwcm9wb3NhbCB3YXM6DQo+ICJUaGUgbWVjaGFu aXNtIE1VU1QgYWxsb3cgRGlhbWV0ZXIgY2xpZW50cyB0byBiZSBhd2FyZSBvZiBhbiBvdmVybG9h ZCBzaXR1YXRpb24gIg0KPiANCj4gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gcmVxdWVzdCB0aGF0 IGlzICJ0aGUgbWVjaGFuaXNtIiB0aGUgb25lIHRoYXQgc2hvdWxkIHByb3ZpZGUgdGhlIG1lYW5z IGZvciB0aGUgY2xpZW50IHRvIGJlIGFibGUgdG8gZG8gc29tZXRoaW5nLCBzaW5jZSB3ZSBhcmUg c3BlY2lmeWluZyB3aGF0IHRoZSBtZWNoYW5pc20gc2hhbGwgZG8gaW4gb3RoZXIgcmVxdWlyZW1l bnRzLCBsaWtlOg0KPiANCj4gICBSRVEgMTogICBUaGUgb3ZlcmxvYWQgY29udHJvbCBtZWNoYW5p c20gTVVTVCBwcm92aWRlIGEgY29tbXVuaWNhdGlvbg0KPiAgICAgICAgICAgIG1ldGhvZCBmb3Ig RGlhbWV0ZXIgbm9kZXMgdG8gZXhjaGFuZ2UgbG9hZCBhbmQgb3ZlcmxvYWQNCj4gICAgICAgICAg ICBpbmZvcm1hdGlvbi4NCj4gDQo+IA0KPiBUaGVuIG15IC1pbnRlcm1lZGlhdGUtIHByb3Bvc2Fs IHdvdWxkIGJlIHRoZSBmb2xsb3dpbmc6DQo+ICJUaGUgbWVjaGFuaXNtIE1VU1QgYWxsb3cgRGlh bWV0ZXIgY2xpZW50cyB0byBzdXBwb3J0IGdyYWNlZnVsIGJlaGF2aW9yIGR1cmluZyBhbiBvdmVy bG9hZCBzaXR1YXRpb24iDQo+IA0KPiBXaGVyZSBJIHRoaW5rICJncmFjZWZ1bCBiZWhhdmlvciIg aXMgcmFpc2luZyBzb21lIGNvbmNlcm5zLCBpbiBmYWN0cyB0aGlzIGlzIG5vdCBzcGVjaWZpYyBl bm91Z2ggaW4gbXkgb3Bpbmlvbi4gR29vZCByZXF1aXJlbWVudCB3cml0aW5nIHdvdWxkIGF2b2lk IG11bHRpcGxlIGludGVycHJldGF0aW9ucy4gVGhlbiwgd2hhdCBhYm91dCB0aGlzOg0KPiANCj4g TmV3IHByb3Bvc2FsIGZvciBSRVEtMiBjb21wbGVtZW50Og0KPiAiVGhlIG1lY2hhbmlzbSBNVVNU IGFsbG93IERpYW1ldGVyIGNsaWVudHMgdG8gYWN0IGR1cmluZyBhbiBvdmVybG9hZCBzaXR1YXRp b24gaW4gb3JkZXIgdG8gaW1wcm92ZSBpdCB3aGlsZSBpbXBhY3RzIGFyZSBtaW5pbWl6ZWQiDQo+ IA0KPiANCg0KDQpJIGFncmVlIHdpdGggTWFydGluIGFib3V0IHRoZSBkb2csIGJ1dCB0aGlzIGlz IGFsc28gc2F5aW5nIHNvbWV0aGluZyBkaWZmZXJlbnQgdGhhbiB0aGUgbGFzdCBwcm9wb3NhbC4g IFRoZXJlIGFyZSBzb21lIGFyZWFzIHdoZXJlIHRoZSByZXF1aXJlbWVudHMgYXJlIGp1c3RpZmlh Ymx5IGludGVudGlvbmFsbHkgYSBiaXQgdmFndWUsIHRvIGdvdmUgc29tZSByb29tZSB0byB0aGUg bWVjaGFuaXNtIGRlc2lnbmVycyB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB0byBzb2x2 ZSBwcm9ibGVtcy4gIFRoaXMgaXMgb25lIG9mIHRob3NlIGNhc2VzLiAgVGhlIHByb3Bvc2FsIGhl cmUgaXMgdG9vIHNwZWNpZmljIGFuZCBkb2VzIG5vdCByZWZsZWN0IHNvbWUgb2YgdGhlIGRpc2N1 c3Npb24gbGVhZGluZyB1cCB0byB0aGlzIHBvaW50LCBuYW1lbHkgdGhlIHBhcnRzIGFib3V0IG92 ZXJsb2FkIGJlaW5nIGhhbmRsZWQgY2xvc2VyIHRvIHRoZSBzZXJ2ZXIgYXMgYXBwcm9wcmlhdGUu DQoNCg0KDQpbLi4uXQ0KDQoNCg== From Thierry.Bessis@alcatel-lucent.com Fri Mar 15 04:13:54 2013 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 9BA9921F8480 for ; Fri, 15 Mar 2013 04:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.582 X-Spam-Level: X-Spam-Status: No, score=-7.582 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owO-4KK1d2us for ; Fri, 15 Mar 2013 04:13:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C1FEF21F8462 for ; Fri, 15 Mar 2013 04:13:51 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2FBDUxX027476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Mar 2013 06:13:30 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r2FBDT11016330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Mar 2013 06:13:30 -0500 Received: from [135.244.229.28] (tbessis.lra.lucent.com [135.244.229.28]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r2FBDMkP021569; Fri, 15 Mar 2013 06:13:22 -0500 (CDT) Message-ID: <51430250.4090602@alcatel-lucent.com> Date: Fri, 15 Mar 2013 12:13:20 +0100 From: Thierry Bessis User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Shishufeng (Susan)" References: <2AD10A91-1423-497F-AB22-E2791794F7A2@nostrum.com> <21692_1363096768_513F34C0_21692_2192_1_6B7134B31289DC4FAF731D844122B36E15EF94@PEXCVZYM13.corporate.adroot.infra.ftgroup> <363_1363103018_513F4D2A_363_5477_1_6B7134B31289DC4FAF731D844122B36E15F1BA@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92066314@ESESSMB101.ericsson.se> <26C84DFD55BC3040A45BF70926E55F2547F86640@szxeml528-mbx.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2547F86640@szxeml528-mbx.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------090407040006020405020404" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 X-Mailman-Approved-At: Fri, 15 Mar 2013 04:42:30 -0700 Cc: "DRAGE, Keith \(Keith\)" , "dime@ietf.org" , "BERRY, Nigel \(Nigel\)" Subject: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2013 11:13:54 -0000 This is a multi-part message in MIME format. --------------090407040006020405020404 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Susan, I believe you have a very good point, that just tend to show the issues that we will face during the next phase, and also explain why we spent so much time in discussions: What we really need is a mechanism to allow a Diameter server to inform its Diameter clients of its load situation, so that the client can take action (optimal distribution, shedding ...). But we have requirements that at many places suggest that this is a hop to hop mechanism. With a hop to hop protocol, the client only sees the situation from the DA's reporting so the DA will need to combine its own load situation with the one from each of the servers it talks to. Of course it's complicated and will only work if all the DAs are upgraded and behaving correctly, which would also probably violate some of the requirements. My take on that is that given the way requirements are written, two mechanisms will be needed: connection based hop to hop and session based end to end. Cordially, Thierry On 15-Mar-2013 05:06, Shishufeng (Susan) wrote: > Hello all, > > To REQ 35, I agree the new proposal could be a separate requirement. > > To REQ 2, since there was too much discussion on it, I'm not going to trigger off another round again if all people can live with the compromise proposal from either Lionel or Maria Cruz, even both of which still seem vague to me. But we may have to keep in mind one point: To the client, the difference of the overload information of the servers from the one of the agent is that if the client knows the servers are overloaded, it might start to shed messages and mitigate the overload of the servers from the beginning, i.e. the originator of the request messages; While if the client only knows that the agent(s) is overloaded, it may decide to continue to route the messages to the servers via another agent or agent group. In the latter case, the client cannot contribute much to help the servers recover from overloaded situation. > > Best Regards, > Susan > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: Eric McMurry [mailto:emcmurry@computer.org] > ·¢ËÍʱ¼ä: 2013Äê3ÔÂ14ÈÕ 6:45 > ÊÕ¼þÈË: Maria Cruz Bartolome > ³­ËÍ: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry) > Ö÷Ìâ: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2 > > Hi Maria, > > Comments inline. > > Thanks, > > Eric > > > On Mar 13, 2013, at 9:36 , Maria Cruz Bartolome wrote: > >> Hello all, >> >> Trying to summarize a bit, for my own clarification here and agreement. >> I think latest proposals are: >> >> REQ-35: >> ========================== >> >> REQ-35 (now in draft v.5): >> REQ 35: The mechanism SHOULD provide a method for exchanging >> overload and load information between elements that are >> connected by intermediaries that do not support the >> mechanism >> >> REQ-35 (proposal): >> "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers" >> >> I think there is something to add to reflect everything cover by former requirement: >> >> REQ-35 (new proposal): >> "The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardless whether or not Diameter agents support the overload control mechanism" >> >> > I think Ben and JJacques have covered this. This is the first instance I have seen of combining the new agent/no-agent language with 35 and they don't really go together. They should remain separate. > >> Although this may be considered covered by REQ-16: >> REQ 16: The overload control mechanism is likely to be deployed >> incrementally. The mechanism MUST support a mixed >> environment where some, but not all, nodes implement it. >> >> But I presume it does not harm to be explicit here, like in former requirement. > I agree with Ben that this does not imply what you are reading into it. Another requirement would be needed to make that clear. > > [...] > >> REQ-2 complement: >> ========================== >> >> First, I could accept the proposal we got now on the table, I do not want to keep discussion forever, but... I'd like to propose some enhancements that I think cover all people concerns stated so far, hopefully without rasing disagreements. >> >> Proposal now is: >> "Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition" >> >> I got some comments on this, taking into account the first proposal was: >> "The mechanism MUST allow Diameter clients to be aware of an overload situation " >> >> I think it is better to request that is "the mechanism" the one that should provide the means for the client to be able to do something, since we are specifying what the mechanism shall do in other requirements, like: >> >> REQ 1: The overload control mechanism MUST provide a communication >> method for Diameter nodes to exchange load and overload >> information. >> >> >> Then my -intermediate- proposal would be the following: >> "The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation" >> >> Where I think "graceful behavior" is raising some concerns, in facts this is not specific enough in my opinion. Good requirement writing would avoid multiple interpretations. Then, what about this: >> >> New proposal for REQ-2 complement: >> "The mechanism MUST allow Diameter clients to act during an overload situation in order to improve it while impacts are minimized" >> >> > > I agree with Martin about the dog, but this is also saying something different than the last proposal. There are some areas where the requirements are justifiably intentionally a bit vague, to gove some roome to the mechanism designers where there are multiple ways to solve problems. This is one of those cases. The proposal here is too specific and does not reflect some of the discussion leading up to this point, namely the parts about overload being handled closer to the server as appropriate. > > > > [...] > > -- Thierry's signature ** *-- Cordially, Thierry Bessis* ACS / IMS Solution Architect - ALTA Member - SARB Review Leader Organization: ALU > S3G > ACS > IMS Sol Arch N1 146.5Alcatel-Lucent France Lieu Dit Le Mail 44708 ORVAULT France Tel/Fax: +1 630 979 7989 or +33 2 5178 3623 Corporate IM: tbessis Engage: https://engage.alcatel-lucent.com/people/tbessis ALTA Hot Line: http://alta.all.alcatel-lucent.com/hotline SARB Site: http://all.alcatel-lucent.com/wps/portal/cf/research/network_tech_strat/sarb Every other Friday: An IMS product/component presentation. We'll cover them all ! Please register: https://engage.alcatel-lucent.com/groups/public-portal-for-the-ims-solution-architecture-board Conference information: 2801 2801 (US):+1 800 771 8734 - (F):+33 800 941 674 - Access Code: 9797989 others countries see: https://engage.alcatel-lucent.com/docs/DOC-46568 *Upcoming planned Trips and Vacations: None* --------------090407040006020405020404 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit Susan,

I believe you have a very good point, that just tend to show the issues that we will face during the next phase, and also explain why we spent so much time in discussions: What we really need is a mechanism to allow a Diameter server to inform its Diameter clients of its load situation, so that the client can take action (optimal distribution, shedding ...). But we have requirements that at many places suggest that this is a hop to hop mechanism. With a hop to hop protocol, the client only sees the situation from the DA's reporting so the DA will need to combine its own load situation with the one from each of the servers it talks to. Of course it's complicated and will only work if all the DAs are upgraded and behaving correctly, which would also probably violate some of the requirements. My take on that is that given the way requirements are written, two mechanisms will be needed: connection based hop to hop and session based end to end.

Cordially,

Thierry




On 15-Mar-2013 05:06, Shishufeng (Susan) wrote:
Hello all,

To REQ 35, I agree the new proposal could be a separate requirement.

To REQ 2, since there was too much discussion on it, I'm not going to trigger off another round again if all people can live with the compromise proposal from either Lionel or Maria Cruz, even both of which still seem vague to me. But we may have to keep in mind one point: To the client, the difference of the overload information of the servers from the one of the agent is that if the client knows the servers are overloaded, it might start to shed messages and mitigate the overload of the servers from the beginning, i.e. the originator of the request messages; While if the client only knows that the agent(s) is overloaded, it may decide to continue to route the messages to the servers via another agent or agent group. In the latter case, the client cannot contribute much to help the servers recover from overloaded situation.

Best Regards,
Susan

-----ÓʼþÔ­¼þ-----
·¢¼þÈË: Eric McMurry [mailto:emcmurry@computer.org] 
·¢ËÍʱ¼ä: 2013Äê3ÔÂ14ÈÕ 6:45
ÊÕ¼þÈË: Maria Cruz Bartolome
³­ËÍ: DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thierry (Thierry)
Ö÷Ìâ: Re: [Dime] draft-ietf-dime-overload-reqs-03: REQ 2

Hi Maria,

Comments inline.

Thanks,

Eric


On Mar 13, 2013, at 9:36 , Maria Cruz Bartolome <maria.cruz.bartolome@ERICSSON.COM> wrote:


Hello all,

Trying to summarize a bit, for my own clarification here and agreement.
I think latest proposals are:

REQ-35:
==========================

REQ-35 (now in draft v.5):
  REQ 35:  The mechanism SHOULD provide a method for exchanging
           overload and load information between elements that are
           connected by intermediaries that do not support the
		mechanism

REQ-35 (proposal):
"The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers"

I think there is something to add to reflect everything cover by former requirement:

REQ-35 (new proposal):
"The solution MUST work in the presence or absence of Diameter agents between Diameter clients and servers, regardless whether or not Diameter agents support the overload control mechanism"



I think Ben and JJacques have covered this.  This is the first instance I have seen of combining the new agent/no-agent language with 35 and they don't really go together.  They should remain separate.


Although this may be considered covered by REQ-16:
  REQ 16:  The overload control mechanism is likely to be deployed
           incrementally.  The mechanism MUST support a mixed
           environment where some, but not all, nodes implement it.

But I presume it does not harm to be explicit here, like in former requirement.

I agree with Ben that this does not imply what you are reading into it.  Another requirement would be needed to make that clear.



      

      
[...]



      

        
REQ-2 complement:
==========================

First, I could accept the proposal we got now on the table, I do not want to keep discussion forever, but... I'd like to propose some enhancements that I think cover all people concerns stated so far, hopefully without rasing disagreements.

Proposal now is: 
"Diameter clients must be able to use the received load and overload information to support graceful behavior during an overload condition"

I got some comments on this, taking into account the first proposal was:
"The mechanism MUST allow Diameter clients to be aware of an overload situation "

I think it is better to request that is "the mechanism" the one that should provide the means for the client to be able to do something, since we are specifying what the mechanism shall do in other requirements, like:

  REQ 1:   The overload control mechanism MUST provide a communication
           method for Diameter nodes to exchange load and overload
           information.


Then my -intermediate- proposal would be the following:
"The mechanism MUST allow Diameter clients to support graceful behavior during an overload situation"

Where I think "graceful behavior" is raising some concerns, in facts this is not specific enough in my opinion. Good requirement writing would avoid multiple interpretations. Then, what about this:

New proposal for REQ-2 complement:
"The mechanism MUST allow Diameter clients to act during an overload situation in order to improve it while impacts are minimized"




      

      

I agree with Martin about the dog, but this is also saying something different than the last proposal.  There are some areas where the requirements are justifiably intentionally a bit vague, to gove some roome to the mechanism designers where there are multiple ways to solve problems.  This is one of those cases.  The proposal here is too specific and does not reflect some of the discussion leading up to this point, namely the parts about overload being handled closer to the server as appropriate.



[...]




    

    

    
-- 

      
      
      
      
      
      Thierry's signature
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      

        
 

        
-- 

              Cordially, 

              Thierry Bessis 

        
  ACS / IMS Solution
            Architect - ALTA
            Member - SARB Review Leader

            Organization: ALU > S3G
            > ACS >
            IMS Sol Arch

          

           N1 146.5  
            Alcatel-Lucent France Lieu Dit Le Mail

             44708 ORVAULT France

           Tel/Fax: +1 630 979 7989 or
            +33 2 5178
            3623

           Corporate IM: tbessis

          

          Engage:
          https://engage.alcatel-lucent.com/people/tbessis

            ALTA Hot Line: http://alta.all.alcatel-lucent.com/hotline

            SARB Site:
http://all.alcatel-lucent.com/wps/portal/cf/research/network_tech_strat/sarb

            Every other Friday: An IMS product/component presentation.
            We'll cover them all ! Please
            register: 

https://engage.alcatel-lucent.com/groups/public-portal-for-the-ims-solution-architecture-board
          

          Conference information:

            2801 2801 (US):+1 800 771 8734
            - (F):+33 800 941 674
            - Access Code: 9797989

            others countries see:
            https://engage.alcatel-lucent.com/docs/DOC-46568

        
Upcoming
              planned Trips and Vacations:
              None

      

    

  


--------------090407040006020405020404--

From trac+dime@trac.tools.ietf.org  Sat Mar 16 15:26:21 2013
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 7026321F8628 for ; Sat, 16 Mar 2013 15:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+Uj57JXFzF0 for ; Sat, 16 Mar 2013 15:26:20 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92F21F85DC for ; Sat, 16 Mar 2013 15:26:20 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43944 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UGzYO-0002ll-Hr; Sat, 16 Mar 2013 23:26:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "dime issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: jouni.nospam@gmail.com
X-Trac-Project: dime
Date: Sat, 16 Mar 2013 22:26:16 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/6#comment:1
Message-ID: <089.a4671f318981e33ad843604fe71c6743@trac.tools.ietf.org>
References: <074.61084d831cfcba1758a9114e3c97be66@trac.tools.ietf.org>
X-Trac-Ticket-ID: 6
In-Reply-To: <074.61084d831cfcba1758a9114e3c97be66@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, avi@bridgewatersystems.com, dime@ietf.org
X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: dime@ietf.org, avi@bridgewatersystems.com
Subject: Re: [Dime] [dime] #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: dime@ietf.org
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Mar 2013 22:26:21 -0000

#6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent

Changes (by jouni.nospam@gmail.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The solution approach regarding this ticket has changed since -03 and the
 concern above is not anymore valid. The solution for redirection is
 described on Section 3.2 and does not anymore affect/change the semantics
 of the RFC6733 Redirect Agent. Rather, the present solution goes into the
 solution pointed in the ticket.

-- 
----------------------------------------------+---------------------
 Reporter:  lionel.morand@orange-ftgroup.com  |       Owner:
     Type:  defect                            |      Status:  closed
 Priority:  major                             |   Milestone:
Component:  realm-based-redirect              |     Version:
 Severity:  In WG Last Call                   |  Resolution:  fixed
 Keywords:                                    |
----------------------------------------------+---------------------

Ticket URL: 
dime 


From jouni.nospam@gmail.com  Sat Mar 16 19:50:30 2013
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 1700721F856C for ; Sat, 16 Mar 2013 19:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtAVRnSNx47W for ; Sat, 16 Mar 2013 19:50:29 -0700 (PDT)
Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id D7FB521F8534 for ; Sat, 16 Mar 2013 19:50:28 -0700 (PDT)
Received: by mail-ve0-f169.google.com with SMTP id 15so3552377vea.14 for ; Sat, 16 Mar 2013 19:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=c/m+1lwjUtFyQ0tt9CcAOzqXOlZ9GDr8Xz8iZ4ieSh0=; b=WEVxSQCEc9HDtkxqbAfXm0wm2bZrezoUJTRFQIGrKsBDZbMo28AdFYoM6H2UGGUd3M +9m0U7A44qeg+0AWgid4RS76lQE9hGRSL4vjm6kF6uhhA8NR7RERevjeIT+L6SzVDZCJ QVEydSRzCT4/GxwKofNRqQUDqbocf87Co6UZWYCPXhVwlhTpSfe5z/IpCRzalIJolXTJ bpL/2K6qK6c4/XnCDBmLerDnpqZ73Cls83Dv/HCPEc6H2Z6vNIEroer7Nb++Dbaf4BC3 +BilSrH7WBKhejwgL96+EyMM3PIPILYB8qNZ/ZsU4iOMSWBv5QcaHzR5pffxdaW70mgj 8JHQ==
X-Received: by 10.52.18.235 with SMTP id z11mr11983481vdd.39.1363488627379; Sat, 16 Mar 2013 19:50:27 -0700 (PDT)
Received: from [10.0.0.91] (c-98-218-0-183.hsd1.dc.comcast.net. [98.218.0.183]) by mx.google.com with ESMTPS id y8sm14445357vei.5.2013.03.16.19.50.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 19:50:26 -0700 (PDT)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: 
Date: Sun, 17 Mar 2013 04:50:18 +0200
To: "dime@ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [Dime] Draft minutes available
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Mar 2013 02:50:30 -0000

Folks,

Please verify the draft minutes from the meeting:
http://www.ietf.org/proceedings/86/minutes/minutes-86-dime

There are few missing parts there and it would be nice that
those who said something during the meeting on mic would
check if everything has been captured.

- Jouni & Lionel

ps: a huge thank to (again) Jean for taking minutes!!

From ben@nostrum.com  Fri Mar 22 14:19:15 2013
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 BD20E21F9430 for ; Fri, 22 Mar 2013 14:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaLkE1M5dUQM for ; Fri, 22 Mar 2013 14:19:15 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B221F942B for ; Fri, 22 Mar 2013 14:19:14 -0700 (PDT)
Received: from [10.119.79.98] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2MLJ3oL063784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 16:19:04 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ben Campbell 
In-Reply-To: 
Date: Fri, 22 Mar 2013 16:18:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <892D074E-B544-4ECF-9380-DE1278C1F220@nostrum.com>
References: 
To: Jouni Korhonen , "lionel.morand@orange.com OLNC/OLN" , "dime@ietf.org" 
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass (shaman.nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism)
Subject: Re: [Dime] Draft minutes available
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Mar 2013 21:19:15 -0000

On Mar 16, 2013, at 9:50 PM, Jouni Korhonen  =
wrote:

> Folks,
>=20
> Please verify the draft minutes from the meeting:
> http://www.ietf.org/proceedings/86/minutes/minutes-86-dime
>=20
> There are few missing parts there and it would be nice that
> those who said something during the meeting on mic would
> check if everything has been captured.
>=20
> - Jouni & Lionel
>=20
> ps: a huge thank to (again) Jean for taking minutes!!

Hi,

I have a few minor comments and corrections for the draft minutes:

-- in the overload-reqs discussion:

> Keith - This is a requirements doc, thus no one will implement this. =
The MUST constrains the working group on the solution doc. There is no =
problem with text here. MUST vs SHOULD - we want to say MUST here. If =
there's problem with the MUST, you should constrain it the following =
text.=20
>=20
> Lionel - I don't understand. There's no way to do this without a new =
application ID. You would need to go through dedicated proxies to do =
this.=20

I thought Lionel was commenting that the "new application" approach for =
moving overload control info around wouldn't be able to solve the Req 35 =
(crossing non-supporting intermediaries) use case. Did I misunderstand =
the comment?

[...]

> Janet - The SIP overload specification has, "If it uses such-n-such, =
it MUST =85". In the SIP solution docs, they have appendix saying how =
they are meeting the requirements.=20
>=20
> Ben - I hope we do appendices like that, too. We haven't done the =
engineering to see if not technically feasible. I'm ok on the SHOULD and =
the MUST UNLESS. However, the implementers can't implement unless its a =
MUST.=20
>=20
> ACTION: Add appendices.=20
>=20

I meant the my appendix comment to apply to the solution(s). That is, I =
hope those documents have appendixes that state how they meet the =
requirements.


-- overload data analysis discussion:

> slide 4 - Fundamental Differences
>=20
> Hannes - The requirements doc was only a kindness. Looking at the =
solutions, it isn't clear what the common cases are. The scopes =
introduce lots of complexity. Where do you stop? What are the deployment =
cases for them?
>=20
> Ben - Some of the scopes are required. There are also requirements on =
making things better, like requirement 3.=20
>=20
> Hannes - I'm worried about the complexity of the implementation. How =
to combine scopes? SDOs reuse application ids. We should extend scope to =
specific AVPs.
>=20

Did Hannes say we "should" extend scopes to cover specific AVPs, or that =
we "could"? I thought his concern is that our scopes may be too complex, =
not that we need to add further complexity.

-- e2e security requirements, slide 3:

> Glen - we have an underlying infrastructure that is trusted. You don't =
really need to know where it came from, that the route is correct. We =
want to protect against a compromised node. If you use TLS and DTLS, =
don't have to worry about [=85]
>=20
> Hannes - the threat model is an intermediary. Authentication tells you =
that you received from the right element. You have multiple keys would =
give you authentication functionality.=20
>=20
> Glen - I don't see a secret key flying. In theory we're using TLS, =
DTLS, IPSEC and public keys. In theory. We should use them instead of =
going to all the trouble of configuring secret keys in an N-squared =
environment.
>=20
> Hannes - we disagree on core crypto principles.=20
>=20
> Ben - I'm confused by trusting a node but could be compromised.

 I further mentioned that, with integrity protection but no =
authentication, a compromised node could still allow untrusted 3rd =
parties to insert messages=20

> Hannes - TLS won't get you anywhere, goes through compromised node. =
CRC check provides integrity by detecting errors [=85] You want to avoid =
[=85] You want to tie to a specific entity. Do it with integrity =
protection and authentication by applying key only known by both =
parties.=20
>=20

The exchange above (between Glen, Hannes, and me) was in the context of =
whether integrity protection is useful without authentication.



From ben@nostrum.com  Tue Mar 26 13:30:52 2013
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 26A5E21F8D7F for ; Tue, 26 Mar 2013 13:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkhZ+Y1uVQJs for ; Tue, 26 Mar 2013 13:30:51 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A08DF21F8D1E for ; Tue, 26 Mar 2013 13:30:50 -0700 (PDT)
Received: from [10.0.1.7] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2QKUjwg041980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Mar 2013 15:30:46 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell 
Content-Type: multipart/alternative; boundary="Apple-Mail=_DDAF9ABB-1199-4C97-8B8A-E571562EA223"
Message-Id: 
Date: Tue, 26 Mar 2013 15:30:44 -0500
To: "dime@ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Subject: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Mar 2013 20:30:52 -0000

--Apple-Mail=_DDAF9ABB-1199-4C97-8B8A-E571562EA223
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

We had a discussion about whether REQ 35 in the =
draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST.  We =
further discussed that any use of a MUST here would require some caveats =
about what sort of intermediaries could be traversed, and the potential =
security issues. The chairs directed us to take the discussion to the =
list due to time constraints. Here's my attempt to do so.

For reference, here's the original text:

> The mechanism SHOULD provide a method for exchanging overload and load =
information between elements that are connected by intermediaries that =
do not support the mechanism.
>=20

Here's a proposed alternative for changing it to a MUST:

> The mechanism MUST provide a method for exchanging overload and load =
information between elements that are connected by intermediaries that =
do not support the mechanism. The mechanism MAY place limitations on the =
nature of the non-supporting intermediaries that may be traversed.=20
>=20
> Nothing in this requirement should be construed to relax the =
security-related requirements elsewhere in this document, in particular =
REQs 28, 30, and 31. Maliciously constructed overload information can =
potentially shut down a Diameter network; it's critical that a node be =
able to confirm that received information came unaltered from an =
authorized source, whether the information comes from an immediate peer =
or crosses an intermediary.


Which general approach do people prefer? I kept the security aspects =
non-normative, since normative text already exists in 28,30, and 31.

Thanks!

Ben.=

--Apple-Mail=_DDAF9ABB-1199-4C97-8B8A-E571562EA223
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


The mechanism SHOULD provide a method for =
exchanging overload and load information between elements that =
are connected by intermediaries that do not support =
the mechanism.




Hi Ben,


See in line,<=
/p>

Kind Regards,=



Nigel


 










From: Ben Campbell
 [mailto:ben@nostrum.com] 

Sent: 11 March 2013 23:16
To: TROTTIN, JEAN-JACQUES (J=
EAN-JACQUES)

Cc: lionel.morand@orange.com=
; DRAGE, Keith (Keith); dime@ietf.org; BERRY, Nigel (Nigel); Bessis, Thierr=
y (Thierry)

Subject: Re: [Dime] draft-ie=
tf-dime-overload-reqs-03: REQ 2




 




Hi,






 






I'm separating out the one really contentious issue:






On Mar 11, 2013, at 5:49 PM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&quo=
t; <jean-jacq=
ues.trottin@alcatel-lucent.com> wrote:












By "client application", I mean the thing the client  does t=
hat needs Diameter in the first place--in your example, it's the "driv=
ing UE behavior" part. (I'm open to suggestions for better words =
than "client application")



[LM] referring to the definition given above, the second "client appli=
cation" seems redundant. The text could simply be:



"Diameter clients must be able to receive sufficient information to su=
pport graceful behavior during an overload condition"






I'm okay with that change. I was looking for a word that described the &quo=
t;application" that a client uses at the edge of the network for its o=
wn customers, to handle things like network attachments. That is, some=
thing distinct from the "Diameter application".
 But I agree that the requirement can stand without it.

[Nigel] Are not these the Diameter Clients?






[JJ] Initially I used the expression Diameter application. After, from Lion=
el's suggestion, we wrote "The mechanism MUST allow Diameter clie=
nts to be aware of an overload situation" to avoid the use of the word=
 "application", so I do not see why this sentence
 is not acceptable . On the other point, I do not understand what &nbs=
p;is "sufficient information". The information that the Diameter =
client must receive is simply the overload information that will be de=
fined by IETF for the overload control mechanism (as in point
 2 a).




 




It comes down to a difference between requirements and solution. &n=
bsp;I don't think any of us know the details of what constitutes "suff=
icient information" yet. The idea
 is, to leave it to the solution development effort to figure out exactly w=
hat that is. Maybe that shows us that the "sufficient information"=
; is always the OC info sent by the server. But maybe it will be something =
else, or maybe it will be a mixture. The important
 point is that it "enables graceful behavior". If people disagree=
 on what the details of what information is sufficient to that goal, that's=
 even a better reason to not over-constrain the solution in the requirement=
 document.


[Nigel] How about
"sufficient information to enable a graceful beh=
aviour"?




 






Imagine a solution with the following properties as a though experi=
ment.










 






1. When a server becomes overloaded, it sends an overload report.






2. If no agent exists, the overload report goes directly to the cli=
ent.






3. If an agent exists, it attempts to resolve the overload situatio=
n locally. (For example, it tries to divert load to another server that has=
 sufficient capacity.)
 If it's successful, the client _never_ learns the overload condition happe=
ned in the first place.






4. If the agent cannot resolve the load locally, it originates its =
own overload report back toward the client. This report describes the aggre=
gate overload of the agent
 and the network upstream of it. It is likely to be significantly different=
 than the report originally sent by the server, and may include no informat=
ion whatsoever from the original report sent by the server.






 






Would an approach like that meet the requirement you have in mind? =
Would another approach that guaranteed that the client would see the origin=
al server's overload report
 be preferable?


[Nigel] We obviously have to bear in mind that a Diamete=
r proxy may be able to deal with an
 overload situation of a topology that it is hiding, on the other hand it m=
ight not, so in the normal case the Diameter Client must be informed of any=
 overload situation pertaining to the Clients it is responsible for.=







 




Here's a =
proposed alternative for changing it to a =
MUST:

The =
mechanism MUST provide a method for exchanging overload and load =
information between elements that are connected by intermediaries =
that do not support the mechanism. The mechanism MAY place =
limitations on the nature of the non-supporting intermediaries that may =
be traversed. 

Nothing in this requirement should =
be construed to relax the security-related requirements elsewhere in =
this document, in particular REQs 28, 30, and 31. Maliciously =
constructed overload information can potentially shut down a Diameter =
network; it's critical that a node be able to confirm that received =
information came unaltered from an authorized source, whether the =
information comes from an immediate peer or crosses an =
intermediary.


=
Which general approach do people prefer? I kept the security aspects =
non-normative, since normative text already exists in 28,30, and =
31.

Thanks!

Ben.
=

--Apple-Mail=_DDAF9ABB-1199-4C97-8B8A-E571562EA223--

From lionel.morand@orange.com  Wed Mar 27 01:48:11 2013
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 5166321F867E for ; Wed, 27 Mar 2013 01:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dSJ8S+H1Jpc for ; Wed, 27 Mar 2013 01:48:10 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7A021F85B3 for ; Wed, 27 Mar 2013 01:48:10 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4204422C718; Wed, 27 Mar 2013 09:48:09 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DE76035C068; Wed, 27 Mar 2013 09:48:08 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 27 Mar 2013 09:48:08 +0100
From: 
To: "jouni.nospam@gmail.com" , "hannes.tschofenig@gmx.net" , "dime@ietf.org" 
Thread-Topic: RE : Fwd: [Dime] Draft minutes available
Thread-Index: Ac4qx82SMKlTBygDQF+hsboaoSe4Dg==
Date: Wed, 27 Mar 2013 08:48:07 +0000
Message-ID: <21919_1364374089_5152B249_21919_5391_1_1lrvjtxdvnkbnomr48au13w5.1364374079483@email.android.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_1lrvjtxdvnkbnomr48au13w51364374079483emailandroidcom_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.27.75417
Subject: [Dime] RE : Fwd:  Draft minutes available
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Mar 2013 08:48:11 -0000

--_000_1lrvjtxdvnkbnomr48au13w51364374079483emailandroidcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNClBsZWFzZSBzZWUgYmVsb3cuDQoNCg0KDQotLS0tLS0tLSBNZXNzYWdlIGQnb3JpZ2lu
ZSAtLS0tLS0tLQ0KT2JqZXQgOiBGd2Q6IFtEaW1lXSBEcmFmdCBtaW51dGVzIGF2YWlsYWJsZQ0K
RGUgOiBKb3VuaSBLb3Job25lbiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT4NCkEgOiBNT1JBTkQg
TGlvbmVsIE9MTkMvT0xOIDxsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+LEhhbm5lcyBUc2Nob2Zl
bmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Pg0KQ0MgOg0KDQoNCg0KPiBJIGhhdmUgYSBm
ZXcgbWlub3IgY29tbWVudHMgYW5kIGNvcnJlY3Rpb25zIGZvciB0aGUgZHJhZnQgbWludXRlczoN
Cj4NCj4gLS0gaW4gdGhlIG92ZXJsb2FkLXJlcXMgZGlzY3Vzc2lvbjoNCj4NCj4+IEtlaXRoIC0g
VGhpcyBpcyBhIHJlcXVpcmVtZW50cyBkb2MsIHRodXMgbm8gb25lIHdpbGwgaW1wbGVtZW50IHRo
aXMuIFRoZSBNVVNUIGNvbnN0cmFpbnMgdGhlIHdvcmtpbmcgZ3JvdXAgb24gdGhlIHNvbHV0aW9u
IGRvYy4gVGhlcmUgaXMgbm8gcHJvYmxlbSB3aXRoIHRleHQgaGVyZS4gTVVTVCB2cyBTSE9VTEQg
LSB3ZSB3YW50IHRvIHNheSBNVVNUIGhlcmUuIElmIHRoZXJlJ3MgcHJvYmxlbSB3aXRoIHRoZSBN
VVNULCB5b3Ugc2hvdWxkIGNvbnN0cmFpbiBpdCB0aGUgZm9sbG93aW5nIHRleHQuDQo+Pg0KPj4g
TGlvbmVsIC0gSSBkb24ndCB1bmRlcnN0YW5kLiBUaGVyZSdzIG5vIHdheSB0byBkbyB0aGlzIHdp
dGhvdXQgYSBuZXcgYXBwbGljYXRpb24gSUQuIFlvdSB3b3VsZCBuZWVkIHRvIGdvIHRocm91Z2gg
ZGVkaWNhdGVkIHByb3hpZXMgdG8gZG8gdGhpcy4NCj4NCj4gSSB0aG91Z2h0IExpb25lbCB3YXMg
Y29tbWVudGluZyB0aGF0IHRoZSAibmV3IGFwcGxpY2F0aW9uIiBhcHByb2FjaCBmb3IgbW92aW5n
IG92ZXJsb2FkIGNvbnRyb2wgaW5mbyBhcm91bmQgd291bGRuJ3QgYmUgYWJsZSB0byBzb2x2ZSB0
aGUgUmVxIDM1IChjcm9zc2luZyBub24tc3VwcG9ydGluZyBpbnRlcm1lZGlhcmllcykgdXNlIGNh
c2UuIERpZCBJIG1pc3VuZGVyc3RhbmQgdGhlIGNvbW1lbnQ/DQo+DQpCZW4gaXMgcmlnaHQuIEkg
c2FpZCB0aGF0IGEgbmV3IGFwcGxpY2F0aW9uIHdpbGwgb25seSBiZSBhYmxlIHRvIGdvIHRocm91
Z2ggZXhpc3RpbmcgcmVsYXkgYW5kIHJlZGlyZWN0IGFnZW50IGFuZCBub3QgdGhyb3VnaCAibGVn
YWN5IiBwcm94aWVzIGkuZS4gTm90IHN1cHBvcnRpbmcvYWR2ZXJ0aXNpbmcgdGhlIG5ldyBhcHBs
aWNhdGlvbi4NClNvIHRoZSBxdWVzdGlvbiBpcyBzaW1wbGU6IGluIHRoZSByZXF1aXJlbWVudCBl
bGFib3JhdGlvbiBwaGFzZSwgYXJlIHdlIHN1cmUgdGhhdCBhIHNvbHV0aW9uIGJhc2VkIG9uIGEg
bmV3IEFwcC1pZCB3aWxsIGJlIHJlamVjdGVkPyBJZiBub3QsIHRoZSAiU2hvdWxkIiBpcyBtZWFu
aW5nZnVsLiBJZiB5ZXMsIHRoaXMgaXMgYSBzdHJvbmcgcmVxdWlyZW1lbnQgZHJhZnQgYW5kIHRo
aXMgbXVzdCBiZSBzdGF0ZWQgc29tZXdoZXJlIGluIHRoZSBkcmFmdC4NCg0KUmVnYXJkcywNCg0K
TGlvbmVsDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu
dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll
ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w
aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl
cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl
IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz
IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29tIC0gT3Jhbmdl
IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs
IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo
bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g
dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1
dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg
ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl
IGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh
Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg
eW91LgoK

--_000_1lrvjtxdvnkbnomr48au13w51364374079483emailandroidcom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KSGksDQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGRpdj5QbGVhc2Ugc2VlIGJlbG93Ljxmb250IGNsYXNzPSJBcHBsZS1zdHls
ZS1zcGFuIiBzaXplPSI0Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZv
bnQtc2l6ZTogMTZweDsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8YnI+DQo8YnI+DQo8
YnI+DQotLS0tLS0tLSBNZXNzYWdlIGQnb3JpZ2luZSAtLS0tLS0tLTxicj4NCk9iamV0IDogRndk
OiBbRGltZV0gRHJhZnQgbWludXRlcyBhdmFpbGFibGU8YnI+DQpEZSA6IEpvdW5pIEtvcmhvbmVu
ICZsdDtqb3VuaS5ub3NwYW1AZ21haWwuY29tJmd0Ozxicj4NCkEgOiBNT1JBTkQgTGlvbmVsIE9M
TkMvT0xOICZsdDtsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20mZ3Q7LEhhbm5lcyBUc2Nob2Zlbmln
ICZsdDtIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Jmd0Ozxicj4NCkNDIDogPGJyPg0KPGJyPg0K
PGJyPg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGw7Ij48YnI+DQomZ3Q7IEkgaGF2
ZSBhIGZldyBtaW5vciBjb21tZW50cyBhbmQgY29ycmVjdGlvbnMgZm9yIHRoZSBkcmFmdCBtaW51
dGVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSBpbiB0aGUgb3ZlcmxvYWQtcmVxcyBkaXNjdXNz
aW9uOjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgS2VpdGggLSBUaGlzIGlzIGEgcmVxdWlyZW1l
bnRzIGRvYywgdGh1cyBubyBvbmUgd2lsbCBpbXBsZW1lbnQgdGhpcy4gVGhlIE1VU1QgY29uc3Ry
YWlucyB0aGUgd29ya2luZyBncm91cCBvbiB0aGUgc29sdXRpb24gZG9jLiBUaGVyZSBpcyBubyBw
cm9ibGVtIHdpdGggdGV4dCBoZXJlLiBNVVNUIHZzIFNIT1VMRCAtIHdlIHdhbnQgdG8gc2F5IE1V
U1QgaGVyZS4gSWYgdGhlcmUncyBwcm9ibGVtIHdpdGggdGhlIE1VU1QsIHlvdSBzaG91bGQgY29u
c3RyYWluDQogaXQgdGhlIGZvbGxvd2luZyB0ZXh0LiA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyBMaW9uZWwgLSBJIGRvbid0IHVuZGVyc3RhbmQuIFRoZXJlJ3Mgbm8gd2F5IHRvIGRvIHRo
aXMgd2l0aG91dCBhIG5ldyBhcHBsaWNhdGlvbiBJRC4gWW91IHdvdWxkIG5lZWQgdG8gZ28gdGhy
b3VnaCBkZWRpY2F0ZWQgcHJveGllcyB0byBkbyB0aGlzLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IEkgdGhvdWdodCBMaW9uZWwgd2FzIGNvbW1lbnRpbmcgdGhhdCB0aGUgJnF1b3Q7bmV3IGFwcGxp
Y2F0aW9uJnF1b3Q7IGFwcHJvYWNoIGZvciBtb3Zpbmcgb3ZlcmxvYWQgY29udHJvbCBpbmZvIGFy
b3VuZCB3b3VsZG4ndCBiZSBhYmxlIHRvIHNvbHZlIHRoZSBSZXEgMzUgKGNyb3NzaW5nIG5vbi1z
dXBwb3J0aW5nIGludGVybWVkaWFyaWVzKSB1c2UgY2FzZS4gRGlkIEkgbWlzdW5kZXJzdGFuZCB0
aGUgY29tbWVudD88YnI+DQomZ3Q7IDxicj4NCkJlbiBpcyByaWdodC4gSSBzYWlkIHRoYXQgYSBu
ZXcgYXBwbGljYXRpb24gd2lsbCBvbmx5IGJlIGFibGUgdG8gZ28gdGhyb3VnaCBleGlzdGluZyBy
ZWxheSBhbmQgcmVkaXJlY3QgYWdlbnQgYW5kIG5vdCB0aHJvdWdoICZxdW90O2xlZ2FjeSZxdW90
OyBwcm94aWVzIGkuZS4gTm90IHN1cHBvcnRpbmcvYWR2ZXJ0aXNpbmcgdGhlIG5ldyBhcHBsaWNh
dGlvbi4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsOyI+U28g
dGhlIHF1ZXN0aW9uIGlzIHNpbXBsZTogaW4gdGhlIHJlcXVpcmVtZW50IGVsYWJvcmF0aW9uIHBo
YXNlLCBhcmUgd2Ugc3VyZSB0aGF0IGEgc29sdXRpb24gYmFzZWQgb24gYSBuZXcgQXBwLWlkIHdp
bGwgYmUgcmVqZWN0ZWQ/IElmIG5vdCwgdGhlICZxdW90O1Nob3VsZCZxdW90OyBpcyBtZWFuaW5n
ZnVsLiBJZiB5ZXMsIHRoaXMgaXMgYSBzdHJvbmcgcmVxdWlyZW1lbnQgZHJhZnQgYW5kIHRoaXMg
bXVzdA0KIGJlIHN0YXRlZCBzb21ld2hlcmUgaW4gdGhlIGRyYWZ0LjwvZGl2Pg0KPGRpdiBzdHls
ZT0id29yZC1icmVhazpicmVhay1hbGw7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQt
YnJlYWs6YnJlYWstYWxsOyI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6
YnJlYWstYWxsOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFs
bDsiPkxpb25lbCZuYnNwOzwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw
aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50
aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz
ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy
ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk
aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l
c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJh
bmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt
ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp
dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNo
b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh
dGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v
dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu
dHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMg
bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg
b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_1lrvjtxdvnkbnomr48au13w51364374079483emailandroidcom_--

From lionel.morand@orange.com  Wed Mar 27 07:55:16 2013
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 D63E621F9047 for ; Wed, 27 Mar 2013 07:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdAADeHGadK9 for ; Wed, 27 Mar 2013 07:55:16 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8EADC21F9007 for ; Wed, 27 Mar 2013 07:55:14 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 925801D00E5; Wed, 27 Mar 2013 15:55:13 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6C02427C093; Wed, 27 Mar 2013 15:55:13 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 27 Mar 2013 15:55:13 +0100
From: 
To: Ben Campbell , "dime@ietf.org" 
Thread-Topic: [Dime] Proposed REQ 35 Text
Thread-Index: AQHOKmDSwGrm0hvPTESdb4ZLexiCLJi5oC+A
Date: Wed, 27 Mar 2013 14:55:12 +0000
Message-ID: <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: 
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.197.38.3]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E18562CPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.27.132717
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Mar 2013 14:55:17 -0000

--_000_6B7134B31289DC4FAF731D844122B36E18562CPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Following the discussion in the meeting, here is my interpretation.
I said during the meeting that a new application will only be able to go th=
rough existing relay and redirect agent and not through "legacy" proxies i.=
e. proxies not supporting/advertising the new application.

So the question is simple: in the requirement elaboration phase, are we sur=
e that any solution based on a new App-id will be rejected?

If not: the "SHOULD" is meaningful in REQ35.
If yes: this is a strong requirement and this must be stated somewhere in t=
he draft.

Lionel

De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben=
 Campbell
Envoy=E9 : mardi 26 mars 2013 21:31
=C0 : dime@ietf.org
Objet : [Dime] Proposed REQ 35 Text

Hi,

We had a discussion about whether REQ 35 in the draft-ietf-dime-overload-re=
qs should stay a SHOULD or become a MUST.  We further discussed that any us=
e of a MUST here would require some caveats about what sort of intermediari=
es could be traversed, and the potential security issues. The chairs direct=
ed us to take the discussion to the list due to time constraints. Here's my=
 attempt to do so.

For reference, here's the original text:

The mechanism SHOULD provide a method for exchanging overload and load info=
rmation between elements that are connected by intermediaries that do not s=
upport the mechanism.


Here's a proposed alternative for changing it to a MUST:

The mechanism MUST provide a method for exchanging overload and load inform=
ation between elements that are connected by intermediaries that do not sup=
port the mechanism. The mechanism MAY place limitations on the nature of th=
e non-supporting intermediaries that may be traversed.

Nothing in this requirement should be construed to relax the security-relat=
ed requirements elsewhere in this document, in particular REQs 28, 30, and =
31. Maliciously constructed overload information can potentially shut down =
a Diameter network; it's critical that a node be able to confirm that recei=
ved information came unaltered from an authorized source, whether the infor=
mation comes from an immediate peer or crosses an intermediary.


Which general approach do people prefer? I kept the security aspects non-no=
rmative, since normative text already exists in 28,30, and 31.

Thanks!

Ben.

___________________________________________________________________________=
______________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


--_000_6B7134B31289DC4FAF731D844122B36E18562CPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Following the discussion in the meeting, here is my interpre=
tation.


I said during the meeting that a new application will only b=
e able to go through existing relay and redirect agent and not through &quo=
t;legacy" proxies
 i.e. proxies not supporting/advertising the new application. 


 


So the question is simple: in the requirement elaboration ph=
ase, are we sure that any solution based on a new App-id will be rejected?<=
o:p>


 


If not: the "SHOULD" is meaningful in REQ35.



If yes: this is a strong requirement and this must be stated=
 somewhere in the draft.


 


Lionel


 






De : dime=
-bounces@ietf.org [mailto:dime-bounces@ietf.org]
De la part de Ben Campbell

Envoy=E9 : mardi 26 mars 2013 21:31

=C0 : dime@ietf.org

Objet : [Dime] Proposed REQ 35 Text






 




Hi,






 






We had a discussion about whether REQ 35 in the draf=
t-ietf-dime-overload-reqs should stay a SHOULD or become a MUST.  We f=
urther discussed that any use of a MUST here would require some caveats abo=
ut what sort of intermediaries could be
 traversed, and the potential security issues. The chairs directed us to ta=
ke the discussion to the list due to time constraints. Here's my attempt to=
 do so.






 






For reference, here's the original text:<=
/p>





 










The mechanism SHOULD provide a method for exchanging=
 overload and load information between elements that are connecte=
d by intermediaries that do not support the mechanism.




 




 






Here's a proposed alternative for changing it to a M=
UST:






 








The mechanism MUST provide a method for exchanging&n=
bsp;overload and load information between elements that are connected =
by intermediaries that do not support the mechanism. The mechanism MAY=
 place limitations on the nature of the non-supporting
 intermediaries that may be traversed. 






 






Nothing in this requirement should be construed to r=
elax the security-related requirements elsewhere in this document, in parti=
cular REQs 28, 30, and 31. Maliciously constructed overload information can=
 potentially shut down a Diameter
 network; it's critical that a node be able to confirm that received inform=
ation came unaltered from an authorized source, whether the information com=
es from an immediate peer or crosses an intermediary.








 






 






Which general approach do people prefer? I kept the =
security aspects non-normative, since normative text already exists in 28,3=
0, and 31.






 






Thanks!






 






Ben.






______________________________________________________________________=
___________________________________________________

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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.




--_000_6B7134B31289DC4FAF731D844122B36E18562CPEXCVZYM13corpora_--

From lists.abooth@gmail.com  Wed Mar 27 08:01:54 2013
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 A1E7121F91BC for ; Wed, 27 Mar 2013 08:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YLJV33v-HyN for ; Wed, 27 Mar 2013 08:01:53 -0700 (PDT)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id BE31121F91C0 for ; Wed, 27 Mar 2013 08:01:53 -0700 (PDT)
Received: by mail-qe0-f54.google.com with SMTP id i11so4591223qej.13 for ; Wed, 27 Mar 2013 08:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Be4zxd6o+m0vO9OdWKjhcG5LNfm9Zw2nV7cu3Fr0IzA=; b=eRG/GUsTnElWKxUeIwn4z63kphBGGRUXtDvBMJ3XFWzVgTDJy2+EV/VXoCd4DfyK3m DhMhnU4UZT2LwOFMT0Q/hS7XI6hxeWtIm0tVziSfl+XvuSKOwMRpecGYI9s+Y4+wSR7i wx1B3CFijR0l1RYb4BTZUlqrriz+fT4c3UKxNUjS6oFGZG5YQwOzPB8azxzJSB6XU9Gt iWQd2OVUlnfwIQ/wNBDzoqmfTqvtXooZgS8b0J4DTVbRSe8U0AEIHWPCjp0CygIva8Il WiSZil4LPYETcxwOo+b8WgF66pwTBgwNYVMXd56O6LDvjiYN0p8bwJqFBHZgKqRBz3a/ GU4Q==
MIME-Version: 1.0
X-Received: by 10.229.62.200 with SMTP id y8mr3670633qch.128.1364396513080; Wed, 27 Mar 2013 08:01:53 -0700 (PDT)
Received: by 10.49.63.163 with HTTP; Wed, 27 Mar 2013 08:01:52 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 27 Mar 2013 11:01:52 -0400
Message-ID: 
From: Andrew Booth 
To: Ben Campbell , Eric McMurry 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Mar 2013 15:01:54 -0000

Hi Ben,

If we don't find a solution that supports REQ 35, I would prefer to
have a 95% solution now than scrap such a solution because it fails
the MUST of REQ 35.  Hence, I prefer that REQ 35 be a SHOULD.

There is nothing to prevent multiple different implementations from
being standardized (well, other than the difficulty getting WG
cycles).  I don't see that all of them need to have full support for
REQ 35.  That opens the door for other approaches to be proposed once
end-to-end security in Diameter is standardized.

There is also nothing that prevents interested parties that want
support for REQ 35 to propose a solution that supports it, and to
defend that solution compared to others.

If I recall correctly, the desire to make this a MUST came from an
implementer that wanted to be able to signal handsets about the
congestion.  Is that the motivating statement?  If so, is it worth
taking a closer look at the motivating case to see what information
they really require (is it full information? or will partial
information do?), and whether it should have this much impact on the
potential solutions?
At first glance, signaling handsets about congestion sounds like a
(potentially useful) optimization, but does not sound to me as
important as protecting core network resources (by having some working
implementation of overload control).  Maybe I'm misunderstanding the
motivating case or it's importance, I'm willing to be convinced.

More comments inline.

On Tue, Mar 26, 2013 at 4:30 PM, Ben Campbell  wrote:
> Hi,
>
> We had a discussion about whether REQ 35 in the
> draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST.  We
> further discussed that any use of a MUST here would require some caveats
> about what sort of intermediaries could be traversed, and the potential
> security issues. The chairs directed us to take the discussion to the list
> due to time constraints. Here's my attempt to do so.
>
> For reference, here's the original text:
>
> The mechanism SHOULD provide a method for exchanging overload and load
> information between elements that are connected by intermediaries that do
> not support the mechanism.
>
>
> Here's a proposed alternative for changing it to a MUST:
>
> The mechanism MUST provide a method for exchanging overload and load
> information between elements that are connected by intermediaries that do
> not support the mechanism. The mechanism MAY place limitations on the nature
> of the non-supporting intermediaries that may be traversed.

Is there any limit to the limitations?  Currently loophole: a
mechanism can limit the non-supporting intermediaries to the empty
set, and we're back to REQ 35 being a SHOULD.
Is this extra text intended to allow for a new application id (hence
limiting proxies that have not been upgraded to support the
mechanism)?
Is this extra text intended to allow for REQ 35 through "trusted"
intermediaries, hence working around the end-to-end security
requirement (this sounds dodgy to me)?

Thanks,
Andrew

>
> Nothing in this requirement should be construed to relax the
> security-related requirements elsewhere in this document, in particular REQs
> 28, 30, and 31. Maliciously constructed overload information can potentially
> shut down a Diameter network; it's critical that a node be able to confirm
> that received information came unaltered from an authorized source, whether
> the information comes from an immediate peer or crosses an intermediary.
>
>
>
> Which general approach do people prefer? I kept the security aspects
> non-normative, since normative text already exists in 28,30, and 31.
>
> Thanks!
>
> Ben.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

From ben@nostrum.com  Wed Mar 27 08:28:26 2013
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 8F84F21F84E3 for ; Wed, 27 Mar 2013 08:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAF92umcESaM for ; Wed, 27 Mar 2013 08:28:23 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B218221F84E0 for ; Wed, 27 Mar 2013 08:28:22 -0700 (PDT)
Received: from [10.119.75.158] (69.147.243.203.rdns.ubiquityservers.com [69.147.243.203] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2RFSKnV073212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 10:28:21 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ben Campbell 
In-Reply-To: <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Wed, 27 Mar 2013 10:28:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <636561F1-0BED-4AB2-B359-FFE0633714D3@nostrum.com>
References:  <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: lionel.morand@orange.com
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass (shaman.nostrum.com: 69.147.243.203 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Mar 2013 15:28:26 -0000

Hi Lionel,

On Mar 27, 2013, at 9:55 AM, lionel.morand@orange.com wrote:

> Hi,
> =20
> Following the discussion in the meeting, here is my interpretation.
> I said during the meeting that a new application will only be able to =
go through existing relay and redirect agent and not through "legacy" =
proxies i.e. proxies not supporting/advertising the new application.
> =20
> So the question is simple: in the requirement elaboration phase, are =
we sure that any solution based on a new App-id will be rejected?
> =20
> If not: the "SHOULD" is meaningful in REQ35.
> If yes: this is a strong requirement and this must be stated somewhere =
in the draft.

For the record, the piggy-backed solution currently proposed also does =
not meet REQ35.

We don't necessarily try to prove feasibility in advance for all =
requirements. I'm not sure what the work group approach would be in =
handling a MUST level requirement that turns out to be infeasible. I =
suspect it would be to merely notate that we couldn't come up with a =
reasonable way to meet the requirement and move on. Making it a MUST =
means we need to try hard, though, and look for alternatives if none of =
our proposals meet it.

I'm also not convinced a MUST here automatically disallows an =
application-based approach. Other applications have to deal with relays =
that return just the relay app ID in the capabilities exchange. We also =
mentioned the possibility of a separate mechanism to handle the =
non-adjacent case.=

From jean-jacques.trottin@alcatel-lucent.com  Wed Mar 27 09:06:40 2013
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 28E7021F9274 for ; Wed, 27 Mar 2013 09:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eFUzN3E8iwA for ; Wed, 27 Mar 2013 09:06:38 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5C21F926D for ; Wed, 27 Mar 2013 09:06:38 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2RG6a3F000782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Mar 2013 11:06:37 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2RG6V74017766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Mar 2013 12:06:36 -0400
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 27 Mar 2013 12:06:35 -0400
Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.29]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 27 Mar 2013 17:06:11 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Ben Campbell , "lionel.morand@orange.com" 
Thread-Topic: [Dime] Proposed REQ 35 Text
Thread-Index: AQHOKmDYS+DcvVurpkqLP2GHzogK35i5kKUAgAAJN4CAABn4UA==
Date: Wed, 27 Mar 2013 16:06:09 +0000
Message-ID: 
References:  <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <636561F1-0BED-4AB2-B359-FFE0633714D3@nostrum.com>
In-Reply-To: <636561F1-0BED-4AB2-B359-FFE0633714D3@nostrum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Mar 2013 16:06:40 -0000

Hi Lionel, Ben


I already  expressed my views for a MUST  on this REQ35 topic in previous m=
ails.

As 3GPP will be a main user of the overlaod mechanism, and as 3GPP CT4 has =
a dedicated meeting on Diameter overlaod on April 9th 11th, where this toin=
t will be discussed. I prefer to wait for the CT4 outputs before coming bac=
k to the DIME mail discussion.

Best regards

JJacques=20

 =20
-----Message d'origine-----
De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B=
en Campbell
Envoy=E9=A0: mercredi 27 mars 2013 16:28
=C0=A0: lionel.morand@orange.com
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] Proposed REQ 35 Text

Hi Lionel,

On Mar 27, 2013, at 9:55 AM, lionel.morand@orange.com wrote:

> Hi,
> =20
> Following the discussion in the meeting, here is my interpretation.
> I said during the meeting that a new application will only be able to go =
through existing relay and redirect agent and not through "legacy" proxies =
i.e. proxies not supporting/advertising the new application.
> =20
> So the question is simple: in the requirement elaboration phase, are we s=
ure that any solution based on a new App-id will be rejected?
> =20
> If not: the "SHOULD" is meaningful in REQ35.
> If yes: this is a strong requirement and this must be stated somewhere in=
 the draft.

For the record, the piggy-backed solution currently proposed also does not =
meet REQ35.

We don't necessarily try to prove feasibility in advance for all requiremen=
ts. I'm not sure what the work group approach would be in handling a MUST l=
evel requirement that turns out to be infeasible. I suspect it would be to =
merely notate that we couldn't come up with a reasonable way to meet the re=
quirement and move on. Making it a MUST means we need to try hard, though, =
and look for alternatives if none of our proposals meet it.

I'm also not convinced a MUST here automatically disallows an application-b=
ased approach. Other applications have to deal with relays that return just=
 the relay app ID in the capabilities exchange. We also mentioned the possi=
bility of a separate mechanism to handle the non-adjacent case.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

From ben@nostrum.com  Wed Mar 27 11:13:53 2013
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 36A0921F92B2 for ; Wed, 27 Mar 2013 11:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.6
X-Spam-Level: 
X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWeqNr1ZAhp9 for ; Wed, 27 Mar 2013 11:13:52 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F82C21F9291 for ; Wed, 27 Mar 2013 11:13:48 -0700 (PDT)
Received: from vpn-cust-10-119-75-94.witopia.net (cloud46-111.mgtt.net [208.81.246.111]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2RIDcLE091508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Mar 2013 13:13:38 -0500 (CDT) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 27 Mar 2013 13:13:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: Andrew Booth 
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass (shaman.nostrum.com: 208.81.246.111 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Mar 2013 18:13:53 -0000

Hi. Comments inline:

On Mar 27, 2013, at 10:01 AM, Andrew Booth  =
wrote:

> Hi Ben,
>=20
> If we don't find a solution that supports REQ 35, I would prefer to
> have a 95% solution now than scrap such a solution because it fails
> the MUST of REQ 35.  Hence, I prefer that REQ 35 be a SHOULD.
>=20

I don't think that means we have to scrap a 95% solution. (Unless we =
have an alternate 100% solution, in which case a SHOULD and MUST would =
would have the same effect.)

My personal opinion would be that a MUST means the working group's job =
isn't done until it either meets the requirement, or determines that the =
requirement was not reasonably feasible. The former could be =
accomplished with a 100% solution, or a 95% solution with an additional =
mechanism designed to solve just this requirement. In the same =
circumstances, a SHOULD would make it easier to just take the 95% =
solution and stop.

> There is nothing to prevent multiple different implementations from
> being standardized (well, other than the difficulty getting WG
> cycles).  I don't see that all of them need to have full support for
> REQ 35.  That opens the door for other approaches to be proposed once
> end-to-end security in Diameter is standardized.

Agreed. The "not reasonably feasible" bit in my previous comment could =
also mean "not reasonably feasible _now_". As a purely hypothetical =
example, if the security issues turn out to be the main thing to block =
Req 34, iIt might make sense to make sure the chosen solution doesn't =
prevent Req 35 from being solved in some future update once the e2e =
security work is complete, or at least stabile.

>=20
> There is also nothing that prevents interested parties that want
> support for REQ 35 to propose a solution that supports it, and to
> defend that solution compared to others.
>=20
> If I recall correctly, the desire to make this a MUST came from an
> implementer that wanted to be able to signal handsets about the
> congestion.  Is that the motivating statement?  If so, is it worth
> taking a closer look at the motivating case to see what information
> they really require (is it full information? or will partial
> information do?), and whether it should have this much impact on the
> potential solutions?
> At first glance, signaling handsets about congestion sounds like a
> (potentially useful) optimization, but does not sound to me as
> important as protecting core network resources (by having some working
> implementation of overload control).  Maybe I'm misunderstanding the
> motivating case or it's importance, I'm willing to be convinced.

I don't think that's the main case. The use case I think the most people =
care about is the situation where you have a non-supporting agent =
between islands of overload-control. For example, an IPX provider =
sitting between operators doesn't support overload control, but the =
operators still need to share overload information.

There are certainly people that care about the use case you =
describe--but I think any solution to that use case would also solve the =
one you mention. It's the special case where _none_ of the agents =
support overload control.


[...]

>>=20
>>=20
>> Here's a proposed alternative for changing it to a MUST:
>>=20
>> The mechanism MUST provide a method for exchanging overload and load
>> information between elements that are connected by intermediaries =
that do
>> not support the mechanism. The mechanism MAY place limitations on the =
nature
>> of the non-supporting intermediaries that may be traversed.
>=20
> Is there any limit to the limitations?  Currently loophole: a
> mechanism can limit the non-supporting intermediaries to the empty
> set, and we're back to REQ 35 being a SHOULD.
> Is this extra text intended to allow for a new application id (hence
> limiting proxies that have not been upgraded to support the
> mechanism)?

I think the "limitation" is an assumption of reasonable behavior on the =
part of the working group :-) This isn't a contract; it's a general =
agreement as to what we are working on.  Creating limitations rule out =
all possible intermediaries would not fit my idea of a reasonable =
interpretation. In general, making "letter of the rule" interpretations =
that don't fit the clear "spirit of the rule" doesn't seem like =
reasonable working group behavior.

The sort of limitations we are likely to run up against are things like =
" can't cross a agent that does topology hiding". The reason we don't =
enumerate the limitations now is because we won't know what they are =
until we do the actual mechanism engineering. I could _hypothetically_ =
imagine things like "can't cross an agent that uses dynamic peer =
discovery" might pop up.

> Is this extra text intended to allow for REQ 35 through "trusted"
> intermediaries, hence working around the end-to-end security
> requirement (this sounds dodgy to me)?

I assume you are talking about the "nothing in this requirement..." =
paragraph. That's indented to show that it is intended as explanatory =
text, not normative text. The idea is not to allow or prohibit any =
particular security approach in advance, and to point out that accepting =
unauthenticated/unauthorized congestion information would violate the =
existing requirements about not adding new vulnerabilities.

It's up to the working group to decide what security approach is "good =
enough". I personally have my doubts that simply assuming intermediaries =
are "trusted" is an adequate approach--but I'm happy to defer that =
argument for now. (I know there are strong opinions on both sides) We =
might end up requiring the e2e security work. We might end up with some =
other special-purpose authz/n solution no one has thought of yet.

>=20
> Thanks,
> Andrew
>=20
>>=20
>> Nothing in this requirement should be construed to relax the
>> security-related requirements elsewhere in this document, in =
particular REQs
>> 28, 30, and 31. Maliciously constructed overload information can =
potentially
>> shut down a Diameter network; it's critical that a node be able to =
confirm
>> that received information came unaltered from an authorized source, =
whether
>> the information comes from an immediate peer or crosses an =
intermediary.
>>=20


From glenzorn@gmail.com  Wed Mar 27 20:09:23 2013
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 67DCC21F942E for ; Wed, 27 Mar 2013 20:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFIEohu2KFHY for ; Wed, 27 Mar 2013 20:09:22 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id ACC8921F941D for ; Wed, 27 Mar 2013 20:09:22 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id r11so1305880pdi.7 for ; Wed, 27 Mar 2013 20:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OhEmcUQ9eOYfEFqJGqjIpaBiZ8LOxNuLTZmrrP2QqWg=; b=jSUYELc03iDKVt8J04rT4+3wwbWs3+AlPsLmtr1aCKPgJNZzfr4VznMBFcQIAtZIQW sP7rvsMfYMxigwKCU6BVyTWSl1Pl7Wtfq8WnHkVxnMp15RA9bod+EHYXdxvWTkPfylrS rlbKOaL4eetED7tiaILEk5Av9mcUJlpT/Uzxp5qfGstTwNSs8xZNUTcezfQU/75+mgOB RA57lGLSe7DOSi8/YEfr/vwPMqU3jYbbN5wg6YMvLlG3a56BtW1rscUX1Z45MEHeJnPO WunVOfpnWKLtC9U64OHVHdvSQmInivcWEXFQTswevx7DVqZ5M4jf281MPE5ZeY6l4Ao4 rSyw==
X-Received: by 10.68.11.35 with SMTP id n3mr32718143pbb.220.1364440162434; Wed, 27 Mar 2013 20:09:22 -0700 (PDT)
Received: from [192.168.0.104] (ppp-115-87-74-30.revip4.asianet.co.th. [115.87.74.30]) by mx.google.com with ESMTPS id ef3sm25696779pad.20.2013.03.27.20.09.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 20:09:20 -0700 (PDT)
Message-ID: <5153B45B.5060600@gmail.com>
Date: Thu, 28 Mar 2013 10:09:15 +0700
From: Glen Zorn 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130317 Thunderbird/17.0.4
MIME-Version: 1.0
To: lionel.morand@orange.com
References:  <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Mar 2013 03:09:23 -0000

On 03/27/2013 09:55 PM, lionel.morand@orange.com wrote:
>
> Hi,
>
> Following the discussion in the meeting, here is my interpretation.
>
> I said during the meeting that a new application will only be able to 
> go through existing relay and redirect agent and not through "legacy" 
> proxies i.e. proxies not supporting/advertising the new application.
>

OK, but this is not different from any other new application, right?  
So, if the only route to a given destination realm is through a proxy, 
either the proxy must be updated to support the app or the application 
will fail.  That behavior seems fine to me: proxy application support 
(or non-support) is an administrative decision. If a transited realm 
doesn't want to carry the traffic generated by an application (perhaps, 
in this case, because the administrators are unconvinced that the 
solution to signaling overload is more signaling), I think that it is 
inappropriate to attempt to force it to do so.

> So the question is simple: in the requirement elaboration phase, are 
> we sure that any solution based on a new App-id will be rejected?
>

Do you mean rejected by the WG?

> If not: the "SHOULD" is meaningful in REQ35.
>
> If yes: this is a strong requirement and this must be stated somewhere 
> in the draft.
>
> Lionel
>
> *De :*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *De la part 
> de* Ben Campbell
> *Envoyé :* mardi 26 mars 2013 21:31
> *À :* dime@ietf.org
> *Objet :* [Dime] Proposed REQ 35 Text
>
> Hi,
>
> We had a discussion about whether REQ 35 in the 
> draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST. 
>  We further discussed that any use of a MUST here would require some 
> caveats about what sort of intermediaries could be traversed, and the 
> potential security issues. The chairs directed us to take the 
> discussion to the list due to time constraints. Here's my attempt to 
> do so.
>
> For reference, here's the original text:
>
>     The mechanism SHOULD provide a method for exchanging overload and
>     load information between elements that are connected by
>     intermediaries that do not support the mechanism.
>
> Here's a proposed alternative for changing it to a MUST:
>
>     The mechanism MUST provide a method for exchanging overload and
>     load information between elements that are connected by
>     intermediaries that do not support the mechanism. The mechanism
>     MAY place limitations on the nature of the non-supporting
>     intermediaries that may be traversed.
>
>         Nothing in this requirement should be construed to relax the
>         security-related requirements elsewhere in this document, in
>         particular REQs 28, 30, and 31. Maliciously constructed
>         overload information can potentially shut down a Diameter
>         network; it's critical that a node be able to confirm that
>         received information came unaltered from an authorized source,
>         whether the information comes from an immediate peer or
>         crosses an intermediary.
>
> Which general approach do people prefer? I kept the security aspects 
> non-normative, since normative text already exists in 28,30, and 31.
>
> Thanks!
>
> Ben.
>
> _________________________________________________________________________________________________________________________
>
> 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,
> France Telecom - 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, France Telecom - 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 lionel.morand@orange.com  Thu Mar 28 02:28:43 2013
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 5467D21F90B2 for ; Thu, 28 Mar 2013 02:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rda523jvwseY for ; Thu, 28 Mar 2013 02:28:42 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3969921F9063 for ; Thu, 28 Mar 2013 02:28:42 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 333212DC4E9; Thu, 28 Mar 2013 10:28:41 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0B83F4C015; Thu, 28 Mar 2013 10:28:41 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 28 Mar 2013 10:28:40 +0100
From: 
To: Glen Zorn 
Thread-Topic: [Dime] Proposed REQ 35 Text
Thread-Index: AQHOK2GgwGrm0hvPTESdb4ZLexiCLJi608CA
Date: Thu, 28 Mar 2013 09:28:39 +0000
Message-ID: <25026_1364462921_51540D49_25026_227_1_6B7134B31289DC4FAF731D844122B36E187F54@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References:  <15534_1364396113_51530851_15534_5884_1_6B7134B31289DC4FAF731D844122B36E18562C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5153B45B.5060600@gmail.com>
In-Reply-To: <5153B45B.5060600@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Mar 2013 09:28:43 -0000

Hi Glen,

Please see below.

Regards,

Lionel

-----Message d'origine-----
De=A0: Glen Zorn [mailto:glenzorn@gmail.com]=20
Envoy=E9=A0: jeudi 28 mars 2013 04:09
=C0=A0: MORAND Lionel OLNC/OLN
Cc=A0: Ben Campbell; dime@ietf.org; glenzorn@gmail.com
Objet=A0: Re: [Dime] Proposed REQ 35 Text

On 03/27/2013 09:55 PM, lionel.morand@orange.com wrote:
>
> Hi,
>
> Following the discussion in the meeting, here is my interpretation.
>
> I said during the meeting that a new application will only be able to=20
> go through existing relay and redirect agent and not through "legacy"=20
> proxies i.e. proxies not supporting/advertising the new application.
>

OK, but this is not different from any other new application, right?=20=20
So, if the only route to a given destination realm is through a proxy,=20
either the proxy must be updated to support the app or the application=20
will fail.  That behavior seems fine to me: proxy application support=20
(or non-support) is an administrative decision.=20

[LM] I'm fine with that also. And it means that a solution based on a new a=
pp-id would fail to meet the REQ35 containing a "MUST". And I'm not sure if=
 it is really what we want at this stage.

If a transited realm=20
doesn't want to carry the traffic generated by an application (perhaps,=20
in this case, because the administrators are unconvinced that the=20
solution to signaling overload is more signaling), I think that it is=20
inappropriate to attempt to force it to do so.

[LM] Right!

> So the question is simple: in the requirement elaboration phase, are=20
> we sure that any solution based on a new App-id will be rejected?
>

Do you mean rejected by the WG?

[LM] Yes!

> If not: the "SHOULD" is meaningful in REQ35.
>
> If yes: this is a strong requirement and this must be stated somewhere=20
> in the draft.
>
> Lionel
>
> *De :*dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *De la part=20
> de* Ben Campbell
> *Envoy=E9 :* mardi 26 mars 2013 21:31
> *=C0 :* dime@ietf.org
> *Objet :* [Dime] Proposed REQ 35 Text
>
> Hi,
>
> We had a discussion about whether REQ 35 in the=20
> draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST.=20
>  We further discussed that any use of a MUST here would require some=20
> caveats about what sort of intermediaries could be traversed, and the=20
> potential security issues. The chairs directed us to take the=20
> discussion to the list due to time constraints. Here's my attempt to=20
> do so.
>
> For reference, here's the original text:
>
>     The mechanism SHOULD provide a method for exchanging overload and
>     load information between elements that are connected by
>     intermediaries that do not support the mechanism.
>
> Here's a proposed alternative for changing it to a MUST:
>
>     The mechanism MUST provide a method for exchanging overload and
>     load information between elements that are connected by
>     intermediaries that do not support the mechanism. The mechanism
>     MAY place limitations on the nature of the non-supporting
>     intermediaries that may be traversed.
>
>         Nothing in this requirement should be construed to relax the
>         security-related requirements elsewhere in this document, in
>         particular REQs 28, 30, and 31. Maliciously constructed
>         overload information can potentially shut down a Diameter
>         network; it's critical that a node be able to confirm that
>         received information came unaltered from an authorized source,
>         whether the information comes from an immediate peer or
>         crosses an intermediary.
>
> Which general approach do people prefer? I kept the security aspects=20
> non-normative, since normative text already exists in 28,30, and 31.
>
> Thanks!
>
> Ben.
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu 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,
> France Telecom - Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation 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, France Telecom - Orange is not liable for messa=
ges that have been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> 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,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, 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, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.


From lists.abooth@gmail.com  Thu Mar 28 12:18:56 2013
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 60E1121F9049 for ; Thu, 28 Mar 2013 12:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIbmwC2AJZdh for ; Thu, 28 Mar 2013 12:18:55 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF821F9042 for ; Thu, 28 Mar 2013 12:18:54 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id bv4so72835qab.16 for ; Thu, 28 Mar 2013 12:18:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=lWeYaEj8x4kMhgxMQhK/HXe5d3wZ2/QzrsCUp9VDQOA=; b=p6rbQCbGdQ0S3NMadehe8xtSWjl25fvQtJYwyOUr6DJlD5jpN+02nKDJ2zbrBkrpmC G+KnK30wCGChg/jtrazSwF+mC8CvZ7XK9mSWZP7vTM6Yb1X8NfN8g9UvZBL6NlWIBqK3 hKQb9tpSpxvCyM7QObBunq5POxCtbUfkqtB3bMHAAEKUdPaMy8qPslUjqXQYXsgzyH5Z rPDy+KL8qlUCriTi6HPU1BsiLk5jgVVo3LK6HCiaL798ea+IX6r3VmHvf0qjJ5mC7B+8 0F8KRD2jfwTpDnXn2sCrvlb7BH+oL9wXXm4ox1PZ9rqk2TOMnqdWt2+jgOgzEkg21ifG 8iqg==
MIME-Version: 1.0
X-Received: by 10.224.117.72 with SMTP id p8mr627345qaq.5.1364498334418; Thu, 28 Mar 2013 12:18:54 -0700 (PDT)
Received: by 10.49.63.163 with HTTP; Thu, 28 Mar 2013 12:18:54 -0700 (PDT)
In-Reply-To: 
References:   
Date: Thu, 28 Mar 2013 15:18:54 -0400
Message-ID: 
From: Andrew Booth 
To: Ben Campbell 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Proposed REQ 35 Text
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Mar 2013 19:18:56 -0000

Hi Ben,

Thanks for the comments and clarifications.

I'm still a little uncomfortable with the idea that a MUST is just a
strong SHOULD, but I'll extrapolate from your comments: no matter
whether we put SHOULD or MUST, the working group can override it
anyway, so maybe it doesn't make much difference as long as the intent
is clear.

So the remaining comment is one more try at improved clarity.

I'm not sure that a MUST with an open ended limitation (without any
guidance on why that limitation is there) is any clearer than an
unqualified SHOULD.
So, if the idea is that the working groups work isn't done until REQ
35 is solved, but that some parts of the solution might require extra
work (e2e or some other idea), or could maybe even be deferred,
perhaps it is clearer to simply make that objective explicit?

For your consideration:

   ALT REQ 35:  The mechanism SHOULD provide a method for exchanging
            overload and load information between elements that are
            connected by intermediaries that do not support the
            mechanism.
            If a mechanism cannot immediately meet this requirement for
            technical reasons, or because the full solution depends on an
            unfinished prerequisite work, then the mechanism MUST
            describe its limitations related to this requirement and
the technical
            reasons why it was unable to meet this requirement fully.
            If the mechanism has substantial limitations with respect
to this requirement,
            it should convincingly describes why it should be possible
for the mechanism
            to operate in parallel with some future mechanism that complete=
ly
            meets this requirement, and the remaining work SHOULD be schedu=
led.

Thoughts?
Andrew


On Wed, Mar 27, 2013 at 2:13 PM, Ben Campbell  wrote:
> Hi. Comments inline:
>
> On Mar 27, 2013, at 10:01 AM, Andrew Booth  wrote=
:
>
>> Hi Ben,
>>
>> If we don't find a solution that supports REQ 35, I would prefer to
>> have a 95% solution now than scrap such a solution because it fails
>> the MUST of REQ 35.  Hence, I prefer that REQ 35 be a SHOULD.
>>
>
> I don't think that means we have to scrap a 95% solution. (Unless we have=
 an alternate 100% solution, in which case a SHOULD and MUST would would ha=
ve the same effect.)
>
> My personal opinion would be that a MUST means the working group's job is=
n't done until it either meets the requirement, or determines that the requ=
irement was not reasonably feasible. The former could be accomplished with =
a 100% solution, or a 95% solution with an additional mechanism designed to=
 solve just this requirement. In the same circumstances, a SHOULD would mak=
e it easier to just take the 95% solution and stop.
>
>> There is nothing to prevent multiple different implementations from
>> being standardized (well, other than the difficulty getting WG
>> cycles).  I don't see that all of them need to have full support for
>> REQ 35.  That opens the door for other approaches to be proposed once
>> end-to-end security in Diameter is standardized.
>
> Agreed. The "not reasonably feasible" bit in my previous comment could al=
so mean "not reasonably feasible _now_". As a purely hypothetical example, =
if the security issues turn out to be the main thing to block Req 34, iIt m=
ight make sense to make sure the chosen solution doesn't prevent Req 35 fro=
m being solved in some future update once the e2e security work is complete=
, or at least stabile.
>
>>
>> There is also nothing that prevents interested parties that want
>> support for REQ 35 to propose a solution that supports it, and to
>> defend that solution compared to others.
>>
>> If I recall correctly, the desire to make this a MUST came from an
>> implementer that wanted to be able to signal handsets about the
>> congestion.  Is that the motivating statement?  If so, is it worth
>> taking a closer look at the motivating case to see what information
>> they really require (is it full information? or will partial
>> information do?), and whether it should have this much impact on the
>> potential solutions?
>> At first glance, signaling handsets about congestion sounds like a
>> (potentially useful) optimization, but does not sound to me as
>> important as protecting core network resources (by having some working
>> implementation of overload control).  Maybe I'm misunderstanding the
>> motivating case or it's importance, I'm willing to be convinced.
>
> I don't think that's the main case. The use case I think the most people =
care about is the situation where you have a non-supporting agent between i=
slands of overload-control. For example, an IPX provider sitting between op=
erators doesn't support overload control, but the operators still need to s=
hare overload information.
>
> There are certainly people that care about the use case you describe--but=
 I think any solution to that use case would also solve the one you mention=
. It's the special case where _none_ of the agents support overload control=
.
>
>
> [...]
>
>>>
>>>
>>> Here's a proposed alternative for changing it to a MUST:
>>>
>>> The mechanism MUST provide a method for exchanging overload and load
>>> information between elements that are connected by intermediaries that =
do
>>> not support the mechanism. The mechanism MAY place limitations on the n=
ature
>>> of the non-supporting intermediaries that may be traversed.
>>
>> Is there any limit to the limitations?  Currently loophole: a
>> mechanism can limit the non-supporting intermediaries to the empty
>> set, and we're back to REQ 35 being a SHOULD.
>> Is this extra text intended to allow for a new application id (hence
>> limiting proxies that have not been upgraded to support the
>> mechanism)?
>
> I think the "limitation" is an assumption of reasonable behavior on the p=
art of the working group :-) This isn't a contract; it's a general agreemen=
t as to what we are working on.  Creating limitations rule out all possible=
 intermediaries would not fit my idea of a reasonable interpretation. In ge=
neral, making "letter of the rule" interpretations that don't fit the clear=
 "spirit of the rule" doesn't seem like reasonable working group behavior.
>
> The sort of limitations we are likely to run up against are things like "=
 can't cross a agent that does topology hiding". The reason we don't enumer=
ate the limitations now is because we won't know what they are until we do =
the actual mechanism engineering. I could _hypothetically_ imagine things l=
ike "can't cross an agent that uses dynamic peer discovery" might pop up.
>
>> Is this extra text intended to allow for REQ 35 through "trusted"
>> intermediaries, hence working around the end-to-end security
>> requirement (this sounds dodgy to me)?
>
> I assume you are talking about the "nothing in this requirement..." parag=
raph. That's indented to show that it is intended as explanatory text, not =
normative text. The idea is not to allow or prohibit any particular securit=
y approach in advance, and to point out that accepting unauthenticated/unau=
thorized congestion information would violate the existing requirements abo=
ut not adding new vulnerabilities.
>
> It's up to the working group to decide what security approach is "good en=
ough". I personally have my doubts that simply assuming intermediaries are =
"trusted" is an adequate approach--but I'm happy to defer that argument for=
 now. (I know there are strong opinions on both sides) We might end up requ=
iring the e2e security work. We might end up with some other special-purpos=
e authz/n solution no one has thought of yet.
>
>>
>> Thanks,
>> Andrew
>>
>>>
>>> Nothing in this requirement should be construed to relax the
>>> security-related requirements elsewhere in this document, in particular=
 REQs
>>> 28, 30, and 31. Maliciously constructed overload information can potent=
ially
>>> shut down a Diameter network; it's critical that a node be able to conf=
irm
>>> that received information came unaltered from an authorized source, whe=
ther
>>> the information comes from an immediate peer or crosses an intermediary=
.
>>>
>