[quagga-dev 16533] Re: [PATCH v3] nhrpd: implement next hop resolution protocol

[Vincent JARDIN]

Le 12/01/2017 à 15:31, Timo Teräs a écrit :

This provides DMVPN support and integrates to strongSwan. Please read
README.nhrpd and README.kernel for more details.


I do like the value that NHRP brings for DMVPN support. Sorry, I did not 
review the code due to lack of time, but since it is quite independent 
code, I feel it brings lot of value to start with.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16328] Re: Quagga 1.1.0 released

[Vincent JARDIN]

Le 20/10/2016 à 12:29, Nicolas Dichtel a écrit :

I vote to remove them also.

+1

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16198] Re: Proposed 8 testing Update

[Vincent JARDIN]

Le 06/10/2016 à 17:01, Philippe Guibert a écrit :

No.  Please merge to master ASAP.
>

+1

+1

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16167] Re: Proposed 8 testing Update

[Vincent Jardin]

Le 4 octobre 2016 3:58:59 AM Alexis Rosen 
<quagga-us...@alexis.users.panix.com> a écrit :



On Oct 3, 2016, at 11:21 AM, Vincent JARDIN <vincent.jar...@6wind.com> wrote:

Le 03/10/2016 à 15:08, Paul Jakma a écrit :


My inclination is to release as is. Document regressions. Try fix them
later.

+1


ISTM the large majority of quagga users will not see any such 
documentation. They'll build/install using their distro's package manager.


Then when things break, they'll come here looking for support, or else 
decide that quagga sucks and try something else.




Agree. I do not think the intents were to announce a new stable tag/release 
but more to move forward so shared work and major OSPF fixing can happen on 
the head.


Paul? Martin?





___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16163] Re: Proposed 8 testing Update

[Vincent JARDIN]

Le 03/10/2016 à 15:08, Paul Jakma a écrit :


My inclination is to release as is. Document regressions. Try fix them
later.

+1

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 16158] Re: Anyone at netdev conference in Tokyo?

[Vincent Jardin]

I am. See you on Wednesday.


Le 3 octobre 2016 11:33:58 "Martin Winter"  a écrit :


Any Quagga folks at the netdevconf (http://www.netdevconf.org/1.2/) in Tokyo?

If yes, ping me - would be good to get together for a beer.

- Martin Winter
  mwin...@opensourcerouting.org

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15850] Re: Time for an experiment? (Was: focus: patchwork drain vs project updates)

[Vincent JARDIN]

Le 05/07/2016 12:11, Lou Berger a écrit :

If there are not roundskeepers  interested in trying this what's the harm?


we'll unfocus and we'll never close the current effort.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15798] Re: [PATCH] bgpd: Add total number of routes received from neighbours to bgp summary

[Vincent JARDIN]

Le 30/06/2016 12:59, Paul Jakma a écrit :

* bgp_vty.c: (bgp_show_summary) The sum of the routes received from
   each neighbour can be interesting/useful.  Add a line with this to
   end of 'show ...  bgp ...  summary'.

   Note, this is also available from 'show bgp  
   statistics', along with more.


It is an easy and convenient one.

Acked-by: Vincent Jardin <vincent.jar...@6wind.com>

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15788] Re: [PATCH] lib: vty_prefix_list_install should validate afi/safi

[Vincent JARDIN]

Le 29/06/2016 16:56, Paul Jakma a écrit :

* lib/plist.c: (vty_prefix_list_install) Check afi/safi is supported and warn
   if not, as a safeguard and to ensure the user is warned, if somehow that
   code is ever called for non-IP AFI.


Acked-by: Vincent Jardin <vincent.jar...@6wind.com>

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15787] Re: [PATCH] ospfd: 'ip ospf network' interface should down iface before changing type

[Vincent JARDIN]

Le 29/06/2016 16:56, Paul Jakma a écrit :

* ospf_vty.c: (ip_ospf_network) This function changes the interface type
   and only then downs/ups the interface if already up.  So the down happens
   with the interface type already altered.  However, the interface type
   can have major ramifications for how underlying state is stored/indexed,
   which may cause problems.

   Further, bit of an encapsulation violation to twiddle state here.
   (no_ip_ospf_network) ditto.
* ospf_interface.c: (ospf_if_reset_type) New function to reset the OSPF
   interface type on an interface. Ensure the interface is downed before
   the type is changed.
* ospf_interface.h: (ospf_if_reset_type) Export, for ospf_vty.c


Acked-by: Vincent Jardin <vincent.jar...@6wind.com>

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15780] ack't done, include patch?

[Vincent JARDIN]

Paul,

This patch is ack't:
 http://patchwork.quagga.net/patch/1986/

can you apply it?

Thank you,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15777] focus: patchwork drain vs project updates

[Vincent JARDIN]

All,

There are many messages to update Quagga's organization. It is a good 
way to proceed and we'll have to do something.


However, from facts, we all see that
  http://patchwork.quagga.net/
needed to be drained. Some patches were 4y+ old.

So, I strongly believe that for the benefits of everyone,
  1st: patchwork needs to be drained,
http://patchwork.quagga.net/bundle/paul/round-8/

  2nd: we need all the ff to be applied onto the head:

http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/8/proposed/ff

Currently, it is being done by Paul. So Thank you!

  3rd: finish the drain of patchwork (round 9?). Maybe it could be 
started in parallel while Paul is finishing the round 8. To do it in 
parallel, it would/could be expedite if patchwork could get some ack't, 
for instance,

  http://patchwork.quagga.net/patch/1652/
no one did ack't it. It is important to get a review or an ack.

  4th: then, let's update Quagga's organization for the benefits of 
everyone. Many comments from Lou/Martin/Jafar/Paul/Donald/Olivier/etc. 
are very valid.


So, instead of getting many emails about new Quagga's organization, I 
would rather prefer to see emails that review patches. Then, once 
patches will be merged into the head, let's fix the organization.


Let's be focus all together,
 Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15774] Re: Quagga project governance

[Vincent JARDIN]

Le 29 juin 2016 00:24, "Vincent JARDIN" <vincent.jar...@6wind.com> a écrit :
>
>
> > Let us move forward and not continue to be distracted by finger
pointing. We all like to see progress.
> >
>
> Right now, the only think that cares is this drain of patchwork and to
get the ff round 8 into the head. I saw this morning LOT of patchwork's
entries that are queued. So I guess that we are closed to get them into the
head. Is my understanding correct?

