Subject: [pim] Removing an RP from the RP-set

From: John Zwiebel <[email-masked]>
Date: Tue, 15 Nov 2005 12:47:34 -0800

Does the BSR draft want RPs to be removed from the RP-set explicitly
or implicitly.

In the following, one has a choice of not sending a deleted C-RP in the
BSM (implicit deletion) or sending a BSM with the C-RP holdtime set  
to 0,
which results in explicit deletion of the C-RP from the client routers.
Considering what the draft says about a group range and the loss of a  
BSMF,
I would think that explicit removal is preferred.

Just before 3.2:
   When a C-RP is being shut down, it SHOULD immediately send a C-RP- 
Adv to
   the BSR for each scope for which it is currently serving as an RP;  
the
   HoldTime in this C-RP-Adv message should be zero.  The BSR will then
   immediately time out the C-RP and generate a new BSR message removing
   the shut down RP from the RPset.

Inside of 3.2:
      HoldTime
           The HoldTime from the C-RP-Adv message.  This is included
           later in the RP-set information in the Bootstrap Message.

Contrast the above with removal of a group range at the end of p26 in  
4.1.1

   It should retain this information for BS Timeout seconds.  Thus
   for a BSR to remove a group-prefix from the BSR, it should include  
that
   group-prefix, but with a RP Count of zero, and it should resend this
   information in each BSM for BS Timeout seconds.

I would recommend that the paragraph just before 3.2 be modified to  
say in
the last sentence:

    The BSR will then immediately time out the C-RP and generate a  
new BSR message
    with the shut down RP holdtime set to 0.

And under the RP-count paragraph in section 4.1.  I'd add:

    (unless the holdtime for a given RP is 0, in which case it is  
removed from the
	RP-set immediately).

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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 13:10:50 +0100

> Does the BSR draft want RPs to be removed from the RP-set explicitly

Both (which I think is in the spirit of previous BSR).

> Considering what the draft says about a group range and the loss of a  

I believe we say that a group range should not span several BSMFs. If
it does and you use "implicit", then you need to get all BSMFs that the
range spans before you can tell whether an RP is missing.

>   information in each BSM for BS Timeout seconds.

Since we now do a combination of implicit and explicit this would work.
Doing only explicit we would need to send several BSMs with each RP of
the previous RPs in the range having a holdtime of 0.

