Subject: [homenet] Selecting a routing protocol for HOMENET

From: Terry Manderson <[email-masked]>
Date: Thu, 26 Mar 2015 16:11:26 +0000

Homenet WG,

The WG is still at an impasse on selecting a single routing
protocol and we ADs understand that this impasse must be resolved since it
is
a detriment to ongoing work and implementation.

In the working group meeting at IETF 92, Alia Atlas as Routing AD,
proposed that
a homenet design team be formed to select the routing protocol for
homenet.  In
the room, there appeared to be support for this. This email is to provide
the proposed
charter for that design team and to confirm on the mailing list (as with
all decisions)
that there is consensus that this is how homenet will move from this
impasse.

The output from the design team would be subject to the question of
whether there
are any substantial technical objections to the selected routing protocol
such that 
the homenet charter can not be met.

The proposed homenet design team charter is below.

=-=-=-=-=-=-=-=-

Homenet's architecture (RFC 7368) articulates the general features
required.  The working group has agreed that a single routing protocol
must be identified as mandatory to implement.  The final purpose of
this design team is to select and present a single routing protocol
with a summary of the necessary extensions and work to be the one that
is mandatory to implement.  Once the design team has made its
recommendation, the working group will consider any substantial
technical objections (see RFC 7282) as part of gaining consensus.

For the design team to make this determination, it shall first
understand the use-cases for homenet and derive routing requirements
from those.  Then it shall compare these routing requirements to
candidate routing protocols and examine the gaps in each.  For each
highly plausible candidate routing protocol, the design team will
estimate the work needed and the associated timeline to get an
acceptable, full, standardized solution using each protocol.  Based
upon this information and the perceived market timing needs of the
technology, the design team will make its selection.  The
requirements, gaps, and reasoning will be documented.

This document should be delivered by the July 2015 IETF.

=-=-=-=-=-=-=-=-

Thanks,
Alia (RTG), Brian (INT), Terry (INT)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Mar 2015 11:53:11 -0500

On Thu, Mar 26, 2015 at 11:11 AM, Terry Manderson <[email-masked]
> wrote:

> For each
> acceptable, full, standardized solution using each protocol.

I find it concerning to say that a decision will be made only on the "work
needed" to get to an acceptable solution, without considering the
likelihood of said work happening and who is expected, able, and
especially, willing to do it.

Example:

For IS-IS, the existence of a small-footprint, source-destination-routing
capable implementation is a blocker for an "acceptable, full" solution.
That requires that either a) someone with knowledge of an existing
implementation extend said existing implementation to meet these
requirements, or b) that someone write a new implementation to meet these
requirements.

On the other hand, for babel, much of the work is in addressing the fact
that the specification is perceived to be underspecified, and verifying
that the existing implementations conform to the specification and
interoperate, and taking the specifications through the standards process.

The types of work involved are radically different, and the people able to
do each may or may not be willing to do it. So if one of the two (say,
IS-IS) is perceived to be lower work, but nobody is willing to actually
*do* that work, then the design team could come to a perfectly logical
conclusion, consistent with its charter, that ends in failure to reach the
full solution.

Or, more succintly: what happened to the "running code" part of the IETF
motto?

---

From: Steven Barth <[email-masked]>
Date: Thu, 26 Mar 2015 12:02:36 -0500

+1

Am 26. März 2015 11:53:11 CDT, schrieb Lorenzo Colitti <[email-masked]>:
>------------------------------------------------------------------------
>
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Terry Manderson <[email-masked]>
Date: Thu, 26 Mar 2015 18:20:31 +0000

Hi Lorenzo,

On 27/03/2015 2:53 am, "Lorenzo Colitti" <[email-masked]> wrote:

>
>I find it concerning to say that a decision will be made only on the
>"work needed" to get to an acceptable solution, without considering the

In the design team charter the following words appear:

"..the design team will estimate the work needed and the associated
timeline to get an acceptable, full, standardized solution using each
protocol."

So the the decision will not be made only on the work needed. Specifying
the timeline means the design team must also consider the resources at
hand, or reasonably available, to reach an acceptable, full, standardized
solution.

>Or, more succintly: what happened to the "running code" part of the IETF

That is certainly not omitted, why do you think it would be?
..Specifically when we look at outputs from the routing area (and Alia can
certainly speak for her own Area on this) two reference implementations
are generally required. That same ideal was highlighted in the workgroup
meeting. So that ethos is very much included.

Are there any other comments in either the positive or negative direction?
Please WG, speak up.

Cheers
Terry

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 13:25:44 -0500

On Mar 26, 2015, at 11:53 AM, Lorenzo Colitti <[email-masked]> wrote:
> For IS-IS, the existence of a small-footprint, source-destination-routing capable implementation is a blocker for an "acceptable, full" solution. That requires that either a) someone with knowledge of an existing implementation extend said existing implementation to meet these requirements, or b) that someone write a new implementation to meet these requirements.

