The MPLS WG Archive

["Vijayanand C - CTD, Chennai." <vijayc@ctd.hcltech.com>]

One would expect the behaviour to be implementation dependent. While it
would be perfectly legitimate for the reciver to drop these messages, it may
be robust/liberal enought to accept them. But, I think it would not be right
to expect all implementations to accept such messages.

Vijay

-----Original Message-----
From: David Charlap [mailto:David.Charlap@marconi.com]
Sent: Thursday, September 26, 2002 12:51 AM
To: IETF MPLS List
Subject: RSVP Refresh Reduction question


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