Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-v4viav6-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 14 Feb 2022 13:17:31 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-babel-v4viav6-07: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/

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

Overall this is well written and fun to read -- thanks!

Section 2

                This extension defines a new AE, called v4-via-v6, which
   has the same format as the existing AE for IPv4 addresses.  This new
   AE is only allowed in TLVs that carry network prefixes: TLVs that
   carry a neighbour address use one of the normal encodings for IPv6
   addresses.

(Could neighbor addresses also be IPv4 addresses?)

Section 2.2

   *  the next hop MUST be computed as for an IPv6 route, as described
      in Section 4.6.9 of [RFC8966]: it is taken from the last preceding
      Next Hop TLV with an AE field equal to 2 or 3; if no such entry
      exists, and if the Update TLV has been sent in a Babel packet
      carried over IPv6, then the next hop is the network-layer source
      address of the packet.

This phrasing implies that the Update TLV carrying a v4-via-v6 entry might
be carried over something other than IPv6, which in turn would require us
to specify some behavior for handling it (specifically, when there is no
preceding Next Hop TLV with AE of 2 or 3).

   As usual, a node MAY ignore the update, e.g., due to filtering
   (Appendix C of [RFC8966]).  If a node cannot install v4-via-v6
   routes, e.g., due to hardware or software limitations, then routes to
   an IPv4 prefix with an IPv6 next hop MUST NOT be selected, as
   described in Section 3.5.3 of [RFC8966].

I'm not entirely sure what the §3.5.3 reference is intending to point to.
That section does cover route selection in a certain sense, but mostly
discusses feasibility as the selection criterion, not "installability".
So I don't see it as a useful reference for "don't select routes you can't
install", and am not sure that a reference for specifically "route
selection" is needed here.

Section 2.3

   When receiving requests, AEs 1 (IPv4) and 4 (v4-via-v6) MUST be
   treated in the same manner: the receiver processes the request as
   described in Section 3.8 of [RFC8966].  If an Update is sent, then it
   MAY be sent with AE 1 or 4, as described in Section 2.1 above,
   irrespective of which AE was used in the request.

(editorial) The referenced §2.1 doesn't use the "AE" phrasing to describe
this scenario, which makes it harder for a reader to cross-reference to
the intended content.

   When receiving a request with AE 0 (wildcard), the receiver SHOULD
   send a full route dump, as described in Section 3.8.1.1 of [RFC8966].
   Any IPv4 routes contained in the route dump MAY use either AE 1
   (IPv4) or AE 4 (v4-via-v6), as described in Section 2.1 above.

The "MAY" here (and above, I suppose) feels a little confusing, as a
literal reading of it gives the sender blanket permission to freely choose
between AE=1 and AE=4, whereas in reality there are some preconditions on
the use of AE=4 (namely, having an IPv6 next hop).  In other words, what's
described in §2.1 is not actually an unqualified "MAY use either", so it's
misleading to summarize it that way.  Would it be better to avoid any
normative keywords here and just say that "the procedures for sending the
Update TLVs comprising the full route dump are described in Section 2.1
above"?

Section 4.1

   A new compression state for AE 4 (v4-via-v6) distinct from that of AE
   1 (IPv4) is introduced, and MUST be used for address compression of
   prefixes tagged with AE 4, as described in Section 4.6.9 of [RFC8966]

The string "compress" does not appear in §4.6.9 of RFC 8966.  Was a
different section intended?

Section 4.2

   As AE 4 (v4-via-v6) is suitable only for network prefixes, IHU
   (Type = 5) and Next-Hop (Type = 7) TLVs MUST NOT be tagged with AE 4.
   Such (incorrect) TLVs MUST be ignored upon reception.

We already imposed this requirement to not send AE=4 in IHU and Next-Hop;
best practice is to use normative keywords exactly once when stating a
given requirement, and refer to that statement of the requirement in
situations where a reminder of the requirement is needed.

Section 4.2.1

   *  Next Hop.  The next hop is determined as described in Section 2.2
      above.

I'd consider emphasizing that the "determined" here applies both when
constructing and receiving the Update.

Section 5

   ignore v4-via-v6 routes.  They will also ignore requests with AE 4,
   which, as stated in Section 2.3, are NOT RECOMMENDED.

In a similar vein as my comment on §4.2, I'd suggest the lowercase "not
recommended" here.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 24 Feb 2022 18:21:15 +0100

Thanks, Benjamin.

> (Could neighbor addresses also be IPv4 addresses?)

Clarified.

> be carried over something other than IPv6,

Yes.

> which in turn would require us to specify some behavior for handling it
> (specifically, when there is no preceding Next Hop TLV with AE of 2 or
> 3).

Section 4.6.9 of RFC 8966:

   otherwise, this Update MUST be ignored.

I don't think it deserves being repeated here, any implementation of
RFC 8966 must already handle that case.

> I'm not entirely sure what the §3.5.3 reference is intending to point to.

Right.  Removed.

> selection" is needed here.

Aside: I think that's a weak point of RFC 8966, it does not specify the
required alignment between the data plane and the control plane.
Unfortunately, I don't know of a good reference for that, it seems to me
like that's something that "everyone knows" must be done, but isn't
actually written down.  (And I don't think it's obvious.)

> this scenario, which makes it harder for a reader to cross-reference to

Right.  Fixed, but the other way than what you suggest, by repeating the
wording of 2.1 in 2.3.

> Update TLVs comprising the full route dump are described in Section 2.1

I've replaced "MAY" with "may", but I've kept the current wording, since
I think it's worth repeating that the request does not dictate the way the
updates are encoding.

> different section intended?

Added Section 4.5.

> situations where a reminder of the requirement is needed.

Done.

> constructing and receiving the Update.

Done.

> In a similar vein as my comment on §4.2, I'd suggest the lowercase "not

Done.

-- Juliusz

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 24 Feb 2022 18:14:33 -0800

Hi Juliusz,

> Thanks, Benjamin.

Thanks to you as well for the replies and updates to the document!

My only remaining comment (from skimming the diff), a nit really, is that
in IPv4 all of 127/8 is loopback, so we should say "a loopback address"
rather than "the loopback address".

-Ben