Subject: Re: [homenet] Selecting a routing protocol for HOMENET

From: joel jaeggli <[email-masked]>
Date: Wed, 1 Apr 2015 18:43:21 -0700

On 3/31/15 9:25 AM, 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.

The concern about labels is offputting, the downref policy is about
exception handling, and the mechanics of reviewing and approving it has
a lot to do with the necessity of making the normative reference, since
it's already been established that the status is a problem.

> 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?

my own .02 is that I don't think we're really forging new ground here.
if you can refer to rfc 3174 which is pretty foundational  then this has
already been considered...

> 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.
>>
>> https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
>>
>> Yours,
>> Joel
>>
>> On 3/31/15 11:54 AM, Ray Bellis wrote:
>>>
>>>> On 31 Mar 2015, at 16:35, Dave Taht <[email-masked]> wrote:
>>>>
>>>> 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).
>>>
>>> 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.
>>>
>>>> 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.
>>>
>>> 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.
>>>
>>>> (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.
>>>
>>> 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.
>>>
>>>> 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
>>>
>>> These requirements are all very well understood.
>>>
>>>> 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,
>>>
>>> please elaborate (in a separate thread, please!)
>>>
>>>> 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.
>>>
>>> If enough people backed that and a suitable charter was agreed that
>>> could happen.
>>>
>>> kind regards,
>>>
>>> Ray
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>
>> _______________________________________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 2 Apr 2015 03:34:10 +0000

My understanding, which could be wrong, is that the IESG has a long-standing policy that a routing protocol needs to have two interoperable implementations, written from the specification. It’s not about the SDO or the specification (IS-IS anyone?), it’s about having proof that the specification is in fact correct and implementable from, by having two or more parties do it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Apr 2015 16:49:43 +1300

> My understanding, which could be wrong, is that the IESG has a long-standing policy that a routing protocol needs to have two interoperable implementations, written from the specification. It’s not…

Formally, it's less rigid since RFC 4794, but the ADs have a lot of discretion.

   Brian

---

From: Alia Atlas <[email-masked]>
Date: Thu, 2 Apr 2015 11:04:07 -0400

Juliusz,

On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboczek <
[email-masked]> wrote:

> > 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.
>
> 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).
>

Perhaps you are familiar with the old joke "I'm sorry this is so long.  I
didn't have time to make
it shorter." ?

> 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?

Yes, I think that the requirement for minimal mechanisms and a simple
easy to implement and troubleshoot protocol can be clearly expressed.  How
well the WG handles this depends in part on the WG chairs and how strongly
the participants are reminded of that requirement and how stringently the
need
for truly active consensus is focused on.

Regards,
Alia

> -- Juliusz

---

From: "George, Wes" <[email-masked]>
Date: Thu, 2 Apr 2015 13:37:55 -0400

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 2, 2015 at 11:04 AM
To: Juliusz Chroboczek <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Margaret Wasserman <[email-masked]<mailto:[email-masked]>>, Dave Taht <[email-masked]<mailto:[email-masked]>>, Ray Bellis <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, Terry Manderson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [homenet] Selecting a routing protocol for HOMENET

 -- 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.

the participants are reminded of that requirement and how stringently the need

WG] Also worth noting that those of us suggesting that Babel move from experimental/individual to IETF consensus standard are not suggesting this because we believe that the design is flawed and needs IETF to fix it. Rather, we're suggesting that it's good to have additional scrutiny and consensus behind your design choices on a mandatory-to-implement protocol that will live on devices that are notorious for not getting consistent software updates. I view a WG that makes changes to an existing protocol for the sake of changes or to "mark their territory" as doing it wrong, and I think most WG chairs are good at making sure that changes are justified. You’ve obviously spent a lot of time thinking about your design choices and refining the design. As to the question of the WG respecting that work, that's unlikely to happen on assertion alone. If the rationale isn't in the RFC, you should be prepared to have those choices questioned by well-meaning folks in the IETF, but it shouldn't be hard to defend them if they are indeed the best choice for the goals of the protocol, especially with the weight of running code behind them. Just don't take those sorts of questions personally, or this will be a lot less pleasant for everyone.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 2 Apr 2015 18:20:03 -0400

