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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux