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

[[e-mail]]

Hi Brian,

On Thu, 10 Nov 2022, Sipos, Brian J. wrote:

> 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.

Fair enough.  I have not assigned more than one IPN Node Number to any 
given instance of ION.

> 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").

ION can be assigned multiple endpoint Node IDs, and the node-nbr component 
can be different, as evidenced in present use and application.  As 
demonstrated, these all continue to function.  Each endpoint Node ID can 
have 2^64-1 endpoints assigned to it.

There is a hard limitation on LTP Engine IDs, which are generally 
concurrent and identical to IPN Node Number.  This limitation does not 
exist outside of implementing multiple LTP Engines in one node.

>
> 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.

"There are four lights!"  Sorry, could not resist.

>
> 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.

Multiple Node ID, not IPN Node Number, assignments works like this:
scott@spacelypackets:~$ bpadmin
: l endpoint
ipn:268435456.0  -1	rule: q  script:
ipn:268435456.1  18932	rule: q  script:
ipn:268435456.2  -1	rule: q  script:
ipn:268435458.0  18815	rule: q  script:
ipn:268435458.1  -1	rule: q  script:
ipn:268435458.2  -1	rule: q  script:
ipn:268435462.0  -1	rule: q  script:
ipn:268435462.1  18931	rule: q  script:
ipn:268435462.2  -1	rule: q  script:

268435458 is the IPN Node Number (and hence the administrative endpoint), 
with Node IDs assigned to various endpoints, as necessary to effect 
discrete circuits over different protocols and ports from my 
experimentation.

>
> 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 quite possibly what is happening, but it works in the mode of 
operation I showed.  Deep packet inspection confirms that bundles passed 
through different CLAs take the same route they are assigned.

> 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.

Yes, I do like to build my own routers. There is such a more versatile 
group of options available when you roll your own...

Notwithstanding, how does my implementation in this manner break 
interoperability?  When one connects to any endpoint on that node 
providing a service, no matter how many Node IDs are assigned to various 
endpoints, one transacts with that node and endpoint in your contact 
graph.  How is this not interoperable?

Scott


>
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: Thursday, November 10, 2022 11:58 AM
>> To: [e-mail]
>> Cc: 'Rick Taylor' <[e-mail]>; Sipos, Brian J.
>> <[e-mail]>; [e-mail]; [e-mail]
>> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-00.txt
>>
>> APL external email warning: Verify sender [e-mail] before
>> clicking links or attachments
>>
>>
>> On Thu, 10 Nov 2022, [e-mail] 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 <[e-mail]>
>>> Sent: Thursday, November 10, 2022 7:56 AM
>>> To: [e-mail]; [e-mail];
>>> [e-mail]
>>> Cc: [e-mail]; [e-mail]
>>> 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, [e-mail] 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 <[e-mail]> On Behalf Of Sipos, Brian J.
>>>> Sent: Thursday, November 10, 2022 4:30 AM
>>>> To: [e-mail]
>>>> Cc: [e-mail]; [e-mail]
>>>> 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: [e-mail] <[e-mail]>
>>>>> Sent: Wednesday, November 9, 2022 6:32 PM
>>>>> To: Sipos, Brian J. <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail]
>>>>> Subject: Re: [dtn] [EXT] I-D Action: draft-ietf-dtn-ipn-update-
>>>>> 00.txt
>>>>>
>>>>> APL external email warning: Verify sender [e-mail]
>>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dtn
>>>
>>>
>>> _______________________________________________
>>> dtn mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtn
>>>
>