The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Irfan,

    Just to add to what Tom says, there are other scary aspects of this
question.
For one, your question seems to assume that an NMS is being used to compute
paths, but that some other mechanism is being used to set them up and there is
apparently no coordination between the two mechanisms.  For another, in order
to avoid the trap storms that Cheenu mentioned, you'd have to include notions
of change granularity and minimum reporting cycle time.  This quickly starts to
be more costly than beneficial.

--
Eric Gray

Thomas Nadeau wrote:

> 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