Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Dear Alvaro,

This mail deals with your Discuss points (B) and (C).  I haven't decided
what to do about (A) yet.

> (B) Error Handling

> Many sections of the document describe functionality, or even Normatively
> mandate it, but there is no discussion about Error Handling.

In most cases, no explicit check is necessary, or even possible.  In other
cases, the TLV is ignored, which is the general approach taken in Babel
with unparseable TLVs.  I've added explicit error handling in cases where
I find it suitable.

> (B1) Router-Id Setting

> §4.5:
>    o  the current router-id; this is undefined at the start of the
>       packet, and is updated by each Router-ID TLV (Section 4.6.7) and
>       by each Update TLV with Router-Id flag set.

> It took me some time to figure out the reason for being able to carry the
> router-id in two different places inside the same packet,

[...]

> Did I understand correctly?  ...it is all simply implied.

You appear to have missed Section 3.5.3 "Encoding of updates", which
probably indicates that it was at the wrong sport.  I have now expanded
this section, merged it into Section 4.5 "Parser state", and added
backward references at suitable points.

> What should happen if no Router-Id has been defined?

Clarified requirement to ignore the Update TLV.

> (B2) Default Prefix

As above.

> (B3) Next Hop

As above.

> (B4) For the Normative behavior listed here (I may have missed other
> instances), I have basically the same question: what should a receiver
> do if it is not the case?

Most of these require no check on the receiver side, in may cases
a receiver-side check is impossible.

> - §3.8.1.2: "A node MUST NOT increase its sequence number by more than 1 in
> response to a seqno request."

This is a requirement for the sender.  When the receiver notices that the
seqno has increased, it cannot possibly know how many requests the sender
has reaceived in the meantime.

> - §4: "A Babel packet MUST be sent as the body of a UDP datagram, with
> network-layer hop count set to 1..."

This is a requirement for the sender.  No receiver side check is required
or even possible.

> - §4.6.9: "If the metric is finite, AE MUST NOT be 0.  If the metric is
> infinite and AE is 0, Plen and Omitted MUST both be 0."

Added requirement to drop the Update TLV if violated.

> - §4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of
> length 0)."

No clarification is necessary here, just like no clarification is
necessary that for an IPv4 address, plen <= 32.

> - §4.6.10/§4.6.11: Is AE 3 a valid value in a request?  I assume it isn't. 
> What should a receiver do if AE = 3.

This case is allowed -- there's nothing in the protocol that disallows
announcing routes within fe80::/64.  Of course, it would be silly to do so.

> (C) Mandatory Bit

> §4.4: "The most-significant bit of the sub-TLV, called the mandatory bit..." 
> The most significant bit of which part of the sub-TLV?  As written, that bit
> would be the first one in the Type, which corresponds to the text in the IANA
> section.  Please be specific.

This was a typo, noticed by Éric Vyncke.  The most-significant bit of the
sub-TLV *Type*.

The sub-TLV value consists of the whole 8 bits.  TLV numbers 0 through 127
are non-mandatory, 128 through 255 are mandatory.

> In the IANA considerations section, please include the whole registry in the
> table to avoid confusion.

I'm confused.  Wouldn't that force me to do a number of downrefs?

> Note that because of the mandatory bit, the 128-239 range should be
> Reserved...but it is currently marked as Unassigned.

No, this range is unassigned.  Mandatory but unassigned.

> Even worse, value 128 is assigned already [draft-ietf-babel-source-specific].

That is correct.  The source prefix is a mandatory TLV.  Value 128 has
nothing to do with Pad1, which has value 0.

-- Juliusz