The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Ping Pan wrote:
> 
> 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?

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.

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

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

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

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 
> again and again.

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