IETF Logo Mail Archive

Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Ben Campbell <ben@nostrum.com> Wed, 26 February 2014 15:15 UTC

Return-Path: <ben@nostrum.com>
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 D100A1A066E for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 a6MDWBKm8f4m for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:15:30 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1331A0231 for <dime@ietf.org>; Wed, 26 Feb 2014 07:15:14 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QFFB6M011425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:15:13 -0600 (CST) (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.29]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
Date: Wed, 26 Feb 2014 09:15:09 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <07D74432-AB28-43BB-9C54-EA091D647250@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026644D6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <D2D4DD91-8F3D-4C24-9E3A-E2AE3918D468@gmail.com> <52FCBBF7.7000700@usdonovans.com> <D4BE67F7-6D7B-4DB2-8DF0-D430A8FC6582@nostrum.com> <5302351F.6050902@usdonovans.com> <E194C2E18676714DACA9C3A2516265D2026697DE@FR712WXCHMBA12.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se> <53035690.1070702@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3A60@DEMUMBX014.nsn-intra.net> <5303742C.50902@usdonovans.com> <6854BD31-1B9A-4F72-B987-E25B407EBD57@nostrum! .com> <530B7D62.1080700@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1g5vrqCpig67hvGTfzyvY7GW9go
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 15:15:33 -0000

Given the further discussion, what is the currently proposed conclusion?

On Feb 26, 2014, at 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Ben, Steve, all
>  
> I still think we can conclude on #34.
>  
> The issue here is independent and is valid for both realm-routed-request reports and realm reports (should we ever agree on them, see #55).  I shall open a new ticket on Multiple Reporting Nodes reporting realm-routed-request reports for the same realm.
>  
> Ulrich
>  
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
> Sent: Monday, February 24, 2014 6:12 PM
> To: Ben Campbell
> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>  
> Ben,
> 
> One comment below.
> 
> Steve
> 
> On 2/20/14 5:16 PM, Ben Campbell wrote:
>  
> On Feb 18, 2014, at 8:54 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>  
> - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.
>  
> I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.
> SRD> The reason for this requirement is to handle the likelihood that each reporting node of the new realm report type will have independent sequence numbers.  Thus, as long as all reporting nodes report all updates to the realm overload status, it should be sufficient for a reacting node to only listen to one of the reporting nodes when determining if the OLR is new.
> 
>  
>  
>  
>

v2.23.0 | Report a Bug | By Email