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

[Juliusz Chroboczek <[e-mail]>]

Thanks, Benjamin.

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

Clarified.

> 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,

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.

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

Right.  Removed.

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

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

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

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

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

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.

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

Added Section 4.5.

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

Done.

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

Done.

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

Done.

-- Juliusz