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

[Marc Blanchet <[e-mail]>]

> Le 7 oct. 2023 à 20:14, [e-mail] a écrit :
> 
> 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?

These are orthogonal. The intended status is just what it is. Wg document adoption is just another process. I haven’t got good success for wg document adoption, so I guess I pass on proposing anything.

> 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.

No I was thinking (I actually proposed that to Vint some months ago) to just advertise a BP service using DNSSD. Very straightforward. Not sure why we need another protocol here.

>  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?

See above. DNSSD is already coded and working on linux, macosx and windows. Pretty straightforward. See RFC6763, avahi on linux. I used it for another project. So simple and easy. No brainer. And widely implemented. (DNSSD is the IETF standard for Bonjour)

> 
>> - 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.

Ok. So this is not for deepspace links (i.e that are typically running BP over LTP over CCSDS links). Correct?

>  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.

Of course, but I feel not good to have a version number of something depending on two versions of other stuff. Does not look good to me as protocol design. But it may not happen often.

> 
>> - “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.

Well if it is not used in deep space, this is less of an issue.

> 
>> - 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?

Not you to decide. IANA asks AD to identify the experts. 

Marc.

> 
> 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