Subject: updated refresh-reduct draft & open issue

From: Lou Berger <[email-masked]>
Date: Mon, 27 Sep 1999 09:05:27 -0400

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.

---

From: Geping Chen <[email-masked]>
Date: Mon, 27 Sep 1999 09:35:11 -0400

Hi, Lou,

For the "hello" and "refresh suspension" mechanism
proposed in the previous version of this draft, do you
think we need to

1) do more experiments and continue discuss it
or
2) just drop it and have no intention to do more
    experiments ?

Thanks,

Geping Chen

---

From: Lou Berger <[email-masked]>
Date: Mon, 27 Sep 1999 09:55:22 -0400

My understanding of the consensus of the RSVP working group is that the
Group does not believe that Hellos and elimination of refreshes as
appropriate general RSVP extensions.  

There's been great interest in Hellos and at least one running
implementation. Based on comments I've received, I plan to move Hellos with
standard refreshes and Srefreshes forward.  (i.e., no elimination of
refreshes.)  This will happen in an application targeted (MPLS) working
group.  Watch the MPLS WG's mailing list if you're interested.  It should
be out within a few weeks.

Lou