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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
