Subject: [RTG-DIR] RTG-DIR QA review of draft-ietf-babel-rfc6126bis-04.txt

From: "Susan Hares" <[email-masked]>
Date: Wed, 3 Jan 2018 22:19:54 -0500

Juliusz and David:

This is a Routing QA review of draft-ietf-babel-rfc6126bis.   The normal
form of this routing review is: 

Status:  (no ready, ready with issues, ready with nits) 

Comments:  

Editorial comments 

However, reviewing the amazing work you have done in babel just does not fit
this mold.   

Personal view on your work: 

I am personally excited about your work because it represents some "of the
box" thinking we will need in the upcoming decades.  Physical infrastructure
(802.11, Ethernet, fiber, and 5G networks) and computing technology sizes
(sensors, tiny-OS, phone computing, and datacenters change) emerge every 2-3
years and change our routing within 5 years.   You are rethinking and
adapting a very old style of protocol to a new environment fixing some of
the obvious problems with lessons we've learned in the last 15-20 years.
Kudos to you! 

Have you've solved and deployed babel with all of these fixes in a home
environment?  It appears from your transition from Experimental to protocol
standard work - that you've really made it work in deployments.   Kudos!

My comments are simply a way to help you refine your specification (or
family of specifications) to be published as standard.  I am glad to help
work on the refinement. 

Technology status: Not ready - due to management issues 

You've missed two important features in your discussion in
draft-ietf-babel-rfc6126bis-04.txt 

1)      How to handle the policy for these routes (RIP was ripe for a lot of
policy, it is appears you allow it), 

2)      How to manage all the normal data and the knobs. 

Did your deployments have a widely diverse equipment population and user
population? If so, you may have solved these issues - but not put them in
this document.  If you expected to write another document to cover these
issues, please let me know.   

The current babel info-model (draft-ietf-babel-information-model-01)
provides information on the data structures you included in chapter 3.  To e
specific - the structures are the protocol info (babel-information-object,
constants (babel-constants-obj), interfaces (babel-interface-obj), neighbors
(babel-neighbors-obj), babel sources and routes (babel-sources-obj,
babel-routes-obj)).   However, I am not seeing a many of the knobs you
mentioned (E.g. timer knobs,  policy).  The info-model includes
babel-security (babel-security-obj), but how will your protocol use it? 

As someone who used to sell routing code to vendors for insertion in low-end
home routers, we spent lots of time getting the management and policy right.
I'm hopeful you are smarter than I am.  It takes careful designs within the
protocol and outside of the protocol in Yang modules to allow for a simpler
user-interface, defaults that work 80% of the time, and policy to cover the
other 20%.  The default have to cover the normal user and the policy the
sophisticated user/program. 

One of the problems with massive deployment in the home is the exposure of
information that should stay private.  It may be necessary to define a
default mandatory security suite that goes with this (e.g.) for home use.
If you run it over a secured Ethernet or Wifi with an existing high level of
encryption - this may also be ok.   For home use, I am uncomfortable without
a default profile. 

Technology nice-things: 

1)      feasibility condition and algorithm ("reset" by sequence number) 

2)      Neighbor being interface + router - but I am not sure you've caught
all the problems 

3)      Hello/IHU timers 

4)      Bi-direction reachability metrics

5)       Target request for route, seqno 

6)      Routes from multiple routers and overlapping routes, 

7)       Garbage collections - however the details are not there.  

8)      Parser-state (section 4.5) - pro/cons to this approach need to be
handled in section 2.0 

9)      Section 4.6.9 - update with "omitted octets" 

10)   Concern for the switching of routers (router-a to router-b to
router-a) for a route - but you lack details in how it can be prevented. 

Document status: Great start, needs work to refine knobs and details  

Your document has a lovely form (intro), conceptual view of protocol,
protocol operations, protocol encoding, IANA, Security considerations, but
it leaves out manageability.   The optimization "knobs" are everywhere in
your document, but the reader has no sense of how they can monitor, manage
or otherwise handle all these knob settings.  If you intend to have this all
in a Yang model, you need to discuss this. 

