Subject: RE: sending null register msgs in register State machine

From: "Sundeep Singatwaria" <[email-masked]>
Date: Mon, 6 Aug 2001 12:12:42 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, August 05, 2001 8:54 PM
To: Singatwaria, Sundeep [SC7:370-M:EXCH]; pim
Subject: RE: sending null register msgs in register State machine

Hi Sandeep,
          Once register stop message (RSM) is received from RP for a
perticular (S,G),
the register encapsulation at the DR is SUPPRESSED for a period
REGISTER_SUPPRESSION_TIME (60s)
( or REGISTER_SUPPRESSION_TIME - PROBE_TIME ).This is period during which DR
stops sending Register-encapsulated data to the RP after receiving a RSM ).
     after "REGISTER_SUPPRESSION_TIME" the RST expires, that's when the DR
sends a NULL register
message to the RP, just to confirm if register encapsulation is to be
restarted. If the RP
responds with a RSM again, within PROBE_TIME (i.e 5 sec), the timer is
restarted for
REGISTER_SUPPRESSION_TIME.
     Data encapsulation will happen only when the RP does not respond with a
register stop message
withing PROBE_TIME, and so there is never a situation when encapsulation is
restored undesired.
Register null message is just a probing mechanism, to start encapsulation of
data.
    bye
              Ram

I guess what you say hold true for the old rfc. If you follow the text in
the new
draft - 'subtracting off register_probe_time is a bit unnecessary .......and
is
kept for compatability'is not correct.
Should I assume that the authors are going to remove this para in the draft
??

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sundeep Singatwaria
Sent: Sunday, August 05, 2001 10:36 PM
To: ramamurthy.pani; pim
Subject: Re: sending null register msgs in register State machine

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Singatwaria, Sundeep [SC7:370-M:EXCH] <[email-masked]>; pim
<[email-masked]>
Date: Wednesday, August 01, 2001 9:38 PM
Subject: RE: sending null register msgs in register State machine

>Hi Sundeep,
>           The NULL register message is sent only after timeout for
>REGISTER_SUPPRESSION_TIME
>and then the RST is restarted for PROBE_INTERVAL. The register NULL message
>should be sent before
>(REGISTER_SUPPRESSION_TIME +  PROBE_INTERVAL)
>     regards
>              Ramamurthy

ram - it is sent before RST expires else we will have data encapsulation
when it is not desired. check out the timer values section of the draft -
Register Stop Timer.

sundeep

>
>
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Sundeep
>Singatwaria
>Sent: Thursday, August 02, 2001 2:42 AM
>To: pim
>Subject: sending null register msgs in register State machine
>
>
>The null register msg is sent before the RST expires.
>However interpreting from the state m/c and the tabular form - the null
>register is sent at the expiry of the RST timer - which doesn't sound
right.
>Could we add one more state 'NULL register state' to describe it.
>
>Pls. let me know if I missed something.
>
>Sundeep
>
>
>

---

From: John Zwiebel <[email-masked]>
Date: Mon, 06 Aug 2001 14:32:30 -0700

FWIW:

The old spec went into way too much detail with this.
And the new one, could have simplified this a lot.

The important thing to recognize here is that you want to
have the DR update (S,G) state on the RP before it times out.
Cisco calls this a "data-header" register because "NULL register"
was already used for something else.

How often you update state on the RP is pretty much immaterial for
a given implementation just as long as you make sure you do it.

IMHO an argument could be made that data-header registers alone would
be "good enough" for a given implementation.  It seems rather 
silly to expect that no data will be lost when switching from the
RPT to the SPT, so the idea that if the RP looses state somehow
and it will require a new encapsulated packet in a register packet
to fix it seems rather a faint possibility.

After all, when the RP gets in any register packet, its going to join
toward the source along the X-line to have the data delivered natively.
So, now you have a 'race' between the joins being sent along the X-line
and the first-hop timing out and sending an encapsulated packet.

And even for those times (which have been rare in my experience) where a
last-hop router wants to stay on the shared-tree, the RP still joins
along the X-line
shortest-path to the source.  So you may lose a few packets at the
beginning
of the source sending, but that then brings up the discussion of RTS/CTS
that we saw on this list a while ago.  How do you set up a "handshake"
to
make sure everyone gets all the data.

