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

[Juliusz Chroboczek <[e-mail]>]

Thanks for your comments.

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

Clarified in a slightly different way from what you suggest.

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

Done (two counts).

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

Fixed, thanks.

> Section 5.2

> We should probably expand "AE" on first use.

Done.

> Section 6.2

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

Hopefully clearer now.  It's now Section 6.1.

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

Added wording to that effect.

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

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

Done.

> Section 7.3

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

Fixed.

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

That's one case (forwarding a request).  The other case is when a router
originates a request, in which case it will send the request over
multicast, and so non-source-specific requests will be received by
non-specific routers, and silently ignored due to the mandatory sub-TLV.

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

Perhaps.  That ship has sailed, though.

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

This section has been completely rewritten, it is now Section 1.1.  I hope
it is clearer now.

Thanks again,

-- Juliusz