Your document suggests is provides a summary in section 2 of the algorithms.
However, here are the pieces it misses:

a)      There is no list in the beginning on what algorithms, 

b)      The cool Hello/IHU timer issues with triggers 

c)       The use of split horizon 

d)      The router updates that allow optimized bytes to be omitted and
assumed to be copied 

e)      Explicit request (section 3.8) - you really make sure all the
sub-section are summarized in the algorithm.

It is important to differentiate route-request from seqno-requests.  It is
also important to cover sections 3.8.2.3 and 3.8.2.4 in the top summary. 

f)       Expansion of the text in 2.5, 2.6, and 2.7 to provide route
distribution of normal routes

a short table and description which covers the feasible route, unfeasible
route, and infinity route

g)      Discussion of what policy will be allowed, what policy is prohibited
(due to breaking algorithm), and what policy is "not a good idea". 

It is also important to bring forward when things are ignored or silently
ignored (examples - see 4.5, 4.6.8, 

Editorial issues: 

I resisted the urge to take out my professorial red pen.  A great deal of
the text is readable, but some portions repeat and confuse.  Especially in
the timers, feasibility, and route update sections.  You are very
intelligent and your vocabulary range is extensive.  I suspect that we can
quickly resolve the editorial issue after you fix the manageability issues
and fill out the details in the sections. 

I will be glad to do a second pass review for editorial once you've fixed.
I'm sorry this took a long time to do in December.

Keep going!  This is a wonderful addition to the Internet suite of routing
protocols. 

Susan Hares

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 05 Jan 2018 19:19:37 +0100

Dear Susan,

Thank you very much for the kind words, and thank you for your review.
Unfortunately, I cannot help but be somewhat puzzled.  As it currently
stands, your review is not likely to help us improve the document.

If I read your review right, it consists of three parts.

In a first part, you comment about the lack of discussion of management.
Rfc6126bis has a very precise scope: it defines the on-the-wire protocol
and associated algorithms in a way that is sufficiently precise to enable
independent reimplementation of the protocol in an interoperable way
without overly restricting implementers' freedom.  It has arguably been
successful with this goal: there are currently three independent,
interoperable implementations of RFC 6126, at least two of which have been
independently updated to comply with rfc6126bis.

The Babel community has done a significant amount of work on management of
Babel networks in a wide range of very different environments, some of it
within the IETF, some of it outside, some of it publicly available, some
of it proprietary.  I would be interested in discussing Babel management
issues with you and Barbara in a separate mail exchange, or even on the
mailing list.

However, management issues are out of scope for rfc6126bis, which deals
with the on-the-wire protocol only.  Hence, your comments about management
in your review of rfc6126bis are somewhat puzzling to me, and do not help
us improve the document.
 
In a second part, you comment about Section 2, the conceptual overview of
the protocol, and mention that it is incomplete.  I have re-read this part
carefully, and I think that it is perfectly clear that this part is not
meant to be exhaustive; for what it's worth, none of people independently
reimplementing Babel have been confused by that.  (As a matter of fact,
you missed the most important simplification that's done in that section
-- we use a mesh model there, rather than the more complicated but more
realistic link model used on the Internet and hence used by the protocol
description in Section 3.)

I think that it is important that Section 2 remains concise and readable.
Hence, I disagree with your comments about triggerred updates or technical
details of the packet format needing to be described in Section 2.  Doing
that would not improve the document.

In a third part of your review, you make a fairly large number of comments
about particular issues you have with this document.  Unfortunately, your
comments range from incomplete ("but I am not sure you’ve caught all the
problems") through cryptic ("however the details are not there") to
somewhat enigmatic ("there is no list in the beginning on what
algorithms").  While we can guess in many cases what you mean, I don't
think that this list is precise enough for us to work with in order to
improve rfc6126bis.

Dear Susan, I realise that you are a busy person.  However, I would like
to strongly encourage you to send us another review, one that fits the
scope of rfc6126bis and is precise and detailed enough to help us improve
the document.

Thank you very much for your help,

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 6 Jan 2018 11:13:08 -0500

Hi Juliusz,

> in your review of rfc6126bis are somewhat puzzling to me, and do not help

Well, the title of rfc6126bis is simply "The Babel Routing Protocol"
and there are many in the IETF who would consider the specification of
a routing protocol that says nothing about management to be
incomplete. Management messages are sent on-the-wire. My apologies for
not thinking about this aspect earlier.

Let me point to one example, with which I am particularly familiar, of
how this was handled: In order to get the TRILL base protocol
specification (RFC 6325) approved, it was necessary to add one
paragraph near the front of the document (the last paragraph of
Section 2.1) and add Section 5 (RBridge Parameters). The added
paragraph starts with "Rbridges SHOULD support SNMPv3 [RFC3411]. The
Rbridge MIB will be specified in a separate document. ..." Of course
TRILL is not BABEL and RFC 6325 was some years ago but, for example,
saying that BABEL implementations SHOULD support NETCONF, a YANG model
will be in a separate document, and providing some specific
enumeration of the knobs (perhaps starting from the current Appendix
B) in the text does not seem that burdensome.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> In a second part, you comment about Section 2, the conceptual overview

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 06 Jan 2018 17:59:25 +0100

Hi Donald,

> there are many in the IETF who would consider the specification of
> a routing protocol that says nothing about management to be incomplete.

I think I disagree with that opinion.  For what it's worth, and unless
I've missed something, neither RFC 2328 (which is one of my favourite
RFCs) nor RFC 4271 (of which Susan happens to be a co-author) say anything
about management.  The only place I can find anything about management in
RFC 5340 is the reference to the MIB.

> Management messages are sent on-the-wire.

It's a different (virtual) wire.

> for example, saying that BABEL implementations SHOULD support NETCONF,
> a YANG model will be in a separate document,

I am fairly sure that such a statement would not reflect WG consensus.
Requiring a full YANG implementation (which includes, for a start, an XML
parser) in every Babel implementation would be a sure way to kill the
protocol.

> and providing some specific enumeration of the knobs

I believe that would be Appendix B.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 06 Jan 2018 18:21:21 +0100

> parser) in every Babel implementation would be a sure way to kill the

I realise that I should clarify this.

The simplicity and implementability of Babel is one of its main features.
Babel can be explained to a lecture hall of fourth-year students in 40
minutes.  Babel can be implemented in less than 1000 lines of Python code,
and a stub implementation of Babel has been written that compiles to 12kB
of text.  Babel has been independently reimplemented three times, and in
one case it took the author (Markus Stenberg) just two nights to do the
implementation.

Given how important for us it is that Babel is a conceptually simple and
highly implementable protocol, I believe that it would be a tragic mistake
to make Babel dependent on the arguably complex protocol stack that is
NETCONF/YANG/XML.

What is more -- Babel development has been driven by the needs of our
users.  While we have been actively discussing management issues with our
userbase for the last years (I can send some pointers to the list if
you're interested), none of our users have every requested support for
YANG.  Hence, by making Babel dependent on YANG, we would not be serving
our constituency well.

-- Juliusz

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 6 Jan 2018 18:32:06 -0500

Juliusz: 

On my review: 

1) On management -  

Management considerations are like security considerations.  Something must be said in the protocol specification to help the reader find out how to manage the protocol. It is always within scope of a protocol specification. 

If you have specific management that is proprietary outside the IETF, this does not apply to the IETF.  If it is open and outside the IETF, you can point to it.  If you are going to manage with yang models, you can provide a short paragraph with your design and point to the yang models (just as Donald points to). 

The point is - give some consideration to how all those "knobs" are going to be managed.   Say something short, sweet, and substantive. 

2) On the summary  in the front 