I think we could come closer to this by forming a Babel-specific WG that is chartered to take the current Babel documents as a starting point and only change them by consensus of the WG to meet IETF standards-track requirements and fix any technical holes, than we will if we form a more generic WG.   if we start a generic DVRP WG, then we are likely to have multiple candidate specs, and people will be looking to combine specs by compromising and merging the features of different specifications into a single document, so that there will be one document with enough followers to gain consensus.  I suspect that what emerges from that sort of process might not be recognizably Babel.

Margaret

On Apr 2, 2015, at 11:04 AM, Alia Atlas <[email-masked]> wrote:

> Juliusz,
> 
> On Tue, Mar 31, 2015 at 6:08 PM, Juliusz Chroboczek <[email-masked]> wrote:
> > requirements - but because of the experience and improvements found during
> Perhaps you are familiar with the old joke "I'm sorry this is so long.  I didn't have time to make
> it shorter." ?  
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2015 06:04:30 +0000

Certainly, Margaret...

... but then you have to differentiate the capability of any new proposed protocol from what current IETF protocols already do to get that work chartered.

We are having an interesting chat on MANET and ROLL where the differences  (and core similarities) between BABEL and RPL are elaborated.

For all I 've seen so far both protocols employ the same basic methods, and yield the same capabilities though RPL is a lot more versatile - and a lot less understood by the general community- outside LLNs.

Though the discussion is still ongoing and we didn't reach any conclusion yet, we are now at the gory details and the fundamentals are clearly the same.

I 'll note that RPL already addresses the problems the Margaret listed in Dallas, in with a proposed standard doc. The shortest time to Homenet is probably to explain how to use RPL at home, and that probably requires only a guideline informational document...

Cheers,
Pascal

Le 3 avr. 2015 à 00:20, Margaret Wasserman <[email-masked]<mailto:[email-masked]>> a écrit :

Margaret

On Apr 2, 2015, at 11:04 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Juliusz,

On the other hand

Regards,
Alia

-- Juliusz

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 3 Apr 2015 15:20:23 +0900

On Fri, Apr 3, 2015 at 7:20 AM, Margaret Wasserman <[email-masked]>
wrote:

> I think we could come closer to this by forming a Babel-specific WG that
> is chartered to take the current Babel documents as a starting point and
> only change them by consensus of the WG to meet IETF standards-track
> requirements and fix any technical holes, than we will if we form a more
> generic WG.
>

Absolutely.

>   if we start a generic DVRP WG, then we are likely to have multiple
> candidate specs, and people will be looking to combine specs by
> compromising and merging the features of different specifications into a
> single document, so that there will be one document with enough followers
> to gain consensus.  I suspect that what emerges from that sort of process
> might not be recognizably Babel.
>

More to the point, that sort of process will likely result in nothing
emerging at all. There are two discussions happening at the moment. One is
what routing protocol should be chosen for homenet, and the proposed
deadline for concluding that discussion is "before Prague". The other is
around standardizing babel. That can proceed in parallel.

We should not block either discussion on considering yet more routing
protocols.

---

From: Teco Boot <[email-masked]>
Date: Fri, 3 Apr 2015 09:28:27 +0200

Please let me repeat myself, by asking the DT that WiFi clients with 
IEEE802.11r (fast BSS transition) are supported in the homenet. The 
requirement is in RFC 7368.

The DT could say: we have RFC 5415/5416 and someone shall bring 
in a WLC, or, add an SDN layer in the homenet. This might not happen.
The alternative would be MAC layer routing (a.k. bridging). This is
brought up several times, by several people. People which IMO
understand home WiFi problems and know how to fix them.

I do not say I prefer ISIS/TRILL or ISIS/RFC6329/IEEE802.1aq 
over Babel. What I say is that selection based on number of pages 
of an RFC, number of lines of code will result in nothing. It is 
about problems to fix with a good engineering effort.  

