Subject: RSVP Refresh Reduction question

From: David Charlap <[email-masked]>
Date: Wed, 25 Sep 2002 15:20:34 -0400

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 25 Sep 2002 22:13:40 -0400

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

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

---

From: Ping Pan <[email-masked]>
Date: Thu, 26 Sep 2002 07:50:42 -0700

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

---

From: David Charlap <[email-masked]>
Date: Thu, 26 Sep 2002 11:21:59 -0400

> how do you know that the messages can be processed by the receiving nodes?

That's another important issue, but not the one I was asking about.  We 
have a piece of conformance-test software which thinks switches must 
drop Bundle messages that don't have the RR bit.  My posting here was 
mostly to determine if they are correct in making that a requirement or 
not - and the consensus here is that they are not correct.

> and time-out all sessions.

Sounds like a broken node.  The RFC clearly states that a node setting 
the bit is telling neighbors that he can receive SRefresh, Bundle and 
Ack messages.

Note also that support for MESSAGE_ID objects is separate from these. 
Support for them is indicated by returning an ACK object upon receipt of 
a MESSAGE_ID, or by returning an "invalid object class" error if it 
isn't supported.

A node should not generate an SRefresh message until it knows that the 
neighbor both supports the RR messages (from the header bit) and that it 
supports MESSAGE_ID (by acknowledging an incoming message ID).

> refreshes to the receiving nodes, and log the error.

Yes.  But your solution here doesn't solve your problem.  Your test will 
prove that the other end knows about MESSAGE_ID, not that it can support 
an SRefresh or Bundle message.

Personally, I don't think supporting them is that difficult.  If you 
support MESSAGE_ID, then you already have all the infrastructure in 
place ncessary to support an incoming SRefresh, even if you don't have 
the infrastructure needed to generate one.  Ditto for Ack messages - if 
you can proces the ACK object in other messages, then you can process it 
in an Ack message.  Bundle messages can be processed with virtually no 
changes to any code-bsae, even if generating them may be difficult.

I would seriously question the viability of any implementation that sets 
the RR bit and doesn't handle all three of these messages.

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

I'm not sure what you're recommending here.  If you're saying that lots 
of interop testing is required, I agree completely.  But that doesn't 
mean the spec isn't ambiguous here.

Personally, I don't like the fact that several parts of RSVP-TE post 
requirements regarding how a message must be formatted, but fail to 
specify how to handle a non-compliant message.

-- David