Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

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

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