I know this SPB technology seems to be overkill and is less an
IP layer routing beast. But a well performing homenet with multiple
WiFi APs cannot without. 

BTW: 802.11r without central controller needs a config distribution 
protocol. We could provide that.

May I ask for having 802.11 experts in the DT?  

Teco

> Op 31 mrt. 2015, om 17:12 heeft Terry Manderson <[email-masked]> het volgende geschreven:
> 
> 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.
> 
> =-=-=-=-=-=-=-=-
> 
> 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 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.
> 
> This document should be delivered by the July 2015 IETF.
> 
> =-=-=-=-=-=-=-=-
> 
> 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: Steven Barth <[email-masked]>
Date: Fri, 03 Apr 2015 10:07:51 +0200

>I 'll note that RPL already addresses the problems the Margaret listed
>in Dallas, in with a proposed standard doc. The shortest time to
>Homenet is probably to explain how to use RPL at home, and that
>probably requires only a guideline informational document...

Interesting. Does RPL fulfill the requirements for a homenet RP already: supporting source-dest-routes and being autoconfiguring?

Also is there any good linux-compatible C implementation to play with?

Cheers,

Steven

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2015 09:05:22 +0000

Yes to both.

RPL had to address multiple IOT GWs from the start, say one for the power utility, one for cloud access, etc... 
to address this is that it creates multiple instances which are as many logical topologies. By selecting the instance applied to a packet, the source or the first RPL router will force which GW is used.

RPL extends the hop count to include more information, including that instance ID. This is done by a HbH option though arguably the flow label would suffice to carry it should 6MAN allow that usage.

For a good Linux implementation, you may start with Unstrung on OpenWRT. More discussion on ROLL at this very moment.

There is also a discussion on relating  BABEL and RPL operations on ROLL and MANET. For the record, we have RPL running on some of the smallest routers on this planet. But we also have it running of the some of the biggest iron we have at Cisco. This is how versatile RPL can be. This is because RPL is a generic DV operation, designed to be instantiated by the selection of an objective function that will deal with link types, metrics and policies,

Cheers,

Cheers,

Pascal

> Le 3 avr. 2015 à 10:08, Steven Barth <[email-masked]> a écrit :
> 
> 
> 
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 03 Apr 2015 11:53:21 +0200

> We are having an interesting chat on MANET and ROLL where the differences  
> (and core similarities) between BABEL and RPL are elaborated.

