home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97aug / ipc-minutes-97aug.txt < prev    next >
Text File  |  1997-10-10  |  5KB  |  120 lines
  1. Munich IETF Proceedings
  2.  
  3. Transport Area
  4. IPC BOF
  5.  
  6. Minutes of the IntServ Policy Control BOF (IPC)
  7.  
  8. Reported by: Raj Yavaktar, Intel and Shai Herzog, IPHighway
  9.  
  10. Tuesday August 12, 1997
  11.  
  12. (All slides are available from ftp://ftp.iphighway.com/pub/IETF/ipc)
  13.  
  14. A. Charter Draft, Roch Guerin, IBM
  15.  
  16. Roch Guerin presented a charter proposal for the IPC WG. He suggested
  17. both immediate (short term) and long term goals for the WG.
  18. Immediate goals include the establishment of a framework overview
  19. and applicability documents, develop a standard client-server protocol
  20. define the set of policy extensions to RSVP and define some experimental
  21. policies. Long term goals should be to identify a set of basic policies
  22. and develop a template for defining new ones.
  23. (slides of his talk to be made available as part of the notes).
  24.  
  25. 1. Jim Binder and some other members of the audience suggested that the
  26.    the scope of the working group as presented is too broad and it
  27.    requires further clarification and focusing.
  28.  
  29. 2. Fred Baker pointed out that the group should concentrate on policies
  30.    related to QoS or resource reservation and its goals should not
  31.    include policies for other purposes such as routing policies.
  32.    Consensus was reached (by vote) that the goals of the WG should be
  33.    to develop policy control to rsvp-like, QoS protocols. Scott Bradner
  34.    emphasized that the immediate goal is RSVP. However, provided that
  35.    the main RSVP effort is not hurt, policy admission control for
  36.    similar resources (other than bandwidth reservation based on
  37.    RSVP) could be supported based on the types of clients (type1=RSVP,
  38.    type 2= something else, etc.).
  39.  
  40. 3. It was suggested that the name of the working group should be
  41.    changed to something like Internet QoS policy Control, to
  42.    reflect the narrow scope.
  43.  
  44.    (Note: the mailing list reached a consensus AFTER the meeting on
  45.    this issue. It was agreed to keep the existing initials (IPC) but
  46.    change the wording to IntServ Policy Control)
  47.  
  48. 4. The BOF formed consensus that the WG would define classes of policy
  49.    elements and NOT policies themselves. Scott Bradner pointed out the
  50.    need for staying out of the business of definition of policies
  51.    (define the mechanisms and policy elements, but not the policies
  52.    themselves). Also, one of the stated goals should be to achieve
  53.    uniform definition of policy elements.
  54.  
  55. 5. Fred Baker emphasized that the WG goals should ensure that
  56.    we consider security aspects in all parts of policy control
  57.    and allow management of components in the sense of network
  58.    (SNMP-based?) management. In particular, a threat analysis must be
  59.    conducted as applied to QoS policies.
  60.  
  61. B. IPC design issues, Roch Guerin, IBM
  62.  
  63. Roch presented a set of design issues (choices) and emphasized
  64. the two main aspects for the scope of the design of the
  65. policy-based framework:
  66.  
  67. (1) Client-server protocol and policy info exchange
  68. (2) Necessary RSVP extensions and interface
  69.  
  70. Jim Binder and Raj suggested that a framework document be drawn up to
  71. discuss the assumptions, basic issues of policy control for RSVP, goals,
  72. and scope of the work.
  73.  
  74. There was some further discussion on the first topic -- what should be the
  75. division of labor between client and server parts and the possible
  76. asymmetry between client and server functionality and how to simplify it?
  77.  
  78. The discussion was inconclusive and deferred to the IPC mailing list.
  79. It was agreed upon that a framework document is needed before we can
  80. effectively evaluate the various design choices.
  81.  
  82. C. PEPCI protocol proposal, Jim Boyle, MCI and David Durham, Intel.
  83.  
  84. Jim Boyle and Dave Durham presented the PEPCI proposal for a protocol
  85. for exchange of policy information between a policy client and the server
  86. (slides to be included in the notes). The main claim was the simplicity of
  87. the protocol (to support "minimum functionality needed")  as compared to
  88. OOPS with some examples of differences in complexity and functionality.
  89.  
  90. D. OOPS-01, Shai Herzog, IPHighway
  91.  
  92. Shai presented the second version of OOPS. (slides to be included in 
  93. the notes). He presented this second version as a mature, significantly
  94. improved version of OOPS-00, true to the original goals: simplicity 
  95. (for routers), distributed division of labor, flexibility, and 
  96. scalability. He further maintained that PEPCI was pushing complexity 
  97. into routers, had several conceptual "bugs" and did not cover some of 
  98. the important scenarios necessary for policy control.
  99.  
  100. E. Client/Server protocol discussion.
  101.  
  102. The following discussion was to some extent "OOPS vs PEPCI -- which is
  103. better" with no constructive conclusions. It was suggested that instead of
  104. trying to compare the two protocols, we should concentrate on the
  105. framework document and use it as a basis for further work.
  106.  
  107. The discussion of the WG charter and the framework document was
  108. deferred to the mailing list.
  109.  
  110. F. Miscellaneous
  111.  
  112. After the meeting, after discussions with our area director,
  113. Scott Bradner, Tim O'mally agreed to be Chair of the IPC WG.
  114.  
  115.  
  116. Raj and Shai
  117.  
  118.  
  119.  
  120.