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

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 <adrian@olddog.co.uk> wrote:

> 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$
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WbRs1TMhGzlPNNHDie9q_XhFrEVt5srbU8_-5vh93TMWIzwrBNLCzd6bwvTFmVsW$>
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>