Re: [Cerowrt-devel] [homenet] pushing the bird faster

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]

On Tue, May 7, 2013 at 4:15 AM, Markus Stenberg <markus.stenberg@iki.fi>wrote:

> Dave Taht <dave.taht <at> gmail.com> writes:
> > 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?
>
> 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).
>

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.



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

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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
Dave Täht

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

[-- Attachment #2: Type: text/html, Size: 3911 bytes --]

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Steven Barth]

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.

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Wed, May 8, 2013 at 2:20 AM, Steven Barth <cyrus@openwrt.org> wrote:

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

#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

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

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Markus Stenberg]

On 8.5.2013, at 12.20, Steven Barth <cyrus@openwrt.org> wrote:
> 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.

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

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Steven Barth]

On 08.05.2013 11:27, Markus Stenberg wrote:
>
> 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.
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.

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

On Wed, May 8, 2013 at 2:27 AM, Markus Stenberg <markus.stenberg@iki.fi>wrote:

> On 8.5.2013, at 12.20, Steven Barth <cyrus@openwrt.org> wrote:
> > 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.
>
> 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

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

[-- Attachment #2: Type: text/html, Size: 1971 bytes --]

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Markus Stenberg]

On 8.5.2013, at 13.22, Dave Taht <dave.taht@gmail.com> wrote:
> 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?

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

Re: [Cerowrt-devel] [homenet] pushing the bird faster

[Lorenzo Colitti]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Wed, May 8, 2013 at 7:28 PM, Markus Stenberg <markus.stenberg@iki.fi>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?

[-- Attachment #2: Type: text/html, Size: 1040 bytes --]