The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Sep> msg00083



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

RSVP Refresh Reduction question

  • From: David Charlap <David.Charlap@marconi.com>
  • Date: Wed, 25 Sep 2002 15:20:34 -0400
  • User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20020920

The Refresh Reduction RFC (RFC 2961) says that the "refresh reduction 
enabled" bit must be set in the common header of all messages that an 
RR-enabled router sends.  Routers receiving RSVP messages check for the 
presence or absence of this bit to determine if the neighbor will 
understand Bundle, SRefresh and Ack messages.  All this is clear.

Obviously, all Bundle, SRefresh and Ack messages must have this bit set 
in their headers, since only an RR-enabled router could send such a message.

My question is what should a router do if it receives a Bundle, SRefresh 
or Ack message where the RR-enabled bit is not set in the common header.

One opinion I've heard is that the message should be silently dropped, 
since its header is non-compliant with the RFC.

I disagree, however.  I think that the message should be processed as if 
the bit was set.  The information conveyed by the RR-enabled bit (that 
the sender supports RR) is implicit in the fact that the message is a 
Bundle, SRefresh or Ack.  Leaving the RR-enabled bit out of the header 
doesn't remove any information from the message, so there is no reason 
why it should be dropped.

What do others here think?  Should routers accept or drop such messages?

-- David