Skip to main content

Minutes IETF105: 6lo
minutes-105-6lo-00

Meeting Minutes IPv6 over Networks of Resource-constrained Nodes (6lo) WG
Title Minutes IETF105: 6lo
State Active
Other versions plain text
Last updated 2019-07-31

minutes-105-6lo-00
     6lo WG Agenda - IETF 105, Montreal
      13:30-15:30 @Sainte-Catherine
      Monday, July 22, 2019

      Chairs: Shwetha Bhandari, Carles Gomez
      Responsible AD: Suresh Krishnan

      Minute takers: Dominique Barthel
      Jabber scribe: Shwetha Bhandari

      Meetecho for remote participants: https://www.meetecho.com/ietf105/6lo
      Etherpad for notes:              
      https://etherpad.ietf.org/p/notes-ietf-105-6lo?useMonospaceFont=true

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

  Introduction and draft status                                Bhandari/Gomez  
           10 min Agenda bashing; blue sheets; scribe; Jabber scribe

  Revisions after IESG evaluation: IPv6 over NFC               Younghwan Choi  
           10 min
    https://tools.ietf.org/html/draft-ietf-6lo-nfc-15

  Status of Fragmentation drafts                               Pascal Thubert  
           10 min
    https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-02
    https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-04

  Status and next steps of Applicability and Use Cases draft   Yong-Geun Hong  
            5 min
    https://tools.ietf.org/html/draft-ietf-6lo-use-cases-06

   Presentation of proposed maintenance scheme for RFC 8505     Pascal Thubert 
             15 min
    https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-03

   ND Unicast Lookup - Assess interest in 6lo                   Pascal Thubert 
             15 min
    https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup-00

  Initial version of new HC (Asymmetric IPv6 for IoT Networks) Brian Carpenter 
           20 min
    https://tools.ietf.org/html/draft-jiang-asymmetric-ipv6-00

 Revisions after IESG evaluation: deadline time               Charlie Perkins  
          10 min
    https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-05

Total: 95 min

  --------------------------------------------------------------
Meeting notes

[13:32]
  Introduction and draft status                                Bhandari/Gomez  
           10 min Note takers Jabber scribe: N/A Note Well Agenda bashing: some
  presentations re-ordered. Added 5 minutes to Pascal's ND presentations. No
  comment. blue sheets

  Status report
    * -deadline and -nfc in IESG processing
    * -ap-nd submitted but not evaluated by the IESG yet
    * -fragment-recovery and -minimal-fragment: shepherd review done, new draft
    versions issued today, which address shepherd comments * -ipv6-over-plc, no
    update since last IETF, news? Author, on the mic: will update after this
    meeting and come back to the mailing list

[13:41]
  Revisions after IESG evaluation: IPv6 over NFC               Younghwan Choi  
           10 min
    https://tools.ietf.org/html/draft-ietf-6lo-nfc-15
  goes through history of the draft.
  as a response to IESG reviews
    * removed "marketing" language
    * MAY, MUST language
    * improved some figures.
    * Security section reshuffled, improved, some text removed

[13:45]
  Status of Fragmentation drafts                               Pascal Thubert  
           10 min
    https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-02
    https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-04
  overview of fragmentation work done in the past and present at 6LoWPAN, 6lo.
  how to forward the fragments over multiple hops without reassembling them at
  each hop. -minimal does not change the fragmentation format, just the
  buffering in intermediary nodes drawback is if fragments are lost, the whole
  process stalls. with -fragment-recovery, retries. describes changes on
  -minimal after reviews. Clarified that routing is only done of first
  fragment, next fragments are labelled -fragment-recovery has bitmap, one bit
  per fragment. This draft extends -minimal. (used to stay "update", now
  "extends"). Added IANA section Suresh: "update tag" is an issue all over the
  IETF. Writing a draft right now to better define this. Suresh: draft will be
  out in the next days. Use it to explain your update. Pascal:
  -fragment-recovery is self sufficient, that's why we believe it extends.

[13:57]
  Status and next steps of Applicability and Use Cases draft   Yong-Geun Hong  
            5 min
    https://tools.ietf.org/html/draft-ietf-6lo-use-cases-06
  Draft not updated since last meeting. However, still willing to do so.
  Goes through expected next steps.
  - scope, consistency
  - technologies considered: add 15.4e?
  - remove Section 5.1
  Pascal: 15.4e is now fully merged into 15.4. No reason to mention 15.4e
  anymore Pascal: 15.4g Carles (as a co-author): question of 6lo technologies
  is tricky. 15.4e wrapped into 15.4, but we don't mean to address all 15.4
  technologies. Shwetha: how do you want to progress from here? Yong-Geun: work
  with co-authors, then ask WG feedback, then LC.

