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

From: Tom Herbert <[email-masked]>
Date: Sat, 16 May 2020 08:31:20 -0700

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

---

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 18:35:58 +0000

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 <[email-masked]> On Behalf Of Tom Herbert
Sent: Saturday, May 16, 2020 11:31 AM
To: 6man <[email-masked]>
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
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WbRs1TMhGzlPNNHDie9q_XhFrEVt5srbU8_-5vh93TMWIzwrBNLCzd6bwvTFmVsW$
--------------------------------------------------------------------

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 16 May 2020 20:13:00 +0100

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 <[email-masked]> On Behalf Of Ron Bonica
Sent: 16 May 2020 19:36
To: Tom Herbert <[email-masked]>; 6man <[email-masked]>
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

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: Saturday, May 16, 2020 11:31 AM
To: 6man <[email-masked]>
Subject: Comments on draft-bonica-6man-comp-rtg-hdr-01

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
[email-masked]
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
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Sat, 16 May 2020 12:26:38 -0700

The subtle title change was also a bit confusing wrt search and the title
hasn't be updated everywhere in the draft. Got it now.

On Sat, May 16, 2020, 12:13 PM Adrian Farrel <[email-masked]> wrote:

> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WbRs1TMhGzlPNNHDie9q_XhFrEVt5srbU8_-5vh93TMWIzwrBNLCzd6bwvTFmVsW$>