Minutes IETF110: roll
minutes-110-roll-00

IETF110 online meeting - ROLL session

Thursday, 11th March 2021 - 14:30-15:30 UTC (Thursday Session II)
Material: https://datatracker.ietf.org/meeting/110/session/roll
Bluesheet/Attendees:

    NOT NEEDED, attendance is recorded in Meetecho

Agenda (times in UTC)

    [14:30-14:38] WG Status (Ines/Dominique, 8 mn -> 10 mn)
    [14:38-14:53] draft-ietf-roll-dao-projection (Pascal, 15 mn -> 20 mn)
    - [14:53-15:13] RFC6550bis status (Michael, 20 mn)
    [15:13-15:21] draft-ietf-roll-enrollment-priority (Michael, 8 mn -> 10 mn)
    [15:21-15:29] draft-ietf-roll-mopex (Rahul, 8mn -> 10 mn)
    [15:29-15:30] Open Floor (as time permits)

[14:30] WG Status (Ines/Dominique)

    note well, scribes
    since IETF109, 4 drafts now in RFC Ed Queue, 1 submitted to IESG
    milestones will need updating
    tickets in tracker and mostly on GitHub

[14:33] draft-ietf-roll-dao-projection (Pascal)

    since last IETF, simplified mechanism. Tries to make everything look
    similar. now, the root of projected DAO is the track ingress skeleton (main
    DODAG or Track) is non-storing, can be made loose with storing mode
    segments inserted can be used by WiSUN free bit in HbH header used to
    signal that packet is on project route new projected RPI 6LoRH simplified
    rules for P-DAO construction P-DAO is DAO that signals full track, using
    VIO instead of TIO UseOfRPLInfo applies unchanged local root will copy
    SR-VIO in 6LoRH unchanged 6 profiles Profile 1 (the original):
        hybrid storing / non-storing mode.
        Use up the amount of store available in the nodes, but no more.
        Bridge the “gaps” with loose hops.
    Profile 2 (expressing the segments as non-storing mode)
        implies re-encapsulation
    Profiles 3-6 do shortcuts
    needs feedback from the group on the topics listed
    Iliar: could a P-DAO be sent to all nodes, not just the egress
    Pascal: can discuss the use cases on the ML

[15:12] draft-ietf-roll-enrollment-priority (Michael)

    decided at Jan interim to merge two drafts, this version is the result
    exp/mantissa representation of DODAG size
    discussion on ML on what is being measured
        number of routes, not number of nodes
    Pascal: in storing mode, root will only know number of final (currentl
    active) destinations Pascal: a same node may have multiple addresses
    experiment needed whole draft to be made experimental? Pascal: WiSUN needs
    this information. Luckily, they have one address per node. MCR: would love
    to hear feedback from them

[15:22] draft-ietf-roll-capabilities-07 and draft-ietf-roll-mopex (Rahul)

    capabilities draft updated after the previous meeting

    use cases descvribed in doc, e.g., root want to known what a node is
    acapable of

    one cap is routing resource available in node

    new capability options, with TLVs in it

    needs feedback from WG on …

    MOP extension

    draft describes how to handle all MOP values/cominations

    how about backward compatibility: by extending RPL Control Options with new
    flags

    flags describe node behaviour if option unknown

    took inspiration from CoAP

    Pascal: how about a bit combination to specify “dont join at all”, e.g. if
    option says “must compress” and node does not know.

    Lets prioritize MOPex over capabilities, since it is a precusor.

[15:33]
Summary of action points

Feedback required for draft presented today