IETF Logo Mail Archive

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

Steve Donovan <srdonovan@usdonovans.com> Wed, 26 February 2014 15:02 UTC

Return-Path: <srdonovan@usdonovans.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 1128C1A00E2 for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Di8nB70DMTDd for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:02:40 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id DC8981A0454 for <dime@ietf.org>; Wed, 26 Feb 2014 07:02:38 -0800 (PST)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60920 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WIg0J-000704-JH; Wed, 26 Feb 2014 07:02:36 -0800
Message-ID: <530E020B.6070300@usdonovans.com>
Date: Wed, 26 Feb 2014 09:02:35 -0600
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, Ben Campbell <ben@nostrum.com>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <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>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A6E@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------070504040704000103020704"
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: srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BNLkww8W4rNodPRiRIH53Fd_id0
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:02:43 -0000

Ulrich,

Sounds good, thanks,

Steve

On 2/26/14 8:55 AM, Wiehe, Ulrich (NSN - DE/Munich) 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> <mailto: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