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 additional updates. A few comments inline.

On 3 Jul 2019, at 20:07, Jen Linkova wrote:

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?

Well, yes, to a certain extent. But my point here was a bit different: Even if we call it "the network stack on a host", it isn't picking the addresses that packets will use, at least not on a packet-by-packet basis. That gets back to the point about dynamic updates: Even if the host stack were to change its mind about which the correct address is, that host isn't using that new address for packets unless/until currently running apps shut down their existing connections and make new ones. They're using the old address until doing so actually fails, and then only if they reinitiate communications. The "stack" can't change that, it can only suggest to the upper layers that they stop using what they're currently using. (You've talked about this in the new paragraph in 6.)

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?

Yes, that'll be OK.

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.

There are still quite a few places that I would change in section 6, but I'll leave it to Alissa to decide which (if any) are really worth diving into. I think now you understand what I'm trying to get at.

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

Sorry, I wasn't clear: I meant it would be nice if there reference in 6.7.1 to section 8.3, or a mention in 6.7.1 of MPTCP in addition to its mention of BGP.

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

Fair enough.

Thanks again for the updates. As the boilerplate for the review says, wait for instructions from your AD for further guidance, particularly in order to address Alissa's DISCUSS.

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