RE: Comments on draft-bonica-6man-comp-rtg-hdr-01

I do have to agree with those who have said that the arrival rate of new
revisions of this draft has been at the high end of normal.

Apparently, even the document editor is struggling to keep up! It looks like
version -22 is the top of stack.

I think this document is suitable for adoption by 6man. It is in scope of
the charter, is interesting, and has potential uses. Once adopted, I look
forward to the WG having editorial control.

If adopted, I promise to review and help revise the work.

In the meantime, I do have a couple of brief comments. None of these needs
to be fixed before adoption, however, the codepoint issue (sections 3 and
11) might be wise to fix before adoption.

Best,
Adrian

===

Abstract
I think this is a bit too brief. It would be nice to add a second paragraph
saying what the CRHs are and what they do.

---

Throughout
Please decide "Routing header" or "Routing Header"

---

Document title
I think this should be "The IPv6 Compact Routing Headers (CRH)" to be
consistent with the Abstract.

---

Section 3
You introduce the term "SID" and go on to explain it concisely. No problem
with what you've written, but...
Is this SID the same SID as we find in RFC 8402? If it is, then a citation
would be nice. 
If it is a subset or reduced form of the SID in 8402, that really needs to
be clarified.
If it is a different thing (no matter if it is "similar") maybe using a
different name would be helpful.

---

Section 11 and Section 3
Please remove explicit codepoint values from these sections. It is OK to
recommend/suggest values, but this seems unnecessary as you are not asking
for anything unusual. Normal practice is to allow IANA to assign codepoints
and avoid any risk of accidental clashes between assignments.

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ron Bonica
Sent: 16 May 2020 19:36
To: Tom Herbert <tom@quantonium.net>; 6man <ipv6@ietf.org>
Subject: RE: Comments on draft-bonica-6man-comp-rtg-hdr-01

Tom,

I'm afraid you are looking at a very old version of the draft. These fields
are all gone in the current version (21).

                                                                  Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Tom Herbert
Sent: Saturday, May 16, 2020 11:31 AM
To: 6man <ipv6@ietf.org>
Subject: Comments on draft-bonica-6man-comp-rtg-hdr-01

[External Email. Be cautious of content]

A few comments...

The CRH header has three reserved bytes after the Com field presumably for
aligning the SIDs. Three bytes would be needed if SIDs are thirty-two bits,
but for sixteen bit SIDs only one byte of padding is needed, and in the case
of eight bit SIDs no padding is needed. Since the routing header needs to be
eight bytes in length, the minimizing padding for alignment can save a fair
number of bytes. For instance, if there is just one 16 bit SID in the list
or one to three 8 bit SIDs, without minimal padding for alignment the EH is
sixteen bytes in size, with minimal padding it's just eight bytes.

I suggest considering switching the Com and Segments field since Segments is
a numeric quantity field and there's some reasons to put that in the lower
order bits. Masking a byte to get a numeric value is easier to conceptualize
than a shift (albeit probably same performance), and also if we ever decide
that the Com field needs to be extended four bits that's as easy as just
reducing the halving the maximum value of segments field.

I suggest the value 0x3 in the Com field be reserved for an "extended
header" format. For instance, if someday we find we really need flags in the
header then an extended format could be defined that includes a set of
flags, SID size, and SID list. This probably doesn't need to be mentioned in
the draft, but maybe the Com field should be renamed to Fmt to indicate it
describes the format of the header following the field.

>From the draft "Therefore, the CRH MAY be padded with zeros." and
"Reserved - SHOULD be set to zero by the sender.". Should both of these be a
MUST?

Tom

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!N
Et6yMaO-gk!WbRs1TMhGzlPNNHDie9q_XhFrEVt5srbU8_-5vh93TMWIzwrBNLCzd6bwvTFmVsW$
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------