There are, however, a number of issues with RPL that make it difficult to
use in the Homenet or the MANET space.  Note that what I say below applies
to RFCs 6550 and 6552, which is not necessarily what any particular RPL
vendor ships.

  - the RPL spec is incomplete and relies on vendor magic (for example,
    there's no link sensing or bidirectional reachability detection in the
    spec);

  - RPL is a large protocol, with many options, and two implementations of
    RPL from different vendors will not necessarily interoperate (for
    example, RPL includes support for no less than three distinct forwarding
    mechanisms -- and perhaps a fourth one, I'm not sure);

  - notwithstanding the omissions above, the RPL spec is a 157 page long
    monster (compare this to the 45 pages of Babel, of which only 20 are
    normative).  I'm supposed to be good at reading this sort of stuff,
    and I'm finding it extremely difficult to work out what is the
    structure of RFC 6552 -- after two days of work on it, I'm still
    grepping.

I am also not entirely convinced that the mechanisms in RFC 6552 are correct
(I think I see a number of race conditions), but I don't understand the
answers that I'm getting from the RPL specialists.

In addition to RFC 6552 and the thread that's being crossposted between
MANET and ROLL, you may want to look at:

    https://hal.inria.fr/inria-00597036/document

Figure 3 on page 14 is my new favourite.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 03 Apr 2015 12:12:57 +0200

> RPL had to address multiple IOT GWs from the start, say one for the
> power utility, one for cloud access, etc...  to address this is that it
> creates multiple instances which are as many logical topologies. By
> selecting the instance applied to a packet, the source or the first RPL
> router will force which GW is used.

Multiple instances of RPL are supported, but I don't see any explicit
support for source-specific routing.  In concrete terms, there's no way
to associate a given source address to an instance ID, so you need to do
that by means outside the protocol.

(That's a little like saying that BGP has support for source-specific
routing because you can use communities to encode source-specific routes.)

> RPL extends the hop count to include more information, including that
> instance ID. This is done by a HbH option

Modifying the data plane so that it supports new IPv6 options is certainly
something that's reasonable in a sensor network.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 03 Apr 2015 12:15:31 +0200

> I'm finding it extremely difficult to work out what is the structure of
> RFC 6552 -- after two days of work on it, I'm still grepping.

[...]
> I am also not entirely convinced that the mechanisms in RFC 6552 are correct

Sorry, that was meant to be 6550 in both cases.

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 4 Apr 2015 11:44:25 +0900

> for truly active consensus is focused on.

Alia - can we put something to that effect in the charter?

There is a real risk that any WG working on standardizing babel will start
proposing lots of changes to the protocol (due to NIH syndrome, general
bikeshedding, etc.), alienating its author and leading to lost time and the
usual failures of design-by-committee.

To avoid this, can we see to it that the charter of any group chartered to
take babel to proposed standard status be chartered to do so without making
substantial changes to the protocol mechanics?

That way, if the protocol works well as is, we'll get a standard soon. If
it doesn't, the WG can always throw up its hands and fail fast.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 3 Apr 2015 23:43:16 -0400

You can definitely charter a WG to use a specific set of documents as a starting point for their work -- that's a solution space WG, and they used to be more common than they are now.  That sort of group will typically formally adopt the documents named in their charter right away, and only change them if they have consensus to do so.  I think that is about as far in that direction as you can go, though.

I don't think you can have a WG that the isn't allowed to make changes to a WG document if they _do_ have consensus to make those changes.

If an AD wants to publish a document as a standards-track document close to as-is and thinks the IETF would have consensus to do that, he or she can just sponsor it for publication without a WG at all.  If I understand correctly, that wouldn't work well in this case, because people active in the Routing Area would not feel comfortable publishing a routing protocol without more review and visibility than that.

Margaret

Sent from my iPhone

> On Apr 3, 2015, at 10:44 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> There is a real risk that any WG working on standardizing babel will start proposing lots of changes to the protocol (due to NIH syndrome, general bikeshedding, etc.), alienating its author and leading to lost time and the usual failures of design-by-committee.
> 
> To avoid this, can we see to it that the charter of any group chartered to take babel to proposed standard status be chartered to do so without making substantial changes to the protocol mechanics?
> 
> That way, if the protocol works well as is, we'll get a standard soon. If it doesn't, the WG can always throw up its hands and fail fast.

---

From: Alia Atlas <[email-masked]>
Date: Sat, 4 Apr 2015 00:25:46 -0400

Lorenzo,

> Alia - can we put something to that effect in the charter?

That is part of the scoping & chartering discussion.  It is a possible
outcome.  I'm
still gathering data (finally next week getting a bit more time to focus)
and listening
to opinions and concerns.
Figuring out the charter scope is part of asking for what are the
requirements and
applicability driving the obvious and deployed interest in Babel?

> usual failures of design-by-committee.

Usually, people are suggesting a change or feature because they need it for
a deployment or customer.  Sometimes,
there are just "interesting ideas" - but requiring implementations and
solid discussion usually make it clear what the
case is and how much applicability/scope creep there is.

Regards,
Alia

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 05 Apr 2015 15:56:06 +0200

Sorry for the delay, I needed to think this over.

>> 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

> easy to implement and troubleshoot protocol can be clearly expressed.

Here's some initial and incomplete input.  I'm just thinking aloud, and
perhaps taking my God-given right to say something stupid.

I'd like the charter to clearly state that no mechanism will be added
unless there is experimental data to show that it is necessary in
realistic situations.  For example, should people believe that an
additional congestion control mechanism is needed, they will need to show
experimental data that prove their point.

I'd like the charter to clearly state that security considerations are
outside the scope of the base spec.  The base spec says "This is
a completely insecure protocol" and I much prefer this frank admission of
failure to a half-baked solution, which would then prevent better security
mechanisms from being developed.  (I am not a security specialist, and
while I'm really glad about RFC 7298 (HMAC auth for Babel), I am not
competent to judge whether it is the only solution.)

I'd like the suggested metrics to remain informative appendices, contrary
to Ted's opinion.  Babel's main claim to fame is that it's an extremely
flexible protocol, and putting the suggested metrics in the body of the
document is contrary with the main goal.  I'd also like the other metrics
(as well as source-specific routing) to remain separate documents, since
they require extensions to the packet format.

There is only one mechanism in the base spec that is not currently used by
implementations -- it's the reliable transport building block defined in
Section 3.3.  It has very low cost (20 lines of code or so in the
C version), so it's a MUST, since it is only useful if implemented by all
nodes.  I have no strong feelings about whether it should stay.

It is not clear to me whether the extension mechanism should be merged
into the base spec.  I think the answer is yes, but in the meantime this
should not delay the publication of
draft-chroboczek-babel-extension-mechanism-04 as an Experimental RFC.
Sorry for the underfull hbox.

The packet format is a little messy, but extremely compact, which is
useful in meshy places.  I believe that Joel Halpern dislikes it, I'm not
so sure I like it myself.  I hold no opinion whether it should be replaced
by a cleaner but more costly format -- it's a difficult choice.

-- Juliusz

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 05 Apr 2015 15:11:22 +0100

Hiya,

Just on one topic...

On 05/04/15 14:56, Juliusz Chroboczek wrote:
> outside the scope of the base spec. 

FWIW, and wearing my security AD hat, I can guarantee that would
generate pushback.

We have BCPs that say we don't do that, e.g. BCP61 and others. And
the effort to get RPL to consider this properly added quite a bit
of delay for that WG partly because they wanted to take the
approach of doing security later which isn't really a good plan
IMO. And of course results tend to be mediocre as well when
folks take the "graft on security later" approach. You may
have an argument that that approach has already been taken,
but how we handle that is IMO one of the differences between
the ISE stream and IETF stream, esp. standards track.

Security in environments like this is tricky though I agree,
esp when one considers the impacts of the various security
mechanisms at the various layers. But that just does not mean
that it's ok to ignore those issues.

S.

PS: The above does not mean that I think it's a problem if a
WG want to produce a base spec and some other RFC that has the
security analysis and defines useful security mechanisms. IMO
so long as those are done at the same time, and so long as the
security mechanisms have the the 2119 keywords associated that
are justified by the security analysis, then that's just fine.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 05 Apr 2015 16:24:06 +0200

> security analysis and defines useful security mechanisms.

I don't think we're disagreeing.  I was careful to say "outside the scope
of the base spec", as opposed to the scope of the WG.

(The base spec is 45 pages long, and can be explained in less than one
hour.  I will fight to keep it that way.)

I'll have a look at the BCP you refer to.

Thanks for your input,

-- Juliusz

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 05 Apr 2015 15:32:52 +0100

> of the base spec", as opposed to the scope of the WG.

You were indeed. And I'm being careful to say that a plan of the
form "produce base spec RCC and only then start to think about
security" will get pushback from me.

And that said, I'm not entirely sure if we're agreeing or not,
but we'd know pretty soon if this gets going, so we're fine for now:-)

