Subject: Question on GenID

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Wed, 13 Sep 2000 16:00:35 -0500

Hi,
I had sent this out on the PIM mailing list a couple of weeks back, but got
no response. I am trying to understand the way GenID works in these cases.
If you can please clarify some of these questions, I would greatly
appreciate it. 

Thanks,
Vidya

----------------------------------------------------------------------------
-------------------

Hi,

A basic question on GenID operation - is a rebooted router expected to send
any BSR message (say, if it is itself a C-BSR) on getting a hello from a
neighbor? 

Given that GenID is to be enabled on a per-interface basis, I have some
questions on the working of GenID with PIM-SM that some of you may be able
to answer. Consider the following configuration for the discussion:

More PIM Routers ----- R1 ----- R2 ----- R3 ----- R4 ----- More PIM Routers
                       |                          |
                      Snd                        Rcv

All the links between the routers are WAN links. Also, please note that all
these questions are based on the assumption that GenID is enabled on a
per-interface basis and also that when an interface goes down and up, a new
GenID is triggered.

1. If an interface, say between R2 and R3 goes down and comes back up, both
R2 and R3 would now send PIM Hellos with new GenIDs on that interface. The
concept of GenID from what I understand is that if a router comes up after a
failure and triggers a new GenID, its neighbor would send it all the RP-Set
information and relevant Join/Prune messages. In this case, Would R2 and R3
both send RP-Set information (BSR Message) to each other? Also, this BSR
message should be unicast (last paragraph in section 4.7.2 in revised
version of PIM-SM spec?), correct? Normally, would R2 or R3, in this case,
continue to propogate this BSR message on other interfaces? I would assume
not, but please clarify. 

2. Assume R3 is the RP for a group for which we have the sender and receiver
as shown. If we are running on a shared tree (i.e., receiving DR never
switches to shortest path tree for administrative reasons), R4 would not
have any (S, G) state at all. If R3 (RP) reboots, how does the (S, G) state
get re-created in it? As long as the other routers have not timed out this
RP, the native multicast packets (assume past encapsulation stage) would be
sent to R3 from R2 once it is up again. At this time, it would have (*, G)
state, since R4 would have sent a (*, G) Join to it on seeing the GenID
change. Now, would the RP forward the incoming packets based on the (*, G)
entry? Or, does it drop the packets since there is no (S, G) entry for that
source? Also, does an (S, G) entry get created again? And, how? If R1 sends
a NULL register message prior to the expiration of its Register Suppression
Timer, how does the RP react to that in this case? 

3. Assume that R3 is also the E-BSR (Elected BSR). Let us say that there are
other C-RPs in the network not shown in the picture above, beyond R1 and R4
on either side. Also assume that the R3 is the only C-BSR in the network.
Now, if the link between R2 and R3 goes down, R1 and R2 just lost
connectivity to the BSR. However, they are never going to time out the RPs.
If the link stays down long enough, R3 would time out all the C-RPs that it
used to reach through R2. If the link comes back up after that, R2 and R3
are going to unicast BSR messages to each other through GenID changes. Now,
the BSR message from R3 to R2 would only have a partial set of C-RPs listed.
But the message from R2 to R3 would have all the RPs listed. First of all,
how does a BSR react to getting a BSR message from a neighbor with its own
address as the BSR address? Second, what is the impact of this having
different information being exchanged going to be on the network? I
understand that the next periodic updates and C-RP advertisements should
clean this up, but then, what is GenID buying here?

4. Now, adding another dimension to the problem, assume that R1 is also a
C-BSR, but R3 is the E-BSR. Again, if the link between R2 and R3 fails and
stays down long, R1 will elect itself as the BSR on one side. In this
picture then, R1 and R2 now have knowledge of all the C-RPs on one half of
the network, while, R3 and R4 have knowledge of C-RPs on the other side.
When the link comes back up and BSR messages get exchanged due to GenID
changes, how does the mess get resolved? Assuming that the GenID-triggered
BSR message exchange is not sent to other routers, would there then be two
E-BSRs in the network, until the next periodic update that triggers the BSR
election process? 

I would greatly appreciate any comments on these questions.

Thanks,
Vidya