comments on draft-bonica-6man-comp-rtg-hdr (Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

[神明達哉 <[e-mail]>]

At Fri, 15 May 2020 15:13:55 -0700,
Bob Hinden <[e-mail]> wrote:

>  Title:          The IPv6 Compact Routing Header (CRH)
>  Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
>  File Name:      draft-bonica-6man-comp-rtg-hdr-21
>  Document date:  2020-05-14
>
>  https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
>
> as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.

I have no strong opinion on the adoption, while I didn't see any
particular reason not for adopting it in the sense of moving the
editorial ownership from individual authors to the wg: the topic seems
relevant to this wg; it's generally well written and seems to be ready
for further detailed discussion without wasting others' time for,
e.g., just to understand the draft text.  I don't know what else is
needed for adoption, but my understanding of the bar for adoption
isn't that high and this draft seems to clear it.

I've read draft-bonica-6man-comp-rtg-hdr-22 (not 21), mostly out of
curiosity.  I'm not an expert in this technology area or am not
particularly interested in it, but as email messages about the draft
and this adoption call consumed 99% of my inbox this week (most of
which seemed mere noise to me and I simply archived them without
reading) I was curious about what was happening.  Here are some
comments about that version from such a novice observer (please also
forgive me if I'm repeating points already made by someone - as I said
I've lazily ignored most of the messages regarding this call):

- General
  In general, I'd like to understand "why we need this" for any new
  protocol.  The motivation described in Section 1 is somewhat
  understandable, but if one major purpose is to realize source
  routing "within a network domain", it would be natural to ask why
  SRv6 isn't enough (I'd also refer to Section 3.2 of RFC1958).
  Perhaps there's a specific reason for the author not to discuss it
  within the draft (to avoid distraction?), but for someone without
  all background details that would be really useful.  For example, if
  CRH is intended to implement a 'source routing within a network
  domain' while being more compatible with the basic IPv6 protocol (like not
  relying on insertion or deletion of the CRH in intermediate nodes)
  that would make it look more persuading to someone like me, who is
  more concerned about the protocols affected by the new proposal than
  the new protocol itself.  But such points aren't discussed
  explicitly or can't be figured out (to me) from the protocol
  description.

- Section 1

   o  Is designed to operate within a network domain.  (See Section 9).

The term "a network domain" is vague to me.  Can't it be more
specific?

- Section 1

   o  Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely
      reliable, many IPv6 hosts refrain from sending packets larger than
      the IPv6 minimum link MTU (i.e., 1280 bytes).

Is this true?  I thought TCP (over IPv6) applications still largely
use larger packets (implicitly relying on PMTUD) while it's probably
pretty common for UDP applications to limit their packets to the
minimum MTU size.

- Section 5

   o  Submit the packet and optional parameters to the IPv6 module.

I can guess what "IPv6 module" means, but it would be more helpful if
it's defined explicitly earlier in the draft (maybe it could have a
"Terminology" section).

- Section 9

I suspect anyone remembering the type 0 RH fiasco will wonder whether
CRH is safe in that sense.  So I'd suggest discussing that more
explicitly with referring to RFC5095.

--
JINMEI, Tatuya