The MPLS WG Archive

[schultz@io.iol.unh.edu]

Hello David,

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?

Thanks,
-Ben

On Tue, 29 Jan 2002, David Charlap wrote:

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