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

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-rtgwg-enterprise-pa-multihoming-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work on this document!!

I have several comments below -- some of them are substantive and I would like
to see them addressed before publication.

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.

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.

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

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

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

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

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

§4 says:

   Note that the mechanism described here for converting source-prefix-
   scoped destination prefix routing advertisements into forwarding
   state is somewhat different from that proposed in
   [I-D.ietf-rtgwg-dst-src-routing].  The method described in the
   current document is functionally equivalent, but it is intended to be
   easier to understand for enterprise network operators.

This text makes me wonder about the relationship to
I-D.ietf-rtgwg-dst-src-routing, which is currently marked as on the Standards
Track (at least on the document itself), and makes no reference to this
document (but it does point to rfc8043).  Should the two be more closely
related?  This document "attempts to define a complete solution" for the
multihoming problem, which is one of the use cases in
I-D.ietf-rtgwg-dst-src-routing -- it seems like the answer could be Yes.

The question might be more appropriate in the context of
I-D.ietf-rtgwg-dst-src-routing, but I'm asking it now because of the explicit
mention (above), and discussion in the WG around the compatibility of the two
documents (for example in [1]).   This makes me think that it is an important
point to consider before publication of this document.

[1] https://mailarchive.ietf.org/arch/msg/rtgwg/n2K1ZDD_Fco1CO7Oy4ZQ6MYJebg

Editorial/Nits:

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

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

(3) s/Section 7 discussed other solutions/Section 7 discusses other solutions

(4) s/router(SER)/router (SER)

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

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

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

(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

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

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

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

(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

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