Re: New Version Notification for draft-sarikaya-6man-next-hop-ra-00.txt

[Dan Lüdtke <[e-mail]>]

Hi,

I have very mixed feelings regarding this draft and I have not yet
decided whether it is me or the draft :)

I just throw my first thoughts in. I might get more verbose later or
next week. Just pick up what you think is helpful and maybe improve
the draft or help me understand why some of the options and fields the
way they are.

The Route Prefix option from section 7 has a field called Metric. It
is "only" 3 bit long. How was this value chosen? Why not something
that fits perfectly into a more standard type like uint8_t or
uint16_t? And why not the usual preference which is 2 bits wide and
allows to assign low/medium/high/reserved values? Did I miss the
reasoning for the field's width in the preceding text?

In section 10 the field "prefix" is said to be 16 octets or less in
length. Please make clear that the size MUST always be a multiple of
16 octets. Please do not specify a field containing a prefix that is
smaller than sizeof(struct in6_addr). We developers will eventually
fill the field using inet_pton() and the last thing we want to do is
to apply bit-magic and/or variable length voodoo. I am sure you have
thought about that it is just the text that is a bit misleading here.

All options, except the modified Route Prefix option, have a bad
alignment. Starting an IPv6 address or prefix at the 3rd octet of an
option is probably not the best idea. If possible use multiples of 4
or better 8 octets as starting point. Just one example: Section 13
Figure 7 could be re-aligned without wasting anything:


BAD:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |    Next Hop Address ...       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +                        ...                                    +
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ...           |        Source Address         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +                        ...                                    +
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ...           | Prefix Length |Resvd|Prf|Metric|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Route Lifetime                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Prefix (Variable Length)                    |
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GOOD:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |Resvd|Prf|Metr.|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Route Lifetime                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +                                                               +
      +                        Next Hop Address                       +
      +                                                               +
      +                                                               +
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +                                                               +
      +                        Source Address                         +
      +                                                               +
      +                                                               +
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Prefix (Variable Length)                    |
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Despite these formal objections I am still in the process of
understanding how the proposed solution would work in the field. The
Next Hop Address option for example can be used alone. Is this right?
And if so, why would I want this? And to what prefixes does the option
apply? How is this different from a default gateway?

In Section 14 you use MUST. This will probably lead to discussion. I
don't think a MUST is required there. SHOULD or MAY is enough, since
these are only considerations. MUST is always something an implementer
gets a headache from :)

I also have the feeling that consuming 7 numbers from the registry for
new options is a bit too greedy. Do you see any way to reduce the
consumption of this very limited resource? I think it would help
supporting the draft a lot.


The usual nitpicking:
Section 4: "eroor" -> "error"
Section 5: "document.The" -> document.[WHITESPACE]The"
Section 7: Figure 1: Metric is too long. It breaks the figure. Maybe
call it "Mtr." in the figure.
Section 7: Field Definition: There is a colon (:) missing after the
first "Metric". Same in Section 11 Figure 5, Section 12 Figure 6 and
Section 13 Figure 7.
Section 8: Figure 2: It is unclear how long the last field is. This is
_very_ confusing for everybody implementing the draft.
Section 9: Figure 3: It is unclear how long the last field is. Same as above.


Hope that helps and have a nice weekend!

Dan

-- 
Dan Luedtke
http://www.danrl.de