BABEL Working Group IETF 105 Minutes Fairmont Queen Elizabeth Montreal Hotel, Montreal, Quebec Wednesday, 24 July 2019 15:50-16:50 Sainte-Catherine Room Chairs: Russ White (Juniper) Donald Eastlake (Futurewei) Jabber: David Schinazi Notes: Barbara Stark, Russ White Area Director: Martin Vigoureux (Nokia) [Times below are as orignally scheduled, not actual time taken] 5 min. Administrativia (scribes), Agenda Bashing, Chairs 5 min. Status, Milestones, Chairs 15 min. Babel Information Model, Barbara Stark draft-ietf-babel-informaton-model-06 10 min. YANG Data Model for Babel, Mahesh Jethanandani draft-ietf-babel-yang-model-02 15 min. Delay Based Metric Extension for Babel, Baptiste Jonglez draft-ietf-babel-rtt-extension-00 5 min. Wrap-Up, Chairs ========================== Status Update: Donald https://datatracker.ietf.org/meeting/105/materials/slides-105-babel-babel-05 ========================== Barbara Stark presents Babel Information Model Major changes 05-07 Juliusz Chroboczek on Jabber: Using negative numbers as NULL seems like a hack. Barbara: This is the way it is expressed in TR-181 [Broadband Forum Technical Report 181] Juliusz on Jabber: Is there precedent? Barbara: There is -- 15 years of them David : If there is precedent I'm fine with it Martin: During the review, comment was made there cannot be all 0's or 1's in the router ID -- this has changed to binary 0's and 1's Barbara: This is easy David: This change was made to be more clear 0x... rather than 0 -- look at what's in rfc6126bis Toke Høiland-Jørgensen on Jabber: Should the information model have a way to specify NULL, and leave the representaton of NULL to the implementation? Mahesh Jethanandani: I would be looking for a suggestion on how to encode those Barbara: You would want the data model to be more explicit? Mahesh: If people do not want the negative numbers, then they should propose a way to represent it Barbara: In TR-181, I provided [to the email list] the text that says NULL values for unsigned integers are modeled as -1 using a signed integer Toke via jabber: Oh, I misread; TR-181 already has a representation for NULL, but it's a bad one... gotcha, I can live with negative numbers ================== Mahesh Jethanandani presents BABEL YANG model https://datatracker.ietf.org/meeting/105/materials/slides-105-babel-babel-yang-model-00 Tracking information model Three issues to discuss Normally good to suggest default values Juliusz: Multicast Hello sequence number is undefined before receiving the first first unicast hello, so this one can be removed Barbara: Mahesh: The existence of the interface is there, but enabling can either be on or off by default Barbara: Do we need to specify a default, and what does it mean? This is not in the information model, would not apply to other instantiations than the YANG model Mahesh: Juliusz: Does this imply how implementations should behave? Mahesh: This does not imply how the implementation should behave; when the first set of configs are provided, this says what the configuration is Mahesh: Enabling the interface as an example Juliusz: Where are these values used? Mahesh: This is the management system telling you the defaults Juliusz: If they are explicitly specific, what makes them default? Mahesh: They are default from the management system Juliusz: Not comfortable with this; example using split horizon, etc.; these values would be fine if the links were wired, but not for wireless David: How about we define an algorithm which is default, which means the implementation to "be smart." Juliusz: What happens if you don't send a default value? Mahesh: If it is not mandatory, the implementation decides; if it is mandatory, then there should be a default Barbara: From a YANG perspective, the management system must send a value, not an empty string Mahesh: The implementation is saying that if the management station does not have a value, the implementation does not know what to do Barbara: The implementation will have a value, as it created the value in the first place Mahesh: In YANG terms, then, this is not a mandatory field Barbara: We have the port numbers and multicast group, the implementation should have logic to determine enabling the interface, etc. Mahesh: I don't remember what we decided for txcost Juliusz: 0 is fine David: Non-mandatory values are fine Martin: Could it be that some of these are state rather than values? Mahesh: Maybe this is correct? Juliusz: In some implementations, these values are determined at startup if they are not configured Mahesh: This leaves three: port number, mcast-group, and txcost David: The implementation can calculate a txcost, so it is not needed, either Mahesh: Assuming txcost is a writeable parameter, what happens if there is no value/not locally calculated? David: The implementation will calculate something if nothing is sent Juliusz on Jabber: Will send examples of routing policy on the mailing list ========================== Baptiste Jonglez, Juliusz Chroboczek presenting Delay-based Metric Extension https://datatracker.ietf.org/meeting/105/materials/slides-105-babel-delay-based-metric-extension-for-the-babel-protocol-00 David: Like the alternative solution at the bottom of the slide, now that we have unicast hellos, we should run over those Toke: Suggest another breaking change: nanosecond timestamps -- while we are breaking things, we should introduce a second one Baptiste: is there a use case for this? Toke: The protocol can show you the fastest way through the data center; don't have a deployed use case for it, but there is some interesting things happening in pave networking, which might make it feasible to need these Baptiste: The counter is currently 32 bits, so you would only have four seconds to respond, having a longer field would be nice Juliusz: You need a timestamp in the packet header, which you do not have unless you are using unicast Hellos; on-demand Hello might be able to help this; no current use for microsecond timestamps, so we don't have any for nanosecond timestamps Juliusz: want to see a convincing use case for nanosecond timestamps Toke: This is fair enough -- it would also be possible to add it in later if we define the base extension Juliusz: We don't need a flag day, just define a new sub-TLV with the nanosecond time stamps, and deprecate the old one Baptiste: Let's not break it just for the resolution Toke: Agree to trying to solve this without breaking anything David: What is your personal preference? Baptiste: Second solution Donald: Should we confirm this on the list Barbara: The RTT draft needs to mention any parameters it would need, such as a boolean in the interface Baptiste: Several parameters, that need to be set, max-tt, min-tt, etc. Barbara: We should have a section in the document talking about what is needed in the information model =========================== Chiars: Thanks everyone. See you on the mailing list and in Signapore.