Subject: LSR-MIB - AvailableBandwidth ?

From: "Irfan Lateef" <[email-masked]>
Date: Wed, 29 Aug 2001 15:00:24 -0400

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

---

From: "Cheenu Srinivasan" <[email-masked]>
Date: Wed, 29 Aug 2001 15:28:54 -0400

> the state of the NE then what is your suggestion.

This would lead to a trap storm. If you want to track link states
at this time scale your best bet is probably to participate passively
in the IGP.

Cheenu

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 29 Aug 2001 13:10:19 -0700

>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

---

From: Eric Gray <[email-masked]>
Date: Wed, 29 Aug 2001 16:43:24 -0400

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

---

From: Sudheer Dharanikota <[email-masked]>
Date: Wed, 29 Aug 2001 16:50:59 -0700

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