The MPLS WG Archive

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

schultz@io.iol.unh.edu wrote:
> 
> I agree with you in theory, but I can not find a reference to
> support the following example:
> 
>> If you get an INTEGRITY object in the middle of the message, then
>> you must reject the message.  If you get an ADSPEC before the
>> SESSION object, then you should accept it.  It all depends on
>> whether the ordering you receive is explicitly forbidden or not.
>>
>> Also, please re-read RFC 2205 more closely.  Object ordering
>> violations do not result in the generation of a PathErr/ResvErr
>> message.  The message is simply ignored if the order is invalid.
> 
> I apologize for not being more clear in my previous email.  RFCs
> 2205, 2961 and 3209 do not mention silently discarding or ignoring
> messages that violate object order rules.  I am looking for a
> reference to support the idea that a device should silently discard
> messages that violate these rules.  Does anyone know of one?

Read Appendix B.  After the description of the last error code, it says:

	...
	Should a programming error allow an RSVP to create a
	malformed message, the error is not generally reported to
	end systems in an ERROR_SPEC object; instead, the error is
	simply logged locally, and perhaps reported through network
	management mechanisms.

	The only message formatting eerrors that are reported to
	end systems are those that may reflect version mismatches,
	and which the end system might be able to circumvent, e.g.,
	by falling back to a previous CType for an object; see code
	13 and 14 above.

	The choice of message formatting errors that an RSVP may
	detect and log locally is implementation-specific, but it
	will typically include the following:

	...
	o    Violation of required object order
	...

If a router is generating messages with the wrong object order, sending
it a PathErr is not going to make it start using the correct order. 
Therefore, there is no point to sending the error in the first place,
which is what Appendix B says.

-- David