ࡱ> `_@( / 0LDTimes New Romanbbb0bb~0   @n?" dd@  @@`` @'q        c $@g4MdMdb~0b ppp@ <4!d!d؋vb <4ddddbbL?j%March 18, 2001 2JDC's Observations on EOSO =L<Evolution of SNMP (eos)Z50th IETF: Minneapolis, MN Jeff Case case@snmp.com +1 865 573 1434 Knoxville, TN U.S.A. VY!3*-OutlinePresentation 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 xZZ8ZiZ Z8i ,Cc# IntroductiontThis 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 togetherH'9>'9> /Context: Internet Standard Management Framework$0 &    `Protocol 3 Parts ProtoOps TM Security and administration 3 revs: Security 2 revs: ProtoOps & TMD ((((,: Presentation GoalsContribute to the requirements discussion by providing some comments on draft-ietf-eos-requirements-00.txt Contribution of suggested approaches to meeting requirements>N> Capability DeterminationWe 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 followed6P?LP?L $Capability Determination (Continued)AAt 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)6x  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 SuppressionHQQ,3+OID Compression and Suppression (Continued)QWe 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( ZFZ F Row OperationsRecall 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 :kp     Row OperationsBut 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 0qr 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)) PFPPjPP[PF64(2h  < Row Operations (Continued)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 operandsB/TZ/t9  3(Row Operations (Continued)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)6(o(oRow Operations (Continued)rOptimizations 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 ...$,{ /Row Operations (Continued)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 ... $  ]a 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 instances6WW,]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$xx>VRcSubtree Deletion (Continued)BipNetToMediaClear OBJECT-TYPE SYNTAX INTEGER { dynamic(1), all (2) } MAX-ACCESS read-only DESCRIPTION  The type of objects to be cleared. When this object is written with a value of dynamic(1), all entries in the ipNetToMediaTable whose value of ipNetToMediaType VZFZ!@Subtree Deletion (Continued) is dynamic(1) are invalidated. When this object is written with a value of all(2), all entries in the ipNetToMediaTable 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.8Z7Z7,j4  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 transferJ g+ g+,G  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$88> y A Plea For Simplicity and SpeedWe 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 SpeedExample: 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< Z Z/Z /v" Your FeedbackWe welcome your input on both These ideas for the standard The mailing list These ideas for future product releases feedback@snmp.com Please help us to keep these together, if possible ~(3(3}9  ` ` ̙33` 333MMM` ff3333f` f` f` 3>?" dd@,|?" dd@   " @ ` n?" dd@   @@``PR    @ ` ` p>> K(    6 v P v T Click to edit Master title style! !  04!v  v RClick to edit Master text styles Second level Third level Fourth level Fifth level!     S  0!v `` v =*  0!v `  v ?*  <"v` f50th IETF Page * * "  0#v `  v ?*H  0޽h ? ̙33 Default Design 0 0 .(     0 P   v Y*   0    v [* d  c $ ?    0t  @  RClick to edit Master text styles Second level Third level Fourth level Fifth level!     S  6Դ `P   Y*   64 `   [* H  0޽h ? ̙33 @$(  r  S T  r  S p`    H  0޽h ? ̙33  P$(  r  S P   r  S   H  0޽h ? ̙33  `( { l  C ԺP   l  C 4  H  0޽h ? ̙33  JBp @( w @ @ 0 @` E   @ 0T p0  E  l @ C 4P   l  @ C bs   l  @ C cs     @ 0tcs  NMIB Continuous revision, mostly expansion MIB I MIB 2 Many mini-MIB documents D&$*$>  @ 0cs P 4SMI 3 Parts SMI TC CONF 3 Versions SMIv1 SMIv2 SMIngl    /^  @ 6Ԕ0 ^ @ 6Ԕ^ @ 6Ԕ^ @ 6ԔH @ 0޽h ? ̙33  ( e l  C dsP   l  C ds  H  0޽h ? ̙33  ((  (l ( C fsP   l ( C tfs  H ( 0޽h ? ̙33  D$(  Dr D S gsP   r D S gs  H D 0޽h ? ̙33  4$( w 4r 4 S tisP  v r 4 S is v H 4 0޽h ? ̙33  X( \@d@ Xl X C lsP  s l X C tls s H X 0޽h ? ̙33"   ,b( \@d@ ,l , C sP  s l , C s s B8  p  ,  pfB , 6D pfB , 6D  ppfB , 6D pfB , 6D@ @pfB , 6D  pfB  , 6D0 pfB  , 6D@ pH , 0޽h ? ̙33"   p(  pr p S sP  s r p S s s X"  p 0P  @X"  p 0 X" p 0  X" p 0p  ` j p@ BGH0*ImW H j p@ BGH0*ImWH   j p@ BGH0*ImW   H p 0޽h ??` ppppppp pp ̙33  \$(  \r \ S dsP  s r \ S ďs s H \ 0޽h ? ̙33  t$(  tr t S sP  s r t S Ds s H t 0޽h ? ̙33  $(  r  S $sP  s r  S s s H  0޽h ? ̙33   d$( @ dr d S sP  s r d S Ds s H d 0޽h ? ̙33  0h$(  hr h S dsP  s r h S ĕs s H h 0޽h ? ̙33  @0$( 5% 0r 0 S sP  s r 0 S s`  H 0 0޽h ? ̙33  PH(  Hl H C tXP   l H C X  H H 0޽h ? ̙33  `L$(  Lr L S ZP   r L S [`  H L 0޽h ? ̙33  pT$(  Tr T S t[P   r T S [  H T 0޽h ? ̙33  8$( w 8r 8 S \P   r 8 S \  H 8 0޽h ? ̙33  <$(  <r < S ^P   r < S 4_  H < 0޽h ? ̙33  $(  $l $ C `P  s l $ C a s H $ 0޽h ? ̙33  $(  r  S bP  s r  S b s H  0޽h ? ̙33   ( ) l  C 4P  v l  C  v H  0޽h ? ̙33rPJ@lPXRDT _>g.{rc҂$Va}~@^ehlq VwByP~sju]vV#Oh+'0 `h   Network Information Modeliwweiss SNMP Researchat11PMicrosoft PowerPointode@њN@>@'s-wG oM  -& &&#TNPP0D v & TNPP &&TNPP    - "-- !-- "-&G& - Times New Roman - .2 RMarch 18, 2001   .&Gy&  .-2 wJDC's Observations on EOS      .--y--  . 2 50 .Times New Roman- . 2 th.Times New Roman - .2  IETF Page    . . 2 Y1 .--!yH-- Times New Roman- .$2 Evolution of SNMP ($ +4!. . 2 eos. . 2 ).--Q1h-- Times New Roman - . 2 50.Times New Roman- . 2 th.Times New Roman - .(2 , IETF: Minneapolis, MN  &   &. .2  Jeff Case .Times New Roman- .2 tcase@ . . 2 snmp . . 2 .com. .2 2s+1 865 573 1434. .'2 `OKnoxville, TN U.S.A. .--"Systemn-&TNPP &՜.+,D՜.+,     #On-screen Show Ellacoya Sh 1 Times New RomanDefault DesignEvolution of SNMP (eos)Outline Introduction0Context: Internet Standard Management FrameworkPresentation GoalsCapability Determination%Capability Determination (Continued)OID Compression and Suppresion,OID Compression and Suppression (Continued)Row OperationsRow OperationsRow Operations (Continued)Row Operations (Continued)Row Operations (Continued)Row Operations (Continued)Row Operations (Continued)Subtree DeletionSubtree Deletion (Continued)Subtree Deletion (Continued)Subtree Deletion (Continued)Bulk TransferBulk Transfer (Continued) A Plea For Simplicity and Speed A Plea For Simplicity and SpeedYour Feedback  Fonts UsedDesign Template Slide Titlesem  % 1 9 AIQYaiqy _PID_GUID TemplateType GraphicType Compression ScreenSize ScreenUsage MailAddress HomePage Other DownloadOriginal DownloadIEButton UseBrowserColor BackColor TextColor LinkColor VisitedColorTransparentButton ButtonType ShowNotes NavBtnPos OutputDirAN{461B9473-1B38-11D5-9C78-0008C7AF96BC}dinfo@snmp.comtohttp://www.int.snmp.comttp  f3 C:\ietf%_ bSNMP Research  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFHIJKLMNPQRSTUVXYZ[\]^aRoot EntrydO)Current UserWSummaryInformation(GPowerPoint Document( DocumentSummaryInformation8O