[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP MIB revision 6
I have added a max throttling rate object.
Martin
----- Original Message -----
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "'Martin Dubuc'" <m.dubuc@rogers.com>; "Wijnen, Bert (Bert)"
<bwijnen@lucent.com>
Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Sent: Sunday, September 28, 2003 5:01 AM
Subject: RE: LMP MIB revision 6
> So below you give me a lot of explanation what kind of
> notifications can get generated and how many would be generated
> under which conditions. I think that is exactly the type of
> information that we would like to see somewhere (best uis probably
> in DESCRITPION clauses so that it stays with the MIB module when
> it gets extracted). You might also add some warnings that people
> should be carefull NOT to configure too short verification times
> and at least take the potential notification rate into consideration
> when doing so.
>
> The question then becomes: should there be an object to throttle
> the max rate?
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Martin Dubuc [mailto:m.dubuc@rogers.com]
> > Sent: zondag 28 september 2003 3:31
> > To: Wijnen, Bert (Bert)
> > Cc: Ccamp-wg (E-mail)
> > Subject: Re: LMP MIB revision 6
> >
> >
> > Bert,
> >
> > I am almost done updating the LMP MIB to address your
> > comments. However, I
> > am stuck on comment 16 (notifications). You would like to
> > know what rate per
> > second we should fear in the worst conditions. It is very difficult to
> > answer this one. I have thought a lot about this, and I don't
> > think I can
> > come up with a number. The notification rate distribution
> > depends too much
> > on the type of network, the size of network, the network
> > configuration, the
> > type of the links, the reliability of the network, etc.
> >
> > I can add some text in some of the notifications to explain
> > some of the
> > expected limits (for instance, there are some notifications
> > that can only
> > happen once per link verification interval), but to give one
> > number for the
> > worst case is next to impossible.
> >
> > In general, I think the LMP MIB is not resource hungry when
> > it comes to
> > notifications because all of the transitions are state driven
> > (meaning the
> > notification are only sent when the system changes state),
> > cover some very
> > specific error conditions (like configuration errors) and are mainly
> > associated with entities that are limited in numbers (TE
> > links and control
> > channels). The only notifications that might have caused a
> > problem are the
> > ones associated with data links (because of the potential
> > high number of
> > data links) but since the data links can happen only once per
> > data link per
> > link verification interval, the notification rate should be
> > sustainable if
> > one chooses an appropriate link verification interval and
> > engineers the
> > network properly. For instance, a network of 100 nodes with 5
> > links of 128
> > wavelengths each and a link verification of 1 minute with say
> > 10% of the
> > links failed at any given time would have 1 notification per
> > second sent
> > from each node (100 notifications per second for the whole
> > network). The
> > rest of the notifications are negligeable compared to this number.
> >
> > Martin
> >
> > ----- Original Message -----
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > To: "'Martin Dubuc'" <m.dubuc@rogers.com>
> > Cc: "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
> > Sent: Monday, September 01, 2003 4:42 PM
> > Subject: RE: LMP MIB revision 6
> >
> >
> > > Well well...
> > >
> > > SMICng says:
> > > W: f(lmp.mi2), (2251,20) Variable "ifIndex" in notification
> > > "lmpDataLinkPropertyMismatch" is an index for a table
> > > W: f(lmp.mi2), (2306,20) Variable "ifIndex" in notification
> > > "lmpTeLinkDegraded" is an index for a table
> > > W: f(lmp.mi2), (2316,20) Variable "ifIndex" in notification
> > > "lmpTeLinkNotDegraded" is an index for a table
> > > W: f(lmp.mi2), (2329,20) Variable "ifIndex" in notification
> > > "lmpDataLinkVerificationFailure" is an index for a table
> > > W: f(lmp.mi2), (2641,19) MIN-ACCESS value identical to access
> > > specified for "lmpCcOperStatus"
> > > W: f(lmp.mi2), (2693,19) MIN-ACCESS value identical to access
> > > specified for "lmpTeLinkOperStatus"
> > > W: f(lmp.mi2), (2761,19) MIN-ACCESS value identical to access
> > > specified for "lmpDataLinkActiveOperStatus"
> > > W: f(lmp.mi2), (2768,19) MIN-ACCESS value identical to access
> > > specified for "lmpDataLinkPassiveOperStatus"
> > >
> > > smilint says:
> > > .\LMP-MIB:2425: [2] {subtype-enumeration-illegal} named number
> > > `degraded(4)' illegal in sub-type
> > > .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > > `up(1)' illegal in sub-type
> > > .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > > `down(2)' illegal in sub-type
> > > .\LMP-MIB:2439: [2] {subtype-enumeration-illegal} named number
> > > `degraded(4)' illegal in sub-type
> > > .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > > `up(1)' illegal in sub-type
> > > .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > > `down(2)' illegal in sub-type
> > > .\LMP-MIB:2444: [2] {subtype-enumeration-illegal} named number
> > > `degraded(4)' illegal in sub-type
> > > .\LMP-MIB:2694: [2] {subtype-enumeration-illegal} named number
> > > `degraded(4)' illegal in sub-type
> > > .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > > `up(1)' illegal in sub-type
> > > .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > > `down(2)' illegal in sub-type
> > > .\LMP-MIB:2763: [2] {subtype-enumeration-illegal} named number
> > > `degraded(4)' illegal in sub-type
> > > .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > > `up(1)' illegal in sub-type
> > > .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > > `down(2)' illegal in sub-type
> > > .\LMP-MIB:2769: [2] {subtype-enumeration-illegal} named number
> > > `degraded(4)' illegal in sub-type
> > > .\LMP-MIB:138: [5] {inetaddress-inetaddresstype} warning:
> > > `InetAddress' object should have an accompanied preceding
> > > `InetAdressType' object
> > > .\LMP-MIB:386: [5] {inetaddress-inetaddresstype} warning:
> > > `InetAddress' object should have an accompanied preceding
> > > `InetAdressType' object
> > > .\LMP-MIB:1213: [5] {inetaddress-inetaddresstype} warning:
> > > `InetAddress' objectshould have an accompanied preceding
> > > `InetAdressType' object
> > >
> > > Some details:
> > > 1. lmpNbrNodeId OBJECT-TYPE
> > > SYNTAX InetAddress (SIZE(4))
> > > MAX-ACCESS not-accessible
> > > STATUS current
> > > DESCRIPTION
> > > "This is a unique index for an entry in the LmpNbrTable.
> > > This value represents the remote Node ID. The Node ID
> > > address type must be IPv4."
> > > ::= { lmpNbrEntry 1 }
> > > You do know that MIB modules need to be IPv6 friendly, no?
> > > Is LMP itself such that it only works with IPv4? I doubt that
> > > IESG will approve new protocols that do not support IPv6.
> > > 2. For these 2 objects:
> > > lmpNbrRetransmitInterval LmpRetransmitInterval,
> > > lmpNbrRetryLimit Unsigned32,
> > > You may want to add some text as to howyou intend to deal with
> > > congestion (RFC 2914). This over UDP if I remember well?
> > > I think it would be good to point explicitly to the text in lmp
> > > document (sect 10).
> > > 3. lmpNbrRowStatus OBJECT-TYPE
> > > SYNTAX RowStatus
> > > MAX-ACCESS read-create
> > > STATUS current
> > > DESCRIPTION
> > > "This variable is used to create, modify, and/or
> > > delete a row in this table. All read-create objects
> > > can only be changed when lmpNbrRowStatus is active."
> > > That sounds strange. The notInService status was specifically
> > > created to allow changes for cases where changes were not allowed
> > > while row was active. Here you say it MUST be active in order
> > > to make changes? Or did you mean "can not be changed"?
> > > This occurs in more (maybe all) RowStatus objects in this doc.
> > > 4. You have some objedts that are not part of a table, yet are
> > > read-write. For example
> > > lmpAdminStatus
> > > lmpCcHelloIntervalDefault
> > > lmpCcHelloIntervalDefaultMin
> > > ... and more ...
> > > What is the persistency behaviour of these objects?
> > > In other words: is the value preserved over a reboot?
> > > 5. Is lmpCcIsIf not redundant? The way I read it, then if the
> > > lmpCcUnderlyingIfIndex has a value of zero, then it is NOT
> > > an interface, no?
> > > 6. lmpRemoteCcAddressType and lmpRemoteCcAddress
> > > In the telink MIB you have done things correctly and as
> > presscribe
> > > by RFC3291. Here you have not. Why ?
> > > Even in this doc you have done it correctly in some places.
> > > 7. Mmmmmm??? 52 counters to "measure the performance" of
> > the LMP channels?
> > > Sounds overwhelming to me.
> > > 8. Formally, every Counterxx object needs to include in its
> > descritpion
> > > clause which object indicates a potential discontinuity.
> > I understand
> > > that they all are covered by lmpCcCounterDiscontinuityTime in the
> > > same row. Maybe write something about that in the
> > ...Entry description
> > > clause as well if you do not want to add text to every Counter
> > > 9. lmpTeLinkTable
> > > DESCRIPTION
> > > "This table contains a collection of TE link."
> > > Means what??
> > > 10. lmpLinkVerificationInterval
> > > What does a value of zero mean?
> > > Any comments regarding possible congestiuon if the
> > value is set to
> > > a very small number of msecs?
> > > 11. lmpLinkVerificationTable
> > > Or is it better namep lmpTeLinkLinkVerificationTable
> > > and then rename objects as well? If is correct name,
> > > Then maybe rename
> > > lmpTeLinkBitRate to lmpLinkVerificationTeLinkBitRate
> > > lmpTeLinkWavelength to
> > lmpLinkVerificationTeLinkWavelength
> > > 12. lmpVerifyTransportMechanism
> > > There are a few TBDs in there. Better decide before you
> > submit to AD
> > > 13. lmpTeLinkBitRate
> > > DESCRIPTION
> > > "This is the bit rate at which the Test messages will be
> > > transmitted and is expressed in bytes per second."
> > > A BIT rate that gest expressed in BYTES per second?
> > > Possible of course but strange, no? Why not call it ByteRate?
> > > 14. Another 40 or so counters for lmpTeLinkPerfTable ???
> > > 15. lmpDataLinkPropertyMismatch NOTIFICATION-TYPE
> > > OBJECTS { ifIndex,
> > > lmpDataLinkRemoteIfId }
> > > The second object already (implicitly) also contains the value
> > > of the first object (it is the index part of the OID).
> > > 16. I see quite a few NOTIFICATION-TYPES. You can enable or disable
> > > them. But when they are enabled, what kind of rates per second
> > > should we fear for in a worst case conidition?
> > > Pls think about both an agent (i.e. an LMP node) generating
> > > them, but also think about a SNMP management station receiving
> > > them from potentially 100s or 1000s of LMP nodes.
> > > 17. On page 7 I see:
> > > lmpDataLinkAddressType = unnumbered(1),
> > > Mm... that is not a valid value for an InetAddressType
> > >
> > > 18. Security COnsiderations
> > > You are not following the guidelines to describe first the
> > > SET (read-write, read-create) issues/concerns/vulnerabilities
> > > and then the read-only sensistivities. So I would not be
> > > surprised to see push back from the Security front.
> > >
> > > I have done a pretty serious review... but not exhaustive.
> > >
> > > Thanks,
> > >
> > > Bert
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert)
> > > Sent: maandag 1 september 2003 20:14
> > > To: 'Martin Dubuc'; Wijnen, Bert (Bert)
> > > Subject: RE: LMP MIB
> > >
> > >
> > > I have it on my todo-list. I am currently checking te-link mib.
> > >
> > >
> > > Thanks,
> > > Bert
> > > -----Original Message-----
> > > From: Martin Dubuc [mailto:m.dubuc@rogers.com]
> > > Sent: maandag 1 september 2003 19:55
> > > To: Bert Wijnen
> > > Subject: LMP MIB
> > >
> > >
> > > Bert,
> > >
> > > I know you have been quite busy with all the MPLS drafts. I
> > just wanted to
> > know if you had time review the LMP MIB draft and if not,
> > when you think
> > you'll get around reviewing it.
> > >
> > > Regards,
> > >
> > > Martin
> >