If you think it is perfectly clear, then we are on a different page. My point was that it was incomplete and therefore gave the reader an unclear and incomplete set of statements.  I gave you a list of topics to provide additional points for.   You can disagree at any time with the review.  If you wish to simply disagree, please take that up with the chairs or your AD. 

I am reading this protocol without your years of work.  The purpose was to provide you with hints where a little work up front would clear out lots of required comments in sections 3 and 4. 

3) On the third part, I assumed some long-term routing background.  

Please let me know if you feel all the comments were unclear or what areas you want to provide a deeper set of comments.   

The reason I left some of this vague is that I thought that if you cleared up some the issues with #1 and #2, then the text would be easier to clear up in section 3 and 4.  If you feel section 2 is complete, well I disagree.  However, I can roll up my sleeves and send you a detailed comments on the sections 3 and 4. 

Cheerily, Susan  Hares 

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Saturday, January 6, 2018 11:13 AM
To: Juliusz Chroboczek
Cc: Susan Hares; David Schinazi; Alia Atlas; Russ White; [email-masked]
Subject: Re: RTG-DIR QA review of draft-ietf-babel-rfc6126bis-04.txt

Hi Juliusz,

> Rfc6126bis has a very precise scope: it defines the on-the-wire 

> protocol and associated algorithms in a way that is sufficiently 

