Subject: RE: Question on BSM Semantic Fragmentation

From: "Mroz, Mike" <[email-masked]>
Date: Fri, 23 Mar 2001 17:00:32 -0500

See my comments below:

> -----Original Message-----
> From: Mark Handley [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 12:07 PM
> To: Mroz, Mike
> Cc: [email-masked]'
> Subject: Re: Question on BSM Semantic Fragmentation 
> 
> 
> 
> >I have the following understanding of BSM semantic 
> fragmentation, leading
> >to questions that are enclosed.
> >
> >It appears that semantic fragmentation was defined to allow 
> processing of 
> >partial bootstrap messages as fragments arrive (as opposed to IP 
> >Fragmentation, where processing is not performed until reassembly is 
> >finished). If a fragment is received it is processed 
> immediately, meaning
> >that semantic fragmentation implementation is required since 
> loss of a 
> >semantic fragment consequently has a different end result 
> than loss of an
> >IP fragment.
> >
> >The mechanism does not provide any method for detection of fragment
> >loss. If we assume no administrative scoping, the total BSM 
> contains a
> >list of group prefixes (with zero Z-bit) and associated 
> lists of RPs. 
> >When the entire message has been received, we must eliminate 
> any group 
> >prefixes that were not contained in the RP-set, and 
> consequently remove
> >any (*,G) state associated to the (deleted) group prefix. If 
> a fragment
> >was lost, any wholly-contained group/RP list are also lost, 
> and so are
> >deleted from the stored RP-set.
> >
> >How does a router know when the entire BSM has been received 
> so it can
> >delete groups that were removed from the RP-set? We've thought about 
> >using a timeout to trigger the deletion of these groups. 
> 
> As far as I know, semantic fragmentation of BSMs was never
> sufficiently well defined in any of the specs.  Thanks for pointing
> this issue out - we need to specify it properly this time.
> 
> What do current implementations actually do?  In practice, my guess is
> that currently no-one sends BSMs that need to be fragmented because
> no-one's using BSM in a large enough domain.
> 
> >This is clearly
> >not a problem for admin scoped groups as the SZ Timeout 
> should take care
> >of the absence of the groups from the BSM.
> 
> It's not a problem if the RPs for the admin scope fit in one packet,
> or if all of them are RPs for the entire admin scope range, but if
> they don't fit and we announce RPs for sub-ranges of an admin-scope
> range (this is allowed, so long as we also announce the whole admin
> scope range at the start of the BSM fragment), then the issue is just
> the same as for non-admin scoped RPs.
> 
> 
> 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.

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? What else could it be?

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).

> 
> 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.

> Cheers,
> 	Mark

Regards,

Mike

---

From: Mark Handley <[email-masked]>
Date: Fri, 23 Mar 2001 15:18:44 -0800

>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.

>the event be the receipt of the BSM itself?

Yes, that's what I was thinking.

>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.

>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.

Cheers,
	Mark