The MPLS WG Archive

[Thomas Nadeau <tnadeau@cisco.com>]

At 03:00 PM 8/29/2001 -0400, Irfan Lateef wrote:
>Cheenu et al,
>
>The mplsInterfaceConfTable in draft-ietf-mpls-lsr-mib-07.txt contains
>the attribute mplsInterfaceAvailableBandwidth
>
>Typically the management application can use this attribute while
>computing a constrained TE path or an LSP path.
>Now if the signalling protocol is also setting up LSP on this
>interface at or around the same time, the management application
>would be computing a path based on incoreect value because the
>value of this attribute may not be current.
>
>My question is do we need a trap, like AvailableBandwidthChange,
>to be sent to the NMS whenever a LSP is setup/teardown on an
>interface. In the absence of such a mechanism the NMS may need to
>get the value of all the interface in the network before it computes
>the path even if the values may not have changed.
>
>So in order to keep the NMS in sync with the NE I think a trap is
>needed. If you think this is not the way to keep the NMS in sync with
>the state of the NE then what is your suggestion.
>Appreciate your comments.

         I think that you raise an important point, but I would
first think carefully about whether or not you want to do
what you describe. What you seem to want to do are
ad hoc off-line TE calculations and then push them down to
the devices. First, as you mention there is a time lag between
when the bandwidth changes and when the NMS can know
about it. This is why it might be a better idea to let the
routers do the path computation after feeding them some
constraints (i.e.: end points and bandwidth requirements).

         Now, if you want to truly do what you describe, I don't
think that adding a notification will help prevent the
timing problem, since the bandwidth can still change
between the time that the notification is sent and processed
by the NMS. Furthermore, since notifications are typically
unreliable, they can be lost, and thus we have the same problem
even after implementing such a notification.

         --Tom