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

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 28 November 2013 08:30 UTC

Return-Path: <ulrich.wiehe@nsn.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 B46DE1AD8DB for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 00:30:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J8EGqsVvB5zJ for <dime@ietfa.amsl.com>; Thu, 28 Nov 2013 00:30:45 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6F33A1ACCFF for <dime@ietf.org>; Thu, 28 Nov 2013 00:30:45 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAS8Ug7G031076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Nov 2013 09:30:42 +0100
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 rAS8UfRl027221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Nov 2013 09:30:42 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 28 Nov 2013 09:30:41 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 09:30:41 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01
Thread-Index: AQHO6uUFBia7lB2bcUaG0OYS8IBkDJo46aSAgABIf6CAAEojAIAA0/DQ
Date: Thu, 28 Nov 2013 08:30:40 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519BC10@DEMUMBX014.nsn-intra.net>
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> <9CFD23C3-AA49-4177-A393-731E86BB6753@nostrum.com>
In-Reply-To: <9CFD23C3-AA49-4177-A393-731E86BB6753@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.108]
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: 1553
X-purgate-ID: 151667::1385627443-000022AE-54AE0F4F/0-0/0-0
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: Thu, 28 Nov 2013 08:30:46 -0000

Ben,

would you agree that your proposal is an optimization that could be introduced by extension?

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, November 27, 2013 9:44 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Jouni Korhonen; dime@ietf.org
Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01


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.