It's pretty hard to believe that the resources would not be made available to get the work done if IS-IS were chosen.   There are some proponents of this choice who have fairly deep pockets.   While I will admit to rooting a bit for Babel, and while I certainly can't speak for the proponents of IS-IS, I am not concerned that if the design chose IS-IS after considering all the technical issues, that would lead to the scenario you are concerned about.

I am, however, concerned that the working group will simply fail because we can't make a choice.   Of the two risks, the second is, to my mind, _far_ more likely.

(Bear in mind that I am no longer an AD, so I am saying this completely independent of any hats that might have formerly rested uneasily on my head.)

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 26 Mar 2015 13:27:27 -0500

> On 26.3.2015, at 13.20, Terry Manderson <[email-masked]> wrote:

I have my doubts that this will converge anywhere useful. Why are we trying to force exactly 1 routing protocol at any rate? It was all based on one hum in London(?) year ago, and it seems more and more like a bad idea given e.g. potential for diverse set of link technologies in future homes.

Also, if routing guys essentially make the decision, I would definitely love to hear what is _the best_ option, not just Babel <> IS-IS choice from them knowing there is ISIS WG in RTG area, but not Babel one.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2015 13:33:24 -0500

On Mar 26, 2015, at 1:27 PM, Markus Stenberg <[email-masked]> wrote:
> I have my doubts that this will converge anywhere useful. Why are we trying to force exactly 1 routing protocol at any rate?

If there isn't a mandatory-to-implement routing protocol, then people are going to buy Homenet[TM] boxes that don't interoperate.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 26 Mar 2015 14:41:48 -0400

Markus,

On Thu, Mar 26, 2015 at 2:27 PM, Markus Stenberg <[email-masked]>
wrote:

> I have my doubts that this will converge anywhere useful. Why are we
> trying to force exactly 1 routing protocol at any rate? It was all based on
> one hum in London(?) year ago, and it seems more and more like a bad idea
> given e.g. potential for diverse set of link technologies in future homes.
>

Different link technologies do not need to lead to different routing
protocols.  Different types of
interfaces can have very different logic.

> Also, if routing guys essentially make the decision, I would definitely
> love to hear what is _the best_ option, not just Babel <> IS-IS choice from
> them knowing there is ISIS WG in RTG area, but not Babel one.
>

PLEASE reread the proposed design team charter.  It articulates the process
that would be followed in this homenet design team. Nowhere does it even
vaguely imply that the team would make a slam dunk answer based on a
superficial examination of implementations, standardization, and deployment.

We have spent quite some time figuring out the proper charter for the
design team to handle and articulate concerns.

Regards,
Alia

---

From: Terry Manderson <[email-masked]>
Date: Thu, 26 Mar 2015 18:41:52 +0000

Hi Markus,

On 27/03/2015 4:27 am, "Markus Stenberg" <[email-masked]> wrote:

>trying to force exactly 1 routing protocol at any rate? It was all based
>on one hum in London(?) year ago, and it seems more and more like a bad
>idea given e.g. potential for diverse set of link technologies in future
>homes.

While that is an interesting walk back from and existing WG consensus, the
topic du jour is about the WG acceptance of the design team to come to an
answer.

>love to hear what is _the best_ option, not just Babel <> IS-IS choice
>from them knowing there is ISIS WG in RTG area, but not Babel one.

The design team will not be limited to the Babel v ISIS competition. The
design team will certainly be directed to first seek out a requirements
position (much of which already exists in RFC7368), and I don't see the
existence of a WG to be a technical requirement. Further the design team
will not be constructed of routing folk alone.

Cheers
Terry

---

From: Gert Doering <[email-masked]>
Date: Thu, 26 Mar 2015 19:48:26 +0100

Hi,

On Thu, Mar 26, 2015 at 01:27:27PM -0500, Markus Stenberg wrote:
> Why are we trying to force exactly 1 routing protocol at any rate? 

I think while we could have any number of routing protocols in there, 
there MUST be one that will *always* be present, and is mandatory for a 
compliant implementation.  Otherwise, we'll end up with incompatible
subsets being implemented by different CPE vendors, and this is absolutely
not acceptible for a homenet solution.

Look at the mess that was made by vendors out of IPSEC - too many choices,
too many knobs, nightmares to operators, totally impossible to use in
cross-vendor scenarios for non-experts.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Steven Barth <[email-masked]>
Date: Thu, 26 Mar 2015 20:35:05 +0100

> Are there any other comments in either the positive or negative 
> direction? Please WG, speak up.
Please take into consideration that the intended solution is aimed at 
relatively low-cost mass-produced devices not big industry routers that 
come with expensive support contracts, i.e. the specifications should be 
relatively simple and clear so it can be implemented in a reasonable 
timeframe by people not knowing the protocol.

Similarly these boxes are mostly unadministered and the overall 
complexity added by the protocol should reflect in the added benefit. 
What I mean is, if the outcome was a protocol that requires compliance 
with 100 pages of specification then it should have a very sophisticated 
mechanism to find the best path without an administrator telling it 
which hops are preferrable.