>    (unless the holdtime for a given RP is 0, in which case it is  

So what we say now is that we immediately send BSM with RP holdtime
of 0, but we also remove RPs if they are missing from the range.

We can of course discuss whether that is the right approach. Not
much feedback from wg until now...

Stig

---

From: John Zwiebel <[email-masked]>
Date: Mon, 21 Nov 2005 09:51:28 -0800

> of 0, but we also remove RPs if they are missing from the range.

FWIW: My experience with the explicit removal of RPs has been
very positive.  I especially like it when one considers whether or
not the complete RP-cache is to be included in triggered BSM.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 20:06:57 +0100

> not the complete RP-cache is to be included in triggered BSM.

Right, I see that. With the combined approach currently described, you
would need to at least send a complete group range (including all the
RP's in the RP-set for that range).

One issue I see with only doing explicit, is that one needs to send
multiple BSMs with holdtime of 0 (or just hope that the single BSM
with holdtime of 0 doesn't get dropped anywhere).

> >much feedback from wg until now...

We've had quite a bit of discussion between the authors on implicit
vs explicit and also asked the wg for input. If you want I can explain
further why I believe we should not just do explicit.

Stig

---

From: John Zwiebel <[email-masked]>
Date: Mon, 21 Nov 2005 13:29:43 -0800

> further why I believe we should not just do explicit.

Isn't it true that a BSM with a BSR priority of 0 means the BSM is
   shutting down?  This will trigger a new BSR-election.  It isn't
   clear to me what's suppose to happen during this election WRT the
   RPs contained in the BSM.  I would hope that the election wouldn't
   require all the C-BSRs to include all the RPs it has in its cache.
   But it would seem that if you depend on implicit deletion, then it
   would have to.  And if there are a large number of RPs requiring
   BSM fragmentation, now things start to get complicated.

Just before 3.3 it says:
   When an elected BSR is being shut down, it should immediately  
originate
   a Bootstrap message listing its current RP set, but with the BSR
   priority field set to the lowest priority value possible.  This will
   cause the election of a new BSR to happen more quickly.

The relationship between the C-BSRs is fairly well defined in 3, and if
the E-BSR sends the priority of 0 then...

   Accept Preferred (AP)
      The router knows the identity of the current BSR, and is using the
      RP-Set provided by that BSR.  Only bootstrap messages from that  
BSR
      or from a C-BSR with higher weight than the current BSR will be
      accepted.

This formula is suppose to tell us how long it takes to move from C- 
RP to E-RP
Looks like its going to be at least 15 seconds if there is any  
significant
difference in priority (ie 200=best 150=second best log_2(51) =  
5.6).  Am I mistaken?
Is this 'fast enough'?  Or should a user configure all C-BSRs with  
near equal priorities?
(ie 200,201,202...)

           Delay = 5 + 2 * log_2(1 + bestPriority - myPriority)
                   + AddrDelay

[PS, I note that if bestPriority < myPriority its kind of hard to use  
this formula.
And if one used abs(best-my) you end up with a situation where a C- 
BSR with a worse
priority ends up triggering a BSM to win the election before the one  
with the better
priority.   ie   best = 50   A=100 B=200, A will have a smaller  
"Delay" than B.]

But back to explicit vs implicit:
   -- large number of C-RPs explicit desired
   -- small number of C-RPs implicit ok

A couple of options:
   -- explicit vs implicit might be vendor configurable.
   -- the MSB-bit from the hash-lengh (or from the reserved field)  
might be used
	to define explicit vs implicit.

I'm not sure I'm recommending either option though.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Nov 2005 23:25:26 +0100

>   require all the C-BSRs to include all the RPs it has in its cache.

Right, it should send BSM with priority 0, since there hopefully is
another C-BSR with non-zero priority, which then will be triggered
to send a BSM. If it didn't, one would have to wait for timeout.

A non C-BSR would use the information in the BSM as normal. However,
the other C-BSRs would be triggered.
 
>   BSM fragmentation, now things start to get complicated.

With current draft, the C-BSRs can choose to send an empty BSM. An
empty BSM does not affect the stored RP-set. It's merely a mechanism
for doing the election and trigger C-RPs to send advertisements.
Note that at least for non-scoped case, BSM contains no group ranges,
so reasonable that nothing should be deleted.

> Is this 'fast enough'?  Or should a user configure all C-BSRs with  

I think it's fine to require near equal if this is an issue. With a
reasonable amount of C-BSRs it wouldn't be too bad then. In some
deployments I guess one would also be ok using the same priority
and let the address decide? I think we can change the formula though.
We have been wondering whether the 5s minimum delay is needed. We
haven't yet had a strong reason to change the formula, so we left it
alone. If we make the delay for different priorities smaller, there
is a danger that routers with smaller priorities needlessly send BSMs
though. This depends on the one-way delay between the C-BSRs.

> priority.   ie   best = 50   A=100 B=200, A will have a smaller  

bestPriority is defined as max(storedPriority, myPriority).

>   -- explicit vs implicit might be vendor configurable.

Yes, have thought of that.

> 	to define explicit vs implicit.

I'm a bit concerned with backwards compatibility though. I think
it's good if the new spec would work reasonably well with at least
non-C-BSRs implementing RFC 2362. Having it configurable at the
C-BSRs might be good. One could then possibly accomodate the old
2362 implementations. Unfortunately 2362 isn't very clear and
implementations have done different things.

> I'm not sure I'm recommending either option though.

My main reasons for also doing implicit are:

1. I read 2362 that way and several implementations do implicit.
   If we don't send complete group ranges (including all the RPs)
   those implementations would end up removing the omitted ones.
   
2. If we don't do implicit, we will need to send multiple BSMs
   with holdtime of 0 for an RP to remove it safely. If not we
   are in trouble if the first one gets dropped.

The problem I see with implicit, is that a newly elected BSR will
need to have a complete RP-set for a group range to not accidentally
remove RPs. With the current spec using empty BSMs and triggering of
C-RP-advs and BSMs I believe we have taken care of this.

Stig