Subject: Reg RFC 2961

From: "Rajesh Advani" <[email-masked]>
Date: Wed, 11 Jul 2001 16:31:06 +0500

Hi all , 
I have a doubt regarding RFC 2961 (RSVP Refresh Overhead Reduction 
Extensions) . 

I could not understand the reason for having a separate MESSAGE_ID 
SRC_LIST object and a MESSAGE_ID MCAST_LIST object . What exactly is 
the purpose of wanting to send a refresh message sometimes to the next 
hop and sometimes to the multicast destination ? Isn't refresh 
messaging always supposed to be hop-by-hop ? 

Could somebody please address this problem ? 

Thank U for u'r time , 
Rajesh Advani .

---

From: Bob Braden <[email-masked]>
Date: Wed, 11 Jul 2001 20:55:05 GMT

*> From [email-masked]  Wed Jul 11 04:41:33 2001
  *> From: "Rajesh Advani" <[email-masked]>
  *> To: [email-masked]
  *> Date: Wed, 11 Jul 2001 16:31:06 +0500
  *> MIME-Version: 1.0
  *> Content-Language: en
  *> Subject: Reg RFC 2961
  *> X-Accept-Language: en
  *> Content-Disposition: inline
  *> 
  *> Hi all , 
  *> I have a doubt regarding RFC 2961 (RSVP Refresh Overhead Reduction 
  *> Extensions) . 
  *> 
  *> I could not understand the reason for having a separate MESSAGE_ID 
  *> SRC_LIST object and a MESSAGE_ID MCAST_LIST object . What exactly is 
  *> the purpose of wanting to send a refresh message sometimes to the next 
  *> hop and sometimes to the multicast destination ? Isn't refresh 
  *> messaging always supposed to be hop-by-hop ? 
  *> 

Refreshing is (RSVP-)hop by (RSVP-) hop, but in the downstream
direction you might not know the next hop(s).   Therefore, in basic
RSVP Path refresh messages are sent to the session destination address,
which might be multicast.  This handles the case of a broadcast or
NMBA network, and the case of a non-RSVP cloud.

Bob Braden

  *> Could somebody please address this problem ? 
  *> 
  *> Thank U for u'r time , 
  *> Rajesh Advani . 
  *> 
  *> 
  *> 
  *>