> precise to enable independent reimplementation of the protocol in an 

> interoperable way without overly restricting implementers' freedom.  

> It has arguably been successful with this goal: there are currently 

> three independent, interoperable implementations of RFC 6126, at least 

> two of which have been independently updated to comply with rfc6126bis.

> The Babel community has done a significant amount of work on 

> management of Babel networks in a wide range of very different 

> environments, some of it within the IETF, some of it outside, some of 

> it publicly available, some of it proprietary.  I would be interested 

> in discussing Babel management issues with you and Barbara in a 

> separate mail exchange, or even on the mailing list.

> However, management issues are out of scope for rfc6126bis, which 

> deals with the on-the-wire protocol only.  Hence, your comments about 

> management in your review of rfc6126bis are somewhat puzzling to me, 

> and do not help us improve the document.

and there are many in the IETF who would consider the specification of a routing protocol that says nothing about management to be incomplete. Management messages are sent on-the-wire. My apologies for not thinking about this aspect earlier.

Let me point to one example, with which I am particularly familiar, of how this was handled: In order to get the TRILL base protocol specification (RFC 6325) approved, it was necessary to add one paragraph near the front of the document (the last paragraph of Section 2.1) and add Section 5 (RBridge Parameters). The added paragraph starts with "Rbridges SHOULD support SNMPv3 [RFC3411]. The Rbridge MIB will be specified in a separate document. ..." Of course TRILL is not BABEL and RFC 6325 was some years ago but, for example, saying that BABEL implementations SHOULD support NETCONF, a YANG model will be in a separate document, and providing some specific enumeration of the knobs (perhaps starting from the current Appendix

Thanks,

Donald

155 Beaver Street, Milford, MA 01757 USA   <mailto:[email-masked]> [email-masked]

> the protocol, and mention that it is incomplete.  I have re-read this 

> part carefully, and I think that it is perfectly clear that this part 

> is not meant to be exhaustive; for what it's worth, none of people 

> independently reimplementing Babel have been confused by that.  (As a 

> matter of fact, you missed the most important simplification that's 

> done in that section

> -- we use a mesh model there, rather than the more complicated but 

> more realistic link model used on the Internet and hence used by the 

> protocol description in Section 3.)

> Hence, I disagree with your comments about triggerred updates or 

> technical details of the packet format needing to be described in 

> Section 2.  Doing that would not improve the document.

> In a third part of your review, you make a fairly large number of 

> comments about particular issues you have with this document.  

> Unfortunately, your comments range from incomplete ("but I am not sure 

> you’ve caught all the

> Dear Susan, I realise that you are a busy person.  However, I would 

> like to strongly encourage you to send us another review, one that 

> fits the scope of rfc6126bis and is precise and detailed enough to 

> help us improve the document.

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 6 Jan 2018 18:59:44 -0500

Juliusz:

Are your users only using proprietary management?  Or are they using another
open source management mechanism?

Sue Hares 

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
Sent: Saturday, January 6, 2018 12:21 PM
To: Donald Eastlake
Cc: Susan Hares; David Schinazi; Alia Atlas; Russ White; [email-masked]
Subject: Re: RTG-DIR QA review of draft-ietf-babel-rfc6126bis-04.txt

>> for example, saying that BABEL implementations SHOULD support 
>> NETCONF, a YANG model will be in a separate document,

The simplicity and implementability of Babel is one of its main features.
Babel can be explained to a lecture hall of fourth-year students in 40
minutes.  Babel can be implemented in less than 1000 lines of Python code,
and a stub implementation of Babel has been written that compiles to 12kB of
text.  Babel has been independently reimplemented three times, and in one
case it took the author (Markus Stenberg) just two nights to do the
implementation.

What is more -- Babel development has been driven by the needs of our users.
While we have been actively discussing management issues with our userbase
for the last years (I can send some pointers to the list if you're
interested), none of our users have every requested support for YANG.
Hence, by making Babel dependent on YANG, we would not be serving our
constituency well.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jan 2018 04:32:02 +0100

I've added Barbara Stark and the babel@ietf mailing list to the CC.

> Are your users only using proprietary management?  Or are they using
> another open source management mechanism?

There are currently four production-quality implementations of Babel:

  (1) the standalone reference implementation, called "babeld" (Babel Daemon);

  (2) the implementation integrated into FRR (formerly Quagga), the leading
      Open-Source routing suite; this is based on an older version of babeld;

  (3) the implementation integrated into BIRD, the other major Open-Source
      routing suite; this is an independent reimplementation;

  (4) a proprietary implementation I know very little about.

Implementations (2) and (3) aim to integrate as well as possible into
their respective routing suites, and therefore they use, respectively,
FRR's and BIRD's native management mechanisms; I will be glad to get you
in touch with FRR and BIRD specialists should you wish to learn more (as
far as I'm aware, neither uses NETCONF).  The rest of this mail only
applies to implementation (1), babeld.

Babeld has a rich management language (including BGP-style route
filtering), which can be used in two ways:

  - statically, in a set of configuration files that are read by babeld at
    startup;
  - dynamically, over a TCP or Unix Domain socket.

The management language is a textual format that is carefully designed to
be both human- and machine-readable, and extensible without breaking
backwards compatibility.  The implementation does not rely on any external
libraries, and the hand-written recursive-descent parser consists of 1347
lines of C code that compile to 11.5kB of text.

It has the following features:

  - global configuration of the daemon;
  - configuration of parameters of specific interfaces;
  - route filtering, inspired by gated but more powerful;
  - one-shot monitoring;
  - event-driven monitoring.

The interface is designed to be as exhaustive as possible.  It therefore
exposes a number of internal implementation details that it would not be
useful to standardise.

As you know, babeld is deployed in production.  Here are a few examples of
how our users do monitoring and reconfiguration in production.

1. Static configuration

A number of our users use a subset of the configuration language in static
configuration files.  As far as I can tell, the most common applications
are, in roughly decreasing order:

  - defining the set of active interfaces;
  - changing the link-quality estimation algorithm of specific interfaces
    (notably enabling the optional RTT- and diversity-based algorithms);
  - filtering out aggregated routes or routes subsumed by a default route.

As far as I can tell, our users do not much tweak any of the other
tweakables.  I like to think that this is because Babel is able to adapt
to widely varying network conditions without the need to tweak.

2. Dynamic reconfiguration using static interfaces

The reference implementation of the Homenet protocol suite generates a new
configuration file every time the hnetd daemon detects a configuration
change, and restarts the babeld process.  While a better approach would be
to use the dynamic reconfiguration mechanisms in babeld, this approach is
easy to implement, and appears to be good enough for Homenet.

    https://github.com/sbyx/hnetd

3. Pure dynamic reconfiguration

Nexedi are a French company that use Babel for managing a global-scale
overlay network between datacenters over the public Internet.  Nexedi are
interested in avoiding any form of manual intervention: they do not
manually configure metrics, but instead rely on the Babel-RTT extension to
compute metrics automatically:

   https://tools.ietf.org/html/draft-jonglez-babel-rtt-extension

However, Nexedi sometimes need to bring down a link in their overlay, and
wish to avoid waiting for the protocol to reconverge.  For that, they use
a proprietary configuration interface in order to bring a Babel interface
down before they bring the link down, thus achieving graceful failover
with no packet loss whatsoever.

Nexedi currently use a proprietary management interface, but I am working
with them on getting them to use the normal babeld mechanisms (which is
somewhat involved, since part of their nodes are at customer sites and
therefore a flag day is not possible).

4. one-shot state dumps parsed by a script

The management interface is designed so that its output is trivial to
parse using a script without using any extra libraries.  For example, the
following command line gives a dump of all routes known to the local Babel
daemon:

  (echo dump; echo quit) | nc ::1 33123 | grep '^route add '

People usually use ssh tunnelling in order to dump the state of remote
nodes.

A surprisingly large number of our users perform monitoring using this
kind of approach.  The most ambitious case I am aware of is the Wlan-SI
nodelist, which is a PHP-based website that gives real-time details about
a fairly large hybrid Babel/OLSRv1 network:

    https://nodes.wlan-si.net/

5. event-driven monitoring

The management interface is designed to support event-driven monitoring.
This is used by the "Babelweb" graphic tool:

    http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/

As you can see, we are actively working with our users on management for
Babel.  There is a lot of exciting and novel experimentation going on, and
it is therefore my opinion that it would be a mistake to mandate a single
style of management in rfc6126bis.

Regards,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jan 2018 05:02:02 +0100

> I can roll up my sleeves and send you a detailed comments on the sections 3
> and 4.

Please do.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 7 Jan 2018 00:21:45 -0500

Hi Juliusz,

> RFC 5340 is the reference to the MIB.

RFC 4271 = 2006 BGP-4; BGP MIBs were defined starting with RFC 1269 in 1991
RFC 2328 = 1998 OSPF v2, RFC 5340 = 2008 OSPF for IPv6; OSPF MIBs were
defined starting with RFC 1248 in 1991

Times change. Back then SNMP was the management protocol for the IETF.
It was just automatically assumed that if a MIB was specified for a
protocol, then you would manage it with SNMP.

Perhaps a better and more recent example of a new routing protocol is
RFC 6550 which has an extensive Manageability Considerations section
and which references RFC 5706 (Guidelines for Considering Operations
and Management of New Protocols and Protocol Extensions).

> parser) in every Babel implementation would be a sure way to kill the

SHOULD does not equal "requiring". In any case, that wording was just
an example cloned from RFC 6325.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jan 2018 12:37:30 +0100

> RFC 6550 which has an extensive Manageability Considerations section

I'll read this in detail.

In the meantime, I'd just like to point out that RPL is a very different
beast from Babel.  Babel is designed to require minimum configuration, and
we have made serious efforts to ensure that all variants interoperate to
the extent possible.  RPL, on the other hand, has at least three distinct
non-interoperable variants (storing mode, non-storing mode, and another
one that I forget), and requires extensive configuration in order to build
a working network.

> and Management of New Protocols and Protocol Extensions).

Thanks for the pointer.  I'm going to do some homework.

> an example cloned from RFC 6325.

Noted, thanks.  I'll read the two documents referenced above, and think it over.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 08 Jan 2018 18:33:29 +0100

Juliusz Chroboczek <[email-masked]> writes:

> As you can see, we are actively working with our users on management
> for Babel. There is a lot of exciting and novel experimentation going
> on, and it is therefore my opinion that it would be a mistake to
> mandate a single style of management in rfc6126bis.

+1 on that assessment :)

