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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-babel-source-specific-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/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-babel-source-specific/



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

Section 3.1

   Note that the route entry contains a source (see sections 2 and 3.2.5
   of [BABEL]) which itself contains a source prefix.  These are two
   very different concepts that should not be confused.

I appreciate having this note; thanks.  I wonder if it is worth
reiterating that the stock [BABEL] "source prefix" is the prefix of the
source of the routing information, to jog the reader's memory.

Section 5.1

   Prefix sub-TLV.  When a node receives a source-specific Update
   (prefix, source prefix, router-id, seqno, metric) from a neighbour
   neigh, it behaves as described in [BABEL] Section 3.5.4, except that

It looks like some section renumbering has occurred, as §3.5.3 of
draft-ietf-babel-rfc6126bis-20 looks much more relevant than §3.5.4
does.

   the entry under consideration is indexed by (prefix, source prefix,
   neigh) rather than just (prefix, neigh).

[The two prefix lengths are implicit now, though were explicit in
[BABEL]?]

Section 5.2

We should probably expand "AE" on first use.

Section 6.2

Is there also the possibility of a kind of starvation where
source-specific routers do not get source-specific routes because the
source-specific routes are dropped by non-source-specific routers
between them and the source of the route advertisement?  Intuitively, it
seems that once you have a connected backbone of source-specific routers
this would only happen if a given source-specific router only has paths
to the backbone that go through non-source-specific routers, and so the
router in question is effectively operating in a non-source-specific
mode, but perhaps there are more interesting scenarios in the absence of
such a backbone.

   A simple yet sufficient condition for avoiding starvation is to build
   a connected source-specific backbone that includes all of the edge
   routers, [...]

I'm not sure I understand what "connected backbone that includes all of
the edge routers" is intended to mean.  If the edge routers are to be
included in the connected backbone (i.e., to implement source-specific),
then wouldn't that make the connected backbone basically all routers?
Or is the intent that any given edge router has a link to a router in
the backbone?  Or something else?

Section 7.1

If I recall correctly, Babel sub-TLVs do not admit sub-sub-TLVs, so we
would treat a sub-TLV "length" that indicates more bytes of payload than
indicated by the "source plen" as an encoding error and reject the
sub-TLV, right?

   Source Plen  The length of the advertised source prefix.  This MUST
             NOT be 0.

Please use "length in bits" to match 6126bis.

Section 7.3

Should we consider being consistent about the use of parentheses around
"route" in the section heading and section body?

Section 7.4

Just to check my understanding: we do not expect issues where (e.g.) a
source-specific seqno request is sent to a non-source-specific node and
thus dropped, because seqno requests are supposed to be sent only to
nodes that are or in the past were advertising a (possibly non-feasible) route
for that prefix.  Such a source-specific advertisement would only be sent
by a source-specific node, that would accordingly not drop the seqno request.

Section 9

I was surprised to see in a quick check of 6126bis that there did not
seem to be a prominent mention in the security considerations of "make
sure your parser handles TLVs that indicate a length larger than the
size of the packet".  Should there be one?

Other than that (which is not really even a comment on this document), I
like the security considerations here: they're clear on the consequences
of the new behaviors from this protocol extension, and give enough
examples of how that might impact the security properties of the system
as a whole.  Thank you!

   The extension defined in this document adds a new sub-TLV to three
   TLVs already present in the original Babel protocol, and does not
   change the security properties of the protocol itself.  However, the

We might as well toss another [BABEL] in here; they're cheap.

Section 11.1

We cite BCP84 as part of the line "which is compatible with [BCP84]".
That in and of itself does not necessarily seem like enough to justify a
normative relationship, though perhaps there are other reasons why it is
needed.