Some URLs:
  http://patchwork.quagga.net/bundle/paul/round-8/

http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/8/proposed/ff
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15773] Re: Quagga project governance

[Vincent JARDIN]

> Let us move forward and not continue to be distracted by finger pointing.
We all like to see progress.
>

Right now, the only think that cares is this drain of patchwork and to get
the ff round 8 into the head. I saw this morning LOT of patchwork's entries
that are queued. So I guess that we are closed to get them into the head.
Is my understanding correct?
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15767] Re: *: get rid of "MTYPE 0" + ff/8 upstream merges

[Vincent JARDIN]

http://patchwork.quagga.net/bundle/paul/round-8/


it is a great information and a nice drain of patchwork. I do see a:
  2012-09-12 patch being applied :D

Just to confirm, does it mean that anything from Paul's round-8 bundle:
  http://patchwork.quagga.net/bundle/paul/round-8/
do show up into:

http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/8/proposed/ff
?

If yes, then, when does

http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/8/proposed/ff
become head into http://git.savannah.gnu.org/cgit/quagga.git/log/?

I feel I am asking something I should know, but I prefer to ask so I and 
everyone on the list can see this drain of patchwork beeing applied.


Thanks,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15768] Re: Quagga project governance

[Vincent JARDIN]

Le 28/06/2016 16:03, Lou Berger a écrit :

On 06/28/2016 09:54 AM, Donald Sharp wrote:

>  I
>won't be paying full attention to any review comments because I will
>be on vacation the 1-10 of July, but hope to resolve all issues upon
>getting back in a timely manner.

Being forever the optimist - we'll plan/hope to have all issues resolved
*before*  you return!


I can hardly follow all the emails, there are too many!

My take is simple, from previous Paul's comment I do see:
  http://patchwork.quagga.net/bundle/paul/round-8/
and

http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile%2Fpatch-tracking%2F8%2Fproposed%2Fff

if that's show up into head within few days, we'll *all be happy, am I 
correct*? Then, we'll be able to slowly restart to be back to a normal 
project/life that can evolve based on recent 
Lou/Martin/Paul/Donal/myself/Olivier/etc. comments.


Thank you,
  Vincent


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15672] Re: [PATCH 07/16] bgpd: fix memory leaks in show commands

[Vincent JARDIN]

Hello,

Is this patch that I did ack't applied?

Regards,
Philippe


Please, Philippe, again, no HTML email (even in 2016 :D), otherwise it 
is hardly indexed:

https://lists.quagga.net/pipermail/quagga-dev/2016-June/015752.html


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15624] Re: RFC: plugin (DSO) + hook support

[Vincent JARDIN]

Le 16/06/2016 16:58, David Lamparter a écrit :

Now, for the "yes" part... there are quite a few things that make sense
to modularise:
- SNMP, if it stays around
- Sproute's/Avneesh's Protobuf stuff
- OSR's/my Cap'n Proto stuff
- the entire CLI
- kernel backends


+1
I like the idea of modularisation of these parts.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15604] Re: [PATCH 07/16] bgpd: fix memory leaks in show commands

[Vincent JARDIN]

Philippe,

please, don't post HTML, it does not bring values to the archives:
  https://lists.quagga.net/pipermail/quagga-dev/2016-June/015678.html

An HTML attachment was scrubbed...
URL: 



Thank you,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 15312] Re: Better APIs for Quagga (JSON PubSub & ReST), OVSDB & OpenSwitch

[Vincent JARDIN]

Le 18/05/2016 16:43, Paul Jakma a écrit :

On Wed, 18 May 2016, Vincent JARDIN wrote:


I would like to see splited patch series:
  1- the features only so it can be used with Linux kernel, BSD, etc...
  2- ovsdb related ones, json,

so it'll be easier to understand. The current OpenSwitch Quagga trie
is mixing both.


Yes, there's a bunch of other stuff in there too.


First, starting with 1- would help to understand the remaining part
for 2-


I think there's an architecture discussion that can be had, without
having to have the "cleaned up and rebased onto head, ready to be
applied" patches. Though, the link to the diff can still be used to
guage roughly the extent of what's being proposed. Which is basically:

- Replace the code serialising between telnet/Zserv and internal state
   with code to do so to the OVSDB embedded DB, via the the OVSDB API.

   (I could see a case for writing a lighter API to the OVSDB protocol
though, but the OVS OVSDB-API mods exist, at least for bgpd and ospfd;
and there's a bunch of engineers who understand that API and
could help  port the rest of the protocols).

- not done in OPS I think, but move the old telnet/string-vty code out to
   old files, make it build-time conditional, and deprecate.

- Replace vtysh/ with the OpenSwitch ops-cli vtysh, which uses OVSDB.

- Potentially suck in the OPS ReST daemon?


then, same question than Lou: how does it run if OVS is not installed?


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14865] Re: Monthly Quagga Meeting

[Vincent JARDIN]

David's proposal needs to be analysed. It can help to open new path to
management APIs.
Le 10 mars 2016 16:47, "Donald Sharp"  a écrit :

> The quagga monthly meeting is next tuesday.  If you would like an invite,
> please let me know.
>
> If you have something that you would like to talk about please let me know
> and I can add it to the agenda.
>
> Current agenda items that I would like to talk about:
>
> 1) Proposed branching scheme, sent under cover of another email
> 2) Call for more gatekeepers.  Please self nominate!
>
> Additionally David Lamparter has generously agreed to give a presentation
> on his current cli api abstraction work, which we will be seeing
> immediately after all other agenda items have been accounted for.
>
> thanks!
>
> donald
>
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14863] Re: Release 1.0.20160309 of Quagga

[Vincent JARDIN]

+1
Le 10 mars 2016 17:10, "Dinesh Dutt"  a écrit :