Thanks,

Steven

---

From: Alia Atlas <[email-masked]>
Date: Thu, 26 Mar 2015 15:39:29 -0400

On Thu, Mar 26, 2015 at 3:35 PM, Steven Barth <[email-masked]> wrote:

> Similarly these boxes are mostly unadministered and the overall complexity
> added by the protocol should reflect in the added benefit. What I mean is,
> if the outcome was a protocol that requires compliance with 100 pages of
> specification then it should have a very sophisticated mechanism to find
> the best path without an administrator telling it which hops are
> preferrable.
>

I certainly hear and understand that these are important requirements.
It is reasonable to consider that a homenet profile of the selected routing
protocol may be appropriate to limit the extensions and functionality that
is needed.

Protocols that have been successful and around a long time do tend to
accumulate lots of extensions.
Frankly, I learned ISIS from a book rather than reading RFCs.

Alia

---

From: Paul Duffy <[email-masked]>
Date: Thu, 26 Mar 2015 16:03:19 -0400

> If there isn't a mandatory-to-implement routing protocol, then people are going to buy Homenet[TM] boxes that don't interoperate.

Which ultimately means people won't buy HomeNet boxes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Mar 2015 15:58:23 -0500

> hand, or reasonably available, to reach an acceptable, full, standardized

Can we make that explicit in the charter? Given how much time has already
been spent here, I feel we must avoid a situation where the design team
chooses a protocol, but then nobody is willing to implement it.

So, I would like to see the charter say that the design team must confirm,
before choosing the protocol, that there are volunteers to provide an
implementation that meets the necessary resource constraints to be included
in a home router.

To my mind, if the perfect routing protocol were to descend from heaven,
but did not have volunteers lined up to implement it in an appropriate
time, the design team should reject it. Do we agree on that?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2015 10:08:28 +1300

> acceptable, full, standardized solution using each protocol. 

I suggest s/work/work and actions/.

Reason: The actions might include a liaison exchange with another
SDO, if it emerged that one of the candidates was not standardised
by the IETF and that it needed an update to its specification.
And the timeline would need to include the estimated time for
that liaison process and the other SDO's latency.

I also suggest that comments in this thread should consist of precise
proposed changes to the draft design team charter, not another run
round the whole discussion loop.

    Brian

---

From: Ray Bellis <[email-masked]>
Date: Thu, 26 Mar 2015 21:33:44 +0000

> round the whole discussion loop.

Thank you Brian, that’s very well put.

Ray

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Mar 2015 17:07:59 -0500

> Thank you Brian, that’s very well put.

One comment is the following: instead of selecting, make them interface; 
maybe use a common TLV.  This has been tried in the past in MANET and 
other routing protocols.

Alex

---

From: James Woodyatt <[email-masked]>
Date: Thu, 26 Mar 2015 17:49:44 -0500

On Thu, Mar 26, 2015 at 3:58 PM, Lorenzo Colitti <[email-masked]> wrote:

> On Thu, Mar 26, 2015 at 1:20 PM, Terry Manderson <
> [email-masked]> wrote:
>

I agree with this to a point, but I think the design team should be
directed to do more than just identify volunteers who are committed to
providing an implementation that meets the resource constraints of a
typical home router device.

I also think it should be directed to require that A) some implementation
of the chosen protocol must be made available in source to the community
under RAND licensing terms, and B) the volunteers must be committed to
presenting in Prague a demonstration of that code running on typical
hardware.

Shorter james: just as it would be a failure if we pick a routing protocol
that we can't standardize, it would also be a failure if we pick one that
can't be demonstrated in running code. I hope this isn't a controversial
statement.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Terry Manderson <[email-masked]>
Date: Tue, 31 Mar 2015 15:12:07 +0000

WG,

I have reviewed all of the emails on this topic.

My assessment is that no-one spoke specifically against (nor for!) the
design team to select the mandatory to implement routing protocol for
homenet. There was, however, some constructive discussion about the design
team charter, along with some advice for the design team to consider.

I have the sense that folks were waiting for charter word-smithing to be
completed prior to accepting/supporting the design team and ultimately its
determination. There simply wasn't enough positive nor negative responses
to gauge consensus.

I have updated the charter as follows which folds in the substantive
comments from Lorenzo and Brian.

=-=-=-=-=-=-=-=-

For the design team to make this determination, it shall first
understand the use-cases for homenet and derive routing requirements
from those.  Then it shall compare these routing requirements to
candidate routing protocols and examine the gaps in each.  For each
highly plausible candidate routing protocol, the design team will
estimate the work and actions needed, the resources at hand
or reasonably available, and the associated timeline to get
an acceptable, full, standardized solution using each protocol.
Based upon this information and the perceived market timing
needs of the technology, the design team will make its selection.
The requirements, gaps, and reasoning will be documented.

=-=-=-=-=-=-=-=-

So with no more emails on the thread, I'm marking the above as the final
design team charter and I now ask the WG to comment by midnight Friday the
3rd April (UTC) of either accepting the design team, or not. I will judge
consensus at that point, remembering that silence doesn't help.