S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 05 Apr 2015 16:37:46 +0200

> a plan of the form "produce base spec RCC and only then start to think
> about security" will get pushback from me.

Why?

(If the answer is "read BCP 61", I'll do that, but not right now.)

-- Juliusz

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 05 Apr 2015 15:48:37 +0100

> (If the answer is "read BCP 61", I'll do that, but not right now.)

Partly that and partly the horrible experience with years of delay
with RPL. I inherited a DISCUSS on the base RPL spec in March 2011
from the previous security AD. I can't remember how much that delayed
the base RPL spec, maybe a year or so until we worked out a plan that
was going to not result in security being ignored. And their security
analysis RFC (7416) was only published in Jan 2015. And there was
loads and loads of gnashing of teeth in between for everyone involved.
And I also think the final result would have been better had the
security work been done up front whilst they had more energy and
motivation.

S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 05 Apr 2015 17:17:11 +0200

> (Argh, kilometer long cc list, sorry guys in advance..)

Dropping everyone and his brother too, leaving Homenet and Alia, adding
babel-users and Stephen.

> Sadly enough the more flexible/less code footprint _given system-wide
> IPsec_ approach of OSPFv3 turned out not to be popular. It allowed us to
> secure Babel with just few lines of changes to one script in the hnetd
> implementation, which was neat, but.. :-)

Hmm, if you're using static keying, you're vulnerable to replay.  Does
that mean I should port the replay protection bits from RFC 7298 to the
reference implementation?  They don't frighten me as much as the crypto
bits.

> I am not very fond of making any MUST metric functions either. However,
> what I _would_ like to see is some guidance on metrics ranges that
> should be used and how the combination should approximately work best
> (remember ‘pybabel’s metric=1 + combination using + favors it too much’
> email). Perhaps this could be also just in an appendix.

Point taken.

>> C version),

