Subject: Object Orders

From: [email-masked]
Date: Mon, 28 Jan 2002 19:51:11 -0500 (EST)

Hello,

I have a question about the object orders.

In RFC 2205, section 3.1 states:
An implementation should create messages with the objects in the order
shown here, but accept the objects in any permissible order.

In sections 3.1.3 and 3.1.4, the standard asserts that the INTEGRITY
object must immediately follow the common header.

RFC 2961 also dictates strict ordering rules for the MESSAGE_ID object.

However, RFC 3209 notes: "The ordering of these objects is not important,
so an implementation MUST be prepared to accept objects in any order."

A strict interpretation of this statement would assume that if a device
disregards the object ordering rules, it can still interoperate.

What is the correct behavior for the following situation:

An LSR receives a Path or Resv message that violates the ordering rules.
Does it accept the message and allow the LSP tunnel to form?  Or does it
send an error message as recommended in Appendix B of RFC 2205?

Thanks,
-Ben

---

From: David Charlap <[email-masked]>
Date: Tue, 29 Jan 2002 10:49:01 -0500

[email-masked] wrote:
> An implementation should create messages with the objects in the
> order shown here, but accept the objects in any permissible order.

Please read the previous two sentences as well:

	The BNF implies an order for the objects in a message.
	However, in many (but not all) cases, object order makes no
	logical difference.

Please note the "but not all" clause.  There are some places where
object order is important.

> object must immediately follow the common header.

This is one of them.

It's also the case that flow descriptors are illegal until after the
STYLE object.

There are also ordering rules regarding the objects within flow
descriptors.

> RFC 2961 also dictates strict ordering rules for the MESSAGE_ID 

Yes.  When refresh reduction is used, MESSAGE_ID and ACK objects have
ordering requirements.

> However, RFC 3209 notes: "The ordering of these objects is not
> important, so an implementation MUST be prepared to accept objects
> in any order."

You are reading individual sentences out of context and jumping to the
completely wrong conclusion.

The sentence immediately before the one you quoted says:

	The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST,
	and SESSION_ATTRIBUTE objects is simply a recommendation.

The paragraph is saying that these three object classes do not have any
particular ordering requirements.  It is not saying that you are free to
discard the ordering requirements of all other objects that are
specified in other drafts.

> A strict interpretation of this statement would assume that if a
> device disregards the object ordering rules, it can still
> interoperate.

Be liberal in what you accept.  Be conservative in what you send.

If the object ordering you receive is not explicitly forbidden, then you
should accept the message.  But when you generate your own outgoing
message, you should order the objects according to the BNF in the RFC.

> An LSR receives a Path or Resv message that violates the ordering
> rules.  Does it accept the message and allow the LSP tunnel to form?
> Or does it send an error message as recommended in Appendix B of
> RFC 2205?

Depends on what the "violation" is.

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.

-- David

---

From: [email-masked]
Date: Tue, 29 Jan 2002 19:00:03 -0500 (EST)

Hello David,

I agree with you in theory, but I can not find a reference to support 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?

Thanks,
-Ben

---

From: David Charlap <[email-masked]>
Date: Wed, 30 Jan 2002 10:21:10 -0500

[email-masked] 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