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

Junxiao Shi <> Mon, 04 April 2022 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C9A83A07DF for <>; Mon, 4 Apr 2022 08:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 MIpdikqrql3G for <>; Mon, 4 Apr 2022 08:58:06 -0700 (PDT)
Received: from ( [IPv6:2001:4860:4864:20::2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B4B33A092D for <>; Mon, 4 Apr 2022 08:58:05 -0700 (PDT)
Received: by with SMTP id 586e51a60fabf-dacc470e03so11169516fac.5 for <>; Mon, 04 Apr 2022 08:58:05 -0700 (PDT)
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 :cc; bh=Y2zs7YNcEd1SX+n18Db34cBbA1HfT3BA3SjtIruNzFw=; b=p9RBKN4a2yiozkdujCrmiWYsdZzUipbm6VBH55gjLh9YcK4+893NF/1vBHA0ksx64z ZUPlKFCYDNLDXqc3x9zymfoV24sYYPN3vXf/aqj7qaS7Vc7UpgYn+5x1BJwmp3FMpJR2 6fG5gPNKSqVIMoYjtbOspmWoeNo2bo5D2Mdpcmn3OermVfT9dAZ24ruMkOE0Yd4Zp5c4 0+LoRlsxfA/hlFGY5GtzHJXk+W8h+/0N0qunRyzabf+lXSkCzPHz7lpV8pqnFbTFzlXQ WpqF0+aY45pWbArNe8NULGeRD+mVIAWm/ohaoND/Hf0scvao4GHwiEmTIZgAoh3d3NSK vp3g==
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:cc; bh=Y2zs7YNcEd1SX+n18Db34cBbA1HfT3BA3SjtIruNzFw=; b=QQbMOrlOmUnnwsjOCYbtQethipG9zFJ0LcYCyopPIfacSyE6SMUiofXDFUzgfmTdwk YWWvmbpxwbuHgE0NoMeJzpOVX6bbdUlnJc2DFL8U8ZJK5dCafeW1B3jbKlAA1/d4pXn7 /FXKHMPJojIklSqEuN+IvhMNbzPekzIKJasa+v0BZSdWP9TeZGvgzdIlbWjWgUnEdbeB /s2m+tGVBirbPDMD9PytCjYUmjCrsEp7dXi79nPzXWxNiYsxNQuTd+UqpGWZpW698RAa 6ySzSr/peKYJkCZsHzkB1iyslJx7ADKLjatPJ4DL1rUoBnazkDcqzo+nOarafUlgfJZs 6PgA==
X-Gm-Message-State: AOAM532g3ikJCTlQt4UWiBwZRjKqByTAKdtms/5K+c/YvWvnwx0MUOOw hmT+b5CFw1e7kdIrGR3efN1LLZl4C5QKZMtyKLfunBJdjKj6NYTko/Dx3XqHl4QJPcMWOnPn3Dt HT1bqy7WS91+hVFnECIVCEQ==
X-Google-Smtp-Source: ABdhPJxdNbl1dcklcCTyEwJTyROPMd1cAu0f/v4w8E6523TMzRC0SamIj8RFk11gGc5PStW4DFxLqgDC4Buyt3vF3j4=
X-Received: by 2002:a05:6870:4792:b0:da:b3f:2b39 with SMTP id c18-20020a056870479200b000da0b3f2b39mr11161363oaq.216.1649087884566; Mon, 04 Apr 2022 08:58:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Junxiao Shi <>
Date: Mon, 04 Apr 2022 11:57:28 -0400
Message-ID: <>
To: Spyridon Mastorakis <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000009034f505dbd63164"
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, 04 Apr 2022 15:58:11 -0000

Hi Spyros

I have inspected the diff between -03 and -4. Certain errors are not fully
fixed. See comments inline.

New problem: in references

[NDNTLV]   "NDN Packet Format Specification.", 2016,

The current spec link is: . It was last updated
in 2022.
You can also cite a specific version on using a commit hash.

On Sun, Mar 6, 2022 at 6:52 PM Spyridon Mastorakis <>

> *External Email*
> Dear Junxiao,
> Thank you for your comments. We have addressed them in the updated
> versions of our drafts that we just uploaded. Please see below for more
> details:
> On Dec 13, 2021, at 9:00 AM, Junxiao Shi <>
> wrote:
> Non-NU Email
> ------------------------------
> 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
> <;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWKR6IgjQ$>,
> 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.
> Fixed. We converted the packet encoding to the ETF ABNF syntax.

RFC5234 <> defines the IETF
ABNF syntax. NDN packet encoding follows this specification.
In this syntax, a rule is defined by the following sequence:

name =  elements crlf

However, draft-irtf-icnrg-icnping-04 Section 5.2 is still defining a rule
with ::= operator.

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
> <*freshnessperiod__;Iw!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWGIoTdsr$>
> :
> 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
> pipelines.
> 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.
> We aim to avoid fetching cached responses from the network (unless a
> request’s base name matches the name of a content object in the CS of a
> forwarder and the client is ok with receiving a cached response). To do
> that in the first place, the operation of a forwarder needs to be different
> than how NFD works right now. So we do not think this is an issue with the
> packet format per se, but rather the operation of the forwarder, which
> needs to be extended/modified to handle ping and traceroute traffic.

draft-irtf-icnrg-icnping-04 Section 5.1 says:

Since the NDN packet format does not provide a mechanism to prevent the
network from caching specific data packets, we use the MustBeFresh element
for echo requests (in combination with a Freshness Period TLV of value 0
for echo replies) to avoid fetching cached echo replies with an expired
freshness period.

This still will not work, because an Interest with MustBeFresh cannot be
satisfied by a non-fresh Data.
This is enforced not only in NDN forwarders, but also in NDN libraries.

To minimize caching effect, you can either set FreshnessPeriod to 1 (not
0), or use a unique name each time (you are already doing this by adding a
random nonce component), or both.

> 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
> element.
> Good point. We have moved the PathSteering TLV after the Signature TLV.
> 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
> <;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWM33PpJJ$> 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
> <;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWA18J1X7$> to
> reserve the number in NDN network layer protocol or edit this page
> <;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWIEfRn16$> to
> reserve the number in NDNLPv2.
> To some extent, this sounds like an open question to us (i.e., whether
> PathSteering TLV should be a part of the encoding of the base NDN protocol
> or should be included in NDNLPv2). Nevertheless, we believe that since a
> field like HopCount (whose value changes on a hop-by-hop basis) is in the
> base NDN protocol rather than NDNLP, path steering should also be in the
> base protocol, since it too is a hop-by-hop field independent of a
> particular single hop.

The "PathSteering TLV" cites draft-oran-icnrg-pathsteering
but that document only defines a "Path label TLV", and its encoding differs
from what's given in Figure 9.

Yours, Junxiao