Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09)

[Dave Taht <[e-mail]>]

On Mon, Jul 23, 2018 at 5:41 AM Ted Lemon <[e-mail]> wrote:
>
> HNCP isn't working for you to distribute IPv6 prefixes?

Can't deploy it without upgrading routers. No incentive to upgrade
routers until source specific is solid again. The HNCP codebase is
rotting and was never quite adaquate enough to replace odhcp(6) and
dnsmasq in the first place. Also I have 80 or so subnets and all I
generally get from each comcast modem is a /60 (last I checked, some
get /56s), and hncp wants to give a publicly routable ipv6
address/subnet to everything.

Given my networks are primarily ipv4 and I don't buy into the dream of
an ipv6 only network, I have a mild preference towards distributing
prefixes via something secure I can deploy along the edge that runs
over the established ipv4 transport, also. IPv4 nat works well with
multiple (potential) exit points with babel and without source
specific ipv6 distributed, ipv6 is used just on the first internal
hops (and if that hop breaks, happy eyeballs helps).

But that's neither here nor there, aside from re-enforcing my point
that source specific be made deployable again. If it wasn't for the
wifi multicast problem, I'd have flattened this network into five big
bridged domains long ago. I was so optimistic 5 years ago...


> On Sun, Jul 22, 2018 at 10:26 PM, Dave Taht <[e-mail]> wrote:
>>
>> In my deployed babel network... I am dreading the source specific
>> change. But I've been prepared to have that flag day for three years,
>> and the ietf processes make me crazy. I have no less than 6 deployed
>> versions of babel in the field (and I mean, in the field, in trees,
>> and on rooftops), spread across 40+ routers, it will take me months or
>> years to replace them all... and the deployment strategy juliusz has
>> outlined is acceptable.
>>
>> In part due to the lack of a good ipv6 address distribution mechanism
>> (slight dig), very little of my network is ipv6 enabled, and the sad
>> way I assign source specific addresses now (ip route show |  grep
>> "from" | pickaddresseslikeslaacdid), ipv6 source specific connectivity
>> either comes back on the reflash/reboot or it doesn't - and ipv4 keeps
>> working. The ipv6 stuff has largely not escaped the lab due to the
>> delays in standardization.
>>
>> due to the address assignment problem, I think very few babel
>> installations are using ipv6 all that much, except in non source
>> specific ways.
>>
>> Let's just get it over with and get the documents AND code out there
>> already. openwrt 18.06-rc2 is out now and it would be great to start
>> testing al the new stuff before it goes final. Warn people in the
>> README.
>>
>> If this were OSPF or BGP or ISIS I'd care more, but babel's deployment
>> is at least 3 orders of magnitude smaller than those.
>>
>> ship it. Move on.
>> On Sun, Jul 22, 2018 at 10:52 AM Juliusz Chroboczek <[e-mail]> wrote:
>> >
>> > > Thank you for reading.
>> >
>> > Our pleasure, as always.
>> >
>> > Denis, I've read your mail twice, and I do not understanding what you are
>> > proposing.  Could you please succintly and clearly explain what it is that
>> > you recommend that the working group should do?
>> >
>> > -- Juliusz
>> >
>> > _______________________________________________
>> > babel mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/babel
>>
>>
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: [phone]
>>
>> _______________________________________________
>> babel mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/babel
>
>


-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: [phone]