Re: Roman Danyliw's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Roman,

Thanks a lot for reviewing such a long draft ;)

On Wed, Jun 26, 2019 at 10:57 PM Roman Danyliw via Datatracker
<[e-mail]> wrote:
> A few questions and comments:
>
> (1) Section 1. Per “That is, some routers must be capable of some form of
> Source Address Dependent Routing (SADR), if only as described in [RFC3704]”,
> I’m not sure what minimal SADR technique is being described in RFC3704.  What
> section?

Added the link to the section 4.3 of [RFC3704].

> (2) Section 3.5.  Per “However, when evaluating scalable implementations of the
> solution, it would be reasonable to assume that the maximum number of ISPs that
> a site would connect to is five”, what is the basis of the up to _five_ ISPs?

Added some clarification:
"
(topologies with two redundant routers each having two uplinks to
different ISPs plus a tunnel to a headoffice acting as fifth one are
not unheard of)."

> (3) Section 5. Per “If all of the ISP uplinks are working, the choice of source
> address by the host may be driven by the desire to load share across ISP
> uplinks …”, how does an individual host have enough information to make that
> kind of decision?

Well, it's a bit out of scope of this draft to discuss all possible
mechanisms but I've added some clarification by adding the following
text:

"
(if some information
uplinks is not working, then the choice of source address by the host
about various path properties has been made availabe to the host
can determine if packets get dropped. somehow - see
[I-D.ietf-intarea-provisioning-domains] as an example)."

> (4) Section 5.  Per “An external host initiating communication with a host
> internal to a PA multihomed site will need to know multiple addresses  for that
> host in order to communicate with it using different ISPs to the multihomed
> site.”, what is mean by “in order to communicate with it using different ISPs”?
>  Why would being multi-homed this matter?  Wouldn’t one IP address be
> sufficient?

Added a sentence to clarify:
"(knowing just one address would undermine all benefits of redundant
connectivity provided by multihoming)."

>Section 9.  Per “It recommends that a given host verify the
> original packet header included into ICMPv6 error message was actually sent by
> the host itself”, is this guidance to the host or to network stack implementers?

I'm not sure if it does matter here (at this draft level of
granularity "host" is mostly equal to 'it's network stack".
Do you have any suggestions on how you'd like it to be phrased? For
I'm a bit lost here..

> (5) Section 9.  Given the current (helpful) text about the threat of a spoofed
> ICMPv6 message, it would be equally useful to discuss the threat to the other
> approach in Section 5 (i.e., DHCPv6) – a rogue DHCPv6 server.

The reason DHCPv6 is not discussed is that the draft concludes that
it's not a  suitable mechanism anyway. The draft concludes that RAs
should be used (with some help of ICMPv6) and the discusses the
security aspect of the recommended approach (ICMPv6 + Neighbor
Discovery/RAs)

> A few editorial nits:

All fixed, thanks for pointing them out!

-- 
SY, Jen Linkova aka Furry