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

Glen Zorn <glenzorn@gmail.com> Fri, 21 September 2012 06:54 UTC

Return-Path: <glenzorn@gmail.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 F3F6921F8692 for <dime@ietfa.amsl.com>; Thu, 20 Sep 2012 23:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 uXl5I00jNuF0 for <dime@ietfa.amsl.com>; Thu, 20 Sep 2012 23:54:14 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98A8621F8661 for <dime@ietf.org>; Thu, 20 Sep 2012 23:54:13 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so4530639pbb.31 for <dime@ietf.org>; Thu, 20 Sep 2012 23:54:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Km3FrFPCG6efEvH0j3yOYAArZnrbwbW7mOL6LgLX1ys=; b=D6r5FZSGJNjeHz3izuYoYsywcUbVgSxVQElcehAFxXWI+kRdpFXpTVElOHgwoetyRy trq8IpxibCzskr8ZcnTAiP+ti4AtL6uaMuMgfdlhh3eazxOw3c5gUtgQsrgcw69CWf0u AeJSroKBKYcTfh3Z3bnv/oZoVkDuv9gOIgXC5mjR+kruDju3rvNMaD7kMKS4SVoKvkLe PLrMCDnVJ9Lp8siL5Cwpp516CwKjL3Qog77hUV+vtu8CwSjvKbNm8yShxqW4kRn/68+f yienBX9PqHEVdPEftn1LN1j9hOCokvjahVHshyc7dPn6Zf2AzlCeDlKvG9GMWB9E4OgN L2Ew==
Received: by 10.68.229.201 with SMTP id ss9mr12915837pbc.80.1348210452898; Thu, 20 Sep 2012 23:54:12 -0700 (PDT)
Received: from [192.168.0.102] (ppp-110-169-206-48.revip5.asianet.co.th. [110.169.206.48]) by mx.google.com with ESMTPS id nt7sm4700699pbb.33.2012.09.20.23.54.10 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 23:54:12 -0700 (PDT)
Message-ID: <505C0F10.3020106@gmail.com>
Date: Fri, 21 Sep 2012 13:54:08 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <E4A11012-4F89-455F-AC98-57F188456D91@gmail.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> <B5943A55-6A2A-4977-A06C-B9DA9FDABF1E@nostrum.com>
In-Reply-To: <B5943A55-6A2A-4977-A06C-B9DA9FDABF1E@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "dime@ietf.org" <dime@ietf.org>
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 06:54:15 -0000

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.

...