Re: [dtn] Neighbor Discovery (draft-johnson-dtnwg-ipnd-00)

[[e-mail]]

Hi Marc,

On Sat, 7 Oct 2023, Marc Blanchet wrote:

>
>       Le 7 oct. 2023 à 04:28, [e-mail] a écrit :
> 
> Hi All,
> 
> I have spent a bit of time of recent working on improving the IONe
> implementation of ipnd, adding support for IPv6 beacons and IPv6 CLA
> advertisements.
> 
> As such, and persuant to the 'Neighbor Discovery' charter item, I have
> submitted the following draft, which is an updated resubmission of an
> expired IRTF draft on this matter:
> 
> https://datatracker.ietf.org/doc/draft-johnson-dtnwg-ipnd/
> 
> 
> Great to see this(We’ve been looking for this work while I was dtn
> co-chair!). 
> 
> Comments:
> 
> Meta:
> - if you use draft-*-wgname-* structure for your draft file name, then, if
> the third token is exactly the working group name, then it would appear in
> the wg documents page (https://datatracker.ietf.org/wg/dtn/documents/),
> which is really useful for everybody to find the related work of a dtn wg.
> Right now it does not appear as you are using “dtnwg” instead of “dtn”.  
> (My guess is that you changed dtnrg  to dtnwg from the older draft but dtnrg
> was actually the dtn research group token, while this group is “dtn").
> - you seem to reuse the dtnrg source, which put “Experimental as its
> intended status and from the “DTN Research Group”. Both should be changed. I
> think we should target “Proposed Standard”/Standard track. 

Thanks for the pointers.  Yes, I lightly edited the existing expired 
draft, having found the xml for it in the archives.  As to proposed 
standard, I will let the wg decide the merits, maybe, and update 
appropriately?

I note your vote for Proposed Standard :)  I think it will 
do the job as well, personally.  In doing so, are you suggesting that we 
make this a wg document at this time?  I have a couple of other edits as 
well, like updating the original author's employer and email address info.

> 
> Abstract:
> s/Disruption Tolerant Networking (DTN)/Delay and Disruption Tolerant
> Networking(DTN)/
>

Good eye, thanks.


> Section 2.6:
> 
> g/iff/s/iff set/if set/
> 
> Substantive:
> - there is already IPv6 Neighbour Discovery and service discovery protocols
> (DNSSD) that exist on the IP protocol stack. This draft uses UDP/IP, which
> means it requires an underlying IP network/links with IP nodes configured.
> It either uses unicast IP (which means the node should know the IP address
> of the other peers) or multicast IP, which IPv6 ND and DNSSD use
> extensively. So I wonder what is the actual additional value of doing a
> separate protocol instead of using the already defined IP ones.  The current
> text of section 3 is pretty outdated and incomplete to that subject.

True, but it could be adapted for beacon over other protocols which do not 
require IP stacks running.  There is now support for IP version heterogeny 
in service advertisement and service CLA; an IPv4 beacon can advertise and 
IPv6 service, and vice versa.  We should take care not to break that.


This being a product primarily of irtf, there is or was at least some 
concensus for the process defined.  As well, there is now running code 
mostly conforming to the spec in the document.  I am open to more robust 
v6 multicast discovery than sending to link local and other scopes on 
ff0*::* if there is useful gain to be had. Can you elaborate on your 
suggestion?

> - is this intended to be used on deep space links?

I would consider it "hailing frequencies" for this purpose.  I would 
imagine that if implemented in deep space, there would be a dedicated band 
for such, and a defined radio link spec, likely pre-existing.

At present, the spec and implementation I have worked with is plainly 
considering networks in reasonably close proximity, like wifi networks, as 
links for beacon passing and service autonegotiation.  It would work over 
the open Internet, but for any security concerns with man in the middle on 
the unencrypted udp beacon passing interface.

> - "Version: An 8-bit field indicating the version of IPND that  constructed
> this beacon. The present document describes version  0x04 of IPND. This
> version field is incremented for IPND if either the IPND protocol is
> modified or the Bundle Protocol  version is incremented. In this way the
> field can also be used to  determine the BP version supported by a potential
> DTN neighbor.”  As I understand it, this version field has 2 different
> semantics: the version of the ND protocol and the version of the BP. It
> seems to be a bit dangerous to have two semantics into a single field. I
> guess this may not be that big since most likely the versions of both won’t
> change often, but there are probably some convoluted cases that could arise
> theoretically.

I think that it would increment to 0x05 if EITHER ipnd or bp were to 
change... reasonably sure only one value is passed here, 0x04, which is 
understood to be BPv7 and ipnd v4, I think, however we may be stale on 
this being intended for BPv6, and incrementation may be required.  I will 
have to look into it. Maybe ScottB has a thought on the matter?  I think 
the idea is one value for a given BP/ipnd pair.


> - “To maintain the current neighbor set, IPND removes stale neighbors
> after the defined neighbor receive timeout period elapses without
> receiving any beacon messages from a particular neighbor.” .  What is the
> timeout value, given that in space links, the delay and disruption is
> variable? How it is set/changed?

It is in the runcontrol file when ipnd is launched, and is also parsed 
from received beacons.  User configurable, in other words.

> - section 6.2 IANA registration policy is “Specification Required”.  It
> seems a bit too loose given that the field is only 8 bits. Specification
> required means that an individual can write a specification and get a
> number. I suggest we put a designated expert to review the request, to avoid
> any bad registrations.
>

You may be right on this, but I see little opportunity to abusively 
register service formats for defined types of beacon advertisements.
Maybe someone will come up with a fictional Avian Carrier CLA, and wish to 
register an identifier for that service type... :)

Either way is fine by me, so might as well make it expert review. 
Unless, wait... that means I will have to do the reviewing, eh?

Thanks,
Scott

> Regards, Marc
> 
>
>       I would ask for comments at this time.
>
>       Sincerely,
>       Scott Johnson
>
>       _______________________________________________
>       dtn mailing list
>       [e-mail]
>       https://www.ietf.org/mailman/listinfo/dtn
> 
> 
> 
>