DTN Interim (10/05/2022)

EBc/EB
RTc/RT

Admin (Chairs)

Comments in mailing list for IPN update draft. Take bulk of meeting to talk about draft and extending IPN via a screenshare. NMA if there is time.

This is standard IETF meeting; Notewell applies.

Please use the Hedgedoc - there will be a recording on YT (link here: TODO)

Document is in Markdown - plan to workshop as a group today and push the update. This document is a personal draft so EB/RT is applied instead of chair positions.

Prioritization of DTNWG IETF 115 meeting topics (5 min)

IPN Naming Scheme and Discussion (35 min):

About 3/4 of participants have read draft.

EB:
- Current IPN naming scheme that the IPN name is two tuple of node nbr and service nbr. Great being a single integer. When something has local meaning control and allocation is managable. To extend to global uniqueness single flat numbers can be difficult to manage. One slice is a Number Authority breakdown. It would turn into NA.nodeNbr.svrcNbr.

• Questions: is flat space going to work in global distribution? if not does this tagging with NAs the right way?

Alberto Montilla:
- Thanks for the document and great topic. Generic question; is there urgency to discuss this? This is very fundamental - do we need to move fast? If so why?

Jorge Amodio (chat):
- It is one of the dependencies to move forward with routing

Shawn Ostermann (chat):
- NASA seems to consider potential changes to the standard to be URGENT

BE:
- Fast is relative. There is a question if extension to IPN is useful and getting through the IETF process is an arc of many months.

Scott B:
- Comment on flat space; it can be used. Compression? Performance advantage of header compression for this. Criteria we should be using. Operational advantages of the header compression.

RT:
- My reasoning; pressing need to look at the preceived issue of IPN. Charter brings in naming and addressing and investigation there was confusion how to use. Not a document to pull it all together. It is timely to do this work now and clarification to IPN before WG gets deep into naming/addressing and forwarding.

Alberto:
- Thanks. One benefit look at specific examples in upcoming meetings. Multiagency examples.

RT:
- This whole thing is about interoperable behavior. If you want to use IPN in a closed system; have fun. When wanting to interop it becomes important. This documenbt makes this easier to admin, and use. Make TODO for examples.

Scott B:
- Agree the time to make the change is NOW. The sooner the better. Agree spec IPN scheme in 9171 is clear what is not is whast registries you can use to do node nbr assignment. Bad labels need to be fixed.

RT:
- Had a convo with Zahed how to update registration. Correct way is to publish a document to do this in IETF. Separate documents?

Joshua Deaton:
- Concern with general size of allocatable node nbrs? Strictly wanting structure instead of flat

RT:
- MY perspective; CBOR anything less than 23 needs only 1 octet. With a fcfs access you have to have overly long encodings. The main driver to use a prefix number. Avoids race to the low numbers.

Joshua Deaton:
- Suggest; would it be possible to use report to EID to act as the authority ID? the ipn scheme stays the same and want to do more low number system you can use report to EID to establish authority. That could give degree of separation. IMC (interplantary multicast) named singluar edge router in the reply to eid space and the separation between networks without having to cover that.

RT:
- I know where you go - it leads to BIBE. Now we tunnel from one address domain to another. Can work its just NAT.

ED:
- Agree with Rick; hesitant to redefine the meaning of the report to EID. True it can have some admin relationship but not necessarily the case. Do not want to change.

Scott B:
- having single naming authority is not effecient mighjt be named by different authorities. each eid will need its own.

Adam W:
- separate docs seem more reasonable

EB:
- what does this change with the node nbrs? They are all reserved because they are under numbering authorities. We need a registry of authorities not ranges.
- Repeat a question: do we need to extend IPN or define a new one and call it something like "extend ipn"

RT:
- Discussion points section of doc.
- Think what the receiving process is for a bundle
- behavior identical but hits error case one octet later
- functionaly no difference
- just pleasing acronym

Joshua Deaton:
- persona preference; from his work standpoint it is more frustrating to fix systems to do both options rather than just a new scheme. maintain with legacy elements.

Scott B:
- sort of issue was focusing on in latest email. institue change to scheme to limit impact on existing implementations. Rick is correct in that readily and simply just modify the scheme the impact on users of various implementations can be lessened.

EB:
- Josh when we talk about existing are they assumng a local admin network? can still say ipn:1.1 and its assumed local. if node is 4-billion and want to the world to know it is you then harder to maintain. reasonable ranges as scott suggested.

