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

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Jul 2019 01:24:12 +1000

Hi Pete,

Thanks for reviewing the draft - not the shortest one...;)

On Wed, Jun 5, 2019 at 1:42 AM Pete Resnick via Datatracker
<[email-masked]> wrote:
> I found this overall to be an excellent document with clear technical
> explanations that even an upper-layer knucklehead like me could understand.
> However, there a couple of issues could use more discussion. I put them as
> "Minor issues", in that they're not showstoppers, but I do think they're
> important and hope you'll be able to address them.
>
> Minor issues:
>
> 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. That works well for the scenarios in 6724, but in
> this document, for example section 5.2.3, I'm not so sure. The idea that a host
> would receive an ICMP destination unreachable and re-arrange its address
> selection seems at least an incomplete picture: An application with a (normal,
> non-multi-path) TCP connection to a remote application is not able to "try
> another source address to reach the destination"; the source address is already
> set for that TCP connection, so the only choice is to close the connection
> entirely. If the application chooses to re-establish the connection with a
> default address, yes, the host stack could then give a new default address back
> to the application, but this is hardly the dynamic and quickly adjusting
> process that the document seems to be envisioning.

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

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.

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

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

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

> 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

---

From: "Pete Resnick" <[email-masked]>
Date: Mon, 01 Jul 2019 17:46:56 -0500

Hi Jen,

Thanks for the reply, and the new draft. Some comments, inline:

On 1 Jul 2019, at 10:24, Jen Linkova wrote:

>> requests a default address.
>

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 

>    source and destination address with which it sends a packet for a 

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.

>    It should be noted that [RFC6724] defines the default behaviour for
>    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".

> If you could review and let me know if it addresses your concern, it

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.

> to clarify my lack of optimism..

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

>> Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems 

Thanks for your work to address these.

pr
-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best

---

From: Jen Linkova <[email-masked]>
Date: Thu, 4 Jul 2019 11:07:44 +1000

Hi Pete,

> appropriate default source addresses".

Done!

>     which hosts are expected to update default source addresses based

Done, thanks for suggesting the text.

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

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

> source address"), or if it needs to be changed to "application".

I've updated a number of places as well.

> 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

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

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 03 Jul 2019 21:58:11 -0500

Hi Jen,

Thanks for the additional updates. A few comments inline.

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

>> their

Yes, that'll be OK.

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

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

> 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