Babel Status PagesBabel routing protocol (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2016-Jun-17 —Chairs:
IETF-104 babel minutes
Session 2019-03-28 0900-1030: Athens/Barcelona - Audio stream - babel chatroom
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.