Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP

"VITON HORCAJO, Pedro (Pedro)" <pedro.viton@alcatel-lucent.com> Fri, 21 September 2012 09:24 UTC

Return-Path: <pedro.viton@alcatel-lucent.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 A372221F8731 for <dime@ietfa.amsl.com>; Fri, 21 Sep 2012 02:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.173
X-Spam-Level:
X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu4TmUL6kB7j for <dime@ietfa.amsl.com>; Fri, 21 Sep 2012 02:24:32 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C44CF21F86FD for <dime@ietf.org>; Fri, 21 Sep 2012 02:24:31 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8L9Lb0c020708 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dime@ietf.org>; Fri, 21 Sep 2012 11:24:30 +0200
Received: from FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 21 Sep 2012 11:24:14 +0200
From: "VITON HORCAJO, Pedro (Pedro)" <pedro.viton@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Date: Fri, 21 Sep 2012 11:24:13 +0200
Thread-Topic: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
Thread-Index: Ac2XyFp4jjluNl+bTGW8FsBAUPzC+QAAHqXA
Message-ID: <5F42DFF905CBA544A7BBB0909003E1A3148F1BB846@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com>
References: <505C0F10.3020106@gmail.com> <979805090.1858135.1348211373193.JavaMail.root@rdmail01>
In-Reply-To: <979805090.1858135.1348211373193.JavaMail.root@rdmail01>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5F42DFF905CBA544A7BBB0909003E1A3148F1BB846FRMRSSXCHMBSC_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 21 Sep 2012 09:24:33 -0000

Let me step in again:


I've read you're making references to DNS and that valid IP addresses to receive/send Diameter messages should be registerd in DNS.
In that case, what extra information does the Host-IP-Address AVP add with respecto to DNS?

If it provides duplicate information, it can be a source of conflict between DNS A/AAAA records and the advertised Host-IP-Address(es).
I think it would be better to use only 1 source of information between Origin-Host and IP address(es): either DNS or Host-IP-Address

But I suppose that at this stage, removing Host-IP-Address would create more interoperability issues that leaving it, and indicating which value(s) to send with TCP and specifying what a receiver should do with that information.



Let me put an example, where it might be interesting to have 2 Host-IP-Addresses with TCP, which I don't know if it would be feasable (and desirable) or not (or is a "mischievious" interpretation of the RFC's)

Imagine we have 2 servers (for Acct application for instance), each one configured with its own IP address (named IP1 & IP2).
But configured to be the backup of the other, sharing state between them, and sharing the same Origin-Host !!!
Server1 could advertise  in Host-IP-Address 2 IP's: IP1 (its own) & IP2 (its mated server) in its CEA messages.
And similarly for server2, also advertising the 2 IP's-

If the Diameter client (for Accounting I'm supposing that the client is the one always trying to establish the TCP connection) loses connectivity with IP1, and that IP1 is no longer reachable (or its Diameter server is temporarily down), then the Diameter client could try to contact IP2.
As the 2 servers are sharing state & Origin-Host, the Diameter client wouldn't be able to distinguish if IP1 & IP2 are 2 interfaces of the same server, or not.
But that would be a way for the Diameter server to have High Availability, without the need for 3rd party software to configure a Cluster sharing a virtual IP address.
And that redundancy could even be geographical, as IP1 & IP2 need not be in the same subnet.

But for that:
1.- Several Host-IP-Address ocurrences should be allowed to be sent in the CER/CEA messages, both with TCP & SCTP (or alternatively configured in the DNS servers)
2.- It should be specified somewhere in a RFC that the Diameter peers establishing a Diameter transport connection should retry secuentially to the advertised Host-IP-Addresses in the last received CER/CEA message (or configured addresses in DNS)


Best Regards,
  Pedro

________________________________
From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ankur Garg
Sent: Friday, September 21, 2012 9:10 AM
To: Glen Zorn
Cc: dime@ietf.org
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP


Hello,

Is it possible to have two Host-IP-Address AVPs; one containing IPv4 and other is IPv6 address while stack working on dual mode(IPv4 and IPv6) and Configured Peer listening on IPv4 only? It would be correct to send both IPv4 and IPv6 address in such case?



Ankur Garg
________________________________

From: "Glen Zorn" <glenzorn@gmail.com>;
To: "Ben Campbell" <ben@nostrum.com>;
Cc: dime@ietf.org
Sent: Friday, September 21, 2012 12:24:08 PM
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP

On 09/21/2012 01:24 AM, Ben Campbell wrote:

> This doesn't really make sense  to me: I was under the impression that
 > a TCP connection was between two unique addresses. Yes, a box might
 > ___have_ a whole bunch of addresses it _could_ use, but that seems
 > irrelevant in the case of TCP (but not SCTP).
 >>>>
 >>>> Sure TCP is between just two IPs. I never claimed otherwise.
 >>>> What I mean that say a Diameter node has IP1 to IP5. Only IP1
 >>>> has a A/AAAA record or given out to other parties for static
 >>>> configuration. During the CER/CEA (and the TCP connection
 >>>> established to IP1) it tell in CEA that "I btw also have IP2 to
 >>>> IP5". A clever implementation can make use of this e.g. for the
 >>>> transport failure case I described.
 >>>>
 >>>
 >>> This actually leads me to agree with the original poster that the
 >>> behavior surrounding Host-IP-Address is underspecified. The
 >>> problem is, "clever implementations" are bad for
 >>> interoperability. If that (or other) behavior is desired, it
 >>> should be documented. Otherwise any behavior beyond "use it for
 >>> informational purposes only" is not likely to work across
 >>> implementations.
 >>
 >> First, we all agree that having more than one Host-IP-Address in
 >> case of TCP is unnecessary. However, I am interested what possible
 >> (error) case you have in mind that could cause interoperability
 >> issue?

The draft says:

    The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
    to inform a Diameter peer of the sender's IP address.

Suppose that I send, instead of one address, three (assuming the use of
TCP).  Which one do you use?  What if the list doesn't contain the
address from which the CEr/CEA command was sent?  If my solution to
transport failure is to send you three addresses assuming that you'll
try them sequentially and you don't understand that, my scheme fails and
since you only have one registered address for me, this could cause a
much longer outage than if my network admins just did their job and
registered all the available addresses in the DNS.

>>
 >
 > I don't have a specific error in mind. My intent was to point out
 > that while there may be interesting things you can do with
 > Host-IP-Address (like the example you gave), anything that requires a
 > mutual understanding between the client and server aren't going to
 > work unless the understanding exists. In you example, using
 > Host-IP-Address to tell the peer about other available addresses to
 > be used for load balancing and/or failover won't work across
 > implementations unless it's documented somewhere.
 >
 > The original poster pointed out that they were seeing real IOT issues
 > because different implementors interpreted the spec differently in
 > regards to Host-IP-Address. Assuming that these differences were due
 > to reasonable interpretations of the spec, rather than simple
 > misunderstandings, that's a pretty big indicator that there's a
 > problem.

I would be inclined to write a short draft clarifying that, in the case
of TCP, exactly one instance of the Host-IP-Address MUST be included in
the CER/CEA messages.

...

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime