From nobody Mon Dec 13 07:40:49 2021 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 AF3B13A0830 for ; Mon, 13 Dec 2021 07:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cLaC_Z-PI3Dz for ; Mon, 13 Dec 2021 07:40:35 -0800 (PST) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F5B3A083C for ; Mon, 13 Dec 2021 07:40:34 -0800 (PST) Received: from [192.168.15.242] ([IPv6:2601:184:407f:80cf:8166:57e8:3301:83b6]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 1BDFeMLb023575 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Dec 2021 07:40:24 -0800 From: "David R. Oran" To: Junxiao Shi Cc: icnrg@irtf.org, Spyros Mastorakis Date: Mon, 13 Dec 2021 10:40:16 -0500 X-Mailer: MailMate (1.14r5853) Message-ID: <779D44B7-B6E3-4248-836A-41546065ADE5@orandom.net> In-Reply-To: References: <163519291458.16034.1879568644895811832@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_DC9ECC4D-778D-45A6-8923-B5C061B10512_=" Embedded-HTML: [{"plain":[412, 5386], "uuid":"08137D9D-86EC-468B-B3DB-5FEAFF2D0A14"}] 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, 13 Dec 2021 15:40:47 -0000 --=_MailMate_DC9ECC4D-778D-45A6-8923-B5C061B10512_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hey, thanks for the quick and thorough review! We=E2=80=99ll likely need = corresponding changes in the traceroute draft as well. If may be useful, if we have time over the holidays, to issue an interim = revised draft with the changes you note, so we don=E2=80=99t have to wait= = until the last call closes to work these out. I=E2=80=99ll talk to the co-authors and see. Thanks again! On 13 Dec 2021, at 10:00, Junxiao Shi wrote: > 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 > GenericNameComponent. > This helps to avoid conflicts with existing protocols, such as the = > ndnping > application > > . > > Section 5.1 defines Ping Echo Request to be an Interest with = > MustBeFresh > "selector". > 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=3D0 > and FreshnessPeriod=3D0. > 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 =E2=80=9Cnon-fresh=E2=80=9D= =2E > 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 > 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 > element. > 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 >> IRTF. >> >> 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: >> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnping/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-irtf-icnrg-icnping-03.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-icnrg-icnping-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> icnrg mailing list >> icnrg@irtf.org >> https://www.irtf.org/mailman/listinfo/icnrg >> >> > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg DaveO --=_MailMate_DC9ECC4D-778D-45A6-8923-B5C061B10512_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hey, thanks for the quick and thorough review! We=E2= =80=99ll likely need corresponding changes in the traceroute draft as wel= l.

If may be useful, if we have time over the holidays, to i= ssue an interim revised draft with the changes you note, so we don=E2=80=99= t have to wait until the last call closes to work these out.

I=E2=80=99ll talk to the co-authors and see.

Thanks again!

On 13 Dec 2021, at 10:00, Junxiao Shi wrote:

Dear folks

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

As of 2019-Ma= y, 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 p= rocessing should use a KeywordNameComponent (TLV-TYPE 0x20) rather than a= GenericNameComponent.
This helps to avoid conflicts with existing protocols, such as the <= a href=3D"https://github.com/named-data/ndn-tools/tree/585e18a5e3be4d2d33= 053dbad2223e5d986d65fa/tools/ping#ndnping-protocol">ndnping application.

Section 5.1 defines Ping Echo Request to be an Interest with MustBeF= resh "selector".
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 inclusi= on of a ParametersSha256DigestComponent somewhere in the Name (it does no= t 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 head= er.

Section 5.2 defines Ping Echo Reply to be a Data packet with Content= Type=3D0 and FreshnessPeriod=3D0.
Since ContentType defaults to 0 and FreshnessPeriod defaults to 0, n= either field is necessary.

Importantly, the NDN protocol specifies:
If the Data does not have a FreshnessPeriod or if it has a Freshness= Period 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 forwar= ding 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 curre= nt NDN packet format.

Section 5.2 inserts a "PathSteering TLV" in the Data packet, which a= ppears 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 elem= ent from the security envelope, it should appear after the SignatureValue= element.
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 adde= d as a link layer header in NDNLPv2 or another link layer protocol.

The "PathSteering TLV" cites=C2=A0draft-oran-icnrg-pathsteering, but= that document only defines a "Path label TLV".
Its TLV-TYPE number assignment is 0x09, but that number is a "critic= al" 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=C2=A0because 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=C2=A0to reserve the number in NDN network lay= er protocol or edit this page=C2=A0to reserve the number in NDNLPv2.
<= /div>

Yours, Junxiao

On Mon, Oct 25, 2021 at 4:17 PM <internet-drafts@ietf.org> wrote:
=
External Email

A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.
This draft is a work item of the Information-Centric Networking RG of the= IRTF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : ICN Ping Protocol Specification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Sp= yridon Mastorakis
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jim Gibson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ilya Moiseenko
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ralph Droms
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dave Oran
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-i= rtf-icnrg-icnping-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2021-10-25

Abstract:
=C2=A0 =C2=A0This document presents the design of an ICN Ping protocol.=C2= =A0 It
=C2=A0 =C2=A0includes the operations of both the client and the forwarder= =2E


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft= -irtf-icnrg-icnping/

There is also an HTML version available at:
https://www.ietf.org/archive/id/= draft-irtf-icnrg-icnping-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-irtf-icnrg-icnping-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
icnrg mailing list
icnrg@irtf.org https://www.irtf.org/mailman/listinfo/icnrg

___________________________________= ____________
icnrg mailing list
icnrg@irtf.org
https://www.irtf.org/mailman/listinfo/icnrg

DaveO

--=_MailMate_DC9ECC4D-778D-45A6-8923-B5C061B10512_=--