[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP MIB revision 6
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org
>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
>Sent: Sunday, September 28, 2003 5:01 AM
>To: 'Martin Dubuc'; Wijnen, Bert (Bert)
>Cc: Ccamp-wg (E-mail)
>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.
Sounds fair to me.
>The question then becomes: should there be an object to throttle
>the max rate?
Yes, there should. We added one to the other MIBs.
--Tom
>
>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
>>
>