Subject: RE: Question on BSM Semantic Fragmentation

From: "Mroz, Mike" <[email-masked]>
Date: Mon, 26 Mar 2001 08:03:27 -0500

Please see my comments below.

> From: Mark Handley
> 
> >> The obvious thing (and I think what was intended) is to use the RP
> >> holdtimes to hold the state.  If in one BSM a group range G1 is
> >> announced with RPs RP1, RP2, and RP3, then we hold that state until
> >> each of those RPs holdtimes expires, or until we see a BSM 
> containing
> >> the same group range G1 and different RPs, or until a BSR change.
> >>
> >
> >I could never figure out why C-RP-Adv HoldTime is included in the 
> >BSM. I had thought of your suggestion before, but it didn't 
> seem to make 
> >sense because the HoldTime is used by the RP to announce a validity 
> >duration to the BSR for the C-RP info. There is no 
> correlation that I 
> >can find between the HoldTime and the BS Period. This means that a 
> >short Holdtime and a longer BS period could result in the premature 
> >aging of RPs at non-BSR PIM routers.
> 
> Agreed.  We'd have to specify the relationship between RP Holdtimes
> and the BS period, or allow the BSR to specify holdtimes that are not
> what the RP gave in its C-RP-Adv.

In Minneapolis, concern was expressed about the time it takes for 
convergence when an RP changes. One suggestion was that the
C-RP-Adv-Period be shortened (to possibly 1 second) through 
configuration, and that the sending of a BSM could be triggered 
when a (3-second) Holdtime expires. This could impact the first 
part of the suggestion above. Allowing the BSR to specify different 
holdtimes would avoid this conflict.

> 
> >What event would retrigger the HoldTime-related timer at a 
> non-BSR PIM
> >router? At the BSR, the event is the receipt of a C-RP 
> message. Would 
> >the event be the receipt of the BSM itself?
> 
> Yes, that's what I was thinking.
> 
> >Also, this means running a timer for each RP and group prefix 
> >combination since an RP could cease advertising a particular group 
> >prefix while continuing to advertise others. In this case, 
> receipt of 
> >the group prefix/RP combination in a BSM would be the retriggering 
> >event (vs. receiving the BSM).
> 
> Yes.  An alternative is to run one timer per advertised group range,
> set to the minimum of the RP's holdtimes.  But I think it's probably
> better to run one timer per RP.  Strictly speaking, you don't really
> need a proper timer either; just check the timeouts when a new BSM
> arrives.

Since the issue is lost BSM fragments, whole groups are lost (even 
when a group spans multiple segments). RPs may be referenced by 
multiple groups, and that would have the tendency to keep the RP
alive if needed. It seems that one timer per advertised group range 
is probably sufficient.

If that is so, the BSMs become more compact if only one timer is 
sent per group. An IPv4 encoded unicast address plus an RP priority 
and a reserved octet would be eight bytes long instead of the current
ten bytes.

> 
> >> However, to make this reliable, if the RPset stops containing *any*
> >> RPs for G1, then the BSR must still announce the range G1 until the
> >> maximum of the holdtimes of those RPs it announced expires, even if
> >> this entails announcing a group range with no RPs for a while.
> >
> >Announcing a group range with no RPs would probably be a good way of
> >announcing the fact that the group is no longer configured for the 
> >global scope zone. Another possibility could be the reverse of the 
> >Z-bit. It is initially cleared, and then set when the group is to be 
> >deleted from the global scope zone.
> 
> I don't think a bit is necessary here - a new BSM changes the RP set
> for a group range anyway (overriding RP timeouts), and so sending one
> with no RPs has the same semantics (the RP set for the group range is
> now empty) and ought to be backwards compatible.
> 
> 
> But I'm really curious as to what any of the current implementations
> actually do in the case of a fragmented BSM where a fragment
> containing an entire group-range is lost?  It certainly doesn't seem
> to be possible to implement this correctly from RFC 2362.

I agree. I suspect very few RFC2362 implementors provided BSM 
fragmentation.

> Cheers,
> 	Mark

Best Regards,

Mike