The MPLS WG Archive

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

Irfan,

    I was not suggesting a probable solution, I was pointing out problems and
making the point that solutions to these problems produce scenarios in which
it does not make sense to introduce the problem in the first place.

    If an NMS needs up-to-date information on the state of specific network
elements in order to make specific resource allocation decisions, then it is
far better off going and asking those specific nodes for that information then
it would be being inundated by unneeded information from network elements
about which it doesn't currently care.  This is particularly true if the period
during which this information might be delivered automatically must be
deliberatly prolonged to prevent the NMS from being overcome by too much
(mostly unecessary) information.  In this case, the frequency at which the
NMS may receive unsolicited updates (from the network elements it cares
about at any given instant) is necessarily less than the frequency at which
it may obtain this information by simply asking for it.

    The only solution that I suggested was to choose the right tools for the job

at hand and use them correctly.

--
Eric Gray

You wrote:

> Eric,
>
> You have brought out all the right issues with trap but also
> suggested a probable solution which looks attractive to me for the
> following reasons.
>
> 1. We allow the NMS/user to set the granularity and hold-off timer
> based on what he/she thinks is necessary for his/her application
> and the desirable number of traps.
> 2. We cannot and donot need to guess the typical setup size and judge
> whether it is going to be beneficial at this point.
> 3. The user can set the thresholds high enough to not see any traps
> or even disbale this trap and use polling before path computation,
> or compare the results and go one way or the other or both ;).
>
> My concern with polling was, in a large network say 100s of links, the
> NMS would be polling ALL THE LINKS even when the values may
> not have changed taxing the control channel.
> Where as if an optional trap is provided then NMS could judiciously
> choose the values which suit its appl and save control bandwidth.
>
> Actually the analogy is good. It is the other way I am looking at it.
> The manager is making long term resources allocation but want to
> have up to minute data when he is making a decision, which is typical
> with managers.
>
> Thanks and Regards,
> Irfan Lateef
>
> >From: Eric Gray <eric.gray@sandburst.com>
> >To: Irfan Lateef <irfanlateef@hotmail.com>
> >CC: tnadeau@cisco.com, mpls@UU.NET
> >Subject: Re: LSR-MIB - AvailableBandwidth ?
> >Date: Wed, 29 Aug 2001 19:01:39 -0400
> >
> >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
> >
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp