Subject: RE: [pim] PIM BSR Draft

From: "bharat_joshi" <[email-masked]>
Date: Thu, 8 May 2003 10:18:27 +0530

Hi Rishabh,

I think I got your point here and I agree to it.

But I think when this new router sends a BSM after getting elected, he will send an empty BSM to all PIM routers (because this new router doesn't have any information about the C-RPs) and all these routers will discard the old RP-Set and try to store the new RP set which is right now not there. It means there won't be any information in the RP-Set.

now when C-RPs send their details to this new BSR and and this new BSR create a RP-Set and send it to all PIM routers. During all these activities every router in this domain will not have the group-rp set information. This is what is my worry.

will it be this way or not??

If it is this way than is it been taken care of?

Thanks,
Bharat

-----Original Message-----
From:	Rishabh Parekh [mailto:[email-masked]]
Sent:	Thu 5/8/2003 6:07 AM
To:	bharat_joshi
Cc:	[email-masked]
Subject:	Re: [pim] PIM BSR Draft

Bharat,
When a new router comes up and it becomes an Elected-BSR from a Pending-BSR, 
it originates a BootStrap message. This BS message is received at the 
Candidate-RPs (and other ordinary non-CRP non-CBSR PIM routers) and they 
appoint the new router as the BSR. The C-RPs then advertise thier C-RP 
messages to the newly elected BSR which builds and distributes the RP set 
information in subsequent BS messages.

I hope this helps to clarify your doubts,
Rishabh.

On Wednesday 07 May 2003 07:24 am, bharat_joshi wrote:
> Hi,
>
> I was going through the C-BSR draft.
>
> Can somebody explain what will happen when a new Router comes up and can be
> the preferred BSR in the PIM domain?
>
> The draft mention that a router will be in pending state after start-up and
> start BS timer to BS timeout value.
>
> Lets say that the DR on the network, pass on the BSM to this new router.
>
> Lets assume that this new router is having higher priority and so should be
> elected as a BSR.
>
> Now the state-machine shows that when in pending state and a non-preferred
> BSM is received ..don't do anything.
>
> Now when the BS timer will expire, this new router will think that he has
> become the new elected BSR but he doesn't have any information about the
> C-RPs till now as C-RPs would be unicasting their info to the old BSR.
>
> Either there is something wrong here or I am not able to understand it
> properly.
>
> Can somebody help me in understanding this??
>
> TIA,
>
> Best Regards,
> Bharat
>
> ==============================
> Infosys Technologies Ltd.
> Bangalore, India
>
>
> _______________________________________________
> pim mailing list
> [email-masked]
> http://catarina.usc.edu/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Mark Handley <[email-masked]>
Date: Thu, 08 May 2003 20:57:13 -0700

>But I think when this new router sends a BSM after getting elected, he will se
>nd an empty BSM to all PIM routers (because this new router doesn't have any i
>nformation about the C-RPs) and all these routers will discard the old RP-Set 
>and try to store the new RP set which is right now not there. It means there w
>on't be any information in the RP-Set.
>
>now when C-RPs send their details to this new BSR and and this new BSR create 
>a RP-Set and send it to all PIM routers. During all these activities every rou
>ter in this domain will not have the group-rp set information. This is what is
> my worry.

The current spec is sadly lacking in detail here, although if you read
between the lines it is possible to devine the intent from the
sections on semantic fragmentation.  Here's the gist of what I propose
to be added to the spec:

1. When the BSR times out, and no alternative BSR is elected, routers
continue to use their cached RP Set, even though it has timed out.

2. When a router receives an *empty* BSM from a new BSR that wins the
election, it continues to use the cached RP Set.  This would be the
case anyway for any group ranges not listed in the empty BSM.

3. When a router receives a non-empty BSM from a new BSM that wins the
election, it will switch to using the new RP set.  However, this is
not necessarily an instantaneous switch.  The old BSM may have listed
multiple group-ranges, each of which was spread across multiple
semantically-fragmented BSM packets.  So, a router continues to use
the old RP Set information for each group range until either that
group range has timed out, or it has received all the BSM packets for
that group range (as indicated by the RP count information in the RP
Set) from the new BSR.

4. A well-designed BSM implementation will issue an empty BSM to
participate in BSR election.  On winning, it will receive C-RP
advertisements.  

If the new BSM has the old RP set, it should not issue a new BSM until
it has heard from all the RPs in the old RP set, or a short time
interval (say three seconds) has elapsed without receiving new RPs to
include in the set, whichever comes first.  It should wait a maximum
of (say) 30 seconds - if new RPs are still arriving, it should issue
the BSM anyway.  To remove group-ranges that are no longer in the RP
set from the previous RP, it should include those obsolete
group-ranges in the BSM with no RPs listed.

If the new BSM does not have the old RP set, it should not issue a new
BSM until a short time (say three seconds) has elapsed without
receiving new RPs to include in the set, whichever comes first.  It
should wait a maximum of (say) 30 seconds - if new RPs are still
arriving, it should issue the BSM anyway.

The motivation is to try hard to avoid RP set churn, which not being
susceptable to a DoS attack or waiting an excessive amount of time.

Does this sound reasonable?  The intent was that we trust the old
information until we're explicitly told otherwise, or it has timed out
after a longish interval.  A change of BSM without a change of RP set
should not (under normal circumstances) cause any transient change in
RP set.

Cheers,
	Mark

---

From: "Prashant Jhingran" <[email-masked]>
Date: Fri, 9 May 2003 10:27:09 +0530

The discussion seems to be interesting. Well definitely it will be as you
described. 
Candidate BSRs are present mainly for backup purposes while the CRPs may
solve the dual purpose of load sharing as well as backup RP. 
Now in order to prevent this black hole although for a short period of time
you may come up with an implementation specific solution like storing the
new BSR address and at the same time not loosing the CRP information for a
short timer interval, lets say 125 secs (60 sec for new BSR mesg + 60 sec
for CRP Adv time + 5 sec for propagation delay). This may lead to a faster
convergence and I think black hole may also be prevented.

However the authors may come up with a standard solution.
Regards,
Prashant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of bharat_joshi
Sent: Thursday, May 08, 2003 10:18 AM
To: Rishabh Parekh
Cc: [email-masked]
Subject: RE: [pim] PIM BSR Draft

Hi Rishabh,

But I think when this new router sends a BSM after getting elected, he will
send an empty BSM to all PIM routers (because this new router doesn't have
any information about the C-RPs) and all these routers will discard the old
RP-Set and try to store the new RP set which is right now not there. It
means there won't be any information in the RP-Set.

now when C-RPs send their details to this new BSR and and this new BSR
create a RP-Set and send it to all PIM routers. During all these activities
every router in this domain will not have the group-rp set information. This
is what is my worry.

Thanks,
Bharat

-----Original Message-----
From:	Rishabh Parekh [mailto:[email-masked]]
Sent:	Thu 5/8/2003 6:07 AM
To:	bharat_joshi
Cc:	[email-masked]
Subject:	Re: [pim] PIM BSR Draft

Bharat,

***************************************************************************
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.
***************************************************************************