The MPLS WG Archive

["Reddy, Vikram" <vikramr@netplane.com>]

Hi David,

This is interesting. The following is my opinion.

If the recieving node had set the RR Capable bit in its last msg Common
Header,
it should accept a Bundle, SRefresh msg from its neighbor. If the receiver
node
had not set the bit it should not accept the message, irrespective of
whether
it has RR capability or not.

The sender should not need to set the bit. The sender could be RR enabled,
may send RR messages
to a willing neighbor, but must have the flexibility to not want to accept
RR messages from the 
neighbor. If it sets the RR capable bit, then it is advertising that it is 
open to recieve RR messages, else it is saying, "I will drop RR messages if
you send them to me".

The significane of the bit is whether a reciever is willing to receive RR
messages
or not. 


"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."

Also, I would like to differ from the statement you made above.Consider the
following,
1) The case where a node wishes to send RR capable messages but does not
want to receive them.
   (Although I can't think of why it wouldn't want to receive them).
2) A node has been recieving RR messages but wants to turn it off. But there
is a Bundle Message
   which has been waiting for some time (accumulation time). It has to send
the bundle 
   message but with the bit not set.


Thanks,
Vikram.




-----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