Pending consensus, and at the appropriate time I will direct the design
team to read the advice from Steven, Alexandru, and James posted here for
their consideration.

Cheers
Terry

---

From: Dave Taht <[email-masked]>
Date: Tue, 31 Mar 2015 08:35:05 -0700

I don't see any point in starting up a new working group[1] whatsoever
based on the events of the last ietf homenet meeting, particularly
with the arrival of a new written from-spec version of babel in under
15 hours, (which I am still chortling about. I am tempted to write one
in rust).

It is just punting the question and more delay when stuff that is more
than sufficiently stable is done, already, and shipping, with a 5 year
long productization pipeline left to fill.

(If it helps any (which I doubt) I have never thought that homenet
must settle on one routing protocol, and certainly the from the ISP
part of the link is underspecified)

At least one routing protocol must be available, however to turn back
the tide of the current situation where none are commonly available in
most consumer routing gear. More than one IS available.

Aside from that my major two requirements have only been

0) Must support source specific routing
1) A homenet capable routing protocol MUST work well over wifi and
wireless links in addition to conventional ethernet and other mac
layers

My minor requirements were:

0) Binary and memory sizes must be small enough to fit into teeny routers
1) should be wildly available in every off the shelf OS that might be
used for routing
2) should be extensively tested in environments ranging from homes, to
battlemesh, to small business campus networks
3) Should have a good spec, must have at least one open sourced and
liberally licensed implementation

So to me, y'all are wasting time that could be better spent into A)
pouring resources into making hnetd less the monster than it became,
B) dogfooding what exists and C) developing better tests and D)
developing better metrics

PS However.

[1] I would not mind a working group that took the outputs of the
battlemesh folk (babel, olsr-ETX, batman, bmx) and stacked them up
against the outputs of the ietf working groups (like RPL, olsrv2, and
others from manet and elsewhere) - and the IEEE (like all the layer 2
isis stuff) and that wg BOTH tackled them in the working group AND in
the real world - and worked to sort out the mess of academic code and
real world requirements in the hope, that one day, maybe before I die
of old age and/or apoplexy, the one true routing protocol and metrics
emerged from the chaos.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Mar 2015 15:54:16 +0000

> On 31 Mar 2015, at 16:35, Dave Taht <[email-masked]> wrote:
> 

Whilst full standardisation of Babel may end up happening in a WG anyway, some of this design team's job will be to establish whether it's more expedient to bring Babel up to "proposed standard" levels of specification than to add Homenet-related features (per your list below) to existing IETF endorsed standards.

> long productization pipeline left to fill.

For better or worse, IETF process dictates that we cannot use what is officially an _experimental_ protocol in a standards track document.  Markus' work was very impressive, but not sufficient to overcome that hurdle.

However this _should_ be a very short-lived punt - less than one IETF cycle.  The WG was unable to reach consensus over three full IETF cycles, and this structured design team approach _should_ clear this log jam.

> most consumer routing gear. More than one IS available.

We are arguing on the choice of one _mandatory to implement_ protocol.  For interoperability's sake, this will be the one that "must be available".

Nothing can (nor will) prevent additional protocols from being implemented, and perhaps even operate simultaneously.

> liberally licensed implementation

These requirements are all very well understood.

> pouring resources into making hnetd less the monster than it became,

please elaborate (in a separate thread, please!)

> of old age and/or apoplexy, the one true routing protocol and metrics

If enough people backed that and a suitable charter was agreed that could happen.

kind regards,

Ray

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 31 Mar 2015 17:56:46 +0200

> Then it shall compare these routing requirements to

I don't see the word "proven" or the words "implementation experience".

My (perhaps mistaken) feeling is that whenever I mention an important
feature of Babel, there's a chorus of "that could be done in IS-IS, we
just haven't done it yet".  I've tried to explain that many of the things
that Babel is doing are difficult or outright impossible[1] in IS-IS, but
I don't feel like I've been heard.

Can the charter please make sure that the design team will only consider
features that have been implemented and proven to work?

-- Juliusz

[1] Dijkstra, next-hop routing, non-distributive metric.  Pick any two,
    but you can't have all three.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Mar 2015 12:02:06 -0400

Actually Ray, IETF process, as described by the IESG, happily allows for 
Downref with suitable approval and notice to the community.  So, as far 
as I can tell, homenet could indeed reference and mandate Babel in a 
Proposed Standard RFC.  I would agree that homenet choosing to do that 
would be a strong impetus for moving the document to Standards track. 
But that does not have to be gating.

https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

Yours,
Joel

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Mar 2015 12:07:47 -0400

On Mar 31, 2015, at 12:02 PM, Joel M. Halpern <[email-masked]> wrote:
> Actually Ray, IETF process, as described by the IESG, happily allows for Downref with suitable approval and notice to the community.  So, as far as I can tell, homenet could indeed reference and mandate Babel in a Proposed Standard RFC.  I would agree that homenet choosing to do that would be a strong impetus for moving the document to Standards track. But that does not have to be gating.
> 

