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

We have several implementations besides ION, ud3DTN, HDTN, etc, where you
can run multiple "nodes" in the same device, even the same interface and IP
address.

-J

On Thu, Nov 10, 2022 at 10:59 AM <scott@solarnetone.org> wrote:

>
> 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
> >
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>