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.