The MPLS WG Archive

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

schultz@io.iol.unh.edu wrote:
> 
> 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.

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.

> In sections 3.1.3 and 3.1.4, the standard asserts that the INTEGRITY
> 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 
> object.

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.

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

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