Subject: Question on BSM Semantic Fragmentation

From: "Mroz, Mike" <[email-masked]>
Date: Fri, 23 Mar 2001 10:31:44 -0500

Hello,

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

Mike

------------------------
Michael D. Mroz
Network Peripherals, Inc.
Tel: (919)313-4683 (temporary)
FAX: (919)313-4643 (temporary)

---

From: Mark Handley <[email-masked]>
Date: Fri, 23 Mar 2001 09:06:34 -0800

>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

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.

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.

Cheers,
	Mark