> Thanks Donald, and the rest of the maintainers in getting a 1.0 out,
>
> Dinesh
>
> On Thu, Mar 10, 2016 at 4:33 AM, Donald Sharp 
> wrote:
>
>> Quagga 1.0.20160309 has been released.
>>
>>
>> This release addresses Security Vulnerability VU #270232.
>>
>> Users using VPNv4 to untrusted peers and zebra that have
>>
>> untrusted clients talking to it are advised to upgrade to
>>
>> this release.
>>
>>
>> This release is up on Savannah or download at:
>>
>>
>> http://download.savannah.gnu.org/releases/quagga
>>
>>
>> http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.gz
>>
>>
>> http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.xz
>>
>>
>> http://download.savannah.gnu.org/releases/quagga/quagga-1.0.20160309.tar.asc
>>
>>
>> If you encounter a “404” error, Savannah mirrors are probably
>>
>> still synchronizing the files, please give it another day.
>>
>>
>> Major user-visible changes:
>>
>> [quagga] - Namespace VRF Support has been added.
>>
>> [lib] - Add 'show commandtree'
>>
>> [bgpd] - vpnv4 and vpnv6 handling has been included.
>>
>> [bgpd] - Add 'set metric (rtt|+rtt|-rtt)' to route map handling.
>>
>> [bgpd] - Addition of 'show ip bgp dampening' command tree.
>>
>> [bgpd] - If route-map does not exist default to DENY for redistribute
>> statements
>>
>> [bgpd] - Lower default 'timers connect' in BGP to 10 seconds.
>>
>> [bgpd] - Enable "bgp log-neighbor-changes" by default
>>
>> [bgpd] - Add support for timer commands with peer-group syntax
>>
>> [bgpd] - Extend Dump to allow Extended Time Format
>>
>> [babeld] - Removed from the distribution.
>>
>> [isisd] - Allow the adjustment of lsp-mtu
>>
>> [isisd] - Allow the import of routes from other protocols
>>
>> [ospfd] - Add per interface 'ip ospf area' command
>>
>> [ospfd] - Lower the default OSPF spf timers to '0 50 5000'
>>
>> [ripngd] - Add ECMP support
>>
>> [pimd] - Add multicast static routes.
>>
>> [pimd] - Add ability to set DR priority for an interface
>>
>> [pimd] - Add ability to modify hello and hold timers per interface
>>
>> [vtysh] - Add 'show thread cpu ..' and 'show work-queues'
>>
>> [vtysh] - Add 'show run ' command
>>
>> [vtysh] - Fix history handling
>>
>> [solaris] - Fix compilation issues.
>>
>>
>> Distributor-visible changes:
>>
>> --enable-opaque-lsa is removed.  This is considered industry
>>
>>   default and there should be no need to specify at compile time
>>
>>   to include this feature
>>
>>
>> --enable-ospf-te is removed.  This is considered industry
>>
>>   default and there should be no need to specify at compile time
>>
>>   to include this feature
>>
>>
>> --enable-pimd is default.  This will allow compile time issues
>>
>>   to be caught before they become a problem
>>
>>
>> --enable-vtysh is default.  This will allow compile time issues
>>
>>   to be caught before they become a problem
>>
>>
>> --enable-werror has been added.  If turned on, compilation will
>>
>>   turn all warnings into errors
>>
>>
>> --enable-babeld has been removed.  The babel daemon has been
>>
>>   removed from Quagga distribution.
>>
>>
>> Thanks!
>>
>>
>> donald
>>
>> ___
>> Quagga-dev mailing list
>> Quagga-dev@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-dev
>>
>
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14743] Re: scrap & rewrite memtypes handling

[Vincent JARDIN]

this patchset replaces the 1990s-era memory allocation tracking
with a 2010s-era memory allocation tracking.  Particularly, it
removes the neccessity to maintain a centralised list of MTYPEs
in the library.  Daemons can now just define their own MTYPEs on
the fly, with per-file static scope even.

The patchset is a drop-in rewrite that does _not_ require changes
to the code making use of the allocators.  There are new
foo_memory.[ch] files in each daemon managing the MTYPEs.

To bring this to "perfection", the definitions from these files
should wander into the individual files using them.  I did that
only for lib/, the remainder is left as an exercise to the reader
;)  (Truthfully I didn't want to touch every single file in
tree.)

This patchset does NOT apply on master.  It applies on top of
"lib: fix vrf_bitmap leak in zclient_free()".



LGTM, I like the mechanics of this patch. It is a nice cleanup.

Acked-by: vincent.jar...@6wind.com

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14559] Re: gerrit vs patchwork vs git bz vs GitLab

[Vincent JARDIN]

My concerns, taking my TE patches as examples, is that it is hard to
work out of the Quagga Git Tree without the possibility to commit
directly on git. We are in the case that original patches have been
patches (patch of patch) and need new corrections (patch of patch of
patch). Which is hard to follow and then to prepare a correct set of
clean patches to be apply on the main tree.


+1



So, IMHO, Gerit seems to be the good tools as during the review, we
could add some corrections/modifications without the necessity to create
a new set of patches. Then, create a dedicated branch per set of patches
(e.g. Paul do that for TE with quagga-lls_te branch) will be fine as it
allows an easy isolation per topics. Now, it remains the permissions
management, but if Atlassian allows that, it will be fine.


I'd like to avoid commercial solutions like Atlassian since they can 
change their policies. However, if Atlassian is *much* better and good 
enough for upcoming 5y, let's go with Atlassian.


Martin,

do you have a breakdown analyzing Atlassian+bitbucket vs 
git+gerrit+jenkins? I guess, you did check it and you saw benefits, your 
inputs would be welcomed.


Best regards,



Regards,

Olivier

Le 20/01/2016 01:20, Martin Winter a écrit :

Pushing patchwork patches into a git would be trivial for me to do (ie
after some passed initial test as patches)

If the community likes this, then let me know and we could figure out
details (branch? Potentially create new branch for each patchwork?)

BTW: Atlassian git (Bitbucket server) allows permission per branch -
would be easy to lock main branch(es) to maintainers without locking
everything.

- Martin

On Tue, Jan 19, 2016 at 3:36 PM, Vincent JARDIN
<vincent.jar...@6wind.com <mailto:vincent.jar...@6wind.com>> wrote:

On 19/01/2016 20:59, Kei Nohguchi wrote:

the original reason, or pain, with the patchwork?


benefit of patchwork: simple
issues of patchwork: very limited tracking and very light
integration with git (git review is missing).


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net <mailto:Quagga-dev@lists.quagga.net>
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev


