IETF 115 DTN working group meeting

Thursday 2022-11-10 13:00 - 15:00 (UTC)

Co-chairs: Rick Taylor, Ed Birrane
Secretary: Adam Wiethuechter

cRT, RT; Rick Taylor
cEB, EB; Ed Birrane
sAW, AW; Adam Wiethuechter
BS; Brian Sipos
SH; Sarah Heiner
SJ; Scott Johnson
BM; Bob Moskowitz
adZ; Zahed
MB; Marc Blanchet
SC; Stu Card

Admin, Chairs, 5 mins.

Agenda Bash

BS: fit two into his single slot?

MB: reposted draft service registry draft and app framework, want to
know if WG interest. At end wouldn't mind a few minutes.

cEB: agree, nothing to add

IPN Naming Scheme (Rick Taylor, 35 min)

• clarity: taking chair hat off so (RT)
• WG adoption call success after interim and now WG document
• All to do with IPN scheme URI

• Background

  • Sources and destinations using URI
  • Defined as node-nbr.service.nbr

  • Specific encodings for two BP versions out in the wild

    • In 6269 and 9171

  • node-nbr is unique where service exists

  • service-nbr id of server
  • In BPv7 the endpoint is unique for interop
  • All about unicast, no multicast
  • In description in RFC node-nbr is implied to be unique following
    ip:port

• Problems

  • One IANA registery for node-nbr: CBHE

    • For BPv6 and predates BPv7
    • CBHE not even used for BPv7
    • Rename?

  • Implied behaviour

    • Implemnetaiton knowledge
    • Interpertations during interop
    • Need clean clear specs
      • Do not care what it says as long as interop spec is
        clear

  • Single flat numbering space

    • BPv6 days of 2^64 bit space from wire encoding
    • Penelty for size of number to encoding on wire

    • Early allocation uses less octets

      • Newer items very large encodings
      • Deep space and constrained devices means this is bad
      • Seems unfair

    • Low numbers are not reserved

      • Using spectrum that is reserved to be handed to others
      • No official unlicensed spectrum

• Solutions

  • IPN scheme clarifications

  • Renamed CBHE registry for clarity

    • BPv6 Node Numbers (and service)
    • Copy it for BPv7 and create registries for them

  • Reserved low numbers for private use

  • Number Authority prefix
    • with effecient encoindg
    • tackle the flat space
    • orgs hand out in a controlled way
    • No large chunks
    • No badgering IANA
    • Probably better encoding

MB: registry has private use. Just not low numbers. Trade offs. private
use is in lab; packet size doesn't matter. In constrained networks this
matters. Precious for production. Opposite; private should be higher.

RT: Agree, using CBOR. Not a political convo but what happens when IANA
gets stuff from NASA and ??? and both want low numbers?

BM: size the header; look at LPWAN? SCHC?

RT: yes. not changing BPv7.

BM: as long as you looked.

RT: dropped out of scope in terms of pragmatism.

• Useage Clarifiations

  • Common intersection of behaviour from those reading documents

  • Value 0 of node-nbr MUST NOT be used except part of ipn:0.0

    • ipn:0.2; makes no sense

  • Great than 2^64 for node-nbr must not be used. Changes CBOR
    encodings.

    • Implied by two statements

  • All ipn for endpoints co-located must share the same node-nbr

    • Read read as ip:port
    • Counter: BPv7 clear URI in totally is unique
    • Personally: arguments for both

Erik Kline: what you just describe doesn't make sense. Saying 2.* is
different than everything on a single node has the same.

N.* is always on * and nowhere else.

Implies that it can have 2.* and not 3.*.

RT: you can only have one node-nbr! adding routing.

EB: time perspective; this will be open again

EB: these is a MUST in this; are there enforements?

RT: are we having DTN police force? we should have a clear spec and
documentation.

- Service-nbr
    - ws a MUST now a MAY?
    -2^64 cause cbor - registry changes
- cut paste, rename - clone registry and named for bpv7
- private at bottom
- experimental at top - private use is chunk of unlicensed spectrum
- if you use in wild, keep in mind that is must be shared

Alberto Montilla: question; why create separate and not extend?

RT: purely want to clean up with the change of private use. if no change
we don't make it

AM: use of unlicensed spectrum. huge implications. why create issue now?

RT: one using term as people familiar. knows someone who deployed as
1,2,3,4,5 and wants to be interopable. as long as we know it is free for
all space then it doesnt really matter where it is. felt low was useful

Kevin Fall: uniqueness in ipn; anycast style envirornment.

RT: very clear; 9171 do not use IPN for that.

KF: seem unfortante

RT: yes, but not trying to sole that

Scott Burleigh: if you have authority reserving low numbers are moot.

RT: agree; once you have authority then it doesnt make sense. if we have
authority then why change?

MB: Same as Scott. No reason for two registry

RT: cause changed allocations

MB: then out of sync

RT: BPv6 and 7 are not interoperable. take to the list.

MB: feel bad about it. would like to learn what you mean between private
and experimental. iana private and experimental are same range.

