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

[Jen Linkova <[e-mail]>]

Hi Alvaro,

Thanks a lot for your comments!
I've just posted -09 version which shall have your comments addressed
- please let me know if I missed anything.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/

On Wed, Jun 26, 2019 at 1:01 AM Alvaro Retana via Datatracker
<[e-mail]> wrote:
> Substantive
>
> (A) It would be nice to add a short terminology section to at least include
> important terms every reader may not be familiar with: PA, PI,
> provider-aggregatable.

Very good point, added the Terminology section.
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-3

> Other terms that are used but not clearly described, which would benefit from a
> definition include "SADR domain" and source-prefix-scoped
> routing/destination/forwarding table...or more-specific-source-prefix-scoped
> forwarding table.  Note that some of the examples help, but going through them
> is not the best way to find out the meaning.

Added them to the Terminology section too:

> (B) §4: "if all routers in a given network support SADR and have a scoped
> forwarding table, then the unscoped forwarding table can be eliminated which
> ensures that packets with legitimate source addresses only can leave the
> network"  This statement is true for traffic existing the network, but not in
> the general case where the unscoped table has to be used to deliver, for
> example, packets originated in the Internet to H32 (or any internal host).  If
> the unscoped forwarding table is eliminated, then how are those packets routed?
>  Am I missing something?

Ah, very good catch. Removed the paragraph.

> (C) §5.2.2: "[RFC8028] recommends that a host SHOULD select default routers for
> each prefix in which it is assigned an address.  It also recommends that hosts
> SHOULD implement Rule 5.5. of [RFC6724]."  These SHOULDs are not Normative in
> this document, but come from rfc8028.  I think there should either be a direct
> quotation or Normative language shouldn't be used.
>
> §5.6/§6 also mention Normative language from rfc8028 without properly quoting
> it.

Fixed.

>
> (D) The documents talks in several places about SADR support and how it is not
> necessary for all routers in the enterprise to support it.  There are some
> mentions of this as examples are described...  However, there is no clear
> guidance about the considerations for deploying a "SADR domain" in the network,
> and should be covered in the Deployment Considerations section.

Added the Deployment Consideration section:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-7

Please let me know if that's what you are looking for.

> (E) I think that rfc4443, rfc4861, rfc4862, rfc6724 and rfc7078 should all be
> Normative references.

Done.

> (F) This point is for the WG Chairs/AD.  I don't think changes to this document
> are needed, but will leave that up to the Chairs/AD.

I guess I shall leave it for the Chairs/AD to comment..

> Editorial/Nits:
>
> (1) I think a title with "Solutions" (not "Solution") at the end would better
> reflect the contents.

Fixed.

> (2) §1: "Multihoming with provider-assigned addresses is typically less
> expensive for the enterprise relative to using provider-independent addresses."
>  I assume you mean "less expensive" from the point of view of acquiring the
> addresses, right?  However, operationally it may be more expensive because of
> the need to manage more moving parts, either NATs, or the mechanisms described
> in this document.  It might be good to clarify.

Rephrased as

'Multihoming with provider-assigned addresses is typically less
expensive for the enterprise relative to using provider-independent
expensive for the enterprise relative to using provider-independent
addresses. PA multihoming is also a practice that should be addresses
as it does not require obtaining and maintaining PI address
facilitated and encouraged because it does not add to the size of the
space as well as running BGP between the enterprise and the ISPs (for
Internet routing table, whereas PI multihoming does. Note that PA is
small/meduim networks running BGP might be not just undesirable but
also used to mean "provider-aggregatable". In this document we
impossible, especially if residential-type ISP connections are used).'

Is it better?


> (3) s/Section 7 discussed other solutions/Section 7 discusses other solutions
>
> (4) s/router(SER)/router (SER)

Fixed.

> (5) §3.2: "using GRE for example"  A reference would be nice.

Added the reference to rfc7676.

> (6) §1: "...some routers must be capable of some form of Source Address
> Dependent Routing (SADR), if only as described in [RFC3704]."  rfc3704 doesn't
> talk about SADR, at least not with that name.  Maybe pointing to §4.3 could
> help.

Added.

> (7) §4: "...then add the entry to the more source-prefix-scoped forwarding
> table."   The more what??

s/to the more source-prefix-scoped forwarding table/to the more
specific source-prefix-scoped forwarding table/

> (8) s/As as an example/As an example
>
> (9) s/while for `2001:db8:0:b101::31/while for 2001:db8:0:b101::31
>
> (10) s/H01/H101

All fixed.

> (11) The first reference to rfc8415 is in §5.2.1.  It would be nice to make it
> earlier, maybe when DHCPv6 is first mentioned.

Fixed. Added the reference for the very first appearance of DHCPv6 in the text.

> (12) "DHCPv6 support is not a mandatory requirement for IPv6 hosts, so this
> method might not work for all devices." A reference to rfc8504 might be nice.

It's actually reference to rfc6434 - "IPv6 node requirements" - the
reference added.

> (13) Given that I-D.pfister-6man-sadr-ra was last updated in 2015, and that it
> "might need tweaking", I think this document shouldn't even mention it.

Unless you have strong opinion on it I'd rather keep it for a reference.

> (14) s/this is traffic is not following/this traffic is not following
>
> (15) s/An site administrator/A site administrator
>
> (16) The first reference to rfc4443 is in §5.2.3.  It would be nice to make it
> earlier, maybe when ICMPv6 is first mentioned.
>
> (17) s/reach the a host on the Internet/reach a host on the Internet

All fixed.

> (18) [style nit/personal preference] Much of the text is written in first
> person ("In this document we assume that...").  I find the use of the third
> person ("In this document it is assumed that..." or "This document assumes...")
> more appropriate in IETF documents.  Maybe just a manner of taste...

Well, I have not addressed this one - how strong do you feel about it?
Point taken for future drafts but I'm a bit reluctant (read: lazy) to
update this one...
Unless you really want me to..

-- 
SY, Jen Linkova aka Furry