--
logo Orange <http://www.orange.com>

Olivier Dugeon
Senior research engineer in QoS and network control
Open Source Referent
Orange/IMT/OLN/WTC/IEE/OPEN

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dug...@orange.com <mailto:olivier.dug...@orange.com>




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14562] Re: gerrit vs patchwork vs git bz vs GitLab

[Vincent JARDIN]

On 20/01/2016 12:27, Martin Winter wrote:

Happy to talk about my impressions at the next call.

Also, I’m not sure if there is any reason why things can’t be mixed -
i.e. Atlassian Bitbucket
for git with gerrit for code review.


there is no emergency. But thanks everyone for checking. On my side, 
I'll do my light homework on gitlab (Paul) and Atlassian (Martin).


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14468] Re: Project update: VRF-device integration and BGP multi-instance as VRFs

[Vincent JARDIN]

It looks good. Which patch serie to check?
Le 8 janv. 2016 07:09, "Vipin Kumar"  a écrit :

> Significant progress has been made on this project. I had sent a few
> emails to quagga-dev outlining the approach for this project -- to leverage
> current VRF lib and BGP multi-instance support. We had a fruitful
> discussion about that and the config model as well.
>
> Will be sending the changes(with explanations) to the data-structures like
> vrf, zebra_vrf and interface soon. And also some of the new trees/lists
> that were needed to keep vrf (devices) within a name-space, take care of
> forward-referencing of VRFs, and deal with challenges associated with
> address notifications via netlink, etc.
>
> Created a new data-structure zebra_ns, so that name-space and vrf device
> models don't just co-exist, but also work in hierarchical way to possibly
> scale the number of vrfs/instances further.
>
> All the configuration/show/clear is  by vrf-device name, implementation
> however internally still uses the vrf-id for efficiency reasons. vrf-device
> index generated by the kernel is used as the vrf-id.
>
> We will also release/submit patches with descriptions in incremental
> (logical) batches as testing/sanities progress and clears.
>
> For now, here are some actual outputs based on the current implementation
> of this project.
>
> *1. Sample Running config*
>
> bgp multiple-instance
> !
> !
> interface swp1 vrf boo
>  link-detect
> !
> interface swp2 vrf foo
>  link-detect
> !
> interface swp3 vrf zoo
>  link-detect
> !
> vrf boo
> !
> vrf foo
> !
> vrf zoo
> !
> router bgp 65001 vrf boo
>  neighbor 11.0.0.2 remote-as 65001
>  address-family ipv4 unicast
>   redistribute static
>   neighbor 11.0.0.2 activate
>  exit-address-family
> !
> router bgp 65001 vrf foo
>  neighbor 11.0.1.2 remote-as 65001
>  address-family ipv4 unicast
>   redistribute static
>   neighbor 11.0.1.2 activate
>  exit-address-family
> !
> router bgp 65001 vrf zoo
>  neighbor 11.0.2.2 remote-as 65001
>  address-family ipv4 unicast
>   redistribute static
>   neighbor 11.0.2.2 activate
>  exit-address-family
> !
> ip route 10.10.10.10/32 Null0 vrf boo
> ip route 11.11.11.11/32 Null0 vrf foo
> ip route 12.12.12.12/32 Null0 vrf zoo
> !
>
>
>
> *2. New config modes*
>
> * Global VRF*
>
> r1(config)#?
>   ..
>   vrf  Select a VRF to configure
>   ..
> r1(config)# vrf
>   NAME  VRF's name
> r1(config)# vrf foo
>   
> r1(config)# vrf foo
> r1(config-vrf)#
>
> Note: This mode works just the way it is for interfaces, i.e. quagga can
> hold the config and (in future) commands within it, VRF becomes active
> (usable by protocols BGP, static, ..) only after its been created in kernel
> and learnt by quagga via netlink interface.
>
>
> * Interface VRF*
>
>
> r1(config)# interface swp2
>   
>   vrf   Specify the VRF
> r1(config)# interface swp2 vrf
>   NAME  The VRF name
> r1(config)# interface swp2 vrf foo
>   
> r1(config)# interface swp2 vrf foo
> r1(config-if)#
>
>
> * BGP VRF*
>
> r1(config)# router bgp 65001
>   
>   view  BGP view
>   vrf   BGP VRF
> r1(config)# router bgp 65001 vrf
>   WORD  View/VRF name
> r1(config)# router bgp 65001 vrf foo
> r1(config-router)#
>
>
>Note: BGP VRF instances (struct bgp) have some state of their
> own now.Which comes  handy as and when VRF creation/deletion is
> learnt by BGP via zebra api.
>  bgp_create() -> bgp_instance_up() ->
> bgp_instance_down() ->bgp_delete ()
>
> When BGP instance is configured as view, it will act
> in view mode just like it used to.
> Introduced instance type - view or vrf, so
> implementation can differentiate as needed.
>
> *3. Sample (of a few) show commands*
>
> *r1# show vrf*
> vrf boo id 7 table 10
> vrf foo id 8 table 11
> vrf zoo id 9 table 12
> r1#
>
> *r1# show interface vrf foo*
> Interface swp2 is up, line protocol is up
>   PTM status: disabled
>   vrf: 8
>   Description: r3
>   index 4 metric 0 mtu 1500
>   flags: 
>   HWaddr: 00:02:00:00:00:0a
>   inet 11.0.1.1/24
>   inet6 fe80::202:ff:fe00:a/64
>   ND advertised reachable time is 0 milliseconds
>   ND advertised retransmit interval is 0 milliseconds
>   ND router advertisements are sent every 600 seconds
>   ND router advertisements lifetime tracks ra-interval
>   ND router advertisement default router preference is medium
>   Hosts use stateless autoconfig for addresses.
>
>
> *r1# show  ip bgp vrf foo summary*
> BGP router identifier 11.0.1.1, local AS number 65001 vrf-id 8
> BGP table version 5
> RIB entries 9, using 1080 bytes of memory
> Peers 1, using 16 KiB of memory
>
> NeighborVAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
>  State/PfxRcd
> r3(11.0.1.2)4 65001 134 135000 00:06:37
>  4
>
> Total number of neighbors 1
> r1#
>
> *r1# show ip bgp vrf foo*
> BGP table version is 5, local router ID is 