RT: read an rfc and leared they are different but if we want to conflate
that is fine.

SC: restatement; saying iunique must point to 1 and only 1 node
different than each node has 1 and only 1 number. What is a node!?
computer, core, vm?

RT: things would share an admin endpoint?

BM: point made for private use for authority for private nodes. not sure
in your envirornment; stealth mode development to get number to work
with disclosure is valuable.

RT: lets get to authority to answer it. must support somehow.

• no specs for well-known services that are global and interop then
  speak up (CCSDS)
• MB's draft on service numbers is perfectly fit for this

• take private/experimental use to list

• Number Authorities

  • flat is inefficient in CBOR
  • prefix in front to go to a tree

  • could put an extra number in front of node-nbr; this is a
    Numbering Authority

    • questions about creds for this

  • can hand out precious low numbers for use in your network and
    still be unique

  • encodes shorter and is more flexible
  • Can have subauthorities!
  • Both components are OPTIONAL
  • Number Auth. have a global registry in IANA
    • maintains interop
    • registry for them

• Advantages

  • How to detect?

    • can see one octet later than you do now
    • type of URI (2), length of array (2,3,4)

  • backwards as optional

  • removes contention in registry

SB: actually, ask Ed first

EB: in reference to understanding that different nodes can not have then
a single node can have constrains: opinions if both should exists? 1:1
to authority/sub node-nbr?

SB: both ipn and dtn are valid in 9171 so, already precedent multiple
unique node ids. There can be DTN and IPN - alias already exists. think
bad practice for a single node to have multple node-nbrs and no oppoosed
to excluding it in spec. there existing mechanism that frustrate that.
agree that same node-nbr should not be used for multple nodes and that
is important to document in spec. Node is technical term in 9171. if say
authorities and absence of encoding of one in ipn implies null authority
would suggest that null authority as one that nobody

RT: in effect creating 0 with iana. ???? if you are 0 then you dont need
to put in there. i think we agree

SB: arguing for something other than iana, might be easier.

RT: its just there?

EB: by having existing behavior unchanged but feel different take to
list

SB: preference for limiting the size of authorities to 32 bits each. so
they can be conbined into a 64bit number as they currently are. minimize
impact of existing implementations and performance.

RT: got a response. 1) do not want to reduce the exisiting 2^64. halfing
is a real change. my implementation can allow for it. one implementation
can work for one and not another.

SB: would be a 64-bit combined still work? 128 and 196 woul dwork bad in
constrained.

RT: breaking backwards compat is more dangerous. do not want to remove
thir registration.

SB: they dont want mnumbers bigger than 32 bits.

cEB: scott please report to list

AM: opinion of uniqueness. agree on first point for scott. 1:1. not sure
we should impose the limitation.

cEB: make a post to mailing list on topic to capture discussion

BS: mentioning that ipv6 made the same clarifying distinction. we can do
the same here.

RT: valid point. we should be id nodes and not interfaces. it was a
mistake; see why but not do it for dtn. we do not have hostnames

BM: putting some work iana; early review?

RT: yes we will be

Felix Flentge: the node is something ???? no reason why have multiple
node-nbrs - agrument from scott doesnt hold as different names (???).
unless we define clear use cases.

cEB: thank you, send to mailing list

RT: i think one of ipn is simplicity. should be tight and light.
multiple node-nbrs and a node might go against it. but dtn uri might be
a good dumping point for cool stuff?

BPv7 Administrative Records (Brian Sipos, 10 min)

• No slides here. Document was not changes; recently adopted.
• Nothing substantial yet.

cEB: please WG read and give some comments. Don't hear in the next few
months it will advance to next step.

• ACME WG and SECDIR are depending for it to IESG for other work to
  continue.

COSE BPSec Security Contexts (Brian Sipos, 20 min)

• Discussion ID wishing to be adopted

• BP already has default sec ctx

  • limited to symmetric keys and situations

• larger networks and envisioned networks need pki sec

  • falls into common practice

• reuse exisiting stuff

• COSE is now STD

• Interop profile

  • here is what expected and required

• Get BPSec to work with existing PKI tools and systems

• Feed back welcome as well as adoption if valuable

cEB: request to consider adoption

BS: yes

Stephen Farrell: ACME doc begin processed.

BS: relationship the ACME extension is where cert comes from. this
document is how do we use in BPsec. currently TLS using TCP-TCL but
could also use for BPsec for e2e sec where other is single hop.

SF: not sure if equivalant and would warrant work.

BS: that is the document from acme.

SF: there is a problem that doesnt know how to solve.

BS: no it has specific solution for node id validation

SF: okay reviewed and wasn't convincing.

BS: based on feedback for ACME it is experimental.

SF: recolation was ack'd existing of no domain validation. if you want
to figure something ebtter it should be here. as you have better idea.

BM: info for pki; ICAO has plans in development for international scale
pki for all memberstates (179). many orgs will be part of this for
aviation components. recommend looking at that pki and leverage it as it
is roled out.

BS: why using exisiting is to not reinvent.

