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
>