The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	There isn't much you can do about it, if the rro gets too big, it
is dropped. See section 4.4.3 of the rfc.

"If the newly added subobject causes the RRO to be too big to fit in a
   Path (or Resv) message, the RRO object SHALL be dropped from the
   message and message processing continues as normal.  A PathErr (or
   ResvErr) message SHOULD be sent back to the sender (or receiver).  An
   error code of "Notify" and an error value of "RRO too large for MTU"
   is used.  If the receiver receives such a ResvErr, it SHOULD send a
   PathErr message with error code of "Notify" and an error value of
   "RRO notification".


			Ina

On Thu, 8 May 2003, bhuvan laddha wrote:

> Hi,
>
> I would appreciate clarification for the following
> point in the RFC: 3209:
>
> 1. Section 4.4.1.3 states -
>
> "The Length contains the total length of the subobject
> in bytes,including the Type and Length fields."
>
> Assume labels represents "set of time-slots".Now,if
> the set is large (e.g. 100 labels ),then Length of the
> subobject will be 404 and length field is just one
> byte and inadequate to carry this value (404) .
> I would appreciate if someone can indicate how the
> implemenation should handle this.
>
> Thanx,
> ---Bhuvan.
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>