Re: Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

["Pete Resnick" <[e-mail]>]

Hi Jen,

Thanks for the reply, and the new draft. Some comments, inline:

On 1 Jul 2019, at 10:24, Jen Linkova wrote:

>> Throughout, but particularly in section 5, this document refers to 
>> "hosts"
>> doing address selection. To be fair, so does RFC 6724, but 6724 is 
>> referring to
>> *default* address selection. In reality, *applications* do address 
>> selection on
>> a host; the host stack will only do address selection if the 
>> application
>> requests a default address.
>
> Oh. Very good point - looks like I assumed that it's obvious and did
> not mention it anywhere explicitly. Yes, all address selection
> processes mentioned are for new connections.
> And indeed the applications/upper-layers could override the default
> address selection algorithm..

It's not just that the address selection is for new connections, though 
that is certainly true. It's also the question of who is doing what: 
Hosts figure out the address for default address selection, and 
applications are the ones that do the selecting (whether it is to choose 
the host default or choose a different one). Part of what the document 
is missing is use of the word "default", at least in a few places. So, 
in -09, a couple of suggestions:

In the Abstract, change "select appropriate source addresses" to "select 
appropriate default source addresses".

In the Introduction, you have:

    Section 6 discusses existing and proposed
    mechanisms for hosts to select the source address applied to 
packets.
    It also discusses the requirements for routing that are needed to
    support these enterprise network scenarios and the mechanisms by
    which hosts are expected to select source addresses dynamically 
based
    on network state.

Hosts definitely don't select the source address to be applied to any 
given packet; that's (at best) an application thing. Also, "dynamically" 
here seems to imply "during the life of the connection", but that's 
certainly not what you meant. Something like this seems better:

    Section 6 discusses existing and proposed mechanisms for hosts to
    select the default source address to be used by applications.
    It also discusses the requirements for routing that are needed to
    support these enterprise network scenarios and the mechanisms by
    which hosts are expected to update default source addresses based
    on network state.

Again, hosts pick default addresses for applications to use, and 
applications pick the addresses that packets will use. So even in your 
updated text:

> I've added some text to clarify. In particular:
>
> 1) Section 6:
> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#page-24
>
>    First we look at how a host is currently expected to select the
>    source and destination address with which it sends a packet for a 
> new
>    connection.

Saying "sends a packet" is the problem. The host doesn't pick the 
address with which it's going to send a packet. If it did, it would be a 
nifty dynamic process like shim6 (or, one layer up, mptcp). Hosts can 
only pick the default address for an app to use.

> 2) Section 6.1
> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.1
>
>    It should be noted that [RFC6724] defines the default behaviour for
>    IPv6 hosts.  The applications and uppler-layer protocols can make
>    their own choices on selecting source addresses.  However the
>    mechanism proposed in this document attempts to ensure that the
>    subset of source addresses available for applications and 
> upper-layer
>    protocols is selected with the up-to-date network state in mind.

How about this? :

"It should be noted that [RFC6724] only defines the behavior of IPv6 
hosts to select default addresses that applications and upper-layer 
protocols can use. Applications and upper-layer protocols can make their 
own choices on selecting source addresses. The mechanism proposed in 
this document attempts to..."

I'd also suggest taking a look through the rest of section 6 for use of 
the word "host" and see if the word "default" needs to be inserted 
somewhere after it (like "...hosts to choose the correct *default* 
source address"), or if it needs to be changed to "application".

>> I don't think the above invalidates the core of the document or 
>> requires some
>> grand rewrite. But I do think some clarification is in order, saying 
>> that the
>> mechanisms described help with the *default* address selection, and 
>> some short
>> discussion of the limitations for what applications can (and more 
>> importantly
>> cannot) do with these mechanisms would be useful.
>
> I've added Section 6.7 - Solution Limitations
>
> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.7
>
> If you could review and let me know if it addresses your concern, it
> would be great!

Nice. If it were me, I'd add a forward pointer to mptcp in 8.3 as 
another mechanism (in addition to BGP) to deal with the problem.

>> My suspicion is that section 7.3 underestimates the availability 
>> (current and
>> future) of multipath transport. Apple is using it now in production, 
>> and Linux
>> already has it in their implementation. I think this is actually a 
>> reasonable
>> possible solution in the future, and I would be a little more 
>> optimistic than
>> the WG in this section.
>
> I've added "(even if new releases of operating systems get multipath
> protocols support
>    there will be a long tail of legacy hosts)."
> to clarify my lack of optimism..

You can have the half empty glass; I'll take the half full one. ;-)

>> Nits/editorial comments:
>>
>> Two editorial bits in section 1:
>>
>>    This document defines routing requirements for enterprise 
>> multihoming
>>    using provider-assigned IPv6 addresses.  We have made no attempt 
>> to
>>    write these requirements in a manner that is agnostic to potential
>>    solutions.  Instead, this document focuses on the following 
>> general
>>    class of solutions.
>>
>> Is that second sentence right? If you are giving a general class of 
>> solutions,
>> that seems agnostic to the particular solution. Just a bit confusing.
>
> Updated.
>
>>
>>    A host SHOULD be able respond dynamically...
>>
>> Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems 
>> overdone.
>
> Fixed, thanks!
>
> -- 
> SY, Jen Linkova aka Furry

Thanks for your work to address these.

pr
-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best