home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ptopomib / ptopomib-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  15KB  |  399 lines
  1. OPS Area
  2. PTOPOMIB WG Meeting Minutes
  3. 39th IETF 
  4. Munich, Germany
  5. August 13 & 14, 1997
  6. Minutes by Andy Bierman
  7.  
  8. Summary
  9. -------
  10.  
  11. The PTOPOMIB WG met to advance progress on all I-Ds under development:
  12.  
  13.   - PTOPO MIB
  14.   - PTOPO Discovery Protocol and MIB (PDP)
  15.   - Entity MIB Extensions for Persistent Identifiers
  16.  
  17. Review Material
  18. ---------------
  19.  
  20.  (1) Physical Topology MIB
  21.      <draft-ietf-ptopomib-mib-00.txt>
  22.  
  23.  (2) Physical Topology Discovery Protocol and MIB
  24.      <draft-ietf-ptopomib-pdp-00.txt>
  25.  
  26.  (3) Entity MIB Extensions for Persistent Component Identification
  27.      <draft-bierman-entmib-compid-00.txt>
  28.  
  29. Agenda
  30. ------
  31.  
  32. Wednesday:
  33.     Agenda Bashing
  34.     Issues - PTOPO MIB I-D
  35.     Issues - PDP I-D
  36. Thursday:
  37.     Presentation: Physical Topology with standard MIBs
  38.       (Nick Dawes - Loran)
  39.     Issues - Entity MIB I-D
  40.     Wrap-up
  41.  
  42. Minutes
  43. -------
  44.  
  45. This section contains a somewhat temporal account of WG issues and
  46. discussions during the two meetings.
  47.  
  48. 1) PTOPO MIB
  49.  
  50. 1.1) Replacement of ptopoConnEntries
  51.  
  52. The current draft specifies that only one type of component 
  53. identifier should be present for each connection endpoint.
  54. Entries with higher values of the ptopoChassisIdType or 
  55. PtopoPortIdType INDEX component are supposed to be replaced 
  56. by identifier types with lower values (if and when such 
  57. information is learned by the PTOPO agent).
  58.  
  59. The WG decided that it is desirable to allow an agent to
  60. maintain multiple entries for the same connection, although
  61. this is not mandatory.  The MIB indexing will be modified
  62. (see sec. 1.7) to allow an arbitrary number of ptopoConnTable 
  63. entries for each local port.
  64.  
  65. 1.2) NULL Identifier Types
  66.  
  67. The WG discussed a proposal to allow NULL identifiers for
  68. both chassis and port components. After much discussion
  69. the WG decided there were enough identifier types to allow a 
  70. PTOPO agent to identify each component with a non-NULL string.  
  71. In the general sense, a NULL identifier in the PTOPO MIB will 
  72. be reserved to indicate the "don't know" value.
  73.  
  74. 1.3) Repeater Backplanes
  75.  
  76. Since repeaters must transmit PDP advertisements out all ports
  77. attached to the same shared backplane, it is not possible to
  78. identify a single port in the PDP Port ID TLV and ptopoPortId
  79. MIB object.
  80.  
  81. The WG decided that entPhysicalEntries with an associated
  82. entPhysicalClass value of 'backplane(4)' should be supported in 
  83. the PTOPO MIB and PDP.  Repeaters which generate PDP 
  84. advertisements should use the appropriate backplane 
  85. entPhysicalEntry in the PortID TLV, if the Entity MIB is implemented.
  86.  
  87. 1.4) PTOPO Traps
  88.  
  89. A default value of 'false(2)' will be specified for the 
  90. ptopoConfigTrapsEnabled scalar object. Text will also be added
  91. to the security section regarding this issue.
  92.  
  93. 1.5) SNMPv3 Alignment
  94.  
  95. The ptopoConnNetAddr object specifies only a network address of an 
  96. SNMP agent containing information associated with the remote endpoint. 
  97. The WG discussed the need for additional MIB objects to support SNMPv3 
  98. command-initiator functions in a secure environment. 
  99.  
  100. These objects (e.g., engineID, contextName, securityModel, securityName) 
  101. will not be added in the next draft of the MIB.  The current table does 
  102. not include community strings either.  It is considered a security risk 
  103. and burden to add this support to the PTOPO MIB and PDP.
  104.  
  105. 1.6) ptopoChassisId and ptopoPortId TCs
  106.  
  107. The TCs which define PTOPO chassis and port identifier strings will have 
  108. a max length of 32 octets, instead of 48 octets.
  109.  
  110. 1.7) ptopoConnTable INDEX
  111.  
  112. In order to allow an agent some flexibility to maintain multiple endpoint 
  113. entries (more than 2) per connection, the indexing of the ptopoConnTable 
  114. will be redone.  The table will now be indexed by 4 integers:
  115.  
  116.    INDEX { ptopoTimeMark, ptopoConnLocalChassis, 
  117.            ptopoConnLocalPort, ptopoConnIndex }
  118.  
  119. *** NEW  WG ISSUE ***
  120. Local Index Uniqueness Requirements:
  121. No Index Reuse:
  122.    The simple arbitrary local integer (ptopoConnIndex) must be unique
  123.    for a given { chassis, port } pair. An agent must insure that
  124.    each index is used at most one time per port between agent reboots.  
  125.    New index values must be used each time an entry is added to the table.
  126.    This restricts the number of significant topology config changes 
  127.    to 4 billion per port, but it makes the MIB easier to use for an NMS.
  128. Allow Index Reuse:
  129.    Some of the same usage and limitations as the first approach, except
  130.    that an agent is permitted (required?) to reuse a ptopoConnIndex value
  131.    for an entry that has been aged out and then subsequently re-learned.
  132.    The new entry must have the exact same semantics as the previous one 
  133.    at the time it was aged out.
  134.  
  135. The WG must decide which approach to use so the Editor can write the text.
  136.  
  137. 1.8) Last Verification Timestamp
  138.  
  139. A MIB object will be added to the ptopoConnEntry to indicate
  140. the value of sysUpTime when the indicated entry was last 
  141. verified by the PTOPO agent (e.g., by receipt of a PDP msg).
  142.  
  143. 1.9) Max Desired Hold Time
  144.  
  145. A scalar MIB object will be added to the ptopoConfig group
  146. called 'ptopoMaxDesiredConnHoldTime', which will specify
  147. the number of seconds a PTOPO agent should maintain connection
  148. information in the absence of entry verification.
  149.  
  150. If an entry exceeds the configured threshold, i.e.,
  151.  
  152. cur_sysUpTime >  (ptopoConnLastVerifyTime + (ptopoMaxDesiredHoldTime * 100))
  153.  
  154. then the PTOPO agent is expected to remove the entry.  Note that an
  155. agent is permitted to remove entries using periodic garbage collection,
  156. so entries may not be deleted at the instant the age-out threshold
  157. is exceeded.
  158.  
  159. 1.10)  Statically Configured ptopoConnEntries
  160.  
  161. Entries which are statically configured by an NMS are not subject
  162. to the garbage collection described in previous sections.
  163. Static entries are indicated by a new read-create MIB object in 
  164. the ptopoConnEntry called 'ptopoConnIsStatic', with SYNTAX TruthValue.
  165. There isn't any one appropriate DEFVAL, but entries with an
  166. associated ptopoConnDiscAlgorithm value of { 0 0 } (conf by NMS)
  167. are most likely static entries.
  168.  
  169. 1.11)  New MIB Counters
  170.  
  171. Three new scalar counters will be added to the ptopoConfig group to
  172. help an NMS identify PTOPO agent activity regarding garbage collection
  173. and topology changes. The ptopoConnTabInserts and ptopoConnTabDeletes 
  174. counters will remain exactly as defined.  
  175.  
  176. A 'drop count' object will be added called ptopoConnTabDrops.  
  177. This counter indicates the number of times a PTOPO agent detected a 
  178. situation in which information would have been added to 
  179. the ptopoConnTable, but wasn't because of insufficient resources.
  180.  
  181. A 'replace count' object will be added called ptopoConnTabReplaces.
  182. This counter indicates the number of times remote endpoint information
  183. of one identifier type has been replaced by information of
  184. a different identifier type.
  185.  
  186. An 'age-out count' object will be added called ptopoConnTabAgeOuts.
  187. This counter indicates the number of times an entry has been removed
  188. because the max desired hold time for the entry was exceeded.
  189.  
  190. The ptopoConnConfigChange notification will be updated to include
  191. the new counters.
  192.  
  193. 1.12) ptopoConnNetAddr Name Change
  194.  
  195. This object specifies a network address of an SNMP agent that contains 
  196. information associated with a remote connection endpoint. The object 
  197. will be renamed to ptopoConnAgentNetAddr.
  198.  
  199. 1.13) ptopoConnChassis1,2 and ptopoConnPort1,2 Name Change
  200.  
  201. The chassis and port identifier objects will be renamed to differentiate 
  202. between 'local' and 'remote' connection endpoints.  E.g., ptopoConnChassis1 
  203. will become ptopoConnLocalChassis and ptopoConnChassis2 will become 
  204. ptopoConnRemoteChassis.
  205.  
  206. 1.14) TLV Support in the ptopoConnTable
  207.  
  208. The WG discussed a proposal to add MIB objects to support vendor-specific
  209. MIB placeholders in the PTOPO MIB.  The WG decided that even though
  210. PDP supports vendor-specific TLVs, the standard PTOPO MIB should not.
  211. Such objects should be defined in a vendor's proprietary MIBs.
  212.  
  213. 1.15) Topology Server MIB
  214.  
  215. The WG recognizes that an aggregation of information gathered from
  216. potentially many PTOPO agents are needed for applications to present
  217. complete physical topology maps, and that future MIB work,
  218. possibly in the DISMAN WG, is needed to effectively deploy
  219. a standard topology server MIB.
  220.  
  221. 1.16) NVRAM Requirements
  222.  
  223. The MIB will be updated to require agents which support NV storage
  224. of static ptopoConnTable entries to recreate the exact semantics
  225. upon agent restart, except that none of the same index values 
  226. have to be reused. 
  227.  
  228. 2) PDP
  229.  
  230. 2.1) Multiple Sources for ChassisID and PortID TLVs
  231.  
  232. Since the PTOPO MIB supports multiple identifier types, the
  233. chassis and port identifiers used in PDP TLVs should also
  234. support this feature.  The ability to associate an identifier 
  235. with any MIB object is already supported.  It is an implementation
  236. specific matter as to how co-located PDP and PTOPO agents
  237. convert these OIDs to PTOPO identifier types.
  238.  
  239. 2.2) PDP Forwarding
  240.  
  241. Text will be added to the document further clarifying the
  242. differences between 'PDP forwarding' and 'PDP non-forwarding'
  243. types of PTOPO implementations.  An agent may contain entries
  244. representing ports not directly attached to the indicated 
  245. local chassis.  An agent may wish to limit and even suppress
  246. such entries, but this is not required.
  247.  
  248. 2.3) Selection of MAC address
  249.  
  250. In the event a MAC address is used in a chassis (or even a port)
  251. identifier TLV, the agent may have to make an implementation-specific 
  252. decision as to which address to choose if more than one is available.
  253.  
  254. 2.4) Elements of Procedure Appendix
  255.  
  256. An appendix will be added to the document to demonstrate how 
  257. a PTOPO agent may use info from a co-located PDP agent to
  258. populate the PTOPO MIB.
  259.  
  260. 2.5) PDP Checksum
  261.  
  262. The checksum in each PDP message operates exactly as a UDP checksum.
  263. The PDP message is encoded with a checksum value of zero. Then the
  264. ones-complement of the ones-complement addition of the encoded message 
  265. is rewritten to the checksum location in the message. 
  266.  
  267. The checksum is optional, and the value zero is reserved to indicate
  268. the checksum is not in use.
  269.  
  270. 2.6) ASN.1 Encoding vs. TLV Encoding
  271.  
  272. The WG discussed a proposal to use ASN.1 and a pseudo-MIB to describe
  273. the PDP message format and encoding.  Proponents think it is overall
  274. simpler to encode the PDP message payload as a varbind list 
  275. in ASN.1/BER encoding, rather than a list of TLVs in network byte order.  
  276.  
  277. The WG held a straw vote on which encoding to use:
  278.        ASN.1      --  6
  279.        TLV        --  3
  280.        don't care -- approx. 35
  281.  
  282. The WG decided to use ASN.1 encoding in PDP and describe the PDP
  283. parameters using a pseudo-MIB (not actually implemented by any SNMP
  284. agent), based on this straw poll.
  285.  
  286. Since the document editor doesn't know how to write a MIB object
  287. for a UDP-style checksum (along with requisite encoding hacks), 
  288. the PDP header and checksum need to be outside the portion of 
  289. the PDU encoded as an ASN.1/BER varbind list. Only the encoding of 
  290. the TLV portion of the PDU will can be affected by this change.
  291.  
  292. 2.7) Management Address TLV
  293.  
  294. A proposal was made to make the mandatory management address 
  295. TLV an optional TLV.  As a compromise, the TLV will remain
  296. mandatory, but an empty string may be used for the "don't know"
  297. value.
  298.  
  299. 2.8) Default Timer Values
  300.  
  301. A proposal was made to change the DEFVAL for the PDP transmission
  302. interval from 60 to 10 seconds.  Some wanted to raise the DEFVAL even 
  303. higher than 60 seconds.  The WG agreed to leave the DEFVAL at 60, 
  304. noting that an agent may be configure any legal DEFVAL in implementation.
  305.  
  306. 2.9) Replace pdpMessageTxHoldTime
  307.  
  308. This object will be changed to indicate a multiplier value, used with
  309. the pdpMessageTxInterval object to derive the same semantics, except
  310. that illegal configurations will be avoided.  The DEFVAL will be 3,
  311. and the same index range will be maintained.
  312.  
  313. 2.10) Authenticated Discovery Protocol
  314.  
  315. A proposal was made to support the ability to encode the PDP messages
  316. as auth/no-priv or auth/priv SNMPv3 PDUs.  This was rejected due to
  317. increased complexity and the inability to do administration such as
  318. discovery protocol.  
  319.  
  320. 2.11) pdpTxSuppressTable Changes
  321.  
  322. The table used to suppress PDP message transmission will be generalized
  323. to suppress PDP transmission and processing of any PDP messages
  324. received on a particular port.  The table will be renamed 
  325. to 'pdpSuppressTable'.
  326.  
  327. 2.12) PDP MAC Group Address
  328.  
  329. An appropriate group address must be chosen for PDP messages.
  330. Keith McCloghrie volunteered to act as WG liaison to the IEEE 
  331. 802.1 sub-working group and pursue the matter further.
  332.  
  333. The IETF may have a group address allocated which can be used
  334. for PDP.  This option will be pursued by the WG as well.
  335.  
  336. 3) Physical Topology Discovery using Standard MIBs
  337.  
  338. Nick Dawes of Loran reported on implementation experience
  339. regarding the discovery of physical topology using MIBs
  340. commonly found on various network devices.  
  341.  
  342. The important features of this SW include:
  343.    - use of probability-based weighting factor to help resolve data
  344.      conflicts from multiple sources, which can occur in the normal
  345.      operation of the network.
  346.    - designed for minimal impact on network traffic; polling gated
  347.      by max-desired-bandwidth (as a percentage of bandwidth); only
  348.      minimum set of required MIB objects actually retrieved from
  349.      each agent.
  350.  
  351. 4) Entity MIB Requirements
  352.  
  353. 4.1) entPhysicalAlias object
  354.  
  355. The max length of this string will be 32 octets instead of 48,
  356. to match other changes made in the PTOPO MIB.
  357.  
  358. The string will be based on the UTF-8 based SnmpAdminString,
  359. defined by the SNMPv3 WG.
  360.  
  361. 4.2) Entity MIB Document Advancement
  362.  
  363. The Entity MIB WG needs to do extensive work to support SNMPv3
  364. and investigate RFC 2037 implementation experience.
  365.  
  366. Therefore, the PTOPOMIB WG wants the ENTMIB WG to phase
  367. the upcoming controversial work, and publish a simple
  368. augmentation to RFC 2037, containing just the entPhysicalAlias
  369. extension defined in draft-bierman-entmib-compid-00.txt.
  370.  
  371. The ENTMIB WG Chair will discuss re-activation with the
  372. Area Director, and report back to the PTOPOMIB WG.
  373.  
  374. Meeting Resolutions
  375. -------------------
  376.  
  377. A)  Document Advancement
  378.  
  379. New versions of the PTOPO MIB and PDP I-Ds will be published
  380. by 17sep97, which will then be discussed on the mailing list.
  381.  
  382. The Entity MIB WG will hopefully be restarted in time to hold a first
  383. meeting at the next IETF in December.
  384.  
  385. The group MAC address issues will be discussed on the mailing list
  386. and hopefully resolved at the next IETF.
  387.  
  388. B) Interim Meeting
  389.  
  390. No interim meeting has been planned at this time.  A charter extension
  391. has been requested instead. Hopefully the WG can complete the currect 
  392. charter soon after the December IETF meeting.
  393.  
  394.  
  395.  
  396.  
  397. --------------64865A6F589F43D0524F8516--
  398.  
  399.