Minutes of the 46th IETF RAP WG Session, Washington DC, 11/08/99 Minutes reported by Diana Rawlins (Diana.Rawlins@wcom.com) Mark Stevens, acting WG "chair" The agenda items, see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-rap-1199.ppt, were: 1. COPS Client MIB - status 2. Yoram Bernet "Application and Sub Application Identity Policy Element for use with RSVP" 3. David Durham " Status of COPS Specification" 4. David Durham "COPS for Provisioning" 5. Yasusi Kanada "SNMP based QoS Programming Interface with MIB for Routers 1. COPS Client MIB http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-client-mib-01.txt No discussion at this meeting. Plan to go to WG last call following IETF meeting. 2. Application and Sub Application Identity Policy Element for use with RSVP http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-appid-00.txt Scott Bradner (Transport Area co-AD) clarified that this item was more appropriate for the RAP WG because the RSVP WG was ramping down. Yoram Bernet presented an overview of the draft. It builds on the identify draft by adding additional levels of granularity with an application as well as sub-application identifier that can be used in an RSVP aware network. This additional granularity permits network QoS management of application based policy. The new application element consists of a policy locator attribute and credential attribute. The policy locator attribute is a formatted X.500 DN that represents the application, version number and sub-application. 3. COPS draft status. Common Open Policy Service http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-08.txt Scott Bradner (Transport Area co-AD) reported that the IESG members received the clarification that was requested and the 6 drafts were entering the RFC editor's queue - RFCs should be published in a few weeks (ed: specifications were approved by IESG as Proposed Standards on 11/18/99). Dave Durham reported that the changes in the cops-08 draft included a mandatory to implement security mechanism. Security is accomplished with the COPS Integrity object which can have manual configuration keys, multiple simultaneous keys, time to live specified, etc. It is similar to IPSEC. The IPSEC/TLS is still optional. IKE can be used for COPS the KEYID exchange. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/durham-COPS-Update-for-46IETF.ppt 4. COPS Usage for Policy Provisioning http://www.ietf.org/internet-drafts/draft-ietf-rap-pr-01.txt Dave Durham presented an overview of the draft, see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/durham-COPS-PR-for-46 IETF.ppt. This draft addresses the provisioning/configuration policy model rather than the outsourcing model. There are protocol suitability issues that are being addressed in the Configuration Management BOF on Thursday. The COPS-PR capabilities include dynamic provisioning support, transactional support, efficient data encoding, and simple access in terms of indexing and security. A provisioning example is the provisioning of Diffserv. The COPS-PR can be used to pre-provisioned classification, metering, and actions in a potentially dynamic manner. Dave quickly reviewed some advantages of using COPS to configure network elements. These included the dynamic update of shared state between the PDP and PEP, the addition/update/removal of provisioned data, the reliable support of large and small transactions, the exclusive access to data, fault tolerance, the support of fail-over, PEP initiated capabilities, the avoidance of network polling, and the ability for the PDP to collects capabilities from the PEPs. Dave pointed out that the Data Model is still needed and work on this is underway (-- pending based on the outcome of the Configuration Management BOF.) The configuration data is opaquely transported via COPS-PR in the ClientSI objects. The proposed PIB provides the Data Model. The decision carries the configuration data. The proposed data representation for Differentiated Services reuses SNMP SMI and BER encoding. The COPS PIB optimizes the SMI for provisioning. It provides row level access, has minimum transmission of object identifiers and avoids data consistency problems by using an OID unique to client type. The draft has included a section describing extending and updating the Data Model. It is expected that it would change over time. Some attributes won't be needed (deprecated) and new attributes may be added. The COPS Report operation can be used to send unsolicited accounting updates. The unsolicited reports are triggered by events and remove the need for polling. Security for COPS-PR uses the same mechanism as the base COPS draft (Integrity Object or the IPSEC.) Questions from floor: 1) When adding PRC's or deprecating PRC's from a PIB why wait until a DECISION to determine this. Why not do it during the initial request / solicited decision exchange? The response was that this seemed to be a reasonable approach. 2) The REPORT type accounting lacks clarification in the draft. The response was to post a suggestion to the mailing list. 3) What is role of bandwidth broker in this scheme? This discussion is postponed until the Configuration Management BOF. 5. SNMP based QoS Programming Interface with MIB for Routers http://www.ietf.org/internet-drafts/draft-kanada-diffserv-qospifmib-00.txt The draft was originally submitted to the DS WG, but was considered more suitable for CONFIGMGT BoF since it deals with configuration management or RAP WG (since we have more time on the agenda). Yasusi Kanada presented an overview of the draft - see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/kanada-QoSMIB-IETF46R AP.ppt. It is based on the concept of Active Networks (AN) where networks download programs to nodes and policy based resource allocation is the first step of AN. Hitachi has implemented both a version of the QoS MIB and COPS PIB using an API of standardized IEEE P1520 CORBA IDL. Problems were found with both the MIB and PIB since they were unsuitable for representing program semantic. The solution proposed by the draft is to provide a rule based programming language for the interface. The definition of the protocol must include a rules based language. Questions: 1) Is this draft alternative to COPS-PR? Response was that the draft is "not opposing COPS" but expanding it. 2) The point was made that pushing programs to the router was never the intention of the MIB or PIB. 3) It was asked that if MIB's aren't good for programming language, then why is the draft submitting a MIB for this purpose. The response was that the MIB was not suited for downloading programming to the router. 4) The point was made the Policy Framework WG assumes that policy rules are declarative and not procedural. The concern was noted that network behavior is unpredictable and what was the reasoning for the policy rule to be procedural? The response was that policy rules viewed as semantics is a different, but good approach. 6. CONCLUSION: Mark Stevens concluded session by providing a summary of the RAP Time Table and milestones and work related to RAP (see slides).