> I am not very fond of it, as I do not see much of a justification for it
> given the goal of minimality.

See the discussion in Section 3.7.2 of RFC 6126.  I've been planning to
implement that, to see how much it improves behaviour in sparse wireless
meshes.

> E.g. on point-to-point link (or one with few routers), you could send
> stuff very rarely and just use that ack feature to make sure the other
> end is aware of the current state

Hmm... have you noticed the (optional) receiver-driven scheme described in
Section 3.8.2.3?  But yes, you're right, although fine-tuning the details
of your scheme might not be quite obvious.

> I only wonder about the padding TLVs/sub-TLVs

I don't expect anyone to use padding for alignment.  But I'm fond of PAD1
and PADN TLVs, since they don't cost much and often turn out to be useful
for various reasons.

For example, the Babel-RTT extension puts a PADN sub-TLV at the place
where a timestamp will go; then it applies jitter to the outgoing packet,
and patches it with a timestamp at the very last moment.  If the
timestamping fails for some reason, the packet can still go out -- the
PADN will be ignored by the receiver.  Look, Ma, no complex error
handling and no packet drops.  (Credit to Baptiste Jonglez.)

Similarly, suppose you wanted to do MTU probing a la OSPF (or is it IS-IS?),
or wanted to evaluate packet loss for full-size frames only.  In either
case, PADN your Hellos to full MTU, and you're done.

> Especially given multicast-using (default) nature of the protocol, I am
> fond of _a_ solution that fits as much as possible in one MTU packet per
> interval; therefore, more costly format would essentially behave worse
> for networks above certain size (in terms of # of total routes mostly).

I agree.  Still, it might be worthwile to have an expert pore over the
packet format, and see how much he shakes his head.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sun, 5 Apr 2015 08:18:57 -0700

> perhaps taking my God-given right to say something stupid.

My vote is for juliusz as benevolent dictator for life. Can that go in an RFC?

> experimental data that prove their point.

I think in larger lans ECN would be nice as a means of distinguishing
between connectivity loss and congestive loss... but am totally
willing to produce experimental data in favor for or against,
and to wait til I get around to it as part of the upcoming short-RTT work.

> competent to judge whether it is the only solution.)

Agree.

Security has two meanings here, one of which is not useful, one that
may be. The "lets encrypt and authenticate everything" part is not
terribly useful (particularly in a world that still has arp and ra). I see
no reason for e2e encryption here, do see so a small one for authentication,
but am not sure it needs to be e2e.

A part that *usefully* allowed a network to allow a mixture of authenticated
nodes (injecting default routes), while retaining un-authenticated routing
for other nodes would be nice. I only briefly deployed the HMAC auth,
but as the quagga version fell too far behind the mainline, did not gain
enough operational experience with it to have a feel for it. I look forward
to seeing it in babeld-1.7.

... somewhat related ...