[quagga-dev 14327] Re: [PATCH 81/89] ospfd: Add unnumbered interface support

[Vincent JARDIN]

I am fine with this specific patch for unnumbered interfaces.

It would be better if it is not into the serie, but since the serie is 
bringing lot of other good things that I am ok to stay as it is.


reviewed-by: vincent.jar...@6wind.com

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14318] Re: Quagga LPM and GPU Acceleration

[Vincent JARDIN]

You should have a look to the SPF / Dijkstra compute from OSPF. It is a
good fit for GPUs.

My 2 cents,
Le 21 déc. 2015 19:23, "Donald Sharp"  a écrit :

> They are in table.c: route_node_match and route_node_lookup.  I suspect
> there will need to be some fairly serious rewrite of the code in order to
> take advantage of GPU's.
>
> The reality though is that I don't think these are the current bottlenecks
> in handling large #'s of routes and peers in the code.  I would point you
> towards perf as a starting point here.
>
> donald
>
> On Mon, Dec 21, 2015 at 3:18 AM, M.Saeed Ansari 
> wrote:
>
>> Dear Friends,
>>
>> I want to do some of CPU consumer task of Quagga with GPU.
>> I need to know where are longest prefix match and other data-flow task
>> functions and how can i change their code?
>> I want to mix OpenCL with Quagga code to do tasks with GPU in this
>> project.
>>
>> Regards,
>> Saeed
>>
>> ___
>> Quagga-dev mailing list
>> Quagga-dev@lists.quagga.net
>> https://lists.quagga.net/mailman/listinfo/quagga-dev
>>
>
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14262] Re: VPN routing architecture and requirements

[Vincent JARDIN]

On 16/12/2015 10:44, Paul Jakma wrote:

Also, since you ask I/we care about:
1) BGP controlled v4 and v6 L3VPNs, RFCs: 4760, 4360, 4364, 4659, 5512,
5566 RFC4364,4659



(and have code in various stages of readiness for upstreaming, and
have
 previously posted the core set of these changes here.)


We should look at those again. Have you kept them updated to more recent
git?


even if not updated, it can be used as a Request For Comment.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14250] Re: VPN routing architecture and requirements

[Vincent JARDIN]

If I can add on top of that, a big user of this support will be Openstack:
  https://wiki.openstack.org/wiki/Neutron/MPLSVPNaaS
and
  https://github.com/openstack/networking-bgpvpn

let's deep dive after season holidays.

best regards,
  Vincent

On 15/12/2015 23:33, Lou Berger wrote:

Hi Paul,
 Do you have any thoughts on how you'd like to have this discussion?

Some detailed responses below.

On 12/15/2015 10:34 AM, Paul Jakma wrote:

Hi,

I'd like to figure out what the right architecture is to support VPN
routing. I'm not terribly interested in them myself, but it seems they're
not going away and there are various people interested in adding things in
this area.

I'd like to try pin down which VPN routing technologies are of interest,
and what the requirements and commonalities are. It'd be good to be learn
from ospfd/ospf6d and ripd/ripngd, and try do a bit better.

VPN routing, to my mind, mostly is about mapping some set of information
to a routing context, potentially in some series, to retrieve routing
information[1]. E.g. perhaps some kind of interface ID to some context
identifier to index into the final prefix-trie.


I/we think both routing and NVO3/NVA overlay control are of interest.


* Which VPN routing technologies are people interested in? (L3VPN)


Also, since you ask I/we care about:
1) BGP controlled v4 and v6 L3VPNs, RFCs: 4760, 4360, 4364, 4659, 5512,
5566 RFC4364,4659
  (and have code in various stages of readiness for upstreaming, and
have
   previously posted the core set of these changes here.)
2) BGP controlled  EVPNs
 (we have a non-standard EVPN-inspired implementation, and expect
will have
 lots of discussion on this, once the core/base VPN discussions take
place.)


* What kind of relations and lookups do we need, in terms of what kind of
identifiers (ifindices? VRF IDs? RDs? etc..)?

yes, interfaces (physical and logical), RDs and RTs.

* At which places do you want to exchange routing information?


A very good / interesting discussion.  This goes to the discussion on
list at the end of last month.  It's important to not forget all the
features that may be needed during import/export, in particular
filtering/route maps.



I think it'd be really good to get all these details down in one place, so
we can figure out what commonalities there are, and avoid having set after
set of "similar but different" bits of code going in here and there.

We sometimes pay a heavy cost down the road for the want of relatively
small amounts of up-front work.

1. In an ideal world, we'd just prepend these things to each other and put
them into the address label and put that information in the packet. Then
routing lookup could be a lot more straight-forward and regular. But, hey
32-bits is enough for everyone...

regards,


Thanks for getting the discussion started,
Lou



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14042] Re: VRF global and protocol specific config

[Vincent JARDIN]

On 30/11/2015 16:25, Paul Jakma wrote:

On Mon, 30 Nov 2015, Vincent JARDIN wrote:


There are some networking datamodels with different options (SDN)
having their logic and building it (at opnfv). So, that's why we need
to avoid to have something internal to zebra.


I'm not against an API, and I'm not against zebra being a client of that
API. I would like Quagga to have its own namespace^WVRF management
facility though, not least to be able to test it; and secondly to ease
testing the rest of Quagga using namespaces.


food for comments:
 https://wiki.openstack.org/wiki/Neutron/MPLSVPNaaS



regards,



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14038] Re: VRF global and protocol specific config

[Vincent JARDIN]

On 30/11/2015 16:10, Paul Jakma wrote:

If there isn't other software already doing this (FOSS), and someone
wants to contribute that...


There are some networking datamodels with different options (SDN) having 
their logic and building it (at opnfv). So, that's why we need to avoid 
to have something internal to zebra.


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 14035] Re: VRF global and protocol specific config

[Vincent JARDIN]

On 29/11/2015 07:43, Vivek Venkatraman wrote:

o__Assigns the label and label management.

In some ways, the VRF registration mechanism that we're introducing as
part of VRF-lite support in BGP can be viewed as a VPN manager. I
envisage a related label management component when we move beyond
VRF-lite to full-blown L3VPNs (or EVPNs w/ MPLS). To me, these would be
part of 'zebra', not a separate daemon; the VRF management is definitely
being implemented as part of zebra.


