[Dime] R: Mail regarding draft-ietf-dime-rfc3588bis

Villa Silvia <Silvia.Villa@italtel.com> Mon, 29 October 2018 16:40 UTC

Return-Path: <Silvia.Villa@italtel.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C671271FF for <dime@ietfa.amsl.com>; Mon, 29 Oct 2018 09:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eGf8BUoexPwY for <dime@ietfa.amsl.com>; Mon, 29 Oct 2018 09:40:41 -0700 (PDT)
Received: from ns.italtel.it (ns.italtel.it [138.132.53.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA35127333 for <dime@ietf.org>; Mon, 29 Oct 2018 09:40:40 -0700 (PDT)
Received: from ns.italtel.it (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7D67F14A2E1; Mon, 29 Oct 2018 17:40:38 +0100 (CET)
Received: from exconn00speak.corp.dom (unknown [138.132.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ns.italtel.it (Postfix) with ESMTPS id 74C8814A2C0; Mon, 29 Oct 2018 17:40:38 +0100 (CET)
Received: from ITMI01VW365.corp.dom (2002:8a84:5a41::8a84:5a41) by ITMI01VW364.corp.dom (2002:8a84:5a40::8a84:5a40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 29 Oct 2018 17:40:37 +0100
Received: from ITMI01VW365.corp.dom ([fe80::d9c:90b0:d9c1:dd97]) by ITMI01VW365.corp.dom ([fe80::d9c:90b0:d9c1:dd97%17]) with mapi id 15.01.1466.003; Mon, 29 Oct 2018 17:40:37 +0100
From: Villa Silvia <Silvia.Villa@italtel.com>
To: Yuval Lifshitz <yuvalif@yahoo.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Mail regarding draft-ietf-dime-rfc3588bis
Thread-Index: AdRtKULzgui1lYo6RmurApMnh888nwBhQ1KAAD1lw/A=
Date: Mon, 29 Oct 2018 16:40:37 +0000
Message-ID: <79e3414ea75a40e5864c40176c1479bb@italtel.com>
References: <9483df2e03b04080a857b3bee987f434@italtel.com> <1783796887.17665942.1540728405641@mail.yahoo.com>
In-Reply-To: <1783796887.17665942.1540728405641@mail.yahoo.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [138.132.89.225]
x-puremessage: [Scanned]
Content-Type: multipart/alternative; boundary="_000_79e3414ea75a40e5864c40176c1479bbitaltelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/hdyjPnUnpmnDCsxD2ELPi0dtu5A>
Subject: [Dime] R: Mail regarding draft-ietf-dime-rfc3588bis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 29 Oct 2018 16:40:44 -0000

A new request in line

Da: Yuval Lifshitz [mailto:yuvalif@yahoo.com]
Inviato: domenica 28 ottobre 2018 13:07
A: dime@ietf.org; Villa Silvia <Silvia.Villa@italtel.com>
Oggetto: Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis

Hello Silvia,
The server is expected to send the RAR to the same host from which the session was initialized (i.e the Destination-Host of the RAR should be the same as the Origin-Host of the AAR).

There is no requirement, however, to send the RAR on the same Diameter connection that was used to send the AAR. For example, if there was a connectivity issue with the client after the AAR was sent, that was resolved (client reconnected wit the same Diameter identity), and then the server want to send the RAR, it should be allowed to send it over the new connection to the same client (with the correct Destination-Host).

Another case is where the client is not directly connected to the server (i.e. a Diameter agent sits between them). In such a case the server may use "realm routing" and send the RAR on any Diameter connection that may reach the desired realm. However, even in this case, the Destination-Host of the RAR must be set to the correct Destination-Host, and it is up to the Diameter agent(s) to route the request to the correct client.

[SILVIA] I would like to check if I understood this last sentence well.
In this last case where there is an agent between server and client..
The server can select a different routing street by “realm routing” so that server can send the RAR or ASR to a different diameter agent peer (compared to that used for the AAR).
However, server must anyway insert in this RAR the specific Destination-Host-AVP that must be the same as the Origin-Host of the AAR.
So that the new diameter agent peer will deliver the RAR always to the same “Client Origin-Host and Connection”.
It is correct?
I'm sorry if I ask you again but I do not know if I understood the second case correctly
Thank you very much.
Silvia



Hope this helps,

Yuval

On Friday, October 26, 2018, 3:47:26 p.m. GMT+3, Villa Silvia <Silvia.Villa@italtel.com<mailto:Silvia.Villa@italtel.com>> wrote:



Hello Diameter experts and funs,



I have a question on the interpretation of RFC 6733.



I have a Client Diameter that opens many Diameter Connections with different Origin-Hosts and the same Origin-Realm.

The Client need to send AAR in session with maintained state to a Server.



Where a Diameter Server will send requests in session such as RAR or ASR?



The Destination-Host-AVP must be valued with the Origin-Host-AVP of the AAR sent by the client or a different Destination-Host-AVP can be chosen by realm?



What would happen if the diameter connection will fell and lost?

The Diameter Server must/can/cannot choose to send the request to a different Destination-Host-AVP of the same Client Realm?



I cannot understand where is the limit between protocol rules and custom policy local develop solution.



Thank you.



Silvia


Internet Email Confidentiality Footer ** La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge vigente (ad es. art. 616 C.P., D.Lgs n. 196/2003 Codice Privacy, Regolamento Europeo n. 679/2016/GDPR). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. Al link seguente e' disponibile l'informativa Privacy: http://www.italtel.com/it/about/privacy/ ** This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. Click here to read your privacy notice: http://www.italtel.com/it/about/privacy/
_______________________________________________
DiME mailing list
DiME@ietf.org<mailto:DiME@ietf.org>
https://www.ietf.org/mailman/listinfo/dime
Internet Email Confidentiality Footer ** La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge vigente (ad es. art. 616 C.P., D.Lgs n. 196/2003 Codice Privacy, Regolamento Europeo n. 679/2016/GDPR). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. Al link seguente e' disponibile l'informativa Privacy: http://www.italtel.com/it/about/privacy/ ** This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. Click here to read your privacy notice: http://www.italtel.com/it/about/privacy/