The MPLS WG Archive

[Ping Pan <ppan@ciena.com>]

David,

First of all, this is an implementation issue.

The real issue here is not at the receiving nodes, rather it is at the 
sending nodes. When refresh reduction is set on an outgoing interface, 
how do you know that the messages can be processed by the receiving nodes?

Worse, if a receiving node has implemented only one of the 4 features in 
refresh reduction, it may send messages with RR-enabled bit on, now what 
  do you do? For example, in my past life, I need to deal the following: 
per OIF standard, a receiving node needs only support msg-ack, but will 
turn on the RR-enable bit anyway. Great! When a sending node starts to 
send out summary refreshes, the receiving node will drop the refreshes 
and time-out all sessions.

Thus, the focus is to make the sending nodes knowing the status of the 
receiving nodes. One solution is the following: once a RR-enable bit is 
detected from a RSVP neighbor, the sending node starts to probe the 
neighbor by sending two identical refresh messages periodically: one 
with RR-enabled bit, and msg-ack; the other without. If an ack is 
received from the receiving node, the life is good... (there ,ay be some 
other twisted corner cases). If there is no ack, only send the plain 
refreshes to the receiving nodes, and log the error.

I agree with Curtis, don't anything with the spec, and beat up the code 
again and again.

Regards,

- Ping



David Charlap wrote:
> 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