Subject: [babel] WG Action: Formed Babel routing protocol (babel)

From: The IESG <[email-masked]>
Date: Fri, 17 Jun 2016 09:19:27 -0700

A new IETF WG has been formed in the Routing Area. For additional
information, please contact the Area Directors or the WG Chairs.

Babel routing protocol (babel)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Donald Eastlake <[email-masked]>
  Russ White <[email-masked]>

Assigned Area Director:
  Alia Atlas <[email-masked]>

Routing Area Directors:
  Alia Atlas <[email-masked]>
  Alvaro Retana <[email-masked]>
  Deborah Brungard <[email-masked]>
 
Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/babel
  Archive: https://mailarchive.ietf.org/arch/browse/babel/

Charter: https://datatracker.ietf.org/doc/charter-ietf-babel/

Babel is a loop-avoiding, distance vector routing protocol with good
provisions for dynamically computed link metrics. The core of the Babel 
protocol and security extensions are described in Experimental 
Independent Stream RFCs 6126, 7557, and 7298.

These RFCs are the basis of three independent, open source
implementations. There is some production deployment of these
implementations, notably in hybrid networks (networks that include
classical, wired parts with meshy radio bits) and in global overlay
networks (networks built out of large numbers of tunnels spanning
continents).

The Working Group will focus on moving the Babel protocol to IETF
Proposed Standard with IETF review.  This includes clarifying RFC 6126
and integrating RFC 7557 and feedback provided by independent
implementations, and resolving comments. It is not a requirement that
the Babel protocol produced is backwards compatible with RFC 6126.  It
is a requirement that Babel support at least one profile that is
auto-configuring.  Other documents that are relevant to the above work
can also be produced. Particular emphasis will be placed on work needed 
for a Proposed Standard routing protocol, such as ensuring manageability 
and strong security. Link metric measurement or link metric calculation 
procedures significantly more complex that those currently in Babel are 
out of scope.

The Babel WG should coordinate with other Working Groups, such as the 
HOMENET WG for likely applicability, the RTGWG and V6OPS WG about 
Source-Specific Routing to support IPv6 multihoming, the PIM WG for 
discussion around multicast, and the MANET WG for considerations around
wireless.

The Babel WG should liaise as necessary with the Broadband Forum to 
facilitate use of the Babel Information Model for TR-069.

Work Items:

- Produce a revision of RFC 6126 suitable for publication as a Proposed 
Standard
    -- incorporate in the revision developments since RFC 6126
    -- resolve technical issues found
    -- include in the base specification the extensibility work in RFC 
       7557
    -- support auto-configuration
    -- consider any important changes based on experience with Babel to 
       date.

- Address security needs for BABEL. This may include using the
techniques in RFC 7298, or other alternatives. Security may be
included in the base spec or the base spec may normatively reference a
separate Proposed Standard specification. This is required as part of
moving Babel to Proposed Standard.

- Address manageability of Babel by producing a Babel informational 
model to help provide guidance and derive the data models. To be 
consistent with  the ongoing effort to use YANG data modules in the 
Routing Area, a Babel  YANG data model to support management of home 
gateway routers is required as part of moving Babel to Proposed 
Standard. This information model is useful as a common source of 
information for the case where the Customer-Premise Equipment (CPE) is 
managed by the Service Provider (SP) with the Broadband Forum TR-069 
protocol and its associated data model.

- As the Proposed Standard version of Babel is completed, an
Applicability Statement should be finalized to guide those potentially
interested in deploying Babel. This Applicability Statement may
include deployment advice and will be published as an RFC.

- The Working Group should document its ongoing implementation
experience with Babel, so that new WG participants can understand the
state that is driving this work and the experience driving changes.
This documentation may be on the Working Group's wiki, in 
an internet-draft that isn't expected to be published as an RFC, or a
combination. 

- As a non-primary focus, the Working Group may work on multicast
aspects of Babel.  This may include discussion of any potential issues
for supporting Babel running with PIM-SM in an auto-configuration
profile.  It may include exploring Babel carrying separate metrics for
multicast.  It may include discussion and consultation with the PIM
WG about Babel providing the ability to build multicast routing
tables.  With AD and WG agreement, once an approach is understood,
then a milestone may be added for an associated document targeted as
Proposed Standard.

- As a non-primary focus, the Working Group may work on documents
defining source specific routing extensions for Babel as a way of 
handling IPv6 multihoming.

Milestones:
  Jul 2016 - WG adoption of Babel Applicability draft
  Jul 2016 - WG adoption of RFC6126bis
  Oct 2016 - WG adoption of Babel Management (Info Model & YANG Model)
draft
  Jul 2017 - IESG Submission of RFC6126bis and potentially companion
security mechanisms draft (Proposed Standard)
  Jul 2017 - IESG Submission of Babel Management draft  (Proposed
Standard)
  Aug 2017 - IESG Submission of Babel Applicability draft (Informational)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 19 Jun 2016 13:17:59 +0200

The IESG says:

> A new IETF WG has been formed in the Routing Area.

> Charter: https://datatracker.ietf.org/doc/charter-ietf-babel/

Hourra!

Many thanks to everyone who helped with making this happen.  (Too many
people to fit in the margin of this mail, so I'll just single out the
fine-tuning work that Alia did in the final phases.)

Pro memoria, IETF 96 is from 17 to 22 July in Berlin, Germany (from
Warsaw, just follow the A2 highway westwards for 550km, or take the train
at central station; from Paris, hop into the first night train at Gare de
l'Est -- no need to suffer through airport security).  The inscription
fees are high, but there are very reasonable student rates, and Berlin is
full of cheap hotels, many of them close to the Hilton.  (And if you've
never been to Berlin -- it's worth visiting.)

I'll send a reminder to both lists just before the meeting, with pointers
to the online participation URLs.

Hope to see you all there,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 19 Jun 2016 15:26:15 +0200

> The inscription fees are high, but there are very reasonable student
> rates, and Berlin is full of cheap hotels, many of them close to the
> Hilton.

People are telling me it's not at the Hilton.  Apologies.  I'm not saying
where it is, please check the web pages rather than listening to me ;-)

-- Juliusz

---

From: Denis Ovsienko <[email-masked]>
Date: Sun, 19 Jun 2016 23:19:59 +0100

---- On Fri, 17 Jun 2016 17:19:27 +0100 The IESG  wrote ---- 
>information, please contact the Area Directors or the WG Chairs. 

Hello list.

It is very pleasing to see the working group formed, congratulations and thank you to everyone who has been spending their effort to make this happen!

Are there any specific work items I could help with in the next couple weeks?

-- 
    Denis Ovsienko