The MPLS WG Archive

["Irfan Lateef" <irfanlateef@hotmail.com>]

Hi,

I will try to reply Cheenu, Tom and Eric in one mail.

Alarm or Trap Storms are considered to be undesirable during
failures because all of them tend to convey the same information during 
failure and hinder any corrective acton by congesting the
network. Even worse sometimes they are only a side effect of a
failure in the network downstream.
This generally happens in transport networks because of
the ability of the network to propagate the defect in forward and
backward direction. Where as in the present case, if an LSP is setup
across N links, then receiving N traps indicating a change in the
available bandwidth of each link respectively is not redundant and
undesirable but necessary. The debatable point could when should it
be sent. Also as Eric pointed if this is used for monitoring, even
then this has to updated at some agreeable interval period.

The second point I would like to make is the assumption that the
networks under consideration are fairly stable, in the sense that the
time scales for setup and teardown are fairly large. For example,
an enterprise customer requesting a 1 Gb pipe from point A to B.

As the number contraints and the number of nodes increase, the
optimization algorithm may become computationally expensive to fit in
the device, hence a desire to compute the bigger bw LSP with more
efficient mechanism off-line.

Addressing the time lag issue. Assume an LSP is being setup

A---B---C---D---E

While you are computing a path in A, from A to E, if C setup another
LSP from C to D and the OSPF update has not yet occured, you still
have the same problem. So let us assume we are operating with the
same assumption of time granularity irrespective of where we are
computing the path and also assume that the network does not change
between computation and setup.

Eric, you are right. for the reasons mentioned I am proposing TE
computation off-line in NMS and then setup from ingress and I am
trying to bring about the necessary coordination by the proposed
TRAP. Autonomous notifications will address the granularity and
reporting cycle issue.

So sending the notification and making the same assumptions as you
would have made while computing the path in the device could solve
the problem I am trying to impress upon the list and the authors.

However taking a cue from this discussion, the other method to do
the calculation  could be to retrieve the whole OSPF-TE MIB from
the ingress node and compute the path. But that also has some of the
caveats discussed above. Also I am not sure what would be the size
of such a MIB in large network.

Regards,

Irfan Lateef

P.S : Cheenu, Can you clarify the passive OSPF suggestion ,
      I did not understand your exact idea.





>From: Eric Gray <eric.gray@sandburst.com>
>To: Thomas Nadeau <tnadeau@cisco.com>
>CC: Irfan Lateef <irfanlateef@hotmail.com>, mpls@UU.NET
>Subject: Re: LSR-MIB - AvailableBandwidth ?
>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
>
>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
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp