The MPLS WG Archive

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

Irfan,

    In this case, the trap storm would arise from the fact that you
have not defined an appropriate granularity for what you mean by
'change' (under this circumstance, every little hiccup in a network
would inundate the NMS with too much information).  Even if you
have picked an appropriate granularity, you should define a minimum
hold off delay in announcing yet more changes (otherwise, the NMS
would still be processing the data from one trap when it is over-run
with data from subsequent traps).

    It is likely that an appropriate granularity for change - dictated
by a need to avoid having a lot of traps sent all at once - will be
larger than the typical size of a setup.  Consequently, a change
large enough to block a typical setup will be too small to report
under some circumstances.  In addition, if any sort of timer is to
be used, then why not have the NMS poll the NEs?  This is what
I meant by the trap approach being more costly than beneficial.

    I think you would have to make up your mind who is going to be
in control of your TE setup.  If, as you say, an NMS can manage it
because of a protracted time scale - and an operator decides to
do it this way - then only the NMS should manage TE setup and
tear down.  If that is the case, then where would the change you
want to be notified of come from?  On the other hand, if you need
to use a more dynamic approach, then the NMS should be limited
to policy level management.  Otherwise, it would be like having a
manager that makes specific resource allocation decisions based
on monthly trend data and an annual budget for individual projects
with an average project life cycle of 3 days.

--
Eric Gray

You wrote:

> 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