I do not think we should assume VRF (same would be for label allocation) 
management/manager is part of "zebra" daemon, it should rather be part 
of the Quagga's framework. We could see multiple policies to 
allocate/free/attribute VRFs. It should rather remain a simple API to 
manage the requests & allocations.




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 13992] Re: cleaning up commands (was Re: BGP 'view' to 'vrf')

[Vincent JARDIN]

On 25/11/2015 16:32, David Lamparter wrote:

That
component could either be in-process (using something like Swig or
Cython to access C memory structures) or external (using some wrapping
like Protobuf to access C memory structures) or badly-done external
(using the CLI to poke at Quagga).


I like the Cython option, but it is maybe to heavy for embedding 
systems, do you have some data points?


I agree +1 for a kind of in-process would help close to CLI's DEFUN 
related when needed.


To implement d- I was more on a lua + bson since lua is light compared 
to Cython. But ideas are welcomed to be shared.


Best regards,

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 13007] Re: FreeBSD FIBs (was Re: patch reviews, 2)

[Vincent JARDIN]

On 02/09/2015 14:35, Paul Jakma wrote:

Further review comments:

- HAVE_FIB is a bit too generic. HAVE_FREEBSD_FIB?


Yes, +it should include a zebra argv (runtime) option too once we 
HAVE_FREEBSD_FIB, so it will leave the options to support both modes for 
FreeBSD:

  - 1 quagga per FIB
  - 1 quagga for all fib

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12901] Re: Question about Not allowing outside programs to remove Quagga routes

[Vincent JARDIN]

+1

When a FIB manager is the author/owner of a route, it must be trusted. 
Since the kernels (BSD, Linux) do not provide any means(*) from 
preventing 3rd parties from removing such routes, let's add them again 
like you are doing with this patch.


However, since it changes some behaviours, I feel it requires a argv + 
CLI command in order to disable this behaviour. I agree that your 
proposal should be the default behavior.


About the patch:
  - the git log is not good enough, your email is better
  - zlog_debug (Zebra route %s/%d was deleted by others from kernel, 
- it should be a warning, not a debug function to be displayed anytimes 
it happens.

 - INET6 is missing.

Best regards,


On 30/07/2015 14:37, Donald Sharp wrote:

In a private discussion with David Lamparter, we discussed this patch:

https://github.com/CumulusNetworks/quagga/commit/8b27eb162a9048498f2f87e4ae60b9a6ae62941b

This patch changes the behavior of Quagga to reinstall routes, that were
sourced from Quagga, back into the kernel if a route delete is
received.  David felt that this behavior was enough of a change that it
should be brought to the list for discussion/decision.  The whole crux
of the decision revolves around the question 'Who is the source of truth
for routes?'.  We've written this patch because we believe that the
answer to this question is that Quagga is the source of truth of routes
if it is being run.

Finally David also had some questions about how this could be done on
BSD as well.

thoughts?

thanks!

donald



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev




___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12719] Re: [PATCH] Allow the changing of the netlink socket buffer size.

[Vincent JARDIN]

On 19/05/2015 18:11, Donald Sharp wrote:

Allow package distributor to use configure option(--enable-nlcache=ARG)
to specify a appropriate netlink socket buffer size for the platform
they intend to run Quagga on.

Signed-off-by: Nolan Leake no...@cumulusnetworks.com
Reviewed-by: Roopa Prabhu ro...@cumulusnetworks.com
Reviewed-by: Donald Sharp sha...@cumulusnetworks.com


Why do you need to define it knowing it can be set at runtime:

ifdef HAVE_NETLINK
case 's':
  nl_rcvbufsize = atoi (optarg);
  break;
#endif /* HAVE_NETLINK */

?

We need to avoid/decrease the number of compilation option so all 
Quagga's packages can have ~ the same behaviors.


Thank you,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12725] VRF - TBD/XXX

[Vincent JARDIN]

We agree that VRF is tainted and we need an internal name which is more 
neutral.


On Linux, it'll be:
  - XXX - netns
  - XXX - table kernel IDs

For other OS,
  - XXX - technology XYZ

proposals are:
  LRF, Logical Routing and Forwarding,
  logical-table,
  Routing Domain (and hence Routing Domain ID),
  Network Domain (NDID),
  LR (logical router),

Do I forget a proposal into this list? Please, add it to this thread.

Thank you,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12726] Re: [PATCH v5 3/3] lib, vtysh: support multiple VRFs by using linux netns

[Vincent JARDIN]

You're creating a new VRF_NODE and installing it under CONFIG_NODE, but
not installing any commands to VRF_NODE - those are going into
CONFIG_NODE instead. So this is basically using it as a place to hook a
vrf config-write function into the CONFIG_NODE config-write function.


What's wrong with it?



This kind of suggests the command node API would be better having a list
of config-write function pointers in the cmd_node? Rather than
installing dummy cmd_nodes with no commands (but commands added into the
parent)?

(I'm little bit of command.c spring cleaning that made me notice this).


OK, then, once there will be a clean logic, the clean rule could be 
followed. Currently, looking at the code, it seems either options are 
OK. I maybe missing something...


Thank you,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12728] Re: [PATCH] pimd: add support for configuring multicast static routes

[Vincent JARDIN]

On 12/06/2015 04:20, Donald Sharp wrote:

Looks good, I'm going to use it.


Are you ready to send an Acked-by: ? on it.

So, it'll be recorded here,
  http://patchwork.quagga.net/patch/1260/


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12718] last week, patches to ack?

[Vincent JARDIN]

1260,
anyone to ack it?
  http://patchwork.quagga.net/patch/1260/
Donald said: Looks good, I'm going to use it.
  Donald?
Should'it it be ack? just obvious logs to be included.

1261, 1262,
  http://patchwork.quagga.net/patch/1261/
  I feel it should be resubmitted with __PRETTY_FUNCTION__ to be 
replaced by __func__

 https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html

dropped from patchwork:
  http://patchwork.quagga.net/patch/1263/
 I'll be sending a patch for the problem here shortly.

1264,
http://patchwork.quagga.net/patch/1264/
   What's the status?

