The MPLS WG Archive

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Irfan:

I think in such situations NMS should poll this parameter
at regualr intervals. This interval should be long enough
not to overwhelm your control channel and short enough to
get almost correct value.

The routing protocol should advertize the avilable change
only after certain thresholds have crossed.

When there is a conflict on the reservations between the
dynamic and static allocations it should be solved during the
signaling phase. I would put manual configuration at a
higher priority in such a conflict as recovering from such
a failure is diffucult than that using dynamic protocols.

Hope this makes sense.

sudheer

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.
>
> Regards,
> Irfan Lateef
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp