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

[jouni korhonen <[e-mail]>]

Glen,

On Sep 21, 2012, at 9:54 AM, Glen Zorn wrote:

> 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 

Obviously you use the address you received CER/CEA from.. and if that address is not included in the
list of Host-IP-Addresses then the other end is on weeds.

> 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.

Might be a good thing.

- Jouni

> 
> ...
>