Subject: Re: Fwd: updated refresh-reduct draft & open issue

From: [email-masked]
Date: Mon, 18 Oct 1999 08:49:46 -0700

Lou,

Sorry, I overlooked this issue.

Now that I look at it, I don't understand it.

Bob

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Oct 1999 14:01:14 -0400

This is really an operational impact issue.

Srefresh as currently documented supports two flavors of multicast related
lists.  This document and code complexity provides the benefit of
aggregation of multicast path Srefreshes on point-to-point links.  (On
multi-access links, only Resv messages from multiple senders and to the
same multicast destinations may be aggregated.)  

An alternative has been proposed to aggregate *all* multicast path
Srefreshes within a single message with the message destined to the all
RSVP nodes subnet multicast address.  The primary benefit of this approach
is higher aggregation.  It's also simpler in specification and code.  The
drawback is that RSVP must perform an {S,G} check for each listed group.
This check must be performed even when the receiving node is *not* a member
of the group.

So the issue comes down to message rate versus non-participant node
processing.  The issue is limited to multi-access networks.

Lou