IETF Logo Mail Archive

Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01

Ben Campbell <ben@nostrum.com> Wed, 27 November 2013 20:44 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 9CD311ADA5D for <dime@ietfa.amsl.com>; Wed, 27 Nov 2013 12:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 PouAB0qG-h3a for <dime@ietfa.amsl.com>; Wed, 27 Nov 2013 12:44:12 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6AD1ADEBA for <dime@ietf.org>; Wed, 27 Nov 2013 12:44:12 -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 shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rARKi7LX058878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Nov 2013 14:44:08 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519BAB8@DEMUMBX014.nsn-intra.net>
Date: Wed, 27 Nov 2013 14:44:06 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <9CFD23C3-AA49-4177-A393-731E86BB6753@nostrum.com>
References: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> <4CFE9D80-E25A-4B8F-96D1-EB7C21F2F11A@nostrum.com> <9AC5C876-99AD-4C43-9B13-3288C76459FB@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519BAB8@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01
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, 27 Nov 2013 20:44:13 -0000

On Nov 27, 2013, at 9:33 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Jouni,
> 
> with regard to 2) I agree with Ben and you.
> 
> For 3) I find it beneficial to distinguish between a) an Overload Report that requests a traffic reduction for traffic destined to a specific Host and b) an Overload Report that requests a traffic reduction for traffic to (an unspecified Host within) a specific Realm. 
> It may however be possible to implicitly derive the ReportType (Host or Realm) from the presence/absence of a Destination Host in the corresponding request message. That means: only one OLR in an anwer, no explicit ReportType in the OLR. I think this proposal is more inline with the end-point concept.


Why is that beneficial? It means that the responding node has to refer back to the original request to determine the meaning of an OLR in an answer. That creates a lot more work and implementation complexity than you would have if we put the ReportType in the OLR itself. it also puts unnecessary constraints on when a reporting node can send the ORL in the first place.

v2.23.0 | Report a Bug | By Email