-Toke

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Jan 2018 04:38:40 -0500

Toke and Juliusz: 

Before I send my next Babel set of comments, can you tell me what management you want to standardize?  Please choose one of the following options: 

1) None - it is all proprietary 
2) Yang modules - for configuration 
3) Yang modules for monitoring 
4) Specific configuration knobs - not as yang modules. 

Thank you, 
Susan Hares 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Toke Høiland-Jørgensen
Sent: Monday, January 8, 2018 12:33 PM
To: Juliusz Chroboczek; Susan Hares
Cc: [email-masked]; [email-masked]; 'Russ White'; 'Alia Atlas'; Barbara Stark; 'Donald Eastlake'; 'David Schinazi'
Subject: Re: [RTG-DIR] [babel] About Babel management [was: RTG-DIR QA review...]

+1 on that assessment :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 18 Jan 2018 17:30:11 +0100

> Sorry I didn't pick from your 1 - 4 options, but I hope this provides
> you with the information you need?

I'll just add one comment, since Susan might want some more insight into
the culture of this WG.

The main contributors to this WG have been working very hard to establish
a tradition of working code.  I'm fairly positive that every single Babel
draft, whether adopted by this WG or written before the WG was established,
does reflect implementation experience.

We're very serious about that.  For instance, the people working on
DTLS-based Babel security have agreed not to write anything up until we've
got at least one proof-of-concept implementation (hopefully two, fingers
crossed).

