Minutes interim-2021-dtn-01: Thu 16:00
minutes-interim-2021-dtn-01-202105271600-00

IETF DTN working group meeting
May 2021 Interim - Virtual

Thurs 2021-05-27 20:00 - 22:00 (UTC)

Co-chairs: Rick Taylor, Ed Birrane

YouTube: https://www.youtube.com/watch?v=CEr3xUGS5WQ

Edward Birrane (cEB)
Marc Blanchet (MB)
Marius Feldmann (MF)
Martin Duke (adMD)
Oscar Malnero (OM)
Rick Taylor (cRT, RT)
Ronald in 't Velt (RV)
Scott Burleigh (SB)
Stu Card (SC)

Agenda
=====
- Admin, Chairs, 10 mins.

- Discussion of Working Group Recharting Text, 50 mins.
  - Chairs to introduce, 10 mins

cEB:
- we want to make sure that the work we select for next charter is stuff the WG
wishes to do and its techical priority and ability to do it - trim the list for
IESG review, avoid exhausting the WG cRT: - IESG focus on documents of value -
to them - Nothing against personal drafts - Do not think we are suffering from
that cEB: - use cases were baked in with past charter documents, did not read
charter but showed it - with new charter there are 3 categories. Items out of
IRTF that were not part of original charter and see what needs to come through.
Try to understand and capture stuff for next stage. Extension work on previous
work (convergence layers). cRT: - operations/admin -- management stuf must be
present. Async management work should continue! Important as a practicality -
new work item mapped to existing documents shown - looking as a sign as active
interest in an area - note that one document was selected for each area which
there could be many - No explict draft for Custody Transfer, part of ECOS? - No
draft for Naming/Addressing/Forwarding - its an obvious missing link but no
personal drafts? - No extension blocks SB: - custody transfer is part of BIBE
cRT: - understood, asks for Martin (current stand-in AD) MB: - Registry of
service IDs - he knows he has to publish it cRT: - folded into naming/address;
service ID is sort of address - aware of active engagement and does not seem to
be contray to general direction of what is being proposed - Martin does this
approach seem good, will you make decision of Zhed? adMD: - Zhed will make
choice - Initial reaction: It seems like a lot! And could lose energy -
Extension Blocks is very open ended; common for something more mature cRT: -
not maintenance of existing extension blocks but NEW ones to perform an
additional function adMD: - Suggestion to slim down: understand obstacles to
deployment or actual operation problems to already deployed systems cRT: - Ed
and Scott are more in tune with deployments; will defer to them to highlight -
We agree this is a big list; it is a concern for the chairs to bite off more
than we can chew cEB: - "It has to be useful" - what is needed to deploy and
run a network - Observation: large part of transport and security protocol was
done some time ago (technical) cRT: - some of these drafts have expired due to
IESG review of BPv7/BPsec MB: - use cases were from experimental to real
deployment - Scale is something that Naming/Addressing is needed for cRT: -
completely agree, will fight for naming/addressing in the recharter text SC: -
does naming only nodes/interfaces or also information (in ICN sense)? cRT: -
bullet does not define this; it would be a follow on discuss it - we don't know
much about names except how to format them RV: - neighbor discovery? cRT: -
part of the naming/addressing/forwarding - how do you forward if you don't know
who your neighbors are? RV: - then everything goes into naming/addressing! cRT:
- wary of doing routing in this recharter cycle, we can burn years doing it but
concerned that the scaffolding to build routing does not exist yet - Neighbor
discovery was left out and should be there! RV: - in my book neighbor discovery
is not the same as routing OM: - can the process of testing the stability of an
established or growing network? - is that a use case or out of scope? cRT: -
ietf looks at other bodies to get accreditiation of items. IETF sets standard
but quality of assurance and what not left to other SDOs - does not prohibt us
understanding the use cases needed by these sdos to do such work OM: - working
in IPNSIG to setup to make it work operationality - Interplanetary Internet
Prototype network we are building out. And specifically asking about putting in
requirments for use cases related to testing,emulation, and such cRT: - rapidly
prototype and test new stuff brilliant! OM: - working on that for some months,
testbeds up to datacenters in size cEB: - what is needed in operation of these
networks, then Oscar your experience is vital for other documents going forward
- are there specific topics missing in the three categories? cRT: - RV brought
up Neighbor Discovery cEB: - Also Service Discovery SB: - Multicast? cRT: -
Again part of Naming/Addressing? BPv7 defined endpoint as unicast or multicast
- Its a name used by multiple destinations but again dipping into routing! -
Multicast Routing...AHHH MB: - we are putting a lot of stuff here - We
explicity write the down here cRT: - make a list in codiMD [this never
happened] adMD: - other advice; agrees naming/addressing is important and could
become a journey - comfortable with finite time milestones driven by charter -
appreciate effort to chop up stuff into smaller bits - not sure if we found the
right building block - potentially noddle on it, milestone for a document to
write something down? - 2027 milestones cRT: - agreed, but worries ignoring it
until it becomes a bigger issue MA: - suggestion: some items in list that are
well defined - which would we like to keep in the list to give more time on
other items cEB: - agree, propose to project these items and ensure that
Naming/Addressing and Service IDs be part and others removed due to maturity
cRT: - do we want to go through one by one and see? cEB: - how about anyone
join queue if you want something to be removed cRT: - remove LTP (Sorry Fred
Templin); go to another CCSDS to finish it/publish it? - Can't think a use case
that is very isoteric or deep space - Any objections? SB: - comment: agree that
CCSDS is a better place for LTP - caveat: sense this is some uses we have not
discussed here; that are not deep space cEB: - feel that LTP fragmentation
would be different in CCSDS without parties as part of discussion? SB: - the
result would be the same regardless of SDO, seems to be better for parallel
into SDO and then adopted cRT: - not a bad approach for this - do we want to
vote it off? cEB: - is BIBE and Custody Transfer the same thing? SB: - do not
need a separate item for it, but do not see value in that - remove custody
transfer from list FF: - It very different than BPv6, with custody transfer in
BIBE - might need a similiar mechanism cRT: - I share some opinions about
pre-determined custody transfer instead of ad-hoc - Lets defer work to next
recharter as we need supporting tech we dont have yet FF: - could also turn out
that a general mechanism that is used in BIBE cRT: - are you willing to help us
get it right? FF: - i would hope so and would like to see something in BPv7
cEB: - from a work item perspective: BIBE is needed in recharter - would CCSDS
could look at custody mechanisms as an update to BIBE? cRT: - BIBE has its uses
ignoring custody transfer SB: - that was designed in last part of draft, with
and with custody transfer - ad-hoc (good samaritan as in BPv6) has appeal,
implementation experience not encouraging - We may need to have a discussion on
this topic? MA: - agree that BIBE stay in keep list; doing it in a way without
custody transfer is important for security - start with chapter in BIBE and let
it grow out? cRT: - pragmatic approach and like that - additional security
contexts? makes senses to have a foot into COSE way of doing things for BPsec -
do we allow in charter to add more? CB: - not correcting. COSE gives heap of
lego bricks, but still need to do the building! flows and what it means must
come from DTN not COSE. SB: - lots of things will end up happening in DTN work,
not all which need to be standardized - adopting standards from use is a good
model; security contexts is an example of that cEB: - concern with WG focus on
this? - Have high level item to address security items as they come up? - COSE
context is 95% done but when done turns into 3yrs of iteration BS: - in defense
of adoption, two parts to this; where you put COSE and what you put in that
container (very small) cRT: - difficult question... - continue this discussion
for 15 mins or list? - rest of this will be taken to list; then argue on which
ones stay and go

  - Collaborative editing in CODI-MD, 40 mins

