Minutes IETF105: babel
minutes-105-babel-00

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 <channeling Juliusz>: 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.