So, if you follow the spec WRT sending an encapsulated packet, those
folks who've chosen to avoid that complexity will still interoperate
with
you just fine.  I don't see a case where an RP that knows (S,G) RP might
be 
able to "heal" something broken by receipt of an encapsulated data
packet
and delivering that down the shared-path.

2cents.

> Sundeep Singatwaria wrote:
> 
> I guess what you say hold true for the old rfc. If you follow the text
> in the new
> draft - 'subtracting off register_probe_time is a bit unnecessary
> .......and is
> Should I assume that the authors are going to remove this para in the
> draft ??
>

---

From: "K.P.Ramamurthy" <[email-masked]>
Date: Tue, 7 Aug 2001 18:11:44 +0530

Hi,
   If a router is configured to be a stand alone BSR, and becomes the E-BSR
of the domain,
is it OK for the BSR to send a BSM with no RP-SET, i.e a null BSM. As a
result of sending
a NULL BSM, all the routers in the domain will be down for some time, is
this acceptable ?

Normally elected routers will inherit the RP-SET ( C-RP list ) from the
active RP-SET used
by the router, but for stand alone routers, expected to function just a BSR,
they will not
have the RP-SET, and so cannot inherit RP-SET, in which case they are forced
to send a
NULL BSM message ( just advertising their BSR address, so that C-RPs can
send their C-RP-ADV
msgs to the new BSR).

           regards and thanks
       Ram

---

From: John Zwiebel <[email-masked]>
Date: Tue, 07 Aug 2001 08:55:14 -0700

FWIW: in some implementations, routers that do not know
of an RP for a given multicast group range will revert to
forwarding using dense-mode.  You are opening yourself up
to problems if you allow the network to switch between 
dense and sparse operation for a group.

2cents

"K.P.Ramamurthy" wrote:
>   ------------------------------------------------------------------------
>                            Name: Wipro_Disclaimer.txt
>    Wipro_Disclaimer.txt    Type: Plain Text (text/plain)
>                        Encoding: 7bit

---

From: "Sridhar Vallepalli" <[email-masked]>
Date: Tue, 7 Aug 2001 23:56:03 +0530

When the standalone BSR is enabled for PIM on the network (sending its first
hello to neighbors). It receives a unicasted BSM with the current RP-set and
current BSR from the PIM DR neighbor on that interface. This might prevent
it from sending the null BSM.

-Sridhar

---

From: "K.P.Ramamurthy" <[email-masked]>
Date: Wed, 8 Aug 2001 08:54:54 +0530

Hi,
    The stand alone BSR, will just participate in the BSR election, and if
it succeeds
to become the elected BSR, will augment the C-RP-ADV messages received from
C-RPs and
distribute the RP-SET to ALL_PIM_ROUTERS group. The stand alone BSR will not
exchange hello
messages, or process the RP-SET contained in the BSM, it uses the BSMs
received purely for
election analysis. The intention is to make available the option of
configuring any router
in the domain, to just collect C-RP-ADVs and distribute the RP-SET, provided
it becomes the
elected BSR. Given this situation, the stand alone BSR will not get a copy
of the active RP-SET
from the DR. How than can we have a stand alone "BSR ONLY" router, without
having the routers in the
domain switch over between PIM-DM and PIM-SM, resulting from a NULL BSM
message.
         regards and thanks
           Ram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sridhar Vallepalli
Sent: Tuesday, August 07, 2001 11:56 PM
To: ramamurthy.pani; pim
Subject: Re: sending NULL Bootstrap message ??

-Sridhar

---

From: "K.P.Ramamurthy" <[email-masked]>
Date: Wed, 8 Aug 2001 09:12:07 +0530

Hi Sridhar,
           When the DR on an interface gets a hello packet from a NEW
neighbour,it will
unicast a copy of the current RP-SET to this new neighbour. This ensures
that the
new neighbour will have a copy of the current RP-SET, not having to wait for
BS_PERIOD
(worst case), to get the RP-SET from the BSR of the domain, but in the case
where a candidate
BSR which has been exchanging HELLO packets with its neighbours, happens to
become the E-BSR,
it will not get any attention from the DR on the interface, since its not a
new neighbour.
The E-BSR is expected to use its current RP-SET, which will not be present
if the router is
a stand alone BSR.
         regards and thanks
     Ram

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Sridhar
Vallepalli
Sent: Tuesday, August 07, 2001 11:56 PM
To: ramamurthy.pani; pim
Subject: Re: sending NULL Bootstrap message ??

-Sridhar