Minutes IETF113: 6lo
minutes-113-6lo-01

  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