Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt

Hmmm.  In ION, a single node may utilize 3 different CLAs (one for UDP, one
for LTP/UDP, one for TCP) concurrently and communicate using 3 different CL
protocols.  Alternatively you can stand up 3 distinct nodes on one computing
device, each of which communicates using a different CL protocol.  CLAs (in
ION, "inducts" and "outducts") are not named in any syntax that includes the
Node ID; only BP endpoints are named in such a syntax, i.e., the ipn-scheme
endpoint IDs.

A BP node can in concept be implemented as a single process on a given
computing device; ION doesn't work that way, though.  Every ION node
comprises multiple processes: a BP forwarder daemon, a BP clock daemon, at
least one CL reception (induct) daemon, at least one CL transmission
(outduct) daemon, and usually several more.  All of the nodes share
concurrent access to a notionally non-volatile "heap" and a single block of
"working memory" allocated from system memory; the data structures managed
in these media constitute the state of the node.

Scott

-----Original Message-----
From: scott@solarnetone.org <scott@solarnetone.org> 
Sent: Thursday, November 10, 2022 8:58 AM
To: sburleig.sb@gmail.com
Cc: 'Rick Taylor' <rick@tropicalstormsoftware.com>; Brian.Sipos@jhuapl.edu;
rick.taylor@ori.co; dtn@ietf.org
Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt

On Thu, 10 Nov 2022, sburleig.sb@gmail.com wrote:

> Hi, Rick.  The definitions of "node" and "BP agent" are in section 3.1. 
> The observation that BP nodes are functionally analogous to network 
> interface cards is merely an observation, but I think it's consistent 
> with -- amplifying -- the third and fourth paragraphs of section 3.2.

+1

So under these definitions, my demonstrated implementation is conformant
with the proposal, since I am not applying more than one Node ID to any
single process, specifically CLA related daemons?  This makes it also true
that I demonstated 7 nodes, not 5. Each CLA is named with a different NodeID
on the ION instance which implements UDP, LTP/UDP, and TCP simultaneously,
making that 3 nodes instead of one.  Is that correct?

ScottJ

>
> Scott
>
> -----Original Message-----
> From: Rick Taylor <rick@tropicalstormsoftware.com>
> Sent: Thursday, November 10, 2022 7:56 AM
> To: Brian.Sipos@jhuapl.edu; sburleig.sb@gmail.com; 
> scott@solarnetone.org
> Cc: rick.taylor@ori.co; dtn@ietf.org
> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt
>
> Hi Scott,
>
> That wasn't my reading, but I am often wrong.  Do you have a reference to
the relevant section(s)?
>
> Cheers
>
> Rick
>
> On Thu, 2022-11-10 at 07:51 -0800, sburleig.sb@gmail.com wrote:
>> I think RFC 9171 is fairly clear on the definitions of "node" and "BP 
>> agent".  BP nodes are functionally analogous to network interface 
>> cards; any number of BP nodes can be located on a single computing 
>> device (whether physical or virtual).
>>
>> Scott
>>
>> -----Original Message-----
>> From: dtn <dtn-bounces@ietf.org> On Behalf Of Sipos, Brian J.
>> Sent: Thursday, November 10, 2022 4:30 AM
>> To: scott@solarnetone.org
>> Cc: dtn@ietf.org; rick.taylor@ori.co
>> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt
>>
>> Scott,
>> I do look forward to seeing more detail about use cases involving a 
>> node with multiple IPN node numbers.
>>
>> I wonder though if this is a terminology difference/confusion similar 
>> to how
>> IPv4 assigned addresses to a "host" while IPv6 assigns addresses to 
>> an "interface" with a host being allowed to have any number of 
>> interfaces. >From my current reading along with this proposed 
>> additional constraint, each BP Agent (BPA) instance is a "node" with 
>> a single node number but there could be a larger entity where BPA 
>> instances can share storage and routing logic to provide bridges 
>> between those BPAs. Or maybe there needs to be clarification on the 
>> difference (if there is one) between a "BP Agent" (with a single 
>> allowed IPN node number and single administrative endpoint) and a "BP 
>> Node" as something else possibly larger in scope.
>>
>>> -----Original Message-----
>>> From: scott@solarnetone.org <scott@solarnetone.org>
>>> Sent: Wednesday, November 9, 2022 6:32 PM
>>> To: Sipos, Brian J. <Brian.Sipos@jhuapl.edu>
>>> Cc: dtn@ietf.org; rick.taylor@ori.co
>>> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update- 
>>> 00.txt
>>>
>>> APL external email warning: Verify sender scott@solarnetone.org 
>>> before clicking links or attachments
>>>
>>> Hi Brian,
>>>
>>> On Wed, 9 Nov 2022, Sipos, Brian J. wrote:
>>>
>>>> Rick,
>>>> I think this kind of new constraint on EID locality is very
>>>> helpful:
>>>>> All 'ipn' scheme URIs for endpoints co-located on a single bundle 
>>>>> processing node MUST share the same value for the node-nbr 
>>>>> component.
>>>
>>> I have to disagree.  This severely limits useful, already deployed 
>>> functionality, as you will see in the wg meeting, and will limit the 
>>> ability to implement sensible routing practices.  The proposal turns 
>>> every node into an end-user host.
>>>
>>> Enjoy,
>>> Scott
>>>
>>>
>>>> There are many assumptions embedded in current BP implementations 
>>>> which are based on "what makes sense" rather than documented an 
>>>> interoperable requirements.
>>>>
>>>> While that statement constrains half of the problem (a single node 
>>>> cannot have extra node numbers allocated) there is still a 
>>>> potential situation where a single "logical node" collection of 
>>>> EIDs with the same node-nbr is distributed over multiple 
>>>> entities/agents. For example Entity A is a routing node with EIDs 
>>>> "ipn:5.0" "ipn:5.2"
>>>> allocated, and Entity B is a stub node with EID "ipn:5.1"
>>>> allocated
>>>> and a forwarding route configured from Entity A. Entity A would 
>>>> contain the administrative endpoint and route to the outside world, 
>>>> and Entity B could be a very lightweight implementation that 
>>>> doesn't need to
>>> do any routing (all bundles pass through Entity A).
>>>> Is this an allowed behavior? Should it be?
>>>> It could be useful in a situation of distributed subsystems (e.g., 
>>>> a collection of sensors) where the whole system has a Node number 
>>>> allocated and each subsystem has a single EID allocated. This 
>>>> allows using "normal" BPA and CLA tools/protocols between the 
>>>> subsystems, though I suspect that most current implementations 
>>>> would not allow this
>>>> off-
>>> the-shelf.
>>>>
>>>> Another way of putting this similar to a behavioral requirement
>>>> is:
>>>> after a node receives a bundle destination matching its own node 
>>>> number, are the only two options for that node to either deliver or 
>>>> delete the bundle? i.e. it's prohibited from forwarding the bundle
>>>>
>>>> Thanks for the explanations,
>>>> Brian S.
>>>>
>>
>> _______________________________________________
>> dtn mailing list
>> dtn@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtn
>
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>