[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [802.1] MSTP MIB - mstpMapTable
Hi,
> Taking into account that 3417 allows agents to support only 484
bytes,
> should we not at least warn the MIB designers and reviewers
> upon this
> fact?
AND develop a recommendation for MIB module designers, so MIB Doctors
use a consistent guideline when recommending how to handle such
objects in standard MIB modules?
Here are some factors that should be considered in the guidelines:
1) If the MIB module is intended to be standards-track (IETF or
other), the size should be **compatible** with the
least-capable-standard-compliant SNMP implementation (currently 484
byte UDP) to ensure interoperability, when considered with these other
factors,
2) when the length is fixed by its function, then the size should be
consistent with the least-capable-standard-compliant SNMP
implementation,
3) if the length is not fixed by function, and the length can be
constrained by operator choice of (read-write) values, then a longer
octet string is acceptable,
4) if the defined length is not fixed, but the length might not be
able to be constrained by operator choice of values, because a
compliant implementation MAY make the object read-only and the
implementation would supply the value, then the size should be
consistent with the least-capable-standard-compliant SNMP
implementation, or the description should make it a requirement that
implementation-supplied read-only values be consistent with the
least-capable-standard-compliant SNMP implementation,
5) if the semantic consistency changes as the result of multiple
reads, such as reading a counter of incoming SNMP messages (although,
just like HC Counter32 pairs, the implementation could anticipate the
multiple reads so can perform a 64-bit fetch and report the values as
two 32-bit objects in separate messages),
6) if the values are likely to change so fast that multiple reads will
be very difficult to coordinate (with the same caveat as #5),
7) if the need is valid (i.e., if other design choices wouldn't avoid
the issue),
8) is the transport protocol/message-size-supported to be used for
SNMP management a requirement of the standards-track functionality
being managed, e.g. DOCSIS might require a 1472-byte UDP message
support for DOCSIS compliance. (I think it might be a bad thing for
interoperability to see this approach become common),
9) ???
David Harrington
dbharrington@comcast.net
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
> Sent: Tuesday, September 06, 2005 1:56 PM
> To: David T. Perkins; Keith McCloghrie
> Cc: bwijnen@lucent.com; mreview@ops.ietf.org
> Subject: RE: [802.1] MSTP MIB - mstpMapTable
>
> David,
>
> You are answering by yourself (correctly) to questions 1) and 2).
>
> In the case under discussion the answer for 3) and 4) are to my
best
> knowledge:
>
> 3) The way the designers suggest to do this is to split the
> object into
> 4 objects, representing the bit mask values for the 1k,
> second 1k, etc.
> VLANs on a bridge. These are rather static configuration parameters
> (like forwarding filters), there is little probability for changes
> between two consecutive PDU operations, and no dependency between
what
> each individual bit carries.
> 4) UDP is the rule, in the enterprise perimeter is Ethernet,
> but because
> of the metro or WAN SP deployment, one cannot exclude remote
> management
> over WAN links that have different MTU values.
>
> However, my intention in bringing this issue to mreview was
different.
> Taking into account that 3417 allows agents to support only 484
bytes,
> should we not at least warn the MIB designers and reviewers
> upon this
> fact?
>
> Dan
>
>
>
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > Sent: Tuesday, September 06, 2005 8:38 PM
> > To: Keith McCloghrie
> > Cc: Romascanu, Dan (Dan); bwijnen@lucent.com; mreview@ops.ietf.org
> > Subject: Re: [802.1] MSTP MIB - mstpMapTable
> >
> > HI,
> >
> > The "easy" answer is to quote standards. The harder to
> > develop reponse requires an investigation as to the area of
> > deployment.
> >
> > Questions:
> > 1) Does the need appear valid? Yes.
> > 2) Could the value be split into several chunks? Yes.
> > 3) (I can't think of the proper terminology for this next
> > question, so please bear with me?)
> > Does it loose semantic consistancy if split (given
> > that if split, it might have to be retrieved in
> > multiple SNMP operations, and that the value
> > may change between the operations)? No (This is really
> > the most important question!) Since the value is
> > really an array of different items, changes in
> > one item do not affect the meaning of other items.
> > If the value was, say, an "error string", and chunks
> > were being retrieved with multiple SNMP operations
> > and the value could change, then the result when
> > "pasted back together" would be semantically meaningless
> > if there was any change to the value during the retrieval.
> > 4) What is the transport being used for the deployment?
> > Is it UDP or TCP. And if UDP what is the expected
> > minimum IP packet size. There may be other requirements
> > that drive this, such as a L2 protocol that must
> > also be supported.
> > I believe those are the most important questions. I probably
> > left out a couple.
> >
> > On Tue, 6 Sep 2005, Keith McCloghrie wrote:
> > > I agree with "tend to be", but the issue is whether to
> > exclude devices
> > > which only support 484 octets. It seems to me that RFC
> 3417, or an
> > > update to it, is the right document in which to require agents
to
> > > support 1472 byte SNMP packets. Since RFC 3417 was able only to
> > > "recommend" rather than require greater than 484, my
> > inclination would
> > > be to say that is it unacceptable for an individual MIB to
> > be written
> > > which is not implementable by an SNMPv3-compliant agent.
> > >
> > > Keith.
> > >
> > > > Bert,
> > > >
> > > > IEEE 802.1 bridges tend to be deployed nowadays more
> and more in
> > > > environments similar with the ones where big routers are being
> > > > deployed
> > > > - including metropolitan and even wide area service providers.
> > > >
> > > > Regards,
> > > >
> > > > Dan
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > > > > Sent: Tuesday, September 06, 2005 7:13 PM
> > > > > To: Romascanu, Dan (Dan); Mreview (E-mail)
> > > > > Cc: Keith McCloghrie
> > > > > Subject: RE: [802.1] MSTP MIB - mstpMapTable
> > > > >
> > > > > So I would wonder if the the typical environment
> where this MIB
> > > > > module gets deployed, if in that environment a length
> of up to
> > > > > 1472 would cause a problem. If not, then why split it into
4
> > > > > smaller OCTET STRINGS?
> > > > >
> > > > > Bert
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-mreview@ops.ietf.org
> > > > > [mailto:owner-mreview@ops.ietf.org]On
> > > > > > Behalf Of Romascanu, Dan (Dan)
> > > > > > Sent: Tuesday, September 06, 2005 15:39
> > > > > > To: Mreview (E-mail)
> > > > > > Cc: Keith McCloghrie
> > > > > > Subject: FW: [802.1] MSTP MIB - mstpMapTable
> > > > > >
> > > > > >
> > > > > > This issue popped-up on the IEEE 802.1 WG list, around a
> > > > > OCTET STRING
> > > > > > object that would exceed 500 octets, and the authors
> > > > > decided to break
> > > > > > it into 'smaller pieces'.
> > > > > > While watching this discussion I checked with the
> MIB review
> > > > > > guidelines, which do not say anything about a
> > recommended size
> > > > > > limiting of an OCTET STRING, excepting the fact that it is
> > > > > recommended
> > > > > > to be limited at some size, especially when the OCTET
> > > > > STRING object is
> > > > > > an index. See
> > > > > >
> http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-
> > > > > > guidelines
> > > > > > -04.txt Section 4.6.1.4. Is this OK? If so, how does
> > this live
> > > > > > together with Keith's comment?
> > > > > >
> > > > > > Dan
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: IEEE 802.1 [mailto:hdk-0119.ckxbsg@ATT.NET] On
Behalf
> > > > > Of Keith
> > > > > > McCloghrie
> > > > > > Sent: Tuesday, September 06, 2005 3:45 PM
> > > > > > To: STDS-802-1-L@listserv.ieee.org
> > > > > > Subject: Re: [802.1] MSTP MIB - mstpMapTable
> > > > > >
> > > > > > > 1. Divide one long OCTET STRING into 4 shorter
> > > > > > > OCTET STRING. I don't see the reason for it.
> > > > > >
> > > > > > The reason is the difference between "must" and
> "recommended".
> > > > > > Specifically, all the transport mappings in RFC
> 3417 say the
> > > > > > equivalent
> > > > > > of:
> > > > > >
> > > > > > When an SNMP entity uses this transport mapping, it
must
> > > > > be capable
> > > > > > of accepting messages up to and including 484 octets in
> > > > > size. It
> > > > > > is
> > > > > > recommended that implementations be capable of
accepting
> > > > > messages
> > > > > > of
> > > > > > up to 1472 octets in size. Implementation of
> > larger values is
> > > > > > encouraged whenever possible.
> > > > > >
> > > > > > Keith.
> > > > > >
> > > > > > IEEE 802.1 list:
> > > > > > When forwarding, PLEASE DELETE this footer & list-related
> > > > > > header items.
> > > > > > http://www.ieee802.org/1/email-pages/pwdqq705.html
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > Regards,
> > /david t. perkins
> >
> >
>
>