I have a smallish bcp38-ish like document for some best current practices
(like filtering out local announcements of non-rfc1918 addresses,
 filtering out route announcements for the hip 1.0.0.0/24, 2001:10::/28,
 and advice to not announce local-only vpn routes) which I could maybe
 finish by Prague. (On the other hand I think it is easier read if on a wiki.)

... But it is the prospect of someone with a laptop announcing the lowest
metric possible default route is through them and out via 3G that is
the biggest hole in the "security" of not just babel, but all non-authenticated
routing protocols (targeted at the home. at least. So far as I know there
are a lot of insecured routing protocol *deployments* in general. Someone
feel free to correct me).

> document is contrary with the main goal.

All routing metrics to date have had various degrees of suckage. Agree.

> I'd also like the other metrics

I am not sure if I share the word "metric" here for source specific routing.
I would support a rollup rfc6126.bis after several more years of deployment
experience.

> Sorry for the underfull hbox.

Can live.

> by a cleaner but more costly format -- it's a difficult choice.

I have no desire to further mess with the wire format at the moment.
I like very much that it carries both ipv4 and ipv6 in the same packet.

-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

---

From: Dave Taht <[email-masked]>
Date: Sun, 5 Apr 2015 09:18:18 -0700

On Sun, Apr 5, 2015 at 8:21 AM, Juliusz Chroboczek
<[email-masked]> wrote:
>> Partly that and partly the horrible experience with years of delay [...]
>> until we worked out a plan that was going to not result in security
>> being ignored.
>
> Stephen, everyone,
>
> I would appreciate an expert opinion on RFC 7298 (HMAC for Babel), perhaps
> by private mail.

Trimming the CC. I found RFC7298 to be a very good read, but me being me,
found reading the code - which is much shorter - only about 1000 lines,
exclusive of the actual implementations of sha1,etc, much more illuminating.

https://github.com/Quagga-RE/quagga-RE/blob/RE-stable-0.99/babeld/babel_auth.c

---

From: Terry Manderson <[email-masked]>
Date: Tue, 7 Apr 2015 02:39:14 +0000

WG,

In reviewing the posts on this thread over the last several days, I note
that no-one spoke strenuously against the Design Team (DT) as chartered.
There were several emails that implied support of the DT, and many others
seeking conditions that the DT take on board comments for their review.

The DT will be chartered as below. I will advise the DT to review this
thread and to take on board the comments that are germane to their work of
selecting the mandatory to implement HOMENET routing protocol.

Thank you for all your comments!

I urge the WG to now focus on the work ahead, and wait patiently for the
DT response in Prague.

Cheers
Terry

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 07 Apr 2015 12:47:53 +0200

> The DT will be chartered as below.

I find the lack of the words "working code", "implementation experience"
or "experimental data" somewhat disquieting.

With frustrated regards,

-- Juliusz Chroboczek

---

From: Ralph Droms <[email-masked]>
Date: Tue, 7 Apr 2015 08:32:23 -0400

> On Apr 7, 2015, at 6:47 AM 4/7/15, Juliusz Chroboczek <[email-masked]> wrote:
> 

I think the umbrella direction for requirements could be considered to cover those specifics:

>> from those.

Terry - you might consider adding a pointer to RFC 7368 as an explicit source of input for the requirements.

- Ralph

---

From: Ray Hunter <[email-masked]>
Date: Wed, 08 Apr 2015 09:23:59 +0200

Ralph Droms wrote:
>> On Apr 7, 2015, at 6:47 AM 4/7/15, Juliusz Chroboczek<[email-masked]>  wrote:
>>
+1 I'd like to see a DT with hands on experience of running Homenet code 
before IETF 93 in Prague, and that they give this appropriate weight in 
any considerations.
> Terry - you might consider adding a pointer to RFC 7368 as an explicit source of input for the requirements.
+1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That 
should be the baseline for any beauty contest of routing protocols for 
Homenet.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 Apr 2015 19:49:56 +0900

> should be the baseline for any beauty contest of routing protocols for

+1, although one would hope that it goes without saying that a routing
protocol that does not meet the requirements in RFC 7368 cannot be chosen.