This is true, however that downref would have to get IETF consensus, which could be a sticking point if there are a lot of people in the routing area who believe that Babel is problematic for some reason.   This isn't particularly an issue as far as the design team goes because I think we can take it as a given that the design team is going to consider Babel as one of the options, and if Babel is selected then I get the impression that there will be reasonably strong motivation in the routing area to bring it up to proposed standard.

But the real problem here is that the working group needs to pick a routing protocol that's mandatory to implement, so that the Homenet routers that eventually get shipped can route between each other.   That's the point of the design team.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Mar 2015 16:13:28 +0000

> On 31 Mar 2015, at 17:07, Ted Lemon <[email-masked]> wrote:
> 
> This is true, however that downref would have to get IETF consensus, which could be a sticking point if there are a lot of people in the routing area who believe that Babel is problematic for some reason.  

Thanks Ted - yes, that's much more accurate :)

> This isn't particularly an issue as far as the design team goes because I think we can take it as a given that the design team is going to consider Babel as one of the options

Yes, I believe we can.

> and if Babel is selected then I get the impression that there will be reasonably strong motivation in the routing area to bring it up to proposed standard.

Indeed, even more so since Markus demonstrated how easy it was to implement :)

Ray

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Mar 2015 12:15:40 -0400

Joel,

On Tue, Mar 31, 2015 at 12:02 PM, Joel M. Halpern <[email-masked]>
wrote:

> Downref with suitable approval and notice to the community.  So, as far as
> I can tell, homenet could indeed reference and mandate Babel in a Proposed
> Standard RFC.  I would agree that homenet choosing to do that would be a
> strong impetus for moving the document to Standards track. But that does
> not have to be gating.
>

RFC 6126 is both experimental and through the ISE.  The experience with it
is not equivalent to that with standardized protocols.  As I said in
Dallas, if the mandatory-to-implement protocol for homenet is babel, it
will need to be standardized through the IETF consensus process.   Ideally,
with motivation, that would be quick.

Regards,
Alia

>> Whilst full standardisation of Babel may end up happening in a WG anyway,
>> some of this design team's job will be to establish whether it's more
>> expedient to bring Babel up to "proposed standard" levels of specification
>> than to add Homenet-related features (per your list below) to existing IETF
>> endorsed standards.
>>
>> For better or worse, IETF process dictates that we cannot use what is
>> officially an _experimental_ protocol in a standards track document.
>> Markus' work was very impressive, but not sufficient to overcome that
>> hurdle.
>>
>> However this _should_ be a very short-lived punt - less than one IETF
>> cycle.  The WG was unable to reach consensus over three full IETF cycles,
>> and this structured design team approach _should_ clear this log jam.
>>
>> We are arguing on the choice of one _mandatory to implement_ protocol.
>> For interoperability's sake, this will be the one that "must be available".
>>
>> Nothing can (nor will) prevent additional protocols from being
>> implemented, and perhaps even operate simultaneously.
>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Mar 2015 12:18:39 -0400

Juliusz,

> features that have been implemented and proven to work?

The design team is considering the work to get an acceptable, full, and
standardized solution.  One aspect of that can be having multiple
interoperable
independent implementations.  That doesn't mean that everything has to be
implemented already but it should be clear that the work necessary is
engineering
and not research.

Regards,
Alia

-- Juliusz

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Mar 2015 12:25:25 -0400

Hi Joel,

As I understand it, the downref policy is intended to allow references to Informational or Experimental documents in specific cases.  The page you referenced says:  "Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards."

I don't think it is intended to allow a downref to a protocol defined in a non-IETF RFC.  Babel was published as an Independent Submission Experimental RFC.  We have already been told by at least one AD that they wouldn't approve that sort of downref, but that may not represent a final decision of the IESG.

