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

"David R. Oran" <> Tue, 05 April 2022 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 931473A2094 for <>; Tue, 5 Apr 2022 04:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x7k5R4joEhau for <>; Tue, 5 Apr 2022 04:40:02 -0700 (PDT)
Received: from ( [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6AE83A208D for <>; Tue, 5 Apr 2022 04:40:02 -0700 (PDT)
Received: from [] ([IPv6:2601:184:407f:80cf:e43c:9c33:d065:d00e]) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 235Bdo07012579 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Apr 2022 04:39:52 -0700
From: "David R. Oran" <>
To: Junxiao Shi <>
Cc: Spyridon Mastorakis <>,
Date: Tue, 05 Apr 2022 07:39:45 -0400
X-Mailer: MailMate (1.14r5882)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 05 Apr 2022 11:40:08 -0000

We’ll get these fixed quickly.

On 4 Apr 2022, at 11:57, Junxiao Shi wrote:

> 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 <>
> wrote:
>> *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

> _______________________________________________
> icnrg mailing list