[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP MIB revision 6
Inline
Thanks,
Bert
> -----Original Message-----
> From: Martin Dubuc [mailto:m.dubuc@rogers.com]
> Sent: woensdag 24 september 2003 13:56
> To: Wijnen, Bert (Bert)
> Cc: Ccamp-wg (E-mail)
> Subject: Re: LMP MIB revision 6
>
>
> Bert,
>
> After working on the document yesterday, I have some comments on your
> original message.
>
> First, with regards to the Node ID, LMP defines Node ID as a 4 octet field.
> It usually maps to a 4-bytes IP address and is usually more of an internal
> network address. I am not sure it makes sense to support IPv6 for this
> field. I haven't heard that there was any proposal to change the Node ID to
> support IPv6 format.
>
If you are sure it is gonna be just an IPv4 address, then the proper
SYNTAX would be InetAddressIPv4 instead of InetAddress.
But it seems it (at least theoretically) it can also be some random
32 bit number (Node_Id). Maybe the proper syntax is OCTET STRING SIZE (4)
and then specify that it is the Node_Id in network byte order?
In any event, you CANNOT use InetAddres without also having a
InetAddressType for it.
And also you better add a REFERENCE clause that explains where
Node ID is defined.
So add a reference to the terminology section of the base
LMP document where Node_Id is defined.
> lmpCcIsIf is not redundant. In some implementations, control channel will be
> mapped to interfaces, in other implementations, they will not. This object
> is used as such indicator. In cases where the control channel is not mapped
> as interface, it is true that the value of lmpCcUnderlyingIfIndex will be 0.
> But in cases where control channels are mapped to interfaces,
> lmpCcUnderlyingIfIndex could be set to 0 to indicate that the control
> channels are not yet assigned/configured/discovered. So a value of 0 for
> lmpCcUnderlyingIfIndex does not necessarily mean that control channel is not
> an interface.
>
So that is/was not so clear from the DESCRIPTION clauses. Maybe you can clarify
that a bit.
> Concerning lmpCcRemoteAddressType and lmpCcRemoteCcAddr, I am not sure what
> it is from TE link MIB that you like that you would like to see here as
> well.
>
It MUST explain WHICH object of syntax InetAddressType specifies the format
of these objects. You did it correctly for example in:
lmpDataLinkIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The local Internet address for numbered links. The type
of this address is determined by the value of
lmpDataLinkAddressType object.
... more stuff ...
> Regards,
>
> Martin
>
Hope this helps,
Bert
> ----- 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
>