Hilton Prague, Prague, Czech Republic
                   Thursday, 28 March
          2019
                   09:00-10:30, Athens/Barcelona Room
          Chairs:  Russ
          White (LinkedIn) [not present]
                   Donald Eastlake (Huawei)
          
          Area Director: Martin Vigoureux (Nokia) [on jabber /
          Meetecho]
          Notes: Barbara Stark (with help)
          Jabber: David Schinazi
          
          ======================================================
          Minutes
          ======================================================
          Administrativia
          (scribes), Agenda Bashing, Chairs
          Status, Milestones, Chairs
          https://datatracker.ietf.org/meeting/104/materials/slides-104-babel-agenda-and-status-03
              Donald presented the chair slides.
          Work is progressing
          nicely.
          ======================================================
          Recent
          Changes to Babel-HMAC, Juliusz Chroboczek
          draft-ietf-babel-hmac-04
          https://datatracker.ietf.org/meeting/104/materials/slides-104-babel-recent-changes-to-babel-hmac-00
              Juliusz Chroboczek presented the slides.
          Mikael: There is
          no requirement for devices to agree on time?
          Juliusz: No. We have
          simple requirements.
          Donald: <made a comment>
          Donald: No other
          questions?
          ======================================================
          RTT-based routing for the Babel routing protocol,
          Julius Chroboczek
          draft-jonglez-babel-rtt-extension-02
          https://datatracker.ietf.org/meeting/104/materials/slides-104-babel-rtt-based-routing-for-the-babel-routing-protocol-00
              Juliusz presented the slides.
          --
          slide 6
          Mickael: it's a 32-bit
          counter that counts microseconds?  The
          wraparound time you gave was
          wrong.
          Juliusz: that's right, the counter wraps every hour or so.
          The
          protocol assumes we get at least one hello every hour.
          Mickael:
          indeed, that's no problem.
          --
          slide 14
          Christian Franke: are you
          relying on latency increasing with load?
          What if the routers are properly
          debloated?
          Juliusz: then you don't have the problem we're trying to
          work around.
          Mikael: He's also talking about running over tunnels. I
          think you're
          looking at a really course model.
          Juliusz: In practice,
          you're going to have plenty of throughput. This
          oscillating won't happen
          in practice.
          Mikael: I had to do a lot of buffer debloating in some
          different iperf
          tests I ran. This can be a real problem.
          Juliusz:
          what we're doing here is avoiding a catastrophic failure when
          your
          network is not running fine.  If your network is running fine,
          then the
          problem doesn't occur.
          --
          slide 15
          Mikael: How often are Hello packets
          sent?
          Juliusz: Every 4 seconds.
          David Schinazi: I support this work
          and think it should happen
          here. The fact it is deployed tell us it
          works. Have you tried running
          this in babeld with hmac or dtls? How
          does that impact timing?
          Juliusz: It doesn't work with dtls. You need
          a Hello and without the
          timestamp, it won't work. With hmac it should
          work. That's a good
          experiment.
          David: It might be good to document.
          Juliusz: No, it's really about the implementation. With unicast Hello
          you can do DTLS.
          David: Could we say that?
          Juliusz: Not until we have
          done this.
          ======================================================
          Babel
          Information Model, Barbara Stark
          draft-ietf-babel-information-model-04
          https://datatracker.ietf.org/meeting/104/materials/slides-104-babel-babel-information-model-00
              Barbara Stark presented.
          
          Major changes -04 to -05
           asked
          for input on remaining issues:
          #1: Link Type registry
          Juliusz: There
          are many potential link property parameters. "Wired"
          and "wireless"
          links have a specific set of properties.
          Mikael Abrahamson: Instead of
          inferring properties from a single
          "type" parameter, why not model them
          individually?
          Juliusz: There is a choice between something that makes
          sense and
          something a user can understand.
          Barbara: So, we should not
          use "ethernet" as a type and change
          description of registered types to
          mention link properties of a type.
          <there was discussion>
          Barbara:
          We should change the registry perhaps to "Link Property
          Types", will
          use names for the registry elements that better evoke a
          collection of
          properties, and change the descriptions to talk some
          about the properties
          that encompass a type.
          #2: HMAC/DTLS interfaces modelling
          Juliusz:
          Question whether credential refers to interface or the other
          way round?
          <there was discussion>
          Barbara: We agree the reference direction should
          be from the interface
          object to the HMAC or DTLS object (that contains
          a set of
          credentials).
          <there was discussion about whether the HMAC
          Boolean for validating
          received packets should be global, per interface,
          or per set of
          credentials>
          Barbara: We agree the HMAC Boolean should be
          per interface. The
          parameter will be moved to the interfaces object.
          <there was discussion about whether DTLS parameters should be global,
          per interface, or per set of credentials>
          Barbara: This needs more
          discussion on the list.
          #3: Name for DTLS cert and HMAC key
          Keys and
          certificates need some unique "name" (this could be a hash of
          a key value
          or certificate). Agreed.
          #4 DTLS and HMAC object unique keys
          DTLS and
          HMAC objects (which are primarily just containers for sets of
          credentials)
          have no parameter defined in the info model that would
          allow an instance
          to be uniquely referenced (aka a unique key). There
          is no need for the
          info model to specify a unique key for these
          objects. Data models can
          specify their own unique keys according to
          how they work.
          
          #5 metric
          parameters
          JC: You want to have both the advertised and the computed
          metric; for
          debugging problems, you must have at least one but having
          both is
          desirable.
          #6: interface-reference
          Juliusz: I don't understand
          the issue.
          Juliusz: Babel runs over IPv6. You want the ability to
          reference the
          layer 3 objects. If we have access to layer 1 and 2 objects
          (e.g. wifi
          interface), we can use it, but what is fundamental is layer 3
          objects.
          Barbara: If you know your interface stack, what layer do you
          want to
          point to? Data models like YANG and BBF TR-181 have interface
          stacks. An interface can be physical (e.g., a Wi-Fi radio), link layer
          (e.g., an Ethernet MAC, which can be used by various Ethertypes),
          network layer (an IP interface). Would it make sense for a Babel
          interface to point to a physical interface?
          Juliusz: I need to know the
          link-local IPv6 address.
          Barbara: Then answer is that we need to limit
          the set of interfaces
          that can be pointed to, to IPv6 interfaces. The
          info model parameter
          description needs to change.
          Next steps:
          WGLC,
          need review
          ======================================================
          Babel YANG Model, Mahesh Jethanandani
          draft-mahesh-babel-yang-model-01
          https://datatracker.ietf.org/meeting/104/materials/slides-104-babel-babel-yang-model-00
              Mahesh Jethanandani presented.
          Issue #11
          David: You can have
          a valid implementation of Babel that is just a
          client on the edge,
          doesn't announce any route (so no router-id),
          which means the attribute
          is not mandatory.
          Barbara: So, you cannot use it as a key (to reference
          an object
          instance).
          Juliusz: Not so clear. Is it possible for the
          management interface to
          put constraints on the implementation? It is
          technically possible to
          have no router-id, but it is not a big cost
          to have one. I have a more
          general question: Does 'ro' (read-only)
          imply there must be a value?
          Mahesh: It is not enforceable. You can
          have it in the description and
          say "must provide" of course.
          David:
          The spec explicitly says router-id (sent in a Babel packet)
          cannot be
          all-zeroes. But an implementation could return that in
          response to a data
          model query.
          Mahesh: In which case the router-id wouldn't be unique.
          David: Those are just observer instances. You can merge them. It's
          fine not to distinguish them.
          Barbara: No, it's not okay.
          Juliusz:
          They can be neighbors.
          Barbara: This isn't about what is seen on the
          wire, but how to
          internally reference a running Babel executable. Can
          the router-id
          value be used as a key into the data? What I'm hearing,
          is it cannot.
          David: Okay, forget what I just said!
          Juliusz: The
          natural data structure used by babel says you only need a
          router-id
          if you originate routes. If the monitoring says "you need a
          router-id
          for every node even if you don't originate routes", then I'm
          fine with
          that. It doesn't cost much to generate 64 random bits.
          <no conclusion>
          
          Issues #13, #15
          no question
          Issue #16
          Mahesh: Help needed to create
          examples. I need real-looking data.
          Juliusz: What you're asking for
          is data from real implementations?
          Mahesh: That's fine, you give it
          to me, I'll do the translation into
          what is accepted by the data model
          and make sure the example makes
          sense.
          Barbara: So, doesn't have to
          be in the YANG syntax already?
          Juliusz: Including HMAC keys?
          Mahesh:
          That's right
          
          ======================================================
          
          Wrap-Up, Chairs
          Thanks. See you at Montreal. Please sign blue sheets.