[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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