Subject: RE: [pim] PIM BSR Draft

From: "bharat_joshi" <[email-masked]>
Date: Sat, 10 May 2003 15:52:41 +0530

>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

Hi Mark,

I agree with you on almost all the points you have listed above.

But I think we can avoid a downtime using the following method:

As per the draft, when a new PIM router comes UP, he start sending hello messages. The DR on the LAN will send a Hello message as well as a copy of the Last BSM to this new router.

If this router is configured to be a C-BSR, it will compare himself with this BSM, if this new router wins than he can use the same RP set which he has just recieved from the Neighbor and start sending BSM messages with this RP set.

This way there won't be any down time and every router/switch will have the same RP set.

I think this will not create any problem as RP set will not change till a C-RP himself change it.

And when this new BSM will reach to C-RPs, they can findout that this is now the elected BSR and so they will start sending their C-RP adv to this new BSR.

In case of point to point link also, the same can be achieved.

Another issue here is:

When A router is a Candidate BSR, We don't have a event "Received Non_preferred BSM from a new C-BSR"

With my proposed solution this can also be taken care of.

otherwise, when we receive such BSM, we can simply discard it.

Next question could be about the DOS attack in my proposed solution.

Now if any router forges a BSM message and send it to the new router, still only this router will get affected. Lets say this new router think he is the elected BSR now and start sending BSMs but no other router will accept him as preferred BSR and drop this new BSM and the elected BSR will originate the BSM as per the state table.

Does it make sense??

If somebody think this is not a good idea,please let me know the details.

Thanks for your time,
Bharat

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

---

From: "bharat_joshi" <[email-masked]>
Date: Fri, 9 May 2003 18:37:37 +0530

Cheers,
	Mark

Hi Mark,

Another issue here is:

Does it make sense??

Thanks for your time,
Bharat

---

From: Cormier Chris-ACC125 <[email-masked]>
Date: Mon, 12 May 2003 19:18:56 -0500

Also, not to be picky, but for a convenience, can you represent the correct
number of bits in the BS message format table:
Right now, this table makes it appear as though the encoded fields
(encoded-unicast and encoded-group format)are only 32 bits. This is
misleading as sometimes people trust these tables. After all, we do have a
bit count at the top of the table.
Thanks,
-chris

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Fragment Tag          | Hash Mask len | BSR-priority  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             BSR Address (Encoded-Unicast format)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 1 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1    | Frag RP Cnt 1 |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 1 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP1 Holdtime         | RP1 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 2 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP2 Holdtime         | RP2 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address m (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RPm Holdtime         | RPm Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 2 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address n (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count n    | Frag RP Cnt n |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 1 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP1 Holdtime         | RP1 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             RP Address 2 (Encoded-Unicast format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          RP2 Holdtime         | RP2 Priority  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+