From nobody Mon Sep 1 14:22:03 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6691A0747 for ; Mon, 1 Sep 2014 14:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8K4BSOGi3eU for ; Mon, 1 Sep 2014 14:21:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4FD1A0720 for ; Mon, 1 Sep 2014 14:21:57 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-0e-5404e3733878 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.BF.24955.373E4045; Mon, 1 Sep 2014 23:21:55 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Mon, 1 Sep 2014 23:21:54 +0200 From: Maria Cruz Bartolome To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposal for new error response for DOIC Thread-Index: AQHPwtSNjh3ll5xznUGPsoYqOjvLWZvmTVCAgADJk4CAAAr1AIAFqoVQ Date: Mon, 1 Sep 2014 21:21:53 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980ECBA@ESESSMB101.ericsson.se> References: <53FF4A17.9050707@usdonovans.com> <95D175DE-C80C-4690-95D8-14ABC6393A38@nostrum.com> 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.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rrf4MUuIQdc5KYv5nafZLeb2rmCz 2HR+HYvFhiYeBxaP1md7WT2WLPnJ5DFr5xMWj1Vv+1gDWKK4bFJSczLLUov07RK4MpbfaWMt mO1S0b9lInMD4z+zLkZODgkBE4mnuw6yQ9hiEhfurWfrYuTiEBI4yiixv2cDlLOYUeLX6qdM IFVsAnYSl06/YAJJiAgsYpQ4e20PM0iCWUBZYvaOB2CjhAVsJN4dng5kcwAV2Uq07cuBMN0k Frc7glSwCKhInHmynAXE5hXwlVj+dTsLxK4OJom/V4+xgiQ4BWIl5vT2g41kBLru+6k1TBCr xCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC2EoSaw9vZ4Go15O4MXUKG4StLbFs4WtmiMWCEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwDg7uOW3 6g7Gy28cDzEKcDAq8fA+mMUcIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGN0aGn+Lac1ZptKom3eCd8Ptz9M8r8YoWp9TPvDlQFaCVU9TpP6WL+5v5PI0 VxZefXDYym6B/4ZDU2fMFi1mOLX+mc59Hv4PfLttX7/TWainuVCK5erCabm/ogx3CtVO+3bX wTBov0arzI+rVfdFYnebx55ynn5D8mzdhcZFFlKmQXq2p689FldiKc5INNRiLipOBACd3coB lAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9be75L6UcQTtXVtMSOSpmSzF1DA Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Sep 2014 21:22:01 -0000 Dear JJ, all, My understanding is that "alternate peer" in the TOO_BUSY description is in= terpreted as either a new destination_host, or a new server that provides s= ervice to the same realm. Then, I think that already the standardized behavior for a reacting node wh= en it receives TOO_BUSY may be enough. It is not explicitly mentioned that = retransmissions to the same "peer" should be avoid, but a different action = is requested.=20 Therefore, I am not sure we really need to define a new error, just to requ= est the reacting node to throttle if required, since in my opinion this is = already implied by TOO_BUSY description by "SHOULD". If this attempt is not= possible or not successful (for any reason), then reacting node will throt= tle this request. As a conclusion, in my opinion, we do not need a new error. If you do not a= gree nowadays TOO_BUSY description is enough we could extend/clarify this d= escription, either updating RFC or with new additional guidelines.=20 Apart from that, take into account TOO_BUSY is already an indication of ove= rload, and this is part of the main RFC, then if we need this requires some= clarification, I think this should not be constraint to the new DOIC draft= . Cheers /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: viernes, 29 de agosto de 2014 10:38 To: Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposal for new error response for DOIC To come back on my point 2) , and reviewing the definition of Diameter too = busy in RFC 6733.=20 DIAMETER_TOO_BUSY 3004 When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service Does it mean that the request is sent to the same specific server but via a= n alternate path (the request contains the same Realm and host destinations= AVP but is sent to another peer (another DA) , or can the alternate peer c= orresponds to another server (so another destination host). According to th= e understanding, this impacts my Point 2) remarks Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: vendredi 29 ao=FBt 2014 09:59 =C0=A0: Ben C= ampbell; Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Proposal f= or new error response for DOIC Dear all A few remarks 1) I am also questioning about the backward compatibility case where a DA = is acting on behalf of a non DOIC client. The solution Steve proposes , to my view, also work in this case: if the = DA throttles a request, it will generate a Diameter too busy to the client,= so with the possible consequence that the non DOIC client do a retry to an= alternate destination. But we cannot avoid it, this is the non DOIC clien= t existing behavior. In any case we should avoid to send a new Diameter error to a non DOIC clie= nt as it can result to a non predictable behavior.=20 Among the possible solutions, one is to continue to use Diameter to busy in= all cases but with, in addition, a new AVP (a "DOIC diagnostic" AVP) whi= ch means message throttled in a DOIC case, which is generated by the DOIC r= eporting node, supported by a DOIC reacting node (which will not do retry t= o another destination) and ignored by a non DOIC client. This AVP may be = in the future take other values if needed. =20 2) some remark about the new retry. - I think a DA can do a retry in the case it has received a realm only requ= est (without destination host), and if not successful, will sent the new di= ameter error to the client. But if instead, the client had received a clas= sical Diameter too busy, it will also not do a retry to another destination= (as it only knows the realm, but not the server), so Diameter too busy see= ms here acceptable, isn't it? - If the client has sent a request with a Destination host, which is reject= ed by the reporting node (so with the new Diameter error) I do not think th= at a DA can do a retry to another destination host (as the client has reque= sted a specific Destination host). Am I wrong here? But the client may even= tually do a retry towards another destination host, according to the applic= ation case, so not so in line with the meaning of the new Diameter error re= questing no retry. - a server rejecting a request, will generate the new Diameter error, but t= he intermediate DA receiving this error may nevertheless do a retry to ano= ther destination a retry, so the meaning of the new Diameter error does not= always mean "no retry" for a reacting node.=20 To have your view on these remarks. =20 Best raegrds. JJacques =20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy= =E9=A0: jeudi 28 ao=FBt 2014 21:57 =C0=A0: Steve Donovan Cc=A0: dime@ietf.o= rg Objet=A0: Re: [Dime] Proposal for new error response for DOIC I agree with doing this.=20 But I'm also concerned that the backwards compatibility issue you mention m= eans that this doesn't help in what is potentially the biggest use case for= throttling at an agent. that is, an agent throttling on behalf of a non-su= pporting client. One approach would be to define DIAMETER_THROTTLED in a separate update to = RFC 6733, in hopes that people who aren't ready to fully support DOIC might= at least support the new error. (Yeah, I know that's a long shot.) Another= might be to write some additional (BCP?) guidance on how clients should ha= ndle TOO_BUSY.=20 On Aug 28, 2014, at 10:26 AM, Steve Donovan wrot= e: > All, >=20 > One of the open issues is the DOIC behavior when a DOIC node rejects a re= quest as a result of an overload condition. >=20 > Today, the logical error response would be the DIAMETER_TOO_BUSY response= . The issue with this behavior is that it can result in the client retryin= g the request to an alternative peer. >=20 > The desired behavior for a request rejected because of overload throttlin= g is the same as if the client, acting as a reacting node, throttled the re= quest. As a result, the transaction should not be retried. >=20 > The proposal is to define a new protocol error response code called DIAME= TER_THROTTLED with the defined behavior that the request SHOULD be treated = as a final response and SHOULD NOT be retried. >=20 > This error response could be generated by agents acting as reacting nodes= or by any reporting node. A server, for instance, that is in a severe ove= rload condition might chose to reject some transactions with the DIAMETER_T= HROTTLED response if the current requested reduction included in the overlo= ad report is not sufficient. >=20 > One issue with this proposal is backwards compatibility with Diameter nod= es that do not support DOIC and, as such, would not understand the DIAMETER= _THROTTLED response. The proposal to address this is to make the generatio= n of the DIAMETER_THROTTLED error response conditional. This is an attempt= at wording this conditional behavior: >=20 > A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transact= ions that are throttled and the DOIC node knows that there is a DOIC reacti= ng node able to process the error response. The DOIC node generating the D= IAMETER_THROTTLED error response determines that there there is a DOIC reac= ting node by the presence or absence of an OC-Supported-Features AVP in the= request message for the transaction. >=20 > If there is no OC-Supported-Features AVP in the request message for a tra= nsaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_B= USY response message. >=20 > Assuming we get agreement on the proposal then I'll come back with detail= ed wording proposals for the DOIC specification. >=20 > Regards, >=20 > Steve >=20 >=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 nobody Mon Sep 1 15:09:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3101E1A0AEA for ; Mon, 1 Sep 2014 15:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doQecgeRQ-NQ for ; Mon, 1 Sep 2014 15:09:34 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9251A0AE5 for ; Mon, 1 Sep 2014 15:09:32 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-5a-5404ee9a983d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 01.93.21334.A9EE4045; Tue, 2 Sep 2014 00:09:30 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 00:09:30 +0200 From: Maria Cruz Bartolome To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "Nirav Salot (nsalot)" , Steve Donovan , "lionel.morand@orange.com" , Ben Campbell Thread-Topic: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis Thread-Index: AQHPsxfWEHmN9pZYckS/sFZJieII0JvG6XMAgAZgQ4CACY6AgIAAPbkAgACH5ACAAB9hgIAAIXaAgAASEwCAAAuVgIAA+gAAgACf7oCAAAGAgIAAB1KAgAAE3ICAAX5PgIAAFb2AgAq2D2CABw4ksA== Date: Mon, 1 Sep 2014 22:09:29 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980ECD2@ESESSMB101.ericsson.se> References: <53E4E339.1070106@usdonovans.com> <7F668A4D-BE76-4A8D-96B2-789F13886AC4@nostrum.com> <53EA7373.90404@usdonovans.com> <53F277B9.1060509@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> <53F610D1.4070007@usdonovans.com> 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.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+Jvje6sdywhBo93WljM7zzNbjG3dwWb xabz61gsbm/PtHi2KsViQxOPA5tH67O9rB5Tfm9k9Viy5CeTx6ydT1g8Wp6dZPNY9baPNYAt issmJTUnsyy1SN8ugStj9ZJT7AWLPjJWdH26ztrAeOUIYxcjJ4eEgInE9F9r2SBsMYkL99YD 2VwcQgJHGSX2v5vLDpIQEljMKPH4VCmIzSZgJ3Hp9AsmkCIRgQ4mie+7/4J1MwsoS8ze8QCs QVjAR2L63P/MILaIgK/EzV+r2CEaljFK/Ju/iRUkwSKgInHl9UKwM3iBir5caGCBWP2AQ2LJ i8dgCU6BWImPqxaDbWAEuu/7qTVMENvEJW49mc8EcbeAxJI955khbFGJl4//sULYShJrD29n gajXk7gxdQrUpdoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi0uzk03 MtZLLcpMLi7Oz9PLSy3ZxAiMyYNbfuvuYFz92vEQowAHoxIP74NZzCFCrIllxZW5hxilOViU xHkXnZsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR9OFZ9ncv+Fi79oTeX/3XV70ncq/M /TCWhLkf3Z8/+7a8rv3lV6famYpmsVr9zqwvnsyzXlO2Y4qlMaNtUvufTua7KvnuWSvvCuc2 M0kwnPx0/HdOfqVB4kWXJU7iDh9Fm6VWa393Cltd9C/u6obaXVtiP24WzA9c7366OiDbprxW j9W64ZISS3FGoqEWc1FxIgDcQ2c4qgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vMaclS2iyK63w-bR29tqTuGsgXE Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 01 Sep 2014 22:09:38 -0000 Dear all, I share the view presented by Lionel, Nirav, and JJ. Cheers /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: jueves, 28 de agosto de 2014 12:26 To: Nirav Salot (nsalot); Steve Donovan; lionel.morand@orange.com; Ben Camp= bell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Dear all A long email thread on this topology hiding topic. I Would like to come ba= ck on the use cases. In the thread, two use cases were mentioned, are there others? - the SFE case, where a DA in front of a set of servers presents this set o= f servers as one Diameter node with a unique Diameter Host identity. The re= acting nodes only know this Diameter Host identity for their host requests.= Regarding DOIC, as the SFE objective is to present the group of servers as= one Diameter node it should apply to DOIC, meaning the DA aggregates the d= ifferent OLRs received from servers to build the OLR associated to the uniq= ue Diameter Host identity. Otherwise this Diameter node will send inconsi= stent OLRs, and then we try to find a solution requesting the reacting node= s, that may be in external networks to solve this DOIC issue internal to t= he servers and their SFE. Lionel did such a remark in his 19/08 mail " a= agent modifying the Origin-host can only be a proxy and a proxy is by defi= nition compliant with the application supporting the new OLR-related AVPs" = on which I agree. Furthermore the Steve's proposed solution would introduce a non consistent = behavior from the reacting node regarding traffic reduction. =20 - the external network case where the DA of the servers network interfacin= g external networks is doing topology hiding to present the servers as a u= nique Diameter node to external networks . I have the same remark as for SF= E, where the proposed solution will request the external network to solve t= he issue of the non DOIC DEA. There is also the case where the DEA modifies the Origin-Host but on a 1 t= o 1 basis, so allocating a different Origin-host identity for each server. = In this case, the DOIC works well without changes. The proposed solution w= ill, I think, here create mismatches, which do not exist.=20 I share the comments from several of us, to not consider this case as an ac= tual one to solve. If a DA presents a set of servers as a unique Diameter H= ost, either this overall entity (servers+DA) supports DOIC and behaves as a= reporting node towards reacting nodes or it does not. If it does not, no = OC-Supported-feature AVP should be sent by this entity in answers to reacti= ng nodes, that I think can be achieved.=20 Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) Envoy=E9=A0: jeudi 21 ao=FBt 2014 18:49 =C0=A0: Steve Donovan; lionel.morand@orange.com; Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analys= is Steve, SRD> Which is worse, an operator not being able to turn on DOIC because of other operators or breaking topology hiding? I don't know the answer bu= t I do think it is a decision that should be made by the operator. I am not sure why should operator A not turn on DOIC feature in its own net= work just because of operator B/C/D does not support it. This is handled in the same way as operator A and B support the feature but= have no agreement to share the overload report. And hence based on configu= ration host in operator A's network ensures that messages going to operator= B does not contain overload report. Regards, Nirav.=20 -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Thursday, August 21, 2014 9:01 PM To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell Cc: dime@ietf.org Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysi= s Nirav, Thanks for the detailed response. Please see my responses inline. Steve On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote: > Steve, > > You are proposing a change (minor or not) for a problem which does not=20 > exist (in my view at least) since the use case is > - The operator has enabled overload feature in his network and has not=20 > upgraded one of the proxy > - The operator has "forgotten" that the proxy which is not upgraded is=20 > doing topology hiding SRD> It's not just about topology hiding. It's about anything that requires changing the origin-host. > > Or between two operators, they have entered into the agreement to share t= he overload reports but have not bothered to upgrade all of their nodes and= not done any basic testing before activating the overload feature. SRD> I don't think we want to get into the situation where Operator A=20 has to wait to turn on overload control because Operator B has not yet=20 upgraded their network to support DOIC. > > So we are defining the solution for the above use cases. And the solution= you are suggesting it results in > - The client ignoring the overload report and thus the operator finds out= that "he has forgotten to upgrade one of the proxy (which is doing topolog= y hiding) with the overload feature". SRD> I'm saying that in the real world strange things happen. Solution 1=20 mitigates the effect of mistakes being made. SRD> I'm not saying the client ignores the overload report. That is=20 clearly one option. I have suggested the behavior be up to local=20 policy. I see four options, others may see others: 1) Always ignore the overload report 2) Always honor the overload report 3) Conditionally honor the overload report -- Honor anything up to some=20 percentage 4) Adjusted percentage - learn the number of servers that exist behind=20 the OHMA and adjust the reduction percentage accordingly. > > Additionally, the solution breaks topology hiding feature itself and your= justification is that "we haven't agreed requirement to not break this fea= ture!". SRD> As pointed out by Dave, there are likely modifications to solution=20 1 that does not break topology hiding, if we think it is a requirement=20 to avoid that breakage. SRD> Which is worse, an operator not being able to turn on DOIC because=20 of other operators or breaking topology hiding? I don't know the answer=20 but I do think it is a decision that should be made by the operator. > > I am sorry, but I don't see why we need any protocol based solution here. SRD> This is where the difference of opinion exists. You are of the=20 opinion that operators never make mistakes and, as a result, we don't=20 need a protocol based solution. I am of the opinion that in the real=20 world strange things happen and a little bit of extra resiliency in the=20 protocol is a good thing. > It is simple matter operator knowing its network/deployment/nodes and exi= sting features and enabling new feature based on "this" knowledge. And doin= g some basic testing/dry run before going live. > 3GPP or IETF, if we start defining solution assuming that "but the operat= or may have forgotten to do this or that", we are adding solutions in our p= roduct which are simply overhead. > > Finally, we should be looking at the justification to have some solution = and not add some change just because it is minor. SRD> No one is making that argument. I have articulated the=20 justification. I also pointed out that the cost of the solution is very=20 small. Cost benefit analysis is a valid aspect of any design process. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, August 20, 2014 9:56 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analy= sis > > Nirav, > > Can you please be more specific about which of the explanations you don't= agree with? > > I agree we can't completely ignore the way that Diameter is being used. > > We should also be avoiding a solution that leaves open the possibility of= significant under utilization of Diameter network resources. We have a st= ated requirement that the solution must not result in under utilization. > > I must admit I'm surprised at the response the proposal is getting. It is= a very minor change that makes the protocol more resilient. > > Steve > > On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: >> Steve, >> >> I don't agree with your explanations. >> >> Additionally, we may not have explicit requirement to make DOIC work in = the face of topology hiding but that does not mean that "DOIC can break any= existing feature - be it topology hiding - and that's fine!". >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 20, 2014 9:24 PM >> To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >> analysis >> >> Nirav, >> >> Please see my comments inline. >> >> Steve >> >> On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >>> I agree with Lionel on multiple accounts. >>> I don't see any value in alternative 1. In fact, as I had already indic= ated, the alternative 1 breaks one or more of existing feature and hence it= is not a solution by itself. >> SRD> The value is that, through a protocol solution, we can make it >> possible to prevent a complete shutdown of all traffic through a OHMA. >> It might be a small probability, but it is > 0, the impact is significan= t and the cost of the proposed protocol solution is extremely small. >> >> SRD> I'm assuming that the breakage you are talking about is that the >> proposal does allow for topology information to leak across operator bou= ndaries. This is true, however, we do not, however, have a requirement to = make DOIC work in the face of topology hiding. Are there other existing fe= atures that you are concerned about? >>> Additionally, like any other feature, the operator does not simply enab= le this feature in their network without considerable planning, lab and fie= ld testing. And this is true for between two operators as well - where the = bigger issue is whether to expose the overload information between two PLMN= s or not. >> SRD> We are designing DOIC for Diameter usage in general, not just >> 3GPP. I agree that this scenario is unlikely in a 3GPP environment, at = least for well disciplined operators that have extensive testing as you poi= nt out. I don't, however, think we can make that assumption across all use= s of Diameter. That's one of the reasons why we have requirements stating = that the solution should not rely on configuration. >>> So I don't see the need to have protocol based solution to help operato= r debug "what they have forgotten about their network". >> SRD> As has been pointed out multiple times, this is not just about >> SRD> the >> operator's own network. The negative impacts can result from another op= erator not upgrading their agents to support DOIC. >> >> SRD> I look at this as a low cost insurance policy. It doesn't hurt >> anything to add this small change and it helps prevent would could be a = major outage. >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>> lionel.morand@orange.com >>> Sent: Tuesday, August 19, 2014 8:57 PM >>> To: Steve Donovan; Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >>> analysis >>> >>> Hi Steve, >>> >>> If you decide to deploy a proxy modifying the origin-host, it would be = for some specific purposes in a given context. If the context has changed, = you will have to reconsider the whole mechanism. And it is not only related= to DOIC. >>> If not done, this is what I'm calling a bad design: it is not only abou= t the implementation of the product itself, it is also about how this produ= ct is used in the operational network. >>> And I don't buy the argument that an operator might have forgotten that= a proxy modifying origin-host would have been deployed in the network befo= re the introduction of DOIC. >>> >>> About alt 1: >>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the O= C-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR r= eport when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When ther= e is a difference, the reacting node should report on the condition (event/= alarm). Local policy would determine if the reacting node honors the overl= oad report or ignores the overload report. >>> The following question still remain not answered: if the proxy replaces= the origin-host A by origin-host B, the Diameter nodes receiving the answe= rs will "see" B as sender of the answer and will use this id when sending n= ew requests with origin-host AVP. So can you remind me how exactly the reac= ting node will use the Diameter-id received in the OLR? >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>> 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>> alternatives analysis >>> >>> Lionel, >>> >>> More inline. >>> >>> Steve >>> >>> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> See below. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mardi >>>> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> Lionel, >>>> >>>> There are two primary reasons that I think option 1 is important: >>>> >>>> 1) This scenario can result in significant under utilization of resour= ces, to the extreme of completely shutting down all traffic to the servers = behind the Origin-Host Munging Agent (OHMA). >>>> >>>> 2) It gives operates a way to detect the unplanned or forgotten instan= ce of the OHMA. >>>> >>>> Being able to prevent number 1 is enough reason for me to add the very= small amount of additional protocol machinery we are talking about. >>>> >>>> [LM] And I disagree. >>>> >>>> More inline. >>>> [LM] same >>>> >>>> Steve >>>> >>>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>>> Because a a gent modifying the Origin-host can only be a proxy and a = proxy is by definition compliant with the application supporting the new OL= R-related AVPs, everything else is out of scope of the standardization. >>>> SRD> I don't understand this argument. It is perfectly valid for a >>>> client or server to advertise support for an application and not also = support DOIC. Why do you imply that it would be different for an agent? >>>> [LM] A proxy that would modify the origin-host without taking into acc= ount the possible use of this origin-host at the application would be a bad= ly-designed proxy and should not be used in operational network. >>> SRD2> Consider the following timeline: >>> >>> Date - Event: >>> >>> Sometime in 2011 - Operator installs an agent to do topology hiding or = load balancing or some other function and the agent modifies the origin-hos= t AVP as part of its logic. In 2011 this works perfectly well for all appl= ications handled by the agent. >>> >>> Sometime in 2015 - The IETF publishes the DOIC specification. >>> >>> Are you asserting that the agent deployed in 2011 was badly designed be= cause it did not anticipate the DOIC solution published four years later? >>>>> Moreover, the real added-value of the addition of the diameter-id in = the OLR does not seem so clear. >>>> SRD> See above. >>>> [LM] still unclear >>> SRD2> Detection of the fact that an OHMA exists so that something >>> intelligent can be done before it results in a total shutdown of the Di= ameter network. >>>>> Finally, we have agreed that the basic mechanism proposed in the draf= t may not cover all the use cases (existing or future) and can be enhanced = if required, with or without the need for a IETF standard action. >>>> SRD> The reasons so far for deferring functionality was because it >>>> SRD> would >>>> add risk to the schedule for finishing the core DOIC solution. That i= s not the case here. We have a very small change to the specification that= addresses multiple requirements. >>>> [LM] is there any clear description of what will be the use of this in= fo by the reacting node? if the proxy replaces the origin-host A by origin-= host B, the Diameter nodes receiving the answers will "see" B as sender of = the answer and will use this id when sending new requests with origin-host = AVP. So can you remind me how exactly the reacting node will use the Diamet= er-id received in the OLR? >>> SRD> Scroll down an look at the details behind alternative 1. >>>>> For all these reasons, I would recommend not to add this Diameter-id = in the OLR and to assume that the Origin-host is not changed by agent in th= e path of the Diameter messages. Some extra text could also be added to cla= rify that proxies modifying the Origin-host would have to be upgraded to ma= nage consistently the OLR received in Diameter application messages. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> >>>>> -----Message d'origine----- >>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell >>>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>>> alternatives analysis >>>>> >>>>> I support Alternative 1, but I'm not sure it's a complete solution. >>>>> >>>>> As Nirav pointed out, it has the potential to leak topology informati= on past a topology hiding proxy. (Unless we can come up with some attributi= on scheme that is not based on Diameter Identity or IP Address.) It may be = reasonable, to do this, but we would need some guidance to warn operators t= hat this may happen if they enable DOIC across a non-supporting, topology-h= iding proxy. It would become the operator's choice to decide which is more = important. >>>>> >>>>> The part I find unsatisfying, is what would happen if you had some pa= ths that supported DOIC (or did not do topology hiding), and some paths tha= t don't support DOIC also do topology hiding. This could become a pretty bi= g administrative hit, and violates the spirit and letter of our requirement= to avoid adding lots of configuration work. >>>>> >>>>> OTOH, if we had a mechanism where servers could detect the existence = of a non-DOIC, topology-hiding proxy, this could be at least partially auto= mated. I can think of multiple ways we could make it possible to tell if an= immediate peer supports DOIC, but not so much for non-adjacent nodes. >>>>> >>>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan = wrote: >>>>> >>>>>> All, >>>>>> >>>>>> My recommendation on this alternative 1 as it give operators the abi= lity to discover when there is an issue associated with "Origin-Host Mungin= g" agents. The operators can then take any administrative action necessary= to fix the issue. It is also a more general solution that does not rely o= n one industries interop procedures. >>>>>> >>>>>> If we can get agreement on this then we can start making progress on= the remainder of the document. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>>> Are there other thoughts on the pros and cons of the three proposal= s for resolution of issue #66? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> The issue with pre-DOIC agents changing origin-host was been disc= ussed in this thread: >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.html >>>>>>>>> >>>>>>>>> One example of the impact of the issue is defined in this message= : >>>>>>>>> >>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.html >>>>>>>>> >>>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>>> >>>>>>>>> 1) Attribution of overload reports. >>>>>>>>> - Add diameter-id of the node that is overloaded into the O= C-OLR AVP. >>>>>>>>> - Reacting node always uses the diameter-id in the OC-OLR r= eport when applying abatement algorithm logic. >>>>>>>>> - Reacting node detects when there is a difference between = the diameter-id in the OC-OLR report and in the Origin-Host AVP. When ther= e is a difference, the reacting node should report on the condition (event/= alarm). Local policy would determine if the reacting node honors the overl= oad report or ignores the overload report. >>>>>>>> I think the last entry is worth further discussion, but it's proba= bly more important to make a high level decision first. But, at risk of get= ting ahead of myself: I have trouble imagining a situation where honoring t= he overload report will be harmful, since if there is an intervening OHMA, = the reacting node will not likely have any host-routed requests to the diam= eter-id from the OLR. OTOH, I have trouble imagining where honoring the rep= ort would be useful, for the same reason. >>>>>>>> >>>>>>>>> 2) Configuration in operator's networks to turn off origin-host m= unging behavior until the agent is upgraded to support DOIC. >>>>>>>>> >>>>>>>>> 3) Configuration of reporting nodes to not send overload reports,= either universally or for transactions that cross the origin-host munging = agent. >>>>>>>>> >>>>>>>>> I've compiled a starting point for a pros and cons analysis of th= e three approaches. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> Option 1 Pros: >>>>>>>>> ------------ >>>>>>>>> - Gives operators a mechanism to detect when there is a non-DOIC = origin-host-munging agent in the path of a transaction. >>>>>>>>> - Gives operators ability to manage the under utilization issue c= aused by the non-DOIC agent. >>>>>>>>> - Gives operators the ability to keep features requiring origin-h= ost munging turned on while DOIC is rolled out. >>>>>>>>> - Leaves the determination of which action to take in this scenar= io (honor or ignore overload reports) to operator policy. >>>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount of c= onfiguration required. >>>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact of = a single node overload on the traffic handled by other nodes in the network= . >>>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact of = overload in a mixed DOIC environment on the overall capacity of the network= . >>>>>>>> Specifically, it complies with the MUST NOT make things worth clau= se, but does not comply with the SHOULD reduce overload clause. >>>>>>>> >>>>>>>>> Option 1 Cons: >>>>>>>>> ------------- >>>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>>> overload control >>>>>>>> One additional con is that, if the OHMA is there for the purposes = of true topology hiding, the identity in the OLR may leak topology informat= ion. >>>>>>>> >>>>>>>>> Option 2 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>>> management of overload conditions >>>>>>>>> >>>>>>>>> Option 2 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires the operator to lose any functionality enabled by >>>>>>>>> the non-DOIC agent until all agents have been upgraded to >>>>>>>>> support DOIC >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - There is not way to determine if all non-DOIC origin-host mungi= ng behavior has been turned off until an overload event happens, with poten= tial to have significant negative effects until the offending agent can be = found and the behavior turned off. >>>>>>>>> - Not always possible, as operator doesn't always have control ov= er non-DOIC agent as it might be in another operators network. Proposal to = address this through interop agreements but while this might work in 3GPP s= cenarios, not all Diameter deployments are 3GPP driven. >>>>>>>> Since you mentioned the 7068 requirements in the cons for option >>>>>>>> 1, it makes sense to mention them for others. This one misses on >>>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a >>>>>>>> requirement about not interfering with existing network features. >>>>>>>> If we had that, Option 2 would not comply.) >>>>>>>> >>>>>>>>> Option 3 Pros: >>>>>>>>> ------------ >>>>>>>>> - Does not require additional protocol machinery >>>>>>>>> - Gives operators the ability to keep features requiring origin-h= ost munging turned on while DOIC is rolled out. >>>>>>>> For very limited definitions of "rolled out." >>>>>>>> >>>>>>>>> Option 3 Cons: >>>>>>>>> ------------ >>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>> - Likely requires extra development in the reporting node that >>>>>>>>> would not otherwise be needed (ability to limit where overload >>>>>>>>> reports are sent) >>>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>>> - Limits ability of operator to fully control overload >>>>>>>>> >>>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in a s= imilar way as option 1. Partially misses 34. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> 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 detr= uire ainsi que les pieces jointes. Les messages electroniques etant suscept= ibles d'alteration, Orange decline toute responsabilite si ce message a ete= altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender an= d delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that have= been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> >>>> ____________________________________________________________________ >>>> _ _ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le detru= ire ainsi que les pieces jointes. Les messages electroniques etant suscepti= bles d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >>>> Thank you. >>>> >>>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc pas etre diffuses, exploites= ou copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les messages electroniques etant susceptibles d'alteration, Orange declin= e toute responsabilite si ce message a ete altere, deforme ou falsifie. Mer= ci. >>> >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; they should not be distributed, = used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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 nobody Mon Sep 1 19:39:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1A1A6F98 for ; Mon, 1 Sep 2014 19:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ9MCHIg1c1X for ; Mon, 1 Sep 2014 19:39:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779091A6F93 for ; Mon, 1 Sep 2014 19:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10136; q=dns/txt; s=iport; t=1409625557; x=1410835157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yCMQUCWWPJ4DPkSHQ4ddRZB8hnGWyXVdq+KLuPA4bVs=; b=lt0L+wVh7zEuOhk97S1nIYlUXZWsRAlV5PSlNECCvxOzWdlRjMGLGXNj uC3U1ygh0CgZ4sLz0iyzqAW68X4rPRskwZ0VMht9zFTOeIqcKGPx63aTy IRJcBe1uQW9IYyrsI6OOZhkb/mFieodbrfCUzwtdDVPjuSLeK0tu0jT2E o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAN4sBVStJA2E/2dsb2JhbABagw1TVwTHeQqHTwGBERZ3hAMBAQEDAQEBAWsLBQcEAgEIEQQBAQsLEgcnCxQJCAIEAQ0FCBOIHwgNuhcBEwSPHDEHBgSDJYEdBYpwhC2CFJdEiQWBZXcBgQRsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,446,1406592000"; d="scan'208";a="351798034" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 02 Sep 2014 02:39:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s822dFVZ023662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 02:39:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 1 Sep 2014 21:39:14 -0500 From: "Nirav Salot (nsalot)" To: Maria Cruz Bartolome , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "Ben Campbell" , Steve Donovan Thread-Topic: [Dime] Proposal for new error response for DOIC Thread-Index: AQHPwtSM6w23XF/IiEK7aWfc1k6gqpvmwqiAgADJlICAAAr1AIAFjHeAgAAB/oA= Date: Tue, 2 Sep 2014 02:39:14 +0000 Message-ID: References: <53FF4A17.9050707@usdonovans.com> <95D175DE-C80C-4690-95D8-14ABC6393A38@nostrum.com> <087A34937E64E74E848732CFF8354B920980ECBA@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980ECBA@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.140.43] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/adNfPR6iCpFwwstz3ikHmQiUjs8 Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2014 02:39:19 -0000 I don't have a strong opinion here but I still prefer to have a new error r= esponse code specifically for the request rejected due to overload for the = following reason: - TOO_BUSY can be used already today due to other than overload reason as w= ell. Additionally, it does not prevent the sender from retransmitting the s= ame request, and this does not help specifically in the overload scenario. - New error response code will also allow the operator/system administrator= to quantify the rejected requests while in the overload. This will further= allow the fine tuning of the overload algorithm or the prediction mechanis= m at the overloaded node (so that more accurate overload-reduction-metric c= an be advertised or a different overload control algorithm can be used and = fewer requests may be rejected). These are the arguments we used during GTP-C overload control work in 3GPP = to define a new GTP-C error cause code. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: Tuesday, September 02, 2014 2:52 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposal for new error response for DOIC Dear JJ, all, My understanding is that "alternate peer" in the TOO_BUSY description is in= terpreted as either a new destination_host, or a new server that provides s= ervice to the same realm. Then, I think that already the standardized behavior for a reacting node wh= en it receives TOO_BUSY may be enough. It is not explicitly mentioned that = retransmissions to the same "peer" should be avoid, but a different action = is requested.=20 Therefore, I am not sure we really need to define a new error, just to requ= est the reacting node to throttle if required, since in my opinion this is = already implied by TOO_BUSY description by "SHOULD". If this attempt is not= possible or not successful (for any reason), then reacting node will throt= tle this request. As a conclusion, in my opinion, we do not need a new error. If you do not a= gree nowadays TOO_BUSY description is enough we could extend/clarify this d= escription, either updating RFC or with new additional guidelines.=20 Apart from that, take into account TOO_BUSY is already an indication of ove= rload, and this is part of the main RFC, then if we need this requires some= clarification, I think this should not be constraint to the new DOIC draft= . Cheers /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: viernes, 29 de agosto de 2014 10:38 To: Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposal for new error response for DOIC To come back on my point 2) , and reviewing the definition of Diameter too = busy in RFC 6733.=20 DIAMETER_TOO_BUSY 3004 When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service Does it mean that the request is sent to the same specific server but via a= n alternate path (the request contains the same Realm and host destinations= AVP but is sent to another peer (another DA) , or can the alternate peer c= orresponds to another server (so another destination host). According to th= e understanding, this impacts my Point 2) remarks Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: vendredi 29 ao=FBt 2014 09:59 =C0=A0: Ben C= ampbell; Steve Donovan Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Proposal f= or new error response for DOIC Dear all A few remarks 1) I am also questioning about the backward compatibility case where a DA = is acting on behalf of a non DOIC client. The solution Steve proposes , to my view, also work in this case: if the = DA throttles a request, it will generate a Diameter too busy to the client,= so with the possible consequence that the non DOIC client do a retry to an= alternate destination. But we cannot avoid it, this is the non DOIC clien= t existing behavior. In any case we should avoid to send a new Diameter error to a non DOIC clie= nt as it can result to a non predictable behavior.=20 Among the possible solutions, one is to continue to use Diameter to busy in= all cases but with, in addition, a new AVP (a "DOIC diagnostic" AVP) whi= ch means message throttled in a DOIC case, which is generated by the DOIC r= eporting node, supported by a DOIC reacting node (which will not do retry t= o another destination) and ignored by a non DOIC client. This AVP may be = in the future take other values if needed. =20 2) some remark about the new retry. - I think a DA can do a retry in the case it has received a realm only requ= est (without destination host), and if not successful, will sent the new di= ameter error to the client. But if instead, the client had received a clas= sical Diameter too busy, it will also not do a retry to another destination= (as it only knows the realm, but not the server), so Diameter too busy see= ms here acceptable, isn't it? - If the client has sent a request with a Destination host, which is reject= ed by the reporting node (so with the new Diameter error) I do not think th= at a DA can do a retry to another destination host (as the client has reque= sted a specific Destination host). Am I wrong here? But the client may even= tually do a retry towards another destination host, according to the applic= ation case, so not so in line with the meaning of the new Diameter error re= questing no retry. - a server rejecting a request, will generate the new Diameter error, but t= he intermediate DA receiving this error may nevertheless do a retry to ano= ther destination a retry, so the meaning of the new Diameter error does not= always mean "no retry" for a reacting node.=20 To have your view on these remarks. =20 Best raegrds. JJacques =20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy= =E9=A0: jeudi 28 ao=FBt 2014 21:57 =C0=A0: Steve Donovan Cc=A0: dime@ietf.o= rg Objet=A0: Re: [Dime] Proposal for new error response for DOIC I agree with doing this.=20 But I'm also concerned that the backwards compatibility issue you mention m= eans that this doesn't help in what is potentially the biggest use case for= throttling at an agent. that is, an agent throttling on behalf of a non-su= pporting client. One approach would be to define DIAMETER_THROTTLED in a separate update to = RFC 6733, in hopes that people who aren't ready to fully support DOIC might= at least support the new error. (Yeah, I know that's a long shot.) Another= might be to write some additional (BCP?) guidance on how clients should ha= ndle TOO_BUSY.=20 On Aug 28, 2014, at 10:26 AM, Steve Donovan wrot= e: > All, >=20 > One of the open issues is the DOIC behavior when a DOIC node rejects a re= quest as a result of an overload condition. >=20 > Today, the logical error response would be the DIAMETER_TOO_BUSY response= . The issue with this behavior is that it can result in the client retryin= g the request to an alternative peer. >=20 > The desired behavior for a request rejected because of overload throttlin= g is the same as if the client, acting as a reacting node, throttled the re= quest. As a result, the transaction should not be retried. >=20 > The proposal is to define a new protocol error response code called DIAME= TER_THROTTLED with the defined behavior that the request SHOULD be treated = as a final response and SHOULD NOT be retried. >=20 > This error response could be generated by agents acting as reacting nodes= or by any reporting node. A server, for instance, that is in a severe ove= rload condition might chose to reject some transactions with the DIAMETER_T= HROTTLED response if the current requested reduction included in the overlo= ad report is not sufficient. >=20 > One issue with this proposal is backwards compatibility with Diameter nod= es that do not support DOIC and, as such, would not understand the DIAMETER= _THROTTLED response. The proposal to address this is to make the generatio= n of the DIAMETER_THROTTLED error response conditional. This is an attempt= at wording this conditional behavior: >=20 > A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transact= ions that are throttled and the DOIC node knows that there is a DOIC reacti= ng node able to process the error response. The DOIC node generating the D= IAMETER_THROTTLED error response determines that there there is a DOIC reac= ting node by the presence or absence of an OC-Supported-Features AVP in the= request message for the transaction. >=20 > If there is no OC-Supported-Features AVP in the request message for a tra= nsaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_B= USY response message. >=20 > Assuming we get agreement on the proposal then I'll come back with detail= ed wording proposals for the DOIC specification. >=20 > Regards, >=20 > Steve >=20 >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Sep 2 01:12:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557731A86EE for ; Tue, 2 Sep 2014 01:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wBAiz20tDZd for ; Tue, 2 Sep 2014 01:12:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F931A0108 for ; Tue, 2 Sep 2014 01:12:02 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-9b-54057bd07ff8 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.86.21334.0DB75045; Tue, 2 Sep 2014 10:12:00 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Tue, 2 Sep 2014 10:11:59 +0200 From: Maria Cruz Bartolome To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Issue #48 - M-bit gives wrong sementics Thread-Index: AQHPrN/gcnDHUd4VRE2L1ydZqMn82Zu6ThqAgAAD7wCAABLYgIAtYxSwgAXmTyA= Date: Tue, 2 Sep 2014 08:11:59 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980EDE6@ESESSMB101.ericsson.se> References: <53DA7458.5080301@usdonovans.com>, <30A10CA8-0B72-4878-8489-5A3156E070AA@nostrum.com> <19339_1406828489_53DA7FC9_19339_507_2_vpoow8l3d11jllgtnin7jy3y.1406828485751@email.android.com> <1D45DC43-3C0A-48AA-A5AA-8A86AFA465AA@gmail.com> 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.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6FatYQg4tXtSzm9q5gs9h0fh2L xYYmHgdmj9Zne1k9liz5yeSx6m0fawBzFJdNSmpOZllqkb5dAlfG9SlLmAtOmFXMnvCQpYFx o04XIyeHhICJxKYpL1khbDGJC/fWs3UxcnEICRxllNjY84EJwlnMKDH//24WkCo2ATuJS6df gCVEQBKbj10Fcjg4hAWsJbpmmoLUiAjYSDxtOc8CYftJnDmyhxnEZhFQkVi86AMbiM0r4Csx sfkI1LYzTBKtFz6ANXAKxEocnTgb7CRGoJO+n1rDBGIzC4hL3HoynwniVAGJJXvOM0PYohIv H/+DekFJonHJE1aIej2JG1OnsEHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYw sqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyeg1t+6+5gXP3a8RCjAAejEg/vAhXWECHW xLLiytxDjNIcLErivIvOzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLjm7MKtFz0Kv13T cDZ9E/B77ixxtQex/QrH56oKsH7kKiv+w6eyguHLq49RvKov3kvaxx2ZzVXuMHPil9SjnYvF W1/dn9ozy+FRmfqB85dZC0Ku3P4pt7zZoTX3tqPbHPX7Mts1fm456D/DcFrL1JcRP1+EHupZ UJNqVMNmkb1N89UH2WNmSxYpsRRnJBpqMRcVJwIAByqTWH8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/F-5DZdDTNUV__1H69_65tXfw898 Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2014 08:12:15 -0000 Dear JJ, all, See comments inline for some clarifications in the draft. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: viernes, 29 de agosto de 2014 17:50 To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics Hi Steve and all M-bit on which I am cautious as often at the origin of interoperability is= sues, is mentioned in different places in the 03 draft (sections 4.3, 6 a= nd 6.8) with rules according to the following: - when DOIC is supporting in an existing application, Mbit SHOULD not be se= t in DOIC AVPS (cf 6.8) - a new application can incorporate the DOIC mechanism as mandatory (cf 6),= in this case the OC-Feature-Vector and OC-OLR AVPs reused in newly defined= Diameter applications SHOULD have the M-bit flag set [MCruz] Fine Some (non fundamental) remarks hereafter: a) We can have a new application where DOIC is not mandatory (when reading = 6), but in 6.8 it is stated "when reused in newly defined Diameter applicat= ions, the DOC (note: to be DOIC) related AVPs SHOULD have the M-bit set". = If DOIC is optional for this new application, Mbit is not set at least for= the OC-Supported-features AVP in the requests, so to be ignored by a non D= OIC supporting node receiving the request. May be to clarify. [MCruz] Agree to clarify in the draft b) We have text with general statements about DOIC AVPs and some text in 6 = (not contradictory) related to OC-Feature-Vector and OC-OLR . I think that= , in 6, OC-Supported-Feature could be added, or even replace OC-Feature-Vec= tor AVP which is a sub AVP of OC-Supported features and so already addresse= d in 4.3.=20 [MCruz] Agree to use OC-Supported-Features c) About "existing commands" in 6, sometimes an application which can be a = new one can reuse an existing command defined in another application, the M= bit rule here is attached to the application, so, to avoid misinterpretatio= n, may be better to write "commands of an existing application" in 6. [MCruz] Agree to be clarified. d) About an intermediate proxy DA for an application but not supporting DO= IC for this application (as not needed), how does it behave when transferr= ing requests with OC-Supported-Features or OLR AVPs with Mbit set, is it c= lear that the DA transfers the DOIC AVPs and not reject them for AVP unsupp= orted? =20 [MCruz] If the proxy DA supports application X, when DOIC AVPs are sent in = application X responses, with M-bit set, isn't that the application will re= ject them? e) in 4.3, it is written "NOT RECOMMENDED", I think better to write " M-bit= in sub-AVPs SHOULD not be set"=20 [MCruz] Agree I hereafter remind the verison03 extracts mentioning M-bit In 4.3 More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED in 6=20 When added to existing commands,both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues A new application specification can incorporate the overload control mechanism specified in this document by making it mandatory to implement for the application and referencing this specification normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set. However, it is the responsibility of the Diameter application designers to define how overload control mechanisms works on that application. In 6.8=20 As described in the Diameter base protocol [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP. The Diameter overload control AVPs SHOULD always be sent with the M-bit cleared when used within existing Diameter applications to avoid backward compatibility issues. Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9=A0:= jeudi 31 juillet 2014 20:49 =C0=A0: Cc=A0: dime= @ietf.org; Ben Campbell Objet=A0: Re: [Dime] Issue #48 - M-bit gives wrong = sementics OK++; On Jul 31, 2014, at 8:41 PM, wrote: > Ok for me. >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > ---- Ben Campbell a =E9crit ---- >=20 >=20 > No objection >=20 > On Jul 31, 2014, at 11:52 AM, Steve Donovan wr= ote: >=20 >> All, >>=20 >> The proposal coming out of the meeting in Toronto was to close this issu= e with no changes to the existing text. >>=20 >> Let me know if there are objections to doing so, otherwise I'll close th= e issue. >>=20 >> Regards, >>=20 >> Steve >>=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 > 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, Orange decline toute responsabilite si ce message a ete altere, deform= e 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, Orange is not liable for messages that have bee= n 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 nobody Tue Sep 2 02:00:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37BC1A0197 for ; Tue, 2 Sep 2014 02:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XQLRHKD6XNY for ; Tue, 2 Sep 2014 02:00:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015EF1A0198 for ; Tue, 2 Sep 2014 02:00:34 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id CB1171902DC; Tue, 2 Sep 2014 11:00:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 720DF158096; Tue, 2 Sep 2014 11:00:29 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 11:00:29 +0200 From: To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Steve Donovan , "dime@ietf.org" , "Maria Cruz Bartolome" Thread-Topic: [Dime] Issue #48 - M-bit gives wrong sementics Thread-Index: Ac/GjFd0cnDHUd4VRE2L1ydZqMn82Q== Date: Tue, 2 Sep 2014 09:00:28 +0000 Message-ID: <11482_1409648429_5405872D_11482_12116_2_cip5taxlylt1fx0uv5bmo3mb.1409647933659@email.android.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.2.52120 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RP5KzdGJbffG7IVfR_fGfSYxT2M Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2014 09:00:38 -0000 SGksIHNvbWUgY29tbWVudHMgYmVsb3cuCgpSZWdhcmRzLAoKTGlvbmVsCgpFbnZvecOpIGRlcHVp cyBtb24gU29ueSBYcGVyaWEgU1AgZCdPcmFuZ2UKCi0tLS0gTWFyaWEgQ3J1eiBCYXJ0b2xvbWUg YSDDqWNyaXQgLS0tLQoKPiBEZWFyIEpKLCBhbGwsDQo+IA0KPiBTZWUgY29tbWVudHMgaW5saW5l IGZvciBzb21lIGNsYXJpZmljYXRpb25zIGluIHRoZSBkcmFmdC4NCj4gQmVzdCByZWdhcmRzDQo+ IC9NQ3J1eg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGlNRSBb bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRST1RUSU4sIEpFQU4t SkFDUVVFUyAoSkVBTi1KQUNRVUVTKQ0KPiBTZW50OiB2aWVybmVzLCAyOSBkZSBhZ29zdG8gZGUg MjAxNCAxNzo1MA0KPiBUbzogU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW0RpbWVdIElzc3VlICM0OCAtIE0tYml0IGdpdmVzIHdyb25nIHNlbWVudGljcw0KPiAN Cj4gSGkgU3RldmUgYW5kICBhbGwNCj4gDQo+IE0tYml0IG9uIHdoaWNoIEkgYW0gY2F1dGlvdXMg YXMgb2Z0ZW4gYXQgdGhlIG9yaWdpbiAgb2YgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMsIGlzIG1l bnRpb25lZCBpbiBkaWZmZXJlbnQgIHBsYWNlcyAgaW4gdGhlIDAzIGRyYWZ0IChzZWN0aW9ucyA0 LjMsIDYgYW5kIDYuOCkgd2l0aCBydWxlcyBhY2NvcmRpbmcgdG8gdGhlIGZvbGxvd2luZzoNCj4g DQo+IC0gd2hlbiBET0lDIGlzIHN1cHBvcnRpbmcgaW4gYW4gZXhpc3RpbmcgYXBwbGljYXRpb24s IE1iaXQgU0hPVUxEIG5vdCBiZSBzZXQgaW4gRE9JQyBBVlBTIChjZiA2LjgpDQo+IC0gYSBuZXcg YXBwbGljYXRpb24gY2FuIGluY29ycG9yYXRlIHRoZSBET0lDIG1lY2hhbmlzbSBhcyBtYW5kYXRv cnkgKGNmIDYpLCBpbiB0aGlzIGNhc2UgdGhlIE9DLUZlYXR1cmUtVmVjdG9yIGFuZCBPQy1PTFIg QVZQcyByZXVzZWQgaW4gbmV3bHkgZGVmaW5lZCBEaWFtZXRlciBhcHBsaWNhdGlvbnMgU0hPVUxE IGhhdmUgdGhlIE0tYml0IGZsYWcgc2V0DQo+IFtNQ3J1el0gRmluZQ0KTGlvbmVsOiBPSwoKPiAN Cj4gU29tZSAobm9uIGZ1bmRhbWVudGFsKSByZW1hcmtzIGhlcmVhZnRlcjoNCj4gYSkgV2UgY2Fu IGhhdmUgYSBuZXcgYXBwbGljYXRpb24gd2hlcmUgRE9JQyBpcyBub3QgbWFuZGF0b3J5ICh3aGVu IHJlYWRpbmcgNiksIGJ1dCBpbiA2LjggaXQgaXMgc3RhdGVkICJ3aGVuIHJldXNlZCBpbiBuZXds eSBkZWZpbmVkIERpYW1ldGVyIGFwcGxpY2F0aW9ucywgdGhlIERPQyAobm90ZTogdG8gYmUgRE9J QykgIHJlbGF0ZWQgQVZQcyBTSE9VTEQgaGF2ZSB0aGUgTS1iaXQgc2V0Ii4gSWYgRE9JQyBpcyBv cHRpb25hbCBmb3IgdGhpcyBuZXcgYXBwbGljYXRpb24sIE1iaXQgaXMgbm90ICBzZXQgYXQgbGVh c3QgZm9yIHRoZSBPQy1TdXBwb3J0ZWQtZmVhdHVyZXMgQVZQIGluIHRoZSByZXF1ZXN0cywgc28g dG8gYmUgaWdub3JlZCBieSBhIG5vbiBET0lDIHN1cHBvcnRpbmcgbm9kZSByZWNlaXZpbmcgdGhl IHJlcXVlc3QuIE1heSBiZSB0byBjbGFyaWZ5Lg0KPiBbTUNydXpdIEFncmVlIHRvIGNsYXJpZnkg aW4gdGhlIGRyYWZ0DQpMaW9uZWw6IG9wdGlvbmFsIHRvIHVzZSBkb2VzIG5vdCBtZWFuIG9wdGlv bmFsIHRvIHVuZGVyc3RhbmQuIFNvIEkgdGhpbmsgdGhhdCB0aGUgIlNIT1VMRCIgaXMgY29ycmVj dCBoZXJlIGZvciBuZXcgYXBwbGljYXRpb24gaW5jb3Jwb3JhdGluZyBET0lDLgoKPiANCj4gYikg V2UgaGF2ZSB0ZXh0IHdpdGggZ2VuZXJhbCBzdGF0ZW1lbnRzIGFib3V0IERPSUMgQVZQcyBhbmQg c29tZSB0ZXh0IGluIDYgKG5vdCBjb250cmFkaWN0b3J5KSAgcmVsYXRlZCB0byBPQy1GZWF0dXJl LVZlY3RvciBhbmQgT0MtT0xSIC4gSSB0aGluayB0aGF0LCBpbiA2LCBPQy1TdXBwb3J0ZWQtRmVh dHVyZSBjb3VsZCBiZSBhZGRlZCwgb3IgZXZlbiByZXBsYWNlIE9DLUZlYXR1cmUtVmVjdG9yIEFW UCB3aGljaCBpcyBhIHN1YiBBVlAgb2YgT0MtU3VwcG9ydGVkIGZlYXR1cmVzIGFuZCBzbyBhbHJl YWR5IGFkZHJlc3NlZCBpbiA0LjMuIA0KPiBbTUNydXpdIEFncmVlIHRvIHVzZSBPQy1TdXBwb3J0 ZWQtRmVhdHVyZXMNCkxpb25lbDogT0sgCgo+IA0KPiBjKSBBYm91dCAiZXhpc3RpbmcgY29tbWFu ZHMiIGluIDYsIHNvbWV0aW1lcyBhbiBhcHBsaWNhdGlvbiB3aGljaCBjYW4gYmUgYSBuZXcgb25l IGNhbiByZXVzZSBhbiBleGlzdGluZyBjb21tYW5kIGRlZmluZWQgaW4gYW5vdGhlciBhcHBsaWNh dGlvbiwgdGhlIE1iaXQgcnVsZSBoZXJlIGlzIGF0dGFjaGVkIHRvIHRoZSBhcHBsaWNhdGlvbiwg c28sIHRvIGF2b2lkIG1pc2ludGVycHJldGF0aW9uLCAgbWF5IGJlIGJldHRlciB0byB3cml0ZSAi Y29tbWFuZHMgb2YgYW4gZXhpc3RpbmcgYXBwbGljYXRpb24iIGluIDYuDQo+IFtNQ3J1el0gQWdy ZWUgdG8gYmUgY2xhcmlmaWVkLg0KTGlvbmVsOiBvbmUgc21hbGwgY2xhcmlmaWNhdGlvbjogdGhl IE0tYml0IHNldHRpbmcgaXMgdGlnaHQgdG8gdGhlIGFwcGxpY2F0aW9uIEFORCB0aGUgY29tbWFu ZC4gVGhlIHNhbWUgQVZQIGNhbiBiZSB3aXRoIHRoZSBNLWJpdCBzZXQgZm9yIG9uZSBjb21tYW5k IGFuZCB0aGUgTS1iaXQgZm9yIGFub3RoZXIgY29tbWFuZCBkZWZpbmVkIGZvciB0aGUgc2FtZSBh cHBsaWNhdGlvbiwgYXMgY2xhcmlmaWVkIGluIHJmYzY3MzMuCgo+IA0KPiBkKSBBYm91dCBhbiBp bnRlcm1lZGlhdGUgIHByb3h5IERBIGZvciBhbiBhcHBsaWNhdGlvbiBidXQgbm90IHN1cHBvcnRp bmcgRE9JQyBmb3IgdGhpcyBhcHBsaWNhdGlvbiAoYXMgbm90IG5lZWRlZCksIGhvdyAgZG9lcyBp dCBiZWhhdmUgd2hlbiB0cmFuc2ZlcnJpbmcgIHJlcXVlc3RzIHdpdGggT0MtU3VwcG9ydGVkLUZl YXR1cmVzIG9yIE9MUiBBVlBzIHdpdGggTWJpdCBzZXQsIGlzIGl0IGNsZWFyIHRoYXQgdGhlIERB IHRyYW5zZmVycyB0aGUgRE9JQyBBVlBzIGFuZCBub3QgcmVqZWN0IHRoZW0gZm9yIEFWUCB1bnN1 cHBvcnRlZD8gICAgDQo+IFtNQ3J1el0gSWYgdGhlIHByb3h5IERBIHN1cHBvcnRzIGFwcGxpY2F0 aW9uIFgsIHdoZW4gRE9JQyBBVlBzIGFyZSBzZW50IGluIGFwcGxpY2F0aW9uIFggcmVzcG9uc2Vz LCB3aXRoIE0tYml0IHNldCwgaXNuJ3QgdGhhdCB0aGUgYXBwbGljYXRpb24gd2lsbCByZWplY3Qg dGhlbT8NCkxpb25lbDogYSBwcm94eSB1c2VkIGluIHRoZSBwYXRoIG9mIERpYW1ldGVyIEVBUCBl eGNoYW5nZXMgYmV0d2VlbiBjbGllbnRzIGFuZCByZW1vdGUgc2VydmVycyB3aWxsIG5vdCByZWpl Y3QgY29tbWFuZHMgYmVjYXVzZSBpdCBpcyBub3QgcGVyZm9ybWluZyBFQVAgYXV0aGVudGljYXRp b24gaXRzZWxmLiBBcyBzb29uIGFzIHRoZSBET0lDIEFWUHMgYXJlIHN1cHBvcnRlZCBieSB0aGUg YXBwbGljYXRpb24sIHRoZXJlIGlzIG5vIHJlYXNvbiBmb3IgdGhlIHByb3h5IHRvIHJlamVjdCB0 aGVtLCBleGNlcHQgaWYgdGhlcmUgaXMgYSBzcGVjaWZpYyBwb2xpY3kgdG8gZG8gaXQuCgo+IA0K PiBlKSBpbiA0LjMsIGl0IGlzIHdyaXR0ZW4gIk5PVCBSRUNPTU1FTkRFRCIsIEkgdGhpbmsgYmV0 dGVyIHRvIHdyaXRlICIgTS1iaXQgaW4gc3ViLUFWUHMgU0hPVUxEIG5vdCBiZSBzZXQiIA0KPiBb TUNydXpdIEFncmVlDQpMaW9uZWw6IGV2ZW4gYmV0dGVyOiAiU0hPVUxEIE5PVCIgOi0pCgo+IA0K PiBJIGhlcmVhZnRlciByZW1pbmQgdGhlIHZlcmlzb24wMyAgZXh0cmFjdHMgbWVudGlvbmluZyBN LWJpdCBJbiA0LjMNCj4gICAgTW9yZSBzcGVjaWZpY2FsbHksIHRoZSBzdWItQVZQcyBpbnNpZGUg dGhlDQo+ICAgIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBhbmQgT0MtT0xSIEFWUCBNQVkgaGF2ZSB0 aGUgTS1iaXQgc2V0Lg0KPiAgICBIb3dldmVyLCB3aGVuIG92ZXJsb2FkIGNvbnRyb2wgQVZQcyBh cmUgcGlnZ3liYWNrZWQgb24gdG9wIG9mIGFuDQo+ICAgIGV4aXN0aW5nIGFwcGxpY2F0aW9ucywg c2V0dGluZyBNLWJpdCBpbiBzdWItQVZQcyBpcyBOT1QgUkVDT01NRU5ERUQNCj4gDQo+IGluIDYg DQo+ICAgIFdoZW4gYWRkZWQgdG8gZXhpc3RpbmcgY29tbWFuZHMsYm90aCBPQy1GZWF0dXJlLVZl Y3RvciBhbmQgT0MtT0xSDQo+ICAgIEFWUHMgU0hPVUxEIGhhdmUgdGhlIE0tYml0IGZsYWcgY2xl YXJlZCB0byBhdm9pZCBiYWNrd2FyZA0KPiAgICBjb21wYXRpYmlsaXR5IGlzc3Vlcw0KPiANCj4g ICAgQSBuZXcgYXBwbGljYXRpb24gc3BlY2lmaWNhdGlvbiBjYW4gaW5jb3Jwb3JhdGUgdGhlIG92 ZXJsb2FkIGNvbnRyb2wNCj4gICAgbWVjaGFuaXNtIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50 IGJ5IG1ha2luZyBpdCBtYW5kYXRvcnkgdG8NCj4gICAgaW1wbGVtZW50IGZvciB0aGUgYXBwbGlj YXRpb24gYW5kIHJlZmVyZW5jaW5nIHRoaXMgc3BlY2lmaWNhdGlvbg0KPiAgICBub3JtYXRpdmVs eS4gIEluIHN1Y2ggYSBjYXNlLCB0aGUgT0MtRmVhdHVyZS1WZWN0b3IgYW5kIE9DLU9MUiBBVlBz DQo+ICAgIHJldXNlZCBpbiBuZXdseSBkZWZpbmVkIERpYW1ldGVyIGFwcGxpY2F0aW9ucyBTSE9V TEQgaGF2ZSB0aGUgTS1iaXQNCj4gICAgZmxhZyBzZXQuICBIb3dldmVyLCBpdCBpcyB0aGUgcmVz cG9uc2liaWxpdHkgb2YgdGhlIERpYW1ldGVyDQo+ICAgIGFwcGxpY2F0aW9uIGRlc2lnbmVycyB0 byBkZWZpbmUgaG93IG92ZXJsb2FkIGNvbnRyb2wgbWVjaGFuaXNtcyB3b3Jrcw0KPiAgICBvbiB0 aGF0IGFwcGxpY2F0aW9uLg0KPiANCj4gSW4gNi44IA0KPiAgICBBcyBkZXNjcmliZWQgaW4gdGhl IERpYW1ldGVyIGJhc2UgcHJvdG9jb2wgW1JGQzY3MzNdLCB0aGUgTS1iaXQNCj4gICAgc2V0dGlu ZyBmb3IgYSBnaXZlbiBBVlAgaXMgcmVsZXZhbnQgdG8gYW4gYXBwbGljYXRpb24gYW5kIGVhY2gN Cj4gICAgY29tbWFuZCB3aXRoaW4gdGhhdCBhcHBsaWNhdGlvbiB0aGF0IGluY2x1ZGVzIHRoZSBB VlAuDQo+IA0KPiAgICBUaGUgRGlhbWV0ZXIgb3ZlcmxvYWQgY29udHJvbCBBVlBzIFNIT1VMRCBh bHdheXMgYmUgc2VudCB3aXRoIHRoZQ0KPiAgICBNLWJpdCBjbGVhcmVkIHdoZW4gdXNlZCB3aXRo aW4gZXhpc3RpbmcgRGlhbWV0ZXIgYXBwbGljYXRpb25zIHRvDQo+ICAgIGF2b2lkIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgaXNzdWVzLiAgT3RoZXJ3aXNlLCB3aGVuIHJldXNlZCBpbiBuZXdseQ0K PiAgICBkZWZpbmVkIERpYW1ldGVyIGFwcGxpY2F0aW9ucywgdGhlIERPQyByZWxhdGVkIEFWUHMg U0hPVUxEIGhhdmUgdGhlDQo+ICAgIE0tYml0IHNldC4NCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiAN Cj4gSkphY3F1ZXMgDQo+IA0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDog RGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBKb3VuaSBF bnZvecOpwqA6IGpldWRpIDMxIGp1aWxsZXQgMjAxNCAyMDo0OSDDgMKgOiA8bGlvbmVsLm1vcmFu ZEBvcmFuZ2UuY29tPiBDY8KgOiBkaW1lQGlldGYub3JnOyBCZW4gQ2FtcGJlbGwgT2JqZXTCoDog UmU6IFtEaW1lXSBJc3N1ZSAjNDggLSBNLWJpdCBnaXZlcyB3cm9uZyBzZW1lbnRpY3MNCj4gDQo+ IA0KPiBPSysrOw0KPiANCj4gT24gSnVsIDMxLCAyMDE0LCBhdCA4OjQxIFBNLCA8bGlvbmVsLm1v cmFuZEBvcmFuZ2UuY29tPiA8bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiB3cm90ZToNCj4gDQo+ ID4gT2sgZm9yIG1lLg0KPiA+IA0KPiA+IEVudm95w6kgZGVwdWlzIG1vbiBTb255IFhwZXJpYSBT UCBkJ09yYW5nZQ0KPiA+IA0KPiA+IC0tLS0gQmVuIENhbXBiZWxsIGEgw6ljcml0IC0tLS0NCj4g PiANCj4gPiANCj4gPiBObyBvYmplY3Rpb24NCj4gPiANCj4gPiBPbiBKdWwgMzEsIDIwMTQsIGF0 IDExOjUyIEFNLCBTdGV2ZSBEb25vdmFuIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+IHdyb3Rl Og0KPiA+IA0KPiA+PiBBbGwsDQo+ID4+IA0KPiA+PiBUaGUgcHJvcG9zYWwgY29taW5nIG91dCBv ZiB0aGUgbWVldGluZyBpbiBUb3JvbnRvIHdhcyB0byBjbG9zZSB0aGlzIGlzc3VlIHdpdGggbm8g Y2hhbmdlcyB0byB0aGUgZXhpc3RpbmcgdGV4dC4NCj4gPj4gDQo+ID4+IExldCBtZSBrbm93IGlm IHRoZXJlIGFyZSBvYmplY3Rpb25zIHRvIGRvaW5nIHNvLCBvdGhlcndpc2UgSSdsbCBjbG9zZSB0 aGUgaXNzdWUuDQo+ID4+IA0KPiA+PiBSZWdhcmRzLA0KPiA+PiANCj4gPj4gU3RldmUNCj4gPj4g DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IERpTUUgbWFpbGluZyBsaXN0DQo+ID4+IERpTUVAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBEaU1FIG1haWxpbmcgbGlz dA0KPiA+IERpTUVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RpbWUNCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gDQo+ID4gQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IA0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j IHBhcyBldHJlIGRpZmZ1c2VzLCANCj4gPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiA+IHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4NCj4gPiANCj4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPiBBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91Lg0KPiA+IA0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g RGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlN RSBtYWlsaW5nIGxpc3QNCj4gRGlNRUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhh bmsgeW91LgoK From nobody Wed Sep 3 06:49:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A41A02D8 for ; Wed, 3 Sep 2014 06:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrwaS5j_E4On for ; Wed, 3 Sep 2014 06:49:01 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48761A02D5 for ; Wed, 3 Sep 2014 06:49:01 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51637 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPAvg-0005Xo-MW; Wed, 03 Sep 2014 06:49:00 -0700 Message-ID: <54071C47.1080005@usdonovans.com> Date: Wed, 03 Sep 2014 08:48:55 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "Nirav Salot (nsalot)" , "lionel.morand@orange.com" , Ben Campbell References: <53E4E339.1070106@usdonovans.com> <20803_1408441727_53F31D7F_20803_530_1_6B7134B31289DC4FAF731D844122B36E6BAF14@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F337D1.1070108@usdonovans.com> <13882_1408455651_53F353E3_13882_1991_1_6B7134B31289DC4FAF731D844122B36E6BBAD9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F3630C.5070104@usdonovans.com> <28349_1408462040_53F36CC3_28349_225_1_6B7134B31289DC4FAF731D844122B36E6BC496@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53F4C4A3.4070105@usdonovans.com> <53F4CC09.6000208@usdonovans.com> <53F610D1.4070007@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iLWakOpcTCWlPFinlQxF-VQzsl0 Cc: "dime@ietf.org" Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives analysis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 13:49:05 -0000 JJ, Apologies for my delayed response. I won't go through things in detail, = as this is ground that has been covered. I will reiterate that we are talking about a backwards compatibility=20 issue here. We are talking about agents that are running today and=20 doing functions that require changing the origin-host in answer=20 messages. There is no way that these existing agents can be expected to = support DOIC, as DOIC doesn't exist yet. For reasons that have already been expressed, I don't consider it=20 sufficient to address this by saying to operators "make sure all agents=20 in your network and your partners networks support DOIC before turning=20 on DOIC." This, however, looks to be the direction this discussion is=20 taking. Steve On 8/28/14, 5:25 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > Dear all > > A long email thread on this topology hiding topic. I Would like to com= e back on the use cases. > In the thread, two use cases were mentioned, are there others? > > - the SFE case, where a DA in front of a set of servers presents this s= et of servers as one Diameter node with a unique Diameter Host identity. = The reacting nodes only know this Diameter Host identity for their host r= equests. Regarding DOIC, as the SFE objective is to present the group of = servers as one Diameter node it should apply to DOIC, meaning the DA aggr= egates the different OLRs received from servers to build the OLR associat= ed to the unique Diameter Host identity. Otherwise this Diameter node w= ill send inconsistent OLRs, and then we try to find a solution requesting= the reacting nodes, that may be in external networks to solve this DOIC= issue internal to the servers and their SFE. Lionel did such a remark= in his 19/08 mail " a agent modifying the Origin-host can only be a prox= y and a proxy is by definition compliant with the application supporting = the new OLR-related AVPs" on which I agree. > Furthermore the Steve's proposed solution would introduce a non consist= ent behavior from the reacting node regarding traffic reduction. > > - the external network case where the DA of the servers network interf= acing external networks is doing topology hiding to present the servers = as a unique Diameter node to external networks . I have the same remark a= s for SFE, where the proposed solution will request the external network = to solve the issue of the non DOIC DEA. > There is also the case where the DEA modifies the Origin-Host but on a= 1 to 1 basis, so allocating a different Origin-host identity for each se= rver. In this case, the DOIC works well without changes. The proposed so= lution will, I think, here create mismatches, which do not exist. > > I share the comments from several of us, to not consider this case as a= n actual one to solve. If a DA presents a set of servers as a unique Diam= eter Host, either this overall entity (servers+DA) supports DOIC and beha= ves as a reporting node towards reacting nodes or it does not. If it doe= s not, no OC-Supported-feature AVP should be sent by this entity in answe= rs to reacting nodes, that I think can be achieved. > > Best regards > > JJacques > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsa= lot) > Envoy=E9 : jeudi 21 ao=FBt 2014 18:49 > =C0 : Steve Donovan; lionel.morand@orange.com; Ben Campbell > Cc : dime@ietf.org > Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives anal= ysis > > Steve, > > SRD> Which is worse, an operator not being able to turn on DOIC because= > of other operators or breaking topology hiding? I don't know the answe= r but I do think it is a decision that should be made by the operator. > > I am not sure why should operator A not turn on DOIC feature in its own= network just because of operator B/C/D does not support it. > This is handled in the same way as operator A and B support the feature= but have no agreement to share the overload report. And hence based on c= onfiguration host in operator A's network ensures that messages going to = operator B does not contain overload report. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Thursday, August 21, 2014 9:01 PM > To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell > Cc: dime@ietf.org > Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives ana= lysis > > Nirav, > > Thanks for the detailed response. Please see my responses inline. > > Steve > > On 8/20/14, 11:43 AM, Nirav Salot (nsalot) wrote: >> Steve, >> >> You are proposing a change (minor or not) for a problem which does not= >> exist (in my view at least) since the use case is >> - The operator has enabled overload feature in his network and has not= >> upgraded one of the proxy >> - The operator has "forgotten" that the proxy which is not upgraded is= >> doing topology hiding > SRD> It's not just about topology hiding. It's about anything that > requires changing the origin-host. > >> Or between two operators, they have entered into the agreement to shar= e the overload reports but have not bothered to upgrade all of their node= s and not done any basic testing before activating the overload feature. > SRD> I don't think we want to get into the situation where Operator A > has to wait to turn on overload control because Operator B has not yet > upgraded their network to support DOIC. >> So we are defining the solution for the above use cases. And the solut= ion you are suggesting it results in >> - The client ignoring the overload report and thus the operator finds = out that "he has forgotten to upgrade one of the proxy (which is doing to= pology hiding) with the overload feature". > SRD> I'm saying that in the real world strange things happen. Solution = 1 > mitigates the effect of mistakes being made. > > SRD> I'm not saying the client ignores the overload report. That is > clearly one option. I have suggested the behavior be up to local > policy. I see four options, others may see others: > > 1) Always ignore the overload report > 2) Always honor the overload report > 3) Conditionally honor the overload report -- Honor anything up to some= > percentage > 4) Adjusted percentage - learn the number of servers that exist behind > the OHMA and adjust the reduction percentage accordingly. >> Additionally, the solution breaks topology hiding feature itself and y= our justification is that "we haven't agreed requirement to not break thi= s feature!". > SRD> As pointed out by Dave, there are likely modifications to solution= > 1 that does not break topology hiding, if we think it is a requirement > to avoid that breakage. > > SRD> Which is worse, an operator not being able to turn on DOIC because= > of other operators or breaking topology hiding? I don't know the answe= r > but I do think it is a decision that should be made by the operator. >> I am sorry, but I don't see why we need any protocol based solution he= re. > SRD> This is where the difference of opinion exists. You are of the > opinion that operators never make mistakes and, as a result, we don't > need a protocol based solution. I am of the opinion that in the real > world strange things happen and a little bit of extra resiliency in the= > protocol is a good thing. >> It is simple matter operator knowing its network/deployment/nodes and = existing features and enabling new feature based on "this" knowledge. And= doing some basic testing/dry run before going live. >> 3GPP or IETF, if we start defining solution assuming that "but the ope= rator may have forgotten to do this or that", we are adding solutions in = our product which are simply overhead. >> >> Finally, we should be looking at the justification to have some soluti= on and not add some change just because it is minor. > SRD> No one is making that argument. I have articulated the > justification. I also pointed out that the cost of the solution is ver= y > small. Cost benefit analysis is a valid aspect of any design process. >> Regards, >> Nirav. >> >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Wednesday, August 20, 2014 9:56 PM >> To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell >> Cc: dime@ietf.org >> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives an= alysis >> >> Nirav, >> >> Can you please be more specific about which of the explanations you do= n't agree with? >> >> I agree we can't completely ignore the way that Diameter is being used= =2E >> >> We should also be avoiding a solution that leaves open the possibility= of significant under utilization of Diameter network resources. We have= a stated requirement that the solution must not result in under utilizat= ion. >> >> I must admit I'm surprised at the response the proposal is getting. It= is a very minor change that makes the protocol more resilient. >> >> Steve >> >> On 8/20/14, 10:59 AM, Nirav Salot (nsalot) wrote: >>> Steve, >>> >>> I don't agree with your explanations. >>> >>> Additionally, we may not have explicit requirement to make DOIC work = in the face of topology hiding but that does not mean that "DOIC can brea= k any existing feature - be it topology hiding - and that's fine!". >>> >>> Regards, >>> Nirav. >>> >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Wednesday, August 20, 2014 9:24 PM >>> To: Nirav Salot (nsalot); lionel.morand@orange.com; Ben Campbell >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >>> analysis >>> >>> Nirav, >>> >>> Please see my comments inline. >>> >>> Steve >>> >>> On 8/20/14, 1:21 AM, Nirav Salot (nsalot) wrote: >>>> I agree with Lionel on multiple accounts. >>>> I don't see any value in alternative 1. In fact, as I had already in= dicated, the alternative 1 breaks one or more of existing feature and hen= ce it is not a solution by itself. >>> SRD> The value is that, through a protocol solution, we can make it >>> possible to prevent a complete shutdown of all traffic through a OHMA= =2E >>> It might be a small probability, but it is > 0, the impact is signifi= cant and the cost of the proposed protocol solution is extremely small. >>> >>> SRD> I'm assuming that the breakage you are talking about is that the= >>> proposal does allow for topology information to leak across operator = boundaries. This is true, however, we do not, however, have a requiremen= t to make DOIC work in the face of topology hiding. Are there other exis= ting features that you are concerned about? >>>> Additionally, like any other feature, the operator does not simply e= nable this feature in their network without considerable planning, lab an= d field testing. And this is true for between two operators as well - whe= re the bigger issue is whether to expose the overload information between= two PLMNs or not. >>> SRD> We are designing DOIC for Diameter usage in general, not just >>> 3GPP. I agree that this scenario is unlikely in a 3GPP environment, = at least for well disciplined operators that have extensive testing as yo= u point out. I don't, however, think we can make that assumption across = all uses of Diameter. That's one of the reasons why we have requirements= stating that the solution should not rely on configuration. >>>> So I don't see the need to have protocol based solution to help oper= ator debug "what they have forgotten about their network". >>> SRD> As has been pointed out multiple times, this is not just about >>> SRD> the >>> operator's own network. The negative impacts can result from another= operator not upgrading their agents to support DOIC. >>> >>> SRD> I look at this as a low cost insurance policy. It doesn't hurt >>> anything to add this small change and it helps prevent would could be= a major outage. >>>> Regards, >>>> Nirav. >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of >>>> lionel.morand@orange.com >>>> Sent: Tuesday, August 19, 2014 8:57 PM >>>> To: Steve Donovan; Ben Campbell >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Non-DOIC Origin-Host Munging agent alternatives >>>> analysis >>>> >>>> Hi Steve, >>>> >>>> If you decide to deploy a proxy modifying the origin-host, it would = be for some specific purposes in a given context. If the context has chan= ged, you will have to reconsider the whole mechanism. And it is not only = related to DOIC. >>>> If not done, this is what I'm calling a bad design: it is not only a= bout the implementation of the product itself, it is also about how this = product is used in the operational network. >>>> And I don't buy the argument that an operator might have forgotten t= hat a proxy modifying origin-host would have been deployed in the network= before the introduction of DOIC. >>>> >>>> About alt 1: >>>> >>>>>>>>>> 1) Attribution of overload reports. >>>>>>>>>> - Add diameter-id of the node that is overloaded into t= he OC-OLR AVP. >>>>>>>>>> - Reacting node always uses the diameter-id in the OC-O= LR report when applying abatement algorithm logic. >>>>>>>>>> - Reacting node detects when there is a difference betw= een the diameter-id in the OC-OLR report and in the Origin-Host AVP. Whe= n there is a difference, the reacting node should report on the condition= (event/alarm). Local policy would determine if the reacting node honors= the overload report or ignores the overload report. >>>> The following question still remain not answered: if the proxy repla= ces the origin-host A by origin-host B, the Diameter nodes receiving the = answers will "see" B as sender of the answer and will use this id when se= nding new requests with origin-host AVP. So can you remind me how exactly= the reacting node will use the Diameter-id received in the OLR? >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- >>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mard= i >>>> 19 ao=FBt 2014 16:46 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc : >>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent >>>> alternatives analysis >>>> >>>> Lionel, >>>> >>>> More inline. >>>> >>>> Steve >>>> >>>> On 8/19/14, 8:40 AM, lionel.morand@orange.com wrote: >>>>> Hi Steve, >>>>> >>>>> See below. >>>>> >>>>> Regards, >>>>> >>>>> Lionel >>>>> >>>>> -----Message d'origine----- >>>>> De : Steve Donovan [mailto:srdonovan@usdonovans.com] Envoy=E9 : mar= di >>>>> 19 ao=FBt 2014 13:41 =C0 : MORAND Lionel IMT/OLN; Ben Campbell Cc := >>>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agent= >>>>> alternatives analysis >>>>> >>>>> Lionel, >>>>> >>>>> There are two primary reasons that I think option 1 is important: >>>>> >>>>> 1) This scenario can result in significant under utilization of res= ources, to the extreme of completely shutting down all traffic to the ser= vers behind the Origin-Host Munging Agent (OHMA). >>>>> >>>>> 2) It gives operates a way to detect the unplanned or forgotten ins= tance of the OHMA. >>>>> >>>>> Being able to prevent number 1 is enough reason for me to add the v= ery small amount of additional protocol machinery we are talking about. >>>>> >>>>> [LM] And I disagree. >>>>> >>>>> More inline. >>>>> [LM] same >>>>> >>>>> Steve >>>>> >>>>> On 8/19/14, 4:48 AM, lionel.morand@orange.com wrote: >>>>>> Because a a gent modifying the Origin-host can only be a proxy and= a proxy is by definition compliant with the application supporting the n= ew OLR-related AVPs, everything else is out of scope of the standardizati= on. >>>>> SRD> I don't understand this argument. It is perfectly valid for a= >>>>> client or server to advertise support for an application and not al= so support DOIC. Why do you imply that it would be different for an agen= t? >>>>> [LM] A proxy that would modify the origin-host without taking into = account the possible use of this origin-host at the application would be = a badly-designed proxy and should not be used in operational network. >>>> SRD2> Consider the following timeline: >>>> >>>> Date - Event: >>>> >>>> Sometime in 2011 - Operator installs an agent to do topology hiding = or load balancing or some other function and the agent modifies the origi= n-host AVP as part of its logic. In 2011 this works perfectly well for a= ll applications handled by the agent. >>>> >>>> Sometime in 2015 - The IETF publishes the DOIC specification. >>>> >>>> Are you asserting that the agent deployed in 2011 was badly designed= because it did not anticipate the DOIC solution published four years lat= er? >>>>>> Moreover, the real added-value of the addition of the diameter-id = in the OLR does not seem so clear. >>>>> SRD> See above. >>>>> [LM] still unclear >>>> SRD2> Detection of the fact that an OHMA exists so that something >>>> intelligent can be done before it results in a total shutdown of the= Diameter network. >>>>>> Finally, we have agreed that the basic mechanism proposed in the d= raft may not cover all the use cases (existing or future) and can be enha= nced if required, with or without the need for a IETF standard action. >>>>> SRD> The reasons so far for deferring functionality was because it >>>>> SRD> would >>>>> add risk to the schedule for finishing the core DOIC solution. Tha= t is not the case here. We have a very small change to the specification= that addresses multiple requirements. >>>>> [LM] is there any clear description of what will be the use of this= info by the reacting node? if the proxy replaces the origin-host A by or= igin-host B, the Diameter nodes receiving the answers will "see" B as sen= der of the answer and will use this id when sending new requests with ori= gin-host AVP. So can you remind me how exactly the reacting node will use= the Diameter-id received in the OLR? >>>> SRD> Scroll down an look at the details behind alternative 1. >>>>>> For all these reasons, I would recommend not to add this Diameter-= id in the OLR and to assume that the Origin-host is not changed by agent = in the path of the Diameter messages. Some extra text could also be added= to clarify that proxies modifying the Origin-host would have to be upgra= ded to manage consistently the OLR received in Diameter application messa= ges. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Lionel >>>>>> >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbel= l >>>>>> Envoy=E9 : mardi 19 ao=FBt 2014 03:42 =C0 : Steve Donovan Cc : >>>>>> dime@ietf.org Objet : Re: [Dime] Non-DOIC Origin-Host Munging agen= t >>>>>> alternatives analysis >>>>>> >>>>>> I support Alternative 1, but I'm not sure it's a complete solution= =2E >>>>>> >>>>>> As Nirav pointed out, it has the potential to leak topology inform= ation past a topology hiding proxy. (Unless we can come up with some attr= ibution scheme that is not based on Diameter Identity or IP Address.) It = may be reasonable, to do this, but we would need some guidance to warn op= erators that this may happen if they enable DOIC across a non-supporting,= topology-hiding proxy. It would become the operator's choice to decide w= hich is more important. >>>>>> >>>>>> The part I find unsatisfying, is what would happen if you had some= paths that supported DOIC (or did not do topology hiding), and some path= s that don't support DOIC also do topology hiding. This could become a pr= etty big administrative hit, and violates the spirit and letter of our re= quirement to avoid adding lots of configuration work. >>>>>> >>>>>> OTOH, if we had a mechanism where servers could detect the existen= ce of a non-DOIC, topology-hiding proxy, this could be at least partially= automated. I can think of multiple ways we could make it possible to tel= l if an immediate peer supports DOIC, but not so much for non-adjacent no= des. >>>>>> >>>>>> On Aug 18, 2014, at 5:01 PM, Steve Donovan wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> My recommendation on this alternative 1 as it give operators the = ability to discover when there is an issue associated with "Origin-Host M= unging" agents. The operators can then take any administrative action ne= cessary to fix the issue. It is also a more general solution that does n= ot rely on one industries interop procedures. >>>>>>> >>>>>>> If we can get agreement on this then we can start making progress= on the remainder of the document. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 8/12/14, 3:05 PM, Steve Donovan wrote: >>>>>>>> Are there other thoughts on the pros and cons of the three propo= sals for resolution of issue #66? >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> On 8/8/14, 1:43 PM, Ben Campbell wrote: >>>>>>>>> On Aug 8, 2014, at 9:48 AM, Steve Donovan wrote: >>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> The issue with pre-DOIC agents changing origin-host was been d= iscussed in this thread: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07618.htm= l >>>>>>>>>> >>>>>>>>>> One example of the impact of the issue is defined in this mess= age: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/msg07660.htm= l >>>>>>>>>> >>>>>>>>>> So far three solutions have been discussed for this issue: >>>>>>>>>> >>>>>>>>>> 1) Attribution of overload reports. >>>>>>>>>> - Add diameter-id of the node that is overloaded into t= he OC-OLR AVP. >>>>>>>>>> - Reacting node always uses the diameter-id in the OC-O= LR report when applying abatement algorithm logic. >>>>>>>>>> - Reacting node detects when there is a difference betw= een the diameter-id in the OC-OLR report and in the Origin-Host AVP. Whe= n there is a difference, the reacting node should report on the condition= (event/alarm). Local policy would determine if the reacting node honors= the overload report or ignores the overload report. >>>>>>>>> I think the last entry is worth further discussion, but it's pr= obably more important to make a high level decision first. But, at risk o= f getting ahead of myself: I have trouble imagining a situation where hon= oring the overload report will be harmful, since if there is an interveni= ng OHMA, the reacting node will not likely have any host-routed requests = to the diameter-id from the OLR. OTOH, I have trouble imagining where hon= oring the report would be useful, for the same reason. >>>>>>>>> >>>>>>>>>> 2) Configuration in operator's networks to turn off origin-hos= t munging behavior until the agent is upgraded to support DOIC. >>>>>>>>>> >>>>>>>>>> 3) Configuration of reporting nodes to not send overload repor= ts, either universally or for transactions that cross the origin-host mun= ging agent. >>>>>>>>>> >>>>>>>>>> I've compiled a starting point for a pros and cons analysis of= the three approaches. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> Option 1 Pros: >>>>>>>>>> ------------ >>>>>>>>>> - Gives operators a mechanism to detect when there is a non-DO= IC origin-host-munging agent in the path of a transaction. >>>>>>>>>> - Gives operators ability to manage the under utilization issu= e caused by the non-DOIC agent. >>>>>>>>>> - Gives operators the ability to keep features requiring origi= n-host munging turned on while DOIC is rolled out. >>>>>>>>>> - Leaves the determination of which action to take in this sce= nario (honor or ignore overload reports) to operator policy. >>>>>>>>>> - Addresses RFC 7068 requirement #6 on minimizing the amount o= f configuration required. >>>>>>>>>> - Addresses RFC 7068 requirement #12 on minimizing the impact = of a single node overload on the traffic handled by other nodes in the ne= twork. >>>>>>>>>> - Addresses RFC 7068 requirement #17 on minimizing the impact = of overload in a mixed DOIC environment on the overall capacity of the ne= twork. >>>>>>>>> Specifically, it complies with the MUST NOT make things worth c= lause, but does not comply with the SHOULD reduce overload clause. >>>>>>>>> >>>>>>>>>> Option 1 Cons: >>>>>>>>>> ------------- >>>>>>>>>> - Requires additional protocol machinery (minimal) >>>>>>>>>> - Does not completely fix the effects of non-DOIC agent on >>>>>>>>>> overload control >>>>>>>>> One additional con is that, if the OHMA is there for the purpos= es of true topology hiding, the identity in the OLR may leak topology inf= ormation. >>>>>>>>> >>>>>>>>>> Option 2 Pros: >>>>>>>>>> ------------ >>>>>>>>>> - Does not require additional protocol machinery >>>>>>>>>> - Does the best job of three alternatives in allowing for >>>>>>>>>> management of overload conditions >>>>>>>>>> >>>>>>>>>> Option 2 Cons: >>>>>>>>>> ------------ >>>>>>>>>> - Requires the operator to lose any functionality enabled by >>>>>>>>>> the non-DOIC agent until all agents have been upgraded to >>>>>>>>>> support DOIC >>>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>>> - There is not way to determine if all non-DOIC origin-host mu= nging behavior has been turned off until an overload event happens, with = potential to have significant negative effects until the offending agent = can be found and the behavior turned off. >>>>>>>>>> - Not always possible, as operator doesn't always have control= over non-DOIC agent as it might be in another operators network. Proposa= l to address this through interop agreements but while this might work in= 3GPP scenarios, not all Diameter deployments are 3GPP driven. >>>>>>>>> Since you mentioned the 7068 requirements in the cons for optio= n >>>>>>>>> 1, it makes sense to mention them for others. This one misses o= n >>>>>>>>> 6, but seems okay for 12 and 17. (I guess we should have had a= >>>>>>>>> requirement about not interfering with existing network feature= s. >>>>>>>>> If we had that, Option 2 would not comply.) >>>>>>>>> >>>>>>>>>> Option 3 Pros: >>>>>>>>>> ------------ >>>>>>>>>> - Does not require additional protocol machinery >>>>>>>>>> - Gives operators the ability to keep features requiring origi= n-host munging turned on while DOIC is rolled out. >>>>>>>>> For very limited definitions of "rolled out." >>>>>>>>> >>>>>>>>>> Option 3 Cons: >>>>>>>>>> ------------ >>>>>>>>>> - Requires extra configuration (against requirement #6) >>>>>>>>>> - Likely requires extra development in the reporting node that= >>>>>>>>>> would not otherwise be needed (ability to limit where overload= >>>>>>>>>> reports are sent) >>>>>>>>>> - Not necessarily easy to determine in advance where which >>>>>>>>>> requests will traverse a the non-DOIC agent >>>>>>>>>> - Limits ability of operator to fully control overload >>>>>>>>>> >>>>>>>>> Seems to miss req 6 even worse than for option 2. Misses 17 in = a similar way as option 1. Partially misses 34. >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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= >>>>>> 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 d= etruire ainsi que les pieces jointes. Les messages electroniques etant su= sceptibles d'alteration, Orange decline toute responsabilite si ce messag= e 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 n= ot be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender= and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> >>>>> ___________________________________________________________________= _ >>>>> _ _ ___________________________________________________ >>>>> >>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>> ce message par erreur, veuillez le signaler a l'expediteur et le de= truire ainsi que les pieces jointes. Les messages electroniques etant sus= ceptibles d'alteration, Orange decline toute responsabilite si ce message= a ete altere, deforme ou falsifie. Merci. >>>>> >>>>> This message and its attachments may contain confidential or >>>>> privileged information that may be protected by law; they should no= t be distributed, used or copied without authorisation. >>>>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>>>> As emails may be altered, Orange is not liable for messages that ha= ve been modified, changed or falsified. >>>>> Thank you. >>>>> >>>>> >>>> ____________________________________________________________________= _ >>>> _ ___________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations c= onfidentielles ou privilegiees et ne doivent donc pas etre diffuses, expl= oites ou copies sans autorisation. Si vous avez recu ce message par erreu= r, veuillez le signaler a l'expediteur et le detruire ainsi que les piece= s jointes. Les messages electroniques etant susceptibles d'alteration, Or= ange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privile= ged information that may be protected by law; they should not be distribu= ted, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender a= nd delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that hav= e 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 > From nobody Wed Sep 3 07:02:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9221A0331 for ; Wed, 3 Sep 2014 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z8F-ayVE9bZ for ; Wed, 3 Sep 2014 07:02:21 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBFB1A0344 for ; Wed, 3 Sep 2014 07:02:11 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51700 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPB8R-0002c6-Q4; Wed, 03 Sep 2014 07:02:10 -0700 Message-ID: <54071F5F.1080503@usdonovans.com> Date: Wed, 03 Sep 2014 09:02:07 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Ben Campbell References: <53FF4A17.9050707@usdonovans.com> <95D175DE-C80C-4690-95D8-14ABC6393A38@nostrum.com> <087A34937E64E74E848732CFF8354B920980ECBA@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980ECBA@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/86153B2LMDE1uv_p77Ebk73eLys Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 14:02:23 -0000 Maria Cruz, I don't have the same interpretation. A peer has a direct connection to the client. If a client is connected to multiple agents then it can be configured to have multiple routes to the same destination-host. If it gets a TOO_BUSY from one of these routes than it is supposed to attempt to send the request to the other route. The new error response code would prevent this attempt to send the request to the alternative route as the client has already been told that the server is overloaded. I also agree with Nirov that having the new error response improves the operators ability to fine tune DOIC usage. Steve On 9/1/14, 4:21 PM, Maria Cruz Bartolome wrote: > Dear JJ, all, > > My understanding is that "alternate peer" in the TOO_BUSY description is interpreted as either a new destination_host, or a new server that provides service to the same realm. > Then, I think that already the standardized behavior for a reacting node when it receives TOO_BUSY may be enough. It is not explicitly mentioned that retransmissions to the same "peer" should be avoid, but a different action is requested. > Therefore, I am not sure we really need to define a new error, just to request the reacting node to throttle if required, since in my opinion this is already implied by TOO_BUSY description by "SHOULD". If this attempt is not possible or not successful (for any reason), then reacting node will throttle this request. > > As a conclusion, in my opinion, we do not need a new error. If you do not agree nowadays TOO_BUSY description is enough we could extend/clarify this description, either updating RFC or with new additional guidelines. > Apart from that, take into account TOO_BUSY is already an indication of overload, and this is part of the main RFC, then if we need this requires some clarification, I think this should not be constraint to the new DOIC draft. > > Cheers > /MCruz > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Sent: viernes, 29 de agosto de 2014 10:38 > To: Ben Campbell; Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] Proposal for new error response for DOIC > > > To come back on my point 2) , and reviewing the definition of Diameter too busy in RFC 6733. > DIAMETER_TOO_BUSY 3004 > When returned, a Diameter node SHOULD attempt to send the message > to an alternate peer. This error MUST only be used when a > specific server is requested, and it cannot provide the requested > service > > Does it mean that the request is sent to the same specific server but via an alternate path (the request contains the same Realm and host destinations AVP but is sent to another peer (another DA) , or can the alternate peer corresponds to another server (so another destination host). According to the understanding, this impacts my Point 2) remarks > > Best regards > > JJacques > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : vendredi 29 août 2014 09:59 À : Ben Campbell; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] Proposal for new error response for DOIC > > Dear all > > A few remarks > > 1) I am also questioning about the backward compatibility case where a DA is acting on behalf of a non DOIC client. > The solution Steve proposes , to my view, also work in this case: if the DA throttles a request, it will generate a Diameter too busy to the client, so with the possible consequence that the non DOIC client do a retry to an alternate destination. But we cannot avoid it, this is the non DOIC client existing behavior. > In any case we should avoid to send a new Diameter error to a non DOIC client as it can result to a non predictable behavior. > > Among the possible solutions, one is to continue to use Diameter to busy in all cases but with, in addition, a new AVP (a "DOIC diagnostic" AVP) which means message throttled in a DOIC case, which is generated by the DOIC reporting node, supported by a DOIC reacting node (which will not do retry to another destination) and ignored by a non DOIC client. This AVP may be in the future take other values if needed. > > 2) some remark about the new retry. > - I think a DA can do a retry in the case it has received a realm only request (without destination host), and if not successful, will sent the new diameter error to the client. But if instead, the client had received a classical Diameter too busy, it will also not do a retry to another destination (as it only knows the realm, but not the server), so Diameter too busy seems here acceptable, isn't it? > - If the client has sent a request with a Destination host, which is rejected by the reporting node (so with the new Diameter error) I do not think that a DA can do a retry to another destination host (as the client has requested a specific Destination host). Am I wrong here? But the client may eventually do a retry towards another destination host, according to the application case, so not so in line with the meaning of the new Diameter error requesting no retry. > - a server rejecting a request, will generate the new Diameter error, but the intermediate DA receiving this error may nevertheless do a retry to another destination a retry, so the meaning of the new Diameter error does not always mean "no retry" for a reacting node. > To have your view on these remarks. > > Best raegrds. > > JJacques > > > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoyé : jeudi 28 août 2014 21:57 À : Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] Proposal for new error response for DOIC > > I agree with doing this. > > But I'm also concerned that the backwards compatibility issue you mention means that this doesn't help in what is potentially the biggest use case for throttling at an agent. that is, an agent throttling on behalf of a non-supporting client. > > One approach would be to define DIAMETER_THROTTLED in a separate update to RFC 6733, in hopes that people who aren't ready to fully support DOIC might at least support the new error. (Yeah, I know that's a long shot.) Another might be to write some additional (BCP?) guidance on how clients should handle TOO_BUSY. > > On Aug 28, 2014, at 10:26 AM, Steve Donovan wrote: > >> All, >> >> One of the open issues is the DOIC behavior when a DOIC node rejects a request as a result of an overload condition. >> >> Today, the logical error response would be the DIAMETER_TOO_BUSY response. The issue with this behavior is that it can result in the client retrying the request to an alternative peer. >> >> The desired behavior for a request rejected because of overload throttling is the same as if the client, acting as a reacting node, throttled the request. As a result, the transaction should not be retried. >> >> The proposal is to define a new protocol error response code called DIAMETER_THROTTLED with the defined behavior that the request SHOULD be treated as a final response and SHOULD NOT be retried. >> >> This error response could be generated by agents acting as reacting nodes or by any reporting node. A server, for instance, that is in a severe overload condition might chose to reject some transactions with the DIAMETER_THROTTLED response if the current requested reduction included in the overload report is not sufficient. >> >> One issue with this proposal is backwards compatibility with Diameter nodes that do not support DOIC and, as such, would not understand the DIAMETER_THROTTLED response. The proposal to address this is to make the generation of the DIAMETER_THROTTLED error response conditional. This is an attempt at wording this conditional behavior: >> >> A DOIC node SHOULD use the DIAMETER_THROTTLED error response for transactions that are throttled and the DOIC node knows that there is a DOIC reacting node able to process the error response. The DOIC node generating the DIAMETER_THROTTLED error response determines that there there is a DOIC reacting node by the presence or absence of an OC-Supported-Features AVP in the request message for the transaction. >> >> If there is no OC-Supported-Features AVP in the request message for a transaction that is throttled then the DOIC node SHOULD send the DIAMETER_TO_BUSY response message. >> >> Assuming we get agreement on the proposal then I'll come back with detailed wording proposals for the DOIC specification. >> >> Regards, >> >> Steve >> >> >> _______________________________________________ >> 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 nobody Wed Sep 3 07:09:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EB11A032E for ; Wed, 3 Sep 2014 07:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QovbP5xNI8EI for ; Wed, 3 Sep 2014 07:09:45 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B701A030E for ; Wed, 3 Sep 2014 07:09:45 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51756 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPBFm-0002BL-Cd; Wed, 03 Sep 2014 07:09:44 -0700 Message-ID: <54072126.10409@usdonovans.com> Date: Wed, 03 Sep 2014 09:09:42 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , Maria Cruz Bartolome References: <11482_1409648429_5405872D_11482_12116_2_cip5taxlylt1fx0uv5bmo3mb.1409647933659@email.android.com> In-Reply-To: <11482_1409648429_5405872D_11482_12116_2_cip5taxlylt1fx0uv5bmo3mb.1409647933659@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rYXhj8ElVFRJDtroHXUp_7bT1Zg Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 14:09:47 -0000 JJ, To make sure that the proposed changes are well understood, can you please open a new issue and include the proposed changes. It would be helpful to have the before and after text in the issue write-up. This will give everyone a chance to review the wording prior to it being incorporated into the draft. Regards, Steve On 9/2/14, 4:00 AM, lionel.morand@orange.com wrote: > Hi, some comments below. > > Regards, > > Lionel > > Envoyé depuis mon Sony Xperia SP d'Orange > > ---- Maria Cruz Bartolome a écrit ---- > >> Dear JJ, all, >> >> See comments inline for some clarifications in the draft. >> Best regards >> /MCruz >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >> Sent: viernes, 29 de agosto de 2014 17:50 >> To: Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics >> >> Hi Steve and all >> >> M-bit on which I am cautious as often at the origin of interoperability issues, is mentioned in different places in the 03 draft (sections 4.3, 6 and 6.8) with rules according to the following: >> >> - when DOIC is supporting in an existing application, Mbit SHOULD not be set in DOIC AVPS (cf 6.8) >> - a new application can incorporate the DOIC mechanism as mandatory (cf 6), in this case the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set >> [MCruz] Fine > Lionel: OK > >> Some (non fundamental) remarks hereafter: >> a) We can have a new application where DOIC is not mandatory (when reading 6), but in 6.8 it is stated "when reused in newly defined Diameter applications, the DOC (note: to be DOIC) related AVPs SHOULD have the M-bit set". If DOIC is optional for this new application, Mbit is not set at least for the OC-Supported-features AVP in the requests, so to be ignored by a non DOIC supporting node receiving the request. May be to clarify. >> [MCruz] Agree to clarify in the draft > Lionel: optional to use does not mean optional to understand. So I think that the "SHOULD" is correct here for new application incorporating DOIC. > >> b) We have text with general statements about DOIC AVPs and some text in 6 (not contradictory) related to OC-Feature-Vector and OC-OLR . I think that, in 6, OC-Supported-Feature could be added, or even replace OC-Feature-Vector AVP which is a sub AVP of OC-Supported features and so already addressed in 4.3. >> [MCruz] Agree to use OC-Supported-Features > Lionel: OK > >> c) About "existing commands" in 6, sometimes an application which can be a new one can reuse an existing command defined in another application, the Mbit rule here is attached to the application, so, to avoid misinterpretation, may be better to write "commands of an existing application" in 6. >> [MCruz] Agree to be clarified. > Lionel: one small clarification: the M-bit setting is tight to the application AND the command. The same AVP can be with the M-bit set for one command and the M-bit for another command defined for the same application, as clarified in rfc6733. > >> d) About an intermediate proxy DA for an application but not supporting DOIC for this application (as not needed), how does it behave when transferring requests with OC-Supported-Features or OLR AVPs with Mbit set, is it clear that the DA transfers the DOIC AVPs and not reject them for AVP unsupported? >> [MCruz] If the proxy DA supports application X, when DOIC AVPs are sent in application X responses, with M-bit set, isn't that the application will reject them? > Lionel: a proxy used in the path of Diameter EAP exchanges between clients and remote servers will not reject commands because it is not performing EAP authentication itself. As soon as the DOIC AVPs are supported by the application, there is no reason for the proxy to reject them, except if there is a specific policy to do it. > >> e) in 4.3, it is written "NOT RECOMMENDED", I think better to write " M-bit in sub-AVPs SHOULD not be set" >> [MCruz] Agree > Lionel: even better: "SHOULD NOT" :-) > >> I hereafter remind the verison03 extracts mentioning M-bit In 4.3 >> More specifically, the sub-AVPs inside the >> OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. >> However, when overload control AVPs are piggybacked on top of an >> existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED >> >> in 6 >> When added to existing commands,both OC-Feature-Vector and OC-OLR >> AVPs SHOULD have the M-bit flag cleared to avoid backward >> compatibility issues >> >> A new application specification can incorporate the overload control >> mechanism specified in this document by making it mandatory to >> implement for the application and referencing this specification >> normatively. In such a case, the OC-Feature-Vector and OC-OLR AVPs >> reused in newly defined Diameter applications SHOULD have the M-bit >> flag set. However, it is the responsibility of the Diameter >> application designers to define how overload control mechanisms works >> on that application. >> >> In 6.8 >> As described in the Diameter base protocol [RFC6733], the M-bit >> setting for a given AVP is relevant to an application and each >> command within that application that includes the AVP. >> >> The Diameter overload control AVPs SHOULD always be sent with the >> M-bit cleared when used within existing Diameter applications to >> avoid backward compatibility issues. Otherwise, when reused in newly >> defined Diameter applications, the DOC related AVPs SHOULD have the >> M-bit set. >> >> Best regards >> >> JJacques >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoyé : jeudi 31 juillet 2014 20:49 À : Cc : dime@ietf.org; Ben Campbell Objet : Re: [Dime] Issue #48 - M-bit gives wrong sementics >> >> >> OK++; >> >> On Jul 31, 2014, at 8:41 PM, wrote: >> >>> Ok for me. >>> >>> Envoyé depuis mon Sony Xperia SP d'Orange >>> >>> ---- Ben Campbell a écrit ---- >>> >>> >>> No objection >>> >>> On Jul 31, 2014, at 11:52 AM, Steve Donovan wrote: >>> >>>> All, >>>> >>>> The proposal coming out of the meeting in Toronto was to close this issue with no changes to the existing text. >>>> >>>> Let me know if there are objections to doing so, otherwise I'll close the issue. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> ______________________________________________________________________ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> 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 confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Wed Sep 3 08:46:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E9E1A8709 for ; Wed, 3 Sep 2014 08:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1rJsgOc7NBg for ; Wed, 3 Sep 2014 08:46:10 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4F71A0466 for ; Wed, 3 Sep 2014 08:46:04 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:52200 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPCkx-0000zG-1s for dime@ietf.org; Wed, 03 Sep 2014 08:46:02 -0700 Message-ID: <540737B6.6010106@usdonovans.com> Date: Wed, 03 Sep 2014 10:45:58 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vpfsrPb77nSrCS9Z_E8lGOsRgpc Subject: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 15:46:16 -0000 All, I propose to add the following paragraph to the Solution Overview section. This would be immediately before the last paragraph and come after the paragraph that introduces the concept of report-types. This is part of the solution to issue #23 - DOIC behavior for realm overload Regards, Steve ---- A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that contain a Destination-Host AVP. The reacting node applies overload abatement on the host-routed requests with a Destination-Host value that matches the Diameter-ID for the overload report. A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of messages that do not contain a Destination-Host AVP and are, as a result, routed based on the Destination-Realm AVP. From nobody Wed Sep 3 11:58:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638F11A071C for ; Wed, 3 Sep 2014 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSX5ofMCr4OI for ; Wed, 3 Sep 2014 11:57:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905411A0718 for ; Wed, 3 Sep 2014 11:57:55 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s83Ivjt0089621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Sep 2014 13:57:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <54071F5F.1080503@usdonovans.com> Date: Wed, 3 Sep 2014 13:57:45 -0500 X-Mao-Original-Outgoing-Id: 431463465.039372-8cf8a111e226f724537871ef22e3adc3 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53FF4A17.9050707@usdonovans.com> <95D175DE-C80C-4690-95D8-14ABC6393A38@nostrum.com> <087A34937E64E74E848732CFF8354B920980ECBA@ESESSMB101.ericsson.se> <54071F5F.1080503@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R2cxYLsb8y_bjLBX9rwUbtQAPNs Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 18:57:58 -0000 The problem with DIAMETER_TOO_BUSY, is that the definition is unclear, = and different implementations have treated it differently. Steve is correct that for Diameter, "peer" is defined to be a diameter = host that you share a direct transport (TCP or SCTP) with. That is, it = means the next hop. But the definition of DIAMETER_TOO_BUSY says the = following: "When returned, a Diameter node SHOULD attempt to send the message to an alternate peer. This error MUST only be used when a specific server is requested, and it cannot provide the requested service. " This seems nonsensical. "Specific server is requested" seems to mean = that Destination-Host is present. Assuming the antecedent of "it" in = "... it cannot..." refers to that server, then sending to an alternate = peer will _never_ help. To further confuse things, RFC 3539 defines a "busy" message semantic = that means pretty much what Maria described, except that it means the = server is too busy for _any_ request, not just requests for a particular = service. I suspect Maria is right that the intent of DIAMETER_TOO_BUSY = was to provide the RFC 3539 "busy" semantic. But unfortunately, that's = not what the words say--as it is, it seems like a merger of "busy" and = "can't forward". As a result, implementors try to figure out what 6733 "really" meant, = and of course came up with different, non-interoperable interpretations. = For backwards compatibility, I think the best way to clarify = DIAMETER_TOO_BUSY is to deprecate it. On Sep 3, 2014, at 9:02 AM, Steve Donovan = wrote: > Maria Cruz, >=20 > I don't have the same interpretation. A peer has a direct connection = to the client. If a client is connected to multiple agents then it can = be configured to have multiple routes to the same destination-host. If = it gets a TOO_BUSY from one of these routes than it is supposed to = attempt to send the request to the other route. >=20 > The new error response code would prevent this attempt to send the = request to the alternative route as the client has already been told = that the server is overloaded. >=20 > I also agree with Nirov that having the new error response improves = the operators ability to fine tune DOIC usage. >=20 > Steve >=20 > On 9/1/14, 4:21 PM, Maria Cruz Bartolome wrote: >> Dear JJ, all, >>=20 >> My understanding is that "alternate peer" in the TOO_BUSY description = is interpreted as either a new destination_host, or a new server that = provides service to the same realm. >> Then, I think that already the standardized behavior for a reacting = node when it receives TOO_BUSY may be enough. It is not explicitly = mentioned that retransmissions to the same "peer" should be avoid, but a = different action is requested. >> Therefore, I am not sure we really need to define a new error, just = to request the reacting node to throttle if required, since in my = opinion this is already implied by TOO_BUSY description by "SHOULD". If = this attempt is not possible or not successful (for any reason), then = reacting node will throttle this request. >>=20 >> As a conclusion, in my opinion, we do not need a new error. If you do = not agree nowadays TOO_BUSY description is enough we could = extend/clarify this description, either updating RFC or with new = additional guidelines. >> Apart from that, take into account TOO_BUSY is already an indication = of overload, and this is part of the main RFC, then if we need this = requires some clarification, I think this should not be constraint to = the new DOIC draft. >>=20 >> Cheers >> /MCruz >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, = JEAN-JACQUES (JEAN-JACQUES) >> Sent: viernes, 29 de agosto de 2014 10:38 >> To: Ben Campbell; Steve Donovan >> Cc: dime@ietf.org >> Subject: Re: [Dime] Proposal for new error response for DOIC >>=20 >>=20 >> To come back on my point 2) , and reviewing the definition of = Diameter too busy in RFC 6733. >> DIAMETER_TOO_BUSY 3004 >> When returned, a Diameter node SHOULD attempt to send the = message >> to an alternate peer. This error MUST only be used when a >> specific server is requested, and it cannot provide the = requested >> service >>=20 >> Does it mean that the request is sent to the same specific server but = via an alternate path (the request contains the same Realm and host = destinations AVP but is sent to another peer (another DA) , or can the = alternate peer corresponds to another server (so another destination = host). According to the understanding, this impacts my Point 2) remarks >>=20 >> Best regards >>=20 >> JJacques >>=20 >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, = JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : vendredi 29 ao=FBt 2014 09:59 =C0 = : Ben Campbell; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] = Proposal for new error response for DOIC >>=20 >> Dear all >>=20 >> A few remarks >>=20 >> 1) I am also questioning about the backward compatibility case where = a DA is acting on behalf of a non DOIC client. >> The solution Steve proposes , to my view, also work in this case: = if the DA throttles a request, it will generate a Diameter too busy to = the client, so with the possible consequence that the non DOIC client do = a retry to an alternate destination. But we cannot avoid it, this is = the non DOIC client existing behavior. >> In any case we should avoid to send a new Diameter error to a non = DOIC client as it can result to a non predictable behavior. >>=20 >> Among the possible solutions, one is to continue to use Diameter to = busy in all cases but with, in addition, a new AVP (a "DOIC = diagnostic" AVP) which means message throttled in a DOIC case, which is = generated by the DOIC reporting node, supported by a DOIC reacting node = (which will not do retry to another destination) and ignored by a non = DOIC client. This AVP may be in the future take other values if needed. >>=20 >> 2) some remark about the new retry. >> - I think a DA can do a retry in the case it has received a realm = only request (without destination host), and if not successful, will = sent the new diameter error to the client. But if instead, the client = had received a classical Diameter too busy, it will also not do a retry = to another destination (as it only knows the realm, but not the server), = so Diameter too busy seems here acceptable, isn't it? >> - If the client has sent a request with a Destination host, which is = rejected by the reporting node (so with the new Diameter error) I do not = think that a DA can do a retry to another destination host (as the = client has requested a specific Destination host). Am I wrong here? But = the client may eventually do a retry towards another destination host, = according to the application case, so not so in line with the meaning of = the new Diameter error requesting no retry. >> - a server rejecting a request, will generate the new Diameter error, = but the intermediate DA receiving this error may nevertheless do a = retry to another destination a retry, so the meaning of the new Diameter = error does not always mean "no retry" for a reacting node. >> To have your view on these remarks. >> Best raegrds. >>=20 >> JJacques >> =20 >>=20 >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell = Envoy=E9 : jeudi 28 ao=FBt 2014 21:57 =C0 : Steve Donovan Cc : = dime@ietf.org Objet : Re: [Dime] Proposal for new error response for = DOIC >>=20 >> I agree with doing this. >>=20 >> But I'm also concerned that the backwards compatibility issue you = mention means that this doesn't help in what is potentially the biggest = use case for throttling at an agent. that is, an agent throttling on = behalf of a non-supporting client. >>=20 >> One approach would be to define DIAMETER_THROTTLED in a separate = update to RFC 6733, in hopes that people who aren't ready to fully = support DOIC might at least support the new error. (Yeah, I know that's = a long shot.) Another might be to write some additional (BCP?) guidance = on how clients should handle TOO_BUSY. >>=20 >> On Aug 28, 2014, at 10:26 AM, Steve Donovan = wrote: >>=20 >>> All, >>>=20 >>> One of the open issues is the DOIC behavior when a DOIC node rejects = a request as a result of an overload condition. >>>=20 >>> Today, the logical error response would be the DIAMETER_TOO_BUSY = response. The issue with this behavior is that it can result in the = client retrying the request to an alternative peer. >>>=20 >>> The desired behavior for a request rejected because of overload = throttling is the same as if the client, acting as a reacting node, = throttled the request. As a result, the transaction should not be = retried. >>>=20 >>> The proposal is to define a new protocol error response code called = DIAMETER_THROTTLED with the defined behavior that the request SHOULD be = treated as a final response and SHOULD NOT be retried. >>>=20 >>> This error response could be generated by agents acting as reacting = nodes or by any reporting node. A server, for instance, that is in a = severe overload condition might chose to reject some transactions with = the DIAMETER_THROTTLED response if the current requested reduction = included in the overload report is not sufficient. >>>=20 >>> One issue with this proposal is backwards compatibility with = Diameter nodes that do not support DOIC and, as such, would not = understand the DIAMETER_THROTTLED response. The proposal to address = this is to make the generation of the DIAMETER_THROTTLED error response = conditional. This is an attempt at wording this conditional behavior: >>>=20 >>> A DOIC node SHOULD use the DIAMETER_THROTTLED error response for = transactions that are throttled and the DOIC node knows that there is a = DOIC reacting node able to process the error response. The DOIC node = generating the DIAMETER_THROTTLED error response determines that there = there is a DOIC reacting node by the presence or absence of an = OC-Supported-Features AVP in the request message for the transaction. >>>=20 >>> If there is no OC-Supported-Features AVP in the request message for = a transaction that is throttled then the DOIC node SHOULD send the = DIAMETER_TO_BUSY response message. >>>=20 >>> Assuming we get agreement on the proposal then I'll come back with = detailed wording proposals for the DOIC specification. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>>=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 >>=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 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 3 11:59:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527F11A0ADE for ; Wed, 3 Sep 2014 11:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLkggTuubRt1 for ; Wed, 3 Sep 2014 11:59:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26561A0AA3 for ; Wed, 3 Sep 2014 11:59:09 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s83Ix72G089724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Sep 2014 13:59:09 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53FF4A17.9050707@usdonovans.com> Date: Wed, 3 Sep 2014 13:59:07 -0500 X-Mao-Original-Outgoing-Id: 431463547.652872-f8fb5f0d32bea2bed3c994a982e6e7b2 Content-Transfer-Encoding: quoted-printable Message-Id: <1565C1F1-A5DB-4245-BFC7-E0045E917C37@nostrum.com> References: <53FF4A17.9050707@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/19CpVk-60glPl8KvDdHohfu3p5U Cc: "dime@ietf.org" Subject: Re: [Dime] Proposal for new error response for DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 18:59:16 -0000 Would DIAMETER_THROTTLED apply to future messages? Does it need a = "Retry-After" concept? On Aug 28, 2014, at 10:26 AM, Steve Donovan = wrote: > All, >=20 > One of the open issues is the DOIC behavior when a DOIC node rejects a = request as a result of an overload condition. >=20 > Today, the logical error response would be the DIAMETER_TOO_BUSY = response. The issue with this behavior is that it can result in the = client retrying the request to an alternative peer. >=20 > The desired behavior for a request rejected because of overload = throttling is the same as if the client, acting as a reacting node, = throttled the request. As a result, the transaction should not be = retried. >=20 > The proposal is to define a new protocol error response code called = DIAMETER_THROTTLED with the defined behavior that the request SHOULD be = treated as a final response and SHOULD NOT be retried. >=20 > This error response could be generated by agents acting as reacting = nodes or by any reporting node. A server, for instance, that is in a = severe overload condition might chose to reject some transactions with = the DIAMETER_THROTTLED response if the current requested reduction = included in the overload report is not sufficient. >=20 > One issue with this proposal is backwards compatibility with Diameter = nodes that do not support DOIC and, as such, would not understand the = DIAMETER_THROTTLED response. The proposal to address this is to make = the generation of the DIAMETER_THROTTLED error response conditional. = This is an attempt at wording this conditional behavior: >=20 > A DOIC node SHOULD use the DIAMETER_THROTTLED error response for = transactions that are throttled and the DOIC node knows that there is a = DOIC reacting node able to process the error response. The DOIC node = generating the DIAMETER_THROTTLED error response determines that there = there is a DOIC reacting node by the presence or absence of an = OC-Supported-Features AVP in the request message for the transaction. >=20 > If there is no OC-Supported-Features AVP in the request message for a = transaction that is throttled then the DOIC node SHOULD send the = DIAMETER_TO_BUSY response message. >=20 > Assuming we get agreement on the proposal then I'll come back with = detailed wording proposals for the DOIC specification. >=20 > Regards, >=20 > Steve >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 3 12:07:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D87F1A0B82 for ; Wed, 3 Sep 2014 12:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUdrfZUHeR0q for ; Wed, 3 Sep 2014 12:07:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1789E1A0B14 for ; Wed, 3 Sep 2014 12:07:25 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s83J7N2N090434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Sep 2014 14:07:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <540737B6.6010106@usdonovans.com> Date: Wed, 3 Sep 2014 14:07:22 -0500 X-Mao-Original-Outgoing-Id: 431464042.795804-60712fab00b9b50d720d9183e4b87fd2 Content-Transfer-Encoding: quoted-printable Message-Id: <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> References: <540737B6.6010106@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qpiO5c182Q-8aGcC67pSvF0s8YM Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 19:07:36 -0000 I agree with putting text similar to those paragraphs in, but I don't = think they are quite right on the distinction between host-routed and = realm-routed. I think "host routed" requests include any request where the sender has = a priori knowledge that the request will land on a particular server. = The presence of Destination-Host is the most obvious way to have that = knowledge.=20 Another way to have the knowledge would be when that host is a direct = peer to the reacting node, and the reacting nodes peer-selection = algorithm chooses that server. This case is a bit more flexible, in that = if the peer-selection algorithm allowed other alternatives, the = reacting-node could choose a different peer. It also allows nodes to = appropriately handle things like pseudo-sessions, correlated sessions, = etc, even if Destination-Host is not present. On Sep 3, 2014, at 10:45 AM, Steve Donovan = wrote: > All, >=20 > I propose to add the following paragraph to the Solution Overview = section. This would be immediately before the last paragraph and come = after the paragraph that introduces the concept of report-types. >=20 > This is part of the solution to issue #23 - DOIC behavior for realm = overload >=20 > Regards, >=20 > Steve >=20 > ---- >=20 > A report of type host is sent to indicate the overload of a specific = server for the application-id indicated in the transaction. When = receiving an OLR of type host, a reacting node applies overload = abatement to what is referred to in this document as host-routed = requests. This is the set of requests that contain a Destination-Host = AVP. The reacting node applies overload abatement on the host-routed = requests with a Destination-Host value that matches the Diameter-ID for = the overload report. >=20 > A report type of realm is sent to indicate the overload of all servers = in a realm for the application-id. When receiving an OLR of type realm, = a reacting node applies overload abatement to what is referred to in = this document as realm-routed requests. This is the set of messages = that do not contain a Destination-Host AVP and are, as a result, routed = based on the Destination-Realm AVP. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 3 13:44:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967481A0AEB for ; Wed, 3 Sep 2014 13:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrfWBwb0mcMH for ; Wed, 3 Sep 2014 13:44:45 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D7A1A036C for ; Wed, 3 Sep 2014 13:44:45 -0700 (PDT) Received: from rrcs-71-40-216-75.sw.biz.rr.com ([71.40.216.75]:54473 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPHQ3-00059P-7D; Wed, 03 Sep 2014 13:44:44 -0700 Message-ID: <54077DBB.9090603@usdonovans.com> Date: Wed, 03 Sep 2014 15:44:43 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> In-Reply-To: <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WsQhAt98BReOBn4SxoN0ee2K21Q Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 20:44:46 -0000 Ben, You are correct. The definition for host routed needs to be as you indicate. Steve On 9/3/14, 2:07 PM, Ben Campbell wrote: > I agree with putting text similar to those paragraphs in, but I don't think they are quite right on the distinction between host-routed and realm-routed. > > I think "host routed" requests include any request where the sender has a priori knowledge that the request will land on a particular server. The presence of Destination-Host is the most obvious way to have that knowledge. > > Another way to have the knowledge would be when that host is a direct peer to the reacting node, and the reacting nodes peer-selection algorithm chooses that server. This case is a bit more flexible, in that if the peer-selection algorithm allowed other alternatives, the reacting-node could choose a different peer. It also allows nodes to appropriately handle things like pseudo-sessions, correlated sessions, etc, even if Destination-Host is not present. > > > On Sep 3, 2014, at 10:45 AM, Steve Donovan wrote: > >> All, >> >> I propose to add the following paragraph to the Solution Overview section. This would be immediately before the last paragraph and come after the paragraph that introduces the concept of report-types. >> >> This is part of the solution to issue #23 - DOIC behavior for realm overload >> >> Regards, >> >> Steve >> >> ---- >> >> A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that contain a Destination-Host AVP. The reacting node applies overload abatement on the host-routed requests with a Destination-Host value that matches the Diameter-ID for the overload report. >> >> A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of messages that do not contain a Destination-Host AVP and are, as a result, routed based on the Destination-Realm AVP. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Sep 3 14:14:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEE71A87B2 for ; Wed, 3 Sep 2014 14:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDqldVHIF-5L for ; Wed, 3 Sep 2014 14:14:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E7D1A88B6 for ; Wed, 3 Sep 2014 14:06:01 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s83L5xXu000774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Sep 2014 16:06:00 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <54077DBB.9090603@usdonovans.com> Date: Wed, 3 Sep 2014 16:05:58 -0500 X-Mao-Original-Outgoing-Id: 431471158.382943-d54100abc20a70ae0b4adc7260cb955a Content-Transfer-Encoding: quoted-printable Message-Id: References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bg5ek3_kfvjxA1oYUsewstxImJk Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 21:14:45 -0000 I think this could be fixed with the following change: Paragraph 1, last two sentences: This is the set of requests that the reacting node knows will be served = by a particular host, either due to the presence of a Destination-Host = AVP, or by some other local knowledge on the part of the reacting node. = The reacting node applies overload abatement on the host-routed requests = with that would be served by a host with a Diameter Identity that = matches the Diameter-Id from the overload report.=20 Paragraph 2, last sentence: This is the set of requests that are not host-routed as defined in the = previous paragraph. On Sep 3, 2014, at 3:44 PM, Steve Donovan = wrote: > Ben, >=20 > You are correct. The definition for host routed needs to be as you = indicate. >=20 > Steve >=20 > On 9/3/14, 2:07 PM, Ben Campbell wrote: >> I agree with putting text similar to those paragraphs in, but I don't = think they are quite right on the distinction between host-routed and = realm-routed. >>=20 >> I think "host routed" requests include any request where the sender = has a priori knowledge that the request will land on a particular = server. The presence of Destination-Host is the most obvious way to have = that knowledge. >>=20 >> Another way to have the knowledge would be when that host is a direct = peer to the reacting node, and the reacting nodes peer-selection = algorithm chooses that server. This case is a bit more flexible, in that = if the peer-selection algorithm allowed other alternatives, the = reacting-node could choose a different peer. It also allows nodes to = appropriately handle things like pseudo-sessions, correlated sessions, = etc, even if Destination-Host is not present. >>=20 >>=20 >> On Sep 3, 2014, at 10:45 AM, Steve Donovan = wrote: >>=20 >>> All, >>>=20 >>> I propose to add the following paragraph to the Solution Overview = section. This would be immediately before the last paragraph and come = after the paragraph that introduces the concept of report-types. >>>=20 >>> This is part of the solution to issue #23 - DOIC behavior for realm = overload >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> ---- >>>=20 >>> A report of type host is sent to indicate the overload of a specific = server for the application-id indicated in the transaction. When = receiving an OLR of type host, a reacting node applies overload = abatement to what is referred to in this document as host-routed = requests. This is the set of requests that contain a Destination-Host = AVP. The reacting node applies overload abatement on the host-routed = requests with a Destination-Host value that matches the Diameter-ID for = the overload report. >>>=20 >>> A report type of realm is sent to indicate the overload of all = servers in a realm for the application-id. When receiving an OLR of = type realm, a reacting node applies overload abatement to what is = referred to in this document as realm-routed requests. This is the set = of messages that do not contain a Destination-Host AVP and are, as a = result, routed based on the Destination-Realm AVP. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From nobody Thu Sep 4 01:23:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379561A6F8C for ; Thu, 4 Sep 2014 01:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfPjbImnMdoB for ; Thu, 4 Sep 2014 01:23:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0970B1A0089 for ; Thu, 4 Sep 2014 01:23:27 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s848NPZB004596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2014 08:23:25 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s848NNIT031247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 10:23:23 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Sep 2014 10:23:23 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 10:23:23 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposed additional wording in section 3. Solution Overview Thread-Index: AQHPx6pWID17vLMGAU2Hdl6MH+RhV5vvvuuAgAAF8ACAAN5EwA== Date: Thu, 4 Sep 2014 08:23:23 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4030 X-purgate-ID: 151667::1409819005-000023E0-791072B1/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iWYSr4AY3yugZ1aroPSpJQC4mRY Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 08:23:34 -0000 Ben, second sentence should read "The reacting node applies overload abatement on those host-routed requests= which the reacting node knows will be served by the server that matches th= e Diameter-Id from the overload report." Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, September 03, 2014 11:06 PM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view I think this could be fixed with the following change: Paragraph 1, last two sentences: This is the set of requests that the reacting node knows will be served by = a particular host, either due to the presence of a Destination-Host AVP, or= by some other local knowledge on the part of the reacting node. The react= ing node applies overload abatement on the host-routed requests with that w= ould be served by a host with a Diameter Identity that matches the Diameter= -Id from the overload report.=20 Paragraph 2, last sentence: This is the set of requests that are not host-routed as defined in the prev= ious paragraph. On Sep 3, 2014, at 3:44 PM, Steve Donovan wrote: > Ben, >=20 > You are correct. The definition for host routed needs to be as you indic= ate. >=20 > Steve >=20 > On 9/3/14, 2:07 PM, Ben Campbell wrote: >> I agree with putting text similar to those paragraphs in, but I don't th= ink they are quite right on the distinction between host-routed and realm-r= outed. >>=20 >> I think "host routed" requests include any request where the sender has = a priori knowledge that the request will land on a particular server. The p= resence of Destination-Host is the most obvious way to have that knowledge. >>=20 >> Another way to have the knowledge would be when that host is a direct pe= er to the reacting node, and the reacting nodes peer-selection algorithm ch= ooses that server. This case is a bit more flexible, in that if the peer-se= lection algorithm allowed other alternatives, the reacting-node could choos= e a different peer. It also allows nodes to appropriately handle things lik= e pseudo-sessions, correlated sessions, etc, even if Destination-Host is no= t present. >>=20 >>=20 >> On Sep 3, 2014, at 10:45 AM, Steve Donovan wr= ote: >>=20 >>> All, >>>=20 >>> I propose to add the following paragraph to the Solution Overview secti= on. This would be immediately before the last paragraph and come after the= paragraph that introduces the concept of report-types. >>>=20 >>> This is part of the solution to issue #23 - DOIC behavior for realm ove= rload >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> ---- >>>=20 >>> A report of type host is sent to indicate the overload of a specific se= rver for the application-id indicated in the transaction. When receiving a= n OLR of type host, a reacting node applies overload abatement to what is r= eferred to in this document as host-routed requests. This is the set of re= quests that contain a Destination-Host AVP. The reacting node applies over= load abatement on the host-routed requests with a Destination-Host value th= at matches the Diameter-ID for the overload report. >>>=20 >>> A report type of realm is sent to indicate the overload of all servers = in a realm for the application-id. When receiving an OLR of type realm, a = reacting node applies overload abatement to what is referred to in this doc= ument as realm-routed requests. This is the set of messages that do not co= ntain a Destination-Host AVP and are, as a result, routed based on the Dest= ination-Realm AVP. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Sep 4 01:26:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977D91A0020 for ; Thu, 4 Sep 2014 01:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn4ufQ9NwfDt for ; Thu, 4 Sep 2014 01:26:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD2F1A003B for ; Thu, 4 Sep 2014 01:26:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BME06971; Thu, 04 Sep 2014 08:26:26 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Sep 2014 09:26:25 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 16:26:16 +0800 From: "Shishufeng (Susan)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Proposed additional wording in section 3. Solution Overview Thread-Index: AQHPx6kBags4qWVN10+wxgqMX2CLrZvwnwqQ Date: Thu, 4 Sep 2014 08:26:15 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF67EDB@SZXEMA512-MBX.china.huawei.com> References: <540737B6.6010106@usdonovans.com> In-Reply-To: <540737B6.6010106@usdonovans.com> Accept-Language: en-GB, 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: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F258DF67EDBSZXEMA512MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Knbv9Ud7YreYa-1O5eS4cArm1Wk Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 08:26:31 -0000 --_000_26C84DFD55BC3040A45BF70926E55F258DF67EDBSZXEMA512MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Steve, As discussed before, most of 3GPP delegates prefer to have the report type = as optional. So apart from updating the AVP as optional in the other parts = of the draft, if we are going to add the following texts, I would propose t= o rephrase the first paragraph as follows: A report of type host can be sent to indicate the overload of a specific se= rver for the application-id indicated in the transaction. By default, the o= verload report is for a specific server. When receiving an OLR for a specif= ic server, a reacting node applies overload abatement to what is referred t= o in this document as host-routed requests. This is the set of requests tha= t contain a Destination-Host AVP. The reacting node applies overload abate= ment on the host-routed requests with a Destination-Host value that matches= the Diameter-ID for the overload report. Best Regards, Susan -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Wednesday, September 03, 2014 11:46 PM To: dime@ietf.org Subject: [Dime] Proposed additional wording in section 3. Solution Overview All, I propose to add the following paragraph to the Solution Overview section. = This would be immediately before the last paragraph and come after the par= agraph that introduces the concept of report-types. This is part of the solution to issue #23 - DOIC behavior for realm overloa= d Regards, Steve ---- A report of type host is sent to indicate the overload of a specific server= for the application-id indicated in the transaction. By default, the overl= oad report is for a specific server. , a reacting node applies overload aba= tement to what is referred to in this document as host-routed requests. Th= is is the set of requests that contain a Destination-Host AVP. The reactin= g node applies overload abatement on the host-routed requests with a Destin= ation-Host value that matches the Diameter-ID for the overload report. A report type of realm is sent to indicate the overload of all servers in a= realm for the application-id. When receiving an OLR of type realm, a reac= ting node applies overload abatement to what is referred to in this documen= t as realm-routed requests. This is the set of messages that do not contai= n a Destination-Host AVP and are, as a result, routed based on the Destinat= ion-Realm AVP. --_000_26C84DFD55BC3040A45BF70926E55F258DF67EDBSZXEMA512MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Steve,

 

As discussed before, most of= 3GPP delegates prefer to have the report type as optional. So apart from u= pdating the AVP as optional in the other parts of the draft, if we are goin= g to add the following texts, I would propose to rephrase the first paragraph as follows:

= A report of type host can be sent t= o indicate the overload of a specific server for the application-id indicat= ed in the transaction. By default, the over= load report is for a specific server. When receiving an OLR for a specific = server, a reacting node applies overload abatement to what is referr= ed to in this document as host-routed requests. This is the set of requests that contain a Destination-Host AVP.=   The reacting node applies overload abatement on the host-routed requ= ests with a Destination-Host value that matches the Diameter-ID for the ove= rload report.

 

Best Regards,

Susan

 

-----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, September 03, 2014 11:46 PM
To: dime@ietf.org
Subject: [Dime] Proposed additional wording in section 3. Solution Overview=

 

All,

 

I propose to add the followi= ng paragraph to the Solution Overview section.  This would be immediat= ely before the last paragraph and come after the paragraph that introduces = the concept of report-types.

 

This is part of the solution= to issue #23 - DOIC behavior for realm overload

 

Regards,

 

Steve

 

----

 

A report of type host is sen= t to indicate the overload of a specific server for the application-id indi= cated in the transaction. By default, the overload report is for a specific= server. , a reacting node applies overload abatement to what is referred to in this document as host-routed requests.=   This is the set of requests that contain a Destination-Host AVP.&nbs= p; The reacting node applies overload abatement on the host-routed requests= with a Destination-Host value that matches the Diameter-ID for the overload report.

 

A report type of realm is se= nt to indicate the overload of all servers in a realm for the application-i= d.  When receiving an OLR of type realm, a reacting node applies overl= oad abatement to what is referred to in this document as realm-routed requests.  This is the set of messages that = do not contain a Destination-Host AVP and are, as a result, routed based on= the Destination-Realm AVP.

 

 

--_000_26C84DFD55BC3040A45BF70926E55F258DF67EDBSZXEMA512MBXchi_-- From nobody Thu Sep 4 02:38:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1FA1A0203 for ; Thu, 4 Sep 2014 02:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3itaV9JxL02 for ; Thu, 4 Sep 2014 02:38:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3891F1A00F1 for ; Thu, 4 Sep 2014 02:38:10 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-a7-540832ff9365 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.27.21334.FF238045; Thu, 4 Sep 2014 11:38:08 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 11:38:07 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposed additional wording in section 3. Solution Overview Thread-Index: AQHPx6pVMo6MozDkWUWBR1co/pALFJvvvuuAgAAF8ACAAL1FgIAANa5Q Date: Thu, 4 Sep 2014 09:38:07 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980FA36@ESESSMB101.ericsson.se> References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RpfBmCPE4MNLfov5nafZLeb2rmCz 2NDEY7Hu7QomBxaPJUt+MnnM2vmExePn+qvsHqve9rEGsERx2aSk5mSWpRbp2yVwZRz5tJO1 oFW14vLZH8wNjN1yXYycHBICJhLLf7YyQdhiEhfurWfrYuTiEBI4yijxc88LZghnMaPE1+3X GUGq2ATsJC6dfsEEkhAR6GGUeDz3OFiCWUBZYvaOB+wgtrBAoMTbHwdZQWwRgSCJZ6tfs0DY bhIPv78Bq2ERUJG49xhiKK+Ar8SXX3OhtjUySfT//swGkuAUCJBYt/4XmM0IdN/3U2uYIJaJ S9x6Mh/qbgGJJXvOM0PYohIvH/9jhbAVJdqfNkAdpyOxYPcnNghbW2LZwtfMEIsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgbF2cMtv3R2M q187HmIU4GBU4uF98J89RIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1ME48/DdF9meGhdVpr6Qrdkx697asVDy/+FH4wvcWR7u7i2vSP15Tblid/s2X145n 0pyM7qkJvy7K77DkkZTUvC4ssk208IRCwous0w/+zOp2nFQ6z2jdqwfVn3eJNfDIrInadl6P Z9HRFxya6Rp/3bsMnx1RumXN6sP0LDfxzInsy63BF1PZYpVYijMSDbWYi4oTAV1/YlSWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jFM0fXmHrdNyFdIDb8kBfyoB_10 Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 09:38:13 -0000 Steve, Ben, Ulrich, What do you mean by " the server that matches the Diameter-Id from the over= load report "? It should be replaced by " the server that matches the Origin-Host AVP of t= he received message that contained the OC-OLR AVP" Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: jueves, 04 de septiembre de 2014 10:23 To: ext Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view Ben, second sentence should read "The reacting node applies overload abatement on those host-routed requests= which the reacting node knows will be served by the server that matches th= e Diameter-Id from the overload report." Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, September 03, 2014 11:06 PM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view I think this could be fixed with the following change: Paragraph 1, last two sentences: This is the set of requests that the reacting node knows will be served by = a particular host, either due to the presence of a Destination-Host AVP, or= by some other local knowledge on the part of the reacting node. The react= ing node applies overload abatement on the host-routed requests with that w= ould be served by a host with a Diameter Identity that matches the Diameter= -Id from the overload report.=20 Paragraph 2, last sentence: This is the set of requests that are not host-routed as defined in the prev= ious paragraph. On Sep 3, 2014, at 3:44 PM, Steve Donovan wrote: > Ben, >=20 > You are correct. The definition for host routed needs to be as you indic= ate. >=20 > Steve >=20 > On 9/3/14, 2:07 PM, Ben Campbell wrote: >> I agree with putting text similar to those paragraphs in, but I don't th= ink they are quite right on the distinction between host-routed and realm-r= outed. >>=20 >> I think "host routed" requests include any request where the sender has = a priori knowledge that the request will land on a particular server. The p= resence of Destination-Host is the most obvious way to have that knowledge. >>=20 >> Another way to have the knowledge would be when that host is a direct pe= er to the reacting node, and the reacting nodes peer-selection algorithm ch= ooses that server. This case is a bit more flexible, in that if the peer-se= lection algorithm allowed other alternatives, the reacting-node could choos= e a different peer. It also allows nodes to appropriately handle things lik= e pseudo-sessions, correlated sessions, etc, even if Destination-Host is no= t present. >>=20 >>=20 >> On Sep 3, 2014, at 10:45 AM, Steve Donovan wr= ote: >>=20 >>> All, >>>=20 >>> I propose to add the following paragraph to the Solution Overview secti= on. This would be immediately before the last paragraph and come after the= paragraph that introduces the concept of report-types. >>>=20 >>> This is part of the solution to issue #23 - DOIC behavior for realm ove= rload >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> ---- >>>=20 >>> A report of type host is sent to indicate the overload of a specific se= rver for the application-id indicated in the transaction. When receiving a= n OLR of type host, a reacting node applies overload abatement to what is r= eferred to in this document as host-routed requests. This is the set of re= quests that contain a Destination-Host AVP. The reacting node applies over= load abatement on the host-routed requests with a Destination-Host value th= at matches the Diameter-ID for the overload report. >>>=20 >>> A report type of realm is sent to indicate the overload of all servers = in a realm for the application-id. When receiving an OLR of type realm, a = reacting node applies overload abatement to what is referred to in this doc= ument as realm-routed requests. This is the set of messages that do not co= ntain a Destination-Host AVP and are, as a result, routed based on the Dest= ination-Realm AVP. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=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 nobody Thu Sep 4 03:27:39 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65391A066A for ; Thu, 4 Sep 2014 03:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvYSic51PrBW for ; Thu, 4 Sep 2014 03:27:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5191A6F29 for ; Thu, 4 Sep 2014 03:27:33 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s84ARTOl019233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Sep 2014 10:27:30 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s84ARL8I027611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Sep 2014 12:27:25 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 4 Sep 2014 12:27:23 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 12:27:23 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "ext Ben Campbell" , Steve Donovan Thread-Topic: [Dime] Proposed additional wording in section 3. Solution Overview Thread-Index: AQHPx6pWID17vLMGAU2Hdl6MH+RhV5vvvuuAgAAF8ACAAN5EwP//8+KAgAAn+iA= Date: Thu, 4 Sep 2014 10:27:23 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815209CA3@DEMUMBX014.nsn-intra.net> References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FA36@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980FA36@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6150 X-purgate-ID: 151667::1409826451-000023E0-DA292670/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SVm26NBLwaCyJl2jvfdJt0Zj2EA Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 10:27:37 -0000 MCruz, I agree. I would have thought that an overload report contains (not explicitly but i= mplicitly) the Diameter-Id of the overloaded node. Anyway, I would propose to replace "the OC-OLR AVP" with "the received OLR = of type host" to better reference back to the second sentence. This would result in: A report of type host is sent to indicate the overload of a specific server= for the application-id indicated in the transaction. When receiving an OL= R of type host, a reacting node applies overload abatement to what is refer= red to in this document as host-routed requests. This is the set of reques= ts that the reacting node knows will be served by a particular host, either= due to the presence of a Destination-Host AVP, or by some other local know= ledge on the part of the reacting node. The reacting node applies overload= abatement on those host-routed requests which the reacting node knows will= be served by the server that matches the Origin-Host AVP of the received m= essage that contained the received OLR of type host. Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Thursday, September 04, 2014 11:38 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: RE: [Dime] Proposed additional wording in section 3. Solution Over= view Steve, Ben, Ulrich, What do you mean by " the server that matches the Diameter-Id from the over= load report "? It should be replaced by " the server that matches the Origin-Host AVP of t= he received message that contained the OC-OLR AVP" Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: jueves, 04 de septiembre de 2014 10:23 To: ext Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view Ben, second sentence should read "The reacting node applies overload abatement on those host-routed requests= which the reacting node knows will be served by the server that matches th= e Diameter-Id from the overload report." Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, September 03, 2014 11:06 PM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view I think this could be fixed with the following change: Paragraph 1, last two sentences: This is the set of requests that the reacting node knows will be served by = a particular host, either due to the presence of a Destination-Host AVP, or= by some other local knowledge on the part of the reacting node. The react= ing node applies overload abatement on the host-routed requests with that w= ould be served by a host with a Diameter Identity that matches the Diameter= -Id from the overload report.=20 Paragraph 2, last sentence: This is the set of requests that are not host-routed as defined in the prev= ious paragraph. On Sep 3, 2014, at 3:44 PM, Steve Donovan wrote: > Ben, >=20 > You are correct. The definition for host routed needs to be as you indic= ate. >=20 > Steve >=20 > On 9/3/14, 2:07 PM, Ben Campbell wrote: >> I agree with putting text similar to those paragraphs in, but I don't th= ink they are quite right on the distinction between host-routed and realm-r= outed. >>=20 >> I think "host routed" requests include any request where the sender has = a priori knowledge that the request will land on a particular server. The p= resence of Destination-Host is the most obvious way to have that knowledge. >>=20 >> Another way to have the knowledge would be when that host is a direct pe= er to the reacting node, and the reacting nodes peer-selection algorithm ch= ooses that server. This case is a bit more flexible, in that if the peer-se= lection algorithm allowed other alternatives, the reacting-node could choos= e a different peer. It also allows nodes to appropriately handle things lik= e pseudo-sessions, correlated sessions, etc, even if Destination-Host is no= t present. >>=20 >>=20 >> On Sep 3, 2014, at 10:45 AM, Steve Donovan wr= ote: >>=20 >>> All, >>>=20 >>> I propose to add the following paragraph to the Solution Overview secti= on. This would be immediately before the last paragraph and come after the= paragraph that introduces the concept of report-types. >>>=20 >>> This is part of the solution to issue #23 - DOIC behavior for realm ove= rload >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> ---- >>>=20 >>> A report of type host is sent to indicate the overload of a specific se= rver for the application-id indicated in the transaction. When receiving a= n OLR of type host, a reacting node applies overload abatement to what is r= eferred to in this document as host-routed requests. This is the set of re= quests that contain a Destination-Host AVP. The reacting node applies over= load abatement on the host-routed requests with a Destination-Host value th= at matches the Diameter-ID for the overload report. >>>=20 >>> A report type of realm is sent to indicate the overload of all servers = in a realm for the application-id. When receiving an OLR of type realm, a = reacting node applies overload abatement to what is referred to in this doc= ument as realm-routed requests. This is the set of messages that do not co= ntain a Destination-Host AVP and are, as a result, routed based on the Dest= ination-Realm AVP. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=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 nobody Thu Sep 4 03:31:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404591A6EE8 for ; Thu, 4 Sep 2014 03:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoH0HtPVmH10 for ; Thu, 4 Sep 2014 03:31:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7D71A6F27 for ; Thu, 4 Sep 2014 03:31:02 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-12-54083f64a6bc Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.5F.21334.46F38045; Thu, 4 Sep 2014 12:31:01 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 12:31:00 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell , Steve Donovan Thread-Topic: [Dime] Proposed additional wording in section 3. Solution Overview Thread-Index: AQHPx6pVMo6MozDkWUWBR1co/pALFJvvvuuAgAAF8ACAAL1FgIAANa5Q///s94CAACJ4kA== Date: Thu, 4 Sep 2014 10:31:00 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980FB5A@ESESSMB101.ericsson.se> References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FA36@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D900066815209CA3@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209CA3@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RjfVniPEYN0dVov5nafZLeb2rmCz 2NDEY7Hu7QomBxaPJUt+MnnM2vmExePn+qvsHqve9rEGsERx2aSk5mSWpRbp2yVwZVzYFFTw xKji4OH3zA2MyzS7GDk5JARMJJ69+csIYYtJXLi3nq2LkYtDSOAoo8TFBc8YIZzFjBKnW5+A VbEJ2ElcOv2CCSQhItDDKPF47nGwBLOAssTsHQ/YQWxhgUCJtz8OsoLYIgJBEs9Wv2aBsMMk 1nVMAKthEVCReHb3LVicV8BX4vLhl8wQ27qZJc783cUEkuAUCJB429wBNogR6L7vp9YwQSwT l7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwphK0q0P22AOk5HYsHuT2wQtrbEsoWvmSEWC0qcnPmE ZQKj2CwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQIj7eCW37o7 GFe/djzEKMDBqMTD++A/e4gQa2JZcWXuIUZpDhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamD04GXq2/n74kR94en750Rt7Pk916k2inGP4KZ3Bbu0Fx65/1h62fmrxgtFXh19 dklkWdf7P475agE191LWr1CykJl24d7/Ks40dYXP0295rTv3iFVDWeDCmb/VQss//liZqyGz cD7PucgqPaYtvXvfyM41PG9uFHDh/JyjApVWj+882BnS8kWkR4mlOCPRUIu5qDgRACMnG4mV AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4uKbCGdRk1IqsXbQn06ZnpL3ouE Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 10:31:10 -0000 Thanks Ulrich, Fine to me /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: jueves, 04 de septiembre de 2014 12:27 To: Maria Cruz Bartolome; ext Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: RE: [Dime] Proposed additional wording in section 3. Solution Over= view MCruz, I agree. I would have thought that an overload report contains (not explicitly but i= mplicitly) the Diameter-Id of the overloaded node. Anyway, I would propose to replace "the OC-OLR AVP" with "the received OLR = of type host" to better reference back to the second sentence. This would result in: A report of type host is sent to indicate the overload of a specific server= for the application-id indicated in the transaction. When receiving an OL= R of type host, a reacting node applies overload abatement to what is refer= red to in this document as host-routed requests. This is the set of reques= ts that the reacting node knows will be served by a particular host, either= due to the presence of a Destination-Host AVP, or by some other local know= ledge on the part of the reacting node. The reacting node applies overload= abatement on those host-routed requests which the reacting node knows will= be served by the server that matches the Origin-Host AVP of the received m= essage that contained the received OLR of type host. Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Thursday, September 04, 2014 11:38 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: RE: [Dime] Proposed additional wording in section 3. Solution Over= view Steve, Ben, Ulrich, What do you mean by " the server that matches the Diameter-Id from the over= load report "? It should be replaced by " the server that matches the Origin-Host AVP of t= he received message that contained the OC-OLR AVP" Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: jueves, 04 de septiembre de 2014 10:23 To: ext Ben Campbell; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view Ben, second sentence should read "The reacting node applies overload abatement on those host-routed requests= which the reacting node knows will be served by the server that matches th= e Diameter-Id from the overload report." Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, September 03, 2014 11:06 PM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] Proposed additional wording in section 3. Solution Over= view I think this could be fixed with the following change: Paragraph 1, last two sentences: This is the set of requests that the reacting node knows will be served by = a particular host, either due to the presence of a Destination-Host AVP, or= by some other local knowledge on the part of the reacting node. The react= ing node applies overload abatement on the host-routed requests with that w= ould be served by a host with a Diameter Identity that matches the Diameter= -Id from the overload report.=20 Paragraph 2, last sentence: This is the set of requests that are not host-routed as defined in the prev= ious paragraph. On Sep 3, 2014, at 3:44 PM, Steve Donovan wrote: > Ben, >=20 > You are correct. The definition for host routed needs to be as you indic= ate. >=20 > Steve >=20 > On 9/3/14, 2:07 PM, Ben Campbell wrote: >> I agree with putting text similar to those paragraphs in, but I don't th= ink they are quite right on the distinction between host-routed and realm-r= outed. >>=20 >> I think "host routed" requests include any request where the sender has = a priori knowledge that the request will land on a particular server. The p= resence of Destination-Host is the most obvious way to have that knowledge. >>=20 >> Another way to have the knowledge would be when that host is a direct pe= er to the reacting node, and the reacting nodes peer-selection algorithm ch= ooses that server. This case is a bit more flexible, in that if the peer-se= lection algorithm allowed other alternatives, the reacting-node could choos= e a different peer. It also allows nodes to appropriately handle things lik= e pseudo-sessions, correlated sessions, etc, even if Destination-Host is no= t present. >>=20 >>=20 >> On Sep 3, 2014, at 10:45 AM, Steve Donovan wr= ote: >>=20 >>> All, >>>=20 >>> I propose to add the following paragraph to the Solution Overview secti= on. This would be immediately before the last paragraph and come after the= paragraph that introduces the concept of report-types. >>>=20 >>> This is part of the solution to issue #23 - DOIC behavior for realm ove= rload >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> ---- >>>=20 >>> A report of type host is sent to indicate the overload of a specific se= rver for the application-id indicated in the transaction. When receiving a= n OLR of type host, a reacting node applies overload abatement to what is r= eferred to in this document as host-routed requests. This is the set of re= quests that contain a Destination-Host AVP. The reacting node applies over= load abatement on the host-routed requests with a Destination-Host value th= at matches the Diameter-ID for the overload report. >>>=20 >>> A report type of realm is sent to indicate the overload of all servers = in a realm for the application-id. When receiving an OLR of type realm, a = reacting node applies overload abatement to what is referred to in this doc= ument as realm-routed requests. This is the set of messages that do not co= ntain a Destination-Host AVP and are, as a result, routed based on the Dest= ination-Realm AVP. >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=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 nobody Thu Sep 4 04:55:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DB1A8764 for ; Thu, 4 Sep 2014 04:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 739tEK9ahU-H for ; Thu, 4 Sep 2014 04:55:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3731A8767 for ; Thu, 4 Sep 2014 04:55:24 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57146 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPVdK-0005yn-Fi; Thu, 04 Sep 2014 04:55:23 -0700 Message-ID: <5408532A.7090007@usdonovans.com> Date: Thu, 04 Sep 2014 06:55:22 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Shishufeng (Susan)" , "dime@ietf.org" References: <540737B6.6010106@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF67EDB@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF67EDB@SZXEMA512-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------060408010701030907000102" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WUVDzzNZYctRtAQzWaPeT2zd7wk Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 11:55:25 -0000 This is a multi-part message in MIME format. --------------060408010701030907000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Susan, Lionel called consensus on this so it is considered as already decided that the report type is required as part of the overload report. Please talk to Lionel and/or Jouni if you need an explanation of the rough consensus process used within the IETF. Regards, Steve On 9/4/14, 3:26 AM, Shishufeng (Susan) wrote: > > Hello Steve, > > As discussed before, most of 3GPP delegates prefer to have the report > type as optional. So apart from updating the AVP as optional in the > other parts of the draft, if we are going to add the following texts, > I would propose to rephrase the first paragraph as follows: > > A report of type host can be sent to indicate the overload of a > specific server for the application-id indicated in the transaction. > By default, the overload report is for a specific server. When > receiving an OLR for a specific server, a reacting node applies > overload abatement to what is referred to in this document as > host-routed requests. This is the set of requests that contain a > Destination-Host AVP. The reacting node applies overload abatement on > the host-routed requests with a Destination-Host value that matches > the Diameter-ID for the overload report. > > Best Regards, > > Susan > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, September 03, 2014 11:46 PM > To: dime@ietf.org > Subject: [Dime] Proposed additional wording in section 3. Solution > Overview > > All, > > I propose to add the following paragraph to the Solution Overview > section. This would be immediately before the last paragraph and come > after the paragraph that introduces the concept of report-types. > > This is part of the solution to issue #23 - DOIC behavior for realm > overload > > Regards, > > Steve > > ---- > > A report of type host is sent to indicate the overload of a specific > server for the application-id indicated in the transaction. By > default, the overload report is for a specific server. , a reacting > node applies overload abatement to what is referred to in this > document as host-routed requests. This is the set of requests that > contain a Destination-Host AVP. The reacting node applies overload > abatement on the host-routed requests with a Destination-Host value > that matches the Diameter-ID for the overload report. > > A report type of realm is sent to indicate the overload of all servers > in a realm for the application-id. When receiving an OLR of type > realm, a reacting node applies overload abatement to what is referred > to in this document as realm-routed requests. This is the set of > messages that do not contain a Destination-Host AVP and are, as a > result, routed based on the Destination-Realm AVP. > --------------060408010701030907000102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Susan,

Lionel called consensus on this so it is considered as already decided that the report type is required as part of the overload report.

Please talk to Lionel and/or Jouni if you need an explanation of the rough consensus process used within the IETF.

Regards,

Steve

On 9/4/14, 3:26 AM, Shishufeng (Susan) wrote:

Hello Steve,

 

As discussed before, most of 3GPP delegates prefer to have the report type as optional. So apart from updating the AVP as optional in the other parts of the draft, if we are going to add the following texts, I would propose to rephrase the first paragraph as follows:

A report of type host can be sent to indicate the overload of a specific server for the application-id indicated in the transaction. By default, the overload report is for a specific server. When receiving an OLR for a specific server, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that contain a Destination-Host AVP.  The reacting node applies overload abatement on the host-routed requests with a Destination-Host value that matches the Diameter-ID for the overload report.

 

Best Regards,

Susan

 

-----Original Message-----
From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, September 03, 2014 11:46 PM
To: dime@ietf.org
Subject: [Dime] Proposed additional wording in section 3. Solution Overview

 

All,

 

I propose to add the following paragraph to the Solution Overview section.  This would be immediately before the last paragraph and come after the paragraph that introduces the concept of report-types.

 

This is part of the solution to issue #23 - DOIC behavior for realm overload

 

Regards,

 

Steve

 

----

 

A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. By default, the overload report is for a specific server. , a reacting node applies overload abatement to what is referred to in this document as host-routed requests.  This is the set of requests that contain a Destination-Host AVP.  The reacting node applies overload abatement on the host-routed requests with a Destination-Host value that matches the Diameter-ID for the overload report.

 

A report type of realm is sent to indicate the overload of all servers in a realm for the application-id.  When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests.  This is the set of messages that do not contain a Destination-Host AVP and are, as a result, routed based on the Destination-Realm AVP.

 

 


--------------060408010701030907000102-- From nobody Thu Sep 4 05:02:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0082D1A8833 for ; Thu, 4 Sep 2014 05:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX7phDy4GhV0 for ; Thu, 4 Sep 2014 05:02:05 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A0F1A87C9 for ; Thu, 4 Sep 2014 05:02:03 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57152 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPVjj-0002za-6y; Thu, 04 Sep 2014 05:02:00 -0700 Message-ID: <540854B6.6020905@usdonovans.com> Date: Thu, 04 Sep 2014 07:01:58 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FA36@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D900066815209CA3@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FB5A@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980FB5A@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ic2cZ6ewAf5o4Y8ZC7kkI3dEGsI Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 12:02:07 -0000 Maria Cruz, The wording did assume that the Diameter identity is implicitly a part of the overload report. There are a number of places where that definition of overload report makes the wording easier. That said, I am ok with the modifications suggested by Ben and Ulrich. I'll go ahead and make the change unless I hear objections today. Steve On 9/4/14, 5:31 AM, Maria Cruz Bartolome wrote: > Thanks Ulrich, > Fine to me > > /MCruz > > -----Original Message----- > From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] > Sent: jueves, 04 de septiembre de 2014 12:27 > To: Maria Cruz Bartolome; ext Ben Campbell; Steve Donovan > Cc: dime@ietf.org > Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview > > MCruz, > I agree. > I would have thought that an overload report contains (not explicitly but implicitly) the Diameter-Id of the overloaded node. > Anyway, I would propose to replace "the OC-OLR AVP" with "the received OLR of type host" to better reference back to the second sentence. > This would result in: > > A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Origin-Host AVP of the received message that contained the received OLR of type host. > > Ulrich > > -----Original Message----- > From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] > Sent: Thursday, September 04, 2014 11:38 AM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell; Steve Donovan > Cc: dime@ietf.org > Subject: RE: [Dime] Proposed additional wording in section 3. Solution Overview > > Steve, Ben, Ulrich, > > What do you mean by " the server that matches the Diameter-Id from the overload report "? > It should be replaced by " the server that matches the Origin-Host AVP of the received > message that contained the OC-OLR AVP" > > Regards > /MCruz > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) > Sent: jueves, 04 de septiembre de 2014 10:23 > To: ext Ben Campbell; Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview > > Ben, > > second sentence should read > > "The reacting node applies overload abatement on those host-routed requests which the reacting node knows will be served by the server that matches the Diameter-Id from the overload report." > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell > Sent: Wednesday, September 03, 2014 11:06 PM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview > > I think this could be fixed with the following change: > > Paragraph 1, last two sentences: > > This is the set of requests that the reacting node knows will be served by a particular host, either due to the presence of a Destination-Host AVP, or by some other local knowledge on the part of the reacting node. The reacting node applies overload abatement on the host-routed requests with that would be served by a host with a Diameter Identity that matches the Diameter-Id from the overload report. > > Paragraph 2, last sentence: > > This is the set of requests that are not host-routed as defined in the previous paragraph. > > > On Sep 3, 2014, at 3:44 PM, Steve Donovan wrote: > >> Ben, >> >> You are correct. The definition for host routed needs to be as you indicate. >> >> Steve >> >> On 9/3/14, 2:07 PM, Ben Campbell wrote: >>> I agree with putting text similar to those paragraphs in, but I don't think they are quite right on the distinction between host-routed and realm-routed. >>> >>> I think "host routed" requests include any request where the sender has a priori knowledge that the request will land on a particular server. The presence of Destination-Host is the most obvious way to have that knowledge. >>> >>> Another way to have the knowledge would be when that host is a direct peer to the reacting node, and the reacting nodes peer-selection algorithm chooses that server. This case is a bit more flexible, in that if the peer-selection algorithm allowed other alternatives, the reacting-node could choose a different peer. It also allows nodes to appropriately handle things like pseudo-sessions, correlated sessions, etc, even if Destination-Host is not present. >>> >>> >>> On Sep 3, 2014, at 10:45 AM, Steve Donovan wrote: >>> >>>> All, >>>> >>>> I propose to add the following paragraph to the Solution Overview section. This would be immediately before the last paragraph and come after the paragraph that introduces the concept of report-types. >>>> >>>> This is part of the solution to issue #23 - DOIC behavior for realm overload >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> ---- >>>> >>>> A report of type host is sent to indicate the overload of a specific server for the application-id indicated in the transaction. When receiving an OLR of type host, a reacting node applies overload abatement to what is referred to in this document as host-routed requests. This is the set of requests that contain a Destination-Host AVP. The reacting node applies overload abatement on the host-routed requests with a Destination-Host value that matches the Diameter-ID for the overload report. >>>> >>>> A report type of realm is sent to indicate the overload of all servers in a realm for the application-id. When receiving an OLR of type realm, a reacting node applies overload abatement to what is referred to in this document as realm-routed requests. This is the set of messages that do not contain a Destination-Host AVP and are, as a result, routed based on the Destination-Realm AVP. >>>> >>>> _______________________________________________ >>>> 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 nobody Thu Sep 4 05:39:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3A1A8887; Thu, 4 Sep 2014 05:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6uxqgUX_pFo; Thu, 4 Sep 2014 05:39:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 892F91A8876; Thu, 4 Sep 2014 05:39:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904123919.6000.44788.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 05:39:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qUBcAb6hNnImKT8ote5bYiEl-9A Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-27.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:39:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Authors : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-27.txt Pages : 27 Date : 2014-09-04 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-27 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 4 08:06:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD841A88F3 for ; Thu, 4 Sep 2014 08:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcdeA0-clIFC for ; Thu, 4 Sep 2014 08:06:27 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDD41A88FB for ; Thu, 4 Sep 2014 08:06:27 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59781 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPYcD-0007hG-0D for dime@ietf.org; Thu, 04 Sep 2014 08:06:26 -0700 Message-ID: <54087FF0.6030504@usdonovans.com> Date: Thu, 04 Sep 2014 10:06:24 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pBYeoBdibQLoOhiTo2vsnaVjsIc Subject: [Dime] Issue #35 being closed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 15:06:32 -0000 All, I am going to close issue #35 as something to be addressed in an extension based on discussions in the Toronto working group meeting. Regards, Steve From nobody Thu Sep 4 08:08:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1811A034E for ; Thu, 4 Sep 2014 08:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8PYUgCWv3S8 for ; Thu, 4 Sep 2014 08:08:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EE71A88BD for ; Thu, 4 Sep 2014 08:08:30 -0700 (PDT) Received: from localhost ([::1]:60290 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPYeA-0003oi-7M; Thu, 04 Sep 2014 08:08:26 -0700 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: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Thu, 04 Sep 2014 15:08:26 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/35#comment:4 Message-ID: <081.42cb1d694dbb9fa54225c39a7e38372b@trac.tools.ietf.org> References: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <066.5bacdffbc40a388af99a5b9c8e0b2d88@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kedXW6EbGO9b17YSzCI3fWGjJQo Cc: dime@ietf.org Subject: Re: [Dime] [dime] #35 (draft-ietf-dime-ovli): additional report types are proposed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Sep 2014 15:08:40 -0000 #35: additional report types are proposed Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => wontfix Comment: As discussed in Toronto working group meeting and previously on the mailing list, this item is deferred to a potential extension to the DOIC solution. -- --------------------------------------+--------------------------- Reporter: lionel.morand@orange.com | Owner: Ulrich Wiehe Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------------+--------------------------- Ticket URL: dime From nobody Thu Sep 4 12:59:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFEE1A00B7 for ; Thu, 4 Sep 2014 12:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XH0P5-4FGmVk for ; Thu, 4 Sep 2014 12:59:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4FD1A004B for ; Thu, 4 Sep 2014 12:59:08 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s84Jx5pd022157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Sep 2014 14:59:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> Date: Thu, 4 Sep 2014 14:59:05 -0500 X-Mao-Original-Outgoing-Id: 431553545.540926-cbd97b20a85ed739d4db6dd767761a02 Content-Transfer-Encoding: quoted-printable Message-Id: <10E9FC82-802B-42F6-B946-164A5FCC9676@nostrum.com> References: <540737B6.6010106@usdonovans.com> <8A3E2539-12A9-4C86-ABF0-4F5457530BD1@nostrum.com> <54077DBB.9090603@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209C49@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6c444wPK5ydpNbRA96QHkMtR_pU Cc: "dime@ietf.org" Subject: Re: [Dime] Proposed additional wording in section 3. Solution Overview X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 19:59:13 -0000 I agree, that version is better. On Sep 4, 2014, at 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Ben, >=20 > second sentence should read >=20 > "The reacting node applies overload abatement on those host-routed = requests which the reacting node knows will be served by the server that = matches the Diameter-Id from the overload report." >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben = Campbell > Sent: Wednesday, September 03, 2014 11:06 PM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] Proposed additional wording in section 3. Solution = Overview >=20 > I think this could be fixed with the following change: >=20 > Paragraph 1, last two sentences: >=20 > This is the set of requests that the reacting node knows will be = served by a particular host, either due to the presence of a = Destination-Host AVP, or by some other local knowledge on the part of = the reacting node. The reacting node applies overload abatement on the = host-routed requests with that would be served by a host with a Diameter = Identity that matches the Diameter-Id from the overload report.=20 >=20 > Paragraph 2, last sentence: >=20 > This is the set of requests that are not host-routed as defined in the = previous paragraph. >=20 >=20 > On Sep 3, 2014, at 3:44 PM, Steve Donovan = wrote: >=20 >> Ben, >>=20 >> You are correct. The definition for host routed needs to be as you = indicate. >>=20 >> Steve >>=20 >> On 9/3/14, 2:07 PM, Ben Campbell wrote: >>> I agree with putting text similar to those paragraphs in, but I = don't think they are quite right on the distinction between host-routed = and realm-routed. >>>=20 >>> I think "host routed" requests include any request where the sender = has a priori knowledge that the request will land on a particular = server. The presence of Destination-Host is the most obvious way to have = that knowledge. >>>=20 >>> Another way to have the knowledge would be when that host is a = direct peer to the reacting node, and the reacting nodes peer-selection = algorithm chooses that server. This case is a bit more flexible, in that = if the peer-selection algorithm allowed other alternatives, the = reacting-node could choose a different peer. It also allows nodes to = appropriately handle things like pseudo-sessions, correlated sessions, = etc, even if Destination-Host is not present. >>>=20 >>>=20 >>> On Sep 3, 2014, at 10:45 AM, Steve Donovan = wrote: >>>=20 >>>> All, >>>>=20 >>>> I propose to add the following paragraph to the Solution Overview = section. This would be immediately before the last paragraph and come = after the paragraph that introduces the concept of report-types. >>>>=20 >>>> This is part of the solution to issue #23 - DOIC behavior for realm = overload >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> ---- >>>>=20 >>>> A report of type host is sent to indicate the overload of a = specific server for the application-id indicated in the transaction. = When receiving an OLR of type host, a reacting node applies overload = abatement to what is referred to in this document as host-routed = requests. This is the set of requests that contain a Destination-Host = AVP. The reacting node applies overload abatement on the host-routed = requests with a Destination-Host value that matches the Diameter-ID for = the overload report. >>>>=20 >>>> A report type of realm is sent to indicate the overload of all = servers in a realm for the application-id. When receiving an OLR of = type realm, a reacting node applies overload abatement to what is = referred to in this document as realm-routed requests. This is the set = of messages that do not contain a Destination-Host AVP and are, as a = result, routed based on the Destination-Realm AVP. >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=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 nobody Fri Sep 5 00:15:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA171A046A for ; Fri, 5 Sep 2014 00:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjDpv37bIkCj for ; Fri, 5 Sep 2014 00:15:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422A01A0478 for ; Fri, 5 Sep 2014 00:15:30 -0700 (PDT) Received: from localhost ([::1]:49177 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPnjs-0000Gu-HC; Fri, 05 Sep 2014 00:15:20 -0700 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: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Fri, 05 Sep 2014 07:15:20 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/67 Message-ID: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> X-Trac-Ticket-ID: 67 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oX9ABB0aNxizsm4O2xuEiESA4pw Cc: dime@ietf.org Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 07:15:31 -0000 #67: OCS for Reporting Nodes - Expiry Time What does "Validity Duration" mean as the information stored in OCS for Reporting Nodes? We need to store some information that allow the reporting node to calculate a Validity-Duration value to be included in each OC-OLR AVP Then, I presume we need just Expiry Time, and then value to be included in each Validation-Duration AVP is calculated based on this. Then, original text: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. Editor's note: This statement is unclear and contradictory with other statements. A validity timer of zero seconds indicates that the overload condition has ended and abatement is no longer requested. Proposed modification: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Expiry Time is used by the reporting node to calculate the value to be included in each Validity-Duration AVP, as part of the overload report. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Sep 5 00:30:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9171A04A8 for ; Fri, 5 Sep 2014 00:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUxjdF3jhIDd for ; Fri, 5 Sep 2014 00:30:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 103A41A049F for ; Fri, 5 Sep 2014 00:30:51 -0700 (PDT) Received: from localhost ([::1]:50274 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPnyh-0000fH-QG; Fri, 05 Sep 2014 00:30:39 -0700 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: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Fri, 05 Sep 2014 07:30:39 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/68 Message-ID: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S2Zb7WKrslnkkKlBGQHadgVwanA Cc: dime@ietf.org Subject: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 07:30:54 -0000 #68: Loss as the common abatemen algorithm Some text is misleading since it may imply that one feature shall be in common between reporting and reacting node to progress, but in reality we only need to have one common abatement algorithm, and in this draft, LOSS is defined as default, then there is always one common algorithm Corrections are required in following clauses: Original text: 4.2.3. Reporting Node Behavior (Normative) ... The operation on the reporting node is straight forward. The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. If the reporting node shares at least one common feature with the reacting node, then the DOIC can be enabled between these two endpoints. See Section 4.1 for further discussion on the capability and feature announcement between two endpoints. Proposed modification: 4.2.3. Reporting Node Behavior (Normative) ... The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. Both reacting and reporting node MUST share at least one abatement algorithm, in fact, they share at least the loss algorithm, that is defined in this document as the default abatement algorithm, then the DOIC can always be enabled between these two endpoints at least with the default algorithm. See Section 4.1 for further discussion on the capability and feature announcement between two endpoints. Original text: 6.1. OC-Supported-Features AVP ... During the message exchange the overload control endpoints express their common set of supported capabilities. The reacting node includes the OC-Supported-Features AVP that announces what it supports. The reporting node that sends the answer also includes the OC-Supported-Features AVP that describes the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. At least one of the announced capabilities MUST match. If there is no single matching capability the reacting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. Editor's note: The last sentence conflicts with the last sentence two paragraphs up. In reality, there will always be at least one matching capability as all nodes supporting DOIC must support the loss algorithm. Suggest removing the last sentence. Proposed text: 6.1. OC-Supported-Features AVP ... During the message exchange the overload control endpoints express their common set of supported capabilities. The reacting node includes the OC-Supported-Features AVP that announces what it supports. The reporting node that sends the answer also includes the OC-Supported-Features AVP that describes the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. Both reacting and reporting node MUST share at least one abatement algorithm, in fact, they share at least the loss algorithm, that is defined in this document as the default abatement algorithm, then the DOIC can always be enabled between these two endpoints at least with the default algorithm. See Section 4.1 for further discussion on the capability and feature announcement between two endpoints. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Sep 5 00:35:07 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675121A04A8 for ; Fri, 5 Sep 2014 00:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO0EYC1Wgsaw for ; Fri, 5 Sep 2014 00:35:01 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892851A04A1 for ; Fri, 5 Sep 2014 00:35:01 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-d6-540967a3ada5 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.D9.21432.3A769045; Fri, 5 Sep 2014 09:34:59 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Fri, 5 Sep 2014 09:34:58 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] Loss algorithm - clarification Thread-Index: Ac/I28jdegizAe2FQli4d+floEc+Yg== Date: Fri, 5 Sep 2014 07:34:57 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980FEF7@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje7idM4Qg/fv5Szm9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvnmHuaCX8wVJxqesTQwfmfqYuTkkBAwkfh6qI8FwhaTuHBv PVsXIxeHkMBRRomrB3vYIZzFjBIHLr5lB6liE7CTuHT6BVA3B4eIgLLE6V8OIKawgJ7Enq8G IBUiAsYSp24vYoOw9STetPxkBbFZBFQk1s64DRbnFfCVWLZyFlicEWjv91NrwO5hFhCXuPVk PtRtAhJL9pxnhrBFJV4+/scKYStJLLr9GapeR2LB7k9sELa2xLKFr5kh5gtKnJz5hGUCo/As JGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECA/zglt8GOxhfPnc8 xCjAwajEw6sgyRkixJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4 pRoYt1mFp4UVSYarxom2yDkvviF1r3HS6wnHDef+fdltFzNp1rOTBzzDrCPP2aUrxt+2tU++ nH9CSl85vUNfoiIrPjvDyGW63/8NK44m/qvTcdTmnb9jc8uz06/WLOAw0/nrd/jHWTmbuhbe 2FkJl05vLj1dvCptdkeV+7kX/8R3a9aVdDr5FaQrsRRnJBpqMRcVJwIADecgaVECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xJ31EFXZXPAEZTI68x1Sc0PbQSg Subject: [Dime] Loss algorithm - clarification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 07:35:03 -0000 Dear all, In clause 5.1, I do not understand following paragraph. Could someone clarify? 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken would be to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. Best regards /MCruz From nobody Fri Sep 5 00:40:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B11A04A8 for ; Fri, 5 Sep 2014 00:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv_a6aTUWLb2 for ; Fri, 5 Sep 2014 00:40:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAC81A04A1 for ; Fri, 5 Sep 2014 00:40:14 -0700 (PDT) Received: from localhost ([::1]:50685 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPo7o-0002GO-Co; Fri, 05 Sep 2014 00:40:04 -0700 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: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Fri, 05 Sep 2014 07:40:04 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/69 Message-ID: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U84dgXliNNDnUG-n1u0gfiQugHI Cc: dime@ietf.org Subject: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 07:40:16 -0000 #69: Report Type - Realm, with absent Destination-Host In clause 6.6, host report was updated to add: ... or the Destination-Host is not present in the request but the value of peer identity associated with the connection used to send the request matches the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. but this clarification needs to be included as well for realm report. Original text: 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is absent in the request. ... Proposed text: 1 A realm report. The overload treatment should apply to requests for which all of the following conditions are true: The Destination-Host AVP is absent in the request and the the value of peer identity associated with the connection used to send the request does not match the value of the Origin-Host AVP of the received message that contained the OC-OLR AVP. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Sep 5 00:49:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD051A04B6 for ; Fri, 5 Sep 2014 00:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO4qGvMpFgTk for ; Fri, 5 Sep 2014 00:49:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5281A04D2 for ; Fri, 5 Sep 2014 00:49:43 -0700 (PDT) Received: from localhost ([::1]:51004 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPoGy-0001LZ-SE; Fri, 05 Sep 2014 00:49:32 -0700 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: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Fri, 05 Sep 2014 07:49:32 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/70 Message-ID: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nHl_y66qE0XIGPcDko5nk6o9R4I Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 07:49:46 -0000 #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent reports Host overload directly back to the Client, when the Client request was for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=DH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=DH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=R) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Sep 5 00:57:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D9D1A04F6 for ; Fri, 5 Sep 2014 00:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOwXQVHxhHLT for ; Fri, 5 Sep 2014 00:57:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878541A04B6 for ; Fri, 5 Sep 2014 00:57:15 -0700 (PDT) Received: from localhost ([::1]:51270 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPoOI-0005yq-AH; Fri, 05 Sep 2014 00:57:06 -0700 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: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Fri, 05 Sep 2014 07:57:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/71 Message-ID: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tKaR04OxWSeeAIi6lMwmlDqN-lY Cc: dime@ietf.org Subject: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 07:57:17 -0000 #71: Active overload report even if OC-OLR is not received Answer message may not include OC-OLR and still the reporting node be overloaded, since it is considered as "no change", as documented in 4.2.1.3: Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). Original text: 4.1.1. Reacting Node Behavior (Normative) ... Note that the loss abatement algorithm is the only feature described in this document and it does not require action to be taken by the reacting node except when the answer message also has an overload report. This behavior is described in Section 4.2 and Section 5. Proposed text: 4.1.1. Reacting Node Behavior (Normative) ... Note that the loss abatement algorithm is the only feature described in this document and it does not require action to be taken by the reacting node except when there is an active overload report. This behavior is described in Section 4.2 and Section 5. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Sep 5 01:03:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48D1A0538 for ; Fri, 5 Sep 2014 01:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2lU9cpUBz37 for ; Fri, 5 Sep 2014 01:03:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BA01A053B for ; Fri, 5 Sep 2014 01:03:52 -0700 (PDT) Received: from localhost ([::1]:51554 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XPoUf-00014v-Oy; Fri, 05 Sep 2014 01:03:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com X-Trac-Project: dime Date: Fri, 05 Sep 2014 08:03:41 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/72 Message-ID: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 72 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hJ-eFkwxBw6YdHfl3DtERgoww9Q Cc: dime@ietf.org Subject: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 05 Sep 2014 08:03:54 -0000 #72: Reporting Node Behaviour when OC-OLR is not received A clarification is required to consider that an answer message may not include OC-OLR and still the reporting node be overloaded, since it is considered as "no change", as documented in 4.2.1.3: Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). Original text: 5.3. Reporting Node Behavior (Normative) The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it must include an OC-OLR AVP in all response messages. Proposed addition: 5.3. Reporting Node Behavior (Normative) The method a reporting nodes uses to determine the amount of traffic reduction required to address an overload condition is an implementation decision. When a reporting node that has selected the loss abatement algorithm determines the need to request a traffic reduction it must include an OC-OLR AVP in all response messages. OC-OLR AVP is not included when reporting node expectations on traffic reduction are not modified. That is, if OC-OLR AVP is not included it is interpreted as “no changeâ€. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Sep 5 01:14:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D718F1A061D for ; Fri, 5 Sep 2014 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy8SCTJc8k_b for ; Fri, 5 Sep 2014 01:14:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8721A04C2 for ; Fri, 5 Sep 2014 01:14:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s858EnFw032394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Sep 2014 08:14:49 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s858EnaB008287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 10:14:49 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 10:14:49 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNk1npQUPKBJHEWH9ycMDpTKl5vyI4dw Date: Fri, 5 Sep 2014 08:14:49 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> In-Reply-To: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4209 X-purgate-ID: 151667::1409904890-000023E0-05F53006/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RhFKxaPPxTXBwTB-QK4bl8oU8aE Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 08:14:56 -0000 Dear Maria Cruz, I do not agree. As an example assume that the reporting node creates an overload state at 1= 0:00 with a duration of 5 minutes. This means that Validity duration is 5 m= inutes and expiry time is 10:05. If only expiration time but not validity duration is stored at the reportin= g node, this will result in the following: For an answer message that is sent immediately (i.e. at 10:00) validity dur= ation will be calculated as 5 minutes (which I think is correct). For an answer message that is sent at 10:01 validity duration will be calcu= lated as 4 minutes, which I think is not correct. The answer message sent a= t 10:01 should contain a replay of the OLR already sent at 10:00, not an up= dated OLR.=20 Therefore validity duration should not be removed from the OCS. Best regards Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:15 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes = - Expiry Time #67: OCS for Reporting Nodes - Expiry Time What does "Validity Duration" mean as the information stored in OCS for Reporting Nodes? We need to store some information that allow the reporting node to calculate a Validity-Duration value to be included in each OC-OLR AVP Then, I presume we need just Expiry Time, and then value to be included in each Validation-Duration AVP is calculated based on this. Then, original text: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. Editor's note: This statement is unclear and contradictory with other statements. A validity timer of zero seconds indicates that the overload condition has ended and abatement is no longer requested. Proposed modification: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Expiry Time is used by the reporting node to calculate the value to be included in each Validity-Duration AVP, as part of the overload report. --=20 -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 5 01:20:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1F1A0655 for ; Fri, 5 Sep 2014 01:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym2wqUQHHYDB for ; Fri, 5 Sep 2014 01:20:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0F41A0654 for ; Fri, 5 Sep 2014 01:20:30 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-a6-5409724d5f58 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C0.71.21432.D4279045; Fri, 5 Sep 2014 10:20:29 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Fri, 5 Sep 2014 10:20:28 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNkuZbpwAkWLB0yx5uVxu0iwDZvyD7KAgAAiZMA= Date: Fri, 5 Sep 2014 08:20:28 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja5vEWeIwdFFUhZze1ewWSw/3sBs se7tCiYHZo8lS34yefxcf5Xd48vlz2wBzFFcNimpOZllqUX6dglcGffmGBUsUavo2nyTuYGx W66LkZNDQsBEonPHUyYIW0ziwr31bF2MXBxCAkcZJVb/aWOEcBYzSjQu7mIDqWITsJO4dPoF E0hCRGAdo8T2dy0sXYwcHMICcRIrTpiA1IgIxEvMXHuAHcK2kmg5+QrMZhFQkfhxYhuYzSvg KzH5VxMzxIIeRolHvd3MIHM4BQIkPtwHu4gR6KLvp9aA2cwC4hK3nsyHulRAYsme88wQtqjE y8f/WCFsJYlFtz9D1etILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKA kWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmDsHNzy22AH48vnjocYBTgYlXh4FSQ5Q4RY E8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6NYXNqv6KnXb0kn mCRfCl++9uFShfPZrUvf71XZIsdh/KJgl1hxkK76N7fnSgKK8c+fTDxyVmkv16WtSp/VNMre MG05fkptxbnUqQuUp0sEa3jN++cYcf1XaZw455Sbpst531cY9ZlW6N9J2cXSYMhZGd6zcfM7 jYeVHpUrVk0zcf7w3G6irpYSS3FGoqEWc1FxIgACmoCAfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Bnwf4jgR3ITmEl_O-cdXrTPcQ6E Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 08:20:33 -0000 Dear Ulrich, Not sure if I understand your point. Is it your intention to send Validity-Duration AVP =3D OCS Validity Duratio= n (in your example 300 s) until timer expires (in your example until 10:05)= ? Could you elaborate a bit further please? Thanks /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 05 de septiembre de 2014 10:15 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Dear Maria Cruz, I do not agree. As an example assume that the reporting node creates an overload state at 1= 0:00 with a duration of 5 minutes. This means that Validity duration is 5 m= inutes and expiry time is 10:05. If only expiration time but not validity duration is stored at the reportin= g node, this will result in the following: For an answer message that is sent immediately (i.e. at 10:00) validity dur= ation will be calculated as 5 minutes (which I think is correct). For an answer message that is sent at 10:01 validity duration will be calcu= lated as 4 minutes, which I think is not correct. The answer message sent a= t 10:01 should contain a replay of the OLR already sent at 10:00, not an up= dated OLR.=20 Therefore validity duration should not be removed from the OCS. Best regards Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:15 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes = - Expiry Time #67: OCS for Reporting Nodes - Expiry Time What does "Validity Duration" mean as the information stored in OCS for R= eporting Nodes? We need to store some information that allow the reporting node to calcul= ate a Validity-Duration value to be included in each OC-OLR AVP Then, I pr= esume we need just Expiry Time, and then value to be included in each Vali= dation-Duration AVP is calculated based on this. Then, original text: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. Editor's note: This statement is unclear and contradictory with other statements. A validity timer of zero seconds indicates that the overload condition has ended and abatement is no longer requested. Proposed modification: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Expiry Time is used by the reporting node to calculate the value to be included in each Validity-Duration AVP, as part of the overload report. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 5 01:28:07 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3A1A0645 for ; Fri, 5 Sep 2014 01:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9aBU0N9eXDY for ; Fri, 5 Sep 2014 01:28:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3903E1A0643 for ; Fri, 5 Sep 2014 01:28:02 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-52-5409740f978a Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.C9.24955.F0479045; Fri, 5 Sep 2014 10:27:59 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Fri, 5 Sep 2014 10:27:58 +0200 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] OVLI .03 rephrasing, modifications, typos Thread-Index: Ac/I4lT7ZOEVVmvxTZuPxS5GqgGv7w== Date: Fri, 5 Sep 2014 08:27:58 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920980FF4A@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/mixed; boundary="_002_087A34937E64E74E848732CFF8354B920980FF4AESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvjS5/CWeIwaqX6hZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9GvE4wFn6ZzVPxoucjawLj2N3sXIyeHhICJxLz9ixghbDGJ C/fWs3UxcnEICRxllOi4dA8sISSwmFHiyF8TEJtNwE7i0ukXTF2MHBwiAsoSp385gISFBSwl ZvYtZgOxRYBKzi7YyQph60m8n3MbLM4ioCJx9dFaRpBWXgFfib87Y0DCjEBrv59awwRiMwuI S9x6Mp8J4hwRiYcXT7NB2KISLx//Y4WwlSQW3f4MVZ8p0X7mHlicV0BQ4uTMJywTGIVmIRk1 C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zp4F9D2zQBOjxPMJvewQCXOJXWePQRUdYpT4clEdwlaU mNL9kH0BI+cqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMAoOrjlt+oOxstvHA8xCnAwKvHw KkhyhgixJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaT4FP5 Tk6Brv++KbJcOPpnucWGXemq3u/Kj17/uPZqrMVt0desYVNf8n7f+CHoYJn5QZWIOT6Pb28/ PqE6qkot94fcz+0vz1x5fuLWqWMXRX5OsHp4xLdSau2hVUfvz/mQnDw7ckFu9u9Q9o/fPxpI mXgxlRrL7hWe5HoiW1h29zqGhurlml35SizFGYmGWsxFxYkAJMErRIMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/b4BiUrhqOAfI7YdnOPC2AosJMgc Subject: [Dime] OVLI .03 rephrasing, modifications, typos X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 08:28:05 -0000 --_002_087A34937E64E74E848732CFF8354B920980FF4AESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all I have included some modification proposals directly into the .03 version .= doc, either with comments and/or direct modification in the text.=20 There are different types of comments/changes: - I marked in green what I already opened as a ticket, or sent as an indivi= dual question. - I marked in yellow some parts that are pending a discussion that is focus= ed on agent behavior. - I included some comments made by Ulrich already, and even some agreement = attempt we reached by email. - the rest of comments include rephrasing, clarifications, typos... what I = hope could be agreeable without open a ticket for them. If any of those com= ments is not directly agreeable, and discussion is started, then I will hap= pily open a new ticket. In general, in the doc there are lot of repetitions that we should avoid. I= n fact, some parts are repeated even in Non-normative and normative parts. = I suggest this is considered for next editing phase. Best regards /MCruz --_002_087A34937E64E74E848732CFF8354B920980FF4AESESSMB101erics_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-dime-ovli-03_MCruz.docx" Content-Description: draft-ietf-dime-ovli-03_MCruz.docx Content-Disposition: attachment; filename="draft-ietf-dime-ovli-03_MCruz.docx"; size=96756; creation-date="Fri, 05 Sep 2014 08:06:44 GMT"; modification-date="Fri, 05 Sep 2014 08:06:45 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAChWeXqgEAAJUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 Vctu2zAQvAfIPwi8FhKdHoKisJxDmh6bAHGQXhlqZRPlC9x1Ev99l7ItOK1quTFyESCROzOc1Q6n V6/OFs+Q0ARfi4tqIgrwOjTGL2rxMP9efhEFkvKNssFDLdaA4mp2fjadryNgwdUea7Ekil+lRL0E p7AKETyvtCE5RfyaFjIq/UstQH6eTC6lDp7AU0kZQ8ym36BVK0vFzSt/3ihJYFEU15uNmasWKkZr tCJWKp998wdLuWWouLLbg0sT8RPLEHKQIa/8m2Bbd8vWJNNAcacS/VCOZciXkBrZBL1yfIbqMMyA ztC2RkNfn9FiChoQ2XNnq37FKeN3+od06BVScD+dlYbA3aUQ8eJkOT1oxoNEBnoPhzR0XiCtLeDJ 1H85scE9ZMEe/aOh5U3bguYfbrwnDstcW20o9mrH2YCIG3UMydsxKMcaj1vkUQkv8HT/YSr2wEeF 6ODyDHyAFzvkUQktJ8RcPVk4oun/2Y8eelQEceyB7J6nT2AHc4iSA6Ibdo7R9I5j73IyV5ecPEdM ec/IEXyyz5BDvoFmgFt2l8rsNwAAAP//AwBQSwMEFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsACAJf cmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACMkttKA0EMhu8F32HIfTfbCiLS2d5IoXci6wOEmewBdw7MpNq+vaMg ulDbXub058tP1puDm9Q7pzwGr2FZ1aDYm2BH32t4bbeLB1BZyFuagmcNR86waW5v1i88kZShPIwx q6Lis4ZBJD4iZjOwo1yFyL5UupAcSQlTj5HMG/WMq7q+x/RXA5qZptpZDWln70C1x1g2X9YOXTca fgpm79jLiRXIB2Fv2S5iKmxJxnKNain1LBpsMM8lnZFirAo24Gmi1fVE/1+LjoUsCaEJic/zfHWc A1peD3TZonnHrzsfIVksFn17+0ODsy9oPgEAAP//AwBQSwMEFAAGAAgAAAAhABYhLnJ4AQAAdwUA ABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArJTBbsIwDIbvk/YOVe5rgG2wIQo7jEkcdtmYtmtI3TYiiavEbPD2CyCgCCiX XiLZaf1/+W15MFoaHf2C8wptwtpxi0VgJabK5gn7mr7dPbHIk7Cp0GghYSvwbDS8vRl8gBYUfvKF Kn0UqlifsIKo7HPuZQFG+BhLsOEmQ2cEhdDlvBRyLnLgnVary121Bhse1YwmacLcJA3601UZlK/X xixTEl5RLgxYOiPBM7Q0FTMNoahwOVDC9qk4kDJ+HuL+AoRR0qHHjGKJhm/117q946dxTysN/ltR Mc4ykOQP+idXdRy9CxxnjL5uRhFsdVrZ+QHGCKUJ+zr0FXRs0IXGv6zPHNYv3H34jmloyHhJ4Ky4 aFqnSditTTuAhG3jOq/aTcrLhSc0P2FC9oMTx3yf5YrAtOtouo3SoFlPeGWKQnM2mTqExyYR/mD2 CURhTVQoKsk6kIcmQfwJxS5Th/DcJAKFbVfZKJuQb879SPCjdTn8BwAA//8DAFBLAwQUAAYACAAA ACEAyoGXQ0wqAQAgxBEAEQAAAHdvcmQvZG9jdW1lbnQueG1s7H1tU9tatub3qZr/sMtfOqkbCMaG JMwNtwgv93A6LwxwztSdrq4uYW1jdWTJLckQ+vb893nWfpG1ZcmxOdhboJ2uPoDsEMlrr/dnPevf /+PHOGR3PEmDOPrY6W7vdBiPBrEfRLcfO79dn22977A08yLfC+OIf+w88LTzH4f/83/8+/2BHw+m Yx5lDL8iSg/uJ4OPnVGWTQ7evk0HIz720u1xMEjiNB5m24N4/DYeDoMBf3sfJ/7b3Z3ujvhuksQD nqb494696M5LO+rXjed/WzzhEf6tYZyMvSzdjpPbt2Mv+T6dbOG3T7wsuAnCIHvA797Z178m/tiZ JtGBuqGt/IborxzIG1Jf9N9I5p6i4t+Vf/NEfQLiX3yb8BD3EEfpKJjMHuOxvw2PONK3dLfoIe7G oX7f/aTbn/v38kdeRgYniXcPUcx+4dyvq/gwfPmXxqH8HEi+M6mWf2N3Z9HDKInQr8jvYZlbMP9N fSdjL4jyX/O4j6b44UIj/sj5/s8knk7y25kEf+y3nUff899FirnCne3sC80rPlq60i+YU92rkTfh HTYeHJzfRnHi3YS4o/tun9GJ7BzCWNzE/gN9nbD7Axgb//JjB1r6vrv36bSjL11A9eYunvChNw2z +VcuCpfEb75IxJer7CHk+JV3XvixcxHiCFzzH1nnLb2YyPckZ3GUpXiPlw4CyOE4niYBT9hXfk83 MzqK0vmrA3xGxTfiF75VvxFfJ+o3Vz7LGv/p+4Ps8CTwxjzD/X/Bw2Y88qIBZzDZ7PQHfiLLnrJX J+dfTl8z48+v2+zPcTKCXY/esFN/m54nk08l/jsRn6d+osLHrS85ga1+VugjPoeUkohnWzCOw8yQ yVI/fEpiz4cDcwLTJmTNGkYCi3zuUyiUTdMDdiVCosRP2XXiDb7XSu1qm53EUXznOQ27NKzFmgV2 +mMSJByC+tWLpl7ywPpvGELOvVpBFV/4tM2OvfHkhoeh07DNaBgF/QfpxBsgbphAcDy5453DolAe 9/03aGfInRSfsRQ/bzNDfoi1kjgeniYJwpDsYYITk06gqjDJiQ7zKgOUNZucL4h7I3+pWz2NfIpH KWx0IRZi6CcOx3Es1mBPYEqiW84+ezepIWQnxfUkVWuR4q/T8IH1RCzQb58UW3FUW/GQMJoWfNxy VjUvR3xDXTlEpsrOIz8YiNooO46jO/5AFYr2qV+ThSbDa1Ryh9lWwLPhlh+M+VZ8FwZbO73t7EfW PnE5Q7I2x354dJNmSM3cqXKF8CeqwS8KF69HQcqQJA4CNCClH9LNy5R5bN5hwUtlSRyiav7t+DW7 8VLnrfLGzHrT6NoQI43DKXVXRWMjG3HmB2nKx0Ek5RkPGV2MdciR8EmcZCyIZLcYf7GF7Q3nwdbn wS75P6YoMRMAooX1AHey1nayai3gNezbd/7ACOuQss6X366uO2/kV/b1m/j+8vR//3Z+eXpC169+ Ofr8Of9GvqN9QXzDci5I5dtvn5V86LuZ5I6/ffly+vVECu/L0X9BdNTD73y7uD7/9vXocwfODD4u aKG1aZgQdezIvISzLGY3HKJBRx+Nqww9Yi9lPk8HSXCDHyCzy7NjttvtfmB/wXf0zV9dKOLSnqdL ew7R+QIogSEEFonOFz6O22foXURiIyJBXl0CM1GmPb0ZBxmZQli/4TQM2SCWeRgB0+6DbES5WvuO aMPcGNrod4FEB8J0fDq+YO/ei5BDfPvBOSnnpJ7OSdVmNab5QDkOMRUynO9AoTMdaAnfRuUd/WZ2 Gt0GEecJ3uXsiGVwz7WXfmdncQLb/ur89Prs9TZjX+MMofHIy1gMuSXslrDvKRt7D8wL05iKdxkC 5Gnm3IDtwuq8siGB0YomEcopJErVhxBSozBzME0SGvzJ3+V00LIOCiB5yhB8QeXUKIjvIS8gdDJP tqmlKwamRIc3fask+NY5eefkLTl5cRILLh7zOoHP0K5BR27s/QjG0zHZmjT4wcZox41c3cu2p6By JHlw1LumE1gX7r9h6LOFQG3jOwguvkGXTtTAbh6U45+FcDBMXvTgPIVlT5EB1wN3fo7eKPxF5E2Q Bk6SANKkUuY0nQXZyvdTPTPhQw6P70Bbs/lES21wjAUj6/FCUjfIaxCIOJvDVIo4GyE3OuToDlFU R+UXSPcW8xTpdqd9mudKgs0oCd4HKAFyMZHFAOAojWS5ENSFoE8Xgh4ex5OHJLgdZVSDAN2EM3tu 1P5ppvwXIQxnp+7V4DVNmvYZlcIwHTxFyYQCZypfTsCzQsP4gY/qCbCIslmMV9p3SBvWC9FpCvOm 2ShOqOB1BKclDAmFv2IgtY0MCS6GshRD5SdSNlT/zgcZBfyFNh1ZlJmR+VPKPvNbz02s266SXMza qpeCEQqNLAhOSOpEEUa1sJbVCkPiHhJ+ndidDK4PPanoqJzuDxawSCG+PJzxMXGEjSHCEPVHEZqU k2f9sv76lwsPM+rdv7YvoFxG9Z7TAax8nvf97unpcU6YVnge85UGcqO14nleGqFdpdBe2kNaSUVD L80uiVMs4T7Z7E8J974LjsJl6OFOvp0fa5M/91VwXFAJwjmBF1n6ckq5+ZT8lcLUZFTP43yGpwlR Yo5SvkWDpq+p4caHQ0rV0eeg/Jy65EAxtE8TrRjVetqnyfQGkiqMCqOqoissCLIvQo4Zb9T57gJ+ T4LDD/rlFubqDRPeAJhgGiN4wERcStJ5yAes2AOoe3WZlsrsKNUCWDoQPNxy1ABXMPnfQqaJhkkR NTCaXsz1Cmp3HPsc/xlPiIIYhMzgaSZSELRFhkk8Nt/OxrC8zo5aRg8F0SCcQmhXwXgSyg7Wp6sT 9ll6QZZBgnPzj1fQPiJu6G87V1hkOLeEIKKwRLYlRb+AFerVZEBp/gKgoTv0KH1hQONpxu69BOyH GcD7zhva7i8Ys8UkzGpddLAaB6t5QljNNe10IDw2USM5zhO3wgJNnac7XrXTgV1EiZgySmJ/KoMI tr3i/xjruajRctS4Cyle8wRkXXEY3yKKQJxxdHND6bZIydOfypSxFlYzG5bA9SDFK83CRtyuoliy ij46KRaW6FgK/2EPt8mq5uS8musQpPSTOKA0/NVXZGtY44RZg+COY2mQKWPG9p1FtWxRSYpkVS+C 29uHG8x40rj8BcbhB8EEcdpPJEjyZN0dJ8UGSJGsqmjnHXsTTy4wZEdRFE8xbSW2Ky6UJet2nRQb IMW+lmLRrPqBqHtdCipSUtCyKLVdZd1dJ8UGSHFPS1EtzlPqWBZbyR/OpOgyDdvFMfKL+5BioSZ2 +gO7vOATj5LBCNOSg2yKCmdZpFqG+KttxE00LNMgKb6DKBCaAkzKE5UkEjfA0QR9B9nIlSwlt/Qq QaxRCSU/6gypdUMqEUl5qljWtRrzWVTBvUdK0URBXhbwkSZorQH4yPuDEPukUEUTe2qHydbZpdoJ JpbUEshHwVw0fNrAVFvLHqVuUgZZUEV2DDxbOmPXX2RfDdHOGR4lwTU83k8+cEJfd925qz13NgVT Wx4mS0OuglLh4nG8xlrAP7o10OYDH+o0oqQsaMxWbD5U6wQbpUs1Ijsn2IB238JKGE+4PLSxBZbe 5gGsEZ+JNa4vEc58+fx3rOvKhzs7jRUumVOqSRl6ufrOVZvPd0i7OYADXOoRnpHxvAYGJwU+jsBU Pw+4yhK0sTDwsPveEMLy9t2M1xsdyeOhnkPITiVKpRhMxEc6xmDzTrnY/cFfc1K0zvtF0sszakD2 QLmHOpbo1eV9unlfW7wCVhKni9ZrI33RfF3Q6/mJNJ0Um9BCB5ABcqQiyCUnh4xCzlfCsn/iI+8u QJkSNa9ckBX1LifF5kiRagezFp0pxsVyxFYfZ1GtW1Spi5SyHN0SKXmug4bwip7Q/J7tuuar/bZd X9Tw8pBUKiTNJgxAXqp654stqpOifSmSLu5Ww8toSZXouzopNj9fJClKv1gZ3fzEsrJdB9Ztii6S X3xsdOPqtE2RImX/j41unBTtS7EvSuqIZrJ4gLXyc/CyRT6RolW2+85lGpYzDQIHfo7TFMSwt3GC JYZjww1WZPlmnkFSdNVw+7q4l8enYn5ldXSSk6L1ajhjeyI+/Q08LZhJ/Xa8dYl6uOiMbV1wbKKL MuJBPPr9ojy8onWS7X5wFtWyRSUpLopPi0VULTfzq5NiE+qoe9uyt1iZKxaFWOMjnRTtS5FA80eZ 2snJfvfCKWcXXpAs32FkPddftB/d7Mvo5njrajqZxAm4lLbOONbDU6+Y3KFpP+d/Yj3X02iCFKn6 hrBGyW7rd8yt0PTDEhIkmTop2reoGJMW0Q2k+O3z5aJYdF4L5RXWcz2NJugiRTeQ4hWhCjGVu/V1 Or7BTusF2UVRoqznxgKbIEWq30CKCG0CDOY+bJ1M5VzZcnJspRRbAdd0D4l+pNvZcU9bFUZHGDj9 2DkGqWwAC/+Vi6sb2dmx63Z2vEzCvlbYl7nZM4XfX8Mcp4bb0zyn26HwdDR8dE5p4rgV57UVD2lF Kes5+CkhpjIjgnCJSNkSYyhLplGyrOGARU1IpYibQ0ixpudWTH/nv2e9x47Zu6GwFWPTBWO8+9vv IcWqkj8bht4tS6YhSsbz0tNXnBTtlxhJD0+TBIXhSyy5AFkObVMAP3hd01vLbvaV9Rw8zLZFJT08 P/p6VKY7mknpZ985KdrXRcbei9YbhTMDoYQ/k1r5dSfFZkiRWm+o/GCV0G1Ay4RWsaf4qz0H1bRt UT9ADNg6gyIeVpaUSOTKWlf9s5NiE3Txg7CoFzEtnAi8kF2PsCUzY1+WjXGcFJshRbKoJzwiEQKt eUXM8QOgM7MMxNWLcgypm6znYNO2LSpjHwSYAczwW7SwLQywDkrMvP9cflqKDnDbBCkSmAGcR1tY x0dfcjd5nqbgTPpZ5sh6Toq2pdjd2aagRmI1YyA0F1RpaqKbvoNqWpci2EMu+RD7vwEpeoQMocZO ig0YROlKHpic76Uo1GrtM686KTYhRoUUKUg9xxZvNYu5mhxZ38GmbVtUEADzyA9+sCOSpAxnQj7M GPHGD6eC959WQec01XNW10mxCbp4JOuovlyfgpwRS6GHw2DAvBtQiIidOJ4ewa3KPpwUmyFFMqiS tCCn9VkhUnVSbIYUaUDz5Pzoy+n16eXfrr99+9un367+iw1CL6m3o7MIh/XdCENj/OIniFJtw6my mzOplb9zUmyCLn4SfvELAhwUUU/Abx1EYjEO0FReOGYJFrVjZXsiua9TsWS1+C437m593F3S5/8S p9mctJbyjE4P7ethnmUcw5oCdpMl4J1ApxEUsFDLrZ1dhs24KVG040daSuUjes2KNTrWd/g36z5x mo1QOv0TO/J9jEanq1fgWL+FXSkHm1Y7uc5Qf0+fDnsvlk/BnhRX3bfPX7vTtbbTVQsEvh4FKTOq YsznwyCCQfTYjQdEaapXvlMZ7STwxjzDaJxO6dt3Shs2VaHXt786+Xb8+k156csgHlPB7BKrBjkY eJMMNivwEUXRrsHVt/psYqorO0xEW8w3jlbdvdat79nIndZoVenGizLA7ZoSyLfyUGT7vr97tt/v FIfmrrIH7K5VWyKBvBDS1G1DKcTEcEbXI5RIP3bGAbZz/ULjrPlc6/wrOAOwuWJ5zf2Bvk39y4v3 Se8Sd4WL87PCxfs17mVuWuFR87VAKnjpvOWBs/TVKjlqh9/xBw+dVOOzdw5l8w4Fduj8+DViGRw3 UYwIElGzT0UbhhKi3KF4WMSMaYVBEtygcOFFpsY74W1eeH6QDqbIhnwWRCJ5HcQJ0iOMlviU4EJY wW1kStWPB1MySk7xLJeX/nJ5dvwO9/BX6N5XQGYhP2BlSeFiVCTC2PMxlwDUEPiHcw2UoZ6SdpA6 GVqWYSkQjxGFR3HGPFmkYF6IZmjZrIYYUhAK66RnWXpFDTxikWSJQhVwTv8SHqKT7bOhZuYjT0hQ BSdCyyKkHJc0rBIuYkgHeVREFSDKproUY3uipPix8+U4mf6TLviQ8cfO7k63v7XzYWunf73bPej2 D3Z2/q+M8HUsTZH/7qe9o0/HRuT/9JF0Tbry6ooDjJ+DZ14bj4koDM9pLfbfLt/MhG5lUvzoSkPh F0mhR6Dfd8KH3jTM5l+5KFwSv1nGXBMj7boIvSC65j8ylW+tJy6jeJd+s4t71/P5osZaowAyV6kL ikrVMeWL4Zl1Lax9R7RhJbA5/3rDs3vOkcHcxwyQwEkcULX+VQo7h3kHsT+5t9193ULj0jDJnU0T eNtkHCf8jfC7uRKiKi2zTYRJVACaTMIH+ob/QLhLuSjKBcpLO/2zHDRpQyikpEpy6RtdJqAUhg1G VIFOSYIUXuV/gzoMTn6W5TfRe4kogdl/1+v9VWiXUMFJGD94NyhBoyDEo7sgiSOq9iDyhd5SLW/s 5GcbzJBrUyQGo/1YFA0CTGlKtLShcWVn6bTPsvblLq9UjDPjzhbGKq1IhNxDVnUUXd5OXVZXnMA5 uPPCjx1XgUF9MR0E89zUK3fUXZnp0+ma66yHf46TURzx6A3jaN6EaMipP6c/JmiHp+xXL5p6yQPr v2GoD+/pl/XXv1zQ9rqeYwR3jODdPRzX5+gOrVSaHCP4U6KSW+UqWhGIW1HK7JAmga9R5gUmMYxv H0R16ejmJuF3gZhgayHwxB23zXf5jnL+gHyFd/uqX+7gbf7gIa4/ipAI6L3xakYXra2bB7RJaE8n tbRk+ZYaW1OCYIrX5E7d9h1TO56qFiAACUrpoIGV0Kpxgldy5o3jKXgQadJTcZSkaI4wX86DepgB HYCFVlB84U1OipZL7ZBiuf3h6uovM8dumP0Ac3GcZSGsfPuMwGMjjhOOyu/OzslJ990HgbAUk0fr gPL5PESJhZCcu8sgOXvX3d2D3Q8CySnG6MwJrD8+9USfmIpSdOnHgDWud+BqkROcnWMGeAC5QOEN BaRK8R3McM85FYlwivCcxtkHQDb/2Hurfuz1gFT1gZmHZ60fGB6DwKGHXkTPp3+i7yWaE1cO6ad1 QFeVcjQEuloUaf8FiHSRJiDOw3aBBRIvAsT3/tCHUbCCaz3IOMKlbIQeLxOHVx5li1DwalmgsGTc 42yMtTzxvK/A2xYM6mHBag6QFATRIJz6yB5AoxaIfCGJJxPKALXFfMMwhyDtSfHjX4cFKQxKK59j E/zesLANCQM6ccjoEv53Ag4XRMTug2xEiEfILkEZkzMuNnHJcUkQyrQws2ie9I6FgkkyNCHJlJEG emFKmNQ4Br+FzOjRlh3QtKQI01F80ZpoWJc1OXGnggtGM6CCkBDhTFmMeDMBCpUcLxlI8R2tZxp4 E4FRRQQKnLFPaRbFpmNTBU3fMGNiKHuGGndrjATZYGIQ95lHlS/fFzxW21Tov7/XP/skEosN5I3v lg7wejubyBuRc6iM9v2qd7ZsaqU+37VGpCqZqo79YBnw5xQ00XHyJzEozQ/YBdyxsuqY1EKIJVC1 gU5QZy0gGBUVhy2I4Z/TEfywqqDXXLqYHcHuzqq39szO4A08k44dyPdQC8cPNA/kK5RIRHhBL8FF jcE3iFgkfc2ouYOtrcJNqaNeSLZwRfz0KEt/IotnGzWC3aXmoEX1bNNWsLt8YU/d2jM7gtcjmneM 2Tj2gyEm5YjWrWD6ZtaO/X0K+llZudM5jWxNvYQTuHwhceMncPmC2PM8gTpjEtYPvlcYwuIZhOnL jeI6TN7lOloD6yrtPzayeFYP2bB6wGWOtPiKQbn2ZfbuzNmB/szGnQlDAt8LXi5UFXmCqiGVpmag BIkFQlH7leBlHXtU52jfQW2Y3UCWSZIgJq4bifvRKBIUCkmk23OcOY+K2Z+VbXfGZPPGBIs+ZBPC +S9R0yuQN1W29fTF5xQYNs/2HVX5L8MpmZX1Is90d0+2XZFbqnpkd3/5YlB3nizNwMEo+apaR39n d6e35tk+lSNXFyRBr5mCC1V2mxZUFc2Pa9aI0B9Wos8tne+Kp7LeiZA3Cg8AVICd83oIQ5iyKYhp UeLNo6ac9tQ4nc5Tbd5TIWTqQERCQh3mayLTiGPXcYrVcSBzGnNEvrIOpbyaiI6J6Yl6eg79AOUv dIYVS/tT1yMWseJBiBUrN/8XCzI2Dm5HwLljmSolNDG+C/ktgSBEcuPH9xEWI3Fv/MZpon0hgrrp fhQMRuiTA+8A6Qn4ww0H4z8pGuuYIygdUZxrF+7I+YjN+4hvmpZcrzBB4AgL8urb8ZXLp5eeyjCD Xx05Ls54CjHlCpg/2Hgdw68Ad9jdBNwhj5iN9GCt0IR6Mlm4TcPrFYHA3RXgGBXZT01C8PRU0Yez WjmAVvDksu4gIjSQqfIkwl7uMWiRM/wfVbC5CW6FFC6cmRXwCfLM1OcW1vK+w6uFaZ2NY3gojKZa oyLBB+bU4ay6rNY/lA7nTES7K+A0Giui6tS8eFZvFqH2nzAQoPO7gnl96sienkQ69YKEV0BoPDcJ w+wyVQrQGBzDbgkThY9CzOqQDhSmcywVMVygvXSY86x6I3aOU43lY/muRqwrJqoBRNifL12E7Y7e EzEK/qSEVB9urIDJe2bO6IilYP4D4Ono94tUZAO1jme2RWZ3BfBaxeexsdyg2s6cR9idMxZ0Tmb6 A09rcWzwUMweg0pFtwkoNlBpjFwfKWdFWCq2ozq0RROqzpSoBGDI1Kh9gsgUiVTmUhoXSDlv9nTe 7LAHBNaVXntNZcq7gN8bfuwJ00RVzHBkz/ggLJA9NyxWB45/BrfIK+RF54pqudp1zOSuXXRSab1K kI7R2Anj+7la3MsHozVMiKWFHOiPKnC8GmGl+EPswpnwhKKmmT/L+63O2ly+RHSX8xtQVaw2uDQa NcoFuhoPPohBavJHYUqTapWykps9EbV831HLv8yAuRX2xY63PzwXfU+ebZ2A6zMT7YbSf06+nR+X Ls1+/HUK0BttA3au3bl2t9UhBkcu2Fy+8nvCgy/2etUVR6gWwRIAuqbdoZipCvCNuqJYfTRPbxh7 PsqxQ6wsFOtEATttnxbaMZu1sivNUBGhD/q1YYm0pxUOrRUP2bDjVznVkk4n1CHFbm/y5KBQ+B4B ysw8gZIV1/Q66TaCZJsmwehhVioTLR1B7YapAyEvQ1xvFNkPdX8k6WLqoOm25wtSFNZ5Qk4bfDmS nQ+Fd0NuUDxsGR7KNeFEH4F5Ax+yzGLnvy0PFnRmENGvVM/sCDHiqsKKiovbHay+KKCyhJpqphAn Qssi1CFYYcwHnXJ0zCV5S1SNHKLYGtsNKWAbx4kLpG2bURPl6FrhL7Oy17Tgi5K1wlCAYcuLPPC7 K/Be9Vaa9z59v3922u+sdcpDwbaqk1jAVOS8Nz38MgCv5WngexUfBfXDNvHMoIHXw9UlqebzDYVb 0b0bo6GzVpnUTd4YNwuJ2ESdAWGr4lrV4k0xgonpNsS7eYkKkW35ll2nnvgEnn6cqVp/UUCMOKeE AhHNcBoOgzAUE+l5F1737VPNFUu5h3gLCRjJypGToOUYdpaFiNyCiJoSCXPPo1uQRASo6VAl54aP vHAo1ivgqvzJbWYrIC2sWG6sZUNFPmGvsodJMACI6QHEEZJA4LXcuwdV+xx85/dBylEuKMUekLlT Q8tqWI9kQq74M/WT4ncytCzDgvrNGDy0ArZPOq4rs3lOiCNh7sHmn8QhFiRR38WoB1NPJoh8PkGN ivbyYMSGXHsOuKS/1sIKSMOKA2e0nOWHN56E8NYz2fAQwRnV+rEz6Qe+o81KqaDWRMJJwiZRt8/O NEx4usOJ/BXpKmU78fSW1htwiAzNGKJBzd+j06FcyCgep04DrQ9RXWG3SWGQgEe0HyllN8GWWkUR E4GH4FobiDErSPseIfjs7zg9tByNqe6o2FdGLZlZLSKL773EL3g93dGGt7zF2pEot7lOiJaFKGoS BEtIg/E0zLyIx9MU6a1yeHNDqaITbqa3LQxnXOS9+cjbLK9QpIYgrhCoFeO0cgFmmMRjChCcubFs blCFSSe0qPQO7flhXkSTNTSFs1Hl0XwO3gmvPI5kqQZaEt6sBKNKoO3TLucHNu8HjHILdojFIuHT 60rQMLvPF9hR22zgJQlgmASXTZDfZ9xv3zFtWAIfzJhY0Da59Ki1QhMSyN87k+D29uHGG3zvSJkV 3iuGkFG2CVLac+2kaNmV5xUVvS6SAZoHSANPSDxCDwW5EGFhc6m5xG9uttiSM9cYV1HvnO2EZ0zA YqmGjUYn2I7VxAEDDYDQSBWkRa6jaRtWqaAhwrVNvMQbc9DeooRW1EIk9oahBOVmEsfD04SQUmhm 848dxONhKFaiyE0oOYZqg4Cpw2/Hf7uSoy3c/9sZ97IpjuRSd34a+fbuuwa2A7tn3LsLEzcfJr66 ojQTrf397d3XMGdFJ1Rr+0ysjnkAnRA3L0RRViYkm2nVvh1v4aLkLizIuffalSIdtvzpaNZqrDsN DMkuBh1CvQ4I9gUZTB7fUok8BN8VDY7RwiDZxKKalytD2kfzlXMXCAXj+VQqoM1OQYa09Hw4z8iZ T9+6saLEvhAhM9BuYs4rV7W3yFEK2oaZ2kwVkw1QDtpblM1gPGTkwjTLVQSseLoJopxINRdlUY7Q xqtgHIReEj68YXD+htSK20t2V9jdWDPA0j3u7e931zu0kx3myY75LIgxbQ6FqMSr/uNdYa2O1Y93 LnJXnypmoJD3Bv7Hzu4Ke24qHsXIjdWE0QkPyShu4gDpWa6t35HkSEpofYmEV1gc4bKWzWct5fTf mDZcYctQc8+d0K+aE9eoZgNFA7XmrLfCOqEKWWxK2bNDBKXGQ8zcBGSgDFpvhc05FQ/TEIO2aPNR ow6WSvcq4xWV5QGEOgjjlJohqkXSwvJEo4TG2PWI8PnAfVOeJ5I+T4AXBHhItzpERZ0yBEouCvkE ZfNIMcqq6GZiNzwTK5TuDbuZZqL17wHwLTrIVGyh8cq8d+UHglEPYxilJokToeW0T+ffZfVSuTy9 LDcCI4PPqy4kxBaaUBfCbz6Evyxyh6RswfCoNxjEiaAjQkiAgpR3m2Bkf2s6iaMnsTInRlapUs2f EJEXUtAV9jsWYskVFl/1W7c+d0a+4IW3cRJkozEqVEcQ/Q0AE2Oa+stfwN75IfbPyhVb+cZy0MnG Y3rjpRfdctF711F8TzazC7JYgZ5GykIASvRBaUhcT62RMccOEATD8ZAUA09YtehyGWO3eHf04w7/ U3N60HNIs1UQ5Qr0Oo0VZW1TjERcgKGg0wVriA6ZBAwtELmpDcBzlHQhB6TUJNxX2QNGcdVunmOl WJyolDFiprAhBmPL9Qha+rEzDqI4+eUoSoMO/vaIvpl/xdhuoLVW/3LjRiFx1N3s5DuH4sNP4gH3 CTiDKOof04CopEUWA04f4pd+Ene0Fs+zLuVbxphUGcifPOT++y7Ro5OwV3Cv63pISyfuz3EyQn4c YQiX/B08oPpz+mOCo5eyXz0syAP0uv+Glgrs6Zf1179cYLya7bk9Hw6x8XSIDbcCQ7gxc0EPvNSC 7QU6UHG2cvNZZp4wwHqKyqQfD6YigaAhuWBIRUoPk7nRLQKc8TTNtnSJMk8wHEm4dRg2gNdAlFAE 1kG5n2imdVpYxl6jC61DxhWACvvzpKMUCe+ddPdOP6wbqPCqHDXaxCdoSO/eayjM2ZRA4kxpiiKJ oPpv+Y5dfX7D9XmArZPYp9U2NIyXa0Pqarcu1nu6WK+2EJEvpQX9sR+I/UuiLXRH2QjYUdNBPOFk QAgDqEmgtJt1xsNyZyiH5uZsqTegClAlDO7TnhTVGhp4qcB+zki+BVeXk6BlCaI9m4K96YZYZDIU xCcZzWGLUQ5DNmbdz6iCv5urgi8P19tbrXR6dLz3fmfNeE9V6662WNkoibMsRLGOPp2asrj5WRVq pOqTMmqkFY9kv0YqbhQPaK9Gmk994TRKOl8shcGssqQXM46mS4Y3nwwbAjDPu2EbPpRtQ395GN/e 3nwuVVUAPpFN1wpFMhoJc3WWlasvM4VHMHIXeOpgSubJx9gD9ek03x6IG7VqDxACfpNc+dIaYJwE 4QWaVmjMooJdHuVymSVVHQq9D7Xy+6n7GphLr3aU6BwsDAXT6WCkIw7UWeJp6BM7zMhLqD8vEGA0 SmrYGWfoN2/oRx7IvzyG7GzAERuiUdxRCxGIkKDDChO9+6816yeV1+hlDahwUrSsioYAihMO/eWB 6HsVpc0F7nj3pHv0fm+9Fc+FobqwMBVeua4Fi2JvAr4XC9EELQ65C+Jk8aDGrB7dXx7xVSU08gyb kE6NZ5iVB8oV95/FQU8ezmWHorxkaAecjM2qOZyf5LUQBlQuLOU/MvBgB+Bcxqtm60kh1spP4Kro G66iF3xiauB4yGOiXCk7hAMUVmhJrURZFeE+CmeXgw5dqLP5UGeWTIiZBdcAcQ2QDTRADNNdX0np K6xx7iON0Gu9tHSH/2cU0P4URc8gCAOxo1lUiVNCjWI6K2Ydz/+7N0A63qG5kEKd/41knDUe1Nm3 zds3OUGHWklBUuSD5LjVNJnEKSAsNJNFSzmQvWuBMkHq7DkBWs7idLdNLBzMEi9KJ3GSvaGBFwow iKfbkJFpTWZ9iDlbUpMRWO9DyBuFrbDXh0DEbbSe3apykSVfbtD91BYYtT7o3U/CwKGISOZLY++E cSObJqiIYdWye46VJmq1iaEuzidt3idNvACT28NCZEFzweX4Acu8whjDSPiK/VEAEqhlXxMvdRVi 22X+afQ9omW4gj+a+uO032sajbE7LwWBOwyooWWmUyo2C/t9Nf+jKnH2bQwmjMo3j5KjQoX2lx0Q IwKPlTqZmyjOqdLpYbFwQXLS1+l7eF15hdKLQvlxWThs9YPXBBtrKO4J20/H0jiAeCSLBb4aZwZw wyAJboArERvBg7lbdhW9DVf0cnS/2LflDQk2Tv4GHkiauCiONMKfMmLpknSBVmVR5YPnpLhhKSKL zZIpFyVZQxhGE2xZpjwYtO6LsuTLAvWqH3xzlpyg6cKaq60wItgw5NlQq058AsKmD6sGIIwnMFzs ssRztgWDgdLt220xOlCOJIq9DIsO9xAm+URNajmvajtZECm6OXJSUoJZgL23LFSwWgmMCoXZ3G94 gL23LCij+sE3Z5afoUn+8tvVNWBJMtoGfvCBhWArziSsGBxyxmmEU3ER24YjNmDHUBKaUpFnkGBC E9W8qjjbkJNZUygUussVhRrVsF/oFjeK4yZT7pd/6Jxmra3Wetjb7iLmyQfrjmOa8AwZ1GISw/Wm 7NVXbNoBnc4YVu+OvzZUqRWCacVDwpg0ppAKNDjVUjX0j+DE4kymcTgVe5+oyIJcHdcBwQQZFBax APuGjRE0S0jbo4H9jyftO6kNE6LkCfOSmwDtZwzo5h24CH21OPkuyl8Vci4sBnUytIwiAKcy/zHA /MwttIz0i5TLYx0RzKPAGQ8CEQ13GPo3GAwN0hHeqBunELOToGUJErPdNNJbqrj260r58p+Buyqw nRg91Y6ToWUZUpubxmTUNI3G1HX0imzaF0qouiIMK7e2E84dsbntUhZRHqSEbUxIkADNzSRGgoUa bmXxFr4UvCT9FerweYTuhwKb6y5cWLq2pKim7cpYZ4DtAhG4ugQwH+rHJ2H8IGi97kEWDCKvMAsm QL8ic+LJmPtwjoVpU9H1c8bUsjEVqkh6paKUujA0d43MS9AYhJa6cIZKYnbnhHO3JsUoUXxg1APC HA5Qx6rzyaNLKpoDxdTpAa1plLQI0MFf4nuhZKba+bT5HHTOiG+QiuSTUZnLK2wrolfwfhhRM+MW hhoieUFIFNtXC26SItkwdrGMfUOK6tkwuJ0mIn1342tufG0D42vXCKKGcRjG95TCIjq+Tbwxcpww BAMuTqIMs3AyNX1E7u11g8JFz5bjr1NdQELB3Wcj6bQfIEvaxyVnvyhURjEw8r3EZ3+5PDvef9fr /RVeQOCbnAQtS1DmsG/UdLkQo0hMTQ+eqrRopq6Iv0iy31G9cOGX9TyIRMFDsZNIFInoZ21QD9qn Y64atvlq2DGwkgGaBsjQmDQq1IdVZp6C/9z2u/DShZcbCC+vCgdSlmjdgSRXIFYZOQu5Ngt5+DQb k/bdxqSXaSad6q1P9c6p0wZA0dZJ4g0zvYKs+FVAVYoXit//OsWkHpaY9V3IfFmoSVZiAfXFxUs6 C+2hBqzQc6q3NtWr7ZIfFcIwUVkQmx04GuRIFIgXSmA0EzZJ4h8PbAyYA/oHxcShfbrYMOQmLKTL 3RA3a4v3Ei1jw47cyelFwWzocn8+h1Bm1tD7estbtvd2m0YLUrBshl2rG0OaewI6fN1+v7ezb/Aj Wx9DkjcKB2uPb0s0mFGX1vQLqFmfC95/45N2McDmYwB4kFnnQPSZxcJL0nJiu5CgDtHwu49V8wjA OjG272RnuUEE2RWQ/SlwcoKypGyCC7PXvQ48pTcF3VbysfPlOJn+ky74kO/HDiVXWzsftnZ6193e Qff9SpQYFXbvyal/FIlRdTgreQoQt9KpXILuaK//hz6KGlv/5M+cKSonCNZQt0JQULgVHQYZQ/Lr ZZGtloZ5BCERi1QR1XdITfHSJ1rQk+VJwJ6fnoDEF+D2ZdVkeVawqk+icDbXewyhJgVy4pJg84nJ wu04VWFf+T3F4BQYyrgjOwQGkPrTKZqFLAvG3PUDX2ahu+A+7PuKQjp5xdM0wOAiO5p1rEFfLa4V 8jPXsn75XBJNO6Lfzo/Z0WyOVhxRulaIwCUbMcXhko4YYyj5MTZckkt0rSS6c8Uqws59izDZPixN NCgIHc1Rh7G3KFJcnmSw+6GpGZXKMeT06TK50/IEg1UPXYjC1h4UEpW+nsItq6DISZwqWlFFSr8o 0pRrP5dXt+UZFKtOnhHrqAzgRO6Z3WABQ+YqsZj1XkLb9pcnzKt65k1qW10KZrcAcOiyGJfFbADV eEZTWpx1C2MyEok/jlNs3vHSYEBUSLNhLnaPRjttYFKgXMcPbh2tD/lE2LmDKVYf+6cHGUBHmFbG qj9BJKDbVvBXAy8FGoJcWA6tVolqOcxwqdqGuSZ1bFGmPhL0ADeIOGYJGsSnAfEISJSQ2ydAFwRb CYL/bYv+/BvaePkfdal9R7Bh5R4I5F+MYXAG/539wQ8YXfiXk479xrfTHdG5UcjdvMNlZLjrra5U 91WlsvyLEYCkpDviktOdRugO1Kfsd+iSk4596UCDDMVRGuVE40RzKoClDZjWaF60Rlrz33kqrvrI /8+FarbZp3Q8IL8W/utE0xDR/LeokxRa205rrJchndbMsptWFKda8ZCNjBoKLglL4VUL54B9Eu0a YRpnrIjti8Hdudx8ZRiTUeoc7lKDCR1C9JuwNUWSf8lde7RAK8PmWqBbBsEE1JCCpk91rIKofQe1 YbaFGoMzjuPhjOZYzqkQ8OwIQsWMdQoqctdIlNQ3DRPiwkZimoENs3qZitFVdKpouW5Dqug6u3re heBgivlDXzJ6Bvqi4w7RHxN1URpQcmtFJOYeEi4Qu/IunU7O2amLgulyOhld8x+ZotBYT4pCuki/ 2emk00k+9JCmFBRQhQlOJ/FB3Hnhx85F6AVOJwdB8LFzHE+TAEwMNF+Mj2d0hO2vc1cHqXmpMIis DY+dbPCJOELfOY7Qlzl00Ap3aEn1HEfoY21lK05lKx7SjuotAnPWQ22LvTP1LlfuLNaNFLFK8vS8 UIsEBvhgBXIdbK8GrhA/ODA7aNDyeqg9uHS1hhEg12mYNdLKxRo2h2+HpAz1Ej87yLtRyLSqYWV1 qhAYvcWh4BthEiukU3PJRRz2I44a0eBy6Y9D/TYg3IBM/iVGT8V/5lHz+WtOWg2RVkmLSIAVl5wl bIYlzPVnax5bn7/mdMvp1qdTapBQw9810lwj7eCpy0R2G2mL8mdyXhrjfCCWCWAd6SSMH8a0XOAe G4jK5NzYQRQPTxMadM8eJqCrTyc8DK8yIKDtLRI5jMBVa4CwDRcMAEXlXWM1t717rhGLAJcbd9+K ansrHrJhLQWl+L05njTi1FKcaATaVcxMfoyNJDTtkE4nROfZvkPaMPnlU9aaHreaFq1MjowhlpwY ecSdFC3nKnKaSI845Px211A8+ZIhIbFTBb438D929rsUtS61RWa321jO4xEePYRlIUuTxGFOAi0W SSxPzrr7hz4LKrVugnk2O8y87/phi5syxKMbkoZHbNyyFqyoEmy5mUCjtgWT2jCzr609ZtbIDafs lkc8weoon92AJdNN2bg9lE+dwCLXq0lXRPUTvTr8qeqRF4uj6l1lI+doWTdMywqZoGjtgCkKGd0Y wPNPNIwa4hXqVHHJaZjlkF7KpNwZclyMMy6ZhoVU1QIjjZtXOrrkNKyRGgYxlpWOLjlpOWk1ucHX TGOYN8jRPA+whxIbqJmmc8xfc7rlmueNbp43U7dkvFH8LzhTS4sNHftjEyYCakKKoujk9y20hK3o 2bbiIRtmJXVjugaRArDHlrCWhZVB4mceeTchyuAOQyHJawoDBGgUvgw+m4Yd1RlHZL/AESmRVMWN xIWOu8ZTqJavy04tZ6ezBjytl8PiOX+x+Gbvb3WvrWGKSOujp4AtCexSwv8xDRLiYs1GtCPQWPaI C9j3GIlO6c8QFr1lUAX96+7uQW81hMXZ2c7pp09ijcTaZpP1Tlu5zlL/RPZGdu5xpYZVaveof3wk lks/1mmo37AiPxgADxrb0l/6k+/uCGwL+jh4sCce8KboT7F6VXpQS4OUhs8wIEF7y3xsvetu72B3 t7GQIAJBkfJ6xMx7dXZKj1tzfAVIRp+Z/WUeXmirOjNCfFqwFC1VHvzCWV6brtb110uSTn56s4pT dL0H81CCtoybg4wUXqmgxe+WlkiV/SSJbMJQZofpzx9FmMOfge1WP1wbkVdNazlHEgHWle/WZUMv GYPm3H+Li/TC2Iu8W1LHS+6F48oPiswknbhJ8XiuyG5rqp6YwykoXgOIXw1T82Hpg11lapowjK+F XynQok95t9Te+4Unf4mjcMJB3pcb4LWaL+VKapRC60LG4qHiqxbWodYBGTZ50ZOu9aGyw+2yJP+w SpoP40bjYN0cx2QcAXIK2Hn6pByTT+FB3HHVycrkKnsAkt4d13Xlg+64Itd2/OiOi3kP3X8R+csq iTM8a6oQkMFxJPAzqMmlkULptPM5LUuxUz9/Ilbt945V27Fqd8n4O9WbMewv4NLHBNWhY9V2rNp6 H0PF1FErcgo7Xq+m1CeQe5jnwB83WkVbQipOZfME5oYXZ2tdnoXAnIY9M4HVTyoWcc/qXe3rOjTP JNJM4rwPq7nkBGYZcKgGBoq6VH/JSctJK8+yG9iCbZ4xhC45Vu1nE82TtJwlfC65F0mrYlKx4pLz W031W4ZkDKDXCnyC/ZXAw592ujv7/c2g3eesiYQy0lPXQLgeW3hTkDX1cOsshOPG8euJ8/HdCjyH UkZrxsUP4jFxRV960S0XLND6RnuSWrlw60tB+iU2vbHHa1ElsRx4lAe6TdaEmsN4f1D8RMFQXfo8 DbThyd67vXeyAa/7zgby51gJhw95wqMBV2zXxpAEiEbHoPEeB1Gc/EIFemrpiF3B868Uyk2z+9S/ 3LhR6JQcMnn5IMRmRsAupqqOqR5r7C+fE7agFQ/ZSL2D2qnp9f4BOzKWKYxgg5kXhuBQ90EBrFjU xaypEZK1QniteMiGnVB1MPcMvn9v/oym8ViT/heOqeKAat9RbZgU9dwOTTVnIEynUS0mRObHtJ6h tARgmTHnd0tNjWLCp3uw926lxK8iQDWCz4+d43jWHNOB59zVhcAaHUiPp6nYSaF/ppP6s0Fnc2TA gQpV5L+aAOpmV5n2cYbNKI7RvVt2Yrf64NHA2CZOWP18aJ6NGXDU9Q561aSgOUnfnIGgiTaiqiiJ oXonUhM2OanQCDOnS91yE9c4SWoi2OLSExTKIcvORuPsv2+s0T1fZHINVV92frr6cTen6qQplQRS Yrrdxa2KDuPJ3Xi9FxkHt6MMmVOK+IaD3iuL2ci7g5TmeXrExjqSoNyj84YoJNJRfB8ZauiEuHkh Uvb7RoqO9v2w3EvpeevkDkDq1bgHXG1xDZQ3i3Z9aKG5UfOXOf3RsFQXxbSVsKPFmrf6i87u229D /4sdd0soD1zanbuEeqmJBUEr9wqXnAzty7BaDysQpjWzFE6G9mVYAeuGxSzjJSre5ZDevlkatFLg Ed6NNK6E9K6QYcW71CWnh/b1sEJgy19yAnQCDPxnhUZoXlZB6pajsWbfLFh0M3uTC0ef1cobiLr0 xwmwuQLUarZQE50AmyvAkq7hx3J+QZdcENOMIEarG1a81YKVt6oGPpwAmyHA5dSt/K7ZREQmFgD8 AaT2iaTtVSgMAHgEK+A6sLKFzvmy5MtoJX8QnXNLMxDvd8ozEO+XGrGRSCt566LUoD9XA2WiLpoS WGtlAiK45j/qG7XynFVH1vX2JTdCwi2of6NwLnGFnqp6LEJ/xDkQpwYoYH0sQt5oDklzrcsNty7V 2Sybwur4pOJd7fN4rUBJtOIhG1eA0Uj08ohEkI0UpgeY5nzN3wwOqFanzW3rePnWtCXntOjki9Ok 73fV6GJlJLTWoKc+3Dn1gyxO/pQS6p4fsIsknsTYQAZ4WsLHgMqg7f0Gq8aCwYhh55gXJtzzHyQc jQUR89rnUhpmiCYJvwviacqGwe004UDr/kK4QrEzbhgP8MLfMVPAYrkrzhAX6JiTOB6eJhR4Zg8T TNCmEx6GDj5dnuhYOLtRp1wSPm184i2xgHkiY+R6lixcOsBK3SSITbxfbS5WNtI1C33s52LiRnGg /kDh41l14FqhO614SDse9IlY4z+0kDXeisBCL80ueeQDc+9fYJjlE0LP76II6ljIJbfJKhOOZFjc 7o0C178RmuiMbB01/3Wtb7KilHWxbs4Ysb/UYL6YTXNz+SIi1mfPOJCWYmU9G2PM5ceYRUtSpibz 25fPuJhs85N2aF4A7Is/S+40KDY71F9s30FtmEeATICbOS51p3CpYkSm4pKbmkmo9qDYPSw5hFo9 JCh+hdJVXHJ6aF+GFfMwUjuL8oK2npxemFg3NzXjpmbcirQSv9OjugFa06qgpPq12deqdzlDat+Q QkJVopkJTn9X9S4nwGYIMAfrzb5ZiNXXb3OQ7waEo04Dl9rVqeu9zcsJnQBfgAC1SbQzdKHg4rv9 /Q97goFuA4D9970OKrXeNBvFyMu/HCfTf9IF38sAm9nd6fa3dj5s7QD1vnvQ7W0CsA9IOf592qfw fqmlBMVbqy88q2q0+QmvtfiA51gGkK8Dq9nXqhBr9qr8bjYlov6ZMib/scVd8wNSn9pa8BS4cS3n ZSluLRzBZUlQ81t7hkcwN3qzbxbNnOXvWjQT8tjzt5aj1pJWpTQNy5iP6myvfXmcO6VWWmBqxGB/ 5RED2V935/Sy0EHRPtros+uLDvgBQGxqAoqMRUn1wI/6CQLP98Fva5xCBzkPzA8ZB1DsqZq7+ihp SMZgVg15boURb8VD2inqHPa2dzFechHc3j7ceIPvoLbHvFAQDYIJuJBffcWICdavjb0suOOvDa1v hVBa8ZB2Tl7NtgjGrsGSPodZO/r9Amg1Pgwi8KxjRk2MQmGwaRAMgwFOJ86poF6/4Txq3zFtmASx RSy4JUFh4vCGs4k2LrhCI2vxhMVDxn8EaUbmxptMQi3DMU9TxLk/l2D3rNt/t0PFOlEmfET8p34D lSwEiBpfjPmfi9ALIipiqQFPmSxg1wL+TVGgW3ZNxu5Bb3cTtcNGDWjxH4MRbV5N5zeNFD7CZVdv 5B+hUWCiPGDROVhrhTM7hJ3C3jwM0Ea0/uH+/7P3rc1tI8mWfwWhD3fsGNFX1MuPu2aErMdtz0xP O2TFxN7t6J2BSFDCNghwAFCyOvrH78msKhAFAjTlFlGwkI6ZtgXS3QCy8n3ypFfsuSkfaGOyoAlj P00fqif7D+3u0PXKvQ+H50e8frdaMrffzqfSC3vksS/VKzfluEFRUK3k2jLHzfI4vWV7sFE1X2uk dZwsG7Lds9Po+1DFKlxfGkToQ0w8cn3VOUfMB8LytV2/qD28Jd/ztcTcxU1f3UJD8b+ZP4EnSrIs vEZge/3gIZEl72M9U3np+NtNGZGKg26dpq+9C+25bBXe6guCDpM7GxUHzOzpg0Omt2A+pz9vfz3d t7nf7RWzlxbu7UabzFXn7XFLB7WhbkPKjRYmCu7QeyKbsstnv0HqJa1u0S6OaEPST6eDn/52SbfI GyT1pc+L+TxJYQ8HF4GfgxQhU9/oIeWKG9k0nqhkTumXrw4VcjOEOkVsT7QpaNciZr4NFFnFOEkh u3kSs/U9VZ9bRlhy7rb9OgY6sPnZu+BCj/fi9PTipWfn1tgOndyDKkb5TIp2bam/yIINkjZZalrl IHnCMjFW0gRjLoQMXx28OqQU++fLi9Pj1wcHv7y048deaFgvHrJjruAy8HEEEVWrTfIhjDyKc1h6 qJy3Ryv1mNAX8TdqzNGCnYD28OIEHCOpG0IsSy7lzalvH4Geq1kUSxlSGxFxPgpXSsJcdrGeZXO4 3f7e6tLb9p4lTyx5wMqtPssjIGUu5dIQUTY8n4vy5ghxDzjz/r0IwLama9OZl6ThTRhzbQb2jMo0 DyjTXK/U9r5K/lgCKNg1PK7UlYZEH1Gg3l6G7Kbm5NVtCC8l65tjFPePVvT2TJGEHx0B6vt2x11e XpSO6ew3ZuSlSufmvYeap2YATRvPnI9MQGDpdCloIbvZyp080tZs9SjkIwqPrFdSG6zqF7Npj8v+ egdNSO1DSk641ZzwMqCqmYTk99QqXgO/orOpyy61+rZdg9BgnZDS11c9iaQXkYkfZ/eYO1ofmHzd zogKblUFketShmvJwWo0bd4Fr3PmVnne7iq14Vl1tFJ/gh8d12zeXK57Fa1FE6PUmNWKVIskpXQr 3bEn1s3C4unMsbhp6yht1+JxCARsSNU/+VGW6NJQCQWmXre0elyPai8yiiRqrFlxhOjcX1zsnX/4 sN10Kh+V2oTkDm1XWD3pX03FraNvNLaUn9s+8hkF1zoFtpFCWxlEg6fAiyXo3HDv0UidLYOImtY7 DPeG1U1Zw73N8QFfhRnZ/rqEidgatmetv1ZDdH/nrRFX3wpv0/+FEengE+BI3BzQzUvb7YA7y8qz ean6+zx/BUDJQsApYLhaB0lgcB/gS4JUhqi9wgEYyAGdumdxAjcv4rd/Ajcvun6fJ7DIW8pQXpNm cy+94Yg1baAo/IgVKNXYewuCTuiYIAZh+hRI43gcaCT6RRLnhEL3s3EYwkzPQFYxCzGm88NJnIU7 +IRhBaufWMN/xuWZf3nhm9njFbZbIqcMW+2/+/CwVHO3nmW7WV59VQBRBoUYyCP8nJOJwuAbRGqW RAuGskwS4PywxUoN90zDLzD2ah6yfxF+x0QIWJ/eeuelScSDHrA4HpY7zBOAAPkiAa8nQR6kME/U IvUz/FNtreqf/GBSxZiKMeVOxLfg/v7orpufaeGKN9yTXTftlNFk180ySl1hQni0ApD1pAZdL6xo x1y9znw8Wif5jqD8OWpDHLmZT+Dn/QIo9SJ8hZWVGTIXnrPqn6fvmPh2sGRrCcvdeQkAG+rlpmRe SIsgbJAivl2GDOz0ETveMQEirk4DYKeDXap0+aSHwFVH3o7aRjpQGdEOQu15lDxQyWCXtVN/vuP9 ePI/ooWO0dVKrbwQTrGc72JVM5FXYGgKRtXbMaIkpLwfYylzkN4FqQjPsfDCGGJixK/xeIbgAD3s E6o++zMizMHQTbZQa7VJnCI9u3LmqNqkEdzUu6YoZUAUATCShnRkmiYzfKCMKVd381LzSnJ2ydm/ PWc/wCyep2aeTv25fx1GYf4AixEnCxT0yVULyZakdO0P/CKkVKfSlNqtEKMMTxzubT5scHC4MmJh OwAb7/BheHh6erxdoJBp1DF4zPxAD1uCJnQq3NezkhnHg8Zg8OBk6M+olq6HK1cHwZ6/p+qUoLxl a8MLpx5vVC0GX1l6cz+/pZBwWRoxg7CIPyyFExPYvgk0lg/+mUmCxkv/jHKWJR67rf8599O8aJe/ UV35eZok0/OU+vtUJnu/AwKFKOKv6ra9tn22QdxuRAycMkEHJpWHqb/X83ji7k4bOsWVGzeYBWKW w+1WZWCBK2qcSwfAFXxalPdxY8xGqDT4WTUitd6zGKP2jZGdEZydnrxE+QfANuxTD+Z+SiQKnKYW yKRSNnGuuRYldZ0INzxhwv54tw1OrMEiaxjm6QnGzojiM8xmdEqvF2GUA5OJtBa0r0guCtJXqrrM C0bpBSFAEM2KwXFc0cxTjEyYRk9hVYrKtCWfMlHGcG/zGa2DGno8HhA5fb2PHV/bjX3qz69BmFnP B4fnchSKCT51EKpYcQB6u0Y+4cEPMFUf+YLqHUu2RxSoFhZ2u3aPxITQKUvGqhNwH5KETFJeaI6e VTNZhWZOowRekj5S/hKtSdp+nFVoFMJgUJObAQJ/nIIadilNxV/FANUJ2J0BQJXMvYZp3YUFB3qY h0CK9L1/hlEStPYNBxfMragXoawq0mIStZ6nAR/TMLMmwRPz3wHzv+Kup4ZNWBv4YCJptKTRPFq1 3XCSDMo0TEEsR8EGAbtgILxly6CILA3/HEcj+pSy4emf43NTMq3PJKtxCCQIuA/QXSTGOpfAfOVa zFqmIkHH6YBGc5lkrci+AY/VfpvBeTSoFhY5gBJxhIRB5OdYfkXW7V+jRM5wGj+6AUFnfjv7yrow oSzHynvX6bihLD96uVTBbEHLHcxwqFqxBP2LAh++MomRtGMsOomjx/OtWpOvph37PZG8dMz/FSHz EtFcp4fXQX6PtXzsGO3hAqlrdkAHKV6xJkSwL8kORtU3mAVZkqOnSo4ulk2QbtA7G4NoWUlHFT4T XM8WsPnazJTGW3ifDDxDkSOdRiGgtCjPx5P/fKLm4pnihj798PrN+QWRalSX69VQgukv00t7hEyB SjRIluHmxFiHw94tlaRTYQo4arQC9AIr5flKedjzPsZVNFf5jW++5k2/cVYJcx4sZdEX7ZOzVQ3C g/BON1qHS8mI+Zn+XAK4bqlg/G3H/al7dvRwqh5cFuvmJG3dFWtj4QGKUCPtUnRIkX3FcnXkpH5e f+MductxEPtpyKs2GlTKwkQMN6eLqzttJWlt1Vo0YHoovBuDmkVBlUk+xfwTVGtjXGtrTwHu2NgE BUAXbXTDq+DW1m63QYvVuJl183jzLnEomC5GmYsxDosZYFqcghcO9+SGI6xyFZozOmrGVp9iG9iU /Q9HJx9OGTT0iNhqe86mABtbJsuF/sIb4Jfph3v3Iajhgcyb0DwqhoejxJ94y7xcI1GqIdHmet7i 8/4BTd9SyHO+f3y8L6cwepfN/TGmHOao1dGI+s5IncIaq2YNkw03Jy+t85TW2XMXbq+LtUtRmHW3 27UMI9RPkedQHqB8OTl1xsmA9AlDpmwUVIeKrTYaVG0YbVGXNUBqaMxntd8DUYy91hgFON0i1JVw neb6ESp1kweUwOPcX11rtw2/KyJcL0J0JMC2glkvArqrSqmBVXNjv9LIUEpZfCJK6LiDCCVcHzBJ xfupKt4l5K9E8NXY6Yq7MJbl2BRQslwF1YY1ESmu8QcaTwKnnVQcuPbYnFY344N6aGzcxMsNRRk1 3Uay4mIHZvdXPfqfskZ4l+ifY29eBltjchZ4kemyZVQUQ1Yxv0R9CEmL/BzLz4aHWOKwywibb8c4 rBlCtBJzu4xw9mb49uBku7OJuqXQYIN4roxwTqCYC+bEDkjvobEN4aIOOeqhn9pSQVHCqTXhVMUA lOk/LBKW4bE75pJRTeRO6ESAqMbRYgIoow0mZorIOQX6NAdPgEbrKeWYtT/bVQQGyy5JgSIucKkK 9V1cR7igtpf0T3q9OKLykEjMhPnz25k//5qktzDu8a6HNMSPYEf0r/Mv85AQ7n/x44WfPniHu97+ 3vDIfKx/19s6hj3c1tEL1XNS9pCVJLKSBCsCVwZbx5l9qbQokJSRIjJRyvbjUrsagoQCVckJ15bB PeBlt8kiAkVcjp1rRAuLNKMIZFHBVIsFepioO7GsDdBKOPPL8vIVAmfEHkmP6sqmWomdeKs4rVKm wTjUApMpmti+JgLmBBZGDOzboigdNYKTtlE7zEepN8focXhdhvcpS5HZ2m6z1pb4UlfKJQ03754v Vd0pTnxfPNCWlHtvb+/i4EDAs02wRXsfLY32I2VrmiOfJGPgowGqI6x0G+UfgT6vqRHDxWY5hv+x ghbiWKUBQOJ9gg/Qjs8WoChFuFQsFSaIHVLxNkQoKLr1IqRdV7SkLolBffkAYZU21mXEH0v8iWpH VhqMg3DOrd1SyCtCdNy6hR6qKAQKZwnjMTNEVmN2y4hpdJDyYLqINrrZ1fmhFm+1oVFcY+w0WpgW bXOGUXzFesgtBRli49bbuCi5Cce0/tz3ANPPE9R+0Qw09F4FdIwXp87Cm1vsUFcOqjCHIkX3Rk5T wybeDAB8AuGr8ENRPRJ3jeoMFhm9Ts048b+WWMM14xDcFEbd5hiLe9BDckL4GArCuyXCR6r43YWT BZb3NoIQlxMiSFuI/koTyKLUG7fhAASRtMaNU9kWs3MXijV28I9gDD9OzI6UZvK+3plPm0UhugpT vMBLqcpYOlwO2N8LneORn+ugTBEYfEF3JSO6R2zuGodTvR1WR9Rw9WkyWYxbceCllySDMtVBGdJA I0e73r2ltKZb0ujFQ5b6Ku7TbDUTQosjlhuPmJfMj7LE8JBwtp1p2hjv/hZb99QlnkEQt90Vw7+k rFQTHxgSiSdoniMRX27ppM1r+Jgn5w0ZoojQsQiXzOimYjIJp9huuVpubIaJv3YIEy+zM1iHqblN W71dCqDOL44/XBxa8ykdaNPyncI1oU3bJduNwXxEC4oBo/LOMU+DwZ9w8n5nOHxD9I7+Ir9NQMf6 42m6+I0uTFAefr8DaObhYO/tYO/warj/7uhxC673Dw/fXLy1hPXkC6vWDhMt5vQUaptt4wQR5oyL V7H5cre6V0EHtI1nBggimEcgoGEilgIZUzp6pTvBs60CmbfbW2go2FtHENrikOyr/g5JW6ybtFju 9jcnJ3V6OOqfjduGd5i/th7QrRRGT0XDc6bIarXumRO/ntq8pKiPyDJLdnN/c+rUo6PekdVqap9g YopFvP/DOny2dm3OWOpUu0YUHRezbSEA1cl93DgRv5Kha5tXPkabk2fqY9QcZOiTb6vDVm09HkQx 8BLhwzRCPZBjjln4JadeEPIKMqr5PTLFgN7VlE6A+Uv0Z4RM6gr//ocZnHR8qF/EJ/aDHWNOLMt+ czq4Gtm3L+Z610IQJEXkRcuN9UKxNXJmoeMfW8Oxynz25i0tfYjeXhy8ecOJwAY8799WEiyf+835 C9pxneV7O948HVJufVN7rN9xG/a4UVGhq1cwyAqLAUTZJMDsxCwE3QLZac38Ysz2LEGNIYRSW/u8 1mg2LPk3WXA3h/D1YwWNuSCYrSdOYemdKUtYPoSPyMm/y0OoO4hqKRzigkU+SKaDbAxoAvMCMJOn 1Ymi5RYEOY6CKWKMddzk39cpfETJoZUsonQKDx6R8X6XpzCczSNem+YT9BbGcBxSCzRDUfWUsAfc 50CfNPd/xQInYJ0mCdFcou9BO7GfzyE86FoqWz6Ej0gMv89DaHrrOGBwxgTO8q/DKMzBoZJlC5Qv iShlgjQzywEMn3n4aTHXfzb083hhnIc9UUp1pgoqzVGh/QnnWX84KsSEDvK2zQrRrZvCp8jUOhIA MoSTKxNPfGou11fcvu2AbCve+tYo4bt6SISrphraIpJgdPDqEC6U+dd/MqO9p2YmGyPBhuf1xd/h deMkncH/3gUvyXgV3YxeyKcXD+nmEDamwBiHY45BPp6n/tw425M4ThbxmOPBXW/due3fOe2YCMEg kHlxcE/pY+a9MGt0j18dvFSDCBOCL6L1LZwQwl6y1XpbM/EFldlQN/vpb5emyIEGSZCmRIGdAB5t Hc5idND+W2JoHKOuikYfVUfzBxSneGSN4pddu5Nuw5gses6DI4e4q7IJVKfM+3hmnSv7zks8GSv3 Td20w4vjI9SFykrlHoCl7hTBlDMA1khhraIgvslvdZuzX6Fsx0KEPJxRT0ORlKI3zYyzKB/f+VGI fXCoJfNwcEUTimyJjvr5cG9/eG4d9Seu/VO6w1QaS7YNU/Pm0GYFPvBN3ZXvKmOVjGhrbfHGjOgK 8AxyboTPWHJxKZ1RQ3iTYIoeIQFfoFPQIsMBs+vdJlluKZEIsH0BFqKCWUOJOJppg1dhxOqFaHrx kHbMZkebDsngGy3MD7AS5kx6/nyO6XOis0n9KQYNlZuGVWHqB0qOihnEYnuJmBjHmRDZedR0KT8l +YVwFpCUnkXRU6IEHyFGCEqWzoIsD2Puqw5Y+ijViBAdC5HjYUjJEkQpcKeo9+2bvQ9nWx7aaKia 0OFBvFFNrDffzdza/Y/MXvCPEzDhoVVbeaP1t9xFFiU+Eui/jG9Joylf0phdw+BiPdlTOFd9wMoQ 3W51Bk0ZwVUcZ73xinbqN+WiqaesP5i1CqNPEJlKUZPcxCAFnAvJgvke/uKJ9UxPcYrsF/EHAAjb 6i+XBNdi67UxAiPBQCJcBuHJbcuLI2WoSm23kJ8yCxOb+1dk2L55INDZrX+HCKw2vNqlwXsVfWXg Ax2zDpIqakSlkHe4JmAxo9vIdXwCW8cQUmiZxpLVaC+YAQiDsjFE7QBEgnkUtpvMReXGynPl5S5B Nd9suO8OdAn4TmG41MyR1FKfxX4jcURbc0Sjp1nitC9LnJ4nw6Co3vZU7yNhweMgH5yhSJpjbGvl F+PXVq7qC39ZoMRK5B2WE++FwOQhEeE8C9deCoa7kEJjldGys7bsYnDDrZo9c8pV6mOorpxvE7b0 4qR2TIhlOtmVRoWSMNGZitm8pDzOrrJdWlpoapDf09BHxw7jZTEJoWjVVUE1m2MEkRdc8eCXntCm wUNK0eMA6Tl90Mrunc5V5s2ps45iGY349BCtxpoqsLwLXtrCPRPVzNY90lkAOjUlp5n/q5Id4Wa0 MNW8aSjuoDAxjkRYmQAu0HcEEJwEc7Bj0sYK0juD/jV9MV1M75+j6JgNvQ5Iu26CGGOzqFxSs4mr l1o+u2wr0VfOfcz2oEQeRpH+doQUqZ2VFGJF13DKF6Ij0llAgsZsLhc5RqB/U3aSMfdZskjBeMhd KWwtY4pa0suVSrVE1VurSjR6QrQPbmEysZMTAowzs8qMwhSSkWUkmf8LbpzJRw82JWE5eLe3zyR6 7ChqowB9Uc+uH54dne9dbBe9reen61+LefCGIWs3ZrQArigUF6bkwHfBNpMzVEtQokjtK5Lu0Fe8 lGrLqTBEYyYNVnKGrY4hWEzYDtJQ2WRXhGjyVkdBJYb7ssX4VgcbCBwxjUrBBrV/4bqWTo5MxBgT yGMi+9C4qyxIMTIvmYHrzMCnDdNLv9Zc5SMhMphGG9P+qZ84ivYdxU/IZgAiUf6CMiCqIBX1BcZy lmtF+KKpVRBAWzkR8RSujQzWMTOXAdkQ7ueZQSsmNmCAPSP2dA0CkKFJqCO2KwB2A54S7J/BcRM7 14f5aLhS2VZPivOIHDKgeyxVsVeaIhVKg8h/WGauhe6KAB0HbGQ7deG2EIoyqKZdRNh4DP8bMqNi sbBXTO6KEB0LkYcXUGOH1QRlI8wqE22YsgSkp71exRXig6daQ/BdDVp3zIau7AvIyLdppbR5VIxo CZC6iJnpR5TPsfKFMWp9ROOGSMW/Buic7aXGO0MTi/BTOuvPEwvYMXMCJAc6szotynZBmIqDyTtw 5jzhtkqLs8thXBoU3XexKY5tCoMcaFZctc+R7l6jw1fhS4G3N369GF5Quw1Ffo7lV0TLKqbWvlwj I9iJq/4QZk6XkmWQBPXdMVeL1rsI0bEQubq5qndamFGSoeew+jER9ZtShqxtXwLpHDUkLM6eJV/m 0UuI8SdIGGCyVRlmaE3ElEppQYoqOlZFFG6LLe2c5pJuctUwSyLgJWhxQf+EJM2H9psPoFCms1eU o+lHePEo8LnmQp9pVA/lgxVCCYThVNPu30ntWIo0RmnsBlUxCKtS9CS7T4vBmWK5EsUpABaT+9yI CB17hBt0pTEmtqyueKFauFhoJvQQaxfvkxS9InQgogDxWlGLwbdFhI5FaNlRmr9PoXCZDq8rekk6 SRCfZR9CTKk9k+IovuZ9Ar43WaQFYPU3bPKhVoRpICkPSdK2VG4dkd8bRRtdzyXFnH8OeaXZLfjJ pPI09Td7Hk/c3WpD27Zy403sFloIFjFwDbS0A+wWfKeIht1xYC+9zq1MOjpP+qmGppiuUWszQXhN nk+1mjjBSlBEgymPl2GKwtKOXqRYvXjIjqUgV5x7lDo1gFNguaKZkgOKrWC0qqQhqITMAaUVmKxr BNu1T0ALjU+rAinWRTdvuxzd/IO2BPgrtJ5NQcLaZ1kNfmiy+mT4enhgLxfoQAzBD+I0hhicmSAa 8A/FN1/CXal8h6Yc+uegOma7szyZIxn9Wn+2MOBadNpuS4AhMBA/G4fh+51TDHaGiDz/HtzT/tfb E5AfrFwdZ/YlrGInM6VK3zkWTh6hZMK9kPMveUD0CWqDrmyYxHp5qorMzcik0Ho81alrKCx4TJJv 9+VUPzwLb2iJigKo6lYepoy42IckzFzhkyv+zXFhFgIpYtvgS0jbDG6KdRT6I0tiwPtTSyXMZtKG DcW7PZ13W2dnMHlC0yfFFDCtPb1J4E95l5M+nwAGqPIzfRUBGFNDa6sjdsa1nYnH0WKiB/YYasMT XlSwow23Rd2jpnIHXCsaCiJBxxJcFZrOddRONaISIkkuv8a6Sa2gbJzwSlERoWMRFqN6ZQzxaqNV stbn6dd7UfvvxUO6KZI9EVH6gRCli30ZHn04pzoYUzifBVMfBD+rNRtZeGRKf0KU/tiCKTkCenu9 cAi9eEg3Xm9dXcKeS1iSnKBDXD/pzTSdXDRlKmTJiBxnRChSl+brwWc2J9A+qtdTQI4XQF5oiGrB mGuuL78qMnQsQzUHq1SR6aEUUc2EKRP0Mndmv7hQMh38A5VBoMQV8QIpo4jQsQhLFdzZAhscuYhE xF733p0fLVA2NByrsKw1YhQBOhYgu7SSFBngxkscqQDo6zY1rK0/UWVCw/xFH1fxVBLMtD/rVh+u 7NKkDUTGtXo/AlCpjv8EaioK6FgBdVxCHXjQ0VjiKIXNlGG/Pdy/ODzaLmN0w+ZzooU1wIDKLZYx hzz0gdoAU2cf7lVmKlp7hlEpMqzcLS1wN/c3pDKGv8AijPT9zo+n6eI3ugBYZfB+h1aTDfbeDvYO r4ag9j5epfZu72lsLKGNWQV4s3ieDd+3exinOhlwFirJh0x4LgoPsroXbLsTUyPpmDzPimbJdHZh E0/FCjXbzP2KzWzx5kc/rWGPzKhEwrPYiPl++tsl5WAEFGuytBIJth8JFlCMymmrn3l0PqA5HgNJ D5Zoe0YGtd80SabnaQp3QACF9zso4UTR6pRCi6pRX0lEhanypst6XfbMVa2m2OFouHd+9tqK5jrg mflOlWd2Y0JHV7eIhMm6EMsDZ6Og+OEElcYFK4mo9f7F5rRvc7A3Irkn5GmV6t2SjLVS5/Bg87j7 9Wrcbam9Dhn1Sp3zN68vDo4tlXrybXtmWw5bLfMDPayKZXHFVSxbb6QqTrqhJmBJS/TIgR4xJy2T QbM2lTg0iql1yVUkV2kBtf2RgL0IyzI/fdjlSn6pPFw4ZV3otwyHXZqwi0GH7hKbesNILQqMCIJy 6C6INg3kqk9BgVyN1+lAIMd36jSQo0YBQuSPwqTmegY+BBD/NrnHQU93UWRWWQpH08SKV+0AlRL9 ZW/B0nMJENoPEHTvlDfoUd+NajBUf/HT9AFpUqTESBtcCATButc/mcnB3NrBxAjzMaz5ZwwgROE0 xBk7/+Ljz1jxlI5vwxzIDKBuPJlnlnlmZMJIh588825oTWK/1UV4Q2fvtYfd2QChgOROj6tly9Pq l08pYVLOQh9U70HaPyvpprBXH4VDekXZuoxRQNJ7FzxQeZiMThDg/9iXARqfg1dDhhTNEkh8Embj RZbhukjRMYyBpgjBi+WHUUaxJkQznQYpLUkwisYLy4AHw07BMEbowviiklaKCB2LcJomM5YKZwTz BFKiKd+7MLiX0tPzLD31ImCWh4THz0B5Udc6+a52AookRZLf0cShHFc5rnJcj9/wyDAVBXisE79Z /ZFPkR/GV+gx6Q7RdkpYpIv0bxadFJ0UnRSdjN7viOHB+MPTcJyKddUaVTvDYC5+T2wZ4ifFT4qf FD8pfpL204mfrNKgryE871UwAC9h3LtVXt3y3OJfk/Q2iYN41wuwnTxCk1T/Old7Z7y/+PECAE7v cNfDLOuR+Vj//vMnH6s1h4dC6CZ9HSF0q2x4WGPa7t9FfpZfBlhdhoF4UqIPWHH6K7Y9YFhtJFRv QvVmNoWUFoCIPwRj5Hb9YSO4yLsM/Gjm/e+K/6v58TPgYLSCOAEuJVV/zZ5M7UVG7CacaRTff0T5 fw02+vUfN/l/ec1fp4/7BzDqxZHtxUN2TC9hP/88GPxf1sw/rxjTd96LZE5oTT966b3rn9p1T1i/ GxDm7zXCKl0SYbme1YIwfv8cpBjV8k5+HwyUcr0aDFSG/47UTundn713LDj6TFTMMXQWkiDB8C+I jLTsny9IPP8iub3zSvpHUit9tpSnCNG9EElk5hckwyKkn18OBu8GkOrJDSHaf8cP1mdL8YoQ3QvR 1sQX3r88D1r4kv6n7CdbULKf1me/e6dRyOIVIboX4lKl2An+Cwr3z3/+89XgT2ROS7/wQ/kzJXsE pn8WIXZAiDqS+SBhJ7JU3gZM2apGODroGzUWWqBRy0ikpF7qj7bG9U+zpMSwHVAumibrTuTKOcQF 0OoN8mSADoxX8FV+jHllgIyBEh1NCbKi14+3OYq9FNkQAVdzPdYkSyu/97NQ272K0VKQ1p9MHck7 mYMHAtt8aSb7f8QjXJZUr9avm4vfEwa026eyxvxXabzqqWRdM9+eWOqCePB7IbwlS1D31k/+ZD2R REsuo6X9tX5X2qQ1wIxO27ksB7WGn068ax8M7LAVeTJOImhi/Qf908RemBt5SCjps+Aw6JyxMexZ 78rkbhZd1vg2CUEIy7xLJbYmSbqrnBquQG5Wilb9AZTkIdrJD+IZJEl7mmnPdWW7j3FBx7eryKQ0 z16Z581YDt7xgPUOiu0NnJIvhi/7d0w75hFQWjUV1usgvw+C2MsYkKK4Z8fcJM0IKvsCuUbNV0SC jouwRZEO8wmAK2C/WjhRy5swrAA0NHH1AeUcF8IjKj77L4kMHctQy8gz6nZP8lqVU7XiBWePSqPa v3i08Z6V4d6j9qy8Pdk/OzvYLqTfrFbxQftJ62Uy5L/jX8kw8e98sumQmu/RnxW9C65QHFZfVSvV /sqrII//0Kui2m8b7yQfga4ht6cSmh4UfbLKxoXW7rKhpQcRpgEtaSd58rrvPLlHYSPjY63OOZsm /qKW+8r3lCt6ka3ECQ63SDY8sMcJkyLTXKTzJMNS+v7Z1V5ULtyEcOBkfw1k22nCDh6012jGqSy9 1J3LPBpLvKFPoXfsQX76eOp9TqIFN++Isb1/p9KNwBoNBXL2OElnkNFdsGLZ5uzOTAPxOTYaxUa0 3zGydH7d5qbXKo74ajzlhAfh6ofwW+OhFukaGvR+jQgQvhVxvBZA8X7JApwdDQ/OTq0Q3CJVPE1m M+R+lwGTsI8DHQtaSxmuboMZ1qvOQpieH2hym4LgW/rD6ielrtnyrJh/uX2nKhB3Y2BHmV4TkCzy KIxRs0ZpibJf4xzBO496U+7/imyKWej98ThZIEmm/MqSh9ik9m0SJLIaqWQmUmF5LcsUSwCShNVo RDzHuMCREaGweojAuhRFYzbEx6KRqYG8yZ4jFB6+JS49C8Aotre3/2bv5PUbcjjc1V2PitNf5v+c MkqbMAijDlQ4Jv4v+Yv8Nknf7/x4mi5+o//0BIuC3u+AHulwsPd2sHd4NTx4NzziUhgzujw1cJZc ijaq5sHdByGeB2+PSoVZ5Izt2z6qjtZpxxaQWrtrOUx7yfNbesGPeeMk3bT2teiL9snhr2/LQ+Ho ECF1Q9iG0iw9uP7SiP5cqjxuKW7Y/3B08kEFfB1g0bZkfbT3fGXtoWb570WQqaprg8ibDu5Wz2g+ goe6uoW6LrdgefhpFvgIZxHnTpLxgnIAb4paapJSmRXbPueR30MkgBsJNdgPT2Uek2Ac0uoyiMxH e+76gYtzzSb1aLi5mu0/qp/z4c3rveNDK5m0EsX3VfJHThJXrq7lTTOqU/gRJGVxHuZ8GM2HFVOK Rhbejm5nHe3/ocenoKON58xH6LGqnhX1LixxwjV0r0uRBtmccuRrrPKkvYjFDvrSZj7Vt5E0S9Ks pyLCXQchMqse32DVIyLPny8vTo9fHxz8gv2CU67p5PcJoZ/zAJYTu2epzMO+jbZ9woreJ1Wt+6ZM 5bvajNUxB5c/zCEUCM8vVWl2gSPiZZ2DCL9zq9dcIGz7xPqydEqfZ0lnS+lRaeq1A+lRLx7SjckZ PQ3z9ZEwXz9P++LkVAoptCxJQAr1mIyYXERHa8HzNJzR6gCzwnuM4oQGggM+hCHE2uiOak/4WEJv x8DhKJwGeUhc1lPvs463P04kd5fcvY3c/QIVpOakTk0ELU8l2YwFZX4oV+fhBrbj8HTvbPiBCoHf Ogyq/w2P7CWW65AHm9chD3vXS5wtojyco5Ro2iYaZeNlQJ/isj4bdnZv13kPH/t+rc4h1XnXnZLt 9mQaK/7UYz3FypAwHwCum6eY4C+VRnRla4KXxeWuQ9A4/ULK4cde8MVHWYvMedW1ci25NtVc9wKM 7pRa7vbXP5Ve4R9Qk0dMn7SiJmUVfsS4h7o364h1oWfvLxvyjebWVjIclOYDI9srtUcpaYX9Tlgr pMrU+jpAJ/l8E/LDwyyFcWG6iG3Vt5H/eOX4m362ox2/asSlNUG4nydvNzdLUAciRR86T/04o45t gmV64avgFbfhtVElH0xdpXAc5pHgJlyzS+ZBCrQ6Gn/oFU3xA5Bqa8Sphgm9OLgvKaHon+P6BDQK U+kEyIcUCXAAuMTtMprRecNK7PL87WRtJG8HIZdW6FkTydtf72DM0jF3TuUKctJzPZ9LRbPcxtRV u9Ylh+/56QY1C1smIkI9Y/SYYvk6tMh0kUKCKarVd4CUUQpNxSQgRGqr1D1ccCR2ZVsw8eYgEzQT eaBQLiV7IYdPes5g8AhXG4XfAKhtPnwYJr/UoHXvPoQ7iylOrjuRAHveBZg8R7U2UuwBt+EcxXgJ kh0HyRAhh8W8jJZx/oF38N+fPhWF4s/DA6uAXK0Ve1JocJ2sQob1SvczhPfL7hrmpqPXm7dADh6F 9C91v7a2HEKD+etbIYMBM1CTgWkE/acmsbGyne02bkaY/07RZIkBIC7V1scYoycmrgrJgIRU7YdU UCeF/wYTtkaj0Jwib2wjEcHFqbWZ9ANcmgKIwy7OfKQE+H/AU3v5iM6emtd7/jWFjqXbkKGRHWVo xM0QjEFDhCCkVIYVrIpgVdrAqnzKgsUkGZhSf6kfn0mmJplaO5laiWNCTzFNErivnFKyB8QjXJ4s 9RBP/vGJquaSobnP0MZJavLmyqgThrCzDBSlxHiJxFoD3FBnznwAM7XBERG6F+H1IicAosd5thHM wAgtjKFpRMoHNUQRhRoFRdvY4NtEiu6lSF1E7troNk5dwcSSUxNpLsq2aV6hzW0zCT39stFtrnL7 tniT9Xm9VYz6eaOnkJdNVZ61pAn5SKNArRcq1Qcn1YclEBe1hnlj7iDIheeaOlAxkDg1/fgmYOMF 9WWm/aM37nxGgzlWrF5PjTiXglnLYMVSKVpnDVh/UKFKsA3Okp2VjmmJRnblkFZg/qYf4J5GVt1p j6q04tDbd+hXSOYKqiOgvoq9dprryJstMtCogSiY8z4CE1WSfInJHGd+jPSy+J13aU+MpsNjKBiA v4zs9ojSdd+2lL3Qul48pJsuF2/f2K/QBF+RnVjuyObRAYWs8YQy+Bspg4WI66t1gjVZADrghhTf WMYVVnwqoM3CPLzBUcWSGOMLxcM59nAqFoEnAzmoJQybf3drXMvnb4cnb47bIQYtpTqPIwY9/mP0 w5QGtfGcRAxa3n5myRNumodzHXmyGibhKdiDkXKaDiTHv2AEtRj98NfK8dVBEXrVGpgi2va8Oz8N kwV1x5hbWUP1ixWHqMLfBDnMVoq9xTSC92uc3KP/wrs7CM0aA0hijBS0g6E+Etw917qbCzzgGodK DEhLym1wNGQZeLaRJYJdm1qEGaBMWGPywMNtJa+Kz6o6L/W0lutphUM11oOsC+wKmDkWoLki8dEn foTVEUn6a5T4sC7EoU4zRSI/uMoSBYKpGLY4vG3EBqOvggT2XLxAfBzMc+OfHspRLKCFgZ8zE75M NjiXoMFNoLRGTh6CpOQDHr0k2gJkoWTMQ/gx4bNZEftnRHtRxJGHRPCPVXUyIPxtA8JPRAx8LMTA zzOP6IV9cVQ/+Ii9jWkc5IOzFLwsSM5XfvEW9JWr+sJfFoA60xo2ce3Pco2jqF77/e0Ki4nOk2YB ViBOCs5VnfYmU9oSPPE43UVCjPGD/mmiG9PZWGfK5lgPNg0hFR5MJaA6FhVHxG8yjhbYF5ZixTGl ucuEKkEapYDsJoESKTquV+gEtly/9mnRFspJXA7nktNs10MKHBoB0wI/SPX/EXIhvhEROhbhOEhp erjQM1jSC6pYLEdBMOgT57tLkRVfBftGFIkAHQtwkS1Qz33gxZiGeo4MJ+Y90wS7DlCsX8oySFMI V+/ECzIjbBGiYyEaj6Yn/hu1DRwB8wAEAAvsNORyfmmqt4cdwo4FNWQ49RgFuFYth3cD+jZSSpq0 m5gt66rrokv9ooOOdVBHmiQmapQVKkl9+pC7Z7oDikoAdc+obn+9yECoAoUkUabCoOu6gebfUCxD M8lpD82hFCLaL0RgUkqoEOm1y+Fr//ChwPwBi8xobzDgrSokBM0X17gQ5ZdIDw0vEUUfIJJFylCk cRJ4OA48IEVC/dXT6SFFOwEIi3I27B7a9RhFSD8qaCFETQAekaF7GXJiHfkPqGkiGlwP+Rh4AZhL meHfxJkiQvci/KwguXb964TqX96AkwLo2oQSBCNr+rMugo79WEToXoTj2yQBgpU0ENTUDyw1g72y oHLQ0IfCjJbRWiJF91I0SFVq2cGeKhWTjO55Qlc6VsX71Mh9IryJwtzZBnMnEgIqJc+bDyJvmlWZ HpWUaQ4XZjJJJ0HK4cnKMk0ZxWh5FAMyNNCFago3AfQhQ7aOtO4aKAekdCFWRJlvI3S599MJPpR4 0nU5GUI0sWMRhVBoqeALGrFSkGgYNvVxAvwKb1qSiagOSLAoldDmJItPA4p5Rduw1MI200RXPLWS BXQgC1jursxUU8fwlGZU/orRlCM1K38ru2UU2XXgoeMaiAXtgP7NEgQqU/8uSRU2bDmuBozYkko4 8FMEMQCKKWCDkXAPk76O5UNwgmwlqd0djH3iE2aRcg/8FoxEfgSRTh7waRB7kyQOiM+h3EIXW+re lhrQwhSJBUDSVCIr200e707G40Vab2hFDTtgSS8Napa0a6bDT9UYIrMJ6DQUkTYGs/Yx3F3DxLT0 RRHdKyIMJtlGS/safB9Ii25uc9jXDDsTAtVXupacogOaCKIFDN0Hkx6aRcF5tI/zMAtSVshxpSIt FemWKtI/gTiGQ4qC6IpCyUbaZiymKxhmiclUQg/3oYdV/OIohHM4liponpIxDYtMeKkuBJvz/N1i TvhmkZ576ZlFjxTf0zbIjHoIqreQLca33BIyYBSDUzFNBZGfe/kt+zrlpoKBfxnJkVEtpKvY8EV4 7oVXmrPSWVlOc1jLXlAc3BudXLbyMH5H5RZxfp1I2fTIMeokSL6LvZjGRMKSfgQKdzJhJPVuIUyF +BMddK+DRlJaAU2PB+YySu7ROcC867V/HUZhjs2SU5SjyVOqVi2iGj8TGXZBhkYLdQADv8eI2kK4 igZiWdU03yMW3IXIsAOWVCkWIVegZdlDPF5uvS7PTarl5YRjIZJR4jru4+br7jXzToCLNhPIkyAL b2JIBtkgplvvuXlO+CQgWJaxzSycGHcpNrQLNpRnfzLm3ygaAya5pwkhNBioywcWHdUx4gWvd34U TpDgiw3tgA0l4RjPRgZSDSPQiBcFLeaTcQSynAFKMAhtxuBwhleUjsPzBMH3oq0iD4lwQEhw72kz 8O1JnIXvd06TRUqwr78HfPUr+4L/mqS3ABjFux4WaPgRcnb96/zLPIR19P7ixws/ffAOd4lx88h8 rH//+RPIrLzhayHBFSM6PPpwTueQ9fEsmPrwvbQsR28A0J98Kl0aYYRgrpq/c2uN6KcIrCNXwRez W307DWIynvrfbG67xb3oIyHBfazBMgITrydez/i3b/J6tN3zAL7uUpM+XC2Rm95phM4tmFTHvIZR tjD2Qtk6VlT6GCtaQuJJ0Gf0Xf8KRXLythP33L/LG2mkEdefMKUi02LS+dN9BMWBRBSMKfMgKfAs VVkUhbRpN/TvmHbMdkCCqH/xZusliiUKp0EeYuucmqI09bBBCH5wtXwRHdwwNkIVIZqshVIUB3vL IMQSsVgJ2i7VyueZaHfMiHxWYLjBR6LBU0ueJQ6ZmypBqYRhLlmFA3NRiiD379bXH9fGIUsvtTyF pWiEOj5M0wjqxRnOK1Uiqekqzsu98woALrmOwuwWFeTS5gPdhkPmfQXhnZxeFoJjyk2EH2Es4nMv vp8vL06PXx8c/ELRIWbKNQc7RY9LKK3SPW6vaq2U4ESCEz8bh6tdqG+p0jX6htNlCipxiiaKpkqB 1Euc1EvgysDH4eP/Yx8OThEKzwh4MsfmJu3yBtpawsWZSoma55Lx42WL0F2yXapqEXho5seIJieG diPzUTkp5koU9JLQ7bkuiiHUkU0VRaPXnRQpIyAdRBTJYL2D//70yft0egrlHN+GORakAfDl/Ywr vzDvN34weipRp/uoEyNBsKJxDpJhFL+KAnSheOWRIW1WEZ2S7YVgaWWXCNG9EKuWlGaWrwO9vXC9 Re2f+CRiaz9iA+wGw2o6cZDu6jupaiZxjqi9JdYHdFctOwcMWpok0/M0xS3kD/Pg/Q5W+UYR1iCl Bv5m6slWkXm7YdaIZzpN9rLRHZ/Hk53/5LtycL8NxYJSuXi54oUnc8C6p3ijOLjX5mBgPahY5/at MxqfHzEFTkSWFM0T9yEkRXVhVB7naXAXJovMpNDIwZ69OskhdHIIjeFYMhkTXxwsRkLR7CSIQIab 4lziZzqnqiZA5zY3oa6YEvfJiBIN87p4ROVYblZ4irizqNDpptTnq6IpJRJ0L8FlX9Bb15QiyBqF 9bosYByEDPcJm1sbcf0ntVikklQKl6CcvjZOH2JmfQCr5o+ro+VaatF7oi7HBCS4SU7xtXg6956O YxVqNJlcFHnQNShBuLG47HiDCV4BrrWsBxqNLSJ0L8IwRkw5U3NDYI/IFaJaN6O06qkwE02L4EuY oe5kuhsiP/fyKzWYNH+LCj8VBGqO/iEyvtJOMItzvIfgp46BluEHea+G3nRCvB8ArJXdXwlIT0Uk YgfJdGmJIzhRQvdKqP2aTsdPPl7uej+eXNJMi/cZvxcRTLnHb7JES35drayfftnoNnU5Xep/Tup/ P28kI9dNmscdJTfmevQLL44289QUzmo4cUbmeW7v5DTq3UNvKpq+NU0f0cD/IVzKpRn4R6PVKwj4 P9K6VzXvn8nAv5zDrZ3Dhi61GofRps8bEwEFmtOgjIxzEFGo7udnZB+gp/eYugI9pjugHMvHNokt jyVCbF+IX1lDvNykmd+mSZ5HEOw0TLNchboiPse5xzSJQHtNWSMG13KKTYxG5sWGzTS4wSpp+o6W If0RM1LA8NxBX2Wth2sUOJbB3SwgiQhkBhm3eEtFHfTtDTsvOF3VmvdgRlaWBSplcNfSM8XQYp8H rZfO04QGfMfABIXZjGQ4TsNr5RVz2jY9ScYLkmJf7WgvfL08JNL3Z8F02gtJOqq1PA2d6xuhc32e g9yielvLCoXO9dEz/nQaSR69OJW9eEg3Xq+xqoY+w5imD1Eto7VxTcm7j3nvPAdlOlL+KBmDTmie oB78sCslGcclmUUcgdjJw0DUmBl5MeOL/G/KRIUGvl3K76Vp9DzDlo6ZlY+l4XTTrxR6Xjl6LVAf 0XhczekD60VMc0k3mEoCW9e/wYYAbBrmXagspglp/F9R5RSP5tijQYClzkHRMRLPJeajBfNhoOWr 1H0yqyKzKi3Nqqw5hEjR5oDlktOaJQCK3SfprzRUazHSiw9z78OQTTcMXHrej5BcgunoYuO34b6j LquJl0WI7oVIUEwwjgD5Rnm1gj+grdo0YVTIDn3WE9l56rpXjkhS7XcA5IFmx2aYNvKSa94GDnAY all0lRQxSvxJ0UhHv5z3EE8WY8E7dECGJKQ8yZGwxYvZtSpCGiMJWgl4Qk0xYSQJDcXVMJfyZBeI Q+uSOW8W3tzm3tS/g5uEbVWgsnp/KX7QvR8kzYKqMU1IXawCf4eiSwiAH9VVVr8oMnQvw8JkbloJ K5VhRH7u5SeVMDTDDW+e7Jdpc4fAqkEvMh3p6khZtoWyLFK5k2I0jTnkrNn0OLj3rjHGjvqJoS2n rEFfovEDokgUL+beixEmIU0WPE+ABDxbXCsugrwmaiyMjEnwiIhUhOheiIrLcRfymatadFYqRnMt hSvS9tpTrompgozI0L0MYR+xBqJIClRCjgb5cvKO+wtT/gZvHFjKVOTnXn5aclSeDoTEUVqTbbQm P9UzUUgOIDlAOznAlRoLpzZpUQ7hEdZ5/clk1Ffu/0r7jvJE3JZ7t4VpVYzoBamiAMSMMTqslLjp 0nERj0xDrA6DzIoWHboEIj/38tPMcdw9LYR1H2LKWK0jUIpokjnE/JeKT0azBaKhLlJ0L8XAT6MQ LR0ttEKoTVmAf3ODRC8DdhYwCMoDRIjuhVioH9fDkvF4kXqRT1M6FbEKdFbisxbis4+1+wX6Zylk jnFrI8SNc4zoD1wVS4bz+6SgCEON2YKVFJuRMsQm1tm8fzdOZjQNcunHNwHzVqLbGE7e7wyPh+7W do3wXIoESz2Tdc9y1JwcNU5iiJocp8v2wvC+szCGE8YuLt01xTkjEWYB/ha4sWMJgDuAKSTSJKBB FS40C8pcZstMRe1VA9gXtfKChR5aGMJIiBq6D4CJ8NqsFUsY3UsyVRWD+CahKpHWQS/LoZN2HGzb e3BJN1p7ApucHBy/fnu2U14p+Tl/wPb6+3d3fvR+51T7jmCKikY8DrTDuChvzoQZmGF5JQxEkv5w gjrIDv42c0KsfoI1kTDuqTJvxjGZf7l9p/S9ji2VNBs6REvca4lxSeXZEq+OaZOJBKxMP5Q8vwO+ itdpEATiJvXHwXRBoyhGqMVuvmxX4ajhngI/HizmerxBNNC9Bur9QwgVs2SRjsG6+SJ4dfPKdk4v eX/DDUKRNESYqGZTaKMm9TdEiu6lqNAsVjJZBP8EhcG4EJlYihVN1DHzY/+G6VNFgO4FCDJwIjsC QzjJaGVYSOdpIM/xsfRG7aglgUIVWfQiwg6IsLbEqKeJCLyEfiGRepCEZ4rlA86SmYxnPWX36EWJ SB4SOeCzoL51Q2Q1ehpW2LfCCiudtqfrtAlhqhCmpgTT+HtwT/VEUxAkb9cbVlg3DmFdo7FuoF0l D8CyKQSNH2UJsc2VmDe9KAB6RpII90mEBUHMKDtAtoDx9gSbpXU3T6HqebE0cxSgCsMj8JwICtpe 0PZPiLYf0da9z0mEmTiUJj6lyRilJJQKac0er8q+C172z2z0IqPrmG/Tq6HVFj3MaKoNUVQsQ8OS lraDNKmgCscGvmQcoquKvingv1xTO/vp42n/jmrHpJhpU2J3u3uhT714SDfHDV5qCD916s/96zAC t5Z3EsfJAkgHJlAWX/W/hJ0ktdAuhIlZFOmrQbqsXB1n9qVSnnv/Lm/MwyxfpRYeZB75n+YjenZ6 8rLwX2IdpVL3dJW6NccUyMHTE9p+asJ64hQlNhJqVtHkG7Zqo2O8mM+TFIx4oMfgU8zYNnVRIirH NYNCKFO0Fik1061iFpS5BlmOo8UkqILKCWRqYOT7BPjzF/ltkr7f+fE0XfxGFyY4AO939veGh4O9 t4O9w6vh8bvDN+/29v6PghviK9zbIRjim/ODt2dvLRhiW0aX8oDqUcTDuUIejkwD3/Ov8QIpCqne 3ZzuTSjDyhBU29fiZD26wr7OKfvRTZIiGZxhIZGyXcEEuvIRXOXM98llUaMnxNkEAhmyesxh4QnM yTldq8I4BV/yAOhkTGoXi4PhrjSyerogEyjh05rwSRtpY7fPFKJolbLwU+kSmyqF9p5bwPJPETDt VxCJRpQ/7cALDAA0M2Lt1Ej2h4D4eOv6TW4yz8bYyjL3cLElR3uwsaM9Gq51tEaGn+Cwt+l9N5JD o+k94ZhxoG0ugdasd4OySL2j3l40senzjIp95nEysSejEBgFEd6/msA73Fyi+6sStcSnZXoWYGyj AzLFU5J6j3hfgPmB5IehDvwTV2pCLPeSa1BL6+DZSnm0uQifg1ICa0qa+P/Z+7bltpEs219B6KXl CMnNqy6OMCMkUZpyT9lySKqa6Og4DxAJSZgiAQ5AWqV+6t+YiHN+rr/krJ0XIBMEKFAWkCCZPd1T tqSyCezMfVl77bWxe8BDSoQGI092GKWUfiO+T+f+YHPua3HFijk5ntrRE1KxcH1xqJ2GMuhsk2Ml XUlJuxBReDPCA4ajb2U6fnglaljn7PfvlNNNoesBkjoy9mwFpYR7xVFuyCMDR9EOnx5Njsq7opxo 8trbaGaAyXfY0HIZT5Ddi1DDIhH9Wgs+amp1XOmrY6HOQIqL1GpAYzovGZXgjb4D2gWATbNJ4Gvn 2KQxxNR1TlYYNc0DDUoUw8Ulof6dBpSE2TCH31cBpHWGnVbnjCGZjMyIv2VV3fvfI5idTVrfA6So pBbOPrg+IK4LgpyIT6CfxaOTdv/80gg6ixiflFII5wHEKZgslGwsMKz662+3d1iNFAPA4d+FqF6a AGAHvF6B7bDlM07GrGFFMi1yOKTXWhJHAOsD5EZEIscH1xDRpW5FTZycTbjPjbIqu6UAWJF6ByGJ XfL2kW5sb6zZmuoqPr5I9zkb33fVTTfLrJpVMvnjxfCo3zcTICgm4JBBL4WFBo/qP7iOok/LEbNa /N4A7otOvXRg7gTgyPgFjozL81ChKs+99nFtfBrf1Gin/AISiQf3ZALlgvzED7g0yPeCHIbq8jFt HYkCKzE0avRpOPYffK+WXak2QuXMEhX2FGBX2BAclch7mHiYm0eG4f+pJ4gmvNuANJ8wxf/AeTKS fqHXYHrqrmo7ZRN3qoFzvLJWipjRdmKflGoS1gaoIrYr3r1MCSbEqN6b5UdeXMKqrAsqayoyjfiI 8kuat5Nf3GjMWLFBRe+XoC0i7xJ990Z2Hb6h6+Cceyj5fHhhy961RKFP732vV0WWM73/5TBgolwF hJaFXQWguMYKQFoKOhyDL+Zfy0FJ2T7S429FmbniLG3AqoYQJG0vo7KS4mnB19CxK+M4RIfz8Hdk rQhuVD6yCTW7tSBNqAyZT7AHaNBVKNxNwjiGQxe8UetFVtAKM7mwTXtR5b1teCjrRW5/uf7t1yHQ sZxpDGqRcFqsRvevA4hqVrhrWCQAOCF6W1aPweoxvKMeQyHMeRYQpa2YSeUG8TNofjIjTtwJQ7HR ccUWate6DQnpGMpAUhImUUvYvB31HuYRrEeMzDAATHKHr2gETefr2d8d2iNo7WfYftxGzr1LE5RC ylViwMmNS4ZVcF+XqwGbZNoks4bRXzRQvoUY7WU0HPIxvNSRw4pp0UOBgb4fBtCqFWf5jX7mots5 abPhFzYx2uQSIWdCBDsGvWADBo9g2bEXjyL/XvY2YcFxOFowKQya3NbMt5Q4CytVEAHLvFTqByB5 TognhOT5SE+EZ0XH7/6tYU4/fmLApnPUOrq63CvXrRE/TK9mDYQPMzL44/mg0Cn9Ta/NWPfvWqef Wl02KATBCVjonaaoyxigEFozfi4KU1+ceMp+Akkq05Mj78+RN5tzme3MyVeY48etdS3DDCPPDUHe yul452ZZGbvRxYGfFpk82hBIF6GIlcyh89RSewEwtSBdK0f0uP1TL4LDsKuumjHHgodkAwQUzfRq CNEOiphg9NDrkT9Gv1bmDOhesIuvmjwDemkYtPy51WHusnN01LkoTTR+54NFjyi727ynop6EUoIQ qrPSrkTzT8Iqh+ICA/7hRZPQzZ0+0SkcGvv6uJvLvm70lUidQ8Hp159XoawsPS2jrHS6veGJxjQ3 T1nhn5Rf6gYmPXrdt/QBFbS1Ih+woiPO5KwSbUVKJ9UE8xadLOqZ9D52aEtQNsRU4TWVt7FGIvZe adSy14yks9ciQAWRTv7VK4yFbAgL7rhJ+vqpwr+9/dawDwnnYbdtPFMa+xb9oPfZttFp2W0b2wnk 7YR/MZN/2JUiazssOo2ygqugPG1WomWvHi/S3zuRJeyISNgdRsIm0TtSSbEsbCpldud2mfH5hSDM bzPUlJE38nygt+DjufjN/yy8GHKNXBQGO4XxJXlaWcN87PHVwzTi9WALUcPd8BSOzvAVSLKWUFiF 16D3zGeQsaU99bC7taJ5KxYziyy+sJ1FTsNiwblKqMGGLCjAsphATmQl641+QIQN60gMO5IkbHOj aIH7jyB8pmVnWI6ctF3IzlE4cR4wqk0As0uLPawVDVtRM4AmoXlcVgX1+FO7v6yCyhpHnCFkAjhH V0N7NKT+WUUy4+C+oJRz+Rzt0+qGKKtlCkMcN84Q5B20ZzNrCQjvEZUC9TBVGNoH01Qbj8uqNua/ dO1siW7SkGsAV0e8wZsVzUTZ9t2P2TY/+Vt6XIUDYSYrGCScZy1k4Jwwlsv66hyrGRnNgrzMvPLC otwdjcJojNtAZFBRxcWL+5gqc6RknFaTuSRJc9Swh5e4AZN/8QN/TvsB7XiOHc+pYzxHqEhlrsYo nBIr94aEiHQS0TEnEWEzU/hwGdEVojUkn/fiGRYgsB/NZRkpzqs6mghC4v94i1jfaAOkNPezgitk 7pMW+LEVVlCpTcIGr/mvBlCb2CflsdpMwBiI4s6hog0rQTBMtmoejcVu/D/NEPj8289OMWOegnvg ZPHz9ZROrAEpo6nF5RYaMENk5jkZUBQFWrcYrcVoa5gou2NQq1aiCXeSo1sQBsTBH/OpMvzGBgLT fiRv8o+L+eaPqfI5ZLvdcIlpaQK8BOU3UanBnDHTah5z3bJ7jJFH4ZT1W4U0ZWK09F9aH0TJA6xu LLLyZtUXkTiv3vDRPz86vuxrgxXvNBqYQoFFqmpiw2KGhKEfHB2GPiEK7mvDjlgoC0QU8455C2Vr ed7Bv//1v9n40zjov7jNydHR7APYSuod52Zfvxzwv7kBVHhiqd3ER+nzftTWUuZrqQyZ7Nnle0qy aiuYQceGdD5QDLNlamh7EQ1nssBTvYjhTyqTYAy4H+o5u2cdi6pVxpkuBGWKSuFv13cO3zog0nGS rkc3P83dx4uIWs1Wics0rjbzIj8EPoHlH/5UyORAlwQsEZJ4VobDkbdz30J4BijJ8DyICPFiMj/Y PWfTMHQb1gKNmNrVlD5f/3pDcrvCgpoano0L7wWRKhWbncxGv3ZGTPboh7c3AEaTExdWibu+Juyq V9ulpIVYtd0p2Bqr2K7C5rHuFhWPQQWA+AiCAHXDQaZaPldBMNd8eJkPa7AdNPYe/ICLfmU+dn5r Po9GUGiEWp5rgFXz2ACJTD3zAFoPPveQ1PP5hg39XJH7MM9CcflGX+ZjKCavFrse6FcflUnzYDZf Z7XY6qn+6kkKZ7MGIdOndGcz8A2BuxDcwjrbJa5htWc5P1xwlcKPS/zl7Udj7UWp/6Igo0w1XGlL K20D0PYAYLUIvpRcH/Z9353SlKx2g6z1jFiPDOOPXEImYwds6rE3m4QvTKc1HnmBCwgiFuR3RUU6 6SlYExqGmnEBKSLlEiQIKkp0wCfhyJ1kGgXOLITxXyz08F7Qg1IBWOihBPTA2FkESZdabbeUu29/ TqOU+xrbxURmCVeTQpgUK9zgRWz+UdtcbGCWgZwKGJBfVNuYX3/MH7M6nVoIgAWhb4I2crKQhVF3 00UfNA1Nas4UYOwEezNWicshh0SdvpTnRAb3qzv6Q+yUs0mb4aQNbrR4S5Jy2+TNxG3lBGYi7xCz nq6ltaJhKyK7Dmj7uzKbnQykqrMP//h6ES3+2T61apzbmmYXzlCetBo3eOg4Z2APPNKoNO3s0ryI piZwUmoLA+/m9Za5s1q6mlETGLZOTo+qpRAL+YB8jHQajv2HF/bshTIDNECI7sD48177pNQWgsI3 Qc2NixoeeY6h2NnEHemRQakglA+idzeVsrW6rmu+KfQDiILAYD+GlpcUk5ydkRtFPu9t5ogMlK9l Tnrty8sLIqZvwA6qCebC8Ul/uJPPew/R4dUNOTQ8Kzsn9MyigpFPo117Q1VqxqdpjdvqLuLzp5Xv igROZaGlA26Fiy2WoodygdVXa376m39SOhbscJTEZbbvIuyyE7DPDm8o3SDdVBFV5Ze4Z7RnfpsC nz3z9syzJK7wvmecwEZPpwrfpaYe7zT6+WruNHHj+Q141MC9xt9RvZ4DdvmDLaYsmBX9zzB6wlB/ cOB4REoAACr+U5Qc1pi4Di7/nGGhaOz8zQ0WbvTi9A6cTqvdlx9R/PMf9KBOp72DuJFStNZply80 txV488MhNUky5mC/ZdSWvG/Q1/62AEUMhuxpZ6x8jNhgX2EfUlTz2nGVqd9Ge/1awCG2+6MLL33G kMlz78n94aPFvP8tjKZgJ/3wmCjonGMP6xSZ9lL1z5Pl0t+VPIXCuCWpZEkql5ikC6O/UGsHq+kP D51vHiA/8H7dMf7xxMa5mBS4juFY/2f9H47K2zf+YXMpvN+13Pd7w5bKON+jcIRNMzQ9aD0h+SsZ URU/Jr9kI+/bdk3SyWurZ+9CLD3AbBZcoD139tx9qmDbW0E70HHOMXOasipIoU8XRYmdKdRdSeE1 OwTPmIcxndrdK8DMVMyFRty/vrj9wNgwoMc8OUBuZiGM5uy7zlOI/WnEHiUjT6YfiM30AtHe6XQR 0CQCZG18nAC7xluJcRVAbshYRa+/AEEDoHFPV1HaLnZQk5FkZhBiGw6SYjEkx6xMuAhiyK3nycXf sXP0sW2tGJm3ItZqMhuN/Xi0QDKJnYbufbiY4yY+0+VbMiTNjSRrDMe20NlW2lpCjNBS52p9DYAe SjdXJJxEQr+RpEpaAKsPldtK21baP1NpF6YsZ2nSyRa5yiyTCyY+hJNJ+MxlfG4dSDNJr4lAOLTz rM0YjlCGWT/tXgmwE56xYXVOiI4Fq2gOaTdOit/pGAqFNFYHDbE72g/YtPXhL6iDdu+QNsx+KHLm 4bMbjWnWzUelCoE90mtDsQPzcKOK0TfS8xzvnsGsV6l/RpN5FYaOrO9WkDpPprt3TDfGryhmlY7F Vti2wq5hO06JRGXqvjjY1uGPMR7mP9Cwyz1ErwARzVw/wvSw9SuS1V0tSlJcpKZyPYdfoNqM7kg2 pyQSDYfW84OHtaFhG/K+6mtXzTlbMrW1nGHLqVeN5Vm4a3fwjkmt8FcluidcDq0WtDY0bEOqxV3n EYzCQEY19arlulTnr5qXtTY0bEN299AyXkzGmnJUCtL6AexMxNEwsEigza5ryK5Rs9+yFfQjzwkW 03t0CPaxiSHyRh58DZ1ToZ5licz2PNZzHu9obQjWh3g0bvTi7I+9Hz74NWO+jVGLYrryR5dmNEtt zevkbM3TusmCnTn0oB/QanXa/eFVpxbljwEkC3yQuV8cLLRhgYAeuJTcR++nHr+u5yyg7UBb6nfx 5IdD8eRNEtkoKG2XXaV2Pi0KXT8Kjd4I7ashjIEtIIInoWg2o6TKBjEbxOoJYree2FB2lmy3PJs8 hhE4otO8DCsV1rMOxHCZBgdy5bnzBUadrb+w/qIef5E6h3jmjdDEGKH0moHtOnbnrrOvOQVdeYnt IkK+yjXf+k1T7lMzpMxTqFp1R6WT1+7xsmofYyv3Wp3j82qT9ILkla2J18c9IODw8XF5nYlJmTia T0jK+YwpVCnIS2RORcep4EU3QMqLHXzk25DyalJT/UAvYvSC9bj8oT9ZPvQrCtajGu6CrEnpnNNp kr+nX3M9NXxlQL8rqau2wSPvTTpxSF/wn8z9Vl3tSflT11o+dbXhBANAAtpT4CSZdJ833njBRui1 D8U+U+Iuy2+S7Bp9tUUvFjdWPstp66eOyQrnVCOaVoDakAUL3JWZmzz47kVYWzQn5STq9P0axvr4 iHbMTstLHBs9ZgVv300q4mR7t3alDN9zW/PZmu/9aj4xOKapZGjMiphdeC6cQXM6dnSM60uzSuOk ragAiZ3GNk38vHcRLqDpHcmBslGsf0nRuoZ+c4Eb5ny7WRhhtOMRukFjbNQRCgVxwaQY24co1u4x gB0DZVnXbZN9qj/fSWASofDVaXcxz47+6D71PDwwhOYL7Kt8wUQIx6A/OHkgtIvOvtDtsTY0DDlr EcHy6rczAcFl3n7naB8SLjv2M4PFKKobvzRDxhqyoLHtGCsEkweF2shr6RJ3rC5xovFf7TTIwOoS nwWxr6fm8AQrsnV596wXtV5UFndP6x6ilSVfmvQ7WtKJ2s/O0DV6PdTyYJWi5ZJT4NkyYjvLCHhG mU5qTZZqg3khiESDZBJHyLiUEjNLFnkwjDzkOI6cCSU7l0S3y8o4Q2KZ1ou+X3uk0K0szyXtnqvY iSpgBZnxtNM0MiOINTiY2knUGF2n5UeQuv1lbo0Wz0WQH/IRpP5R5/SoWy27UVAi8u+knM5xkukc 6jbQq2gWk4KBQS8ODZFl7FTAcVw6ZdR5zHnd5jmO/JPijXN6nQWTLc765s0d+Zec+7dXuOiM2Ayt W0GHc3TuknbpdiSCNaoggw2JPraDNKZVqURPLADffqfZMHwgHxvgrCd9ZCJG4ckWZBAfxXXkILR1 KIYhAjmITjP5LZBKRh+d+ImJmGDZGJ/S9yC/BrSH1iy8OLMIA/vhImYMlMCKxdbUbiuM6PvYLTPx PrCp6CeMY9FU9NihTQou/guDQf0JxHZBArOwsYWNa8B3tIWFnyBHRisKaQfSFPQ12uSBZS0Tz4Xo FapMiguRO/ZH2HH4wvfsYMWL5R6iUK1lzWmha0ksFjP5RhmymYsh4U3nn14UUsgISZvaD2BCmJhW E8D1wII2ths2YCg3N5KFfJLIwLqkmJYnIUTQ1UuHNXAng9CZhMEjiMdCA9jLrNnRM3BlkPSU5d9K akogS++q27k61TCtBoAsslKwIEuyf9cy759/ZkllF87xq6DWU5qVXxLtni+06FD96kjQoExzfVTc yP2xupCvNxTCyxe3GSVtLEUk1ebPGDCYzZZGRy2iUvPAh+Yo0JWOwvDhMiIMkpa5fN6DgMhkwlRB zLXPBv74gOSFS31W5AkGP+mhP/6ALSrQ1eWilwx9oiWt8TMSnSn2WNNULnJZZU0T/Rr/nvZ01pvV 781UwBDMxsh/1EyiT033Sw+099rLvVnWFex2z0+rlpgZ+IH2EDhXBmUP8ks/tgWK7gSTEPdFqZBt jCuiE6fl9X16HYMvP/9xoUTBB3QP72hdFvRy3QkWMOnPm9pJfe7yEi+9rsHnHvz7X/+3QadukBM7 1LdaXsLE6FvNP01FxwY8CsRwJuN1Wl5IJO8BV/FIanBhK3kkPMmks1bIG0kt3WmVVyHJexH1OW3e yvr3v/6fdosygEefv3zB7NGraiP0Xe3D5jmwTqu81kgDHTd2txd6aRNNe9I0InHas9+/A+CeILfM WuDVamroPbiLyZxOtq6E8F35EmOr8nRspkFq3yfAIe68P+ci4eY/o164TvksiQdqiA3gmL/zwDvO orkhxGLFhHiBXYvJ2hQo49867gQl9PgFfVA/nse2e2a7ZzV0z4pQHBzFydTCON6zYPsw8YyG+hLN 8zcYxmFnqtSHtTjOu0fmHYmra+A4nVZ5jn2vV1BSd1r9bsX7POYbgeMgkEymBOTwyPE6ktNplV8z 0ssZcWAVWS2vvwi0aRjSkede1Xx8DdTS5OsugDryy+K00kwxj05rDYgw50lXYR41nDcJZrDki6Kl /AL9mlMJ8BUqlVTjroEO5jxybXepwLhUXWuJQWpXE8V1wadMS+7sZ3211s47UzdVFOA7EuY55AHZ AlTRr/m9NSBek1djsNQPx/2ma656tjXQ3JxnyTuFQzEVWJ9nK7hdK12dCS8woCa4RWYI2IM7ti6u AnBylcAOEmqVXwMv4BG/hrZo3nKWgS9nJmJn3//ofeRfHS2iiJjPRM63cUpC2wxarp9WMPWDBd+B yrbGMaMQJ/0RQWsOUgjoy0Eyn5Qsavxgwd9tBX/V0XHGrBKN2k67ZY65VBCRHSczW5FxSe4kDh3h l0D3Zn4Jm4HIRy1m2DYF4jdaVNYHGfZBcDfJEmba3KRMRCYeR05Y6I6niIS/fFipgDw/brcvrppF whefNKmctz+Lsala/VE+4xe586OppEyH1x8jMcNGPjjG+xfyl5YMnSNxbChV0+JUg7toOYS2fOK2 baLZJtrb1nms00Rrr0HrKti32brsd7oXWuLwziQg1Nkb0UT7BYMOa5ChO+01OFZGX/6GtNByfKvS ZGmv0S82+bYLyrk1OmjtNVqzOU+6Ameu466jJCVi4uD1DpoJWLnAOpn0Qz12azRuc4xBpVkdb72A 69hk4iyvhrU3b8un+sunGGMwXjDynGAxvQco+uQ/QpKDY6NURMUQ60DJlPkxHarYCbvtxEMqkw5a HDFUFhbX9oDwLUWW7ZZQtgTSERUepDnDKUtCu/kFcwMmndmZ0gJSERJhq3tb3ddQ3a9BpTOZe25E dY9QsiZFtr0Gre8kn6FcS+pP02i5c82bRZFtr0EVM/m6C0rIpMB/fS64016DSZbzqFpmJgK9YJLV ceC2rMLvrDGbnGMMW+Ezhprcb6yOxlKFr6VTtoSqv753s6W7rfCLyiZ7PKs6ntXvg+3afbCJkkC1 YI3dB7v2Kk+Jy1gHU5WDKeh/YIlGBkIch5C/nUvipEroXiEb98Yk5vzoqM+Vbxq/NRzCqMD9J/jf HAUFBKA/74El7QUbMIDPRKjHIeSoybCCPcGp+olIy75mwSWQWxiqAr9Z5r0yfgRNELj3MevEYI6X 1GWmHsQLnb1gaThv+3mUzbNQQdXvOCMMETx6e3ZqwN/WqYEG8RQonM3CKNnykSr/8gmA0hzXosZG A7owWFuW8db5DSOzPZid3MvVqJuQ1frFnAWYDJzCt6zxKxMDIQsMyFw7ZDYzrz8zv13MyJd548Mr zOMtImRwJKgn1ouQoWL+E0TKJCpKzpJra0TD802aAZoaVTYipBRkmPvPTz50Fuj88xYTXYwgHIOZ haHk0Twm1XN/Qqvb6DtyE4w3PnirNGVee8nKZaAsHr2t5c90MqzGpFUyQFVbf5TNFgxiZFhFvlIp gx2kdepjttpUeKct4K8dBFzMLqRbGn3Xi16xtxRo2TgZdpeBT0TJ9RWZbdh703KsgrTF4fsd0/2/ S9PuDjbNYhp+5kV+OGYpPjRTHPeBlDm4d9JyS1uh1R87vD9nPpVlMBTTMZjiko1hSI+2ZlBGmlw6 wO5i7yDuJPJQPZDoPhbADZIpWpDQ4R5WQXuJTTMc9oa9S20iURM/vwintF30xnvwoLUz8oR0hza1 ePeEDaSf96AAE0a/nAWxv4e/kvXtlr+jEKjTDyr/cP2T4hDuShpj71v99y2bqylaBlQ/WHS3LoqD RXdretPF2QNtckOIeUGrfg6Yg4WbwEP4QeiZhmP/4UVgIgz0xdfdabiA8lr4YNMGw5hgDvqOvd8P D/4Iyfl4AWG9MMgmCElrgTKAq1MkAUMtA9Ci++e9i3AR+UgUv2FHgIzsS199E16jnR5N5rdTft6/ X7D8rJYHG/wXwwMpYvBtJgfK+md38hhG4OVOKaMjwgS7SxDF0Q2C6M8EUHciC9iJh1SSbK3SrYD0 gveZ0MF7Hzv4P4WG9Y2g63Pvyf3ho6zY/xZGU3fu//B2MOTac1d/in1No+4u4pCi74rfjTwcwTjD GnuIwin7WRV9OnB8fR2utWL9VmQZBuwl0wr3HoKXBAo4926MXBCCmARP8A4Z5YZJ1GOqE/ieFuat Ces3YaaZ6QIUIpNJAeVlZAlB5I41QZWba61oONWfeG4EkipZLmNQzTSajn6nvJJT/2h5rlbLXpD7 E7daTD9220dH2LlaaUojph/zC1dBWIHHoceXg5L0aw4b4iv04RR9oU55sae8l0HVUh1PPR8Quwpg sL4sXUkqlU8ijHKjWapSoxTR/7VDCCuwmkb50DV+wkEao5JoFDtjvNLRfPKS/aC241iz4D/L9bgb Y7kg7UKPn4EwTLHd1X1EYAqDOZauEseGfgwEwmX+mrWi4XAE/uASjrH9V6l8+nrc6faPmKKdEjWP L3sXVwzbqmxMCXEvaaSVFdQ7+dSuZTNx4VKAzhHvLKofvqwkSPLhWdjLDYh66iKMUGmUFPlIfuqC UTlyX+JnBvRr5CxLsXLVCTL34XlhIBx3rmtm1OKcB+SPTJ9cNXN5KZJ+jvAOzypy31QduZo0oZyJ K/3UZVVJVh3u3Kc2f7j5lBaL3AwTRxhf8Vo2yqF2y+qXJGareNW7cpG6ZfWpk8+2MS4H/nIZo0DS OP4rYO1lXCrJ+QFKzWl+K3Z8NtXwPsdQC+FDvlWu3riORbyIaO5i/hRGn/e+XkSLf9IXaBMNiD6t du+wdXrY6t21E1PXeAzLIg7JZ9ukY0jxToi4Hn7jIq40RyMKFoDatOOKOFtP7py6fitOnBYFu2tA E82Ngngz7gSkgdJPvXZ+ujlnBYXritfwk1HvqH+8htoB/2F6dUKxdKZx/L5PUGuTjrgg93F8Wo0s ZbURSbKLgYg1upv3qBJ07627dHbiqoLs8ZLpxW9hlTCLPDSdF/HkRXb8xn8F/BZGYwC2zEeix/Dl obyDLFsmJGewrKsQd6kOOw8K0SwqmapzF/r5fm2+7Kfdxdq1TX3uolc+gReurIHHqNBdqAvwiPFP x+3BjzCnTTtS2RAAfSnTPcIPrjh6WprS24YaQ97CFQ/9k+F5vft20u6fcwr+28Jzr8HVQG+rq4G8 UoDn/7iJEzQzqA7g9Ii8eLg1B7Bs8ZKUfDU6/C0uMRxKrZSMymHSWyKnlKhyLujaWyOjbxfRAnLh xxqzqfwwSOSWFRdLD2fvUjys6PPUklTC14SLOZgZBDt4fMk2w8seJuEzRgODcfj84YC+x1zRipez WWGvfEVQT3NLqZh7a6fAZdNMkVrUcbDy7xew2Mx+IsK54rkLWYx97+MjpPUC6MrMaQFsGAAOQnq5 QCs/+cK7nD8xMp3b1xNffK3M+dm0q1++lKj9/PW3IU8vPH+oXybuywdqADi3v1z/9usQgixODGGW APQe8HzikUs4A6MnFIZDtRetjsmKTrQ2JJNz6zQIzcyYLPuk8Nmc72a5FwiBOg+uSk8QvfOUFMVe ATPKj10jY67wrp2BN+fFo8i/B27nB84tKHTw687Rxy5LKYicRQKqWheE0pAAPH+wuSJLtzM93ukH wIJo8Admo+A7l6WBRo7tl0cRWgUTd0cn3eG5mVFCbJnnyJZCWNcfFg9ukpEq4bicPrYYoNBRORa7 EkuRc6CUbyZdAzGA9RzIej4hOvE+o6mOc0UTSXSo4OFumBLs4d3LDMqIab+Xu0TxM8ILcq8oZ560 +2atWFUfrbiDxtT7xOQEVExhKw6L59xDfgGplz/yaNAC21xm3sjHKLW1onQ2ldadxVakdeXOvgse z5jqygfMUDvC5V9H/qMfHLKF8nQ1hX6pzii3BjRswGVGv3CXHwgfIA9Kdo2oN0WrA3NNbY1o2Iji qmHLB0xUeNckGUqZ3pC2XjupGXJ23dmwPewxrLYEa178MEuXeLxZk+7SL9+zap3WQXdJoIgmFITa LUw1vGgxgybo2O8tMfr75Xsx4sWycCNzXu3pxRf1A1JpdJJA0h2clUzvuDiwMpg59N0pNHSgqjeb TfwRL7qgopMIC9Prk38S/VqZVcxND0/Oe8j0id3Jjv7r70D+5NB7kHuD9T/jO9UOP39J1ugg1XBJ ct9diQJJPz85707/M9i7U8DAtzXs++XbTvU4GBxIPDpTCeyX76o0+I7+Zxg9hYEXHDjeHIIEoJqJ /1wKlcW/ucEC2JTTO3DAl+7Lb4t//uM7TSF2emzP3Tq3VT8tuSX5W05c57x/dn6x9xMhrXw/qo4T V+dtvewcHXV+5t0dle/z2HdHR1TxJkfl+1B1vDv9s60BePII1qRspHjLp/RXX9ByjQJvfjiEHtw8 4+HYb4fXXy7yvs6+9rcFWmk0S7JuxlKRD/z5e9ystH6zfGB5hlcd93iz3t3aVU997LijtbP4JvlA 4ekKe5cJxiuQXalklehPnKVF2uGXYTF0KF1qmYKthPt7hZnyNk9XXT9ajedrVy6bdF4KQcoVIVBH QBQeicQ/EvAmU3ZHohdinkfCPyl8ap4GgTjOzIyVdW8GeXpjztffbu+cRUysRv99VkwM3wAnvu02 qnemfEXdrmV6LjmRGphUrYULfbRKTkB/h3EHZ4s5m1Xx53mqg8l0Nw4NXcykSa5n9+UrXvHWG+ip BsAaV/iejUqDjsuX0fVcA5X/pyHXx2wVkXaajsvXis09TYV3cMUR09/CGhVUv2hqQM+PhEcWCHWl PgguuXjWFn1ll3jMbG6f2pGl30n5ymjTTobe5JDJM7YBsF0w8/KvaI0CaD0NyhqPzQCDXOMJ9TQ5 wWDF+dgst1y+AqzHLSuZ03H5amPT7hYgtiXdmgN0CTlBCcvW5ugx8hXLQhQRuRHoEXM3ekR/kW3m cLfmDDYtQ1bP4DbkkYWRXxLcHE6wWmZXrThiWmpwUj67azXXx8vufemnLt/eaK6DGqTcOfD7KfcR noeoWSvexEaFuZO1E/j6QNiT8ml1c09RoYsB+cUNXriDwfli6yCI4YdYF2B3AJpMdOSGXgyhNkaX Adla8ss47CMSdzm1gHOHr7DfvYkTPzQBAp2sXSbUeP7K5+cbeP5mWKpJ6VTGtwE8+hbOhVDbw2K+ QHIloyE7hrHz9ezvmH168IOtwWBOGpzsn2x1sh94z3lzJEwsRKAO/nTGhldleb2lBedJg5P9k61O 9tNJTTi/K9DuvT9dnDkPW5YoLtOQIIEbdFTdMd8wjPF98LwxdoGtvlxeYlsSwtPyBYsIevUF5NNt KCsKE8IVJ0grKU/Lp+wNLin/o/TjbkMVMIjCxQzoVOpqOKL+HC4mWGbOkimUl7TjTUBZwvcgydqa WvO0wbn+6Vbn+o8RaN0TFztXqapEL/m/F5gbdFnxyWaPtqGUPG1WEr9RMNDp2kVGjVF/7cS4gYyF wqiPhsclcsow+gtbhex9YgsG3Xtw9CDeIzbUkkgCR394jEDiyYg/W3Ft164tajt63dbayfCGHT0/ ALcv9mMSIYMi3vyJgY4sH/GZLgrqHrS7gUsmBy+AzBmTulmRwL3V920sAbTb2urSBE4q1Tc6WpUx FNI+JXkoIdk1lvbJPymOcEn5MGWgVOfwsKFIhSe6xlBkupyz21qj3OMbMCr1jxVd7be9puq43ckx bQIXFOsAqBekFI9gZIl94eNEvTwVNNeldtgsNjnrhBBqbVgZY7swz2Ok7RFiKXoryfwFEeujcEIq ofiyG8fhyMevxmkojrwJ+wILwtaIhoU+kIan4kdJ65ZTAyhJUngioq2WbG51o+hFLHyz91Dq+stZ j3eWjISrK7yHuiM9wKXL13Hsfex8bLNMZ7fMVT42nF30umesQCohPmM2vkMBz398muB/qHI+obn4 eW/04gYkxILnZaeQnltEBal20YTQr7l8fFT9swkTVEAPL/HGKKEQmQnf7SAUxpCm5O1/EENkCG4J 44DvStUe0R6/hpm40JHq2ajccEeqZfqCD342YiBc3PRAn9Xtp2/wrjvieExf7kLL56evsuhIFyBL +eNlKXJ75QW2kBtxGmv4VECeraijVGpdz28tv5GW5yXO8tUGDvHIalrSqoRnT4+E6vCt0TfS6DJM F+EVCPWwN/ihOAVB6My0zZZs/ZI1/EYaPrPHRkZ2VUKeaxDMaLM2u/TZnOCNltcB9FfaQWZrylcL x8aG8VVoI6FY/F4nrG+u5ZkUbfgJC4uMb+yigZHvL60UeDpDN3npq6NY/5ICu6yC6jQfolIgu601 OIHrTdVdtTstMLErQFSkv2APUjxw/180/oNMKutQRY8AoZY3EcZ0TRfMAY8PVo+cZxAFxW1Wh7+y XbLIDMEUCB41Q5ZHePRgIMaThIEkDra6+apYc43mK1g1+ONJ9bXbWoOyyA9apc3XJQCwFlsWAgFs hwTLBEgEgQ+sLU1va8ZXN+t0W2twLnlnW2PXkAdWDFzdWS54fiJl4YA/CYIMfifnpHjEZJ0FSE1O weFlWxmwkhQzV7MwGJNcwvXF7VIcFYt41AO4Bqlxwzwd3hsb5E8R4RRSpENTDbltLf/xs/rC3dYa vMpa/Id6tNbgVW7a0XKgj0aXjPCIRBcLYTUIF1hik7QgqFWxmBHr3hsfXqE3j2nHmCZ7Kjh/rxQz b5NTq44Aox6UNRiam3dQCvtSOC7xMzYWyBa+OwlxohKSZClnZSZgD5YCy5sGwl85sUrusUZyVdWJ fWtauVEPaeY4FeQ/DmOqowHgg7+O7bKLiG/1EG3gpIBRlQyzl01LDq0J66elpV6MUFwPDHB4PO9P 2tHi085gLEmnbS1ayPxdmPxwKExurWiYl8Z2TkVkQRqWF6ZjLXnM0IcsCwKnn9beiIbdfp9Y/KhE 4g+Oz9il1oaGbYibuHSx2DIxWNW9J6mOYjHgqYs98vifNaJhI4r+ZyYiCuw8iYgUBRPaL6x6jZqE Lqk1n2HzLSczcx/pvxMu5oVNMLC2F1NrviaQJdULxnU6gDHx6p6P08sWtTpK8QSczgvG3tgWTbar 5caVd7XOUs7UP70odPb3WnsfcE4FuUbEitxsAN9zbYxPFrxX2qQrniAQTbe0Qyd0O2SppIhl5zgk uBsb5g2HeebucZWgFvzkQnAFIHFiKU6OQM4NRhMBfiiHWVZgo8N2RoedAJ3sQwI5hVLbjZalluMQ NAvmNoMAD95nb2yf7Y19w8SHzgTZKMjeXj179Zxv3vMevM1b2HGD91xXaq+ezDyl79/4gLAT/sVM 1Cvse37hgy4jl+3gExXEMnaINppPfBIww6i3ljTVbP0nb6GhCj72HwN3gp4moL97j3hCmWJPs5DG WWyvoQiWsxybOIsXR/1W77JaivF8cKA9A7yE4BaaIAMXXCSqu7VPqXG822soauW86TzHPuQbDuow gCAv5j85xxjo0cWPDejXfFQIX6FboQhAtcsLQLVzXkR9Rw6M1ow5k8OmfIjcyGvEEWgf1uwNGeRo /2Q/3vZzuBoW5hNMUAC8jOl+T2uApvgWogcARFrh4t6DIDMlBUVrRTixDbEiB4GppeKIfjxlBA9u /OSHAZryZw/g7ts7aDhVY3dNMrmTC8kDKOUPmVFVvhv72/Ud8jpakc3U8awRDRtRrBHCYuEZNMhj KM7SPo2M6WLbYdnODouZeDAgAbcu/PgNY4CQC/kWYlXLudTU3v+GvS5gLP/wPuyeg0C2a9NJylRq VB48E2QkjjfgKBKx05GrNeWUfexFNDKLxFIlKVGasnun1IznyK/ZIYGdmEqzhA5alB9M77TW2gR/ 1Ds6bVWMGq0ELeQYFD18Kdii/Oh03qsgxKCOZ54P+ExurLNvlaOnfBKLXbBWlq7fMIBzIrUfqAGF oFmydWlsmymb/Rez0Peg0JJPkym8doVsNKp/8IeGP/iKB4Ix5E71xMUtjfHb7Nxm5zWwYzW/oIfW 8moRnfZmhdY7IiDOPDk/KZeNE3NdTRZjXEomYQwX++xGYxQ3K4Nxgr5rvZBqofYBnkWzofXt9ft2 jlcnR2fiuREgF4LLRu7MvfcncPzUl+ZrJaRKD4/UbP24P7c2NIyZiYEAbjZMA+TrVFAHG5janGxJ rQgZv99ovuNOt3/E/CyxJYe8XSqycJn7rlZcUlL2NUQBUE/gj2eKS+3ygjedDnPz76q4lKN7DoFT b/Ol4oVpK/D+ZV5ZocybTDxFdSlCWsJT0zOA8mI6xRnAqiNu7OWsLLyhsZ8T5vVFW7dzcgLyCp3Q YgOlguXxv8lPPmABpxSsUF6MJu8QFBbzxu/H4C7rtPMZO8Y/aD4+tszlQbuHmuI3LoZoLlFjFp1O Mkn76OjkmFlWoennPOnt/GXi4U8C2Y4kJflf4D1AhBgj1OLUa5Au0tGp93kPGmxh9AuJUyY83OXv sEuztChkyf2nN0/+xfqjIePN64LnPI32SXWJTPyRpdnCP+mAtTJDO4MaDalTnvm2WRcv/zzHT+5k otPTYNiGXskBPm2k111a5OyU59Ll2W4D4seqdbhFkdBYuC+aLQWTGLUaNnOvuIXlyYAiPdYygeaG v/xbSDXrr2FMCigJx2ryGGKR+dM0lWLTKlguhptkkOmlVYqMzhptGl5kaG9xA+5DGKDYR3wMg5zc Ee8EL4ORTivpAqetqjVqwPduxeIhxd+uGn6NptRGGj7/GqF5+cDVLVdemsL8O4MkNjSVgbPg0Onw +ssFoK5glR9dA03uLaPJ5EePW63Wabr/TnMKTQst7uTZfYn195F6xqaZdwDynhe490TIvPfmz8Bf tIhIV5ve8AxZMqsXWFg7adNaSfklbo4NHhxdylqUQeTata4dQo9p2uk5JLGcWQi9MV3HQq8V1gDx Vt+uCi4STo94f6/mYULsFUQdKZ+Xk4dkj2Z+jVCL9QbAz249L1nW3vvYZuuhHxYR7Bc5tMBrEccg ODv4L76U/ez2WtVMCksaMhgjAEYio7RUqmZTBcIF6pfP9uNtP76GfjxfR+JIOgh2eC5A64HzgE8k 7B4DrmNI/yIyhCq9h0YqUnqJ9TKGm4nw9AnzSk67OHE4WUhTxlIF37nnazygN0qMLt4itvYzbD/Z 1pU8LSlGqUG3bDzND0aTBbjFnD6cNo2tCQ2bUN0uwUL9EsGbLqm+IiYxO99EsIMhv2FF0B1MpCim 09wgVJc5RyOJhsuxkivNsX/V3kPD9zB1idqNVMUbkcxE7sODP8pFneehtaFhG7JtYyh1755ohCbp B8j5bMK+Bbct+SZ+bvyDRmtoJvT+xZrQsAkp2EnuD881dzC6WRyzfm7s0hTe17O/4yRi1QlHxCi+ /55dcML2MIBzsgBrFuRr6z0a4D3kppOcwnZOW6lHaKUHi5k0q9Yj3kFf07BM+pfw2UM8PnD8OUFJ N5cX11+/Xn4bXg4BSwtFtQyNXfSwrI6aQpGrpatQ2FPWk2YgRoyGrnlHvS20BoG3n990PYd02rBd tXhaoD1DYaPU5NuXg5Qp0rqDTs0mUPUnUISBZDzz7S/Xv/06THbFsUkj6Q3SkV8nHI0W2IAMpm72 etm2Y81tR6D8VHUxoQkn8J6d619vODUoN/2NPWxJQINHX13yRite9o4uLxlBgAWyV+aJOKuDsT34 WZ9pHPDvEwBwd96fc0H+ft/78PzpnpHCR+EEIq6Cdn51BeJPi/4+ySQgNyT+4lz6iRESg8M3yyxP 1GTYPsIcFXzGkm8Ps0E0NVroVGIsZeZJITGytTxep6CUjwY7dASbYN7CBFIMObKAUbBWx2Y1lufw fjwHpgrWg088eyS9TisGRmGrvN8UBY8Mck0O3Q2PzZdgx4TRX2jNFLCqw0Po6qAxQTnWGP+gvgb2 8xI7w/q/7fR/O3Hp7EMCdt2KvVM7YUkzGPk7Ldc6ssu1bKTQRmBseoZR/Vifq1dQG8Id7HIt0kTQ XxGy+xVvjQLBzhQNNuq9L56K9ylHr1CJd1GHf4/CeQh41bn8c+7hKDJxshfHinPb8cZaxbkJgFZb qvMIZzKZkKBZYppJpTM69sYHjvfx8SPvl1DzRNBF39gPsaDKOvGnUEkMM+45w5nxAWtv8YalM3+Z 8X18IfiHEfvOwyJgOAsoX/MXC7ZsZwptprArbHuwoTpMFPtB2oBlvoVN5rr8XAq9hnsQpCSxmf0r gAktBVEZ+K+gcamkKYU2hAMhqqgYIjj8HWhtGElOuhzjJeMBymWLiIDtkiDLIvBHoCfaWGGYQiom Htl4PNmS4rgwm40CNgq8X8ux0INQyqm5gVRYkCQTNUnPjpD0nEVh+HAZEYWDcpnPe/HMm0zYjwoC jOzNafon1frIAYtd1KzKPE7+p70MxuY+a4E1Mh+8QLpSWiFh0FAY6gzbl+0TjZGqMZQqUKlM45P8 oFklSv5J6eeY6U0ciqkLSYtJHJJ0io+JLHKwZ79/ZwMUFBFBF3SYUNOF1CS3U1lYeZPy3QyI/Ky4 Bro7OuU3OP+Cm3ZHZ0GIoo5tZM08UP7n3WCHJOygOaTe2XFneN40h8Q+qVGHxPR1QONUfc81ZlAm oUsLcISWAkvhSepK+CvtBOHzW6pyzVTl+ClcTEgHTgQSxpKRYBwVzBi/DxmDEOVYznQ3zG5taDiu wDJEMGfhX4IYCP+M5zQORwuSubJVl626aqi6vsyd1KMQ+Y7odhg4/MfN1cXRcbf7fxI38x9RuJjh 2zi1HPknZ2NdiWFXMvVGT27gx1MoOsxmkxcJuWE2IHwG2g9sFNZyp7OJd8BNmWKsAt+xNjRsQ3bh gItOEZtdwKaQHAvZwnbSHIvnYTh2MBwcOGwX1cx/fHy5d0d/4CpiRN+1V9B0lej96cd8RzEuIKHZ lIThHn4NMagDQGrkQzsH9/GFy5TFi/tDFvmhlORDmgxoq72Bhm9gYaqsyluRMsaT+4NZzPl6SM0M DALuYJ7WsPZhop3A/OMSa4HdNawDcTKecx5CDIPWxNnbZ/j25TlQzSja8pbuGot3TpZVE7RGgACC h3yz3+lV7+TqQkOK3mklUYpQy50Cay1oMYiCHpCPY9GNezyUqUkAy9hIgu9L3Zpu21yDY4C86tv1 naqosuJjA/rEkWCLF5c+NDU3ck6I+eYG/6RGscQdDIIW+6yMC1vQlCSBQw8ZWDCeUA2L2K3wSmLq nxFxYYmEwgALVmJld4JZE9ZvQkBMWNIbhyMfrB84W2yuSommeYTFhO0lKinPwtemC16hiZ5Q9Ejw F5ChaGzTJRQXM7ZxwYLYNYDYOoGUOpUKwZmL9AAKpYOpC4on4MwSWceGhvpDA6P1Kk4k9gCIzv1R LNWLM4YF4o10/SnEwMGTB3LNwwNIp1pyb61YvxVFDib6m0m6xnkEKRxKN46HdkaKikAxiACtudZ+ hsEY3UPSlctrE2k6lt3yS1i7rWVEhpHXe9328LRa6KVovRmA3OypM7mzjBAXjjGvRKWzH9kScWom 4lzxiRQx6sDIHDbdteluDenuHYc5ZIhNpjFnyIeSmnpGEdbF0KZsN4YBRN19NDys5zAcYifeozuC LYiUQVQv1jFmC3pj94Gk9/3HgHrHSKX4Vu9wMXfuofT4B3Avaz3D1iPuxbMbjWl8bQbTiRF9ItpQ 7vvoE1UDofuGUWgP7zCXwiBIti+BGd23GBZ6KQabWpiNFgBBgiYnxSYKlS8PzJKU+ybeky7rCyNB Jz9pb6JhG9KVSwxId08K8Ev+OhtwZ8APiFLMeMv30lrRsBW5X8zMdNtM2mbSNWTS31J4I3b2S7cT PzDkkYcQ6z8M+w8uYrKftn8zideHpIMYeY9ganq0opn1Hb+cfTtDuD97q2y6Vap5L6UaZg43eHGS Fa9aa4aL1jAiH4sTDDLGzFNqUHsLDd9C9ULdAr+85XLNzkmiKJEshMXU6Qh70wH52yi/nVF+J/pu 9iHBA7dizovJXFFfEoTi78qXSHFCrMOpc1cPjidTTKBjSl1ge1ztcfUe3E05rmZmTN5Je/zYao/b xMZqj1+Ei8iHrihQlj0ExhUq2lZ7HO/nyWqPy9OiyNLvVP5iKOr1gYL9GsaxczZ5DCNQ8qdWcZyl 7SKdv1HSefmlvDnCm6HNsF5x8ytme9IlX44UwaHJAi8FBZPZ3gkd1mRaxIJ/hsE/V7oNC+htZ95r LC61EZlIlO6Hj04dtmAEWBAYTcG6+eF92L1rvxMYjpmztiIuIQBdf7nIjC4IvWweoFyFAzYFwuKD 2JdMNe7eMW2YBZM8Afq7Ir1lGoloICYzpXAzd8g0cn6UqdVbGxrOMIjqRf1hDGbMXYjZ0khYkg0i cRx76OtPoasMZUzIZ6lJI4UP0jS1NjRsw1TY2jkLUk1ih/WDkc/LpB82BJlDNpB7H9s2q7RZZQ1k MAoAvLCUYQJuJR5F/j0/keoaalpjQl4G46rUUkkji/Uyhr0MkyKYLmJMTCC+L2akY82jAiT4Uigh CGFbmBC6BXL1CWV51tVYV2PG1bAkJsbkDw4rl/90nRib9PzHpzmyHzZxQvPuyH/m3sSLLWnR9AhJ kn/mVA2oJ6CsDJtCXZ+lpJwsTLpFwvOENlIYjhRESPQQJ1xn5kUjmsN7JErpeMEWIEo9KXeK7Rlz JkERQWLCH2E8G+rsrF60JjRsQrFplKbq3JEI85SWCdPi6qX2HHszbCuFmAjXCSPaOKxqTWjYhIkX 5R7SJmA2AashAeMzImk4piU4PN+ae48v5O2Zmj79QBrdJ+Ej3D/frmL9hmG/kbp4JXrDbjKqT5Ei I6DHLFw7+3JUFCFBTAqN3NgKrxvPoXHRHpFPxR8kbguZA+RfIk/mBTqJd2cjvAwb9h4av4eEsNiw bcN2DWH7KgqniNOjEC2g2XwBeZsJNqNMuLYjD88A9HgFoLqRkdiZ9i7eQqjFn130j3ptIrayKZjV 1C/xw2vOgkAsHn88lyPv0t/kLuZPYfR57+tFtPgnfQH7YrD1ttNq9w5bp4et3l375FO3yzTWwKHE R3tnAXvJxmxYixcCOdCERmx3aZ8qW32ECl2ztr5DoFf+bXaWFevyuH/6qWDvvirxRRyLO4jvDr6g kqVnlL+nX/NJH3yFPgH+kZyffvkn5ueHPQL+9cIZryHfmqAc7cpWtMonfCKU1I9Hi5iWj5GQNHbl 8SRBvfQrXkpFFBrlJTRg1ku3/NEWWL6QnkNoKuGsbCSczgDQubFMH1lWIs9O5nZUdBAUVaMGHISd eMiGxSKiLJ4FKTuF41p0RiNv5IG4iCiFPg6dVUUIX9YzvL9DZ3U+SE+sFfesIJfBKy50K1AII4tp dtC96nF5r9pbK4No9Y+H3V61UrjCJ+Y/fowdZ2P26AWuUxf/PfmpF0GTFXU88XzgYa4Fw2gjAAzU KQAgtJhR+jx29qGKSbCRj2aBzipWXIvyQXOTokozvqKDqp1P+AyTusWCd6fhNxYWsLBADbBAh0Iu 0/dL9IMkDAwnDnzRi9hFF0eUoH2xp9OJFkFA6aJdZWxckpNirlrFMaaE9SDWg9TgQbqc0IE0QIUN E1a5YAq6gBzQnMCeiiRd59l9Ng7bfN1Avs7cOpE6Q+FGGL1HM42euZ6Wz1z7yym8khBWm/sNDgjW 5ItxGJdMX9FxfXGrPaPhNNA6bOuwa3DYvdccNm06uEfWRwL7TvwkGkCM1gH9dTiJ7KUp6bNbx0dX HeY5SrR9zKKBkBQBe3hCDGKUrNBZ/rz34lFzhNbxwk1o+mBKqau1N6r1bfkIBGWC+A9PBpkXh7U1 ey19WmGWCj5tqbdIcN11AERvhmkmd/SEz45GpGw7OnP3DywFeJaHEBEqBof7zdvKduYMmrfqygPq OhGgXLSkg8X0HtjSvTd/9mDoNkN4260Wjq1YJqD/IKrSn6DwW/OjEx6PfH9Jfri0hFLZS73S/Ljj nEus7h2Q9HGFlQY/xn9OBSVoTYjm0uCQbQjSodWmX/8kv5gTqEyZxoETEsr87INPqoQv6iXwxTBM vmLyRsNvk+B4w20bgVJCuKBmKWjYhVMy883/Z+9rmNtGkiz/CkIXO23vWh5JlmRbfVaELMljz3Xb DkndE7cdGxsQUSSxBgEeAIpWR//4e5lVBaJAQqZskUWR6Zhp2ZTaTTCr8uPly5dh2lOXZZhTYsX8 nP0dSqpWMS2pzuYdj3KOhmTbg7TUuZflLUQuTFp5aj4W1YW6PrhZ5rNwyEdX2GYFrhKG9LP8PUnd UfXNDnv6O7X8dPKZ27/cfaeUx67mBy+V8HpWwvMH6kfsr+Uh4VdE3fyxyEVvxHGdyi5q8NLCqJdJ WJQX4NTR2pzPmNV4i1T3C6c65QOpZb8StWwJlKKWLWrZpSkbFsObpxAhizDenlPZtR6ZjZd4WB4f PCe+0W9AeDBuygtFDea3/XmiI4FlZU69vREJykY8pJ9T1wpEn4CzQhOYduYBijP0WwIfG2JmLIpF g+70Pefcbt5JXTEjuo4jeGLFDw+fv3Rs4/BX9PDhfCOBr2bzV85e7ey+O1ss17w8djnVcBIeacot 9wgd2cYH3Y707s1EepdRi5XHttPUeLMg6leo6D0GRWecCqf3bzKFMz3ot4zDYicOWK3V/oEe1plr zGemMAvo/dN/WGejczHwJ1g19QfqoHrzzBCofniw++r0nXP5VgBU53eqP3A/TvKYwhPEGWkao67M tQCtJnOizWlawaV9fO6rM/jQw9x3DUBZZa1KP+v5lBef7la7n2d9G4r7nRX8pHHip5+ngd/P8o31 h3R/fAUf0s+Fbgm5TPE6j+Iyy38qwPUv1ZHRYAe5OohGekYDfN4xUanQQK9v+LYVlxMHxYaLQU7u 8hOwYiN5Lczm545jm9rRo9i3jFyiPAY9B3S86/A6uSU14FwNcLQi6cuuJ9xcO2KOp15sXgg4iIZH JoJyH0mR4K3qhzcxZkyxs0b21Qxtvs5p7ysH63dMZX/ubjGdWqm1AhoLfo5da1AFmSYYKMgEQWag AQ2xGjHPx1SDTYwFTUncOp5bouryo2qVdcOCei6dpprCKMqhaghy8WT+DFJYSKFIDAcZUvi9jFI3 c5WcFn7o7m21rdcPOoUJz5xgRxmMEqlOTFJFknOsa87RjhPu+8MJW4/nv4iK3owLCAKosPoYMtRT KTQeVbUPKo5ztTzrO6ODCwGstI+ZMR3QyzHYQQYlaMy2kU1gsFmLk8osNutsNXAV2WlkWUETgWfd OIxorfspYCeIyyb23cBXF1eszfNB02gVt67itJOMkFtLlFtoAT2nTVpPIDqLn365CNAAJ8SGlu4g aRlmKRqPVpPZjYbtqHnTg7YgByuAmvM7JdfADmL9kUQpCpZfFFBl1+j1G78YkZoNCdjXhs4mJcQE N/3OyC3VwdSg4XdWBxd2u0yDKuQ6xI24XBvxkCuIDTU9SHgbdDDHitVHlC9OvEbNlcCBFKPrgtYl pSw4LNKUB+BResrwG9JDBcBnruqijHhfhRW/cThhHCcAFWGR3OD7pS8kDjxUHGjYELW3Fi2u9lFT 6mxJYPvgm76QCLGuAFKj2K41NxY209NGZjKeRAcCx4HUYAXABWkGbilCRs74AnDnWtyIU8kyPa9k sRDPDDsaISQSSXfaCDorgNfhUgKBRIzo24jIxpphAi2eydWDnlMcsTRcPWqI3TzbTaK2EOm4MnDE L6YSx7mVighU1FgTTR6R7N2F1SgVpgl5u80Z6ltBNKHGNKkL52LKqMEzGfdjqOJZASzbCJBo5Tla 0WpFLUw1EcusBIM0pYRWLwqlQbyMJ7iLsS29OYfwLXCfTIORmov0v2KMOtQ4FHDFoVPBSOaP0hUE 7JrKWb6z6WFn1qrNuzDg5WhI+IKKtt9BOW+EDrFuGGvWgju4ytsdJVJ4jhSuMj4DymEJeeUh9m2C moiVGrc1weVJDME3gUOI+bybj3WUmyN1UxkZr8sWsFnA5h8U2K2Vra1MIcwOfeSxLwIqXZ/Pqafe hUdCyaAR9bIcC7wGqH9PNOBcQJvsmfgVz36lkmmvl39RhniOib6gNwohfF0qSsn0YmZkZ+MYnDCM YwmPbxVWLoXXRZaMwB6atP6JMJSH3W7c0dEAkFOIK5o/I6poZVJK1UKhA2COXw80eaqPqgs4O76n amxjPCZpzc1rVPziRFfAhlZBXHKv9cy9NoLvJg8JjF5Ugx+LarCXhsriBXVfi6CuxBBnyF7m6b81 0Hv8AWVqnqpy+wylT4mseurX2acPp1Mv2hf+OQL+ubezu795ybQE/XUJ+l7iYTsZFavT3K4DZq0B LGEzDynvEmiIFWt25qmCLCY4Bgaaw827jitmRLT2kA5agzUZjWWMfUDYvj7C5iwyaDej/ZT0EqYV OnDIMGEu3SPfINPF+emnX389/3h2fkbdPgJv0fDDHlXA8Vcwm3tNiV1MJiSDGiBRrqFniGmyARcX q1D5DfRJILOHuZNnuHR5oL6GRPPBH+K8wMJcIohvkXia2rLkikKM6NmIuHqJCnO9TLJypRMJIBMV 7XfQ7E1JjOxawcLiRH07UdjpRuU99oxgTKS31jkGWoDr7zkNcZNiUATLXePb8J90EVUON3uJSJmE udxBz3dwkpcw5YVYaGhndkJivIJ91ribZq4GaY5JXEfpDyz+FU7aQ3HS6GoNcwWJxhEKClzLJAsj pDFEStO0gyiYlBZVSSHNmfUE1lasZgKo1BBG/mh0nCABSDKArPgXJmjGx1GIOomS8gKFEzAoqCQh Gy8k3PsO9zAieRkO6pSY1RgVzJi8yWKS6CxGUYSoUQzjL4qmvs3P0WCfxHrPsd6YsGkbYBOjhKIF IxuwWYZl9EmiFR9NDs7Ca0i7xYb+bVjFd+RuZZ4lEsXXNYq3i3EerKAYJ/BtjhB2npOL9Yo7qWde VFObsb7q55B2+c21AGr/xfQCKEeu0mhYmlU/r96+PNk9XazCjdnuM5sdHPJjr9QCINomQMKG8Pd2 fJHpkQjm4uQ9O3m6RqRthFL8tirnLPyFb+qqvIFS9zmK67RZLOjZgrZsac+ZHRPVCjYSBV2GvyqP 9ShT83y52US7mGkzArW87xUQM+V3SgMcx/SZi5jpWhD6ajfGCfyeaOsfeKVTMer1IEsNT23nQxqt RKDhjGawW5A9Ff97xazYGCQAeIFp3gFUIql9sbfzbwFS2z6yJGpRBaO0jBOT8Zr9XRjzctz6Rrib FbMhaiY0fkuFzMksyKKuMAlNWcgKslOthnaj30bYbyMecsUOKZC4K+T4vQygNyNsOJPXdscWfo/U jJs0WvtBL32Lk7hENdCtEjZxNZ6TfFiRIoHeV1T287DoUzdci3agvI4HAxXF1AWH60kL/XPdPBsQ 0e/fxHz+zVd1QunGIb5P/qzR8GpLZ1NmOruBpcWC/i2IdWKdL4j112HnC7AsmBEXr46Q6+spcX1d MXIfesPHh6TbUJZ5fE2j5r+HyUgFn0NQDWVBJhXgsiATnTnwp46WoDpy1Ue+aJcUY898B4cS5CyC kFXayZi5TAVQoQaQrog74AfpPs1ZHELuUElL1zez4pPla30wctVYtNjiXLCFqngKTmU3TgEyEb0C 1pc0xHMaEmWdEaFEkmRIkrEEj88SkmDNEcycYdIhLkoqO4ksAEdfPAuus7JPspJGi3D7d6ywx0wE RQEtNikew7PHID8eXL7/9NsvZ1iWgsEVCte/bl9DkKibhLAlzUVo+4ZMrKPyZhzmkVjOs+UIXgYz 7lqjcXFRjFQhfl/8/hL8/gnW04z1pCL2I9I6brMpw/ypQ5AjUv4crH8GHeFT6kgIcQXFf3j2HwNF 6+niYmCNN8njA5tHUrdxEH6hoI6AQEE9RPzGAJUws3zXapV4PE+ZUtTmyWFzAynDylUXmt1ph6xH 1Zm1s/4RuX+e719KtDqaFU5ugeF9oFWQaOmHPPGmZ/bvSpxJ1Vvqbd+XMFdYyMHwBwIisH+Lh1hE q34nW9JsuYee7yGXOYUqcQnfZ2MFCIzlWKn3DaeK7hutWLdptiCWRz7aHLO57Oh612MeIOe4lyq0 PgBG6JsY9LPxVOYJlrnJfACMZ/kXcaO+3SgKCKYp1qwplex6VrIbwfGShwTLbS3I3WLJdbGkF97l wiVpX+xsoCStF1OWImR679Wq5D1pxepGeFFPp/Lw+S4q19bNb5sHL8hh01uN84ffk9xahl8BKWk9 gsETYJUgBUAw7+rt2e5TWkFV3g7REuoG/8iz0RAIGvDqzTupfjxGqxFJvBJ8PRKtLMdZMByhfQfx NXiXdyRdyahYmKbZCLpItCmMVBV+QldBb5ykf09M6BnLJMSS1dRByOspYGFhAvNd8pgg24+EWsIY 4r/0k5qjOeQGrgY2xYCeDWguEzwim7Frd7ga3NkKANPVg2Gn3K7Yz7P9nKW7v/52eUWSzqBCJCMi yeFWUn/hNqj6Q3a9csj2FvN5Np+5ftQxZ80gum9CqorXE4pesfQL3azZKfTR0Zvgb0n5My/yfq9C yBYfcSYd/K1X/iw+w7PPgN3af/1BNm2wnwWx891vbLdX8O/BH3zPNtBIGwGcbMRDrlhkM2VKww0W o+ttAoaABjGJigemNbrA1alTAEmU8xzlJoUpKMEEHiAzHmYYcwesoEUASSaQIL1QD45gggRYUqyg 54sfGPfjTl+M6NmILBpFoz0TGC9LIfCoUYYAwF8nHIZmomTK4lQRiQk9m/BJoRQBegzaHT7fe2pg IGybB9WbMXW6ndNZJ1ytGM+z8WI9Vs1D8SFWt6WgDJO1QFYMaZeb1QULrzE1w2pvYdLL8rjsDwxY e62kT+K7euB41xynoDSm8phCXhTEaCljeK7wssGZqbmD00i5NXJq63MwwFVMwntMPggKRRISPIcE V86Leq31nYEUHBwTjY8g3Q45lzh6s/Vi/+V8MvV7O0f7h/eSqd8/33t5crAUmfpjW0gET+hJV0uZ 3rlfdxji1ToY4unKff4tVIVBeOvYQjCd5TN+qrDClX3wpDsqRzlnsiQI9PSuVBZShqXYz3PcMbkq y0ravWeUEdTKEcliJYtdQhZ7Nsr1hLqy61+gJEQDej0tRtMUjqiQxwI/N8R8pszv+a6I4TRiYIeQ fSIpEMVL6ati2Ck6DFrVnldJLPcRy5mfpEmBszkIXEz2gVlNkOMx/VEiOZbkmO3BnhZ+2EheXS1a tVsxmHiulmlMHNoh/j1WEGBLCkIGJmaXfMyzFb9x7Vw51apLQzCOXMFVu4ImAjpWCiMQP8uY1EJM A9VFfuQCer6AkRoS2RNNmSDJOtiGMcySuIMLBr96UgaQQSyoY1N12GwgnKMfY9A0swnyQm+J2nu3 d7J3QLgRT0qf6RYQ7S5zl9F/ppdqeBwP1GGuzlln9jkBqf9KfS3NMk6dQxDP30KFr+dHqF4xVPh3 DmcPNEM0PurHvX6C/5d4Rzdh8marlyuV0ttFxpfT+6XMz+Q+9kNZhX1azsV04NeDnft+pvyRug/n HoMzhU/GMTd/NPiElmiICoSdDb85bo0+nVbItnb+DnZ/6LOqfSgzP74FpF7zHNnxUXk8o1fbODK5 fcur+xSzLe22HmBpGLT9CPuzwex3z9MXUFjr9J+7D8LPAZtwD+Vgb00P5uwP5UPa/Cyoaodi+AXh LZdlmJOD1p/Mi8Zm59U9vsfAE2gnlXPxJue1/ojnEEZsPGDdTe3PcxoOrnZeH73Yne6o0Se0e3j4 6iVH25oCivHy9SvixO9TYwSj2KjMJ+84/as+KCFvtgYxhAPfn0CSjN4qj+RPf4eD97dD7mSnqv0P u58NPkIdmM3Fr39SnLp8e0U29R51QuF4jhU+S6y9iFbGOE4SFMrj8JY2ogUAO6occOY5w4c1vdH1 nqmf++MPk/odzLnMfGIpj6lf/YTdo7s944Q5WXb94jmX6s3WaQb8GZDIRzWuLtTUq53CfWnu+1XO dsN6AIGDEyE1VUp1G4SYrMa5I65lRSiiH2E29GCEGsTgPQTnzH8O3ZpiZgni5p5wBM265MEOJxLG ys/co3PuvS6pH85711OO+3sEhzPJCjqKhn441Qs0ESG354Qc+l2HbOVuoHN3nLru8Mfqum99EuYT c6+bt4/HFm8feBUTwh6YY9hQW8DnJGjIUfrseij63Oy/RL/XCQJe0RU8Pci3l27dVfXaE7UIRARv 03qew3tXpB7DYv19/1jB4nielTyKrRETAQ9yvCGo73Y8m0s8vEBRM+4CCYdwPcJmmqExRbuXmULN kZP00DuA8DhkrsDx3Xt7cPL2lAl29wD06sfgxTyVyv7VSmR19fc9V4VVf9/tgfNxHV9ETOoA4OyG KRQgPn04xWlOQPSPWMsd7TiegJsWhwCIiwkAJvUuwPle3O1nTTnLbl2js/Mgz8uEK6nu0u+sfsx+ rDx9xF7SbmJxXeUdBwch3IZc57G9pSTl8VS2OV1Y35Vr2se5+2Sbv+ERnOyZyMIcH8CZ001Y5KdS v3mPCW6ov+8HhBseV2ACGHGO3dRZDjE3pE4K4iLItEi6FlyutOSxQuiGddEOpVWyOhY1fuAO//K4 Tu9jwiPqp/cB8YhHd3pZrTDMw14eDvtQExiiZY9Gh2kKzInn4sOkBjpXsZ5q2u+LSLVT8PLeyMVq 1LQv712Lr0tRAN87A2O5Pwr8w6fXTSfOfGQOL++NbDzo6SUsy+Wh1G/WvcvtNTqhDSgYgqKjXk8h PcjVILuhipagGSdh4Az+gQ/lNyrV7/OeD1WpNk/P/FmPe/Me1UNOlY41Gzwwccl+vkS5gewFIrxI XDDsIQfNkAYfqK9bO2itSDTVRzOPnyt1fuhInf8GygbWk0WH+wAA52CNNvyCxmYaL64ywmE/SDqg xkQWgnCeZQE4k/1Pw1m02rBSwg4DWMTuO7eSVaRjZaTO0TiwokhEt+fvULlbLxXmxKfEei6NAudh BrNiHuu1DgWaKRhQjEdM1f5T5VnwZIdvImYFSeI++l548RGbjy4hI532CrZ2qeUhD96eU2+N6C/M wDKfCH982pEtswVibwNZ0JYna29JL4nl4pd17W6gqqwXU8qyLs0Mvk+43SgHsxHx0M/Va824qWrq ZkmSjR1GGSXV4UQ6htRiWb8syjojIvAcbV6yLadz+TX9p18u/vvs/N3Jb79c/ffJL//4hKLh6477 a5cVsjar7pOjuPyjiKbQv/rKuMFuEvZYXBSyKmZyvLX4JQbkQEHjYfNc5orFOpiQlTeoMRK1qvs+ oc7K0wnLXkRkNwCl8HNS0TR5oZsmCHREOHVchDMS+3J+iu7BzuwhyNP9vcMXmt68uD5QS6L55BOU NpIsjIILRVI4U0GbR1c2Iq5txEP6uU8th6/ayWhumdsQ2nMaQrXdt9BOm+zldG6mmHD5+VeqsOC2 CLGnMU5pq0nIyxYcszgDYy/nJ5vPcphON8wAz4aAsww/alkamD7AKbxRmEFNgyrF1CpF9Oz25+j3 NYKcGzrmJ/8etMzPL+OR27qCjonxmGbIEV9gFhZFeDk/S3iWqanr4vEBw+tsVLoCELOfcn4W7Aqa MQQvydHAm8Os89NnvZr1uLqXWaczynPiZrc8XWOoo9bEWlxGdmy6r+BGzMoycdbWvwm5YulINRAJ rVzSMyuxcsYkGyw0UI9wqVK0pbjSp9Ojls3zJSbEiPND0wbvYqrwJmJE50h14gi6JH0FVAEanlCC wNKn/zcCRg6Ph69gZLJCxCjFitgetnsAg8izskyAt4sVrTyBJ77RMM8oq5zMz+TIMmOwUWC7aKT3 eQ1V3oE1w55d7l7RWAhHglcVK3q2ooYUtq9uh4oX7NA0FDes2Dy26LPLEWBt2nvIw+jke8V8ns1X j3YQusD8tboJ4T5R5ZmmI3xsEUMDtLFn79Ds2RMLerZgOKQ0RlfkxinaW8ffQjMZoRK2pW8W4QDC Xfr3J5N/UdxopdXjKRh+iHDlkKboZr8KzmJYqkRSMyDgBYsf+rzm3pQTzqVz8IZX8w+8HeytHFRd PbXzgJOK3EsJhxQzLaGlyBdICrmaiONSSuhWXBlFW0flQKLg2yK6KxCCRPLYzbOBNlUe9+J0+32G KoC2NTwhyZtP+sULyGMOppo+Uo4vH1pGMBqrJHlq3F9lPQA54bAYQQ6GuFGVYyDlUtjRgVWazkLq 8SXX43S7cAmh1wPBeFxB5BvQByWpBL3RF/hJE4KUiQNZpbWEVVpgnZiIfXT0JvhbUv7MoeA9J1OQ 9Xh7thf8rVf+LC7EcxUDQ9V+saFguEsG8zpq++NocI1kWEyV18aUPJUqNTvht9ZUdRxIzLRyZvqD /OCFxVW3P1e4aiATOL5rf/dCsaV+h3o/FKhut7ELUkM7YqZVMtO/B39wIrGBVtmIInkjHnLFGvNX uqM37fq4vEwjArkJzMaPoQvI7jEoY+DZECDAi5LCe07hKyaOJhuhzVBknZjlfFkiEe35IZpJ3bgD aICa9B0VpJzXP6MZjQLb0kUExHeQC7vUdKBO/JA5nvpu2SIaN9Egb+4NZNnxj5+uAPvINfR8DUfD iO/cDEvW6DGTPkaNgEHdQbGfZ/s1fKO5b3ZkCvcOMi66O88Mi5nhUozo2YjaTMDED4In8XP1/Bl+ Uyh0rKKCeBNmmLHdgIDTxYaebUhLM4akkIQ2xhSjiTV0q0FGbW5Dt5DWhrQ2ltDa+AhhctQ92MKH RS/hVIcUXVVISOgRlhK7kEGETcoYK2BquZz4GN/pNupW9Eax3o4z6H54g+HouNuF6eB0GLGluY0J u5IdDQJILX2TOOE5TnBxO0q/pNk4JWQCtPPg8v2n33454y54nMCWmDGI4qIT5tQeJx4KoRjqhqys f1Ss6NmKICwkGUScRQsxlvC9hPCNpk9jx8hHDBtRwNYo2S2Y8ojtfSSViqYtWf5knAGaoYhAqqvi Mjy7DJiQ3DhzqkuafyDRLjvEIlXAerqRjegMyUOiNwa124tZSgSPaiGBWHJdLOmlW7t4BeC9DaRQ eDGlKACLAvAoj9Hd/ajGW1gUhdDAwhcUImjuYyNChaerd/h8X6N2TUYzOuqbV8fJSVv+nNWVZlfN OH+uItsLR5FtsqJnA+tZP76idd7xA1CfEc8Cm24kqdZgQSfx3yruFb2WZ4meiSw6eXwNUClON8/H rJjxLpUWNNnHprbNM4Y4/OU7/Hd2Dro7SvnsgTOLIfZhhjFNchk3sRprFgOaibPCArUkN++orpjf QFtqVFDPECshsIs83b7JaCQabfw47WCfc8GbI6AcQbTNa1WOFcmko09gI4JY0HOXwEZkjEbz3SsM o6/B86OInaXoE5NwWQwqtJmiHqUxuNJiRc9WnHW1WDaQkq26aa0nNdR2vcmlxE0thd0OrVe/kiFI nENX7RXYR55l3fOcpGWoifdmC/3XJLksw7wklMRPPDjGtXfufNv7PE8jj+9yO4KnMskF1ranqcqf BcR35RDU8HDk3wIVdvrOg0lquPzUsLKakzFUXoz72MR+hRocjxJAC66TQVuX/yTly3o2tv04ula0 gynyPQWPohWAms5Ely6pGjeHyTSVUgaRvAfbHic9JCMJ+fwwvZ0yFEVj/A/xA7RXW68YgpPECM+p 0jBXN3E2KlCR8AREpYFdF5LnUgaFC3IoKPUCXdA05iyJ2J5iRM9GJNWt6wyR3IxxavIgQQYkoS2R XCL5wzFdsU/rQPc4f58SL5EuJ5HJatJNZqnN4+eXrVjWaLqcM0+g2+fcn9nnfLEnMct3zGIRZKv2 gRzRzM0y1xrjNVPCH83UcQPD2greQq3sQYmHtR/yRCvzEcwQJyAqfTfOIdarh9vkInq+iCS7Y4Rb eqjQzGwbWXR2w9D0NRylAjGiZyN+SymC2k53axSICT2bELdtdj4D031bo0DM59l8jj8MrEZEEFib BpGVeGRniwyHBoixmBCg2KvD/Z0dsaBnC7KCy8/B3n7Qz0Y51pPX5K6YnYHI9yHl1HRiTGvHXHr3 vru+pvtOHBpIZVCe2epSWTSj7lQxqy/3z/P9gwYPtEusBo/rT68VoZlEkdrAsk9658vvnZ+w5iht DTaYeqNxhYn9YiJ0CfKX3lHDQj20ThS0LnEonh0KSJVl+AUVLaiwWAra6RB/0m55tTQIbkzCt4C0 QiFDhXlCw1N2vl+M6NmIjXv3hIX1LM3+8PlLFtwZFYWRDI4HQ3SaSTejusAyFuGdI0A3q+igeWy9 aZmHXVIIDq/BPBqQPlKY9LIcS0UHhUR46SE9XL/ybuZRc18Vh3X4fvI6COK8psx6IFAeRcarKZbh aTlNrOtwOA+mHKmvccEL5KytDL2IlpWBCkzy8SC4DMIS4xOGzCKB3XNg74AUhgwNROEYCnkR5WVg IEVU5+E7Vt66YdDgCXpLKf0MQoqY0LMJaQExzb1Ad5TnlqZZmk8na9/bwBixomcrMoSJu1fSKNKf Ks+CJ1s7W6Rf/UHDaM07iIYEcGuUxvh59XWI2QCxoWcbpmGJ9kKS3Gq+tEsADH49+b9Bp59lBSsF F6iREA0TGBwJTQQlwkxSbkm5l5BynyAtIx44wjcRU3WDxUnlIvzEAP6GUoCm2yFsTRyNZ0ej/b1e JkIhAHbCS0ncgStpGsykBiajQ/wX63m23u9TlN224L95ptqILos8JDiUoviJPus0S/1z7SWCdVgt Dl8uy1voUIyP4CrebH1OUOxdQY7IjCMvpjNHx5T+5o04rn5Yvcf/J8v7WarSZwEKgTBBuWd+nXNJ VwT/DNNRmN8G+8+CvZ3dA/tt8/WPz2FPBS9ebKCu50acyo14SE9X7wPJ+KSq3D5DG6xsXCz+49mn D6ezXufX/jlC+Y4ruS9J2loOW8nVW0xWAeUXTC8eItKhFr3gBRvVyiW5Smt5lfw4+Nae85UmpTbO njuxeOBMLJ5jwIq0MUB8DAL865t3TlfMhBowMaRAmp2KlNZfpeU92ORDVJcZQBjTA8WE7iS0J/JA N0uSbEywJBsT3Sws9InTuIypg0LbPuNURUebd9Uk8VhY4tEaEnaC4AQDJ5iH1U077SMmLoSnGpgh V2AsBYorNFp0S61XUpBURSnbPX0PnqAoo/nLcT/u9HnLp4kOEz+DTkgE95IRTQK+psxHStyLtFyX 0HLF2TwHqxaMdkpMzuAvYnAFcBK335PPoQQGdI6hu//aeBY09yAqLw7GO30aRtRpJxiMnb5hujuJ 6Kc87sU1mxoPJFMMK8JXhQUHquCtDjwiZFrjNCekS0Ki0uEy/hwgkMy8qbHE+RWI8/WZUVCLyVLW WV4TIQ5/ru7lUMHrxhGGGyDIv3nFxIrV7biBYVFknZilbnkGn6yFi5ianR0swI+8mljIjmWN1xUT emavwITOBaM/fCPwOV5XDOjfgG2BTxioUg4tpxy6qsdociH1ouhChclAV0VudK9l3uJG/LuRKsmq xYCJ7RrVjwSBmTqkntB3RHEJAuRDhOHm7wROBYEToOpxRyNjH86sCM1ZHA4Urdx6r8IIX7RjkQDg PwDYqrsWlyeVNwWFhkFNSLAGFRP6N6FzpwCjdBTkRyMnWEuk0Bxo4ULTgq7lN2d3qTmLmTXUBNKd HW8hjewUb7ZOIY9IGkktC+ZXD/iT7uwcZhPyx/L9C2ohJxOZujp77/ZO9g62FpAoj4/6ca+f4P+l ne3BJieV0lwPjoJxtuUxZcp1hKTeNg6veWeQ2whpPBBJQ4yP4ujN1otXu+RBwlHZz/I3W7+e5qM/ 6YUIiPybLeKzb++83t7Zv9rbOTp4fbSz85/6ufEjPLJF40mn+3uHL07p36pNcXn/kFrIPdQ+b3wa uX3nj+1hKKVuPMv8GzVX92GP8VxzPdb51ALO1X2oluNYYWbtjcma/3l0j9cw46O9ad/bpVyX548y EFyoz/74HuiY0YjH975bHMbjexBy5y4M9N39YXGFKWRUka4VnTh2az682j9Ji+lXZ1QZc6aZs0/g zD5B41R2sgGxoy/CtKd4mzfenc429xobs1c3oh2D+eU8FhJw5M2U9dcfDznInQ83Iw92ZvdPzUel uhC3hGC1+XzeQcGtsjTS/QGy8UGcZvl7MjLl2mzt6e84lYJ9o/Yvd98pVRT0OPVq4AX91WtYDRxP cRnYlhtRX2/EQ9ZCw2cUsitAS8TddMNevWKf9MXdQp30UC2buOl9hnRZh7ifVeV9+Gr34O05Xdla 5d148Ux1w8ciLbJ6RqzqM0piTN4ysZ1wGmwTxMB0M0/iAoAyCl36P1nOzlIA4uHXzFwFcX0qGKz/ 1ZIg4AVJngoCjRa48f62BS6chgoiWpEoLpyGqq0I5z6jmLSumBzMakYB4TSYvvB8BvzeSHGmIEW3 s/Pu1e7O25dVTrqI9DNSCR5FAwr7cxasu+hdcfsKBTKSB6e+/n4kZfrw19/bwX3fG7+1mTmUedH9 jBeaWOFBSFLwrvTqHPPTWf4TI8PqiJRQSLMBK7jKOElYLXhIi56KYgT5DU3dZh0HnroGb48KHPOf 0f1N/ide4a/flZO5H5D9KBd9CA/va+glHkK+inMgOtUFeWSHUFdjmgmESX6C4/oK1VqupV/0N4Ly dogOhlFrwIaLYjQcZjkp+KzNIXy1wofw9X3f2yM7hJXrQ8UJ+kUxKjAVB+GhmobI7NPH+lF6V8M6 eMLXO/c19PI84et5mS6P1RMi8kZx0cHePUhJUMCddo38yvYFROJVBLU91qoxLEq94m0tDuHeCh/C eRssj/UQEuChF6jXUj2SR4pJIiPTZ7LlBFLkXiNfuMKlyet1L00arg91CR9H0vbA1lmr1gVpOXg/ rdilAza3X2iifV3SwtcrXJu8XvfaJKcpBayoTCOFSphUR+yu1SGLO3XUMzhLJIwdFMi50y18kPP3 an/3/Lxi5nqpjV/7LUvGRwlIKMAB0Mh7s9XNt99d1MnUE9ASiQ9+ijGl1+tercw4W1Od17uOzgJw p2/YaYIT1Zvolvb+MDW8+8QXi8CMHgp2/ManZU81fSVbfZszIM9OJQOTKMTuq7mG5sHP/DrxZMz9 9eGYk7AoLyi5wW5uWj/zFknPF0Z1WnoHrTtuKCyVDP0zLTG3N3KJneDje+3Z2Zc9OyKQ9INcbJx5 y2Q6lhU08zLY7adGGQ6RDujrfJnOI/b6G/GQU4WIMdgCQps9RIg6rV3uRkyyhPrmYMP+zk5jsGGZ QYswV8BbRPN1MIQZK3WoPb8TPImfq+es20gNKucZ5ZAtnyeoe9RPuYytJUD1wzYZM5k+ajxD83Z/ f2dfz2abB/A+ZmLeKV0z8dBVfek4BpvirnLRad0keYYVJPiR85teHUZ+TqU3MbVCNegP0gfEhLuj hPdCFHE5YmExUfD2PSrDTb8gRCOmvoY+VSrihqFu1kRxlwfkagvNqyUsYkLfJiQtn4mFnHyCkVuD rO/v3IOCsTctNjLLdZqmBgCQ13unTvx7YIpnBUHPzhW3mGG2Rf0dev4WHoWf7PbY7j5rWKZCWCiD WMYn2JZnN97XZCB1f+ceXI4ZJ2ZpD3ZMo0agy075IjMyXH3UzhlebFFzjLVV73Az1ddwMEzQakRb 2/WyT4qnzkdPIX7ty2g/d3C218CM2oDVnijcETWh7OdZWWK1e+VOsVesoiiwshMRGIJiqDpxN+5g MUJ+o3KxomfpzCd6p0g3hhmvsQkON21Wp9Jq2BqLPmW+sjWvGNGzEfUWoDANUCv0wSRPtDHD9NZc MzIfJ6rJwKwENL4V3xDrebYeJivRhoq/Bm+f7wYYQBkVJe3oJSY2isER7XlyEZaNiHYb8ZB+Qjr2 lr+EG2DwIRp1eIHfZ5V3QPPCWaOFFZvnE+S4LR8+rhCw2YfQ3WT+ytlk/hvEhHoAyF7sbd5R9eM0 WusAmlyLqrXllEAOJ77ECI0goHUp6edEhX4EBQGtQJA9hN4Ff0wSr6s4UGFGxO1FB2eI3cJc2fEi +hj4JeyWj+NCBWNeHU0m1MmkXEHPGeQdkZxnBswIC1082259kmRFgTIu6WU5VvoOxIaebWiAEdw5 llZB5m+hEm734Ka9z8YKkImGw5CkBR1d8eWKl00CyxYjejZid1SOMLITXqN+IyHJyf0qME3Rpf3X CH2DEFtcO0XQhVeNUwbPVJCqsZjPs/kqbyj1tvAjH44f2Zo6XyEgO0J9F5R/zajHiRVwrcoxVioE f6o8C57saAgWJAHxGp69Rn+URpQrP9nd2XmKOP17mIyA3mEBBqIALWBHmMa3AiTUAYrWDD+r8+bK 9mJCzyYk8wxUiO0iXKHSeK0tWXHzEKEBrNsOV4RIblmImgAXpz2xoGcLplnEEk64i7hz6DNSqqyC JAsj7lV1VFjoQX5sGumoghR3binpsivitIxExWIUPNAPHliFQ+dCUuVa3TXsc9C25qZWUYbXaDvj S4nEO43kJnq+if2QdNVwtRASiV9FtmPsCLzGaJih4JlIGdAdtI62Kpo2MPleMUiX8lILFFUXkux4 F9CEQLmDvOZffeSo+Fm5h57v4TdsRUtxhizmQCCEvqUImRwwtat9Jib0bEK6cu49NIJEG+giJSFb WEIGPsAreO6Tsszjayis6Qo2+BzGedBNwl6QjxI1RRBdf8LlRhw5eUgkX0UcXTgE58c43ySWFEs+ op05clzluMpxrakEmCHVoTP//DkJ45T07M2Y/mKSQLqL9DfLnZQ7KXdS7iQkJ8Xx/PC6WnhTlkgS 79oQL5JSa0L7NZXmZ5r4XS3Hg9Nry2DHYAsd/r1Dle+4VYDvXuJ3ByJ+t57kro1IXr1cylIU/ube US9Bn8DUWjSbGUPsi6IfdeduyrsU/nhR8L3/8R/b9td/SHu3nnAZMdOHUjq3buDhLfgXjX5wW+4v seDjtCD3U+nqigWdoufR3EH2ovofcgdX9w6SpwyCS8UjFXTfJr/+ot/+9etvl1dyB1fhDk7IJx/D garsdEpUXygSdWNSwzTElCvsRLXGCz5+Egu60JEfLzpJLG2C+c2v4kVnME8Wiq616RjyffsLjNFL u154+x2mlzDLWmDR69uz3YDFIavpCLQL8yzrnueEEJKA5JstTCsnyWUZ5rZTaUu85WGH5fHX51+d eNz2Ps/TyJ/sees4IKzwjzwbDcnT4ZcOUcHvkibW0AR/10McXIzJqo9qvIWb3SnebJ1mo9y+hL05 tuIlGNawFDy4gLsuFzm4T79c8OWq/wMObk8c3BLmnfGhi4Nb2eshDs56s8fs4C5pLTD2sm5/HA2u 4bDpFxzcC3Fwy3FwVpnucF8yuBWL/+Lg1sHBQV4jjuLydvtsBJlcrEnRDg7Xba7ST0rUbyXw32hZ WQf3AjmzlKgrheCIg1sHB3ehhllebmuUm/M3zuAOxMEtJ4M7T0cDhdBCMJw4OHFwDfKyUJbuhP++ kT0QBlep3Bnn9o0v5g7ip6RVuwKtWphju7YtoDIeQIZXEqKWE6IkBxcUdUZgtniLhKgfDVGm+739 O7hD0DDjX3Bwh+LgluvgBEX1MYR1J01EQIb7gQzUD1/73ZQb8ZB+Zq9aGQ0nRbV3xyyNwO7GGOxJ Up2+htwt9P2yMutkSfDHxbvTw5cvXvyXXh7x6/Z1XDpoudhvMcIad1XDhSpLSEezSGoY9OIbCGcS YxlCmrlK1A22RLBSKlY3DodJ3NHNDlq3hIXjfTGfZ945diRhkUcUjLE+hwU0Q6z7qBmKlcTjtJOM sB2L9TVhXBFuXNfZQDoO2PhyEaY9xT1GFGNx9GZrf+fFClJNSeG3ihV2yzrWfqVljnCBg1oEl+8/ /fbLGTbYjMNb2j5BO9tKPu0i75v7Z6RyDA86ieI9bWNSXeY1UMYdqa9xwdGlsnLNN9FKA4kfnuNH eJPF2Lkddr6MwzzSK/fK+DpOwG1ADlBghwhEWT9BA5i37j0L2MZm2RcCDnYXJLdiRc9WjMxo0sxr prPts0+nlNBxQ7HuWfvhDW0VEaV0300N7UqRjrvZGTDEWkzHyEhrRKdocPBqd3f/dKs+n+AI+Z2a v0t1sZcE/EyTFLxDyC3wFzOshqg8wCjNIMaSoPcnWHFLVHtWnpj+To1xP3mj9i933ymKO9H2O6fP cj2Efv3gEMcvEY4w8QU4/EIVwywFwEDjmSIMvq4lDQ33Td+YuodzvJc7EWQ919Srd4wO3YWWnIPz meU/0W6ZUh0FV33AJIWZ7I7UELtligBcUEwsZsmIaaHYPc1pVPC/9l66nn0j0K6NeEhPrpDWJXw4 +XgCB4gojY1jjM2JJxRP+HDt0eNXz3dxzAgR7kiY5ThUQ11mhib7ovAfvpv/gPleDf/ZwvYaG9o4 1g5VJ+5WXQjarQiECRxZQBFWYeWQzmuSCCjhGZSofAbQ2yRD4whm6ubZgLsQP52MADrQBnIOWs8C +nOWx3+aP8oOxZqb8ZTsnnQ62QgmQnfwycnJyVPsYsp1Y7f4iSMCF15Idnu4g/mtZLfrmXhsRAov Dzmryn6MqYxYcl0s6aWsXrz0+6FIv0ug3D14O+kFSKX4rUpRpN9F+v0uma+NCPpe4mEJBHAPiApB MqbSi6XbFq9nBPNzwlq55Vf9XCmiGNVOXgCmGV5SEdCkUYqmx0w4ScA/3+DfFJwX3AknCYh0NLTV dg35sy858rX2RUkbv5U2tnqWSa9gD+MrpOtdBCF7mq1PNypPsjCirirzkM0UZqCnMLesLxLWo2/G nB5rIHgarQR0gOIyDpMgLIq4lxILnpirlLbchAlorEEnTIlAHkYUOuK0zOhfk0DhOVBYxw/euLXk pdPku4CUZJzDZMMM40e3PEV2sLd3+F+w7qUSA/q+hXVX2gUtb/ZdpAYtfceaW5pFUkE8HEtljjh/ 2BrntdJZQEpnk+CuR4zicgPZVCtWBLbHdVr50AjrLUFEorznKN8exDfPNIJVLmzK/fg1J4UdrITA +JrQYjdA82PFohVPBAxUpx+mcTFgPYViMuOcEoWW8+DQjFiiCs1JK7+AykI/FDkM39VMlI1TkNlU OMCIBxkL8+agLaoxgOZqutJYjPEF/qGIsASMglwLKOTbgOor3b0eYQmVokDOWsZ08aCOEQFM6JTJ bRB2u/iNNhzwhRHvZ9zAunQVPaixIlC9ArhPSURhkIhvg2J0/T9stCwYjJIyHiYqgNRQP6O5q24Q liUm2Z9tXk65YjYkRZp+qCNdZT6SEQL+yvoQ+F6IhZoprLqddbcvVX4Td1TwxLEcJMtWcr/fWXY5 1/vEsLY/0ZXjp+Y2OG9Vao+F1R6tGNQNHFaWb2BgkcO2/MNWdS9tzjMIb1lRKQQAH6cA6AdGwe06 G1HyA/GPDJ2VrIeEKI3EWXgGygBdQJijDIoSi291TjOpO1JVjrP8CzAOLjPr5owFqPZdeVSJDuWp ChPZJcQUuQXNVguyIU1oZ3kR0J0cx0WfMiKjdiYXz/PFi+Kik2QFlk1TITFdOmZgm4WG1ETNaKyY Bg+SLKgltKRVVKMteRpYRGnBOqZQTBqqku8fET2wEjzukdpRQO1pQDVh3lOQyeRisZDETDrRS+hE V+BhlMFtQD4GJ5NVWQEumh33OJooeG+g5BEAdNwus218kcDgOTCQ0yf8yQ6qk0PpcX+JhK1R22H5 4zPyLIjkXdiOoSq0n2yWhmAvNvRsw05IoYHCglWwhtodiZUSuj8TKr5Gqq3wA2mWbov5PJsvjP4n 7FBVxC0ZCdgSsB8uYIMyQAJHn22TAaU1un9l8KuoHYnaESYtHu6ktQLEV3UZ9GpbRpzeZMkNlZh5 mBYh5xmFpdESjkd1qu1ES4jyHaLQ8YKZQBMoAtu8hK62ySI6SYzwhZ4XfqpArws/xemhoqxk8j2x omcrGtswQIdW5VDBUCSfjXjg2GZVO5Nx8QzFiltvtL1Xr93JFl9IwGjRpwnP0PA0tPejVdTBE/W8 t4G534q19q9OP1Oxe3l69fkplbxprQKmbtJAFUXYQ9giWyJ0ka8D8JYy+DbIchnY8d2nIAAjH6go DqGoAPf2JQXnDWNzkz7TCdBSnp6rQCvNhaMi+uqXS+HX+DbhGVmBruGjiEofPmNGbK53uooxiTo8 EwiwSgoolasBtg3wz3la4UEsnwdB5pmF1FLRhKjUhYZslZ1zmkeNWuby0pjwIPwiccq3k7PdVs1X iSD8WwBqB8kaSyUjUtmndINsF2jUnfux9auKikwI9b6tSEZiBINz+CS8VUKFE/WgZcBq/6IGD0oR Bl5QUhpALaKCnmjlWNJhQJlA8SgA6Dqg7vSz4fb17Ta+SBD3DMeU+QhzUQOE5YThMsAwQDiIOW4X DGvwjDJhDd2wyIcNHEAR0s2z4UZkm/KQgIWw8+VChKH0arr7LXhavMjvSxH5Xc8u9UZ4Hj+Ys4j8 isiviPwerdTCQ66fNKla5SUNERkmwrPgGvNDMdJzytF1ps6NUv1vABoVEG0FFrRj33qeDfMY25cY xq5WLEEOywJqIY+CYYDBNryZppABYtvAdqvE9+WD9ZegwhM91+FPM1lmNoTfwZQcyDQ8vrh5Bb6f 5KyFsRFMgbtYvqcxN2qkgEoJvI38CYbf+uEQtIAsiru39NotD1GxbIMY0TPSVgFqhr7xzEynEDce ZmyMw0lYWM/adsU8y1VfERMM/y8UaERhEozDWyJRmtE9dP4Gca/Pk3xqMEQ4yMC9HCYZslK0ncSp eHYqlddAZGcl9UoXDWj+SeoO1KInk+ux2ltj1TglqR+xomcrTrt/IlaweDoE860gwQfQKqirVjcj /jgaajE1saJnK5I4lumG6nysVqt3wzjRk+zDIRqgVDDCtdouGtMvxH6e7cfi90zXnFIoJKLtABt4 wVlKYT4LxZDWOnEuuHMq8iBbvokwWm6ABO1QuCYqBGrGIhKsazeAWEGPN2TzpnNkPUUxQkoDwhNc Kv4FJuDKLfR8C+3IfpXZWJUl4KJVCWXHgAgf1XP+1ZjWBhZOK1dT4ALS1BxUQN1SAilNH9MKTIdP VNRjHRhirwEyhZwoqg8zbCe30PsthE148xvLJyHDHEHHNYR9iiEIoqS5xKUjhiQVgAwM/StaB8SJ TBFcvv/02y9nYkTPRsRSpjiiroRORJGb8vQkocDUZpoNPHH0NAlq4o65CW6/fNwettKXD3xse/lY EQtor9bVMC4TJovB0YOLpe4hSTMze1suoedL2MhjNjA9EbexfLdxEhTxIE5CYAwswWaZ2ZyPZUi5 cogjTtrVcC5Vbk1lEEcMcR2eXQcpJ7HBkBrXOAZNjxIE7+D41deQsjCibhueNnIzMaFnE1JxgwZt Mgi2jIGeQyJry8DvZOAZvT9c1oi10HjtpgxY+ceVWNeM5C6z/CeqbR2DAqHfoqzZ3ksVoToCWM9u VqNKlJPJXfR8F804o8aTaEJJAdQFsNsNk4Kmkq4VZGKATnC1VF1XY12xnm/rmZ3RCmSX+iwZr5Wh eofNxlcTV7QTDsOOVYhEi5txCrGhZxvGJZkGwp6Ibok2mFa9mEIqrC+Fr6UGC750FGYHIzGhZxN2 82yAFJNnwhHURtxagQdFd3McozNtein0fY6UDBfGZhPbNd9DsaFnGzoAkb1hKCHgJMdhzmKtOm/l qwdESWcyVsMB1YaY0LMJJ9XeFHMw0FfUMdH4CPO9UFqMozdb+zv7WyS6yEL7b7Z+Pc1Hf9ILhBS/ 2drb2d3f3nm9vbN/tbd7tPP6aGfnP7dYax4/0joOeaYSkqbfe3tw8vZU//iiMA88yJX6Wh6n9ID2 D/T7/Ni80v5uvWjms6vUCDy4H3ahgSki0Lx0DCVY2aLOTdnKrsYuwwjdSGyW1CkJGwz1XDEqhmDH CWIrTNwlKNSCrKmh2opyS1JwFIedHUTUxKuQBhu7qelTFOAniS/xHJeR/3bsEJ/ZfdKEZ2t27mSj JKJtjXUbiw0921DP6tktYVUlik5shMqV5LFw38p4gPbJ4xAHfBTLNFvCs2lfoTQBVvc1HowGcj88 3w+NvrE2Jrku7AsuaL06dkdUd8Vy9ngHbVep6Bo7g6Fba3e2l5lY0bMVQY/Ntb4faCXY82wWIQ5z dRNnI/wpB4OklzFJiCOZ5MGSBz9cHoydIHtok+n91DSgemn2U5/otGnz/IOU/ssv/SvSy1Tkoslq vdIq5BYu5XwdTBTQoKTm3RUZMkCBQv0355NkQl6yy1pYTgUmBFIIcwHcwbhVnFFj/opG6Eg3hQbp FHoZm+dpVmxeoKTBYsoz9BZ3Np1jlLb1GpfYMlpu/d0X3nv8mOuqEgl5gevwbpTjGuS0NeIZOIMk ElI5RVwUEF0ygZVWwMfxWD7KLZJcR8k15NYc0ibTmsOazKyTJazcKnenE8dTYpX31n0bH/1/9r61 qW1kW/uvdPHhTKZezMHmzq5QmwCZkJkkFDCz6+ypU7uE1La1I0s+ukCY2j/+fVZ3S5Z8wyTYLaOV mgnGJomk1ev+rGfNahmYmgTwRLmqVB45B3KrD+RgqgL/K6G4EKdhHAktbrj3COFavuwNtgwQBeyp VjFADgliCU4w3FppkgqDk/z0+82t+PzlFhThIVUgClDCZG1JtbkrC+M5GLfuqEajBRn4SEBbCIeV RFnsSl4C/0pXEjTC3fFNzkH/XJ/LroMSMkGA9g/be+8uCE9EYKGr0lvkV4Y6MhjepI+BxM8A9/l2 4yrAMCphekwqt5zogSRo/uapSKalur3lk6EfMhn66yzPN8Ly2KlIMRn6s5Pi3Io24lQ24iYtqd7R 1g4S8c9R2DqLMLfqO4APqOWAzSul8DFbTsQ3u4AnhF5cVlR/dIuvmLce6waC4CalrVfENKVIw3g+ vroUaamx86wqrEBzIjBlowcfLzFYDW5FWJVTvBu21LfKrihGA01jS9Q3fphBgJFq5DbP2tix9zPQ fQIIZkDHEqCPaHoMcsMbHqimiJQPjY4gcqhne63JxIhhSnQOxZ/X788OkGk2MOWpmfQMUYHqpetd AaM6LalaHAUo/wWZkuekBSUNZg3MayaWrGjewzKmFFoHxIsmHVbE4CFGb5MEi+xz4lOawKZ1AzTT xNKzLL0BON5cBdjUk9QUo9wBmR4E0QNq74RUB9ZFON49ImzsDVLLuYlx0YzTswAtCzA3k2VwtOhJ 2skKVn7omALp+miEOfgt6RNXP/r+xPHju5JBua+z6lczP3+pkeIOkP6EENJM57kJUXyS5OmLI7xZ TawS+BOmbhg1Ryw5eo2M0EStAqSSmPfumXFkAklg1FUhIsGFc4+ATrXXu0EUgYIs6rKbsOwm8jzJ hF569R+AYNpHEDWv5ye0VgBsKUieiPWVkictxijkTS1Fa9KS9mkUhPAi6BYFaTRoo2amCH6ZYyS0 uDTZDSFicy+vZkhZBy3r4Ih0Y+TfSELFxHYsaZ0OdNE1M8BAnbsQso67WX6W5ZfbUK1lBpak0ljM CbgIUQq5BSBPTQke/cWkSXmMwzK0LEOay0F+C2xnRmvJKBLVnLYYIRj4fykCejVBkGRuvxTlbIoH WnXG8rMsv4nVOiHtnVO1eIo+lSImen2EKgujHEVvd/04gc8MnEamvDXLBj+gtAShKQpNimMWSwqL 0Id10LIOxnKA3F3pFSXmylxCyQCWH02TII6hHswoTeRKE1eaXnT8exfh1UXotVCWoC83EowrYGwV l1jLJZPmGQmGgaweBnKL0AIxxVeKIzEnjLPYwhdEI+YsdqWTosSSDwwDBtLFSgVVmceK7a7vAvXc vJNas3AEBgShonMX+EnfrGZE1FhUp3MuGkXBaBaNoTqm6puEE2H5WQ5HHO/fCOsB7VAdTMLvYG89 SiYhUCEm/Dcr07HNESAR4mz3sYMMtNDECqWW3bMQLQtxXN0gRgXnFAMMgRULUzVGBH3MQuaKVJjY GcDwxdRetovUZi+x25dgB6ANYuNi1WYTyQJkqESn+xEJOKLDTVZCy0roYv2BYtJwoHFY9ge6wnvZ 0tuKqfiJhZwKQ6dZUajBQLx6Q/T+gIoEZITX/dlWwACcawIsefBvFJPmHvGzwWPR1nAHS2gQkJJZ 9WQK6g4/BH+o3g3PGmhZA0dqZ3xeWe2IT8V15ZBiVQSgUD1tSD05DKJH0swmDknXLJvQUYthWCET WeAjC1+YQ7YUWUEPJlaM9BISZSW0rISOWTeCxBBgFurIPvR9dIN0rEkAupyaAD+BFQKQIKgmTKeP pWdZeiZf14ElmnbQKGUokRNWJQcDSutKCslhdIDQLw0sHdbMhBallSLL03FM81SLa7q1qenCaXd9 Tyc61GYwkEdqcg0kciXEYqhOOCHnQLZzoCLgUjXAvASoSn9jwGNt8Gk0U9z78oHC6ebZmJoZfwqO VekWslIqpYWEeiBA5I6nVyiouRT0XsrZURGtsQgtR2BzomVAPSYDLqwCKOoSKie6YzW0bURViaFQ qYkESG9/8//SI2Jmu2YeQFMLRpWeWBMta6LSJkKLK72Dm8uzVCMqsqNmGaciJ1A7/cakykK0LEQ/ hUJVeJYhSB3bKPkaOBZCz3Hx6qCUBWhZgJo6ou+g0HcnJRETUPMZphMbAzViTuW3+BAlCVXYzdeo OkX1kIVoW4g0xI7555HFVNEpavIzLeeEOjIGkjGQL4eBnMmJcqoGMfWKOZVF4ZA+0Nb0sKcx1+eX ny7EQxR/pf5EL46yocCPJGnmPeIdNjWWTU0pq8UcLdp8lPZCUlMQhs2TVSNKonyTqEpNMMvnvLtM F/xw7CbVDRXYYoNDE+ty+fLpgo8ayJ3FSslKKT7LByInfzbxLcgkmS742U+NVI5MGqseq96PqN7M VOnPy9b5li/TbsvDQu6W7MgWhndaiMD/VxTDO0j5854iKnG3atIx/5BBy7Y7FYD4qBnvR9TPwNkK rrp7xw+of7EpdOWNtjUSBS/Wb/qEBZqY92leFgVzkkfTV/HYkg0TRMbv0YlF4eB4BRULjOnQKFUV 76NS36JhkYMmh1k8xF6uBJp4LR1PAsucgMwh8FiIlssWoNVAKwKUrkTw2R/N+M8idi3o3lDYcLHj CdVVxt7Ztqa5o8sH6GAs9YScOP3jiubp0KyP8/G5HI7hBPmnacQO0bYI5Tc/UVM8Zuoxh6ahtVSM r473nmBNL8sjzGxMLRvTYoQchXkZUjQDo0pQZkQyGAMRsZ981fgoRVSkdNR3NX0RjCm7Q+t0mfd+ FBCNog88W08xU4wgozqNoPkrhKpqUivD7uQewUdFNyPKAFZAywpYOMIpXZcRU61eOzARpNI+CZag ZQmaNhrgvbHsZrTfAxOtSBiUkdTjITQRcicfI8VGL0XiAohIc5Np3+dQ1HYc40VuRkONjJpg1MTL 1SBO2tvwvme0XMS/y2gWunmGuhHl9JqVuFA2RkGL1mpQoDeU0RAz3KqoRccQYMAkuwMLkSJSEHBT TrKJCrT07kAvpZxV845pzSQIgnQ3SxKa+EJVhEIEUFJqF3XcPOGwDVn9aGIExsPYd0XltKFFGkdR 9yKmin76OJRvN5KhDIKb1IlTsxLbQq3/5JP7KYvj6jjkrGu9CD260kacqcVv8nC3fXFxlu9Cr/WW 9IfjwIFbMxvZu3Hr/bURqOom0T0bdbFwFGd2f8f0aKwlZh7/EvY9PPG0Zi4ehf5/wBpR8EmOXflz LYDNWzu5Tdx+1JWhX0Uav5hteH1qwyajBAa1eXZnWhJo5u8BXHNf/MOX3z1Fzif3VTu7up7cj+Cv aH10XNqkK26xygvdw4qDabL9acC9y6R1cfMvUM95YbBQ1FbLg1w5sROlg1Vd8qxnSfhfOIlP2IPr iLM4+0u8Q3oWBQCsVS6cjxs9jiEF3cM8VSjh0/K3NGhtbf3lrFNCtz41T6rB8Z0X++BYw2eIc9Q3 qwk/y5KPs0qgpyru0lPrWXo2M8MWQsBKf/Zj517cOEH0vdsZXq1lYoWGZ7JUKPrO03yTJSAMuUG/ op+h7FKturA8n2Gg9w/be+8u1iJHhVxrUHk9abcVTr8L3CIWf3OrnZEcL4nkaG/R8fqMzR/AdIFd 51ryQXs6a2IrVh2dR2g6d5o+nZn5/Hn9/qzTbh/9r/jRhoyRyRIC4twRUAHiHZV4ZFwpODzRdpkI dlZzpZviZmtTbPwqH4mnxtM0KBk2TCLLxEPHSEMEPlCPEO/fWz9hNXgpNUDSlP+6Lm2J+Q1LXoNk Y1O8O7sS7d1NEpwgddmkMhhaJe2jowMGd3JI8HIhwVxLvdfp7K+Lpf6MgpqsNmFqaainP/BNcbuF WRZPfNhaD8d4GtxjBSRWXlWniGv5yE/gF3/JgBANsLhJO8Z/aHI3PPKKa188t2dfuARfeHn6+ZSA 5qOhk0RgS7Hai23CGOMcO/vaOZKF4vlZ23MneSyDr5+wKrSzvX3IUQpHKauKUo629xClfMIEISYA zpEF6ebapviI1++y+M4JMRBA35CH/ceaeNhf8fj6Fe9UW+dqliVWLpZd6erR7iU7fAtyJnEFZFLk RoH4A6QvNIWxezx6j3ThNOiB4CDtD763zry2Xbt1AVyXRFpRr1m2YPYMw6oAERNPlupoN0Pp+l1D t7DQjZgBh4lqms3bmJ67ISSlOs0e3NDmjyZvNu/u5GMWVkuDsw7Z+sgGsSimVysHbnHH9PqMG987 jnQOrHl9ILkJ00vypjCE5b6I3F9TTceiI5nDpT3dgf4axf0olOGmkNgHGaBBbX5V7PZEJLCavtrF t6Efo2r40QkzJ34U6MrAp+zll2i+/nlFm052t5nk+3WWPRY3oK/JiKxGwy5B9xWHMm2dx043HVMs 9e35l8uzae+r9z5mAZUc27sVa9EIgfFNwinw0ovv5tef7o6hVQTT2T/Y2UFZ9b3zb6x8jzbFH6if nsZfv+IllVIr2jYrUZxdjViNafktynr9UFYnLGZd7KysdjWXOipQ/7Il/hnFIbe1atTW2ijIDd85 wFTlhVVT+iFV2RRf3DS6A1s6fFHne0sOaxw9NMIZWUpCAArvIC26DLHbjJG7zyhnrLE+2Tlqs0OC tXD4Z98Wuky7rh5Rlfq188vV1aYAOOni9uZS3N6IdudIdPD/H9D33a1teJfTrJclKbmUHXYpc0oL a1uqnzWhRt506lzzSqLRmVZgTLvqN9Z3Mmc/UeXimxmurKosPOtYzxsjNlaRvlQkNStfs51cfh8r V53c+ibgxptiVH6nvF6lnuIXvCKAyK9rApa6AvjLWYs0v3K0m2mE7LqwkpkZZfVY1SPU9A3hjTPa PXEsblysEYn9CMtDoAmlOR1M6LAULa8qKEnRo7ZBa+pKwtb2tnhDa9tpCg6Ujz108pKfWXo1qqzd yGEqB6ZuxkmOPyfJ4WLGS82c/Hl1dmay8ClJ+A7y7R2VhKOQS1n4uXT5iC7EL8ZH9MWOKFpwu7DT OKaVYKOu2dAH56sTOAtdqtXq2/TShs6EFrp622nnJwdso+v8pH9bl+7xr1HyFROj4ULHopaH+mPr al0e9g12+K2B+TjBdJmpjXxsYEW+TtWrUgq4LiXDtcKjjKojZ7H0/LSlVoBhmux0OAzMKI8BQFCg wll1jbLqom+4vddAK8Vl1dXPnhJkcO+gQ8xe1YbCR0D7MZdNXnOhQMp6fB2tB6vJrESGwmsqWINQ Zi2e920SZQtdqNUI+4TdW43c28ZZgM5MPk+MdeBYMIhtkddRBlL1Hu0jLvCa1LcBU1GC7QGJrJIV sZtYvZsoBe1GaL8nmP5wwFZARktJUTrBwASW5FEq9dftI45nuEWwImaZAzQ516X++h3LI+0k86ig XGiuu3db4swZDO+wehMgyMJif7mXcRA5nl45HQWV4IBttlWbXUVBKN4LUpJNUErfc4uMW2TH8Xvs iU9AsbAKE33Tpgk1+jWliwso9UFHdXGPJpq4PJ/DOIMXPKEnqIhKcGt/E6c0pZMktBYwkBhmxryO 6GZobUiBFdMjCqTv5dta4/46e+7Ve+5bJMV3NLCYRAFSY2RcdCApyYK71kGWC3sdo6jvRTizYZQK lz4CDQfHXbYLHsMoSfy7QAqi8XchxgTW5VSEmYLLochRSNUh40JuF1tjAHUEETYJGzKsQqJZBVev gnPdgKp5AJeqWRoJqMrVDa5uvFzofHKq9v2cemjfKoMgQNneRd1UOHfYAzKAnYCl/0EOUI5JSivO rkqscmolq7Y4w5v0EYb84fjeCd5uXAWOH97KbyntDkYVZjlWiay9+Ztzyju9BNYIbIn/9Lwxr1us 1asGw8KTiRv7dwhAohBkPgNs19Y0/Y5I/MEQDy6AK1SRDFfwbUclhb1AMPJepzbFWwnClFDcoZbv edJD3ELdGAo3IWG/F3L/ZcO29IqQEdZHYtECUoKBdPtO6CcDCJQShlA+lJwCvoUksTzqrsoNy7Hk cqz2PNMZy56fgCwNAnkAa7egfRkQ2o2U+F+tyUjE/lZbRZWHRaoX6w1TnvpxLqZbHlyD/IYJR/kc 5b9olE/sQKc9Cufz7lnzFJ090uo90pRgvhu5qFcpTE7R0kVxfBihLiXeAOxB5UVUId3Ax3n9uXnn 1E7bfTpcEK2zvBJMFkQkcujEqAyIUXj4AGoFCumLMAKxIHBWtEuNQnuWn+WAArG7B2HoPIuqxAR/ Axs1tK0QbfOE1AhnwDcJW/oq+H8bIUkrjm/ONoKT0aDC2OKBZ5H+t5n0/3Vmc6yUS0soTpj0/xTV 1+eQRdBpJHk04lQ24iat+MMUPeEd5Hrnl6efLm4vrv91++XLv979fvM/SMjLMzWcMlyXWrlTG6j5 m+ey62RBOvnj3AzWDiSdWXygfhP49mLKVkdLJ+5k37n3USMCa5ujkE9qpGvixPoNhFHaMRozBZhE A/nQd1KRhR7qegbkKj1YmPcQoPyGAY9AblKliKBpBDGEVA2NPZqP/eiheZamZjIMIlM9yiHKo+nJ MPKU1KgIqGpM1AeGrJ17BxxEwCZS1ZAFaLkEmMvNURDfbOjhBUQ6MqhJP8oCz3j4R4XIKMqGUZfl Z1l+k7FYN44GSkwyjmFGgYcCtBeGEzA+LduitUIaygK0LEDd3ELd/d4n8AwGmQsBYr96zwcUW/VP MIjOQqTTWkdgYkWIFL9kMUUtKnaB1NwAcDZELJByAcwHzM0Aa1kFLatgOagEov7e98gFgtcbYFPt /RC4eH6C5jR4IDTwPp+vYGibdVxiLN1oADw6wUYV2JCGXjzGSb3OyvrDsZZ2eu2EPakYn1BM8b23 G7vbewYUn1dXVohZH81xgppAXOjctVpjqF75BTz9rOumctBFZ3+/c7ZRRtpXBgHO1JlPr2UX2XHo SnPrlRlqlEgG8u3GwA+j+AMVjTfwT/bpxeQnGCeAczXzBPkjzv/y6pXSz3ExmZ7l6+gg26kpnLxT A0afMPqMuOgc8S1iXcpCW9fE4iNiIIVg0Qk7pEiYKDQu/9SHKEk5dLIcOgEENian5omEG05L6/XO rB0XNQwMKkcPWLNjMKEUAEbDfIIZmMQAww2qGoIxotzA4G1CkjbvpNox9DOFSGDD3L5vCnkvQ+F3 TbnfQclfIRExuyfTB4nPkFHnUjZ8byxBy+ZfKxICXsSTuWwUG0RKk5qjGb5xv03JNf7UZcgStCxB xQ0hHlSLraRgI0oPUkRoJcZpDQmNsZ5QXFf697Ka47AvXL0vJLGZKHlT+GBhwRxtNMCLCa0js6nC NWVLzZ/RasqKaFkRSYplgekkiCRW4swXlx4cZbdLE5v3EvPugcRGFxQrHbaktsej9dxEKeI0zrF5 msVOYPVO4EyNxIFEAWVBxYSRoCAuBv43IpDDRF21wkK1E9XHKFuc5h3UmuVDU+te1E0so6EI14b/ RntU4MsJQ0Vzk/iNs1rbfgCCoGYv9laMihKPQyy9AaWaeIjCnyhCQ1D90Pfdfh5MK0gNJFhdY8WG dPWG1IivVQLM5CVoqOK7DKOR6LaoANr8KEETzU9LhGcI5NiSWg6m9YA4mE4wf6wcIZRPJNldQs0E 4IVziUJu2nzmokT5kALxBEsFWIiWhVguLsUSuF8UIlJYUIIjKqGSpLTijSBSitwmjFh4loVXDixV tGkqfl2SYV46oqpS5rpwmN0sQFhDSEWNmdIKzFK0LEWtbG401MDfLwqQ2FLyBBthJkdYRQMzHUCW SIShlrCkHMzYjkWnaSH5POlQ6DnhD7U7hPvTIexW8/SPI+7VR9ynSGcV50jfSQT6sqhq+ihfA/uh O7kUXauE95EqnTkxSYmGNmV3b9vQFAG1KkYQMTxoaiv17DwISKjvh5Z8kRKjXQHu+OaZmpoVnyb7 QuTBAXtGt0HNWOpwnNIl3YrHbk7he8imsEwPuupzB8K2Eo57e2haRa2qANQqdHbfInT2sqr9D8ee DArE6QHhLJ0s7Ufx241PZ3H2F72BMTUAWzvb7d3W9lFre/e20z5uHx1vb/9TI2bnYTPPJXi0AbA9 aL8/OqoAbCvg2QmCBQWcnXjXTapvVXC0uBHi6j75ieSQf0OvNX4W7yh879SrLSN/X/zCZoxVJ/MO TBmxPH5cZjzQGiCW1ZXqJ27H4p6odkwsB/CIKoBR8DSUelHPUOUm7HBIwVOOTLhfUVeORVcfixZx TBCpgv0m0U1CSrqICFwF4lO1YDCWwyhOwSvvfsXnD07sJVz5hYW27QNN5TfRdVzzHSFi0r7RM6oa 5mKGh7ylci8miNAtdfuRj9I+U0NYl2KWZKpdNqCiL/AuvkuEr5tY6UC9F1QQhzHBRbG2yAmpNKVF WxoWoBlaNqaWq4d3kvwdTCdNLpN1FF0/BvBgGDgueD0UGk0OYFKV6dRFgJ9A82G2BpDNZRlalqEi EaD9KcrPKSEao4qGjK4jenGEHYaF8nHV8LUOXsa1yVMwdvTFVCFgVmJB8AkyKKVC4gDhtFD+I5Dy wYGXQDkDqJnHIoZj22LZtowWiZEtyWMy2BjgmbzIbJR8opLIDDS2I27y66P6/QBsdj6t3dLlQlW7 9xGnDSXUNCXap2K5TA8Q5hBix7Bn81SxEck93yRKTq+CZNxK6Wz5/Nsd5t9+ncFqIyyPFaVMmX/7 2Y0gOo1Uy27EqWzETdpRvZmT9FRKK42EFGOguqlPnaVSegWGBEqaNzE8iM24eUeDF6xar3qblIkL aK8zJqmZzbhUVBuF/iNhR2/TTx9Rq3eRlAMDqqHYOrcfoIKGd2FIHHBY0j4+xRnQvMS9ZlIkS04t S1UtS7K8VYYRs6HjkjQdN6YF6GoARtHeoNkSqYIpSjHURGMRWi6DqgpYa4xGi1CSVOGGZImiQ6ui +km0PzFk3lU0D8w+at1pAzmACg+UEHBlAw5RKwxui7IomU7d08RbpnkGFcy71qx/ddQ/hTk3FM1k MMexlYb2joVnXXiaHtIgeXIVHEUzpH13RN+c45iLvrUOtzdZhJZFSMkrNZGKAJQkRG9od1eRzzwI 86E9CPP0xBxtzDkXX4bTjl96feG06kpR4kE1y04kfIKIKPC/EvkRzHJFs9VoAg5P5aFzOWr1KFoC 5Y3RxWn7rMe4S0iNUWwUUV+YcLQEuWUJWrbJZvVIisSj6OgXvlVjnxPQK6R941grAgOteYhPDSn7 0cIDHJ3O5ADHDEv48gMRJ4ApVu4ChgO3QWYOYxr53bS3f+huKoT0Bk11vvpxFMAy6VbXYCBl3IEO 4yjqXsSERMMEIUaAYGaCQI0y2fP+J9dqGOAWF1Q5Qej6TL1ceH57Fzs9VCEwbuXa2W2u3m1eSy8D sSMY8K9k7MIeEZOC4llIuCfAPQEncf3Jtc/PbkbDcs6wAWCa83ugCxSHAsRJWZLGmLLEDiRqHzrE JSg9VaZUqH6cT+z8jUp1ynxhJ9sRy8GbTqaJ4j4RN+1NcdPRwxY3O3ndv8DaVlPtDZVxbzTQ2NjJ ZWfq4SkSKFB2kiBRJpYoGwPbrjkCS418wknTFCnoE8TQwTSiItRnEsgajCHmfHJv/C3suTW9nbvH Shn5mpDPP8OAFqSCoMPSzDs8g2h/khT7QgBX95M+kTpS+7QwmmqYDbqXC2sAVyl66OiMyAPxGdnf BlpSThxWnzhgHEqIM8UArV6eKjol9fKmrb7gt5tO8WqHQzTLIVouiv/kL8QTr1hidZHYm/bP4lov pRNvKmKZVe+xXZ46vz5Wgf1CF2u1OHXys9GHkjZUrpq9iyXvArn8p2V+/Vcv/VtJQNNMGAutLuZq mnSmvccSY4kdtvfeXVCDi4YWr8ZSMDXBAhdX4fS6CsBqRRRnpqGxHOtEVt/8zebiriudNBtUaYUO wTAWr/+jI2+9BIiKb/ik9CnrGOsY61gsPssHshdQa7NvfHZHIletkhblb5U1a/Qe6xjrGOvYj+rY mw4nuRriuASkUZHksq2qn616MsllodVPaCP3P+0VS4wlxiHBj4YEI81CWptjgak3GkvsGAXg98tv 16xprGmsaS+naSOdG71iHWMdYx37UR17s/OzOFULByeauOVxj/bi4x6Hk8MrlSK1vXGPL6b/q0Zd azX0cfLlwzEQqogcjq9v355/+JmNW/2M238F6d/yrHhqGZaFVj+hjeKFaa9YYiwxjiF+NIZIJKZj KqpUVwQYHOymAqEnC12uVQzYjKGIsQsvTRi3O4sHaTuTQdrKJoyn31gI8ET1EKEtagaPacx1kj96 uWiHk/NrgcEvIhIjQPtN57+cwfBvNwwZts2zn/vxqSFY/mG5J17RGAZOLgeaNG+aMhcKS2zC064P oisXYlmzRu+9iI5VGSBym38uuw6WaZRQeOaTHwDmlUsbO4t7TV3aAGIH7uiF++Gjg+BGgwFm3q+d sCcru2nbuxpcWL74vedevLr2/NHWoy4zPR4ozhaQg292R0WqooijSybUbTE1E/EfOoUz6zrl51ri nMqfahFjzIiDKnDPMyMj2aWd0K40qM/KmbjtywGIOQZ+GMUfUGLzSVRqSn3ykwoILL/Q/C/HH/O9 txu7+kpxi01hUMedTj2pyw38nj6OTxaCirOrTmSqEX7q9yFd+zC/q0mbVsXz5j+3DBO4LANGhoxv 0vdYkpOn+wc89rKOqxUbs/yFPju80Od1EuU0wrxaUUpe6KOj07cbZ1EW+1hTSOMJCEHcpPpWKVil 00j1hEacykbcpB3VezrmHoXU81+9SCHiep0CbpYYhjRN6ejd+d7RtiroqHbBMsRYrr7sk3l0srQf gWrp01mc/UVveGCLe7vR2W7vtraPWtu7t5328U5bNVyWXDoqX9vBc69t0cqQecZLTcJNEedps2DI XvIdEsmInEiR8p4TrAYGY15liM06dwQ4MdVngOdPTYm2GvEuFgSzI6YVz8vwua+q+LOAjr3Z46nT 5U+djhIJThrqAgPM8bVMrTSlysIOhh3MkyU5BuJQ4vtsNvi8kll/HRujViI20xKwil1ZXVzZKLyY /4olxhLjGYQJZCT7sVfux97sc5K7/CSXvUv9vEue5I6+jqW7LLT6CY2DOE1SuT6JEkvsNUgM6zqw 6XjEs7S1tcXmkc0jZ0ycMb3MHkh2aCWye27fzu/1P7Mq8eagNLgGLBIWUI7m1Ro4HFT/6np5tmuU n3GBfeX8C09j/+bH96NPOVzkcJHDxR8NF/O2I6h+iEUHQFtsbcXK3YdSbsaaxprGmvajmjbyXNNe sY6xjrGOfZ+OvTkcpWMVPcKQ40zWlUNN7jGMo6h7EcfID9PHIQZ8kqEMAtsrTXM2lDl3U+Y6mXsv k2x3NME/ZdynBlQo6kZQudENVMhk5fRwm2OPvDx7dbTI7NXe7fbR8e7z2JLPttvt3fcbq5i9UpTE HXWXZhqrRGOCd2aPiy316mah58ekMVOdO9sTJEqdxcmtdzqTvIlzSJSm6E6FImhiyuTZsMUR31FR V6InMVNi5edSMgz5UyHrpjSptpqvr9Su5qsangBR9zXzdNeGDbJcuCuV6ziENtOduWZXzJUVU12I pIxbLt6cKruKdaeGDV34q6bRqn+lnCW2HvCKiRH5ijKpWAG2QTEMdhZnkK5vJDS9caCYADYFfUET zgk9xTU9M06qZ7Z3bhaYjElw+sWadI6tJdMbML0B0xvkbF7PTjHJgHAMmYfPTG8wlxDumfgYjiHX I4acL6fRp5XApBGRB9/ktNr7OlrLRkiyfmWF934vi6U4PBaf/G8i6opzmaR+6KR+FLY+REmqkrXy m9cKeXIdZan0mmdw6ifBwvxPvriW/5dBnNVtW41QtEbcZM3OYntLCOzWEG7gY4GKSGToJcLJKSGF YoQMo0kDc/rHlXiT9p0Uk0bVti5L0U7xxKkISRt8tbfPy6W51cDWWyNOI9/kawmorXiH5a/W2OXV Grxao80zcwsviUBN8OQyTGUcyrR1jpWq6WSiIMT5l8uzae+r9z5mwaMgRvXm5XvsD9kffnfvZl45 vmOyJadHyVI3CoLoIRFB5DqBGEaB7z7S3uNEBtJFDQYv4nvshOnG0UD4aSKGUsbN00YrMc0szKs2 l6lzF0jI8jIUaR9UGa6TyE28lEJLVkswwQZrVUnrRvGDEyMxxk+w/GowSxLrGlkDWU0a4dpqZjF2 YCmwEqVKqQPjUZTLKjYBuLAwKdBhz9iUvDuJkydI+cVB+/3R0XLnF9KTsHIPOGW4iZqNKzhh8gBv 6oee76LVEfZEkrmuTJJNcZfB3QZJNH4TjHldwtrteQESuVc/dIPMw8yzExZzzihBDqM4JUXCx1K5 2pyfynwmojB4ZAHWwLs6wyG6AYh2Ipg9HRZV5AJwUy0H+67VGbvFpOFClzs5u2cf5w8fs1Hu21Iz d4PDnNdZPKtZmLNbSW4TSRYAGdGYmdZA8Fi6kU6I0AFUsVFF5ThKtdMDzGUlPXGHUgSkd+8EmYRL Vt9cSy9zFUjkSsYuShjIdgU6uZQJpyzAGrjeO9mj7MHzUTdSIS7J0ES8EOpwJDagfhSdTMv0eFMU ibu++51S7LzvnHb2aASbRlnPZVDKPBYDppXSFAN9HlZm3q8Cxw9v5bdUzxLHWkEwTFKkSruLTICr zaCdvZffDIr9J36vH+D/FFcEtXm70YulDOlyYc7U9ZJZqymsuyL3CcdixLuE0cVFHtvMhEEVRuE9 KNDUlbYbyrXH7qV8RtQRXWh7rDkjU3LYeWfd2hPKp6p0euSnKEmGP6XGEFSQHRQS0hPK/4Q6neqM 4h31dcGsd95zWJXOL74N2L7Ol8/h4puC1/McTh8I1MVzUfU4m2htoBUyqpCPR4yk3uTGNMRMJTOv 4uwerpG/Kp/dhZhWyn52zWzo3LN7S+0e2e2iQYcYCx1yPBnZw/ZxneyYpdhUXESAZWIqhYJ8EZO7 X2GheoI4uMSE8oyIanl7X0tnaGf7uWf/NZ2h8QIN7Utfgo171mExP0yPuQaHhfP/1ef/e6Z8U0Vy hxFcb1wJIKdCgysxdyPE14ibnMgES3bCpOAv7TBmZnuIHvfHSoyEkyGUhS4qVoJIbvEzV08U4nQ8 HDsvs7Ri3sE8UCVQkWYxqm+YkkPCQoVttUeHGstFTiO9TarC9Z0hqnSorMLvO0Ggfrx5JrRm1oXS 0zxkR06aRtFXJTfKTtGkgIgh0FhqITsVcVUofXaeQW7YngRtVLqIppByriuqpZB+adYXYTqVWTWi I/+Gbha8n/gd70yJxW26BYPi6GYBEAME8ahIht306kNJUiQXxhcVe8qE5+I4kE5rbIfCb4gRdoCl WIN+EoVWVHurCIPxG9U5jGfT+8yOJBi/ocsPbLVXb7UPx5IrVdKcFcWO4wMqBoKlt3rpkc+dhs9Q QoVZMUAODJHE0R3GF1C59lHGjmkQBcmKAniwEGvgcrWgTGv7pzw6quimhnfojkMsBybM+jEExxpX i+uYRgKRsCOcRNyBioW+6o68Rpqr14GbBaZtBBtLMVYhSVbDGqih6wwd108fhePGUQIwuqrSANFj pvIg0gSruDC8F/ZQIE8yQk8pDpSUxwjqwFAPn+YFGMiD3KgVqxQM69PG8G65exxI1A5GP8UqWAMV xMirDLoTc1O3uSjhHHPAahnZCL0cGIxTqkpWunC1IKqp6gerdbfFUE2lIt0zWqmoq+GvV5TgO8+g BN95eSQjove6oxUD/6vCXoxHsPCkVKuVPtSdSraCCrc0dF3R52qxdvEJux39sGeXP+0Va0kn1Ogx 3eiMou3iWdnR2fb5gYLTqsU08/l39847nb13ar7wGcf9pbqGi+BH6cZ1QlZWssXhwvWV+1yo0pSj MBEpVyVdtXbqnL9sIruItEbn1/RzYeZvOkUiJO4c92sVLpOPJ5z7zkCC86TUBpihCrOeg7VbTk8U rvE7/FVVgk9Awkptmtrrapx7W90PM/dpT0JP6lohvKp/WRxyPtvOVIVcLzWd/lxOPc+nSSGE34+b 8/d+1E3QJ5QraB4P0LTIWGXpjgjlQ96pohiDfkgN0CC7qEQXS3KzrLpuUt3dh8GaxfzJfC6XDSXF DQ0hwvAUBqcoEUQoafqSfmjAmbq7bCpxGib3IpKv6nNu9uZHXT+eZCw+OmHsknreduK2upmI6TaP SvD4ZTDgaJ9UTsfD8R0AJQMn/qoW2BbJnhoFCRG5vN341y/RO0Q3E9sydxYfFVhPH3Ji0HpAayF1 q6BNaVyJANLQxyiEyYU13oRmjjiuZ4R4SzLD65rtLD60sZ4naK5GzjhUGBkkpnuNcNYH68klZbkO lxa57hyYkdTcctckYB1TqvB7y9Lzgs/8luc7q/b+/uGBpiB6RtoBxc6N5O7i8yLsrCojx7OhJtpZ jc+i0Dj/mNsqy+EZyMaZxbJ558laeme8yAwzAjvxKImREWx/MfjQ4YQQBr7Rw7Zo9PXR4YMdoQf3 wu7ovAL8XJW62S1ALxLVT63p7b5ELXcNj6dW5RHNQ94V0dg9M9DjRYhIcUiL+LSIoizNJ1509vc7 Z7YKxzhAY12Osp17ieLw2h6kcZ9wDFaFOaathsVUXlTBjFcvN/VzcjocYq8NVmWdwetfA9ETgwYp i82Ud2u7I0C3k6DamSMNPGJcr4RRi6ej1QZ0rQv64za0ETc5Ye5KldmlDeXMLmEqQoKE6Ahw/ABa wrk0XAQYvkh9IhYPgO6kkjU+KJ1cKmDTAoDmHdOaSTAZStcHeEyt39Nk7ySbslkxBWhqQbS2d3Jr 870tw0ZYmMPd9sXFGdFMLIBhKKnwMwoUL1cLh4b2cKWKNawbt95frwFrWMVuTKiUefxLyefnPi0U PE4wqonlJ3Fk2ArFmxC2MYziAVTsXn5vcPj6TtTi/prv/TVZksXlvsauok4mac6GtOkVx1+juI92 V7gpqOwYIO0wv+Zb3ZIfW14oenLxbehTkPnRCTMnfhS7m7Qnai+/RPP1zytih93d49VtrzMXb6YR WY2G8eq20zDxq3AfxMdTEEA4hZUybiNOZSNucsJ/r0T1prtj7dJaLXHxzU8UrzZRpOhcPa+9IOlo tSrumcX0sujxXNfn9bQx7HEr44EfRkHUw/Be6InTu7tY3vuqvJKINxUR1ZXKopKwLnTFVreRnHxv Tv2a8oua2ydoBtsn7EOzK6adLXETBZmq1n9B1+jeR033zeeXqE+xLj0nYJznRODuy74+nfD1kCLr knVdEmJnqy1Ii4LI8cQZGMfiKBDwhMMIoH34etarMeS8XeNXhNGfYfSUVgUS0nOws6anv1e0JzIP svPQeg9iZn2rhb51xJXf6z3SECYJ7QogCNcfgmeBde24nrpWpKwjNzZFwcDzp1DyMgRvhisHoIVK WOdoi5Vtk7mztaNwGuIMjDR3fkCcNOd+4hLI85HVrn5lIh09PtvF7bC61UPddrW6leNKPcsM6B8t ISa/x96upt6uUDuOF2vhu/a0Ml18SyU6OsZ9sfbUXXvm52U3Bm66t7XLTqseTmtP3PgDrF3v+ljz evHNwWus5o3dvp9CWMAEs8uqa6Q4JUHLCx+ob23tc2aW03fVLMHe2dqnoiMWHhNJDPD3iYLZY1ok MGjuhHCoskefUoXLIO5HHQB2hHV3hBxG1iCMpEL/PkyhKKmWOAOoMhnNTbB/q6V/UyX/p5ppba7v V5Y+LWFqYhHsDMmKFA1IgbKi3T4O5ajLdklRpp5VSkCBwB22mgUlSuHot6eVrsPJWx2SN610gBRc a1YrcRuDac7RE53s5eDWCEZIYEoDJ8xn+upiM43KPa1wXOKP66NwuyWFYw8H1mSUztdg7LTwb4t4 OC5P1kDhoGgF5PEqjlzpKYoChI4/OJDLgMeXAzzuIgUrAQxOwzDKDA6EgnyWlO9d1ybemB9p7AEw wmWrWpStoFVUtrqWFM2jAvw58qR4J/vOvQ8+FtYrzc1RG716Om2GbnGtqi7yIu1CrWqEyqmqF+sX Umc0p+rjtxbTLy5L1SBoJ1GRfqEsdYotGOnIa7FaradacVBYC7XaJZdVYEu178IYBdJidDM1spST rRo5LZIXQvhCYvmUGZZ4pApUxdKqkbTIbT3R+drb4nGy2oSEpF0qhJ+aIHOosY6hxt4WR/C1CDUo gu9QBM8Z8jo1tp6q7nJ9t1buC+0tzpDXAKDxtFpxt7gWbmuXXBYy4jRyic1jfHKM86065VtPaRXr VA10am9L/BYliTgNelGMBZuDZidWjeBl5Jucljvn0NH5+ypLlB8Gczq8SR8xUGlWNFwFjh8SA6hZ /Lkcmku7iNeTmRTkz6L/3mf6b6b/bu+9u9hg1TMYWzyIOUTWtL+E6b+Z/tufjchuhGuH984tRk3w Rkh1CnaZYRYE1K1VfIV+iO1qtFsILK7JMJbgokz7cZT1+mrk24vcjPjUGJRZh+EPNP90N5eZd+s7 TsWqtnEWYcHoQhGD3TxhzsIENAJn954Y/Fw7cCZr3evQOtXxnQqoYKVjpRvvHuRRNpfEnsrLZ7q6 fbSA0zT27zJAAv9wgkyKK8ePFQE9t6vGD5w9dpP5zSo08nlsrgZjc4rp6ctZ6yYbEt2u9FrvpaPX mp/+cVVZhsSVkOW0Hp5YjvI0yJbGiVmZaqFMNG5wlqtQ6w+wgWL0lBWpDrWoBdDqQHCyItVBVvuE SoIiffntmrWnBpgWpTtPzXoASsbaUw/tQXRNMR1RnIFXpPU5G9yhusl+qA7SWcgPMZKvFlZvH+Nr pEkoM/hYS/LYOs80+TTrUi3ks5Au7bFXqoPd2wfZLemSno9qKaJb9kh1kMxCWrTPWlQHWe1vHRgt 8jJFWtu6krELwIvTwwoSrtjVoAq0kDodsDrVQ50Op7eTRDdweiLOAplwEdz6Ws6FVOqQVcq+SsE7 XcQxit7XMhliSY/E0h6PdahGbqmA1d45CdaXAUYbyyQKMoWojbrCTxK01LmfZF1k8EyXp59Px7Ze sTey743mQxtgAll7rGuPEIcEPkdKJFz2QOtSrTtgKEM9BnAOCU5OoUIse34CuB3HcDUwaQvkQQeM YaiDBh1hD4d0MVWSPnIAV7vpQgRo4LqBXVObYsEtoGcL803AiLw5gquBuTuiCO4qwjb71HcCcdvH uGcqPnE4V59w7klNYmhqLYR1RPHcuQxJj1DkuZHxve+iY5SmjvuVS9zb9osKC8R2CMrZMdmvcQtx RPhUbONtnUW0odcB3wCtQ2E9Whc9YqRqTbwSkKoXoddKI/WlSJkuqQnB6rQu6sRw1RqoU3t7i0oN ejQ2ill7bGtPG9nrtezKmED4LA7b4hACAoFIigWrLJw6ETRAOEhRL3N6r3vJ4lm1eAInSa9l6MFi eVcAlL5Dve3rfxOFQDqTjuF0OMSf8L+JUwhPRW0ikF0UVIEB6mY0SQ6aNun6Xd9VpG1sB1dkB1+I U/aAOWWZU5Y5ZRdniGNOWZAc9ZlTNucThP8Ec0pM3CE5eSAzqdhgUjlVeDAPc5zgjkUbJI2dLqIS 4dxhuaTijHXylQ0cpKwoSJkZVgrEk0gH9LKnfB8oY1+tt6lOqfNxfnn66eL24vpft1++/Ovd7zf/ I9zAiTnEr9EC+NMtVNYxGgj8niGnDNGgwnfE8sXmzbZ5K7Lmd+h/fHPQROQCYQ0AR+8oRPiEYgYg EueS4GGqZoGZdScYCLDMgyAPOgRalSRNhBN6lZ9i92TdPSkQhfgQJem4tFg4loVzmqV9dKV+Eqee h4mzpIkGrxGJXyNu0s7GlBNWIl1FoZ7EMCfTLiHC8rcqIwD5m0y6/d2k2x+jLPRFvqVOvJGookTx z+xULTvVd3HkeG40YEFYFkRFALBNcRR1QYQA05M+DuXbDfRAg+AmdeJ8jWVulCqWarls7SdXUfz1 qxM44VdQfC90xcDmmbWbFq53RnGws1u59MXDjfO9g72D9diN+HAMKfXwzO+d4O1GN269vy7Wn571 8RGtR/W9txu7u3u07NFRwfXbjU9ncfYXveGhpv12o7Pd3m1tH7W2d2/b7eOd9vH29j83lnjIIAs0 OvQFTrY97MRMM06REJVTNHFt5rAs4WE9Q7b7tZctdTs/yCDxw6++EO8vP7e2t9uH25Vn23QNPai9 FElCUxfU1UILDmv//OYBpCqq8PzIoBYSOFoHCZy890N4TW+hB24Cm4abpr3t2gs2N01Nl1R7bSRV y1Bqr1P75zfPiVwMHD84Fv+mMsxWGCVDZ/D3Hr239f3J/6tMh/Z2ai9ntmgqcd3bfYWS2j98PVDZ OkSee/Wvbswz22OhaIzCzKoxQic3qcQszXkURvdOyJX7pCYbMr/EjhvIygFZPMR9TWbG3MsSCm14 ngp2PU9DD3b3t8U/nBgzmlgjG399cB5ZJpZ7Ke9jP3GjTXErvzmJEAd72zvfW/JnRXn7jDXr8xTl 99An8BtaWCkjd+BDGHTg+v7E4Xr23M+8I2eS3iT2dPDy9ywxr5IfSHvX2CQ0IkBoxE1O1MjsRkHv EP2cAYV+B5AChz+Wwx/ODK5XCIqZCQ/gzAATqzWzU5wZTO3S23UenBkMSVEYjgzusYSwaMmqMoM7 Gf4dzbA0zgacEKjC8mvMShdPCA532xcXZ9RWUg+jznj/GSDAvGRJ91xDU1/JDSZiA/P4l1DJfeJp oYhw8htIHWQAcvh4HALE56fUc7Ipo5mhNjIeQjSPna7nYuht3trJb85ddap+FtLv2cCzBhg1m5Kb eSh3Dv97dxsbYKXwMvGLDGUMzpjfJJp2sVs5qWxf6m5fwEv42PpNJq1PURb4oXSyb+JMevKbOAKX e+fg6HvbS6ybP9ACeNqpz9TN93AY7vc2z1+f0NgC1d0CXfURnR6L/7ez097d6xztd/YOnu1DXmM6 U0vPb/qOFQGB0hBznDG8x1cRq8m7+NJTgz19rBGL4se3G209WZdnn5SKH7V39t4rnGPpgJ7vdI52 DitjeDfpY0ATfWra70P+D5mJv/cvU1d52tyeBCqH2hqoHOrv9HtPTiusFI9ixjD+2G2XDm71k6tS uUKV0HTKO6w8jqvA8UNAQfLBWZMWr+ap5Hn4VAtbvRnTtJjtXao/vub3PtZFrzRscg0oyb364zW4 dwhUYcNyAU8UM1ZSU38hjuZD5mieCshZpwOYWxjaQXlVAIVLBtJoFVbkpPRuyXMOezd/4dMHuKBO Z1eNdPXxeu8QrxV7+7D3yaG/Mo2GeL+9oz2S3+vjb2oDXUcV07soTaPB6GMicR992pcOWOHfbhxs q1HAboSljKNve1mqvjX/nBsF1AfAkIqLGfSD7UN9FV7k/hL7Hj6hHOzKT11c5c6++kO4e33jyqPc Rd6jeoE/khEz68n/FwAAAP//AwBQSwMEFAAGAAgAAAAhADDdQymoBgAApBsAABUAAAB3b3JkL3Ro ZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva 44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP 2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/D WF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJ E2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBs eIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzM rU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a 72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrB pRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/H H6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3z GBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWc d6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTS c/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArM KoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6ax ixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiI NAsQPTMRFb68TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+HiCjeUyhdfP66Q+20t2Zuwe1XlzPaJ Qr0Id7I8d7kI6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkb qCkjN6RpvCXsPUEfBvU6c+IkxSksjeBRZzIwcHChwGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOi Ga6krfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oR zRRFh1uhsjaxOZSDyQvVYLCwJjQ1CFohsPIqnPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uo bpyUx8qcIloPGwz64HiK1UrcWprsG3A7i5PK7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZeb HvJx2vbGcE6GxzgFr0vdR2IWwmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOV hQBLNCcr/3ITzHpRClRUo7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfg fh2qoE9AJVx3mIqgX+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/ KiblL0iVchj/z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/Bfk UP+3OWdpmLSGQ6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRB qJtqkpUBgzsZf+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kR PTFrsxp5VgCz0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI96G2 Ivh4oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7i7/PaeyiOXPZObl4 kcbOLOzY2o4tNDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg6KEHJg8g+S1Hs3Tj LwAAAP//AwBQSwMEFAAGAAgAAAAhAOSZa2cgEgAAbXQAABEAAAB3b3JkL2NvbW1lbnRzLnhtbORd 3W7byBW+L9B3GGhvdgH/kBL1240Wsih1DWTj1Ha6QO9ocWRxQ5EsSVlRr/Y1CrQvt0/S78wMKZKm bVERE6UGWq+joTgzZ87vd84Z//jTp6XLHngYOb73pqGfaQ3GvZlvO979m8aH2+lpr8Gi2PJsy/U9 /qax4VHjp+Gf//TjejDzl0vuxRHDK7xosA5mbxqLOA4G5+fRbMGXVnS2dGahH/nz+AwPn/vzuTPj 52s/tM+bmq6J34LQn/Eownxjy3uwooZ63fLx2/yAe5hr7odLK47O/PD+fGmFH1fBKd4eWLFz57hO vMG7tU7yGv9NYxV6A7Wg03RB9JWBXJD6T/KN8NEuSuaV3zT92YpIIGY8D7mLNfhetHCC7Tb2fRu2 uEiW9PDcJh6WbvLcOtCNR/OlW97lDMzQWuMoti989LoSYtjyS0tX0oHOd3uqxTfq2nObUSdCr0jX sMsS8nMmK1lajpe+Zj/SZIkLifgc/v5r6K+CdDmB83lvu/Q+pu8iwaywMq0jJC+7tajSCx6J7s3C CniDLWeDy3vPD607Fyta6wYjjmwMt8qCrQeO/aYBLbMeWKt44UPafhmHq3/RB7YV42vQDMap1j/V 2rdaf9DSB5r2Dxp1PCd2LBcrlV+gtwb4HKrLvsYrNbPdbXcn9Kj4yORza+XGmRHxjfeh+M9NvHE5 Hn2w3DeNsdRkt/xT3Dgf/niOF8vHxLOh+r3sK9d8zkMoTK6+p561PM+PhTLAA/KN8lU0dzyMN4FP s8RiLozQjOIntBIpFHpM/Uo7B8Wg0F4zxa554Fozzu42A/bH7/+5XYR+HLvQVMyJWMBDsgncxjCL F5yF3JrFNOj5NmfcwWchs0M/COhDC+P/XPEoZn6IX3/j8lknZms8ySyPWQH0VxA64EfGw1A8FgXQ 7Pwv9B3MEnLbCdUX5YzyjbGP7/tiPtOxljzGxGIRMysgqWD+nC1gTeXS47OKXKC3Xzcb4OjHOAYY 3eiP3//LltaG3XHmeCBzEILYNrMips7e98ALVowfKa/EoUUuSFWqt1qvm+q3CwiZojWJDjjfZpA4 Zt1BQkhfMcu990NIzxLcHuNAZu7KxkMOnQG+DA8BPiB7h7H0BRAVnJ3No1no3OFZz19XPpjuqz4Y 8pQHUQC9+KYB9o94+MAbw0siufdREp4OzolcbpFDf8YqqptW/1XTd/iWWw9QL7Fk9ntidMnJFelo vHIFUrDeIyiBwA+FhYYtZDM/BPfCvhKTYixrvEntkEqBqrDs38DqOIN56C9hxVMDC7Xu4ethTJ5A FJBZfuBVdYlhvG5eF0o+sELrPrSCBbN9HgnC+567IYcIP6GxYYBxmETq200gjfDdCjaW3J4Nuxqz 0d/fQ6fPHS+r/f1Sk/uF3Pe4XE1W1YXt5uvmjxEcKzp+cbiIxHyPPDDoxpRT+CcnquzRdl+5aixa axWs8E+Id4QQzVchhRMnFHiEfOk/cLuqauu98nD7BoEYBQZz534VcmZUtN69WiS/OTLGI4Crj9EK NXI0aMUlg03gvCLVdE2vQ2HqU93oCn4ugjxq5GjINoaoUqBk3eGXNBKaudYqAje6cHPsTVVJ1jXB MYdGzi50YzwWCFORqGrkCIiaCArhedq4029pDVrVXmCartcDp/X0fmuUivR7YJvIRPT09kU5Kpl7 /L0AKuVHT5L7PRmFBKaE5lDI5NSnNAzwwWjmAFYe+6vQAfD0jq9pMYuRFz3+dAYgNfugQinpjTXi n9lTnEw7F1OJDte0EbBHufOnVJoE/HKKDURN1pg7PzqS+lY5/PD2+nL88yC3FAkKF73kHNNc59aY LDyLfOceP04eS5ad20vN9L5Z+CvXpljTZo1bARknEamAa0XUo2AsOL4e9LftzASiTxButApEEEQg GNKijFS96+NdJYjYGWMitgIUQ0jxFilT6CTB1bm5Cc70bDztMzIVkVwqPG3EvpBqLCadbkYxM/ni 0jsUGHT6xfXCAeCM7yGeXlkuAjgsAYhc6QvO2HU27o7YDI/R9LRmtXkYs3Tmko3SggPsxYKPRYQJ fKR1BeadUEdulOhps+UKAHzFCZw5UxAuaGavEOdj59hUukEF7MNFblQWpcdS86QafiJf9HIWR9dr QSyVJk0EKbOTjI5VKa2gLI2VmJQaNT8RMwY4KXxJqXg/uKEzW5yxyzhh8siS+Z3c4X0lldy4JPCa QxAgBWuEYJBdCI9AAWPrI+ARGg19mdShpFJOir/f/htyQY/a/tqLYqicJZ7NYFw/CHkQmQpIO8Uq sUM/SufIfI9hCvVPiEEiW8hKccBfAOgFSgYhDtJJswv8IS8hILI8IUT1OervwNStWrJSxrTThpNX wtRqpKp4qi0mVrxMDvZK5+7gYkhOH0DHbtOYOSp/JR63WESpUOSvmbda3vEwt6hdjr4WR7rf0y5M kXsoxiNq5FiOfvgWCTDYMaHURCJMSB1qnxyX2U40W8EE+t4Oft2LW1ZyIFy4l6iQCxMKOj0eAsRL EHjyZVCMwNnCxy5gSSPC16GvEosvFFdq9PE0OAYAu4MsKp5FvikUpp7UG2HEykU6dSj1JxymBAaG PiOUnvSV78El+nXBSWeRrhI5eY9dvb3OLedEJOqz+k7MAL2brmfrhGDJa0r2YgshlWRQ4C22gQ3g M1sVahEKRFs9RSkOZYuVvxAVfLSIozZgno7iHUo7pwpXOIkfPX+NsMtxXUpPCHKIEgSLwQeKndnK tUIx3Ulag7ACHaQ1CChhR4IniGqCixxP+JenP9NZAEcXkB9qDSIf1kDWFLj+zHIZzety+x6fShNF 0wnakUFKbAItUeyr8Jk8qHIyivf5sHdlRAKFYa4FR+QmEespowNxhWISQUGUtKEuUNrNq9C5d7x0 r9vVK+uFDH8EWytJDzc3lmioMLmJhStyTBmaUgifXhSzPTULSVV1u1kLmGOY7Yk2LbWbcmTPLR7c bu5TBqXXk5Ie6V29VQrSqJFvmmZGLfh/32hODeH5PTLScuTbplktoH9b1yamCAGLNFMjx0KznX1a RPw+An3LHeQTql/HoS1fdgNutyo3IKMYpbDD1fiUbAjlrGGVqeBy5ZELkwF0cg7xo001O1pnOhFA dKIeD4TFrgd3QGTXgxX8PlGjShXyLs+XmcZDfzZb5Z32zBoJUVYrTKIoibF99WWH+WxSZs1HskA4 ZtHzR69wfTqjAx89HHb1xifQazDr2gqBEObcsKgU88LLVCExrVT9Cm6gmmK9npqXSa87bZVmk9TI sSi54a8qZFhyC2EPXG2ERrEfMJc/cJfKG6AZfsqxgQyJC05lXRuOhyZ3UdVatoTnz7UWlNFs6y1z XOZYqpGjOdc96uv1dj3O+Fgz9Ysymhly5GhoJipLSpPVZWHVs+zXqSXzP2p1un2zjJRq5GhI+cu2 4vZl5VHXtuJhFmyEYruWTQ8UfhOawcMlAQ7AbRCjC5RKwNBAJQSUgCRUaJ0mIwlOAp1YnRtqEayx 2Wm3SyM2NXIE3FBwusym1hxlfcWFc79w8X80nkgfb8Nd118XfbwrtD1mwMQzmU6M0ayUYk9SeOHD 4pxlhuKOL6wHB1k4m0rvyZbh9yX6OucOcC9rhppbqrZ1q5egVKjYa3d3bt4aN1uGKTilGBmpkSM4 T1oCUlg3Nx8m7LuuzsbXk9HtxCyR8WfVY7cW6zxuNXu6KKZ8REA5cjQE3Mc611PCODa1Xr/UU1Uj R0Cz/08l0qslZdgxtGa31NtSI0dwnlKJ/Aq7SwnlCL1sMv+BNge+LqsfSZW8qLwW+RQoegldnDBR fU8pDvzvNyqpoES0DPPQTku5lqrqqV8P8tVp9jtb9STD/NZYa5dD1W35+K7nlUbMj0wqVa56WYtK EVxNzb15UVWboy2ocP7lxZF9AWt4PElfiT46nOkabTA4dVTx+GuVgclCWgK+slzKOAmP7u+W66Aw aHNqrkJZtAQMSeaekKnKtuchW7RQzETRbgmzFIJddTLJXjO1JhXPLHMQyctyXFGVcOXY3y3yjCfs kgqTqG2UrRV1haxMPgVOuGG3KLdAthFFSbnt49yShRGSZkxbzek2KV3DWpHc8p5cwmfNNxQMIdOL KUtAYyCbKHkGeUuUuaC+SzZs5uhAByUEMUsNc6xNx1t5zrCBGtlVdBM2+DKz4ExpYcqL+67T3deJ 69fSLlbgsQxV1UhVqqr9JgjlIWpeEi74PIa8pstSpJajnG4CTAqxRGoYMZGom6eyRApuhHSidj50 5huZ6Yd1s0TFQuwj2S/FdwHl+Fj15fi8zBwWNNwrZ+2mXku68KKr6+PStLQaOQLWVqpBdq9TrUjI 70URBwXbJ6IdcgKz6od//P5v0R2ZT2NIFYafTyLuzWYt0JhpGqZRCoaokddBWxHJHbo3pjsxxlPh EhfjajVyNLSVmtJ+2XbXtaV4OPafTUaOxkZrlPTtIExBw3bacHzH4dpCxgjWCqjyB5Xqd/BZS7bz rIS1azHMI1M3jdLEvRo5Ii4IuLCsjjenOj7WOeskVrSMN54lZrcWdfUiMZWLIWodv3X6FpyLF/de lZFeNjotvRYEXu90et1tPJTxVdVI1Z3U4KvSElLEttNjV+8n7yoDtoBPKet0aMPSNPWJPJmiYVEj R0O/PQDbVrOWq2OMUbdplgJ8auSbplmrFm3bnxq9aWnaXo0cDc2QoUL+6ubnqw9vTXHhy4Pv4Bap 6pW1rSoVj+2dc1Rau2u2hHtRlFg1cjSUvETFuwhXVp6NK3Ho/tacH1WAtjojo2NMRWryqZKj79cL 6nSSGUpkjz/FP+wQSk9GnWlPcHWRYmqkKsWktSvY1IPPkqJEf/swubm9vHrHbibvbnMU3MHsGrUA 6Z223iuPo9VIVZLWZnb3MRu7VqTp2kBr7Sy4Zk/Tp9vSEYlcmb12c1yacVaP70pIEFAmFF7G94lr vkjyQW2OtrDz4shVur0wB7hoy96hY6lA1Iz/V5F+GaLkscV9N5Ep6wX2l7uQEH2cSaskpd1EGw/u 2kEoKsBx9BYBAJe3RAL8SVqMKVVHr0nqJ6gEQzQbnTC0JD8zHZqvsYLC/ZSwcR6qjXEN6D1/oqCm oOB6ZrMnQ7GiGlUju7JqQmqpveqeJVWjSclEc0+0vSX7DA7tgfcuuiO91DNSI1XJWpsqLWmb3kFC mxed5nRUVjGX37mIs1/acq6nMNUq4YHK3cGQQk8lDIp/5nXBFym3HmauhRiwxiWaI6mjLmf4MysT 9fWSxhlFe2iSQC2XpzazjX7bW9hkTyV/IY/4RchZvmw00VPTBZApIi56QtdoIhU1idt7IMUdFjSM 7hIkrFX5IVNNgds2VXrkqdORVr7bhuqUrm2SBDsQy+7YoUE3U9PlG88v8yueR9pOi2ycsIcgqjyb XHtBekUDYFq6SsSbYRidonQEqDFAy8z2co6ki5jGkmZd9fbSJoWCIXpab+VHjlBvlRrW/KqvJWOq E0+0XMZ9yj9+hJuECqxX3w0/RFzc807Cg5t1NlS/6uDyDLquB3wGDyoRq3JwoMBQeXN3naX1tDlq tkXku//9KA+W50SLzAVaWdCxn/g81G1ONTvsewjNGRPXBd1ZM1zULBvCZ66D5vszRn+0gIlynTPq D3/GCc3csl0o40FJd07fSLbEzyczk622KOY4tIv1ekDiXW+JpMh1d8ipKfmzTEscgnPDQxSEkC7Y guwpv1dkQEOrpexgfGEYWilmp0aOx8ef44JST9zTJftVT2/pZg7Ej0vAdxaqDjYnVL6mkD1RI2jR XcsZhVGZ5rUIfbun40LJsrhDjRwNzW/ltU5UiQuFLBpfoKR5LO5UE5elkQuT3B5yIt1UdSGb8Euf vI+3YIHqIgkQGyr+FdcFy+tDiGHucQEUrqqK0chooSQYrnYLDSRz3ItC17uIK4iiMvT2OQNhaLuX bLeh43b8oz2TZqfTLOUVNXI0vCJAjO+6WmLPK8taLeUpk64+7ZdmYdXI0dBvDzjYqOe622+HZlU7 fw38tS34Cof24r4FgiUukijVnhh6t/dcPmuKXCN1Smz/ahMKTS13KcLZnGSrYCcejuTf/0j+LgIC EGrCZz/n/5JXAR4yMisZUmdlchVmieefm/Zlj92op6zjwmz3NeEWFLFmNXI0CqWycDRr8TC/HYI9 y/RPsvfnce3WpYiG/xMAAAD//wMAUEsDBBQABgAIAAAAIQAiBCFwbwYAAAcWAAARAAAAd29yZC9z ZXR0aW5ncy54bWy0WG1v2zYQ/j5g/8Hw56XmOyVvaSGJ4taiWYe5/QGyxSRCJVGg5Ljpr99Jsupm vRTDhn0yzXu/e3gU75dXn5p69eBCX/n2ek1fkPXKtQdfVu3d9frDe3sVrVf9ULRlUfvWXa8fXb9+ 9fLHH345bXs3DMDWr0BF22+bw/X6fhi67WbTH+5dU/QvfOdaIN760BQD/A13m6YIH4/d1cE3XTFU +6quhscNI0Stz2r89foY2u1ZxVVTHYLv/e0wimz97W11cOefRSL8E7uzpPGHY+PaYbK4Ca4GH3zb 31ddv2hr/q02CPF+UfLwvSAemnrhO1HyPc5zuCcfyi8S/8S9UaAL/uD6HgrU1HO4TVG1X9RQ8Y2i L6l+AanezLY3oyoQp2RaXTzv62/kkWrPVXxb7UMR5jIDAEYvmsP29V3rQ7GvAVQnKtYvAVGfvW9W p23nwgGKBHAkZL0ZCRCMv90NxeCA3Heurid8HmpXtDNH6W6LYz28L/a7wXfA9VCAh5qdFRzui1Ac Bhd2XXEA2cy3Q/D1wlf63/2QASYDpGxWOCN0ND6vdjPaQaItGvB53j0j+MaXbg2kY6i+ScuzaR0F Ji8h+ilK3JCH0xmq0kFotdsNj7Wz4Pyu+uyStnxz7IcKzsSE4//gwfcccO1o+R2c5fePnbOuGI6Q pv/J2FQJW1fdTRWCD6/bEpDwX41tliKO5YRWV/bL4k/vh6UMhEjNkiSfczGyXSiEEMs5SpHa8HMB /yajlWUxKpOKXDKUkqmYnzH7N205odKiMqCLZxiFUikVqo0KwaHnTrB7aocqFWnUa5pILnBtGVeK otosFRqVYVQai+aACRFZ1AMmVCw1ZocpoixaORaRREeoTMwkS1FKIrIEl0llkqK5ZqliNkG1GZpE 8hlKTnE7hhGGa7MsYag2DqWL0bzxjEiCYgcoOkfj4ZmWGvVAEEY4mmsRSctQOyLRzKC5FimNI/T8 iFRpjiJEZMRQXJuROR6pyJlO0LyJXFAcIcJyhiNRWCXxcyopyQ2KUcmIxOORnKcxGo+UhAq0plKx WKEd6fkuJiNKBVptGWud4nagCjmaN2mozHEZw5hE41EAHv0MhVODalNw6gmKNyVplKF4U1LYFM2O klounxVPO5+KqExxOxE3qcFOsEqEEqgHGq6MGO18mnGp0IxqwVSEZkdLFmncTi4yvI9GgsYMrTZQ cvzUR4JZhZ7GKBXjVzpyY0SpTihux4DX6L0Q5TzGqx1TLi3qQcwpS9AcxOC1QDMaRyR9xk7CjEER EkN30bgHlkcR2q9jC3cWmoOEaop3y4QrHaOoSiR8iqA4SLQUHO0uSSZ4guItyaQSaBWAEhGcYqgR qJ0U3gI4QlIicoNqS6Gm+M2UQj/KUFSlSj1zTlNNKX7q00g/55uRMUGrnRHoiSiqMsaFQaudcRZR XBucYPxbbCyPROuTQaAC7TtZKgRBkZilOspxrw2JYjSjmVFSonYM4xy/F4yk3KC4NtBHNa4NMGVR XJuIxjzBeoiJJMvQXJtUswzNtcmIfYZiqI5RJBojDJ7rnBJG0XhyphTeR3Oh8hzNdQ41pQyLNNfU 4mchj+ATFq12Dr2f43Zi+LbEKYlIGe5BomyEZifPpBBofXKrUrwrW8oI3hPBCEnRHmJjYgyKEJtp hn/hW4Ai3uOtJXk6dUt4541XOrzumu04jvkjLKvxybxq5ud2VjT7UBWrm3FgA/dZs92Hj2nVLvS9 g4GV+5qyO+4X4tXVTOiboq4tzBQWwnS0m21Z9Z1xt5Pa+qYIdxe9Z46A7sL84s0XXeP0w4Vfgz92 s7VTKLr5KbyYgwfcWV/VDm+rZtnvj/vdItXC0OUr0rEt3z2EUeHmkp7TdoBZ3TRSeFu0d8uL17VX H3YjK7yc67Ab53nupug6GJ0Ay/6OXq/r6u5+oOMYYIB/Jcz1pj/7O3amsYkG/0ba9Kc4jJEB93kx MsxL4DovLnt82eOXPZhazXzisieXPXnZU8sezBVP23uYWwQYGX2E4cyyHPdvfV37kyt/Wzav199s zUno74vOQV3HGRPAy2+nDSjatLF62LpPMK9yZTXAuLSryqb4NI6v2HQ0z9x18eiPwxPeUdPI3D3Z XZXFUID4VKonwlA6mH899eW0Ld2hAjjuHpv9ZaT10+x4XfXDznUw/Rp8gJCngdPPk+bLBPflXwAA AP//AwBQSwMEFAAGAAgAAAAhAHj5mf7+CQAAYksAABoAAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3Rz LnhtbMxc33ObSBJ+v6r7HyjeHUuyI8euVbYcOd64Krubje265xEaWZyB4QDZ8f7119MDwwgY0SPI 1eVFFjD99c+vR8q0fvn1Rxx5LzzLQ5Es/Om7ie/xJBDrMHla+I8PtycffC8vWLJmkUj4wn/juf/r x3/+45fXq7x4i3jugYAkv3pNg4W/LYr06vQ0D7Y8Zvm7OAwykYtN8S4Q8anYbMKAn76KbH06m0wn +FeaiYDnOaAtWfLCcr8UF7eliZQngLURWcyK/J3Ink5jlj3v0hOQnrIiXIVRWLyB7Mm8EiMW/i5L rkqFTrRCcsmVUqh8qVZkLSs6cNXKGxHsYp4UiHia8Qh0EEm+DdPajGOlgYnbSqWXQ0a8xFH13Gs6 PW/haZMpMbjJ2CuEohbYEtfhjLVaFEfKDzK+dVSbEqeTQ8aUEZEitA4UFfYxK01iFiZazHGuMZ0L 9TAkv3/LxC7V6qThMGl3ybOWJcvSQbPJHCvPNC13EtAq3fstS7nvxcHV3VMiMraKQKPX6bknM9L/ CFSxFsEN37BdVOTybfYtK9+W7/DlViRF7r1esTwIwwegEJAShyDwy3WShz7c4SwvrvOQdd7cyqc6 7wR5YUj7FK5D/1Qi5n+DzBcWLfzZrLqylBrsXYtY8lRd48nJ472pycLXl1Ygd+Gz7OT+Wgo7RTOr V8PcdM94eIeqpCyAygMctik4kBCwmMSJQhnd2QUwmnrzfSedy3aFKEFQAICZYuFtw+PATcBU94qx 4S7ffBXBM1/fF3Bj4SMWXHy8+5aFIgMaXfiXlxITLt7zOPwSrtdcNojy2mOyDdf8X1uePOZ8XV// 6xbpuZQYiF1SgPrzC8yCKF9//hHwVNIkiE6YjPAfcgFwGITDwEGFdmGtjbrQQMWL/6kgpyqGnShb zmRL81D/g0Bo9W4w0ExaZBqAcp10PRsu4ny4iPfDRWDyDvPFxXAtYCMzNCIqN4yspAe1EIFKPtMP Z5cHUlauaGVR74pW0vSuaOVI74pWSvSuaGVA74pWwHtXtOLbu6IVzoMrAobE1cyiM/QGqbAfwiKC PtnDdNOBVFe2Gu8by9hTxtKtJxtrU+1DZHm/WxU0VZFOjyfL+yITcrvZ4xHozrJ0j+bkz3G6ZXkI u/I+oIGuf5BbH++3LITtaw/Ue5V8LZtwY9LZwr5FLOBbEa155j3wHyqiDuv/EN692mX0KjcwrF/D p23hwa5QttxesLnF6XZPKPlfwxx9cLCbzy2m9AknxXBuyUu78N/5OtzFlWsIu5G54nOHMDcgUMXD LjqXIWpXV68VMgAUE1S7cDcB5RP0V83FXb6MMUV/1YqOlE/QXzWuI+VjfhyOrzPT3MDXKh6pvC6c a3cpIpFtdlFVA730cOFcwRqCZoJzEWv5JJK4cK7gPfr0roMAPrlR8tQ5FjWPOqA4h0OhYLHRbXEO SoP2pg4WOQeogTVzwBrGtQ5AzqT7nb+E8ktg12aALK33mr3lfGbxALQg0h76r50o+vfQMwvnUVHu Evi6JOceDe3MUnlUtDKfVL9ziPGwxucANKwDOgANa4UOQJb8sO95dE+kgwxvjg5YzrSsuximHZmZ L5yZWQO5tYCR+iZh/2WpXnsutPsmAcU5QO2+SUBxjk6jl+m+ScAarW8SsCxdwx4jk1NdjHLumyaQ 3gkQLBqHvAlA45A3AWgc8iYADSfvfpDxyJuA5cwNmlNN8iYA4SMuH/U1kEneBCBnblBsV35nVPU9 lHL4w+0I5E1AcQ5Qm7wJKM7RsZE3AQsfccmEBpamOgLWOORNABqHvAlA45A3AWgc8iYAjUPeBKDh 5N0PMh55E7CcuUFzqkneBCBnetBAJnkTgPARF27oJG+s+p9O3gQU5wC1yZuA4hydBqHqTSoByzlA DSxN3gQsfMQlGUosTG4Xo8Yhb4JF45A3AWgc8iYAjUPeBKDh5N0PMh55E7CcuUFzqkneBCBnetBA JnkTgJy5oZO8sRh/OnkTUJwD1CZvAopzdBqEqnmOgOUcoAaWJm8CFubLYPImAOEjxwK5WDQOeRMs Goe8CUDjkDcBaDh594OMR94ELGdu0JxqkjcByJkeNJBJ3gQgZ27oJG+skZ9O3gQU5wC1yZuA4hyd BqFq8iZgOQeogaWpjoA1DnkTgDAxB5M3AQgfOQIIq8glTOOQN8GiccibADScvPtBxiNvApYzN2hO NcmbAORMDxrIJG8CkDM3yHO2cF6UfDx1akkC6jmD6lQDGXBmCRIVsDTwO9/wDKYKef/pkIGAlYUO iJb0oJr4SYhnj3aw+8ySIGSocBWFAo90v+EpHWMQ4eziwCTBw59L74sagGmtw5TaP3kD00PmuBCO J8nBIdCzeEthZCetTpZLaTAgJOe6yhEgnAm9g4GgcqxHLpZzPvAgDlWVl/H/bUtU+BsQcWEbKtgC VgATUQegygPv+gwSHndvAltOxaMi9UhGpWZ5Or7eQ6nn9s5oHtS7kCfBD+iMJ8UP+sjDR1RU2wrC cBaq1KchhGwVqREz+OMuWYOFr+V0lgrm+gdTouD+kkfR7wwH0gqR2h+N+KZQd6cT7IANUStRFCK2 r8/wgDhq0iUA0sFURr2VRtjzJNnFK56Vx82tKSk7B06i7aekOutqSQWqp+267ZWLLhA4zh8meI6/ map4Rx3xR51WDEbs/pQTc60SgvHA5+q6FriEmunLm/1NGMLACLjMDsSYTK4/TC7PbpQY24wi/t9r OaF4rt90TyiW05DwsjfmufCXMDItIjn5/XqFI5zGJZXi9ZRmVZZ/G1OaeA2cDzOlhxJkj0iCXQ75 idOQTd7a96I9NF7t5UZ8OukILemMVl+k7GFBi/8/HKqzeiliORJf99+mB1mSCJg5lROgmd4WdKW5 3Y1D2HDfmx/OZ7fzcxWB0pv1TPB0rm7kRrapa/3Z1l3ypXM6i97wSyGHe7pcYjZPM5cMuXVW2r3U W/umW1q171rvtUNnk7ZD1bV+h1LLt+mKZvqV95Fdh5awgaUMs7vcIe2GeOlg2sFm/N88aPc/I/Py 8pGu5GtZm0CaVv2idbMjPUt8Sob272p6HbpSNixzeB09vUxTbBlWPmNPMsNntU/sfutLsYbPnBwE 2++6yQ6o0u78+8SiSIjuvU55z323YwitvWcvwIZ3hlFg+RMNescDv3Bw9PbngW1FzIzNT30hgJ/l KN9hMtcxGtKaqEzadHAzz83I2ZPc3sXNTDewxk7z5nazdm+52awv/A/8rfdJX+CDdCZd0Po4Ut/p YmG7P+2535vsl9Oz97f726BAjulV7D6Bf7e3Mkfxd1Tw+zH4xRhtAiq6q56WP+YEn31JvNtNGHoU qZlz+gYiwi+QwG+SKHD9VUilheVj2z4tfp7N57OlSrnWRueIKodGgxGuP4jkH/8LAAD//wMAUEsD BBQABgAIAAAAIQBJfSJ/fAkAAHFIAAAPAAAAd29yZC9zdHlsZXMueG1szFzbcts2EH3vTP+Bw/dE N0eOPVE6jhI3nknSJLKnzxAFWWxIQiWpOO7Xd7EgQYgkxIXJdJoXmbc9wO7Zs6CC1avffsSR952n WSiShT95PvY9ngRiEyb3C//u9vrZS9/LcpZsWCQSvvAfeeb/9vrXX149XGb5Y8QzDwwk2WUcLPxd nu8vR6Ms2PGYZc/FnidwcSvSmOVwmN6PYpZ+O+yfBSLeszxch1GYP46m4/HcL8ykFCtiuw0D/lYE h5gnOT4/SnkEFkWS7cJ9Vlp7oFh7EOlmn4qAZxlMOo6UvZiFiTYzOWsYisMgFZnY5s9hMiM1opE0 BY9PxvhXHPleHFze3CciZesInPcwOfNfg+c2InjLt+wQ5Zk8TD+nxWFxhB/XIskz7+GSZUEY3oJL wUAcgq33V0kW+nCFsyy/ykLWenEn72q9EmS5Ye1NuAn9kUTM/gGb31m08KfT8sxSjuDoXMSS+/Ic T57drcyRLHx9ag12Fz5Ln62upLERTrP8NKa7P5o8HOFQ9iyAYAAO2+YcSAEckThRKDk4PQe+qIOv B+lXdshFAYIGAMw0C4c1jwNXgDkrRWC4yrcfRPCNb1Y5XFj4iAUn724+p6FIgaQL/+JCYsLJFY/D 9+Fmw2W+FOfukl244X/ueHKX8U11/ss1kr+wGIhDksPw5+fIgijbvPsR8L2kLZhOmIzwJ/kAEAfC YeDggA5hNRp1ooaKJ/8uIScqhq0oO85khns4/pNAOOtDb6CpnJE5AbTrNNZZfxNn/U286G8CydvP F+f9RwG63jciihsGK+lBzUWgyGf6YXZxgrLyiQaLOp9okKbziQZHOp9oUKLziQYDOp9oBLzziUZ8 O59ohPPkEwFD4aqzaIbeICX2bZhHXD5/UoAmPaWuKDXeZ5ay+5Ttd54srPVhnxLL1WGd04aKcvp0 sVzlqUjuOz0C1Vmm7pM1+V2837EshFVSh+unPV1/K1c93u9puOmEeqHI15gTLkxaS9jniAV8J6IN T71b/kNF1OH5T8JbqVVG5+B6hvVDeL/LvdUOS24n2NzidLsnlP0PYYY+OJlMc8tUuoyTYji38NJu /CPfhIe4dA1hNTJXeu4Q5hoEDvG0i85kiJrZ1TkLGQDKFFS5cJ8C2ieMXxUXd/syxpTxq1L0RPuE 8avC9UT7yI/T8XVWmrfw0uqR0uvcOXeXIhLp9hCVOdApD+fOGawhaFNwTmJtnyQS584ZfCSf3lUQ wJsbhafOsah01AHFORwKBZONPhfnoNRkb+IwI+cA1bCmDlj9tNYByFl0v/LvofxOzLUYoErrtWZn Os8sHoASRFpDfzmIvHsNPbVoHhXlJoGvSzLu0dBmlsyjohV8UvXOIcb9Cp8DUL8K6ADUrxQ6AFn4 YV/z6JpIB+lfHB2wnGVZVzGkHVmZz52VWQO5lYCB6iZh/WXJXjsXmnWTgOIcoGbdJKA4R6dWy3Td JGANVjcJWJaqYY+Rqakuk3KumyaQXgkQZjSMeBOAhhFvAtAw4k0A6i/e3SDDiTcBy1kbtKaa4k0A wltcXvU1kCneBCBnbVBqV3xnVNY9tHL65XYA8SagOAeoKd4EFOfo2MSbgIW3uDChhqWljoA1jHgT gIYRbwLQMOJNABpGvAlAw4g3Aai/eHeDDCfeBCxnbdCaaoo3AchZHjSQKd4EILzFRRtaxRuz/qeL NwHFOUBN8SagOEenJqh6kUrAcg5QDUuLNwELb3EhQ4GF5HaZ1DDiTZjRMOJNABpGvAlAw4g3Aai/ eHeDDCfeBCxnbdCaaoo3AchZHjSQKd4EIGdtaBVvTMafLt4EFOcANcWbgOIcnZqgap0jYDkHqIal xZuAhXzpLd4EILzlqUAuMxpGvAkzGka8CUDDiDcBqL94d4MMJ94ELGdt0JpqijcByFkeNJAp3gQg Z21oFW/MkZ8u3gQU5wA1xZuA4hydmqBq8SZgOQeohqWljoA1jHgTgJCYvcWbAIS3PAEIs8glTMOI N2FGw4g3Aai/eHeDDCfeBCxnbdCaaoo3AchZHjSQKd4EIGdtkPtsYb8oeXvqxEIC6j6DclcDGXBq CRIVsJjgV77lKTRZ8e7dIT0Byxk6IFroQZ3iGyG+ebSN3TMLQchQ4ToKBW7pfsRdOkYjwuz8RCfB 7R9L771qgGk8h5Q63nkD3UNmuxC2J8nGIRhn/riHlp19ubNcWoMGIdnXVbQAYYvcDTQEFW098mHZ 5wM3YlNVcRr/37ZAhb8BER9sQgU7wAqgI+oEVLHhXe9Bwu3udWDLrngcSNWSUQ6z2B1fraHUfUd7 NE+OO5c7wU+MGXeKn/SRh7eoqDYHCM1ZOKSuEULI1pFqMYM/bpINzBCaBPF/zVQwNz+YMgXXlzyK PjJsSMvF3n5rxLe5ujoZYwWsmVqLPBex/fkUN4jjSNoMAB3MwahDOQk7T5JDvOYpdHid8PknISsH dqIdU1LtdbVQgepp+9iO0kUnCGznDxPcx1+nKl5RW/xxTGsGLXZ/yI65RgpBe+C38rw2uISc6eLN 8SIMYaAjVrIDMcbjq5fji9lbZcbWo4gsKjoUz/RBe4di0Q0JH0dtngt/CS2sImKZDBy2cBqnFMWr Ls0yLf8xujTxHDgfekpPEeRISIJDBvzEbsi6bh170R4ar/JyLT6tcoQzaY1WV6TsYcEZ/z8cqlm9 FLFsUa7qb92DLEkE9JzKDtBULwvaaG53Yx81PPbmy7Pp9fxMRaDwZtUTPJmrC5nBNnWum23tKV84 pzXpDb/ksrmnzSVm8TS5ZNitWGn3Umfum25p5L5rvlcOhe6qIqGN9MVz3Q6lpm/dFXX6FddRXfum sIGlJmZ3uQPt+njpJO1gMf4XD5r1z2BeVtzSRr7GbBOgaVkvGhdb6FngUxjavarpdOhazWGZwefg 9DKnYmNYcY+dZIbPKp/Y/dZFsZrPnBwEy++qyPbI0nb+vWFRJET7Wqe45r7aMYxW3rMnYM07/SSw +IkGveKBXzh48vLnlu1EzIzFT3UiyBZ+cVToZplufUoTVUnrDq7z3IycneT2Km4y3cAamub15Wbl 3mKxWZ34D/yt10nv4UU6lS5ovI5UV9pU2O5PO/c7yX4xmb24Pl4GBbJNr6TbGP5dX0uO4u+o4Pdj 8Pswego40EN5t/xRGXj3Jeluu2DoVqQ65/QFRIRfIIHfJFHg+quQchSW17ZjWXw3nc+nS0W5xkLn CVkOhQYjXL2IZK//BQAA//8DAFBLAwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVht bC9fcmVscy9pdGVtMS54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AITPwYoCMQwG4LvgO5Tcnc54EJHpeFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlT NNBUNSiMjnofRwM/5+/VFhSLjb2dKaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2Sg HKyUMo86WXe1I+p1XW90/m1A92GqQ28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2 jygGvGB4t5qq3Au6a/XHf90LAAD//wMAUEsDBBQABgAIAAAAIQArBLs/4gAAAFUBAAAYACgAY3Vz dG9tWG1sL2l0ZW1Qcm9wczEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJyQwWrDMAyG74O+Q9DdtZN2SVvilCZdodexwa6u4ySG2Aq2MzbG3n0OO3XHncQnIX0/Ko8f ZkzelfMaLYd0zSBRVmKrbc/h9eVCdpD4IGwrRrSKg0U4VquHsvWHVgThAzp1DcoksaFjvZ45fJ2K 07bJioLkTdqQbZHvSd1cGHnaMVandb15zPbfkES1jWc8hyGE6UCpl4Mywq9xUjYOO3RGhIiup9h1 WqozytkoG2jGWE7lHPXmzYxQLXl+t59V5+9xiTY7/V/LTd9Gjb0T0/AJtCrpH9XCd6+ofgAAAP// AwBQSwMEFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMAKABjdXN0b21YbWwvaXRlbTEueG1sIKIkACig IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALJJsgrOLy1KTi1WCE7NSU0uSU0JLqnM SbVVinEMcNSLCPZRUgAL+CXmAgWBYkoKFbk5ecVWSbZKGSUlBVb6+sXJGam5icV6+QWpeUC5tPyi 3MQSILcoXT8/LS0zOdUlP7k0NzWvRN/IwMBMPykzKSczP70osSCjEmoYVYyys9GHe8aOlwsAAAD/ /wMAUEsDBBQABgAIAAAAIQC//cGGRwEAAHcCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcklFPwjAUhd9N/A9L37d2oASXbSRieJLERAzG t6a9QOPaNW1h4K+33WCO6JOPt+f0u+feNp8dZRUdwFhRqwKlCUERKFZzobYFelst4imKrKOK06pW UKATWDQrb29ypjNWG3gxtQbjBNjIk5TNmC7QzjmdYWzZDiS1iXcoL25qI6nzpdliTdkn3QIeETLB Ehzl1FEcgLHuieiM5KxH6r2pWgBnGCqQoJzFaZLiH68DI+2fF1pl4JTCnbSf6Rx3yOasE3v30Yre 2DRN0ozbGD5/it+Xz6/tqLFQYVcMUJlzljED1NWmXM7N/ivHg5OwvYpat/SL3gjgj6eL6bcQvAYO IrxQOcrxsPRd2qG6VsAjHzPrhroo6/H8abVA5YikdzF5iMn9ikwzMskI+QiZru6H2N2BPCf7N/EC KNvE11+l/AYAAP//AwBQSwMEFAAGAAgAAAAhADEBs7AsAgAAwAcAABIAAAB3b3JkL2ZvbnRUYWJs ZS54bWy8VF1v2jAUfZ+0/xD5vcQOgRbUULWsSHvZw9T9AGMcYs0fkW1I+fe7jtNUgrEGJhWkCM61 j+49OffcP7wqmey5dcLoApERRgnXzGyE3hbo18vq5g4lzlO9odJoXqADd+hh8fXLfTMvjfYugfva zRUrUOV9PU9TxyquqBuZmmsolsYq6uGv3aaK2t+7+oYZVVMv1kIKf0gzjKeoo7FDWExZCsa/GbZT XPv2fmq5BEajXSVq98bWDGFrjN3U1jDuHMysZORTVOiehuQnREowa5wp/QiGSWNHaaCC6wS3v5RE iWLz71ttLF1L0K4hOVp0wiXNXFMF4JJKsbaiLdRUG8cJ1PZUFghneIUn8AzfHI/DE6WBgVXUOu77 gzjCJVVCHt5Q1wjnYqEWnlVv+J5aERqKJSe2UNi5NS7QM8EYZ6sViggpUA7A47JHMmgqfmbdmXGP gHOgsZanPUJmLQ8gwNPdavtMo3VOlHgRirvkB2+Sn0ZRfUaRDE9BiQnoEZQZX6SIbXlbBYcqAo1n j/38MMkSkNu7nHTzX6RI5BmuyBIMbSR1Z6R4AilmV5pDmQ23+i/uKMUr3wy1xuqzrEEreHX/kCFs R/BE/ik7kj0fO2KKJ0/Hjsg+2hGCyeWO2FnBbdiSM2rcghLRFGE/QJH4LgclxsWmOLcd42Mt8Eda 4Cu0oAqC85wrQj5ET4S8uCw5r8uJ0+TEee+T95xocxLy9n+Ss4tQt/gDAAD//wMAUEsDBBQABgAI AAAAIQBo9xt2gAEAAE0DAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyUU9FOwjAUfTfxH5a+Q7cJ xiwMEkIwJsYYxQ/ouo41tr1NW5jw9V42QBQf4Km3t+ec3ntPO5p8aRWthfMSTE6SfkwiYTiU0ixz 8rGY9x5I5AMzJVNgRE42wpPJ+PZm1GSNKN5FCIj0EaoYn2mekzoEm1HqeS00832wwuBhBU6zgFu3 pJq5z5XtcdCWBVlIJcOGpnF8T/Yy7hIVqCrJxQz4SgsTWj51QqEiGF9L6w9qzSVqDbjSOuDCe+xH q05PM2mOMsngTEhL7sBDFfrYDO0qojsppCdxG2lFIs2zp6UBxwqFE2ySARnj+Eq59vs1ajJZ5iSN h4P0Lh7GaQsooNzM5BoP10yhN4Tu4Di9Z1GFQzY+Zt/ksv4nvQB7jp1CCKD/5LGgael2d4QfjkHX CQL9Nif4NjCwjGMXbcxBAZrFVgG6MtRJZdcxi18VXcd1p51fQ6WtC23TXTgedWtrDNggtdyKObip g8YL1xrAlILm9eURNwg++QTjbwAAAP//AwBQSwMEFAAGAAgAAAAhAG0CkdjzAQAA8AMAABAACAFk b2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPBbtsw DL0P2D8Yvjey07RNAkXFkG7oYVsDxG3PmkwnwmRJkNig2dePshvX2XZaTuQj8fTy+MxvX1uTHSBE 7ewqLydFnoFVrtZ2t8ofqy8X8zyLKG0tjbOwyo8Q81vx8QPfBOchoIaYEYWNq3yP6JeMRbWHVsYJ jS1NGhdaidSGHXNNoxXcOfXSgkU2LYprBq8Itob6wg+Eec+4POD/ktZOJX3xqTp6Eix4Ba03EkF8 T3LMpHbYcjagvHIoTaVbEAXBQ8M3cgdRzBac9RV/dqGOory5vCk56xu+3ssgFZKJYrEoSloeIfyT 90YriWSw+KZVcNE1mD10VmSJgbPxCid7tqBegsZjEjNu+VdtSc58esVZX5LAIHdB+n0U08tpkjn0 fKukgTX5IBppInD2DvB7kOnGG6lJNT/g8gAKXcii/kVXnubZDxkhubfKDzJoaZFcTGt909XGRwyi 0miIm2Z935XjtXGtZ4J8o10qzhcT2Gugwbm67oX40NB/w3+ILcdiOw291JGcUTm88Qfr2rVe2qP4 HLSK0Vk64huSXP8ZH33l7lKC3rw8B0cZeNa433qp6FBleV1ezcdxGA35lmIDNd33RPkO8HtyPpj0 LkXJ7qA+7fw9SAF76j9gUc4mBf26RJ0wysTwZYnfAAAA//8DAFBLAQItABQABgAIAAAAIQAChWeX qgEAAJUGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgA AAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAA4wMAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgA AAAhABYhLnJ4AQAAdwUAABwAAAAAAAAAAAAAAAAABwcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s LnJlbHNQSwECLQAUAAYACAAAACEAyoGXQ0wqAQAgxBEAEQAAAAAAAAAAAAAAAADBCQAAd29yZC9k b2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAMN1DKagGAACkGwAAFQAAAAAAAAAAAAAAAAA8NAEA d29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAOSZa2cgEgAAbXQAABEAAAAAAAAA AAAAAAAAFzsBAHdvcmQvY29tbWVudHMueG1sUEsBAi0AFAAGAAgAAAAhACIEIXBvBgAABxYAABEA AAAAAAAAAAAAAAAAZk0BAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAHj5mf7+CQAA YksAABoAAAAAAAAAAAAAAAAABFQBAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1sUEsBAi0AFAAG AAgAAAAhAEl9In98CQAAcUgAAA8AAAAAAAAAAAAAAAAAOl4BAHdvcmQvc3R5bGVzLnhtbFBLAQIt ABQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAAAONnAQBjdXN0b21YbWwvX3JlbHMv aXRlbTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAKwS7P+IAAABVAQAAGAAAAAAAAAAAAAAAAADp aQEAY3VzdG9tWG1sL2l0ZW1Qcm9wczEueG1sUEsBAi0AFAAGAAgAAAAhAKnIXKqMAAAA2gAAABMA AAAAAAAAAAAAAAAAKWsBAGN1c3RvbVhtbC9pdGVtMS54bWxQSwECLQAUAAYACAAAACEAv/3BhkcB AAB3AgAAEQAAAAAAAAAAAAAAAAAObAEAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEA MQGzsCwCAADABwAAEgAAAAAAAAAAAAAAAACMbgEAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAG AAgAAAAhAGj3G3aAAQAATQMAABQAAAAAAAAAAAAAAAAA6HABAHdvcmQvd2ViU2V0dGluZ3MueG1s UEsBAi0AFAAGAAgAAAAhAG0CkdjzAQAA8AMAABAAAAAAAAAAAAAAAAAAmnIBAGRvY1Byb3BzL2Fw cC54bWxQSwUGAAAAABAAEAAbBAAAw3UBAAAA --_002_087A34937E64E74E848732CFF8354B920980FF4AESESSMB101erics_-- From nobody Fri Sep 5 03:23:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C1F1A067D for ; Fri, 5 Sep 2014 03:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQkLh7ELfAbK for ; Fri, 5 Sep 2014 03:23:21 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388261A063E for ; Fri, 5 Sep 2014 03:23:21 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-58-54098f1648db Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DC.72.02247.61F89045; Fri, 5 Sep 2014 12:23:19 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Fri, 5 Sep 2014 12:23:18 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNkuZbpwAkWLB0yx5uVxu0iwDZvyD7KAgAAiZMD//+WPAIAAO6xg Date: Fri, 5 Sep 2014 10:23:17 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920981005A@ESESSMB101.ericsson.se> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D900066815209DA6@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209DA6@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja54P2eIwfM+Hou5vSvYLNa9XcHk wOSxZMlPJo+f66+yBzBFcdmkpOZklqUW6dslcGXs+H+eueChaUX7tHdMDYzXtboYOTkkBEwk bs2ZzwJhi0lcuLeerYuRi0NI4CijROesGSwQzmJGiZXbIarYBOwkLp1+wQRiiwjES7x884O5 i5GDQ1ggTmLFCROY8My1B9hBwiICbhJ9G/JAwiwCKhJbD+9gBrF5BXwlZny6yAgxfhqTxL0p J9hBEpwCARJ9f1tZQWxGoIO+n1oDtopZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rhK0osfNs OzNEvY7Egt2f2CBsbYllC19DLRaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+em GxnppRZlJhcX5+fp5aWWbGIExsnBLb+tdjAefO54iFGAg1GJh1dBkjNEiDWxrLgy9xCjNAeL kjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw5uucnXjl/ry7rPxbTyQ+N07i0OVc tdekRj1b0Dft19Qgnz+7/R3e9U34m9zu/aDmhfmqJ/2u0zleRq/kLEzurLsgt2jnFbFLoil6 yQyNS+rdHhqL7q7af8VfV/zAj8YlTD+VxJpupf4/tUb6mdWCv2tu7SvhzWDU82hcMcfiinaK 6Ldoo0cvlViKMxINtZiLihMBYOFRf3QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bf8b4WX7TcHsag6TP34qH98Naew Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 10:23:24 -0000 Dear Ulrich, If the reporting node decides to re-send an OLR, it should be because the i= nformation sent keeps being valid. I.e. if reporting node resends "near" 10:00 (in your example) I think it co= uld be considered that same values apply (i.e. same OC-Validity-Duration), = then very same OLR could be sent, then it is a retransmission and the SeqNu= m could remain being the same. Then, reacting node if have already received= the first OLR, it will simply ignore this new message, if not, it will sto= re it as a new OCS. But, if the reporting node wants to send same Reduction-Percentage a bit la= ter, e.g. 10:03, then in my opinion, it should update OC-Validity-Duration,= since the OCS indicates this overload occurrence expires at 10:05 (in this= case, I understand why Expiry Time is required for). Then, OC-Validity-Dur= ation has to be just 2 minutes and then reporting node needs to increase Se= q-Number. Is this the behavior you have in mind? Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 05 de septiembre de 2014 10:43 To: Maria Cruz Bartolome Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Exactly. If the OLR sent at 10:00 contains a duration of 5 minutes and the OLR sent = at 10:01 contains a duration of 4 minutes, the two OLRs are different i.e. = the later is not a replay but an update although it contains the same seque= nce number. My understanding was that OLRs with identical sequence numbers should have = identical content. -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 05, 2014 10:20 AM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; draft-ietf-dime-ovli@to= ols.ietf.org Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Dear Ulrich, Not sure if I understand your point. Is it your intention to send Validity-Duration AVP =3D OCS Validity Duratio= n (in your example 300 s) until timer expires (in your example until 10:05)= ? Could you elaborate a bit further please? Thanks /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 05 de septiembre de 2014 10:15 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Dear Maria Cruz, I do not agree. As an example assume that the reporting node creates an overload state at 1= 0:00 with a duration of 5 minutes. This means that Validity duration is 5 m= inutes and expiry time is 10:05. If only expiration time but not validity duration is stored at the reportin= g node, this will result in the following: For an answer message that is sent immediately (i.e. at 10:00) validity dur= ation will be calculated as 5 minutes (which I think is correct). For an answer message that is sent at 10:01 validity duration will be calcu= lated as 4 minutes, which I think is not correct. The answer message sent a= t 10:01 should contain a replay of the OLR already sent at 10:00, not an up= dated OLR.=20 Therefore validity duration should not be removed from the OCS. Best regards Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:15 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes = - Expiry Time #67: OCS for Reporting Nodes - Expiry Time What does "Validity Duration" mean as the information stored in OCS for R= eporting Nodes? We need to store some information that allow the reporting node to calcul= ate a Validity-Duration value to be included in each OC-OLR AVP Then, I pr= esume we need just Expiry Time, and then value to be included in each Vali= dation-Duration AVP is calculated based on this. Then, original text: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Validity Duration and Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. Editor's note: This statement is unclear and contradictory with other statements. A validity timer of zero seconds indicates that the overload condition has ended and abatement is no longer requested. Proposed modification: 4.2.1.2. Overload Control States for Reporting Nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: o Sequence number o Expiry Time o Algorithm specific input data (e.g. Reduction Percentage for Loss) Expiry Time is used by the reporting node to calculate the value to be included in each Validity-Duration AVP, as part of the overload report. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 5 06:53:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2133E1A06BF for ; Fri, 5 Sep 2014 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBjvvOEjlFhY for ; Fri, 5 Sep 2014 06:53:30 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C30A1A06CC for ; Fri, 5 Sep 2014 06:53:27 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64841 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPtx7-00010P-Gk for dime@ietf.org; Fri, 05 Sep 2014 06:53:26 -0700 Message-ID: <5409C055.4080204@usdonovans.com> Date: Fri, 05 Sep 2014 08:53:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B920980FEF7@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980FEF7@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sEdVML2FmJY17yB0iRUGd7lZoL8 Subject: Re: [Dime] Loss algorithm - clarification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 13:53:31 -0000 Maria Cruz, This is one example of a way that a reacting node could determine if a request is given abatement treatment or allowed to pass through. The calculation of the random number would be done on a per request basis. Assume, for example, that the requested reduction percentage is 20%. For each request controlled by the overload report, a new random number is generated. If the random number is less-than-or-equal-too 20 then the request is rejected. Otherwise the request is routed. This is not normative but rather is an example to explain the loss algorithm. Steve On 9/5/14, 2:34 AM, Maria Cruz Bartolome wrote: > Dear all, > > In clause 5.1, I do not understand following paragraph. > Could someone clarify? > > 4. The reacting node determines if abatement should be applied to > the request. One approach that could be taken would be to select > a random number between 1 and 100. If the random number is less > than the indicated reduction percentage then the request is given > abatement treatment, otherwise the request is given normal > routing treatment. > > Best regards > /MCruz > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Sep 5 06:55:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF22B1A06C3; Fri, 5 Sep 2014 06:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK0DTH1LX6G5; Fri, 5 Sep 2014 06:55:17 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8805A1A06BF; Fri, 5 Sep 2014 06:55:17 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-171.messagelabs.com!1409925315!18701471!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30217 invoked from network); 5 Sep 2014 13:55:15 -0000 Received: from amer-mta102.csc.com (HELO amer-mta112.csc.com) (20.137.2.88) by server-7.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2014 13:55:15 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta112.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s85DtERw031215; Fri, 5 Sep 2014 09:55:14 -0400 In-Reply-To: <087A34937E64E74E848732CFF8354B920980FEF7@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B920980FEF7@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome MIME-Version: 1.0 X-KeepSent: C94A68A7:C1047B45-85257D4A:004BF637; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Fri, 5 Sep 2014 09:55:12 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 09/05/2014 09:55:15 AM, Serialize complete at 09/05/2014 09:55:15 AM Content-Type: multipart/alternative; boundary="=_alternative 004C77E485257D4A_=" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iFEQpHd8IhnkbV7cv7ePXxTJuKM Cc: DiME , "dime@ietf.org" Subject: Re: [Dime] Loss algorithm - clarification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 13:55:19 -0000 This is a multipart message in MIME format. --=_alternative 004C77E485257D4A_= Content-Type: text/plain; charset="US-ASCII" Suppose the overload control algorithm has indicated that 20% of the Diameter traffic should be throttled. Each time the client has a request it would like to transmit, it selects a random number between 1 and 100. If the selected number is 20 or less, it does NOT transmit the request, but instead gives it "abatement treatment" If the selected number is 21 or more, it transmits the request normally. 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: Maria Cruz Bartolome To: "dime@ietf.org" Date: 09/05/2014 03:35 AM Subject: [Dime] Loss algorithm - clarification Sent by: "DiME" Dear all, In clause 5.1, I do not understand following paragraph. Could someone clarify? 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken would be to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. Best regards /MCruz _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --=_alternative 004C77E485257D4A_= Content-Type: text/html; charset="US-ASCII" Suppose the  overload control algorithm has indicated that 20% of the Diameter traffic should be throttled.

Each time the client has a request it would like to transmit, it selects a random number between 1 and 100.
If the selected number is 20 or less, it does NOT transmit the request, but instead gives it "abatement treatment"
If the selected number is 21 or more, it transmits the request normally.

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:        Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To:        "dime@ietf.org" <dime@ietf.org>
Date:        09/05/2014 03:35 AM
Subject:        [Dime]  Loss algorithm - clarification
Sent by:        "DiME" <dime-bounces@ietf.org>



Dear all,

In clause 5.1, I do not understand following paragraph.
Could someone clarify?

  4.  The reacting node determines if abatement should be applied to
      the request.  One approach that could be taken would be to select
      a random number between 1 and 100.  If the random number is less
      than the indicated reduction percentage then the request is given
      abatement treatment, otherwise the request is given normal
      routing treatment.

Best regards
/MCruz

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--=_alternative 004C77E485257D4A_=-- From nobody Fri Sep 5 06:59:11 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05AA1A06C6 for ; Fri, 5 Sep 2014 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHYSuaozLBWR for ; Fri, 5 Sep 2014 06:59:08 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8231A06C3 for ; Fri, 5 Sep 2014 06:59:08 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64894 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPu2b-0005th-F4 for dime@ietf.org; Fri, 05 Sep 2014 06:59:07 -0700 Message-ID: <5409C1A7.5000805@usdonovans.com> Date: Fri, 05 Sep 2014 08:59:03 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/y2XSFGcsL-Hz8kSuYgytFZaR-aw Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 13:59:09 -0000 Ulrich, I think it would be correct for the OLR sent at 10:01 to indicate that the OLR expires in four minutes. A reacting node that has already received the OLR will ignore it because the sequence number is unchanged. A reacting node that has not already received the OLR will treat it as a new report and get the correct expiration time. It is certainly possible to implement it so that the OLR sent to a specific reacting node always gets an exact replay until the report changes or expires but I don't see that as a requirement. Regards, Steve On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: > Dear Ulrich, > > Not sure if I understand your point. > Is it your intention to send Validity-Duration AVP = OCS Validity Duration (in your example 300 s) until timer expires (in your example until 10:05)? > Could you elaborate a bit further please? > > Thanks > /MCruz > > -----Original Message----- > From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] > Sent: viernes, 05 de septiembre de 2014 10:15 > To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolome > Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time > > Dear Maria Cruz, > > I do not agree. > As an example assume that the reporting node creates an overload state at 10:00 with a duration of 5 minutes. This means that Validity duration is 5 minutes and expiry time is 10:05. > If only expiration time but not validity duration is stored at the reporting node, this will result in the following: > For an answer message that is sent immediately (i.e. at 10:00) validity duration will be calculated as 5 minutes (which I think is correct). > For an answer message that is sent at 10:01 validity duration will be calculated as 4 minutes, which I think is not correct. The answer message sent at 10:01 should contain a replay of the OLR already sent at 10:00, not an updated OLR. > > Therefore validity duration should not be removed from the OCS. > > Best regards > Ulrich > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tracker > Sent: Friday, September 05, 2014 9:15 AM > To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com > Cc: dime@ietf.org > Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time > > #67: OCS for Reporting Nodes - Expiry Time > > What does "Validity Duration" mean as the information stored in OCS for Reporting Nodes? > > We need to store some information that allow the reporting node to calculate a Validity-Duration value to be included in each OC-OLR AVP Then, I presume we need just Expiry Time, and then value to be included in each Validation-Duration AVP is calculated based on this. > > Then, original text: > > 4.2.1.2. Overload Control States for Reporting Nodes > > A reporting node maintains per supported Diameter application and per > supported (and eventually selected) Abatement Algorithm an Overload > Control State. > > An Overload Control State may be identified by the pair of > Application-Id and supported Abatement Algorithm. > > The Overload Control State for a given pair of Application and > Abatement Algorithm could include the information: > > o Sequence number > > o Validity Duration and Expiry Time > > o Algorithm specific input data (e.g. Reduction Percentage for > Loss) > > Overload Control States for reporting nodes containing a validity > duration of 0 sec. should not expire before any previously sent > (stale) OLR has timed out at any reacting node. > > Editor's note: This statement is unclear and contradictory with other > statements. A validity timer of zero seconds indicates that the > overload condition has ended and abatement is no longer requested. > > > Proposed modification: > > 4.2.1.2. Overload Control States for Reporting Nodes > > A reporting node maintains per supported Diameter application and per > supported (and eventually selected) Abatement Algorithm an Overload > Control State. > > An Overload Control State may be identified by the pair of > Application-Id and supported Abatement Algorithm. > > The Overload Control State for a given pair of Application and > Abatement Algorithm could include the information: > > o Sequence number > > o Expiry Time > > o Algorithm specific input data (e.g. Reduction Percentage for > Loss) > > Expiry Time is used by the reporting node to calculate the value to be > included in each Validity-Duration AVP, as part of the overload report. > From nobody Fri Sep 5 07:14:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5771A06EE for ; Fri, 5 Sep 2014 07:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiagRYTcGhp5 for ; Fri, 5 Sep 2014 07:14:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E1F1A06ED for ; Fri, 5 Sep 2014 07:14:24 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65030 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPuHM-0002cr-SN for dime@ietf.org; Fri, 05 Sep 2014 07:14:23 -0700 Message-ID: <5409C53C.2000107@usdonovans.com> Date: Fri, 05 Sep 2014 09:14:20 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B920980FF4A@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980FF4A@ESESSMB101.ericsson.se> Content-Type: multipart/alternative; boundary="------------040109000109070707010604" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AG-1KDd4wVNuMRF4zs_Sh7v8VIk Subject: Re: [Dime] OVLI .03 rephrasing, modifications, typos X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:14:25 -0000 This is a multi-part message in MIME format. --------------040109000109070707010604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Maria Cruz, Thanks for the thorough review of the draft. This is is what is needed after the restructuring done in -03. As a reminder to everyone, the most recent version can be found here: https://github.com/jounikor/draft-docdt-dime-ovli We need to use that version going forward to stay in sync. The delta so far from -03 is removal of the "endpoint" concept and the section that described it. I have also included the two paragraphs in the solution overview section that describe host and realm reports. I have taken a similar approach in using a Word document to record needed editorial changes. I had assumed that the best approach was to focus on getting the fundamental behaviors defined before fixing the editorial issues. I'm also assuming that one of the things we do at interim meeting would be a beginning-to-end scrub of the document to handle the editorial issues. Regards, Steve On 9/5/14, 3:27 AM, Maria Cruz Bartolome wrote: > Dear all > > I have included some modification proposals directly into the .03 version .doc, either with comments and/or direct modification in the text. > > There are different types of comments/changes: > - I marked in green what I already opened as a ticket, or sent as an individual question. > - I marked in yellow some parts that are pending a discussion that is focused on agent behavior. > - I included some comments made by Ulrich already, and even some agreement attempt we reached by email. > - the rest of comments include rephrasing, clarifications, typos... what I hope could be agreeable without open a ticket for them. If any of those comments is not directly agreeable, and discussion is started, then I will happily open a new ticket. > > In general, in the doc there are lot of repetitions that we should avoid. In fact, some parts are repeated even in Non-normative and normative parts. I suggest this is considered for next editing phase. > > Best regards > /MCruz > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------040109000109070707010604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Maria Cruz,

Thanks for the thorough review of the draft.  This is is what is needed after the restructuring done in -03.

As a reminder to everyone, the most recent version can be found here:

https://github.com/jounikor/draft-docdt-dime-ovli

We need to use that version going forward to stay in sync.

The delta so far from -03 is removal of the "endpoint" concept and the section that described it.  I have also included the two paragraphs in the solution overview section that describe host and realm reports.

I have taken a similar approach in using a Word document to record needed editorial changes.  I had assumed that the best approach was to focus on getting the fundamental behaviors defined before fixing the editorial issues. 

I'm also assuming that one of the things we do at interim meeting would be a beginning-to-end scrub of the document to handle the editorial issues.

Regards,

Steve

On 9/5/14, 3:27 AM, Maria Cruz Bartolome wrote:
Dear all

I have included some modification proposals directly into the .03 version .doc, either with comments and/or direct modification in the text. 

There are different types of comments/changes:
- I marked in green what I already opened as a ticket, or sent as an individual question.
- I marked in yellow some parts that are pending a discussion that is focused on agent behavior.
- I included some comments made by Ulrich already, and even some agreement attempt we reached by email.
- the rest of comments include rephrasing, clarifications, typos... what I hope could be agreeable without open a ticket for them. If any of those comments is not directly agreeable, and discussion is started, then I will happily open a new ticket.

In general, in the doc there are lot of repetitions that we should avoid. In fact, some parts are repeated even in Non-normative and normative parts. I suggest this is considered for next editing phase.

Best regards
/MCruz




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

--------------040109000109070707010604-- From nobody Fri Sep 5 07:16:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190B51A06EF for ; Fri, 5 Sep 2014 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlxffA8pHVtL for ; Fri, 5 Sep 2014 07:16:11 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7611A06EE for ; Fri, 5 Sep 2014 07:16:11 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65034 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPuJ3-0004Ut-2S; Fri, 05 Sep 2014 07:16:05 -0700 Message-ID: <5409C5A4.5090203@usdonovans.com> Date: Fri, 05 Sep 2014 09:16:04 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org, draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> In-Reply-To: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZLOOIRW39W-PJ6Qv3DYfTxAYpFQ Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:16:12 -0000 I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the value > of peer identity associated with the connection used to send the request > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > From nobody Fri Sep 5 07:24:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36FE1A0707 for ; Fri, 5 Sep 2014 07:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gi_7K7KOyTAj for ; Fri, 5 Sep 2014 07:24:50 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CBC1A0702 for ; Fri, 5 Sep 2014 07:24:50 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65090 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPuRT-0005K4-AT; Fri, 05 Sep 2014 07:24:48 -0700 Message-ID: <5409C7AE.5080403@usdonovans.com> Date: Fri, 05 Sep 2014 09:24:46 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org, draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com References: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> In-Reply-To: <075.42ce9b1c1c8c40b23a5717c66ad4bd65@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iRzrJhtnH8FzZTBwejFp3h2cUJo Subject: Re: [Dime] [dime] #71 (draft-ietf-dime-ovli): Active overload report even if OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:24:51 -0000 I agree to the proposed change. Steve On 9/5/14, 2:57 AM, dime issue tracker wrote: > #71: Active overload report even if OC-OLR is not received > > Answer message may not include OC-OLR and still the reporting node be > overloaded, since it is considered as "no change", as documented in > 4.2.1.3: > > Reacting nodes do not delete an OCS when receiving an answer message > that does not contain an OC-OLR AVP (i.e. absence of OLR means "no > change"). > > > Original text: > > 4.1.1. Reacting Node Behavior (Normative) > ... > Note that the loss abatement algorithm is the only feature > described in this document and it does not require action to be > taken by the reacting node except when the answer message also has > an overload report. This behavior is described in Section 4.2 and > Section 5. > > Proposed text: > > 4.1.1. Reacting Node Behavior (Normative) > ... > Note that the loss abatement algorithm is the only feature > described in this document and it does not require action to be > taken by the reacting node except when there is an active overload > report. This behavior is described in Section 4.2 and > Section 5. > From nobody Fri Sep 5 07:30:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855761A06E4 for ; Fri, 5 Sep 2014 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM2pSVSWHmno for ; Fri, 5 Sep 2014 07:30:51 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A2D1A06FA for ; Fri, 5 Sep 2014 07:30:51 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65116 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPuXE-0002Un-CA; Fri, 05 Sep 2014 07:30:48 -0700 Message-ID: <5409C913.7080103@usdonovans.com> Date: Fri, 05 Sep 2014 09:30:43 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org, draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> In-Reply-To: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tLGLexklTRMLiOiamvBmQZgS_Ak Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:30:52 -0000 Maria Cruz, I'm not sure I agree with this proposed change. The wording to indicate that absence of an overload report was to handle unusual situations. Your proposed wording implies that it is acceptable for a reporting node to not include the OLR in every answer message. I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node. Regards, Steve On 9/5/14, 3:03 AM, dime issue tracker wrote: > #72: Reporting Node Behaviour when OC-OLR is not received > > A clarification is required to consider that an answer message may not > include OC-OLR and still the reporting node be overloaded, since it is > considered as "no change", as documented in 4.2.1.3: > > Reacting nodes do not delete an OCS when receiving an answer message > that does not contain an OC-OLR AVP (i.e. absence of OLR means "no > change"). > > > Original text: > > 5.3. Reporting Node Behavior (Normative) > > The method a reporting nodes uses to determine the amount of traffic > reduction required to address an overload condition is an > implementation decision. > > When a reporting node that has selected the loss abatement algorithm > determines the need to request a traffic reduction it must include an > OC-OLR AVP in all response messages. > > > Proposed addition: > > > 5.3. Reporting Node Behavior (Normative) > > The method a reporting nodes uses to determine the amount of traffic > reduction required to address an overload condition is an > implementation decision. > > When a reporting node that has selected the loss abatement algorithm > determines the need to request a traffic reduction it must include an > OC-OLR AVP in all response messages. OC-OLR AVP is not included when > reporting node expectations on traffic reduction are not modified. That > is, if OC-OLR AVP is not included it is interpreted as “no changeâ€. > From nobody Fri Sep 5 07:31:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E231A0701; Fri, 5 Sep 2014 07:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EvV4kyKDiyn; Fri, 5 Sep 2014 07:30:55 -0700 (PDT) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0681A0702; Fri, 5 Sep 2014 07:30:55 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-8.tower-170.messagelabs.com!1409927452!11565360!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10472 invoked from network); 5 Sep 2014 14:30:53 -0000 Received: from amer-mta102.csc.com (HELO amer-mta112.csc.com) (20.137.2.88) by server-8.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Sep 2014 14:30:53 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta112.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s85EUohi018396; Fri, 5 Sep 2014 10:30:51 -0400 In-Reply-To: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> To: dime@ietf.org MIME-Version: 1.0 X-KeepSent: 09943392:89BD06EC-85257D4A:004F2B46; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Fri, 5 Sep 2014 10:30:48 -0400 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 09/05/2014 10:30:52 AM, Serialize complete at 09/05/2014 10:30:52 AM Content-Type: multipart/alternative; boundary="=_alternative 004FBA9B85257D4A_=" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sKLhl2ppCBVl36_79tCdRHgV5Sg Cc: DiME , draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatement algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:31:03 -0000 This is a multipart message in MIME format. --=_alternative 004FBA9B85257D4A_= Content-Type: text/plain; charset="US-ASCII" The proposed modifications lead to some rather long and awkward sentences. For the same meaning, how about 4.2.3 ... Both reacting and reporting node MUST share the default abatement algorithm (loss). Therefore the DOIC can always be enabled between these two endpoints at least with the default algorithm. ... 6.1 ... Both reacting and reporting node MUST share the default abatement algorithm (loss). Therefore the DOIC can always be enabled between these two endpoints at least with the default algorithm. 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: "dime issue tracker" To: draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Date: 09/05/2014 03:36 AM Subject: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm Sent by: "DiME" #68: Loss as the common abatemen algorithm Some text is misleading since it may imply that one feature shall be in common between reporting and reacting node to progress, but in reality we only need to have one common abatement algorithm, and in this draft, LOSS is defined as default, then there is always one common algorithm Corrections are required in following clauses: Original text: 4.2.3. Reporting Node Behavior (Normative) ... The operation on the reporting node is straight forward. The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. If the reporting node shares at least one common feature with the reacting node, then the DOIC can be enabled between these two endpoints. See Section 4.1 for further discussion on the capability and feature announcement between two endpoints. Proposed modification: 4.2.3. Reporting Node Behavior (Normative) ... The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Features AVP as part of any Diameter request message. Both reacting and reporting node MUST share at least one abatement algorithm, in fact, they share at least the loss algorithm, that is defined in this document as the default abatement algorithm, then the DOIC can always be enabled between these two endpoints at least with the default algorithm. See Section 4.1 for further discussion on the capability and feature announcement between two endpoints. Original text: 6.1. OC-Supported-Features AVP ... During the message exchange the overload control endpoints express their common set of supported capabilities. The reacting node includes the OC-Supported-Features AVP that announces what it supports. The reporting node that sends the answer also includes the OC-Supported-Features AVP that describes the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. At least one of the announced capabilities MUST match. If there is no single matching capability the reacting node MUST act as if it does not implement DOIC and cease inserting any DOIC related AVPs into any Diameter messages with this specific reacting node. Editor's note: The last sentence conflicts with the last sentence two paragraphs up. In reality, there will always be at least one matching capability as all nodes supporting DOIC must support the loss algorithm. Suggest removing the last sentence. Proposed text: 6.1. OC-Supported-Features AVP ... During the message exchange the overload control endpoints express their common set of supported capabilities. The reacting node includes the OC-Supported-Features AVP that announces what it supports. The reporting node that sends the answer also includes the OC-Supported-Features AVP that describes the capabilities it supports. The set of capabilities advertised by the reporting node depends on local policies. Both reacting and reporting node MUST share at least one abatement algorithm, in fact, they share at least the loss algorithm, that is defined in this document as the default abatement algorithm, then the DOIC can always be enabled between these two endpoints at least with the default algorithm. See Section 4.1 for further discussion on the capability and feature announcement between two endpoints. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --=_alternative 004FBA9B85257D4A_= Content-Type: text/html; charset="US-ASCII" The proposed modifications lead to some rather long and awkward sentences.  For the same meaning, how about

4.2.3
 
...
 Both reacting and reporting node MUST share the default abatement algorithm (loss).
 Therefore the DOIC can always be enabled between these two endpoints at least with
the default algorithm.
...

6.1

...
 Both reacting and reporting node MUST share the default abatement algorithm (loss).
Therefore the DOIC can always be enabled between these two endpoints
at least with the default algorithm.

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:        "dime issue tracker" <trac+dime@zinfandel.tools.ietf.org>
To:        draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com
Cc:        dime@ietf.org
Date:        09/05/2014 03:36 AM
Subject:        [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm
Sent by:        "DiME" <dime-bounces@ietf.org>



#68: Loss as the common abatemen algorithm

Some text is misleading since it may imply that one feature shall be in
common between reporting and reacting node to progress, but in reality we
only need to have one common abatement algorithm, and in this draft, LOSS
is defined as default, then there is always one common algorithm

Corrections are required in following clauses:

Original text:

4.2.3.  Reporting Node Behavior (Normative)

  ...

   The operation on the reporting node is straight forward.  The
   reporting node learns the capabilities of the reacting node when it
   receives the OC-Supported-Features AVP as part of any Diameter
   request message.  If the reporting node shares at least one common
   feature with the reacting node, then the DOIC can be enabled between
   these two endpoints.  See Section 4.1 for further discussion on the
   capability and feature announcement between two endpoints.


Proposed modification:

4.2.3.  Reporting Node Behavior (Normative)

   ...

   The
   reporting node learns the capabilities of the reacting node when it
   receives the OC-Supported-Features AVP as part of any Diameter
   request message.  Both reacting and reporting node MUST share at least
one abatement algorithm, in fact, they share at least the loss algorithm,
that is defined in this document as the default abatement algorithm, then
the DOIC can always be enabled between these two endpoints at least with
the default algorithm.  See Section 4.1 for further discussion on the
   capability and feature announcement between two endpoints.



Original text:

6.1.  OC-Supported-Features AVP

  ...

   During the message exchange the overload control endpoints express
   their common set of supported capabilities.  The reacting node
   includes the OC-Supported-Features AVP that announces what it
   supports.  The reporting node that sends the answer also includes the
   OC-Supported-Features AVP that describes the capabilities it
   supports.  The set of capabilities advertised by the reporting node
   depends on local policies.  At least one of the announced
   capabilities MUST match.  If there is no single matching capability
   the reacting node MUST act as if it does not implement DOIC and cease
   inserting any DOIC related AVPs into any Diameter messages with this
   specific reacting node.

      Editor's note: The last sentence conflicts with the last sentence
      two paragraphs up.  In reality, there will always be at least one
      matching capability as all nodes supporting DOIC must support the
      loss algorithm.  Suggest removing the last sentence.


Proposed text:

6.1.  OC-Supported-Features AVP

  ...

   During the message exchange the overload control endpoints express
   their common set of supported capabilities.  The reacting node
   includes the OC-Supported-Features AVP that announces what it
   supports.  The reporting node that sends the answer also includes the
   OC-Supported-Features AVP that describes the capabilities it
   supports.  The set of capabilities advertised by the reporting node
   depends on local policies. Both reacting and reporting node MUST share
at least one abatement algorithm, in fact, they share at least the loss
algorithm, that is defined in this document as the default abatement
algorithm, then the DOIC can always be enabled between these two endpoints
at least with the default algorithm.  See Section 4.1 for further
discussion on the capability and feature announcement between two
endpoints.

--
-------------------------------------+-------------------------------------
Reporter:                           |      Owner:  draft-ietf-dime-
 maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
    Type:  defect                   |     Status:  new
Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/68>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--=_alternative 004FBA9B85257D4A_=-- From nobody Fri Sep 5 07:43:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD41A06FB for ; Fri, 5 Sep 2014 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH96S8G64OKK for ; Fri, 5 Sep 2014 07:42:59 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F661A06F6 for ; Fri, 5 Sep 2014 07:42:59 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65180 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPuj0-00067J-GM; Fri, 05 Sep 2014 07:42:56 -0700 Message-ID: <5409CBEE.9070607@usdonovans.com> Date: Fri, 05 Sep 2014 09:42:54 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org, draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> In-Reply-To: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sfVIc4bwkuR2PTmcQ0Y9R4GKMG8 Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:43:00 -0000 Maria Cruz, I support the need for these changes. I have a proposal for alternative wording below. Regards, Steve On 9/5/14, 2:30 AM, dime issue tracker wrote: > #68: Loss as the common abatemen algorithm > > Some text is misleading since it may imply that one feature shall be in > common between reporting and reacting node to progress, but in reality we > only need to have one common abatement algorithm, and in this draft, LOSS > is defined as default, then there is always one common algorithm > > Corrections are required in following clauses: > > Original text: > > 4.2.3. Reporting Node Behavior (Normative) > > ... > > The operation on the reporting node is straight forward. The > reporting node learns the capabilities of the reacting node when it > receives the OC-Supported-Features AVP as part of any Diameter > request message. If the reporting node shares at least one common > feature with the reacting node, then the DOIC can be enabled between > these two endpoints. See Section 4.1 for further discussion on the > capability and feature announcement between two endpoints. > > > Proposed modification: > > 4.2.3. Reporting Node Behavior (Normative) > > ... > > The > reporting node learns the capabilities of the reacting node when it > receives the OC-Supported-Features AVP as part of any Diameter > request message. Both reacting and reporting node MUST share at least > one abatement algorithm, in fact, they share at least the loss algorithm, > that is defined in this document as the default abatement algorithm, then > the DOIC can always be enabled between these two endpoints at least with > the default algorithm. See Section 4.1 for further discussion on the > capability and feature announcement between two endpoints. SRD> I propose the following wording: The reporting node learns the capabilities of the reacting node when it receives the OC-Supported-Featuers AVP as part of any Diameter request message. At a minimum, the reacting node and reporting node must both the loss abatement algorithm defined in this document and, as a result, DOIC can always be enabled between these two endpoints. See Section 4.1 ... > > > > Original text: > > 6.1. OC-Supported-Features AVP > > ... > > During the message exchange the overload control endpoints express > their common set of supported capabilities. The reacting node > includes the OC-Supported-Features AVP that announces what it > supports. The reporting node that sends the answer also includes the > OC-Supported-Features AVP that describes the capabilities it > supports. The set of capabilities advertised by the reporting node > depends on local policies. At least one of the announced > capabilities MUST match. If there is no single matching capability > the reacting node MUST act as if it does not implement DOIC and cease > inserting any DOIC related AVPs into any Diameter messages with this > specific reacting node. > > Editor's note: The last sentence conflicts with the last sentence > two paragraphs up. In reality, there will always be at least one > matching capability as all nodes supporting DOIC must support the > loss algorithm. Suggest removing the last sentence. > > > Proposed text: > > 6.1. OC-Supported-Features AVP > > ... > > During the message exchange the overload control endpoints express > their common set of supported capabilities. The reacting node > includes the OC-Supported-Features AVP that announces what it > supports. The reporting node that sends the answer also includes the > OC-Supported-Features AVP that describes the capabilities it > supports. The set of capabilities advertised by the reporting node > depends on local policies. Both reacting and reporting node MUST share > at least one abatement algorithm, in fact, they share at least the loss > algorithm, that is defined in this document as the default abatement > algorithm, then the DOIC can always be enabled between these two endpoints > at least with the default algorithm. See Section 4.1 for further > discussion on the capability and feature announcement between two > endpoints. > SRD> I propose the following: ... Both the reacting and reporting nodes must support the loss abatement algorithm defined in this document. As a result, DOIC behavior can always be enabled between the reacting and reporting nodes. See Section 4.1 ... From nobody Fri Sep 5 07:46:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807101A02D1 for ; Fri, 5 Sep 2014 07:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCUEvzAuMDjZ for ; Fri, 5 Sep 2014 07:46:36 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA441A06F6 for ; Fri, 5 Sep 2014 07:46:36 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65209 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPumT-0001AX-Ow for dime@ietf.org; Fri, 05 Sep 2014 07:46:36 -0700 Message-ID: <5409CCC5.5010202@usdonovans.com> Date: Fri, 05 Sep 2014 09:46:29 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030506070708080105020802" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NYI2rWyd84iPecoubLrsqWW6GvQ Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatement algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:46:38 -0000 This is a multi-part message in MIME format. --------------030506070708080105020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Janet, These are similar to what I just sent. One difference is that these still use the endpoint concept that has been purged from the document. It now uses the term "DOIC node" or explicitly refers to reacting node and/or reporting node. Otherwise, your suggestions looks good. Steve On 9/5/14, 9:30 AM, Janet P Gunn wrote: > The proposed modifications lead to some rather long and awkward > sentences. For the same meaning, how about > > 4.2.3 > > ... > Both reacting and reporting node MUST share the default abatement > algorithm (loss). > Therefore the DOIC can always be enabled between these two endpoints > at least with > the default algorithm. > ... > > 6.1 > > ... > Both reacting and reporting node MUST share the default abatement > algorithm (loss). > Therefore the DOIC can always be enabled between these two endpoints > at least with the default algorithm. > > 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: "dime issue tracker" > To: draft-ietf-dime-ovli@tools.ietf.org, > maria.cruz.bartolome@ericsson.com > Cc: dime@ietf.org > Date: 09/05/2014 03:36 AM > Subject: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common > abatemen algorithm > Sent by: "DiME" > ------------------------------------------------------------------------ > > > > #68: Loss as the common abatemen algorithm > > Some text is misleading since it may imply that one feature shall be in > common between reporting and reacting node to progress, but in reality we > only need to have one common abatement algorithm, and in this draft, LOSS > is defined as default, then there is always one common algorithm > > Corrections are required in following clauses: > > Original text: > > 4.2.3. Reporting Node Behavior (Normative) > > ... > > The operation on the reporting node is straight forward. The > reporting node learns the capabilities of the reacting node when it > receives the OC-Supported-Features AVP as part of any Diameter > request message. If the reporting node shares at least one common > feature with the reacting node, then the DOIC can be enabled between > these two endpoints. See Section 4.1 for further discussion on the > capability and feature announcement between two endpoints. > > > Proposed modification: > > 4.2.3. Reporting Node Behavior (Normative) > > ... > > The > reporting node learns the capabilities of the reacting node when it > receives the OC-Supported-Features AVP as part of any Diameter > request message. Both reacting and reporting node MUST share at least > one abatement algorithm, in fact, they share at least the loss algorithm, > that is defined in this document as the default abatement algorithm, then > the DOIC can always be enabled between these two endpoints at least with > the default algorithm. See Section 4.1 for further discussion on the > capability and feature announcement between two endpoints. > > > > Original text: > > 6.1. OC-Supported-Features AVP > > ... > > During the message exchange the overload control endpoints express > their common set of supported capabilities. The reacting node > includes the OC-Supported-Features AVP that announces what it > supports. The reporting node that sends the answer also includes the > OC-Supported-Features AVP that describes the capabilities it > supports. The set of capabilities advertised by the reporting node > depends on local policies. At least one of the announced > capabilities MUST match. If there is no single matching capability > the reacting node MUST act as if it does not implement DOIC and cease > inserting any DOIC related AVPs into any Diameter messages with this > specific reacting node. > > Editor's note: The last sentence conflicts with the last sentence > two paragraphs up. In reality, there will always be at least one > matching capability as all nodes supporting DOIC must support the > loss algorithm. Suggest removing the last sentence. > > > Proposed text: > > 6.1. OC-Supported-Features AVP > > ... > > During the message exchange the overload control endpoints express > their common set of supported capabilities. The reacting node > includes the OC-Supported-Features AVP that announces what it > supports. The reporting node that sends the answer also includes the > OC-Supported-Features AVP that describes the capabilities it > supports. The set of capabilities advertised by the reporting node > depends on local policies. Both reacting and reporting node MUST share > at least one abatement algorithm, in fact, they share at least the loss > algorithm, that is defined in this document as the default abatement > algorithm, then the DOIC can always be enabled between these two endpoints > at least with the default algorithm. See Section 4.1 for further > discussion on the capability and feature announcement between two > endpoints. > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-dime- > maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: > Component: draft-ietf-dime-ovli | Version: > Severity: Active WG Document | Keywords: > -------------------------------------+------------------------------------- > > Ticket URL: > 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 --------------030506070708080105020802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Janet,

These are similar to what I just sent.  One difference is that these still use the endpoint concept that has been purged from the document.  It now uses the term "DOIC node" or explicitly refers to reacting node and/or reporting node.

Otherwise, your suggestions looks good.

Steve

On 9/5/14, 9:30 AM, Janet P Gunn wrote:
The proposed modifications lead to some rather long and awkward sentences.  For the same meaning, how about

4.2.3
 
...
 Both reacting and reporting node MUST share the default abatement algorithm (loss).
 Therefore the DOIC can always be enabled between these two endpoints at least with
the default algorithm.
...

6.1

...
 Both reacting and reporting node MUST share the default abatement algorithm (loss).
Therefore the DOIC can always be enabled between these two endpoints
at least with the default algorithm.

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:        "dime issue tracker" <trac+dime@zinfandel.tools.ietf.org>
To:        draft-ietf-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com
Cc:        dime@ietf.org
Date:        09/05/2014 03:36 AM
Subject:        [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm
Sent by:        "DiME" <dime-bounces@ietf.org>



#68: Loss as the common abatemen algorithm

Some text is misleading since it may imply that one feature shall be in
common between reporting and reacting node to progress, but in reality we
only need to have one common abatement algorithm, and in this draft, LOSS
is defined as default, then there is always one common algorithm

Corrections are required in following clauses:

Original text:

4.2.3.  Reporting Node Behavior (Normative)

  ...

   The operation on the reporting node is straight forward.  The
   reporting node learns the capabilities of the reacting node when it
   receives the OC-Supported-Features AVP as part of any Diameter
   request message.  If the reporting node shares at least one common
   feature with the reacting node, then the DOIC can be enabled between
   these two endpoints.  See Section 4.1 for further discussion on the
   capability and feature announcement between two endpoints.


Proposed modification:

4.2.3.  Reporting Node Behavior (Normative)

   ...

   The
   reporting node learns the capabilities of the reacting node when it
   receives the OC-Supported-Features AVP as part of any Diameter
   request message.  Both reacting and reporting node MUST share at least
one abatement algorithm, in fact, they share at least the loss algorithm,
that is defined in this document as the default abatement algorithm, then
the DOIC can always be enabled between these two endpoints at least with
the default algorithm.  See Section 4.1 for further discussion on the
   capability and feature announcement between two endpoints.



Original text:

6.1.  OC-Supported-Features AVP

  ...

   During the message exchange the overload control endpoints express
   their common set of supported capabilities.  The reacting node
   includes the OC-Supported-Features AVP that announces what it
   supports.  The reporting node that sends the answer also includes the
   OC-Supported-Features AVP that describes the capabilities it
   supports.  The set of capabilities advertised by the reporting node
   depends on local policies.  At least one of the announced
   capabilities MUST match.  If there is no single matching capability
   the reacting node MUST act as if it does not implement DOIC and cease
   inserting any DOIC related AVPs into any Diameter messages with this
   specific reacting node.

      Editor's note: The last sentence conflicts with the last sentence
      two paragraphs up.  In reality, there will always be at least one
      matching capability as all nodes supporting DOIC must support the
      loss algorithm.  Suggest removing the last sentence.


Proposed text:

6.1.  OC-Supported-Features AVP

  ...

   During the message exchange the overload control endpoints express
   their common set of supported capabilities.  The reacting node
   includes the OC-Supported-Features AVP that announces what it
   supports.  The reporting node that sends the answer also includes the
   OC-Supported-Features AVP that describes the capabilities it
   supports.  The set of capabilities advertised by the reporting node
   depends on local policies. Both reacting and reporting node MUST share
at least one abatement algorithm, in fact, they share at least the loss
algorithm, that is defined in this document as the default abatement
algorithm, then the DOIC can always be enabled between these two endpoints
at least with the default algorithm.  See Section 4.1 for further
discussion on the capability and feature announcement between two
endpoints.

--
-------------------------------------+-------------------------------------
Reporter:                           |      Owner:  draft-ietf-dime-
 maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
    Type:  defect                   |     Status:  new
Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/68>
dime <http://tools.ietf.org/wg/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

--------------030506070708080105020802-- From nobody Fri Sep 5 08:02:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9391A071C for ; Fri, 5 Sep 2014 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7-IOGVJfDCw for ; Fri, 5 Sep 2014 08:01:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D1B1A070F for ; Fri, 5 Sep 2014 08:01:52 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s85F1oNq029579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Sep 2014 15:01:50 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s85F1mJ2003333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 17:01:49 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 5 Sep 2014 17:01:49 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 17:01:49 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNk1npQUPKBJHEWH9ycMDpTKl5vyI4dw///tvwCAAF6agIAAMDdg Date: Fri, 5 Sep 2014 15:01:48 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> In-Reply-To: <5409C1A7.5000805@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5518 X-purgate-ID: 151667::1409929310-0000061C-E1DBD125/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NBX_gXG8NQIfuIR87wKA9PvdX7A Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 15:02:02 -0000 Steve, I would have thought that two OLRs with same sequence number must have same= OLR content, especially same duration. A replay is either an exact replay or its not a replay. Regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Friday, September 05, 2014 3:59 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Ulrich, I think it would be correct for the OLR sent at 10:01 to indicate that=20 the OLR expires in four minutes. A reacting node that has already received the OLR will ignore it because=20 the sequence number is unchanged. A reacting node that has not already=20 received the OLR will treat it as a new report and get the correct=20 expiration time. It is certainly possible to implement it so that the OLR sent to a=20 specific reacting node always gets an exact replay until the report=20 changes or expires but I don't see that as a requirement. Regards, Steve On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: > Dear Ulrich, > > Not sure if I understand your point. > Is it your intention to send Validity-Duration AVP =3D OCS Validity Durat= ion (in your example 300 s) until timer expires (in your example until 10:0= 5)? > Could you elaborate a bit further please? > > Thanks > /MCruz > > -----Original Message----- > From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] > Sent: viernes, 05 de septiembre de 2014 10:15 > To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartol= ome > Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting = Nodes - Expiry Time > > Dear Maria Cruz, > > I do not agree. > As an example assume that the reporting node creates an overload state at= 10:00 with a duration of 5 minutes. This means that Validity duration is 5= minutes and expiry time is 10:05. > If only expiration time but not validity duration is stored at the report= ing node, this will result in the following: > For an answer message that is sent immediately (i.e. at 10:00) validity d= uration will be calculated as 5 minutes (which I think is correct). > For an answer message that is sent at 10:01 validity duration will be cal= culated as 4 minutes, which I think is not correct. The answer message sent= at 10:01 should contain a replay of the OLR already sent at 10:00, not an = updated OLR. > > Therefore validity duration should not be removed from the OCS. > > Best regards > Ulrich > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tra= cker > Sent: Friday, September 05, 2014 9:15 AM > To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.co= m > Cc: dime@ietf.org > Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Node= s - Expiry Time > > #67: OCS for Reporting Nodes - Expiry Time > > What does "Validity Duration" mean as the information stored in OCS for= Reporting Nodes? > > We need to store some information that allow the reporting node to cal= culate a Validity-Duration value to be included in each OC-OLR AVP Then, I= presume we need just Expiry Time, and then value to be included in each V= alidation-Duration AVP is calculated based on this. > > Then, original text: > > 4.2.1.2. Overload Control States for Reporting Nodes > > A reporting node maintains per supported Diameter application and pe= r > supported (and eventually selected) Abatement Algorithm an Overload > Control State. > > An Overload Control State may be identified by the pair of > Application-Id and supported Abatement Algorithm. > > The Overload Control State for a given pair of Application and > Abatement Algorithm could include the information: > > o Sequence number > > o Validity Duration and Expiry Time > > o Algorithm specific input data (e.g. Reduction Percentage for > Loss) > > Overload Control States for reporting nodes containing a validity > duration of 0 sec. should not expire before any previously sent > (stale) OLR has timed out at any reacting node. > > Editor's note: This statement is unclear and contradictory with othe= r > statements. A validity timer of zero seconds indicates that the > overload condition has ended and abatement is no longer requested. > > > Proposed modification: > > 4.2.1.2. Overload Control States for Reporting Nodes > > A reporting node maintains per supported Diameter application and pe= r > supported (and eventually selected) Abatement Algorithm an Overload > Control State. > > An Overload Control State may be identified by the pair of > Application-Id and supported Abatement Algorithm. > > The Overload Control State for a given pair of Application and > Abatement Algorithm could include the information: > > o Sequence number > > o Expiry Time > > o Algorithm specific input data (e.g. Reduction Percentage for > Loss) > > Expiry Time is used by the reporting node to calculate the value to = be > included in each Validity-Duration AVP, as part of the overload repo= rt. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 5 08:16:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BAE1A0712 for ; Fri, 5 Sep 2014 08:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caRl0NmWGJaO for ; Fri, 5 Sep 2014 08:16:30 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD1B1A0711 for ; Fri, 5 Sep 2014 08:16:30 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49221 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPvFS-0005hS-8i; Fri, 05 Sep 2014 08:16:29 -0700 Message-ID: <5409D3C9.7030609@usdonovans.com> Date: Fri, 05 Sep 2014 10:16:25 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hLCJ1UkaJxnlhePhO8_4ofTbCJ8 Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 15:16:31 -0000 Ulrich, My interpretation is that two OLRs with the same sequence number apply to the same overload event at the reporting node. The contents do not need to be the same, although the only item in a loss report that is likely to change is the validation time. The important behavior is that the reacting node ignores an overload report with a sequence number it has already seen. If that behavior is followed then it doesn't matter if the contents of the report is an exact replay of a previous report. Regards, Steve On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I would have thought that two OLRs with same sequence number must have same OLR content, especially same duration. > A replay is either an exact replay or its not a replay. > Regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Friday, September 05, 2014 3:59 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time > > Ulrich, > > I think it would be correct for the OLR sent at 10:01 to indicate that > the OLR expires in four minutes. > > A reacting node that has already received the OLR will ignore it because > the sequence number is unchanged. A reacting node that has not already > received the OLR will treat it as a new report and get the correct > expiration time. > > It is certainly possible to implement it so that the OLR sent to a > specific reacting node always gets an exact replay until the report > changes or expires but I don't see that as a requirement. > > Regards, > > Steve > > On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >> Dear Ulrich, >> >> Not sure if I understand your point. >> Is it your intention to send Validity-Duration AVP = OCS Validity Duration (in your example 300 s) until timer expires (in your example until 10:05)? >> Could you elaborate a bit further please? >> >> Thanks >> /MCruz >> >> -----Original Message----- >> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >> Sent: viernes, 05 de septiembre de 2014 10:15 >> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolome >> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time >> >> Dear Maria Cruz, >> >> I do not agree. >> As an example assume that the reporting node creates an overload state at 10:00 with a duration of 5 minutes. This means that Validity duration is 5 minutes and expiry time is 10:05. >> If only expiration time but not validity duration is stored at the reporting node, this will result in the following: >> For an answer message that is sent immediately (i.e. at 10:00) validity duration will be calculated as 5 minutes (which I think is correct). >> For an answer message that is sent at 10:01 validity duration will be calculated as 4 minutes, which I think is not correct. The answer message sent at 10:01 should contain a replay of the OLR already sent at 10:00, not an updated OLR. >> >> Therefore validity duration should not be removed from the OCS. >> >> Best regards >> Ulrich >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tracker >> Sent: Friday, September 05, 2014 9:15 AM >> To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com >> Cc: dime@ietf.org >> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time >> >> #67: OCS for Reporting Nodes - Expiry Time >> >> What does "Validity Duration" mean as the information stored in OCS for Reporting Nodes? >> >> We need to store some information that allow the reporting node to calculate a Validity-Duration value to be included in each OC-OLR AVP Then, I presume we need just Expiry Time, and then value to be included in each Validation-Duration AVP is calculated based on this. >> >> Then, original text: >> >> 4.2.1.2. Overload Control States for Reporting Nodes >> >> A reporting node maintains per supported Diameter application and per >> supported (and eventually selected) Abatement Algorithm an Overload >> Control State. >> >> An Overload Control State may be identified by the pair of >> Application-Id and supported Abatement Algorithm. >> >> The Overload Control State for a given pair of Application and >> Abatement Algorithm could include the information: >> >> o Sequence number >> >> o Validity Duration and Expiry Time >> >> o Algorithm specific input data (e.g. Reduction Percentage for >> Loss) >> >> Overload Control States for reporting nodes containing a validity >> duration of 0 sec. should not expire before any previously sent >> (stale) OLR has timed out at any reacting node. >> >> Editor's note: This statement is unclear and contradictory with other >> statements. A validity timer of zero seconds indicates that the >> overload condition has ended and abatement is no longer requested. >> >> >> Proposed modification: >> >> 4.2.1.2. Overload Control States for Reporting Nodes >> >> A reporting node maintains per supported Diameter application and per >> supported (and eventually selected) Abatement Algorithm an Overload >> Control State. >> >> An Overload Control State may be identified by the pair of >> Application-Id and supported Abatement Algorithm. >> >> The Overload Control State for a given pair of Application and >> Abatement Algorithm could include the information: >> >> o Sequence number >> >> o Expiry Time >> >> o Algorithm specific input data (e.g. Reduction Percentage for >> Loss) >> >> Expiry Time is used by the reporting node to calculate the value to be >> included in each Validity-Duration AVP, as part of the overload report. >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Sep 5 08:32:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11861A078D for ; Fri, 5 Sep 2014 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS4LmxV-s8Wr for ; Fri, 5 Sep 2014 08:32:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B6C1A0747 for ; Fri, 5 Sep 2014 08:32:51 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s85FWom5028627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Sep 2014 15:32:50 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s85FWo87013698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 17:32:50 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 5 Sep 2014 17:32:50 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 17:32:50 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNk1npQUPKBJHEWH9ycMDpTKl5vyI4dw///tvwCAAF6agIAAMDdg///lZoCAACPDQA== Date: Fri, 5 Sep 2014 15:32:49 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> In-Reply-To: <5409D3C9.7030609@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7134 X-purgate-ID: 151667::1409931170-0000061C-5C6B80AC/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vMW5zMuynnfes_QlDb-r8518KZw Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 15:32:55 -0000 Steve, if - as proposed by MCruz - the validity duration is not stored at the repo= rting node, the reporting node always has to calculate the duration (e.g. 4= min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and t= he reacting node has to calculate the expiration time from reception time a= nd duration. Would it not be more straight forward to transmit the expiry t= ime rather than the duration? This avoids the need to send different values= depending on sending time. Regards Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Friday, September 05, 2014 5:16 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Ulrich, My interpretation is that two OLRs with the same sequence number apply=20 to the same overload event at the reporting node. The contents do not=20 need to be the same, although the only item in a loss report that is=20 likely to change is the validation time. The important behavior is that the reacting node ignores an overload=20 report with a sequence number it has already seen. If that behavior is=20 followed then it doesn't matter if the contents of the report is an=20 exact replay of a previous report. Regards, Steve On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I would have thought that two OLRs with same sequence number must have sa= me OLR content, especially same duration. > A replay is either an exact replay or its not a replay. > Regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Friday, September 05, 2014 3:59 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting = Nodes - Expiry Time > > Ulrich, > > I think it would be correct for the OLR sent at 10:01 to indicate that > the OLR expires in four minutes. > > A reacting node that has already received the OLR will ignore it because > the sequence number is unchanged. A reacting node that has not already > received the OLR will treat it as a new report and get the correct > expiration time. > > It is certainly possible to implement it so that the OLR sent to a > specific reacting node always gets an exact replay until the report > changes or expires but I don't see that as a requirement. > > Regards, > > Steve > > On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >> Dear Ulrich, >> >> Not sure if I understand your point. >> Is it your intention to send Validity-Duration AVP =3D OCS Validity Dura= tion (in your example 300 s) until timer expires (in your example until 10:= 05)? >> Could you elaborate a bit further please? >> >> Thanks >> /MCruz >> >> -----Original Message----- >> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >> Sent: viernes, 05 de septiembre de 2014 10:15 >> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Barto= lome >> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting= Nodes - Expiry Time >> >> Dear Maria Cruz, >> >> I do not agree. >> As an example assume that the reporting node creates an overload state a= t 10:00 with a duration of 5 minutes. This means that Validity duration is = 5 minutes and expiry time is 10:05. >> If only expiration time but not validity duration is stored at the repor= ting node, this will result in the following: >> For an answer message that is sent immediately (i.e. at 10:00) validity = duration will be calculated as 5 minutes (which I think is correct). >> For an answer message that is sent at 10:01 validity duration will be ca= lculated as 4 minutes, which I think is not correct. The answer message sen= t at 10:01 should contain a replay of the OLR already sent at 10:00, not an= updated OLR. >> >> Therefore validity duration should not be removed from the OCS. >> >> Best regards >> Ulrich >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tr= acker >> Sent: Friday, September 05, 2014 9:15 AM >> To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.c= om >> Cc: dime@ietf.org >> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nod= es - Expiry Time >> >> #67: OCS for Reporting Nodes - Expiry Time >> >> What does "Validity Duration" mean as the information stored in OCS f= or Reporting Nodes? >> >> We need to store some information that allow the reporting node to c= alculate a Validity-Duration value to be included in each OC-OLR AVP Then,= I presume we need just Expiry Time, and then value to be included in each= Validation-Duration AVP is calculated based on this. >> >> Then, original text: >> >> 4.2.1.2. Overload Control States for Reporting Nodes >> >> A reporting node maintains per supported Diameter application and = per >> supported (and eventually selected) Abatement Algorithm an Overloa= d >> Control State. >> >> An Overload Control State may be identified by the pair of >> Application-Id and supported Abatement Algorithm. >> >> The Overload Control State for a given pair of Application and >> Abatement Algorithm could include the information: >> >> o Sequence number >> >> o Validity Duration and Expiry Time >> >> o Algorithm specific input data (e.g. Reduction Percentage for >> Loss) >> >> Overload Control States for reporting nodes containing a validity >> duration of 0 sec. should not expire before any previously sent >> (stale) OLR has timed out at any reacting node. >> >> Editor's note: This statement is unclear and contradictory with ot= her >> statements. A validity timer of zero seconds indicates that the >> overload condition has ended and abatement is no longer requested. >> >> >> Proposed modification: >> >> 4.2.1.2. Overload Control States for Reporting Nodes >> >> A reporting node maintains per supported Diameter application and = per >> supported (and eventually selected) Abatement Algorithm an Overloa= d >> Control State. >> >> An Overload Control State may be identified by the pair of >> Application-Id and supported Abatement Algorithm. >> >> The Overload Control State for a given pair of Application and >> Abatement Algorithm could include the information: >> >> o Sequence number >> >> o Expiry Time >> >> o Algorithm specific input data (e.g. Reduction Percentage for >> Loss) >> >> Expiry Time is used by the reporting node to calculate the value t= o be >> included in each Validity-Duration AVP, as part of the overload re= port. >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Sep 5 11:38:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1B71A01FF for ; Fri, 5 Sep 2014 11:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgSLs4RGlf13 for ; Fri, 5 Sep 2014 11:38:44 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9AA1A01E0 for ; Fri, 5 Sep 2014 11:38:44 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:49431 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPyP8-00012o-HP; Fri, 05 Sep 2014 11:38:43 -0700 Message-ID: <540A032C.5010808@usdonovans.com> Date: Fri, 05 Sep 2014 13:38:36 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1WIrBUrD-YBIrEK6YMewE9BJsVE Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 18:38:46 -0000 Ulrich, What the reporting node does is an implementation decision. If the reporting node wants to have precise control over when overload reports end on all reacting nodes then it can calculate the duration for every answer message sent. If it considers it ok to have a staggered end of the OLR, or if it sends explicit end-of-overload OLRs then it might choose to not recalculate. I don't see the need to specify that behavior in the DOIC specification. The reacting node MUST NOT recalculate the expiration time because the sequence number is the same. The reacting node will ignore the overload report and not bother to even look at any parameters in the report other then the sequence number. Regards, Steve On 9/5/14, 10:32 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > if - as proposed by MCruz - the validity duration is not stored at the reporting node, the reporting node always has to calculate the duration (e.g. 4 min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and the reacting node has to calculate the expiration time from reception time and duration. Would it not be more straight forward to transmit the expiry time rather than the duration? This avoids the need to send different values depending on sending time. > > Regards > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Friday, September 05, 2014 5:16 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time > > Ulrich, > > My interpretation is that two OLRs with the same sequence number apply > to the same overload event at the reporting node. The contents do not > need to be the same, although the only item in a loss report that is > likely to change is the validation time. > > The important behavior is that the reacting node ignores an overload > report with a sequence number it has already seen. If that behavior is > followed then it doesn't matter if the contents of the report is an > exact replay of a previous report. > > Regards, > > Steve > > On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> I would have thought that two OLRs with same sequence number must have same OLR content, especially same duration. >> A replay is either an exact replay or its not a replay. >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Friday, September 05, 2014 3:59 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time >> >> Ulrich, >> >> I think it would be correct for the OLR sent at 10:01 to indicate that >> the OLR expires in four minutes. >> >> A reacting node that has already received the OLR will ignore it because >> the sequence number is unchanged. A reacting node that has not already >> received the OLR will treat it as a new report and get the correct >> expiration time. >> >> It is certainly possible to implement it so that the OLR sent to a >> specific reacting node always gets an exact replay until the report >> changes or expires but I don't see that as a requirement. >> >> Regards, >> >> Steve >> >> On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >>> Dear Ulrich, >>> >>> Not sure if I understand your point. >>> Is it your intention to send Validity-Duration AVP = OCS Validity Duration (in your example 300 s) until timer expires (in your example until 10:05)? >>> Could you elaborate a bit further please? >>> >>> Thanks >>> /MCruz >>> >>> -----Original Message----- >>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >>> Sent: viernes, 05 de septiembre de 2014 10:15 >>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolome >>> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time >>> >>> Dear Maria Cruz, >>> >>> I do not agree. >>> As an example assume that the reporting node creates an overload state at 10:00 with a duration of 5 minutes. This means that Validity duration is 5 minutes and expiry time is 10:05. >>> If only expiration time but not validity duration is stored at the reporting node, this will result in the following: >>> For an answer message that is sent immediately (i.e. at 10:00) validity duration will be calculated as 5 minutes (which I think is correct). >>> For an answer message that is sent at 10:01 validity duration will be calculated as 4 minutes, which I think is not correct. The answer message sent at 10:01 should contain a replay of the OLR already sent at 10:00, not an updated OLR. >>> >>> Therefore validity duration should not be removed from the OCS. >>> >>> Best regards >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue tracker >>> Sent: Friday, September 05, 2014 9:15 AM >>> To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com >>> Cc: dime@ietf.org >>> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time >>> >>> #67: OCS for Reporting Nodes - Expiry Time >>> >>> What does "Validity Duration" mean as the information stored in OCS for Reporting Nodes? >>> >>> We need to store some information that allow the reporting node to calculate a Validity-Duration value to be included in each OC-OLR AVP Then, I presume we need just Expiry Time, and then value to be included in each Validation-Duration AVP is calculated based on this. >>> >>> Then, original text: >>> >>> 4.2.1.2. Overload Control States for Reporting Nodes >>> >>> A reporting node maintains per supported Diameter application and per >>> supported (and eventually selected) Abatement Algorithm an Overload >>> Control State. >>> >>> An Overload Control State may be identified by the pair of >>> Application-Id and supported Abatement Algorithm. >>> >>> The Overload Control State for a given pair of Application and >>> Abatement Algorithm could include the information: >>> >>> o Sequence number >>> >>> o Validity Duration and Expiry Time >>> >>> o Algorithm specific input data (e.g. Reduction Percentage for >>> Loss) >>> >>> Overload Control States for reporting nodes containing a validity >>> duration of 0 sec. should not expire before any previously sent >>> (stale) OLR has timed out at any reacting node. >>> >>> Editor's note: This statement is unclear and contradictory with other >>> statements. A validity timer of zero seconds indicates that the >>> overload condition has ended and abatement is no longer requested. >>> >>> >>> Proposed modification: >>> >>> 4.2.1.2. Overload Control States for Reporting Nodes >>> >>> A reporting node maintains per supported Diameter application and per >>> supported (and eventually selected) Abatement Algorithm an Overload >>> Control State. >>> >>> An Overload Control State may be identified by the pair of >>> Application-Id and supported Abatement Algorithm. >>> >>> The Overload Control State for a given pair of Application and >>> Abatement Algorithm could include the information: >>> >>> o Sequence number >>> >>> o Expiry Time >>> >>> o Algorithm specific input data (e.g. Reduction Percentage for >>> Loss) >>> >>> Expiry Time is used by the reporting node to calculate the value to be >>> included in each Validity-Duration AVP, as part of the overload report. >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Sun Sep 7 21:48:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8FF1A6EF2 for ; Sun, 7 Sep 2014 21:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.453 X-Spam-Level: X-Spam-Status: No, score=-13.453 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJogo185hX6b for ; Sun, 7 Sep 2014 21:48:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522C61A6EF8 for ; Sun, 7 Sep 2014 21:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4208; q=dns/txt; s=iport; t=1410151688; x=1411361288; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=t+BoEU0+tNGisUcv9tWaCBCyOaI7fn+K6+zngg6J+uQ=; b=SzjnyL9KMQXrlWtR7si+gdHDccQg+3NKw8Ya0bQNhk62YrC4Q3S3Ucs3 5PL3mv7fs7DFbMVnyERFoDJynoQyST6lbFUMMl5RQIi+JzHz/mtl0seuw sBYiDknAt0JZA0lgFzD5bTp5Q5JO3qBz0O+jekVs/NcjPBXBBpQuP8H3W w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJI0DVStJA2I/2dsb2JhbABTBoMNU1cEgnjGbQqHTAEZdhZ4hAMBAQEDAQEBASAROhAHBAIBCA4DBAEBAQICBh0DAgICJQsUAQgIAgQBEgiIMggNpV2VBAETBIEsjV4SOAaCczaBHQWRQKBeghuBRmwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,484,1406592000"; d="scan'208";a="353313789" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP; 08 Sep 2014 04:48:07 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s884m7vF010158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 04:48:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Sun, 7 Sep 2014 23:48:07 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/1+Q8BEs1TL06ARTN1arg4/pvy7gSAgAO/zUA= Date: Mon, 8 Sep 2014 04:48:06 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> In-Reply-To: <5409C913.7080103@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nSBHc60fRa4uwZtkBFbirT3stAA Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 04:48:10 -0000 U3RldmUsDQoNCj4gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc3BlY2lmeSB0aGUgYmVoYXZpb3Ig b2YgdGhlIHJlcG9ydGluZyBub2RlIHRvIGFsd2F5cyBpbmNsdWRlIHRoZSBPTFIgaW4gZXZlcnkg YW5zd2VyIG1lc3NhZ2UgZm9yIGFzIGxvbmcgYXMgdGhlcmUgaXMgYW4gb3ZlcmxvYWQgY29uZGl0 aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZS4NCkkgZG9u4oCZdCB0aGluayB0aGlzIGlzIG5lY2Vz c2FyeS4gVGhlIHJlcG9ydGluZyBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBt ZXNzYWdlIGJ1dCB3ZSBkb27igJl0IGhhdmUgdG8gcHV0IHRoYXQgYXMgbWFuZGF0b3J5IHJlcXVp cmVtZW50LCBlLmcuIGlmIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyAoYW5kIGtlZXBzIHRyYWNr IG9mKSBpZiB0aGUgdGFyZ2V0IHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkgcmVjZWl2ZWQgY3Vy cmVudGx5IGFjdGl2ZSBPTFIuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNSwgMjAx NCA4OjAxIFBNDQpUbzogZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1lLW92bGlAdG9vbHMu aWV0Zi5vcmc7IG1hcmlhLmNydXouYmFydG9sb21lQGVyaWNzc29uLmNvbQ0KU3ViamVjdDogUmU6 IFtEaW1lXSBbZGltZV0gIzcyIChkcmFmdC1pZXRmLWRpbWUtb3ZsaSk6IFJlcG9ydGluZyBOb2Rl IEJlaGF2aW91ciB3aGVuIE9DLU9MUiBpcyBub3QgcmVjZWl2ZWQNCg0KTWFyaWEgQ3J1eiwNCg0K SSdtIG5vdCBzdXJlIEkgYWdyZWUgd2l0aCB0aGlzIHByb3Bvc2VkIGNoYW5nZS4NCg0KVGhlIHdv cmRpbmcgdG8gaW5kaWNhdGUgdGhhdCBhYnNlbmNlIG9mIGFuIG92ZXJsb2FkIHJlcG9ydCB3YXMg dG8gaGFuZGxlIHVudXN1YWwgc2l0dWF0aW9ucy4gIFlvdXIgcHJvcG9zZWQgd29yZGluZyBpbXBs aWVzIHRoYXQgaXQgaXMgYWNjZXB0YWJsZSBmb3IgYSByZXBvcnRpbmcgbm9kZSB0byBub3QgaW5j bHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLg0KDQpJIHRoaW5rIGl0IGlzIGJl dHRlciB0byBzcGVjaWZ5IHRoZSBiZWhhdmlvciBvZiB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gYWx3 YXlzIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZSBmb3IgYXMgbG9uZyBh cyB0aGVyZSBpcyBhbiBvdmVybG9hZCBjb25kaXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlLg0K DQpSZWdhcmRzLA0KDQpTdGV2ZQ0KDQpPbiA5LzUvMTQsIDM6MDMgQU0sIGRpbWUgaXNzdWUgdHJh Y2tlciB3cm90ZToNCj4gIzcyOiBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvdXIgd2hlbiBPQy1PTFIg aXMgbm90IHJlY2VpdmVkDQo+DQo+ICAgQSBjbGFyaWZpY2F0aW9uIGlzIHJlcXVpcmVkIHRvIGNv bnNpZGVyIHRoYXQgYW4gYW5zd2VyIG1lc3NhZ2UgbWF5IG5vdA0KPiAgIGluY2x1ZGUgT0MtT0xS IGFuZCBzdGlsbCB0aGUgcmVwb3J0aW5nIG5vZGUgYmUgIG92ZXJsb2FkZWQsIHNpbmNlIGl0IGlz DQo+ICAgY29uc2lkZXJlZCBhcyAibm8gY2hhbmdlIiwgYXMgZG9jdW1lbnRlZCBpbiA0LjIuMS4z Og0KPg0KPiAgICAgICBSZWFjdGluZyBub2RlcyBkbyBub3QgZGVsZXRlIGFuIE9DUyB3aGVuIHJl Y2VpdmluZyBhbiBhbnN3ZXIgbWVzc2FnZQ0KPiAgICAgICB0aGF0IGRvZXMgbm90IGNvbnRhaW4g YW4gT0MtT0xSIEFWUCAoaS5lLiBhYnNlbmNlIG9mIE9MUiBtZWFucyAibm8NCj4gICAgICAgY2hh bmdlIikuDQo+DQo+DQo+ICAgT3JpZ2luYWwgdGV4dDoNCj4NCj4gICA1LjMuICBSZXBvcnRpbmcg Tm9kZSBCZWhhdmlvciAoTm9ybWF0aXZlKQ0KPg0KPiAgICAgIFRoZSBtZXRob2QgYSByZXBvcnRp bmcgbm9kZXMgdXNlcyB0byBkZXRlcm1pbmUgdGhlIGFtb3VudCBvZiB0cmFmZmljDQo+ICAgICAg cmVkdWN0aW9uIHJlcXVpcmVkIHRvIGFkZHJlc3MgYW4gb3ZlcmxvYWQgY29uZGl0aW9uIGlzIGFu DQo+ICAgICAgaW1wbGVtZW50YXRpb24gZGVjaXNpb24uDQo+DQo+ICAgICAgV2hlbiBhIHJlcG9y dGluZyBub2RlIHRoYXQgaGFzIHNlbGVjdGVkIHRoZSBsb3NzIGFiYXRlbWVudCBhbGdvcml0aG0N Cj4gICAgICBkZXRlcm1pbmVzIHRoZSBuZWVkIHRvIHJlcXVlc3QgYSB0cmFmZmljIHJlZHVjdGlv biBpdCBtdXN0IGluY2x1ZGUgYW4NCj4gICAgICBPQy1PTFIgQVZQIGluIGFsbCByZXNwb25zZSBt ZXNzYWdlcy4NCj4NCj4NCj4gICBQcm9wb3NlZCBhZGRpdGlvbjoNCj4NCj4NCj4gICA1LjMuICBS ZXBvcnRpbmcgTm9kZSBCZWhhdmlvciAoTm9ybWF0aXZlKQ0KPg0KPiAgICAgIFRoZSBtZXRob2Qg YSByZXBvcnRpbmcgbm9kZXMgdXNlcyB0byBkZXRlcm1pbmUgdGhlIGFtb3VudCBvZiB0cmFmZmlj DQo+ICAgICAgcmVkdWN0aW9uIHJlcXVpcmVkIHRvIGFkZHJlc3MgYW4gb3ZlcmxvYWQgY29uZGl0 aW9uIGlzIGFuDQo+ICAgICAgaW1wbGVtZW50YXRpb24gZGVjaXNpb24uDQo+DQo+ICAgICAgV2hl biBhIHJlcG9ydGluZyBub2RlIHRoYXQgaGFzIHNlbGVjdGVkIHRoZSBsb3NzIGFiYXRlbWVudCBh bGdvcml0aG0NCj4gICAgICBkZXRlcm1pbmVzIHRoZSBuZWVkIHRvIHJlcXVlc3QgYSB0cmFmZmlj IHJlZHVjdGlvbiBpdCBtdXN0IGluY2x1ZGUgYW4NCj4gICAgICBPQy1PTFIgQVZQIGluIGFsbCBy ZXNwb25zZSBtZXNzYWdlcy4gT0MtT0xSIEFWUCBpcyBub3QgaW5jbHVkZWQgd2hlbg0KPiAgIHJl cG9ydGluZyBub2RlIGV4cGVjdGF0aW9ucyBvbiB0cmFmZmljIHJlZHVjdGlvbiBhcmUgbm90IG1v ZGlmaWVkLiBUaGF0DQo+ICAgaXMsIGlmIE9DLU9MUiBBVlAgaXMgbm90IGluY2x1ZGVkIGl0IGlz IGludGVycHJldGVkIGFzIOKAnG5vIGNoYW5nZeKAnS4NCj4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg== From nobody Mon Sep 8 00:25:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A6A1A6F3F for ; Mon, 8 Sep 2014 00:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_sBIKApSHK0 for ; Mon, 8 Sep 2014 00:25:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940541A6F3E for ; Mon, 8 Sep 2014 00:25:19 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 449F9AB30EEAC; Mon, 8 Sep 2014 07:25:16 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s887P1Ae022441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 09:25:17 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 8 Sep 2014 09:25:10 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNk8ZIiexx4ldEipoOaowgvbU5vyD7KAgAABlACAAF6ZgIAAEYkAgAAEFYCAAASVgIAAM+gAgAQPEmA= Date: Mon, 8 Sep 2014 07:25:09 +0000 Message-ID: References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> <540A032C.5010808@usdonovans.com> In-Reply-To: <540A032C.5010808@usdonovans.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Fi-Ix5-qnlxvNA2DKWkNASn0sp0 Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 07:25:22 -0000 Dear all I suggest to have a look at what is foreseen with GTP overload control, whe= re there is a validity timer with a recommended handling (TR 29.807 6.2.2.1= .2. and 6.2.2.1.3). I think for Diameter and GTP overload we should have th= e same handling of the Validity period (and also the seq number) as I do no= t see a reason/justification them to be different. For both cases the important point is that the timer (in the reacting node)= is restarted only when a new sequence number is received (as Steve indicat= ed, the IETF draft is clear here: in 6.3 "The validity time MUST NOT be up= dated after reception of subsequent OC-OLR AVPs with the same sequence numb= er")=20 If the reacting node wants to recalculate the value at each answer, why not= (as Steve said this is an implementation choice, probably not the best one= ), but if the reporting node wants the reacting node to take the new value = sent in the OLR into account, it has to change the seq number. The frequenc= y at which the reporting node updates the validity period is also implement= ation specific and depends of the overload characteristics. =20 Another remark is that as the OLRs may be received out of order, if the rep= orting node changes the validity period value (without changing the seq nu= mber) in OLR it sends, the reporting cannot be sure of the value that the = reacting node will use, for this it will have to change the seq number. So = better to send the same value in OLRs if the same seq number. I think the p= rinciple is that the OLR content if the same (same AVPS with same values) i= f the seq number is not modified. This point is not clearly stated in the d= raft, may be good to indicate this. Otherwise, I do not think we have to m= odify the OCS. Best regards JJacques=20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: vendredi 5 septembre 2014 20:39 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting N= odes - Expiry Time Ulrich, What the reporting node does is an implementation decision. If the reporti= ng node wants to have precise control over when overload reports end on all= reacting nodes then it can calculate the duration for every answer message= sent. If it considers it ok to have a staggered end of the OLR, or if it = sends explicit end-of-overload OLRs then it might choose to not recalculate= . I don't see the need to specify that behavior in the DOIC specification. The reacting node MUST NOT recalculate the expiration time because the sequ= ence number is the same. The reacting node will ignore the overload report= and not bother to even look at any parameters in the report other then the= sequence number. Regards, Steve On 9/5/14, 10:32 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > if - as proposed by MCruz - the validity duration is not stored at the re= porting node, the reporting node always has to calculate the duration (e.g.= 4 min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and= the reacting node has to calculate the expiration time from reception time= and duration. Would it not be more straight forward to transmit the expiry= time rather than the duration? This avoids the need to send different valu= es depending on sending time. > > Regards > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Friday, September 05, 2014 5:16 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 > Reporting Nodes - Expiry Time > > Ulrich, > > My interpretation is that two OLRs with the same sequence number apply=20 > to the same overload event at the reporting node. The contents do not=20 > need to be the same, although the only item in a loss report that is=20 > likely to change is the validation time. > > The important behavior is that the reacting node ignores an overload=20 > report with a sequence number it has already seen. If that behavior=20 > is followed then it doesn't matter if the contents of the report is an=20 > exact replay of a previous report. > > Regards, > > Steve > > On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> I would have thought that two OLRs with same sequence number must have s= ame OLR content, especially same duration. >> A replay is either an exact replay or its not a replay. >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Friday, September 05, 2014 3:59 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 >> Reporting Nodes - Expiry Time >> >> Ulrich, >> >> I think it would be correct for the OLR sent at 10:01 to indicate=20 >> that the OLR expires in four minutes. >> >> A reacting node that has already received the OLR will ignore it=20 >> because the sequence number is unchanged. A reacting node that has=20 >> not already received the OLR will treat it as a new report and get=20 >> the correct expiration time. >> >> It is certainly possible to implement it so that the OLR sent to a=20 >> specific reacting node always gets an exact replay until the report=20 >> changes or expires but I don't see that as a requirement. >> >> Regards, >> >> Steve >> >> On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >>> Dear Ulrich, >>> >>> Not sure if I understand your point. >>> Is it your intention to send Validity-Duration AVP =3D OCS Validity Dur= ation (in your example 300 s) until timer expires (in your example until 10= :05)? >>> Could you elaborate a bit further please? >>> >>> Thanks >>> /MCruz >>> >>> -----Original Message----- >>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >>> Sent: viernes, 05 de septiembre de 2014 10:15 >>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz=20 >>> Bartolome >>> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 >>> Reporting Nodes - Expiry Time >>> >>> Dear Maria Cruz, >>> >>> I do not agree. >>> As an example assume that the reporting node creates an overload state = at 10:00 with a duration of 5 minutes. This means that Validity duration is= 5 minutes and expiry time is 10:05. >>> If only expiration time but not validity duration is stored at the repo= rting node, this will result in the following: >>> For an answer message that is sent immediately (i.e. at 10:00) validity= duration will be calculated as 5 minutes (which I think is correct). >>> For an answer message that is sent at 10:01 validity duration will be c= alculated as 4 minutes, which I think is not correct. The answer message se= nt at 10:01 should contain a replay of the OLR already sent at 10:00, not a= n updated OLR. >>> >>> Therefore validity duration should not be removed from the OCS. >>> >>> Best regards >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime=20 >>> issue tracker >>> Sent: Friday, September 05, 2014 9:15 AM >>> To: draft-ietf-dime-ovli@tools.ietf.org;=20 >>> maria.cruz.bartolome@ericsson.com >>> Cc: dime@ietf.org >>> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting=20 >>> Nodes - Expiry Time >>> >>> #67: OCS for Reporting Nodes - Expiry Time >>> >>> What does "Validity Duration" mean as the information stored in OCS= for Reporting Nodes? >>> >>> We need to store some information that allow the reporting node to = calculate a Validity-Duration value to be included in each OC-OLR AVP The= n, I presume we need just Expiry Time, and then value to be included in ea= ch Validation-Duration AVP is calculated based on this. >>> >>> Then, original text: >>> >>> 4.2.1.2. Overload Control States for Reporting Nodes >>> >>> A reporting node maintains per supported Diameter application an= d per >>> supported (and eventually selected) Abatement Algorithm an Overl= oad >>> Control State. >>> >>> An Overload Control State may be identified by the pair of >>> Application-Id and supported Abatement Algorithm. >>> >>> The Overload Control State for a given pair of Application and >>> Abatement Algorithm could include the information: >>> >>> o Sequence number >>> >>> o Validity Duration and Expiry Time >>> >>> o Algorithm specific input data (e.g. Reduction Percentage for >>> Loss) >>> >>> Overload Control States for reporting nodes containing a validit= y >>> duration of 0 sec. should not expire before any previously sent >>> (stale) OLR has timed out at any reacting node. >>> >>> Editor's note: This statement is unclear and contradictory with = other >>> statements. A validity timer of zero seconds indicates that the >>> overload condition has ended and abatement is no longer requeste= d. >>> >>> >>> Proposed modification: >>> >>> 4.2.1.2. Overload Control States for Reporting Nodes >>> >>> A reporting node maintains per supported Diameter application an= d per >>> supported (and eventually selected) Abatement Algorithm an Overl= oad >>> Control State. >>> >>> An Overload Control State may be identified by the pair of >>> Application-Id and supported Abatement Algorithm. >>> >>> The Overload Control State for a given pair of Application and >>> Abatement Algorithm could include the information: >>> >>> o Sequence number >>> >>> o Expiry Time >>> >>> o Algorithm specific input data (e.g. Reduction Percentage for >>> Loss) >>> >>> Expiry Time is used by the reporting node to calculate the value= to be >>> included in each Validity-Duration AVP, as part of the overload = report. >>> >> _______________________________________________ >> 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 nobody Mon Sep 8 01:55:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22661A6F88; Mon, 8 Sep 2014 01:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV0dLHyyABfL; Mon, 8 Sep 2014 01:55:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEB41A0421; Mon, 8 Sep 2014 01:55:44 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id DA1112640C6; Mon, 8 Sep 2014 10:55:42 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BAEB44C015; Mon, 8 Sep 2014 10:55:42 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 10:55:42 +0200 From: To: "iesg-secretary@ietf.org" , "dime@ietf.org" Thread-Topic: DIME WG Interim Meeting Thread-Index: Ac/LQpFuDUgBmi8IRWaBzz3UFKCQog== Date: Mon, 8 Sep 2014 08:55:41 +0000 Message-ID: <11294_1410166542_540D6F0E_11294_720_1_6B7134B31289DC4FAF731D844122B36E6FF6E6@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: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E6FF6E6PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7dY8mQ8NFdgszWMiuRMVLK-p_wU Subject: [Dime] DIME WG Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 08:55:48 -0000 --_000_6B7134B31289DC4FAF731D844122B36E6FF6E6PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IETF DIME WG will hold an Interim Meeting on October 16-17, 2014. The meeting will take place at: Orange Labs Sophia-Antipolis (close to ETSI premises) 905 Rue Albert Einstein 06560 VALBONNE, FRANCE Meeting Room: S905 ROYA. The agenda of the meeting is to work on the remaining open issues on the Di= ameter Overload Control indication Conveyance (DOIC) draft, in order to pro= duce a final version for IETF Last-Call before the end of the year. A detai= led agenda will be provided later on the DIME mailing list. If you'd like to attend, please register by sending an email to the DIME WG= chairs (dime-chairs@tools.ietf.org). Here is a preliminary list of participants: - Jouni Korhonen - Lionel Morand - Steve Donovan - Ben Campbell - Maria Cruz Bartolome - Jean-Jacques Trottin - Susan Shishufeng - Ulrich Wiehe Regards, Lionel & Jouni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E6FF6E6PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IETF DIME WG wi= ll hold an Interim Meeting on October 16-17,

2014. The meeting w= ill take place at:

 

Orange Labs Sophia-= Antipolis (close to ETSI premises)

905 Rue Albert Einstein

06560 VALBONNE, FRANCE<= /span>

Meeting Room: S905 = ROYA.

 

The agenda of the m= eeting is to work on the remaining open issues on the Diameter Overload Con= trol indication Conveyance (DOIC) draft, in order to produce a final version for IETF Last-Call before the end of the year. = A detailed agenda will be provided later on the DIME mailing list.

 

If you'd like to at= tend, please register by sending an email to the DIME WG chairs (dime-chairs@tools.ietf.org).

 

Here is a prelimina= ry list of participants:

 

- Jouni Korhonen

- Lionel Morand

- Steve Donovan

- Ben Campbell

- Maria Cruz Bartolome<= /span>

- Jean-Jacques Trottin<= /span>

- Susan Shishufeng

- Ulrich Wiehe

 

Regards,

 

Lionel & Jouni

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E6FF6E6PEXCVZYM13corpora_-- From nobody Mon Sep 8 02:35:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D801A6FA6 for ; Mon, 8 Sep 2014 02:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4iAGvkEG1_q for ; Mon, 8 Sep 2014 02:35:48 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9F51A6F9E for ; Mon, 8 Sep 2014 02:35:48 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id E6565DC85E948; Mon, 8 Sep 2014 09:35:43 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s889ZUja020396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 11:35:44 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 8 Sep 2014 11:35:35 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" , Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNk8ZIiexx4ldEipoOaowgvbU5vyD7KAgAABlACAAF6ZgIAAEYkAgAAEFYCAAASVgIAAM+gAgAQPEmCAACXsQA== Date: Mon, 8 Sep 2014 09:35:34 +0000 Message-ID: References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> <540A032C.5010808@usdonovans.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.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kj_GN4HvseKmX1OD2a-h4qW8PDo Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 09:35:51 -0000 HI To complement my previous mail Instead to refer to the 3GPP TR 29.807, I should have referred to the norma= tive TS 29.274 v 12.5.0 integrating GTP Overload control (chapter 12) wit= h sections 12.3.5.1.2.1 Overload Control Sequence Number 276 and 12.3.5.1.= 2.2 Period of Validity and the following statement "The sender of this information shall increment the Overload-Sequence-Numbe= r associated to a particular overload scope whenever modifying some informa= tion in the Overload-Control-Information IE. The Overload-Sequence-Number s= hall not be incremented otherwise." Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: lundi 8 septembre 2014 09:25 =C0=A0: dime@ietf.org; Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich) Objet=A0: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting N= odes - Expiry Time Dear all I suggest to have a look at what is foreseen with GTP overload control, whe= re there is a validity timer with a recommended handling (TR 29.807 6.2.2.1= .2. and 6.2.2.1.3). I think for Diameter and GTP overload we should have th= e same handling of the Validity period (and also the seq number) as I do no= t see a reason/justification them to be different. For both cases the important point is that the timer (in the reacting node)= is restarted only when a new sequence number is received (as Steve indicat= ed, the IETF draft is clear here: in 6.3 "The validity time MUST NOT be up= dated after reception of subsequent OC-OLR AVPs with the same sequence numb= er")=20 If the reacting node wants to recalculate the value at each answer, why not= (as Steve said this is an implementation choice, probably not the best one= ), but if the reporting node wants the reacting node to take the new value = sent in the OLR into account, it has to change the seq number. The frequenc= y at which the reporting node updates the validity period is also implement= ation specific and depends of the overload characteristics. =20 Another remark is that as the OLRs may be received out of order, if the rep= orting node changes the validity period value (without changing the seq nu= mber) in OLR it sends, the reporting cannot be sure of the value that the = reacting node will use, for this it will have to change the seq number. So = better to send the same value in OLRs if the same seq number. I think the p= rinciple is that the OLR content if the same (same AVPS with same values) i= f the seq number is not modified. This point is not clearly stated in the d= raft, may be good to indicate this. Otherwise, I do not think we have to m= odify the OCS. Best regards JJacques=20 =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 20:39 =C0=A0: Wiehe, Ulrich (NSN - DE/Mu= nich); dime@ietf.org Objet=A0: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli)= : OCS for Reporting Nodes - Expiry Time Ulrich, What the reporting node does is an implementation decision. If the reporti= ng node wants to have precise control over when overload reports end on all= reacting nodes then it can calculate the duration for every answer message= sent. If it considers it ok to have a staggered end of the OLR, or if it = sends explicit end-of-overload OLRs then it might choose to not recalculate= . I don't see the need to specify that behavior in the DOIC specification. The reacting node MUST NOT recalculate the expiration time because the sequ= ence number is the same. The reacting node will ignore the overload report= and not bother to even look at any parameters in the report other then the= sequence number. Regards, Steve On 9/5/14, 10:32 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > if - as proposed by MCruz - the validity duration is not stored at the re= porting node, the reporting node always has to calculate the duration (e.g.= 4 min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and= the reacting node has to calculate the expiration time from reception time= and duration. Would it not be more straight forward to transmit the expiry= time rather than the duration? This avoids the need to send different valu= es depending on sending time. > > Regards > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Friday, September 05, 2014 5:16 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 > Reporting Nodes - Expiry Time > > Ulrich, > > My interpretation is that two OLRs with the same sequence number apply=20 > to the same overload event at the reporting node. The contents do not=20 > need to be the same, although the only item in a loss report that is=20 > likely to change is the validation time. > > The important behavior is that the reacting node ignores an overload=20 > report with a sequence number it has already seen. If that behavior=20 > is followed then it doesn't matter if the contents of the report is an=20 > exact replay of a previous report. > > Regards, > > Steve > > On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> I would have thought that two OLRs with same sequence number must have s= ame OLR content, especially same duration. >> A replay is either an exact replay or its not a replay. >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Friday, September 05, 2014 3:59 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 >> Reporting Nodes - Expiry Time >> >> Ulrich, >> >> I think it would be correct for the OLR sent at 10:01 to indicate=20 >> that the OLR expires in four minutes. >> >> A reacting node that has already received the OLR will ignore it=20 >> because the sequence number is unchanged. A reacting node that has=20 >> not already received the OLR will treat it as a new report and get=20 >> the correct expiration time. >> >> It is certainly possible to implement it so that the OLR sent to a=20 >> specific reacting node always gets an exact replay until the report=20 >> changes or expires but I don't see that as a requirement. >> >> Regards, >> >> Steve >> >> On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >>> Dear Ulrich, >>> >>> Not sure if I understand your point. >>> Is it your intention to send Validity-Duration AVP =3D OCS Validity Dur= ation (in your example 300 s) until timer expires (in your example until 10= :05)? >>> Could you elaborate a bit further please? >>> >>> Thanks >>> /MCruz >>> >>> -----Original Message----- >>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >>> Sent: viernes, 05 de septiembre de 2014 10:15 >>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz=20 >>> Bartolome >>> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 >>> Reporting Nodes - Expiry Time >>> >>> Dear Maria Cruz, >>> >>> I do not agree. >>> As an example assume that the reporting node creates an overload state = at 10:00 with a duration of 5 minutes. This means that Validity duration is= 5 minutes and expiry time is 10:05. >>> If only expiration time but not validity duration is stored at the repo= rting node, this will result in the following: >>> For an answer message that is sent immediately (i.e. at 10:00) validity= duration will be calculated as 5 minutes (which I think is correct). >>> For an answer message that is sent at 10:01 validity duration will be c= alculated as 4 minutes, which I think is not correct. The answer message se= nt at 10:01 should contain a replay of the OLR already sent at 10:00, not a= n updated OLR. >>> >>> Therefore validity duration should not be removed from the OCS. >>> >>> Best regards >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime=20 >>> issue tracker >>> Sent: Friday, September 05, 2014 9:15 AM >>> To: draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com >>> Cc: dime@ietf.org >>> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting=20 >>> Nodes - Expiry Time >>> >>> #67: OCS for Reporting Nodes - Expiry Time >>> >>> What does "Validity Duration" mean as the information stored in OCS= for Reporting Nodes? >>> >>> We need to store some information that allow the reporting node to = calculate a Validity-Duration value to be included in each OC-OLR AVP The= n, I presume we need just Expiry Time, and then value to be included in ea= ch Validation-Duration AVP is calculated based on this. >>> >>> Then, original text: >>> >>> 4.2.1.2. Overload Control States for Reporting Nodes >>> >>> A reporting node maintains per supported Diameter application an= d per >>> supported (and eventually selected) Abatement Algorithm an Overl= oad >>> Control State. >>> >>> An Overload Control State may be identified by the pair of >>> Application-Id and supported Abatement Algorithm. >>> >>> The Overload Control State for a given pair of Application and >>> Abatement Algorithm could include the information: >>> >>> o Sequence number >>> >>> o Validity Duration and Expiry Time >>> >>> o Algorithm specific input data (e.g. Reduction Percentage for >>> Loss) >>> >>> Overload Control States for reporting nodes containing a validit= y >>> duration of 0 sec. should not expire before any previously sent >>> (stale) OLR has timed out at any reacting node. >>> >>> Editor's note: This statement is unclear and contradictory with = other >>> statements. A validity timer of zero seconds indicates that the >>> overload condition has ended and abatement is no longer requeste= d. >>> >>> >>> Proposed modification: >>> >>> 4.2.1.2. Overload Control States for Reporting Nodes >>> >>> A reporting node maintains per supported Diameter application an= d per >>> supported (and eventually selected) Abatement Algorithm an Overl= oad >>> Control State. >>> >>> An Overload Control State may be identified by the pair of >>> Application-Id and supported Abatement Algorithm. >>> >>> The Overload Control State for a given pair of Application and >>> Abatement Algorithm could include the information: >>> >>> o Sequence number >>> >>> o Expiry Time >>> >>> o Algorithm specific input data (e.g. Reduction Percentage for >>> Loss) >>> >>> Expiry Time is used by the reporting node to calculate the value= to be >>> included in each Validity-Duration AVP, as part of the overload = report. >>> >> _______________________________________________ >> 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 nobody Mon Sep 8 07:21:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7BA1A8840 for ; Mon, 8 Sep 2014 07:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7taJa2RG2S3 for ; Mon, 8 Sep 2014 07:21:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A191A883D for ; Mon, 8 Sep 2014 07:21:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s88EL2Nj017209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Sep 2014 14:21:02 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s88EL0OS025717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 16:21:00 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 16:20:59 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 16:20:59 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4w Date: Mon, 8 Sep 2014 14:20:59 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> In-Reply-To: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/mixed; boundary="_002_5BCBA1FC2B7F0B4C9D935572D90006681520A0BFDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 26627 X-purgate-ID: 151667::1410186062-00002A30-5828F764/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/V2IH09I3-8fxRcesTnyZPUTrC08 Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 14:21:08 -0000 --_002_5BCBA1FC2B7F0B4C9D935572D90006681520A0BFDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent reports Host overload directly back to the Client, when the Client request was for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_002_5BCBA1FC2B7F0B4C9D935572D90006681520A0BFDEMUMBX014nsnin_ Content-Type: application/x-zip-compressed; name="#70.zip" Content-Description: #70.zip Content-Disposition: attachment; filename="#70.zip"; size=14020; creation-date="Mon, 08 Sep 2014 14:15:56 GMT"; modification-date="Mon, 08 Sep 2014 14:15:56 GMT" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAM6BKEWMGggXUjYAAPZAAAAIAAAAIzcwLmRvY3jte2VwHUuy5hEzMzMzM7PFaDEz MzOjxbKYmVkWMzMzk8UsWby+897s3Ll7X+z+3/lOREed7s7s6or6qjKzMxWkQUBRAeAASAAAQAQ4 m1cqdQYCAArAAAAUACSwloidrbOJrbOeioe9iZMOvbuNNWE+KDBlLgAY8B/8f43GpHG5fkZEsSfJ t6BDui8b9YKQZCeBw8jUivw9TRRVIXr1m8vbLFLrkECyYhW2xGI3mV5X7uSD5jasGsLhY6sJ8HdA ZPohiWNTX16YPEYvqSIitEabGhTm4ES5y6trIkeHREjVbYykjqmeIYbyU4N2mdzwaX3LdBh5d61S maYHKXKA2vFgL1Pt2QNkNSwxG6m3ZgQVkEdSw+7H4E5rk2GQEbCDIIy+sX7BbzGJcZRqfdKEyp7h 0NJ8FmFxcqkClaRAhyO0M+fnBGIyZC6443suJmoodw9MZ3AmnrZybrYRB+B9UrTBpBmZWNFOJcfy Qb+XuU7Bs5fALMdy5XHhrdqbPH0gvIRbFOwCf208fBwtmHaw52fGDW2QAE3P+E7IkomCQET1s/rS 3lkS6vgEedftoOvXRSSpNpf+hZO7K4LmhOIo9pN9Xwn21NJrUwreS2kEmsw2w9K73TU/yeYbFIac +dCH26zKJ5NL5fugmt7v8f78BAEo/BtZ8eOxW+5+t+R+cxHmN1n1HE2snRjo/zj+h6T/wR+ITlj/ AiIEG3oFtm0w4sOxDk08t7olmedGfAYSnHYO5AY/UbjW1VlA2Kawrnt0fzwuv5QRlLHAU8ILXmOg sZi7kqEvsW3lbtMSBaGgMaKVHmgGJzFVa2Frt8TAG5+UxxvNVJG/1xAqRMpPbMpSW6AdMtKl0haH KwWlHBs/gfMQXdHWNXz/FSQ9rXhNA87C7EqwaVidXW8JXocD2xfa9GplPAJtBMLAbpXekNpaasgx xpLqgRbbmnGaLCvesBKafccif/FB9FMv6lsILVQeVMT0nbdLJoimLoLzar7HcA0PAZEGLbqP16tI UAODOT/Q33Ekg6epH+r3lUYQAAAXAAnkZudozPBfRDG2M3Kx+b23/bGp/ZM0QL9JA/T/+6SpTJT9 Y2UPeZLc6E3nc1DKFVbNslUosiXC7XEhFyCuI5lGHblgildSUgyRZU850vC9ajDr2PRpivklKN/U AJ1ACR6w9KOjuSiwxdrvCTRQfV2bYyo/EB/K9eRi8hEMZ3IXUdVFgviHupICkxsO1ajKimWkdhj7 OepUS7rIifSqxV21dFIFp660wIP/fZ8yriPYR9x20MgLPenn1UVkPvuv84kysfGvxAcU+HrxXNrf AqseyeoDIzDBNOOWhdSkA2cIIhXTRCTRxXa6oCZ5BUDgHrTfPEfd4UkCu09EqMLY0ozctRPy7FNY fKzJcc0s4PcMpCD313IcspwNVcRBPW6W5+z+drl1axyjLkMAADyqAACk32f+MZX+PInOdbTs1jnR ffX0P0F2wUx1COWsKSyUpweCXJk34WujoM4n6GvtGkWHhU2kpEcdQCZit2MxNPLp9H6uSC3UIzQJ r87tDjsdH77d3y1bSOJjygdxttk6y63D9REzPAb9/Gi7Gd4sWVINKsSK8cYeQmq35a1vvHH6rPF7 tti6M7JjN1EUvw6nvODbuSQdT9ha1TiVXUkqLnHoI97AHfb+wvI2ejVdnOSXRkbHkE3OCiMuhGkc a7bp+mojIkDeZTvhvjAfay4LEjtswTs1IO95447rLuN30L3T3vH1/VY8kXbbfUgDEnuPMgtUKl3A pu1qfmZQ6iMuTDbLPTX0+elolN7ujivLiLc4j9gL30lgt254DrWK4/RoLyLrsdjNCjBIgt69EgJ6 l8VFpowtGjUMeamO/Tm4k2V4PbXQPj1QEPkNEMXvboH6GrvHQnSH7z5LoM2xdlHxtBlLQI/tMU8H 7ll0ExpzQjuhdrWRkn6QaNf6hmkaS9RPQmDuvvkDbjaI55HNKjMiQ9uHonDW5wMOvekDM7Ld7IWd H+WBTVdqpXo67an+Y3uryetABJjqJqjmgMQiXq97zgKZ+aZZplP5I0dy7u4p2TOFo5PeGlT8IR8z SAuqaNAc+n1RGuVUCB55SmmIQL1A3jdKkt0guCyATOgghCXn+QdlzBsUFDNy4UAQM7T3kINAxozM x20/n7P1JNae+7VjygCv9Ogx56QkrAj60AKFb0/a95BYY9FOBtIosrjuYKA4XqI7KGWjfGxIs8+M ugUhWjgPMIhpiy/6fWShIOL9VISw9VK84+QH4D1g8Y35lpDpv/KF9RidghX9A3ycTn+5xXgy+qc9 6VOESLP5gxn2R9/CalJd5103BXiWJ5x+ir+lijqI/+Qzi55BCkUigdlkMUR5QRxg6Qoo1CPxi8hN CDwItXgXewqOyZsijj2B944kkTzrkFBmgLzcIRfWkguiPMoREHyA0hJAwqhwKwzQrZ/4/KXePAHm +cwz3gj9ShchVnDPCJuocTo0xyNzxjBRb3Tkki6cTk0Zxkhqr0CgP5pyX58XIYUrJMLQWKfWD3o6 tCN4LIM6JUrdR+cfrhBdCHUHHCxiDDz/1S3bOUgbtv4bkCR3HmIhEoly8P6+/7Nt3Pf+bmxQD6vz D7rYRM6QnBrw5UR6lZqjyBpfJW2ByFiML0jv8mFiewwmMyavtQV2iQZuDi66TqF8/Kn+p9O41TZf 4SfYxhyBCHusXbfiAiJXpOYFK68/vxeUTOXll2QIxUZBuvd7RSFS+VlRNbs3ESUUoo1dCxLN4fAZ ki1xEDpZttg/jU1szn36/pj2pTVo+fWlbHK3Nai+FLi6fDLgpAeV+0QQhUdNn5qAxoTIsYgq3nZJ eeDNH8VwOjKcKHAN0eQdGVnVUasRS2B7sAMXgsLgbNlkGH0Af57MeXONfVJrz/J11tL1onO6+pH/ cP1Fjd74ucTT8WWxLS5Bzb9CW3JxNYRAXetm4zR+sdkMxkWlzEinZYF29my+5Brx1sP2KEf/kbvf syzp7WM6AKdhmdtUtf5I/MwlRu3uDa534S7TYe7t3cluhStA8gHcbZkjZ1s9NpmpNXOak0Dhe8/E WpXq+uwiE3fk94NCnHek6bXDB8P6DmNtX8gGAicnTUt64373Z3r+DiFVuVPp/Mx5fURToOXHntke c5+huzcFrOk5QRt3l/j7CT3t0/uKB3WyKpjYhxGjr8BzDm/Cfh3mldaSFvxv280vlA4GY6n32PKc Kf67zH3M5o4shFglhsmd6qbM5x/+hyMC8JusOfvKee85TAJrHY3yjdq4Yz81Ds1vW5Z696Q0EUxv XqLuvzWYq6HTPQVushIQR9ic2bS8DpAVqDEaLibv9rYBCjzh26B/lLNDFKOZ0cveRbCpkHW56GsG aAzGimWAzAc8d2xZ9npl1OCaaTqY3lX5INo/EwsJfixxgwIlLJGAAn1rrUrlQQCOnC6y79m1CCmZ 78CRo3PfVZXadituimSpiwD2so2KeJufb7u65O6xzkt0O24mJimcn4ioy3kzibV0yHxWylz1NqMf /5kdXiTnqTOUMyVRvzdxixzdd+XsQYkEV/bAapsvH77AInevyiWharPdWRjGOgnOSSWTCe8ifbUq cS76RiwvVre/yotUZfZZ54+Kg+1AOtFxEOP7pL8upDlY88eLjImj9ajqcDHipU5b5aZ/JYNAzabo Tdjp5agl5tS7Nj0w/fJ8BjIx/n1zMiHx5MDzUEXxe05/c91x8hk1faWlE7oZRFTBdPQoOe9UPWK1 ySEyN1OPcL/315K3S39dtHXVJi41Z31ushPmge230Z9yE05MNTmjzqgQvj7TRSq2wyU7vkNYrafx fnmMQrz0OXebCRJVBcThs5QI4BQgdckjbrZjru9N9lfRMD61OpsIgtU50JyneyFTVEScM5nu9QCg XqIp3y/mum6C+MWxb+1EckpD/G+vKawmeOGEfA7CTRqllEyIwh7E6MSDZPDTEjZEuJyxjmBM1CNv SLc9GXGfoNZ9ou3yLLhC2zZu9JoXT1WPizrH9W4Os1Ytn+txo7VjrGm2HQalRA2cie5PG1iSKGJm L0WnUHRCPlv01ar8oHRnZSvvIRp6J2ati/PTXFeNlxoyJWbRdLw6VWaMXOFGe8MOmEN3ScF1Eg74 frjgWwUrCxVy6UEf8WiWnFh37pG3LFRSmCxWApzucO4hRVM/KY39NdQekMC8zMfkjE1QwV72MLvJ TFB3gvGLorc0aArGhbFWJb2HCYGMoLAHrvKUWKkoL0zLMKQLzdE4GYsRnPcnUR4Mn36M2ccQIdFX BaQFyxg9bKFXjE/p9qvJagUyS7DulMPHChkxVXc4ilpzgov5HiVlXHphBcFHgqwxTWQT3isu28oy wFxeOGcLy5Kpt92UndNsuiFS23T8HDaw8WCLgiRrjE6Tbj4jtuYeKS+/N2F0f6KiNSGyPAtFlLCt VF6Xx7BzCmidvXJa99VLou2df+UTVeU1Pd0SrkErbiCxElrjvPU6zTndDfC/ENw/ZBFaHeauNvFY Ru8KTvX5eefK0LCoR6f448uEUyv/Yr8EealRi1K6HL5Tg9zRF8G11y+vQBqy7Y5MLQhP455UkPQK VeY0yTpWHHt7ceqWDBBFbreRRutUzc5sgrZi4EKF0FM8WVMlzWO05/b+OZxCdgMKqHFVhaBfByqs bDrgoc/g923tTLYuSqJFxRpTxlxSxWvGyp2rqsYMYrZdLxs4qLz2is8ZleKBBRP4yNfpZJa3+rQv 2EoXIxXPweIjfQYUFtDE9DSuAaMpXHC4Sa8jCldo73kkxs/GVbcX5lqaVCOeoxhj/ZHvxp1tsbIE Pglga4tp1mYimSptnQSP6GdxIEEbI67IF5OqbgxbJxTRUcT3O7DYNmRnG3P8eDkgKbfIqprnG3Oi Oo/0TwNKP3pbDwcoMY5UcDFXypZacn+Y1pm/U/Kfoi5xOWbPlBylmBQKNXiz0wQajzYkgizUYyzC 1mHxZXngS8+jMAvHGGAX39T/XIym+BZZK6n4c+86FTcaPcOB0Cq/r7VHT3xU+O3WZv8lm7bwrLaq OZv7QcQ8Qf+FTfUmO7IEHHmV5wdXYB3O4Son0+ea+qwJ2/7Xkv7o5wwYI08ZfD8tIhkKRH4kbE+m YdrOTJ/vkdOjy6bPYy7I3pVIR1h5RfjmnEHGYrexQHdmuugDimcpDgh3iakMJOo7+mPqXFQetnjT utVQbUhObltuNoGXbDqdIjULvNvMHJWi+8dLvZcmVOY0YUiPC08+KUz8cMR5l+So8ZnOqwPs8j9b WVEeVgs4tVLjI8fm2gTk5bhrgJC/9TMHss1XSTyBiZ/rFhKYnFN0UjGFr7UGRhPljxZBjt8d4Otm 3YwgXLsCaoz4D5EPuIA9plpVXvrv4NZGuKWdOT1052ND2DXxT1RNjLOE2mgPgbOLo5cQp1dR0UV+ UpA7cTqyDhBwRyOKq4elnEq34RWQdRWlzKX1J4cNPjh5nUrcKC5uF7kuTDwk1KqjLBxReZ0kR62l FOWZhg7eBO42dus4rrkkq2QCN+YTOStZilFxgqtrFmpW3DVtBQDFmSqJXdZ2Cno0nv7ijVem9qij 6KNJnwHVRQFGUIeGlvjK2cP2FUpCtbkPa0y6C1SQ41u3pGTIA9qz9kFW2zUD2seI9Enhlju6pfJF j87+3s+JRAySFTjieMTN1CUR82IlH+asr2Nfufw5QHiDmRD586SPn5MrHCC2TaUqKsimCeVdVdJD DzOTEssmmVWTqxPdRaRPOvDZYa/dgx+uYyWVooc5U2Az4PVtTLqmd9ux9ELy5ITe+JbfwCUqJmKh fZHorFDyZZv63Vi6iMuc5Gp37AZqE8By7G14scvKJD3wPBsQo4SjYcvAVwPasbRjyRdg6iWE+fBL UquSbNnNZOyogNcoKTCNjhWdY8P5siI8AwNUEGyh3cdHA2dyfMNpMQnFdL/+YFNt3dRGk8eaMxxs wd23NdU+dzTadTdB69f5xozqwB+jKlcblFGSivBxObv5CjrH+KuvfANURjaCMhGMuYECep3k4HyJ L8Dp3l7nuiI9dEBcfqgIraB0m3saRBLoVNhFMPZ8rPUT4g+X7Vy199s8I+I7Gg1F3M/q9aTGGPMi MZpeMKr8TbG9I9niCLJl+KnG1duHCU4LVWgYnV44xzq+/brjTvct0XxZn4Ko2LQcCSU5s4IWjv2C G/QlS6trCXlXQ80Oi3nuOwP1vS0AXquyKb6JuEV7oER09epJO5/46m0tyPmO7ejW2ZaskV/Sp4Xh 9+z5Ykp8DnIby+R+3nI+1h03RDrRTzH8pFXRmuD6kJmUjhXISlRohKY7SXZnY8DaTOMOl8j57QEu ZeDt/CBvJIqptE2d48BO1g13zQAFHFptp4LkcuyBPW9cQ0BmdagUtURZUk4B4BCQcII7x4Hj8ghT 6om9ByO3LgLvCRFSqh0EsrFsfRrHxssiKkOkGaMqqBEIJj+KfkBiSLnDMxCcTZhDlMOL4/HWEsfw zV6XP/6YoDtnMBmRhpiZA5s2e1uJBePh5IqHJsuvMrv2Fn4W0F3FoGVemt63Xn8p4NStlq9FLK0V srba61Wu6uCUE5ErEiBRLVk+XrE9n9qRLYM8yuYRn/u03s9zeXDEBTwpPJkHd5CKZxVjch7ImoI6 oLVPWvwNBbWG/rse1Z0rfjzkWG4Z2mSiBe9Fm4SOr4I3Qlv6+b4BIkHNeKQcNy3BT6g2OAKkMHxT fZ+9KkE0QWy+eGVyiwvcbNpxutCi8+rxLIOQq1eIsGB8tR9vWcuFGWWz6MwxXCZYKGc6CGcrkDZ7 vWivjHlxF6Goxjdwf+fX543s3nwHBgDmYP/k1xvZ2fzh1jv94dcfqG3bZTAi+uY0fvbeKr/GCfq6 QFGrbNZLJZLbjGmqrmVAfDeEszbOmHl74sORzKCXzvOy0hNccdv26XqdGn4e1MmOh6OcLII8Mf+p DEycAoXRQtTZ9cKcqpwPhwI1XugfZys0H/Xzvf2OOtwkO4gxnTB4phfcTdkosufOOVN46l4BndDe iU51Cta3XIvB7FReA3amRT/08wiLQ8vu/NWsMSCeiC4ZEjtcaMqIrEkb5wx55CF9eKZDE2GRzPai NcnBgqs9PDsQlksyT1n3JzqdHxU2PpONEPswfN1ow1I1dZuoNGpFLb6H2nx14RdoMqMZ7K/fH47g HQ4IojZJZ4TPedsUVmJXmUexMHgwK75RPGyj2YUP3p2uZId4ckIeEXvOIJcBZwejiqmDVbKWDazp mkUOU7XuxgXqyKf2Shr5seL9igoQ6MaeDBylvX7Xc/0OY8s5zvqyyXkAjKG4OQpt8P5s+HbjaHmx MYe8VDkxUYA3XvQrb+OsZNXUvxgnJeReme6R5gfLQtRUZ1Zag2pTFPdBfSAb5TmV+Ru2Fnkwq5yv uQLJkgId17glE9cr4+v5lEF+jWiJDNDqmFK8OnE+ckq4g/PMaoKj/ESz6vN2BN6D3PkbHKmaUHwd JqRONTAY7TiT9EahV6vY4FsF4+MetHMAJBEdqrkCTi7SySn+7FTKtw3B0TnBuVULgg+PmGgvK+Ob FzbHH0NV9rrqUSTpka5K55E+qXkozHllC8WzsnpcMi9jBty+FY6cadkJ0nk0ClkZn/aLcvasKzhb O96DSPKphNvdVXKfKMlWCU5P04wbEp4fcvYkDdOCvrLEtUYLojY1AljIwfxdSa/sy5VuTrK68k58 icv4bujQP54PZ2f5/jY6ta8pRfEdHABQxQEA0P45i53NTWxM/uvI9I8IlYasHY4YZhfJDYG4l50R hSu2hEv5Sh2OuVL+Ct2pQwfPVpapqxkbi9wpjmWspGR4IKdCBA4EqIolGf3hMmhkruQ7TAdLQ/tW xDKpBYmmkI9kR8N0x7YeS5fnhe7EDBFSwm3hxSLDMq8ocg4EK9T6VpXB51x6WGGflD+WvOR6BvKJ zrr7Z2eFu44YKTnkI4UjXkunZJmzj4XUS230oUl2AuhWTGt4XaAEEj0YMAHQZiod3bJlhTRTcUQY Mi7IKh5tadKvOfR4VpmOmEzvWKBYUanOHRammYGI9mH/oKC20JGyc+YAeCYrrx7qHQkRR3mPcIOy HbH1irTYlkYHF6gas4xUzdqWxho7/tUuaxH7Wmv3SHsVxqonnCoaLTAfEH1L/OWzh7ZOT6FpQO1V ULlaCvOkuF/V1qhFiuDjGe+FbZWG1Y9fyO/JXGlaWXIlq2PGdaJwI742E7u/exkzaQJhJ4i+ndnP wZ2xeVkexEEYpZfV/1TTqIZDv+VPLJ4YxNXoat6do8hAaDTVTLNrBdCrMLnGgs7Pg2SYNJxAaWJc MfT+HsVPyJpgIIZSWEyFZURA3Bq1H5+r7tRzBvp9a4VMb4rOwlTyJbC4/MIn1XAkEqvz+7Sv+/M5 FHfX5/2vj+lhBHzc7c9RZEdXm31S2ivPm81jP74X0Pfng3UMhO7KoXHmjxYCgfeH7wzlAXECLA7Z fg+/nkpic/zeVwm2BSr97aB5qfvDWMmRN0klzHOGc1PrImm4sCLuLjDFU1PcrMnzBqCWtKl/Pqkc 5NrJMY137I/MElWD2cGUEqj2nCW2f+sJkpRBrdrxJonE26E/ruwXK0KzNdclY0GgkFKf1JYZ++ET jVDh7uaw96uFQyrP8cjghHIrJpzkCL8/oo9IKlz4BU+AsFC4nSeJ23WzqGsnIRatTUQRYv5LIuzJ SETxarENdpBesSp3UDfe+vmWON5UeeMWcRg9cj1wA/RuWDCXacc3CuhhVdIwTlOToCt9NFUorlTo 7ugzKbBseKj9UgxEcxs0JW9Swe2EeTt9So1k222T+RUxaDGEcvNL/anxETrfmRj7TDUDCNaIsRWE A6BgSnEvbdVet9YMohesN//EkMsu2Yj9y/mKXjpsbuJJYNHuNEgbsdJFObBvFrfyh6mKpcNLLxhf v+UB+D+PFEPkt5eEO6D4yqhRmuWTtsV+JIq1jIsJbn+kt4dQjOIHMObY8V59uWxPOHs/lr7M9+a3 ystaVKNs97StVa5Li98fJLlNZWZXUBZ3LUxLIGONzEWI8izgIk7Ym0gSv2ajOYenR105FwqsiC2L BEeSM+ir9kqXpGSZyxOl+m7fyDKe3MiGX+xsghAq62NcCyZk2DQO0t6R//0uUUhoqDFjJlPASZwm vUcjrUp7NDxwraavsjqEm6WlDWlygTtMK4+Z00GXTZ22EgoFMrAVrLIDOsx5EluOPDVecH2TfXuD bggG44QYa9ffmH/Oc/q11DYzaTiyFdZ/pew6nv8oy7AJuSWF/BV7Y2qvkLl9CNi19Ul3WNoDdLqj EOVJlLu+MDOTVkjCpmZR29ZzZNhiHac/D71riMpd5zQPoQHRNsybzHolJ32CfNxsy/owslVKISwK 2uqJKySLOw66rLk22to89asGZK2oU/0tA0dvJUaRf8z91zhDE7jA3RgpIFdnHekho72K+gZpmjXX RyaaIu/8cEzRXiTsuoiV4R1fvPJceUGyDdnUyFyCHXJZrfUOxyinFOfDV5qghrPUIqSpsSq5Wd5E uo0DB6IgD+oIiDbVMdsknm5q8kMGyWRHzM9pldl30GpoNeALIIJLRzBxbr11fAzqPYWQufAXH6DE oDI8RDp7HJgaotId8dU3jAOFzxYuM4vUxlCUnLUSImTUl/hIUCIvhRSZ+yzhyuwHeukEk2AZ0eSB 5DI0L1F4KJxT7B/lXu1hxJAuyrL1zPr2FPvTPlPM5qinRCWZdnJwVJ41kwF+Xrd1o7BfWl1WYFlb 32GQaNrKN+2ajztbKsN9mXAasD3UAA1KNOYmFp+RxJkNi2uRbCU3jiwY8B2cNUy06CCK0Bj8kp8B HxIh0+FQRpsKYd4EljSBOdisTJA44afSrteCbYJrg0iwcq6z4InkJrIZMXJrlh4NXTtSLTtefSua 9Q2/XjOH6ENZvmclRmFYnE/0fau6WBNWDjKTL6akjblLjHaIftapeOtHIdgEk7DrBfsMprIIhPJV RcYUnw4YBZH0HZ+13vyF83c7GeJjca3X76Y00Z/sMScTZ2cLW7N/2GOZmtJO+0NIXSXUn0KDTsaT r73qZ+lmmQu2CfWZ0raIUFKVZFDoAKn25weLuOCmSIE27VmxnnvngpKc+c23jzCG9otF6XWEDFu/ 9p3tukHVdj2Xs8mPG9ebmpyzJi1tOKMGPY512+0t+q7m/r0wBL+334v4eB6exBq7NlLEe+25Lcb0 uy9XZfaaDov2FXtFF05b2I3n4kXKZn+/6WL2J90U5vvFngUuwnhGBsuc22beJkpTWPU22/61zrLA ViajU4vnVtPrjTijqe2L63r0wPV1IxcsS9Pmp3QM/wMrisdzlUjHefNd19cpX6vj5x81Ot0fYPtP tRxEuC+2i/AgUq4tfHhuy9aPLGkGr14/Mw+eHZy2Od6X7cK9CZs6rdeWaV6WEYveSX9e7Jlqfsov X5i/zzzSILOuBhpQ9KxwVEwLNDFkjIqH7m+5vM7w2g3nZLy21/FMLNA6UUSX1ISVuPqpzHaPWpr+ QH4B1eNjE3Wyfm0XacgPKrYVeNx03Wq5/NiKKVvH80zoxwraSr/5ZcO8+MDIxMv3tuCyHz2UekcM 7tKXmmuHOOTMCi5cOEsuGL7UJwnJ1JEKSyQXdUpEiqkDFiwqdkBIqlHM2FTp3BdHXCAbjm2WbhXe fzItssX5fVToxL4aWuDsrrOSa5k3m27Xj1AYjYDIro8S3qSnKBLMMoBfGTVsARamQx8SA0wTkuKs k5CjonCAuXZMDKbbyCUCc9ji+EYq6wZL+e6LPs5hr2RsE2LrXKrmAboWWuwXzsqcUpb++qkEsWjl 4G59CNUi6HcJRny+0Dgqy1JlosKjOA4hzwqFpeAEZbF0lFAnmE5RzDPmoYg+LEqQ+EIlBQFimMTc kHBanz5myg3RkQBShOpj9/et48KFb0Kf8XOY5w9KiRx9mMQx+lDKLAl7DAmljeJYpQQnhbeMSpJm Vr0LHZNIToIOCMNWaUnt11nE72DVNCzAY5pMFWwHgg5TzI2KgaWkcc5JhiEiWHG7oJkYkAn2B8rp aJlAyXXgr7GOE6ilBIfu1KkcFIGDxzf5O+5VHa5g0qzh7gEtI1hTmNQaZ3WVLHfongVjvKA/ycqZ dYnYJtNkFLjTpQ0Yv6lN9NIWNCEBrzWxT0BTKgpDcT5aMmj4Iy8K1ULbqEBYSAunlAaVq4pAWgAd i+NxxTKqnVBG989FcIN6z4ku1FYmGsNaylFI7QVoJ8aqmHdyp5XWwtYbctqd9dGvfCP/pPvFKxbu z0VJzQLSSr9k4Z1tmRTMGbrel4en8IMeXDM/PlAv0DyIpDI+hWckY3Zp6qHv9U0EESNXFcuIa2kD tDTVyiq6j8Il89if1LIjaaVBJqVXkIdxVeFL2EIkE7Y4hnLrcOusSgUWb6zJxJ6MFdahp7lqipNB 3jRSsCHB3hr1/o1NVkJDOOZwZLBRTZNzhf/sIPcJy1HMZQHSWkAM785rk5HKd0Ebnt7CdgAS+rZX Fir6MB4FWZEZKQeFi+FMOe7hBcBkJ2ns1+VekhSyU5WkYyq2ziBudMQ36ggYigdnhIAlr1ZhVyFT b3lnxWsYbQoNe157MTWopgtqVWeF/Gxi3inMbJgIn3UY2fu4o44DqO33TlaVLCHcwaQg/uMybjiF fGWLUJ9eK7EipLdvqkyGllOk3kH3QlzaN8ozdcjiJjkygy4p8kuolSHGUSFzUNG8aNkU19L4uKgP CLkP4P0+wUzxhIO9lVjRI2hO+jEzjJegVqSXi4gDMOpEELe03jXEknQz1SIKxEbVJ6FKub7C6BoG mX0rIYlqu7UMwdQdoUs4WFAQY3TMkZ8K4KjVdNVp+TPIX98UNasYITS/Q1/QWeo4CJAqGX3rNceq qvuhjJyVawt32/qzbEkGETm14hePlGdsUaJxjyIt+ZemGWSjeuQnEcMjcDOzQFKQBqeJlOqVa15j nh9mGFFyP/KjUcX4FuQNVXCEBGRV2D1hd6OFafdiqg9wvyJLJaLnxpBLYNC7z4lSgRxfiEbk6Vsq glurUiWoGmSS4l5uFk+wdfUXCwv3MOfC0zUPTJT5wdlQOGnYN2WQPSGvmRdfYnyD0JhVhfSTUPyO PXRWyZUsLlmiYRW7L9RcaEsZhCvb0yQjt2BKc82jQR4qr1kFPSMdyTrVv6LFKv3jg0pTcgOIVpcc ykTwW0+aoDaG3Rnvk7seVnIP9CVjcq5VoEceafWNTSdpnsMSrZh26TGkEsi9p+WuSgwXpQqIcE2N s1//O6Jl0Q3sRa5SSm+LP/WPvs0l6tb4VBApPDPM0YrCmSiu3K26QU5xMnAW8aLCCDu2RSjLG0Ke 0qlgULo67nJ4g6nypOybi2alEvx1raI0pOa4dC4yrREcF5LzWXhbOSO29JqLlHnt+5z3NxULcbcm nhg45Yb2K47JxRILxy8irZu3XZ+4HK9YvttzoC3v6I5P3gIgNTXy/gHksetfnHqwBEXmUYw7seBb fTiRt3wtX4Y5xiSALlP4tIvKDrZ989jhmNY/GHyevDkVfS4y+vWerDSzBUbKnjwDbR73hydtdQmy r65MK/ngFLqB+K6WP91PKAozOIA66SXSPVoSg/nZX4c9Tn/Y1hxXvFmub8s63TwqO3HO9CQ2bwjc rg+63v1ivQXr/HbfbPsyPfz9VcIhNIIkeot85aZIQ5aiYPM4zKL/JN41i2Br6aCDfHtpoaN4a+m+ o3h7aaLDtJgt/aT53bXhU+bu+NlB0+9n8/plk84nJ8MWvW8T62iUL8P1Aq7m3BkrFznImRzMseKt /UO9dffMSquOnfjLaK9Bwxabni1GYFa6wfHm+pHVE2/XOo9iOjvBVpVuVUZdHtGjoupVnJRL996h S6vtVxzmkfaa9tcWofscuWg7jn73Zfz0Lqz27G/euFmfz5JplE0lekLevxj+1uem+EgV4AICAAqB AQDUf1oqbiaGyn8yVpKUxm37GBE7vp4KiHZhlMyYiQYGI5Zka74ADW0hSjcv18sq/Xqhh7I52VeQ 072aijZz48vq1EhsQswX/1p/pjjFbI+c7JqR0Fmd8hWBNkqKkwyWm3IVnjhD9TvGfPVP/XdgKiRm 08I9Q6QvS4UHMFMF1j2RnMII3yzZwGmQdfpDjXSsoGCStGDobxyyt28A4qSOiDgXJDzlLp+KZ4yU BArC0cYD6ULT0BfqYvjJtvs3E23CFQmylxQc+683+zZ6egVrdM7STWqYpzk3IGuR16AuLyNHOatm nRYfkjUzn0NTTGSNArcHZtV9uzH3gw6sGuI9PxiwJnOAGUgn22LJsAtbI236ekO5HFzxnd4nZz02 7NeeuVS2GPLsPCErTuwfvYRyGhe91A1TIc6JQTUBi/Ifag/wfzfUBIECOAq/hzoE+A+jEBLI2M5I wdHO3onByM7R5L/Tkv+TvPWPjD9F+X5C1JBt2TcEuCu6WnrThGbphfNRMnLbtJuYns0vtI1A2i1+ DBfNa2UI/HNOl8Nc303vgqrz+dRLLBNJ0hFRA5CaVEy/FzxYIk0rHPByJHxtCsDF683zcPBKjAiN WOuLqsKp1Q2IAh7lJE/HTd7igDWi+DKzQdZrEPijquqIH/cCnkPb+xpvB4rITT3oOMHrG4/+Bqyo s/gXJsIMea0HABWjSm6ve5iF8E3LctDi5XSALhZX0+0wuTP3MF5DEWdE0OvOgr71OrvFPL/4iPzN +u1zUw02zfzFFwA1M1VqbY+PTZSLSTJlQUwgMjMvchuZ2sazycqTWoA358f1x1I7EozXYudXIRZe /lCe18iSKCFxIlYe1Q7KjPsbiybBweAZC5lLI2at2aQiKpKDzihXtu1kTp+ZY/9PUjmsLF0UBv98 ee/3fdS/T7nlRYLZvP/dDJUAABD+t2/i7GFt8g+yd2hvO81zIvp2p70S8Poer5FrQ8MGWMDgTgCG 410vNeqSh8KMDq3DlD5etKqsxeqq3Ftcr8qaaC9a1gi2qcuaGfQ+Vwp73dIwIsaOdlftSgwIGyQH pVx5EOyqt/k80MHFqOrVC6kT76510XfPvnZ/3N5eiiluldRDCgqqdYwc77bRtjDIyUWa03Hk/5K1 MQG/UqPeDkfGv1tHadIki/cuyN8UNz0cPbh3dk0YV0kC6FYm2iCpzV1Szl2q4Ns5oY3mA2w4yuJb kKTQu4AfDNE642nqpMeFBY70bk/rPPsIrlTU0Hs3YRRFpRzhIvvROaSKb58wNOKDr8Uj8zsokWef HavMXLoiIufiXdMGpNzzkaJyCO/aJY93jZVitS3g4IeU4jeXjOq8b4+qKkZ5k1YTM0LwNQM3PChv KaJg6M5BWzQ+nZvb+VZ4efOotZACdgWj1ZORcSE/ZoTnRXk8HfkrCLoulTAR25VUCSkBPdp11yu1 nL/QOjoYFYHtDk8LIrtG3RX7ojzC1Rnd73als0t5qa6Od++OsVHAMRwTO+T31E9zK4ds612Qx7uX mdupjDsIPs/wQtXJmJTaK0EfzI4xwSyQut+RRqvgmRCzoC52pz2FygfR4eGpG6Uf11IDwKnhP7RE srEIXPMri2YsUHM/JALsl9t7BVE6SdxAKL8XnTn/CC/pF3vj1wYFv2LUykRYBh5xKpWQseZUlHKz LCNG8a7GK56ODa7UnY3M30Kryj3RmY2M/92I+/m74b+FRhf2VG3+3OImNp4l8VUUOKICS0y5EZyq riaROdnzXRGYG0fSRbUMqitce+PIsB3e2cCm3CeaFqPdREoZ7eR+17iV0il581ETtLxBbhPC6XZ9 0pUuElSOla84B5b1vUm9mPkXifyebum27HXTYzBE4hTyIxlavHYFa4qHPZ0fZizzkp9ab18ms2cy zs+l2NGLNlh0K9rWTn2W2Nn3FMZbAXKwtR1z5klerRMUudvdCZTvvrs5xpnn7E0WkCXxabtOoRk4 iKV7Dih8i/SWZl+v6BtBKLUYDwO7wZLkZ7ZRMbq8L4wiP4pR+RT4hfyUf+BTEuzv//BblbkTP9gG VvLManB6+lJErXcxxw3hebKbmdWLHtgM5oqs9UyawGlmdg3kA46hCJqzQekw9jiYLYFFae2GiSrD /qK7Imcxs4VlJGENwVZLDltpoD0OMEy8/PrMN6vH6xAFVN/IZ/VYfLdgBEQpVMhyr8ej+piTR4E/ VZDvPbJzliAMztpYRnFXaq7Km+Y5fH1T2zcMwFYDwhLs/0IEMoJC8MESWxXhHLc7GB8wWGyiNch4 PjLhPWVqCjNAA0SyKNv3PJ7Y+aFuviwLDL0udNEmJWjgVaI4br1Jqh+jxgGlnl2++xQ/XpYpW3dW DGMsDxyMFyOyBZrrMJIBYIX3QPEPTXQTGHE/kO0xdAo6VPneASXIGXKnuA3ceiAL+H3KoP2Up6Dt Mi9pn8BWgtDuj2fY3JLn1nbuk9gBo8vtigqDjCvhAVnh3pID/l3xEJEd8Iz97SUEVmwHlLq1bW3m aQIHULgsAvoImR0wotyuvQiFh9GSALcHisIKvGUiB1DIRRZ43poINVDURS54Ctk/9IOKhIT0Tq4u cB7Irsz+PgCww353cT+OA8ic0+MpKFpiC5SWnUNdzmU0AzBQDAFz8MczJuGyDmJGf/08kBU04CmV 3QJFbXbDDrb0+OY/6KoAMv77Fph9E8bffbQfEwng5PlDJc//s16u27/qHc34L73/HAcDfXjyP97Q A4BoijQs+1upgcT/VfNLNt0GBpmePN8dKNBDtpBPRQAs5w1nBLS6zXWF9igud5rx50VcgP8DPFZ4 9nWu7Y1SmR3QheHTAgqhcalxGjl0jfP2Ph1eCZKBp29h4s7LdMVOp4W/RVV/HHeHB8imiG07YjPF yRDRTEPHtvD4VHOXRnWRUFDc5Vm5pn8twgUIK6iqDZ9n3eVdQMSKiirc/rYNjcobnufWnufUyYkz O5+P2oO4YE0q+p6rgdD4IsF31VeULvAYpB9Vlo3gOiQ/S7nzLV0MtrYM+s5uZQf5Wk4Vn32kJTpD Tl3fP2BNj/A2boKJureKuqR8Rc06LHwXhoDkmBRn1RDT2xWK+OEuqmgzdeiV9+F+HYoU44FPBvzC 4ETBvEEwGOh7pUkrzgF9qVbR+lxQqf5y93iOWmEhsqCUXLT2a/nYfRWX7QQZQO6azBTrieK7btY+ qXQ0Q+c68JGTXC28suiKuXW0VenQMik/g1+QY+nSbQtRZpYIpwmSAOsFnG4QZSfTDjhtRJ2pfiq5 7LIqImnE9q0YruqhGcnZZXJO3ZzOlqdnyMYu63qUgC0vf74p8/lp61uJTbc7LARxwtsRKKeWHCn8 itQukkWE8v4KPsNt5McNl+sSK1MBhIoeFMW5gHIBHW543m3NfJhX9Q4P+9hl7l6X2GMflMVv8jJ/ 1RGZTjB4LvO6pvJDCWdzukMAwApHXS8jNF9hKzR50VpIw/Gmhidc0rm0wUGWMxldAk1BPqne7dDm kc8sR6HM6Url4qb4XWrj9CI0hcSNoDDWqAjdwF7K0E7v52OfbNsjm9H7Ix/nV1ypy2KT9Fn1TolQ /PQd+KUVKjmmtaBpcwkjNH7hN5IC1yKXvqbSYmcx63FyrAFXnUNNBh7Dtj6/89rqUmeLR3vVnunZ oJnNSAb4Cq4PBWfr5paIbVsjCOJpwc14Ex68dPFahhmYawT4HT38nRpj6rsGr6iW8s87/Wn2azvk EYgsCF/MU/bhIknlorbY2EWeD6A5pDYElHoshG5iUYw3+RSbbJPqQU2bYCf/DQTRQd7KbIV+Pgl4 qo2FvjlWe5YUnennhlW/IQfltV5snhyC1a2DdFDjKImRvUW/vzWQGD2UxiR/2+iiv/8i/9NAMrWz dVYxMLT+h6HeqCptu86IuInxEw/0Ekexfn9N/KDHocAEPcYLoFlMC/wGibv2ZWrG5GoW5579go8b mQyiKWtFzgAaMRfLktPb++rm6FFqVL+fDrIABVlHEdk+K61opiLYO6MkJ5QUMHyfIFXgIZzNFbc+ OozAscjJsSbk/2mFuR6MOpW8zxhcuRPZm0zVOqRtW2kIL3BBzepBz/wxaGw12ARj9AUi7zCBSxsH WhHYokK1RKUiWidlyRgXkKE6t6wsY85s0Q5TXmcK3Z7NRIWuxhqRYAHC27cROho8k1p8j739MF/S +SLb1yasxgizYUOhRDCVhnzbGiVMBvDOR6WnafsVqtGLnvCKGo5GvlSbC9VawrnHSsaPTFYYG3Bi jRNRRyWQ7ypnh9O73zuUzj2ZZL6w0Au5ZPFp+QL7/nxOxDTYfEDDuTELRLwTbz7zgxP+xrnd6twv FOcX7/nTmk73DiP3t6AaJ254pzxOUIQO6C7sQV6TxzQkEmI+Y4luA8krWtOVYtv+QpZUB8T4bxAY YsahxKwJvTgHmJ3KpGO0rYsQKglRFF28hPGQabUU8fdxonK5Q63IaQ3AsZdwmJbfS7kUrQ77dAME B57asbFmztp1YgaG/cPNnavF8UM8tb0sGE/wZ6R43F7v7l6v9ATWQDbv5iFVRZBItOcEIHyMOa93 /d6TqrIszrJNS6pOXIoD2JERwizwNkMosXHr4tfCcMqybElYiq91PWJom2zcyxfYHfE1tswIXsvz 3ul8dM8L+o/86FMeQwNG/94wx3HAh7357fzdgAAAiH/2Dw3s7f/jHv4Lmcrjf7CvA+OnAGTbcFIW BG6QqQInpaN5IkAt4S5FczWYKoEQi+Ny2Y1qEHrzUSXblAAT3i3s7ahqfhDfR2GJdvykkBqGdY59 zDrlUPn9wVoXnSjQQlAraPzWP68DKUfgRsIO76WUEVXUoK9+Y+gnejRY6yB8X/BYKHXVA54o9Hvo arMqsl2V98WMKHtFOU2oHZJs0GQaDtR4gENd7Kf0mnrafcjxy45k7Q6bq5yIqEPOgfnUEGiNDahO BbyY2AnTTmxtL+EUFw7Ar64LypA/w4ldsGstEALLwn3Pkb3ziFb6mmHKgoxoTnvQjawTrjlmUEQg gBjJPqXFPn0M+7Di601c8AHRZzGsVCshHQixDT47/gZ7+AktFa5IV0qug1gsBt1P/0wf0l94wprn JJQJE08OdRJYVQyBL2IVWcmDCJCp4s20TztoqZIF0jYiM0YXwvf5aoooHIuhP8I8tL4thqQ+woHK 4aD05gZAl5y+4PSJSNtFfSLyTA4+YoOXpWXCfnN7622rzwJxIvx6jopqFXIwrrBh9GbxTj8jvH1m AdJ+fWDplSFzz786b2wahoHWYgWRkOKqmqV3NDTyxVv2ozeU3Yf0TfKaZy1w+USNOXlV3+n8uT2u 8pH3Td+xvzB/3usslcQvWk/6DfyfNAECpgP8TxXef8Xf1Hv/VcG/V53+GVW/ufenGtS/Cv57Kd6f MQv+3xvF/1CY91dNf63E+hdwof6mLuuv4n9N+PoX7jH/Jv3rr+J/zbT5F9pw/oe8m7+q+Osnzn8h mPhvPnj+Vfyvccd/gZ7m76OQf9Xw7+G0PyONFgD4P4JrfxX/axjkXyBk+D+CIn8V/quJ8C8Icf6d wfBX+X9f6v+MVu4/9f2/F34FaTDwP67B/v4Bfkvs/JE+BfhfUEsBAhQAFAACAAgAzoEoRYwaCBdS NgAA9kAAAAgAAAAAAAAAAAAgAAAAAAAAACM3MC5kb2N4UEsFBgAAAAABAAEANgAAAHg2AAAAAA== --_002_5BCBA1FC2B7F0B4C9D935572D90006681520A0BFDEMUMBX014nsnin_-- From nobody Mon Sep 8 07:40:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14441A8842 for ; Mon, 8 Sep 2014 07:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V2pZNCi7ldc for ; Mon, 8 Sep 2014 07:40:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129DB1A884C for ; Mon, 8 Sep 2014 07:40:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 472A2D8C665C3; Mon, 8 Sep 2014 14:26:51 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s88EQjaR032509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 16:26:53 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 8 Sep 2014 16:25:33 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Steve Donovan , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" , "Nirav Salot (nsalot)" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/31LPWG+9t20ShWDRGsSmaRZvyeKuAgAQUNgCAALShMA== Date: Mon, 8 Sep 2014 14:25:32 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.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.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_pSFA_kwYlsrABv50HUhnltIwH4 Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 14:40:52 -0000 DQpEZWFyIGFsbA0KDQpJIHRoaW5rIHdlIGFyZSByZXN0YXJ0aW5nIGEgZGlzY3Vzc2lvbiB3ZSBo YWQgYSBmZXcgbW9udGhzIGFnby4gDQpUaGUgcXVlc3Rpb24gaXMgaG93IGZyZXF1ZW50bHkgdGhl IE9MUiAod2l0aCBzYW1lIHNlcSBudW1iZXIsIHNvIG5vIGNoYW5nZSlpcyBzZW50Pw0KYSkgY3Vy cmVudCB0ZXh0IGluIHRoZSBkcmFmdCBpcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSAoaW4gb3Zl cmxvYWQgY29uZGl0aW9uKSAgbXVzdCBpbmNsdWRlIGFuICBPQy1PTFIgQVZQIGluIGFsbCByZXNw b25zZSBtZXNzYWdlcw0KYikgaXQgY2FuIGFsc28gYmUgc2FpZCBpdCBpcyBvbmx5IHNlbnQgb25j ZSB3aGVuIGEgY2hhbmdlIG9jY3VycyBpbiB0aGUgT0xSLiBJdCBpcyBpbiB0aGVvcnkgZW5vdWdo DQpjKSBpbiB0aGUgbWlkZGxlICwgaXQgY2FuIGJlIHNlbnQgaW4gYSBmZXcgLyBtYW55IG1lc3Nh Z2VzIA0KDQpiKSBpcyBub3Qgc2VjdXJlLCBhcyB0aGUgYW5zd2VyIGNvbnZleWluZyB0aGUgbmV3 IE9MUiBjYW4gYmUgbG9zdC4gYykgaXMgT0sgZm9yIG1lIGlmIHdoZW4gdGhlcmUgaXMgYSBjaGFu Z2UgaW4gdGhlIE9MUiwgdGhlIHJlcG9ydGluZyBub2RlIHJhcGlkbHkgIHNlbmQgYSBzaWduaWZp Y2FudCBhbW91bnQgb2YgYW5zd2VycyB3aXRoIHRoZSBzYW1lIHNlcSBudW1iZXIgIHNvIHRvIGNv bnNpZGVyIHdpdGggYSBoaWdoIHByb2JhYmlsaXR5IHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgIGhh cyB3ZWxsIHJlY2VpdmVkIHRoZSBuZXcgIE9MUi4gKE5vdGU6IFdpdGggdGhlIGN1cnJlbnQgZHJh ZnQsIGFwYXJ0IHRoaXMgd2F5LCBJIGRvIG5vdCB3ZWxsIHNlZSBob3cgdGhlIHJlcG9ydGluZyBu b2RlIGtub3dzIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUgaGFzIHdlbGwgcmVjZWl2ZWQgdGhlIG5l dyBPTFIpDQoNCkkgdGhpbmsgdGhhdCBpdCB3YXMgIGNvbnNpZGVyZWQgc2ltcGxlciAgdG8gYWx3 YXlzIHNlbmQgT0xSIGluIGVhY2ggYW5zd2VyIHRoYW4gdG8gaGF2ZSB0byB0YWtlIGEgZGVjaXNp b24gYXQgZWFjaCBhbnN3ZXIgdG8gc2VuZCBpdCBvciBub3QuIFdlIGFsc28gaGFkIGEgc2ltaWxh ciBkZWJhdGUgYWJvdXQgdGhlIE9DLVN1cHBvcnRlZC1GZWF0dXJlcykgdG8gYmUgYWx3YXlzIHBy ZXNlbnQgb3Igbm90Lg0KDQpTbyBhKSBpcyBPSyBmb3IgbWUgYXMgc2ltcGxlLiBJIGFjY2VwdCB0 aGUgaWRlYSBvZiBzb21lIHRvbGVyYW5jZSwgd2l0aCBNY3J1eiBwcm9wb3NhbCB0aGF0IHRoZSBh YnNlbmNlIG9mIHRoZSBPTFIgc2ltcGx5IG1lYW5zIG5vIGNoYW5nZS4gQnV0IHRoaXMgdG9sZXJh bmNlIHNob3VsZCBub3QgZHJpdmUgdG8gYSBiKSBiZWhhdmlvci4gDQoNCkJlc3QgcmVnYXJkcw0K DQpKSmFjcXVlcw0KIA0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBEaU1FIFtt YWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90IChu c2Fsb3QpDQpFbnZvecOpwqA6IGx1bmRpIDggc2VwdGVtYnJlIDIwMTQgMDY6NDgNCsOAwqA6IFN0 ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRvb2xzLmll dGYub3JnOyBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20NCk9iamV0wqA6IFJlOiBb RGltZV0gW2RpbWVdICM3MiAoZHJhZnQtaWV0Zi1kaW1lLW92bGkpOiBSZXBvcnRpbmcgTm9kZSBC ZWhhdmlvdXIgd2hlbiBPQy1PTFIgaXMgbm90IHJlY2VpdmVkDQoNClN0ZXZlLA0KDQo+IEkgdGhp bmsgaXQgaXMgYmV0dGVyIHRvIHNwZWNpZnkgdGhlIGJlaGF2aW9yIG9mIHRoZSByZXBvcnRpbmcg bm9kZSB0byBhbHdheXMgaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlIGZv ciBhcyBsb25nIGFzIHRoZXJlIGlzIGFuIG92ZXJsb2FkIGNvbmRpdGlvbiBhdCB0aGUgcmVwb3J0 aW5nIG5vZGUuDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBuZWNlc3NhcnkuIFRoZSByZXBvcnRp bmcgbWF5IGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZSBidXQgd2UgZG9u 4oCZdCBoYXZlIHRvIHB1dCB0aGF0IGFzIG1hbmRhdG9yeSByZXF1aXJlbWVudCwgZS5nLiBpZiB0 aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgKGFuZCBrZWVwcyB0cmFjayBvZikgaWYgdGhlIHRhcmdl dCByZWFjdGluZyBub2RlIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGN1cnJlbnRseSBhY3RpdmUgT0xS Lg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RldmUg RG9ub3Zhbg0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTQgODowMSBQTQ0KVG86IGRp bWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBtYXJpYS5j cnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICM3 MiAoZHJhZnQtaWV0Zi1kaW1lLW92bGkpOiBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvdXIgd2hlbiBP Qy1PTFIgaXMgbm90IHJlY2VpdmVkDQoNCk1hcmlhIENydXosDQoNCkknbSBub3Qgc3VyZSBJIGFn cmVlIHdpdGggdGhpcyBwcm9wb3NlZCBjaGFuZ2UuDQoNClRoZSB3b3JkaW5nIHRvIGluZGljYXRl IHRoYXQgYWJzZW5jZSBvZiBhbiBvdmVybG9hZCByZXBvcnQgd2FzIHRvIGhhbmRsZSB1bnVzdWFs IHNpdHVhdGlvbnMuICBZb3VyIHByb3Bvc2VkIHdvcmRpbmcgaW1wbGllcyB0aGF0IGl0IGlzIGFj Y2VwdGFibGUgZm9yIGEgcmVwb3J0aW5nIG5vZGUgdG8gbm90IGluY2x1ZGUgdGhlIE9MUiBpbiBl dmVyeSBhbnN3ZXIgbWVzc2FnZS4NCg0KSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc3BlY2lmeSB0 aGUgYmVoYXZpb3Igb2YgdGhlIHJlcG9ydGluZyBub2RlIHRvIGFsd2F5cyBpbmNsdWRlIHRoZSBP TFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UgZm9yIGFzIGxvbmcgYXMgdGhlcmUgaXMgYW4gb3Zl cmxvYWQgY29uZGl0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZS4NCg0KUmVnYXJkcywNCg0KU3Rl dmUNCg0KT24gOS81LzE0LCAzOjAzIEFNLCBkaW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6DQo+ICM3 MjogUmVwb3J0aW5nIE5vZGUgQmVoYXZpb3VyIHdoZW4gT0MtT0xSIGlzIG5vdCByZWNlaXZlZA0K Pg0KPiAgIEEgY2xhcmlmaWNhdGlvbiBpcyByZXF1aXJlZCB0byBjb25zaWRlciB0aGF0IGFuIGFu c3dlciBtZXNzYWdlIG1heSBub3QNCj4gICBpbmNsdWRlIE9DLU9MUiBhbmQgc3RpbGwgdGhlIHJl cG9ydGluZyBub2RlIGJlICBvdmVybG9hZGVkLCBzaW5jZSBpdCBpcw0KPiAgIGNvbnNpZGVyZWQg YXMgIm5vIGNoYW5nZSIsIGFzIGRvY3VtZW50ZWQgaW4gNC4yLjEuMzoNCj4NCj4gICAgICAgUmVh Y3Rpbmcgbm9kZXMgZG8gbm90IGRlbGV0ZSBhbiBPQ1Mgd2hlbiByZWNlaXZpbmcgYW4gYW5zd2Vy IG1lc3NhZ2UNCj4gICAgICAgdGhhdCBkb2VzIG5vdCBjb250YWluIGFuIE9DLU9MUiBBVlAgKGku ZS4gYWJzZW5jZSBvZiBPTFIgbWVhbnMgIm5vDQo+ICAgICAgIGNoYW5nZSIpLg0KPg0KPg0KPiAg IE9yaWdpbmFsIHRleHQ6DQo+DQo+ICAgNS4zLiAgUmVwb3J0aW5nIE5vZGUgQmVoYXZpb3IgKE5v cm1hdGl2ZSkNCj4NCj4gICAgICBUaGUgbWV0aG9kIGEgcmVwb3J0aW5nIG5vZGVzIHVzZXMgdG8g ZGV0ZXJtaW5lIHRoZSBhbW91bnQgb2YgdHJhZmZpYw0KPiAgICAgIHJlZHVjdGlvbiByZXF1aXJl ZCB0byBhZGRyZXNzIGFuIG92ZXJsb2FkIGNvbmRpdGlvbiBpcyBhbg0KPiAgICAgIGltcGxlbWVu dGF0aW9uIGRlY2lzaW9uLg0KPg0KPiAgICAgIFdoZW4gYSByZXBvcnRpbmcgbm9kZSB0aGF0IGhh cyBzZWxlY3RlZCB0aGUgbG9zcyBhYmF0ZW1lbnQgYWxnb3JpdGhtDQo+ICAgICAgZGV0ZXJtaW5l cyB0aGUgbmVlZCB0byByZXF1ZXN0IGEgdHJhZmZpYyByZWR1Y3Rpb24gaXQgbXVzdCBpbmNsdWRl IGFuDQo+ICAgICAgT0MtT0xSIEFWUCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMuDQo+DQo+DQo+ ICAgUHJvcG9zZWQgYWRkaXRpb246DQo+DQo+DQo+ICAgNS4zLiAgUmVwb3J0aW5nIE5vZGUgQmVo YXZpb3IgKE5vcm1hdGl2ZSkNCj4NCj4gICAgICBUaGUgbWV0aG9kIGEgcmVwb3J0aW5nIG5vZGVz IHVzZXMgdG8gZGV0ZXJtaW5lIHRoZSBhbW91bnQgb2YgdHJhZmZpYw0KPiAgICAgIHJlZHVjdGlv biByZXF1aXJlZCB0byBhZGRyZXNzIGFuIG92ZXJsb2FkIGNvbmRpdGlvbiBpcyBhbg0KPiAgICAg IGltcGxlbWVudGF0aW9uIGRlY2lzaW9uLg0KPg0KPiAgICAgIFdoZW4gYSByZXBvcnRpbmcgbm9k ZSB0aGF0IGhhcyBzZWxlY3RlZCB0aGUgbG9zcyBhYmF0ZW1lbnQgYWxnb3JpdGhtDQo+ICAgICAg ZGV0ZXJtaW5lcyB0aGUgbmVlZCB0byByZXF1ZXN0IGEgdHJhZmZpYyByZWR1Y3Rpb24gaXQgbXVz dCBpbmNsdWRlIGFuDQo+ICAgICAgT0MtT0xSIEFWUCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMu IE9DLU9MUiBBVlAgaXMgbm90IGluY2x1ZGVkIHdoZW4NCj4gICByZXBvcnRpbmcgbm9kZSBleHBl Y3RhdGlvbnMgb24gdHJhZmZpYyByZWR1Y3Rpb24gYXJlIG5vdCBtb2RpZmllZC4gVGhhdA0KPiAg IGlzLCBpZiBPQy1PTFIgQVZQIGlzIG5vdCBpbmNsdWRlZCBpdCBpcyBpbnRlcnByZXRlZCBhcyDi gJxubyBjaGFuZ2XigJ0uDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0K From nobody Mon Sep 8 08:31:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FEE1A8871 for ; Mon, 8 Sep 2014 08:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKzlnbWZUI7a for ; Mon, 8 Sep 2014 08:31:39 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548811A8859 for ; Mon, 8 Sep 2014 08:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8142; q=dns/txt; s=iport; t=1410190300; x=1411399900; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ohgn69c5nh+PHKx4xNRCBAjkz20lt+9Mga5IZkjt8cc=; b=nGe/J4WBZsXPpdtb83IGWhe5GmX1cko5QAIacouSCn1qh/4alkhoZoJR 6np/2OeEEXHgjp8ta3YA6O6Eqbo5lDI8+Kmdk4pUnXHRY9ZhpkNmqXVEf dDa9/3WAakafw/BZGYvzv/Tb+GSs+igWHxyHXjNn3CnL2GTnKRQ4avQnY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAMvKDVStJA2D/2dsb2JhbABTBoMNU1cEgnjGbgqHTAEZeRZ4hAMBAQEDAQEBASAROhAHBAIBCBEEAQEBAgIGHQMCAgIlCxQBCAgCBAESCIgyCA2mE5U0ARMEgSyIVIUKEjgGgnM2gR0FkUCgXoIbgUZsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,486,1406592000"; d="scan'208";a="75965024" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 08 Sep 2014 15:31:39 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s88FVcQ7005355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 15:31:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 10:31:38 -0500 From: "Nirav Salot (nsalot)" To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Steve Donovan , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/1+Q8BEs1TL06ARTN1arg4/pvy7gSAgAO/zUCAAPW+AP//veCg Date: Mon, 8 Sep 2014 15:31:38 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HHAERtEPIZS9mtvtFLcVauhWgrg Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 15:31:41 -0000 SGkgSkosDQoNCkkgc2hhcmUgeW91ciB2aWV3IGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkg b2YgdGhlIHJlcG9ydGluZyBub2RlIHRvIGVuc3VyZSB0aGF0IHRoZSBPTFIgcmVhY2hlcyB0aGUg dGFyZ2V0IG5vZGUuDQpJZiB0aGUgcmVwb3J0aW5nIG5vZGUgaXMgbm90IGZvbGxvd2luZyAiYSIg YmVsb3cgdGhlbiBpdCBoYXMgdG8gaGF2ZSBvdGhlciBtZWFucyB0byBrbm93IHRoZSB0YXJnZXQg b2YgdGhlIHJlc3BvbnNlIGFuZCBhbHNvIGhhdmUgdG8ga2VlcCB0cmFjayBpZiB0aGUgYWN0aXZl IE9MUiB3YXMgYWxyZWFkeSBzZW50IG9yIG5vdC4NCldlIGRvbuKAmXQgaGF2ZSB0byBzdWdnZXN0 IHRoZSByZXBvcnRpbmcgbm9kZSB0byBkbyB0aGlzIGJ1dCBhdCB0aGUgc2FtZSB0aW1lIHdlIG5l ZWQgbm90IGZvcmJpZCB0aGlzIHR5cGUgb2YgaW1wbGVtZW50YXRpb24uIA0KDQpTbyBJIGFtIGFs c28gZmluZSB0byBzcGVjaWZ5IHRoYXQgaWYgdGhlIE9MUiBpcyBub3QgcmVjZWl2ZWQgYnkgdGhl IHJlYWN0aW5nIG5vZGUgdGhlbiB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgc3RhbmRzIHZh bGlkLg0KDQpSZWdhcmRzLA0KTmlyYXYuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykgW21haWx0bzpqZWFuLWph Y3F1ZXMudHJvdHRpbkBhbGNhdGVsLWx1Y2VudC5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1i ZXIgMDgsIDIwMTQgNzo1NiBQTQ0KVG86IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBtYXJpYS5jcnV6LmJhcnRvbG9tZUBl cmljc3Nvbi5jb207IE5pcmF2IFNhbG90IChuc2Fsb3QpDQpTdWJqZWN0OiBSRTogW0RpbWVdIFtk aW1lXSAjNzIgKGRyYWZ0LWlldGYtZGltZS1vdmxpKTogUmVwb3J0aW5nIE5vZGUgQmVoYXZpb3Vy IHdoZW4gT0MtT0xSIGlzIG5vdCByZWNlaXZlZA0KDQoNCkRlYXIgYWxsDQoNCkkgdGhpbmsgd2Ug YXJlIHJlc3RhcnRpbmcgYSBkaXNjdXNzaW9uIHdlIGhhZCBhIGZldyBtb250aHMgYWdvLiANClRo ZSBxdWVzdGlvbiBpcyBob3cgZnJlcXVlbnRseSB0aGUgT0xSICh3aXRoIHNhbWUgc2VxIG51bWJl ciwgc28gbm8gY2hhbmdlKWlzIHNlbnQ/DQphKSBjdXJyZW50IHRleHQgaW4gdGhlIGRyYWZ0IGlz IHRoYXQgdGhlIHJlcG9ydGluZyBub2RlIChpbiBvdmVybG9hZCBjb25kaXRpb24pICBtdXN0IGlu Y2x1ZGUgYW4gIE9DLU9MUiBBVlAgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzDQpiKSBpdCBjYW4g YWxzbyBiZSBzYWlkIGl0IGlzIG9ubHkgc2VudCBvbmNlIHdoZW4gYSBjaGFuZ2Ugb2NjdXJzIGlu IHRoZSBPTFIuIEl0IGlzIGluIHRoZW9yeSBlbm91Z2gNCmMpIGluIHRoZSBtaWRkbGUgLCBpdCBj YW4gYmUgc2VudCBpbiBhIGZldyAvIG1hbnkgbWVzc2FnZXMgDQoNCmIpIGlzIG5vdCBzZWN1cmUs IGFzIHRoZSBhbnN3ZXIgY29udmV5aW5nIHRoZSBuZXcgT0xSIGNhbiBiZSBsb3N0LiBjKSBpcyBP SyBmb3IgbWUgaWYgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSBpbiB0aGUgT0xSLCB0aGUgcmVwb3J0 aW5nIG5vZGUgcmFwaWRseSAgc2VuZCBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBhbnN3ZXJzIHdp dGggdGhlIHNhbWUgc2VxIG51bWJlciAgc28gdG8gY29uc2lkZXIgd2l0aCBhIGhpZ2ggcHJvYmFi aWxpdHkgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSAgaGFzIHdlbGwgcmVjZWl2ZWQgdGhlIG5ldyAg T0xSLiAoTm90ZTogV2l0aCB0aGUgY3VycmVudCBkcmFmdCwgYXBhcnQgdGhpcyB3YXksIEkgZG8g bm90IHdlbGwgc2VlIGhvdyB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgcmVhY3Rp bmcgbm9kZSBoYXMgd2VsbCByZWNlaXZlZCB0aGUgbmV3IE9MUikNCg0KSSB0aGluayB0aGF0IGl0 IHdhcyAgY29uc2lkZXJlZCBzaW1wbGVyICB0byBhbHdheXMgc2VuZCBPTFIgaW4gZWFjaCBhbnN3 ZXIgdGhhbiB0byBoYXZlIHRvIHRha2UgYSBkZWNpc2lvbiBhdCBlYWNoIGFuc3dlciB0byBzZW5k IGl0IG9yIG5vdC4gV2UgYWxzbyBoYWQgYSBzaW1pbGFyIGRlYmF0ZSBhYm91dCB0aGUgT0MtU3Vw cG9ydGVkLUZlYXR1cmVzKSB0byBiZSBhbHdheXMgcHJlc2VudCBvciBub3QuDQoNClNvIGEpIGlz IE9LIGZvciBtZSBhcyBzaW1wbGUuIEkgYWNjZXB0IHRoZSBpZGVhIG9mIHNvbWUgdG9sZXJhbmNl LCB3aXRoIE1jcnV6IHByb3Bvc2FsIHRoYXQgdGhlIGFic2VuY2Ugb2YgdGhlIE9MUiBzaW1wbHkg bWVhbnMgbm8gY2hhbmdlLiBCdXQgdGhpcyB0b2xlcmFuY2Ugc2hvdWxkIG5vdCBkcml2ZSB0byBh IGIpIGJlaGF2aW9yLiANCg0KQmVzdCByZWdhcmRzDQoNCkpKYWNxdWVzDQogDQotLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmddIERlIGxhIHBhcnQgZGUgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgRW52b3nDqcKgOiBsdW5kaSA4 IHNlcHRlbWJyZSAyMDE0IDA2OjQ4IMOAwqA6IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBtYXJpYS5jcnV6LmJhcnRvbG9t ZUBlcmljc3Nvbi5jb20gT2JqZXTCoDogUmU6IFtEaW1lXSBbZGltZV0gIzcyIChkcmFmdC1pZXRm LWRpbWUtb3ZsaSk6IFJlcG9ydGluZyBOb2RlIEJlaGF2aW91ciB3aGVuIE9DLU9MUiBpcyBub3Qg cmVjZWl2ZWQNCg0KU3RldmUsDQoNCj4gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc3BlY2lmeSB0 aGUgYmVoYXZpb3Igb2YgdGhlIHJlcG9ydGluZyBub2RlIHRvIGFsd2F5cyBpbmNsdWRlIHRoZSBP TFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UgZm9yIGFzIGxvbmcgYXMgdGhlcmUgaXMgYW4gb3Zl cmxvYWQgY29uZGl0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZS4NCkkgZG9u4oCZdCB0aGluayB0 aGlzIGlzIG5lY2Vzc2FyeS4gVGhlIHJlcG9ydGluZyBtYXkgaW5jbHVkZSB0aGUgT0xSIGluIGV2 ZXJ5IGFuc3dlciBtZXNzYWdlIGJ1dCB3ZSBkb27igJl0IGhhdmUgdG8gcHV0IHRoYXQgYXMgbWFu ZGF0b3J5IHJlcXVpcmVtZW50LCBlLmcuIGlmIHRoZSByZXBvcnRpbmcgbm9kZSBrbm93cyAoYW5k IGtlZXBzIHRyYWNrIG9mKSBpZiB0aGUgdGFyZ2V0IHJlYWN0aW5nIG5vZGUgaGFzIGFscmVhZHkg cmVjZWl2ZWQgY3VycmVudGx5IGFjdGl2ZSBPTFIuDQoNClJlZ2FyZHMsDQpOaXJhdi4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBGcmlkYXksIFNlcHRl bWJlciAwNSwgMjAxNCA4OjAxIFBNDQpUbzogZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1l LW92bGlAdG9vbHMuaWV0Zi5vcmc7IG1hcmlhLmNydXouYmFydG9sb21lQGVyaWNzc29uLmNvbQ0K U3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzcyIChkcmFmdC1pZXRmLWRpbWUtb3ZsaSk6IFJl cG9ydGluZyBOb2RlIEJlaGF2aW91ciB3aGVuIE9DLU9MUiBpcyBub3QgcmVjZWl2ZWQNCg0KTWFy aWEgQ3J1eiwNCg0KSSdtIG5vdCBzdXJlIEkgYWdyZWUgd2l0aCB0aGlzIHByb3Bvc2VkIGNoYW5n ZS4NCg0KVGhlIHdvcmRpbmcgdG8gaW5kaWNhdGUgdGhhdCBhYnNlbmNlIG9mIGFuIG92ZXJsb2Fk IHJlcG9ydCB3YXMgdG8gaGFuZGxlIHVudXN1YWwgc2l0dWF0aW9ucy4gIFlvdXIgcHJvcG9zZWQg d29yZGluZyBpbXBsaWVzIHRoYXQgaXQgaXMgYWNjZXB0YWJsZSBmb3IgYSByZXBvcnRpbmcgbm9k ZSB0byBub3QgaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLg0KDQpJIHRo aW5rIGl0IGlzIGJldHRlciB0byBzcGVjaWZ5IHRoZSBiZWhhdmlvciBvZiB0aGUgcmVwb3J0aW5n IG5vZGUgdG8gYWx3YXlzIGluY2x1ZGUgdGhlIE9MUiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZSBm b3IgYXMgbG9uZyBhcyB0aGVyZSBpcyBhbiBvdmVybG9hZCBjb25kaXRpb24gYXQgdGhlIHJlcG9y dGluZyBub2RlLg0KDQpSZWdhcmRzLA0KDQpTdGV2ZQ0KDQpPbiA5LzUvMTQsIDM6MDMgQU0sIGRp bWUgaXNzdWUgdHJhY2tlciB3cm90ZToNCj4gIzcyOiBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvdXIg d2hlbiBPQy1PTFIgaXMgbm90IHJlY2VpdmVkDQo+DQo+ICAgQSBjbGFyaWZpY2F0aW9uIGlzIHJl cXVpcmVkIHRvIGNvbnNpZGVyIHRoYXQgYW4gYW5zd2VyIG1lc3NhZ2UgbWF5IG5vdA0KPiAgIGlu Y2x1ZGUgT0MtT0xSIGFuZCBzdGlsbCB0aGUgcmVwb3J0aW5nIG5vZGUgYmUgIG92ZXJsb2FkZWQs IHNpbmNlIGl0IGlzDQo+ICAgY29uc2lkZXJlZCBhcyAibm8gY2hhbmdlIiwgYXMgZG9jdW1lbnRl ZCBpbiA0LjIuMS4zOg0KPg0KPiAgICAgICBSZWFjdGluZyBub2RlcyBkbyBub3QgZGVsZXRlIGFu IE9DUyB3aGVuIHJlY2VpdmluZyBhbiBhbnN3ZXIgbWVzc2FnZQ0KPiAgICAgICB0aGF0IGRvZXMg bm90IGNvbnRhaW4gYW4gT0MtT0xSIEFWUCAoaS5lLiBhYnNlbmNlIG9mIE9MUiBtZWFucyAibm8N Cj4gICAgICAgY2hhbmdlIikuDQo+DQo+DQo+ICAgT3JpZ2luYWwgdGV4dDoNCj4NCj4gICA1LjMu ICBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvciAoTm9ybWF0aXZlKQ0KPg0KPiAgICAgIFRoZSBtZXRo b2QgYSByZXBvcnRpbmcgbm9kZXMgdXNlcyB0byBkZXRlcm1pbmUgdGhlIGFtb3VudCBvZiB0cmFm ZmljDQo+ICAgICAgcmVkdWN0aW9uIHJlcXVpcmVkIHRvIGFkZHJlc3MgYW4gb3ZlcmxvYWQgY29u ZGl0aW9uIGlzIGFuDQo+ICAgICAgaW1wbGVtZW50YXRpb24gZGVjaXNpb24uDQo+DQo+ICAgICAg V2hlbiBhIHJlcG9ydGluZyBub2RlIHRoYXQgaGFzIHNlbGVjdGVkIHRoZSBsb3NzIGFiYXRlbWVu dCBhbGdvcml0aG0NCj4gICAgICBkZXRlcm1pbmVzIHRoZSBuZWVkIHRvIHJlcXVlc3QgYSB0cmFm ZmljIHJlZHVjdGlvbiBpdCBtdXN0IGluY2x1ZGUgYW4NCj4gICAgICBPQy1PTFIgQVZQIGluIGFs bCByZXNwb25zZSBtZXNzYWdlcy4NCj4NCj4NCj4gICBQcm9wb3NlZCBhZGRpdGlvbjoNCj4NCj4N Cj4gICA1LjMuICBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvciAoTm9ybWF0aXZlKQ0KPg0KPiAgICAg IFRoZSBtZXRob2QgYSByZXBvcnRpbmcgbm9kZXMgdXNlcyB0byBkZXRlcm1pbmUgdGhlIGFtb3Vu dCBvZiB0cmFmZmljDQo+ICAgICAgcmVkdWN0aW9uIHJlcXVpcmVkIHRvIGFkZHJlc3MgYW4gb3Zl cmxvYWQgY29uZGl0aW9uIGlzIGFuDQo+ICAgICAgaW1wbGVtZW50YXRpb24gZGVjaXNpb24uDQo+ DQo+ICAgICAgV2hlbiBhIHJlcG9ydGluZyBub2RlIHRoYXQgaGFzIHNlbGVjdGVkIHRoZSBsb3Nz IGFiYXRlbWVudCBhbGdvcml0aG0NCj4gICAgICBkZXRlcm1pbmVzIHRoZSBuZWVkIHRvIHJlcXVl c3QgYSB0cmFmZmljIHJlZHVjdGlvbiBpdCBtdXN0IGluY2x1ZGUgYW4NCj4gICAgICBPQy1PTFIg QVZQIGluIGFsbCByZXNwb25zZSBtZXNzYWdlcy4gT0MtT0xSIEFWUCBpcyBub3QgaW5jbHVkZWQg d2hlbg0KPiAgIHJlcG9ydGluZyBub2RlIGV4cGVjdGF0aW9ucyBvbiB0cmFmZmljIHJlZHVjdGlv biBhcmUgbm90IG1vZGlmaWVkLiBUaGF0DQo+ICAgaXMsIGlmIE9DLU9MUiBBVlAgaXMgbm90IGlu Y2x1ZGVkIGl0IGlzIGludGVycHJldGVkIGFzIOKAnG5vIGNoYW5nZeKAnS4NCj4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBs aXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RpbWUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpE aU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaW1lDQo= From nobody Mon Sep 8 10:23:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DDD1A0023 for ; Mon, 8 Sep 2014 10:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfEVwZJn7dr4 for ; Mon, 8 Sep 2014 10:22:55 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464311A0020 for ; Mon, 8 Sep 2014 10:22:31 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so5830584qgd.19 for ; Mon, 08 Sep 2014 10:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=3HG4G9KP0zYINd+kcnCvtPRlNhBnHPv5k9r6deqi9r0=; b=SBbHh1fcuplM7rM9Y1MzI7fBWnTzihNbLDaThII9QRaRfd8Zs3FT5zIQKVWncp9jI8 5HftgaY8DIOQb2cknnVaGrtm+mIJ7QZF0/hHHGgxBYC0pypMpn14pti+1W3RWoLxTqDO F7GKt8lUsNYiZqtyEaZ8vQ+BHhDM8yJVP+mTX75IHes2lXh+1GD/+9+1BaCsNTQV0cep Nvz08l55aRQznS821Ey84gqT2q9u/qFkDJtFKkc9cbwMNGFeEmH4gcwWAAN7zLHxgXaT ykUTPS8z4r9SmkmtL7v0RQf6UB6UP2q28yCtmkN/SjhMSxvx1tGWgCKFVMT4RbwOhGMq 4ktw== X-Received: by 10.140.87.71 with SMTP id q65mr10892924qgd.94.1410196950509; Mon, 08 Sep 2014 10:22:30 -0700 (PDT) Received: from mtl-morriss-d1.ulticom.com (74-8-208-5.ulticom.com. [74.8.208.5]) by mx.google.com with ESMTPSA id e9sm8165543qar.44.2014.09.08.10.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 10:22:29 -0700 (PDT) Message-ID: <540DE5D5.8030503@gmail.com> Date: Mon, 08 Sep 2014 13:22:29 -0400 From: Jeff Morriss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yNTcXUgq-Jo0IwTWVXB7I9MgxUM Subject: [Dime] Diameter Time format and year 2036 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 17:23:03 -0000 Hi folks, RFC 6733 says, in part: > This represents the number of seconds since 0h on 1 January 1900 > with respect to the Coordinated Universal Time (UTC). > > On 6h 28m 16s UTC, 7 February 2036, the time value will overflow. > Simple Network Time Protocol (SNTP) [RFC5905] describes a > procedure to extend the time to 2104. This procedure MUST be > supported by all Diameter nodes. However, I can find no such procedure in RFC 5905. (Admittedly I have no read all 110 pages of the RFC but I've searched it fairly extensively.) I *can* find the procedure in RFCs 2030 and 4330, the former being what RFC 3588 originally referred to when describing this procedure. Was the RFC 5905 reference quoted above a search-and-replace mistake? Or am I just blind (and can't see it in 5905)? Regards, -Jeff From nobody Mon Sep 8 14:03:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453F21A03AE for ; Mon, 8 Sep 2014 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2iglBSxKRmE for ; Mon, 8 Sep 2014 14:02:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49BE1A03A5 for ; Mon, 8 Sep 2014 14:02:27 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s88L2LaE084655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Sep 2014 16:02:23 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5409CBEE.9070607@usdonovans.com> Date: Mon, 8 Sep 2014 16:02:20 -0500 X-Mao-Original-Outgoing-Id: 431902940.423868-baa75427bf060b547dc7619831e41095 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> <5409CBEE.9070607@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fwtw5q30qt2er0-ZMc8IXo3sEyo Cc: dime@ietf.org, draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 21:02:41 -0000 Steve, am I correct in assuming the removal of the 2119 "MUST" was = intentional? (For the record, I agree--in this context it's a statement = of fact, not a normative requirement.) If so, I suggest changing it to something other than "must" to avoid = confusion with MUST. For example, " Since the "loss" abatement algorithm [crossref] is mandatory to = implement, DOIC can always be enabled between these two endpoints." On Sep 5, 2014, at 9:42 AM, Steve Donovan = wrote: > Maria Cruz, >=20 > I support the need for these changes. I have a proposal for = alternative wording below. >=20 > Regards, >=20 > Steve >=20 > On 9/5/14, 2:30 AM, dime issue tracker wrote: >> #68: Loss as the common abatemen algorithm >>=20 >> Some text is misleading since it may imply that one feature shall be = in >> common between reporting and reacting node to progress, but in = reality we >> only need to have one common abatement algorithm, and in this draft, = LOSS >> is defined as default, then there is always one common algorithm >>=20 >> Corrections are required in following clauses: >>=20 >> Original text: >>=20 >> 4.2.3. Reporting Node Behavior (Normative) >>=20 >> ... >>=20 >> The operation on the reporting node is straight forward. The >> reporting node learns the capabilities of the reacting node when = it >> receives the OC-Supported-Features AVP as part of any Diameter >> request message. If the reporting node shares at least one = common >> feature with the reacting node, then the DOIC can be enabled = between >> these two endpoints. See Section 4.1 for further discussion on = the >> capability and feature announcement between two endpoints. >>=20 >>=20 >> Proposed modification: >>=20 >> 4.2.3. Reporting Node Behavior (Normative) >>=20 >> ... >>=20 >> The >> reporting node learns the capabilities of the reacting node when = it >> receives the OC-Supported-Features AVP as part of any Diameter >> request message. Both reacting and reporting node MUST share at = least >> one abatement algorithm, in fact, they share at least the loss = algorithm, >> that is defined in this document as the default abatement algorithm, = then >> the DOIC can always be enabled between these two endpoints at least = with >> the default algorithm. See Section 4.1 for further discussion on = the >> capability and feature announcement between two endpoints. > SRD> I propose the following wording: >=20 > The reporting node learns the capabilities of the reacting node when = it receives the > OC-Supported-Featuers AVP as part of any Diameter request message. At = a minimum, > the reacting node and reporting node must both the loss abatement = algorithm defined in this document > and, as a result, DOIC can always be enabled between these two = endpoints. See Section > 4.1 ... >>=20 >>=20 >>=20 >> Original text: >>=20 >> 6.1. OC-Supported-Features AVP >>=20 >> ... >>=20 >> During the message exchange the overload control endpoints = express >> their common set of supported capabilities. The reacting node >> includes the OC-Supported-Features AVP that announces what it >> supports. The reporting node that sends the answer also includes = the >> OC-Supported-Features AVP that describes the capabilities it >> supports. The set of capabilities advertised by the reporting = node >> depends on local policies. At least one of the announced >> capabilities MUST match. If there is no single matching = capability >> the reacting node MUST act as if it does not implement DOIC and = cease >> inserting any DOIC related AVPs into any Diameter messages with = this >> specific reacting node. >>=20 >> Editor's note: The last sentence conflicts with the last = sentence >> two paragraphs up. In reality, there will always be at least = one >> matching capability as all nodes supporting DOIC must support = the >> loss algorithm. Suggest removing the last sentence. >>=20 >>=20 >> Proposed text: >>=20 >> 6.1. OC-Supported-Features AVP >>=20 >> ... >>=20 >> During the message exchange the overload control endpoints = express >> their common set of supported capabilities. The reacting node >> includes the OC-Supported-Features AVP that announces what it >> supports. The reporting node that sends the answer also includes = the >> OC-Supported-Features AVP that describes the capabilities it >> supports. The set of capabilities advertised by the reporting = node >> depends on local policies. Both reacting and reporting node MUST = share >> at least one abatement algorithm, in fact, they share at least the = loss >> algorithm, that is defined in this document as the default abatement >> algorithm, then the DOIC can always be enabled between these two = endpoints >> at least with the default algorithm. See Section 4.1 for further >> discussion on the capability and feature announcement between two >> endpoints. >>=20 > SRD> I propose the following: >=20 > ... Both the reacting and reporting nodes must support the loss = abatement algorithm > defined in this document. As a result, DOIC behavior can always be = enabled between > the reacting and reporting nodes. See Section 4.1 ... >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 8 14:09:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FF31A029C for ; Mon, 8 Sep 2014 14:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2oU71P6s58X for ; Mon, 8 Sep 2014 14:09:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D4B1A02E1 for ; Mon, 8 Sep 2014 14:09:32 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s88L9UbH085197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Sep 2014 16:09:31 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <540A032C.5010808@usdonovans.com> Date: Mon, 8 Sep 2014 16:09:29 -0500 X-Mao-Original-Outgoing-Id: 431903369.353913-8de781e4dda7ad379839810f7609d75e Content-Transfer-Encoding: quoted-printable Message-Id: <83EAF34D-DD86-41DC-9EC3-86B10EA715D3@nostrum.com> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> <540A032C.5010808@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Zcvm6cbjGK98ZQnCl5FyYBgsf2g Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 21:09:36 -0000 On Sep 5, 2014, at 1:38 PM, Steve Donovan = wrote: > Ulrich, >=20 > What the reporting node does is an implementation decision. If the = reporting node wants to have precise control over when overload reports = end on all reacting nodes then it can calculate the duration for every = answer message sent. If it considers it ok to have a staggered end of = the OLR, or if it sends explicit end-of-overload OLRs then it might = choose to not recalculate. I don't see the need to specify that = behavior in the DOIC specification. +1 >=20 > The reacting node MUST NOT recalculate the expiration time because the = sequence number is the same. The reacting node will ignore the overload = report and not bother to even look at any parameters in the report other = then the sequence number. >=20 Also, +1. > Regards, >=20 > Steve From nobody Mon Sep 8 14:52:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8051A03D9; Mon, 8 Sep 2014 14:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmDJ8HP9XwKh; Mon, 8 Sep 2014 14:52:33 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C8D1A02A5; Mon, 8 Sep 2014 14:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=172; q=dns/txt; s=iport; t=1410213153; x=1411422753; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=pPX8/N93gk/3Jo79kEAFhPZURk0uOGtnADpq0aEFuc8=; b=POElzzJOvjvXOJc3POLBDTQHeaUH3NCfqDIL8V7RG1TGO+7ELF8TZ0tQ S4drX6fJF4+vmW1QUHH7NUy5KVxRmmft9Jr584YWpPtUUh85WZQDW4DDW zudqOObXUiVUpgrO6DHVbCnINZQWZJqc942BGnGA01geXMtWx5l7KK4Iy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskIABskDlStJssW/2dsb2JhbABZg2COGLxAiHx4hEJAPRYYAwIBAgFLAQwIAQGIPg29PAETBJQgAQSccodBjWuDYzuCfgEBAQ X-IronPort-AV: E=Sophos;i="5.04,488,1406592000"; d="scan'208";a="166333889" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 08 Sep 2014 21:52:31 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s88LqU4S003249; Mon, 8 Sep 2014 21:52:30 GMT Message-ID: <540E251E.2050206@cisco.com> Date: Mon, 08 Sep 2014 23:52:30 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: dime mailing list , "radext@ietf.org" , "aaa-doctors@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AqcUG2x5w95mgDzG79YNbFCX2ZM Subject: [Dime] AAA tutorial posted X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2014 21:52:35 -0000 Dear all, I (finally) posted the IETF 89 AAA tutorial. https://www.youtube.com/watch?v=7yMwP1D3Um4 The link is also on both DIME and RADEXT WIKIs. Regards, Benoit From nobody Mon Sep 8 23:07:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3B1A0AEC for ; Mon, 8 Sep 2014 23:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS6qNJgXSusA for ; Mon, 8 Sep 2014 23:07:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D08E31A0AEF for ; Mon, 8 Sep 2014 23:07:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140909060707.685.12510.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 23:07:07 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rIdA_1NfJ7FHg6fMGgEA57whHZ4 Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 06:07:12 -0000 URL: http://datatracker.ietf.org/wg/dime/charter/ From nobody Tue Sep 9 01:04:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F831A0BEB; Tue, 9 Sep 2014 01:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr2b28zxmRjL; Tue, 9 Sep 2014 01:04:07 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2671A0B7D; Tue, 9 Sep 2014 01:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=288; q=dns/txt; s=iport; t=1410249847; x=1411459447; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1SsgyAEr2fYHihgawLT8enTEQGXHAO4aiGk38cKXt3Y=; b=ZAkq9fv6djeUfEvcJ0Q6/5GcRQtPvWVs7YpbtMscwcxn0NHh8j/heFYI 7V3gf20XLXtZ0FFaieqLJIDAzf3INycBVlGTxfVb8mPSlg3/Z0wg12VEr +2XDihlnroHCfQ8GXqC4kKtllFrNJ8oPdd5vpfmynxmXrKW3ST4KyQIBp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHAEC0DlStJssW/2dsb2JhbABZg2COGLxRh0wBgSl4hAQBAQQ4UQshJQ8CRgYBDAgBAYg+DbxMARMEj1SETAEEnHOHQY1tg2M7gn4BAQE X-IronPort-AV: E=Sophos;i="5.04,491,1406592000"; d="scan'208";a="171501614" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Sep 2014 08:04:03 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s89843iH017674; Tue, 9 Sep 2014 08:04:03 GMT Message-ID: <540EB473.20302@cisco.com> Date: Tue, 09 Sep 2014 10:04:03 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: dime mailing list , "radext@ietf.org" , "aaa-doctors@ietf.org" References: <540E251E.2050206@cisco.com> In-Reply-To: <540E251E.2050206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uEE7OoQYH2lRW8oWCHA3AX5zFDY Subject: Re: [Dime] AAA tutorial posted X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 08:04:09 -0000 Dear all, I didn't realize that this video was posted as private. Now corrected. Regards, Benoit > Dear all, > > I (finally) posted the IETF 89 AAA tutorial. > https://www.youtube.com/watch?v=7yMwP1D3Um4 > The link is also on both DIME and RADEXT WIKIs. > > Regards, Benoit From nobody Tue Sep 9 03:02:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901CD1A0421 for ; Tue, 9 Sep 2014 03:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wym5BugWXNq1 for ; Tue, 9 Sep 2014 03:01:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9323A1A030A for ; Tue, 9 Sep 2014 03:01:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 8C991244746C4; Tue, 9 Sep 2014 10:01:42 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s89A1atO022516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 12:01:44 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 9 Sep 2014 12:01:27 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "maria.cruz.bartolome@ericsson.com" , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN4B9soJ86/RAkCPYLHsUJaF65v3LPWAgAFYMUA= Date: Tue, 9 Sep 2014 10:01:26 +0000 Message-ID: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hw9f40SGBELeL0UT58kjl2KFH9o Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 10:02:00 -0000 Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bart= olome@ericsson.com Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Sep 9 03:48:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449D91A6FBE for ; Tue, 9 Sep 2014 03:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19M68M731MAL for ; Tue, 9 Sep 2014 03:48:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143CF1A6FBA for ; Tue, 9 Sep 2014 03:48:50 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3FFCD3193B976; Tue, 9 Sep 2014 10:48:46 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s89AmVxL007603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 12:48:47 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 9 Sep 2014 12:48:28 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "maria.cruz.bartolome@ericsson.com" , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN4B9soJ86/RAkCPYLHsUJaF65v3LPWAgAFYMUCAABzR0A== Date: Tue, 9 Sep 2014 10:48:27 +0000 Message-ID: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Pgahcm2Jmbiswq1ccFk3dWy2P2k Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 10:48:54 -0000 Dear all Another remark on this type of use cases. There is a realm overload, the DA receives a realm routed request and decid= e to throttle it and generates a Diameter error (congestion or too busy und= er discussion). The request was not sent to any server; which Origin-Host A= VP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 s= tates that "Origin-Host AVP MUST be present in all Diameter messages. This = AVP identifies the endpoint that originated the Diameter message".=20 Another clarification, in our discussions, we speak of OLRs put in successf= ul answers; my understanding is that OLRs may also be present in unsuccess= ful answers (with a Diameter error). Do we agree on this? Best regards Jacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: mardi 9 septembre 2014 12:01 =C0=A0: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich);= dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: 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 nobody Tue Sep 9 03:57:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5971A6FC7 for ; Tue, 9 Sep 2014 03:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfo7LvmuF61b for ; Tue, 9 Sep 2014 03:57:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C981A6FC6 for ; Tue, 9 Sep 2014 03:57:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s89AvbNm016893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Sep 2014 10:57:37 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s89AvbDd016441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 12:57:37 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Sep 2014 12:57:37 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 12:57:37 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "maria.cruz.bartolome@ericsson.com" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgA== Date: Tue, 9 Sep 2014 10:57:36 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10600 X-purgate-ID: 151667::1410260257-00002A30-20BCC430/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K3CFA5ET8b60dv0bGamuBBq-7wM Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 10:57:45 -0000 Dear JJacques, assume the following example: In step 1 (realm routed request sent from Client to Agent), the client indi= cates that it supports loss. In step 2 (host routed request send from agent to S1), the agent indicates = that it supports loss and rate. In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicat= es that it selected rate. Now in step 4 there is no point in forwarding the host-type OLR from agent = to client as the client does not support rate. Similar for step 8 where no = host type OLR of rate shall be sent in addition to the realm-type OLR of lo= ss. Also note that the answer in step 8 can contain only one Supported-Features= AVP i.e. can only contain one selected algorithm. Even when the agent supp= orts loss and realm, you cannot say in one answer "use loss for realm route= d requests and rate for host routed requests" Furthermore the client may never send host routed requests to S1. (And if i= t does, it will learn the host type OLR and selected algorithm in the corre= sponding answer). I'm aware that there may be cases where agent and server select the same al= gorithm and the problem described above disappears, but even then we should= not mandate including the host-type OLR in the answer that corresponds to = a realm type request. Best regards Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com]=20 Sent: Tuesday, September 09, 2014 12:01 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bart= olome@ericsson.com Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Sep 9 04:16:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303F71A00A6 for ; Tue, 9 Sep 2014 04:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI-LwJQblXTX for ; Tue, 9 Sep 2014 04:16:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8C21A0087 for ; Tue, 9 Sep 2014 04:16:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s89BGD3H023291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Sep 2014 11:16:13 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s89BGCXJ020714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 13:16:12 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Sep 2014 13:16:12 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 13:16:12 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "maria.cruz.bartolome@ericsson.com" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAAA0igIAAJvQA Date: Tue, 9 Sep 2014 11:16:12 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A2CF@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10913 X-purgate-ID: 151667::1410261373-00005326-1B3E2E2E/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U0fcua78RHDyjZYSEvsRXiinzPY Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 11:16:20 -0000 Jacques, in this scenario where the client supports DOIC my understanding is: If there is a realm overload, the agent will receive only those realm route= d requests that survived a throttling at the client. There is no point for = the agent to throttle again. Anyway this seems not to be related to #70. See also inline. Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com]=20 Sent: Tuesday, September 09, 2014 12:48 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear all Another remark on this type of use cases. There is a realm overload, the DA receives a realm routed request and decid= e to throttle it and generates a Diameter error (congestion or too busy und= er discussion). The request was not sent to any server; which Origin-Host A= VP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 s= tates that "Origin-Host AVP MUST be present in all Diameter messages. This = AVP identifies the endpoint that originated the Diameter message".=20 Another clarification, in our discussions, we speak of OLRs put in successf= ul answers; my understanding is that OLRs may also be present in unsuccess= ful answers (with a Diameter error). Do we agree on this? [Wiehe, Ulrich (NSN - DE/Munich)] I agree. Best regards Jacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: mardi 9 septembre 2014 12:01 =C0=A0: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich);= dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: 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 nobody Tue Sep 9 08:10:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D011A6FB0 for ; Tue, 9 Sep 2014 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChtjNFJ6FuzD for ; Tue, 9 Sep 2014 08:10:34 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40FC1A034D for ; Tue, 9 Sep 2014 08:10:33 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63412 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XRN3m-0006AN-KQ; Tue, 09 Sep 2014 08:10:26 -0700 Message-ID: <540F185E.6080706@usdonovans.com> Date: Tue, 09 Sep 2014 10:10:22 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/a2y2yIQtJr_2Rw5ZKuHVdJIDCOc Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 15:10:35 -0000 All, I agree with JJ that we have had this discussion and, I believe, we reached the conclusion that the OLR MUST be in all answer messages. This seems a much more resilient and interoperable solution. Anyone can implement a proprietary solution that doesn't address all of the MUST requirements, but that will not work with other implementations. If we want to take away the MUST then we need to expand the solution to include a way for the reporting node to know for sure that the reacting node received the OLR. Regards, Steve On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: > Hi JJ, > > I share your view and it is the responsibility of the reporting node to ensure that the OLR reaches the target node. > If the reporting node is not following "a" below then it has to have other means to know the target of the response and also have to keep track if the active OLR was already sent or not. > We don’t have to suggest the reporting node to do this but at the same time we need not forbid this type of implementation. > > So I am also fine to specify that if the OLR is not received by the reacting node then the previously received OLR stands valid. > > Regards, > Nirav. > > -----Original Message----- > From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alcatel-lucent.com] > Sent: Monday, September 08, 2014 7:56 PM > To: Steve Donovan; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) > Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received > > > Dear all > > I think we are restarting a discussion we had a few months ago. > The question is how frequently the OLR (with same seq number, so no change)is sent? > a) current text in the draft is that the reporting node (in overload condition) must include an OC-OLR AVP in all response messages > b) it can also be said it is only sent once when a change occurs in the OLR. It is in theory enough > c) in the middle , it can be sent in a few / many messages > > b) is not secure, as the answer conveying the new OLR can be lost. c) is OK for me if when there is a change in the OLR, the reporting node rapidly send a significant amount of answers with the same seq number so to consider with a high probability that the reacting node has well received the new OLR. (Note: With the current draft, apart this way, I do not well see how the reporting node knows that the reacting node has well received the new OLR) > > I think that it was considered simpler to always send OLR in each answer than to have to take a decision at each answer to send it or not. We also had a similar debate about the OC-Supported-Features) to be always present or not. > > So a) is OK for me as simple. I accept the idea of some tolerance, with Mcruz proposal that the absence of the OLR simply means no change. But this tolerance should not drive to a b) behavior. > > Best regards > > JJacques > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) Envoyé : lundi 8 septembre 2014 06:48 À : Steve Donovan; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received > > Steve, > >> I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node. > I don’t think this is necessary. The reporting may include the OLR in every answer message but we don’t have to put that as mandatory requirement, e.g. if the reporting node knows (and keeps track of) if the target reacting node has already received currently active OLR. > > Regards, > Nirav. > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Friday, September 05, 2014 8:01 PM > To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com > Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received > > Maria Cruz, > > I'm not sure I agree with this proposed change. > > The wording to indicate that absence of an overload report was to handle unusual situations. Your proposed wording implies that it is acceptable for a reporting node to not include the OLR in every answer message. > > I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node. > > Regards, > > Steve > > On 9/5/14, 3:03 AM, dime issue tracker wrote: >> #72: Reporting Node Behaviour when OC-OLR is not received >> >> A clarification is required to consider that an answer message may not >> include OC-OLR and still the reporting node be overloaded, since it is >> considered as "no change", as documented in 4.2.1.3: >> >> Reacting nodes do not delete an OCS when receiving an answer message >> that does not contain an OC-OLR AVP (i.e. absence of OLR means "no >> change"). >> >> >> Original text: >> >> 5.3. Reporting Node Behavior (Normative) >> >> The method a reporting nodes uses to determine the amount of traffic >> reduction required to address an overload condition is an >> implementation decision. >> >> When a reporting node that has selected the loss abatement algorithm >> determines the need to request a traffic reduction it must include an >> OC-OLR AVP in all response messages. >> >> >> Proposed addition: >> >> >> 5.3. Reporting Node Behavior (Normative) >> >> The method a reporting nodes uses to determine the amount of traffic >> reduction required to address an overload condition is an >> implementation decision. >> >> When a reporting node that has selected the loss abatement algorithm >> determines the need to request a traffic reduction it must include an >> OC-OLR AVP in all response messages. OC-OLR AVP is not included when >> reporting node expectations on traffic reduction are not modified. That >> is, if OC-OLR AVP is not included it is interpreted as “no changeâ€. >> > _______________________________________________ > 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 nobody Tue Sep 9 08:12:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046511A0AE9 for ; Tue, 9 Sep 2014 08:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO0Pm760vl-E for ; Tue, 9 Sep 2014 08:12:12 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3BC1A034D for ; Tue, 9 Sep 2014 08:12:12 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63416 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XRN5R-0007tv-MG; Tue, 09 Sep 2014 08:12:10 -0700 Message-ID: <540F18C5.2010802@usdonovans.com> Date: Tue, 09 Sep 2014 10:12:05 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "Wiehe, Ulrich (NSN - DE/Munich)" References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> <540A032C.5010808@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9g4XdWq2zxUjcUrU1z18UaRzfxY Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 15:12:15 -0000 JJ, I think this is the behavior currently in the DOIC draft. Are you suggesting changes to any wording in the draft? Regards, Steve On 9/8/14, 4:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote: > HI > > To complement my previous mail > > Instead to refer to the 3GPP TR 29.807, I should have referred to the normative TS 29.274 v 12.5.0 integrating GTP Overload control (chapter 12) with sections 12.3.5.1.2.1 Overload Control Sequence Number 276 and 12.3.5.1.2.2 Period of Validity and the following statement > "The sender of this information shall increment the Overload-Sequence-Number associated to a particular overload scope whenever modifying some information in the Overload-Control-Information IE. The Overload-Sequence-Number shall not be incremented otherwise." > > Best regards > > JJacques > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Envoyé : lundi 8 septembre 2014 09:25 > À : dime@ietf.org; Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich) > Objet : Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time > > Dear all > > I suggest to have a look at what is foreseen with GTP overload control, where there is a validity timer with a recommended handling (TR 29.807 6.2.2.1.2. and 6.2.2.1.3). I think for Diameter and GTP overload we should have the same handling of the Validity period (and also the seq number) as I do not see a reason/justification them to be different. > > For both cases the important point is that the timer (in the reacting node) is restarted only when a new sequence number is received (as Steve indicated, the IETF draft is clear here: in 6.3 "The validity time MUST NOT be updated after reception of subsequent OC-OLR AVPs with the same sequence number") > > If the reacting node wants to recalculate the value at each answer, why not (as Steve said this is an implementation choice, probably not the best one), but if the reporting node wants the reacting node to take the new value sent in the OLR into account, it has to change the seq number. The frequency at which the reporting node updates the validity period is also implementation specific and depends of the overload characteristics. > > Another remark is that as the OLRs may be received out of order, if the reporting node changes the validity period value (without changing the seq number) in OLR it sends, the reporting cannot be sure of the value that the reacting node will use, for this it will have to change the seq number. So better to send the same value in OLRs if the same seq number. I think the principle is that the OLR content if the same (same AVPS with same values) if the seq number is not modified. This point is not clearly stated in the draft, may be good to indicate this. Otherwise, I do not think we have to modify the OCS. > > Best regards > > JJacques > > > > > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : vendredi 5 septembre 2014 20:39 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time > > Ulrich, > > What the reporting node does is an implementation decision. If the reporting node wants to have precise control over when overload reports end on all reacting nodes then it can calculate the duration for every answer message sent. If it considers it ok to have a staggered end of the OLR, or if it sends explicit end-of-overload OLRs then it might choose to not recalculate. I don't see the need to specify that behavior in the DOIC specification. > > The reacting node MUST NOT recalculate the expiration time because the sequence number is the same. The reacting node will ignore the overload report and not bother to even look at any parameters in the report other then the sequence number. > > Regards, > > Steve > > On 9/5/14, 10:32 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> if - as proposed by MCruz - the validity duration is not stored at the reporting node, the reporting node always has to calculate the duration (e.g. 4 min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and the reacting node has to calculate the expiration time from reception time and duration. Would it not be more straight forward to transmit the expiry time rather than the duration? This avoids the need to send different values depending on sending time. >> >> Regards >> Ulrich >> >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Friday, September 05, 2014 5:16 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for >> Reporting Nodes - Expiry Time >> >> Ulrich, >> >> My interpretation is that two OLRs with the same sequence number apply >> to the same overload event at the reporting node. The contents do not >> need to be the same, although the only item in a loss report that is >> likely to change is the validation time. >> >> The important behavior is that the reacting node ignores an overload >> report with a sequence number it has already seen. If that behavior >> is followed then it doesn't matter if the contents of the report is an >> exact replay of a previous report. >> >> Regards, >> >> Steve >> >> On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>> >>> I would have thought that two OLRs with same sequence number must have same OLR content, especially same duration. >>> A replay is either an exact replay or its not a replay. >>> Regards >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Friday, September 05, 2014 3:59 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for >>> Reporting Nodes - Expiry Time >>> >>> Ulrich, >>> >>> I think it would be correct for the OLR sent at 10:01 to indicate >>> that the OLR expires in four minutes. >>> >>> A reacting node that has already received the OLR will ignore it >>> because the sequence number is unchanged. A reacting node that has >>> not already received the OLR will treat it as a new report and get >>> the correct expiration time. >>> >>> It is certainly possible to implement it so that the OLR sent to a >>> specific reacting node always gets an exact replay until the report >>> changes or expires but I don't see that as a requirement. >>> >>> Regards, >>> >>> Steve >>> >>> On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >>>> Dear Ulrich, >>>> >>>> Not sure if I understand your point. >>>> Is it your intention to send Validity-Duration AVP = OCS Validity Duration (in your example 300 s) until timer expires (in your example until 10:05)? >>>> Could you elaborate a bit further please? >>>> >>>> Thanks >>>> /MCruz >>>> >>>> -----Original Message----- >>>> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >>>> Sent: viernes, 05 de septiembre de 2014 10:15 >>>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz >>>> Bartolome >>>> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for >>>> Reporting Nodes - Expiry Time >>>> >>>> Dear Maria Cruz, >>>> >>>> I do not agree. >>>> As an example assume that the reporting node creates an overload state at 10:00 with a duration of 5 minutes. This means that Validity duration is 5 minutes and expiry time is 10:05. >>>> If only expiration time but not validity duration is stored at the reporting node, this will result in the following: >>>> For an answer message that is sent immediately (i.e. at 10:00) validity duration will be calculated as 5 minutes (which I think is correct). >>>> For an answer message that is sent at 10:01 validity duration will be calculated as 4 minutes, which I think is not correct. The answer message sent at 10:01 should contain a replay of the OLR already sent at 10:00, not an updated OLR. >>>> >>>> Therefore validity duration should not be removed from the OCS. >>>> >>>> Best regards >>>> Ulrich >>>> >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime >>>> issue tracker >>>> Sent: Friday, September 05, 2014 9:15 AM >>>> To: draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com >>>> Cc: dime@ietf.org >>>> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting >>>> Nodes - Expiry Time >>>> >>>> #67: OCS for Reporting Nodes - Expiry Time >>>> >>>> What does "Validity Duration" mean as the information stored in OCS for Reporting Nodes? >>>> >>>> We need to store some information that allow the reporting node to calculate a Validity-Duration value to be included in each OC-OLR AVP Then, I presume we need just Expiry Time, and then value to be included in each Validation-Duration AVP is calculated based on this. >>>> >>>> Then, original text: >>>> >>>> 4.2.1.2. Overload Control States for Reporting Nodes >>>> >>>> A reporting node maintains per supported Diameter application and per >>>> supported (and eventually selected) Abatement Algorithm an Overload >>>> Control State. >>>> >>>> An Overload Control State may be identified by the pair of >>>> Application-Id and supported Abatement Algorithm. >>>> >>>> The Overload Control State for a given pair of Application and >>>> Abatement Algorithm could include the information: >>>> >>>> o Sequence number >>>> >>>> o Validity Duration and Expiry Time >>>> >>>> o Algorithm specific input data (e.g. Reduction Percentage for >>>> Loss) >>>> >>>> Overload Control States for reporting nodes containing a validity >>>> duration of 0 sec. should not expire before any previously sent >>>> (stale) OLR has timed out at any reacting node. >>>> >>>> Editor's note: This statement is unclear and contradictory with other >>>> statements. A validity timer of zero seconds indicates that the >>>> overload condition has ended and abatement is no longer requested. >>>> >>>> >>>> Proposed modification: >>>> >>>> 4.2.1.2. Overload Control States for Reporting Nodes >>>> >>>> A reporting node maintains per supported Diameter application and per >>>> supported (and eventually selected) Abatement Algorithm an Overload >>>> Control State. >>>> >>>> An Overload Control State may be identified by the pair of >>>> Application-Id and supported Abatement Algorithm. >>>> >>>> The Overload Control State for a given pair of Application and >>>> Abatement Algorithm could include the information: >>>> >>>> o Sequence number >>>> >>>> o Expiry Time >>>> >>>> o Algorithm specific input data (e.g. Reduction Percentage for >>>> Loss) >>>> >>>> Expiry Time is used by the reporting node to calculate the value to be >>>> included in each Validity-Duration AVP, as part of the overload report. >>>> >>> _______________________________________________ >>> 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 nobody Tue Sep 9 08:16:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6B51A6FEE for ; Tue, 9 Sep 2014 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2rGi-I1PREq for ; Tue, 9 Sep 2014 08:15:59 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C3C1A6FF9 for ; Tue, 9 Sep 2014 08:15:40 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63422 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XRN8r-0002xB-L9; Tue, 09 Sep 2014 08:15:39 -0700 Message-ID: <540F1999.6020804@usdonovans.com> Date: Tue, 09 Sep 2014 10:15:37 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> <5409CBEE.9070607@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xmatumHGiDlgSdmIwcWyA7Yh2_o Cc: dime@ietf.org Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 15:16:00 -0000 Ben, I agree, this wording is better. Steve On 9/8/14, 4:02 PM, Ben Campbell wrote: > Steve, am I correct in assuming the removal of the 2119 "MUST" was intentional? (For the record, I agree--in this context it's a statement of fact, not a normative requirement.) > > If so, I suggest changing it to something other than "must" to avoid confusion with MUST. For example, > > " Since the "loss" abatement algorithm [crossref] is mandatory to implement, DOIC can always be enabled between these two endpoints." > > On Sep 5, 2014, at 9:42 AM, Steve Donovan wrote: > >> Maria Cruz, >> >> I support the need for these changes. I have a proposal for alternative wording below. >> >> Regards, >> >> Steve >> >> On 9/5/14, 2:30 AM, dime issue tracker wrote: >>> #68: Loss as the common abatemen algorithm >>> >>> Some text is misleading since it may imply that one feature shall be in >>> common between reporting and reacting node to progress, but in reality we >>> only need to have one common abatement algorithm, and in this draft, LOSS >>> is defined as default, then there is always one common algorithm >>> >>> Corrections are required in following clauses: >>> >>> Original text: >>> >>> 4.2.3. Reporting Node Behavior (Normative) >>> >>> ... >>> >>> The operation on the reporting node is straight forward. The >>> reporting node learns the capabilities of the reacting node when it >>> receives the OC-Supported-Features AVP as part of any Diameter >>> request message. If the reporting node shares at least one common >>> feature with the reacting node, then the DOIC can be enabled between >>> these two endpoints. See Section 4.1 for further discussion on the >>> capability and feature announcement between two endpoints. >>> >>> >>> Proposed modification: >>> >>> 4.2.3. Reporting Node Behavior (Normative) >>> >>> ... >>> >>> The >>> reporting node learns the capabilities of the reacting node when it >>> receives the OC-Supported-Features AVP as part of any Diameter >>> request message. Both reacting and reporting node MUST share at least >>> one abatement algorithm, in fact, they share at least the loss algorithm, >>> that is defined in this document as the default abatement algorithm, then >>> the DOIC can always be enabled between these two endpoints at least with >>> the default algorithm. See Section 4.1 for further discussion on the >>> capability and feature announcement between two endpoints. >> SRD> I propose the following wording: >> >> The reporting node learns the capabilities of the reacting node when it receives the >> OC-Supported-Featuers AVP as part of any Diameter request message. At a minimum, >> the reacting node and reporting node must both the loss abatement algorithm defined in this document >> and, as a result, DOIC can always be enabled between these two endpoints. See Section >> 4.1 ... >>> >>> >>> Original text: >>> >>> 6.1. OC-Supported-Features AVP >>> >>> ... >>> >>> During the message exchange the overload control endpoints express >>> their common set of supported capabilities. The reacting node >>> includes the OC-Supported-Features AVP that announces what it >>> supports. The reporting node that sends the answer also includes the >>> OC-Supported-Features AVP that describes the capabilities it >>> supports. The set of capabilities advertised by the reporting node >>> depends on local policies. At least one of the announced >>> capabilities MUST match. If there is no single matching capability >>> the reacting node MUST act as if it does not implement DOIC and cease >>> inserting any DOIC related AVPs into any Diameter messages with this >>> specific reacting node. >>> >>> Editor's note: The last sentence conflicts with the last sentence >>> two paragraphs up. In reality, there will always be at least one >>> matching capability as all nodes supporting DOIC must support the >>> loss algorithm. Suggest removing the last sentence. >>> >>> >>> Proposed text: >>> >>> 6.1. OC-Supported-Features AVP >>> >>> ... >>> >>> During the message exchange the overload control endpoints express >>> their common set of supported capabilities. The reacting node >>> includes the OC-Supported-Features AVP that announces what it >>> supports. The reporting node that sends the answer also includes the >>> OC-Supported-Features AVP that describes the capabilities it >>> supports. The set of capabilities advertised by the reporting node >>> depends on local policies. Both reacting and reporting node MUST share >>> at least one abatement algorithm, in fact, they share at least the loss >>> algorithm, that is defined in this document as the default abatement >>> algorithm, then the DOIC can always be enabled between these two endpoints >>> at least with the default algorithm. See Section 4.1 for further >>> discussion on the capability and feature announcement between two >>> endpoints. >>> >> SRD> I propose the following: >> >> ... Both the reacting and reporting nodes must support the loss abatement algorithm >> defined in this document. As a result, DOIC behavior can always be enabled between >> the reacting and reporting nodes. See Section 4.1 ... >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Sep 9 08:16:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9F11A6FE0 for ; Tue, 9 Sep 2014 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXUcxHI9b2bI for ; Tue, 9 Sep 2014 08:16:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988521A6FF4 for ; Tue, 9 Sep 2014 08:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10658; q=dns/txt; s=iport; t=1410275775; x=1411485375; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b2h+Y0aWyDuq5ZBJ3mI/vw3RRPy4iNSvckrxPAQmTNQ=; b=bjvRHuoiYI/+pW/n30E8jef8DSu83Nuei19V3fdDA0K3N3dUpULoVlJc 4vD54IpUHPiP2N39Jv2//hY/PSC/e/nfP4HmeKm4h65cmcfLd0z1VSASO ePqgUC7W9huSfLSXXqJHLKUu6lOlVOGtMX0oQm+1qHblAqrXS7gbVpKzu 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAEAZD1StJA2F/2dsb2JhbABTBoMNU1cEgnjHJQqHTAEZdBZ4hAMBAQEEAQEBIBE6FwQCAQgOAwQBAQECAgYdAwICAiULFAEICAIEARIIE4gnDaZ7lWoBEwSBLIhUhQoSOAaCczaBHQWRQaBgghuBRmwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,491,1406592000"; d="scan'208";a="353761437" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2014 15:16:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s89FGDc8020337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 15:16:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 10:16:13 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/1+Q8BEs1TL06ARTN1arg4/pvy7gSAgAO/zUCAAPW+AP//veCggAHg/AD//6y4IA== Date: Tue, 9 Sep 2014 15:16:12 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> In-Reply-To: <540F185E.6080706@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SCojqgsCsreuq2tUvT7oUSWKR3A Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 15:16:31 -0000 U3RldmUsDQoNCkkgZG9u4oCZdCBhZ3JlZSB0aGF0ICJ3ZSBuZWVkIHRvIHByb3ZpZGUgdGhlIHNv bHV0aW9uIGZvciB0aGUgcmVwb3J0aW5nIG5vZGUgdG8ga25vdyBpZiB0aGUgcmVwb3J0IHJlYWNo ZWQgdGhlIHJlYWN0aW5nIG5vZGUgb3Igbm90Ii4NClRoZSBwb2ludCBiZWluZywgaXQgaXMgdGhl IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSByZXBvcnRpbmcgbm9kZSB0byBlbnN1cmUgdGhhdCB0aGUg cmVwb3J0IHJlYWNoZXMgdGhlIHJlYWN0aW5nIG5vZGUgZWxzZSB0aGUgb3ZlcmxvYWQgc29sdXRp b24gd2lsbCBub3QgaGVscC4gQnV0IHRoaXMgZG9lcyBub3QganVzdGlmeSBNVVNUIHJlcXVpcmVt ZW50IHNpbmNlIHRoaXMgbWVhbnMgYW55IGFsdGVybmF0ZSBzb2x1dGlvbiBpcyBub3QgYWxsb3dl ZC4NCg0KTWFueSBuZXR3b3JrcyBtYXkgaGF2ZSB2ZXJ5IHNpbXBsZSB0b3BvbG9neSBvZiBvbmUg UENSRiBjb25uZWN0ZWQgdG8gb25lIFBHVy4gV2h5IHNob3VsZCB3ZSBlbmZvcmNlIHRoZSBQQ1JG L1BHVyB0byBpbmNsdWRlICJzYW1lIiBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UsIGluIHRo YXQgY2FzZT8NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogU3RldmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDksIDIwMTQgODo0MCBQTQ0KVG86IE5pcmF2IFNh bG90IChuc2Fsb3QpOyBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUyk7IGRpbWVA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyBtYXJpYS5jcnV6 LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20NClN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICM3MiAo ZHJhZnQtaWV0Zi1kaW1lLW92bGkpOiBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvdXIgd2hlbiBPQy1P TFIgaXMgbm90IHJlY2VpdmVkDQoNCkFsbCwNCg0KSSBhZ3JlZSB3aXRoIEpKIHRoYXQgd2UgaGF2 ZSBoYWQgdGhpcyBkaXNjdXNzaW9uIGFuZCwgSSBiZWxpZXZlLCB3ZSByZWFjaGVkIHRoZSBjb25j bHVzaW9uIHRoYXQgdGhlIE9MUiBNVVNUIGJlIGluIGFsbCBhbnN3ZXIgbWVzc2FnZXMuDQoNClRo aXMgc2VlbXMgYSBtdWNoIG1vcmUgcmVzaWxpZW50IGFuZCBpbnRlcm9wZXJhYmxlIHNvbHV0aW9u LiAgQW55b25lIGNhbiBpbXBsZW1lbnQgYSBwcm9wcmlldGFyeSBzb2x1dGlvbiB0aGF0IGRvZXNu J3QgYWRkcmVzcyBhbGwgb2YgdGhlIE1VU1QgcmVxdWlyZW1lbnRzLCBidXQgdGhhdCB3aWxsIG5v dCB3b3JrIHdpdGggb3RoZXIgaW1wbGVtZW50YXRpb25zLiAgSWYgd2Ugd2FudCB0byB0YWtlIGF3 YXkgdGhlIE1VU1QgdGhlbiB3ZSBuZWVkIHRvIGV4cGFuZCB0aGUgc29sdXRpb24gdG8gaW5jbHVk ZSBhIHdheSBmb3IgdGhlIHJlcG9ydGluZyBub2RlIHRvIGtub3cgZm9yIHN1cmUgdGhhdCB0aGUg cmVhY3Rpbmcgbm9kZSByZWNlaXZlZCB0aGUgT0xSLg0KDQpSZWdhcmRzLA0KDQpTdGV2ZQ0KDQpP biA5LzgvMTQsIDEwOjMxIEFNLCBOaXJhdiBTYWxvdCAobnNhbG90KSB3cm90ZToNCj4gSGkgSkos DQo+DQo+IEkgc2hhcmUgeW91ciB2aWV3IGFuZCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2Yg dGhlIHJlcG9ydGluZyBub2RlIHRvIGVuc3VyZSB0aGF0IHRoZSBPTFIgcmVhY2hlcyB0aGUgdGFy Z2V0IG5vZGUuDQo+IElmIHRoZSByZXBvcnRpbmcgbm9kZSBpcyBub3QgZm9sbG93aW5nICJhIiBi ZWxvdyB0aGVuIGl0IGhhcyB0byBoYXZlIG90aGVyIG1lYW5zIHRvIGtub3cgdGhlIHRhcmdldCBv ZiB0aGUgcmVzcG9uc2UgYW5kIGFsc28gaGF2ZSB0byBrZWVwIHRyYWNrIGlmIHRoZSBhY3RpdmUg T0xSIHdhcyBhbHJlYWR5IHNlbnQgb3Igbm90Lg0KPiBXZSBkb27igJl0IGhhdmUgdG8gc3VnZ2Vz dCB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZG8gdGhpcyBidXQgYXQgdGhlIHNhbWUgdGltZSB3ZSBu ZWVkIG5vdCBmb3JiaWQgdGhpcyB0eXBlIG9mIGltcGxlbWVudGF0aW9uLg0KPg0KPiBTbyBJIGFt IGFsc28gZmluZSB0byBzcGVjaWZ5IHRoYXQgaWYgdGhlIE9MUiBpcyBub3QgcmVjZWl2ZWQgYnkg dGhlIHJlYWN0aW5nIG5vZGUgdGhlbiB0aGUgcHJldmlvdXNseSByZWNlaXZlZCBPTFIgc3RhbmRz IHZhbGlkLg0KPg0KPiBSZWdhcmRzLA0KPiBOaXJhdi4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpIA0K PiBbbWFpbHRvOmplYW4tamFjcXVlcy50cm90dGluQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4gU2Vu dDogTW9uZGF5LCBTZXB0ZW1iZXIgMDgsIDIwMTQgNzo1NiBQTQ0KPiBUbzogU3RldmUgRG9ub3Zh bjsgZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IA0K PiBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb207IE5pcmF2IFNhbG90IChuc2Fsb3Qp DQo+IFN1YmplY3Q6IFJFOiBbRGltZV0gW2RpbWVdICM3MiAoZHJhZnQtaWV0Zi1kaW1lLW92bGkp OiBSZXBvcnRpbmcgTm9kZSANCj4gQmVoYXZpb3VyIHdoZW4gT0MtT0xSIGlzIG5vdCByZWNlaXZl ZA0KPg0KPg0KPiBEZWFyIGFsbA0KPg0KPiBJIHRoaW5rIHdlIGFyZSByZXN0YXJ0aW5nIGEgZGlz Y3Vzc2lvbiB3ZSBoYWQgYSBmZXcgbW9udGhzIGFnby4NCj4gVGhlIHF1ZXN0aW9uIGlzIGhvdyBm cmVxdWVudGx5IHRoZSBPTFIgKHdpdGggc2FtZSBzZXEgbnVtYmVyLCBzbyBubyBjaGFuZ2UpaXMg c2VudD8NCj4gYSkgY3VycmVudCB0ZXh0IGluIHRoZSBkcmFmdCBpcyB0aGF0IHRoZSByZXBvcnRp bmcgbm9kZSAoaW4gb3ZlcmxvYWQgDQo+IGNvbmRpdGlvbikgIG11c3QgaW5jbHVkZSBhbiAgT0Mt T0xSIEFWUCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMNCj4gYikgaXQgY2FuIGFsc28gYmUgc2Fp ZCBpdCBpcyBvbmx5IHNlbnQgb25jZSB3aGVuIGEgY2hhbmdlIG9jY3VycyBpbiANCj4gdGhlIE9M Ui4gSXQgaXMgaW4gdGhlb3J5IGVub3VnaA0KPiBjKSBpbiB0aGUgbWlkZGxlICwgaXQgY2FuIGJl IHNlbnQgaW4gYSBmZXcgLyBtYW55IG1lc3NhZ2VzDQo+DQo+IGIpIGlzIG5vdCBzZWN1cmUsIGFz IHRoZSBhbnN3ZXIgY29udmV5aW5nIHRoZSBuZXcgT0xSIGNhbiBiZSBsb3N0LiBjKSANCj4gaXMg T0sgZm9yIG1lIGlmIHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgaW4gdGhlIE9MUiwgdGhlIHJlcG9y dGluZyBub2RlIA0KPiByYXBpZGx5ICBzZW5kIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9mIGFuc3dl cnMgd2l0aCB0aGUgc2FtZSBzZXEgbnVtYmVyICANCj4gc28gdG8gY29uc2lkZXIgd2l0aCBhIGhp Z2ggcHJvYmFiaWxpdHkgdGhhdCB0aGUgcmVhY3Rpbmcgbm9kZSAgaGFzIA0KPiB3ZWxsIHJlY2Vp dmVkIHRoZSBuZXcgIE9MUi4gKE5vdGU6IFdpdGggdGhlIGN1cnJlbnQgZHJhZnQsIGFwYXJ0IHRo aXMgDQo+IHdheSwgSSBkbyBub3Qgd2VsbCBzZWUgaG93IHRoZSByZXBvcnRpbmcgbm9kZSBrbm93 cyB0aGF0IHRoZSByZWFjdGluZyANCj4gbm9kZSBoYXMgd2VsbCByZWNlaXZlZCB0aGUgbmV3IE9M UikNCj4NCj4gSSB0aGluayB0aGF0IGl0IHdhcyAgY29uc2lkZXJlZCBzaW1wbGVyICB0byBhbHdh eXMgc2VuZCBPTFIgaW4gZWFjaCBhbnN3ZXIgdGhhbiB0byBoYXZlIHRvIHRha2UgYSBkZWNpc2lv biBhdCBlYWNoIGFuc3dlciB0byBzZW5kIGl0IG9yIG5vdC4gV2UgYWxzbyBoYWQgYSBzaW1pbGFy IGRlYmF0ZSBhYm91dCB0aGUgT0MtU3VwcG9ydGVkLUZlYXR1cmVzKSB0byBiZSBhbHdheXMgcHJl c2VudCBvciBub3QuDQo+DQo+IFNvIGEpIGlzIE9LIGZvciBtZSBhcyBzaW1wbGUuIEkgYWNjZXB0 IHRoZSBpZGVhIG9mIHNvbWUgdG9sZXJhbmNlLCB3aXRoIE1jcnV6IHByb3Bvc2FsIHRoYXQgdGhl IGFic2VuY2Ugb2YgdGhlIE9MUiBzaW1wbHkgbWVhbnMgbm8gY2hhbmdlLiBCdXQgdGhpcyB0b2xl cmFuY2Ugc2hvdWxkIG5vdCBkcml2ZSB0byBhIGIpIGJlaGF2aW9yLg0KPg0KPiBCZXN0IHJlZ2Fy ZHMNCj4NCj4gSkphY3F1ZXMNCj4gICANCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBO aXJhdiBTYWxvdCANCj4gKG5zYWxvdCkgRW52b3nDqSA6IGx1bmRpIDggc2VwdGVtYnJlIDIwMTQg MDY6NDggw4AgOiBTdGV2ZSBEb25vdmFuOyANCj4gZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1k aW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7IA0KPiBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nv bi5jb20gT2JqZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjNzIgDQo+IChkcmFmdC1pZXRmLWRpbWUt b3ZsaSk6IFJlcG9ydGluZyBOb2RlIEJlaGF2aW91ciB3aGVuIE9DLU9MUiBpcyBub3QgDQo+IHJl Y2VpdmVkDQo+DQo+IFN0ZXZlLA0KPg0KPj4gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc3BlY2lm eSB0aGUgYmVoYXZpb3Igb2YgdGhlIHJlcG9ydGluZyBub2RlIHRvIGFsd2F5cyBpbmNsdWRlIHRo ZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UgZm9yIGFzIGxvbmcgYXMgdGhlcmUgaXMgYW4g b3ZlcmxvYWQgY29uZGl0aW9uIGF0IHRoZSByZXBvcnRpbmcgbm9kZS4NCj4gSSBkb27igJl0IHRo aW5rIHRoaXMgaXMgbmVjZXNzYXJ5LiBUaGUgcmVwb3J0aW5nIG1heSBpbmNsdWRlIHRoZSBPTFIg aW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UgYnV0IHdlIGRvbuKAmXQgaGF2ZSB0byBwdXQgdGhhdCBh cyBtYW5kYXRvcnkgcmVxdWlyZW1lbnQsIGUuZy4gaWYgdGhlIHJlcG9ydGluZyBub2RlIGtub3dz IChhbmQga2VlcHMgdHJhY2sgb2YpIGlmIHRoZSB0YXJnZXQgcmVhY3Rpbmcgbm9kZSBoYXMgYWxy ZWFkeSByZWNlaXZlZCBjdXJyZW50bHkgYWN0aXZlIE9MUi4NCj4NCj4gUmVnYXJkcywNCj4gTmly YXYuDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERpTUUgW21haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQo+IFNl bnQ6IEZyaWRheSwgU2VwdGVtYmVyIDA1LCAyMDE0IDg6MDEgUE0NCj4gVG86IGRpbWVAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRvb2xzLmlldGYub3JnOyANCj4gbWFyaWEuY3J1ei5i YXJ0b2xvbWVAZXJpY3Nzb24uY29tDQo+IFN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICM3MiAo ZHJhZnQtaWV0Zi1kaW1lLW92bGkpOiBSZXBvcnRpbmcgTm9kZSANCj4gQmVoYXZpb3VyIHdoZW4g T0MtT0xSIGlzIG5vdCByZWNlaXZlZA0KPg0KPiBNYXJpYSBDcnV6LA0KPg0KPiBJJ20gbm90IHN1 cmUgSSBhZ3JlZSB3aXRoIHRoaXMgcHJvcG9zZWQgY2hhbmdlLg0KPg0KPiBUaGUgd29yZGluZyB0 byBpbmRpY2F0ZSB0aGF0IGFic2VuY2Ugb2YgYW4gb3ZlcmxvYWQgcmVwb3J0IHdhcyB0byBoYW5k bGUgdW51c3VhbCBzaXR1YXRpb25zLiAgWW91ciBwcm9wb3NlZCB3b3JkaW5nIGltcGxpZXMgdGhh dCBpdCBpcyBhY2NlcHRhYmxlIGZvciBhIHJlcG9ydGluZyBub2RlIHRvIG5vdCBpbmNsdWRlIHRo ZSBPTFIgaW4gZXZlcnkgYW5zd2VyIG1lc3NhZ2UuDQo+DQo+IEkgdGhpbmsgaXQgaXMgYmV0dGVy IHRvIHNwZWNpZnkgdGhlIGJlaGF2aW9yIG9mIHRoZSByZXBvcnRpbmcgbm9kZSB0byBhbHdheXMg aW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlIGZvciBhcyBsb25nIGFzIHRo ZXJlIGlzIGFuIG92ZXJsb2FkIGNvbmRpdGlvbiBhdCB0aGUgcmVwb3J0aW5nIG5vZGUuDQo+DQo+ IFJlZ2FyZHMsDQo+DQo+IFN0ZXZlDQo+DQo+IE9uIDkvNS8xNCwgMzowMyBBTSwgZGltZSBpc3N1 ZSB0cmFja2VyIHdyb3RlOg0KPj4gIzcyOiBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvdXIgd2hlbiBP Qy1PTFIgaXMgbm90IHJlY2VpdmVkDQo+Pg0KPj4gICAgQSBjbGFyaWZpY2F0aW9uIGlzIHJlcXVp cmVkIHRvIGNvbnNpZGVyIHRoYXQgYW4gYW5zd2VyIG1lc3NhZ2UgbWF5IG5vdA0KPj4gICAgaW5j bHVkZSBPQy1PTFIgYW5kIHN0aWxsIHRoZSByZXBvcnRpbmcgbm9kZSBiZSAgb3ZlcmxvYWRlZCwg c2luY2UgaXQgaXMNCj4+ICAgIGNvbnNpZGVyZWQgYXMgIm5vIGNoYW5nZSIsIGFzIGRvY3VtZW50 ZWQgaW4gNC4yLjEuMzoNCj4+DQo+PiAgICAgICAgUmVhY3Rpbmcgbm9kZXMgZG8gbm90IGRlbGV0 ZSBhbiBPQ1Mgd2hlbiByZWNlaXZpbmcgYW4gYW5zd2VyIG1lc3NhZ2UNCj4+ICAgICAgICB0aGF0 IGRvZXMgbm90IGNvbnRhaW4gYW4gT0MtT0xSIEFWUCAoaS5lLiBhYnNlbmNlIG9mIE9MUiBtZWFu cyAibm8NCj4+ICAgICAgICBjaGFuZ2UiKS4NCj4+DQo+Pg0KPj4gICAgT3JpZ2luYWwgdGV4dDoN Cj4+DQo+PiAgICA1LjMuICBSZXBvcnRpbmcgTm9kZSBCZWhhdmlvciAoTm9ybWF0aXZlKQ0KPj4N Cj4+ICAgICAgIFRoZSBtZXRob2QgYSByZXBvcnRpbmcgbm9kZXMgdXNlcyB0byBkZXRlcm1pbmUg dGhlIGFtb3VudCBvZiB0cmFmZmljDQo+PiAgICAgICByZWR1Y3Rpb24gcmVxdWlyZWQgdG8gYWRk cmVzcyBhbiBvdmVybG9hZCBjb25kaXRpb24gaXMgYW4NCj4+ICAgICAgIGltcGxlbWVudGF0aW9u IGRlY2lzaW9uLg0KPj4NCj4+ICAgICAgIFdoZW4gYSByZXBvcnRpbmcgbm9kZSB0aGF0IGhhcyBz ZWxlY3RlZCB0aGUgbG9zcyBhYmF0ZW1lbnQgYWxnb3JpdGhtDQo+PiAgICAgICBkZXRlcm1pbmVz IHRoZSBuZWVkIHRvIHJlcXVlc3QgYSB0cmFmZmljIHJlZHVjdGlvbiBpdCBtdXN0IGluY2x1ZGUg YW4NCj4+ICAgICAgIE9DLU9MUiBBVlAgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzLg0KPj4NCj4+ DQo+PiAgICBQcm9wb3NlZCBhZGRpdGlvbjoNCj4+DQo+Pg0KPj4gICAgNS4zLiAgUmVwb3J0aW5n IE5vZGUgQmVoYXZpb3IgKE5vcm1hdGl2ZSkNCj4+DQo+PiAgICAgICBUaGUgbWV0aG9kIGEgcmVw b3J0aW5nIG5vZGVzIHVzZXMgdG8gZGV0ZXJtaW5lIHRoZSBhbW91bnQgb2YgdHJhZmZpYw0KPj4g ICAgICAgcmVkdWN0aW9uIHJlcXVpcmVkIHRvIGFkZHJlc3MgYW4gb3ZlcmxvYWQgY29uZGl0aW9u IGlzIGFuDQo+PiAgICAgICBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbi4NCj4+DQo+PiAgICAgICBX aGVuIGEgcmVwb3J0aW5nIG5vZGUgdGhhdCBoYXMgc2VsZWN0ZWQgdGhlIGxvc3MgYWJhdGVtZW50 IGFsZ29yaXRobQ0KPj4gICAgICAgZGV0ZXJtaW5lcyB0aGUgbmVlZCB0byByZXF1ZXN0IGEgdHJh ZmZpYyByZWR1Y3Rpb24gaXQgbXVzdCBpbmNsdWRlIGFuDQo+PiAgICAgICBPQy1PTFIgQVZQIGlu IGFsbCByZXNwb25zZSBtZXNzYWdlcy4gT0MtT0xSIEFWUCBpcyBub3QgaW5jbHVkZWQgd2hlbg0K Pj4gICAgcmVwb3J0aW5nIG5vZGUgZXhwZWN0YXRpb25zIG9uIHRyYWZmaWMgcmVkdWN0aW9uIGFy ZSBub3QgbW9kaWZpZWQuIFRoYXQNCj4+ICAgIGlzLCBpZiBPQy1PTFIgQVZQIGlzIG5vdCBpbmNs dWRlZCBpdCBpcyBpbnRlcnByZXRlZCBhcyDigJxubyBjaGFuZ2XigJ0uDQo+Pg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcg bGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0KPiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQo= From nobody Tue Sep 9 10:14:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929131A8026 for ; Tue, 9 Sep 2014 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo-EvD-0n3Bg for ; Tue, 9 Sep 2014 10:14:33 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073411A7003 for ; Tue, 9 Sep 2014 10:14:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56767 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XROzs-00032T-3U; Tue, 09 Sep 2014 10:14:30 -0700 Message-ID: <540F3573.9030202@usdonovans.com> Date: Tue, 09 Sep 2014 12:14:27 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eI5zM8LGDvKZzMYHsSoA3VoaTd0 Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 17:14:34 -0000 Nirav, My concern is with interoperability. I'm also concerned with agent based cases where the reporting node doesn't know if it is the client for the transaction or an agent that is the reacting node. We also need to address the fact that both the client and an agent will be reacting nodes for host reports in agent based deployments. I think we can achieve what you are looking for with the following. This is just the concept, not the formal wording. ----- The reporting node MUST ensure that all reacting nodes for the transaction receive all new and updated overload reports. This includes the client for the transaction and agents involved in the transaction that have a direct connection to the reporting node. The recommended method to achieve this is to send OLRs in all answer messages sent while the reporting node has an active overload report. Out-of-band mechanisms can also be used by reporting nodes to determine that reacting nodes have received overload reports but these SHOULD NOT be used in cross vendor deployments. ----- Regards, Steve On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote: > Steve, > > I don’t agree that "we need to provide the solution for the reporting node to know if the report reached the reacting node or not". > The point being, it is the responsibility of the reporting node to ensure that the report reaches the reacting node else the overload solution will not help. But this does not justify MUST requirement since this means any alternate solution is not allowed. > > Many networks may have very simple topology of one PCRF connected to one PGW. Why should we enforce the PCRF/PGW to include "same" OLR in every answer message, in that case? > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, September 09, 2014 8:40 PM > To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com > Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received > > All, > > I agree with JJ that we have had this discussion and, I believe, we reached the conclusion that the OLR MUST be in all answer messages. > > This seems a much more resilient and interoperable solution. Anyone can implement a proprietary solution that doesn't address all of the MUST requirements, but that will not work with other implementations. If we want to take away the MUST then we need to expand the solution to include a way for the reporting node to know for sure that the reacting node received the OLR. > > Regards, > > Steve > > On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: >> Hi JJ, >> >> I share your view and it is the responsibility of the reporting node to ensure that the OLR reaches the target node. >> If the reporting node is not following "a" below then it has to have other means to know the target of the response and also have to keep track if the active OLR was already sent or not. >> We don’t have to suggest the reporting node to do this but at the same time we need not forbid this type of implementation. >> >> So I am also fine to specify that if the OLR is not received by the reacting node then the previously received OLR stands valid. >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >> [mailto:jean-jacques.trottin@alcatel-lucent.com] >> Sent: Monday, September 08, 2014 7:56 PM >> To: Steve Donovan; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >> maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) >> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node >> Behaviour when OC-OLR is not received >> >> >> Dear all >> >> I think we are restarting a discussion we had a few months ago. >> The question is how frequently the OLR (with same seq number, so no change)is sent? >> a) current text in the draft is that the reporting node (in overload >> condition) must include an OC-OLR AVP in all response messages >> b) it can also be said it is only sent once when a change occurs in >> the OLR. It is in theory enough >> c) in the middle , it can be sent in a few / many messages >> >> b) is not secure, as the answer conveying the new OLR can be lost. c) >> is OK for me if when there is a change in the OLR, the reporting node >> rapidly send a significant amount of answers with the same seq number >> so to consider with a high probability that the reacting node has >> well received the new OLR. (Note: With the current draft, apart this >> way, I do not well see how the reporting node knows that the reacting >> node has well received the new OLR) >> >> I think that it was considered simpler to always send OLR in each answer than to have to take a decision at each answer to send it or not. We also had a similar debate about the OC-Supported-Features) to be always present or not. >> >> So a) is OK for me as simple. I accept the idea of some tolerance, with Mcruz proposal that the absence of the OLR simply means no change. But this tolerance should not drive to a b) behavior. >> >> Best regards >> >> JJacques >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >> (nsalot) Envoyé : lundi 8 septembre 2014 06:48 À : Steve Donovan; >> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >> maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 >> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not >> received >> >> Steve, >> >>> I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node. >> I don’t think this is necessary. The reporting may include the OLR in every answer message but we don’t have to put that as mandatory requirement, e.g. if the reporting node knows (and keeps track of) if the target reacting node has already received currently active OLR. >> >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Friday, September 05, 2014 8:01 PM >> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >> maria.cruz.bartolome@ericsson.com >> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node >> Behaviour when OC-OLR is not received >> >> Maria Cruz, >> >> I'm not sure I agree with this proposed change. >> >> The wording to indicate that absence of an overload report was to handle unusual situations. Your proposed wording implies that it is acceptable for a reporting node to not include the OLR in every answer message. >> >> I think it is better to specify the behavior of the reporting node to always include the OLR in every answer message for as long as there is an overload condition at the reporting node. >> >> Regards, >> >> Steve >> >> On 9/5/14, 3:03 AM, dime issue tracker wrote: >>> #72: Reporting Node Behaviour when OC-OLR is not received >>> >>> A clarification is required to consider that an answer message may not >>> include OC-OLR and still the reporting node be overloaded, since it is >>> considered as "no change", as documented in 4.2.1.3: >>> >>> Reacting nodes do not delete an OCS when receiving an answer message >>> that does not contain an OC-OLR AVP (i.e. absence of OLR means "no >>> change"). >>> >>> >>> Original text: >>> >>> 5.3. Reporting Node Behavior (Normative) >>> >>> The method a reporting nodes uses to determine the amount of traffic >>> reduction required to address an overload condition is an >>> implementation decision. >>> >>> When a reporting node that has selected the loss abatement algorithm >>> determines the need to request a traffic reduction it must include an >>> OC-OLR AVP in all response messages. >>> >>> >>> Proposed addition: >>> >>> >>> 5.3. Reporting Node Behavior (Normative) >>> >>> The method a reporting nodes uses to determine the amount of traffic >>> reduction required to address an overload condition is an >>> implementation decision. >>> >>> When a reporting node that has selected the loss abatement algorithm >>> determines the need to request a traffic reduction it must include an >>> OC-OLR AVP in all response messages. OC-OLR AVP is not included when >>> reporting node expectations on traffic reduction are not modified. That >>> is, if OC-OLR AVP is not included it is interpreted as “no changeâ€. >>> >> _______________________________________________ >> 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 nobody Tue Sep 9 10:31:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805DA1A700B for ; Tue, 9 Sep 2014 10:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu8xu-dx_eYh for ; Tue, 9 Sep 2014 10:31:05 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A22A1A700F for ; Tue, 9 Sep 2014 10:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13516; q=dns/txt; s=iport; t=1410283865; x=1411493465; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wRYUhUKxTZ9VAaN7PSdC8KB55ZxUxpXKWTB7YdQWDgc=; b=Dk2DlF01Kv7n0OizrPvi89twPrLqeyaX0bd+L5JktLmyVafepdTSxEdW 5wrKh+WKTlcS6cQbUuUZ3XLuVhIweD+t5ILq5GfNhY/M8T5NYwKFa2ZO2 T5KjxQWrpNnAtKHWuohFTI0pBUh5QkTIKvO8AVgGNIr2V1Ho+FE6pDbew 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAA84D1StJA2B/2dsb2JhbABTBoMNU1cEgnjHJQqHTAEZdBZ4hAMBAQEEAQEBIBE6FwQCAQgOAwQBAQECAgYdAwICAiULFAEICAIEARIIE4gnDacwlWYBEwSBLIhUhQoSFiIGgnM2gR0FkUGgYIIbgUZsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,492,1406592000"; d="scan'208";a="353796721" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 09 Sep 2014 17:31:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s89HV3OC030303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 17:31:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 12:31:03 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/1+Q8BEs1TL06ARTN1arg4/pvy7gSAgAO/zUCAAPW+AP//veCggAHg/AD//6y4IIAAdfOA//+vRUA= Date: Tue, 9 Sep 2014 17:31:02 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> In-Reply-To: <540F3573.9030202@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.217] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-qZDZftQuKkP1-9YUBqNpJYaofk Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 09 Sep 2014 17:31:08 -0000 U3RldmUsDQoNClRoZSBwcmluY2lwbGUgb2YgeW91ciBwcm9wb3NhbCBpcyBmaW5lIHdpdGggbWUu DQoNCkZvciB0aGUgd29yZGluZywgSSBkb27igJl0IHRoaW5rIGl0IGlzIGNvcnJlY3QgdG8gc2F5 ICJTSE9VTEQgTk9UIGJlIHVzZWQgaW4gY3Jvc3MgdmVuZG9yIGRlcGxveW1lbnRzIiBzaW5jZSB0 aGVyZSBpcyBub3RoaW5nIHZlbmRvciBzcGVjaWZpYyBoZXJlLg0KUGVyaGFwcywgIk1BWSBCRSB1 c2VkIGluIHNwZWNpZmljIGNhc2VzLCBlLmcuIHdoZW4gdGhlIHJlcG9ydGluZyBub2RlIGlzIGF3 YXJlIGFib3V0IHRoZSBuZXR3b3JrIHRvcG9sb2d5Ii4NCg0KUmVnYXJkcywNCk5pcmF2Lg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RldmUgRG9ub3ZhbiBbbWFpbHRvOnNy ZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDksIDIw MTQgMTA6NDQgUE0NClRvOiBOaXJhdiBTYWxvdCAobnNhbG90KTsgVFJPVFRJTiwgSkVBTi1KQUNR VUVTIChKRUFOLUpBQ1FVRVMpOyBkaW1lQGlldGYub3JnOyBkcmFmdC1pZXRmLWRpbWUtb3ZsaUB0 b29scy5pZXRmLm9yZzsgbWFyaWEuY3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29tDQpTdWJqZWN0 OiBSZTogW0RpbWVdIFtkaW1lXSAjNzIgKGRyYWZ0LWlldGYtZGltZS1vdmxpKTogUmVwb3J0aW5n IE5vZGUgQmVoYXZpb3VyIHdoZW4gT0MtT0xSIGlzIG5vdCByZWNlaXZlZA0KDQpOaXJhdiwNCg0K TXkgY29uY2VybiBpcyB3aXRoIGludGVyb3BlcmFiaWxpdHkuICBJJ20gYWxzbyBjb25jZXJuZWQg d2l0aCBhZ2VudCBiYXNlZCBjYXNlcyB3aGVyZSB0aGUgcmVwb3J0aW5nIG5vZGUgZG9lc24ndCBr bm93IGlmIGl0IGlzIHRoZSBjbGllbnQgZm9yIHRoZSB0cmFuc2FjdGlvbiBvciBhbiBhZ2VudCB0 aGF0IGlzIHRoZSByZWFjdGluZyBub2RlLiBXZSBhbHNvIG5lZWQgdG8gYWRkcmVzcyB0aGUgZmFj dCB0aGF0IGJvdGggdGhlIGNsaWVudCBhbmQgYW4gYWdlbnQgd2lsbCBiZSByZWFjdGluZyBub2Rl cyBmb3IgaG9zdCByZXBvcnRzIGluIGFnZW50IGJhc2VkIGRlcGxveW1lbnRzLg0KDQpJIHRoaW5r IHdlIGNhbiBhY2hpZXZlIHdoYXQgeW91IGFyZSBsb29raW5nIGZvciB3aXRoIHRoZSBmb2xsb3dp bmcuIFRoaXMgaXMganVzdCB0aGUgY29uY2VwdCwgbm90IHRoZSBmb3JtYWwgd29yZGluZy4NCg0K LS0tLS0NCg0KVGhlIHJlcG9ydGluZyBub2RlIE1VU1QgZW5zdXJlIHRoYXQgYWxsIHJlYWN0aW5n IG5vZGVzIGZvciB0aGUgdHJhbnNhY3Rpb24gcmVjZWl2ZSBhbGwgbmV3IGFuZCB1cGRhdGVkIG92 ZXJsb2FkIHJlcG9ydHMuICBUaGlzIGluY2x1ZGVzIHRoZSBjbGllbnQgZm9yIHRoZSB0cmFuc2Fj dGlvbiBhbmQgYWdlbnRzIGludm9sdmVkIGluIHRoZSB0cmFuc2FjdGlvbiB0aGF0IGhhdmUgYSBk aXJlY3QgY29ubmVjdGlvbiB0byB0aGUgcmVwb3J0aW5nIG5vZGUuDQoNClRoZSByZWNvbW1lbmRl ZCBtZXRob2QgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvIHNlbmQgT0xScyBpbiBhbGwgYW5zd2VyIG1l c3NhZ2VzIHNlbnQgd2hpbGUgdGhlIHJlcG9ydGluZyBub2RlIGhhcyBhbiBhY3RpdmUgb3Zlcmxv YWQgcmVwb3J0LiAgDQpPdXQtb2YtYmFuZCBtZWNoYW5pc21zIGNhbiBhbHNvIGJlIHVzZWQgYnkg cmVwb3J0aW5nIG5vZGVzIHRvIGRldGVybWluZSB0aGF0IHJlYWN0aW5nIG5vZGVzIGhhdmUgcmVj ZWl2ZWQgb3ZlcmxvYWQgcmVwb3J0cyBidXQgdGhlc2UgU0hPVUxEIE5PVCBiZSB1c2VkIGluIGNy b3NzIHZlbmRvciBkZXBsb3ltZW50cy4NCg0KLS0tLS0NCg0KUmVnYXJkcywNCg0KU3RldmUNCg0K DQoNCk9uIDkvOS8xNCwgMTA6MTYgQU0sIE5pcmF2IFNhbG90IChuc2Fsb3QpIHdyb3RlOg0KPiBT dGV2ZSwNCj4NCj4gSSBkb27igJl0IGFncmVlIHRoYXQgIndlIG5lZWQgdG8gcHJvdmlkZSB0aGUg c29sdXRpb24gZm9yIHRoZSByZXBvcnRpbmcgbm9kZSB0byBrbm93IGlmIHRoZSByZXBvcnQgcmVh Y2hlZCB0aGUgcmVhY3Rpbmcgbm9kZSBvciBub3QiLg0KPiBUaGUgcG9pbnQgYmVpbmcsIGl0IGlz IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZW5zdXJlIHRoYXQg dGhlIHJlcG9ydCByZWFjaGVzIHRoZSByZWFjdGluZyBub2RlIGVsc2UgdGhlIG92ZXJsb2FkIHNv bHV0aW9uIHdpbGwgbm90IGhlbHAuIEJ1dCB0aGlzIGRvZXMgbm90IGp1c3RpZnkgTVVTVCByZXF1 aXJlbWVudCBzaW5jZSB0aGlzIG1lYW5zIGFueSBhbHRlcm5hdGUgc29sdXRpb24gaXMgbm90IGFs bG93ZWQuDQo+DQo+IE1hbnkgbmV0d29ya3MgbWF5IGhhdmUgdmVyeSBzaW1wbGUgdG9wb2xvZ3kg b2Ygb25lIFBDUkYgY29ubmVjdGVkIHRvIG9uZSBQR1cuIFdoeSBzaG91bGQgd2UgZW5mb3JjZSB0 aGUgUENSRi9QR1cgdG8gaW5jbHVkZSAic2FtZSIgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdl LCBpbiB0aGF0IGNhc2U/DQo+DQo+IFJlZ2FyZHMsDQo+IE5pcmF2Lg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGV2ZSBEb25vdmFuIFttYWlsdG86c3Jkb25vdmFu QHVzZG9ub3ZhbnMuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDksIDIwMTQgODo0 MCBQTQ0KPiBUbzogTmlyYXYgU2Fsb3QgKG5zYWxvdCk7IFRST1RUSU4sIEpFQU4tSkFDUVVFUyAo SkVBTi1KQUNRVUVTKTsgDQo+IGRpbWVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRv b2xzLmlldGYub3JnOyANCj4gbWFyaWEuY3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29tDQo+IFN1 YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVdICM3MiAoZHJhZnQtaWV0Zi1kaW1lLW92bGkpOiBSZXBv cnRpbmcgTm9kZSANCj4gQmVoYXZpb3VyIHdoZW4gT0MtT0xSIGlzIG5vdCByZWNlaXZlZA0KPg0K PiBBbGwsDQo+DQo+IEkgYWdyZWUgd2l0aCBKSiB0aGF0IHdlIGhhdmUgaGFkIHRoaXMgZGlzY3Vz c2lvbiBhbmQsIEkgYmVsaWV2ZSwgd2UgcmVhY2hlZCB0aGUgY29uY2x1c2lvbiB0aGF0IHRoZSBP TFIgTVVTVCBiZSBpbiBhbGwgYW5zd2VyIG1lc3NhZ2VzLg0KPg0KPiBUaGlzIHNlZW1zIGEgbXVj aCBtb3JlIHJlc2lsaWVudCBhbmQgaW50ZXJvcGVyYWJsZSBzb2x1dGlvbi4gIEFueW9uZSBjYW4g aW1wbGVtZW50IGEgcHJvcHJpZXRhcnkgc29sdXRpb24gdGhhdCBkb2Vzbid0IGFkZHJlc3MgYWxs IG9mIHRoZSBNVVNUIHJlcXVpcmVtZW50cywgYnV0IHRoYXQgd2lsbCBub3Qgd29yayB3aXRoIG90 aGVyIGltcGxlbWVudGF0aW9ucy4gIElmIHdlIHdhbnQgdG8gdGFrZSBhd2F5IHRoZSBNVVNUIHRo ZW4gd2UgbmVlZCB0byBleHBhbmQgdGhlIHNvbHV0aW9uIHRvIGluY2x1ZGUgYSB3YXkgZm9yIHRo ZSByZXBvcnRpbmcgbm9kZSB0byBrbm93IGZvciBzdXJlIHRoYXQgdGhlIHJlYWN0aW5nIG5vZGUg cmVjZWl2ZWQgdGhlIE9MUi4NCj4NCj4gUmVnYXJkcywNCj4NCj4gU3RldmUNCj4NCj4gT24gOS84 LzE0LCAxMDozMSBBTSwgTmlyYXYgU2Fsb3QgKG5zYWxvdCkgd3JvdGU6DQo+PiBIaSBKSiwNCj4+ DQo+PiBJIHNoYXJlIHlvdXIgdmlldyBhbmQgaXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRo ZSByZXBvcnRpbmcgbm9kZSB0byBlbnN1cmUgdGhhdCB0aGUgT0xSIHJlYWNoZXMgdGhlIHRhcmdl dCBub2RlLg0KPj4gSWYgdGhlIHJlcG9ydGluZyBub2RlIGlzIG5vdCBmb2xsb3dpbmcgImEiIGJl bG93IHRoZW4gaXQgaGFzIHRvIGhhdmUgb3RoZXIgbWVhbnMgdG8ga25vdyB0aGUgdGFyZ2V0IG9m IHRoZSByZXNwb25zZSBhbmQgYWxzbyBoYXZlIHRvIGtlZXAgdHJhY2sgaWYgdGhlIGFjdGl2ZSBP TFIgd2FzIGFscmVhZHkgc2VudCBvciBub3QuDQo+PiBXZSBkb27igJl0IGhhdmUgdG8gc3VnZ2Vz dCB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gZG8gdGhpcyBidXQgYXQgdGhlIHNhbWUgdGltZSB3ZSBu ZWVkIG5vdCBmb3JiaWQgdGhpcyB0eXBlIG9mIGltcGxlbWVudGF0aW9uLg0KPj4NCj4+IFNvIEkg YW0gYWxzbyBmaW5lIHRvIHNwZWNpZnkgdGhhdCBpZiB0aGUgT0xSIGlzIG5vdCByZWNlaXZlZCBi eSB0aGUgcmVhY3Rpbmcgbm9kZSB0aGVuIHRoZSBwcmV2aW91c2x5IHJlY2VpdmVkIE9MUiBzdGFu ZHMgdmFsaWQuDQo+Pg0KPj4gUmVnYXJkcywNCj4+IE5pcmF2Lg0KPj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFD UVVFUykgDQo+PiBbbWFpbHRvOmplYW4tamFjcXVlcy50cm90dGluQGFsY2F0ZWwtbHVjZW50LmNv bV0NCj4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDA4LCAyMDE0IDc6NTYgUE0NCj4+IFRvOiBT dGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnOyANCj4+IGRyYWZ0LWlldGYtZGltZS1vdmxpQHRv b2xzLmlldGYub3JnOw0KPj4gbWFyaWEuY3J1ei5iYXJ0b2xvbWVAZXJpY3Nzb24uY29tOyBOaXJh diBTYWxvdCAobnNhbG90KQ0KPj4gU3ViamVjdDogUkU6IFtEaW1lXSBbZGltZV0gIzcyIChkcmFm dC1pZXRmLWRpbWUtb3ZsaSk6IFJlcG9ydGluZyBOb2RlIA0KPj4gQmVoYXZpb3VyIHdoZW4gT0Mt T0xSIGlzIG5vdCByZWNlaXZlZA0KPj4NCj4+DQo+PiBEZWFyIGFsbA0KPj4NCj4+IEkgdGhpbmsg d2UgYXJlIHJlc3RhcnRpbmcgYSBkaXNjdXNzaW9uIHdlIGhhZCBhIGZldyBtb250aHMgYWdvLg0K Pj4gVGhlIHF1ZXN0aW9uIGlzIGhvdyBmcmVxdWVudGx5IHRoZSBPTFIgKHdpdGggc2FtZSBzZXEg bnVtYmVyLCBzbyBubyBjaGFuZ2UpaXMgc2VudD8NCj4+IGEpIGN1cnJlbnQgdGV4dCBpbiB0aGUg ZHJhZnQgaXMgdGhhdCB0aGUgcmVwb3J0aW5nIG5vZGUgKGluIG92ZXJsb2FkDQo+PiBjb25kaXRp b24pICBtdXN0IGluY2x1ZGUgYW4gIE9DLU9MUiBBVlAgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2Vz DQo+PiBiKSBpdCBjYW4gYWxzbyBiZSBzYWlkIGl0IGlzIG9ubHkgc2VudCBvbmNlIHdoZW4gYSBj aGFuZ2Ugb2NjdXJzIGluIA0KPj4gdGhlIE9MUi4gSXQgaXMgaW4gdGhlb3J5IGVub3VnaA0KPj4g YykgaW4gdGhlIG1pZGRsZSAsIGl0IGNhbiBiZSBzZW50IGluIGEgZmV3IC8gbWFueSBtZXNzYWdl cw0KPj4NCj4+IGIpIGlzIG5vdCBzZWN1cmUsIGFzIHRoZSBhbnN3ZXIgY29udmV5aW5nIHRoZSBu ZXcgT0xSIGNhbiBiZSBsb3N0LiBjKSANCj4+IGlzIE9LIGZvciBtZSBpZiB3aGVuIHRoZXJlIGlz IGEgY2hhbmdlIGluIHRoZSBPTFIsIHRoZSByZXBvcnRpbmcgbm9kZSANCj4+IHJhcGlkbHkgIHNl bmQgYSBzaWduaWZpY2FudCBhbW91bnQgb2YgYW5zd2VycyB3aXRoIHRoZSBzYW1lIHNlcSANCj4+ IG51bWJlciBzbyB0byBjb25zaWRlciB3aXRoIGEgaGlnaCBwcm9iYWJpbGl0eSB0aGF0IHRoZSBy ZWFjdGluZyBub2RlICANCj4+IGhhcyB3ZWxsIHJlY2VpdmVkIHRoZSBuZXcgIE9MUi4gKE5vdGU6 IFdpdGggdGhlIGN1cnJlbnQgZHJhZnQsIGFwYXJ0IA0KPj4gdGhpcyB3YXksIEkgZG8gbm90IHdl bGwgc2VlIGhvdyB0aGUgcmVwb3J0aW5nIG5vZGUga25vd3MgdGhhdCB0aGUgDQo+PiByZWFjdGlu ZyBub2RlIGhhcyB3ZWxsIHJlY2VpdmVkIHRoZSBuZXcgT0xSKQ0KPj4NCj4+IEkgdGhpbmsgdGhh dCBpdCB3YXMgIGNvbnNpZGVyZWQgc2ltcGxlciAgdG8gYWx3YXlzIHNlbmQgT0xSIGluIGVhY2gg YW5zd2VyIHRoYW4gdG8gaGF2ZSB0byB0YWtlIGEgZGVjaXNpb24gYXQgZWFjaCBhbnN3ZXIgdG8g c2VuZCBpdCBvciBub3QuIFdlIGFsc28gaGFkIGEgc2ltaWxhciBkZWJhdGUgYWJvdXQgdGhlIE9D LVN1cHBvcnRlZC1GZWF0dXJlcykgdG8gYmUgYWx3YXlzIHByZXNlbnQgb3Igbm90Lg0KPj4NCj4+ IFNvIGEpIGlzIE9LIGZvciBtZSBhcyBzaW1wbGUuIEkgYWNjZXB0IHRoZSBpZGVhIG9mIHNvbWUg dG9sZXJhbmNlLCB3aXRoIE1jcnV6IHByb3Bvc2FsIHRoYXQgdGhlIGFic2VuY2Ugb2YgdGhlIE9M UiBzaW1wbHkgbWVhbnMgbm8gY2hhbmdlLiBCdXQgdGhpcyB0b2xlcmFuY2Ugc2hvdWxkIG5vdCBk cml2ZSB0byBhIGIpIGJlaGF2aW9yLg0KPj4NCj4+IEJlc3QgcmVnYXJkcw0KPj4NCj4+IEpKYWNx dWVzDQo+PiAgICANCj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBEaU1F IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE5pcmF2IFNhbG90 DQo+PiAobnNhbG90KSBFbnZvecOpIDogbHVuZGkgOCBzZXB0ZW1icmUgMjAxNCAwNjo0OCDDgCA6 IFN0ZXZlIERvbm92YW47IA0KPj4gZGltZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1lLW92bGlA dG9vbHMuaWV0Zi5vcmc7DQo+PiBtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20gT2Jq ZXQgOiBSZTogW0RpbWVdIFtkaW1lXSAjNzINCj4+IChkcmFmdC1pZXRmLWRpbWUtb3ZsaSk6IFJl cG9ydGluZyBOb2RlIEJlaGF2aW91ciB3aGVuIE9DLU9MUiBpcyBub3QgDQo+PiByZWNlaXZlZA0K Pj4NCj4+IFN0ZXZlLA0KPj4NCj4+PiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBzcGVjaWZ5IHRo ZSBiZWhhdmlvciBvZiB0aGUgcmVwb3J0aW5nIG5vZGUgdG8gYWx3YXlzIGluY2x1ZGUgdGhlIE9M UiBpbiBldmVyeSBhbnN3ZXIgbWVzc2FnZSBmb3IgYXMgbG9uZyBhcyB0aGVyZSBpcyBhbiBvdmVy bG9hZCBjb25kaXRpb24gYXQgdGhlIHJlcG9ydGluZyBub2RlLg0KPj4gSSBkb27igJl0IHRoaW5r IHRoaXMgaXMgbmVjZXNzYXJ5LiBUaGUgcmVwb3J0aW5nIG1heSBpbmNsdWRlIHRoZSBPTFIgaW4g ZXZlcnkgYW5zd2VyIG1lc3NhZ2UgYnV0IHdlIGRvbuKAmXQgaGF2ZSB0byBwdXQgdGhhdCBhcyBt YW5kYXRvcnkgcmVxdWlyZW1lbnQsIGUuZy4gaWYgdGhlIHJlcG9ydGluZyBub2RlIGtub3dzIChh bmQga2VlcHMgdHJhY2sgb2YpIGlmIHRoZSB0YXJnZXQgcmVhY3Rpbmcgbm9kZSBoYXMgYWxyZWFk eSByZWNlaXZlZCBjdXJyZW50bHkgYWN0aXZlIE9MUi4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gTmly YXYuDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IERpTUUgW21h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGV2ZSBEb25vdmFuDQo+ PiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNSwgMjAxNCA4OjAxIFBNDQo+PiBUbzogZGltZUBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1lLW92bGlAdG9vbHMuaWV0Zi5vcmc7DQo+PiBtYXJpYS5j cnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20NCj4+IFN1YmplY3Q6IFJlOiBbRGltZV0gW2RpbWVd ICM3MiAoZHJhZnQtaWV0Zi1kaW1lLW92bGkpOiBSZXBvcnRpbmcgTm9kZSANCj4+IEJlaGF2aW91 ciB3aGVuIE9DLU9MUiBpcyBub3QgcmVjZWl2ZWQNCj4+DQo+PiBNYXJpYSBDcnV6LA0KPj4NCj4+ IEknbSBub3Qgc3VyZSBJIGFncmVlIHdpdGggdGhpcyBwcm9wb3NlZCBjaGFuZ2UuDQo+Pg0KPj4g VGhlIHdvcmRpbmcgdG8gaW5kaWNhdGUgdGhhdCBhYnNlbmNlIG9mIGFuIG92ZXJsb2FkIHJlcG9y dCB3YXMgdG8gaGFuZGxlIHVudXN1YWwgc2l0dWF0aW9ucy4gIFlvdXIgcHJvcG9zZWQgd29yZGlu ZyBpbXBsaWVzIHRoYXQgaXQgaXMgYWNjZXB0YWJsZSBmb3IgYSByZXBvcnRpbmcgbm9kZSB0byBu b3QgaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlLg0KPj4NCj4+IEkgdGhp bmsgaXQgaXMgYmV0dGVyIHRvIHNwZWNpZnkgdGhlIGJlaGF2aW9yIG9mIHRoZSByZXBvcnRpbmcg bm9kZSB0byBhbHdheXMgaW5jbHVkZSB0aGUgT0xSIGluIGV2ZXJ5IGFuc3dlciBtZXNzYWdlIGZv ciBhcyBsb25nIGFzIHRoZXJlIGlzIGFuIG92ZXJsb2FkIGNvbmRpdGlvbiBhdCB0aGUgcmVwb3J0 aW5nIG5vZGUuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBTdGV2ZQ0KPj4NCj4+IE9uIDkvNS8x NCwgMzowMyBBTSwgZGltZSBpc3N1ZSB0cmFja2VyIHdyb3RlOg0KPj4+ICM3MjogUmVwb3J0aW5n IE5vZGUgQmVoYXZpb3VyIHdoZW4gT0MtT0xSIGlzIG5vdCByZWNlaXZlZA0KPj4+DQo+Pj4gICAg IEEgY2xhcmlmaWNhdGlvbiBpcyByZXF1aXJlZCB0byBjb25zaWRlciB0aGF0IGFuIGFuc3dlciBt ZXNzYWdlIG1heSBub3QNCj4+PiAgICAgaW5jbHVkZSBPQy1PTFIgYW5kIHN0aWxsIHRoZSByZXBv cnRpbmcgbm9kZSBiZSAgb3ZlcmxvYWRlZCwgc2luY2UgaXQgaXMNCj4+PiAgICAgY29uc2lkZXJl ZCBhcyAibm8gY2hhbmdlIiwgYXMgZG9jdW1lbnRlZCBpbiA0LjIuMS4zOg0KPj4+DQo+Pj4gICAg ICAgICBSZWFjdGluZyBub2RlcyBkbyBub3QgZGVsZXRlIGFuIE9DUyB3aGVuIHJlY2VpdmluZyBh biBhbnN3ZXIgbWVzc2FnZQ0KPj4+ICAgICAgICAgdGhhdCBkb2VzIG5vdCBjb250YWluIGFuIE9D LU9MUiBBVlAgKGkuZS4gYWJzZW5jZSBvZiBPTFIgbWVhbnMgIm5vDQo+Pj4gICAgICAgICBjaGFu Z2UiKS4NCj4+Pg0KPj4+DQo+Pj4gICAgIE9yaWdpbmFsIHRleHQ6DQo+Pj4NCj4+PiAgICAgNS4z LiAgUmVwb3J0aW5nIE5vZGUgQmVoYXZpb3IgKE5vcm1hdGl2ZSkNCj4+Pg0KPj4+ICAgICAgICBU aGUgbWV0aG9kIGEgcmVwb3J0aW5nIG5vZGVzIHVzZXMgdG8gZGV0ZXJtaW5lIHRoZSBhbW91bnQg b2YgdHJhZmZpYw0KPj4+ICAgICAgICByZWR1Y3Rpb24gcmVxdWlyZWQgdG8gYWRkcmVzcyBhbiBv dmVybG9hZCBjb25kaXRpb24gaXMgYW4NCj4+PiAgICAgICAgaW1wbGVtZW50YXRpb24gZGVjaXNp b24uDQo+Pj4NCj4+PiAgICAgICAgV2hlbiBhIHJlcG9ydGluZyBub2RlIHRoYXQgaGFzIHNlbGVj dGVkIHRoZSBsb3NzIGFiYXRlbWVudCBhbGdvcml0aG0NCj4+PiAgICAgICAgZGV0ZXJtaW5lcyB0 aGUgbmVlZCB0byByZXF1ZXN0IGEgdHJhZmZpYyByZWR1Y3Rpb24gaXQgbXVzdCBpbmNsdWRlIGFu DQo+Pj4gICAgICAgIE9DLU9MUiBBVlAgaW4gYWxsIHJlc3BvbnNlIG1lc3NhZ2VzLg0KPj4+DQo+ Pj4NCj4+PiAgICAgUHJvcG9zZWQgYWRkaXRpb246DQo+Pj4NCj4+Pg0KPj4+ICAgICA1LjMuICBS ZXBvcnRpbmcgTm9kZSBCZWhhdmlvciAoTm9ybWF0aXZlKQ0KPj4+DQo+Pj4gICAgICAgIFRoZSBt ZXRob2QgYSByZXBvcnRpbmcgbm9kZXMgdXNlcyB0byBkZXRlcm1pbmUgdGhlIGFtb3VudCBvZiB0 cmFmZmljDQo+Pj4gICAgICAgIHJlZHVjdGlvbiByZXF1aXJlZCB0byBhZGRyZXNzIGFuIG92ZXJs b2FkIGNvbmRpdGlvbiBpcyBhbg0KPj4+ICAgICAgICBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbi4N Cj4+Pg0KPj4+ICAgICAgICBXaGVuIGEgcmVwb3J0aW5nIG5vZGUgdGhhdCBoYXMgc2VsZWN0ZWQg dGhlIGxvc3MgYWJhdGVtZW50IGFsZ29yaXRobQ0KPj4+ICAgICAgICBkZXRlcm1pbmVzIHRoZSBu ZWVkIHRvIHJlcXVlc3QgYSB0cmFmZmljIHJlZHVjdGlvbiBpdCBtdXN0IGluY2x1ZGUgYW4NCj4+ PiAgICAgICAgT0MtT0xSIEFWUCBpbiBhbGwgcmVzcG9uc2UgbWVzc2FnZXMuIE9DLU9MUiBBVlAg aXMgbm90IGluY2x1ZGVkIHdoZW4NCj4+PiAgICAgcmVwb3J0aW5nIG5vZGUgZXhwZWN0YXRpb25z IG9uIHRyYWZmaWMgcmVkdWN0aW9uIGFyZSBub3QgbW9kaWZpZWQuIFRoYXQNCj4+PiAgICAgaXMs IGlmIE9DLU9MUiBBVlAgaXMgbm90IGluY2x1ZGVkIGl0IGlzIGludGVycHJldGVkIGFzIOKAnG5v IGNoYW5nZeKAnS4NCj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IERpTUUgbWFpbGluZyBsaXN0DQo+PiBEaU1FQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBEaU1FIG1haWxpbmcgbGlz dA0KPj4gRGlNRUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaW1lDQoNCg== From nobody Tue Sep 9 19:37:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14271A0360 for ; Tue, 9 Sep 2014 19:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIGfRocieqeW for ; Tue, 9 Sep 2014 19:37:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0741A0348 for ; Tue, 9 Sep 2014 19:37:40 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8A2bVoW049858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Sep 2014 21:37:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> Date: Tue, 9 Sep 2014 21:37:31 -0500 X-Mao-Original-Outgoing-Id: 432009451.744359-c7bfc5148aa1a5215f0776646a586f5f Content-Transfer-Encoding: quoted-printable Message-Id: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bk1AEwAc079TG-gEVTjLg97I4Sw Cc: "draft-ietf-dime-ovli@tools.ietf.org" , "dime@ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 02:37:43 -0000 We had exactly that example in the draft discussed in Toronto ( = draft-donovan-doic-agent-cases ). Comments inline: On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Dear JJacques, >=20 > assume the following example: > In step 1 (realm routed request sent from Client to Agent), the client = indicates that it supports loss. > In step 2 (host routed request send from agent to S1), the agent = indicates that it supports loss and rate. > In step 3 (answer from S1 to agent, containing a host type OLR), S1 = indicates that it selected rate. >=20 > Now in step 4 there is no point in forwarding the host-type OLR from = agent to client as the client does not support rate. Similar for step 8 = where no host type OLR of rate shall be sent in addition to the = realm-type OLR of loss. I agree there is no point forwarding the OLR per se. However, the agent = may still indicate that it supports "loss" back to the client, and send = loss-based reports if the client sends too much traffic for the agent to = comply with the max rate without throttling. >=20 > Also note that the answer in step 8 can contain only one = Supported-Features AVP i.e. can only contain one selected algorithm. = Even when the agent supports loss and realm, you cannot say in one = answer "use loss for realm routed requests and rate for host routed = requests" One approach is where you end up with is "loss" is supported between the = client and agent, and "rate" is supported between the agent and server. Don't get me wrong, I'm not saying that's a _required_ approach, but it = should be allowed. >=20 > Furthermore the client may never send host routed requests to S1. (And = if it does, it will learn the host type OLR and selected algorithm in = the corresponding answer). >=20 I don't follow this. Do you mean "might never"? (I read "may never" as = "is never allowed to"). The agent has to ensure that any OLRs that get back to the client match = the capabilities the client advertised, and received. It could do that = by stripping all OC-S-F and OLR avps in answers, or it could act as as = an algorithm "gateway" and (statefully) translate between the = capabilities selected on either side.=20 > I'm aware that there may be cases where agent and server select the = same algorithm and the problem described above disappears, but even then = we should not mandate including the host-type OLR in the answer that = corresponds to a realm type request. I don't see that following. We should prevent a server from putting any = host reports into answers to realm routed requests. Otherwise, you have = use cases that just want work. For example, consider how a server could = report any overload at all for an application that is exclusively = realm-routed. Also, consider that with the recently discussed distinction between = realm-routed requests and host-routed requests, we consider a request to = be host-routed if it has a Destination-Host _or_ if a node has other = knowledge that the request will go to specific server (e.g., if the = peer-selection decision would send a request to the specific host. ) In = the second case, the server itself cannot distinguish a host-routed = request from a host-routed request. =20 From nobody Tue Sep 9 19:50:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1844D1A0389 for ; Tue, 9 Sep 2014 19:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAUgfhn_9wc9 for ; Tue, 9 Sep 2014 19:50:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D181A017C for ; Tue, 9 Sep 2014 19:50:23 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8A2oCUB050801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Sep 2014 21:50:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <540F3573.9030202@usdonovans.com> Date: Tue, 9 Sep 2014 21:50:12 -0500 X-Mao-Original-Outgoing-Id: 432010212.443404-c7fef912bacd065e8d075bff9260cdbf Content-Transfer-Encoding: quoted-printable Message-Id: <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Zk_E_hMIArrNBP59LTT3A1Xx61c Cc: "draft-ietf-dime-ovli@tools.ietf.org" , "dime@ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 02:50:27 -0000 On Sep 9, 2014, at 12:14 PM, Steve Donovan = wrote: > Nirav, >=20 > My concern is with interoperability. I'm also concerned with agent = based cases where the reporting node doesn't know if it is the client = for the transaction or an agent that is the reacting node. We also need = to address the fact that both the client and an agent will be reacting = nodes for host reports in agent based deployments. >=20 > I think we can achieve what you are looking for with the following. = This is just the concept, not the formal wording. >=20 > ----- >=20 > The reporting node MUST ensure that all reacting nodes for the = transaction receive all new and updated overload reports. This includes = the client for the transaction and agents involved in the transaction = that have a direct connection to the reporting node. >=20 > The recommended method to achieve this is to send OLRs in all answer = messages sent while the reporting node has an active overload report. = Out-of-band mechanisms can also be used by reporting nodes to determine = that reacting nodes have received overload reports but these SHOULD NOT = be used in cross vendor deployments. This is degenerating into weasel wording. Sending the OLR in every answer solves the issue for all cases. I can't = imagine a case where it does harm. Can someone suggest one? Do people = really think that making an _overloaded_ reporting node jump through = hoops with methods (whether proprietary or standardized) to determine = which reacting nodes have received the reports would every be a = reasonable implementation? Sending in every answer is cheap and easy. We should just do it. The text to make the reacting node handle getting an answer with no OLR = was there to handle weird corner cases. For example, e.g. two physical = hosts with same diameter identity. (Yes, those exist.) >=20 > ----- >=20 > Regards, >=20 > Steve >=20 >=20 >=20 > On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote: >> Steve, >>=20 >> I don=92t agree that "we need to provide the solution for the = reporting node to know if the report reached the reacting node or not". >> The point being, it is the responsibility of the reporting node to = ensure that the report reaches the reacting node else the overload = solution will not help. But this does not justify MUST requirement since = this means any alternate solution is not allowed. >>=20 >> Many networks may have very simple topology of one PCRF connected to = one PGW. Why should we enforce the PCRF/PGW to include "same" OLR in = every answer message, in that case? >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Tuesday, September 09, 2014 8:40 PM >> To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; = maria.cruz.bartolome@ericsson.com >> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node = Behaviour when OC-OLR is not received >>=20 >> All, >>=20 >> I agree with JJ that we have had this discussion and, I believe, we = reached the conclusion that the OLR MUST be in all answer messages. >>=20 >> This seems a much more resilient and interoperable solution. Anyone = can implement a proprietary solution that doesn't address all of the = MUST requirements, but that will not work with other implementations. = If we want to take away the MUST then we need to expand the solution to = include a way for the reporting node to know for sure that the reacting = node received the OLR. >>=20 >> Regards, >>=20 >> Steve >>=20 >> On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: >>> Hi JJ, >>>=20 >>> I share your view and it is the responsibility of the reporting node = to ensure that the OLR reaches the target node. >>> If the reporting node is not following "a" below then it has to have = other means to know the target of the response and also have to keep = track if the active OLR was already sent or not. >>> We don=92t have to suggest the reporting node to do this but at the = same time we need not forbid this type of implementation. >>>=20 >>> So I am also fine to specify that if the OLR is not received by the = reacting node then the previously received OLR stands valid. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >>> [mailto:jean-jacques.trottin@alcatel-lucent.com] >>> Sent: Monday, September 08, 2014 7:56 PM >>> To: Steve Donovan; dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) >>> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting = Node >>> Behaviour when OC-OLR is not received >>>=20 >>>=20 >>> Dear all >>>=20 >>> I think we are restarting a discussion we had a few months ago. >>> The question is how frequently the OLR (with same seq number, so no = change)is sent? >>> a) current text in the draft is that the reporting node (in overload >>> condition) must include an OC-OLR AVP in all response messages >>> b) it can also be said it is only sent once when a change occurs in >>> the OLR. It is in theory enough >>> c) in the middle , it can be sent in a few / many messages >>>=20 >>> b) is not secure, as the answer conveying the new OLR can be lost. = c) >>> is OK for me if when there is a change in the OLR, the reporting = node >>> rapidly send a significant amount of answers with the same seq = number >>> so to consider with a high probability that the reacting node has >>> well received the new OLR. (Note: With the current draft, apart = this >>> way, I do not well see how the reporting node knows that the = reacting >>> node has well received the new OLR) >>>=20 >>> I think that it was considered simpler to always send OLR in each = answer than to have to take a decision at each answer to send it or not. = We also had a similar debate about the OC-Supported-Features) to be = always present or not. >>>=20 >>> So a) is OK for me as simple. I accept the idea of some tolerance, = with Mcruz proposal that the absence of the OLR simply means no change. = But this tolerance should not drive to a b) behavior. >>>=20 >>> Best regards >>>=20 >>> JJacques >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>> (nsalot) Envoy=E9 : lundi 8 septembre 2014 06:48 =C0 : Steve = Donovan; >>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 >>> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not >>> received >>>=20 >>> Steve, >>>=20 >>>> I think it is better to specify the behavior of the reporting node = to always include the OLR in every answer message for as long as there = is an overload condition at the reporting node. >>> I don=92t think this is necessary. The reporting may include the OLR = in every answer message but we don=92t have to put that as mandatory = requirement, e.g. if the reporting node knows (and keeps track of) if = the target reacting node has already received currently active OLR. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Friday, September 05, 2014 8:01 PM >>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com >>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting = Node >>> Behaviour when OC-OLR is not received >>>=20 >>> Maria Cruz, >>>=20 >>> I'm not sure I agree with this proposed change. >>>=20 >>> The wording to indicate that absence of an overload report was to = handle unusual situations. Your proposed wording implies that it is = acceptable for a reporting node to not include the OLR in every answer = message. >>>=20 >>> I think it is better to specify the behavior of the reporting node = to always include the OLR in every answer message for as long as there = is an overload condition at the reporting node. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 9/5/14, 3:03 AM, dime issue tracker wrote: >>>> #72: Reporting Node Behaviour when OC-OLR is not received >>>>=20 >>>> A clarification is required to consider that an answer message = may not >>>> include OC-OLR and still the reporting node be overloaded, = since it is >>>> considered as "no change", as documented in 4.2.1.3: >>>>=20 >>>> Reacting nodes do not delete an OCS when receiving an answer = message >>>> that does not contain an OC-OLR AVP (i.e. absence of OLR = means "no >>>> change"). >>>>=20 >>>>=20 >>>> Original text: >>>>=20 >>>> 5.3. Reporting Node Behavior (Normative) >>>>=20 >>>> The method a reporting nodes uses to determine the amount of = traffic >>>> reduction required to address an overload condition is an >>>> implementation decision. >>>>=20 >>>> When a reporting node that has selected the loss abatement = algorithm >>>> determines the need to request a traffic reduction it must = include an >>>> OC-OLR AVP in all response messages. >>>>=20 >>>>=20 >>>> Proposed addition: >>>>=20 >>>>=20 >>>> 5.3. Reporting Node Behavior (Normative) >>>>=20 >>>> The method a reporting nodes uses to determine the amount of = traffic >>>> reduction required to address an overload condition is an >>>> implementation decision. >>>>=20 >>>> When a reporting node that has selected the loss abatement = algorithm >>>> determines the need to request a traffic reduction it must = include an >>>> OC-OLR AVP in all response messages. OC-OLR AVP is not = included when >>>> reporting node expectations on traffic reduction are not = modified. That >>>> is, if OC-OLR AVP is not included it is interpreted as =93no = change=94. >>>>=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 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Sep 9 22:18:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81FB1A04B0 for ; Tue, 9 Sep 2014 22:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXjziLq4SIru for ; Tue, 9 Sep 2014 22:18:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C618F1A035A for ; Tue, 9 Sep 2014 22:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11726; q=dns/txt; s=iport; t=1410326313; x=1411535913; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R1Alq+Nye8cH6/dMm2XICQT6skAKYHK3Ks1awrnzyd4=; b=J39l7FZb5Gdk0qd/IZXYN05tgfXVWY7MJWEb4kySnwgn+/Y0vkIFEvNi 06n82ixdyy/GhhLmmOjyfM0ryasEVurFkHSdrwlleHAuQkT0KEr4GDI0e RMqBtBbDtaIdYytyWPXgD2yoNSfF98ZU244DUa/+dTsVbgk6xJdyvA1RE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFANjeD1StJA2K/2dsb2JhbABQAwaDDVNXBMowCodMAYEKFniEAwEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQBDQMCCBOIHwgNvSEBEwSKAIRyGBIxBwaDKYEdBYp6hkegYIIbgUZBKwGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,496,1406592000"; d="scan'208";a="353986788" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 10 Sep 2014 05:18:32 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8A5IVq9005401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 05:18:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 00:18:31 -0500 From: "Nirav Salot (nsalot)" To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/1+Q8BEs1TL06ARTN1arg4/pvy7gSAgAO/zUCAAPW+AP//veCggAHg/AD//6y4IIAAdfOAgACg3QD//9RZgA== Date: Wed, 10 Sep 2014 05:18:31 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> In-Reply-To: <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.217] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/p3H4YAVaK4_382IC0RdUA59oULE Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 05:18:36 -0000 Ben, > Sending in every answer is cheap and easy. We should just do it. I woundnt agree on cheap since redundant information is sent in every answe= r message. I already mentioned the simple topology of one PGW connected to = one PCRF directly where even DRA is not used. > The text to make the reacting node handle getting an answer with no OLR w= as there to handle weird corner cases. For example, e.g. two physical hosts= with same diameter identity. (Yes, those exist.) Nothing is changing from the reacting node since "absent of OLR should stil= l mean that the previously received OLR is active". The idea is just to not "force" reporting node with a particular behavior. Regards, Nirav. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, September 10, 2014 8:20 AM To: Steve Donovan Cc: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behav= iour when OC-OLR is not received On Sep 9, 2014, at 12:14 PM, Steve Donovan wrote= : > Nirav, >=20 > My concern is with interoperability. I'm also concerned with agent based= cases where the reporting node doesn't know if it is the client for the tr= ansaction or an agent that is the reacting node. We also need to address th= e fact that both the client and an agent will be reacting nodes for host re= ports in agent based deployments. >=20 > I think we can achieve what you are looking for with the following. This = is just the concept, not the formal wording. >=20 > ----- >=20 > The reporting node MUST ensure that all reacting nodes for the transactio= n receive all new and updated overload reports. This includes the client f= or the transaction and agents involved in the transaction that have a direc= t connection to the reporting node. >=20 > The recommended method to achieve this is to send OLRs in all answer mess= ages sent while the reporting node has an active overload report. Out-of-b= and mechanisms can also be used by reporting nodes to determine that reacti= ng nodes have received overload reports but these SHOULD NOT be used in cro= ss vendor deployments. This is degenerating into weasel wording. Sending the OLR in every answer solves the issue for all cases. I can't ima= gine a case where it does harm. Can someone suggest one? Do people really t= hink that making an _overloaded_ reporting node jump through hoops with me= thods (whether proprietary or standardized) to determine which reacting nod= es have received the reports would every be a reasonable implementation? Sending in every answer is cheap and easy. We should just do it. The text to make the reacting node handle getting an answer with no OLR was= there to handle weird corner cases. For example, e.g. two physical hosts w= ith same diameter identity. (Yes, those exist.) >=20 > ----- >=20 > Regards, >=20 > Steve >=20 >=20 >=20 > On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote: >> Steve, >>=20 >> I don't agree that "we need to provide the solution for the reporting no= de to know if the report reached the reacting node or not". >> The point being, it is the responsibility of the reporting node to ensur= e that the report reaches the reacting node else the overload solution will= not help. But this does not justify MUST requirement since this means any = alternate solution is not allowed. >>=20 >> Many networks may have very simple topology of one PCRF connected to one= PGW. Why should we enforce the PCRF/PGW to include "same" OLR in every ans= wer message, in that case? >>=20 >> Regards, >> Nirav. >>=20 >> -----Original Message----- >> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Tuesday, September 09, 2014 8:40 PM >> To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 >> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org;=20 >> maria.cruz.bartolome@ericsson.com >> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node=20 >> Behaviour when OC-OLR is not received >>=20 >> All, >>=20 >> I agree with JJ that we have had this discussion and, I believe, we reac= hed the conclusion that the OLR MUST be in all answer messages. >>=20 >> This seems a much more resilient and interoperable solution. Anyone can= implement a proprietary solution that doesn't address all of the MUST requ= irements, but that will not work with other implementations. If we want to= take away the MUST then we need to expand the solution to include a way fo= r the reporting node to know for sure that the reacting node received the O= LR. >>=20 >> Regards, >>=20 >> Steve >>=20 >> On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: >>> Hi JJ, >>>=20 >>> I share your view and it is the responsibility of the reporting node to= ensure that the OLR reaches the target node. >>> If the reporting node is not following "a" below then it has to have ot= her means to know the target of the response and also have to keep track if= the active OLR was already sent or not. >>> We don't have to suggest the reporting node to do this but at the same = time we need not forbid this type of implementation. >>>=20 >>> So I am also fine to specify that if the OLR is not received by the rea= cting node then the previously received OLR stands valid. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>> [mailto:jean-jacques.trottin@alcatel-lucent.com] >>> Sent: Monday, September 08, 2014 7:56 PM >>> To: Steve Donovan; dime@ietf.org;=20 >>> draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) >>> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>> Node Behaviour when OC-OLR is not received >>>=20 >>>=20 >>> Dear all >>>=20 >>> I think we are restarting a discussion we had a few months ago. >>> The question is how frequently the OLR (with same seq number, so no cha= nge)is sent? >>> a) current text in the draft is that the reporting node (in overload >>> condition) must include an OC-OLR AVP in all response messages >>> b) it can also be said it is only sent once when a change occurs in=20 >>> the OLR. It is in theory enough >>> c) in the middle , it can be sent in a few / many messages >>>=20 >>> b) is not secure, as the answer conveying the new OLR can be lost.=20 >>> c) is OK for me if when there is a change in the OLR, the reporting=20 >>> node rapidly send a significant amount of answers with the same seq=20 >>> number so to consider with a high probability that the reacting node =20 >>> has well received the new OLR. (Note: With the current draft, apart=20 >>> this way, I do not well see how the reporting node knows that the=20 >>> reacting node has well received the new OLR) >>>=20 >>> I think that it was considered simpler to always send OLR in each ans= wer than to have to take a decision at each answer to send it or not. We al= so had a similar debate about the OC-Supported-Features) to be always prese= nt or not. >>>=20 >>> So a) is OK for me as simple. I accept the idea of some tolerance, with= Mcruz proposal that the absence of the OLR simply means no change. But thi= s tolerance should not drive to a b) behavior. >>>=20 >>> Best regards >>>=20 >>> JJacques >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>> (nsalot) Envoy=E9 : lundi 8 septembre 2014 06:48 =C0 : Steve Donovan;=20 >>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 >>> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not=20 >>> received >>>=20 >>> Steve, >>>=20 >>>> I think it is better to specify the behavior of the reporting node to = always include the OLR in every answer message for as long as there is an o= verload condition at the reporting node. >>> I don't think this is necessary. The reporting may include the OLR in e= very answer message but we don't have to put that as mandatory requirement,= e.g. if the reporting node knows (and keeps track of) if the target reacti= ng node has already received currently active OLR. >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>> Sent: Friday, September 05, 2014 8:01 PM >>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com >>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>> Node Behaviour when OC-OLR is not received >>>=20 >>> Maria Cruz, >>>=20 >>> I'm not sure I agree with this proposed change. >>>=20 >>> The wording to indicate that absence of an overload report was to handl= e unusual situations. Your proposed wording implies that it is acceptable = for a reporting node to not include the OLR in every answer message. >>>=20 >>> I think it is better to specify the behavior of the reporting node to a= lways include the OLR in every answer message for as long as there is an ov= erload condition at the reporting node. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 9/5/14, 3:03 AM, dime issue tracker wrote: >>>> #72: Reporting Node Behaviour when OC-OLR is not received >>>>=20 >>>> A clarification is required to consider that an answer message may = not >>>> include OC-OLR and still the reporting node be overloaded, since i= t is >>>> considered as "no change", as documented in 4.2.1.3: >>>>=20 >>>> Reacting nodes do not delete an OCS when receiving an answer me= ssage >>>> that does not contain an OC-OLR AVP (i.e. absence of OLR means = "no >>>> change"). >>>>=20 >>>>=20 >>>> Original text: >>>>=20 >>>> 5.3. Reporting Node Behavior (Normative) >>>>=20 >>>> The method a reporting nodes uses to determine the amount of tra= ffic >>>> reduction required to address an overload condition is an >>>> implementation decision. >>>>=20 >>>> When a reporting node that has selected the loss abatement algor= ithm >>>> determines the need to request a traffic reduction it must inclu= de an >>>> OC-OLR AVP in all response messages. >>>>=20 >>>>=20 >>>> Proposed addition: >>>>=20 >>>>=20 >>>> 5.3. Reporting Node Behavior (Normative) >>>>=20 >>>> The method a reporting nodes uses to determine the amount of tra= ffic >>>> reduction required to address an overload condition is an >>>> implementation decision. >>>>=20 >>>> When a reporting node that has selected the loss abatement algor= ithm >>>> determines the need to request a traffic reduction it must inclu= de an >>>> OC-OLR AVP in all response messages. OC-OLR AVP is not included = when >>>> reporting node expectations on traffic reduction are not modified. = That >>>> is, if OC-OLR AVP is not included it is interpreted as "no change". >>>>=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 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 10 00:18:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A691A0654 for ; Wed, 10 Sep 2014 00:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfDImxdmPm7y for ; Wed, 10 Sep 2014 00:18:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F021A0650 for ; Wed, 10 Sep 2014 00:18:50 -0700 (PDT) Received: from localhost ([::1]:51272 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XRcAt-0006TV-8V; Wed, 10 Sep 2014 00:18:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: draft-ietf-dime-ovli@tools.ietf.org, jean-jacques.trottin@alcatel-lucent.com X-Trac-Project: dime Date: Wed, 10 Sep 2014 07:18:43 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/dime/trac/ticket/73 Message-ID: <081.1b4a897dcd07e50c4d2a8df5bb419ded@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jean-jacques.trottin@alcatel-lucent.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EvUlmQ05jUp8c1FmtbX-5REFCYc Cc: dime@ietf.org Subject: [Dime] [dime] #73 (draft-ietf-dime-ovli): Clarifications On Mbit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 07:18:53 -0000 #73: Clarifications On Mbit Mbit is mentioned in different places in the 03 draft (sections 4.3, 6 and 6.8). It is proposed clarifications to ensure a good consistency between the different sections. 1) In 4.3, existing text: More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED Proposed text with an affirmation instead of a negation and the use of SHOULD: More specifically, the sub-AVPs inside the OC-Supported-Features and OC-OLR AVP MAY have the M-bit set. However, when overload control AVPs are piggybacked on top of an existing applications, the M-bit in sub-AVPs SHOULD be cleared. 2) in section 6, existing text: When added to existing commands, both OC-Feature-Vector and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. It is proposed to replace OC-Feature-Vector by OC-Supported-Features (Mbit for OC-Feature AVP case is already covered by the statement about Sub-AVPs in 4.3). “Existing commands†is a bit ambiguous as an existing command may be used in a new application, it is proposed “commands of existing applications†Proposed text: When added to commands of existing applications, both OC-Supported- Features and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid backward compatibility issues. 3) In 6.8, existing text: Otherwise, when reused in newly defined Diameter applications, the DOC related AVPs SHOULD have the M-bit set. This text indicates that for a new application, there is a high recommendation to use DOIC, as we have a SHOULD. The specification of a new application may only define an optional use of DOIC. In this case should the Mbit be set for DOIC AVPs? In the following use case, the reacting node advertise DOIC support for a new application in a request and set the MBit in the OC-Supported-Features AVP; the reporting node does not support DOIC for this new application. The reporting node must not reject the request because containing an AVP which is not supported, it should simply ignore it and DOIC will not be used between these two nodes. Is additional text needed to avoid rejecting requests? -- -------------------------------------+------------------------------------- Reporter: jean-jacques.trottin | Owner: draft-ietf-dime- @alcatel-lucent.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Sep 10 06:59:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08491A00BB for ; Wed, 10 Sep 2014 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYo5z20Su8Fc for ; Wed, 10 Sep 2014 06:59:24 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D4321A00B8 for ; Wed, 10 Sep 2014 06:59:23 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-99-541059380b12 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 36.7B.24955.83950145; Wed, 10 Sep 2014 15:59:21 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 15:59:20 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAAA0igIAAJvQAgAHB0TA= Date: Wed, 10 Sep 2014 13:59:19 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920981208A@ESESSMB101.ericsson.se> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2CF@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A2CF@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvja5lpECIwdSb7BZze1ewWSw/3sBs sen8OhaLdW9XMDmweLQ+28vqsWTJTyaPn+uvsnt8ufyZLYAlissmJTUnsyy1SN8ugSvj8xmT gocRFfMWfWNuYFxh3sXIziEhYCIxRaOLkRPIEpO4cG89WxcjF4eQwFFGiZPz5zFCOEsYJZZv WMoKUsUmYCdx6fQLJpCEiEAbk8TTV+eYQRLCAt4ScxbdZwexRQR8JJYvWwDUzQFk+0kceeAJ EmYRUJU4f/0EC4jNK+ArcaZ5JhPEgh9MEhd6T4Mt4BQIkNj1YgNYESPQSd9PrWECsZkFxCVu PZnPBHGqgMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHq9SRuTJ3CBmFrSyxb+JoZYrGgxMmZT1gm MIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMJoObvmtuoPx 8hvHQ4wCHIxKPLwLNvCHCLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRpXwdp/CPbc/19otWWIhM/di8DZHbaPPhzUuPfg7JfS+btefpXMOFlt4c0h/3Kfv e17n41kOtxWsE0/M2rZoqq8ec8LffY45+2e6OzfMuXI04SsDo/KR+NWzvZvmZxxZF/9M5ZND yrOos8Gn7/WLxKXadJpJzGn6nt18yPHdNW/7ZPWJ+Y93+imxFGckGmoxFxUnAgDXKQ+dhwIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4KNXLHrKYVlQpCxCpS8q1HTMQSI Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 13:59:26 -0000 Dear JJ,=20 I agree with Ulrich comments below. But this is not related to #70 Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: martes, 09 de septiembre de 2014 13:16 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Jacques, in this scenario where the client supports DOIC my understanding is: If there is a realm overload, the agent will receive only those realm route= d requests that survived a throttling at the client. There is no point for = the agent to throttle again. Anyway this seems not to be related to #70. See also inline. Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com] Sent: Tuesday, September 09, 2014 12:48 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear all Another remark on this type of use cases. There is a realm overload, the DA receives a realm routed request and decid= e to throttle it and generates a Diameter error (congestion or too busy und= er discussion). The request was not sent to any server; which Origin-Host A= VP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 s= tates that "Origin-Host AVP MUST be present in all Diameter messages. This = AVP identifies the endpoint that originated the Diameter message".=20 Another clarification, in our discussions, we speak of OLRs put in successf= ul answers; my understanding is that OLRs may also be present in unsuccess= ful answers (with a Diameter error). Do we agree on this? [Wiehe, Ulrich (NSN - DE/Munich)] I agree. Best regards Jacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: mardi 9 septembre 2014 12:01 =C0=A0: maria.= cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org= ; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: 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 nobody Wed Sep 10 07:02:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7201D1A02DF for ; Wed, 10 Sep 2014 07:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ljsA2BibKox for ; Wed, 10 Sep 2014 07:02:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6284D1A00BB for ; Wed, 10 Sep 2014 07:02:41 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-96-541059ff4865 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.EB.21432.FF950145; Wed, 10 Sep 2014 16:02:39 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 16:02:38 +0200 From: Maria Cruz Bartolome To: Ben Campbell , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPzKArGIptMc1Hek2MmXu5dUbbdpv6ZbSg Date: Wed, 10 Sep 2014 14:02:38 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920981209A@ESESSMB101.ericsson.se> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> 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.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3Rvd/pECIwd2JOhbzO0+zW8ztXcFm sfx4A7PFpvPrWCzWvV3B5MDq0fpsL6vHkiU/mTxm7XzC4vFz/VV2jy+XP7MFsEZx2aSk5mSW pRbp2yVwZbxcu4i5YJlCxYWJLSwNjF8kuxg5OSQETCR2fV/KAmGLSVy4t56ti5GLQ0jgKKPE jC3f2SGcJYwS6yfuZAOpYhOwk7h0+gUTiC0iECfx8PA7JpAiZoFTjBI7Nh5kB0kIC3hLzFl0 nx2iyEdi+bIFjBC2kUTL4hVg61gEVCXe908Es3kFfCVaP31hgdh2i0ni0pkpQNs4ODgF7CX+ vQ8BqWEEOu/7qTVgi5kFxCVuPZnPBHG2gMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHq9SRuTJ3C BmFrSyxb+JoZYq+gxMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk33chIL7UoM7m4 OD9PLy+1ZBMjMP4ObvltsIPx5XPHQ4wCHIxKPLwLNvCHCLEmlhVX5h5ilOZgURLnXXhuXrCQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtnLP91aG/VV/+Ifz6OfHwUfa91zUarula6y9srI p73zd4feXF+i67pjzvxXEokXp/gY2n+UuaD78UW0u9beQLPUfbtmNq4SbPVZGnfO4elhv/dr 7I7XftrCH3FX30I1/mzgtJPpO/k+XY+Odu9u2XIu68DPQB05d5mXei6KK9l3lq9+4/3Y2kqJ pTgj0VCLuag4EQBVsFGboAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hYRwgN1PG2PCsCWEKB6ECKo4ls8 Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 14:02:43 -0000 Hello, In my opinion, the main reason to answer realm-routed requests with only Re= alm OLR is because specific host(s) OLR may never be used by this reacting = node, since this client may never send a request routed to these hosts If ever the reacting node sends a request to any host, it will receive back= corresponding host OLR, and from then on it could apply corresponding abat= ement. Regards /MCruz -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: mi=E9rcoles, 10 de septiembre de 2014 4:38 To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example We had exactly that example in the draft discussed in Toronto ( draft-donov= an-doic-agent-cases ). Comments inline: On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Dear JJacques, >=20 > assume the following example: > In step 1 (realm routed request sent from Client to Agent), the client in= dicates that it supports loss. > In step 2 (host routed request send from agent to S1), the agent indicate= s that it supports loss and rate. > In step 3 (answer from S1 to agent, containing a host type OLR), S1 indic= ates that it selected rate. >=20 > Now in step 4 there is no point in forwarding the host-type OLR from agen= t to client as the client does not support rate. Similar for step 8 where n= o host type OLR of rate shall be sent in addition to the realm-type OLR of = loss. I agree there is no point forwarding the OLR per se. However, the agent may= still indicate that it supports "loss" back to the client, and send loss-b= ased reports if the client sends too much traffic for the agent to comply w= ith the max rate without throttling. >=20 > Also note that the answer in step 8 can contain only one Supported-Featur= es AVP i.e. can only contain one selected algorithm. Even when the agent su= pports loss and realm, you cannot say in one answer "use loss for realm rou= ted requests and rate for host routed requests" One approach is where you end up with is "loss" is supported between the cl= ient and agent, and "rate" is supported between the agent and server. Don't get me wrong, I'm not saying that's a _required_ approach, but it sho= uld be allowed. >=20 > Furthermore the client may never send host routed requests to S1. (And if= it does, it will learn the host type OLR and selected algorithm in the cor= responding answer). >=20 I don't follow this. Do you mean "might never"? (I read "may never" as "is = never allowed to"). The agent has to ensure that any OLRs that get back to the client match the= capabilities the client advertised, and received. It could do that by stri= pping all OC-S-F and OLR avps in answers, or it could act as as an algorith= m "gateway" and (statefully) translate between the capabilities selected on= either side.=20 > I'm aware that there may be cases where agent and server select the same = algorithm and the problem described above disappears, but even then we shou= ld not mandate including the host-type OLR in the answer that corresponds t= o a realm type request. I don't see that following. We should prevent a server from putting any hos= t reports into answers to realm routed requests. Otherwise, you have use ca= ses that just want work. For example, consider how a server could report an= y overload at all for an application that is exclusively realm-routed. Also, consider that with the recently discussed distinction between realm-r= outed requests and host-routed requests, we consider a request to be host-r= outed if it has a Destination-Host _or_ if a node has other knowledge that = the request will go to specific server (e.g., if the peer-selection decisio= n would send a request to the specific host. ) In the second case, the serv= er itself cannot distinguish a host-routed request from a host-routed reque= st. =20 From nobody Wed Sep 10 07:09:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFF21A02D7 for ; Wed, 10 Sep 2014 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuyvKHiVHS-j for ; Wed, 10 Sep 2014 07:09:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4F51A00B8 for ; Wed, 10 Sep 2014 07:09:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8AE9Y46006103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Sep 2014 14:09:35 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8AE9Yfp029019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 16:09:34 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 10 Sep 2014 16:09:34 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 16:09:34 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4A= Date: Wed, 10 Sep 2014 14:09:33 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5225 X-purgate-ID: 151667::1410358176-00005326-630D5167/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/04jEAUVCNKD2W5g2WNYepT0n-Lo Cc: "draft-ietf-dime-ovli@tools.ietf.org" , "dime@ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 14:09:50 -0000 Ben, please see comments inline. Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, September 10, 2014 4:38 AM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@ericsson= .com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example We had exactly that example in the draft discussed in Toronto ( draft-donov= an-doic-agent-cases ). Comments inline: On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Dear JJacques, >=20 > assume the following example: > In step 1 (realm routed request sent from Client to Agent), the client in= dicates that it supports loss. > In step 2 (host routed request send from agent to S1), the agent indicate= s that it supports loss and rate. > In step 3 (answer from S1 to agent, containing a host type OLR), S1 indic= ates that it selected rate. >=20 > Now in step 4 there is no point in forwarding the host-type OLR from agen= t to client as the client does not support rate. Similar for step 8 where n= o host type OLR of rate shall be sent in addition to the realm-type OLR of = loss. I agree there is no point forwarding the OLR per se. However, the agent may= still indicate that it supports "loss" back to the client, and send loss-b= ased reports if the client sends too much traffic for the agent to comply w= ith the max rate without throttling. I think the agent shall indicate that it supports "loss" back to t= he client. In addition, are you proposing that the agent may translate the = rate based host-type OLR received from S1 into a loss based host type OLR a= nd forward it to the client? >=20 > Also note that the answer in step 8 can contain only one Supported-Featur= es AVP i.e. can only contain one selected algorithm. Even when the agent su= pports loss and realm, you cannot say in one answer "use loss for realm rou= ted requests and rate for host routed requests" One approach is where you end up with is "loss" is supported between the cl= ient and agent, and "rate" is supported between the agent and server. Don't get me wrong, I'm not saying that's a _required_ approach, but it sho= uld be allowed. I'm ok with "loss" for realm type OLRs sent from agent to client a= nd "rate" for host type OLRs sent from Server to agent in this scenario (st= eps 8 and 7).=20 However, if we allow an agent to translate a received host type OLR of "rat= e" into a sent host type OLR of "loss" we may end up in situations where th= e client receices out of sync OLRs from different agents on different paths= between client and server. >=20 > Furthermore the client may never send host routed requests to S1. (And if= it does, it will learn the host type OLR and selected algorithm in the cor= responding answer). >=20 I don't follow this. Do you mean "might never"? (I read "may never" as "is = never allowed to"). yes sorry I meant "might never" The agent has to ensure that any OLRs that get back to the client match the= capabilities the client advertised, and received. It could do that by stri= pping all OC-S-F and OLR avps in answers I agree , or it could act as as an algorithm "gateway" and (statefully) translate b= etween the capabilities selected on either side.=20 this sounds complex to me and is absolutely unnecessary > I'm aware that there may be cases where agent and server select the same = algorithm and the problem described above disappears, but even then we shou= ld not mandate including the host-type OLR in the answer that corresponds t= o a realm type request. I don't see that following.=20 I did not say "shall forbid" but "should not mandate" We should prevent a server from putting any host reports into answers to re= alm routed requests. Otherwise, you have use cases that just want work. how can a server receive a realm routed request? I can understand t= hat a server may receive a request that does not contain a Destination-Host= AVP, but that's not the definition of realm-routed request For example, consider how a server could report any overload at all for an= application that is exclusively realm-routed. Also, consider that with the recently discussed distinction between realm-r= outed requests and host-routed requests, we consider a request to be host-r= outed if it has a Destination-Host _or_ if a node has other knowledge that = the request will go to specific server (e.g., if the peer-selection decisio= n would send a request to the specific host. ) In the second case, the serv= er itself cannot distinguish a host-routed request from a host-routed reque= st. I don't follow this. Do you mean "from a realm-routed request"? My= interpretation of the definition is that a server will never receive a rea= lm-routed request as the previous direct peer always has the knowledge that= the request will go to that server. =20 From nobody Wed Sep 10 07:16:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9A1A0277 for ; Wed, 10 Sep 2014 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZVymxOwFPQL for ; Wed, 10 Sep 2014 07:16:11 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCE71A00D1 for ; Wed, 10 Sep 2014 07:15:50 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-66-54105d1461ef Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A3.90.21334.41D50145; Wed, 10 Sep 2014 16:15:48 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 16:15:47 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time Thread-Index: AQHPyNkuZbpwAkWLB0yx5uVxu0iwDZvyD7KAgAAiZMCAAD3KgIAAEYgAgAAEFYCAAASVgIAH5xMQ Date: Wed, 10 Sep 2014 14:15:47 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92098120C5@ESESSMB101.ericsson.se> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja5IrECIwbttahZze1ewWWxo4rFY 93YFkwOzx5IlP5k8fq6/yu6x6m0fawBzFJdNSmpOZllqkb5dAldGT8dMpoI3NhW/11xmb2C8 p9/FyMkhIWAi8bXjLROELSZx4d56ti5GLg4hgaOMEgtOtbJAOEsYJSbM28QCUsUmYCdx6fQL JpCEiEA/o8SRqxOAHA4OYYE4iRUnTEBqRATiJWauPcAOYUdJPF63E6yXRUBV4uzBn2wgNq+A r8TEl3uZoRYwS3S9eMMIkuAUCJCYv+U9WDMj0EnfT60BO49ZQFzi1pP5UKcKSCzZc54ZwhaV ePn4HyuErSjR/rSBEaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKW BYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECo+fglt+6OxhXv3Y8xCjAwajEw7tgA3+I EGtiWXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgtBe9evxnmMfP 3Sf2Mm2turpjRd48PtHz2oHZd/Z12y6q2lW8Wmjlx62XbIo+262dk9dnvGjGxJ16jktEeLsF Uviva3475v5j8u1erwkrJm/ljJ9/YpbAu+uTUsw48jZIGOvt93itschOyDExe11YrcS8i/7h Z6O2GThpexzx2Ptp5Q/Rm625hUosxRmJhlrMRcWJAIO4rrF/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Sh4JpgrqTK2EilxpqhVD7CjJE1U Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 14:16:16 -0000 Ulrich, Yes, sending "expiry time" could be a good option, but only as long as time= is synchronized between reporting and reacting nodes. Can we assure that? Regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: viernes, 05 de septiembre de 2014 17:33 To: ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Steve, if - as proposed by MCruz - the validity duration is not stored at the repo= rting node, the reporting node always has to calculate the duration (e.g. 4= min) from current time (e.g. 10:01) and expiration time (e.g. 10:05) and t= he reacting node has to calculate the expiration time from reception time a= nd duration. Would it not be more straight forward to transmit the expiry t= ime rather than the duration? This avoids the need to send different values= depending on sending time. Regards Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Friday, September 05, 2014 5:16 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting No= des - Expiry Time Ulrich, My interpretation is that two OLRs with the same sequence number apply to t= he same overload event at the reporting node. The contents do not need to = be the same, although the only item in a loss report that is likely to chan= ge is the validation time. The important behavior is that the reacting node ignores an overload report= with a sequence number it has already seen. If that behavior is followed = then it doesn't matter if the contents of the report is an exact replay of = a previous report. Regards, Steve On 9/5/14, 10:01 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I would have thought that two OLRs with same sequence number must have sa= me OLR content, especially same duration. > A replay is either an exact replay or its not a replay. > Regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 > Donovan > Sent: Friday, September 05, 2014 3:59 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 > Reporting Nodes - Expiry Time > > Ulrich, > > I think it would be correct for the OLR sent at 10:01 to indicate that=20 > the OLR expires in four minutes. > > A reacting node that has already received the OLR will ignore it=20 > because the sequence number is unchanged. A reacting node that has=20 > not already received the OLR will treat it as a new report and get the=20 > correct expiration time. > > It is certainly possible to implement it so that the OLR sent to a=20 > specific reacting node always gets an exact replay until the report=20 > changes or expires but I don't see that as a requirement. > > Regards, > > Steve > > On 9/5/14, 3:20 AM, Maria Cruz Bartolome wrote: >> Dear Ulrich, >> >> Not sure if I understand your point. >> Is it your intention to send Validity-Duration AVP =3D OCS Validity Dura= tion (in your example 300 s) until timer expires (in your example until 10:= 05)? >> Could you elaborate a bit further please? >> >> Thanks >> /MCruz >> >> -----Original Message----- >> From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] >> Sent: viernes, 05 de septiembre de 2014 10:15 >> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz=20 >> Bartolome >> Subject: RE: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for=20 >> Reporting Nodes - Expiry Time >> >> Dear Maria Cruz, >> >> I do not agree. >> As an example assume that the reporting node creates an overload state a= t 10:00 with a duration of 5 minutes. This means that Validity duration is = 5 minutes and expiry time is 10:05. >> If only expiration time but not validity duration is stored at the repor= ting node, this will result in the following: >> For an answer message that is sent immediately (i.e. at 10:00) validity = duration will be calculated as 5 minutes (which I think is correct). >> For an answer message that is sent at 10:01 validity duration will be ca= lculated as 4 minutes, which I think is not correct. The answer message sen= t at 10:01 should contain a replay of the OLR already sent at 10:00, not an= updated OLR. >> >> Therefore validity duration should not be removed from the OCS. >> >> Best regards >> Ulrich >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue=20 >> tracker >> Sent: Friday, September 05, 2014 9:15 AM >> To: draft-ietf-dime-ovli@tools.ietf.org;=20 >> maria.cruz.bartolome@ericsson.com >> Cc: dime@ietf.org >> Subject: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting=20 >> Nodes - Expiry Time >> >> #67: OCS for Reporting Nodes - Expiry Time >> >> What does "Validity Duration" mean as the information stored in OCS f= or Reporting Nodes? >> >> We need to store some information that allow the reporting node to c= alculate a Validity-Duration value to be included in each OC-OLR AVP Then,= I presume we need just Expiry Time, and then value to be included in each= Validation-Duration AVP is calculated based on this. >> >> Then, original text: >> >> 4.2.1.2. Overload Control States for Reporting Nodes >> >> A reporting node maintains per supported Diameter application and = per >> supported (and eventually selected) Abatement Algorithm an Overloa= d >> Control State. >> >> An Overload Control State may be identified by the pair of >> Application-Id and supported Abatement Algorithm. >> >> The Overload Control State for a given pair of Application and >> Abatement Algorithm could include the information: >> >> o Sequence number >> >> o Validity Duration and Expiry Time >> >> o Algorithm specific input data (e.g. Reduction Percentage for >> Loss) >> >> Overload Control States for reporting nodes containing a validity >> duration of 0 sec. should not expire before any previously sent >> (stale) OLR has timed out at any reacting node. >> >> Editor's note: This statement is unclear and contradictory with ot= her >> statements. A validity timer of zero seconds indicates that the >> overload condition has ended and abatement is no longer requested. >> >> >> Proposed modification: >> >> 4.2.1.2. Overload Control States for Reporting Nodes >> >> A reporting node maintains per supported Diameter application and = per >> supported (and eventually selected) Abatement Algorithm an Overloa= d >> Control State. >> >> An Overload Control State may be identified by the pair of >> Application-Id and supported Abatement Algorithm. >> >> The Overload Control State for a given pair of Application and >> Abatement Algorithm could include the information: >> >> o Sequence number >> >> o Expiry Time >> >> o Algorithm specific input data (e.g. Reduction Percentage for >> Loss) >> >> Expiry Time is used by the reporting node to calculate the value t= o be >> included in each Validity-Duration AVP, as part of the overload re= port. >> > _______________________________________________ > 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 nobody Wed Sep 10 07:17:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD21A00D1 for ; Wed, 10 Sep 2014 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlWN5SOzV_e1 for ; Wed, 10 Sep 2014 07:17:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DBC1A00D5 for ; Wed, 10 Sep 2014 07:17:18 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-d3-54105d6c13fa Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7E.8E.02247.C6D50145; Wed, 10 Sep 2014 16:17:16 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 16:17:16 +0200 From: Maria Cruz Bartolome To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm Thread-Index: AQHPzEDsmdsCAf1kT0ySSdRAcJk5gpv6a0OQ Date: Wed, 10 Sep 2014 14:17:15 +0000 Message-ID: <087A34937E64E74E848732CFF8354B92098120D4@ESESSMB101.ericsson.se> References: <075.8d19bd9550e16275f187acd9d2a6195d@trac.tools.ietf.org> <5409CBEE.9070607@usdonovans.com> <540F1999.6020804@usdonovans.com> In-Reply-To: <540F1999.6020804@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+JvjW5OrECIwctlJhbzO0+zW8ztXcFm saGJx4HZY8mSn0wes3Y+YfFY9baPNYA5issmJTUnsyy1SN8ugStj9/x3jAW9BhUvpx9jb2Cc odrFyMEhIWAi0bOhoouRE8gUk7hwbz1bFyMXh5DAUUaJvgPPmCCcJYwSHyYtZwKpYhOwk7h0 +gWYLSLgI/H67B92EJtZQFli9o4HYLawQJzEw4XnWSFq4iX2rHrACrJMRMBIou0hWCuLgKpE 36+fYCW8Ar4SrTO6GSF2HWaUWHWnlQUkwSmgJ3F0+xuwmYxA130/tYYJYpe4xK0n85kgrhaQ WLLnPDOELSrx8vE/VghbUaL9aQMjRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C 0jILScssJC0LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG1MEtv612MB587niIUYCD UYmHd8EG/hAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBo OKVip8WmC7aChvEuVTe2H54t+ap9+tNbMf7aypL8V53OPy/XjKxKXzaXc07bcdHU4m0FfFNN fJ4xqCZa7zgqZP7jUV2aadfsSzttvi2Js553tXLFrFeSPJMdra+/UudRYXw3w0P38vJikyfN zm5tvfPKLzL1KQW2W0qYCx/edDpVellpZLwSS3FGoqEWc1FxIgBoBsIBiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PZJoVeUfz6DLu3dkjJ-_gNSYf3Q Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common abatemen algorithm X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 14:17:22 -0000 Ben, Steve, Proposed rewording is fine to me. /MCruz -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: martes, 09 de septiembre de 2014 17:16 To: Ben Campbell Cc: dime@ietf.org; Maria Cruz Bartolome Subject: Re: [Dime] [dime] #68 (draft-ietf-dime-ovli): Loss as the common a= batemen algorithm Ben, I agree, this wording is better. Steve On 9/8/14, 4:02 PM, Ben Campbell wrote: > Steve, am I correct in assuming the removal of the 2119 "MUST" was intent= ional? (For the record, I agree--in this context it's a statement of fact,= not a normative requirement.) > > If so, I suggest changing it to something other than "must" to avoid conf= usion with MUST. For example, > > " Since the "loss" abatement algorithm [crossref] is mandatory to impleme= nt, DOIC can always be enabled between these two endpoints." > > On Sep 5, 2014, at 9:42 AM, Steve Donovan wrot= e: > >> Maria Cruz, >> >> I support the need for these changes. I have a proposal for alternative= wording below. >> >> Regards, >> >> Steve >> >> On 9/5/14, 2:30 AM, dime issue tracker wrote: >>> #68: Loss as the common abatemen algorithm >>> >>> Some text is misleading since it may imply that one feature shall be = in >>> common between reporting and reacting node to progress, but in realit= y we >>> only need to have one common abatement algorithm, and in this draft, = LOSS >>> is defined as default, then there is always one common algorithm >>> >>> Corrections are required in following clauses: >>> >>> Original text: >>> >>> 4.2.3. Reporting Node Behavior (Normative) >>> >>> ... >>> >>> The operation on the reporting node is straight forward. The >>> reporting node learns the capabilities of the reacting node when i= t >>> receives the OC-Supported-Features AVP as part of any Diameter >>> request message. If the reporting node shares at least one common >>> feature with the reacting node, then the DOIC can be enabled betwe= en >>> these two endpoints. See Section 4.1 for further discussion on th= e >>> capability and feature announcement between two endpoints. >>> >>> >>> Proposed modification: >>> >>> 4.2.3. Reporting Node Behavior (Normative) >>> >>> ... >>> >>> The >>> reporting node learns the capabilities of the reacting node when i= t >>> receives the OC-Supported-Features AVP as part of any Diameter >>> request message. Both reacting and reporting node MUST share at l= east >>> one abatement algorithm, in fact, they share at least the loss algori= thm, >>> that is defined in this document as the default abatement algorithm, = then >>> the DOIC can always be enabled between these two endpoints at least w= ith >>> the default algorithm. See Section 4.1 for further discussion on the >>> capability and feature announcement between two endpoints. >> SRD> I propose the following wording: >> >> The reporting node learns the capabilities of the reacting node when it = receives the >> OC-Supported-Featuers AVP as part of any Diameter request message. At a = minimum, >> the reacting node and reporting node must both the loss abatement algori= thm defined in this document >> and, as a result, DOIC can always be enabled between these two endpoints= . See Section >> 4.1 ... >>> >>> >>> Original text: >>> >>> 6.1. OC-Supported-Features AVP >>> >>> ... >>> >>> During the message exchange the overload control endpoints express >>> their common set of supported capabilities. The reacting node >>> includes the OC-Supported-Features AVP that announces what it >>> supports. The reporting node that sends the answer also includes = the >>> OC-Supported-Features AVP that describes the capabilities it >>> supports. The set of capabilities advertised by the reporting nod= e >>> depends on local policies. At least one of the announced >>> capabilities MUST match. If there is no single matching capabilit= y >>> the reacting node MUST act as if it does not implement DOIC and ce= ase >>> inserting any DOIC related AVPs into any Diameter messages with th= is >>> specific reacting node. >>> >>> Editor's note: The last sentence conflicts with the last senten= ce >>> two paragraphs up. In reality, there will always be at least o= ne >>> matching capability as all nodes supporting DOIC must support t= he >>> loss algorithm. Suggest removing the last sentence. >>> >>> >>> Proposed text: >>> >>> 6.1. OC-Supported-Features AVP >>> >>> ... >>> >>> During the message exchange the overload control endpoints express >>> their common set of supported capabilities. The reacting node >>> includes the OC-Supported-Features AVP that announces what it >>> supports. The reporting node that sends the answer also includes = the >>> OC-Supported-Features AVP that describes the capabilities it >>> supports. The set of capabilities advertised by the reporting nod= e >>> depends on local policies. Both reacting and reporting node MUST s= hare >>> at least one abatement algorithm, in fact, they share at least the lo= ss >>> algorithm, that is defined in this document as the default abatement >>> algorithm, then the DOIC can always be enabled between these two endp= oints >>> at least with the default algorithm. See Section 4.1 for further >>> discussion on the capability and feature announcement between two >>> endpoints. >>> >> SRD> I propose the following: >> >> ... Both the reacting and reporting nodes must support the loss abatemen= t algorithm >> defined in this document. As a result, DOIC behavior can always be enab= led between >> the reacting and reporting nodes. See Section 4.1 ... >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Sep 10 09:17:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D191A8945 for ; Wed, 10 Sep 2014 09:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6VkW4dhqgpC for ; Wed, 10 Sep 2014 09:17:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FBC71A893C for ; Wed, 10 Sep 2014 09:17:39 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 3787044D2588A; Wed, 10 Sep 2014 16:17:35 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s8AGHapf023191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 18:17:37 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 10 Sep 2014 18:17:37 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN4B9soJ86/RAkCPYLHsUJaF65v3LPWAgAFYMUCAABzR0P//6bIAgAG/6ICAAEWLcA== Date: Wed, 10 Sep 2014 16:17:36 +0000 Message-ID: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2CF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920981208A@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920981208A@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.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ve-tHqDLqDr9qD2CKAaZ7VQsEnk Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 16:17:43 -0000 Hi MCruz, Ulrich I agree this is not related to #70 as the DA does not do throttling , but = my question still applies for a DOIC DA acting on behalf of clients not sup= porting DOIC. This DA throttles a Realm routed request. What does it send= as Origin Host in the unsuccesfull answer to the client. This question may= be more a RFC 6733 one. I may generate a ticket if this generates discussion. Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Envoy=E9=A0: mercredi 10 septembre 2014 15:59 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUE= S); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Dear JJ,=20 I agree with Ulrich comments below. But this is not related to #70 Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: martes, 09 de septiembre de 2014 13:16 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Jacques, in this scenario where the client supports DOIC my understanding is: If there is a realm overload, the agent will receive only those realm route= d requests that survived a throttling at the client. There is no point for = the agent to throttle again. Anyway this seems not to be related to #70. See also inline. Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com] Sent: Tuesday, September 09, 2014 12:48 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear all Question Another remark on this type of use cases. There is a realm overload, the DA receives a realm routed request and decid= e to throttle it and generates a Diameter error (congestion or too busy und= er discussion). The request was not sent to any server; which Origin-Host A= VP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 s= tates that "Origin-Host AVP MUST be present in all Diameter messages. This = AVP identifies the endpoint that originated the Diameter message".=20 Another clarification, in our discussions, we speak of OLRs put in successf= ul answers; my understanding is that OLRs may also be present in unsuccess= ful answers (with a Diameter error). Do we agree on this? [Wiehe, Ulrich (NSN - DE/Munich)] I agree. Best regards Jacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: mardi 9 septembre 2014 12:01 =C0=A0: maria.= cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org= ; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: 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 nobody Wed Sep 10 09:35:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080C81A8A01 for ; Wed, 10 Sep 2014 09:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOcZxuLoVcuE for ; Wed, 10 Sep 2014 09:35:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051931A87A3 for ; Wed, 10 Sep 2014 09:35:45 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 356DFFA2FAD17; Wed, 10 Sep 2014 16:35:41 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8AGZi5P022875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 18:35:44 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 10 Sep 2014 18:35:44 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Maria Cruz Bartolome , "dime@ietf.org" Thread-Topic: [Dime] Loss algorithm - clarification Thread-Index: Ac/I28jdegizAe2FQli4d+floEc+YgEN3NSA Date: Wed, 10 Sep 2014 16:35:44 +0000 Message-ID: References: <087A34937E64E74E848732CFF8354B920980FEF7@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920980FEF7@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.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iN-EXRS--7ecAdOzK-IFJnEDtDI Subject: Re: [Dime] Loss algorithm - clarification X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 16:35:48 -0000 Hi MCruz The described approach is only an example which is a simple one. If the re= quested traffic reduction is 10%, the random number between 1 and 100 will= have a probability of 10% to have a value under 10, meaning that statistic= ally 10% of the messages will be suppressed.=20 This algorithm is quite simple and e.g. does not take into account the type= of requests.=20 About to have it this non normative part, why not, but may be to clearly sa= y is a simple example. Best regards JJacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolo= me Envoy=E9=A0: vendredi 5 septembre 2014 09:35 =C0=A0: dime@ietf.org Objet=A0: [Dime] Loss algorithm - clarification Dear all, In clause 5.1, I do not understand following paragraph. Could someone clarify? 4. The reacting node determines if abatement should be applied to the request. One approach that could be taken would be to select a random number between 1 and 100. If the random number is less than the indicated reduction percentage then the request is given abatement treatment, otherwise the request is given normal routing treatment. Best regards /MCruz _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 10 13:05:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D931A87AA for ; Wed, 10 Sep 2014 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPzaD1TYNXz8 for ; Wed, 10 Sep 2014 13:05:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65471A01A8 for ; Wed, 10 Sep 2014 13:05:48 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8AK5fGH066031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Sep 2014 15:05:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B92098120C5@ESESSMB101.ericsson.se> Date: Wed, 10 Sep 2014 15:05:41 -0500 X-Mao-Original-Outgoing-Id: 432072341.163199-0ab34a76685e8c9ef3ffb101864dc652 Content-Transfer-Encoding: quoted-printable Message-Id: <62AF4CFD-7D2F-48F1-AD02-9042C051851C@nostrum.com> References: <075.8088ac7cf45248574468df6730350e07@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D900066815209D71@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920980FF36@ESESSMB101.ericsson.se> <5409C1A7.5000805@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209ED5@DEMUMBX014.nsn-intra.net> <5409D3C9.7030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815209F09@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92098120C5@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XFxkoao08nTGVQ4muXmccQDKG-Y Cc: "dime@ietf.org" Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for Reporting Nodes - Expiry Time X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 20:05:50 -0000 The point of sending a validity period was to avoid a need for clock = sync. Nodes may or may not have clock sync for other reasons, but I = don't think we want to introduce that as a requirement for using DOIC. In real life, I don't expect reporting nodes to have any idea how long a = period of overload will last. Rather, the expiration time means "I'll = update you within X seconds. If you don't get anything in that time, = assume the overload is over". The point is to cause automatic clean-up = of soft state, not to offer precise expiration time of the OCS. =46rom that perspective, it's not all that critical that each = responding node knows the "correct" expiration time. I just needs to be = reasonably close. For example, if a reporting node just reved the = sequence number every X minutes as long as it's overload state has not = changed, and changed nothing else, things will work reason. Not every = reporting node will ramp back up at precisely the same time--but that = can actually be a good thing. If the reporting node wants to more precisely control the expiration of = OCS, it should send a new with a new value (likely zero).=20 (For the record, this is the way soft-state is typically handled by a = number of other IETF protocols. For example, SIP. On Sep 10, 2014, at 9:15 AM, Maria Cruz Bartolome = wrote: > Ulrich, >=20 > Yes, sending "expiry time" could be a good option, but only as long as = time is synchronized between reporting and reacting nodes. Can we assure = that? > Regards > /MCruz >=20 >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich = (NSN - DE/Munich) > Sent: viernes, 05 de septiembre de 2014 17:33 > To: ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] [dime] #67 (draft-ietf-dime-ovli): OCS for = Reporting Nodes - Expiry Time >=20 > Steve, >=20 > if - as proposed by MCruz - the validity duration is not stored at the = reporting node, the reporting node always has to calculate the duration = (e.g. 4 min) from current time (e.g. 10:01) and expiration time (e.g. = 10:05) and the reacting node has to calculate the expiration time from = reception time and duration. Would it not be more straight forward to = transmit the expiry time rather than the duration? This avoids the need = to send different values depending on sending time. >=20 > Regards > Ulrich [...]= From nobody Wed Sep 10 13:12:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714CA1A9128 for ; Wed, 10 Sep 2014 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO9Rb49R7oVZ for ; Wed, 10 Sep 2014 13:12:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DF11A8821 for ; Wed, 10 Sep 2014 13:12:17 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8AKCCqH066605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Sep 2014 15:12:13 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <087A34937E64E74E848732CFF8354B920981209A@ESESSMB101.ericsson.se> Date: Wed, 10 Sep 2014 15:12:12 -0500 X-Mao-Original-Outgoing-Id: 432072732.223128-2bdf48fb65468de8c35a206f0bc0bdf0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920981209A@ESESSMB101.ericsson.se> To: Maria Cruz Bartolome X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bghxfAOhuegs21Y0LiYR-Mtifmw Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 20:12:19 -0000 On Sep 10, 2014, at 9:02 AM, Maria Cruz Bartolome = wrote: > Hello, >=20 > In my opinion, the main reason to answer realm-routed requests with = only Realm OLR is because specific host(s) OLR may never be used by this = reacting node, since this client may never send a request routed to = these hosts If the reacting node never sends a request to that host, then it never = cares. No harm done. Bytes on the wire are cheap. > If ever the reacting node sends a request to any host, it will receive = back corresponding host OLR, and from then on it could apply = corresponding abatement. Again-A restriction against the reporting-node sending a host-report in = response to a realm-routed request is incompatible with our current = definition of ream-routing vs host-routing.=20 It also prevents servers from sending any OLRs at all for applications = that are entirely realm-routed, unless the server can generate = authoritative realm-reports. While that may be true sometimes, it will = not be true in the general case. >=20 > Regards > /MCruz >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: mi=E9rcoles, 10 de septiembre de 2014 4:38 > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - = Example >=20 > We had exactly that example in the draft discussed in Toronto ( = draft-donovan-doic-agent-cases ). >=20 > Comments inline: >=20 > On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >=20 >> Dear JJacques, >>=20 >> assume the following example: >> In step 1 (realm routed request sent from Client to Agent), the = client indicates that it supports loss. >> In step 2 (host routed request send from agent to S1), the agent = indicates that it supports loss and rate. >> In step 3 (answer from S1 to agent, containing a host type OLR), S1 = indicates that it selected rate. >>=20 >> Now in step 4 there is no point in forwarding the host-type OLR from = agent to client as the client does not support rate. Similar for step 8 = where no host type OLR of rate shall be sent in addition to the = realm-type OLR of loss. >=20 > I agree there is no point forwarding the OLR per se. However, the = agent may still indicate that it supports "loss" back to the client, and = send loss-based reports if the client sends too much traffic for the = agent to comply with the max rate without throttling. >=20 >>=20 >> Also note that the answer in step 8 can contain only one = Supported-Features AVP i.e. can only contain one selected algorithm. = Even when the agent supports loss and realm, you cannot say in one = answer "use loss for realm routed requests and rate for host routed = requests" >=20 > One approach is where you end up with is "loss" is supported between = the client and agent, and "rate" is supported between the agent and = server. >=20 > Don't get me wrong, I'm not saying that's a _required_ approach, but = it should be allowed. >=20 >>=20 >> Furthermore the client may never send host routed requests to S1. = (And if it does, it will learn the host type OLR and selected algorithm = in the corresponding answer). >>=20 >=20 > I don't follow this. Do you mean "might never"? (I read "may never" as = "is never allowed to"). >=20 > The agent has to ensure that any OLRs that get back to the client = match the capabilities the client advertised, and received. It could do = that by stripping all OC-S-F and OLR avps in answers, or it could act as = as an algorithm "gateway" and (statefully) translate between the = capabilities selected on either side.=20 >=20 >> I'm aware that there may be cases where agent and server select the = same algorithm and the problem described above disappears, but even then = we should not mandate including the host-type OLR in the answer that = corresponds to a realm type request. >=20 > I don't see that following. We should prevent a server from putting = any host reports into answers to realm routed requests. Otherwise, you = have use cases that just want work. For example, consider how a server = could report any overload at all for an application that is exclusively = realm-routed. >=20 > Also, consider that with the recently discussed distinction between = realm-routed requests and host-routed requests, we consider a request to = be host-routed if it has a Destination-Host _or_ if a node has other = knowledge that the request will go to specific server (e.g., if the = peer-selection decision would send a request to the specific host. ) In = the second case, the server itself cannot distinguish a host-routed = request from a host-routed request. >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Sep 10 13:34:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC001A87B1 for ; Wed, 10 Sep 2014 13:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIf2JQyOdJ4I for ; Wed, 10 Sep 2014 13:34:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A342E1A0196 for ; Wed, 10 Sep 2014 13:34:48 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8AKYkZu068483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Sep 2014 15:34:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> Date: Wed, 10 Sep 2014 15:34:46 -0500 X-Mao-Original-Outgoing-Id: 432074086.18876-28c9fb89da1772fa9d4a32d0ddf41d46 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/m3F79ar9NM8y8RDZT6ZENN_kYNc Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 20:34:50 -0000 On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Ben, >=20 > please see comments inline. >=20 > Ulrich >=20 > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Wednesday, September 10, 2014 4:38 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = maria.cruz.bartolome@ericsson.com; dime@ietf.org; = draft-ietf-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - = Example >=20 > We had exactly that example in the draft discussed in Toronto ( = draft-donovan-doic-agent-cases ). >=20 > Comments inline: >=20 > On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: >=20 >> Dear JJacques, >>=20 >> assume the following example: >> In step 1 (realm routed request sent from Client to Agent), the = client indicates that it supports loss. >> In step 2 (host routed request send from agent to S1), the agent = indicates that it supports loss and rate. >> In step 3 (answer from S1 to agent, containing a host type OLR), S1 = indicates that it selected rate. >>=20 >> Now in step 4 there is no point in forwarding the host-type OLR from = agent to client as the client does not support rate. Similar for step 8 = where no host type OLR of rate shall be sent in addition to the = realm-type OLR of loss. >=20 > I agree there is no point forwarding the OLR per se. However, the = agent may still indicate that it supports "loss" back to the client, and = send loss-based reports if the client sends too much traffic for the = agent to comply with the max rate without throttling. > I think the agent shall indicate that it supports "loss" back = to the client. I wouldn't put it as strongly as "shall", but I think there are = circumstances where it makes sense to do so. (see next comment). There = may also be circumstances where it decides to handle OC control locally, = in which case it may chose not to send any OC-O-F at all back to the = client. > In addition, are you proposing that the agent may translate the rate = based host-type OLR received from S1 into a loss based host type OLR and = forward it to the client? Not quite. I would use the term "gateway" rather than "translate".=20 I think it highly unlikely one can translate any given rate-based OLR = into a loss-based OLR in a useful way. But, I do think that the agent = may choose to locally enforce the rate limit, and send lost-based OLRs = back to the client in an attempt to reduce the number of requests that = the agent might have to throttle. For example, if the agent can achieve the rate limit at the current load = offered by the client without throttling, it need send no OLRs to the = client at all. In this case, the client doesn't need to know about the = overload condition. But if the agent has to throttle, it might (maybe = should) delegate the required throttling back to the client as much as = it can. The loss algorithm is sort of clumsy for that purpose, but it = would still be better than nothing. >=20 >>=20 >> Also note that the answer in step 8 can contain only one = Supported-Features AVP i.e. can only contain one selected algorithm. = Even when the agent supports loss and realm, you cannot say in one = answer "use loss for realm routed requests and rate for host routed = requests" >=20 > One approach is where you end up with is "loss" is supported between = the client and agent, and "rate" is supported between the agent and = server. >=20 > Don't get me wrong, I'm not saying that's a _required_ approach, but = it should be allowed. > I'm ok with "loss" for realm type OLRs sent from agent to = client and "rate" for host type OLRs sent from Server to agent in this = scenario (steps 8 and 7).=20 > However, if we allow an agent to translate a received host type OLR of = "rate" into a sent host type OLR of "loss" we may end up in situations = where the client receices out of sync OLRs from different agents on = different paths between client and server. That's a good point. If your load is reasonably balanced across agents, = it might not matter. If it _does_ matter, then something like an = agent-overload report (as in Steve's draft) from the agent to the client = might work better. I think we are going to need a better understanding of the rate = algorithm to really specify how this should work. I just want to make = sure we don't make choices now that prevent us from solving that later. >=20 >>=20 >> Furthermore the client may never send host routed requests to S1. = (And if it does, it will learn the host type OLR and selected algorithm = in the corresponding answer). >>=20 >=20 > I don't follow this. Do you mean "might never"? (I read "may never" as = "is never allowed to"). > yes sorry I meant "might never" >=20 > The agent has to ensure that any OLRs that get back to the client = match the capabilities the client advertised, and received. It could do = that by stripping all OC-S-F and OLR avps in answers > I agree > , or it could act as as an algorithm "gateway" and (statefully) = translate between the capabilities selected on either side.=20 > this sounds complex to me and is absolutely = unnecessary I didn't say it had to, I said it could. I think it's a reasonable = implementation choice that we should not forbid, but probably also = should not require. >=20 >> I'm aware that there may be cases where agent and server select the = same algorithm and the problem described above disappears, but even then = we should not mandate including the host-type OLR in the answer that = corresponds to a realm type request. >=20 > I don't see that following.=20 > I did not say "shall forbid" but "should not mandate" = I think others were arguing for "shall forbid". > We should prevent a server from putting any host reports into answers = to realm routed requests. Otherwise, you have use cases that just want = work. > how can a server receive a realm routed request? I can = understand that a server may receive a request that does not contain a = Destination-Host AVP, but that's not the definition of realm-routed = request That's actually the point I was trying to make. If a node is a pure = server, then by our current definition it never ever receives a = realm-routed request. So a prohibition against having it put = host-reports in responses to realm-routed requests is both = non-constraining and non-sensical. Now, if a previous hop Agent handled server selection, then it's up to = that agent whether to pass through an existing host-report, if the = original request had been realm-routed from _its_ perspective. We = should neither require or forbid that. (And I actually don't think = that's specific to realm-routed requests. It's true for all request and = report types.) But if we allow the agent to pass through a host-report, then the client = must be prepared to receive it. > For example, consider how a server could report any overload at all = for an application that is exclusively realm-routed. >=20 > Also, consider that with the recently discussed distinction between = realm-routed requests and host-routed requests, we consider a request to = be host-routed if it has a Destination-Host _or_ if a node has other = knowledge that the request will go to specific server (e.g., if the = peer-selection decision would send a request to the specific host. ) In = the second case, the server itself cannot distinguish a host-routed = request from a host-routed request. > I don't follow this. Do you mean "from a realm-routed = request"? Yes. > My interpretation of the definition is that a server will never = receive a realm-routed request as the previous direct peer always has = the knowledge that the request will go to that server. Agreed, so by the time the request gets to the server, it's host = routed--even if it may have been previously realm-routed. I think we are = proving the routing type to be at least somewhat hop-by-hop. My main point was that the server has no knowledge that the request = might have been realm-routed prior to the agent's peer selection. From nobody Wed Sep 10 13:45:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2681A9128 for ; Wed, 10 Sep 2014 13:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTkRagupg_Pg for ; Wed, 10 Sep 2014 13:45:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88191A01CA for ; Wed, 10 Sep 2014 13:45:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8AKjHh6069509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Sep 2014 15:45:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Wed, 10 Sep 2014 15:45:17 -0500 X-Mao-Original-Outgoing-Id: 432074717.216733-e552c95af71fb241ce61126fe6f8b86c Content-Transfer-Encoding: quoted-printable Message-Id: <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@nostrum.com> References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ujyqfbnvr5m4ouv9RuWvGIvd01Q Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2014 20:45:24 -0000 On Sep 10, 2014, at 12:18 AM, Nirav Salot (nsalot) = wrote: > Ben, >=20 >> Sending in every answer is cheap and easy. We should just do it. > I woundnt agree on cheap since redundant information is sent in every = answer message. I already mentioned the simple topology of one PGW = connected to one PCRF directly where even DRA is not used. I guess cheap is relative. A few extra bytes on the wire is going to be = cheap compared to almost any workable feedback-based mechanism of = determining that all the reacting nodes actually got the OLR. >=20 >> The text to make the reacting node handle getting an answer with no = OLR was there to handle weird corner cases. For example, e.g. two = physical hosts with same diameter identity. (Yes, those exist.) > Nothing is changing from the reacting node since "absent of OLR should = still mean that the previously received OLR is active". > The idea is just to not "force" reporting node with a particular = behavior. Every time we offer this sort of choice, we add complexity to the = protocol. (This is why you see a lot of IETF-wide pushback on SHOULDs = without guidance on when it might make sense to do something = different.). Some times that complexity is worth it. In this case, I am = convinced it is not. I am especially convinced of this when we find the = need to normatively distinguish between same-vendor and cross-vendor = communication. Does anyone have a concrete example of a different alternative that they = might really use? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Wednesday, September 10, 2014 8:20 AM > To: Steve Donovan > Cc: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; = maria.cruz.bartolome@ericsson.com > Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node = Behaviour when OC-OLR is not received >=20 >=20 > On Sep 9, 2014, at 12:14 PM, Steve Donovan = wrote: >=20 >> Nirav, >>=20 >> My concern is with interoperability. I'm also concerned with agent = based cases where the reporting node doesn't know if it is the client = for the transaction or an agent that is the reacting node. We also need = to address the fact that both the client and an agent will be reacting = nodes for host reports in agent based deployments. >>=20 >> I think we can achieve what you are looking for with the following. = This is just the concept, not the formal wording. >>=20 >> ----- >>=20 >> The reporting node MUST ensure that all reacting nodes for the = transaction receive all new and updated overload reports. This includes = the client for the transaction and agents involved in the transaction = that have a direct connection to the reporting node. >>=20 >> The recommended method to achieve this is to send OLRs in all answer = messages sent while the reporting node has an active overload report. = Out-of-band mechanisms can also be used by reporting nodes to determine = that reacting nodes have received overload reports but these SHOULD NOT = be used in cross vendor deployments. >=20 > This is degenerating into weasel wording. >=20 > Sending the OLR in every answer solves the issue for all cases. I = can't imagine a case where it does harm. Can someone suggest one? Do = people really think that making an _overloaded_ reporting node jump = through hoops with methods (whether proprietary or standardized) to = determine which reacting nodes have received the reports would every be = a reasonable implementation? >=20 > Sending in every answer is cheap and easy. We should just do it. >=20 > The text to make the reacting node handle getting an answer with no = OLR was there to handle weird corner cases. For example, e.g. two = physical hosts with same diameter identity. (Yes, those exist.) >=20 >>=20 >> ----- >>=20 >> Regards, >>=20 >> Steve >>=20 >>=20 >>=20 >> On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote: >>> Steve, >>>=20 >>> I don't agree that "we need to provide the solution for the = reporting node to know if the report reached the reacting node or not". >>> The point being, it is the responsibility of the reporting node to = ensure that the report reaches the reacting node else the overload = solution will not help. But this does not justify MUST requirement since = this means any alternate solution is not allowed. >>>=20 >>> Many networks may have very simple topology of one PCRF connected to = one PGW. Why should we enforce the PCRF/PGW to include "same" OLR in = every answer message, in that case? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Tuesday, September 09, 2014 8:40 PM >>> To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 >>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org;=20 >>> maria.cruz.bartolome@ericsson.com >>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting = Node=20 >>> Behaviour when OC-OLR is not received >>>=20 >>> All, >>>=20 >>> I agree with JJ that we have had this discussion and, I believe, we = reached the conclusion that the OLR MUST be in all answer messages. >>>=20 >>> This seems a much more resilient and interoperable solution. Anyone = can implement a proprietary solution that doesn't address all of the = MUST requirements, but that will not work with other implementations. = If we want to take away the MUST then we need to expand the solution to = include a way for the reporting node to know for sure that the reacting = node received the OLR. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: >>>> Hi JJ, >>>>=20 >>>> I share your view and it is the responsibility of the reporting = node to ensure that the OLR reaches the target node. >>>> If the reporting node is not following "a" below then it has to = have other means to know the target of the response and also have to = keep track if the active OLR was already sent or not. >>>> We don't have to suggest the reporting node to do this but at the = same time we need not forbid this type of implementation. >>>>=20 >>>> So I am also fine to specify that if the OLR is not received by the = reacting node then the previously received OLR stands valid. >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>>> [mailto:jean-jacques.trottin@alcatel-lucent.com] >>>> Sent: Monday, September 08, 2014 7:56 PM >>>> To: Steve Donovan; dime@ietf.org;=20 >>>> draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) >>>> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>>> Node Behaviour when OC-OLR is not received >>>>=20 >>>>=20 >>>> Dear all >>>>=20 >>>> I think we are restarting a discussion we had a few months ago. >>>> The question is how frequently the OLR (with same seq number, so no = change)is sent? >>>> a) current text in the draft is that the reporting node (in = overload >>>> condition) must include an OC-OLR AVP in all response messages >>>> b) it can also be said it is only sent once when a change occurs in=20= >>>> the OLR. It is in theory enough >>>> c) in the middle , it can be sent in a few / many messages >>>>=20 >>>> b) is not secure, as the answer conveying the new OLR can be lost.=20= >>>> c) is OK for me if when there is a change in the OLR, the reporting=20= >>>> node rapidly send a significant amount of answers with the same = seq=20 >>>> number so to consider with a high probability that the reacting = node =20 >>>> has well received the new OLR. (Note: With the current draft, = apart=20 >>>> this way, I do not well see how the reporting node knows that the=20= >>>> reacting node has well received the new OLR) >>>>=20 >>>> I think that it was considered simpler to always send OLR in each = answer than to have to take a decision at each answer to send it or not. = We also had a similar debate about the OC-Supported-Features) to be = always present or not. >>>>=20 >>>> So a) is OK for me as simple. I accept the idea of some tolerance, = with Mcruz proposal that the absence of the OLR simply means no change. = But this tolerance should not drive to a b) behavior. >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>>> (nsalot) Envoy=E9 : lundi 8 septembre 2014 06:48 =C0 : Steve = Donovan;=20 >>>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 >>>> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not=20= >>>> received >>>>=20 >>>> Steve, >>>>=20 >>>>> I think it is better to specify the behavior of the reporting node = to always include the OLR in every answer message for as long as there = is an overload condition at the reporting node. >>>> I don't think this is necessary. The reporting may include the OLR = in every answer message but we don't have to put that as mandatory = requirement, e.g. if the reporting node knows (and keeps track of) if = the target reacting node has already received currently active OLR. >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve = Donovan >>>> Sent: Friday, September 05, 2014 8:01 PM >>>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com >>>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>>> Node Behaviour when OC-OLR is not received >>>>=20 >>>> Maria Cruz, >>>>=20 >>>> I'm not sure I agree with this proposed change. >>>>=20 >>>> The wording to indicate that absence of an overload report was to = handle unusual situations. Your proposed wording implies that it is = acceptable for a reporting node to not include the OLR in every answer = message. >>>>=20 >>>> I think it is better to specify the behavior of the reporting node = to always include the OLR in every answer message for as long as there = is an overload condition at the reporting node. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> On 9/5/14, 3:03 AM, dime issue tracker wrote: >>>>> #72: Reporting Node Behaviour when OC-OLR is not received >>>>>=20 >>>>> A clarification is required to consider that an answer message = may not >>>>> include OC-OLR and still the reporting node be overloaded, = since it is >>>>> considered as "no change", as documented in 4.2.1.3: >>>>>=20 >>>>> Reacting nodes do not delete an OCS when receiving an answer = message >>>>> that does not contain an OC-OLR AVP (i.e. absence of OLR = means "no >>>>> change"). >>>>>=20 >>>>>=20 >>>>> Original text: >>>>>=20 >>>>> 5.3. Reporting Node Behavior (Normative) >>>>>=20 >>>>> The method a reporting nodes uses to determine the amount of = traffic >>>>> reduction required to address an overload condition is an >>>>> implementation decision. >>>>>=20 >>>>> When a reporting node that has selected the loss abatement = algorithm >>>>> determines the need to request a traffic reduction it must = include an >>>>> OC-OLR AVP in all response messages. >>>>>=20 >>>>>=20 >>>>> Proposed addition: >>>>>=20 >>>>>=20 >>>>> 5.3. Reporting Node Behavior (Normative) >>>>>=20 >>>>> The method a reporting nodes uses to determine the amount of = traffic >>>>> reduction required to address an overload condition is an >>>>> implementation decision. >>>>>=20 >>>>> When a reporting node that has selected the loss abatement = algorithm >>>>> determines the need to request a traffic reduction it must = include an >>>>> OC-OLR AVP in all response messages. OC-OLR AVP is not = included when >>>>> reporting node expectations on traffic reduction are not = modified. That >>>>> is, if OC-OLR AVP is not included it is interpreted as "no = change". >>>>>=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 >>=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 nobody Thu Sep 11 00:14:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5CB1A066F for ; Thu, 11 Sep 2014 00:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0MzouMlJ0pI for ; Thu, 11 Sep 2014 00:14:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751D31A0601 for ; Thu, 11 Sep 2014 00:14:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 82C6C81EF7FF2; Thu, 11 Sep 2014 07:14:14 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8B7E5No011216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 09:14:15 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 11 Sep 2014 09:14:14 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Ben Campbell , Maria Cruz Bartolome , "Nirav Salot (nsalot)" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPyN/31LPWG+9t20ShWDRGsSmaRZvyeKuAgAQUNgCAALShMP///y0AgAGMYwCAAAGhAIAAIQqAgACg3QCAAClxgIABAu+AgADPN+A= Date: Thu, 11 Sep 2014 07:14:13 +0000 Message-ID: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@nostrum.com> In-Reply-To: <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@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.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bSQOZk_YvH7tNh5MRw7xEYxT3V0 Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2014 07:14:24 -0000 Dear all=20 I have another questioning. If a reporting node put an OLR in all answers, = does it mean that the reacting node (eg a client) will have an OLR in all a= nswers it receives for given Origin-Realm, Origin-Host AVPS?. In another e= mail thread (#70 Appendix B), for a realm request routed to an overloaded = server which will put a host type OLR in its answer, Ulrich then considers = that the DA receiving this Host OLR will not send it to the client, as the = client will receive this host type OLR in answers to host routed request.=20 =20 There is also the case of realm OLRs: when realm is overloaded, the DA wil= l put realm OLRs in answers to realm routed requests, but is this realm= OLR will be also be put in answers to host routed requests transferred vi= a this DA? The DA may do, (the realm OLR is also valid from the piggybackin= g view) or it may not. =20 For a reacting node (client), I do not think it matters in which answers (= for given Origin realm- Origin host AVPS) it receives corresponding Realm = OLRs and Host OLRs, and if they are not present in some answers, as long as= it receives enough answers containing the OLRs, so to not miss a new OLR = whatever their types. =20 So may be to have an additional sentence in 5.4 Reacting node behavior.=20 Wording proposed=20 - an OCS in the reacting node is not modified when received answers do not = contain an OLR related to this OCS To note that this proposal is valid whatever the outputs of this #72 discus= sion regarding if the reporting node must put an OLR in all answers, which = concerns reporting node behavior (5.3). Best regards=20 JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: mercredi 10 septembre 2014 22:45 =C0=A0: Nirav Salot (nsalot) Cc=A0: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Beha= viour when OC-OLR is not received On Sep 10, 2014, at 12:18 AM, Nirav Salot (nsalot) wrote= : > Ben, >=20 >> Sending in every answer is cheap and easy. We should just do it. > I woundnt agree on cheap since redundant information is sent in every ans= wer message. I already mentioned the simple topology of one PGW connected t= o one PCRF directly where even DRA is not used. I guess cheap is relative. A few extra bytes on the wire is going to be che= ap compared to almost any workable feedback-based mechanism of determining = that all the reacting nodes actually got the OLR. >=20 >> The text to make the reacting node handle getting an answer with no=20 >> OLR was there to handle weird corner cases. For example, e.g. two=20 >> physical hosts with same diameter identity. (Yes, those exist.) > Nothing is changing from the reacting node since "absent of OLR should st= ill mean that the previously received OLR is active". > The idea is just to not "force" reporting node with a particular behavior= . Every time we offer this sort of choice, we add complexity to the protocol.= (This is why you see a lot of IETF-wide pushback on SHOULDs without guidan= ce on when it might make sense to do something different.). Some times tha= t complexity is worth it. In this case, I am convinced it is not. I am espe= cially convinced of this when we find the need to normatively distinguish b= etween same-vendor and cross-vendor communication. Does anyone have a concrete example of a different alternative that they mi= ght really use? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, September 10, 2014 8:20 AM > To: Steve Donovan > Cc: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 > dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org;=20 > maria.cruz.bartolome@ericsson.com > Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node=20 > Behaviour when OC-OLR is not received >=20 >=20 > On Sep 9, 2014, at 12:14 PM, Steve Donovan wro= te: >=20 >> Nirav, >>=20 >> My concern is with interoperability. I'm also concerned with agent base= d cases where the reporting node doesn't know if it is the client for the t= ransaction or an agent that is the reacting node. We also need to address t= he fact that both the client and an agent will be reacting nodes for host r= eports in agent based deployments. >>=20 >> I think we can achieve what you are looking for with the following. This= is just the concept, not the formal wording. >>=20 >> ----- >>=20 >> The reporting node MUST ensure that all reacting nodes for the transacti= on receive all new and updated overload reports. This includes the client = for the transaction and agents involved in the transaction that have a dire= ct connection to the reporting node. >>=20 >> The recommended method to achieve this is to send OLRs in all answer mes= sages sent while the reporting node has an active overload report. Out-of-= band mechanisms can also be used by reporting nodes to determine that react= ing nodes have received overload reports but these SHOULD NOT be used in cr= oss vendor deployments. >=20 > This is degenerating into weasel wording. >=20 > Sending the OLR in every answer solves the issue for all cases. I can't i= magine a case where it does harm. Can someone suggest one? Do people really= think that making an _overloaded_ reporting node jump through hoops with = methods (whether proprietary or standardized) to determine which reacting n= odes have received the reports would every be a reasonable implementation? >=20 > Sending in every answer is cheap and easy. We should just do it. >=20 > The text to make the reacting node handle getting an answer with no=20 > OLR was there to handle weird corner cases. For example, e.g. two=20 > physical hosts with same diameter identity. (Yes, those exist.) >=20 >>=20 >> ----- >>=20 >> Regards, >>=20 >> Steve >>=20 >>=20 >>=20 >> On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote: >>> Steve, >>>=20 >>> I don't agree that "we need to provide the solution for the reporting n= ode to know if the report reached the reacting node or not". >>> The point being, it is the responsibility of the reporting node to ensu= re that the report reaches the reacting node else the overload solution wil= l not help. But this does not justify MUST requirement since this means any= alternate solution is not allowed. >>>=20 >>> Many networks may have very simple topology of one PCRF connected to on= e PGW. Why should we enforce the PCRF/PGW to include "same" OLR in every an= swer message, in that case? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Tuesday, September 09, 2014 8:40 PM >>> To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 >>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>> maria.cruz.bartolome@ericsson.com >>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>> Node Behaviour when OC-OLR is not received >>>=20 >>> All, >>>=20 >>> I agree with JJ that we have had this discussion and, I believe, we rea= ched the conclusion that the OLR MUST be in all answer messages. >>>=20 >>> This seems a much more resilient and interoperable solution. Anyone ca= n implement a proprietary solution that doesn't address all of the MUST req= uirements, but that will not work with other implementations. If we want t= o take away the MUST then we need to expand the solution to include a way f= or the reporting node to know for sure that the reacting node received the = OLR. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: >>>> Hi JJ, >>>>=20 >>>> I share your view and it is the responsibility of the reporting node t= o ensure that the OLR reaches the target node. >>>> If the reporting node is not following "a" below then it has to have o= ther means to know the target of the response and also have to keep track i= f the active OLR was already sent or not. >>>> We don't have to suggest the reporting node to do this but at the same= time we need not forbid this type of implementation. >>>>=20 >>>> So I am also fine to specify that if the OLR is not received by the re= acting node then the previously received OLR stands valid. >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>>> [mailto:jean-jacques.trottin@alcatel-lucent.com] >>>> Sent: Monday, September 08, 2014 7:56 PM >>>> To: Steve Donovan; dime@ietf.org; >>>> draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) >>>> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>>> Node Behaviour when OC-OLR is not received >>>>=20 >>>>=20 >>>> Dear all >>>>=20 >>>> I think we are restarting a discussion we had a few months ago. >>>> The question is how frequently the OLR (with same seq number, so no ch= ange)is sent? >>>> a) current text in the draft is that the reporting node (in=20 >>>> overload >>>> condition) must include an OC-OLR AVP in all response messages >>>> b) it can also be said it is only sent once when a change occurs in=20 >>>> the OLR. It is in theory enough >>>> c) in the middle , it can be sent in a few / many messages >>>>=20 >>>> b) is not secure, as the answer conveying the new OLR can be lost.=20 >>>> c) is OK for me if when there is a change in the OLR, the reporting=20 >>>> node rapidly send a significant amount of answers with the same=20 >>>> seq number so to consider with a high probability that the reacting=20 >>>> node has well received the new OLR. (Note: With the current draft,=20 >>>> apart this way, I do not well see how the reporting node knows that=20 >>>> the reacting node has well received the new OLR) >>>>=20 >>>> I think that it was considered simpler to always send OLR in each an= swer than to have to take a decision at each answer to send it or not. We a= lso had a similar debate about the OC-Supported-Features) to be always pres= ent or not. >>>>=20 >>>> So a) is OK for me as simple. I accept the idea of some tolerance, wit= h Mcruz proposal that the absence of the OLR simply means no change. But th= is tolerance should not drive to a b) behavior. >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>>> (nsalot) Envoy=E9 : lundi 8 septembre 2014 06:48 =C0 : Steve Donovan;= =20 >>>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 >>>> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not=20 >>>> received >>>>=20 >>>> Steve, >>>>=20 >>>>> I think it is better to specify the behavior of the reporting node to= always include the OLR in every answer message for as long as there is an = overload condition at the reporting node. >>>> I don't think this is necessary. The reporting may include the OLR in = every answer message but we don't have to put that as mandatory requirement= , e.g. if the reporting node knows (and keeps track of) if the target react= ing node has already received currently active OLR. >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve=20 >>>> Donovan >>>> Sent: Friday, September 05, 2014 8:01 PM >>>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com >>>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>>> Node Behaviour when OC-OLR is not received >>>>=20 >>>> Maria Cruz, >>>>=20 >>>> I'm not sure I agree with this proposed change. >>>>=20 >>>> The wording to indicate that absence of an overload report was to hand= le unusual situations. Your proposed wording implies that it is acceptable= for a reporting node to not include the OLR in every answer message. >>>>=20 >>>> I think it is better to specify the behavior of the reporting node to = always include the OLR in every answer message for as long as there is an o= verload condition at the reporting node. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> On 9/5/14, 3:03 AM, dime issue tracker wrote: >>>>> #72: Reporting Node Behaviour when OC-OLR is not received >>>>>=20 >>>>> A clarification is required to consider that an answer message may = not >>>>> include OC-OLR and still the reporting node be overloaded, since i= t is >>>>> considered as "no change", as documented in 4.2.1.3: >>>>>=20 >>>>> Reacting nodes do not delete an OCS when receiving an answer me= ssage >>>>> that does not contain an OC-OLR AVP (i.e. absence of OLR means = "no >>>>> change"). >>>>>=20 >>>>>=20 >>>>> Original text: >>>>>=20 >>>>> 5.3. Reporting Node Behavior (Normative) >>>>>=20 >>>>> The method a reporting nodes uses to determine the amount of tra= ffic >>>>> reduction required to address an overload condition is an >>>>> implementation decision. >>>>>=20 >>>>> When a reporting node that has selected the loss abatement algor= ithm >>>>> determines the need to request a traffic reduction it must inclu= de an >>>>> OC-OLR AVP in all response messages. >>>>>=20 >>>>>=20 >>>>> Proposed addition: >>>>>=20 >>>>>=20 >>>>> 5.3. Reporting Node Behavior (Normative) >>>>>=20 >>>>> The method a reporting nodes uses to determine the amount of tra= ffic >>>>> reduction required to address an overload condition is an >>>>> implementation decision. >>>>>=20 >>>>> When a reporting node that has selected the loss abatement algor= ithm >>>>> determines the need to request a traffic reduction it must inclu= de an >>>>> OC-OLR AVP in all response messages. OC-OLR AVP is not included = when >>>>> reporting node expectations on traffic reduction are not modified. = That >>>>> is, if OC-OLR AVP is not included it is interpreted as "no change". >>>>>=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 >>=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 From nobody Thu Sep 11 01:19:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251F41A0673 for ; Thu, 11 Sep 2014 01:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK8v6SWBV-45 for ; Thu, 11 Sep 2014 01:19:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AB81A0669 for ; Thu, 11 Sep 2014 01:19:36 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-b4-54115b164abf Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.DD.21334.61B51145; Thu, 11 Sep 2014 10:19:34 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.185]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 10:19:33 +0200 From: Maria Cruz Bartolome To: Ben Campbell Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPzKArGIptMc1Hek2MmXu5dUbbdpv6ZbSggABGhwCAAOu+sA== Date: Thu, 11 Sep 2014 08:19:32 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920981244E@ESESSMB101.ericsson.se> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920981209A@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: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RlcsWjDE4P8GRYv5nafZLeb2rmCz WH68gdli3dsVTA4sHkuW/GTymLXzCYvHz/VX2T2+XP7MFsASxWWTkpqTWZZapG+XwJVxYtIS xoKluhX7vl5hbWA8o9LFyMkhIWAiseL/VzYIW0ziwr31QDYXh5DAUUaJNfvfMUI4SxglZi04 BFbFJmAncen0CyYQW0RASeJ581YWkCJmgXWMEmc2fwBLCAt4S8xZdJ8doshHYvmyBUCTOIBs J4nV68DCLAKqEssf7ACzeQV8JToPvWKFWHaZWeL7kw+sIAlOAXuJE8taGEFsRqDzvp9aAzaf WUBc4taT+UwQZwtILNlznhnCFpV4+fgfK8guCQFFieX9chDlehI3pk5hg7C1JZYtfM0MsVdQ 4uTMJywTGMVmIZk6C0nLLCQts5C0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGGkH t/zW3cG4+rXjIUYBDkYlHt4EK8EQIdbEsuLK3EOM0hwsSuK8i87NCxYSSE8sSc1OTS1ILYov Ks1JLT7EyMTBKdXA6Bbx7jVXqkKu3kyFh75VW9VnzTqZsM2Mf91sfc8rf7OVpkQJKLkkvPvz aJ8d41eB2afyz32Yqy748ZUw25VCmVbxV0ULhKcFbnTt/HHbiZ8vpPVswn7vq7MFS+Yfzgtg P/8u747Ac8N4S2W2+4VqIol6E2vXPjeZ8/LrngV//01TY+M5+j5+vhJLcUaioRZzUXEiAAf2 c1OVAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rgTJbakdOXXG9zO-Al66TOkASa0 Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2014 08:19:40 -0000 Ben, See below Thanks /MCruz -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: mi=E9rcoles, 10 de septiembre de 2014 22:12 To: Maria Cruz Bartolome Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; draft-ietf-dime-ovli@to= ols.ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example On Sep 10, 2014, at 9:02 AM, Maria Cruz Bartolome wrote: > Hello, >=20 > In my opinion, the main reason to answer realm-routed requests with only = Realm OLR is because specific host(s) OLR may never be used by this reactin= g node, since this client may never send a request routed to these hosts If the reacting node never sends a request to that host, then it never care= s. No harm done. Bytes on the wire are cheap. [MCruz] When received by reacting node, it will need to create correspondin= g OCS, and analyze all traffic against this to determine if any of them is = active. Eventually the client may end up with several of those _never to be used_ O= CS, what is far from being effective, in bandwidth, memory and processing. > If ever the reacting node sends a request to any host, it will receive ba= ck corresponding host OLR, and from then on it could apply corresponding ab= atement. Again-A restriction against the reporting-node sending a host-report in res= ponse to a realm-routed request is incompatible with our current definition= of ream-routing vs host-routing.=20 [MCruz] Why? It also prevents servers from sending any OLRs at all for applications that= are entirely realm-routed, unless the server can generate authoritative re= alm-reports. While that may be true sometimes, it will not be true in the g= eneral case. [MCruz] Why? >=20 > Regards > /MCruz >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: mi=E9rcoles, 10 de septiembre de 2014 4:38 > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@= ietf.org; draft-ietf-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Examp= le >=20 > We had exactly that example in the draft discussed in Toronto ( draft-don= ovan-doic-agent-cases ). >=20 > Comments inline: >=20 > On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >=20 >> Dear JJacques, >>=20 >> assume the following example: >> In step 1 (realm routed request sent from Client to Agent), the client i= ndicates that it supports loss. >> In step 2 (host routed request send from agent to S1), the agent indicat= es that it supports loss and rate. >> In step 3 (answer from S1 to agent, containing a host type OLR), S1 indi= cates that it selected rate. >>=20 >> Now in step 4 there is no point in forwarding the host-type OLR from age= nt to client as the client does not support rate. Similar for step 8 where = no host type OLR of rate shall be sent in addition to the realm-type OLR of= loss. >=20 > I agree there is no point forwarding the OLR per se. However, the agent m= ay still indicate that it supports "loss" back to the client, and send loss= -based reports if the client sends too much traffic for the agent to comply= with the max rate without throttling. >=20 >>=20 >> Also note that the answer in step 8 can contain only one Supported-Featu= res AVP i.e. can only contain one selected algorithm. Even when the agent s= upports loss and realm, you cannot say in one answer "use loss for realm ro= uted requests and rate for host routed requests" >=20 > One approach is where you end up with is "loss" is supported between the = client and agent, and "rate" is supported between the agent and server. >=20 > Don't get me wrong, I'm not saying that's a _required_ approach, but it s= hould be allowed. >=20 >>=20 >> Furthermore the client may never send host routed requests to S1. (And i= f it does, it will learn the host type OLR and selected algorithm in the co= rresponding answer). >>=20 >=20 > I don't follow this. Do you mean "might never"? (I read "may never" as "i= s never allowed to"). >=20 > The agent has to ensure that any OLRs that get back to the client match t= he capabilities the client advertised, and received. It could do that by st= ripping all OC-S-F and OLR avps in answers, or it could act as as an algori= thm "gateway" and (statefully) translate between the capabilities selected = on either side.=20 >=20 >> I'm aware that there may be cases where agent and server select the same= algorithm and the problem described above disappears, but even then we sho= uld not mandate including the host-type OLR in the answer that corresponds = to a realm type request. >=20 > I don't see that following. We should prevent a server from putting any h= ost reports into answers to realm routed requests. Otherwise, you have use = cases that just want work. For example, consider how a server could report = any overload at all for an application that is exclusively realm-routed. >=20 > Also, consider that with the recently discussed distinction between realm= -routed requests and host-routed requests, we consider a request to be host= -routed if it has a Destination-Host _or_ if a node has other knowledge tha= t the request will go to specific server (e.g., if the peer-selection decis= ion would send a request to the specific host. ) In the second case, the se= rver itself cannot distinguish a host-routed request from a host-routed req= uest. >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Sep 11 02:12:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7D1A8912 for ; Thu, 11 Sep 2014 02:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61FxBvQFl8rw for ; Thu, 11 Sep 2014 02:12:29 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7971A8914 for ; Thu, 11 Sep 2014 02:12:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8B9CM4M025120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 09:12:22 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8B9CJnj014098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 11:12:19 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 11 Sep 2014 11:12:19 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 11:12:19 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4CAALBYAIAA2pug Date: Thu, 11 Sep 2014 09:12:18 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10996 X-purgate-ID: 151667::1410426743-00002A30-FC794482/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s5w3ar3HGcB8ZMxEL25OptLdmEY Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2014 09:12:32 -0000 Ben, you worte: My main point was that the server has no knowledge that the request might h= ave been realm-routed prior to the agent's peer selection. I think there in no need for the server to have this knowledge. The server = simply puts its host-type OLR in the answer. The agent that handled server selection receives this OLR and makes use of = it for=20 a) diverting future realm routed request to other servers and=20 b) calculating an aggregated realm overload (taking into account the suppor= ted algorithm at the client).=20 This aggregated realm-type OLR is sent to the client.=20 Open question is whether in addition also the host-type OLR generated by th= e server is sent to the client. Issues identified so far are: 1. Two OLRs in one answer must use the same algorithm resulting in the need= for some kind of OLR conversion from one algorithm to another. 2. Host type OLRs received by the client may easily get out of synch. 3. There is no added value as the client either has no need for the host-ty= pe OLR (i.e. never sends host-type requests to the server) or will receive = it with the response to the next sent host-type request. 4. There may be negative impact for clients that are forced to maintain OCS= s that are never used. Similar to this is another point recently questiond by JJ: Whether an agent may insert a realm-type OLR to an answer which corresponds= to a host-routed request, and which potentially already contains a host-ty= pe OLR. (This would only be possible if the agent supports the algorithm th= at was negotiated/selected between client and server). Again I think that there is no added value as the client either has no need= for the realm-type OLR (i.e. never sends realm-type requests to the realm)= or will receive it with the response to the next sent realm-type request. = And again there may be negative impacts for clients. As a way forward we may think about a way to convey both OLRs in one answer= but clearly indicate which OLR is the "real thing" and which is the additi= onal one. It must however be made clear that the additional one can savely = be ignored by the reacting node. Ulrich =20 =20 -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, September 10, 2014 10:35 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, >=20 > please see comments inline. >=20 > Ulrich >=20 > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Wednesday, September 10, 2014 4:38 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@ericss= on.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Examp= le >=20 > We had exactly that example in the draft discussed in Toronto ( draft-don= ovan-doic-agent-cases ). >=20 > Comments inline: >=20 > On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >=20 >> Dear JJacques, >>=20 >> assume the following example: >> In step 1 (realm routed request sent from Client to Agent), the client i= ndicates that it supports loss. >> In step 2 (host routed request send from agent to S1), the agent indicat= es that it supports loss and rate. >> In step 3 (answer from S1 to agent, containing a host type OLR), S1 indi= cates that it selected rate. >>=20 >> Now in step 4 there is no point in forwarding the host-type OLR from age= nt to client as the client does not support rate. Similar for step 8 where = no host type OLR of rate shall be sent in addition to the realm-type OLR of= loss. >=20 > I agree there is no point forwarding the OLR per se. However, the agent m= ay still indicate that it supports "loss" back to the client, and send loss= -based reports if the client sends too much traffic for the agent to comply= with the max rate without throttling. > I think the agent shall indicate that it supports "loss" back to= the client. I wouldn't put it as strongly as "shall", but I think there are circumstanc= es where it makes sense to do so. (see next comment). There may also be cir= cumstances where it decides to handle OC control locally, in which case it = may chose not to send any OC-O-F at all back to the client. > In addition, are you proposing that the agent may translate the rate base= d host-type OLR received from S1 into a loss based host type OLR and forwar= d it to the client? Not quite. I would use the term "gateway" rather than "translate".=20 I think it highly unlikely one can translate any given rate-based OLR into = a loss-based OLR in a useful way. But, I do think that the agent may choose= to locally enforce the rate limit, and send lost-based OLRs back to the cl= ient in an attempt to reduce the number of requests that the agent might ha= ve to throttle. For example, if the agent can achieve the rate limit at the current load of= fered by the client without throttling, it need send no OLRs to the client = at all. In this case, the client doesn't need to know about the overload co= ndition. But if the agent has to throttle, it might (maybe should) delegate= the required throttling back to the client as much as it can. The loss alg= orithm is sort of clumsy for that purpose, but it would still be better tha= n nothing. >=20 >>=20 >> Also note that the answer in step 8 can contain only one Supported-Featu= res AVP i.e. can only contain one selected algorithm. Even when the agent s= upports loss and realm, you cannot say in one answer "use loss for realm ro= uted requests and rate for host routed requests" >=20 > One approach is where you end up with is "loss" is supported between the = client and agent, and "rate" is supported between the agent and server. >=20 > Don't get me wrong, I'm not saying that's a _required_ approach, but it s= hould be allowed. > I'm ok with "loss" for realm type OLRs sent from agent to client= and "rate" for host type OLRs sent from Server to agent in this scenario (= steps 8 and 7).=20 > However, if we allow an agent to translate a received host type OLR of "r= ate" into a sent host type OLR of "loss" we may end up in situations where = the client receices out of sync OLRs from different agents on different pat= hs between client and server. That's a good point. If your load is reasonably balanced across agents, it = might not matter. If it _does_ matter, then something like an agent-overloa= d report (as in Steve's draft) from the agent to the client might work bett= er. I think we are going to need a better understanding of the rate algorithm t= o really specify how this should work. I just want to make sure we don't ma= ke choices now that prevent us from solving that later. >=20 >>=20 >> Furthermore the client may never send host routed requests to S1. (And i= f it does, it will learn the host type OLR and selected algorithm in the co= rresponding answer). >>=20 >=20 > I don't follow this. Do you mean "might never"? (I read "may never" as "i= s never allowed to"). > yes sorry I meant "might never" >=20 > The agent has to ensure that any OLRs that get back to the client match t= he capabilities the client advertised, and received. It could do that by st= ripping all OC-S-F and OLR avps in answers > I agree > , or it could act as as an algorithm "gateway" and (statefully) translate= between the capabilities selected on either side.=20 > this sounds complex to me and is absolutely unnecessary I didn't say it had to, I said it could. I think it's a reasonable implemen= tation choice that we should not forbid, but probably also should not requi= re. >=20 >> I'm aware that there may be cases where agent and server select the same= algorithm and the problem described above disappears, but even then we sho= uld not mandate including the host-type OLR in the answer that corresponds = to a realm type request. >=20 > I don't see that following.=20 > I did not say "shall forbid" but "should not mandate" I think others were arguing for "shall forbid". > We should prevent a server from putting any host reports into answers to = realm routed requests. Otherwise, you have use cases that just want work. > how can a server receive a realm routed request? I can understand= that a server may receive a request that does not contain a Destination-Ho= st AVP, but that's not the definition of realm-routed request That's actually the point I was trying to make. If a node is a pure server,= then by our current definition it never ever receives a realm-routed reque= st. So a prohibition against having it put host-reports in responses to rea= lm-routed requests is both non-constraining and non-sensical. Now, if a previous hop Agent handled server selection, then it's up to that= agent whether to pass through an existing host-report, if the original req= uest had been realm-routed from _its_ perspective. We should neither requi= re or forbid that. (And I actually don't think that's specific to realm-ro= uted requests. It's true for all request and report types.) But if we allow the agent to pass through a host-report, then the client mu= st be prepared to receive it. > For example, consider how a server could report any overload at all for a= n application that is exclusively realm-routed. >=20 > Also, consider that with the recently discussed distinction between realm= -routed requests and host-routed requests, we consider a request to be host= -routed if it has a Destination-Host _or_ if a node has other knowledge tha= t the request will go to specific server (e.g., if the peer-selection decis= ion would send a request to the specific host. ) In the second case, the se= rver itself cannot distinguish a host-routed request from a host-routed req= uest. > I don't follow this. Do you mean "from a realm-routed request"? Yes. > My interpretation of the definition is that a server will never receive a= realm-routed request as the previous direct peer always has the knowledge = that the request will go to that server. Agreed, so by the time the request gets to the server, it's host routed--ev= en if it may have been previously realm-routed. I think we are proving the = routing type to be at least somewhat hop-by-hop. My main point was that the server has no knowledge that the request might h= ave been realm-routed prior to the agent's peer selection. From nobody Thu Sep 11 02:36:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36761A06AA for ; Thu, 11 Sep 2014 02:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrmNDqwAYpVM for ; Thu, 11 Sep 2014 02:35:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456611A891B for ; Thu, 11 Sep 2014 02:35:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8B9Zr23026171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 09:35:53 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8B9ZrfX023016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 11:35:53 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 11:35:50 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Maria Cruz Bartolome , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3LPWAgAFYMUCAABzR0P//6bIAgAG/6ICAAEWLcIABINFA Date: Thu, 11 Sep 2014 09:35:50 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A68C@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2CF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920981208A@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: [10.159.42.119] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13141 X-purgate-ID: 151667::1410428153-00002A30-2C3B0B66/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gX3D2SRgOsS-1y9fkRpOgdYFHFA Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2014 09:36:00 -0000 Hi Jean-Jacques It is my understanding that the agent that throttles a request on behalf of= a non-DOIC supporting client populates the Origin-Host AVP in the unsucces= sful answer with its own Diameter Identity and the Origin-Realm AVP with th= e realm the agent belongs to.=20 This is independend from the request being host-routed or realm-routed. Any= way, the unsuccessful answer (in this case) shall not contain an OLR as a) the client does not support DOIC and b) it is not the agent that is overloaded Can people please confirm. Best regards Ulrich=20 -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com]=20 Sent: Wednesday, September 10, 2014 6:18 PM To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; d= raft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Hi MCruz, Ulrich I agree this is not related to #70 as the DA does not do throttling , but = my question still applies for a DOIC DA acting on behalf of clients not sup= porting DOIC. This DA throttles a Realm routed request. What does it send= as Origin Host in the unsuccesfull answer to the client. This question may= be more a RFC 6733 one. I may generate a ticket if this generates discussion. Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Envoy=E9=A0: mercredi 10 septembre 2014 15:59 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUE= S); dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Dear JJ,=20 I agree with Ulrich comments below. But this is not related to #70 Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: martes, 09 de septiembre de 2014 13:16 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Jacques, in this scenario where the client supports DOIC my understanding is: If there is a realm overload, the agent will receive only those realm route= d requests that survived a throttling at the client. There is no point for = the agent to throttle again. Anyway this seems not to be related to #70. See also inline. Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com] Sent: Tuesday, September 09, 2014 12:48 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear all Question Another remark on this type of use cases. There is a realm overload, the DA receives a realm routed request and decid= e to throttle it and generates a Diameter error (congestion or too busy und= er discussion). The request was not sent to any server; which Origin-Host A= VP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 s= tates that "Origin-Host AVP MUST be present in all Diameter messages. This = AVP identifies the endpoint that originated the Diameter message".=20 Another clarification, in our discussions, we speak of OLRs put in successf= ul answers; my understanding is that OLRs may also be present in unsuccess= ful answers (with a Diameter error). Do we agree on this? [Wiehe, Ulrich (NSN - DE/Munich)] I agree. Best regards Jacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: mardi 9 septembre 2014 12:01 =C0=A0: maria.= cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org= ; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: 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 nobody Thu Sep 11 06:54:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F721A0023 for ; Thu, 11 Sep 2014 06:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZffIvxRtZCV for ; Thu, 11 Sep 2014 06:54:14 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE161A005E for ; Thu, 11 Sep 2014 06:54:14 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58095 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XS4p5-0006Og-DV for dime@ietf.org; Thu, 11 Sep 2014 06:54:14 -0700 Message-ID: <5411A97F.2020007@usdonovans.com> Date: Thu, 11 Sep 2014 08:54:07 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ggZ9cxBie3n1KKu_lKWVBmUZsA8 Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2014 13:54:18 -0000 All, It seems the concern is forcing the client to save OCS state for host reports from servers to which the client never sends host routed requests. This, I think, is only an issue for requests that do not contain a destination-host AVP. Please correct me if I'm mistaken. I think we all agree that the server has no way to differentiate host routed requests from realm routed requests in this case, so the solution cannot be server based. That leaves two options: 1) The agent that does the server selection strips the host report for these types of transactions. 2) The client ignores host reports for these types of transactions. Option 2 seems better to me, as it is the client that understands whether or not the host reports have value. For some applications the client might never send requests with a destination-host AVP. In this case the client can safely ignore the OLRs. For applications where there is a mix of transaction types (host-routed and realm-routed), the client might choose to save all OLRs in the interest of better handling the overload for the requests that do include the destination-host AVP. Note that in this type of application, it will still work if the client ignores all host reports received on "realm-routed" transactions as the client will still receive a host report on host-routed transactions. This assumes that all answer messages have the OLR for the duration of the overload event. I suggest wording something like: A client MAY ignore OLRs of type host received in transactions where the request was realm-routed by the client. Note: In applications where there is a mix of realm-routed and host-routed requests it is recommended that the client save all host overload reports. Regards, Steve On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, > > you worte: > My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection. > > I think there in no need for the server to have this knowledge. The server simply puts its host-type OLR in the answer. > The agent that handled server selection receives this OLR and makes use of it for > a) diverting future realm routed request to other servers and > b) calculating an aggregated realm overload (taking into account the supported algorithm at the client). > This aggregated realm-type OLR is sent to the client. > Open question is whether in addition also the host-type OLR generated by the server is sent to the client. Issues identified so far are: > 1. Two OLRs in one answer must use the same algorithm resulting in the need for some kind of OLR conversion from one algorithm to another. > 2. Host type OLRs received by the client may easily get out of synch. > 3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-type request. > 4. There may be negative impact for clients that are forced to maintain OCSs that are never used. > > Similar to this is another point recently questiond by JJ: > Whether an agent may insert a realm-type OLR to an answer which corresponds to a host-routed request, and which potentially already contains a host-type OLR. (This would only be possible if the agent supports the algorithm that was negotiated/selected between client and server). > Again I think that there is no added value as the client either has no need for the realm-type OLR (i.e. never sends realm-type requests to the realm) or will receive it with the response to the next sent realm-type request. And again there may be negative impacts for clients. > > As a way forward we may think about a way to convey both OLRs in one answer but clearly indicate which OLR is the "real thing" and which is the additional one. It must however be made clear that the additional one can savely be ignored by the reacting node. > > Ulrich > > > > > > > > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, September 10, 2014 10:35 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example > > > On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > >> Ben, >> >> please see comments inline. >> >> Ulrich >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 4:38 AM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@ericsson.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example >> >> We had exactly that example in the draft discussed in Toronto ( draft-donovan-doic-agent-cases ). >> >> Comments inline: >> >> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Dear JJacques, >>> >>> assume the following example: >>> In step 1 (realm routed request sent from Client to Agent), the client indicates that it supports loss. >>> In step 2 (host routed request send from agent to S1), the agent indicates that it supports loss and rate. >>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicates that it selected rate. >>> >>> Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition to the realm-type OLR of loss. >> I agree there is no point forwarding the OLR per se. However, the agent may still indicate that it supports "loss" back to the client, and send loss-based reports if the client sends too much traffic for the agent to comply with the max rate without throttling. >> I think the agent shall indicate that it supports "loss" back to the client. > I wouldn't put it as strongly as "shall", but I think there are circumstances where it makes sense to do so. (see next comment). There may also be circumstances where it decides to handle OC control locally, in which case it may chose not to send any OC-O-F at all back to the client. > >> In addition, are you proposing that the agent may translate the rate based host-type OLR received from S1 into a loss based host type OLR and forward it to the client? > Not quite. I would use the term "gateway" rather than "translate". > > I think it highly unlikely one can translate any given rate-based OLR into a loss-based OLR in a useful way. But, I do think that the agent may choose to locally enforce the rate limit, and send lost-based OLRs back to the client in an attempt to reduce the number of requests that the agent might have to throttle. > > For example, if the agent can achieve the rate limit at the current load offered by the client without throttling, it need send no OLRs to the client at all. In this case, the client doesn't need to know about the overload condition. But if the agent has to throttle, it might (maybe should) delegate the required throttling back to the client as much as it can. The loss algorithm is sort of clumsy for that purpose, but it would still be better than nothing. > > >>> Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answer "use loss for realm routed requests and rate for host routed requests" >> One approach is where you end up with is "loss" is supported between the client and agent, and "rate" is supported between the agent and server. >> >> Don't get me wrong, I'm not saying that's a _required_ approach, but it should be allowed. >> I'm ok with "loss" for realm type OLRs sent from agent to client and "rate" for host type OLRs sent from Server to agent in this scenario (steps 8 and 7). >> However, if we allow an agent to translate a received host type OLR of "rate" into a sent host type OLR of "loss" we may end up in situations where the client receices out of sync OLRs from different agents on different paths between client and server. > That's a good point. If your load is reasonably balanced across agents, it might not matter. If it _does_ matter, then something like an agent-overload report (as in Steve's draft) from the agent to the client might work better. > > I think we are going to need a better understanding of the rate algorithm to really specify how this should work. I just want to make sure we don't make choices now that prevent us from solving that later. > >>> Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer). >>> >> I don't follow this. Do you mean "might never"? (I read "may never" as "is never allowed to"). >> yes sorry I meant "might never" >> >> The agent has to ensure that any OLRs that get back to the client match the capabilities the client advertised, and received. It could do that by stripping all OC-S-F and OLR avps in answers >> I agree >> , or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side. >> this sounds complex to me and is absolutely unnecessary > I didn't say it had to, I said it could. I think it's a reasonable implementation choice that we should not forbid, but probably also should not require. > >>> I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the answer that corresponds to a realm type request. >> I don't see that following. >> I did not say "shall forbid" but "should not mandate" > I think others were arguing for "shall forbid". > >> We should prevent a server from putting any host reports into answers to realm routed requests. Otherwise, you have use cases that just want work. >> how can a server receive a realm routed request? I can understand that a server may receive a request that does not contain a Destination-Host AVP, but that's not the definition of realm-routed request > That's actually the point I was trying to make. If a node is a pure server, then by our current definition it never ever receives a realm-routed request. So a prohibition against having it put host-reports in responses to realm-routed requests is both non-constraining and non-sensical. > > Now, if a previous hop Agent handled server selection, then it's up to that agent whether to pass through an existing host-report, if the original request had been realm-routed from _its_ perspective. We should neither require or forbid that. (And I actually don't think that's specific to realm-routed requests. It's true for all request and report types.) > > But if we allow the agent to pass through a host-report, then the client must be prepared to receive it. > > >> For example, consider how a server could report any overload at all for an application that is exclusively realm-routed. >> >> Also, consider that with the recently discussed distinction between realm-routed requests and host-routed requests, we consider a request to be host-routed if it has a Destination-Host _or_ if a node has other knowledge that the request will go to specific server (e.g., if the peer-selection decision would send a request to the specific host. ) In the second case, the server itself cannot distinguish a host-routed request from a host-routed request. >> I don't follow this. Do you mean "from a realm-routed request"? > Yes. > >> My interpretation of the definition is that a server will never receive a realm-routed request as the previous direct peer always has the knowledge that the request will go to that server. > Agreed, so by the time the request gets to the server, it's host routed--even if it may have been previously realm-routed. I think we are proving the routing type to be at least somewhat hop-by-hop. > > My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Thu Sep 11 08:45:11 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83B1A00C6 for ; Thu, 11 Sep 2014 08:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHOsDIGvR2IB for ; Thu, 11 Sep 2014 08:45:05 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4501A0410 for ; Thu, 11 Sep 2014 08:45:05 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 49EDC6848C371; Thu, 11 Sep 2014 15:44:59 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8BFiV6C019840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 17:45:00 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 11 Sep 2014 17:44:43 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN4B9soJ86/RAkCPYLHsUJaF65v3LPWAgAFYMUCAAAFRAIABBpyAgADBWoCAAGuhAIAA06cAgABOvYCAAD5+oA== Date: Thu, 11 Sep 2014 15:44:42 +0000 Message-ID: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> In-Reply-To: <5411A97F.2020007@usdonovans.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.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J5vU18yQDmh0RNYhAS1nB89_fXY Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 11 Sep 2014 15:45:09 -0000 Hi all In parallel of Steve, I have written this hereafter mail related to Ulrich= MCruz and Ben comments and is not taking into account last Steve proposal= , but I nevertheless submit it to you as other ways forward proposed. It is true that the server does not distinguish a request that was realm ro= uted by a DA from other client requests having a Destination Host (so-calle= d host routed). I agree with Ulrich that the server has not the need to mak= e this distinction and it simply sends a host type OLR. =20 I also agree that the DA will use this host type OLR to do the a) and b) ac= tions of Ulrich's mail.=20 Then for other points: 1) on one side Ulrich and Mcruz argue there is no added value to add Host OLRs reports in= an answer to realms request (and realm OLRs in answers to Host routed r= equests), given Host OLRs reports will be present in answers to Host routed= (and realm OLRs in answers to realm requests).=20 An additional point is that Host routed request may not go through the DA h= andling realm requets, so in this case there will not be a realm OLR in the= answer. =20 This drive to not mandate the host or realms OLRs to be sent in all answers= (and the client to not expect to receive OLRs in all answers cf my #70 mai= l). I am OK to accept this proposal as in any case the client will receiv= e enough Host OLRs in answers to host routed requests , and enough realm OL= Rs in answers to realm routed requests so to apply the correct abatement. 2) on the other side, current text in draft that Ben and Steve support in= dicates that, when overload, reporting nodes must inserts OLRs in all ans= wers. The argument is that it is a simple way to ensure/guarantee that OLRs= are well taken into account by the reacting node, and that to put a SHOUL= D may be the source of problems as some implementations would not observe = the should, which finally would drive to bad behaviors. As I said in a pr= evious mail, my concern is that the reacting nodes receive enough answers c= ontaining the OLR (with same seq number) to secure the right abatement, and= I also agree the simple described way in the draft achieves this. =20 3 way forwards to try to find a compromise - to continue to put a MUST but with some identified exceptions (with a MAY= ) as in 1) allowing the DA to remove Host OLRs and put realm OLRs only in = answers to realm routed requests. It would not be forbidden to put both OLR= s in answers to realm or Host routed request. But do we limit to these exce= ptions or have we other exceptions to list? - to put a SHOULD for OLRs in all answers but if not observed to write that= the reporting nevertheless MUST ensure that new/updated overload control i= nformation is propagated to the reacting nodes with an acceptable delay (th= is wording is coming from GTP overload control in TS 29.274 where it is not= mandated to put new "GTP OLRs" in all messages sent to the target node doi= ng the abatement). - or to only say that the reporting nevertheless MUST ensure that new/updat= ed overload control information is propagated to the reacting nodes with an= acceptable delay. A possible and simple way to achieve this is to put the = OLR in all answers.=20 Regarding the Ulrich proposal for a way to convey both OLRs in one answer b= ut clearly indicate which OLR is the "real thing" and which is the addition= al one. Here I do not see why to make this distinction, the two OLRs are va= lid ones and possible from the piggybacking rule, the Host type OLR referri= ng to the Origin Host of the answer and the Realm type OLR referring to the= Origin Realm of the answer.=20 Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: jeudi 11 septembre 2014 15:54 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e All, It seems the concern is forcing the client to save OCS state for host repor= ts from servers to which the client never sends host routed requests. This= , I think, is only an issue for requests that do not contain a destination-= host AVP. Please correct me if I'm mistaken. I think we all agree that the server has no way to differentiate host route= d requests from realm routed requests in this case, so the solution cannot = be server based. That leaves two options: 1) The agent that does the server selection strips the host report for thes= e types of transactions. 2) The client ignores host reports for these types of transactions. Option 2 seems better to me, as it is the client that understands whether o= r not the host reports have value. For some applications the client might = never send requests with a destination-host AVP. In this case the client ca= n safely ignore the OLRs. For applications where there is a mix of transac= tion types (host-routed and realm-routed), the client might choose to save = all OLRs in the interest of better handling the overload for the requests t= hat do include the destination-host AVP. Note that in this type of application, it will still work if the client ign= ores all host reports received on "realm-routed" transactions as the client= will still receive a host report on host-routed transactions. =20 This assumes that all answer messages have the OLR for the duration of the = overload event. I suggest wording something like: A client MAY ignore OLRs of type host received in transactions where the re= quest was realm-routed by the client. Note: In applications where there is a mix of realm-routed and host-rou= ted requests it is recommended that the client save all host overload repor= ts. Regards, Steve On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, > > you worte: > My main point was that the server has no knowledge that the request might= have been realm-routed prior to the agent's peer selection. > > I think there in no need for the server to have this knowledge. The serve= r simply puts its host-type OLR in the answer. > The agent that handled server selection receives this OLR and makes=20 > use of it for > a) diverting future realm routed request to other servers and > b) calculating an aggregated realm overload (taking into account the supp= orted algorithm at the client). > This aggregated realm-type OLR is sent to the client. > Open question is whether in addition also the host-type OLR generated by = the server is sent to the client. Issues identified so far are: > 1. Two OLRs in one answer must use the same algorithm resulting in the ne= ed for some kind of OLR conversion from one algorithm to another. > 2. Host type OLRs received by the client may easily get out of synch. > 3. There is no added value as the client either has no need for the host-= type OLR (i.e. never sends host-type requests to the server) or will receiv= e it with the response to the next sent host-type request. > 4. There may be negative impact for clients that are forced to maintain O= CSs that are never used. > > Similar to this is another point recently questiond by JJ: > Whether an agent may insert a realm-type OLR to an answer which correspon= ds to a host-routed request, and which potentially already contains a host-= type OLR. (This would only be possible if the agent supports the algorithm = that was negotiated/selected between client and server). > Again I think that there is no added value as the client either has no ne= ed for the realm-type OLR (i.e. never sends realm-type requests to the real= m) or will receive it with the response to the next sent realm-type request= . And again there may be negative impacts for clients. > > As a way forward we may think about a way to convey both OLRs in one answ= er but clearly indicate which OLR is the "real thing" and which is the addi= tional one. It must however be made clear that the additional one can savel= y be ignored by the reacting node. > > Ulrich > > > > =20 > =20 > > > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, September 10, 2014 10:35 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B -=20 > Example > > > On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > >> Ben, >> >> please see comments inline. >> >> Ulrich >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 4:38 AM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 >> maria.cruz.bartolome@ericsson.com; dime@ietf.org;=20 >> draft-ietf-dime-ovli@tools.ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B -=20 >> Example >> >> We had exactly that example in the draft discussed in Toronto ( draft-do= novan-doic-agent-cases ). >> >> Comments inline: >> >> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Dear JJacques, >>> >>> assume the following example: >>> In step 1 (realm routed request sent from Client to Agent), the client = indicates that it supports loss. >>> In step 2 (host routed request send from agent to S1), the agent indica= tes that it supports loss and rate. >>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 ind= icates that it selected rate. >>> >>> Now in step 4 there is no point in forwarding the host-type OLR from ag= ent to client as the client does not support rate. Similar for step 8 where= no host type OLR of rate shall be sent in addition to the realm-type OLR o= f loss. >> I agree there is no point forwarding the OLR per se. However, the agent = may still indicate that it supports "loss" back to the client, and send los= s-based reports if the client sends too much traffic for the agent to compl= y with the max rate without throttling. >> I think the agent shall indicate that it supports "loss" back t= o the client. > I wouldn't put it as strongly as "shall", but I think there are circumsta= nces where it makes sense to do so. (see next comment). There may also be c= ircumstances where it decides to handle OC control locally, in which case i= t may chose not to send any OC-O-F at all back to the client. > >> In addition, are you proposing that the agent may translate the rate=20 >> based host-type OLR received from S1 into a loss based host type OLR=20 >> and forward it to the client? > Not quite. I would use the term "gateway" rather than "translate". > > I think it highly unlikely one can translate any given rate-based OLR int= o a loss-based OLR in a useful way. But, I do think that the agent may choo= se to locally enforce the rate limit, and send lost-based OLRs back to the = client in an attempt to reduce the number of requests that the agent might = have to throttle. > > For example, if the agent can achieve the rate limit at the current load = offered by the client without throttling, it need send no OLRs to the clien= t at all. In this case, the client doesn't need to know about the overload = condition. But if the agent has to throttle, it might (maybe should) delega= te the required throttling back to the client as much as it can. The loss a= lgorithm is sort of clumsy for that purpose, but it would still be better t= han nothing. > > >>> Also note that the answer in step 8 can contain only one Supported-Feat= ures AVP i.e. can only contain one selected algorithm. Even when the agent = supports loss and realm, you cannot say in one answer "use loss for realm r= outed requests and rate for host routed requests" >> One approach is where you end up with is "loss" is supported between the= client and agent, and "rate" is supported between the agent and server. >> >> Don't get me wrong, I'm not saying that's a _required_ approach, but it = should be allowed. >> I'm ok with "loss" for realm type OLRs sent from agent to clien= t and "rate" for host type OLRs sent from Server to agent in this scenario = (steps 8 and 7). >> However, if we allow an agent to translate a received host type OLR=20 >> of "rate" into a sent host type OLR of "loss" we may end up in=20 >> situations where the client receices out of sync OLRs from different=20 >> agents on different paths between client and server. > That's a good point. If your load is reasonably balanced across agents, i= t might not matter. If it _does_ matter, then something like an agent-overl= oad report (as in Steve's draft) from the agent to the client might work be= tter. > > I think we are going to need a better understanding of the rate algorithm= to really specify how this should work. I just want to make sure we don't = make choices now that prevent us from solving that later. > >>> Furthermore the client may never send host routed requests to S1. (And = if it does, it will learn the host type OLR and selected algorithm in the c= orresponding answer). >>> >> I don't follow this. Do you mean "might never"? (I read "may never" as "= is never allowed to"). >> yes sorry I meant "might never" >> >> The agent has to ensure that any OLRs that get back to the client=20 >> match the capabilities the client advertised, and received. It could=20 >> do that by stripping all OC-S-F and OLR avps in answers I agree<= /Ulrich> , or it could act as as an algorithm "gateway" and (statefully) tr= anslate between the capabilities selected on either side. >> this sounds complex to me and is absolutely=20 >> unnecessary > I didn't say it had to, I said it could. I think it's a reasonable implem= entation choice that we should not forbid, but probably also should not req= uire. > >>> I'm aware that there may be cases where agent and server select the sam= e algorithm and the problem described above disappears, but even then we sh= ould not mandate including the host-type OLR in the answer that corresponds= to a realm type request. >> I don't see that following. >> I did not say "shall forbid" but "should not mandate"=20 >> > I think others were arguing for "shall forbid". > >> We should prevent a server from putting any host reports into answers to= realm routed requests. Otherwise, you have use cases that just want work. >> how can a server receive a realm routed request? I can=20 >> understand that a server may receive a request that does not contain=20 >> a Destination-Host AVP, but that's not the definition of realm-routed=20 >> request > That's actually the point I was trying to make. If a node is a pure serve= r, then by our current definition it never ever receives a realm-routed req= uest. So a prohibition against having it put host-reports in responses to r= ealm-routed requests is both non-constraining and non-sensical. > > Now, if a previous hop Agent handled server selection, then it's up to=20 > that agent whether to pass through an existing host-report, if the=20 > original request had been realm-routed from _its_ perspective. We=20 > should neither require or forbid that. (And I actually don't think=20 > that's specific to realm-routed requests. It's true for all request=20 > and report types.) > > But if we allow the agent to pass through a host-report, then the client = must be prepared to receive it. > > >> For example, consider how a server could report any overload at all for = an application that is exclusively realm-routed. >> >> Also, consider that with the recently discussed distinction between real= m-routed requests and host-routed requests, we consider a request to be hos= t-routed if it has a Destination-Host _or_ if a node has other knowledge th= at the request will go to specific server (e.g., if the peer-selection deci= sion would send a request to the specific host. ) In the second case, the s= erver itself cannot distinguish a host-routed request from a host-routed re= quest. >> I don't follow this. Do you mean "from a realm-routed request"? > Yes. > >> My interpretation of the definition is that a server will never=20 >> receive a realm-routed request as the previous direct peer always has=20 >> the knowledge that the request will go to that server. > Agreed, so by the time the request gets to the server, it's host routed--= even if it may have been previously realm-routed. I think we are proving th= e routing type to be at least somewhat hop-by-hop. > > My main point was that the server has no knowledge that the request might= have been realm-routed prior to the agent's peer selection. > > _______________________________________________ > 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 nobody Thu Sep 11 23:48:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351AD1A0481 for ; Thu, 11 Sep 2014 23:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_52=0.6, RP_MATCHES_RCVD=-1.652] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yncMzHxEwtJl for ; Thu, 11 Sep 2014 23:48:14 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06AD1A0661 for ; Thu, 11 Sep 2014 23:48:13 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 251E04AB79484; Fri, 12 Sep 2014 06:48:10 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s8C6mB25001907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 08:48:11 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 12 Sep 2014 08:48:11 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "Maria Cruz Bartolome" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN4B9soJ86/RAkCPYLHsUJaF65v3LPWAgAFYMUCAABzR0P//6bIAgAG/6ICAAEWLcIABAywAgABgtQA= Date: Fri, 12 Sep 2014 06:48:10 +0000 Message-ID: References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2CF@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920981208A@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520A68C@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A68C@DEMUMBX014.nsn-intra.net> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7JJ4UIXXE7Q9olwEUkK2OVEUU6k Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 12 Sep 2014 06:48:16 -0000 Hi Ulrich=20 Effectively there is a logic for the DA generating the unsuccessful answer = (which will not contain any OLR as Ulrich reminded) to put its own Diameter= identity (host and realm)as Origin Host /Realm. There is a small differenc= e with the existing (when no DOIC at all) case, where a DA may also try to = redirect an unsuccessful request to other servers, and if the last one als= o rejects the request, it would normally be the Origin Host Realm of the l= ast server that DA will send back to the existing client. I would not thin= k this difference has particular consequences for the existing client.=20 Best regards JJacques=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: jeudi 11 septembre 2014 11:36 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi Jean-Jacques It is my understanding that the agent that throttles a request on behalf of= a non-DOIC supporting client populates the Origin-Host AVP in the unsucces= sful answer with its own Diameter Identity and the Origin-Realm AVP with th= e realm the agent belongs to.=20 This is independend from the request being host-routed or realm-routed. Any= way, the unsuccessful answer (in this case) shall not contain an OLR as a) the client does not support DOIC and b) it is not the agent that is overloaded Can people please confirm. Best regards Ulrich=20 -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com] Sent: Wednesday, September 10, 2014 6:18 PM To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org; d= raft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Hi MCruz, Ulrich I agree this is not related to #70 as the DA does not do throttling , but = my question still applies for a DOIC DA acting on behalf of clients not sup= porting DOIC. This DA throttles a Realm routed request. What does it send= as Origin Host in the unsuccesfull answer to the client. This question may= be more a RFC 6733 one. I may generate a ticket if this generates discussion. Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: mercredi 10 septembre 2014 15:59 =C0=A0: Wiehe, Ulrich (NSN - = DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf= -dime-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Dear JJ, I agree with Ulrich comments below. But this is not related to #70 Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: martes, 09 de septiembre de 2014 13:16 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Maria Cruz Bartolome; dime@ie= tf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Jacques, in this scenario where the client supports DOIC my understanding is: If there is a realm overload, the agent will receive only those realm route= d requests that survived a throttling at the client. There is no point for = the agent to throttle again. Anyway this seems not to be related to #70. See also inline. Ulrich -----Original Message----- From: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin= @alcatel-lucent.com] Sent: Tuesday, September 09, 2014 12:48 PM To: maria.cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear all Question Another remark on this type of use cases. There is a realm overload, the DA receives a realm routed request and decid= e to throttle it and generates a Diameter error (congestion or too busy und= er discussion). The request was not sent to any server; which Origin-Host A= VP does the DA puts in the unsuccessful answer to the client. RFC6733 6.3 s= tates that "Origin-Host AVP MUST be present in all Diameter messages. This = AVP identifies the endpoint that originated the Diameter message".=20 Another clarification, in our discussions, we speak of OLRs put in successf= ul answers; my understanding is that OLRs may also be present in unsuccess= ful answers (with a Diameter error). Do we agree on this? [Wiehe, Ulrich (NSN - DE/Munich)] I agree. Best regards Jacques =20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES) Envoy=E9=A0: mardi 9 septembre 2014 12:01 =C0=A0: maria.= cruz.bartolome@ericsson.com; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org= ; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Hi MCruz, Ulrich I think we already had some discussion on the OLRs to be reported by DA to = clients in this type of use cases. a) In step 4), in the existing draft wording, the DA sends a successful ans= wer to the client with origin host =3D S1 and an Host type OLR related to S= 1. As the client will have further Host routed requests to this S1 host, it= seemed good for the client to be immediately informed of the S1 host overl= oad, so to apply throttling to further S1 host requests. This has no impact= on Realm routed requests. In Step 8), the DA has determined a realm overload and send a realm type OL= R in the answer and also, as in step 4) the Host type OLR related to the Or= igin Host S2. This works. The point that was discussed in our previous disc= ussions, is that the answer will contains two OLRs a realm type one and a = host type one, which was accepted at this time. Is it this point you consid= er as an issue, and why?=20 b) this drives to some other remarks. The IETF draft indicates that, in 5.3= , when a reporting node requests traffic reduction, it sends OLRs in all an= swer messages (with the additional MCRuz proposal that if not present this = means no change), so this drives to have a realm type OLR related to the = Origin-Realm AVP (when overloaded) of an answer and a Host type OLR related= to the Origin-Host AVP (when overloaded) of the same answer. The example = in a) is one such case. Do you want to modify 5.3 to introduce additional r= ules, which ones? Best regards JJacques=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: lundi 8 septembre 2014 16:21 =C0=A0: dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com = Objet=A0: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exampl= e Maria Cruz, I share your concern. Please find some comments attached. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext dime issue track= er Sent: Friday, September 05, 2014 9:50 AM To: draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Cc: dime@ietf.org Subject: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example #70: Appendix B - Example In the example included in Appendix B, it is considered that the Agent re= ports Host overload directly back to the Client, when the Client request w= as for the Realm, withouth Destination Host (or direct connection). I do not agree about this behaviour. Agent will provide Host overload to the Client only when the request was = sent to one specific host. Example shall be modified. Proposed modification: Client Agent S1 S2 S3 | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes next DR traffic to S2&S3 | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OLR: RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1. The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2. The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3. S1 is overloaded. It sends an answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4. The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. 5. The client sends another Destination-Realm routed request. 6. The agent selects S2, and forwards the request. 7. It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8. The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with no Destination-Host AVP at requested rate. --=20 -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: | Owner: draft-ietf-dime- maria.cruz.bartolome@ericsson.com | ovli@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: 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 nobody Fri Sep 12 00:40:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675F31A065B for ; Fri, 12 Sep 2014 00:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XyBppVhfe8O for ; Fri, 12 Sep 2014 00:40:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC9D1A048E for ; Fri, 12 Sep 2014 00:39:59 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8C7dcUf022236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Sep 2014 07:39:53 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8C7dUxW016583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 09:39:37 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 09:39:31 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , "Nirav Salot (nsalot)" Thread-Topic: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received Thread-Index: AQHPzTgrs36h9AGZMEa1zYPVvNIfupv9Fzeg Date: Fri, 12 Sep 2014 07:39:30 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A778@DEMUMBX014.nsn-intra.net> References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@nostrum.com> In-Reply-To: <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 14390 X-purgate-ID: 151667::1410507595-00002A30-CEE96EA8/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O4E896enAIzpUXfh4Tuam4Cdi7g Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 12 Sep 2014 07:40:04 -0000 Ben, here is an example use case which I believe is concrete and might really be= used: suppose the overload control mechanism is implemented by a server in a way = that the server never sends OLRs with validity duration of more than e.g. o= ne hour. (I think it is quite reasonable to implement a limit). While an overload condition is active an OLR (e.g. reduction 10% and durati= on 30min) is included in every answer. If the overload condition lasts longer than 20 min, a refresh is generated = and sent in every answer (OLR with new sequence number, and e.g. still 10% = and 30min). If the overload condition ceases the server sends an OLR indicating "end of= overload" in every answer. If after one hour the server is still no longer overloaded, the server can = safely assume that all clients are aware of the end of overload and may the= refore cease sending OLRs until a new overload condition occurs. Ulrich=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, September 10, 2014 10:45 PM To: Nirav Salot (nsalot) Cc: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behav= iour when OC-OLR is not received On Sep 10, 2014, at 12:18 AM, Nirav Salot (nsalot) wrote= : > Ben, >=20 >> Sending in every answer is cheap and easy. We should just do it. > I woundnt agree on cheap since redundant information is sent in every ans= wer message. I already mentioned the simple topology of one PGW connected t= o one PCRF directly where even DRA is not used. I guess cheap is relative. A few extra bytes on the wire is going to be che= ap compared to almost any workable feedback-based mechanism of determining = that all the reacting nodes actually got the OLR. >=20 >> The text to make the reacting node handle getting an answer with no OLR = was there to handle weird corner cases. For example, e.g. two physical host= s with same diameter identity. (Yes, those exist.) > Nothing is changing from the reacting node since "absent of OLR should st= ill mean that the previously received OLR is active". > The idea is just to not "force" reporting node with a particular behavior= . Every time we offer this sort of choice, we add complexity to the protocol.= (This is why you see a lot of IETF-wide pushback on SHOULDs without guidan= ce on when it might make sense to do something different.). Some times tha= t complexity is worth it. In this case, I am convinced it is not. I am espe= cially convinced of this when we find the need to normatively distinguish b= etween same-vendor and cross-vendor communication. Does anyone have a concrete example of a different alternative that they mi= ght really use? >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: Wednesday, September 10, 2014 8:20 AM > To: Steve Donovan > Cc: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf= .org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.co= m > Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Beh= aviour when OC-OLR is not received >=20 >=20 > On Sep 9, 2014, at 12:14 PM, Steve Donovan wro= te: >=20 >> Nirav, >>=20 >> My concern is with interoperability. I'm also concerned with agent base= d cases where the reporting node doesn't know if it is the client for the t= ransaction or an agent that is the reacting node. We also need to address t= he fact that both the client and an agent will be reacting nodes for host r= eports in agent based deployments. >>=20 >> I think we can achieve what you are looking for with the following. This= is just the concept, not the formal wording. >>=20 >> ----- >>=20 >> The reporting node MUST ensure that all reacting nodes for the transacti= on receive all new and updated overload reports. This includes the client = for the transaction and agents involved in the transaction that have a dire= ct connection to the reporting node. >>=20 >> The recommended method to achieve this is to send OLRs in all answer mes= sages sent while the reporting node has an active overload report. Out-of-= band mechanisms can also be used by reporting nodes to determine that react= ing nodes have received overload reports but these SHOULD NOT be used in cr= oss vendor deployments. >=20 > This is degenerating into weasel wording. >=20 > Sending the OLR in every answer solves the issue for all cases. I can't i= magine a case where it does harm. Can someone suggest one? Do people really= think that making an _overloaded_ reporting node jump through hoops with = methods (whether proprietary or standardized) to determine which reacting n= odes have received the reports would every be a reasonable implementation? >=20 > Sending in every answer is cheap and easy. We should just do it. >=20 > The text to make the reacting node handle getting an answer with no OLR w= as there to handle weird corner cases. For example, e.g. two physical hosts= with same diameter identity. (Yes, those exist.) >=20 >>=20 >> ----- >>=20 >> Regards, >>=20 >> Steve >>=20 >>=20 >>=20 >> On 9/9/14, 10:16 AM, Nirav Salot (nsalot) wrote: >>> Steve, >>>=20 >>> I don't agree that "we need to provide the solution for the reporting n= ode to know if the report reached the reacting node or not". >>> The point being, it is the responsibility of the reporting node to ensu= re that the report reaches the reacting node else the overload solution wil= l not help. But this does not justify MUST requirement since this means any= alternate solution is not allowed. >>>=20 >>> Many networks may have very simple topology of one PCRF connected to on= e PGW. Why should we enforce the PCRF/PGW to include "same" OLR in every an= swer message, in that case? >>>=20 >>> Regards, >>> Nirav. >>>=20 >>> -----Original Message----- >>> From: Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Tuesday, September 09, 2014 8:40 PM >>> To: Nirav Salot (nsalot); TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 >>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org;=20 >>> maria.cruz.bartolome@ericsson.com >>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node=20 >>> Behaviour when OC-OLR is not received >>>=20 >>> All, >>>=20 >>> I agree with JJ that we have had this discussion and, I believe, we rea= ched the conclusion that the OLR MUST be in all answer messages. >>>=20 >>> This seems a much more resilient and interoperable solution. Anyone ca= n implement a proprietary solution that doesn't address all of the MUST req= uirements, but that will not work with other implementations. If we want t= o take away the MUST then we need to expand the solution to include a way f= or the reporting node to know for sure that the reacting node received the = OLR. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 9/8/14, 10:31 AM, Nirav Salot (nsalot) wrote: >>>> Hi JJ, >>>>=20 >>>> I share your view and it is the responsibility of the reporting node t= o ensure that the OLR reaches the target node. >>>> If the reporting node is not following "a" below then it has to have o= ther means to know the target of the response and also have to keep track i= f the active OLR was already sent or not. >>>> We don't have to suggest the reporting node to do this but at the same= time we need not forbid this type of implementation. >>>>=20 >>>> So I am also fine to specify that if the OLR is not received by the re= acting node then the previously received OLR stands valid. >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 >>>> [mailto:jean-jacques.trottin@alcatel-lucent.com] >>>> Sent: Monday, September 08, 2014 7:56 PM >>>> To: Steve Donovan; dime@ietf.org;=20 >>>> draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com; Nirav Salot (nsalot) >>>> Subject: RE: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>>> Node Behaviour when OC-OLR is not received >>>>=20 >>>>=20 >>>> Dear all >>>>=20 >>>> I think we are restarting a discussion we had a few months ago. >>>> The question is how frequently the OLR (with same seq number, so no ch= ange)is sent? >>>> a) current text in the draft is that the reporting node (in overload >>>> condition) must include an OC-OLR AVP in all response messages >>>> b) it can also be said it is only sent once when a change occurs in=20 >>>> the OLR. It is in theory enough >>>> c) in the middle , it can be sent in a few / many messages >>>>=20 >>>> b) is not secure, as the answer conveying the new OLR can be lost.=20 >>>> c) is OK for me if when there is a change in the OLR, the reporting=20 >>>> node rapidly send a significant amount of answers with the same seq=20 >>>> number so to consider with a high probability that the reacting node = =20 >>>> has well received the new OLR. (Note: With the current draft, apart=20 >>>> this way, I do not well see how the reporting node knows that the=20 >>>> reacting node has well received the new OLR) >>>>=20 >>>> I think that it was considered simpler to always send OLR in each an= swer than to have to take a decision at each answer to send it or not. We a= lso had a similar debate about the OC-Supported-Features) to be always pres= ent or not. >>>>=20 >>>> So a) is OK for me as simple. I accept the idea of some tolerance, wit= h Mcruz proposal that the absence of the OLR simply means no change. But th= is tolerance should not drive to a b) behavior. >>>>=20 >>>> Best regards >>>>=20 >>>> JJacques >>>> -----Message d'origine----- >>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot >>>> (nsalot) Envoy=E9 : lundi 8 septembre 2014 06:48 =C0 : Steve Donovan;= =20 >>>> dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] [dime] #72 >>>> (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not=20 >>>> received >>>>=20 >>>> Steve, >>>>=20 >>>>> I think it is better to specify the behavior of the reporting node to= always include the OLR in every answer message for as long as there is an = overload condition at the reporting node. >>>> I don't think this is necessary. The reporting may include the OLR in = every answer message but we don't have to put that as mandatory requirement= , e.g. if the reporting node knows (and keeps track of) if the target react= ing node has already received currently active OLR. >>>>=20 >>>> Regards, >>>> Nirav. >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >>>> Sent: Friday, September 05, 2014 8:01 PM >>>> To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; >>>> maria.cruz.bartolome@ericsson.com >>>> Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting=20 >>>> Node Behaviour when OC-OLR is not received >>>>=20 >>>> Maria Cruz, >>>>=20 >>>> I'm not sure I agree with this proposed change. >>>>=20 >>>> The wording to indicate that absence of an overload report was to hand= le unusual situations. Your proposed wording implies that it is acceptable= for a reporting node to not include the OLR in every answer message. >>>>=20 >>>> I think it is better to specify the behavior of the reporting node to = always include the OLR in every answer message for as long as there is an o= verload condition at the reporting node. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> On 9/5/14, 3:03 AM, dime issue tracker wrote: >>>>> #72: Reporting Node Behaviour when OC-OLR is not received >>>>>=20 >>>>> A clarification is required to consider that an answer message may = not >>>>> include OC-OLR and still the reporting node be overloaded, since i= t is >>>>> considered as "no change", as documented in 4.2.1.3: >>>>>=20 >>>>> Reacting nodes do not delete an OCS when receiving an answer me= ssage >>>>> that does not contain an OC-OLR AVP (i.e. absence of OLR means = "no >>>>> change"). >>>>>=20 >>>>>=20 >>>>> Original text: >>>>>=20 >>>>> 5.3. Reporting Node Behavior (Normative) >>>>>=20 >>>>> The method a reporting nodes uses to determine the amount of tra= ffic >>>>> reduction required to address an overload condition is an >>>>> implementation decision. >>>>>=20 >>>>> When a reporting node that has selected the loss abatement algor= ithm >>>>> determines the need to request a traffic reduction it must inclu= de an >>>>> OC-OLR AVP in all response messages. >>>>>=20 >>>>>=20 >>>>> Proposed addition: >>>>>=20 >>>>>=20 >>>>> 5.3. Reporting Node Behavior (Normative) >>>>>=20 >>>>> The method a reporting nodes uses to determine the amount of tra= ffic >>>>> reduction required to address an overload condition is an >>>>> implementation decision. >>>>>=20 >>>>> When a reporting node that has selected the loss abatement algor= ithm >>>>> determines the need to request a traffic reduction it must inclu= de an >>>>> OC-OLR AVP in all response messages. OC-OLR AVP is not included = when >>>>> reporting node expectations on traffic reduction are not modified. = That >>>>> is, if OC-OLR AVP is not included it is interpreted as "no change". >>>>>=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 >>=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 From nobody Fri Sep 12 02:54:03 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8AE1A00F1 for ; Fri, 12 Sep 2014 02:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IiTLJXHnv3E for ; Fri, 12 Sep 2014 02:53:59 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3B01A00E9 for ; Fri, 12 Sep 2014 02:53:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8C9rtql018840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Sep 2014 09:53:55 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8C9rs8E008262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 11:53:54 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 12 Sep 2014 11:53:53 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 11:53:53 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4CAALBYAIAA2puggABHyYCAAVSmwA== Date: Fri, 12 Sep 2014 09:53:53 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> In-Reply-To: <5411A97F.2020007@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 14833 X-purgate-ID: 151667::1410515635-00002A30-74A99A6B/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dDI1qkvJat59NtLFgSvXxCWSMIs Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 12 Sep 2014 09:54:02 -0000 Steve, please see inline. Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Thursday, September 11, 2014 3:54 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example All, It seems the concern is forcing the client to save OCS state for host=20 reports from servers to which the client never sends host routed=20 requests. This, I think, is only an issue for requests that do not=20 contain a destination-host AVP. Please correct me if I'm mistaken. I listed 4 issues (see below). You address only half of issue 4. The other half is forcing the client to save OCS state for realm reports from agents (realms) to which the client never sends realm routed requests. I think we all agree that the server has no way to differentiate host=20 routed requests from realm routed requests in this case, so the solution=20 cannot be server based. That leaves two options: 1) The agent that does the server selection strips the host report for=20 these types of transactions. 2) The client ignores host reports for these types of transactions. I agree that these are the options when the request was realm-routed. When the request was host routed the options are 1') The agent does not insert a realm report to an answer forwarded from server to client 2') The agent inserts a realm report and the client ignores it. At least we should allow option 1 (and 1'); or are there any issues with this option? Whether or not to allow option 2 (and 2') needs to be discussed, as there are issues. Option 2 seems better to me, as it is the client that understands=20 whether or not the host reports have value. host reports in answers that correspond to realm-routed requests never have added value. Similarly, realm reports in answer messages that=20 correspond to host-routed requestsnever have added value. See issue 3 below= . For some applications the=20 client might never send requests with a destination-host AVP. In this=20 case the client can safely ignore the OLRs. For applications where=20 there is a mix of transaction types (host-routed and realm-routed), the=20 client might choose to save all OLRs in the interest of better handling=20 the overload for the requests that do include the destination-host AVP. What do you mean with "better handling"? Note that in this type of application, it will still work if the client=20 ignores all host reports received on "realm-routed" transactions as the=20 client will still receive a host report on host-routed transactions. =20 This assumes that all answer messages have the OLR for the duration of=20 the overload event. I suggest wording something like: A client MAY ignore OLRs of type host received in transactions where the=20 request was realm-routed by the client. ok, but also:=20 "A client MAY ignore OLRs of type realm received in transactions where the request was host-routed by the client." (And maybe replace "client" with "reacting node") Note: In applications where there is a mix of realm-routed and=20 host-routed requests it is recommended that the client save all host=20 overload reports. I would like to see all issues solved before recommending so. Regards, Steve On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Ben, > > you worte: > My main point was that the server has no knowledge that the request might= have been realm-routed prior to the agent's peer selection. > > I think there in no need for the server to have this knowledge. The serve= r simply puts its host-type OLR in the answer. > The agent that handled server selection receives this OLR and makes use o= f it for > a) diverting future realm routed request to other servers and > b) calculating an aggregated realm overload (taking into account the supp= orted algorithm at the client). > This aggregated realm-type OLR is sent to the client. > Open question is whether in addition also the host-type OLR generated by = the server is sent to the client. Issues identified so far are: > 1. Two OLRs in one answer must use the same algorithm resulting in the ne= ed for some kind of OLR conversion from one algorithm to another. > 2. Host type OLRs received by the client may easily get out of synch. > 3. There is no added value as the client either has no need for the host-= type OLR (i.e. never sends host-type requests to the server) or will receiv= e it with the response to the next sent host-type request. > 4. There may be negative impact for clients that are forced to maintain O= CSs that are never used. > > Similar to this is another point recently questiond by JJ: > Whether an agent may insert a realm-type OLR to an answer which correspon= ds to a host-routed request, and which potentially already contains a host-= type OLR. (This would only be possible if the agent supports the algorithm = that was negotiated/selected between client and server). > Again I think that there is no added value as the client either has no ne= ed for the realm-type OLR (i.e. never sends realm-type requests to the real= m) or will receive it with the response to the next sent realm-type request= . And again there may be negative impacts for clients. > > As a way forward we may think about a way to convey both OLRs in one answ= er but clearly indicate which OLR is the "real thing" and which is the addi= tional one. It must however be made clear that the additional one can savel= y be ignored by the reacting node. > > Ulrich > > > > =20 > =20 > > > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, September 10, 2014 10:35 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Examp= le > > > On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > >> Ben, >> >> please see comments inline. >> >> Ulrich >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 4:38 AM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@erics= son.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exam= ple >> >> We had exactly that example in the draft discussed in Toronto ( draft-do= novan-doic-agent-cases ). >> >> Comments inline: >> >> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Dear JJacques, >>> >>> assume the following example: >>> In step 1 (realm routed request sent from Client to Agent), the client = indicates that it supports loss. >>> In step 2 (host routed request send from agent to S1), the agent indica= tes that it supports loss and rate. >>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 ind= icates that it selected rate. >>> >>> Now in step 4 there is no point in forwarding the host-type OLR from ag= ent to client as the client does not support rate. Similar for step 8 where= no host type OLR of rate shall be sent in addition to the realm-type OLR o= f loss. >> I agree there is no point forwarding the OLR per se. However, the agent = may still indicate that it supports "loss" back to the client, and send los= s-based reports if the client sends too much traffic for the agent to compl= y with the max rate without throttling. >> I think the agent shall indicate that it supports "loss" back t= o the client. > I wouldn't put it as strongly as "shall", but I think there are circumsta= nces where it makes sense to do so. (see next comment). There may also be c= ircumstances where it decides to handle OC control locally, in which case i= t may chose not to send any OC-O-F at all back to the client. > >> In addition, are you proposing that the agent may translate the rate bas= ed host-type OLR received from S1 into a loss based host type OLR and forwa= rd it to the client? > Not quite. I would use the term "gateway" rather than "translate". > > I think it highly unlikely one can translate any given rate-based OLR int= o a loss-based OLR in a useful way. But, I do think that the agent may choo= se to locally enforce the rate limit, and send lost-based OLRs back to the = client in an attempt to reduce the number of requests that the agent might = have to throttle. > > For example, if the agent can achieve the rate limit at the current load = offered by the client without throttling, it need send no OLRs to the clien= t at all. In this case, the client doesn't need to know about the overload = condition. But if the agent has to throttle, it might (maybe should) delega= te the required throttling back to the client as much as it can. The loss a= lgorithm is sort of clumsy for that purpose, but it would still be better t= han nothing. > > >>> Also note that the answer in step 8 can contain only one Supported-Feat= ures AVP i.e. can only contain one selected algorithm. Even when the agent = supports loss and realm, you cannot say in one answer "use loss for realm r= outed requests and rate for host routed requests" >> One approach is where you end up with is "loss" is supported between the= client and agent, and "rate" is supported between the agent and server. >> >> Don't get me wrong, I'm not saying that's a _required_ approach, but it = should be allowed. >> I'm ok with "loss" for realm type OLRs sent from agent to clien= t and "rate" for host type OLRs sent from Server to agent in this scenario = (steps 8 and 7). >> However, if we allow an agent to translate a received host type OLR of "= rate" into a sent host type OLR of "loss" we may end up in situations where= the client receices out of sync OLRs from different agents on different pa= ths between client and server. > That's a good point. If your load is reasonably balanced across agents, i= t might not matter. If it _does_ matter, then something like an agent-overl= oad report (as in Steve's draft) from the agent to the client might work be= tter. > > I think we are going to need a better understanding of the rate algorithm= to really specify how this should work. I just want to make sure we don't = make choices now that prevent us from solving that later. > >>> Furthermore the client may never send host routed requests to S1. (And = if it does, it will learn the host type OLR and selected algorithm in the c= orresponding answer). >>> >> I don't follow this. Do you mean "might never"? (I read "may never" as "= is never allowed to"). >> yes sorry I meant "might never" >> >> The agent has to ensure that any OLRs that get back to the client match = the capabilities the client advertised, and received. It could do that by s= tripping all OC-S-F and OLR avps in answers >> I agree >> , or it could act as as an algorithm "gateway" and (statefully) translat= e between the capabilities selected on either side. >> this sounds complex to me and is absolutely unnecessary > I didn't say it had to, I said it could. I think it's a reasonable implem= entation choice that we should not forbid, but probably also should not req= uire. > >>> I'm aware that there may be cases where agent and server select the sam= e algorithm and the problem described above disappears, but even then we sh= ould not mandate including the host-type OLR in the answer that corresponds= to a realm type request. >> I don't see that following. >> I did not say "shall forbid" but "should not mandate" > I think others were arguing for "shall forbid". > >> We should prevent a server from putting any host reports into answers to= realm routed requests. Otherwise, you have use cases that just want work. >> how can a server receive a realm routed request? I can understan= d that a server may receive a request that does not contain a Destination-H= ost AVP, but that's not the definition of realm-routed request > That's actually the point I was trying to make. If a node is a pure serve= r, then by our current definition it never ever receives a realm-routed req= uest. So a prohibition against having it put host-reports in responses to r= ealm-routed requests is both non-constraining and non-sensical. > > Now, if a previous hop Agent handled server selection, then it's up to th= at agent whether to pass through an existing host-report, if the original r= equest had been realm-routed from _its_ perspective. We should neither req= uire or forbid that. (And I actually don't think that's specific to realm-= routed requests. It's true for all request and report types.) > > But if we allow the agent to pass through a host-report, then the client = must be prepared to receive it. > > >> For example, consider how a server could report any overload at all for = an application that is exclusively realm-routed. >> >> Also, consider that with the recently discussed distinction between real= m-routed requests and host-routed requests, we consider a request to be hos= t-routed if it has a Destination-Host _or_ if a node has other knowledge th= at the request will go to specific server (e.g., if the peer-selection deci= sion would send a request to the specific host. ) In the second case, the s= erver itself cannot distinguish a host-routed request from a host-routed re= quest. >> I don't follow this. Do you mean "from a realm-routed request"? > Yes. > >> My interpretation of the definition is that a server will never receive = a realm-routed request as the previous direct peer always has the knowledge= that the request will go to that server. > Agreed, so by the time the request gets to the server, it's host routed--= even if it may have been previously realm-routed. I think we are proving th= e routing type to be at least somewhat hop-by-hop. > > My main point was that the server has no knowledge that the request might= have been realm-routed prior to the agent's peer selection. > > _______________________________________________ > 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 nobody Fri Sep 12 05:14:39 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B641A071C for ; Fri, 12 Sep 2014 05:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04qfIMZ1B_vH for ; Fri, 12 Sep 2014 05:14:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778D11A0716 for ; Fri, 12 Sep 2014 05:14:23 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A0B0AB8AB2E47; Fri, 12 Sep 2014 12:14:18 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8CCCPKj025076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 14:14:15 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.220]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 12 Sep 2014 14:12:54 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "maria.cruz.bartolome@ericsson.com" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/A= Date: Fri, 12 Sep 2014 12:12:54 +0000 Message-ID: References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> In-Reply-To: <5409C5A4.5090203@usdonovans.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5owXD6Qh3gp1qGO2rW_rakhJ-Ak Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 12 Sep 2014 12:14:36 -0000 Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; maria.cruz.bart= olome@ericsson.com Objet=A0: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 15 08:17:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037C11A0387 for ; Mon, 15 Sep 2014 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIg5Sm8raxu0 for ; Mon, 15 Sep 2014 08:17:45 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422F51A037C for ; Mon, 15 Sep 2014 08:17:45 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61157 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTY26-0003r5-0H; Mon, 15 Sep 2014 08:17:40 -0700 Message-ID: <54170311.9070400@usdonovans.com> Date: Mon, 15 Sep 2014 10:17:37 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ajP7UGplvOFsyotk0u_1bRt2lFg Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Sep 2014 15:17:46 -0000 Ulrich, I was suggesting that the client is the best to understand if there is value in a specific OLR and, if the client knows that it will never have a request that is impacted by the overload report then it can choose to not save OCS related to the OLR. On your four points, more comments below: >> 1. Two OLRs in one answer must use the same algorithm resulting in the need for some kind of OLR conversion from one algorithm to another. SRD> I don't understand the issue. Both reports would be for the loss algorithm. How agents handle interaction between loss and future algorithms like rate is a separate question. >> 2. Host type OLRs received by the client may easily get out of synch. SRD> Can you explain this. How can host OLRs get out of sync? >> 3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-type request. SRD> If the client never sends to the reporting node then it can ignore the OLR. If it does send to the reporting node then it should start applying the overload report, independent of the type of transaction used to receive the OLR. >> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used. SRD> Are there negative impacts other than the state it needs to save? Regards, Steve From nobody Mon Sep 15 08:38:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A001E1A6FA9 for ; Mon, 15 Sep 2014 08:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWsDVajQ6Ryz for ; Mon, 15 Sep 2014 08:38:46 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414B61A6FB7 for ; Mon, 15 Sep 2014 08:31:55 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:61169 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XTYFr-0007lZ-AT; Mon, 15 Sep 2014 08:31:54 -0700 Message-ID: <54170666.3050900@usdonovans.com> Date: Mon, 15 Sep 2014 10:31:50 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gxCwjIlNL3C1GYTrFp5S20C41Sc Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Sep 2014 15:38:49 -0000 Ulrich, A few more comments inline. Steve On 9/12/14, 4:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > please see inline. > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Thursday, September 11, 2014 3:54 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example > > All, > > It seems the concern is forcing the client to save OCS state for host > reports from servers to which the client never sends host routed > requests. This, I think, is only an issue for requests that do not > contain a destination-host AVP. Please correct me if I'm mistaken. > > > I listed 4 issues (see below). You address only half of issue 4. > The other half is forcing the client to save OCS state for realm reports > from agents (realms) to which the client never sends realm routed requests. > > > I think we all agree that the server has no way to differentiate host > routed requests from realm routed requests in this case, so the solution > cannot be server based. > > That leaves two options: > > 1) The agent that does the server selection strips the host report for > these types of transactions. > > 2) The client ignores host reports for these types of transactions. > > > I agree that these are the options when the request was realm-routed. > When the request was host routed the options are > > 1') The agent does not insert a realm report to an answer forwarded > from server to client > > 2') The agent inserts a realm report and the client ignores it. SRD> There are scenarios where realm reports cannot be used. Partitioning of the server space is the primary example. As such, we need to make sure we aren't designing a solution that depends on realm reports. That's not saying that realm reports don't have value, just that they can't always be used. > > At least we should allow option 1 (and 1'); or are there any issues > with this option? Whether or not to allow option 2 (and 2') needs to be > discussed, as there are issues. > SRD> I disagree with allowing 1. The only time that an agent should strip a host report is when it knows it is the reacting node host-routed requests. > > Option 2 seems better to me, as it is the client that understands > whether or not the host reports have value. > > > host reports in answers that correspond to realm-routed requests > never have added value. Similarly, realm reports in answer messages that > correspond to host-routed requestsnever have added value. See issue 3 below. > SRD> How is it not good for a client to know about the fact that a server is overloaded? How is it not good for a client to know that a realm is overloaded? There is clear value for both cases, as the sooner a client learns about overload of a server or realm to which it sends requests the sooner the overload condition will be abated. SRD> There might be times when an OLR isn't useful to a client/reacting node. I disagree with the assertion that there is never added value. > > For some applications the > client might never send requests with a destination-host AVP. In this > case the client can safely ignore the OLRs. For applications where > there is a mix of transaction types (host-routed and realm-routed), the > client might choose to save all OLRs in the interest of better handling > the overload for the requests that do include the destination-host AVP. > > > What do you mean with "better handling"? > SRD> I mean that the sooner a reacting node learns about an overload condition the sooner the overload condition can be properly handled. > > Note that in this type of application, it will still work if the client > ignores all host reports received on "realm-routed" transactions as the > client will still receive a host report on host-routed transactions. > This assumes that all answer messages have the OLR for the duration of > the overload event. > > I suggest wording something like: > > A client MAY ignore OLRs of type host received in transactions where the > request was realm-routed by the client. > > > ok, but also: > "A client MAY ignore OLRs of type realm received in transactions where the > request was host-routed by the client." > (And maybe replace "client" with "reacting node") > SRD> Yes, it should say reacting node. > > Note: In applications where there is a mix of realm-routed and > host-routed requests it is recommended that the client save all host > overload reports. > > > I would like to see all issues solved before recommending so. > SRD> I don't understand issues 1 and 2. I think my proposal addresses issues 3 and 4. > Regards, > > Steve > > On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Ben, >> >> you worte: >> My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection. >> >> I think there in no need for the server to have this knowledge. The server simply puts its host-type OLR in the answer. >> The agent that handled server selection receives this OLR and makes use of it for >> a) diverting future realm routed request to other servers and >> b) calculating an aggregated realm overload (taking into account the supported algorithm at the client). >> This aggregated realm-type OLR is sent to the client. >> Open question is whether in addition also the host-type OLR generated by the server is sent to the client. Issues identified so far are: >> 1. Two OLRs in one answer must use the same algorithm resulting in the need for some kind of OLR conversion from one algorithm to another. >> 2. Host type OLRs received by the client may easily get out of synch. >> 3. There is no added value as the client either has no need for the host-type OLR (i.e. never sends host-type requests to the server) or will receive it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain OCSs that are never used. >> >> Similar to this is another point recently questiond by JJ: >> Whether an agent may insert a realm-type OLR to an answer which corresponds to a host-routed request, and which potentially already contains a host-type OLR. (This would only be possible if the agent supports the algorithm that was negotiated/selected between client and server). >> Again I think that there is no added value as the client either has no need for the realm-type OLR (i.e. never sends realm-type requests to the realm) or will receive it with the response to the next sent realm-type request. And again there may be negative impacts for clients. >> >> As a way forward we may think about a way to convey both OLRs in one answer but clearly indicate which OLR is the "real thing" and which is the additional one. It must however be made clear that the additional one can savely be ignored by the reacting node. >> >> Ulrich >> >> >> >> >> >> >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 10:35 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example >> >> >> On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Ben, >>> >>> please see comments inline. >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: ext Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Wednesday, September 10, 2014 4:38 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@ericsson.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org >>> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example >>> >>> We had exactly that example in the draft discussed in Toronto ( draft-donovan-doic-agent-cases ). >>> >>> Comments inline: >>> >>> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> >>>> Dear JJacques, >>>> >>>> assume the following example: >>>> In step 1 (realm routed request sent from Client to Agent), the client indicates that it supports loss. >>>> In step 2 (host routed request send from agent to S1), the agent indicates that it supports loss and rate. >>>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 indicates that it selected rate. >>>> >>>> Now in step 4 there is no point in forwarding the host-type OLR from agent to client as the client does not support rate. Similar for step 8 where no host type OLR of rate shall be sent in addition to the realm-type OLR of loss. >>> I agree there is no point forwarding the OLR per se. However, the agent may still indicate that it supports "loss" back to the client, and send loss-based reports if the client sends too much traffic for the agent to comply with the max rate without throttling. >>> I think the agent shall indicate that it supports "loss" back to the client. >> I wouldn't put it as strongly as "shall", but I think there are circumstances where it makes sense to do so. (see next comment). There may also be circumstances where it decides to handle OC control locally, in which case it may chose not to send any OC-O-F at all back to the client. >> >>> In addition, are you proposing that the agent may translate the rate based host-type OLR received from S1 into a loss based host type OLR and forward it to the client? >> Not quite. I would use the term "gateway" rather than "translate". >> >> I think it highly unlikely one can translate any given rate-based OLR into a loss-based OLR in a useful way. But, I do think that the agent may choose to locally enforce the rate limit, and send lost-based OLRs back to the client in an attempt to reduce the number of requests that the agent might have to throttle. >> >> For example, if the agent can achieve the rate limit at the current load offered by the client without throttling, it need send no OLRs to the client at all. In this case, the client doesn't need to know about the overload condition. But if the agent has to throttle, it might (maybe should) delegate the required throttling back to the client as much as it can. The loss algorithm is sort of clumsy for that purpose, but it would still be better than nothing. >> >> >>>> Also note that the answer in step 8 can contain only one Supported-Features AVP i.e. can only contain one selected algorithm. Even when the agent supports loss and realm, you cannot say in one answer "use loss for realm routed requests and rate for host routed requests" >>> One approach is where you end up with is "loss" is supported between the client and agent, and "rate" is supported between the agent and server. >>> >>> Don't get me wrong, I'm not saying that's a _required_ approach, but it should be allowed. >>> I'm ok with "loss" for realm type OLRs sent from agent to client and "rate" for host type OLRs sent from Server to agent in this scenario (steps 8 and 7). >>> However, if we allow an agent to translate a received host type OLR of "rate" into a sent host type OLR of "loss" we may end up in situations where the client receices out of sync OLRs from different agents on different paths between client and server. >> That's a good point. If your load is reasonably balanced across agents, it might not matter. If it _does_ matter, then something like an agent-overload report (as in Steve's draft) from the agent to the client might work better. >> >> I think we are going to need a better understanding of the rate algorithm to really specify how this should work. I just want to make sure we don't make choices now that prevent us from solving that later. >> >>>> Furthermore the client may never send host routed requests to S1. (And if it does, it will learn the host type OLR and selected algorithm in the corresponding answer). >>>> >>> I don't follow this. Do you mean "might never"? (I read "may never" as "is never allowed to"). >>> yes sorry I meant "might never" >>> >>> The agent has to ensure that any OLRs that get back to the client match the capabilities the client advertised, and received. It could do that by stripping all OC-S-F and OLR avps in answers >>> I agree >>> , or it could act as as an algorithm "gateway" and (statefully) translate between the capabilities selected on either side. >>> this sounds complex to me and is absolutely unnecessary >> I didn't say it had to, I said it could. I think it's a reasonable implementation choice that we should not forbid, but probably also should not require. >> >>>> I'm aware that there may be cases where agent and server select the same algorithm and the problem described above disappears, but even then we should not mandate including the host-type OLR in the answer that corresponds to a realm type request. >>> I don't see that following. >>> I did not say "shall forbid" but "should not mandate" >> I think others were arguing for "shall forbid". >> >>> We should prevent a server from putting any host reports into answers to realm routed requests. Otherwise, you have use cases that just want work. >>> how can a server receive a realm routed request? I can understand that a server may receive a request that does not contain a Destination-Host AVP, but that's not the definition of realm-routed request >> That's actually the point I was trying to make. If a node is a pure server, then by our current definition it never ever receives a realm-routed request. So a prohibition against having it put host-reports in responses to realm-routed requests is both non-constraining and non-sensical. >> >> Now, if a previous hop Agent handled server selection, then it's up to that agent whether to pass through an existing host-report, if the original request had been realm-routed from _its_ perspective. We should neither require or forbid that. (And I actually don't think that's specific to realm-routed requests. It's true for all request and report types.) >> >> But if we allow the agent to pass through a host-report, then the client must be prepared to receive it. >> >> >>> For example, consider how a server could report any overload at all for an application that is exclusively realm-routed. >>> >>> Also, consider that with the recently discussed distinction between realm-routed requests and host-routed requests, we consider a request to be host-routed if it has a Destination-Host _or_ if a node has other knowledge that the request will go to specific server (e.g., if the peer-selection decision would send a request to the specific host. ) In the second case, the server itself cannot distinguish a host-routed request from a host-routed request. >>> I don't follow this. Do you mean "from a realm-routed request"? >> Yes. >> >>> My interpretation of the definition is that a server will never receive a realm-routed request as the previous direct peer always has the knowledge that the request will go to that server. >> Agreed, so by the time the request gets to the server, it's host routed--even if it may have been previously realm-routed. I think we are proving the routing type to be at least somewhat hop-by-hop. >> >> My main point was that the server has no knowledge that the request might have been realm-routed prior to the agent's peer selection. >> >> _______________________________________________ >> 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 nobody Mon Sep 15 13:46:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563801A870C for ; Mon, 15 Sep 2014 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Mx5YmLDqL4 for ; Mon, 15 Sep 2014 13:46:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA691A86F7 for ; Mon, 15 Sep 2014 13:46:33 -0700 (PDT) Received: from [172.19.131.150] ([12.130.116.84]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8FKkGjW013167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Sep 2014 15:46:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.130.116.84] claimed to be [172.19.131.150] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (11D257) In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520A778@DEMUMBX014.nsn-intra.net> Date: Mon, 15 Sep 2014 15:45:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A778@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9OKku0eW1tG0mqhWez_sI9L6Cd8 Cc: "draft-ietf-dime-ovli@tools.ietf.org" , "dime@ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Sep 2014 20:46:39 -0000 On Sep 12, 2014, at 2:39 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 > Ben, >=20 > here is an example use case which I believe is concrete and might really b= e used: >=20 > suppose the overload control mechanism is implemented by a server in a way= that the server never sends OLRs with validity duration of more than e.g. o= ne hour. (I think it is quite reasonable to implement a limit). >=20 > While an overload condition is active an OLR (e.g. reduction 10% and durat= ion 30min) is included in every answer. > If the overload condition lasts longer than 20 min, a refresh is generated= and sent in every answer (OLR with new sequence number, and e.g. still 10% a= nd 30min). > If the overload condition ceases the server sends an OLR indicating "end o= f overload" in every answer. > If after one hour the server is still no longer overloaded, the server can= safely assume that all clients are aware of the end of overload and may the= refore cease sending OLRs until a new overload condition occurs. >=20 > Ulrich Hmm. Your example seems to be one of sending an OLR in every answer for the d= uration of the overload request. That's how I have even arguing it should wo= rk. I never meant to say that the server had to send an OLR in every request= when it was not actually overloaded. You do bring up an interesting point is, how long should the server keep sen= ding an OLR that ends the overload condition? In your example, that appears t= o be a case of local policy. I'm okay with that, but we should probably at l= east mention it. (Possibly with the guidance that once a reporting node know= s that all previous OLRs have expired, there's no longer any reason to send t= ermination OLRs.) From nobody Mon Sep 15 18:36:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1590C1A00BA for ; Mon, 15 Sep 2014 18:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdrLnsT2o_fV for ; Mon, 15 Sep 2014 18:36:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB151A00D8 for ; Mon, 15 Sep 2014 18:36:17 -0700 (PDT) Received: from [172.20.10.2] ([166.205.64.218]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s8G1aArL036765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Sep 2014 20:36:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [166.205.64.218] claimed to be [172.20.10.2] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Mon, 15 Sep 2014 20:35:55 -0500 X-Mao-Original-Outgoing-Id: 432524155.166168-db3b6545aa0e6f8c4e5e99979531c12d Content-Transfer-Encoding: quoted-printable Message-Id: <09F832E1-8A59-492B-A0BD-E388F5548965@nostrum.com> References: <075.67c19030c021c5f440170dd8f3f3c9a8@trac.tools.ietf.org> <5409C913.7080103@usdonovans.com> <540F185E.6080706@usdonovans.com> <540F3573.9030202@usdonovans.com> <004BA4FD-37BE-408A-B9DE-526EE3E579B8@nostrum.com> <6A88EB98-1EFC-4FEB-A137-8D3102A5BA8D@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A778@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_Ceme7ysg7QL7nREYwmU3wA8pos Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #72 (draft-ietf-dime-ovli): Reporting Node Behaviour when OC-OLR is not received X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2014 01:36:19 -0000 On Sep 15, 2014, at 3:45 PM, Ben Campbell wrote: > On Sep 12, 2014, at 2:39 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>=20 >> Ben, >>=20 >> here is an example use case which I believe is concrete and might = really be used: >>=20 >> suppose the overload control mechanism is implemented by a server in = a way that the server never sends OLRs with validity duration of more = than e.g. one hour. (I think it is quite reasonable to implement a = limit). >>=20 >> While an overload condition is active an OLR (e.g. reduction 10% and = duration 30min) is included in every answer. >> If the overload condition lasts longer than 20 min, a refresh is = generated and sent in every answer (OLR with new sequence number, and = e.g. still 10% and 30min). >> If the overload condition ceases the server sends an OLR indicating = "end of overload" in every answer. >> If after one hour the server is still no longer overloaded, the = server can safely assume that all clients are aware of the end of = overload and may therefore cease sending OLRs until a new overload = condition occurs. >>=20 >> Ulrich >=20 > Hmm. Your example seems to be one of sending an OLR in every answer = for the duration of the overload request. That's how I have even arguing = it should work. s/"even arguing"/"been arguing" (iPad autocorrect :-) ) > I never meant to say that the server had to send an OLR in every = request when it was not actually overloaded. >=20 > You do bring up an interesting point is, how long should the server = keep sending an OLR that ends the overload condition? In your example, = that appears to be a case of local policy. I'm okay with that, but we = should probably at least mention it. (Possibly with the guidance that = once a reporting node knows that all previous OLRs have expired, there's = no longer any reason to send termination OLRs.) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Sep 16 18:51:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830591A212A for ; Tue, 16 Sep 2014 18:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca8RLKMIL1h0 for ; Tue, 16 Sep 2014 18:50:49 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF4A1A0655 for ; Tue, 16 Sep 2014 18:50:49 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id l13so4499068iga.3 for ; Tue, 16 Sep 2014 18:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fiVE3DvFUXadYoQKNXUrZJXNU3SKX+4bIflfIL3x6k4=; b=aZ3n65Ph7k0LN09r6S7KGWO6YP3+Gl5cswoUUH8R8HZzM1HfEOOXB8SFddshrzkczG xhv8gIJcDg7diGHg70m6qZRBE3yTJhy+dvgoqIJJ4iONMTxVZ0fCMkRDsCS11lySjNxx 1kxBLtr/sGSGz2mxX0Vh/OSNEORD+rFTAhyuepPwp0nmgBS8Rcrt82H9KKP2ZKQ+97h5 nUuAhTglmTol2haig4HOmbmbPt1EBU+LW9r7oh+mHMIgw5Z5hKM1ub0jrPD9AITUHKFO XtUYdiAeSKofOyEQ3Byf29bL3huLYTKICeieKMJDsRsky1dr8qfJy6lDUa+cEBhbFeYU kdCg== X-Received: by 10.50.33.73 with SMTP id p9mr34968374igi.24.1410918648867; Tue, 16 Sep 2014 18:50:48 -0700 (PDT) Received: from [192.168.97.8] ([67.210.160.130]) by mx.google.com with ESMTPSA id l19sm3059568igk.6.2014.09.16.18.50.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 18:50:48 -0700 (PDT) Message-ID: <5418E8F8.9010605@gmail.com> Date: Tue, 16 Sep 2014 21:50:48 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> In-Reply-To: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GrpJk-ZoCK6MzSGdCfKgk-weZkE Subject: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Sep 2014 01:50:51 -0000 This is the mature version of a document on which DIME has provided advice in the past. Please have a quick look and see whether it makes sense in Diameter terms. If it is OK, I'm not sure what process the Chairs want to follow: adopt as a DIME document, or pass it off to Softwires? Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt Date: Tue, 16 Sep 2014 18:21:42 -0700 From: internet-drafts@ietf.org To: M. Boucadair , "Qiong Sun" , "Tom Taylor" , Cathy Zhou , Qiong Sun , T. Taylor , "Cathy Zhou" , "Mohamed Boucadair" A new version of I-D, draft-zhou-dime-4over6-provisioning-04.txt has been successfully submitted by T. Taylor and posted to the IETF repository. Name: draft-zhou-dime-4over6-provisioning Revision: 04 Title: Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions Document date: 2014-09-16 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-04.txt Status: https://datatracker.ietf.org/doc/draft-zhou-dime-4over6-provisioning/ Htmlized: http://tools.ietf.org/html/draft-zhou-dime-4over6-provisioning-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-zhou-dime-4over6-provisioning-04 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates 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 (RFC 6733) attribute-value pairs to be used for that purpose. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Sep 17 04:12:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387D1A0202 for ; Wed, 17 Sep 2014 04:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXi6feq0E0AH for ; Wed, 17 Sep 2014 04:12:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1231A0067 for ; Wed, 17 Sep 2014 04:12:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 237EB18C36E; Wed, 17 Sep 2014 13:12:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 07A1F35C07B; Wed, 17 Sep 2014 13:12:25 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 13:12:24 +0200 From: To: Tom Taylor , "dime@ietf.org" Thread-Topic: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt Thread-Index: AQHP0hnq2qfCS0mUN0+aJfg/GZ8d0ZwFEFrQ Date: Wed, 17 Sep 2014 11:12:23 +0000 Message-ID: <6341_1410952345_54196C99_6341_4311_1_6B7134B31289DC4FAF731D844122B36E721810@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> <5418E8F8.9010605@gmail.com> In-Reply-To: <5418E8F8.9010605@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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.17.72421 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QKzOcaLoMuIcOo-IYCSak1k-Uhs Subject: Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Sep 2014 11:12:29 -0000 Hi Tom, Coming back on the need for a new format ("Common prefix Data format"), cou= ld you please explain (or remind me) why this new AVP format would be simpl= er than creating a Grouped AVP as soon as Prefix or Address can be provisio= ned? For instance, based on the current draft, the Tunnel-Source-Pref-Or-Addr is= defined as a single AVP using the new AVP format defined in this draft: 3.4. Tunnel-Source-Pref-Or-Addr AVP The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) conveys either the IPv6 Binding Prefix or the tunnel source address on the CE, as described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP uses the common prefix data format. The AddressType field MUST be set to 2 (IPv6). Valid values in the PrefixLength field are from 0 to 128 (full address). This AVP is defined separately from the LW4over6-Binding AVP (which includes it) to provide flexibility in the transport of the tunnel source address from the provisioning system to AAA. But the same info could be also provided as follow: 3.4. Tunnel-Source-Pref-Or-Addr AVP The Tunnel-Source-Pref-Or-Addr (AVP Code TBD0X) is of type Grouped. It MUST contains either an either the IPv6 Binding Prefix or the tunnel = source=20 address on the CE, as described in Section 2.2.=20=20=20 Tunnel-Source-Pref-Or-Addr ::=3D < AVP Header: TBD0X > [ Tunnel-Source-Address ] [ Tunnel-Source-Prefix ] *[ AVP ] 3.X Tunnel-Source-Address AVP=20 The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address=20 and specifies the tunnel source IPv6 address on the CE. 3.Y. Framed-IPv6-Prefix AVP The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString and contains the IPv6 Binding Prefix on the CE. If there is no risk of clash, the existing Framed-IPv6-Prefix AVP could eve= n be reused for the second one. This alternative would have the advantage not to define a new format. I'm n= ot saying that the definition of any new format should be prohibited. But i= n this case, it seems weird to have to define a new format for combining di= fferent types of information that can be already carried in existing AVPs. About the link with Softwires, we need to ensure that the set of informatio= n defined in this document has reviewed and somehow endorsed by the WG. The= n I think it will become a pure Dime discussion. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Tom Taylor Envoy=E9=A0: mercredi 17 septembre 2014 03:51 =C0=A0: dime@ietf.org Objet=A0: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-p= rovisioning-04.txt This is the mature version of a document on which DIME has provided advice = in the past. Please have a quick look and see whether it makes sense in Dia= meter terms. If it is OK, I'm not sure what process the Chairs want to foll= ow: adopt as a DIME document, or pass it off to Softwires? Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt Date: Tue, 16 Sep 2014 18:21:42 -0700 From: internet-drafts@ietf.org To: M. Boucadair , "Qiong Sun"=20 , "Tom Taylor" , Cathy Zh= ou , Qiong Sun , T.=20 Taylor , "Cathy Zhou"=20 , "Mohamed Boucadair" A new version of I-D, draft-zhou-dime-4over6-provisioning-04.txt has been successfully submitted by T. Taylor and posted to the IETF reposit= ory. Name: draft-zhou-dime-4over6-provisioning Revision: 04 Title: Attribute-Value Pairs For Provisioning Customer Equipment=20 Supporting IPv4-Over-IPv6 Transitional Solutions Document date: 2014-09-16 Group: Individual Submission Pages: 17 URL:=20 http://www.ietf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-04.= txt Status:=20 https://datatracker.ietf.org/doc/draft-zhou-dime-4over6-provisioning/ Htmlized:=20 http://tools.ietf.org/html/draft-zhou-dime-4over6-provisioning-04 Diff:=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-zhou-dime-4over6-provisioning-04 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates 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 (RFC 6733) attribute-value pairs to be used for that purpose. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Sep 17 06:45:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17091A01CB for ; Wed, 17 Sep 2014 06:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMoRSeMUsPdy for ; Wed, 17 Sep 2014 06:45:47 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3F71A0102 for ; Wed, 17 Sep 2014 06:45:47 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id l13so155633iga.6 for ; Wed, 17 Sep 2014 06:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=E6UD9MlZAxMJNthWS8piZRgoaQYivd8Vz4sSFJqK4Yk=; b=tLAcTLHL0up5exLAeVQUxnEUroS9vUYJ8zxEyY6kK0EzkOTa8gct9ar0A1jYi1xZ/s NGyYnI9R9Vmr8XYjZWVRe6tLc7pSgojRSI3oDF+q0VXLkMbM7Tc+tReNin7SRcxf78FJ h255jGNV79vBAaqcqNFboA6R41ijCHt28guc9ra86+pAjkkQKeE0mjbZnFQHkcXBstfc CpTnp11E/Z8hQ7hErrK+0pMOcHXiyrEqROwwnty1SkIlqEGogUE8BRxv/9g6P4ZmxUOx XNYIh0SmiF9rgOFThZJ+EC/M2FT1OD+at+clI1dCxRhKeiKRjlUhaey0KNofEynN7BO2 BPtQ== X-Received: by 10.43.140.132 with SMTP id ja4mr5626095icc.4.1410961547194; Wed, 17 Sep 2014 06:45:47 -0700 (PDT) Received: from [192.168.97.21] ([67.210.160.130]) by mx.google.com with ESMTPSA id qo8sm4344578igb.7.2014.09.17.06.45.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Sep 2014 06:45:46 -0700 (PDT) Message-ID: <5419908A.2010508@gmail.com> Date: Wed, 17 Sep 2014 09:45:46 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> <5418E8F8.9010605@gmail.com> <6341_1410952345_54196C99_6341_4311_1_6B7134B31289DC4FAF731D844122B36E721810@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <6341_1410952345_54196C99_6341_4311_1_6B7134B31289DC4FAF731D844122B36E721810@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mDtOapVi4z9AH_Ka4HD-aSGUiEg Subject: Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Sep 2014 13:45:49 -0000 Thank you for your comments. I think my aversion to going with Grouped AVPs was concern over reusability of the AVPs, that I would have to create a new AVP for each Grouped one to make the semantics clear. But I guess if I can get away with using a generic AVP like the Framed-IPv6-Prefix AVP the semantics are set by its presence within the specific Grouped AVP. I'll rework the document and see what I get. I can't find Framed-IPv6-Prefix AVP in the IANA registry. So I guess that's my "common data format" redefined as an AVP. Tom Taylor On 17/09/2014 7:12 AM, lionel.morand@orange.com wrote: > Hi Tom, > > Coming back on the need for a new format ("Common prefix Data format"), could you please explain (or remind me) why this new AVP format would be simpler than creating a Grouped AVP as soon as Prefix or Address can be provisioned? > > For instance, based on the current draft, the Tunnel-Source-Pref-Or-Addr is defined as a single AVP using the new AVP format defined in this draft: > > 3.4. Tunnel-Source-Pref-Or-Addr AVP > > The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) conveys either > the IPv6 Binding Prefix or the tunnel source address on the CE, as > described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP uses > the common prefix data format. The AddressType field MUST be set to > 2 (IPv6). Valid values in the PrefixLength field are from 0 to 128 > (full address). > > This AVP is defined separately from the LW4over6-Binding AVP (which > includes it) to provide flexibility in the transport of the tunnel > source address from the provisioning system to AAA. > > But the same info could be also provided as follow: > > 3.4. Tunnel-Source-Pref-Or-Addr AVP > > The Tunnel-Source-Pref-Or-Addr (AVP Code TBD0X) is of type Grouped. > It MUST contains either an either the IPv6 Binding Prefix or the tunnel source > address on the CE, as described in Section 2.2. > > Tunnel-Source-Pref-Or-Addr ::= < AVP Header: TBD0X > > [ Tunnel-Source-Address ] > [ Tunnel-Source-Prefix ] > *[ AVP ] > > 3.X Tunnel-Source-Address AVP > > The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address > and specifies the tunnel source IPv6 address on the CE. > > 3.Y. Framed-IPv6-Prefix AVP > > The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString and > contains the IPv6 Binding Prefix on the CE. > > If there is no risk of clash, the existing Framed-IPv6-Prefix AVP could even be reused for the second one. > > This alternative would have the advantage not to define a new format. I'm not saying that the definition of any new format should be prohibited. But in this case, it seems weird to have to define a new format for combining different types of information that can be already carried in existing AVPs. > > About the link with Softwires, we need to ensure that the set of information defined in this document has reviewed and somehow endorsed by the WG. Then I think it will become a pure Dime discussion. > > Lionel > ... From nobody Wed Sep 17 07:11:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2E21A045C for ; Wed, 17 Sep 2014 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSVqO9enD4lg for ; Wed, 17 Sep 2014 07:11:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B32E1A0465 for ; Wed, 17 Sep 2014 07:11:51 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 23B4C3B423D; Wed, 17 Sep 2014 16:11:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id BDC6715809F; Wed, 17 Sep 2014 16:11:48 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 16:11:48 +0200 From: To: Tom Taylor , "dime@ietf.org" Thread-Topic: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt Thread-Index: AQHP0hnq2qfCS0mUN0+aJfg/GZ8d0ZwFEFrQgAAlSACAACTN8A== Date: Wed, 17 Sep 2014 14:11:48 +0000 Message-ID: <18610_1410963108_541996A4_18610_4429_11_6B7134B31289DC4FAF731D844122B36E721F79@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> <5418E8F8.9010605@gmail.com> <6341_1410952345_54196C99_6341_4311_1_6B7134B31289DC4FAF731D844122B36E721810@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5419908A.2010508@gmail.com> In-Reply-To: <5419908A.2010508@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.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.17.133020 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ls9UOeeRT1kO5l0nY-ixY_f6Z9I Subject: Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 17 Sep 2014 14:11:54 -0000 "I can't find Framed-IPv6-Prefix AVP in the IANA registry" It is because it is one of the reuse of RADIUS attributes and it is therefo= re part of AVP codes reserved for RADIUS attributes. You can look into the = table given in http://www.iana.org/assignments/radius-types/radius-types.xh= tml#radius-types-2=20 You can also refer to RFC 7155 when the AVP is defined. If you are considering reusing the Framed-IPv6-Prefix AVP, we may also cons= ider reusing the IP-Address AVP (Address type) defined in RFC 5777 to conve= y either an IPv4 or an IPv6. Again, this is only a proposal and others might have another opinion. I jus= t try to move forward this draft in the best and easiest direction. Regards, Lionel -----Message d'origine----- De=A0: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 Envoy=E9=A0: mercredi 17 septembre 2014 15:46 =C0=A0: MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4ove= r6-provisioning-04.txt Thank you for your comments. I think my aversion to going with Grouped AVPs= was concern over reusability of the AVPs, that I would have to create a ne= w AVP for each Grouped one to make the semantics clear. But I guess if I ca= n get away with using a generic AVP like the Framed-IPv6-Prefix AVP the sem= antics are set by its presence within the specific Grouped AVP. I'll rework= the document and see what I get. I can't find Framed-IPv6-Prefix AVP in the IANA registry. So I guess that's= my "common data format" redefined as an AVP. Tom Taylor On 17/09/2014 7:12 AM, lionel.morand@orange.com wrote: > Hi Tom, > > Coming back on the need for a new format ("Common prefix Data format"), c= ould you please explain (or remind me) why this new AVP format would be sim= pler than creating a Grouped AVP as soon as Prefix or Address can be provis= ioned? > > For instance, based on the current draft, the Tunnel-Source-Pref-Or-Addr = is defined as a single AVP using the new AVP format defined in this draft: > > 3.4. Tunnel-Source-Pref-Or-Addr AVP > > The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) conveys either > the IPv6 Binding Prefix or the tunnel source address on the CE, as > described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP uses > the common prefix data format. The AddressType field MUST be set to > 2 (IPv6). Valid values in the PrefixLength field are from 0 to 128 > (full address). > > This AVP is defined separately from the LW4over6-Binding AVP (which > includes it) to provide flexibility in the transport of the tunnel > source address from the provisioning system to AAA. > > But the same info could be also provided as follow: > > 3.4. Tunnel-Source-Pref-Or-Addr AVP > > The Tunnel-Source-Pref-Or-Addr (AVP Code TBD0X) is of type Grouped. > It MUST contains either an either the IPv6 Binding Prefix or the tunn= el source > address on the CE, as described in Section 2.2. > > Tunnel-Source-Pref-Or-Addr ::=3D < AVP Header: TBD0= X > > [ Tunnel-Source-Address ] > [ Tunnel-Source-Prefix ] > *[ AVP ] > > 3.X Tunnel-Source-Address AVP > > The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address > and specifies the tunnel source IPv6 address on the CE. > > 3.Y. Framed-IPv6-Prefix AVP > > The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString and > contains the IPv6 Binding Prefix on the CE. > > If there is no risk of clash, the existing Framed-IPv6-Prefix AVP could e= ven be reused for the second one. > > This alternative would have the advantage not to define a new format. I'm= not saying that the definition of any new format should be prohibited. But= in this case, it seems weird to have to define a new format for combining = different types of information that can be already carried in existing AVPs. > > About the link with Softwires, we need to ensure that the set of informat= ion defined in this document has reviewed and somehow endorsed by the WG. T= hen I think it will become a pure Dime discussion. > > Lionel > ... ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Sep 18 11:01:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502E71A8891; Thu, 18 Sep 2014 11:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr1WVIk2g_Uk; Thu, 18 Sep 2014 11:01:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA381A889E; Thu, 18 Sep 2014 11:01:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918180108.27131.60652.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 11:01:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/psBYvB53U5k_RnmEok8QZ-f2NJI Cc: dime@ietf.org Subject: [Dime] DIME WG Interim Meeting, October 17-17, 2014 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 18 Sep 2014 18:01:19 -0000 The IETF DIME WG will hold an Interim Meeting on October 16-17, 2014. The meeting will take place at: Orange Labs Sophia-Antipolis (close to ETSI premises) 905 Rue Albert Einstein 06560 VALBONNE, FRANCE Meeting Room: S905 ROYA. The agenda of the meeting is to work on the remaining open issues on the Diameter Overload Control indication Conveyance (DOIC) draft, in order to produce a final version for IETF Last-Call before the end of the year. A detailed agenda will be provided later on the DIME mailing list. If you'd like to attend, please register by sending an email to the DIME WG chairs (dime-chairs@tools.ietf.org). Here is a preliminary list of participants: - Jouni Korhonen - Lionel Morand - Steve Donovan - Ben Campbell - Maria Cruz Bartolome - Jean-Jacques Trottin - Susan Shishufeng - Ulrich Wiehe Regards, Lionel & Jouni From nobody Tue Sep 23 05:10:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FEF1A7113; Tue, 23 Sep 2014 05:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzJRe16KJoKa; Tue, 23 Sep 2014 05:10:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024B81A1A45; Tue, 23 Sep 2014 05:10:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923121017.31665.9175.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 05:10:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_i0liKF3fNAWjVuYxCTIohCOxwk Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-app-design-guide-28.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 12:10:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Authors : Lionel Morand Victor Fajardo Hannes Tschofenig Filename : draft-ietf-dime-app-design-guide-28.txt Pages : 27 Date : 2014-09-23 Abstract: The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-app-design-guide-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 23 09:09:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFDF1A8721; Tue, 23 Sep 2014 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RutbpkiFY0zn; Tue, 23 Sep 2014 09:09:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0921A872D; Tue, 23 Sep 2014 09:09:13 -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: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923160913.29850.24532.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 09:09:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OiG7xkH7a_4HOriwvsodvxAnRPc Cc: dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter Applications Design Guidelines' to Best Current Practice (draft-ietf-dime-app-design-guide-28.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 16:09:20 -0000 The IESG has approved the following document: - 'Diameter Applications Design Guidelines' (draft-ietf-dime-app-design-guide-28.txt) as Best Current Practice This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-app-design-guide/ Technical Summary The Diameter Base protocol provides an extensibility mechanism enabling a consistent way to define new Diameter applications, commands and attribute- value-pairs or modify existing ones. This document is a companion document to the Diameter Base protocol that further clarifies the rules to extend Diameter. This document is a guidelines document and therefore informative in nature. Working Group Summary The working group reached consensus on the document and the contents of the document was discussed in length. Document Quality The document is a guideline document as such. Several topics discusses in the document originate from specification and implementation experience done outside IETF, specifically in 3GPP, when implementing and deploying new Diameter applications. The document has received early reviews from the AAA-Doctors, OPS-DIR, SecDir and Gen-Art. The request for reviews was posted into dir-coord and aaa-doctors mailing lists. Received comments have been reflected. Since the document does not define any MIBs, media types and such. Therefore, there is no need for MIB Doctor or Media Type and such expert reviews. Personnel Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise (bclaise@cisco.com) is the responsible Area Director. From nobody Tue Sep 23 19:48:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDF21A19EA for ; Tue, 23 Sep 2014 19:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBTGyJvfBlcZ for ; Tue, 23 Sep 2014 19:48:49 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DAF1A047A for ; Tue, 23 Sep 2014 19:48:49 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id tp5so5384890ieb.41 for ; Tue, 23 Sep 2014 19:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EUDHd1SZoCZ+ZvhmfJHItadzJBXLD077PRN5kC+d/Ow=; b=0vxgaeOTUlkRYIla/t5mgHJzrm6s5+GdrBdlzW1n6XJWM1zIxTXew/yA5xWwnnIlsW GzSnLdD/WEV4bd+1CeSV8sV9761gPJFxXBNzykaWsjJ1TJmkvOQL5R648Em6X1TXwR37 T5NaM/oYhJuZeEz31JNJMKvfth9bdU6k+iAhd4i+6pCMJVTOMWBkmEiVZufHIG3Lforc rVfQx2e8Fwp+7p6LJoHRVG438w1hb0Y3oU8T13Bw38iJlaHCIR7bXZTVl+rs6IWygD56 +ZiTYh2Etd3JHmZWN/rmhWAGXNKmlMqyJcPDWmQC6E1xsd/eKXLxtkIQn9ee7A/x5nMI 10zQ== X-Received: by 10.42.23.16 with SMTP id q16mr7909606icb.0.1411526928952; Tue, 23 Sep 2014 19:48:48 -0700 (PDT) Received: from [192.168.97.184] ([67.210.160.130]) by mx.google.com with ESMTPSA id jj6sm3245284igb.15.2014.09.23.19.48.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 19:48:48 -0700 (PDT) Message-ID: <5422310A.5010503@gmail.com> Date: Tue, 23 Sep 2014 22:48:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <20140917012142.28396.19843.idtracker@ietfa.amsl.com> <5418E8F8.9010605@gmail.com> <6341_1410952345_54196C99_6341_4311_1_6B7134B31289DC4FAF731D844122B36E721810@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5419908A.2010508@gmail.com> <18610_1410963108_541996A4_18610_4429_11_6B7134B31289DC4FAF731D844122B36E721F79@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <18610_1410963108_541996A4_18610_4429_11_6B7134B31289DC4FAF731D844122B36E721F79@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IWu7bhxA3RRqdj7NDtNfl1-gPN8 Cc: draft-zhou-dime-4over6-provisioning.authors@tools.ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 24 Sep 2014 02:48:51 -0000 OK, I've used Delegated-IPv6-Prefix (RFC 4818) in version -05 where the semantics seemed to fit, and otherwise defined Grouped AVPs based on RFC 5777 IP-Address. Submitted as draft-zhou-dime-4over6-provisioning-05. Thanks for your comments. Tom On 17/09/2014 10:11 AM, lionel.morand@orange.com wrote: > "I can't find Framed-IPv6-Prefix AVP in the IANA registry" > > It is because it is one of the reuse of RADIUS attributes and it istom.taylor.stds@gmail. > therefore part of AVP codes reserved for RADIUS attributes. You can > look into the table given in > http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2 > > You can also refer to RFC 7155 when the AVP is defined. > > If you are considering reusing the Framed-IPv6-Prefix AVP, we may > also consider reusing the IP-Address AVP (Address type) defined in > RFC 5777 to convey either an IPv4 or an IPv6. > > Again, this is only a proposal and others might have another opinion. > I just try to move forward this draft in the best and easiest > direction. > > Regards, > > Lionel > > > -----Message d'origine----- De : Tom Taylor > [mailto:tom.taylor.stds@gmail.com] Envoyé : mercredi 17 septembre > 2014 15:46 À : MORAND Lionel IMT/OLN; dime@ietf.org Objet : Re: > [Dime] Fwd: New Version Notification for > draft-zhou-dime-4over6-provisioning-04.txt > > Thank you for your comments. I think my aversion to going with > Grouped AVPs was concern over reusability of the AVPs, that I would > have to create a new AVP for each Grouped one to make the semantics > clear. But I guess if I can get away with using a generic AVP like > the Framed-IPv6-Prefix AVP the semantics are set by its presence > within the specific Grouped AVP. I'll rework the document and see > what I get. > > I can't find Framed-IPv6-Prefix AVP in the IANA registry. So I guess > that's my "common data format" redefined as an AVP. > > Tom Taylor > > On 17/09/2014 7:12 AM, lionel.morand@orange.com wrote: >> Hi Tom, >> >> Coming back on the need for a new format ("Common prefix Data >> format"), could you please explain (or remind me) why this new AVP >> format would be simpler than creating a Grouped AVP as soon as >> Prefix or Address can be provisioned? >> >> For instance, based on the current draft, the >> Tunnel-Source-Pref-Or-Addr is defined as a single AVP using the new >> AVP format defined in this draft: >> >> 3.4. Tunnel-Source-Pref-Or-Addr AVP >> >> The Tunnel-Source-Pref-Or-Addr AVP (AVP Code TBD02) conveys either >> the IPv6 Binding Prefix or the tunnel source address on the CE, as >> described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP uses >> the common prefix data format. The AddressType field MUST be set >> to 2 (IPv6). Valid values in the PrefixLength field are from 0 to >> 128 (full address). >> >> This AVP is defined separately from the LW4over6-Binding AVP >> (which includes it) to provide flexibility in the transport of the >> tunnel source address from the provisioning system to AAA. >> >> But the same info could be also provided as follow: >> >> 3.4. Tunnel-Source-Pref-Or-Addr AVP >> >> The Tunnel-Source-Pref-Or-Addr (AVP Code TBD0X) is of type >> Grouped. It MUST contains either an either the IPv6 Binding Prefix >> or the tunnel source address on the CE, as described in Section >> 2.2. >> >> Tunnel-Source-Pref-Or-Addr ::= < AVP Header: TBD0X > [ >> Tunnel-Source-Address ] [ Tunnel-Source-Prefix ] *[ AVP ] >> >> 3.X Tunnel-Source-Address AVP >> >> The Tunnel-Source-Address AVP (AVP Code xxx) is of type Address and >> specifies the tunnel source IPv6 address on the CE. >> >> 3.Y. Framed-IPv6-Prefix AVP >> >> The Tunnel-Source-Prefix AVP (AVP Code yyy) is of type OctetString >> and contains the IPv6 Binding Prefix on the CE. >> >> If there is no risk of clash, the existing Framed-IPv6-Prefix AVP >> could even be reused for the second one. >> >> This alternative would have the advantage not to define a new >> format. I'm not saying that the definition of any new format should >> be prohibited. But in this case, it seems weird to have to define a >> new format for combining different types of information that can be >> already carried in existing AVPs. >> >> About the link with Softwires, we need to ensure that the set of >> information defined in this document has reviewed and somehow >> endorsed by the WG. Then I think it will become a pure Dime >> discussion. >> >> Lionel >> > ... > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. If you have > received this email in error, please notify the sender and delete > this message and its attachments. As emails may be altered, Orange is > not liable for messages that have been modified, changed or > falsified. Thank you. > > From nobody Thu Sep 25 09:01:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4351A0193 for ; Thu, 25 Sep 2014 09:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_6XTzJzMqXw for ; Thu, 25 Sep 2014 09:01:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E381A014E for ; Thu, 25 Sep 2014 09:01:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-ee-54243c63fed1 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.50.02247.36C34245; Thu, 25 Sep 2014 18:01:39 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 18:01:38 +0200 From: Maria Cruz Bartolome To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4CAALBYAIAA2puggABHyYCAAVSmwIAFD/sAgA/fwpA= Date: Thu, 25 Sep 2014 16:01:38 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920983BCEB@ESESSMB101.ericsson.se> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> <54170666.3050900@usdonovans.com> In-Reply-To: <54170666.3050900@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW6yjUqIwbKtihZze1ewWWxo4rFY 93YFkwOzx5IlP5k8fq6/yu6x6m0fawBzFJdNSmpOZllqkb5dAlfGmb6TjAUbuhgr7lybzNjA +Cuvi5GTQ0LAROLqkT3MELaYxIV769m6GLk4hASOMkp8/TePEcJZzCgxbcZKJpAqNgE7iUun XzCBJEQEOhklNq49wQqSEBbwlpiz6D47iC0i4COxfNkCRgi7TOLx39NgzSwCqhKb9y4Fi/MK +Er8nL8aat1KVomV7ycA3cHBwSmgJ/FvFhtIDSPQSd9PrQHrZRYQl7j1ZD4TxKkCEkv2nIc6 W1Ti5eN/rBC2ksSK7ZcYIep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpm IWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwfg5u+W21g/Hgc8dDjAIcjEo8vArl yiFCrIllxZW5hxilOViUxHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFRV5y/zEYz YIPJ95uXZXn29t5/z2jxOtOh414Hd+Xnhm0cQRe/8+48KsuTpXL25oqSTNUgwwlHBSbo9++8 o/LTg7n0lfkbVrXQedN39im65uX3HHbiq2l7k7xVNU171bv8t7P7Wc/JzNQVEzY0MM0WOnWw z+3ef/3Hz55eXKy077BVsO0sXkslluKMREMt5qLiRADGNDzFgAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zPrqgF5IN2DtJ6ZSfaZZ1ORwj6I Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 25 Sep 2014 16:01:46 -0000 Dear Ulrich, Steve, JJ, I think Ulrich summarized this discussion very clearly and even proposed a = way forward as a compromise. I agree with his argumentations and with the p= roposal. I only do not understand issue 2 (Host type OLRs received by the client may= easily get out of synch), I would appreciate some clarification. But I think we need to focus on issues 3 and 4: >> 3. There is no added value as the client either has no need for the host= -type OLR (i.e. never sends host-type requests to the server) or will recei= ve it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain = OCSs that are never used. Steve, you mentioned your proposal focusses on 3 and 4, could you explain i= t further? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 15 de septiembre de 2014 17:32 To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Ulrich, A few more comments inline. Steve On 9/12/14, 4:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > please see inline. > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Thursday, September 11, 2014 3:54 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Examp= le > > All, > > It seems the concern is forcing the client to save OCS state for host > reports from servers to which the client never sends host routed > requests. This, I think, is only an issue for requests that do not > contain a destination-host AVP. Please correct me if I'm mistaken. > > > I listed 4 issues (see below). You address only half of issue 4. > The other half is forcing the client to save OCS state for realm reports > from agents (realms) to which the client never sends realm routed request= s. > > > I think we all agree that the server has no way to differentiate host > routed requests from realm routed requests in this case, so the solution > cannot be server based. > > That leaves two options: > > 1) The agent that does the server selection strips the host report for > these types of transactions. > > 2) The client ignores host reports for these types of transactions. > > > I agree that these are the options when the request was realm-routed. > When the request was host routed the options are > > 1') The agent does not insert a realm report to an answer forwarded > from server to client > > 2') The agent inserts a realm report and the client ignores it. SRD> There are scenarios where realm reports cannot be used.=20 Partitioning of the server space is the primary example. As such, we=20 need to make sure we aren't designing a solution that depends on realm=20 reports. That's not saying that realm reports don't have value, just=20 that they can't always be used. > > At least we should allow option 1 (and 1'); or are there any issues > with this option? Whether or not to allow option 2 (and 2') needs to be > discussed, as there are issues. > SRD> I disagree with allowing 1. The only time that an agent should=20 strip a host report is when it knows it is the reacting node host-routed=20 requests. > > Option 2 seems better to me, as it is the client that understands > whether or not the host reports have value. > > > host reports in answers that correspond to realm-routed requests > never have added value. Similarly, realm reports in answer messages that > correspond to host-routed requestsnever have added value. See issue 3 bel= ow. > SRD> How is it not good for a client to know about the fact that a=20 server is overloaded? How is it not good for a client to know that a=20 realm is overloaded? There is clear value for both cases, as the sooner=20 a client learns about overload of a server or realm to which it sends=20 requests the sooner the overload condition will be abated. SRD> There might be times when an OLR isn't useful to a client/reacting=20 node. I disagree with the assertion that there is never added value. > > For some applications the > client might never send requests with a destination-host AVP. In this > case the client can safely ignore the OLRs. For applications where > there is a mix of transaction types (host-routed and realm-routed), the > client might choose to save all OLRs in the interest of better handling > the overload for the requests that do include the destination-host AVP. > > > What do you mean with "better handling"? > SRD> I mean that the sooner a reacting node learns about an overload=20 condition the sooner the overload condition can be properly handled. > > Note that in this type of application, it will still work if the client > ignores all host reports received on "realm-routed" transactions as the > client will still receive a host report on host-routed transactions. > This assumes that all answer messages have the OLR for the duration of > the overload event. > > I suggest wording something like: > > A client MAY ignore OLRs of type host received in transactions where the > request was realm-routed by the client. > > > ok, but also: > "A client MAY ignore OLRs of type realm received in transactions where th= e > request was host-routed by the client." > (And maybe replace "client" with "reacting node") > SRD> Yes, it should say reacting node. > > Note: In applications where there is a mix of realm-routed and > host-routed requests it is recommended that the client save all host > overload reports. > > > I would like to see all issues solved before recommending so. > SRD> I don't understand issues 1 and 2. I think my proposal addresses=20 issues 3 and 4. > Regards, > > Steve > > On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Ben, >> >> you worte: >> My main point was that the server has no knowledge that the request migh= t have been realm-routed prior to the agent's peer selection. >> >> I think there in no need for the server to have this knowledge. The serv= er simply puts its host-type OLR in the answer. >> The agent that handled server selection receives this OLR and makes use = of it for >> a) diverting future realm routed request to other servers and >> b) calculating an aggregated realm overload (taking into account the sup= ported algorithm at the client). >> This aggregated realm-type OLR is sent to the client. >> Open question is whether in addition also the host-type OLR generated by= the server is sent to the client. Issues identified so far are: >> 1. Two OLRs in one answer must use the same algorithm resulting in the n= eed for some kind of OLR conversion from one algorithm to another. >> 2. Host type OLRs received by the client may easily get out of synch. >> 3. There is no added value as the client either has no need for the host= -type OLR (i.e. never sends host-type requests to the server) or will recei= ve it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain = OCSs that are never used. >> >> Similar to this is another point recently questiond by JJ: >> Whether an agent may insert a realm-type OLR to an answer which correspo= nds to a host-routed request, and which potentially already contains a host= -type OLR. (This would only be possible if the agent supports the algorithm= that was negotiated/selected between client and server). >> Again I think that there is no added value as the client either has no n= eed for the realm-type OLR (i.e. never sends realm-type requests to the rea= lm) or will receive it with the response to the next sent realm-type reques= t. And again there may be negative impacts for clients. >> >> As a way forward we may think about a way to convey both OLRs in one ans= wer but clearly indicate which OLR is the "real thing" and which is the add= itional one. It must however be made clear that the additional one can save= ly be ignored by the reacting node. >> >> Ulrich >> >> >> >> =20 >> =20 >> >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 10:35 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exam= ple >> >> >> On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Ben, >>> >>> please see comments inline. >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: ext Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Wednesday, September 10, 2014 4:38 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@eric= sson.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org >>> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exa= mple >>> >>> We had exactly that example in the draft discussed in Toronto ( draft-d= onovan-doic-agent-cases ). >>> >>> Comments inline: >>> >>> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> >>>> Dear JJacques, >>>> >>>> assume the following example: >>>> In step 1 (realm routed request sent from Client to Agent), the client= indicates that it supports loss. >>>> In step 2 (host routed request send from agent to S1), the agent indic= ates that it supports loss and rate. >>>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 in= dicates that it selected rate. >>>> >>>> Now in step 4 there is no point in forwarding the host-type OLR from a= gent to client as the client does not support rate. Similar for step 8 wher= e no host type OLR of rate shall be sent in addition to the realm-type OLR = of loss. >>> I agree there is no point forwarding the OLR per se. However, the agent= may still indicate that it supports "loss" back to the client, and send lo= ss-based reports if the client sends too much traffic for the agent to comp= ly with the max rate without throttling. >>> I think the agent shall indicate that it supports "loss" back = to the client. >> I wouldn't put it as strongly as "shall", but I think there are circumst= ances where it makes sense to do so. (see next comment). There may also be = circumstances where it decides to handle OC control locally, in which case = it may chose not to send any OC-O-F at all back to the client. >> >>> In addition, are you proposing that the agent may translate the rate ba= sed host-type OLR received from S1 into a loss based host type OLR and forw= ard it to the client? >> Not quite. I would use the term "gateway" rather than "translate". >> >> I think it highly unlikely one can translate any given rate-based OLR in= to a loss-based OLR in a useful way. But, I do think that the agent may cho= ose to locally enforce the rate limit, and send lost-based OLRs back to the= client in an attempt to reduce the number of requests that the agent might= have to throttle. >> >> For example, if the agent can achieve the rate limit at the current load= offered by the client without throttling, it need send no OLRs to the clie= nt at all. In this case, the client doesn't need to know about the overload= condition. But if the agent has to throttle, it might (maybe should) deleg= ate the required throttling back to the client as much as it can. The loss = algorithm is sort of clumsy for that purpose, but it would still be better = than nothing. >> >> >>>> Also note that the answer in step 8 can contain only one Supported-Fea= tures AVP i.e. can only contain one selected algorithm. Even when the agent= supports loss and realm, you cannot say in one answer "use loss for realm = routed requests and rate for host routed requests" >>> One approach is where you end up with is "loss" is supported between th= e client and agent, and "rate" is supported between the agent and server. >>> >>> Don't get me wrong, I'm not saying that's a _required_ approach, but it= should be allowed. >>> I'm ok with "loss" for realm type OLRs sent from agent to clie= nt and "rate" for host type OLRs sent from Server to agent in this scenario= (steps 8 and 7). >>> However, if we allow an agent to translate a received host type OLR of = "rate" into a sent host type OLR of "loss" we may end up in situations wher= e the client receices out of sync OLRs from different agents on different p= aths between client and server. >> That's a good point. If your load is reasonably balanced across agents, = it might not matter. If it _does_ matter, then something like an agent-over= load report (as in Steve's draft) from the agent to the client might work b= etter. >> >> I think we are going to need a better understanding of the rate algorith= m to really specify how this should work. I just want to make sure we don't= make choices now that prevent us from solving that later. >> >>>> Furthermore the client may never send host routed requests to S1. (And= if it does, it will learn the host type OLR and selected algorithm in the = corresponding answer). >>>> >>> I don't follow this. Do you mean "might never"? (I read "may never" as = "is never allowed to"). >>> yes sorry I meant "might never" >>> >>> The agent has to ensure that any OLRs that get back to the client match= the capabilities the client advertised, and received. It could do that by = stripping all OC-S-F and OLR avps in answers >>> I agree >>> , or it could act as as an algorithm "gateway" and (statefully) transla= te between the capabilities selected on either side. >>> this sounds complex to me and is absolutely unnecessary >> I didn't say it had to, I said it could. I think it's a reasonable imple= mentation choice that we should not forbid, but probably also should not re= quire. >> >>>> I'm aware that there may be cases where agent and server select the sa= me algorithm and the problem described above disappears, but even then we s= hould not mandate including the host-type OLR in the answer that correspond= s to a realm type request. >>> I don't see that following. >>> I did not say "shall forbid" but "should not mandate" >> I think others were arguing for "shall forbid". >> >>> We should prevent a server from putting any host reports into answers t= o realm routed requests. Otherwise, you have use cases that just want work. >>> how can a server receive a realm routed request? I can understa= nd that a server may receive a request that does not contain a Destination-= Host AVP, but that's not the definition of realm-routed request >> That's actually the point I was trying to make. If a node is a pure serv= er, then by our current definition it never ever receives a realm-routed re= quest. So a prohibition against having it put host-reports in responses to = realm-routed requests is both non-constraining and non-sensical. >> >> Now, if a previous hop Agent handled server selection, then it's up to t= hat agent whether to pass through an existing host-report, if the original = request had been realm-routed from _its_ perspective. We should neither re= quire or forbid that. (And I actually don't think that's specific to realm= -routed requests. It's true for all request and report types.) >> >> But if we allow the agent to pass through a host-report, then the client= must be prepared to receive it. >> >> >>> For example, consider how a server could report any overload at all for= an application that is exclusively realm-routed. >>> >>> Also, consider that with the recently discussed distinction between rea= lm-routed requests and host-routed requests, we consider a request to be ho= st-routed if it has a Destination-Host _or_ if a node has other knowledge t= hat the request will go to specific server (e.g., if the peer-selection dec= ision would send a request to the specific host. ) In the second case, the = server itself cannot distinguish a host-routed request from a host-routed r= equest. >>> I don't follow this. Do you mean "from a realm-routed request"= ? >> Yes. >> >>> My interpretation of the definition is that a server will never receive= a realm-routed request as the previous direct peer always has the knowledg= e that the request will go to that server. >> Agreed, so by the time the request gets to the server, it's host routed-= -even if it may have been previously realm-routed. I think we are proving t= he routing type to be at least somewhat hop-by-hop. >> >> My main point was that the server has no knowledge that the request migh= t have been realm-routed prior to the agent's peer selection. >> >> _______________________________________________ >> 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 nobody Thu Sep 25 09:27:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DFF1A010C for ; Thu, 25 Sep 2014 09:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_8aT1AxCCSP for ; Thu, 25 Sep 2014 09:27:36 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AD21A0077 for ; Thu, 25 Sep 2014 09:27:35 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-76-542442759c7e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.AD.21432.57244245; Thu, 25 Sep 2014 18:27:34 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Thu, 25 Sep 2014 18:27:33 +0200 From: Maria Cruz Bartolome To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUA== Date: Thu, 25 Sep 2014 16:27:32 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> 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.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW6Zk0qIwab5HBZze1ewWSw/3sBs sen8OhYHZo/WZ3tZPZYs+cnk8eXyZ7YA5igum5TUnMyy1CJ9uwSujFUff7EUrJGs2HSxj6mB 8Y1wFyMnh4SAicTJKa/ZIGwxiQv31oPZQgJHGSVu9sd0MXIB2YsZJbpmPWQFSbAJ2ElcOv2C CSQhInCMUaJ54ksmkISwQJbEh76t7CC2iEC2xK3W5YwQtpPE0tkrwWwWAVWJqTduMIPYvAK+ Erc3NzJBbNjLKHGmZxXYBk6BWIktDyaBFTECnfT91BqwBcwC4hK3nsxngjhVQGLJnvPMELao xMvH/1ghbCWJFdsvMULU60ncmDqFDcLWlli28DXUYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKy gJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg/Bzc8ttgB+PL546HGAU4GJV4eBXKlUOE WBPLiitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj1AOVte8SO9m1 ZQwXrf7IpRfXHaPjtkx6/3fL5ydXZyz4ueyLz7dnm9Z+jWJ6ceJW/dSN7vUmvfdOzX3g9aHl 898Dr+XzbzKlBtklRRiqSpj+yS7q361d+tfD+MoZ8xPP+T4/6rB6Jdu6qk9XOuLicqfZMSkr vp60P+QnOkWH85xguYTwE/3DSizFGYmGWsxFxYkAaHwEIIACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/T_K2Vf5xk90ubxFQlddu5YPmo-Y Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 25 Sep 2014 16:27:39 -0000 Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Sep 25 23:57:44 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085E21A1A6B for ; Thu, 25 Sep 2014 23:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WviYWeNxOiI5 for ; Thu, 25 Sep 2014 23:57:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803751A1A5A for ; Thu, 25 Sep 2014 23:57:33 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8Q6vUKp013508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Sep 2014 06:57:30 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8Q6vTbf007617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 08:57:29 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 08:57:29 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 08:57:29 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4CAALBYAIAA2puggABHyYCAAVSmwIAFD/sAgA/fwpCAAPDc0A== Date: Fri, 26 Sep 2014 06:57:28 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520B6A4@DEMUMBX014.nsn-intra.net> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> <54170666.3050900@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BCEB@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920983BCEB@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19573 X-purgate-ID: 151667::1411714650-0000437E-0B8DC24D/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lCe7ByvGlXBom1o8NJYHg0TZjIs Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 06:57:42 -0000 Dear Maria Cruz, thank you for your support. With regard to issue 2 I was thinking of e.g.the following configuration: +---+ +---+ | |------------------------------------------| | | C | +---+ | S |=20 | |------------| A |-------------------------| | +---+ +---+ +---+ | =20 C supports loss A supports loss and rate S supports loss and rate 1. for a host routed request from C to S (that possibly does not transit A = (and if so, A would be transparent with regard to OC-AVPs)), S would send a= host type OLR for loss to C. 2. for a realm routed request sent from C to A where A then selects S, S wo= uld send a host type OLR of rate to A and A would send a realm type OLR of = loss to C. I hope this is not contentious so far. The open question is whether the answer send from A to C which contains the= realm type OLR of loss must also contain a host type OLR. It seems clear t= hat A cannot just transparently forward the received host type OLR of rate = to C as C does not support rate. It has then been proposed that A would som= ehow calculate a host type OLR of loss on behalf of S and insert it into th= e anser sent from A to C.=20 This means that C in step 1 receives a host type OLR of loss from S and in = step 2 C receives a host type OLR of loss from S (actually from A on behalf= of S, but C cannot know), and these two OLRs cannot easily be in sync. =20 Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Thursday, September 25, 2014 6:02 PM To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear Ulrich, Steve, JJ, I think Ulrich summarized this discussion very clearly and even proposed a = way forward as a compromise. I agree with his argumentations and with the p= roposal. I only do not understand issue 2 (Host type OLRs received by the client may= easily get out of synch), I would appreciate some clarification. But I think we need to focus on issues 3 and 4: >> 3. There is no added value as the client either has no need for the host= -type OLR (i.e. never sends host-type requests to the server) or will recei= ve it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain = OCSs that are never used. Steve, you mentioned your proposal focusses on 3 and 4, could you explain i= t further? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 15 de septiembre de 2014 17:32 To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Ulrich, A few more comments inline. Steve On 9/12/14, 4:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > please see inline. > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Thursday, September 11, 2014 3:54 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Examp= le > > All, > > It seems the concern is forcing the client to save OCS state for host > reports from servers to which the client never sends host routed > requests. This, I think, is only an issue for requests that do not > contain a destination-host AVP. Please correct me if I'm mistaken. > > > I listed 4 issues (see below). You address only half of issue 4. > The other half is forcing the client to save OCS state for realm reports > from agents (realms) to which the client never sends realm routed request= s. > > > I think we all agree that the server has no way to differentiate host > routed requests from realm routed requests in this case, so the solution > cannot be server based. > > That leaves two options: > > 1) The agent that does the server selection strips the host report for > these types of transactions. > > 2) The client ignores host reports for these types of transactions. > > > I agree that these are the options when the request was realm-routed. > When the request was host routed the options are > > 1') The agent does not insert a realm report to an answer forwarded > from server to client > > 2') The agent inserts a realm report and the client ignores it. SRD> There are scenarios where realm reports cannot be used.=20 Partitioning of the server space is the primary example. As such, we=20 need to make sure we aren't designing a solution that depends on realm=20 reports. That's not saying that realm reports don't have value, just=20 that they can't always be used. > > At least we should allow option 1 (and 1'); or are there any issues > with this option? Whether or not to allow option 2 (and 2') needs to be > discussed, as there are issues. > SRD> I disagree with allowing 1. The only time that an agent should=20 strip a host report is when it knows it is the reacting node host-routed=20 requests. > > Option 2 seems better to me, as it is the client that understands > whether or not the host reports have value. > > > host reports in answers that correspond to realm-routed requests > never have added value. Similarly, realm reports in answer messages that > correspond to host-routed requestsnever have added value. See issue 3 bel= ow. > SRD> How is it not good for a client to know about the fact that a=20 server is overloaded? How is it not good for a client to know that a=20 realm is overloaded? There is clear value for both cases, as the sooner=20 a client learns about overload of a server or realm to which it sends=20 requests the sooner the overload condition will be abated. SRD> There might be times when an OLR isn't useful to a client/reacting=20 node. I disagree with the assertion that there is never added value. > > For some applications the > client might never send requests with a destination-host AVP. In this > case the client can safely ignore the OLRs. For applications where > there is a mix of transaction types (host-routed and realm-routed), the > client might choose to save all OLRs in the interest of better handling > the overload for the requests that do include the destination-host AVP. > > > What do you mean with "better handling"? > SRD> I mean that the sooner a reacting node learns about an overload=20 condition the sooner the overload condition can be properly handled. > > Note that in this type of application, it will still work if the client > ignores all host reports received on "realm-routed" transactions as the > client will still receive a host report on host-routed transactions. > This assumes that all answer messages have the OLR for the duration of > the overload event. > > I suggest wording something like: > > A client MAY ignore OLRs of type host received in transactions where the > request was realm-routed by the client. > > > ok, but also: > "A client MAY ignore OLRs of type realm received in transactions where th= e > request was host-routed by the client." > (And maybe replace "client" with "reacting node") > SRD> Yes, it should say reacting node. > > Note: In applications where there is a mix of realm-routed and > host-routed requests it is recommended that the client save all host > overload reports. > > > I would like to see all issues solved before recommending so. > SRD> I don't understand issues 1 and 2. I think my proposal addresses=20 issues 3 and 4. > Regards, > > Steve > > On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Ben, >> >> you worte: >> My main point was that the server has no knowledge that the request migh= t have been realm-routed prior to the agent's peer selection. >> >> I think there in no need for the server to have this knowledge. The serv= er simply puts its host-type OLR in the answer. >> The agent that handled server selection receives this OLR and makes use = of it for >> a) diverting future realm routed request to other servers and >> b) calculating an aggregated realm overload (taking into account the sup= ported algorithm at the client). >> This aggregated realm-type OLR is sent to the client. >> Open question is whether in addition also the host-type OLR generated by= the server is sent to the client. Issues identified so far are: >> 1. Two OLRs in one answer must use the same algorithm resulting in the n= eed for some kind of OLR conversion from one algorithm to another. >> 2. Host type OLRs received by the client may easily get out of synch. >> 3. There is no added value as the client either has no need for the host= -type OLR (i.e. never sends host-type requests to the server) or will recei= ve it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain = OCSs that are never used. >> >> Similar to this is another point recently questiond by JJ: >> Whether an agent may insert a realm-type OLR to an answer which correspo= nds to a host-routed request, and which potentially already contains a host= -type OLR. (This would only be possible if the agent supports the algorithm= that was negotiated/selected between client and server). >> Again I think that there is no added value as the client either has no n= eed for the realm-type OLR (i.e. never sends realm-type requests to the rea= lm) or will receive it with the response to the next sent realm-type reques= t. And again there may be negative impacts for clients. >> >> As a way forward we may think about a way to convey both OLRs in one ans= wer but clearly indicate which OLR is the "real thing" and which is the add= itional one. It must however be made clear that the additional one can save= ly be ignored by the reacting node. >> >> Ulrich >> >> >> >> =20 >> =20 >> >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 10:35 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exam= ple >> >> >> On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Ben, >>> >>> please see comments inline. >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: ext Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Wednesday, September 10, 2014 4:38 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); maria.cruz.bartolome@eric= sson.com; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org >>> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Exa= mple >>> >>> We had exactly that example in the draft discussed in Toronto ( draft-d= onovan-doic-agent-cases ). >>> >>> Comments inline: >>> >>> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> >>>> Dear JJacques, >>>> >>>> assume the following example: >>>> In step 1 (realm routed request sent from Client to Agent), the client= indicates that it supports loss. >>>> In step 2 (host routed request send from agent to S1), the agent indic= ates that it supports loss and rate. >>>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 in= dicates that it selected rate. >>>> >>>> Now in step 4 there is no point in forwarding the host-type OLR from a= gent to client as the client does not support rate. Similar for step 8 wher= e no host type OLR of rate shall be sent in addition to the realm-type OLR = of loss. >>> I agree there is no point forwarding the OLR per se. However, the agent= may still indicate that it supports "loss" back to the client, and send lo= ss-based reports if the client sends too much traffic for the agent to comp= ly with the max rate without throttling. >>> I think the agent shall indicate that it supports "loss" back = to the client. >> I wouldn't put it as strongly as "shall", but I think there are circumst= ances where it makes sense to do so. (see next comment). There may also be = circumstances where it decides to handle OC control locally, in which case = it may chose not to send any OC-O-F at all back to the client. >> >>> In addition, are you proposing that the agent may translate the rate ba= sed host-type OLR received from S1 into a loss based host type OLR and forw= ard it to the client? >> Not quite. I would use the term "gateway" rather than "translate". >> >> I think it highly unlikely one can translate any given rate-based OLR in= to a loss-based OLR in a useful way. But, I do think that the agent may cho= ose to locally enforce the rate limit, and send lost-based OLRs back to the= client in an attempt to reduce the number of requests that the agent might= have to throttle. >> >> For example, if the agent can achieve the rate limit at the current load= offered by the client without throttling, it need send no OLRs to the clie= nt at all. In this case, the client doesn't need to know about the overload= condition. But if the agent has to throttle, it might (maybe should) deleg= ate the required throttling back to the client as much as it can. The loss = algorithm is sort of clumsy for that purpose, but it would still be better = than nothing. >> >> >>>> Also note that the answer in step 8 can contain only one Supported-Fea= tures AVP i.e. can only contain one selected algorithm. Even when the agent= supports loss and realm, you cannot say in one answer "use loss for realm = routed requests and rate for host routed requests" >>> One approach is where you end up with is "loss" is supported between th= e client and agent, and "rate" is supported between the agent and server. >>> >>> Don't get me wrong, I'm not saying that's a _required_ approach, but it= should be allowed. >>> I'm ok with "loss" for realm type OLRs sent from agent to clie= nt and "rate" for host type OLRs sent from Server to agent in this scenario= (steps 8 and 7). >>> However, if we allow an agent to translate a received host type OLR of = "rate" into a sent host type OLR of "loss" we may end up in situations wher= e the client receices out of sync OLRs from different agents on different p= aths between client and server. >> That's a good point. If your load is reasonably balanced across agents, = it might not matter. If it _does_ matter, then something like an agent-over= load report (as in Steve's draft) from the agent to the client might work b= etter. >> >> I think we are going to need a better understanding of the rate algorith= m to really specify how this should work. I just want to make sure we don't= make choices now that prevent us from solving that later. >> >>>> Furthermore the client may never send host routed requests to S1. (And= if it does, it will learn the host type OLR and selected algorithm in the = corresponding answer). >>>> >>> I don't follow this. Do you mean "might never"? (I read "may never" as = "is never allowed to"). >>> yes sorry I meant "might never" >>> >>> The agent has to ensure that any OLRs that get back to the client match= the capabilities the client advertised, and received. It could do that by = stripping all OC-S-F and OLR avps in answers >>> I agree >>> , or it could act as as an algorithm "gateway" and (statefully) transla= te between the capabilities selected on either side. >>> this sounds complex to me and is absolutely unnecessary >> I didn't say it had to, I said it could. I think it's a reasonable imple= mentation choice that we should not forbid, but probably also should not re= quire. >> >>>> I'm aware that there may be cases where agent and server select the sa= me algorithm and the problem described above disappears, but even then we s= hould not mandate including the host-type OLR in the answer that correspond= s to a realm type request. >>> I don't see that following. >>> I did not say "shall forbid" but "should not mandate" >> I think others were arguing for "shall forbid". >> >>> We should prevent a server from putting any host reports into answers t= o realm routed requests. Otherwise, you have use cases that just want work. >>> how can a server receive a realm routed request? I can understa= nd that a server may receive a request that does not contain a Destination-= Host AVP, but that's not the definition of realm-routed request >> That's actually the point I was trying to make. If a node is a pure serv= er, then by our current definition it never ever receives a realm-routed re= quest. So a prohibition against having it put host-reports in responses to = realm-routed requests is both non-constraining and non-sensical. >> >> Now, if a previous hop Agent handled server selection, then it's up to t= hat agent whether to pass through an existing host-report, if the original = request had been realm-routed from _its_ perspective. We should neither re= quire or forbid that. (And I actually don't think that's specific to realm= -routed requests. It's true for all request and report types.) >> >> But if we allow the agent to pass through a host-report, then the client= must be prepared to receive it. >> >> >>> For example, consider how a server could report any overload at all for= an application that is exclusively realm-routed. >>> >>> Also, consider that with the recently discussed distinction between rea= lm-routed requests and host-routed requests, we consider a request to be ho= st-routed if it has a Destination-Host _or_ if a node has other knowledge t= hat the request will go to specific server (e.g., if the peer-selection dec= ision would send a request to the specific host. ) In the second case, the = server itself cannot distinguish a host-routed request from a host-routed r= equest. >>> I don't follow this. Do you mean "from a realm-routed request"= ? >> Yes. >> >>> My interpretation of the definition is that a server will never receive= a realm-routed request as the previous direct peer always has the knowledg= e that the request will go to that server. >> Agreed, so by the time the request gets to the server, it's host routed-= -even if it may have been previously realm-routed. I think we are proving t= he routing type to be at least somewhat hop-by-hop. >> >> My main point was that the server has no knowledge that the request migh= t have been realm-routed prior to the agent's peer selection. >> >> _______________________________________________ >> 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 nobody Fri Sep 26 01:00:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34E31A01CB for ; Fri, 26 Sep 2014 01:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD19qQ2h7oQE for ; Fri, 26 Sep 2014 01:00:23 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C611A1A8E for ; Fri, 26 Sep 2014 01:00:17 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-33-54251d0f6c03 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.76.02247.F0D15245; Fri, 26 Sep 2014 10:00:15 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 10:00:14 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Thread-Index: AQHPyN37GIptMc1Hek2MmXu5dUbbdpv3TT4wgAEpiACAACgSgIAA7juAgAB8o4CAALBYAIAA2puggABHyYCAAVSmwIAFD/sAgA/fwpCAAPDc0IAAG42g Date: Fri, 26 Sep 2014 08:00:14 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920983BEAD@ESESSMB101.ericsson.se> References: <075.932a395897d769fbc9cf22116adcb797@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D90006681520A0BF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A2B6@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A52D@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681520A65E@DEMUMBX014.nsn-intra.net> <5411A97F.2020007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520A7EF@DEMUMBX014.nsn-intra.net> <54170666.3050900@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BCEB@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B6A4@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520B6A4@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvjS6/rGqIwfsrIhZze1ewWWxo4rFY 93YFkwOzx5IlP5k8fq6/yu6x6m0fawBzFJdNSmpOZllqkb5dAlfGxUWfmQruzGes+NV9hqmB cUF9FyMnh4SAicSvniuMELaYxIV769m6GLk4hASOMkocenWaFcJZzChx//t9JpAqNgE7iUun XzCBJEQEOhklfpxuYQVJCAt4S8xZdJ8dxBYR8JFYvmwBI0RRE6PE4Z5WsCIWAVWJFY1/2UBs XgFfiVXb2qBWbGaTWDbrKNghnAIBEtMadoBNYgQ66vupNWCrmQXEJW49mc8EcayAxJI955kh bFGJl4//sULYShIrtl9ihKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZ haRlASPLKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAGDq45bfVDsaDzx0PMQpwMCrx8C44 oRIixJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYFy1ZrpOV kHHmpM5WUx2V4jxn7dW6+1Q7j5lHRMsm+xemfvTpFD4UJZR9omNXDLP7tQULbS6eMv7oLzDH e2pVG1ex0FtnqYVOG6Pyjsw8MdFbyyKn9/y/x0af463vZk3iPMB0v3virIxX35MqZ9dZbOU/ 6PXRozBR9t7uT+EVoibnLqrFF91WYinOSDTUYi4qTgQArz1464ICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DcY0heXMaaWSt38ayX2_ttsOZS8 Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 08:00:29 -0000 Dear Ulrich, Therefore, issue 2 is a consequence of 1. In case there is not a need for c= onversion, I presume this out of synch situation is avoided. Thanks for the explanation. Cheers /MCruz 1. Two OLRs in one answer must use the same algorithm resulting in the need= for some kind of OLR conversion from one algorithm to another. 2. Host type OLRs received by the client may easily get out of synch. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 8:57 To: Maria Cruz Bartolome; Steve Donovan; dime@ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear Maria Cruz, thank you for your support. With regard to issue 2 I was thinking of e.g.the following configuration: +---+ +---+ | |------------------------------------------| | | C | +---+ | S |=20 | |------------| A |-------------------------| | +---+ +---+ +---+ | =20 C supports loss A supports loss and rate S supports loss and rate 1. for a host routed request from C to S (that possibly does not transit A = (and if so, A would be transparent with regard to OC-AVPs)), S would send a= host type OLR for loss to C. 2. for a realm routed request sent from C to A where A then selects S, S wo= uld send a host type OLR of rate to A and A would send a realm type OLR of = loss to C. I hope this is not contentious so far. The open question is whether the answer send from A to C which contains the= realm type OLR of loss must also contain a host type OLR. It seems clear t= hat A cannot just transparently forward the received host type OLR of rate = to C as C does not support rate. It has then been proposed that A would som= ehow calculate a host type OLR of loss on behalf of S and insert it into th= e anser sent from A to C.=20 This means that C in step 1 receives a host type OLR of loss from S and in = step 2 C receives a host type OLR of loss from S (actually from A on behalf= of S, but C cannot know), and these two OLRs cannot easily be in sync. =20 Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Sent: Thursday, September 25, 2014 6:02 PM To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: RE: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Dear Ulrich, Steve, JJ, I think Ulrich summarized this discussion very clearly and even proposed a = way forward as a compromise. I agree with his argumentations and with the p= roposal. I only do not understand issue 2 (Host type OLRs received by the client may= easily get out of synch), I would appreciate some clarification. But I think we need to focus on issues 3 and 4: >> 3. There is no added value as the client either has no need for the host= -type OLR (i.e. never sends host-type requests to the server) or will recei= ve it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain = OCSs that are never used. Steve, you mentioned your proposal focusses on 3 and 4, could you explain i= t further? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 15 de septiembre de 2014 17:32 To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B - Example Ulrich, A few more comments inline. Steve On 9/12/14, 4:53 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > please see inline. > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 > Donovan > Sent: Thursday, September 11, 2014 3:54 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B -=20 > Example > > All, > > It seems the concern is forcing the client to save OCS state for host=20 > reports from servers to which the client never sends host routed=20 > requests. This, I think, is only an issue for requests that do not=20 > contain a destination-host AVP. Please correct me if I'm mistaken. > > > I listed 4 issues (see below). You address only half of issue 4. > The other half is forcing the client to save OCS state for realm=20 > reports from agents (realms) to which the client never sends realm routed= requests. > > > I think we all agree that the server has no way to differentiate host=20 > routed requests from realm routed requests in this case, so the=20 > solution cannot be server based. > > That leaves two options: > > 1) The agent that does the server selection strips the host report for=20 > these types of transactions. > > 2) The client ignores host reports for these types of transactions. > > > I agree that these are the options when the request was realm-routed. > When the request was host routed the options are > > 1') The agent does not insert a realm report to an answer forwarded=20 > from server to client > > 2') The agent inserts a realm report and the client ignores it. SRD> There are scenarios where realm reports cannot be used.=20 Partitioning of the server space is the primary example. As such, we need = to make sure we aren't designing a solution that depends on realm reports. = That's not saying that realm reports don't have value, just that they can'= t always be used. > > At least we should allow option 1 (and 1'); or are there any issues=20 > with this option? Whether or not to allow option 2 (and 2') needs to=20 > be discussed, as there are issues. > SRD> I disagree with allowing 1. The only time that an agent should strip a host report is when it knows it is the reacting node host-routed re= quests. > > Option 2 seems better to me, as it is the client that understands=20 > whether or not the host reports have value. > > > host reports in answers that correspond to realm-routed requests never=20 > have added value. Similarly, realm reports in answer messages that=20 > correspond to host-routed requestsnever have added value. See issue 3 bel= ow. > SRD> How is it not good for a client to know about the fact that a server is overloaded? How is it not good for a client to know that a realm= is overloaded? There is clear value for both cases, as the sooner a clien= t learns about overload of a server or realm to which it sends requests the= sooner the overload condition will be abated. SRD> There might be times when an OLR isn't useful to a client/reacting node. I disagree with the assertion that there is never added value. > > For some applications the > client might never send requests with a destination-host AVP. In this=20 > case the client can safely ignore the OLRs. For applications where=20 > there is a mix of transaction types (host-routed and realm-routed),=20 > the client might choose to save all OLRs in the interest of better=20 > handling the overload for the requests that do include the destination-ho= st AVP. > > > What do you mean with "better handling"? > SRD> I mean that the sooner a reacting node learns about an overload condition the sooner the overload condition can be properly handled. > > Note that in this type of application, it will still work if the=20 > client ignores all host reports received on "realm-routed"=20 > transactions as the client will still receive a host report on host-route= d transactions. > This assumes that all answer messages have the OLR for the duration of=20 > the overload event. > > I suggest wording something like: > > A client MAY ignore OLRs of type host received in transactions where=20 > the request was realm-routed by the client. > > > ok, but also: > "A client MAY ignore OLRs of type realm received in transactions where=20 > the request was host-routed by the client." > (And maybe replace "client" with "reacting node") SRD> Yes, it should say reacting node. > > Note: In applications where there is a mix of realm-routed and=20 > host-routed requests it is recommended that the client save all host=20 > overload reports. > > > I would like to see all issues solved before recommending so. > SRD> I don't understand issues 1 and 2. I think my proposal addresses issues 3 and 4. > Regards, > > Steve > > On 9/11/14, 4:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Ben, >> >> you worte: >> My main point was that the server has no knowledge that the request migh= t have been realm-routed prior to the agent's peer selection. >> >> I think there in no need for the server to have this knowledge. The serv= er simply puts its host-type OLR in the answer. >> The agent that handled server selection receives this OLR and makes=20 >> use of it for >> a) diverting future realm routed request to other servers and >> b) calculating an aggregated realm overload (taking into account the sup= ported algorithm at the client). >> This aggregated realm-type OLR is sent to the client. >> Open question is whether in addition also the host-type OLR generated by= the server is sent to the client. Issues identified so far are: >> 1. Two OLRs in one answer must use the same algorithm resulting in the n= eed for some kind of OLR conversion from one algorithm to another. >> 2. Host type OLRs received by the client may easily get out of synch. >> 3. There is no added value as the client either has no need for the host= -type OLR (i.e. never sends host-type requests to the server) or will recei= ve it with the response to the next sent host-type request. >> 4. There may be negative impact for clients that are forced to maintain = OCSs that are never used. >> >> Similar to this is another point recently questiond by JJ: >> Whether an agent may insert a realm-type OLR to an answer which correspo= nds to a host-routed request, and which potentially already contains a host= -type OLR. (This would only be possible if the agent supports the algorithm= that was negotiated/selected between client and server). >> Again I think that there is no added value as the client either has no n= eed for the realm-type OLR (i.e. never sends realm-type requests to the rea= lm) or will receive it with the response to the next sent realm-type reques= t. And again there may be negative impacts for clients. >> >> As a way forward we may think about a way to convey both OLRs in one ans= wer but clearly indicate which OLR is the "real thing" and which is the add= itional one. It must however be made clear that the additional one can save= ly be ignored by the reacting node. >> >> Ulrich >> >> >> >> =20 >> =20 >> >> >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, September 10, 2014 10:35 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org >> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B -=20 >> Example >> >> >> On Sep 10, 2014, at 9:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> >>> Ben, >>> >>> please see comments inline. >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: ext Ben Campbell [mailto:ben@nostrum.com] >>> Sent: Wednesday, September 10, 2014 4:38 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES);=20 >>> maria.cruz.bartolome@ericsson.com; dime@ietf.org;=20 >>> draft-ietf-dime-ovli@tools.ietf.org >>> Subject: Re: [Dime] [dime] #70 (draft-ietf-dime-ovli): Appendix B -=20 >>> Example >>> >>> We had exactly that example in the draft discussed in Toronto ( draft-d= onovan-doic-agent-cases ). >>> >>> Comments inline: >>> >>> On Sep 9, 2014, at 5:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> >>>> Dear JJacques, >>>> >>>> assume the following example: >>>> In step 1 (realm routed request sent from Client to Agent), the client= indicates that it supports loss. >>>> In step 2 (host routed request send from agent to S1), the agent indic= ates that it supports loss and rate. >>>> In step 3 (answer from S1 to agent, containing a host type OLR), S1 in= dicates that it selected rate. >>>> >>>> Now in step 4 there is no point in forwarding the host-type OLR from a= gent to client as the client does not support rate. Similar for step 8 wher= e no host type OLR of rate shall be sent in addition to the realm-type OLR = of loss. >>> I agree there is no point forwarding the OLR per se. However, the agent= may still indicate that it supports "loss" back to the client, and send lo= ss-based reports if the client sends too much traffic for the agent to comp= ly with the max rate without throttling. >>> I think the agent shall indicate that it supports "loss" back = to the client. >> I wouldn't put it as strongly as "shall", but I think there are circumst= ances where it makes sense to do so. (see next comment). There may also be = circumstances where it decides to handle OC control locally, in which case = it may chose not to send any OC-O-F at all back to the client. >> >>> In addition, are you proposing that the agent may translate the rate=20 >>> based host-type OLR received from S1 into a loss based host type OLR=20 >>> and forward it to the client? >> Not quite. I would use the term "gateway" rather than "translate". >> >> I think it highly unlikely one can translate any given rate-based OLR in= to a loss-based OLR in a useful way. But, I do think that the agent may cho= ose to locally enforce the rate limit, and send lost-based OLRs back to the= client in an attempt to reduce the number of requests that the agent might= have to throttle. >> >> For example, if the agent can achieve the rate limit at the current load= offered by the client without throttling, it need send no OLRs to the clie= nt at all. In this case, the client doesn't need to know about the overload= condition. But if the agent has to throttle, it might (maybe should) deleg= ate the required throttling back to the client as much as it can. The loss = algorithm is sort of clumsy for that purpose, but it would still be better = than nothing. >> >> >>>> Also note that the answer in step 8 can contain only one Supported-Fea= tures AVP i.e. can only contain one selected algorithm. Even when the agent= supports loss and realm, you cannot say in one answer "use loss for realm = routed requests and rate for host routed requests" >>> One approach is where you end up with is "loss" is supported between th= e client and agent, and "rate" is supported between the agent and server. >>> >>> Don't get me wrong, I'm not saying that's a _required_ approach, but it= should be allowed. >>> I'm ok with "loss" for realm type OLRs sent from agent to clie= nt and "rate" for host type OLRs sent from Server to agent in this scenario= (steps 8 and 7). >>> However, if we allow an agent to translate a received host type OLR=20 >>> of "rate" into a sent host type OLR of "loss" we may end up in=20 >>> situations where the client receices out of sync OLRs from different=20 >>> agents on different paths between client and server. >> That's a good point. If your load is reasonably balanced across agents, = it might not matter. If it _does_ matter, then something like an agent-over= load report (as in Steve's draft) from the agent to the client might work b= etter. >> >> I think we are going to need a better understanding of the rate algorith= m to really specify how this should work. I just want to make sure we don't= make choices now that prevent us from solving that later. >> >>>> Furthermore the client may never send host routed requests to S1. (And= if it does, it will learn the host type OLR and selected algorithm in the = corresponding answer). >>>> >>> I don't follow this. Do you mean "might never"? (I read "may never" as = "is never allowed to"). >>> yes sorry I meant "might never" >>> >>> The agent has to ensure that any OLRs that get back to the client=20 >>> match the capabilities the client advertised, and received. It could=20 >>> do that by stripping all OC-S-F and OLR avps in answers I agree= , or it could act as as an algorithm "gateway" and (statefully) t= ranslate between the capabilities selected on either side. >>> this sounds complex to me and is absolutely=20 >>> unnecessary >> I didn't say it had to, I said it could. I think it's a reasonable imple= mentation choice that we should not forbid, but probably also should not re= quire. >> >>>> I'm aware that there may be cases where agent and server select the sa= me algorithm and the problem described above disappears, but even then we s= hould not mandate including the host-type OLR in the answer that correspond= s to a realm type request. >>> I don't see that following. >>> I did not say "shall forbid" but "should not mandate"=20 >>> >> I think others were arguing for "shall forbid". >> >>> We should prevent a server from putting any host reports into answers t= o realm routed requests. Otherwise, you have use cases that just want work. >>> how can a server receive a realm routed request? I can=20 >>> understand that a server may receive a request that does not contain=20 >>> a Destination-Host AVP, but that's not the definition of=20 >>> realm-routed request >> That's actually the point I was trying to make. If a node is a pure serv= er, then by our current definition it never ever receives a realm-routed re= quest. So a prohibition against having it put host-reports in responses to = realm-routed requests is both non-constraining and non-sensical. >> >> Now, if a previous hop Agent handled server selection, then it's up=20 >> to that agent whether to pass through an existing host-report, if the=20 >> original request had been realm-routed from _its_ perspective. We=20 >> should neither require or forbid that. (And I actually don't think=20 >> that's specific to realm-routed requests. It's true for all request=20 >> and report types.) >> >> But if we allow the agent to pass through a host-report, then the client= must be prepared to receive it. >> >> >>> For example, consider how a server could report any overload at all for= an application that is exclusively realm-routed. >>> >>> Also, consider that with the recently discussed distinction between rea= lm-routed requests and host-routed requests, we consider a request to be ho= st-routed if it has a Destination-Host _or_ if a node has other knowledge t= hat the request will go to specific server (e.g., if the peer-selection dec= ision would send a request to the specific host. ) In the second case, the = server itself cannot distinguish a host-routed request from a host-routed r= equest. >>> I don't follow this. Do you mean "from a realm-routed request"= ? >> Yes. >> >>> My interpretation of the definition is that a server will never=20 >>> receive a realm-routed request as the previous direct peer always=20 >>> has the knowledge that the request will go to that server. >> Agreed, so by the time the request gets to the server, it's host routed-= -even if it may have been previously realm-routed. I think we are proving t= he routing type to be at least somewhat hop-by-hop. >> >> My main point was that the server has no knowledge that the request migh= t have been realm-routed prior to the agent's peer selection. >> >> _______________________________________________ >> 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 nobody Fri Sep 26 01:12:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7CE1A1A8C for ; Fri, 26 Sep 2014 01:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMH7RGD27XbB for ; Fri, 26 Sep 2014 01:11:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881CD1A1A9B for ; Fri, 26 Sep 2014 01:11:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B4EE0B688F016; Fri, 26 Sep 2014 08:11:37 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s8Q8BdFZ004995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 10:11:39 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 10:11:39 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: Maria Cruz Bartolome , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7Xjg Date: Fri, 26 Sep 2014 08:11:38 +0000 Message-ID: References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920983BD00@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 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nS5_NstUK2TdYUIEMIltmnaAwbo Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 08:11:47 -0000 Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer identity associated with the connection used to send the request does not match the value of the Origin-Host AVP of a received message that contained a Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 26 02:58:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70DC1A1ABB for ; Fri, 26 Sep 2014 02:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtdoOuum2ZgJ for ; Fri, 26 Sep 2014 02:58:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF8D1A1ABF for ; Fri, 26 Sep 2014 02:58:08 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-17-542538af2945 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.D4.21432.FA835245; Fri, 26 Sep 2014 11:58:07 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 11:58:06 +0200 From: Maria Cruz Bartolome To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8A= Date: Fri, 26 Sep 2014 09:58:05 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/mixed; boundary="_002_087A34937E64E74E848732CFF8354B920983BF65ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM+Jvje56C9UQgwMPhC3m9q5gs1h+vIHZ YtP5dSwOzB6tz/ayeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGdO2HWQq2PSJsWLbmpvM DYzTHzN2MXJySAiYSHzpWsAKYYtJXLi3ng3EFhI4yiixb61VFyMXkL2YUeLCpXawIjYBO4lL p18wgSREBI4xSjRPfMkEkhAWyJL40LeVHcQWEciWuNW6nBHC9pNY+HUqC4jNIqAqcWnjbmYQ m1fAV+La7Z+MEBuuMElc2LINrJlTIFai8fJGsKGMQCd9P7UGzGYWEJe49WQ+E8SpIhIPL55m g7BFJV4+/gf1gpLEiu2XGCHqMyWWr25kh1gmKHFy5hOWCYwis5CMmoWkbBaSMoi4nsSNqVPY IGxtiWULXzND2HUS91rPMkLYxhInNj4FquECsvcwSqzddQqqSFFiSvdD9gWMnKsYRYtTi5Ny 042M9FKLMpOLi/Pz9PJSSzYxAqP04JbfBjsYXz53PMQowMGoxMO74IRKiBBrYllxZe4hRmkO FiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOxia1J4PenYpI2J3d/5akv+rU7c qf63trL05tnrElvElb5uLAxmjGLK+x/2VM2vrviExplz/12fbZm2qLxy55H/3yvO3ljWlv/z sNApxWcZ4fodU9v8hPatm/K14sf06tV8p/gvbGU3Xq63/ULsd7viDcubU7f95bfaU2mnHv1t fUtm1coNd38qsRRnJBpqMRcVJwIArAE+3rMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GPHOXwxiE6x7MnEpkj1tr0bNtuA Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 09:58:13 -0000 --_002_087A34937E64E74E848732CFF8354B920983BF65ESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_002_087A34937E64E74E848732CFF8354B920983BF65ESESSMB101erics_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="OC-Report-Type clause 6-6.docx" Content-Description: OC-Report-Type clause 6-6.docx Content-Disposition: attachment; filename="OC-Report-Type clause 6-6.docx"; size=17659; creation-date="Fri, 26 Sep 2014 08:56:48 GMT"; modification-date="Fri, 26 Sep 2014 09:55:58 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQB8O5c5IgEAALkDAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTTU+EMBCG7yb+B9K7FFZdjdmyFzXZq67x3C1T aISWdMYP/r0VswrKogcuTWaavs/TSbtav9VV9AIejbOCpXHCIrDK5cYWgj1sb08uWYQkbS4rZ0Gw FpCts+Oj1R1UksIhLE2DUUixKFhJ1FxxjqqEWmLsGrBhRztfSwqlL3gj1ZMsgC+SZMl9P4Nlg8xo kwvmN/kpi7ZtE8h/ZzutjYJrp55rsDSC4AhE4WYYMqUvgATbd+Lgyfi4wuKAQm2Ud+g0xcrV/JP+ Qb0YXowjtRXgo6HyRmtQ1Mf/3JrySA94jIz5H6PoyL1BdPUUfjknnsILgW96V/JuTacczud00M7S Vu6qnsdXa0ribE6JV9jd/3qVveZehA8+XPYOAAD//wMAUEsDBBQABgAIAAAAIQAa1p+5shIAAJ6b AAARAAAAd29yZC9kb2N1bWVudC54bWzcXdtu48gRfQ+QfyD0kl1gbJO6WXbWWszYs7sDZDGGx8lD XgKaoi3CFMmQlL3ep/xGfi9fkuoLyW6yKVVJFG1vEOzMiFKzuy6nTld3V//w42+r0Hry0yyIo4uB c2wPLD/y4kUQPVwM/n7709FsYGW5Gy3cMI78i8GLnw1+nP/5Tz88ny9ib73yo9yCJqLs/DnxLgbL PE/OT04yb+mv3Ox4FXhpnMX3+bEXr07i+/vA80+e43RxMrQdm/8tSWPPzzJ436UbPbnZQDa3arYW J34E77qP05WbZ8dx+nCyctPHdXIErSduHtwFYZC/QNv2tGgmvhis0+hcduio7BD7ybnokPyj+EXa GIXhveKXV1IC/I0nqR9CH+IoWwZJNYxdW4MhLosuPW0axNMqLL73nDjjxvvKIWN0cJW6z6CKqsFG cwZhLMSPVqGQA9NvpdV6i469aTBSI6yJsg+YLujvLHqycoOobGY30ajCBY/Yx75/TuN1UnYnCfZr 7Uv0WLbFHJPQM3vKPU8dWkZqoOG635Zu4g+slXf+5SGKU/cuhB49O2OLWeRgDmBxFy9e2J+J9XwO YLO4uRjY9tmn0/HMGRQfXfn37jrMm0+ulY94I9cp/+Nb/hL68OsnN7wYXIeg7Vv/t3xwMv/hBN4k vsS/mc+nx1P2Yc4fiV+ncXz/OU3h9/lLAv19SN3Vt9xNeQPQS/aKfH5sWV8vMT/9HC3Ym8sfHt34 SZzmR7fQuPXxH9daG6x/fAjF2JURFh8dQByv9NpCJgzaz7PE9UDaSepnfvrkD+aWZd0ufZByXWLW dyA2C4KRb91+upp8bwWZxVRlxffW5whiT+rm/gIUBD9/C9LdOkytk2ABOAsE617r42v5ac0CW6QN wstB3Ey0Cz/z0uDOz6xazxZ+CFYYLMAqmXe663wZQ1z89TJd/84+WIDgLwYQw8dH9tnRcHrrOOf2 7Ny2/zngHiBN+MoHv7Tt0aXjTC/5E2iYuai5a89LN+c9kd8qfBWsFj5hDQdRJvvFUWPXfnHwUXrV 0h8mpqvAXfm5nwIryoFbWLH8W1AXGnQSeqf4P/t1DMwqjN2FlXIsAFuOPD+Nspq4q2EN8eI+a4gb OSwrj7X3N3r+h/eo+zgMY8ZzNDns5VXcSTPLTX0riII8cMPwBfzrPoj8xbn2mlfCYONrpQ9Id73p MOIAFor4W9n2iGrbIo7zdljv1XhuBhCIJJqoWzTaDPK2ZX3E/BKHsMs4y6XHgyvV2q3kMabKQ4VW rK9rby88nWgLupXQyZjBFibosTtDjnNGW6hkCfM9bJhScJMJtAX7wZTgf19yK1gw5L9neJ+z+MRg HajK17/d8BBaIHo7qFadPEV3Ug5aiSYNDIFmBc1lX9JYta4u1an1J1yR8iPeyFZWbVAkpAeQgscp 8ozaXiWjVkywjnQnLNxA4xMEooO0ILciDxwRSktaWHcviB7hKY5jV1yAySOfcytNg4cgOvqFoRFj e6nv+cGTv4AAxa24pDZulD0Dw6lZNpDtIPLC9QIo9oFQZF/jc/B0yRljYMTBxyhnVJP5JvOzFFvQ ZFlMGeap74Yr46OWdnVrUvRtbGR+Q22/N4uxR8Pp50vm9jwvoHAQ/QmHK/nRznAF2Qg0XuEshhDJ RIM4wNLxAU1k3Jr2jVNMHIsp4aHWpMyLuEkSBh5PeBq/gDbbj1VDR1+u2NyeGXPxdq3tAriN/EW3 FjXs6U+6sSM84UAiD4Ec4O3Isn7x3YWfalIsMKdFQ8bvAj71EDx0RW1R4d7Bg0BdBNYbOKjREnWa pQ5Df9IJk3bwjMkWxAU7DD07K3M57SrSv77H2CDXAxjNkk9DPClzJu3xXWmQwKlEgxytZWzSRcCe QMssnTW/VXM9OcTynC+MZct4HS4sBpUvMEEABvbvtZ/lPP1T/JS5G0Aq/Bc+aWH0umj1bhjipv71 bjRBYFo4TRCYFkETLZjGJ3Owbmg9LwNvaUFypogzZSqI5eYWkLiB9TuexcnTtc8nXbsrSvX8fXXC gIbNz4yAozf+KvZB4FU4+yDwqo7s43MAxENMg67AS4OIk5tq/gQTooQtWsCKt5xBSX+2YHncCt6l WxNoDE5tBBrTkdp45tWC5XLYc8ByNL4lPpFE8mttFgwfS7DlyF2DX47CRfTBEwRboWR6sFBYigQS M0SxfmP7hY/4MiriglhB8TZ0442iz6hrnjA6DE8wq54HJ2sFm2DcBx8MGJKMEItyWM2GXM0GZai2 OsLH515tdXSYMD+vMrB/ZUtyzHsamB28Q5416jqOjvqPo1GctwXKu7VIoJcInfgQcUUqK3/ZYOtv FXi6jp+j/uOnm2WxF7CdFNYzMCDuS4A/ke8xMmytM3gAcxfgPfAn+FlBemTEfYdKw8d13KxydJiA vCladEhzxvjg2WvoGB8mBleZLDXivj8rHuMjPs6Kx4cJ1ZusmExzxvjw2K+tHibKKjSHL8Htnop4 jZzAuIvg+EYD/5gcpw1ZV5XAj8lBCTWp2+R9t/Wpssqg+XohXzau5TqUifY7BE1ypN6itgk+eFLm 4pvUVnJnxgFkdqPSlsx6FHN5bVr5/vQ1IXOAbfoiR8293awKclxh5dahd4joEzJFMKjjjSL6BE8t cHxqchhOsAkaGoheW1uvb/wRi8NyKeQdokMXBEMNwhNyVN8bHWqzaT7D1hC+pkLD9oj3xQonZKJj wBBNaeSYvrfSNL+p9tWpE0olhdsp7Pe2pvjpbPTT8JNpW5a+2rjH8nK1M3ZKoFHT9oV+sTWpFSEZ wtEPgDmd7g2HvQHhCkyGHQ2rbw43RsZ2PehPuB7kR8zA5Xb5pP2MHOw7qG/RnxL41gY9KIol8C3R IHdO9p/uNmYT9k7rMlWdTX/SjbQJdAonbQKHwUv7yFK3rwoDbt19Ws1EyilInXV0ud1Y18qh9UVg dDh9EQgMSV+7Id0hNo+yvU9ym2h1lIJvgGdhcTu5KfEawLH9yEO/ZkBgiTgzIFAivBkUez8rfvJm HFEyiN3DFIHytWrAGG11biOzpu3WpX99DyoEHF7uOjklUKHTdiqkNEiI6aJBHoL1bSxSBOxJMd1g k83yfGtPex771QSBu+A0QYj3BE208l3YWNL7nsdXcRkC7WlV1FuFAwLnaB2bOl0+JXCOjoyQIYW6 tlCeSIMdle6dYUNlN6nRfsGCQApa9fRWbZDAT1rHptkgIX53aINaXk01yGrScuDFrl5NctY1kxCl elBFNxyM2kI3y29gW5Gf+otr2Pv4CeaWj5DtKznGpsimKbP/ZbB+Ndk1E5n1z0QOuwzWrzr+wHxj 1jXfmL0O39DgoZZmqM+DtXR+J8tg/ZpjF9RDDc8zcrxHzRg3oflbWAbrV2lkCrRlGeyMHO33Vprm N1WaqY9lsNeYZp6REykGlb1Rin/WNcM4659hfIbjm3H6l8yCAwj+OSsKyIpxZVC+NoDznm5ksdKl 8EG2hsSVKIHCC3TxQ5+wCeL9If9ZF0RERf4zcvTfG0TE3EssiEI6AA4ZPC99WBtgZ3XhJJQsnMfK PoImxXnqO9/K1glbQZWlaYqUJNPgTmepe4X+MzIjMuCIpjUyAdhba6VzAa2HBE62ltWxlNJnZnXx Yp0pL2f5zrRGJkXbtEZmAHtrDcBwEWTeGsptAwDC/5vOxz85uonX4FtQj5XXK5BOmL3DtJxjk2nR FrU5NpkG7K03lkB172CxRVSUFAGLr6yyE8+xUGOL0hicvkd/c+yuKYlj989Jag4GhETWBGVqYxrk dUFYPQo5A5I4ynfZs82A74+UOHbXrMSx+6clKdun9QEKPSx8YI2sBmRRMSThNSA8/4NYu/CATKZa yYH9VHZzDYWW66XRX2O647BLFLC1HVFpf8fun6gYlAEcUS5uI2TNsLsgKuqSQbGGRY6J7QWU9Cd7 bCaott85NoG1tBb4MM5ZR9PJTJRLrJft08k0H4ccGhPmTvsSHRtPlkaiGKYxjCuSccjEgIdx9p+W nYksSgNswLHp6EEv3wcC5HuXtIKjDoFHKKXVN3QgYpXymcE3Nk3pLyYH1m0jz5YsgiHejA/AQ2XI hbfyWvLC7LgU5j7L8sLJdcSbyTFp25gxwyWELWW4GzTMtnOAhS0LtlDOleFzVnYBkhwIWRBwXdlu pmpB8ecWZ2jfGYToICFM4OQGGQPEawlYqchFmCLjcohX4GHMwY0s8BcfEGMjVNLDeJ45lS83Bb8w /CuSONtlMsTjoIR27pqqOcpYtMFx3AhTcXmIR8bdpVSGiK+X3zCaw2MmRjxztudG7MmFS3qAw2aw R4zdhpARdslDUavp+Mp0NkRnBd3E/iEeu0e4mr1DPDCrMt1gX5gK40M87o7gOpXiLhWBL1CJHuqb eY/61SFGYjHEwydydFYgi/KSyuIhXB+PuFKzTdcXpiiExMl4g/wQ6atu3B2ZMB73peq30VdCyTNV dEJOR9aXjQrdrjlCgbSRUiidBtpFFSkKMrXOSg6BTISqa6PW2ZXGzQn10lS5crWagzKvLodQKAFk 6+BkfnENEtElzINc623L73A1zAVkMviC8pwySaO1bgRQQs20kbidhMPSBiUoRTOqVJHWEb5w1Tq1 hOsD6tALm1hwpGaEDzuTZklOfs/M5cfp5SdxgVcL3WfrPkf8bjZtVGbxEuJTXbxQEecbBeXbiYr2 hKO8BH6mxt2SFCNCOBPsfivKE+KGorsNlsjhYGfX5GvkZYDdyzWFS6AmL4QKZSPkrKlgUwWz0ay2 8MX5x+rwGruaYOu+sVIyhd2bqYdmeuqZRQP12NsoCWXUkOyZUHkMqQ5RAbWmA+PVFc2ru+S6CebH uJhhxGpYiakfVtTeWChcC+aEimoj5U4hlSTNriZwS+qAO/ScZX/yJUzgAAQRb8dH9LGCHW1vNwd5 TO5hjJ9tjZvbxnkAUsVg7giE+Cz+wMtnIESDD4m7i6aaZSNm+YR6YmMl90RTFiVIE+qRYUTE4jZC L/hwt7ulsC1h1fH17Z0ilPhCSeLN0hdCsS1kpJjg82mNSarZzbfNXHVXKwO5OGWm6bp8Rpld9hq5 CdW2JCZso5OEGldj3CRP0smg5FOajI1RkVAXa1yn/2ajAOzXXluqlkXt8iCAVmoa8p4bqx7D7gxY M2itffyd63lwRT1LdMM3gwguCI7csLy0yoKb3vkqYM5uQs++L24n0HppFg4hMil5lU2EH/FS/IQM qZFK8Ii342dNY9yQoUbWPhPmCT4K9TNhJlRHakgIF3gJdX8wMc7sphiuOMVHjN0ZAIkrTvHrL7uL hsQVpwRi3wtXnBIIPmKmgTRZAlLuPKugcsUpAUmVTEUbjZ8TuKKcIhVNKddo6k94qkuZT+2W6poS QLv11jltsjzFo646A9oU+Rg5qaW6qqC7Lb2gbBUilGQZK1oVk/agw5wZ2+JByJud4lfWx0r+Qfa7 pHQAlyyeqxlosa2VXRHbPDC/PeKf4kF+0rjZ2EO0T4DsxrjlJVLGt4D1JEw62nXbunup6Tz9STeO d0oAf5zjnRLQuy4tc6AX6bySeBtFqfk+oSZJ0yD0qmWVg6sOTIBl5BARg8JDZHNQirMh3kSATtzw 4OQHK1O5/dWEGhONQZqNB72uRahGsTtNh8064WrjwtZdHD+u3PSRZ6Yh+rJ7S50ZR7jIXfkXg3/9 HH9yvccBTM6fz4tvQypa+S5/pNgroTxDQ6o49jQjwwjrvaiv+nZZCaF4wUTkN7ZlTAjVC2SLlZzM 9i0zJpprtSykNRc7uiQTJZGokjcy0h9m2UuPhoeOkzM85GNNgYDnhOSZDrJoS3i1ZS91EQrOx1TL Lm1z2BI2OJbW7F4iikBYtiFSS84favqz96LqjBBxyXeHt22t1JLP3exLIxSNGG044qOELkKRhJGS nGCo2bK1RBzr/99//lsc7NdMyMj3CNUM5LC2oTZfds3hqm9W1z2D5aNUXDWL6At+MoIUCKSu16uE X87HLwuFXGcATANy0BY/fh1HcKoQprdP0E04hO2nTwEcUoM8dRzBwXnIWYf8nEq4OhbbAMHllCbh X/wkgef5CU9fY9J2hEIEDYHPK9nK8/1B5IVrOMpSrNJ5/CLm4vydgjPluDm0ENBC32ihxiL9SUde hp9hDVvRQpswEUoIII1KD0OFVxknvFPbmZhvBtCf0Ce87HXqJecZ3EF5XR7WY8d/5BuYuyYP334H Dv0MdHs4FFuElvD3yQz+zgl18vCry36cxwl8PhZfgdugl3n1z7s4z+NV9e/Qv1eeLn0XPP1icCqO 0d3HUFik+ufDOuf/lK/z4jCDt2WJ6wHrZz/hvVjE3s9pwNh+CBf6XgdwTfXFYAQpfUE9xRDnDEfu 4sUL/wv8ZL2CE6fz/wsAAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29yZC90 aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b 2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEp T9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQP w1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2Kg SRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCw bHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqc zK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d 2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6 waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezP xx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt 8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIV nHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU 0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgK zCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsum sYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2no iDQLED0zERW+vE64E7+DKRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV5cz2 iUK9CHeyPHe5COjbX5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKue0wZ G6gpIzekabwl7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVKuYTD ohmupK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6M7e6 Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7Ses/7 qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHbazWX mx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHVFpaRDQ0z lYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKIGETBERqxidjH 4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpSIYN5K4kHulXKbpQ7 vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC2vwX 5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmWETIRVRJXplbsETkkbKhr4Kre2z0U QaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bne29Z ET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw48OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11yPeh tiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz2Tm5 eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPktR7N0 4y8AAAD//wMAUEsDBBQABgAIAAAAIQA4WL0+ywMAAMgJAAARAAAAd29yZC9zZXR0aW5ncy54bWy0 Vttu2zgQfV9g/8HQ8zqSfFEcNU5hO/Fui3hbVOkHUBJtE+ENJGXF/fodkmLUbNSg2GKfRM7MmTtn dP3+idHRCStNBF9G6UUSjTCvRE34YRl9fdiOF9FIG8RrRAXHy+iMdfT+5vffrttcY2NATI9ABdc5 q5bR0RiZx7GujpghfSEk5sDcC8WQgas6xAypx0aOK8EkMqQklJhzPEmSLOrUiGXUKJ53KsaMVEpo sTcWkov9nlS4+wSE+hm7HnkrqoZhbpzFWGEKPgiuj0TqoI39V20Q4jEoOb0VxInRINemyVuSXbit UPUz4mfcswCpRIW1hgIx6sNliPBnNenslaLnVF9AqmNvO7aqAJ4m7tR7rukr/EC1fRXvSamQ8mWG BrBesCr/cOBCoZJCU7XpLLqBjvomBBu1ucSqgiJBOyZJFFsGBCP2hUEGA1tLTKnrz4piBMra/KAQ g85aRp7iMEah6vELPhHb2tqRarxHDTUPqCyMkIA7IQjjctJZqY4IMAarQqIKDGwEN0rQIFeLv4XZ QOMqyKv3y7ex9dCfCv8kAMERg8A8tWvznaixdbZR5FXufph7C3BeQopcDMOGBDxhRWoMoVFcmDPF W3C+IN/witcfG20IPBzX7L/gwVsOYG4tf4IH/3CWeIuRaSBN/5MxV4ktJXJHlBLqA6+hXX7VWByK aMsJ87DW4fBFCBPKAJNqNbm82/pcWLGek0wn2d1miDPN5ot0OsjZpGk2jNmk2ex2CJMl6XyyHuT8 0LfL1XS+HsQsbufJ1SDnan05W6RDdtbpfJsMc66m22HfNqtssx6M9G6RrJK5tQM16DLPcjtPP6ub a3+y7Txi/ilsECsVQaOdnbiAYnmpHteEB36JYePg7zlFUwbmeOwZmiFKt/DeA8MNAZbXRMtbvHdq 6Q6pQ6+3k1CDVJgtH5912fGF1Z9KNNJbaxWSvk2DuXQ26/QRbu4JC3TdlEVAcZia37EaXn86Kasw 7tPT5gaWrXvu94gfQjdiPv5aWFHoaqoKu5DxDkkJYw1EykO6jCg5HE1qn6iBWw2L2V3Kw6TjTRwP bpbnLqiykYF0d7AC/ghS3aGnTQNt2tNg7Xi5WU+bB9q8p2WBBj8GbX6EmaJg5j/C4AxHS98LSkWL 678CcRm9Ivkk6COSGOpq5z88bJE7QrcQ9OiU4ydYOLgmBv53JKkZerL7Z5JZeCdN0Vk05oWs5Vlh +YI6qpFBAHelegF2Lf4vX9q8xhWBdizOrOzXzR/ecUq0KbCEzWSEgpDdMnjnNPe/YDf/AAAA//8D AFBLAwQUAAYACAAAACEA2JqDi38BAABMAwAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1slFNRT8Iw EH438T8sfYcORIILGwkhGBNjjOIP6LqONba9pi1M+PUeGyCKD/DU6933fb27bxtPvrSK1sJ5CSYl vW5MImE4FNIsU/KxmHdGJPKBmYIpMCIlG+HJJLu9GddJLfJ3EQIifYQqxieap6QKwSaUel4JzXwX rDBYLMFpFvDqllQz97myHQ7asiBzqWTY0H4cD8lexl2iAmUpuZgBX2lhQsOnTihUBOMraf1Brb5E rQZXWAdceI/zaNXqaSbNUaY3OBPSkjvwUIYuDkPbjuhOCum9uIm0IpHmydPSgGO5wg3WvQHJcH2F XPv9GdWJLFLSv4+HD8PR8K6p51BsZnKNtTVTaA2hOzQu71mU4ZCNj9k3uaz+SS/AnmOnEALoP3ns Z1q43Rvhh2PQdIJAv00JfhoYWMZxiCbmoAC9YqsAbRvqpLPrmPmvjq7jutPJr6HSxoRm6DbMxu3Z +AI2SC23Yg5u6qD2wjUGMKWgfn15xAuCT/6B7BsAAP//AwBQSwMEFAAGAAgAAAAhAAlDyfuzCAAA IEMAABoAAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbLxb23LbNhB970z/gcN3R5LtSI2nSidR msQzaZtG9vQZoiALY5JgScqXfH0XCxKiSFHcNZk+ybxgz17PQjL219+eotB7kGmmdDz3J6/Gvifj QK9VfDf3b28+nv3ie1ku4rUIdSzn/rPM/N/e/vzTr49XWf4cyswDAXF29ZgEc3+b58nVaJQFWxmJ 7FWkglRnepO/CnQ00puNCuToUafr0fl4Msa/klQHMssAbSHiB5H5hbioKU0nMgasjU4jkWevdHo3 ikR6v0vOQHoicrVSocqfQfZ4WorRc3+XxleFQmdOIbPkyipUfJQr0oYVR3Dtyg862EUyzhFxlMoQ dNBxtlXJ3oyXSgMTt6VKD6eMeIjC8r3HZHLZwHMmU2LwIRWPEIq9wIa4I85Y20VRaP1g4ruPal3i ZHzKmCIiRoTTgaLCIWapSSRU7MS8zDVV50I99MnvT6neJU6dRPWTdh3fO1mmLBmajadYeVXTMpaA RukutyKRvhcFV9d3sU7FKgSNHieXnslI/y1QxVoHH+RG7MI8M5fp17S4LK7w46OO88x7vBJZoNQN UAhIiRQI/PwuzpQPT6TI8neZEkcfbs1bR58EWV6R9l6tlT8yiNl3kPkgwrl/fl7eWRgNDu6FIr4r 78n47HZZ1WTuu1srkDv3RXq2fGeEjdDM8rNibnJgPFyhKokIoPIAR2xyCSQELGZwQmWiez4DRrMX 33bGuWKX6wIEBQBYVSxc1jwO3ARMtbSMDU/l5osO7uV6mcODuY9YcPP2+muqdAo0OvffvDGYcHMp I/VZrdfSNIji3m28VWv5z1bGt5lc7+///RHpuZAY6F2cg/rTGWZBmK1/fwpkYmgSRMfCRPhPswA4 DMJRwUGFdmqvjb1RQ8Wb/5aQExvDoyhbKUxL81D/k0Bo9a430LmxqGoAymXpetFfxGV/Ea/7i8Dk 7eeLWX8tYCPTNyI2NypZSQ9qrgObfFU/XLw5kbJmRSOLOlc0kqZzRSNHOlc0UqJzRSMDOlc0At65 ohHfzhWNcJ5cEQgkrnoWXaA3SIV9o/IQ+mQH0016Ul3RaryvIhV3qUi2nmmsdbVPkeVyt8ppqiKd vpwsl3mqzXazwyPQnU3pvpiTf4+SrcgU7Mq7gHq6/sZsfbxPqYLtawfUa5t8DZtwY3K0hX0NRSC3 OlzL1LuRTzaijPV/am9pdxmdyvUM6xd1t8092BWaltsJNm1xersnrPwvKkMfnOzm0xZTuoSTYjht yct24X/ItdpFpWsIu5Gp5XNGmGsQqOJpF12aEDWrq9MKEwCKCbZd8E1A+QT9bXPhyzcxpuhvW9EL 5RP0t43rhfIxP07Hl800H+BnFY9UXjN27S50qNPNLixroJMeZuwKdhA0E9hF7OSTSGLGruAD+vTe BQF8c6PkKTsWex5loLDDYVGw2Oi2sINSo70JwyJ2gGpY5wysflzLAGKT7jf5oMyPwNxmgCzt9pqd 5XzR4gFoQaQ99N87nXfvoc9bOI+Kch3DzyWZ9GhoFy2VR0Ur8sn2O0aM+zU+BlC/DsgA6tcKGUAt +dG+53E9kQ7SvzkysNi07LoYph2ZmWdsZnZAvBYwUN8k7L9aqrc9F5p9k4DCDlCzbxJQ2NGp9TLX NwlYg/VNAlZL12iPUZVTOUax+2YVyO0ECBYNQ94EoGHImwA0DHkTgPqTdzfIcORNwGJzg+PUKnkT gPAVzld9B1QlbwIQmxss2xW/GZV9D6Wc/nI7AHkTUNgBapI3AYUdnTbyJmDhK5xMqGE5qiNgDUPe BKBhyJsANAx5E4CGIW8C0DDkTQDqT97dIMORNwGLzQ2OU6vkTQBi04MDqpI3AQhf4XDDUfLGqv/h 5E1AYQeoSd4EFHZ0aoTqNqkELHaAaliOvAlY+AonGQosTG6OUcOQN8GiYcibADQMeROAhiFvAlB/ 8u4GGY68CVhsbnCcWiVvAhCbHhxQlbwJQGxuOEreWIw/nLwJKOwANcmbgMKOTo1QHc8RsNgBqmE5 8iZgYb70Jm8CEL7yUiCORcOQN8GiYcibADQMeROA+pN3N8hw5E3AYnOD49QqeROA2PTggKrkTQBi c8NR8sYa+eHkTUBhB6hJ3gQUdnRqhOrIm4DFDlANy1EdAWsY8iYAYWL2Jm8CEL7yAiCsIk6YhiFv gkXDkDcBqD95d4MMR94ELDY3OE6tkjcBiE0PDqhK3gQgNjeYc7ZwXpR8PHXSkgTUcwblqQYy4HlL kKiAhYHf5EamMFUou0+H9AQsLWQgtqQH1cT3Wt97tIPdFy0JQoZSq1BpPNL9jKd0KoMIF7MTkwQ3 fy28z3YAprEOU+rw5A1MD1XHhXA8yQwOgZ75cwIjO0l5stxIgwEhM9dVjADhTOg1DAQVYz1msZnz gRdxqKq4jf+3LVDhb0DEhU2oYAtYAUxEnYAqDry7M0h43L0O3HIqHhXZj2SUahan4/d7KPvewRnN k3rn5iT4CZ3xpPhJH3n4io1qU0EYzkKVujSEkK1CO2IGf1zHa7DwsZjOssFcPwkrCp4vZBj+IXAg LddJ+6uh3OT26WSMHbAmaqXzXEft61M8II6aHBMA6VBVxl4aI9rzJN5FK5kWx81bU9J0DpxEO0xJ e9a1JRWonm7X7aBcXIHAcX4V4zn+eqriE3vEH3VaCRix+8tMzDVKCMYD78v7TuACaqYrbw43YQgD I+AmOxBjPH7zfnb5S1EGbTOK+L/XYkLx0l0cn1AspiHh42DMc+4vRKhWqTK1ghOc+zs2wb9XJjJR H3A0zI+eSoYD0gh2GeQiTj7WOerQY+1h8PYercXiKPWg3kcj0xWV9hCgxf+L845n63sRhlofz9fi GT9jK0L3Hu7DdYf+u1hMJtOF9fkPTeEbsdWRqGTw/kYAo9XFVZHOZYlNplazrJLg9t5wCV53cD3F q5Hrm+QVrK40rzWt9qi1ZP3evQVj7G8M4++Sy7O3/wEAAP//AwBQSwMEFAAGAAgAAAAhAMZPOQh4 AQAA4QIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAIxSwW7CMAy9T9o/VLm3SWEwqNoijYnTkCaNadNuWWIgo02jJFDY1y9taaHaDrvFfs/P 9nPi2THPvANoIwqZoDAgyAPJCi7kJkGvq4U/QZ6xVHKaFRISdAKDZuntTcxUxAoNz7pQoK0A4zkl aSKmErS1VkUYG7aFnJrAMaQD14XOqXWh3mBF2Y5uAA8IGeMcLOXUUlwJ+qpTRGdJzjpJtddZLcAZ hgxykNbgMAjxhWtB5+bPghq5YubCnpTb6TzutTZnDdixj0Z0xLIsg3JYj+HmD/H78umlXtUXsvKK AUpjziIrbAZpjC9P9zL7zy9gtkl3gQOYBmoLnS7nev9dF7WZyusdnMpCc+PqepEr5GCYFsq6Czaq vYRjZ9TYpTvpWgB/OLUNfgNVHw0HUf2FdFI36kK3T21fMyZwzxkSNfa1yNtw/rhaoHRAwjufTP3B eEUm0eg+IuSj2qdXXxnUJPLzZP9UnEajUV+xFWis6X/K9AcAAP//AwBQSwMEFAAGAAgAAAAhAGio WJYxCAAAL0AAAA8AAAB3b3JkL3N0eWxlcy54bWy8W99zmzgQfr+Z+x8Y3lPHds5uMnU7idteM9Mf aZ3MPcsgx5oC8gFukv71t1phjMHAbiD3FCPQfqvdT99iR/vm3WMYOL9knCgdzdzhq1PXkZGnfRXd z9y7248nr10nSUXki0BHcuY+ycR99/bPP948XCTpUyATBwxEyUXozdx1mm4uBoPEW8tQJK/0RkZw c6XjUKRwGd8PQhH/3G5OPB1uRKqWKlDp02B0ejpxMzMxxYperZQn32tvG8ooxfmDWAZgUUfJWm2S nbUHirUHHfubWHsySWDRYWDthUJFuZnhWcVQqLxYJ3qVvoLFDKxHA2MKpg9P8VMYuE7oXVzfRzoW ywCC9zA8c99C5HztvZcrsQ3SxFzGN3F2mV3hn486ShPn4UIknlK3EFIwECqw9ekySpQLd6RI0stE iaM31+apo3e8JC1Yu1K+cgcGMfkNNn+JYOaORruRufHgYCwQ0f1uTEYnd4uiJzM3H1qC3Zkr4pPF pTE2wGXu/haWuzlYPFyhKxvhQTIAR6xSCaQAjhicQBkOjqbAF3vxY2viKrapzkDQAIAVzcJlKeLA FWDOwhIY7srVZ+39lP4ihRszF7Fg8O76JlY6BpLO3PNzgwmDCxmqT8r3pdkv2dhdtFa+/Gcto7tE +vvx7x+R/JlFT2+jFNyfTJEFQeJ/ePTkxtAWTEfCZPirmQDEgXQUcNChrdp7YwdKqDj47w5yaHN4 FGUthdnhDvrfCISr3nYGGpkVFReAdlm+jrubOOtu4q/uJpC83WIx7e4F6HrXjFhuFFhJT2qqPUu+ YhzG5w2UNTMqLGqdUSFN64wKR1pnVCjROqPCgNYZlYS3zqjkt3VGJZ2NMzyBwlVm0RijQdrYtyoN pJnfKEDDjlKXlRrnRsTiPhabtWMKa9ntJrFcbJcpzVWU0+eL5SKNdXTfGhGozmbrPluTP4SbtUgU vCW1hH7UMfS35q3H+TtWfivUX5Z8lTXhi8nREnYTCE+udeDL2LmVjzajjPlftbOwbxmtznVM62d1 v06dxRpLbivYpCbo9ZGw9j+rBGPQuJkmNUtpM07K4aSGl/XGv0hfbcNdaAhvIxOr54w0lyDQxeYQ nZkUVXdX6ypMAihLsOWCvwS0T/DfFhe+fZNjiv+2FD3TPsF/W7ieaR/50ZxfttK8hy+tDml7Tdl7 d64DHa+2wW4PtMrDlL2DcwjaEtibOLdPEokpewcfyKdz6XnwzY3CU3Yu9jrKQGGnw6LgZqOvhZ2U kuwNGStiJ6iENWJgddNaBhBbdH/IX8r8JsYtBqjS+btm63Ye10QAShDpHfr7Vqft79CjGs2jolxH 8HNJIh0a2rhm51HRMj7ZesfIcbfCxwDqVgEZQN1KIQOohh/17zx5TaSDdC+ODCy2LOdVDGlHVuYp W5lzIF4J6KluEt6/anZvPReqdZOAwk5QtW4SUNjZKdWyvG4SsHqrmwSsmqpRn6OipnIWxa6bRaD8 TYCwon7EmwDUj3gTgPoRbwJQd/FuB+lPvAlYbG3INbUo3gQgfITzVT8HKoo3AYitDVbtst+MdnUP rTR/ue1BvAko7ARVxZuAws5OnXgTsPARDhNKWLnUEbD6EW8CUD/iTQDqR7wJQP2INwGoH/EmAHUX 73aQ/sSbgMXWhlxTi+JNAGLLQw5UFG8CED7C0Yaj4o27/sXFm4DCTlBVvAko7OyUBDV/SSVgsRNU wsrFm4CFj3DIkGEhuTmL6ke8CSvqR7wJQP2INwGoH/EmAHUX73aQ/sSbgMXWhlxTi+JNAGLLQw5U FG8CEFsbjoo3bsYXF28CCjtBVfEmoLCzUxLUXOcIWOwElbBy8SZgIV86izcBCB95LhBnRf2IN2FF /Yg3Aagf8SYAdRfvdpD+xJuAxdaGXFOL4k0AYstDDlQUbwIQWxuOijfukRcXbwIKO0FV8SagsLNT EtRcvAlY7ASVsHKpI2D1I94EICRmZ/EmAOEjzwDCXcRJUz/iTVhRP+JNAOou3u0g/Yk3AYutDbmm FsWbAMSWhxyoKN4EILY2mHO2cF6UfDx1WEMC6jmD3akGMuCoJklUwGyBP+RKxtBkJdtPh3QE3K2Q gVhDD+oSr7T+6dAOdo9rCEKGUstAaTzS/YSndAqNCONpQyfB7be588k2wFTmIaUOT95A91CxXQjb k0zjEPiZPm2gZWezO1lurEGDkOnrylqAsEXuGhqCsrYeM9n0+cCD2FSVDeP/bTNU+AyIOLEK5a0B y4OOqAao7MB7fgYJj7uXgWtOxaMj+5aMnZvZ6fj9O5R97uCMZqPfqTkJ3uAznhRvjJGDj9isVh2E 5ix0qc1DSNkysC1m8OE68mGF0CSI/zWzyfQfhTUF9+cyCL4IbEhL9ab+0UCuUnt3eIoVsGRqqdNU h/XzYzwgjp4cMwB0KDpjL80i6nkSbcOljKHDqyHmX7WpHNiJdkhJe9a1hgrUSNf7drBd8g0Cx/lV hOf4y1TFO/aIP/q0FNBi9810zFW2ELQH/tyN5wbnsGfaeHP4EoYw0BFr2IEYp6fnV9Oz19k2qOtR RBZlHYpn+cXxDsWsGxL+HLR5zty5CNQyViZv2MG5H7EE/13oyER/INDQP9pEhgPR8LYJcBE7H8sa dRix+jQ4+4iWcnFUetDvo5lpy0p9CnDF/0vwjrP1SgSB1sf5mt3jM7ZgdB/hLlp3GL/xfDiczG3M X5TCt2KtQ1Fg8H7AS2ZudpXRebfFhhPrWVIguB3rj+DlAJcpXsxcV5IXsNpoXipa9VmrYf0+vJli 7Af6ifdOy5O3/wEAAP//AwBQSwMEFAAGAAgAAAAhAPRuesHoAQAAqwUAABIAAAB3b3JkL2ZvbnRU YWJsZS54bWy8k9GK2zAQRd8L/Qej940lx0l3zTrLbrqBvvShbD9AUeRY1JKMRombv+9IdlzYEBq3 UBtMcke6zBzuPD791E1ylA6UNSVhM0oSaYTdKbMvyfe3zd09ScBzs+ONNbIkJwnkafXxw2NXVNZ4 SPC+gUKLktTet0Wagqil5jCzrTRYrKzT3ONft081dz8O7Z2wuuVebVWj/CnNKF2Swcbd4mKrSgn5 2YqDlsbH+6mTDTpaA7Vq4ezW3eLWWbdrnRUSAGfWTe+nuTKjDcsvjLQSzoKt/AyHSfuO0mCF1xmN v3RDEi2KL3tjHd82yK5jOVkN4JKuMFyjuOaN2joVCy03FiTD2pE3JaEZ3dAFfsOb03n4kjQ4iJo7 kH48SHu54lo1p7MKnQLoC63yoj7rR+5UaKgvgdpj4QBbWpJXRinNNhvSK6wkOQrP61HJsKn+eRjO zEcFk4ONRZ94hD1EH1TQZ7gV+0z76FyQeFNaQvJVdsk3q7m5QiSjSySxQB6BzHwSERd9I8FbiWDj 2fM4P06yRuXTfc6G+ScR6X0mEOE1dnwFxAuCCKEIKPL/Eo3s9T2IJV28vAeR/SkajLKpINZc445c IxGi0HMI0Zi2JH8XicslofnI5nck4krgav3LkgzbAqtfAAAA//8DAFBLAwQUAAYACAAAACEAZ8PI ou0BAADoAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACcU8Fu2zAMvQ/oPxi+N4rTpOsCWUWRbuhhWwPEbc+aTCfCZEmQ2KDZ14+yG8fZdppP 5CP99PRI8du31mR7CFE7W+bFZJpnYJWrtd2W+VP15fImzyJKW0vjLJT5AWJ+Ky4+8HVwHgJqiBlR 2FjmO0S/ZCyqHbQyTqhsqdK40EqkNGyZaxqt4N6p1xYsstl0es3gDcHWUF/6gTDvGZd7/F/S2qmk Lz5XB0+CBa+g9UYiiO9JjpnUDlvOBpRXDqWpdAtiMSN8yPhabiEKwvqAv7hQR3H9cc5ZH/LVTgap kCwUVzfzBWcjgN95b7SSSO6Kb1oFF12D2WPnQ5YIOBu3cPJmA+o1aDyIKWfjlH/VlqRckZY+Im1B boP0uyg+JYFDxjdKGliRA6KRJgJnJ4A/gEzTXUtNivkel3tQ6EIW9S+a7yzPfsgIybcy38ugpUXy L7X1SRcbHzGISqMhbqr1eReO28axnouia6DgvDER9BqocK6uOyE+NnQ3/IfYYiy209BLHckZhcMZ f7CuXOulPYjPQasYnaUJviPJ8p/xyVfuPu3Ou5fn4Gj+Lxp3Gy8VTWm+KGh8p00YlfiGFgZqGu2R 8ATwB/I9mHQq/Wu3UB97/i6k3XruH64o5pMpfd0yHTHaiOFFid8AAAD//wMAUEsBAi0AFAAGAAgA AAAhAAkkh4KBAQAAjgUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwEC LQAUAAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAAC6AwAAX3JlbHMvLnJlbHNQSwEC LQAUAAYACAAAACEAfDuXOSIBAAC5AwAAHAAAAAAAAAAAAAAAAADeBgAAd29yZC9fcmVscy9kb2N1 bWVudC54bWwucmVsc1BLAQItABQABgAIAAAAIQAa1p+5shIAAJ6bAAARAAAAAAAAAAAAAAAAAEIJ AAB3b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAA AAAAACMcAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAOFi9PssDAADICQAA EQAAAAAAAAAAAAAAAAD+IgAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA2JqDi38B AABMAwAAFAAAAAAAAAAAAAAAAAD4JgAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAA ACEACUPJ+7MIAAAgQwAAGgAAAAAAAAAAAAAAAACpKAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54 bWxQSwECLQAUAAYACAAAACEAxk85CHgBAADhAgAAEQAAAAAAAAAAAAAAAACUMQAAZG9jUHJvcHMv Y29yZS54bWxQSwECLQAUAAYACAAAACEAaKhYljEIAAAvQAAADwAAAAAAAAAAAAAAAABDNAAAd29y ZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAPRuesHoAQAAqwUAABIAAAAAAAAAAAAAAAAAoTwA AHdvcmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQBnw8ii7QEAAOgDAAAQAAAAAAAAAAAA AAAAALk+AABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAMAAwACQMAANxBAAAAAA== --_002_087A34937E64E74E848732CFF8354B920983BF65ESESSMB101erics_-- From nobody Fri Sep 26 03:37:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F941A1AC7 for ; Fri, 26 Sep 2014 03:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9zBFwjleq1o for ; Fri, 26 Sep 2014 03:37:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27AE1A1AC8 for ; Fri, 26 Sep 2014 03:37:38 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8QAbXeu008989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Sep 2014 10:37:34 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8QAbVJ2003209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 12:37:32 +0200 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 12:37:31 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 12:37:31 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0A== Date: Fri, 26 Sep 2014 10:37:31 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: multipart/mixed; boundary="_002_5BCBA1FC2B7F0B4C9D935572D90006681520B965DEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 29557 X-purgate-ID: 151667::1411727854-0000437E-EE74B118/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/j8La7mBLPrttiK_XJ3-Tks4fc6g Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 10:37:43 -0000 --_002_5BCBA1FC2B7F0B4C9D935572D90006681520B965DEMUMBX014nsnin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different.=20 Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_002_5BCBA1FC2B7F0B4C9D935572D90006681520B965DEMUMBX014nsnin_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="OC-Report-Type clause 6-6 UW.docx" Content-Description: OC-Report-Type clause 6-6 UW.docx Content-Disposition: attachment; filename="OC-Report-Type clause 6-6 UW.docx"; size=16205; creation-date="Fri, 26 Sep 2014 10:12:08 GMT"; modification-date="Fri, 26 Sep 2014 10:33:29 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBhKvXWmgEAABIGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VEtLw0AQvgv+h7BXSbZ6EJGmHnwcVbCi13UzaRf3xc5U7b93ktagVRO1eAmEMN9rvsn45MXZ7AkS muBLsV+MRAZeh8r4WSlupxf5kciQlK+UDR5KsQQUJ5PdnfF0GQEznvZYijlRPJYS9RycwiJE8Pyl Dskp4tc0k1HpRzUDeTAaHUodPIGnnBoMMRlfsYBkKsiuVaJL5ZhH6gVScPfOSkPgrlOIuF8wqMhO V9ONgFKoGK3Rili+fPLVBnUe6tpoqIJeOCYsOtAGDxIZwL0GU07GZ1CrhaXs/IWlrdJIYPF3dGuX BU+2knBuYh9Dv5+1sq/SeQ6pkp2tfpjhWBq0mIIGRN67s0WH7JTxbwl9qwNpaQG3Xs4nFSvcPnrW 2TZDcg225odm8xVUOUexUY4B63eG5ud1DZrLPrwLh3ljtVjZezfb57RdOAIRL+gnJB9PcPMOPke9 Rh6UQHzhINvn9ufYwgxS1nzvU/Vg4QfZ/tJ2Bz0o4hkebv4t/XfgfUK6tuuQ/hDG28+pmf6i47L9 o09eAQAA//8DAFBLAwQUAAYACAAAACEAHpEat/MAAABOAgAACwAIAl9yZWxzLy5yZWxzIKIEAiig AAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIyS20oDQQyG7wXfYch9N9sKItLZ3kihdyLrA4SZ7AF3Dsyk2r69oyC6UNte5vTny0/Wm4Ob1Dun PAavYVnVoNibYEffa3htt4sHUFnIW5qCZw1HzrBpbm/WLzyRlKE8jDGrouKzhkEkPiJmM7CjXIXI vlS6kBxJCVOPkcwb9Yyrur7H9FcDmpmm2lkNaWfvQLXHWDZf1g5dNxp+Cmbv2MuJFcgHYW/ZLmIq bEnGco1qKfUsGmwwzyWdkWKsCjbgaaLV9UT/X4uOhSwJoQmJz/N8dZwDWl4PdNmiecevOx8hWSwW fXv7Q4OzL2g+AQAA//8DAFBLAwQUAAYACAAAACEAkmzaLzkBAABHBAAAHAAIAXdvcmQvX3JlbHMv ZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACskzFP wzAQhXck/kPknVxboEWoaRdA6gpFsLrOObGI7ch3BfrvMUEtKbSBIYulO8vvffdsT+fvtkpeMZDx LhPDdCASdMrnxhWZeFzenV2JhFi6XFbeYSY2SGI+Oz2Z3mMlOR6i0tSURBVHmSiZ62sAUiVaSamv 0cUd7YOVHMtQQC3ViywQRoPBGEJbQ8z2NJNFnomwyM9FstzU0flvba+1UXjj1dqi4wMWQMgcJ6Oo KUOBnIltJ42cAg4jTI4gWKOCJ685Vd7Cl/un62R/MCDeVEhPhstbrVFx2/7nVhfH6AjHgZj/EUXj 3Aqiqbvsh33aqzWxt88x9N1VpCnsumAY7bCLZtwnDcf3it8kTQnN2slw2SeD9o6XclW1OHatriAu +oR4w9XDrz/Sam5BYO/7zz4AAAD//wMAUEsDBBQABgAIAAAAIQD+wIelKwkAABg2AAARAAAAd29y ZC9kb2N1bWVudC54bWzsWVtvo0YUfq/U/zDiqX2wDSTrJG7sVTbeaCu1SpR6W6lvExiHUYGhM4O9 7q/vmQECQwBjZ6XYkp+cwHDmXL5zv/74LQrRinBBWTy1nKFtIRJ7zKfx89T6urgbXFpISBz7OGQx mVobIqyPsx9/uF5PfOalEYklAhKxmKzgbSBlMhmNhBeQCIshS0gML5eMR1jCv/x5FGH+T5oMPBYl WNInGlK5Gbm2PbZyMmxqpTye5CQGEfU4E2wp1ScTtlxSj+Q/xRe8z73Zl/OcZX3jiJMQeGCxCGgi CmrRvtRAxKAgsuoSYhWFxbl10uc2n+M12CMKM7bXjPsJZx4RAp7Os5cvFB276+5cgYrEyxd9WDDv LDiJMI1fyCh01Oz/YrwhGG+U3T1SpEpBQBczwNIT8zfqN0HrCWDRf5xatn316eL80rGKR3OyxGko X795qDzSRB64/vlDbkICX69wOLUeQmB2Qb5JazS7HsFN2SF9Us7Gw/EQofvbwSNJGJeDxSYh6ObP B3VS6vNwUH31Dky+07VgCCWsdu+JSLAH9k04EYSviDVDCC0C0qAx9BOoDUEEIWjxaf7hZ0QFkkqb bIk+xxAwOJbEB2XD54eg3a1iAnpSzb0EeZVsPhEep09EIIN/CIgkBLRRH+CoQItTGTAITr/f8vQ/ 9cAHyaeWazvnA/tq4I4XjjOxLye2/belNM3hiML+nABcbfvs1nHGt/oNEFbIna0DLNWdxf/q7wyX 8ESRoLHIOdBuU3DwNeTUC9BflASkmRF34rivGNFOeHc+dm+uNBttUDDUACwBFyYzblUdfZg5A8XU tKKZmd+Nz27mXcysAyXpVo7OduWoj3pmnPybEiFRBKEZPxPRwgYYK7fSeZWN74YTlUkbPFZx04oc gJGKdArjDMqBkGEfcR0LwZdjj/DYlKaKtQ/9pbhqtmsF620gk6xFmznnRxRRliwMmcroSMcWgTAn iMZUUhyGG4gvSxoTf1KX95R7ytxjI3SDAga+loEUrG+oq4jqM5WkXgAtOcFSl6wiYGnoI5wkoHDJ gIr2XBPj4C/vofOC9xY3hsyLEJTUKAt1ABmVWpXjlrgCl/UBTlDaamxJnpITnDpKGdDoZwoq5FqP c4jhNNatweCLwpjK+lDG6OoH+h0a62NFtIfmCFF5NNDJ6hnoVqBJg9IMcGNUOPecPtO4lDvHFice oSviG152wA6Sp2CQD0uVwSRU/8TX4kKVf//bozLqLwjcSGnglcXp0ZgzZrINmE+pNO1rGK+awaH7 LuvVPgWa21Kgba8WlboNPsqCMc/kCQE/pD5MFmA2UD96qAEZC8E8qlobtIZIovUOsIuJp8IwSoUC H0OCQLBQKiiCR+6HxyLmruGiKIVB5qx1ee9muk9ybQsXw0Ow0gHH3EU9l1TD6iPBYZRlUjN9VjLR Iei3D0CaEmYpXy1jnlzge0/tjskFbqDDoF5WS/46L0rHOcURkZDmvhDsw08GmWOBfy13mTWGyhA1 oXOHKIQ+FjEN20DCzgpgw51bK8tTqujothzVvEMrDvng1L0fe/eeV/z57Pqxe0lTaQ/y/UvSvqSB TJztaMqp9sXOfUo21c5WPpqcSh7V1U/XlEUVNNUapjoMwE9Qy9dnAUZoqzZYsEXdrcFyxs2T0ooG 2yalMI8w+CgbrFKRVzvzc7E3PwYzYNQCKmrJsV0co+MwSDXJ5Ribl16d7N57D8VZI0ON9Um7n5hv 9DKzopa9/MTZef3jnmn7NjpKCRtn502OW1GvXjF0+VujNqtu5Oy+t6ngNltxGOMFhPZs3BtZbTR8 +xb7rYZX19UjpGOslHo5QGZ5pZxsANNhoUapDQMZu6A+1zt1A7Vcv/3qnYdYTmX32oFNn8GcVI3Z trOwc37qKb3ukXvcv3Oace0yrHeoAMPgCraCPTh4U2LJHFQGWxXtvinMZ9foubBaAumtUnUo13K9 kbhyr85Inar9jmofdiuqjjJmJtWiqhyc1PYqew+G/gcAAP//7FdbT9swFP4rVl72Qkd6oUBFKrWU y6RNVC3bpL1MbnzaWCR2ZjuU7tfvHCdh7WAM0KS10vISx3Z8zndu/o4UkxHMeZG6KAjD4+Fh56gZ sGXPWCnGa1P9k2UvHxv/mrpVCrjnlqdRME65VNdw54L9/sn+/Sa/07G7LO3ZnMcQBbkBC+YWgj7z D/5dANNz5hJgV0YupGpMgKcZG3wa1/MGYpC3IFgG1vIF4GbuSIzzwlAKifRaVUpP1pSup/4Rwlgr h8ZB7T3E08bV+wmBe7sNALbYbtcYEBvRMcjzVMbcSa0a70ZMKm/QkeQZODDsErjAVxlK22BbTB8K ySfD38C3AqxjGXdxAtYjegp0lSg16F2BueEb9mg6s/958roKeiak0+aNZUo76DFMGwNMWmadTFPG FdM5KJywVGfLnBEwl0pSImG67EoMlbeCgVwbZxGXYMsEsKQafHOHQUULzK1yTCOb6CIVbAbMFjnN g9iKcvucknDvQEwIC8oWVBUQYKKxTtTwHwPISt/vij8xRIW0cWGtj0PFHjrYzzQmukD/ISsoS2Vl gl3yJ+MzfQtsLe043WVU73UJ+zcgKcQN7IpHf3EgliGPmJiPZoR45QdYlaprr4psf/nR1bcrQA0R 1D1kIAKwtgpQrmaqOdFbFcMeutwPmDYbLObFEMfmIZUdAVLuMBydd9uDUc3T/yaDxzpVsnwBKdJn KaKg5RsCXrhEo0YfUyPjhH2WkAApILhDct8Km51GeNxoda+brV672QvDL1VD4M97SWOwYSjUp2bx G/bw/Ko/QgYlVUkML6lKPo9dd8PmQWv4mPk2V3wDVNna9xh/bIB8/3OacIWtSmW9Fsl5hfWeJ7A2 bPkuJZdNUanrTOubjJubqeN4R1YqtUklhew5Cr5e6CGPb8hXy169+Yyu2NL37bqto3ULsRvf+4MC cdNeU1yn2fNBezgYBB7BYvodz1pGQbPV6oQkOMHxwRGOvcx88YHTkU7nON8pt2A3mOBJ9edMO6ez n98pzNdWE0//o+AwPKLj5xrZEAZq9bkonP+sxMU6tbip6klpj9dC6PjCSEKdYsM2lsjJo6Dd9T+h aUvg3q4zLVZ+gL8UGRaA/g8AAAD//wMAUEsDBBQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAd29y ZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDS SX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwd EiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteX lqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrA Z2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bps QXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ /sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRg Dq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjW DPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+/ /ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb 5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJ iaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQO SUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6 SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrd vsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68G t2noiDQLED0zERW+vE64E7+DKRtjYkoNFHWnVsc0+bvCzShUbsvh4go3lMoXXz+ukPttLdmbsHtV 5cz2iUK9CHeyPHe5COjbX5238CTZI5AQ81vUu+L8rjh7//nivCifL74kz6owFGjdi9hG27Td8cKu e0wZG6gpIzekabwl7D1BHwb1OnPiJMUpLI3gUWcyMHBwocBmDRJcfURVNIhwCk173dNEQpmRDiVK uYTDohmupK3x0Pgre9Rs6kOIrRwSq10e2OEVPZyfNQoyRqrQHGhzRiuawFmZrVzJiIJur8OsroU6 M7e6Ec0URYdbobI2sTmUg8kL1WCwsCY0NQhaIbDyKpz5NWs47GBGAm1366PcLcYLF+kiGeGAZD7S es/7qG6clMfKnCJaDxsM+uB4itVK3Fqa7BtwO4uTyuwaC9jl3nsTL+URPPMSUDuZjiwpJydL0FHb azWXmx7ycdr2xnBOhsc4Ba9L3UdiFsJlk6+EDftTk9lk+cybrVwxNwnqcPVh7T6nsFMHUiHVFpaR DQ0zlYUASzQnK/9yE8x6UQpUVKOzSbGyBsHwr0kBdnRdS8Zj4quys0sj2nb2NSulfKKIGETBERqx idjH4H4dqqBPQCVcd5iKoF/gbk5b20y5xTlLuvKNmMHZcczSCGflVqdonskWbgpSIYN5K4kHulXK bpQ7vyom5S9IlXIY/89U0fsJ3D6sBNoDPlwNC4x0prQ9LlTEoQqlEfX7AhoHUzsgWuB+F6YhqOCC 2vwX5FD/tzlnaZi0hkOk2qchEhT2IxUJQvagLJnoO4VYPdu7LEmWETIRVRJXplbsETkkbKhr4Kre 2z0UQaibapKVAYM7GX/ue5ZBo1A3OeV8cypZsffaHPinOx+bzKCUW4dNQ5PbvxCxaA9mu6pdb5bn e29ZET0xa7MaeVYAs9JW0MrS/jVFOOdWayvWnMbLzVw48OK8xjBYNEQp3CEh/Qf2Pyp8Zr926A11 yPehtiL4eKGJQdhAVF+yjQfSBdIOjqBxsoM2mDQpa9qsddJWyzfrC+50C74njK0lO4u/z2nsojlz 2Tm5eJHGzizs2NqOLTQ1ePZkisLQOD/IGMeYz2TlL1l8dA8cvQXfDCZMSRNM8J1KYOihByYPIPkt R7N04y8AAAD//wMAUEsDBBQABgAIAAAAIQCQWH2hPAMAAM0HAAARAAAAd29yZC9zZXR0aW5ncy54 bWycVU2P2zYQvRfIfxB0jtf6sGSvEm8gy6umxW5SxOmlN0qiLWL5BZK21v31HUpitNuqQZCTyPdm Hoczw9H7D8+MehesNBF864c3ge9hXouG8NPW//Nrudj4njaIN4gKjrf+FWv/w92bX953mcbGgJn2 QILrTGz9s+KZrlvMkF4wUiuhxdEsasEycTySGo8ff/RQW781RmbL5eh0IyTmoHYUiiGjb4Q6LQfP vajPDHOzjIIgXSpMkYGAdUukdmrsZ9XgqNaJXL53iQujzq4Lg+9ZjtfthGq+efxIeNZBKlFjrSGz jA7XZYhwJ6Ppj+gM+XwglULq+kLkDsp2Ibjz4INAidtEU39p8b+FYIBLrGpINPRCEgyEUah++oIv xPaI7m0bfERnar6i6mCEdGrraPRor7LFvC/RX9A1jl9FyaBYtwg0DVYHiWq4aCG4UYI6u0Z8EqYQ TCrIw+gBO2T6s6FVG20DtosvQhjnBp2RR+v7cvCw7MQEcZTeF3NMnCabMJ5lijBM532KMF3t53zS IEyi3Szzv7Gt8zjZzfps9klwO8vc7tarTTh3zi5MymCeuY3L+diKPC12szct9ut4Xm1fpnE+m4P7 TZAHY6VfV6FcpVF+Oxd1mce7PLfMcigsVJhl9mX+odyqhC7x2NC4BWKVIsh7tG8XvFhWqacd4Y6v MMwQ/JI5nCtHLhYDoaH3aQmd6Ah4tgPTEC33+NgL00ekTpNy3+IsU7MovIvfv6nZZ4TVr0qc5aDa KSR/4w3A7sBwtRr1CDcPhDlcn6uD8+LwhF9QZ958vigruJwS1GUGpi62GXpA/OT6vsGL/b017bKa qoOdzPgRSQlPDkyqU7j1KTm1JvRha2DXIPXUb6pTNHJRz8HOcv0G1fZmYD0urMGwBKtxMWGxw+IJ WzlsNWGJw5IJSx2WWgymClaU8CeYgG5p8aOgVHS4+ejArf8faEiCbpHEUFc7u6DBRNYD4zDT3iXD zzD4cEMM/PQkaRh63vpRMAzC0ZqiqzibV7ZWyRrLV6jXIINgjPaleuXcN/m/YumyBtcEGvJwZdU0 Ct8OgVOizQFLmJpGKLhyP7zf9crTf/juHwAAAP//AwBQSwMEFAAGAAgAAAAhAHQ/OXrCAAAAKAEA AB4ACAFjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACEz8GKAjEMBuC74DuU3J3OeBCR6XhZFryJuOC1dDIzxWlTmij69hZPKyzs MQn5/qTdP8Ks7pjZUzTQVDUojI56H0cDP+fv1RYUi429nSmigScy7Lvloj3hbKUs8eQTq6JENjCJ pJ3W7CYMlitKGMtkoByslDKPOll3tSPqdV1vdP5tQPdhqkNvIB/6BtT5mUry/zYNg3f4Re4WMMof EdrdWChcwnzMlLjINo8oBrxgeLeaqtwLumv1x3/dCwAA//8DAFBLAwQUAAYACAAAACEAeDczrOEA AABVAQAAGAAoAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACckMFqwzAMhu+DvoPR3bXn1ltb4pQ2IdDr2GBX13ESQ2wH2ykbY+8+ h526407ik5C+HxXHDzuimw7ReCfgcU0Baad8a1wv4O21wTtAMUnXytE7LcB5OJarh6KNh1YmGZMP +pK0Rblhcr3UAr7o7tzsN5Tjc9UwvGVVhfeMcfzMebVteH3anOg3oKx2+UwUMKQ0HQiJatBWxrWf tMvDzgcrU8bQE991Runaq9lqlwij9ImoOevtux2hXPL8br/oLt7jEm0O5r+Wq7mOxvdBTsMnkLIg f1QL372i/AEAAP//AwBQSwMEFAAGAAgAAAAhAEbxY+0DCAAAuj8AAA8AAAB3b3JkL3N0eWxlcy54 bWy8W9tym0gQfd+q/QeK96wtyZFiV5SU7cSbVOXiRHbt8whG1pQRowUU2/n67emBEQIhug3eJ5mB 6dPX00iefvv+cRV5v2SSKh1P/cFfx74n40CHKr6b+rc3V6/e+F6aiTgUkY7l1H+Sqf/+3Z9/vH04 S7OnSKYeCIjTs2TqL7NsfXZ0lAZLuRLpX3otY7i30MlKZHCZ3B3pxUIF8oMONisZZ0fD4+PxUSIj kQF4ulTr1M+lPVCkPegkXCc6kGkK2q4iK28lVOy/A/VCHXyQC7GJstRcJtdJfplf4ceVjrPUezgT aaDUDSgOJq5UrJNP53GqfLgjRZqdp0rsvbk0T+29E6RZSdqFCpV/ZBDT3yDzl4im/nBYrFwaDXbW IhHfFWsyfnU7K2sy9d3SHOROfZG8mp0bYUdoZvFZMne9YzxcoSprEYDjAEcsMgkBhHgYnEiZQA8n 4+Li5yaCBbHJdA6CAgCsLBYuKx6HuEKUZzZL4K5cfNHBvQxnGdyY+ogFi7efrxOlE5U9Tf3TU4MJ izO5Up9UGEqTlPnabbxUofxnKePbVIbb9R9XmGK5xEBv4gzUH08wC6I0/PgYyLVJMRAdCxPhb2ZD ZMSmJRxUaKO22tiFCiou/ltADmwM96IspTBl5KH+B4HQ6k1noKGxqGwAymXpOuou4qS7iNfdRWDy dvPFpLsWQJ5dI2Jzo5SV9KBmOrDJV/bD6PRAypodtSxq3VFLmtYdtRxp3VFLidYdtQxo3VELeOuO Wnxbd9TCeXBHIJC4qlk0Qm+QCvtGZZE0+w8S0KAj1eWtxrsWibhLxHrpmcZaVfsQWc4284ymKtLp 88lyliU6vmv1CHRnU7rP5uSPq/VSpAreaFpcP+zo+hsxj6T3d6LCVqjXNvlqNuGLyd4Wdh2JQC51 FMrEu5GPNqKM/d+0N7NvGa3KdQzrF3W3zLzZEltuK9i4wenNnrDyv6gUfXCwmMYNprQJJ8Vw3JCX zcK/ylBtVoVrCG8jY8vnjDBXIFDFwy46MSGqV1erFSYAFBNsu+CbgPIJ+tvmwpdvYkzR37aiZ8on 6G8b1zPlY34cji+baT6I5N4jldeEXbuXOtLJYhMVNdBKDxN2BTsImgnsInbySSQxYVfwDn1650EA 39woecqOxZZHGSjscFgULDa6LeygVGhvwLCIHaAK1pCB1Y1rGUBs0v0pfynzwxO3GSBLu3fN1nIe NXgAWhDpHfrHRmft79DDBs6jonyO4eeSVHo0tFFD5VHR8nyy/Y4R426NjwHUrQMygLq1QgZQQ340 v/O4nkgH6d4cGVhsWnZdDNOOzMwTNjM7IF4L6KlvEt6/Gqq3ORfqfZOAwg5QvW8SUNjRqfQy1zcJ WL31TQJWQ9dojlGZUzlGsftmGci9CRAs6oe8CUD9kDcBqB/yJgB1J+92kP7Im4DF5gbHqWXyJgDh I5yv+g6oTN4EIDY3WLbLfzMq+h5KOfzltgfyJqCwA1QnbwIKOzpN5E3Awkc4mVDBclRHwOqHvAlA /ZA3Aagf8iYA9UPeBKB+yJsA1J2820H6I28CFpsbHKeWyZsAxKYHB1QmbwIQPsLhhr3kjVX/4uRN QGEHqE7eBBR2dCqE6l5SCVjsAFWwHHkTsPARTjLkWJjcHKP6IW+CRf2QNwGoH/ImAPVD3gSg7uTd DtIfeROw2NzgOLVM3gQgNj04oDJ5E4DY3LCXvLEYX5y8CSjsANXJm4DCjk6FUB3PEbDYAapgOfIm YGG+dCZvAhA+8lwgjkX9kDfBon7ImwDUD3kTgLqTdztIf+RNwGJzg+PUMnkTgNj04IDK5E0AYnPD XvLGGnlx8iagsANUJ28CCjs6FUJ15E3AYgeoguWojoDVD3kTgDAxO5M3AQgfeQYQVhEnTP2QN8Gi fsibANSdvNtB+iNvAhabGxynlsmbAMSmBwdUJm8CEJsbzDlbOC9KPp46aEgC6jmD4lQDGXDYECQq YG7gT7mQCUwyyfbTIR0BCwsZiA3pQTXxQut7j3awe9SQIGQoNY+UxiPdT3hKpzSIMJocmCS4+X7p fbIDMLV9mFK7J29geqg8LoTjSWZwCPTMntYwsrMuTpYbaTAgZOa68hEgnEP7DANB+ViP2WzmfOBB HKrKl/H/tjkq/g0zb2HxzPHx1fno4ryYokKRdSWCJWgRwKzUASXyo/DudBIehK+q1HBeHtXaDmsU yuXn5rdvV/a5ndObsAQ+bNA7M2fED+iMZ8gPes/DR2y86wrC2Baq1KahO2+FT2fzyA6iwR+fYxMK GPvD/63ZkIePwoqF+5cyir4KHFvL9Lr50UguMnt3cIx9siJqrrNMr5r3J3iMHDXZJwBcXFbGXhoj mn0fb1ZzmcAc2AH/f9Omv+C82m7i2hOxNtyu8kB7zGuq15t12ykqV0Zw6F/FeNq/mrZ4xw4CoE5z AYN4381cXa3QYIjwvlh3Ai+hftpyaPdVDWF2C/X0YnLyJi+JpklGzKJ8jvHEXeyfY8xnJuFjZxh0 6l+KSM0TZeKGc57bFdQq/V2a20R9wNEwZXooGXYIJNikkIszQ3NVJtv1WHMYvK1HK7HYS0Oo997I tEWlOQRo8f/ivP3ZeiGiSOv9+Zrf42dsSejWw114b9d/o8vBYHxpff6iKXwjlnolShm8XQjSqZ9f 5elclOtgbDUrJ7hd6y/Bqw6upng5cl2TvITVluaVBtYctYas37o3Z4ztQj/+Lrg8ffcfAAAA//8D AFBLAwQUAAYACAAAACEAUut17OQBAADiAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcU8Fu2zAMvQ/YPxi+N7KToBsCRsWQbuhhWwPEbc+a TCfCZEmQ1KDZ14+yG1fZdppO5CPx9PRIwc1Lr4sj+qCsWZf1rCoLNNK2yuzX5UPz5epjWYQoTCu0 NbguTxjKG/7+HWy9deijwlAQhQnr8hCjWzEW5AF7EWZUNlTprO9FpNTvme06JfHWyuceTWTzqrpm +BLRtNheuYmwHBlXx/i/pK2VSV94bE6OBHNosHdaROTfkxwNbAKgsVHoRvXIK4KnBLZij4HPgY0B PFnfBr5YLIGNIWwOwgsZyTw+r6trYBkAn5zTSopIvvJvSnobbBeL+8GBIhEAy1uAXNmhfPYqnpKQ PIWvypCU+gOwMSJtXuy9cIfASU6WwU4KjRt6O++EDgjsDYA7FGmuW6FIMRzj6ogyWl8E9YsmOy+L HyJgcmxdHoVXwkRyLrWNyRBrF6LnjYqauKk25kOYt+WxWvJ6aKDgsjERjBqocKluuCHcd/S2+A+x dS520DBKzeRk4XTHH6wb2zthTvyzVzIEa2iCr0iy/Gd4cI29TVvz6uUlmM3/ScXDzgmZFma5uNiE rAQ7WhhsabRnwjcA7sh3r9OttEVmj+255+9C2q3H8cvyej6r6AzLdMZoI6a/xH8DAAD//wMAUEsD BBQABgAIAAAAIQChYJ8TVAEAAH4CAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMklFLwzAUhd8F/0PJe5u0laGlzcDJnhwIbii+heRuDTZp SLJ189ebdlvd0Acfc8+5X869STndqybagXWy1RVKE4Ii0LwVUm8qtFrO43sUOc+0YE2roUIHcGhK b29KbgreWnixrQHrJbgokLQruKlQ7b0pMHa8BsVcEhw6iOvWKubD0W6wYfyTbQBnhEywAs8E8wz3 wNiMRHRCCj4izdY2A0BwDA0o0N7hNEnxj9eDVe7PhkG5cCrpDybMdIp7yRb8KI7uvZOjseu6pMuH GCF/it8Xz6/DqLHU/a44IFoKXnALzLeWLmZ2+1Xii0q/vYY5vwiLXksQjwe6aqzkdfQmoYYS/9b7 Fgs72T8UzQfHeAyXDbMdbwQRhbTFcbaz8pbPnpZzRDOS3sXkIc4my5QUaVYQ8tFHu+rv0x8L6hTw 38Q8vyaeAXRIfP1j6DcAAAD//wMAUEsDBBQABgAIAAAAIQAJQx2XrwEAABAFAAASAAAAd29yZC9m b250VGFibGUueG1stJNRT4MwEMffTfwOpO9KYWzORWbcdI8+GP0AN1ZGE9qSXjf023tQhonLMtFY EhL+1/65+/Xu7v5dlcFeWJRGpyy65iwQOjMbqbcpe3tdXU1ZgA70BkqjRco+BLL7+eXFXT3LjXYY 0HmNM5uywrlqFoaYFUIBXptKaIrlxipw9Gm3oclzmYlHk+2U0C6MOZ+EVpTg6N9YyApZ51b/xK02 dlNZkwlESlaV3k+B1GzeZRfUMw2Ksl5CKddWtoEKtEERUWwPZcp4zFd8TO/mSfioebOwccgKsChc v5F7OQcly4+DirVE9IFKuqw46HuwEtal8CGUWwrscM1T9sRpxasV80qUsoSEh2WvxJSUX1G3Z9Qr dD2UWOvTboluWx9SyKc71eYZ+vs5IvEqlcDgWdTBi1HgUR0TifmESIyJR0NmNIiIbX1bggOIxA99 /VTJkkq5mSaH+r+I3J4n4n0GEIGCMj7RGgsC0TRFgyL5/9aIqDOevoOY8PGiK7sHEZ8DEfFoKIgl KJqRUySaVvAcmtYYNiS/a4njIeFJz6YnwduRoNH6y5B004LzTwAAAP//AwBQSwMEFAAGAAgAAAAh AAHidXZCAQAAsQIAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbJRSy07DMBC8I/EPke/UoYioRE0q VVW5IISgfICbbBpLttey3Zj269kmBcrjQE/7mh3P7no6e9Mq6cB5iaZg16OUJWAqrKXZFOx1tbya sMQHYWqh0EDBduDZrLy8mMY8wvoFQiCkT4jF+NwVrA3B5pz7qgUt/AgtGKo16LQIFLoNx6aRFSyw 2mowgY/TNOMOlAikwLfSenZki/9hi+hq67AC70mIVgOfFtKwkjTWsvNHm8Rc1gUb36bZXTbJbvr6 GuvdQnZU64Si+Rk/oLVwD9CEj2z6mX2Wm/aP9Artb+wcQ0D9I0965rU7vBG+egxtlhHQ7wtG+yfH iop23fsVKqS9im3AQYY6UXZe5/qbovN63enk57Ty/gj90INbTgfb3wVtkFruYYlu7jB6cP0BhFIY nx7vKSDwyUcr3wEAAP//AwBQSwMEFAAGAAgAAAAhAIXafrCYAAAA6AAAABMAKABjdXN0b21YbWwv aXRlbTEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyPvQrCMBRG d8F3CHmApjg4hLZQUCcRIYuDS5LeNIH8lOQW7NsbRHwCx+98cOB0iou0Zg2FCPCgESaBm4eePsf7 2DzElZIPuMlQYWXk4gxacp4cuhQpeQUfC1c9tYgLZ6xoC0GWJi0Q62dSDhLrzDNLxjgNp6TXABHZ oW2PTDnlXZqzXOz2lf1FNXTslzbsd28AAAD//wMAUEsDBBQABgAIAAAAIQAJQ8n7swgAACBDAAAa AAAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWy8W9ty2zYQfe9M/4HDd0eS7UiNp0onUZrEM2mb Rvb0GaIgC2OSYEnKl3x9FwsSokhR3DWZPsm8YM9ez0Iy9tffnqLQe5BppnQ89yevxr4n40CvVXw3 929vPp794ntZLuK1CHUs5/6zzPzf3v7806+PV1n+HMrMAwFxdvWYBHN/m+fJ1WiUBVsZiexVpIJU Z3qTvwp0NNKbjQrk6FGn69H5eDLGv5JUBzLLAG0h4geR+YW4qClNJzIGrI1OI5Fnr3R6N4pEer9L zkB6InK1UqHKn0H2eFqK0XN/l8ZXhUJnTiGz5MoqVHyUK9KGFUdw7coPOthFMs4RcZTKEHTQcbZV yd6Ml0oDE7elSg+njHiIwvK9x2Ry2cBzJlNi8CEVjxCKvcCGuCPOWNtFUWj9YOK7j2pd4mR8ypgi IkaE04GiwiFmqUkkVOzEvMw1VedCPfTJ70+p3iVOnUT1k3Yd3ztZpiwZmo2nWHlV0zKWgEbpLrci kb4XBVfXd7FOxSoEjR4nl57JSP8tUMVaBx/kRuzCPDOX6de0uCyu8OOjjvPMe7wSWaDUDVAISIkU CPz8Ls6UD0+kyPJ3mRJHH27NW0efBFlekfZerZU/MojZd5D5IMK5f35e3lkYDQ7uhSK+K+/J+Ox2 WdVk7rtbK5A790V6tnxnhI3QzPKzYm5yYDxcoSqJCKDyAEdscgkkBCxmcEJlons+A0azF992xrli l+sCBAUAWFUsXNY8DtwETLW0jA1P5eaLDu7lepnDg7mPWHDz9vprqnQKNDr337wxmHBzKSP1Wa3X 0jSI4t5tvFVr+c9WxreZXO/v//0R6bmQGOhdnIP60xlmQZitf38KZGJoEkTHwkT4T7MAOAzCUcFB hXZqr429UUPFm/+WkBMbw6MoWylMS/NQ/5NAaPWuN9C5sahqAMpl6XrRX8RlfxGv+4vA5O3ni1l/ LWAj0zciNjcqWUkPaq4Dm3xVP1y8OZGyZkUjizpXNJKmc0UjRzpXNFKic0UjAzpXNALeuaIR384V jXCeXBEIJK56Fl2gN0iFfaPyEPpkB9NNelJd0Wq8ryIVd6lItp5prHW1T5HlcrfKaaoinb6cLJd5 qs12s8Mj0J1N6b6Yk3+Pkq3IFOzKu4B6uv7GbH28T6mC7WsH1GubfA2bcGNytIV9DUUgtzpcy9S7 kU82ooz1f2pvaXcZncr1DOsXdbfNPdgVmpbbCTZtcXq7J6z8LypDH5zs5tMWU7qEk2I4bcnLduF/ yLXaRaVrCLuRqeVzRphrEKjiaRddmhA1q6vTChMAigm2XfBNQPkE/W1z4cs3Mabob1vRC+UT9LeN 64XyMT9Ox5fNNB/gZxWPVF4zdu0udKjTzS4sa6CTHmbsCnYQNBPYRezkk0hixq7gA/r03gUBfHOj 5Ck7FnseZaCww2FRsNjotrCDUqO9CcMidoBqWOcMrH5cywBik+43+aDMj8DcZoAs7faaneV80eIB aEGkPfTfO51376HPWziPinIdw88lmfRoaBctlUdFK/LJ9jtGjPs1PgZQvw7IAOrXChlALfnRvudx PZEO0r85MrDYtOy6GKYdmZlnbGZ2QLwWMFDfJOy/Wqq3PReafZOAwg5Qs28SUNjRqfUy1zcJWIP1 TQJWS9doj1GVUzlGsftmFcjtBAgWDUPeBKBhyJsANAx5E4D6k3c3yHDkTcBic4Pj1Cp5E4DwFc5X fQdUJW8CEJsbLNsVvxmVfQ+lnP5yOwB5E1DYAWqSNwGFHZ028iZg4SucTKhhOaojYA1D3gSgYcib ADQMeROAhiFvAtAw5E0A6k/e3SDDkTcBi80NjlOr5E0AYtODA6qSNwEIX+Fww1Hyxqr/4eRNQGEH qEneBBR2dGqE6japBCx2gGpYjrwJWPgKJxkKLExujlHDkDfBomHImwA0DHkTgIYhbwJQf/LuBhmO vAlYbG5wnFolbwIQmx4cUJW8CUBsbjhK3liMP5y8CSjsADXJm4DCjk6NUB3PEbDYAaphOfImYGG+ 9CZvAhC+8lIgjkXDkDfBomHImwA0DHkTgPqTdzfIcORNwGJzg+PUKnkTgNj04ICq5E0AYnPDUfLG Gvnh5E1AYQeoSd4EFHZ0aoTqyJuAxQ5QDctRHQFrGPImAGFi9iZvAhC+8gIgrCJOmIYhb4JFw5A3 Aag/eXeDDEfeBCw2NzhOrZI3AYhNDw6oSt4EIDY3mHO2cF6UfDx10pIE1HMG5akGMuB5S5CogIWB 3+RGpjBVKLtPh/QELC1kILakB9XE91rfe7SD3RctCUKGUqtQaTzS/YyndCqDCBezE5MEN38tvM92 AKaxDlPq8OQNTA9Vx4VwPMkMDoGe+XMCIztJebLcSIMBITPXVYwA4UzoNQwEFWM9ZrGZ84EXcaiq uI3/ty1Q4W9AxIVNqGALWAFMRJ2AKg68uzNIeNy9DtxyKh4V2Y9klGoWp+P3eyj73sEZzZN65+Yk +Amd8aT4SR95+IqNalNBGM5Clbo0hJCtQjtiBn9cx2uw8LGYzrLBXD8JKwqeL2QY/iFwIC3XSfur odzk9ulkjB2wJmql81xH7etTPCCOmhwTAOlQVcZeGiPa8yTeRSuZFsfNW1PSdA6cRDtMSXvWtSUV qJ5u1+2gXFyBwHF+FeM5/nqq4hN7xB91WgkYsfvLTMw1SgjGA+/L+07gAmqmK28ON2EIAyPgJjsQ Yzx+8352+UtRBm0zivi/12JC8dJdHJ9QLKYh4eNgzHPuL0SoVqkytYITnPs7NsG/VyYyUR9wNMyP nkqGA9IIdhnkIk4+1jnq0GPtYfD2Hq3F4ij1oN5HI9MVlfYQoMX/i/OOZ+t7EYZaH8/X4hk/YytC 9x7uw3WH/rtYTCbThfX5D03hG7HVkahk8P5GAKPVxVWRzmWJTaZWs6yS4PbecAled3A9xauR65vk FayuNK81rfaotWT93r0FY+xvDOPvksuzt/8BAAD//wMAUEsBAi0AFAAGAAgAAAAhAGEq9daaAQAA EgYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEA HpEat/MAAABOAgAACwAAAAAAAAAAAAAAAADTAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA kmzaLzkBAABHBAAAHAAAAAAAAAAAAAAAAAD3BgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVs c1BLAQItABQABgAIAAAAIQD+wIelKwkAABg2AAARAAAAAAAAAAAAAAAAAHIJAAB3b3JkL2RvY3Vt ZW50LnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAAMwSAAB3b3Jk L3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAkFh9oTwDAADNBwAAEQAAAAAAAAAAAAAA AACnGQAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAA AAAAAAAAAAASHQAAY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh AHg3M6zhAAAAVQEAABgAAAAAAAAAAAAAAAAAGB8AAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBL AQItABQABgAIAAAAIQBG8WPtAwgAALo/AAAPAAAAAAAAAAAAAAAAAFcgAAB3b3JkL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAUut17OQBAADiAwAAEAAAAAAAAAAAAAAAAACHKAAAZG9jUHJvcHMv YXBwLnhtbFBLAQItABQABgAIAAAAIQChYJ8TVAEAAH4CAAARAAAAAAAAAAAAAAAAAKErAABkb2NQ cm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAJQx2XrwEAABAFAAASAAAAAAAAAAAAAAAAACwu AAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAAeJ1dkIBAACxAgAAFAAAAAAAAAAA AAAAAAALMAAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAhdp+sJgAAADoAAAA EwAAAAAAAAAAAAAAAAB/MQAAY3VzdG9tWG1sL2l0ZW0xLnhtbFBLAQItABQABgAIAAAAIQAJQ8n7 swgAACBDAAAaAAAAAAAAAAAAAAAAAHAyAAB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLBQYA AAAADwAPANwDAABbOwAAAAA= --_002_5BCBA1FC2B7F0B4C9D935572D90006681520B965DEMUMBX014nsnin_-- From nobody Fri Sep 26 03:43:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B653A1A1AD1 for ; Fri, 26 Sep 2014 03:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAQKnywwZh_X for ; Fri, 26 Sep 2014 03:43:26 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72561A1A96 for ; Fri, 26 Sep 2014 03:43:25 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-7d-5425434bb1ad Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.DE.24955.B4345245; Fri, 26 Sep 2014 12:43:23 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 12:43:23 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0IAAAbHw Date: Fri, 26 Sep 2014 10:43:23 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja63s2qIwa/7JhZze1ewWSw/3sBs sen8OhaLdW9XMDmweLQ+28vqsWTJTyaPn+uvsnt8ufyZLYAlissmJTUnsyy1SN8ugStj3v3l zAVHrCqmvtzG1MD4Wa+LkZNDQsBE4srTDUwQtpjEhXvr2boYuTiEBI4ySnQ/P8gI4SxmlLg8 bTUbSBWbgJ3EpdMvmEASIgJNTBKbPk9jB0kIC2RJfOjbCmaLCGRL3GpdDtTNAWRHSby6kgQS ZhFQlTh6ZyfYHF4BX4lNO2exQyy4xywx/d8qsASnQIDE7k23WUFsRqCTvp9aA3Yes4C4xK0n 86FOFZBYsuc8M4QtKvHy8T9WCFtJYu3h7SwQ9XoSN6ZOYYOwtSWWLXzNDLFYUOLkzCcsExhF ZyEZOwtJyywkLbOQtCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhTB7f8Vt3BePmN 4yFGAQ5GJR7eBSdUQoRYE8uKK3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA6OT4u771y5c+/onhnuWUYtz5I8nTd0T30kwc9uasNxfn77O4Pnp6b+Uq6RjnkU83LdO IItl9jvjvdm1BqlzWZwephsYCf9gfGB/bTrLYkmuJg4JA6dvFxz8uCX53q7/9+9W498De4Ok vsiW2u3/aMB6Uy88/0byBQnNRRs5Owq9ioyipjRwTVRiKc5INNRiLipOBADfe9cLigIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/wGFwCRuP_bw6kEkyPU4K-gjgFqU Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 10:43:29 -0000 Ulrich, Your clarification does not contradict my understanding. However, I think in clause 6.6 it is better to clearly state what OC-Report= -Type identifies first, and then how the reacting node identifies if an ove= rload abatement applies, and for this, refer to OCS, since this is what the= reacting node will use to apply abatement, if required. This is my intenti= on with the new proposal. I hope this clarifies. Regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:38 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different.=20 Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 26 03:54:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6251A1ACC for ; Fri, 26 Sep 2014 03:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSHYN00RceVS for ; Fri, 26 Sep 2014 03:54:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA911A1AAC for ; Fri, 26 Sep 2014 03:54:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8QArvmJ030453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Sep 2014 10:53:57 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8QArugA011889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 12:53:56 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 12:53:56 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 12:53:56 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0IAAAbHwgAACWwA= Date: Fri, 26 Sep 2014 10:53:56 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520B98E@DEMUMBX014.nsn-intra.net> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8249 X-purgate-ID: 151667::1411728837-0000437E-B6DC0F62/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5yZxDiTcJy33jivSSDSfQkc6Jw8 Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 10:54:05 -0000 Maria Cruz, thank you for clarification. I think there is a (maybe minor) difference between your and my version. According to your description, a request that does not contain a destinati= on host but is send to a direct peer which in a non-overloaded server would= potentially undergo throttling according to a realm type OLR. Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 26, 2014 12:43 PM To: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Ulrich, Your clarification does not contradict my understanding. However, I think in clause 6.6 it is better to clearly state what OC-Report= -Type identifies first, and then how the reacting node identifies if an ove= rload abatement applies, and for this, refer to OCS, since this is what the= reacting node will use to apply abatement, if required. This is my intenti= on with the new proposal. I hope this clarifies. Regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:38 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different.=20 Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Fri Sep 26 04:13:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217581A1AF7 for ; Fri, 26 Sep 2014 04:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtgoBRcyY449 for ; Fri, 26 Sep 2014 04:13:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B2E1A1AC8 for ; Fri, 26 Sep 2014 04:13:40 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-99-54254a6143b0 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.54.02247.16A45245; Fri, 26 Sep 2014 13:13:38 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.19]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Fri, 26 Sep 2014 13:13:37 +0200 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0IAAAbHwgAACWwCAAAZ6kA== Date: Fri, 26 Sep 2014 11:13:36 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920983BFF9@ESESSMB101.ericsson.se> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B98E@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520B98E@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/mixed; boundary="_002_087A34937E64E74E848732CFF8354B920983BFF9ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM+JvjW6Sl2qIQfNScYu5vSvYLJYfb2C2 2HR+HYvFurcrmBxYPFqf7WX1WLLkJ5PHz/VX2T2+XP7MFsASxWWTkpqTWZZapG+XwJUx8e5B toKlHUwVn49uYmtgPPWVsYuRk0NCwETi/pYeJghbTOLCvfVsXYxcHEICRxklFr1ZxA7hLGaU mPTjBAtIFZuAncSl0y+YQBIiAk1MEps+T2MHSQgLZEl86NsKZosIZEvcal3OCGFnSSzc0svc xcjBwSKgKnHgDjNImFfAV6Jt7xKobS9YJKbvnwG2gFMgQOJCayvYSYxAJ30/tQbMZhYQl7j1 ZD7UqSISDy+eZoOwRSVePv7HCmErSaw9vJ0Foj5T4kDfQxaIZYISJ2c+YZnAKDILyahZSMpm ISmDiOtJ3Jg6hQ3C1pZYtvA18yygW5kFmhklLn0+AZTgAHIsJHZ3SkDUHGaUWHMLar6ixJTu h+wLGDlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG7cEtv612MB587niIUYCDUYmHd8EJ lRAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYYxyy9FWH 6VsTD/ZXrKHPLNm91dQC/Crk7lluPP5YX1I9w6lpj/2S2z6Vq1lKF5xxs07nu+d+hsPmbZtO 7ImTWzeIOagdv+FspbnqWNfDQxc74pW/fO6WF/i2dqKG4kZOuXzmT2cmyx8VnskpEJv18Y3G fpdb5zf8WXBcN3hGn+1DewXPLbeVWIozEg21mIuKEwE/y57tvAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Sc58thDB7gRAOnu8_8gHBPaE0-U Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Sep 2014 11:13:45 -0000 --_002_087A34937E64E74E848732CFF8354B920983BFF9ESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Ulrich, This was not my intention, but text may be misleading. I modified some inde= ntation, to be clearer. Let me know if this is alright now. Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:54 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Maria Cruz, thank you for clarification. I think there is a (maybe minor) difference between your and my version. According to your description, a request that does not contain a destinati= on host but is send to a direct peer which in a non-overloaded server would= potentially undergo throttling according to a realm type OLR. Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 26, 2014 12:43 PM To: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Ulrich, Your clarification does not contradict my understanding. However, I think in clause 6.6 it is better to clearly state what OC-Report= -Type identifies first, and then how the reacting node identifies if an ove= rload abatement applies, and for this, refer to OCS, since this is what the= reacting node will use to apply abatement, if required. This is my intenti= on with the new proposal. I hope this clarifies. Regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:38 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different.=20 Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_002_087A34937E64E74E848732CFF8354B920983BFF9ESESSMB101erics_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="OC-Report-Type clause 6-6_rev2.docx" Content-Description: OC-Report-Type clause 6-6_rev2.docx Content-Disposition: attachment; filename="OC-Report-Type clause 6-6_rev2.docx"; size=17758; creation-date="Fri, 26 Sep 2014 11:03:42 GMT"; modification-date="Fri, 26 Sep 2014 11:11:38 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lE1Pg0AQhu8m/geyVwPbejDGlPag9ahNrPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX 0QI8KmtS1k96LAIjbabMLGWv08f4lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6 MHSSW69FoFs/407IDzEDft3r3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI +cJk31zirUNClZt3sFAOrwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4k NPWVmvNWAiJlrsukOdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNM vv6CcVfouFXuRFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ ou3dgqiqYxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAe kRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3 IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJn DUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamaba WQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1 RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAI AAAAIQB8O5c5IgEAALkDAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTTU+EMBCG7yb+B9K7FFZdjdmyFzXZq67x3C1T aISWdMYP/r0VswrKogcuTWaavs/TSbtav9VV9AIejbOCpXHCIrDK5cYWgj1sb08uWYQkbS4rZ0Gw FpCts+Oj1R1UksIhLE2DUUixKFhJ1FxxjqqEWmLsGrBhRztfSwqlL3gj1ZMsgC+SZMl9P4Nlg8xo kwvmN/kpi7ZtE8h/ZzutjYJrp55rsDSC4AhE4WYYMqUvgATbd+Lgyfi4wuKAQm2Ud+g0xcrV/JP+ Qb0YXowjtRXgo6HyRmtQ1Mf/3JrySA94jIz5H6PoyL1BdPUUfjknnsILgW96V/JuTacczud00M7S Vu6qnsdXa0ribE6JV9jd/3qVveZehA8+XPYOAAD//wMAUEsDBBQABgAIAAAAIQAxqcuxQxMAAHCc AAARAAAAd29yZC9kb2N1bWVudC54bWzcXdtu48gRfQ+QfyD0kg0wGou6Wt61FuPL7g6QxRgeJw95 CWiKtoiRSIWk7PU+5Tfye/mSVF8odpPdVJVE0fYuFmNbFMnuupw6Xd1d/cOPv62WzlOQpGEcnXfc j72OE0R+PA+jx/PO3+9+6p52nDTzorm3jKPgvPMSpJ0fZ3/+0w/PZ/PY36yCKHPgEVF69rz2zzuL LFufnZyk/iJYeenHVegncRo/ZB/9eHUSPzyEfnDyHCfzk37P7fHf1knsB2kK77v0oicv7cjHrapP i9dBBO96iJOVl6Uf4+TxZOUl3zbrLjx97WXhfbgMsxd4dm+cPyY+72yS6Ew2qLttELvlTDRI/sjv SCq9MLxX3HklJcDfeJIES2hDHKWLcF10Y9+nQRcXeZOe6jrxtFrm33teu8PK+7ZdxujgKvGeQRXF AyuPMwhjLm5aLYUcmH4LrZaf6PbqOiM1wh6xbQOmCfo785asvDDaPmY/0ajCBY84xL5/TuLNetuc dXjY0z5H37bPYo5JaFlvzD1P7VpKekDFdb8uvHXQcVb+2efHKE68+yW06NkdOswiOzMAi/t4/sJ+ rp3nMwCb+e15p9ebXkyGp24n/+gqePA2y6x65Ub5iD/kJuE/vmYvywDufvKW552bJWj7Lvgt65zM fjiBN4kv8W9ms/HHMfsw45fE3UkcP1wnCdyfvayhvY+Jt/qaeQl/ALSSvSKbfXScL5eYW6+jOXvz 9sbubbCOk6x7Bw93Pv3jRnsGax/vQt53pYf5R0cQxyu9NpcJg/azdO35IO11EqRB8hR0Zo7j3C0C kHJZYs53IDYHglHg3F1cjf7qhKnDVOXED851BLEn8bJgDgqC29+CdHd2U2skWADOAsG6N3r/LLeW LNAibRBeBuJmop0HqZ+E90HqlFo2D5ZgheEcrJJ5p7fJFjHExV8vk83v7IM5CP68AzF82O1Nu/3x neue9U7Per1/drgHSBO+CsAve73BpeuOL/kVeDBzUXPTnhdexlsiv5X7KlgtfMIeHEapbBdHjX3b xcFHaZWlPUxMV6G3CrIgAVaUAbdwYvlbWBYaNBJap/g/uzsGZrWMvbmTcCwAW478IInSkriLbvXx 4p5WxI3slpPF2vsrLf/De9RDvFzGjOdocjjIq7iTpo6XBE4YhVnoLZcv4F8PYRTMz7TXvBIGG18r fUC6622DEQewUMTfwrYHVNsWcZw/h7VejedmAIFIoonaotFqkO85zifMnTiEXcRpJj0eXKn03EIe Q6o8VGjF+rr29tzTibagWwmdjBlsYYTuu9vnOGe0hUKWMN7DhikFN5lALdgPpgT/fc6ccM6Q/4Hh fcbiE4N1oCpf/nbLQ2iO6HZQLRo5QTdSdlqJJhUMgccKmsu+pLFqXV2qU+tXuCLlR/whO1m1QZGQ HkAKHqfIKfV5hYysmOB0dSfM3UDjEwSig7QgryAPHBG2ljR37l8QLcJTHLdXcAEmj2zGrTQJH8Oo +wtDI8b2ksAPwqdgDgGKW/GW2nhR+gwMp2TZQLbDyF9u5kCxj4Qihxqfi6dL7hADIy4+RrmDkszr zM9RbCEJvOWqgBVuDIq6bvnl1vTVG/TH15fM6fioXGEA+hUOFvKjvcECcgFotMDpixBHxANxcKF7 J5pGeJqfWG7DcYjCOdfrZejzxKLBaD4VV7ufr9jAmJlSfrPWnBz1jMFfV7YaM/QrzZgBPloj3ZYQ WfFm4Di/BN4cgLEV4NTlvEMDBwMnIWwLnDPwL6Mh6RRD7YZ+pREW6eLZQk8EbWw39MykzGPYVaR/ /YC+QZ4DEJIlXvp4QuKO7LFNeSCBT4gHcqyUkUEXAbsCT2apnNmdmufIILplfFIoXcSb5dzxAKBe gByDE/17E6QZT33ktzJ8gjQr/AufWNisLlq9GYaopX+9GU0QWAZOEwSWQdCEnYA4DsyZOc+L0F84 kJjIw8Q2DcLyUnNIWsDcFc9gZMkm4AOO/RWlev6hOmFAw8YmRsDRH/4q9kFgNTj7ILCahuzjOgTe IIYAV+ClYcQJRzF2gMHAmiXsYbZXjh6kPzswNeyE79KtCSwEpzYCC2lIbTzr6MBUMcy3s/xE4IhP JA/8UhoBwscSbDlyl+CXo3AeffAEoacwKj1YKCxFAokZoli7se3CR3wZFXFBLKd4Nc14o+gzaJon DI7DE8yqF2m2FSwA8R4DMGBIsEEsymAmF/IUNcpQbXWAj8+t2urgOGF+VmQfv2fTUcx7KpgdvkOe NWg6jg7aj6NRnNkC5f1GJI+3CL0OIOKKpGD2UmPrbxV4mo6fg/bjp5emsR+yVQTOMzAg7kuAP1Hg MzLsbFK4AGMX4D3wE/wsJz0y4r5DpeHjOm5UOThOQK6LFg3SnCE+eLYaOobHicGznOY4asR9f1Y8 xEd8nBUPjxOq66yYTHOG+PDYrq0eJ8oqNIdPP+2finiNnMCwieD4RgP/kBynDVlXlcAPyUEJNair 87678lBZZdDFFFwp16EMtN8haJIj9Q61jfDBkzIWr1PbljszDiCzG4W2ZNbjDxLkRmQOsEtf5Kh5 sJsVQY4rbLts5h0i+ohMEQzqeKOIPsJTCxyfGh2HE9RBQwXRS1Pj5UUvcm5XYMb7Q/NREwRDDcIj clQ/GB1Ko2k+wtYQvqRCie/q6ob3xQpHZKJjwBBNaeSYfrDSNL8plkaoA0olhdso7Lc2p3gxHfzU vzAtitJnGw+YXi5WhY4JNGpsn+iH+dG6xawM4eibn9xG10XD2gBY+Sa2QpQXRhsjo10P+hWuB/kR E4NcKr627w8zrGQdE/hWjR4UxRL4lnggd856PVIXJRPWDesyVZ1Nv9KMtAl0CidtAofBS7vrvN2l m7pWjq0vAqPD6YtAYEj62g/p3u/SzXbNgMAScWZAoER4M2h36SZJA5JB7B+mCJTPqgFjtNW5jcya 2vumf/0AKgQcXq46mRCo0MROhZQHEmK6eCAPwfoyFikCdiUfbrDB5nZvZ0trHtvVBIG74DRBiPcE TdRlBFpf8/gqLkOgPVZFvVU4IHAOa9/U4fKEwDkaMkKGFOrcwnY3Fqyo9O4NCyqbSY22CxYEUmDV 01u1QQI/sfZNs0FC/G7QBrW8mmqQxfTJkSe7WjXJ06aZhChTgyo44WLUtvTS7BaWFQVJML+BtY8X kBz5Btm+Lceoi2yaMtufBmtXk00zkdP2mchxp8HaVccfmG+cNs03Tl+Hb2jwUJpDOf40WLvm2AT1 UMPzKTneo0aMdWj+FqbB2lUamQLtmAabkqP9wUp7xWmw1xhmTsmJFIPK3ijFnzbNMKbtM4xr2L4Z J39JHdiAEJyxgnisEFUKpVtD2O/pRQ4r2wkfpBtIXInyH7w4Fd/0CftBG1kA0SqITJsgIiryT8nR /2AQEWMvMSEK6QDYZPC8CGDKnO3VhZ1QsmgcK3kImhT7qe8DJ92sWWFJWZYlT0kyDe61l7pdrZEZ kQFHNK2RCcDBWts6F9B6SOCkG1kZSin7ZVYXL1SZ8FKO70xrZFK0S2tkBnCw1gAM52Hqb6DUNAAg /F91Pv5J9zbegG9BLVJer0A6YfoO03Juj0yLdqjN7ZFpwMF6YwlU7x4mW0Q1RRGwWFUJXpEtFmq0 KI3B6Xv0N7fXNCVxe+1zkpKDASGR9TDZljqmQV4XhNWjkCMgiaN8lT1bDPj+SInba5qVuL32aUnC 1ml9gEIP8wBYI6t/mFcMWfMaEH7wQcxd+EAmE63kwGEqu72BIsPlsuCvMdxx2QEC2LqGqLS/22uf qBiUARxRTm4jZM2wOycq6pRBPodFjon2Akr6lQMWExTL79wegbVYC3wYx6yD8ehUlAosF83TyTTv h+waE+Ze6xLdHp4sDUQhSGMYVyTjkokBD+PsH0u5VBalATZg23T0qBfPAwHCm9mtagMIPEIpK17T gIhViWcGv13kan4xObDu6nm6YBEM8WZ8AO4rXc69lddRF2bHpTALWJYXdq4j3kyOSbv6jOkuIWwp 3a3RMFvOARa2yNnCdqwMn7OyC5DkQMiCgOvKcjNVC4o/W5zBvjII0UBCmMDJDTIGiNcSsFKRizBF xuUQr8DDmIvrWRjMPyD6Rqikh/E8cypfFvd9YfiXJ3F2y6SPx0EJ7dw1VXOUsajGcbwIU224j0fG /aW0DRFfLr9iNIfHTIx4ZmzNDRs5+uyAGuCwKdTFYycBpIRV8lDUajy8Mu0N0VlBM7G/j8fuAa5i bh8PzKpMa+wLU127j8fdARwlkp8jIvAFqrBDfTP/m35shjG+9/HwieydE8qauqSyeAjXxyOu1GzV 9YUpCiFxMl4hPyCk6jlDuqGqGwd0427IhPG4L1W/i74SSp6pohNy6jqfaxW6W3OEAmkDpUg4DbTz KlIUZLKOSnSFc7X+dDGcXl13mEwwoxLIBUD7l8EDnM7VPx3Kg67KJ3y4hFJsA+uQSxspEIqoVYDD HKlLcAX9xx3DFGaaaVjuw1X3FnDGoAVKZ8oEivZ0I7gRCqQNxKkZHDK43ZtloRS0KNI4UKu+jHWw agTHIggl10bVGpj8UJPLT+PLC3FalIVfs4mWLj8IDCEzQuApywxK0HylwKqdGWhXjul/hPCHowsD QphSFFpjc11m9sLwUPSdUGFsgBw35Hwij+2fBClkNd9YFf3aNVLb4afRdyBr7ZSetttGCVXIBsrZ I2pAOb0awWmKHM6zGRspZwsgu2C/iLfjxyBDRcO2t5uBBjNOI1T1GlaX2HLsUMVgbgjYniYSdS7Z NZQB46Oi6nF3ENerZW/VJkjxyOS1Em3zhGrKD2HL/2Jt0mfvq0kzQwEwcuuUhmQz6YSaPIyBZ4gf M+yvmQ+8/gOiMXhE399ei2Gibi5m8eBRd6gkT2geRAl6hIJaGBGxOIjQC57n728kbE1TcY7S7kYR alShJHEsOiAHXlg6XjlbzyVUi0ImCkb4hBB9lCX3PhFGNxK5cqdRDioyDFoVmGtwdGMoAWUHYNzw hlB5aVjOi5gDHNCrLb1B+AcB2Sv0GGIp4zvb5eZaQWPIrtXW1oU1AJCZtlbY/c7zfTgEnKVT4Zth BEewRt5ye7KRA2dp87mmjKXy0r/mNfARPSaED2X0XkNoERGCUFxpWBazWc2F4BFdxnP4Ia7LUInp kFHiCB8q2hklEmrwVCSEi46G6jK7sIOZ3Ha2ns3/KaiWzRqBTsmXJageOjCdwEwL5O6g1ZXE0Lga THZ1f1cWcIyfHFBCOxBu6C07YAnS+JU1HrvapKrETu0/MJe0MHtO863T6DYo2ZWiUqbWxwREV0ZR HN9mIV8Ivs0iH5Tj0nBJG2aNqxBsF3x1mGUXPH1MNa5Sd0pT+IhPc0v0mGpMAOWynswhATuAGuPR V3EcGJ1azZY0WiIU+VBHSzWvpwyNJvtlO4R7oMZBE25AqJ3C6jiopn/UQc+kiowHGbXZ3L43gxVA X3XGSY8z6oyTTuuPGIEmVbRn8F9N7bhnI8G0dwWgSRVp7WJWMmc1mi7NTRizDYYiFvbXKugpTDgG 4pg8hyli3dCkio02iQ2LxKsSYCdViEO1NB/jMc6jW44d+nesRaxm0yYEFCySNkrvDCUGjtU7swNy /4MGmc7yMloOoYaBWaGnvIMatLXbZRhxsqVe2uzBTgnURS4dw7SZR0KdgCEmK18My+W4WZ1lE2vl 2anP1SocGpEyK5aAbcpR4QY/EyDhI15ZBT8rOGCkI8+vs7x4XxVWieYhjTS74Tb9YWm7ws1P8Yg6 wuhJL1poNo0qBjcvAt2LzO3Awy2q64rz7JY7YX84xpXNdgA7xlh5W0Rr8BQUIwpza9Az9oTdz/vn YmDd33KFnbInbJ/GyAeXnzFsJ7aHNgXQasicdc7zPo6/rbzk29fMS7I8GyG2H0feKjjv/Ovn+MLz v4lkSv5tWFmifJfnWRRomeKhTtJb1vLEGgIgRm2jbCVylWa4a+fLLf6wJ6JPCQiq5Mut3aTW3lCn 1mGH1IOTxmLYrQyBFWOHAaM+eCPMH+nMVx0z6Vf4mOng+aMpIU6IHLFheATIXx376dMzaj/0K7wf yuJ6zMRNNdE4xceZQc3GrcKz+oRdtINioFBn36JYw//+89+8XIPFR9RG4GOG7BZ37xp04gtEMjjA nVXrT2FONREHCCPaUh0F2CgFUiAwVbRZrfmRi/wIWJhbCAEIYc7HYbkd2K0Ne0UhB/oEzYSt9UHy FMLWQ5gXiiMohwBzREu++2i5+igWd7J13sUj4S++P8T3gzWfLrICsyrwag7F2slyem5WyFZWbQgj f7mBDUr51LXPj9fOd1Uq2LHtNwcRAlrovnRkL+sTtrn2rWihjrb6hG2uSKMyMzEjRI177sh83oN+ hUOURF/mWrshir1OPbo+hZNFb7SoK9/AH/f49XeIVM8wN9Hvi0VhC/h9dAq/83i/fvzVYzdn8Ro+ H4qvwBnfC1iVm/95H2dZvCr+Fmt286uLwANPP+9MxObIhxjKxRR/Pm4y/qd8nR8vU3hbuvZ8ICXs Ft6Keez/nIR8PTAc03wTwuHj550BTKGJiCC6OGM4ch/PX/gvcMtmBfuIZ/8XAAAA//8DAFBLAwQU AAYACAAAACEAMN1DKagGAACkGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3 IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCv sEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjx hLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZb XYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7y EMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHP ALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DF N+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjz RC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3 r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJn Js6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9 nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG 7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00y pCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjB VPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/ kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bH NPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi /K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFn MjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2c nzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw 8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuL k8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37 U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9J AXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ry jZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuM dKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ 6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH3 2hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzG y81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0 KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k 5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQUAAYACAAAACEAi/o6 F80DAADpCQAAEQAAAHdvcmQvc2V0dGluZ3MueG1stFbbbts4EH1fYP/B0PM6knyLo41T+LptEW+L VfoBlETbRHgDSVlxv36HpBg1jRoUW+yTyDlzn+GMbt89MTo4Y6WJ4IsovUqiAealqAg/LqIvD7vh PBpog3iFqOB4EV2wjt7d/f7bbZNpbAyw6QGo4Dpj5SI6GSOzONblCTOkr4TEHMCDUAwZuKpjzJB6 rOWwFEwiQwpCibnEoySZRa0asYhqxbNWxZCRUgktDsaKZOJwICVuP0FC/YxdL7kRZc0wN85irDAF HwTXJyJ10Mb+qzYI8RSUnN8K4sxo4GvS5C3ONtxGqOpZ4mfcswJSiRJrDQVi1IfLEOHPatLJK0XP qb6CVMfedmxVgXiauFPnuaav5Huq7at4TwqFlC8zNID1gpXZhyMXChUUmqpJJ9EddNRXIdigySRW JRQJ2jFJotgCEIw45AYZDLCWmFLXnyXFCJQ12VEhBp21iDzFyVT4gGpqHlCRGyGB6YzA5+tRq7I8 IYVKg1UuUQna1oIbJWjgq8TfwqyhSxUk0Tvhe9a640+573+Q4IhBFJ7a9vReVNh6VivyKlE/TLQV cF5CPlwM/YYEvFdFKgyhUZybC8U7cD4nX/GSVx9rbQi8EtfZv+DBWw5gbi1/gtf9cJF4h5GpIU3/ kzFXiR0lck+UEuoDr6A3ftVYHIpoywnDr9Lh8I8QJpQBxtJydL3d+VxYtg5JxqPZdt2HjGfTeTru RdZpOuuXWaezyaZPZjJJ0u2oD5kl6XS06kV+6PX1cjxd9crMN9Pkphe5WV1P5mmfnVU63SX9yM14 1+/bejlbr3pzsJ0ny2TaZ2e3mtxsthaBurXVYpkduJ/V3a0/2ScwYP75rBErFEGDvR3JIMWyQj2u CA94gWEl4W+RvC4COBx6QDNE6Q5mRADc4GBZRbTc4INTS/dIHTu9LYfqpcI8+visy843rP5Sopbe WqOQ9K0dzKVQeY8Rbu4JC3RdF3mQ4jBWv4FqXn06KysUd+lpMgPb2I2Ie8SPoYMxH37JLSu8BKpy u7HxHkkJoxBYimO6iCg5nkxqn7WBWwWb212K46jFRg6Dm8XcBZU2MuBuD5bBH4GrPXS0caCNOxrs Jc836WjTQJt2tFmgwZ9Dk51gDilYCo8wbMPR0g+CUtHg6n0gLqJXJJ8EfUISQ13tzoBhIDJHaJeI Hpwz/AQbCVfEwA+RJBVDT3ZBjWZWvOWm6CJq84LXYpZZvqAOKmQQiLtSvRB2Lf6dL01W4ZJAO+YX VnQr6g/vOCXa5FjCNjNCQchugfzpNHf/aHf/AgAA//8DAFBLAwQUAAYACAAAACEA2JqDi38BAABM AwAAFAAAAHdvcmQvd2ViU2V0dGluZ3MueG1slFNRT8IwEH438T8sfYcORIILGwkhGBNjjOIP6LqO Nba9pi1M+PUeGyCKD/DU6933fb27bxtPvrSK1sJ5CSYlvW5MImE4FNIsU/KxmHdGJPKBmYIpMCIl G+HJJLu9GddJLfJ3EQIifYQqxieap6QKwSaUel4JzXwXrDBYLMFpFvDqllQz97myHQ7asiBzqWTY 0H4cD8lexl2iAmUpuZgBX2lhQsOnTihUBOMraf1Brb5ErQZXWAdceI/zaNXqaSbNUaY3OBPSkjvw UIYuDkPbjuhOCum9uIm0IpHmydPSgGO5wg3WvQHJcH2FXPv9GdWJLFLSv4+HD8PR8K6p51BsZnKN tTVTaA2hOzQu71mU4ZCNj9k3uaz+SS/AnmOnEALoP3nsZ1q43Rvhh2PQdIJAv00JfhoYWMZxiCbm oAC9YqsAbRvqpLPrmPmvjq7jutPJr6HSxoRm6DbMxu3Z+AI2SC23Yg5u6qD2wjUGMKWgfn15xAuC T/6B7BsAAP//AwBQSwMEFAAGAAgAAAAhAAlDyfuzCAAAIEMAABoAAAB3b3JkL3N0eWxlc1dpdGhF ZmZlY3RzLnhtbLxb23LbNhB970z/gcN3R5LtSI2nSidRmsQzaZtG9vQZoiALY5JgScqXfH0XCxKi SFHcNZk+ybxgz17PQjL219+eotB7kGmmdDz3J6/GvifjQK9VfDf3b28+nv3ie1ku4rUIdSzn/rPM /N/e/vzTr49XWf4cyswDAXF29ZgEc3+b58nVaJQFWxmJ7FWkglRnepO/CnQ00puNCuToUafr0fl4 Msa/klQHMssAbSHiB5H5hbioKU0nMgasjU4jkWevdHo3ikR6v0vOQHoicrVSocqfQfZ4WorRc3+X xleFQmdOIbPkyipUfJQr0oYVR3Dtyg862EUyzhFxlMoQdNBxtlXJ3oyXSgMTt6VKD6eMeIjC8r3H ZHLZwHMmU2LwIRWPEIq9wIa4I85Y20VRaP1g4ruPal3iZHzKmCIiRoTTgaLCIWapSSRU7MS8zDVV 50I99MnvT6neJU6dRPWTdh3fO1mmLBmajadYeVXTMpaARukutyKRvhcFV9d3sU7FKgSNHieXnslI /y1QxVoHH+RG7MI8M5fp17S4LK7w46OO88x7vBJZoNQNUAhIiRQI/PwuzpQPT6TI8neZEkcfbs1b R58EWV6R9l6tlT8yiNl3kPkgwrl/fl7eWRgNDu6FIr4r78n47HZZ1WTuu1srkDv3RXq2fGeEjdDM 8rNibnJgPFyhKokIoPIAR2xyCSQELGZwQmWiez4DRrMX33bGuWKX6wIEBQBYVSxc1jwO3ARMtbSM DU/l5osO7uV6mcODuY9YcPP2+muqdAo0OvffvDGYcHMpI/VZrdfSNIji3m28VWv5z1bGt5lc7+// /RHpuZAY6F2cg/rTGWZBmK1/fwpkYmgSRMfCRPhPswA4DMJRwUGFdmqvjb1RQ8Wb/5aQExvDoyhb KUxL81D/k0Bo9a430LmxqGoAymXpetFfxGV/Ea/7i8Dk7eeLWX8tYCPTNyI2NypZSQ9qrgObfFU/ XLw5kbJmRSOLOlc0kqZzRSNHOlc0UqJzRSMDOlc0At65ohHfzhWNcJ5cEQgkrnoWXaA3SIV9o/IQ +mQH0016Ul3RaryvIhV3qUi2nmmsdbVPkeVyt8ppqiKdvpwsl3mqzXazwyPQnU3pvpiTf4+SrcgU 7Mq7gHq6/sZsfbxPqYLtawfUa5t8DZtwY3K0hX0NRSC3OlzL1LuRTzaijPV/am9pdxmdyvUM6xd1 t8092BWaltsJNm1xersnrPwvKkMfnOzm0xZTuoSTYjhtyct24X/ItdpFpWsIu5Gp5XNGmGsQqOJp F12aEDWrq9MKEwCKCbZd8E1A+QT9bXPhyzcxpuhvW9EL5RP0t43rhfIxP07Hl800H+BnFY9UXjN2 7S50qNPNLixroJMeZuwKdhA0E9hF7OSTSGLGruAD+vTeBQF8c6PkKTsWex5loLDDYVGw2Oi2sINS o70JwyJ2gGpY5wysflzLAGKT7jf5oMyPwNxmgCzt9pqd5XzR4gFoQaQ99N87nXfvoc9bOI+Kch3D zyWZ9GhoFy2VR0Ur8sn2O0aM+zU+BlC/DsgA6tcKGUAt+dG+53E9kQ7SvzkysNi07LoYph2ZmWds ZnZAvBYwUN8k7L9aqrc9F5p9k4DCDlCzbxJQ2NGp9TLXNwlYg/VNAlZL12iPUZVTOUax+2YVyO0E CBYNQ94EoGHImwA0DHkTgPqTdzfIcORNwGJzg+PUKnkTgPAVzld9B1QlbwIQmxss2xW/GZV9D6Wc /nI7AHkTUNgBapI3AYUdnTbyJmDhK5xMqGE5qiNgDUPeBKBhyJsANAx5E4CGIW8C0DDkTQDqT97d IMORNwGLzQ2OU6vkTQBi04MDqpI3AQhf4XDDUfLGqv/h5E1AYQeoSd4EFHZ0aoTqNqkELHaAaliO vAlY+AonGQosTG6OUcOQN8GiYcibADQMeROAhiFvAlB/8u4GGY68CVhsbnCcWiVvAhCbHhxQlbwJ QGxuOEreWIw/nLwJKOwANcmbgMKOTo1QHc8RsNgBqmE58iZgYb70Jm8CEL7yUiCORcOQN8GiYcib ADQMeROA+pN3N8hw5E3AYnOD49QqeROA2PTggKrkTQBic8NR8sYa+eHkTUBhB6hJ3gQUdnRqhOrI m4DFDlANy1EdAWsY8iYAYWL2Jm8CEL7yAiCsIk6YhiFvgkXDkDcBqD95d4MMR94ELDY3OE6tkjcB iE0PDqhK3gQgNjeYc7ZwXpR8PHXSkgTUcwblqQYy4HlLkKiAhYHf5EamMFUou0+H9AQsLWQgtqQH 1cT3Wt97tIPdFy0JQoZSq1BpPNL9jKd0KoMIF7MTkwQ3fy28z3YAprEOU+rw5A1MD1XHhXA8yQwO gZ75cwIjO0l5stxIgwEhM9dVjADhTOg1DAQVYz1msZnzgRdxqKq4jf+3LVDhb0DEhU2oYAtYAUxE nYAqDry7M0h43L0O3HIqHhXZj2SUahan4/d7KPvewRnNk3rn5iT4CZ3xpPhJH3n4io1qU0EYzkKV ujSEkK1CO2IGf1zHa7DwsZjOssFcPwkrCp4vZBj+IXAgLddJ+6uh3OT26WSMHbAmaqXzXEft61M8 II6aHBMA6VBVxl4aI9rzJN5FK5kWx81bU9J0DpxEO0xJe9a1JRWonm7X7aBcXIHAcX4V4zn+eqri E3vEH3VaCRix+8tMzDVKCMYD78v7TuACaqYrbw43YQgDI+AmOxBjPH7zfnb5S1EGbTOK+L/XYkLx 0l0cn1AspiHh42DMc+4vRKhWqTK1ghOc+zs2wb9XJjJRH3A0zI+eSoYD0gh2GeQiTj7WOerQY+1h 8PYercXiKPWg3kcj0xWV9hCgxf+L845n63sRhlofz9fiGT9jK0L3Hu7DdYf+u1hMJtOF9fkPTeEb sdWRqGTw/kYAo9XFVZHOZYlNplazrJLg9t5wCV53cD3Fq5Hrm+QVrK40rzWt9qi1ZP3evQVj7G8M 4++Sy7O3/wEAAP//AwBQSwMEFAAGAAgAAAAhACXcbe5MAQAAeAIAABEACAFkb2NQcm9wcy9jb3Jl LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySUU/DIBSF3038Dw3vLbQ1 izZtlzizJ5eYOKPxjcDdRiyUAFs3f73QztpFH3y8nMN3z71Qzo+yiQ5grGhVhdKEoAgUa7lQ2wq9 rJfxLYqso4rTplVQoRNYNK+vr0qmC9YaeDKtBuME2MiTlC2YrtDOOV1gbNkOJLWJdygvblojqfOl 2WJN2QfdAs4ImWEJjnLqKA7AWI9EdEZyNiL13jQ9gDMMDUhQzuI0SfGP14GR9s8LvTJxSuFO2s90 jjtlczaIo/toxWjsui7p8j6Gz5/it9Xjcz9qLFTYFQNUl5wVzAB1ralXC7P/LPHkJGyvodat/KI3 Avj9aTBlJf6tBLOBgwhPVOe9Yyx9m36qoRfwyOcshqm+ldd88bBeojoj6U1M7uJstk7TguQFIe8h 1MX9kHs4kOdo/yYG6JT4Daj7xJd/pf4CAAD//wMAUEsDBBQABgAIAAAAIQBoqFiWMQgAAC9AAAAP AAAAd29yZC9zdHlsZXMueG1svFvfc5s4EH6/mfsfGN5Tx3bObjJ1O4nbXjPTH2mdzD3LIMeaAvIB bpL+9bdaYYzBwG4g9xQj0H6r3U/fYkf75t1jGDi/ZJwoHc3c4atT15GRp30V3c/cu9uPJ69dJ0lF 5ItAR3LmPsnEfff2zz/ePFwk6VMgEwcMRMlF6M3cdZpuLgaDxFvLUCSv9EZGcHOl41CkcBnfD0IR /9xuTjwdbkSqlipQ6dNgdHo6cTMzMcWKXq2UJ99rbxvKKMX5g1gGYFFHyVptkp21B4q1Bx37m1h7 Mklg0WFg7YVCRbmZ4VnFUKi8WCd6lb6CxQysRwNjCqYPT/FTGLhO6F1c30c6FssAgvcwPHPfQuR8 7b2XK7EN0sRcxjdxdpld4Z+POkoT5+FCJJ5StxBSMBAqsPXpMkqUC3ekSNLLRImjN9fmqaN3vCQt WLtSvnIHBjH5DTZ/iWDmjka7kbnx4GAsENH9bkxGJ3eLoiczNx9agt2ZK+KTxaUxNsBl7v4Wlrs5 WDxcoSsb4UEyAEesUgmkAI4YnEAZDo6mwBd78WNr4iq2qc5A0ACAFc3CZSniwBVgzsISGO7K1Wft /ZT+IoUbMxexYPDu+iZWOgaSztzzc4MJgwsZqk/K96XZL9nYXbRWvvxnLaO7RPr78e8fkfyZRU9v oxTcn0yRBUHif3j05MbQFkxHwmT4q5kAxIF0FHDQoa3ae2MHSqg4+O8OcmhzeBRlLYXZ4Q763wiE q952BhqZFRUXgHZZvo67mzjrbuKv7iaQvN1iMe3uBeh614xYbhRYSU9qqj1LvmIcxucNlDUzKixq nVEhTeuMCkdaZ1Qo0TqjwoDWGZWEt86o5Ld1RiWdjTM8gcJVZtEYo0Ha2LcqDaSZ3yhAw45Sl5Ua 50bE4j4Wm7VjCmvZ7SaxXGyXKc1VlNPni+UijXV03xoRqM5m6z5bkz+Em7VIFLwltYR+1DH0t+at x/k7Vn4r1F+WfJU14YvJ0RJ2EwhPrnXgy9i5lY82o4z5X7WzsG8Zrc51TOtndb9OncUaS24r2KQm 6PWRsPY/qwRj0LiZJjVLaTNOyuGkhpf1xr9IX23DXWgIbyMTq+eMNJcg0MXmEJ2ZFFV3V+sqTAIo S7Dlgr8EtE/w3xYXvn2TY4r/thQ90z7Bf1u4nmkf+dGcX7bSvIcvrQ5pe03Ze3euAx2vtsFuD7TK w5S9g3MI2hLYmzi3TxKJKXsHH8inc+l58M2NwlN2LvY6ykBhp8Oi4Gajr4WdlJLsDRkrYieohDVi YHXTWgYQW3R/yF/K/CbGLQao0vm7Zut2HtdEAEoQ6R36+1an7e/QoxrNo6JcR/BzSSIdGtq4ZudR 0TI+2XrHyHG3wscA6lYBGUDdSiEDqIYf9e88eU2kg3QvjgwstiznVQxpR1bmKVuZcyBeCeipbhLe v2p2bz0XqnWTgMJOULVuElDY2SnVsrxuErB6q5sErJqqUZ+joqZyFsWum0Wg/E2AsKJ+xJsA1I94 E4D6EW8CUHfxbgfpT7wJWGxtyDW1KN4EIHyE81U/ByqKNwGIrQ1W7bLfjHZ1D600f7ntQbwJKOwE VcWbgMLOTp14E7DwEQ4TSli51BGw+hFvAlA/4k0A6ke8CUD9iDcBqB/xJgB1F+92kP7Em4DF1oZc U4viTQBiy0MOVBRvAhA+wtGGo+KNu/7FxZuAwk5QVbwJKOzslAQ1f0klYLETVMLKxZuAhY9wyJBh Ibk5i+pHvAkr6ke8CUD9iDcBqB/xJgB1F+92kP7Em4DF1oZcU4viTQBiy0MOVBRvAhBbG46KN27G FxdvAgo7QVXxJqCws1MS1FznCFjsBJWwcvEmYCFfOos3AQgfeS4QZ0X9iDdhRf2INwGoH/EmAHUX 73aQ/sSbgMXWhlxTi+JNAGLLQw5UFG8CEFsbjoo37pEXF28CCjtBVfEmoLCzUxLUXLwJWOwElbBy qSNg9SPeBCAkZmfxJgDhI88Awl3ESVM/4k1YUT/iTQDqLt7tIP2JNwGLrQ25phbFmwDEloccqCje BCC2NphztnBelHw8dVhDAuo5g92pBjLgqCZJVMBsgT/kSsbQZCXbT4d0BNytkIFYQw/qEq+0/unQ DnaPawhChlLLQGk80v2Ep3QKjQjjaUMnwe23ufPJNsBU5iGlDk/eQPdQsV0I25NM4xD4mT5toGVn sztZbqxBg5Dp68pagLBF7hoagrK2HjPZ9PnAg9hUlQ3j/20zVPgMiDixCuWtAcuDjqgGqOzAe34G CY+7l4FrTsWjI/uWjJ2b2en4/TuUfe7gjGaj36k5Cd7gM54Ub4yRg4/YrFYdhOYsdKnNQ0jZMrAt ZvDhOvJhhdAkiP81s8n0H4U1BffnMgi+CGxIS/Wm/tFArlJ7d3iKFbBkaqnTVIf182M8II6eHDMA dCg6Yy/NIup5Em3DpYyhw6sh5l+1qRzYiXZISXvWtYYK1EjX+3awXfINAsf5VYTn+MtUxTv2iD/6 tBTQYvfNdMxVthC0B/7cjecG57Bn2nhz+BKGMNARa9iBGKen51fTs9fZNqjrUUQWZR2KZ/nF8Q7F rBsS/hy0ec7cuQjUMlYmb9jBuR+xBP9d6MhEfyDQ0D/aRIYD0fC2CXAROx/LGnUYsfo0OPuIlnJx VHrQ76OZactKfQpwxf9L8I6z9UoEgdbH+Zrd4zO2YHQf4S5adxi/8Xw4nMxtzF+UwrdirUNRYPB+ wEtmbnaV0Xm3xYYT61lSILgd64/g5QCXKV7MXFeSF7DaaF4qWvVZq2H9PryZYuwH+on3TsuTt/8B AAD//wMAUEsDBBQABgAIAAAAIQD0bnrB6AEAAKsFAAASAAAAd29yZC9mb250VGFibGUueG1svJPR itswEEXfC/0Ho/eNJcdJd806y266gb70oWw/QFHkWNSSjEaJm7/vSHZc2BAat1AbTHJHuswc7jw+ /dRNcpQOlDUlYTNKEmmE3SmzL8n3t83dPUnAc7PjjTWyJCcJ5Gn18cNjV1TWeEjwvoFCi5LU3rdF moKopeYws600WKys09zjX7dPNXc/Du2dsLrlXm1Vo/wpzShdksHG3eJiq0oJ+dmKg5bGx/upkw06 WgO1auHs1t3i1lm3a50VEgBn1k3vp7kyow3LL4y0Es6CrfwMh0n7jtJghdcZjb90QxItii97Yx3f NsiuYzlZDeCSrjBco7jmjdo6FQstNxYkw9qRNyWhGd3QBX7Dm9N5+JI0OIiaO5B+PEh7ueJaNaez Cp0C6Aut8qI+60fuVGioL4HaY+EAW1qSV0YpzTYb0iusJDkKz+tRybCp/nkYzsxHBZODjUWfeIQ9 RB9U0Ge4FftM++hckHhTWkLyVXbJN6u5uUIko0sksUAegcx8EhEXfSPBW4lg49nzOD9Oskbl033O hvknEel9JhDhNXZ8BcQLggihCCjy/xKN7PU9iCVdvLwHkf0pGoyyqSDWXOOOXCMRotBzCNGYtiR/ F4nLJaH5yOZ3JOJK4Gr9y5IM2wKrXwAAAP//AwBQSwMEFAAGAAgAAAAhADUegbXpAQAA5wMAABAA CAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFPB btswDL0P2D8YvjdK0qxLA1nFkG7oYVsDxG3Pmkw7wmRJkNig2dePsptU2XaaT+Qj8fj8SPGbl94U ewhRO1uVs8m0LMAq12jbVeVD/eViWRYRpW2kcRaq8gCxvBHv3/FNcB4CaogFUdhYlTtEv2Isqh30 Mk6obKnSutBLpDR0zLWtVnDr1HMPFtl8Or1i8IJgG2gu/ImwHBlXe/xf0sappC8+1gdPggWvofdG IojvSY6ZNA57zk4orx1KU+sexJLgU8I3soMo5pyNAX9yoYni6iMhY8jXOxmkQnJQXC4vZ5xlAP/k vdFKIpkrvmkVXHQtFveDDUUi4Cxv4WTNFtRz0HgQU87ylH/VlqSkCWNE2oLsgvS7mERnGd8qaWBN BohWmgicvQH8DmRa7kZqUsz3uNqDQheKqH/Reudl8UNGSLZV5V4GLS2SfaltTIbY+IhB1BoNcVNt zIcwb8tjvRCknHopOG9M4KiBCufqhgnxvqV/w3+IneViBw2j1ExOFp5m/MG6dr2X9iA+B61idJY2 +Ioky3/GB1+723Q6r16eg9n+nzTutl4q2tJicf0hv4SsxLd0MNDQao+EbwC/I9+DSVPpimwHzbHn 70K6rcfx3YrZYjKlbzimI0YXcXpQ4jcAAAD//wMAUEsBAi0AFAAGAAgAAAAhAAkkh4KBAQAAjgUA ABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEa t/MAAABOAgAACwAAAAAAAAAAAAAAAAC6AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAfDuX OSIBAAC5AwAAHAAAAAAAAAAAAAAAAADeBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BL AQItABQABgAIAAAAIQAxqcuxQxMAAHCcAAARAAAAAAAAAAAAAAAAAEIJAAB3b3JkL2RvY3VtZW50 LnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQbAAAVAAAAAAAAAAAAAAAAALQcAAB3b3JkL3Ro ZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAi/o6F80DAADpCQAAEQAAAAAAAAAAAAAAAACP IwAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA2JqDi38BAABMAwAAFAAAAAAAAAAA AAAAAACLJwAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEACUPJ+7MIAAAgQwAA GgAAAAAAAAAAAAAAAAA8KQAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwECLQAUAAYACAAA ACEAJdxt7kwBAAB4AgAAEQAAAAAAAAAAAAAAAAAnMgAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAU AAYACAAAACEAaKhYljEIAAAvQAAADwAAAAAAAAAAAAAAAACqNAAAd29yZC9zdHlsZXMueG1sUEsB Ai0AFAAGAAgAAAAhAPRuesHoAQAAqwUAABIAAAAAAAAAAAAAAAAACD0AAHdvcmQvZm9udFRhYmxl LnhtbFBLAQItABQABgAIAAAAIQA1HoG16QEAAOcDAAAQAAAAAAAAAAAAAAAAACA/AABkb2NQcm9w cy9hcHAueG1sUEsFBgAAAAAMAAwACQMAAD9CAAAAAA== --_002_087A34937E64E74E848732CFF8354B920983BFF9ESESSMB101erics_-- From nobody Mon Sep 29 01:53:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D3F1A8713 for ; Mon, 29 Sep 2014 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6GVEqLuUC7V for ; Mon, 29 Sep 2014 01:53:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E061B1A870E for ; Mon, 29 Sep 2014 01:53:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s8T8r1Qq007059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Sep 2014 08:53:01 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s8T8qw0x009061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 10:53:00 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Sep 2014 10:52:59 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.218]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 10:52:58 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Maria Cruz Bartolome , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0IAAAbHwgAACWwCAAAZ6kIAEjXnA Date: Mon, 29 Sep 2014 08:52:58 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520EBD2@DEMUMBX014.nsn-intra.net> References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B98E@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920983BFF9@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B920983BFF9@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 9408 X-purgate-ID: 151667::1411980781-0000437E-42425DE5/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hMvFmFqQBxWJ8lG3eY5vWp1adQY Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Sep 2014 08:53:08 -0000 Hi Maria Cruz, your modification does not address my concern. Anyway, I like my proposal better as it clearly describes which (future) re= quests should be subject to throttling. Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 26, 2014 1:14 PM To: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear Ulrich, This was not my intention, but text may be misleading. I modified some inde= ntation, to be clearer. Let me know if this is alright now. Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:54 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Maria Cruz, thank you for clarification. I think there is a (maybe minor) difference between your and my version. According to your description, a request that does not contain a destinati= on host but is send to a direct peer which in a non-overloaded server would= potentially undergo throttling according to a realm type OLR. Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 26, 2014 12:43 PM To: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Ulrich, Your clarification does not contradict my understanding. However, I think in clause 6.6 it is better to clearly state what OC-Report= -Type identifies first, and then how the reacting node identifies if an ove= rload abatement applies, and for this, refer to OCS, since this is what the= reacting node will use to apply abatement, if required. This is my intenti= on with the new proposal. I hope this clarifies. Regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:38 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different.=20 Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Sep 29 09:26:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975471A8872 for ; Mon, 29 Sep 2014 09:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0GYVD1lbdxs for ; Mon, 29 Sep 2014 09:26:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A281A8883 for ; Mon, 29 Sep 2014 09:26:41 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id CB1CE714C4D7E; Mon, 29 Sep 2014 16:26:36 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s8TGQYm1012799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 18:26:38 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 18:26:35 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: ext Maria Cruz Bartolome , "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host Thread-Index: AQHPyNyuNnzaufIU0EqXUbjmECT9z5vydJoAgAr8v/CAFLcIUIAA7XjggAA4s8CAAAqN0IAAAbHwgAACWwCAAAZ6kIAEjXnAgABOzeA= Date: Mon, 29 Sep 2014 16:26:33 +0000 Message-ID: References: <075.41a258960641a985e7e7d8a618123b41@trac.tools.ietf.org> <5409C5A4.5090203@usdonovans.com> <087A34937E64E74E848732CFF8354B920983BD00@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B920983BF65@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B965@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920983BFD0@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520B98E@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920983BFF9@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681520EBD2@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520EBD2@DEMUMBX014.nsn-intra.net> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EZGmWzRehcgxxL8WAVFxTAp37Ks Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent Destination-Host X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Sep 2014 16:26:44 -0000 Hi MCruz, Ulrich Thanks for your inputs.=20 I agree with the Ulrich remark to do no throttling if the peer is a server= which is not overloaded. But I think this drives to distinguish peers whic= h are servers from those which are not (other DAs). RFC 6733 does not seem = to make this difference. Independently of the above point, MCruz was also proposing to separate the = meaning of the OLR-Type, (what does it identify) from the overload treatmen= t which is a behavior of the reacting node. This is to be considered and m= ay drive to move this part of the text in 5.4 (Reacting Node Behavior).= =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Envoy=E9=A0: lundi 29 septembre 2014 10:53 =C0=A0: ext Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dim= e@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Hi Maria Cruz, your modification does not address my concern. Anyway, I like my proposal better as it clearly describes which (future) re= quests should be subject to throttling. Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 26, 2014 1:14 PM To: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear Ulrich, This was not my intention, but text may be misleading. I modified some inde= ntation, to be clearer. Let me know if this is alright now. Cheers /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:54 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Maria Cruz, thank you for clarification. I think there is a (maybe minor) difference between your and my version. According to your description, a request that does not contain a destinati= on host but is send to a direct peer which in a non-overloaded server would= potentially undergo throttling according to a realm type OLR. Best regards Ulrich -----Original Message----- From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]=20 Sent: Friday, September 26, 2014 12:43 PM To: Wiehe, Ulrich (NSN - DE/Munich); TROTTIN, JEAN-JACQUES (JEAN-JACQUES); = dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Ulrich, Your clarification does not contradict my understanding. However, I think in clause 6.6 it is better to clearly state what OC-Report= -Type identifies first, and then how the reacting node identifies if an ove= rload abatement applies, and for this, refer to OCS, since this is what the= reacting node will use to apply abatement, if required. This is my intenti= on with the new proposal. I hope this clarifies. Regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: viernes, 26 de septiembre de 2014 12:38 To: Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.o= rg; draft-ietf-dime-ovli@tools.ietf.org Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Mcruz, JJ, Maybe I missed your point, but my understanding is a bit different.=20 Please see the attached proposal. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Friday, September 26, 2014 11:58 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dime-ov= li@tools.ietf.org Subject: Re: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Dear JJ, all I think I understand your concern. I modified text in clause 6.6 to clarify this point. Attached. Let me know your opinions. Best regards /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com]=20 Sent: viernes, 26 de septiembre de 2014 10:12 To: Maria Cruz Bartolome; dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.or= g Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi Maria Cruz 1) The hereafter proposed text is in a sub part of section 6.6 addressing = the overload treatment when the OC-report type indicates realm report so = according to a Realm type OLR. The proposed text mentions "...Origin-Host = AVP of the received message that contained the OC-OLR AVP". This OC-OLR AV= P can be understood as the Realm type OLR subject of this section 6.6 subp= art (this was my first reading), but it is another report which is a host t= ype OLR generated by this peer.=20 As you said we have to distinguish when either a host or a realm report to = be applied, so here the proposal is to exclude from the text the case where= the reacting node has an active type Host type OLR of which the Origin Hos= t match the peer identity, as for this case the host type OLR will be appli= ed. On this basis I would propose write "Host type OC-OLR AVP" as hereafter= . =20 "The Destination-Host AVP is absent in the request and the value of peer id= entity associated with the connection used to send the request does not mat= ch the value of the Origin-Host AVP of a received message that contained a = Host type OC-OLR AVP" 2) When thinking a bit more to this case where the reacting node is directl= y connected to the reporting node (eg a Client directly connected to two or= more servers, without intermediate DA, or a DA acting as a reacting node d= irectly connected to servers). The servers usually only send Host type repo= rts (I know there is a debate on servers sending realm reports), so the r= eacting node will not receive Realm reports. For requests for which there = is no destination Host, the reacting node will select the peer according to= the host OLRs it has or not for each of the peers (eg a peer that is not = overload or with a small overload ) and then apply the abatement/throttlin= g according to the Host type OLR of this peer. I think we have the same und= erstanding. =20 Best regards JJacques=20 -----Message d'origine----- De=A0: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com] Envoy=E9=A0: jeudi 25 septembre 2014 18:28 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org; draft-ietf-dim= e-ovli@tools.ietf.org Objet=A0: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm= , with absent Destination-Host Dear JJ, I do not understand your point. Proposed clarification has the purpose to allow a reacting node to distingu= ish when either a host or a realm report shall apply. Some time ago we based such a distinction on the presence (meaning host rep= ort) or absence (meaning realm report). Now we have covered the case for host reports when the host is absent but i= t refers to the directly connected peer. Therefore, just absence does not a= llow the reacting node to identify it has to apply a realm report. Let me know if this clarifies, or if I may be missing your point. Thanks /MCruz -----Original Message----- From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) [mailto:jean-jacques.trottin@alc= atel-lucent.com] Sent: viernes, 12 de septiembre de 2014 14:13 To: dime@ietf.org; draft-ietf-dime-ovli@tools.ietf.org; Maria Cruz Bartolom= e Subject: RE: [Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm,= with absent Destination-Host Hi MCruz The proposed text applies to the realm report.=20 Realm OLRs (in particular with same seq number) may be conveyed in answers = with different Origin-host (but with same Origin realm), so what means to r= efer "to the Origin-Host AVP of the received message that contained the (re= alm type) OC-OLR AVP". This is different from the Host report, where the h= ost type OC-OLR always refers to the origin host of the answer. =20 Can you clarify and give a use case / topology case. Best regards JJacques -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envo= y=E9=A0: vendredi 5 septembre 2014 16:16 =C0=A0: dime@ietf.org; draft-ietf-= dime-ovli@tools.ietf.org; maria.cruz.bartolome@ericsson.com Objet=A0: Re: [= Dime] [dime] #69 (draft-ietf-dime-ovli): Report Type - Realm, with absent D= estination-Host I agree. On 9/5/14, 2:40 AM, dime issue tracker wrote: > #69: Report Type - Realm, with absent Destination-Host > > In clause 6.6, host report was updated to add: > > ... or the Destination-Host is > not present in the request but the value of peer identity > associated with the connection used to send the request matches > the value of the Origin-Host AVP of the received message that > contained the OC-OLR AVP. > > but this clarification needs to be included as well for realm report. > > Original text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request. > > ... > > Proposed text: > > 1 A realm report. The overload treatment should apply to requests > for which all of the following conditions are true: > > The Destination-Host AVP is absent in the request and the the val= ue > of peer identity associated with the connection used to send the reques= t > does not match the value of the Origin-Host AVP of the received message > that contained the OC-OLR AVP. > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Sep 30 07:43:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1351A1A3B for ; Tue, 30 Sep 2014 07:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFG9EnxjtY2E for ; Tue, 30 Sep 2014 07:43:40 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F6C1A1A34 for ; Tue, 30 Sep 2014 07:43:40 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51718 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYyeJ-0002Vg-LD for dime@ietf.org; Tue, 30 Sep 2014 07:43:33 -0700 Message-ID: <542AC192.9090600@usdonovans.com> Date: Tue, 30 Sep 2014 09:43:30 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UgRFVfgqJqtxk3k0b-jmT0WXqYU Subject: [Dime] DOIC #70 - Proposed resolution to core issue X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 30 Sep 2014 14:43:41 -0000 All, The core issue raised in issue #70 is whether a client can receive an OLR of type host when the request sent by the client was realm routed. I do not support the suggested change as there are scenarios where clients MUST be prepared to receive the OLR of type host when the client does not do server selection. This is required for the scenario where agents do not support DOIC. If the request does not contain a Destination-Host AVP then agents will be responsible for server selection. An overloaded server will send an OLR of type host that will find its way back to the client. It is true that this might cause unneeded OCS entries in the client in a scenario where the client will never do server selection for that overloaded server. This concern can be addressed by making it up to local policy whether or not the client saves OCS for the overload report. If the client knows that it will never do server selection for a server indicated in a host OLR then the client can choose to not save the overload report. Based on this, I propose that we close issue #70 without changes to the DOIC specification. The discussion about the handling of a mix of overload abatement algorithms should continue. We can open a separate issue if needed to address that functionality. Regards, Steve