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!