50 th IETF Page 1March 18, 2001JDC's Observations on EOS Evolution of SNMP (eos) 50 th IETF:...

March 18, 2001 JDC's Observations on EOS 50th IETF

Evolution of SNMP (eos)

50th IETF: Minneapolis, MN

Jeff [email protected]

+1 865 573 1434

Knoxville, TN U.S.A.


Outline

• Presentation Introduction– Context– Goals

• Charter Items (in order of req doc rather than Charter)– Capability Determination– OID Compression (and suppression)– Row Operations– Subtree Deletion– Bulk Transfer

• Conclusion


Introduction

• This presentation is a combination of:– Contribution to the IETF EOS work– Ideas we have been working on independently for

some time and considering for inclusion in a future major software release

• A snapshot of work-in-progress

• … Your mileage may vary …

• It is desirable to be able to pull these two efforts together


Context:Internet Standard Management Framework

Protocol• 3 Parts

– ProtoOps

– TM

– Security and administration

• 3 revs: Security• 2 revs:

ProtoOps & TM

MIB• Continuous

revision, mostly expansion– MIB I

– MIB 2

– Many mini-MIB documents

SMI• 3 Parts

– SMI

– TC

– CONF

• 3 Versions

– SMIv1

– SMIv2

– SMIng


Presentation Goals

• Contribute to the requirements discussion by providing some comments ondraft-ietf-eos-requirements-00.txt

• Contribution of suggested approaches to meeting requirements


Capability Determination

• We see this as a MIB object issue, not a protocol operations issue

• Many choices– Wad of scalars– Object(s) of type BITS or OCTET STRING– Table(s)

• At first blush, it just does not matter which of these choices are followed


Capability Determination (Continued)

• At second look we see:– Additional requirement: low cost for low-end

agent implementations (e.g., not a table of OBJECT IDENTIFIERs)

– Granularity needs to reflect granularity of implementations

• Monolithic versus Master agent / subagent

• Toolkit vendor versus product vendor

• (Hard to have shared ownership of pieces of BITS)


OID Compression and Suppresion

• Multiple approaches– Message/PDU compression, e.g., Lempel-Ziv– Multiple approaches to OID Compression

• Name and value versus name only• Relative• Static anchor / Multiple static anchor• Dynamic anchor / Multiple dynamic anchor• Combinations + anchor selection algorithms

– OID Suppression


OID Compression and Suppression (Continued)

• We believe:– More ongoing research is needed to sort out the

various approaches to OID compression– OID Suppression is tightly related to row

operations– The jury is still out as to whether OID

compression is of value if you have OID suppression (more research is needed)

– But before we can discuss this further, we must cover row operations


Row Operations

• Recall– fooTable SEQUENCE OF FooEntry– fooEntry FooEntry { fooTable 1 }– FooEntry SEQENCE { col1, col2, …, colm }

foo.1.1.a foo.1.2.a … foo.1.m.a

foo.1.1.b foo.1.2.b … foo.1.m.b

… … … ...

foo.1.1.n foo.1.2.n … foo.1.m.n


Row Operations

• But we want …foo.1.1.a foo.1.2.a … foo.1.m.a

foo.1.1.b foo.1.2.b … foo.1.m.b

… … … …

foo.1.1.n foo.1.2.n … foo.1.m.n


Row Operations(Continued)

• What we need is:– A row as a single thing– The transpose of the table as a column vector

• Example: Row 5– (foo.1.a.5 = val1, foo.1.b.5 = val2,…foo.1.m.5 = valm)– tablename, column indicator, row number

(instance)• Need

– factoring out tablename and row number:– (foo, 5 (col1 =val1, col2 = val2, … colm = valm))



• Conveying table name and row number (instance)– Note that fooEntry is always { fooTable 1 }– { fooTable 2 } is always unused to date– This can be used for conveying table name and

row number (instance)– The name, value pair becomes

(fooTable.2.5 = (val1, val2, …, valm))– Implementing the idea of the value portion of a varbind as

a sequence, i.e., row-based operands



• Conveying Column Indicator– Can be implicit or explicit– Must handle

• Default case of full tables (easy)

• Missing rows (easy)

• Missing columns

• Missing cells

• Non-contiguous (AUGMENTS)



• Optimizations and extensions– Holes in table: Suggest map to an existing or a

new exception(s) but do not shift “up”– Make { fooTable 2} invisible when necessary:

Suggest through pduType field a la Counter64– Selection of subsets of columns, especially non-

accessible: Suggest both implicit and explicit– … etc ...



• Benefits– Atomic row operations– Ideal for OID suppression– Compact form means shorter rows fit PDUs– Natural ordering makes life easier for agent and

manager, including cache strategies– … etc ...


Subtree Deletion

• The Charter is odd:– A standards-track document defining a mechanism

used to delete an entire subtree of managed object instances. This could, for example, be used to remove all information related to a particular username in the SNMP administrative framework;

• Mechanism does not match Example: there is no such subtree of managed object instances


Subtree Deletion(Continued)

• Could have a MIB object that deleted all references to username “Joe” but it is not a subtree

• Perhaps a better example:– Want to clear entries in the ARP cache as found in

the ipNetToMediaTable of MIB-2– This example also illustrates an additional

requirement often encountered: the need for subtree deletion with constraints



ipNetToMediaClear OBJECT-TYPESYNTAX INTEGER {

dynamic(1),all (2)

}

MAX-ACCESS read-only

DESCRIPTION

“The type of objects to be cleared. When this objectis written with a value of dynamic(1), all entries in theipNetToMediaTable whose value of ipNetToMediaType



is dynamic(1) are invalidated. When this object iswritten with a value of all(2), all entries in theipNetToMediaTable are invalidated.“

• We believe that the capability of subtree deletion with constraints can best be handled through the judicious selection of appropriate MIB objects.

• We are unaware of any requirements for changes to protocol operations to support this capability, which, by definition, are MIB-specific and application specific.


Bulk Transfer

• We believe:– Read: OID suppression + row operations +

existing Awesome getBulk with full PDUs– Write: OID suppression + row operations +

existing Breathtaking set operator• Many fewer writes than reads

• Manager knows the instances

• Policy approach reduces the data even further

form a powerful approach to bulk transfer


Bulk Transfer(Continued)

• Additional Requirement: performant in lossy and error-prone networks

• It is important to remember the lessons of M-Linked replies– Importance of statelessness versus goto jail

phenomenon


A Plea For Simplicity and Speed

• We are mightily frustrated with the pace of IETF standardization in the SNMP arena

• The pace and pulse of the IETF are increasingly out of sync with the pace and pulse of the market


A Plea For Simplicity and Speed

• Example:– The replacements for RFC 1905/6/7 have been

“almost finished” since Oslo (July 1999)– Still not published Six IETFs later and essentially

only a bunch of non-changes– It is nearly impossible to do product release

planning for standards-based products in this climate

• Impassioned plea: keep this simple and timely


Your Feedback

• We welcome your input on both– These ideas for the standard

• The mailing list

– These ideas for future product releases• [email protected]

• Please help us to keep these together, if possible

50 th IETF Page 1March 18, 2001JDC's Observations on EOS Evolution of SNMP (eos) 50 th IETF:...

Documents

Transcript of 50 th IETF Page 1March 18, 2001JDC's Observations on EOS Evolution of SNMP (eos) 50 th IETF:...