If this is something the Homenet WG may want to do (even though we didn't have consensus to do this during the meeting), would it be possible for us to get an answer from the IESG about whether they would approve this, as part of our selection process?

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 Mar 2015 12:58:03 -0400

As I read the rules, if Alia does not want to allow the downref, it 
can't happen.  But if she and the working group both want it, and the 
IETF last call accepts it, then it can happen.  This is an example of 
the rules allowing us to do what we as a community think is best.

Yours,
Joel

On 3/31/15 12:25 PM, Margaret Wasserman wrote:
>
> Hi Joel,
>
> As I understand it, the downref policy is intended to allow references
> to Informational or Experimental documents in specific cases.  The page
> you referenced says:  "Exceptions to this rule are sometimes needed as
> the IETF uses informational RFCs to describe non-IETF standards or
> IETF-specific modes of use of such standards."
>
> I don't think it is intended to allow a downref to a protocol defined in
> a non-IETF RFC.  Babel was published as an Independent Submission
> Experimental RFC.  We have already been told by at least one AD that
> they wouldn't approve that sort of downref, but that may not represent a
> final decision of the IESG.
>
> If this is something the Homenet WG may want to do (even though we
> didn't have consensus to do this during the meeting), would it be
> possible for us to get an answer from the IESG about whether they would
> approve this, as part of our selection process?
>
> Margaret
>
>
> On Mar 31, 2015, at 12:02 PM, "Joel M. Halpern" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Actually Ray, IETF process, as described by the IESG, happily allows
>> for Downref with suitable approval and notice to the community.  So,
>> as far as I can tell, homenet could indeed reference and mandate Babel
>> in a Proposed Standard RFC.  I would agree that homenet choosing to do
>> that would be a strong impetus for moving the document to Standards
>> track. But that does not have to be gating.
>>
>>> Whilst full standardisation of Babel may end up happening in a WG
>>> anyway, some of this design team's job will be to establish whether
>>> it's more expedient to bring Babel up to "proposed standard" levels
>>> of specification than to add Homenet-related features (per your list
>>> below) to existing IETF endorsed standards.
>>>
>>>  Markus' work was very impressive, but not sufficient to overcome
>>> that hurdle.
>>>
>>> cycle.  The WG was unable to reach consensus over three full IETF
>>> cycles, and this structured design team approach _should_ clear this
>>> log jam.
>>>
>>> We are arguing on the choice of one _mandatory to implement_
>>> protocol.  For interoperability's sake, this will be the one that
>>> "must be available".
>>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Mar 2015 13:09:24 -0400

On Tue, Mar 31, 2015 at 12:58 PM, Joel M. Halpern <[email-masked]>
wrote:

> As I read the rules, if Alia does not want to allow the downref, it can't
> happen.  But if she and the working group both want it, and the IETF last
> call accepts it, then it can happen.  This is an example of the rules
> allowing us to do what we as a community think is best.
>

As I said in the meeting, my concern is not because of the process
requirements - but because of the experience and improvements found during
the standardization and interoperability process.  Even the partial
implementation that was done brought up a couple different issues in either
documentation or code.

Regards,
Alia

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 31 Mar 2015 19:26:18 +0200

>> just haven't done it yet".  I've tried to explain that many of the
>> things that Babel is doing are difficult or outright impossible in IS-IS

> it should be clear that the work necessary is engineering and not research.

Without a strict requirement for implementation experience and empirical
data, there is nothing preventing people from claiming "it's just a matter
of engineering".

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Apr 2015 08:40:41 +1300

On 01/04/2015 05:02, Joel M. Halpern wrote:
> Actually Ray, IETF process, as described by the IESG, happily allows for Downref with suitable approval and notice to the
> community.  So, as far as I can tell, homenet could indeed reference and mandate Babel in a Proposed Standard RFC.  I would
> agree that homenet choosing to do that would be a strong impetus for moving the document to Standards track. But that does not
> have to be gating.

It doesn't. But otoh we'd like the protocol to meet the standards track criteria
in reality, not so much on paper (which is why the downref mechanism exists,
so that reality trumps bureaucracy). I actually like Dave Taht's point:
running code trumps theoretical extensibility.

So yes, I think the design team should be chartered to focus on technical
reality and to set aside bureaucratic requirements.

(But, since the interop that occurred last week - great to see that -
did apparently show up some minor issues, revving the Babel document
may be a good thing to do in any case.)

   Brian

>> Whilst full standardisation of Babel may end up happening in a WG anyway, some of this design team's job will be to establish
>> whether it's more expedient to bring Babel up to "proposed standard" levels of specification than to add Homenet-related
>> features (per your list below) to existing IETF endorsed standards.
>>
>> For better or worse, IETF process dictates that we cannot use what is officially an _experimental_ protocol in a standards
>> track document.  Markus' work was very impressive, but not sufficient to overcome that hurdle.
>>
>> However this _should_ be a very short-lived punt - less than one IETF cycle.  The WG was unable to reach consensus over three
>> full IETF cycles, and this structured design team approach _should_ clear this log jam.
>>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Mar 2015 16:37:51 -0400

I like to think that the IETF standards process has considerable value, and that the specifications that we produce as standards-track RFCs are higher-quality, not just in document quality but in the technical quality of the protocols, than the documents that enter the process.

In the case of Babel, there are two things I think we should consider that would definitely come up as part of the IETF standards process:

1) A mandatory-to-implement security mechanism.  The current draft says that security can be accomplished by using a lower-layer security solution, like IPsec.  It doesn't specify one, and (perhaps more importantly) doesn't specify how the Babel session would be bound to a lower-layer security mechanism. A lower layer mechanism can't really be used to secure a higher-layer protocol, unless the identifiers used in the higher-layer protocol are properly bound to the identifiers used in the lower-layer security mechanism.

2) Congestion avoidance.  I am not sure how Babel would behave in the presence of congestion, nor am I sure that it wouldn't cause congestion in the presence of route flapping.  I have looked through the spec, and I don't see any mechanism to rate-limit Babel messages, or to do any sort of back-off in the presence of congestion.  I'd be interested to know if this has been considered?  Are there mechanisms in the implementation to avoid these problems?