cEB: now have a short other topic; in 5-6 mins?

Expected CLA Services (Brian Sipos - added with Bash)

• generic abstract definition of cla interaction in bp

• results in different terms, configs between two

  • lack of interop and understanding

• Not on the wire; but semantics

• Makes difficult for nodes to swap things out
• Logical definition, not API
• No changes to CLA or definitions but a harmonized definition of what
  is happening

RT: great work. missing for wg. will give review in spare moment. helps
guide wg for work in forwarding (selecting cla). understanding that
helps that.

BS: appendix a is discrepencies. mostly open ended for implementors but
lose interop. be aware, careful and negotiate

BS: feedback and contributions are welcome. not asking for adoption as
of yet.

cEB: please start a thread on the list.

cRT: wg this is handy get involved.

DTN Management Architecture (Sarah Heiner, 25 min)

• Check out -03 as it is most up to date

• Renamed Async to DTN

  • better fits

• Support async behaviour, autonomy and self-managment, compact
  encodings by naming structs

• DTN is a constrianed network and refined to say is challenged
  network

  • Handles compact encodings and async

• Looked at existing network mgmt work

  • SNMP, NETCONF - well structured was good

    • low latency is not guarenteed

  • RESTCONF - stateless

    • requires HTTPS and large data transfer

  • CORECONF/CoAP - great for encoding

    • Transfer with YANG and no autonomy

• Very oversimplied view for diagram

  • DTNMA fits between intersection
  • Exisitng good work in all circles but nothing in intersection

• Following feedback changed DTNMA reference model

  • Too generic originally

• Main points

  • For self-managements

  • Pre-Shared Definitions

    • Mst take advtage of the breif connectivity points

  • Agent Self-Management

    • Autonomy, disconnected and act on policy for managing device

  • Command-Based Mgmt

    • C2 interface, to get policy

• Pre-shared Definition

  • realtime data negotation is not guarenteed
  • must preshare

• Managing Device

  • on top is apps and source of policy informing autonomy

    • target of reports
    • open loop control

  • DTNMA manager interface btween apps and services and the DTNMA
    agent

    • policy stmts -> translate for agent to understand (rules)
    • rcv reporting and give back to apps that need it
    • keeping track of things

• Managed Device

  • applications

RT: applications on managemed device. but also on managening device.
same text in both places or are they are different groups?

SH: different

AJ Beal: transport control, verification of delivery?

SH: async mgmnt protocol proposed to send control, valuable is approach
that the underlaying transport is flexible.

AJB: thinking of tcp addressing all acks

cRT: answer is held elsewhere. trying to separate from protocol spec.
ignoring what running over; not how. you mut choose one that gives the
proper attributes.

AJB: thanks that helps

cEB: when policy is sent; what is the ack that is sent? considered at
transport layer. in open loop one policy action is to produce something
as update to system. lots of ways mngr gets items back.

• DTNMA Agent

  • interfaces with apps/services

• autonomy

  • how does agent handle data it is sampling?

  • rule db is local to db

    • IF ... THEN ... rules

  • could do

    • application control
    • change of defintions
    • report to manager

cRT: thank you. good work and lots of people behind the scenes. having a
framework in general and not caught in encodings. pleae wg review and
its clever.

AM: great read; very informative. 1) why only BPv7? (?)

EB: users of model not using BPv6 or 7. Do not specify?

AM: comment; great use-cases. No challenged segments of network how do
you envisioning working on segments no challeged.

SH: want to deveope that is robust for our challenges but still be
usable and strength of other segments.

cEB: serval ietfs was aw netconf to amp bridge; please look for it.
otherwise send me an email.

cRT: an app could have upstream management bridges.

AM: in case of disconnect agent may store reports or rely on underlying
tranports. was expecting to use BP or rely on it.

SH: concern on reliance on store and forward.

AM: its tha the agent may store or rely on TP - document tends to imply
S&F is part of TL.

cEB: some instances of use over BP but if there can provide.

SH: thanks for clsoe read of use cases.

cEB: udpate ot original AMA doc and wish to finish it. please read and
provide comments to mailing list.

IPv6 Support for DTN - Demo (Scott Johnson, 10 min)

• jpl implmenetation and ion (inlcuding tcls)
  • ltp, udp, and tcp CLs
  • updates to support ipv6

cEB: thank you!

cRT: i am going to answer your question. we should support both! thanks
for the demo. enjoy the hurricane!

SJ: it is built for these things,

KF: been a long time. back in the day. CLA and FIB at the node the
vision was the next hop could be email or bike with usb or write message
on wall and someone copies it. HAs there been progress for other areas.

cRT: this is ambition as CLs. A CL is not rigidly an IP system. Reindeer
is ruled out?

SJ: there is an IPNSIG member that completed running code for URAT
adapter. connecting to LoRA

cRT: different between bits on wire using IP and higher layer. serialize
a bundle and give it a thing that moves it.

SB: LoRA not native TCP/IP. other CLAs not based on IP is what we can
do!

Open Mic (15 mins)