The 2nd NMRG meeting took place in Boston, MA, USA on May 23 and 26, in parallel to IM'99. Duration = 2 * 0.5 day. Present: * Juergen Schoenwaelder (JS) * Aiko Pras (AP) * Jean-Philippe Martin-Flatin (JPMF) Agenda: * draft-irtf-nmrg-snmp-tcp-00.txt * compression * SMIng * long-term aim of NMRG * how should NMRG operate? * next NMRG meetings Minutes: 1) draft-irtf-nmrg-snmp-tcp-00.txt =============================== * We are not far from completing this draft. We went through the comments that JPMF sent to the NMRG mailing list (NMRGml) on May 7. * The new section 3.3 should be rephrased (e.g. "UDP connections" is a contradiction). JS typed in a new text we all agreed with. JPMF's idea that this RFC should not explicitly limit the use of TCP to bulk data transfers was accepted. AP proposed a new wording for the retransmissions with which we all agreed. * Use of MUST, SHOULD, CAN...: JS will decide when to capitalize these words. * What should be the minimum size guaranteed to be accepted by all entities? We had a long discussion to find a good trade-off between what should be supported by all boxes (don't make this guaranteed size too high) and when the use of TCP becomes useless if this guaranteed size is too low. JS put 484 octets in his first draft. JPMF changed it to 64k. JS advocated 2k instead. AP, Grand Master of Consensus, proposed 8k. Agreed by all parties present; to be discussed on the NMRGml. In the meantime, JS puts 8k in his new draft. * ACTION: JS modifies the draft posted by JPMF on May 7 and sends it to the NMRGml for review. 2) Compression =========== * Do we want compression only in SNMPv3, or in SNMPv1 and SNMPv2c as well? AP and JPMF both mentioned the danger of multiple releases branching off. JS argued that since SNMPv3 is not getting deployed fast, adding compression to SNMPv1 and SNMPv2c might be a good idea. To be discussed on the NMRGml. * JS: it is important to compress before we encrypt, otherwise we would lose any pattern in the data --> poor compression ratio (see IPcomp in IPv6). * We discussed the pros and cons of JS's solutions for compression. * Solution #1: Compression is a special case of encryption. Problem: authentication would become mandatory (because encryption mandates authentication in SNMPv3). AP and JPMF: This is a big problem. * Solution #2: In the SNMPv3 header, the 4th bit of the msgFlags (RFC 2572) specifies if compression is used. Name: compressFlag. (The 1st bit is authFlag for authentication, the 2nd bit is privFlag for encryption, the 3rd bit is reportableFlag for Report PDUs). If compressFlag is set, compression is then handled like encryption today. Advantage: simple. Drawback: this works only with v3. * Solution #3: In RFC 2572, a scoped PDU is defined as follows: ScopedPDU ::= SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in RFC 1905 Instead of using only PDUs as defined in RFC 1905, we could define a new PDU called compressedPDU. The encoding of this PDU would specify to compress the data. We need to put in a MIB a table of all the ANYs supported by an entity; this enables a sending entity to find out if a receiving entity supports compressedPDU. Advantage: works with v1, v2c and v3. Drawback: allows the compression of a little less data than solution #2 (the context engine and the context name are not compressed with #3). * There's no clear winner yet. For each solution, we need to study in detail the reaction of a normal SNMP agent/manager when it receives a compressed SNMP message. * All solutions require that the compression algorithm (e.g. gzip) be specified in a MIB. We need to define this in more detail. * ACTION: Discuss this on the NMRGml and choose a solution at the next NMRG Meeting. 3) SMIng ===== * JS: Is NMRG the right forum to discuss SMIng? JPMF=yes. AP=not sure. We didn't get enough answers to this question on the NMRGml. * AP: We should develop a vision of an architecture (service mgmt, distributed network mgmt...) together with looking at the more detailed things such as SMIng. * AP: What we miss in SMIv2 is the equivalent of C structures. We have only tables. JS: We don't need nested tables, equiv. to structures, because nested tables are easy to flatten into a single table (see SQL which doesn't support nested tables either). * JS: We miss the notion of method or function calls with well-defined signatures. There are currently many different ways to do the same thing via side effects of SET operations. This raises implementation cost issues and leads to interoperability problems. How these SMI methods or function calls map to underlying management protocols or APIs remains to be defined. * ACTION: JS reposts his question of May 12 to the NMRGml. 4) Long-term aim of NMRG & 5) How should NMRG operate? =================================================== * Starting point: JS is a bit disappointed that we don't get things done fast enough. We are very slow to progress. Few people in the NMRGml answer his questions. There are many "sleeping partners" (do nothing, see what the others do) and not enough active members in NMRG. * We had a long discussion showing that we all expect different things from NMRG: * AP wants to work on a new architecture for Internet mgmt: - SLA - inter-domain mgmt - distributed mgmt - not simply network elements Preference = architecture. Also interested in design & implem. * JPMF: Main interest in distributed network mgmt. Manager to manager, manager to agent. Define high-level semantics, high-level information models. Map to XML. Preference = design. Also interested in arch. & implementation. * JS wants to get real things out, especially prototypes and RFCs. His primary interest is to get the initial thing which started the NMRG completed (SNMP over TCP, Compression, getsubtree PDU). Preference = implementation. Also interested in arch. & design. * The bad news is: - we have different expectations, different poles of interest - we are all funded separately to do very different tasks - we'll probably never agree to work all on the same thing at the same time. * The good news is: - we all want to work together - we are very complementary in our interests * Everyone agrees that this working group has great value, and we all like to work together. Still, it may be necessary to adjust our mode of operation as all of us are busy with many things, which must be performed in parallel with the work for NMRG. We must accept that it will not be possible to investigate every research topic that we would like. We agreed therefore that we will only start a new topic if there is at least one person who takes the lead for that topic, and who sends documents to the NMRGml for scrutiny, analysis, criticism, feedback... Our commitment as members of NMRG is to make the effort to read these documents reasonably fast and spend the time to provide valuable feedback. For NMRG to be successful, it is important that, once in a while, we set a milestone and produce some output: RFC, paper, prototype... * ACTION: Discuss this on the NMRGml and check if others are happy with this change. 6) Next NMRG meetings ================== * It is important that we have meetings several times per year. Otherwise the group will dissolve quickly. It is OK that all NMRG members don't attend all meetings (money, time schedule...). * The 3rd NMRG Meeting will take place in Oslo, Norway on July 10, just before the 45th IETF Meeting. It will last only 1 day because IETF Meetings are already very demanding. * The 4th NMRG Meeting will take place in Zurich, Switzerland in October, together with the DSOM'99 workshop. It will last 2 days. * ACTION: JS contacts the IETF folks and gets a room in Oslo. * ACTION: JPMF contacts the organizers of DSOM'99, chooses a date with them and gets a room at ETH Zurich. ____________________________________________________________________ Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland Email: martin-flatin@epfl.ch Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/