Scott B:
- deep concern; really want to avoid prohibiting NASA from participating.

RT:
- dont think status quo statisfactory. there needs to be change. making allocations in exsiting registry is not built on solid foundation. new scheme or update to ipn (prefer later). doing nothing is not an option

Joshua Deaton:
- invetible; on iss there will combined BPv6 and BPv7 but worry that tusing the same ipn nominclature might enter confusion territory.

RT:
- remember that BPv6 and v7 are NOT wire compatible!!!
- even if naming the same; there will be encap decap between v6 and v7
- doing name translation as part of that is a viable price to pay
- there is no backward compat between v6 and v7!

Joshua Deaton:
- perpective of operator on ground when they talk about DTN and see v6 and v7 bundle and same different names is could lead confusion

Scott B:
- requiring some change; agree taht we need to do something about the IANA registries structure.
- does not entail changing scheme specific part
- value of doing it and all for it
- higher numbers use more bandwidth and that is an operational disadvantage

RT:
- agree with scott
- point splipped through reviews
- in v6 the admin endpoint was always 0
- in v7 the admin endpoint is MAY 0
- The admin should just be 0 for everyone

Scott B:
- would need to re-read
- reclocation is always 0; the language in 9171 the admin endpoint svc nbr is 0 or must so the endpoint may be a node identifier
- langauge and wording; we all agree on what we want

RT:
- leads to second point
- if we agree ipn that its a tuple...
- for all eids on that device would have a common node nbr
- this is not written down anywhere...

Scott B:
- intent is node nbr is first class and construct eids from them
- if from clean cloth
- all ipn scheme endpoints in which this node is a member should have the same node nbr

Scott Johnson (chat):
- so there can be no potential for multihoming then?

RT:
- very specific to ipn

Scott B:
- desirable and can do then lets do it; not certain it is

RT:
- if we make a change to ipn and close the lid for like 5 years
- too many changes loses faith

RT:
- more comments?

Stuart Card:
- so kept quiet
- not going to pretend that fully understand doc and its ramifications
- has been involved in HIP
- recent with DRIP using an extension of the HIT -> HHIT
- appears draft as written could take RAA and call it a NA and sub-NA and mark it as HDA and build a HHIT
- 64-bit hash as the node-nbr
- HHIT is ID not a locator
- We must revolve the ID to locator
- repeat plea to look at DRIP docs for the HHIT for compatability

RT:
- me and Stu have discussed this and with Bob M.
- Cool to embed other schemes
- Important its the admin

Scott B:
- have variety of ways to assign numbers is fine!
- concern about tags that are 64 bits in length would defeat purpose of separating out authority id and saving bandwidth

EB:
- similar to scott
- resist temptation to give global meaning to node nbrs

EBc:
- seems to me that extension to ipn is something generally onboard with but questions how it would happen
- any final comments on thresholding?
- does size restriction to BPv7 as a whole or CCSDS?
- ipn uri will be supported but not dtn uri per blue book

Scott Johnson (chat):
- not sure i have heard a salient argument as to modification vs new scheme yet.

RT:
- threshold?

EB:
- if fields capped at 32-bits, 16-bits and 16-bits would always fit in 64 bit unsign int

RT:
- more radical change!!
- can see good implementaiton reasons
- suggested that any number larger 2^16 would not be availible for registration
- enforce via registraiton instead of document

Scott B:
- ??? breaks interop

RT:
- agree with you
- trying hard to not update 9171 with the document

Scott B:
- if need to mod 9171 then agree don't
- why would limiting size in this document changes thing?

Scott Johnson (chat)
- i am confused as to why, in the long term, we are encouraging the deployment of multiple dtn networks which are inherently named in a non-interoperable way.

Edward Birrane (chat):
- The original intent of IPN was small space networks - IIRC, the desire to use this more expansively (and to standardize on it) spurred this discussion.

RT:
- always work for backwards compat but...

Scott B:
- thats the deal it would break everything
- think its exestential
- 48-bits ???

Scott Johnson (chat):
- Scott is correct. This lays waste to the existing networks.

RT:
- none of the existing are interop unless with themselves in a lan

Scott B:
- ????

RT:
- out of time
- take action to do new revision

EB:
- keep the converstation going on ML!!
- Enter 115 with this in agreement for adoption to WG

RT:
- thanks!
- personal thanks to Carsten for kramdown RFC!
- see you all in London!

Network Management Architecture (10 min)

Open Discussion (10 min)