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

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Feb 2014 15:41:06 -0600

Hi all,

I submitted this draft, appreciate your comments.

Regards,

Behcet

A new version of I-D, draft-sarikaya-6man-next-hop-ra-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-6man-next-hop-ra
Revision:       00
Title:          IPv6 RA Options for Next Hop Routes
Document date:  2014-02-10
Group:          Individual Submission
Pages:          15
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-6man-next-hop-ra-00.txt
Status:
https://datatracker.ietf.org/doc/draft-sarikaya-6man-next-hop-ra/
Htmlized:
http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-00

Abstract:
   This document proposes new Router Advertisement options for
   configuring next hop routes on the mobile or fixed nodes.  Using
   these options, an operator can easily configure nodes with multiple
   interfaces (or otherwise multi-homed) to enable them to select the
   routes to a destination.  Each option is defined together with
   definitions of host and router behaviors.  This document also
   proposes the router advertisement extensions for source address
   dependent routing.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dan Lüdtke <[email-masked]>
Date: Fri, 14 Feb 2014 18:35:47 +0100

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Feb 2014 16:18:50 -0600

Hi Dan,

Thanks for your comments.

My replies inline.
I have done the edits but not able to submit it, I will submit Rev 01 as
soon as the submissions open up.

Regards,

Behcet

> reasoning for the field's width in the preceding text?
Right. Changed to 8-bit field.

> thought about that it is just the text that is a bit misleading here.
As also defined in other documents, prefix length field indicates the
number of valid leading bits in the prefix. You can use 16 octets for the
prefix but the bits in the prefix after the prefix length must be set to
zero.

I hope it is clear.

> Normally, no. You want to use it as in Section  11, 12 or 13.

> OK

> We can consider combinations rather than Sections 8, 9 and 10.

> Done all of these.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Feb 2014 16:35:49 +1300

> decided whether it is me or the draft :)

It's probably the fact that the community is very divided as to whether
this, or a DHCPv6 based solution, is the right one for delivering
routing information to hosts. Personally I see advantages in defining
enough in RA that a DHCPv6-free network is possible, but it only
makes sense if we insist that routing information capable of delivery
by RA and that capable of delivery by DHCPv6 have *exactly* the same
semantics (even if the syntax of the messages is different).
...

> supporting the draft a lot.

Since an address is the same thing as a /128 prefix, I would
think that the address TLVs could be replaced by prefixes,
which would save at least a couple of option numbers. If that
isn't enough, it would have to go to subtypes.

    Brian