Subject: [pim] Doubt reg. BSR

From: "girishkg" <[email-masked]>
Date: Fri, 2 Jul 2004 20:21:27 +0530

Hello,

I have few queries reg. BSR draft-03 -

1. According to BSR draft, at start-up,  the BS Timer is initialised to BS
Timeout value (~130sec). Is there any specific reason for choosing this
large value. I feel this value can be reduced to a small value.

2. In the BSR draft, it is not mentioned that Unicast non-preferred BSM
should be accepted by a Candidate-BSR in the P-BSR state, if no previous BSM
has been received for a particular scope zone. This will help in learning
RP-SET.

Please let me know if i am missing something or this has been already
discussed in the mailing list.

Regards,
Girish

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Mon, 5 Jul 2004 13:37:40 +0200

Hi

> large value. I feel this value can be reduced to a small value.

I don't know the history behind this. I believe it's good to wait for
existing BSR information first, so that it can compare with its own
priority. Which means at least a bit longer than 60s (the default BS
period).

When a router is booted the routing might also be a bit unstable (e.g.
new routes being learnt, routing tables updated etc). Thus it might be
possible that a BSM is lost, e.g. RPF check fails. If this is a likely
problem it might be good to wait a bit longer than 120s (2 * BS period).

It's also convenient perhaps to reuse the BS timeout value.

Do you believe it's a problem that it takes 130s from the first c-BSR
is booted/configured until it starts? If there already is an elected
BSR, then I see no problem with it.

I suppose someone that knows the background might be able to give you a
better answer.

> has been received for a particular scope zone. This will help in learning

I'm not sure I understand. Are you suggesting that a pending BSR could
learn the RP-set this way rather than waiting for C-RP advs? It's a
possible optimization, but at least in my mind, it breaks the model a
bit.

We plan to add text saying that an empty BSM must not delete the current
RP-set. A new BSR would first send an empty BSM, and by the time it sends
the next BSM, it has hopefully received C-RP advs from all the C-RPs.

Currently the default periods for BSMs and C-RP advs are both 60s. So
it might be possible to send two BSMs and just missing an C-RP adv. I
see two possible solutions to that. One is making the C-RP adv period
shorter. The other would be to have C-RPs send C-RP adv immediately
(or with small random delay) when a new BSR is elected.

With the changes above the new BSR should have complete RP information
by the time it sends the second BSM, and the routers shouldn't lose
any RP information during the switchover.

> discussed in the mailing list.

These are just my opinions.

Stig