6lo WG Agenda - IETF 113, Vienna (hybrid) 09:00-11:00 (UTC) @ Park Suite 8 10:00-12:00 (local time) @ Park Suite 8 Wednesday, March 23, 2022 Chairs: Shwetha Bhandari, Carles Gomez Responsible AD: Erik Kline Minute takers: Adnan Rashid, Dominique Barthel, Michael Richardson Jabber scribe: Michael Richardson Agenda Introduction and draft status Bhandari/Gomez 10 min Agenda bashing; blue sheets; scribe; Jabber scribe Chairs’ introduction (slides-113-6lo-chairs-introduction) https://datatracker.ietf.org/doc/slides-113-6lo-chairs-introduction/ (Note for meetecho: These slides did not render correctly) Paolo Volpato 10 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-plc-10 IPv6 over PLC (slides-113-6lo-ipv6-over-plc) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-ipv6-over-plc-00 IPv6 ND Multicast Address Listener Registration Pascal Thubert 40 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-04 draft-ietf-6lo-multicast-registration (slides-113-6lo-draft-ietf-6lo-multicast-registration) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-draft-ietf-6lo-multicast-registration-00 IPv6 ND Unicast Lookup https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup-01 draft-thubert-6lo-unicast-lookup PDF (slides-113-6lo-draft-thubert-6lo-unicast-lookup-pdf) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-draft-thubert-6lo-unicast-lookup-pdf-00 Potential use of 6LoWPAN ND outside IoT domain https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling draft-thubert-bess-secure-evpn-mac-signaling PDF (slides-113-6lo-draft-thubert-bess-secure-evpn-mac-signaling-pdf) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-draft-thubert-bess-secure-evpn-mac-signaling-pdf-00 Prefix registration: applications, impact vs RFC 8505 (no related draft) Announcing Prefixes (slides-113-6lo-announcing-prefixes) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-announcing-prefixes-00 Transmission of SCHC-compressed Packets over IEEE 802.15.4 Carles Gomez 20 min https://datatracker.ietf.org/doc/html/draft-gomez-6lo-schc-15dot4-02 SCHC header compression over IEEE 802.15.4 (slides-113-6lo-schc-header-compression-over-ieee-802154) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-schc-header-compression-over-ieee-802154-00 Native Short Address for LLN Expansion Luigi Iannone 15 min https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-02 Native Short Addresses Update (slides-113-6lo-native-short-addresses-update) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-native-short-addresses-update-00 Native Short Address for LLN Expansion (demo) Guangpeng Li 5 min https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-02 Native Short Address for LLN Expansion (demo) (slides-113-6lo-native-short-address-for-lln-expansion-demo) https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-native-short-address-for-lln-expansion-demo-00 WG meeting minutes (Time in CET) [10:01] Introduction and draft status (Bhandari/Gomez) [10min] Note Well is presented Agenda bashing; blue sheets; scribe; Jabber scribe No comment on the agenda. Chairs’ introduction new since last IETF meeting: RFC9159 IPv6 over NFC: Erik will discuss with Lars, consider bringing it back to telechat. Issue with access to L2 spec. IPv6 over PLC: both DISCUSS’es have been cleared hours before the meeting, slide not longer accurate. Still comments remaining. Erik: please authors introduce in -11 whatever response to comments you can, before sending to RFC Editor [10:11] Status update of IPv6 over PLC (Paolo Volpato) [10 min] Paolo not an author, presenting on their behalf. recent developments have obsoloted some content of these slides (DISCUSSes cleared) draft now in -10. draft received 3 DISCUSSes, first one addressed and cleared by -09 goes through Benjamin’s Roman’s and Dave’s coments, and responses to them. Carles: as per Erik’s earlier comment, authors may want to consider comments in Benjamin’s last meeting before the doc proceeds further. Erik: works for me [10:21] IPv6 ND Multicast Address Listener Registration (Pascal Thubert) [40 min overall] this draft expands 6LoWPAN ND for multicast goes through changes since IETF112 during IETF112, addressed legacy anycast support, repurposed existing field for that. question to the group: is anything missing, needed changing, before going to ROLL? [MCR: suggests 6lo WG chairs do a consensus call on this topic] Carles: volunteers to review the draft at this stage? Carles: will ask on the list later Pascal: WiSUN (RPL+6LoWPAN) will publish review on the list Carsten: Has anyone looked how this covers constrained cast? Pascal: not yet. We can work offline on that Carsten: welcome [10:29] IPv6 ND Unicast Lookup (Pascal Thubert) use the registration on the BBR side as well this doc proposes to place the 6LBR on the backbone this draft is individual submission, but stable. Do we adopt or drop? Carsten: given we now do 6LoWPAN signalling on the backbone side, is that useful for other (non-constrained) nodes?? Pascal: Carsten: this is a soft entry to efficient ND Pascal: this is an evolution of efficient ND. Carsten: I’m not against adoption at all. Pascal: was presented at 6man, little interest. Pascal: let’s do the work here, and get validation from 6man when done. 6LBR is collection of info of all 6BBRs [10:38]Potential use of 6LoWPAN ND outside IoT domain (Pascal Thubert) slides not written for this audience for DHCP, you might think IPv4 and IPv6 are similar, they are not. SLAAC: you don’t know when addresses are no longer used, when they are created. Issue for injecting in BGP. Now IPv6 ND is stateful, state of the address synchronized with the network. Lifetime negociated, redistribution explicitely request. this draft extends signalling to expose ROVR, … RFC8928 info injected into BGP. Erik Nordmark asked for clarification about how the network would know when hosts have gone away. Answer: hosts propose a lifetime, and need to renew during that lifetime. Hosts can de-registrer with a lifetime = 0. [10:44] Prefix registration: applications, impact vs RFC 8505 (Pascal Thubert) we know to redistribute host addresses (RUL), this work is about redistributing prefixes use cases: network in node, private IPv4 realms. in RPL, know to advertize prefix, but RUL only address. Need for equivalent for prefix. what about DAD? can be real duplicate (exact match), but also result from aggregation Draft is not written yet. Proposal is to do with RS what we did with NS. Assuming stub, no risk of loop. Shwetha: how do the use case fits in the 6lo charter? Pascal: IoT network (could be IPv4, could be any routing protocol) exposed to the RPL network through gateway. Pascal: gateway has an IP address for each node below, whether the network is IP or not. Michael: ANIMA’s ACP already injecting prefixes into ACP RPL. The NOC could have some structure. This extend prefix allocation would be very useful to ANIMA. Michael: responing to Swetha’s point, might be that this work doesn’t belong to 6lo, but is is based on 6lo’s documents. Pascal: no other home. Hoping this work can be done here, where the expertise lies. Carsten: prefix B vs. prefix A.? Pascal: explained that how the prefix works in the topology. A and B are unrelated. B forms A::B using SLAAC out of of A::/ owned and advertised by A IPR on these topics Pascal: go/no-go feedback? Luigi: metrics to do load balancing. Maybe overlap/connection with other solutions. Work interesteing anyway Carsten: prefix A and B again Pascal: different prefixes, unrelated. Then congregate (like a MANET of cars). Carsten: nodes in A cannot address any node in B Pascal: without RPL, they indeed can’t. With RPL, they can. Carsten: this is RPL used for transit network Pascal: not transit is not connected to anything Carsten: A is transit network to B. Carsten: looking forward to the draft, this makes no sense to me. Pascal: this will not be in the draft. Can discuss this slide, maybe on the ML. Pascal: See this as RFC9010, but for external destination that is not host. Guangpeng: does this mean encapsulation at the root? Pascal: If you are dealing with non-storing mode, then yes RFC9008 will apply and perform the encapsulation. RFC 9008 applies for external destination and RUL is when they are hosts. This generalizes it. Carles: it may be good to further confirm on the ML, but it appears that there is interest in this work. Carles: was useful to clarify that this work fits the 6lo WG’s charter though it has broader applicability. [11:19] Transmission of SCHC-compressed Packets over IEEE 802.15.4 (Carles Gomez) 20 min Carles: RFC6282 compressed IPv6/UDP header into 7 bytes with global addresses (best case). SCHC specified at LPWAN WG. Used to compress CoAP/UDP/IPv6. no 6LoWPAN compression of CoAP header. smaller headers result in lower battery consumption. this draft describes use of SCHC over IEEE 15.4 SCHC uses Dev and App to designate source/destination addresses/ports, assuming node knows its role of “device” and “network side”, because star topology. could happen in 15.4 that star topology is known. but peer-to-peer relationship needs to be addressed. Each endpoint needs to know if it is Dev or App in its communnication with any other node. Also “uplink” and “downlink” a priori knowledge of SCHC needs to be addressed. This version tries to stick with Dev and App, no longer trying to define new SCHC concepts like source and destination, sender and receiver, and the like. Carsten: since you need to install context in the nodes, can’t you establish roles at the same time? Carles: right. Deciding about roles needs to be done at the same time context is established. Carsten: is sharing of rule sets considered (if communicating with multiple node?) Carles: coming in next slide Carles: AppIID (defined in SCHC) now used. when several hops between source and destination, quite challenging to use this with route-over. Carles asking for adoption Carsten: this work is very interesting. As an author, do another one or two rounds. Make sure it’s complete before asking for adoption. Carsten (in the chat) You may want to force VRB (RFC 8930) [11:40] Native Short Address for LLN Expansion (Luigi Iannone ) 15 min goes through changes since IETF112 applicability mostly in static deployment, otherwise, need to renumber. next: will try to evaluate gain with this approach; will respond to latest comments. then will consider asking for adoption Carles: draft states applicability for static deployment of wired technologies. PLC? Luigi: some others, will do literature review Guangpeng: PLC, also APL (Advanced Physical Layer) which is extension of IEEE 802.3cg Carles: is this technology for constrained devices? Guangpeng: used in industrial equipment Peng Liu: support this work [11:50] Native Short Address for LLN Expansion (demo) (Guangpeng Li) 5 min goes over address allocation function, one page of code for implementation simulation generates topology, then assigns addresses. Parameters are depth and max number of children. 4 x 4 example shows addresses of up to 6 bits in length live demo 4x4 example: max address length is 6 bits. Pascal: can see how this can be useful in wired harness to save copper of star topology. But concerned about tree, not enough to build redundancy. Guangpeng: not a tree, a meshed graph Pascal: but routing goes along the tree, unless you have a routing protocol. Pascal: would need multiple trees, multiple addresses per node, for redundancy Guangpeng: scenario is dedicated topology Pascal: if a node breaks, subtree is lost. Pascal: safety use cases requires redundancy Pascal: suggest working on two trees, two addresses and non-congruent paths. [12:04] meeting is over Chat Michael Richardson @meetecho, the slides have the rendering in the middle problem for 6lo.14:20:49 what should we do?14:21:01 Meetecho What slide deck was this?14:21:32 We’ll try reconverting it14:21:38 Michael Richardson intro, I think.14:22:39 Meetecho I think it’s a problem with PDFs thathave some rotation settings14:23:04 Michael Richardson I think it still fails.14:23:16 Meetecho It looks like the target resolution is rotated, which explains why it looks like portrait instead of landscapes14:23:35 We’ll need time to investigate, so please use the screen sharing functionality for the slides that have this issue14:23:51 Michael Richardson Shwetha you’ll need to share your PDF.14:23:56 MichaelRichardson Do you want me to share the PDF?14:27:48 Carsten Bormann Has anyone looked how this covers ccast?14:57:58 16 bits in minutes15:13:37 topological addressing?15:18:23 MichaelRichardson could be done… next presentation right :-)15:24:14 Carsten Bormann I have no idea how A and B relate – is B a subprefix of A?15:25:31 (It will RFC8138-encapsulate, that is.)15:48:53 Guangpeng Li Clear. Thanks.15:49:52 Carsten Bormann You have to install rules anyway, can’t you make the determination at the same time?16:01:17 Answer: of course!16:06:44 You may want to force VRB16:07:23 (RFC 8930)16:09:08 Wrong slides16:10:32 Guangpeng Li IEEE 802.3cg16:19:40 Carles Gomez thanks for the details