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
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
Background
Specific encodings for two BP versions out in the wild
node-nbr is unique where service exists
Problems
One IANA registery for node-nbr: CBHE
Implied behaviour
Single flat numbering space
Early allocation uses less octets
Low numbers are not reserved
Solutions
Renamed CBHE registry for clarity
Reserved low numbers for private use
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
Value 0 of node-nbr MUST NOT be used except part of ipn:0.0
Great than 2^64 for node-nbr must not be used. Changes CBOR
encodings.
All ipn for endpoints co-located must share the same node-nbr
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.
take private/experimental use to list
Number Authorities
could put an extra number in front of node-nbr; this is a
Numbering Authority
can hand out precious low numbers for use in your network and
still be unique
Advantages
How to detect?
backwards as optional
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?
cEB: please WG read and give some comments. Don't hear in the next few
months it will advance to next step.
BP already has default sec ctx
larger networks and envisioned networks need pki sec
reuse exisiting stuff
Interop profile
Get BPSec to work with existing PKI tools and systems
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?
results in different terms, configs between two
Not on the wire; but semantics
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.
Renamed Async to DTN
Support async behaviour, autonomy and self-managment, compact
encodings by naming structs
DTN is a constrianed network and refined to say is challenged
network
Looked at existing network mgmt work
SNMP, NETCONF - well structured was good
RESTCONF - stateless
CORECONF/CoAP - great for encoding
Very oversimplied view for diagram
Following feedback changed DTNMA reference model
Main points
Pre-Shared Definitions
Agent Self-Management
Command-Based Mgmt
Pre-shared Definition
Managing Device
on top is apps and source of policy informing autonomy
DTNMA manager interface btween apps and services and the DTNMA
agent
Managed Device
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
autonomy
rule db is local to db
could do
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.
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!