**Current Charter**

The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
mechanisms for data communications in the presence of long delays and/or
intermittent connectivity. Delay-Tolerant Networking (DTN) protocols have been
the subject of extensive research and development in the Delay-Tolerant
Networking Research Group (DTNRG) of the Internet Research Task Force since
2002.  The key documents are the DTN Architecture  (RFC 4838), the Bundle
Protocol (RFC 5050), Licklider Transmission Protocol (RFC 5326) and convergence
layers (RFC 7122, 7242). Multiple independent implementations exist for these
technologies and multiple deployments in space and terrestrial environments. 
There is an increase interest in the commercial world for these technologies,
for similar and different use cases, such as unmanned air vehicles.  In this
context, there is a need to update the base specifications, i.e., RFC 5050, RFC
7122, RFC 7242, RFC 6257 and RFC 6260,  based on the deployment and
implementation experience as well as the new use cases. Moreover, there is also
a need to have standards track documents for the market.

Therefore, the purpose of this working group is to update the base
specifications in light of implementation experience. The group shall do a
review of deployment problems and lessons learned, come to consensus on the
issues to be addressed in the base protocol documents, and update the
specifications accordingly. The group shall not endeavour to change the
underlying architecture or the bundle protocol principle.

Work items are:
•Agree to a list of use cases for evolving the DTN specifications and a list of
work items to be worked on. •Create updates to RFC5050, convergence layer RFCs,
and security (RFC6257), as standard track documents. •Document a registry for
DTN Service Identifiers.

**Proposed Charter**

