[Int-area] Review of draft-ietf-intarea-provisioning-domains

[Ted Lemon <[e-mail]>]

As requested, I'm doing a review of the document.   Executive summary: I don't think the document is ready.   I don't actually think the proposed model for doing multiple RAs makes sense.   I don't think it makes sense to tie in the HTTP/JSON stuff.   It feels vague and underspecified.   I think that an RA option for specifying PvD IDs is a good idea, and I will admit that I missed some of the discussion that I think resulted in the changes that I'm complaining about.   I think the tie to DHCP is pretty half-baked, particularly the IPv4 part.   I realize that this is partly because of some IPR issues, but I don't think this is the right way to address that.   I think this needs further discussion.

On to the detailed comments:

I think that the Abstract isn't going to make much sense to anyone who isn't already familiar with the problem space, so I have some suggestions for addressing that.

OLD:
   An increasing number of hosts access the Internet via multiple
   interfaces or, in IPv6 multi-homed networks, via multiple IPv6 prefix
   configurations.
NEW:
   An increasing number of hosts access the Internet simultaneously through
   networks managed by different providers.  This is true of devices with mobile
   and fixed interfaces, and also of devices connected to networks that are
   multihomed—that are connected to more than one internet service provider.

OLD:
   This document describes a way for hosts to identify such means,
   called Provisioning Domains (PvDs), with Fully Qualified Domain Names
   (FQDN).  Those identifiers are advertised in a new Router
   Advertisement (RA) option and, when present, are associated with the
   set of information included within the RA.
NEW:
   This document describes a way to signal to hosts that have access
   to one or more provisioning domains (PvDs), using Fully Qualified Domain Names
   (FQDN) as identifiers.  These identifiers are advertised in a new Router
   Advertisement (RA) option and, when present, identify information in the RA
   that is specific to a particular provisioning domain.

OLD:
   Based on this FQDN, hosts can retrieve additional information about
   their network access characteristics via an HTTP over TLS query.
   This allows applications to select which Provisioning Domains to use
   as well as to provide configuration parameters to the transport layer
   and above.
NEW:
   This allows applications to select which Provisioning Domains to use
   as well as to provide configuration parameters to the transport layer
   and above.      Based on this FQDN, hosts can retrieve additional information about
   their network access characteristics using an HTTP over TLS query.

Even this might not really be the right set of changes, though.  I have a bit of a bias toward very brief abstracts, because the abstract is basically an elevator pitch for the document, and this abstract is more detailed, like a brief introduction.   As an alternative, you might consider this text:

This document defines a mechanism for signaling to hosts that they are connected to more than one service provider.  This can be used for example if a host has two interfaces with different providers, like the mobile and fixed interfaces of a smart phone.  It can also be used on multi-homed networks, where the network to which the host is connected may have available service from more than one provider.  It further defines a naming scheme for these provisioning domains, a router advertisement extension for announcing them, and a schema for acquiring additional information using HTTP.

I think this conveys everything that the reader needs to know in order to decide whether to read the document.   They can find out how these mechanisms work by reading the document (I hope!).

OLD:
   It has become very common in modern networks for hosts to access the
   internet through different network interfaces, tunnels, or next-hop
   routers.  To describe the set of network configurations associated
   with each access method, the concept of Provisioning Domain (PvD) was
   defined in [RFC7556].
NEW:
   It has become very common in modern networks for hosts to have available
   more than one way of accessing the Internet at the same time, and for these
   access methods to have different and sometimes incompatible configuration
   information.  To describe the set of network configuration information associated
   with each access method, the concept of Provisioning Domain (PvD) was
   defined in [RFC7556].

OLD:
   This document also introduces a way for hosts to retrieve additional
   information related to a specific PvD by means of an HTTP over TLS
   query using an URI derived from the PvD ID.  The retrieved JSON
   object contains additional information that would typically be
   considered unfit, or too large, to be directly included in the Router
   Advertisement, but might be considered useful to the applications, or
   even sometimes users, when choosing which PvD and transport should be
   used.
