The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3D920C82.4040805@marconi.com>, David Charlap writes:
> 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


David,

I think that falls under "Be conservative in what you send and liberal
in what you accept".  It need not be in the spec, but if you recognize
what appears to be a minor coding error in another implementation, it
might be a logical choice to log the error and process the messages.
The counter argument is that if the implementation is that shakey
maybe you don't want to trust it and disabling a buggy Refresh
Reduction implementation would also be a logical choice since it is
just an optimization.

Again, this is not something that should be in the spec.  The sender
should get it right and it would be acceptable as far as the spec is
concerned to either reject it or log and accept and try to continue.

Curtis