These are two of the things that I look for in protocols -- there are different things that other people look for, and I think it would be valuable to examine Babel from all of those different perspectives.

I think there are other parts of the protocol that could be improved in various ways, although I am not sure that everyone would agree with me.  I think it would be both fun and fruitful to have those discussion, though.  If Juliusz would be willing to surrender change control of the protocol to an IETF WG, I would like to see an IETF WG formed to standardize Babel, whether or not the Homenet WG chooses to adopt it.  I don't see why the formation of that group couldn't start now, in parallel with the design team assessment.  If there are folks who would like to get together to propose a charter for that group, I would be happy to cooperate in that effort.

Margaret

---

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Mar 2015 16:42:46 -0400

Margaret and all,

I have started conversations about the possibility of having an IETF WG
where Babel or a similar protocol could be started.   Alvaro, Deborah and I
are thinking of it as potentially a Distance Vector IGP working group.   It
isn't yet clear whether there is (a) a community to do the work or (b) a
clear scope and applicability to which a protocol would need to conform.

I expect that we may have a mailing list to encourage focused discussion
soon.

Regards,
Alia

On Tue, Mar 31, 2015 at 4:37 PM, Margaret Wasserman <[email-masked]>
wrote:

>
> I like to think that the IETF standards process has considerable value,
> and that the specifications that we produce as standards-track RFCs are
> higher-quality, not just in document quality but in the technical quality
> of the protocols, than the documents that enter the process.
>
> In the case of Babel, there are two things I think we should consider that
> would definitely come up as part of the IETF standards process:
>
> 1) A mandatory-to-implement security mechanism.  The current draft says
> that security can be accomplished by using a lower-layer security solution,
> like IPsec.  It doesn't specify one, and (perhaps more importantly) doesn't
> specify how the Babel session would be bound to a lower-layer security
> mechanism. A lower layer mechanism can't really be used to secure a
> higher-layer protocol, unless the identifiers used in the higher-layer
> protocol are properly bound to the identifiers used in the lower-layer
> security mechanism.
>
> 2) Congestion avoidance.  I am not sure how Babel would behave in the
> presence of congestion, nor am I sure that it wouldn't cause congestion in
> the presence of route flapping.  I have looked through the spec, and I
> don't see any mechanism to rate-limit Babel messages, or to do any sort of
> back-off in the presence of congestion.  I'd be interested to know if this
> has been considered?  Are there mechanisms in the implementation to avoid
> these problems?
>
> These are two of the things that I look for in protocols -- there are
> different things that other people look for, and I think it would be
> valuable to examine Babel from all of those different perspectives.
>
> I think there are other parts of the protocol that could be improved in
> various ways, although I am not sure that everyone would agree with me.  I
> think it would be both fun and fruitful to have those discussion, though.
> If Juliusz would be willing to surrender change control of the protocol to
> an IETF WG, I would like to see an IETF WG formed to standardize Babel,
> whether or not the Homenet WG chooses to adopt it.  I don't see why the
> formation of that group couldn't start now, in parallel with the design
> team assessment.  If there are folks who would like to get together to
> propose a charter for that group, I would be happy to cooperate in that
> effort.
>
> Margaret
>
> for Downref with suitable approval and notice to the
> >> community.  So, as far as I can tell, homenet could indeed reference
> and mandate Babel in a Proposed Standard RFC.  I would
> >> agree that homenet choosing to do that would be a strong impetus for
> moving the document to Standards track. But that does not
> >> have to be gating.
> >
> anyway, some of this design team's job will be to establish
> >>> whether it's more expedient to bring Babel up to "proposed standard"
> levels of specification than to add Homenet-related
> officially an _experimental_ protocol in a standards
> cycle.  The WG was unable to reach consensus over three

---

From: Steven Barth <[email-masked]>
Date: Tue, 31 Mar 2015 22:55:48 +0200

> I like to think that the IETF standards process has considerable value, and that the specifications that we produce as standards-track RFCs are higher-quality, not just in document quality but in t…
What do you think about ISO standards (or RFCs imported from them)?

> 1) A mandatory-to-implement security mechanism.  The current draft says that security can be accomplished by using a lower-layer security solution, like IPsec.  It doesn't specify one, and (perhaps…
There is RFC7298 for Babel which is mentioned in the comparison draft. 
On a more general matter, IIRC both our candidates (and I think most 
IETF routing protocols) have equally non-existent asymmetric 
authentication and that is not even talking about encryption. If you 
want to have encrypted routing protocol traffic, you are going to have a 
bad time last time I looked.

The best we can currently achieve seems to be HNCP managing a PSK to at 
least have symmetric authentication.

Cheers,

Steven

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Apr 2015 10:40:12 +1300

On 01/04/2015 09:55, Steven Barth wrote:
> 
>> I like to think that the IETF standards process has considerable value, and that the specifications that we produce as
>> standards-track RFCs are higher-quality, not just in document quality but in the technical quality of the protocols, than the
>> documents that enter the process.

