Subject: [homenet] pushing the bird faster

From: Dave Taht <[email-masked]>
Date: Sun, 5 May 2013 05:15:05 -0700

I note that in order to speed up the cycle and development time
involving routing advancements, the openwrt team has broken out most
of the routing protocols in openwrt into a separate repository which
can spin faster:

https://github.com/openwrt-routing/packages

Perhaps this could be a home for the enhancements to bird/etc that the
cisco homenet group has been doing?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 7 May 2013 11:15:04 +0000 (UTC)

> cisco homenet group has been doing?

Possibly. I'm not sure how keen they are to have 'big' changes,
though, and looking at
https://github.com/fingon/hnet-openwrt-feed Cisco homenet
implementation requires currently 4 new Lua modules (1 of them
forked version of original with better IPv6 support), forked
versions of dnsmasq/odhcp6c (for prefix class option support),
and BIRD (for external LSA support). 

As it's not very self-contained, I'm not sure how well it would
work there, and as we currently _only_ work with AA base, it
might have issues with people using trunk..

Cheers,

-Markus

---

From: Dave Taht <[email-masked]>
Date: Wed, 8 May 2013 02:07:46 -0700

> and BIRD (for external LSA support).

Unless you wish to maintain these modifications forever, it is helpful to
seek consensus with the mainline developers of these tools to push your
patches in a mutually acceptible form. I would suspect that dnsmasq and
odhcp6c devs would be amiable to a discussion at the very least.

> might have issues with people using trunk..

Perfect! You can continue have your stable release and also establish a
repo(s) for moving them into the ongoing development processes for head of
trunk, so that these standards can be more widely adopted. Or not,
depending on consensus with the devs....

 Please post your patches to the relevant mailing lists. This is the open
source process. It's pretty similar to the ietf process of seeking
consensus except that it's incremental and the code needs to compile at
every stage.

You end up with a lot of eyeballs on the code and more feedback from an
increasingly large userbase.

I'm very happy (and relieved) to say that as of 3 weeks back everything
important from CeroWrt has finally been pushed into openwrt, and if I were
to wipe out on the autobahn tomorrow, it really wouldn't matter all that
much. (to the project!)

We'll (cerowrt folk) will take a look at this repo too to see what can get
folded back into Cero, for now, but a better path is to the core devs of
the individual packages. "Feed the upstream".

Does anyone know where the hipnet stuff lives?

> Cheers,
>
> -Markus
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

---

From: Steven Barth <[email-masked]>
Date: Wed, 08 May 2013 11:20:58 +0200

On 08.05.2013 11:07, Dave Taht wrote:
> Unless you wish to maintain these modifications forever, it is helpful
> to seek consensus with the mainline developers of these tools to push
> your patches in a mutually acceptible form. I would suspect that dnsmasq
> and odhcp6c devs would be amiable to a discussion at the very least.

Speaking for odhcp6c I have looked into the homenet changes yesterday 
and I don't see it as a big hassle to merge these features into the main 
branch at some point once they have an official IANA number and the 
specs are somewhat stable.

Also feel free to contact me if you are thinking about getting anything 
IPv6-related upstream to OpenWrt and we can discuss that or you can of 
course also use the official channels, mailing lists and so on.

---

From: Dave Taht <[email-masked]>
Date: Wed, 8 May 2013 02:23:22 -0700

On Wed, May 8, 2013 at 2:20 AM, Steven Barth <[email-masked]> wrote:

> Speaking for odhcp6c I have looked into the homenet changes yesterday and
> I don't see it as a big hassle to merge these features into the main branch
> at some point once they have an official IANA number and the specs are
> somewhat stable.
>

#ifdef HOMENET
do_not_quite_iana_approved_stuff()
#endif

not work for you?

I would certainly like to get more users of the code on more platforms at
this point.

-- 
Dave Täht

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 8 May 2013 12:27:46 +0300

On 8.5.2013, at 12.20, Steven Barth <[email-masked]> wrote:
> Speaking for odhcp6c I have looked into the homenet changes yesterday and I don't see it as a big hassle to merge these features into the main branch at some point once they have an official IANA number and the specs are somewhat stable.
> 
> Also feel free to contact me if you are thinking about getting anything IPv6-related upstream to OpenWrt and we can discuss that or you can of course also use the official channels, mailing lists and so on.

That's underlying problem with both dnsmasq and odhcp6c forked changes - we use IOS-specific prefix class option # that is NOT from IANA, and I'd rather not see it in wide use for obvious reasons. 

And as a general point on odhcp6c front, I think a better method of expressing 'extra prefix-specificoptions' should be found than just adding more entries to the CSV list of ENV_PREFIXES. In my experience, long lists of CSV-style entries become rather awkward to handle if you want to be futureproof; key=value within (or something else) is much better.

Cheers,

-Markus

---

From: Steven Barth <[email-masked]>
Date: Wed, 08 May 2013 11:32:23 +0200

> And as a general point on odhcp6c front, I think a better method of expressing 'extra prefix-specificoptions' should be found than just adding more entries to the CSV list of ENV_PREFIXES. In my ex…
Yes, I agree. Feel free to do that for the prefix class. I guess I will 
eventually do that for the prefix exclusion feature as well.

---

From: Dave Taht <[email-masked]>
Date: Wed, 8 May 2013 03:22:36 -0700

On Wed, May 8, 2013 at 2:27 AM, Markus Stenberg <[email-masked]>wrote:

> branch at some point once they have an official IANA number and the specs
> are somewhat stable.
> >
> That's underlying problem with both dnsmasq and odhcp6c forked changes -
> we use IOS-specific prefix class option # that is NOT from IANA, and I'd
> rather not see it in wide use for obvious reasons.
>

I have few problems with IOS setting a default standard, open source
following it, and the IANA blessing it later. :) That said, what is the
status of the IANA application? Link?

-- 
Dave Täht

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 8 May 2013 13:28:53 +0300

On 8.5.2013, at 13.22, Dave Taht <[email-masked]> wrote:
> I have few problems with IOS setting a default standard, open source following it, and the IANA blessing it later. :) That said, what is the status of the IANA application? Link?

IANA application is applicable iff draft is about to go RFC; I'm not related to that author in any shape or form, so no clue (not even sure if draft is going anywhere, in IETF86 there was muted response at best to it if I remember right).

Cheers,

-Markus

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 8 May 2013 19:34:18 +0900

On Wed, May 8, 2013 at 7:28 PM, Markus Stenberg <[email-masked]>wrote:

> IANA application is applicable iff draft is about to go RFC; I'm not
> related to that author in any shape or form, so no clue (not even sure if
> draft is going anywhere, in IETF86 there was muted response at best to it
> if I remember right).
>

What about the non-prefix colouring work, like source-based routing, prefix
allocation, basic DHCPv6 fixes, etc.? Could that be merged upstream?

For the prefix-colouring work, you could always commit the code using a
vendor option and then update it when/if the draft gets traction?