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

神明達哉 <> Fri, 29 May 2020 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAF323A0F74 for <>; Fri, 29 May 2020 11:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YOUxljRB47dn for <>; Fri, 29 May 2020 11:27:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D165E3A0F69 for <>; Fri, 29 May 2020 11:27:51 -0700 (PDT)
Received: by with SMTP id l10so4859741wrr.10 for <>; Fri, 29 May 2020 11:27:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sOQ8zViGKL3kb8PAUUuVxIZ8VOSjhC/SS9qSlvjP7sc=; b=tf1v7IykyLy2IRDYevWxZ8f0SN/4aI7pbJOOvpyWkCqUpxXpjEm4sE/rr4gTkhinI/ T+Ffn0JzVTP5IKAtinuap+SFNb72Supd2nBHJmDKlk3O7XJ6Eyp8WtVltLEF3IQsx6Kf UeSQ2NBJh/VmoQ/2H5oYliaft3z11M/n5NgBlN8NtuajTp2+oZWa69VE/L53ymnkYc4r lTba/1+Tsotzc4T9dkiowhXW+kz19TawjfcacLqsy3b4Nrt5w9MTSfvSRC44WAJrI9nE r/2sQzVA0oIQrVeojxMYbUAVClfTEPHNhFMSjio8PW0b/0pwMezAYEZ9W3aypjJOliwg /M4Q==
X-Gm-Message-State: AOAM533/Y9DLQY/mN2h1chFpJOLDd66YseNizVZAxyvx5gkZAhWxXztk 8vyfiFBlFct1n8Vk+NZAkpNmHQbP6a9RG1v84Z4=
X-Google-Smtp-Source: ABdhPJzm2JDPPHfvHX4Z2tJkHjpOaGF5eB1eGHM4KYmvyE2+odGTOX4kGIDvk3rTDNKmHAzWn8CvtpvEYwW7O9J7zDk=
X-Received: by 2002:a5d:5605:: with SMTP id l5mr9582341wrv.318.1590776870150; Fri, 29 May 2020 11:27:50 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 29 May 2020 11:27:37 -0700
Message-ID: <>
Subject: comments on draft-bonica-6man-comp-rtg-hdr (Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")
To: Bob Hinden <>
Cc: IPv6 List <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 May 2020 18:27:55 -0000

At Fri, 15 May 2020 15:13:55 -0700,
Bob Hinden <> 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
> 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

- 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

- 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