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