[14:04]
  Presentation of proposed maintenance scheme for RFC 8505     Pascal Thubert  
           15 min
    https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-03
  Was elaborated based on work done here, but draft submitted at 6man.
  Gives overview.
  RFC6775 is about registering an address. 8505 describes association.
  Need for protecting against an attacker registering the same address, and
  claim the traffic. Backbone router does ND proxy for registration process.
  Analoguous to WiFi bridging in ESS (multiple APs) Address protection draft
  (-ap-nd) is homologuous to SeND (Secure ND). Protects the ownership of the
  address, at the router. Provides Source Address Validation, proving the
  ownership with the possession of a crypto token. This all basically rebuilds
  an ESS at layer 3. -unicast-lookup extends the DAD onto the backbone. Any
  node can query the Map resolver. This is on the wire. This draft could go to
  6man. Will be presented at 6man tomorrow as well. -6man-ipv6-over-wireless is
  destined at 6man, to show them the whole story. Draft explains need for
  upgrading ND. Links are nore subnets. Subnets of thousands of devices. Need
  to avoid broadcast on those large fabrics. Explains the drawbacks of
  broadcast. PHY behaves differently when broadcasting. Fast Roaming (.11r):
  reports may arrive out of order, resulting in wrong location determination
  Fast Intial Link Setup (.11ai) prepopulates entry on DAD request. Link with
  radios? when node A is in broadcast domain of B and B is in braodcast domain
  of A. Even RFC8200 is not clear on wireless links. Hub&Spoke subnet model:
  central router does DAD and lookup and 1-hop forwarding. Mesh subnet: 6775
  does DAD, routing with RPL. Heterogeneous multilink subnet: e.g. WiFi
  (hub&spoke on one side and 6TiSCH (mesh) on the other side. Shwetha: what do
  you need from this group? Pascal: general approval, then maintenance at 6man.
  Shwetha: implication on other drafts at 6lo? Pascal: generalisation to
  multiple interface Suresh (as contributor): hard to address is backward
  compatibilty. For those who use 6775 now. Suresh: maintenance of draft
  published in 6lo stays in 6lo. Will be taken into consideration before
  closing 6lo WG. Suresh: 6lo looks at the "constrained nodes cluster" aspects,
  and 6man will look at it with another perspective (operational, etc) Samita:
  agree with Suresh. You will have easier time in 6lo. Pascal: but if want to
  extend it to different links, will have to go to 6man.

[14:40]
  ND Unicast Lookup - Assess interest in 6lo                   Pascal Thubert  
           15 min
    https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup-00
  It's about scaling the backbone infrastructure.
  ND causes broadcast storms, which is a problem even on wired backbone.
  Key problem is to know where each IP address is. Time to do it right, with a
  registration protocol and centralised info. Map server talks LISP, hosts
  don't. The more nodes do registration and lookup, the less broadcasts on the
  network. Adding a 6LBR on the backbone to share address registration. 6lo
  method applied to wired network. Goes through message exchange diagram. First
  multicast goes to AP, which does not broadcast is back, goes straight to L3.
  In mixed environment (with registered nodes and no-registered nodes), still
  need to do DAD after lookup. Involves extendeing the DAR/DAC because now
  occurs between BBR and 6LBR. Shwetha: where do you want this work to happen?
  Pascal: anywhere as long as it moves forward. Will be presented at 6man, in
  much shorter form.

[14:50]
  Initial version of new HC (Asymmetric IPv6 for IoT Networks) Brian Carpenter 
           20 min
    https://tools.ietf.org/html/draft-jiang-asymmetric-ipv6-00
  Brian goes through rationale for this work: constrained links, and
  memory-constrained edge routers. Want ot avoid compression/decompression
  algorithms (because of CPU cyles and memory requirement). Suggests using
  shorter addresses. Compatibility with other mechanisms to be evaluated.
  "flexible header encoding" means headers have variable size. Address length
  could be preconfigured, or configured by router, of even negociated between
  peer node. RA-PIO modification proposal to tell address length. Language in
  the draft needs to be made more specific and accurate. Proposes to use a new
  dispatch value in 6LoWPAN, or new flexible header (starting with FHE octet)
  Laurent Toutain: SCHC compression mechanism at LPWAN, need to talk together.
  Suresh: mis-alignement. Isn't that a problem in C implementation? Come to
  side discussion at Notre-Dame room on Wedn 8:30 Guangpeng Li (co-author): use
  case with supermarket <<??>>. SCHC and 6LoWPAN require
  compression/decompression. Brian: reckon use-cases need to be better defined
  in draft. Pascal: this is the right place for this work. Years of experience.
  Pascal: also look at RFC8138. Same kind of processing. Don't reject other
  people's work just because it's "compression". Pascal: source routing header
  also needs address compression. Pascal: don't see what you need that current
  work doesn't already do. Pascal: "adaptation layer" vs "compression" is
  fallacy. Carles (as a participant): evaluated benefit of avoiding
  compression/decompression? Sheng Jiang: 6LoWPAN does
  compression/decompression at every hop. Want to go through whole domain
  without decompression. Pascal: this is behavior, not format. So far,
  presentation has shown format. Pascal: with 8138, we can process the packets
  in the compressed format. What you require is already possible Sheng: could
  agree. But 6LoWPAN framework is complicated. This could be said to be a
  simplified 6LoWPAN. We care that nodes can do this in a simple way. Pascal:
  could have a simpler behavior, or subset of behavior, without changing the
  format. Look at 8138, as a starting point. Guangpeng: assume address length
  can be configured at deploment Shwetha: please provide a section in the draft
  that compares with what already exists Suresh (as AD): rationale, use-case,
  comparison. This need to be all in the draft.

[15:16]
  Revisions after IESG evaluation: deadline time               Charlie Perkins
  (remote)       10 min
    https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-05
  Reminds of the purpose of the draft, history.
  Current status is 3 DISCUSS in IESG review, 1 YES, 8 NO_OBJECTIONS.
  Suresh: haven't seen your response to Alissa's DISCUSS. If you provided by
  mail or in draft change, indicate what/where are the changes related to her
  comments. Charlie: will check and provide info. Charlie goes through draft
  updates, describes format Carsten: this slides says OTL where it should say
  OTD. Charlie: will check that. Chairs: any comments? No comments in the room.
  Chairs: we expect to see your response to Alissa, and take it from there.

[15:29] Meeting adjourns