Hi Roman, Thanks a lot for reviewing such a long draft ;)
On Wed, Jun 26, 2019 at 10:57 PM Roman Danyliw via Datatracker <[email protected]> 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
