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

[Alissa Cooper]

Jen, thanks for the updates. Pete, thanks for your response. I cleared my 
DISCUSS.

Cheers,
Alissa

> On Jul 3, 2019, at 10:58 PM, Pete Resnick  wrote:
> 
> 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
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Pete Resnick]

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Jen Linkova]

Hi Pete,

On Tue, Jul 2, 2019 at 8:47 AM Pete Resnick  wrote:
> 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".

Done!

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

Done, thanks for suggesting the text.

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

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

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

> 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

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


-- 
SY, Jen Linkova aka Furry

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Pete Resnick]

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 

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

[Jen Linkova]

Hi Pete,

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

On Wed, Jun 5, 2019 at 1:42 AM Pete Resnick via Datatracker
 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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Alissa Cooper]

Pete, thank you for your review. I entered a DISCUSS ballot on the basis of 
your first point.

Alissa

> On Jun 4, 2019, at 11:41 AM, Pete Resnick via Datatracker  
> wrote:
> 
> Reviewer: Pete Resnick
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-rtgwg-enterprise-pa-multihoming-08
> Reviewer: Pete Resnick
> Review Date: 2019-06-04
> IETF LC End Date: 2019-06-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Almost Ready.
> 
> 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.
> 
> Major issues:
> 
> None.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
>   A host SHOULD be able respond dynamically...
> 
> Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art