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

Brian, this isn't exactly right.  Every BP node comprises a BP Agent, an Application Agent, and zero or more Convergence-Layer Adapters (see section 3.1 and Figure 2 of RFC 9171).  The node - not the BPA - is the thing that is assigned an IPN node number.

But ION is indeed limited to assigning exactly one node number to a given node; stating that node number is one of the very first steps of deploying an ION BP node.

You're also correct that an IPN node number is not a Node ID as defined in RFC 9171, much as I might wish it otherwise.  A Node ID is defined as the endpoint ID of any singleton endpoint of which the node is a member (RFC 9171 section 4.2.5.2).

A BP endpoint is simply a set of nodes, nothing more.  There is nothing in RFC 9171 that prohibits a given node from registering in (becoming a member of) any endpoint it likes, so unfortunately it is conceptually possible for a given node to register (for example) in two different administrative endpoints whose EIDs are ipn-scheme URIs with (necessarily) different node numbers.

In this event, the node would have two different node IDs and would be informally identified by two different node numbers.  I don't think this is ever necessary, and I don't think it's desirable.

Scott

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

Scott,
The BP Agent (BPA) is the thing which gets assigned an IPN Node Number and I believe that ION is limited to assigning exactly one node number to a BPA. It's important not to confuse the IPN node number, which is what we are talking about, with a Node ID. An ION BPA can currently be assigned a set of endpoint Node IDs but they must all have the same IPN node number (e.g. one BPA can have endpoints "ipn:3.1" and "ipn:3.8", but cannot have endpoint "ipn:5.1").

CLAs are fully separate from Endpoint ID (and Node ID) and don't have their own on-the-wire identifiers; any CLA identifier or CLA parameters are an implementation detail and not currently standardized. So in your case you were working with 5 nodes.

If Section 3.1 of RFC 9171 draws equivalency of a BP "node" to an IPv6 "interface", meaning it's the thing to which BP names / IP addresses are assigned, then the BP model is missing the concept of the IPv6 "node" which is the router which operates separately from address assignments. In the BP model the node is 1:1 with the BPA which is 1:1 with the administrative endpoint, and there is no specific example of how multiple node number assignments would interact with that structure.

My naïve understanding is that a BPA is still 1:1 with an administrative endpoint and if there were multiple IPN node numbers assigned to that "node" the administrative endpoint (the entity doing the protocol work) would actually be registered as the "ipn:X.0" endpoint on all of the node numbers. In this case there is one BP "node" which is assigned multiple node numbers and it's the one BPA which is doing the routing and forwarding. This is more in-line with the IPv4 model where IP addresses are all assigned to the node, the same thing which is the router.

> -----Original Message-----
> From: scott@solarnetone.org <scott@solarnetone.org>
> Sent: Thursday, November 10, 2022 11:58 AM
> To: sburleig.sb@gmail.com
> Cc: 'Rick Taylor' <rick@tropicalstormsoftware.com>; Sipos, Brian J.
> <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
> 
> APL external email warning: Verify sender scott@solarnetone.org before
> clicking links or attachments
> 
> 
> 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
> >