Re: [Dime] OC-Supported Feature AVP
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 17 December 2013 10:15 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 E08131AE154 for <dime@ietfa.amsl.com>; Tue, 17 Dec 2013 02:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9NxrYwLPTHBH for <dime@ietfa.amsl.com>; Tue, 17 Dec 2013 02:15:24 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C66EA1AE148 for <dime@ietf.org>; Tue, 17 Dec 2013 02:15:22 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBHAFGSU006730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Dec 2013 11:15:16 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBHAFFO5013485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 11:15:15 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 17 Dec 2013 11:15:15 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.217]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 17 Dec 2013 11:15:15 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: OC-Supported Feature AVP
Thread-Index: Ac74CX1Hcx+hHoLfTg+cADFSVxx9GADAT4Xw
Date: Tue, 17 Dec 2013 10:15:15 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151A5EDE@DEMUMBX014.nsn-intra.net>
References: <E194C2E18676714DACA9C3A2516265D201CB53EA@FR712WXCHMBA12.zeu.alcatel-lucent.com>
In-Reply-To: <E194C2E18676714DACA9C3A2516265D201CB53EA@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.109]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151A5EDEDEMUMBX014nsnin_"
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: 34932
X-purgate-ID: 151667::1387275317-00000661-8198393E/0-0/0-0
Subject: Re: [Dime] OC-Supported Feature 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: Tue, 17 Dec 2013 10:15:31 -0000
Hi JJacques, ad A) I support to mandate a) for applications that do and also for applications that do not maintain state, because: for applications that do not maintain state: "if the OC-Supported-Features AVP is no more present in a message (and in later messages) , it would be interpreted that DOIC is no more supported" and for applications that maintain state: State is maintained at session endpoints which are not necessarily DOIC endpoints. With regard to SequenceNumber it has been argued that we could have a situation where the OC-Feature-Vector remain unchanged but some additional AVPs related to the supported features would change however, we should cross the bridge when we come to it , e.g. the additional AVP, when introduced, could be of type grouped with a sequence number as first component. Ad B) Advertisement (OC-Supported-Features AVP in request messages) followed by selection (OC-OLR AVP in answer messages) is a good approach. I never understood why we need the OC-Supported-Features AVP in answer messages as long as no extension is defined. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: Friday, December 13, 2013 2:45 PM To: dime@ietf.org Subject: [Dime] OC-Supported Feature AVP Dear all When analysing the discussion of the sequence number in the OC-Supported-Features AVP , it has driven me to some other considerations regarding this feature negotiation that I hereafter present: it is a bit long but it raises a certain number of questions and then we have to draw some conclusion and adapt the text of the draft if needed A) Behaviours for sending the OC-Supported-Features AVP Currently there is only one default algorithm. So the use of OC-Supported-Features AVP containing the OC-Feature-Vector is only to indicate the support of DOIC with the default algorithm, given that en entity not supporting DOIC will never sends the OC-Supported-Features AVP. This AVP in the future will allow to add new feature/capabilities . This AVP is needed initially to advertise the mutual capabilities between reacting and reporting node and when changes occur in the supported features (eg in general to add a new feature, but may be also to remove one). A sequence number was introduced to manage these changes, but this introduction is still under discussion (cf Ulrich's mails questioning this point) Then there is the question about when the OC-Supported-Features AVP is sent. The current draft has related statements in 3.2 and 4.1 : The several hereafter possible behaviors are compliant for me with 3.2 and 4.1 statements (are you sharing this reading?), we have to see if the draft allows all of them or if additional rules must be fulfilled: a) The reacting node sends the OC-Supported-Features AVP in each request and the reporting node sends back its own OC-Supported-Features AVP in each answer. b) The reacting nodes initially sends its OC-Supported-Features AVP, but does not repeat it any more , until a change in the features to be advertised happens or after a node restart c) Something intermediate, so when there is a change as in b) plus a periodic advertisement of the supported features although unchanged About a): Steve, and I agree, indicated that the features are quite stable over time, and modifications will appear when a new feature is deployed (OAM case); I think it is also needed at restart. So there are very few events over the year where the advertisement is actually needed (have you others in mind?) . Now my questioning: why to permanently do such an exchange in each request/answer? I observe that this behavior is used in 3GPP where supported features are advertised in each request/answer, so we can apply the same principle, but I nevertheless raise the question. About the sequence number: o the receiving node has to open the sequence number AVP and checks if it has changed, given the value will change only a few times a year. A besides question, which value the seq number takes after a restart o if we do not use the sequence number, the receiving node has to open the OC-feature-Vector AVP and see if it has changed, so I do not see much difference with the above o the sequence number has the property to be equal or to increase in order to detect an eventual change of the order of the messages and avoid to come back to a previous value of the feature-vector. But further messages will all be with the new feature-vector, so the right result. I am not sure that the seq number bring a value for the transient period when the supported feature is modified. So question: can we suppress the seq number in this a) behaviour? In this a ) behaviour, if the OC-Supported-Features AVP is no more present in a message (and in later messages) , it would be interpreted that DOIC is no more supported . ( so different from the b) or c) case) About b): this is the other extreme use case compared to a). Here in practice all the messages will not contain an OC-Supported-Features AVP (except in the rare cases of a change or after a restart), So the absence of this AVP in a message does not mean that DOIC is not supported. Capability negotiation happens once and remain valid until a change. At restart or when a change a reacting node sends an OC-Supported-Features AVP in a request, and wait for an OC-Supported-Features AVP in the answer; if nothing, it means the reporting node is not supporting DOIC. If the answer is lost the reacting node may repeat the request or use another one with its OC Supported-feature AVP. If the change occurs in the reporting node, it cannot wait for a request coming from the reacting node with an OC Supported-feature AVP, (as it will never come if no change at the reacting node side), so the reporting node should advertise the OC Supported-feature AVP in answers (although the corresponding request do not contain this AVP). I think this behavior is currently allowed by the draft text, do you agree?. To secure a bit more, the reacting node may then send a request with its own OC Supported-feature AVP, acting as an acknowledgement to the reporting node. The reporting node may repeat if needed or to be more secure. There may be some corner cases to investigate more, but I currently stop here. In this use case, I do not see a need for a sequence number . Do you think such an approach is applicable? it will save many checks compared to a). About c): it is the same principle as in b) but with some periodic "refresh" that may make the a) approach still more secure. But not sure it is actually needed. So do you think the draft should allow these different behaviors or only mandate one? Then do you think we need a sequence number for the OC-Supported-Features AVP? B) Another point also related to the OC-Supported-Features AVP and OC-Feature-Vector: For example a node can use the default mechanism and in addition support extensions (eg the APN or the session group examples). I would think extensions should be advertized by the reacting node , otherwise the server does not know if it can use an extension or not, and a server should avoid to send OLRs that the client will not understand . So here we may have a set of extensions compatible with the default mechanism The other example is "exclusive" or not compatible features, for example Traffic reduction %control and rate control. I do not consider a reporting node will use both with a reacting node. A reacting node , even if it supports both does not want to mix throttling based on % traffic and throttling on rate control with the same reporting node. But the current text does not say anything about which feature is selected . I remember that in our initial discussions, the reacting node was advertising its features / capabilities and the reporting node was selecting the ones it wants to use. Should not we come back to this rule? or do you consider that when we will introduce new features , we will introduce statements to indicate rules on their presence in OC-Feature-Vector. Personnaly, I think the advertisement followed by selection was a good approach. Views on this? I have described this B part here, as it may have some interaction with the A part. Best regards JJacques
- [Dime] OC-Supported Feature AVP TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] OC-Supported Feature AVP Jouni Korhonen
- Re: [Dime] OC-Supported Feature AVP Steve Donovan
- Re: [Dime] OC-Supported Feature AVP Ben Campbell
- Re: [Dime] OC-Supported Feature AVP Wiehe, Ulrich (NSN - DE/Munich)