Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icnping-03.txt

Junxiao Shi <> Mon, 13 December 2021 15:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E457A3A03F8 for <>; Mon, 13 Dec 2021 07:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvSZk-6XRyJY for <>; Mon, 13 Dec 2021 07:01:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA1B33A0163 for <>; Mon, 13 Dec 2021 07:01:05 -0800 (PST)
Received: by with SMTP id b1-20020a4a8101000000b002c659ab1342so4239920oog.1 for <>; Mon, 13 Dec 2021 07:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aRuw+b3oDdtrDVyYwnLxQ/2fSZ1N51BsQi7rkwT4Ucw=; b=sJuADpWUDHrUrFMerQlSDWw6n2zLwAcH/n8eSunPbmsXDC5yriwA9rubAKtpvPAYVt UZpnUB5ww2ZMyj0LMwQv1nt3OSK4Ocs/CcRggjHJ0lnGEyjXl1Fz0aOyxyJDCtn5UUVx HhXNnUfMzozvDv1LGIOsKBOqnxVv1onVgzAYvV2mFVpeeMSoynX7zHwHI6BO6i3PAgc2 rK2/eOEDb8yM72JrQiMzlEflh38100pu4g7WJ8ukLo3BYWK1Uv01Y+HOobtdfjUp0pFl KiDSJWxIiWBROptnhJt5lMLDaBW9ToaH4+IT3EWkf+z9yNCdzM0dmiSnNipHpzWPx8ph kt1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aRuw+b3oDdtrDVyYwnLxQ/2fSZ1N51BsQi7rkwT4Ucw=; b=k5HDjyRkADqFStB1H05o4efxFXDEAm6EijgZVpdQ+jE3z8S70pV4an2XHQTcoVdCGM Reka+MA2vnORLumWwqN67WVX5FxfiAwfKotJfexvUlqMghH0NKVxZVCX8Dh6wW+UkuNm 9EDfgSxIeThEG97dd35N8SkJJaWBGjSvGcSno+2wrP+q9VUB/slYXTFzNDrG4BG7aOwq MO6H/STSDOmzSYc3gZ9Rm9gfGG+5lzFds7/T/YHo+c9Ris96DEY7uUi2Pa4k9Emf2Uj9 a/08B2xN5iPkHxs536ise3CdcFOwnlk981XCW5QU2mBab8Kweltil+/wQig/iAuTNILk zBuA==
X-Gm-Message-State: AOAM532WdPWrkKmB9yJcdCQKUiKslMoBvI9oAlP7R/q/7UUs8+dLEi1M F+lPw7xTJmOxk4k0Eacxs/3Z3TzmdkafrHfRLBMmrx4zU5xhIKgj0UYNr+d8fzI6KpcOKaH72f+ exsIqBeb7Qg0rhAwKxv0=
X-Google-Smtp-Source: ABdhPJwYl5eXFWYy9QigsPOFeHiS+PrjQKnIDm6LDPPLvSqmjTmYyNORRD1wg9Iy29ZMq6X8qoFxhk5bOpR2mGrXgo8=
X-Received: by 2002:a4a:300f:: with SMTP id q15mr20108687oof.36.1639407659368; Mon, 13 Dec 2021 07:00:59 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Junxiao Shi <>
Date: Mon, 13 Dec 2021 10:00:23 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000002e4e2b05d3085790"
X-ua-ms: gsuite
Archived-At: <>
Subject: Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icnping-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Dec 2021 15:01:11 -0000

Dear folks

I had a look at the NDN encoding for ICN Ping Protocol rev03.
It seems that the protocol partially assumes NDN packet format v0.2, and is
incompatible with the current NDN packet format.

As of 2019-May <>, the NDN packet
encoding is written with IETF ABNF syntax.
However, ICN Ping still specifies its encoding with W3C EBNF syntax, which
could lead to confusion.

Section 5.1 defines that the Name of a Ping Echo Request should have a
"ping" suffix, so that it can be identified as a Ping Echo Request.
Since NDN packet format v0.3, name components that require special
processing should use a KeywordNameComponent (TLV-TYPE 0x20) rather than a
This helps to avoid conflicts with existing protocols, such as the ndnping

Section 5.1 defines Ping Echo Request to be an Interest with MustBeFresh
NDN packet format has eliminated the concept of selectors.
It's called "MustBeFresh element" now.

Section 5.1 mentions a "Parameters" element.
It's been renamed to "ApplicationParameters".
Also, the inclusion of an ApplicationParameters requires the inclusion of a
ParametersSha256DigestComponent somewhere in the Name (it does not have to
be the last component).
It's necessary to specify where this component should be placed.

The Parameters element is meant to contain PathSteering TLV.
As suggested below, it may make sense to move it to the NDNLPv2 header.

Section 5.2 defines Ping Echo Reply to be a Data packet with ContentType=0
and FreshnessPeriod=0.
Since ContentType defaults to 0 and FreshnessPeriod defaults to 0, neither
field is necessary.

Importantly, the NDN protocol specifies

If the Data does not have a FreshnessPeriod or if it has a FreshnessPeriod
equal to zero, it MUST be immediately marked “non-fresh”.
If an Interest contains MustBeFresh element, a node MUST NOT return
“non-fresh” Data in response to this Interest.

This rule applies to not only the Content Store, but also the forwarding
Based on this rule, the Ping Echo Reply packet does not satisfy the Ping
Echo Request packet, making the ICN Ping incompatible with the current NDN
packet format.

Section 5.2 inserts a "PathSteering TLV" in the Data packet, which appears
before the Name element.
The TLV evolvability guidelines of the NDN protocol does not permit adding
new elements before the Name element.
New elements should be added later in the packet; to exclude an element
from the security envelope, it should appear after the SignatureValue
In the case of PathSteering TLV that "might be modified in a hop-by-hop
fashion", it does not belong in the network layer, but should be added as a
link layer header in NDNLPv2 or another link layer protocol.

The "PathSteering TLV" cites draft-oran-icnrg-pathsteering, but that
document only defines a "Path label TLV".
Its TLV-TYPE number assignment is 0x09, but that number is a "critical"
TLV-TYPE number that would cause a forwarder that does not understand this
feature to drop the packet; this choice needs justification.
Moreover, 0x09 is marked as reserved
<> because it
conflicts with the former Selectors element in NDN packet format v0.2, so
that you may need to choose a different number.
You can then propose a change
<> to reserve the number
in NDN network layer protocol or edit this page
<> to reserve the
number in NDNLPv2.

Yours, Junxiao

On Mon, Oct 25, 2021 at 4:17 PM <> wrote:

> External Email
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Information-Centric Networking RG of the
>         Title           : ICN Ping Protocol Specification
>         Authors         : Spyridon Mastorakis
>                           Jim Gibson
>                           Ilya Moiseenko
>                           Ralph Droms
>                           Dave Oran
>         Filename        : draft-irtf-icnrg-icnping-03.txt
>         Pages           : 20
>         Date            : 2021-10-25
> Abstract:
>    This document presents the design of an ICN Ping protocol.  It
>    includes the operations of both the client and the forwarder.
> The IETF datatracker status page for this draft is:
> There is also an HTML version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> icnrg mailing list