The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
mechanisms for data communications in the presence of long delays and/or
intermittent connectivity. The Working Group has submitted the Bundle Protocol
v7 (BPv7), corresponding Bundle Protocol Security protocol (BPSec) and
interoperable Security Context, and the TCP Convergence Layer documents to the
IESG for publication as standards track RFCs.

The purpose of this Working Group now turns to further work relevant to the
area of Delay/Disruption Tolerant Networking, divided into 3 broad categories:
•Standardisation of protocols and capabilities that were defined in the DTN
IRTF documents, but excluded from the current output of the Working Group;
including an update to the Licklider Transmission Protocol (RFC5326),
Bundle-in-Bundle Encapsulation, Quality of Service indication, and Custody
Transfer for reliable bundle delivery. •The definition of protocols and best
practice in the areas of Naming, Addressing and Forwarding, Key Management, and
Operations, Management and Administration (OAM); including the standardisation
of the Asynchronous Management Protocol (AMP). •Extensions to existing
protocols, including Extension Blocks to add additional capabilities to Bundle
Protocol, additional Security Context definitions for BPSec, and new
convergence layer adaptors.

- Naming/Addressing workshop, 50 mins.

  - RINAish Thoughts on DTN Naming and Addressing
  (https://datatracker.ietf.org/doc/slides-interim-2021-dtn-01-sessa-rinaish-thoughts-on-dtn-naming-and-addressing/)
    Marius Feldmann, 15 mins

MF:
- share some thoughts on naming/addressing
- took a look a RINA; proposal by John Day
- gives clear definition of things, and how to structure things in DTN domain
- Help weakness of certain things in IP stacks (mobilty and multihoming)
- layer of naming, layer of node addresses independent of interfaces (point of
attachement) - Terms are well defined; Names, Addresses, Titles - EID - name?
title? address? not clear - We need a well defined vocabulary - Difficult to
get a scalable approach for routing - Need clear separation of scopes, between
DTN domains - Roles to EIDs; EIDs can be used for routing; used as name and
address - Do not need to change DTN for this - Conclusions - BIBE is really
needed to separate scopes/layers - No way to store EIDs as titles in BP --
extension block to store EIDs you may need - Info RFC with clear definitions
OM: - RINA model; any relation to object oriented model of DNS? instead of
hierarchial considers each endpoint an object all capabilities/information for
resolution? MF: - unware of this model so can not answer question OM: - noticed
dynamic network, the model of the object was easier to deploy new nodes - feels
like this is similiar approach compared to RINA model cRT: - RINA model is what
I believe in as well; may refer to your slides - Difference between title and
address is critical - there is an alternative to BIBE by using label switching
cEB: - EIDs: would take multiple roles? scheme EID asserting specific role, or
EIDs only used for a certain role MF: - both could be possible, does not want
to exclude

  - A proposed framework for Naming, Addressing and Forwarding
  (https://datatracker.ietf.org/doc/slides-interim-2021-dtn-01-sessa-a-proposed-framework-for-naming-addressing-and-forwarding/)
    Rick Taylor, 15 mins

RT:
- Marius tackled with semantics, I am taking a functional approach with
experience - Need formality in terms and understanding to avoid confusion -
Very similiar to MF without working with him - Not attempting to standardize
but a conceptual model for discussion - Personal opinion and disclaimer stuff -
Receivers can have multiple EIDs; thing that receives bundle has a name, and
can have many of them but is divorced from how to get there - Node IDs and
special EIDs that are unicast and name individual BPA app - Neither scheme
defines mutliplicity of EID - With two schemes; there is no universal scheme? -
Late binding is very important! SB: - destination fixed - address mailbox - dtn
routing is doing what you can to get into mailbox that content to nodes SC: -
registry of schemes? RT: - can i come back to later? - attempting to define
name resolution; the algorithm - Filling FIB is out of scope as it is part of
routing - but we assume its existence - Need to map EIDs from one scope to a CL
name -- Anntonate bundles for Name Resolution - How to cross Naming Domains?
BPA between them - Extension Block recoding Name translation as it traverses
network implemented as a stack - Ed originally called this "Ticket to Ride" SB:
- stack is right way to do this, no need for extension block but is a
converstation - ION has been doing this for a long time internally with
implementation -

SB
- agree that have on massive registry is the wrong approach
cEB:
- agree its useful, but plug security!
- we need to be sure not to expose internals of one network to another
RT:
- when leaving a domain you pop all stuff off stack to avoid data leaks
MD:
- makes a lot of sense from routing perspective
- how do you prove idenity without global namespace?
RT:
- do i need to prove everyone or just people i want to communicate with?

  - Heated debate, 20 mins

- Any other business / Open Mic, 10 mins

cRT:
- thank you!
RB:
- Requst time next meeting for updates on ...
OM:
- Thanks! We love to collab with the work you are doing!