Note that for a same serie of patch, a version number and changelog 
annotations are helpful:


$ git send-email -1 --subject-prefix 'PATCH v2' --annotate
--to quagga-dev@lists.quagga.net --cc everybody discussing the patch 
--in-reply-to Message-ID of the previous patch


___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12693] Re: v1 - Patchwork ack't patches

[Vincent JARDIN]

On 10/06/2015 12:35, David Lamparter wrote:

If you just send an Ack to a year-old patch, they won't know
what the Ack is for...


+1, you are right.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12689] Re: v1 - Patchwork ack't patches

[Vincent JARDIN]

On 10/06/2015 03:19, Donald Sharp wrote:

http://patchwork.quagga.net/patch/1241/

This one will be 2 weeks tomorrow.

+1

So, it remains 50 weeks before we'll face the bug :D

Paul you can push it. If you are busy, I'll be able to connect to git 
only by tomorrow.


I agree for many patches, I do not understand the 2 weeks delay. It can 
be a rule, but there are many cases for simple fix (like this one for 
BGP) that do not deserve this rule. Unless maintainers are busy.


Patch sent
  - patch ack't
  - consensus
  - apply it

Then, if it is a bad patch, git is our friend and it'll be blamed/reverted


Honestly though I don't know how to read the patchwork.quagga.net
http://patchwork.quagga.net.  It has hundreds of patches that are
years old, what applies anymore and what doesn't apply?


I agree that we should start dropping everything from patchwork that is 
too old, just keep them into an Attic. It the old patches were useful, 
we'll rewrote/redo the same fix/developments.


My 2 cents,



donald

On Tue, Jun 9, 2015 at 5:59 PM, Vincent JARDIN vincent.jar...@6wind.com
mailto:vincent.jar...@6wind.com wrote:

I did try to browse status on patchwork (I do not want to debate if
patchwork or not patchwork ;) ) in order to drain the list,

The following are ack't:
http://patchwork.quagga.net/patch/1257/
http://patchwork.quagga.net/patch/409/
http://patchwork.quagga.net/patch/406/
http://patchwork.quagga.net/patch/408/
http://patchwork.quagga.net/patch/411/
http://patchwork.quagga.net/patch/407/

Paul/Greg: should I push them?

can be taken:
http://patchwork.quagga.net/patch/1249/
http://patchwork.quagga.net/patch/1246/
http://patchwork.quagga.net/patch/1245/
http://patchwork.quagga.net/patch/1240/

Paul/Greg: should I push them?

minor update to be sent, then could be merged:
http://patchwork.quagga.net/patch/1248/ - Please, Donald?

nack:
http://patchwork.quagga.net/patch/410/
http://patchwork.quagga.net/patch/537/
We can keep them on patchwork for few more weeks, then when the
queue become lower, we can drop them...

Any comments?

I'll continue investigation after this first list to be processed.
Any helps are welcomed too.

Best regards,

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net mailto:Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev





___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12690] Re: [PATCH] Add code to extract.pl.in to prevent further cli function overwrites

[Vincent JARDIN]

On 10/06/2015 02:22, Donald Sharp wrote:

Currently extract.pl.in is used to build the vtysh cli.  When two
different cli's collide with the same command name, the original
cli is never called, because it is dropped.  This code notes the
silent drop and tracks the number of drops.  If they change then
the code will fail the build.  The current number of drops was
figured out by running extract.pl and counting up the drops
then adding code to compare the numbers returned.

If you have added to the problem, the solution is to fix your cli
command to not stomp on someone else's command.  If you have removed
a stomp, safely modify extract.pl.in as part of your commit.

Signed-off-by: Donald Sharp sharpd at cumulusnetworks.com


Acked-by: Vincent Jardin vincent.jar...@6wind.com



---
  vtysh/extract.pl.in |   29 +
  1 file changed, 29 insertions(+)



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12683] Re: Building RPMs for Redhat 6 or 7 (or CentOS 6 or 7)

[Vincent JARDIN]

Martin,

 in general nice work. Much better than the SPECs I’ve created on our

CI system (See
https://git-us.netdef.org/projects/OSR/repos/ci-files/browse/centos7/example)


Great to learn. I did not notice it.

why not submitting them on Quagga's git / website so it would be visible 
and consumable by the distributions?


The mailing list, neither patchwork have any entries about your SPECs:
  http://patchwork.quagga.net/project/quagga/list/

Could you git-send them?

Thank you,
  Vincent



___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12681] v1 - Patchwork ack't patches

[Vincent JARDIN]

I did try to browse status on patchwork (I do not want to debate if 
patchwork or not patchwork ;) ) in order to drain the list,


The following are ack't:
  http://patchwork.quagga.net/patch/1257/
  http://patchwork.quagga.net/patch/409/
  http://patchwork.quagga.net/patch/406/
  http://patchwork.quagga.net/patch/408/
  http://patchwork.quagga.net/patch/411/
  http://patchwork.quagga.net/patch/407/

Paul/Greg: should I push them?

can be taken:
  http://patchwork.quagga.net/patch/1249/
  http://patchwork.quagga.net/patch/1246/
  http://patchwork.quagga.net/patch/1245/
  http://patchwork.quagga.net/patch/1240/

Paul/Greg: should I push them?

minor update to be sent, then could be merged:
  http://patchwork.quagga.net/patch/1248/ - Please, Donald?

nack:
  http://patchwork.quagga.net/patch/410/
  http://patchwork.quagga.net/patch/537/
We can keep them on patchwork for few more weeks, then when the queue 
become lower, we can drop them...


Any comments?

I'll continue investigation after this first list to be processed. Any 
helps are welcomed too.


Best regards,

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12650] Re: [PATCH v5 3/3] lib, vtysh: support multiple VRFs by using linux netns

[Vincent JARDIN]

Lou,


Also, responding to Donald's comment: it seems to me that the current
patch set is closer to vrf-lite than logical routers/systems due to the
single control model and lack of separable administration options. That
said, I think 'MRF' is much better choice than 'domain'.


it is related to topics of:
  http://wiki.linuxplumbersconf.org/2015:networking

Quagga shall consume it.

Best regards,

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12649] Re: [PATCH v5 3/3] lib, vtysh: support multiple VRFs by using linux netns

[Vincent JARDIN]