NEW:
   This document also introduces a way for hosts to retrieve additional
   information related to a specific PvD by means of an HTTP over TLS
   query using an URI derived from the PvD ID.  The retrieved JSON
   object is used to convey information that either would not fit, or for which
   no encoding is available, in a router advertisement.   This information
   can be used by applications, or presented to users, when choosing
   which PvD and transport should be used.

On page 6:
   RA message header :   (16 octets) When the A-flag is set, a full
      Router Advertisement message header as specified in [RFC4861].
      The 'Type', 'Code' and 'Checksum' fields (i.e. the first 32 bits),
      MUST be set to zero by the sender and ignored by the receiver.
      The other fields are to be set and parsed as specified in
      [RFC4861] or any updating documents.

I don't know if this has already been discussed—I'm sure there's some rationale behind this decision.  But why burn 32 bits on this?

In section 3.2:
   A router MAY send RAs containing at most one PvD ID RA option, but
   MUST NOT include more than one PvD ID RA option in each RA.  In
   particular, the PvD ID RA option MUST NOT contain further PvD ID RA
   options.

I don't think you should say "in particular" here.   I don't think the particular example given is more important than the other case. :)

Then:
   Whenever an RA, for a single PvD, would need to be sent via multiple
   packets, the PvD ID RA option header (i.e., all fields except the
   'Options' field) MUST be repeated in all the transmitted RAs.  But
   the options within the 'Options' field, MAY be transmitted only once,
   included in one of the transmitted PvD ID RA options.

When would an RA for a single PvD need to be sent in multiple packets?   I'm not saying it wouldn't—I just mean that this scenario needs to be explained.

In 3.3:
   Hosts MUST associate received RAs and included configuration
   information (e.g., Router Valid Lifetime, Prefix Information
   [RFC4861], Recursive DNS Server [RFC8106], Routing Information
   [RFC4191] options) with the explicit PvD identified by the first PvD
   ID Option present in the received RA, if any, or with the implicit
   PvD identified by the host interface and the source address of the
   received RA otherwise.

What's the point of encapsulating options in a PvD if options that aren't encapsulated in the PvD are also part of the PvD?   What's the behavior if an option appears in the RA outside of the PvD option, and the same type of option appears inside of the PvD option?

Then:
   In case multiple PvD ID options are found in a given RA, hosts MUST
   ignore all but the first PvD ID option.

It seems like this is a programming error, and attempting to proceed is probably a mistake.   Such packets should be silently dropped.

There is no specification of host behavior, which is great.   However, the examples here don't feel very clear, and I don't think they really help.   If we want to talk about how hosts use PvDs, the text here isn't enough.   If we don't, this section would be made clearer by removing this text and making the description of what winds up in what PvD more explicit.   I'd be happy to discuss this, but I don't want to propose specific text without a discussion first.

Sections 3.3.1 and 3.3.2

The DHCPv6 and DHCPv4 behaviors specified here seem like they aren't very clear, and it's hard to imagine that implementors will know what is intended.   I do not know what is intended.   It might be worth sitting down and gaming out the possible combinations, so that a more clear specification can be made.   However, I think it's also likely that section 3.3.2 should just say "Configuration information received via DHCPv4 SHOULD NOT be treated as part of an explicit or implicit PvD received through an RA."   Is there a reason not to do that?

I really do not like the PvD additional information feature.   I think this should be considered as a separate document.   The problem isn't so much that it's a bad idea, but that it really muddies the water—it makes this document harder to understand, because it adds essentially unrelated additional complexity.   Why is this in the same document with the RA option?

Section 5 makes me feel pretty uncomfortable about this proposal—you're changing the behavior of the host stack if it supports PvDs in a way that doesn't really make sense, but rather is just an artifact of the fact that this document requires the sending of redundant RAs. What's the rationale for doing this?