I don't think anyone here would be opposed to writing up and standardising
a YANG model for Babel should one be implemented first.  However, since
none of the implementations of Babel speak Netconf, and since until now
the users of Babel have not been asking for Netconf-based management, this
is not something that's likely to happen in the immediate future.

Should we find out that either the users or the implementers are requesting
Netconf, a YANG model would become much more likely.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Jan 2018 14:26:43 +0000

Hi Susan,
I hope Juliusz and Toke don't mind, but I'll provide my thoughts re babel management, as the current author of draft-ietf-babel-information-model.
https://tools.ietf.org/html/draft-ietf-babel-information-model-01 

We agreed to start with an information model, rather than go directly to some management protocol's data model, because babel may be implemented in ISP-supplied CE routers which are almost all managed using BBF TR-069 today. But I understand YANG models are expected to exist for all IETF routing protocols.
By starting with the information model, subsequent BBF and YANG data models can be created that can easily be mapped from one to the other.

The current draft-ietf-babel-information-model has a few parameters that an implementation may choose to allow to be configurable. All are readable.
Statistics (for monitoring) are on the to-do list. 

I have no intention of creating a YANG module (not my specialty and not something I have need of) from this information model. That would need to be an exercise for someone else. I do expect to create the BBF TR-069 data model. In BBF.

