Subject: Re: [dtn] DTN neighbor discovery

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Mon, 26 Jul 2021 18:54:19 +0000

Brian,

Apologies for not getting back to you sooner. The DTN Interim was held on the eve of an important day job event that completely absorbed me for the bigger part of June.

Please see inline.

From: Brian Sipos <[email-masked]>
Sent: vrijdag 28 mei 2021 03:58
To: Velt, R. (Ronald) in 't <[email-masked]>; [email-masked]
Subject: DTN neighbor discovery

Ronald,
As a follow-on to the interest in advancing IRTF IPND [1] to an IETF document, I was looking at this earlier and think it would be beneficial to separate the concerns of:

Note that I argued for 'Neighbor Discovery' as a charter item, not necessarily for reviving the IPND spec. I more or less gave up on IPND after my ill-received presentation at the Buenos Aires meeting.
1.      The neighbor messaging payload with discovery information
2.      Framing of the payload with security (e.g., source signing), data lifetime, etc.
3.      The transport of that packet via broadcast, multicast, or even unicast
If layer #2 is performed by BPv7, then BPSec provides security and #3 can be done with a BP convergence layer. This gives a huge benefit that all of the mechanisms of BP, BPSec, and CLs can be leveraged. It also avoids needing a separate UDP port or broadcast address assignment for DTN neighbor messaging and allows the neighbor messaging to apply to IP and any other network type usable by BP.

The separation may make sense, but the problem I see with making neighbor[*] discovery bundle-based is that it creates a potential chicken-and-egg problem, in that you may not always know a priori which CLs neighbors support. In contrast, an out-of-bundle-protocol neighbor discovery approach could signal which CLs the neighbor implements.

[*] My definition of 'neighbor' in this context: another BP speaker that is reachable in a single 'bundle hop'. Note that a 'bundle hop' may involve multiple underlying (IP or other) network protocol hops.

I have a very rough draft of layer #1 in a public repository [2], nothing in there is settled at this point other than "it uses BPv7 as framing/security and UDPCL for transport" so it's not submitted as an actual I-D. Let me know what you think about this. If it's worth progressing you're welcome to comment and/or contribute to the draft.

Thanks for the offer! I just gave your draft a very cursory glance. I need to read it more carefully in order to come up with meaningful comments, but obviously that is not going to happen before today's DTN session :-\ One advance remark though: section 1.5 mentions NHDP [RFC6130], but in my opinion mischaracterizes the purpose of that protocol, which is to discover a 2-IP-hop neighborHOOD in order to enable the selection of Multi-point Relays (MPR) for efficient dissemination of routing information.

Thanks,
Ronald

Thanks,
Brian S.

[1] https://datatracker.ietf.org/doc/html/draft-irtf-dtnrg-ipnd-03
[2] https://briansipos.github.io/dtn-neighbor-msg/draft-sipos-dtn-neighbor-msg.html
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.