[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP MIB revision 6
Thanks Bert.
See in-line.
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: Wednesday, September 24, 2003 9:34 AM
Subject: 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.
>
I like your suggestion of defining Node ID as a 4 octet octetstring. Since
Node ID
is used in two different places, I have created a textual convention for
Node ID.
I have also added the reference as per your suggestion.
>
> > 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.
>
I have clarified this in the MIB.
> > 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.
>
I have added explicit reference to lmpCcRemoteAddressType in
lmpCcRemoteIpAddr description.
> ... 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
> >