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

[Jen Linkova <[e-mail]>]

Hi Pete,

On Tue, Jul 2, 2019 at 8:47 AM Pete Resnick <[e-mail]> wrote:
> 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".

Done!

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

Done, thanks for suggesting the text.

> Again, hosts pick default addresses for applications to use, and
> applications pick the addresses that packets will use.

OK, I guess we are just using different terminology here...
For me 'a host' is a whole element connected to the network, including
all subsystems and applications running.
Until your email I was thinking about an application as an element of
a host. If I got you right, when the draft says 'host' you read it as
'network stack on a host', right?

> 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've updated that paragraph:

"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 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. The rest of the
document discusses various aspects of the default source address
selection defined in [RFC6724], calling it for the sake of brevity
"the source address selection".

I hope that the last sentence makes the rest of the document less confusing.
What do you think?

> 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've updated a number of places as well.

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

It is there:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3

> >> My suspicion is that section 7.3 underestimates the availability
> >> (current and
> >> future) of multipath transport.

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

As per Magnus's suggestion, I've updated the text to mention that
PA-based multihoming and MP transport could benefit from each other:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3


-- 
SY, Jen Linkova aka Furry