[quagga-dev 16143] [PATCH v2 1/3] lib: 3byte stream foo

From: David Lamparter API enhancement to be able to write and read 3 byte series in stream structures. Signed-off-by: David Lamparter Signed-off-by: Philippe Guibert --- lib/stream.c | 77

[quagga-dev 16142] BGP multiple label support

Hi Quagga-dev, This work is enhancing RFC3107 encoding format for label in BGP NLRI messages. This applies for instance to VPNv4 address family. It is to be noted that this commit does not bring any API enhancement regarding VTY configuration. However, the mecanic is ready to receive BGP updates

[quagga-dev 16141] Re: round-8: tentative proposed head for master

On Thu, 29 Sep 2016, Lou Berger wrote: looks like the NHT code is generating an event into the state machine that it shouldn't be. I removed this and checked it into my work area. See https://github.com/LabNConsulting/quagga-vnc/commit/7162337f9261b91056b95a673a54ad595aef3e5f Kudos to

[quagga-dev 16140] Re: round-8: tentative proposed head for master

On Thu, 29 Sep 2016, Lou Berger wrote: Just walked through the code a bit -- looks like quagga needs to add support for DelayOpen(Timer) when receiving a new tcp connection... I added something similar to that, but that wasn't it. The existing code did that anyway. regards, -- Paul Jakma |

[quagga-dev 16147] Re: round-8: tentative proposed head for master

It's unclear to me why an NHT should *ever* trigger a state machine change. At this point, I'm more comfortable with going back to not changing BGP FSM state than introducing the three new FSM changes you have in the code... Why do you think the state transitions are are appropriate based on an

[quagga-dev 16154] Re: Doing something different wrt patch integration

Paul, Just restating things I've said here before : - I don't the issue is backlog - I do think the issue is that in order for organizations/companies/individuals to invest in an open source project that there needs to be process transparency, predicable releases, and a deterministic way to get

[quagga-dev 16151] Re: round-8: tentative proposed head for master

On Fri, 30 Sep 2016, Lou Berger wrote: The change I submitted continues the original use of NHT information for Idle (start event) and Active (retry) states, i.e., just removes NHT info in Connect state. Bug-wise it is just the bgp_connect_check call that needs to go. In which case, that

[quagga-dev 16152] Re: round-8: tentative proposed head for master

woops - you're right - these are BGP_ignore actions... Lou On 9/30/2016 10:49 AM, Paul Jakma wrote: > Which change? > > There's no changes to OpenXXX? ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net

[quagga-dev 16148] Re: round-8: tentative proposed head for master

On Fri, 30 Sep 2016, Lou Berger wrote: It's unclear to me why an NHT should *ever* trigger a state machine change. At this point, I'm more comfortable with going back to not changing BGP FSM state than introducing the three new FSM changes you have in the code... The 3 FSM changes are

[quagga-dev 16149] Re: round-8: tentative proposed head for master

On Fri, 30 Sep 2016, Paul Jakma wrote: I.e. the major functional difference to yours is that it retains going through the ConnectRetry_timer_expired event on Connect as the prior NHT code was doing. Oh, but if that should be removed, the Active one should too. Then there's just the

[quagga-dev 16150] Re: round-8: tentative proposed head for master

The change I submitted continues the original use of NHT information for Idle (start event) and Active (retry) states, i.e., just removes NHT info in Connect state. Keeping these event sources seems fine (at least based on testing) and not clear to me very significant, but I haven't traced

[quagga-dev 16153] Re: round-8: tentative proposed head for master

On Fri, 30 Sep 2016, Lou Berger wrote: woops - you're right - these are BGP_ignore actions... Yeah, you have to add those to get the table right. ;) The prior NHT code basically is doing, FSM wise: State -> Event --- Idle -> BGP_Start Connect - > ConnectRetry_timer_expired