From nobody Mon Apr 11 09:37:21 2022 Return-Path: X-Original-To: icnrg@ietfa.amsl.com Delivered-To: icnrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DA83A1207 for ; Mon, 11 Apr 2022 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=email-arizona-edu.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSchu-4_dCEE for ; Mon, 11 Apr 2022 09:37:14 -0700 (PDT) Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [IPv6:2001:4860:4864:20::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B243A120E for ; Mon, 11 Apr 2022 09:37:13 -0700 (PDT) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-dacc470e03so17828894fac.5 for ; Mon, 11 Apr 2022 09:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email-arizona-edu.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5FFgjlHlFk3uZe8IHNl4b18GYStvAGOWZ8GXnVhafLw=; b=3c9qPJWhDBCbF9GfkLiiYq7KXrX0b1DEyn94QnnvOlBtiWN+0xXNvIM8KXkb7NEmJI oz2gfb9F1G6n47ujsKgJ39F8OJLdZJEA9wx7cuDf/l0qYtgCek3CI57e77xt1ueaN0j9 xoyfJzs4cxCFPWBcBvrXQJToCn9eXrIdhzwkbld3DRaBhUZaZ1fKVkB1DFW1GbNMcM8W OoUzqG5vii5Z6uzD1Eht3Eu7D/gqUq/Oc/5T8UGCzGY44md1SUYsPNGWLL9EXCw0xkjb yeU0QibjjqnC0/5l6eahPosbg76+/N7prASRiERLT2rZdh32m0bcxzOiBXSjJlmg/cFA 6IvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5FFgjlHlFk3uZe8IHNl4b18GYStvAGOWZ8GXnVhafLw=; b=MQe4K3eNpJ8cJtg58IR3DGqsQHHZBz8KYRndTNKuLYywBKC/LhbZWC1mUAuLcUdNxb K2NAN0fOnexLNKjjrMvdSCh5AXt7DYSwE1+iHm8SxMYC4Z5Begn17iURCaIRm+DAPnzq 8w9fyvH8s59GkLLABIUa4XH51lbKyNhYPXEtYnivMAtQhlOAGUKWap0iX1ZeZMpcKk7d 0Q8qOci3yRbJcgZy8w4DJtXe9OgTKnWKtjd4ULayYdHpiJdFcGFKcGpZD6rudI7FtUoZ T+qQYkFuqDZwLICP6JmJPfj/5v9TPR0heVJKIDritNOVWX/XXKh5mjqu4YHSzE97/AS7 InuQ== X-Gm-Message-State: AOAM531guearhNtkkY95yKYl/CYMpwCvewoD9u6Z6MADhzkrYU1Z0uKl 5q6dudvKJN6eifor/hcNi6ClPdWSpOeNRMz0FQxeMPBb2Mzp42yIpsm71jSim+rzkiNGHFD8KR6 FwhlcuKkPCec= X-Google-Smtp-Source: ABdhPJz8/Bp0Ul2wiRAPGAGhVy9mtsvjS1c6st4rB0sIQ3fKgVReFCOSvcGn4nY/KWH20I4qw8DKXuC22ZM9NvUh4yo= X-Received: by 2002:a05:6870:41c6:b0:da:b3f:3260 with SMTP id z6-20020a05687041c600b000da0b3f3260mr6284oac.272.1649695032066; Mon, 11 Apr 2022 09:37:12 -0700 (PDT) MIME-Version: 1.0 References: <163519291458.16034.1879568644895811832@ietfa.amsl.com> <2D588ADD-F5F2-47F5-9C7C-A15113395CF9@unomaha.edu> <23D030F8-DDFD-437A-A289-3F23960021E0@unomaha.edu> <683DC592-2C9C-401B-91A7-46867EBFD773@dkutscher.net> In-Reply-To: <683DC592-2C9C-401B-91A7-46867EBFD773@dkutscher.net> From: Junxiao Shi Date: Mon, 11 Apr 2022 12:36:35 -0400 Message-ID: To: Dirk Kutscher Cc: Spyridon Mastorakis , icnrg@irtf.org, "David R. Oran" Content-Type: multipart/alternative; boundary="0000000000005fd6a005dc638ea2" X-ua-ms: gsuite Archived-At: Subject: Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icnping-03.txt X-BeenThere: icnrg@irtf.org 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, 11 Apr 2022 16:37:20 -0000 --0000000000005fd6a005dc638ea2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dirk Yes, I looked at the diff from -05 revision and I believe the errors have been corrected. Yours, Junxiao On Mon, Apr 11, 2022 at 6:23 AM Dirk Kutscher wrote: > Hi Junxiao, > > Thanks for paying attention and for the additional comments. > > Can you check whether your issues have been addressed? > > Thanks, > Dirk > > > On 8 Apr 2022, at 21:15, Spyridon Mastorakis wrote: > > Thanks for the comments, Junxiao. The drafts have been updated and your > comments have been addressed. > > Spyros > > =E2=80=94 > > Spyridon (Spyros) Mastorakis, Ph.D. > Assistant Professor > Computer Science Department > University of Nebraska at Omaha > Peter Kiewit Institute Room 174E > Associate Editor, IEEE Internet of Things Journal > Director, Ph.D. Program in Information Technology > Website: https://sites.google.com/site/spyridonmastorakis > > On Apr 5, 2022, at 6:39 AM, David R. Oran wrote: > > Non-NU Email > > Thanks! > We=E2=80=99ll 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 full= y > fixed. See comments inline. > > New problem: in references > > [NDNTLV] "NDN Packet Format Specification.", 2016, > < > https://urldefense.com/v3/__http://named-data.net/doc/ndn-tlv/__;!!PvXuog= Z4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLFGp= rkAL$ > > . > > The current spec link is: > > https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/cu= rrent/__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZ= dhj71JsWc0R-MLKV7kvFM$ > . It was last updated > in 2022. > You can also cite a specific version on > > https://urldefense.com/v3/__https://github.com/named-data/NDN-packet-spec= __;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71J= sWc0R-MLMaxcvab$ > using a commit hash. > > On Sun, Mar 6, 2022 at 6:52 PM Spyridon Mastorakis < > smastorakis@unomaha.edu> > 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 > < > https://urldefense.com/v3/__https://redmine.named-data.net/issues/4853__;= !!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9pi= KdxFWKR6IgjQ$> > , > the NDN packet encoding is written with IETF ABNF syntax. > However, ICN Ping still specifies its encoding with W3C EBNF syntax, whic= h > could lead to confusion. > > > Fixed. We converted the packet encoding to the ETF ABNF syntax. > > > RFC5234 < > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5234= __;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71J= sWc0R-MLHhiZDl2$ > > defines the IETF > ABNF syntax. NDN packet encoding follows this specification. > In this syntax, a rule is defined by the following sequence: > > name =3D elements crlf > > However, draft-irtf-icnrg-icnping-04 Section 5.2 is still defining a rule > with ::=3D 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= =3D0 > and FreshnessPeriod=3D0. > Since ContentType defaults to 0 and FreshnessPeriod defaults to 0, neithe= r > field is necessary. > > Importantly, the NDN protocol specifies > < > https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/cu= rrent/data.html*freshnessperiod__;Iw!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6= sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWGIoTdsr$ > > > : > > If the Data does not have a FreshnessPeriod or if it has a FreshnessPerio= d > equal to zero, it MUST be immediately marked =E2=80=9Cnon-fresh=E2=80=9D. > If an Interest contains MustBeFresh element, a node MUST NOT return > =E2=80=9Cnon-fresh=E2=80=9D 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 ND= N > packet format. > > > We aim to avoid fetching cached responses from the network (unless a > request=E2=80=99s base name matches the name of a content object in the C= S 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 differe= nt > than how NFD works right now. So we do not think this is an issue with th= e > 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 elemen= t > 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 appear= s > before the Name element. > The TLV evolvability guidelines of the NDN protocol does not permit addin= g > 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 thi= s > feature to drop the packet; this choice needs justification. > Moreover, 0x09 is marked as reserved > < > https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/cu= rrent/types.html__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKS= ybSpxaQ2vKKrLONq9piKdxFWM33PpJJ$> > 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 > < > https://urldefense.com/v3/__https://gerrit.named-data.net/admin/repos/NDN= -TLV__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKr= LONq9piKdxFWA18J1X7$> > to > reserve the number in NDN network layer protocol or edit this page > < > https://urldefense.com/v3/__https://redmine.named-data.net/projects/nfd/w= iki/NDNLPv2__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpx= aQ2vKKrLONq9piKdxFWIEfRn16$> > 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 protoco= l > 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 > < > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-oran-ic= nrg-pathsteering-05.html__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92Q= SiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLLgu6Y3D$ > > , > but that document only defines a "Path label TLV", and its encoding diffe= rs > from what's given in Figure 9. > > Yours, Junxiao > > > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > > https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__= ;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsW= c0R-MLBoVZn8p$ > > DaveO > > > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg > > *External Email* > --0000000000005fd6a005dc638ea2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dirk

Yes, I looked at the diff from = -05 revision and I believe the errors have been corrected.

Yours, Junxiao

On Mon, Apr 11, 2022 at 6:23 AM Dirk Kutscher= <ietf@dkutscher.net> wrote= :

Hi Junxiao,

Thanks for paying attention and for the additional comments= .

Can you check whether your issues have been addressed?

Thanks,
Dirk



On 8 Apr 2022, at 21:15, Spyridon Mastorakis wrote:=

Thanks for the comments, Junxiao. The drafts have been updated and your com= ments have been addressed.

Spyros

=E2=80=94

Spyridon (Spyros) Mastorakis, Ph.D.
Assistant Professor
Computer Science Department
University of Nebraska at Omaha
Peter Kiewit Institute Room 174E
Associate Editor, IEEE Internet of Things=C2=A0Journal
Director, Ph.D. Program in Information=C2=A0Technology
Website:=C2=A0https://sites.google.com/site/spyridonmastorakis

On Apr 5, 2022, at 6:39 AM, David R. Oran <daveoran@orandom.net> wrote:

Non-NU Email

Thanks!
We=E2=80=99ll 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<= br> fixed. See comments inline.

New problem: in references

[NDNTLV] =C2=A0=C2=A0"NDN Packet Format Specification.", 2016, <https://urldefense.com/v3/__http://na= med-data.net/doc/ndn-tlv/__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92= QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLFGprkAL$ > .

The current spec link is:
https://urldefense.com/v= 3/__https://named-data.net/doc/NDN-packet-spec/current/__;!!PvXuogZ4sRB2p-t= U!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLKV7kvFM$= =C2=A0. It was last updated
in 2022.
You can also cite a specific version on
https://urldefense.com/v3/__ht= tps://github.com/named-data/NDN-packet-spec__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAc= MkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLMaxcvab$ =C2=A0using= a commit hash.

On Sun, Mar 6, 2022 at 6:52 PM Spyridon Mastorakis <smastorakis@unomaha.edu> 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 <shijunxiao@email.arizona.edu> 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
<https://urldefense.com/v3/__h= ttps://redmine.named-data.net/issues/4853__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXY= UAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWKR6IgjQ$> ,
the NDN packet encoding is written with IETF ABNF syntax.
However, ICN Ping still specifies its encoding with W3C EBNF syntax, which<= br> could lead to confusion.


Fixed. We converted the packet encoding to the ETF ABNF syntax.


RFC5234 <https://urldefense= .com/v3/__https://datatracker.ietf.org/doc/html/rfc5234__;!!PvXuogZ4sRB2p-t= U!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLHhiZDl2$= > defines the IETF
ABNF syntax. NDN packet encoding follows this specification.
In this syntax, a rule is defined by the following sequence:

name =3D =C2=A0elements crlf

However, draft-irtf-icnrg-icnping-04 Section 5.2 is still defining a rule with ::=3D 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=3D= 0
and FreshnessPeriod=3D0.
Since ContentType defaults to 0 and FreshnessPeriod defaults to 0, neither<= br> field is necessary.

Importantly, the NDN protocol specifies
<https://urldefense.com/v3/__https://named-data.net/doc/NDN-packet-sp= ec/current/data.html*freshnessperiod__;Iw!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAz= HhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWGIoTdsr$>
:

If the Data does not have a FreshnessPeriod or if it has a FreshnessPeriod<= br> equal to zero, it MUST be immediately marked =E2=80=9Cnon-fresh=E2=80=9D. If an Interest contains MustBeFresh element, a node MUST NOT return
=E2=80=9Cnon-fresh=E2=80=9D 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<= br> packet format.


We aim to avoid fetching cached responses from the network (unless a
request=E2=80=99s 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<= br> 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<= br> 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<= br> 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<= br> 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-ho= p
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 t= hat
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<= br> feature to drop the packet; this choice needs justification.
Moreover, 0x09 is marked as reserved
<https://ur= ldefense.com/v3/__https://named-data.net/doc/NDN-packet-spec/current/types.= html__;!!PvXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKr= LONq9piKdxFWM33PpJJ$> 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
<https://urldefense.com= /v3/__https://gerrit.named-data.net/admin/repos/NDN-TLV__;!!PvXuogZ4sRB2p-t= U!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdxFWA18J1X7$= > to
reserve the number in NDN network layer protocol or edit this page
<https://urldefe= nse.com/v3/__https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2__;!!P= vXuogZ4sRB2p-tU!R1XTGYwBlOXYUAzHhlV6sAyjq-Qz47wI4GLKSybSpxaQ2vKKrLONq9piKdx= FWIEfRn16$> 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<= br> 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
<ht= tps://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-oran-icnrg-= pathsteering-05.html__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJkLusl_deBsZ2d92QSiVe= CmfC6bOzFHRjdZdhj71JsWc0R-MLLgu6Y3D$ > ,
but that document only defines a "Path label TLV", and its encodi= ng differs
from what's given in Figure 9.

Yours, Junxiao

_______________________________________________ icnrg mailing list
icnrg@irtf.org
https://urldefense.com/v3/__http= s://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Xz_WVwqvAcMkJk= Lusl_deBsZ2d92QSiVeCmfC6bOzFHRjdZdhj71JsWc0R-MLBoVZn8p$
DaveO

______________= _________________________________
icnrg mailing list
icnrg@irtf.org
https://www.irtf.org/mailman/listinfo/icnrg=

External Email

--0000000000005fd6a005dc638ea2--