Minutes IETF104: dtn
minutes-104-dtn-00
| Meeting Minutes | Delay/Disruption Tolerant Networking (dtn) WG | |
|---|---|---|
| Date and time | 2019-03-26 15:10 | |
| Title | Minutes IETF104: dtn | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2019-04-20 |
minutes-104-dtn-00
IETF DTN Working Group Minutes March 26th, 2019 IETF104, Prague Chairs: Marc Blanchet & Rick Taylor ================================================================================ Administrativia -------------------------------------------------------------------------------- - Ed Birrane, Felix Walter, Ron in 't Velt will take notes. - Notewell noted. Agenda Bashing -------------------------------------------------------------------------------- - No changes. YouTube link to proceedings: -------------------------------------------------------------------------------- https://www.youtube.com/watch?v=F24qXyW30ns ACTIONS -------------------------------------------------------------------------------- 1. DTNWG chairs will send request for BpBis publication. 2. Fred Templin will perform shepherd writeup for BpBis. 3. Brian Sipos to pose 16/32bit extension length encoding to mailing list and provide update as pursuant to list guidance. 4. Brian Sipos will post final update to TCPCLv4 pursuant to #3. 5. Once posted, chairs will send request for TCPCLv4 publication. 6. Ed Birrane will perform shepherd writeup for TCPCLv4. 7. Ed Birrane will post final update to BPSec. 8. Once posted, chairs will send request for BPSec publication. 9. Scott Burleigh will perform shepherd writeup. 10. DTNWG chairs will request last call for mTCPCL document. 11. DTNWG chairs will request last call for BPSec Interoperability Security Context document. 12. Felix Walter to post to mailing list questions about redundant MTCPCL length encoding. 13. Martin Pilka, Stan Ratliff, Ronald in 't Velt to revive IPND draft. 14. Marin Pilka, Stan Ratliff to start discussion on general architecture for neighbor discovery to DTNWG mailing list. Questions (Q), Answers (A), and Comments (C): Presentation 1: Minimal TCP Convergence Layer (Scott Burleigh) ------------------------------------------------------------------------------- Brief overview of Minimal TCP CL (mTCPCL). Intent is to provide a convergence layer adapter simple enough for ready agreement to be provided with BPSec and BPBis. Spec is short, about 8 pages. Q: B. Sipos: What is policy on CBOR tagging? A: S. Burleigh: mTCPCL and BpBis state required elements. Neither preclude tags such as in extension blocks. Both specs intentionally silent on tags. Q: R. Taylor: Believe CBOR tags parsed as meta-data only. This might need to be handled explicitly in a dissector or an FPGA implementation, but tags do not alter content and shouldn't be part of canonical spec. C: S. Burleigh: Current specs complete without tags, but no objection to them. Q; F. Walter: In mTCPCL spec there is a length value in front of CBOR byte string, but CBOR byte string includes a length so this seems redundant. Q: R. Taylor: Does this have something to do with the problem of very large (1-2GB PDUs?) A: F. Walter: No. Last issue for BpBis was needing to serialize a block to gets its length first making implementing a streaming serializer hard. This issue is different because in mTCPCL you already have the serialized bundle so length is easy to get from the binary string and an extra length value is redundant. A: S. Burleigh: Need to look into it but fine to remove if it is redundant. C: R. Taylor: Classic mailing list question - please take it there. Q: M. Blanchet: We have 2 TCPCLs. In TCPCLv4 we connect to a port # (4556) which is the IANA designated port. Do we need one for mTCPCL? A: S. Burleigh: mTCPCL doesn't specify a port. Says connection established by management. Fine with assigning a port but it should be different than TCPCLv4. Q: R. Taylor: Do we need an IANA request for reserved port? A: M. Westerlund: IANA would need to provide a port, but we try to keep port usage down. If there are other methods like local config and/or dynamic port may want to try that first. C: S. Burleigh: mTCPCL considers this a local configuration and managed outside of the protocol. Assigned port does not need to be part of the standard. It can be added if necessary. C: M. Westerlund: Recommend against a reserved port for mTCPCL. C: R. Taylor: Can add text to mTCPCL saying it is configured out of band. C: S. Burleigh: Existing text says it is established out of band. Q; J. Ott: To fail safely, should TCPCLv4 and mTCPCL fail gracefully if they use the same port? A: S. Burleigh: I see no advantage to them sharing a port; if they are not supposed to share a port you don't need to implement a way to distinguish between the two. C: R. Taylor: First bytes in both are length and payload so you could get intro strange cases. C. J. Ott: Things on the Internet are often mis-configured. Some minimal wisdom in the spec may make failures graceful. C: S. Burleigh: Individual implementations can do that, but not something that needs to be added to the spec itself. Q: R. Taylor: Is there a unique enough header or preamble on connection to distinguish the two? Do we need to add a preamble to mTCPCL? A: S. Burleigh: Protocol will fail on misconfiguration. Adding more protocol elements to diagnose the misconfiguration could be done but prefer not to do that. C: R. in 't Velt: TCPCLv4 needs a port number and consider keeping it 4556. C: E. Birrane: mTCPCL by definition is the minimal needed to communicate and that should be rubric to apply when considering other features. Presentation 2: TCPCLv4 (Brian Sipos) -------------------------------------------------------------------------------- Spec just about done. No changes to background slides. Goal is to not change workflow or scope. CL in v4 works much as in v3. Same phases, headers, type codes. Demonstrated performance metrics and showed wireshark dissector which handles TLS in messages and re-assembling individual xfer segments. Presented some open issues from slides for WG discussion: Q. B. Sipos: Can we reduce 32bit extension item data length to 16bits? If a field needs more they can stitch together 2 fields. Q: R. Taylor: What was vision for extensions? A: B. Sipos: Original concept was negotiated data (EIDs, small parms). EIDs related to URLs are single-digit thousands of octets. C. R. Taylor: That sounds like 16bits. Take to the mailing list. Q: M. Blanchet: Are all authors in agreement on latest spec? A: J. Ott: We agree. Q: M. Blanchet: Apart from small changes described, is it ready for IESG? A: B. Sipos: Yes. Q: M. Blanchet: Anyone opposed to sending for publication? <<No one opposed>> C: M. Blanchet: Ed Birrane will be doc shepherd. Get write-up done. Q: M. Blanchet: Scott Burleigh, is the mTCPCL document ready for publication? A: S. Burleigh: Yes. Q: M. Blanchet: Anyone opposed to sending mTCPCL for publication? <<No one opposed>> Presentation 3: BPSec and Interoperability Suites (Ed Birrane) -------------------------------------------------------------------------------- Recent updater to BPSec and Security Contexts. Did not adopt CCSDS recommendation to add security association block. Changes name of cipher suite ID to security context. Will produce version -10 to capture editorial comments from CCSDS. C: R. Taylor: Will ask for WG adoption on the security context draft on the mailing list. Presentation 4: Interfacing Async and Sync NM protocols (Jean Chorin) -------------------------------------------------------------------------------- Walked through the slides for the architecture and goals. C: E Birrane: Good work considering it must interface with existing ION AMP manager which is not a clean interface. New interfaces coming. Q: E. Voidt: Do you handle DB lock on one side while queuing transactions on the other side? A: J. Chorin: No. NETCONF supposed to have commits on the DB and some small support if comment is made and others waiting, this is not as developed as in a real NETCONF DB, but something to look at. Q: R. Taylor: Question for E. Voidt (got YANG push through NETCONF) which was NETCONF notification on steroids. Do you have any advice for the guys working on this on whether that push/pull thing? And could that interface be more elegant? A: E. Voidt: We can talk offline some. 2 types of NETCONF notifications push events and yang-push subscribe to data store elements to get push on change. Less relevant for writes looking more how to push on a subscription. Diff between events when app knows something. When some recipient cares say what they want to receive. C: E Birrane: In example, command to generate data then followed by commands to get the data. With yang push could have NETCONF agent push data as it is received. Issue is when you reconnect after a long time you could get a lot of queued data. Q: M. Westerlund: What happens if you cause more data to be produced than can be delivered across the DTN? A: E. Birrane: AMP currently does not do data throttling and concept is hard in a DTN. Passes to BP bundles with quality of service and TTL and lets lower layer address it. Presentation 5: AMP/CAMP walkthrough (Ed Birrane) -------------------------------------------------------------------------------- Ed walked through some architecture/goals. Screen shots of the nm_mgr, nm_agent and camp scripts bundled in ION open source release 3.6.2. C: R. Taylor: For those not familiar, some of the parameterizations being shown in AMP is because you really need single roundtrip because delays can be very long. Presentation 6: pyDTN Hackathon Outbrief (Martin Pilka) -------------------------------------------------------------------------------- Reviewed of hackathon outputs and discussion of pyDTN for spacecraft. Request to resurrect IP Neighbor Discovery as it was needed to implement the pyDTN implementation. The draft is expired but information in it might still be valid. Specific requests from hackathon: - Get IPND draft up to date unless there is another means for discovery. - IPND should be updated to use CBOR. - Could we do non-IP discovery? Future CLAs. C: Rick Taylor: Neighbor Discovery is an active charter item. A DTN-ND using CLAs and maybe event-driven could be way to go. Others have proposed alternate designs. WOuld appreciate you working on it. C: M. Pilka: We would volunteer to do that. C: R. Taylor: Start a discussion on mailing list with ideas. C: M. Pilka: We agree to update the draft. And to move to CBOR and cover more than just IP? C: M. Blanchet: DTN may not be transported over IP anyway. C: M. Pilka: YTrue, but we need IP to help test with other implementations. C: Ron in 't Velt: The only CL we have is IP-based so we should do IPND first. I presented something in Buenos Aires that was not adopted, but can bring it back and work with you on it to have before Montreal. If we instead do a new architecture and start over, then not interested in that. C: R. Taylor: Do both. Refresh IPND as it is. In parallel investigate on the mailing list a generalized structure and approach for other CLs. C: S. Ratliff: I will sign up for generalized structure work on the mailing list, but no non-IP based solution should come out of IETF. C: R. Taylor: Other SDOs like CCSDS will want CLs for non-IP and will look to us for guidance. C: S. Ratliff: An architecture to slide in different transports underneath it is good. Some other SDO can do the non-IP ones. C: S. Burleigh: Agree with Stan. An architecture can draw a clear interface between neighbor discovery and establishing a connection. Build an IP-based substrate for neighbor discovery. There is no advantage for a proliferation of vastly different ND protocols for different environments. Better to have a standard data exchange of ND info and, separate, connected through a well-defined interface. The CL connection management software can start with IP and maybe later do others (such as bluetooth and wifi) w/o IP. But mistake to say never anything other than IP. C: M. Blanchet: Good to see people interested in next topics. Neighbor discovery and addressing architecture are work to be done. We also have LTP as an RFC so not just IP. C: M. Pilka: Lot of feedback from hackathon people asking if we can use this for IoT. We cannot see sensors all the time. Seems to be of interest from that part of the world for using this. ND is needed not just in IP world, could be bluetooth or something else. Wrap-Up -------------------------------------------------------------------------------- C: M. Blanchet: Next steps: BPBis chair will send request for publication and Fred Templin will do shepherd writeup. Brian will post last version of TCPCLv4 and Ed Birrane will do shepherd writeup. Ed Birrane will post last version of BPSec. Scott Burleigh to do shepherd writeup. mTCPCL will go to WG last call and if approved need a shepherd. BPSec Security Context document will go to WG last call. If it passes it will need a shepherd. C: S. Burleigh: I agree to shepherd BPSec Interoperability Security Contexts document. C: M. Blanchet: Once all of this is time we will revisit milestones. Neighbor discovery and management are good starting discussions. C: R. Taylor: Agreed. Get these out the door first. C: J. Chorin: Have laptop if anyone wants to see please visit. C: R. Taylor: Big thank you to those who came and showed running code. It is really good to see these things happening in the working group.