6lo WG Agenda - IETF 103, Bangkok

                         16:10 -18:10 @Meeting2

                         Monday, Nov 5, 2018

                         Chairs: Gabriel Montenegro, Samita Chakrabarti

                         Responsible AD: Suresh Krishnan 

                         

                         Minute takers: Charlie Perkins and Dominique Barthel

 

                --------------------------------------------------------------

 

Summary

 

Agenda and Slides: https://datatracker.ietf.org/meeting/materials#6lo

 

Both co-chairs, Samita and Gabriel, have announced they are stepping down. Suresh is looking for replacements, so now's the time to volunteer.

 

draft-ietf-6lo-rfc6775-update is in AUTH 48.

draft-ietf-6lo-nfc in AD review stage and comments addressed.

draft-ietf-6lo-deadline-time addressed comments from AD review, Suresh to initiate IETF LC soon.

 

Reviewed latest comments and changes on several documents now preparing for or at WG LC:

-draft-ietf-6lo-backbone-router

-draft-ietf-6lo-ap-nd (will be subject to early security directorate review)

-draft-ietf-6lo-use-cases

 

One document ready for call for adoption: draft-hou-6lo-plc-05

 

We reviewed implementation experience on two drafts: draft-ietf-6lo-blemesh-02 (now ready for WG LC) and Fragment Forwarding performance.

 

Minutes

 

[16:19]   IPv6-over-NFC Final comments during AD review              Younghwan Choi

 

    Suresh: do you intend to publish -12 soon? in which case, wait for -12 to review.

    Younghwan reports on the IoTdir's reviews.

    no comments in the room

 

[16:26] 6775 extension series of 3 drafts (Pascal)

 

    first draft is draft-ietf-rfc6775-update [NOTE: After Bangkok published as RFC 8505]

 

        goal is to extend 6775 to be able to handle RPL-unaware leaves in a RPL network.

        gone through IANA steps, currently in RFC-EDITOR state.

 

    second draft is 6lo-ap-nd

 

        protects your address against other nodes. Prove ownership of crypto-token.

        assumes trust between 6LR and 6LBR (could be the same node).

        added René Struik as a co-author.

        token typically 256 or 512 bits, avoids compute-intensive processing.

        challenge can be sent from 6LR or 6LBR

        propagating trust with ROVR could be used in RPL.

        question to the WG: should we allow 64 bits ROVR or RECOMMEND larger sizes?

        anything else missing?

        Carsten: want to use SHA3

        Pascal: only mandated is NIST 512, nobody so far expressed need for other hash or curve.

        Charlie: neighbor cache in 6LR needs to maintain crypto for each 6LN

        Pascal: only during registration phase.

        Charlie: so 6LR don't need to be pre-configured with each of the 6LNs?

        Pascal: correct.

        Gabriel: this will get crypto/security experts review. How about showing this at SAAG meeting?

        Suresh: we can ask for early review. Will talk to Sec AD's.

        Gabriel: seems this is ready for WGLC, so seems like good time to request early review.

        Pascal: now that René has contributed, we feel confident that this is ready.

        Suresh: will go through Sec review anyway as part of IESG review, but can benefit from early review.

        Pascal: I don't expect much surprise, but on the trust assumption between 6LR and 6LBR. That's why proposing to propagate the trust all the way to the 6LBR with RPL.

        Gabriel: if RPL is the way to solve the issue, maybe this document should be in ROLL.

        Pascal: this is agnostic to RPL. In RPL or any routing protocol, we could be able to challenge all the way to the root.

 

    third draft is draft-ietf-6lo-backbone-router

 

        proxy operation between 6LoWPAN registration and the rest of the world

 

        Charlie joined as a co-author. Clean up and reorg. Is document ready for WGLC?

 

[16:53] 6LoWPAN packet delivery deadline: Comments discussion      Charlie Perkins

 

    uses routing header extension for carrying deadline time for reception. Also includes origination time.

    stable for several IETF meetings.

    got several reviews, including IoT Dir and shepherd.

    a few updates.

    think no remaining issues

    Suresh: will start the Last Call after this IETF meeting finishes.

 

[17:01] Transmission of IPv6 Packets over PLC Networks                   Remy Liubing

 

    comments received since Montreal

    comment 1: privacy issue associated with use of EUI-48 or -64 to form IPv6 IID.

    comment 2: terminology issues. Now aligned.

    comment 3: fragmentation. PLC has own fragmentation. But fragm in adaptation layer required xxx

    asking for WG adoption.

    Gabriel:

        who has read this draft? about 5 hands.

        interested in commenting on this draft? 5 hands 

        interested in implementing this? no hand

    Co-chairs will consult about adoption

 

[17:08] Performance report on 6lo-fragment-forwarding drafts        Rahul Jadav

 

    in route-over mesh networks, re-assembly at each hop and re-fragmentation for next hop.

    with fragment forwarding ("FF"), no reassembly at intermediate nodes.

    wanted to understand latency/PDR implications of FF, notably for use for EAP/PANA

    describes simulation setting

    Pascal: have you tried sending two big packets in a row?

    Rahul: one bulky packet at a time.

    Pascal: results would be much worse with two big packets in a row. Recommend to interleave fragments of two packets, to free first hop to forward.

    Rahul: indeed. More scenarios to be tested.

    Pascal: this is great work, eye-opener. Would love to see more cases.

    per hop reassembly has good PDR, FF with pacing achieves about same, but FF without pacing comes lower.

    however, pacing creates long latency.

    Peter: 

    MAC transmit failure high with FF no pacing.

    observation: in this scenario, per hop reassembly seems to be doing better both in terms of PDR and latency.

    Pascal: seems like your CA not well tuned, forwarding generates collisions between hidden nodes.

    Pascal: pacing should be randomized, you're using same value at each hop.

    Pascal: looks like bas results are due to L2 behavior.

    Rahul: but use same L2 for per-hop reassembly

    Pascal: but you're only sending one packet. If you sent two in a row, you would see the same interference effect.

    Carsten: FF increases concurrency in your network. If you network has problems with concurrency, then FF is not as good as expected.

    Fragment Forwarding is better with L2 RTS/CTS, for example

    Rahul conclusion: per-hop reassembly not as bad as it sounds.

    Thomas Watteyne: everything you're seeing is related to L2. Beware of conclusions. All depends on the MAC layer. What you're seeing is the effect of bursty traffic.

    Rahul: FF does generate this train of fragments.

    Thomas: conclusion is, if you're using 15.4, do not generate bursty traffic, one way or another.

 

[17:33] BLEmesh implementation Update                               Carles Gomez Montenegro

 

    document not modified since last IETF meeeting. Not aware of any change needed.

    implementation progressed. Using BLEach/Contiki

    Showing results achieved with CC2650-based boards. Static routing, a mesh protocol is needed

    Pascal: RPL/Contiki exists on these same boards, would be good to integrate.

    asking for WGLC

    Gabriel: did you learn anything relate to the spec when impementing?

    Carles: not found any issue.

    Gabriel: will consult with Samita and decide on WGLC.

    Pascal: do you foresee any impact of using a routing protocol? Why not wait for feedback of running RPL?

    Carles: in theory, cannot think of any potential issue.

    Pascal: would like to see any routing protocol work with this before shipping

    Lijo Thomas: is this code available?

    Carles: BLEach is open source. Plan is to provide this as open source, too, when stable,

         but not done yet.