Sorry I didn't pick from your 1 - 4 options, but I hope this provides you with the information you need?
Barbara

> From: babel [mailto:[email-masked]] On Behalf Of Susan Hares
> Sent: Thursday, January 18, 2018 4:39 AM
> To: 'Toke Høiland-Jørgensen' <[email-masked]>; 'Juliusz Chroboczek'
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; 'Russ White' <[email-masked]>; 'David
> Schinazi' <[email-masked]>; 'Alia Atlas' <[email-masked]>; 'Donald
> Eastlake' <[email-masked]>; STARK, BARBARA H <[email-masked]>
> Subject: Re: [babel] [RTG-DIR] About Babel management [was: RTG-DIR QA
> review...]
> 
> Toke and Juliusz:
> 
> Before I send my next Babel set of comments, can you tell me what
> management you want to standardize?  Please choose one of the following
> options:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=5533-
> AnnrHe4u9HjLj8J3SX7PX0kKhWwSisuRIrV0SI&s=oh7uMBdX9kqNvQh9wGrec
> HaiJkxhn16tFFSomeH0DQw&e=

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 18 Jan 2018 19:49:53 +0000

Hi all,
IMHO and FWIW the work described by Barbara matches Option 4 in Susan's list.

Hope this helps.

My 2c

Thump typed by Sasha Vainshtein

