[Xorp-hackers] BSR Restart

[Pavlin Radoslavov]

Samuel Lucas Vaz de Mello <samuellucas at datacom.ind.br> wrote:

> Pavlin Radoslavov wrote:
> > However, I have to admit that I didn't look into the details of what
> > you are doing when the BSR is restarted, so I cannot comment whether
> > it is the right thing or whether something is missing.
> > I intend to do this in the future, but unfortunately I cannot do
> > this right now (see below).
> > 
> > Currently we are in the process of code freeze, so I am afraid
> > this fix has to wait (strictly speaking it is an
> > optimization so it is not critical).
> > In the mean time please have a look in my refactoring of your patch
> > in case I messed-up something.. If it is OK for you and if it works,
> > please create a Bugzilla entry about the issue, and add that patch
> > to the entry. Thus we can track its status, update the patch, etc.
> 
> I think we need also the rest of bsr_stop(), the parts that sends the Cand-RP-Adv with zero holdtime and BSR Message with lowest priority if i'm not the elected bsr for the zone. This is needed to keep the current behavior for non-elected zones, but would duplicate the whole code, that's why I choosed to change bsr_start()/bsr_stop().

I see. In that case we might have to move the whole "for ..." block
in PimBsr::stop() to a new method, and then just use that method
where necessary.

> As this patch is target for the next version, maybe we should try a more intrusive approach making the configuration commands change also the active state and get rid of the restarts.
> 
> How long will the code freeze last? What is the release schedule for Xorp 1.6?

I cannot give you any concrete dates/timescales, but right now the
Q/A team are very close toward making a cut and start doing
lots of internal tests.
Hopefully very soon we will have a schedule on the Web site which
will answer your questions.

The BSR restart patch is not crystalized/polished yet, and it is a
notable change that could break things if not done right.
Hence we need to have a working and polished patch first before we
can consider it for inclusion.
In any case, the patch should go first to Bugzilla, so we can track
the issue, and all technical comments will be in one place.

Thanks,
Pavlin