Re: [Dime] endpoint determination

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 04 December 2013 10:00 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 260EA1AE21C for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 02:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 MbzSwNDTtz45 for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 02:00:29 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B47101AE047 for <dime@ietf.org>; Wed, 4 Dec 2013 02:00:28 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB4A0NUS014547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 11:00:24 +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 rB4A0NSd030127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:00:23 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 11:00:22 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:00:22 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] endpoint determination
Thread-Index: Ac7sNGlk8/aQM1p4QPOTYH1OvkMS+gENDhIAABmkvQA=
Date: Wed, 4 Dec 2013 10:00:22 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D603@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519BD77@DEMUMBX014.nsn-intra.net> <B2C75305-AC2B-40A3-AC3B-EA22AF3EF02F@nostrum.com>
In-Reply-To: <B2C75305-AC2B-40A3-AC3B-EA22AF3EF02F@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.117]
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: 3560
X-purgate-ID: 151667::1386151224-00006154-04201736/0-0/0-0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] endpoint determination
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, 04 Dec 2013 10:00:31 -0000

Ben,

please see inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, December 03, 2013 10:46 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] endpoint determination


On Nov 28, 2013, at 6:21 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com>; wrote:

> Hi,
> 
> draft-ietf-dime-ovli-00 in Clause 5.1 says:
> 
> How the endpoints are determined is specific to a deployment, a Diameter node role in that deployment and local configuration.
> 
> 
> In order to better address REQ  6 of RFC 7068 I would like to propose some principles that should be taken into account:
> 
> 1. A client that supports the Diameter Overload Control Mechanism must (offer to) take the role of a reacting endpoint and hence includes the OC-Feature-Vector AVP when sending requests.
> 2. An Agent that - based on local configuration - takes the role of a reporting endpoint (towards the downstream reacting endpoint) must also (offer to) take the role of a reacting endpoint towards the server and hence replace the received OC-Feature-Vector AVP with its own OC-Featur-Vector AVP.

I agree with the concepts in 1 and 2, but not as written (assuming you intend the use of must to be normative.) I think this is better written in terms of a definition of what reporting node and reacting node means, then mention that a supporting client is normally a reacting node, a supporting server is normally a reporting node, and an agent can be both.

> 3. An agent that supports the Diameter Overload Control Mechanism and that - based on absence of local configuration - does not take the role of a reporting endpoint must be able to detect whether a downstream agent or client  already takes the role of the reacting endpoint (e.g. by checking the presence of an OC-Feature-Vector AVP in the received request). If it detects that no downstream node took the role of the reacting  endpoint, the agent must take the role of the reacting endpoint and hence insert an OC-Feature AVP to the request. I.e. determination of the reporting endpoint is done dynamically and does not rely on local configuration.

I read that to mean you expect an agent to "take over" as the reacting node even if the administrator has completely turned off OC? If so, I don't agree, at least not as a normative requirement. Implementors can choose to create such a mode if they want to, but we don't need to require it.
[Wiehe, Ulrich (NSN - DE/Munich)] The original intention was to say: "An agent that supports DOIC must be able to detect whether a downstream agent or client already takes the role of the reacting endpoint..." This is to cover the case in figure 4 (see clause 5.1) where the reacting DEP is in A instead of C (A performs throttling on behalf of C towards the reporting endpoint S). But then I noticed that in figure 6 the agent does not take the role of the reacting endpoint on behalf of C2 because A already is the reporting endpoint (by configuration) (A performs throttling on behalf of C2 towards the reporting endpoint A). If the administrator turns off the reporting endpoint functionality in A, then we would have a DOIC association beween C1 and S and a DOIC association between A (on behalf of C2) and S. In summary: the agent takes over the reacting DEP functionality on behalf of the client unless the agent itself is the reporting DEP.