Re: [v6ops] RFC6555 / Multiple interfaces

On 27/12/2016 21:43, Mark Smith wrote:
> Courtesy of Fred a while back. Multi-addressing is a form of multihoming.

Yes, if the different interfaces use different addresses. It's not as if
RFC6555 ignores this issue: see sections 5.3 and 5.4. And it's not as if
the former MIF WG ignored this issue:
https://datatracker.ietf.org/doc/draft-ietf-mif-happy-eyeballs-extension/
which is still an active document.

    Brian

> 
> 
> https://tools.ietf.org/html/draft-baker-happier-eyeballs-00
> 
> On 27 Dec. 2016 19:05, "Asveren, Tolga" <tasveren@sonusnet.com> wrote:
> 
>>>> Was/Is there a technical reason why RFC6555 does not address use of
>>> multiple interfaces, e.g. WiFi and LTE, in addition to different IP
>> address
>>> families?  Would you consider such an enhancement -assuming no technical
>>> issues- as a candidate for a potential RFC6555-bis or as a new work item?
>>>
>>> It addresses matters in which the application has more than one address
>> to
>>> choose from, and the outcome of its choice potentially varies from
>> address
>>> to address and from event to event. The document discusses IPv4 and IPv6;
>>> from my perspective, there is no significant reason it couldn’t be
>> between
>>> two IPv4 addresses, or among a long list of IPv6 addresses. The issue is
>> the
>>> fact of making a choice, and not wanting to wait for a TCP timeout before
>>> wondering about the next.
>>>
>>> Whether the address in question is applied to an Ethernet, a Wifi, an LTE
>>> interface, or something else, is a layer that it presumes the
>> application to not
>>> see or not be vitally interested in. If the device wanted to prefer Wifi
>> over
>>> LTE, for example, it could choose to try the address associated with the
>> Wifi
>>> before the LTE, and if it turned out that the Wifi didn’t work at that
>> instant,
>>> the LTE would likely wind up being chosen.
>>>
>>> Speaking strictly for myself, I would want to see the argument made as to
>>> why this need further work. If I were to embrace and extend 6555, I
>> might do
>>> it in a single sentence very similar to my opening sentence in this
>> reply.
>> [TOLGA] Agreed on all technical points. Agreed also that what is needed is
>> probably a short section with a few paragraphs.
>> Regarding the question "Why do we need this explanation?": I think the
>> answer is similar to why RFC6555 was needed to start with. Overall, the
>> idea (both for this potential mini-extension and happy-eyeballs in general)
>> is relatively straightforward and can be categorized as "common sense" (or
>> if I dare to say a "no-brainer"). Nonetheless specifying it in an IETF
>> document still has benefits as it gets more legs to be deployed/promoted
>> widely. And let's don’t forget there still is some normative behavior
>> defined in RFC6555 by using RFC2119 verbiage. I think the extension about
>> use of multiple interfaces would have a few such sentences as well.
>> So, as a summary, I don’t think the extension would require any
>> "architectural changes" in the happy-eyeballs philosophy, is needed/would
>> be used though and I wouldn’t expect it to consume much energy. I can craft
>> some text if there is a "Go" from the V6ops WG/Chairs.
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 