We can and do make normative references to non-IETF documents
when there's consensus that this is the right thing to do.
I see nothing in the rules that prevents citing a non-IETF
RFC *if* there's consensus to do so. There's plenty of flexibility
in RFC 2026. But (as Alia implied) the real issue is whether the
protocol (and its spec) are good enough technically. Proposing
Babel for the standards track is a good way of evaluating that.

     Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Mar 2015 17:44:02 -0400

> What do you think about ISO standards (or RFCs imported from them)?

I don't have personal experience with the ISO standards process, but I would guess it is valuable in some ways.  In the case of IS-IS, it has been through both the ISO and IETF standardization processes.  It is also an mature protocol that has been widely deployed…  

I have an even higher level of confidence that protocols are improved by the experience of being widely deployed.

> There is RFC7298 for Babel which is mentioned in the comparison draft.

If we made RFC 7298 mandatory to implement as part of Babel, that might be a start.  I have not done a full security analysis of Babel, so I don't know if it would be sufficient.

> On a more general matter, IIRC both our candidates (and I think most IETF routing protocols) have equally non-existent asymmetric authentication and that is not even talking about encryption. If you want to have encrypted routing protocol traffic, you are going to have a bad time last time I looked.

I don't know if a mechanism to encrypt routing protocol traffic is needed to make Babel (or IS-IS) reasonably secure.  There are only limited use cases where it is desirable to hide the existence of routers or the topology of the local network from nodes on the local network, and encrypting the routing protocols wouldn't be sufficient to accomplish all of that.

Margaret

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Mar 2015 14:50:37 -0700

> I don't know if a mechanism to encrypt routing protocol traffic is needed to make Babel (or IS-IS) reasonably secure.  There are only limited use cases where it is desirable to hide the existence o…

The larger point is that security != crypto.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 31 Mar 2015 23:53:18 +0200

> 1) A mandatory-to-implement security mechanism.

That's not what our userbase want.  People are running Babel over VPNs
(the RTT-based variant).  People are running Babel over secure link
layers.  These users would not be served by putting encryption into the
base protocol.

RFC 7298 (HMAC-based authentication for Babel) is a feature that I've been
under pressure to implement in the reference implementation, and I'm open
to that, time permitting, but I don't want to bloat the base protocol
document with it.

> The current draft says that security can be accomplished by using
> a lower-layer security solution,

No.  The current RFC (not draft) says that Babel as defined in this
document is a completely insecure protocol.  Either you roll your own
security, or you use RFC 7298.

> presence of congestion,

Very well.  It has seen a lot of testing in congested meshes.

> I have looked through the spec, and I don't see any mechanism
> to rate-limit Babel messages,

The metric doesn't change more often than once per hello interval, so
there's no way to get more than one triggered update per hello interval.
Updates are delayed and aggregated, so unless you have massive metric
instability, you get much, much less than that.  And route flapping
doesn't cause triggered updates in Babel.

> Are there mechanisms in the implementation to avoid these problems?

The implementation has a token bucket that logs a huge warning whenever it
triggers.  It hasn't triggered in years, but has been useful to detect
bugs in earlier versions.

Margaret, this is a loop-avoiding distance vector protocol that employs
delayed and aggregated updates.  The amount of traffic generated is
microscopic.  Please don't take my word for it -- see Fig. 4.7 on page 43
of Roger Baig Viñas' M.Sc.  (Note that Roger is part of the BMX6 community,
so if he's biased, he's biased against Babel -- but I've met him
personally, and I believe he's an honest and conscienscious researcher.)

  http://bmx6.net/attachments/download/129/master_thesis__evaluation.pdf

> If Juliusz would be willing to surrender change control of the protocol
> to an IETF WG,

I'm willing to go to Prague.  I'm willing to have the number of coffees,
teas, beers, heck, even Cokes if you insist, that will be necessary for
both of us to feel that trust and understanding have been established.

You cannot reasonably expect me to "surrender" the fruit of seven years of
my life before that has happened.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 01 Apr 2015 00:08:41 +0200

> the standardization and interoperability process.

This makes sense, and I'm quite open to discussing that in Prague.

However, I'd like to attract your attention on one set of data:

  - OSPFv2 is 244 pages, OSPFv3 adds 92 pages;
  - OLSRv2 is 144+60+14 = 218 pages (including dependencies);
  - RPL is 157 pages, and it's badly underspecified (grep for
    "implementation" and try not to cry).

On the other hand

  - Babel 45+10 = 55 pages (including the extension mechanism).

The current version of Babel is version 2.  It has been much simplified
since versions 0 and 1 -- there's almost nothing left to remove from this
protocol.  With one minor exception, all of the mechanisms in RFC 6126 are
used by the implementation, and are necessary for correctness.

In the light of the above figures -- can I trust an IETF working group to
understand that a huge amount of effort has been put into removing
mechanisms from this protocol, and to respect that work?

-- Juliusz