From: STARK, BARBARA H
Sent: Thursday, January 18, 18:57
Subject: Re: [RTG-DIR] [babel] About Babel management [was: RTG-DIR QA review...]
To: Susan Hares, 'Toke Høiland-Jørgensen', 'Juliusz Chroboczek'
Cc: [email-masked], [email-masked], 'Russ White', 'Alia Atlas', 'Donald Eastlake', 'David Schinazi'

Hi Susan, I hope Juliusz and Toke don't mind, but I'll provide my thoughts re babel management, as the current author of draft-ietf-babel-information-model. https://tools.ietf.org/html/draft-ietf-babel-information-model-01 We agreed to start with an information model, rather than go directly to some management protocol's data model, because babel may be implemented in ISP-supplied CE routers which are almost all managed using BBF TR-069 today. But I understand YANG models are expected to exist for all IETF routing protocols. By starting with the information model, subsequent BBF and YANG data models can be created that can easily be mapped from one to the other. The current draft-ietf-babel-information-model has a few parameters that an implementation may choose to allow to be configurable. All are readable. Statistics (for monitoring) are on the to-do list. I have no intention of creating a YANG module (not my specialty and not something I have need of) from this information model. That would need to be an exercise for someone else. I do expect to create the BBF TR-069 data model. In BBF. Sorry I didn't pick from your 1 - 4 options, but I hope this provides you with the information you need? Barbara > -----Original Message----- > From: babel [mailto:[email-masked]] On Behalf Of Susan Hares > Sent: Thursday, January 18, 2018 4:39 AM > To: 'Toke Høiland-Jørgensen' ; 'Juliusz Chroboczek' > > Cc: [email-masked]; [email-masked]; 'Russ White' ; 'David > Schinazi' ; 'Alia Atlas' ; 'Donald > Eastlake' ; STARK, BARBARA H > Subject: Re: [babel] [RTG-DIR] About Babel management [was: RTG-DIR QA > review...] > > Toke and Juliusz: > > Before I send my next Babel set of comments, can you tell me what > management you want to standardize? Please choose one of the following > options: > > 1) None - it is all proprietary > 2) Yang modules - for configuration > 3) Yang modules for monitoring > 4) Specific configuration knobs - not as yang modules. > > Thank you, > Susan Hares > > > -----Original Message----- > From: rtg-dir [mailto:[email-masked]] On Behalf Of Toke Høiland- > Jørgensen > Sent: Monday, January 8, 2018 12:33 PM > To: Juliusz Chroboczek; Susan Hares > Cc: [email-masked]; [email-masked]; 'Russ White'; 'Alia Atlas'; Barbara Stark; > 'Donald Eastlake'; 'David Schinazi' > Subject: Re: [RTG-DIR] [babel] About Babel management [was: RTG-DIR QA > review...] > > Juliusz Chroboczek writes: > > > As you can see, we are actively working with our users on management > > for Babel. There is a lot of exciting and novel experimentation going > > on, and it is therefore my opinion that it would be a mistake to > > mandate a single style of management in rfc6126bis. > > +1 on that assessment :) > > -Toke > > > _______________________________________________ > babel mailing list > [email-masked] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_babel&d=DwIGaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=5533- > AnnrHe4u9HjLj8J3SX7PX0kKhWwSisuRIrV0SI&s=oh7uMBdX9kqNvQh9wGrec > HaiJkxhn16tFFSomeH0DQw&e=

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________