On 05/06/2015 13:54, Alain Ritoux wrote:

Code level:
s/vrfid/ltid (standing for logical table index)


+1 , it makes sense since it is indexing tables.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12661] Re: [PATCH] pim_mroute.h has a different version of code than linux/mroute.h provides

[Vincent JARDIN]

Ack't
Le 5 juin 2015 21:17, Donald Sharp sha...@cumulusnetworks.com a écrit :

 linux/mroutes.h and pim_mroute.h both have copies of the same structures.
 This is causing failures in setsockopt(..., MRT_ADD_MFC,...) because
 of data structure incompatibilities between the kernel and what
 pim_mroute.h was providing.  Modify the code to check for mroute.h
 and include it if necessary.  I did not modify the non linux/mroute.h
 path because I do not have other systems to test on easily.

 Signed-off-by: Donald Sharp sha...@cumulusnetworks.com
 ---
  configure.ac  |5 +
  pimd/pim_mroute.h |4 
  2 files changed, 9 insertions(+)

 diff --git a/configure.ac b/configure.ac
 index f20fb3f..f44b421 100755
 --- a/configure.ac
 +++ b/configure.ac
 @@ -939,6 +939,11 @@ dnl figure out how to specify an interface in
 multicast sockets API
  dnl ---
  AC_CHECK_MEMBERS([struct ip_mreqn.imr_ifindex], [], [], QUAGGA_INCLUDES)

 +AC_CHECK_HEADERS([linux/mroute.h], [], [],
 +[
 +#if HAVE_NETINET_IN_H
 +#includenetinet/in.h
 +#endif])
  AC_MSG_CHECKING([for BSD struct ip_mreq hack])
  AC_TRY_COMPILE([#ifdef HAVE_SYS_PARAM_H
  #include sys/param.h
 diff --git a/pimd/pim_mroute.h b/pimd/pim_mroute.h
 index 350b1e3..125d190 100644
 --- a/pimd/pim_mroute.h
 +++ b/pimd/pim_mroute.h
 @@ -40,6 +40,9 @@

  #define PIM_MROUTE_MIN_TTL (1)

 +#if defined(HAVE_LINUX_MROUTE_H)
 +#include linux/mroute.h
 +#else
  /*
Below: from linux/mroute.h
  */
 @@ -154,6 +157,7 @@ struct igmpmsg
struct in_addr im_src,im_dst;
  };
  #endif
 +#endif

  /*
Above: from linux/mroute.h
 --
 1.7.10.4


 ___
 Quagga-dev mailing list
 Quagga-dev@lists.quagga.net
 https://lists.quagga.net/mailman/listinfo/quagga-dev

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12550] Re: [PATCH] Add code to extract.pl.in to prevent further cli function overwrites

[Vincent JARDIN]

Donald,
On 29/05/2015 06:57, Donald Sharp wrote:

+my $bad_cli_stomps = 78;


you should explain/comment how you started/get 78 magic number.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12569] Re: [PATCH] Add code to extract.pl.in to prevent further cli function overwrites

[Vincent JARDIN]

+my $bad_cli_stomps = 78;

you should explain/comment how you started/get 78 magic number.


On 29/05/2015 21:13, Donald Sharp wrote:

I got it from Running the code and seeing the number it returned to me.
Or do you mean explain in the code?


Just a comment into the code and git log explaining it would be enough.

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12547] Re: [PATCH v3 00/22] VRF support in quagga

[Vincent JARDIN]

In a small experiment that I'm running now Quagga (zebra,
ospfd, pimd)  uses 9MB of RAM.  if I start adding VRFs I'm going to hit
a wall really quick.


Right, memory will be an issue. Even worst, we have seen that time to 
start many daemons does not scale:


https://lists.quagga.net/pipermail/quagga-dev/2014-December/011933.html

Here, we are targeting +1000.

Best regards,
  Vincent

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12480] Re: [PATCH v3 02/22] ripngd: add ECMP support

[Vincent JARDIN]

On 22/05/2015 11:39, Nicolas Dichtel wrote:

From: Feng Lulu.f...@6wind.com

* Each node in the routing table is changed into a list, holding
   the multiple equal-cost paths.

* If one of the multiple entries gets less-preferred (greater
   metric or greater distance), it will be directly deleted instead
   of starting a garbage-collection timer for it.
   The garbage-collection timer is started only when the last entry
   in the list gets INFINITY.

* Some new functions are used to maintain the ECMP list. And hence
   ripng_route_process(), ripng_redistribute_add() and ripng_timeout()
   are significantly simplified.

* ripng_zebra_ipv6_add() and ripng_zebra_ipv6_delete() now can share
   the common code. The common part is moved to ripng_zebra_ipv6_send().

Signed-off-by: Feng Lulu.f...@6wind.com
Reviewed-by: Alain Ritouxalain.rit...@6wind.com
Signed-off-by: Nicolas Dichtelnicolas.dich...@6wind.com


Acked-by: Vincent Jardin vincent.jar...@6wind.com

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

[quagga-dev 12479] Re: [PATCH v3 03/22] ripngd: allow to enable/disable the ECMP feature

[Vincent JARDIN]

On 22/05/2015 11:39, Nicolas Dichtel wrote:

From: Feng Lulu.f...@6wind.com

Introduce a new command [no] allow-ecmp to enable/disable the
ECMP feature in RIPng. By default, ECMP is not allowed.

Once ECMP is disabled, only one route entry can exist in the list.

* ripng_zebra.c: adjust a debugging information, which shows the number
  of nexthops according to whether ECMP is enabled.
* ripngd.c: ripng_ecmp_add() will reject the new route if ECMP is not
 allowed and some entry already exists.
 A new configurable command allow-ecmp is added to control
 whether ECMP is allowed.
 When ECMP is disabled, ripng_ecmp_disable() is called to
 remove the multiple nexthops.
* ripngd.h: Add a new member ecmp to struct ripng, indicating whether
 ECMP is allowed or not.

Signed-off-by: Feng Lulu.f...@6wind.com
Reviewed-by: Alain Ritouxalain.rit...@6wind.com
Signed-off-by: Nicolas Dichtelnicolas.dich...@6wind.com


Acked-by: Vincent Jardin vincent.jar...@6wind.com

___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev