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

From: Lou Berger <[email-masked]>
Date: Mon, 18 Oct 1999 08:41:29 -0400

Bob,
	Now that you've had a chance to review the draft, do you have an opinion
on the open issue mentioned below?

Thanks,
Lou

>X-Sender: [email-masked] (Unverified)
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
>Date: Mon, 27 Sep 1999 09:05:27 -0400
>To: [email-masked]
>From: Lou Berger <[email-masked]>
>Subject: updated refresh-reduct draft & open issue
>Cc: [email-masked], [email-masked], [email-masked],
>        [email-masked]
>Sender: [email-masked]
>
>The recently announced draft draft-ietf-rsvp-refresh-reduct-00.txt contains
>the following changes:
>
>- Changed draft name from draft-berger-rsvp-refresh-reduct-03.txt.
>
>- Removed Hello Messages and associated MESSAGE_ID processing.
>
>- Updated Srefresh per Oslo:
>  1) Introduced MESSAGE_ID LIST object so that MESSAGE_ID object 
>     epoch value isn't repeated.
>  2) Introduced MESSAGE_ID SRC_LIST and MCAST_LIST objects to 
>     properly handle multicast (S,G) forwarding for multi-access 
>     networks and an optimization for point-to-point links.
>
>- Other minor edits and clarifications
>
>There is a minor open issue related to the second Srefresh change.  
>This issue ONLY relates to the summery refreshing of multicast Path
>state over multi-access (ethernet) networks.
>
>The draft currently states that on multi-access networks an Srefresh 
>is sent per multicast group Srefresh messages.  Essentially, only
>the Path state of multiple senders will be refreshed within a 
>single message.
>
>An alternative approach is to send all the multicast Path associated 
>Message_Ids within a single message (MTU permitting) to the all RSVP 
>routers multicast group.  
>
>In the documented approach only Srefreshes related to groups being 
>forward by a receiver are processed by RSVP at the receiver.  In the 
>alternative approach, RSVP at the receiver will see all Srefreshes 
>and will need to identify which groups (actually {S,G}s) are being 
>forwarded by the system.
>
>The big win of the alternative approach is that only a single message 
>will be sent, compared to a message per group.  The cost is that, at 
>receiving nodes, RSVP will need to perform {S,G} lookups to identify 
>entries that should be ignored.  (Currently {S,G} filtering is 
>typically done in the forwarding path and RSVP never needs to perform
>this lookup.)
>
>The authors of the draft would like to solicit any comments that the
>working group may have on this issue.
>
>Thank you.
>