Minutes of the Resource Allocation Protocol WG (rap) IETF47, Adelaide, Australia, March 28th 2000 WG co-chairs: Mark Stevens and Andrew Smith Minutes submitted by: Andrew Smith WG charter: http://www.ietf.org/html.charters/rap-charter.html Current status - chairs (see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-rap-0300.ppt) 1. Policy terminology 2. COPS Client MIB 3. COPS for Provisioning and PIB framework/mechanisms 4. Interop testing of COPS-PR 5. New work - Proxy-RSVP, interactions between COPS-RSVP and COPS-PR Policy Terminology - Mark Stevens/co-chair Please use consistent terminology: need to align with policy WG and others in this area: see e.g. draft-reichmeyer-polterm-terminology-00.txt which is now owned by Policy WG. Please help with contributions in this area. COPS Client MIB - Andrew Smith COPS client MIB (draft-ietf-rap-cops-client-mib-02.txt) from Extreme/Ericsson/Nortel. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/smith-cops-mib-0300.p pt. Revised objects for server retry algorithms - in WG last call (again). COPS-PR - Scott Hahn Overview of provisioning using COPS - see slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/hahn-COPS-PR-0300.ppt . Changes: added multiple contexts for data, supports different encoding methods, multiple client-types, expanded treatment of reports. PIB syntax is now described in separate draft. Client-Types: - COPS-PR is not a client-type now: client-type represents an area of policy - ClientType is described by the PIBs themselves. Data encoding: still BER encoded - future PIBs might use different encoding rules (clarification: he means future usages of COPS-PR - we do not expect PIBs to choose their own encodings) Contexts: to support multiple concurrent configuration sets with a flag to indicate which one is current. PDP can initiate a new context (by asking PEP to allocate a new context). Error handling: broke up errors into 2 different types: global, class-specific. New COPS-PR objects (new S-nums): PRID, PRID Prefix, EPD, GPERR, CPERR, ErrorPRID Q: if COPS-PR does not have its own ClientType, how do we know what format ClientSI objects are in? A: Dave Durham - thinks this works out OK. Accounting: sent as a {PRID,EPD} - we have not developed an accounting PIB yet. Q: Is COPS-PR intended as an AAA protocol? A: Not directly although there is overlap. AD suggests that those interested in having COPS considered in this space (AAA WG) should contribute there. Q Jeff Case: where are encodings specified? A: Inherited from SNMP right now - need to make this more explicit. Structure of Policy Provisioning Information (SPPI) - Keith McCloghrie See slides ftp://ftpeng.cisco.com/ftp/kzm/pub/sppi-mar00.ppt. Now a formal definition: deltas to RFC 2578-80 SMIv2 (which is a Full Standard). POLICY-ACCESS: install or notify (or both). INSTALL-ERRORS MAX-ACCESS - not needed SYNTAX - we do not want the base types to specify semantics here: that is the job of Textual-Conventions. Just have base types here for on-the-wire encodings (INTEGER, OCTET STRING, OBJECT IDENTIFIER). Application-defined types e.g. Integer32, Integer64. We retained Timeticks & IpAddress since SNMP does but they shouldn't really be base types. NOTIFICATIONS not used. INDEX clauses: limited to a single Unsigned32 with arbitrary semantics (TC for PolicyInstanceId). We do not really intend COPS for GETNEXT-like searching so multiple indices are not that useful. We keep it here just for consistency with SMI syntax. UNIQUENESS: specific the set of attributes that must be unique for all instances of the PRC - promotes good design and aids understandability. AUGMENTS: it is its own PRC. An install/delete of the base PRC implicitly installs/deletes an instance of the augmenting class. Q Bert: how does implicit install work? A: rely on DEFVALs if PDP does not specify). MODULE IDENTITY: now has a "CLIENT-TYPE" clause to say which ClientTypes are relevant. IMPORTS - from SPPI, from other PIBs, from MIBS, from TCs. Extending the SPPI: can add client-types, INSTALL-ERRORS. Algorithm for converting PIB to MIB (need to define how to map to 64-bit types: propose we make them OCTET STRINGs). Q Bert: need to consider how to invent OIDs for RowStatus objects that get automatically added. Q Bert: CLIENT-TYPE maybe needs a new non-COPS name. There are probably other places. Q Dan: is it OK to define SPPI by reference to SMIv2? What if it changes. A: the existing understanding of SMI is worth Q Jeff: is it a design goal that we continue to support algorithmic mapping to SNMP? A: yes. Q Jeff: Why read-only MIB? Q Jeff: Why map Integer64 to an octet string? SNMP only had problem with Integer64. Be consistent. A: want to avoid the SNMP controversy over 64-bit types. AD says it is up to this WG - you may want to see what SNMPv3 WG comes up with in this space. Q Bert: why not just do a complete definition, rather than reference SMI? A: Because it's easier for the many who know (or would benefit by knowing) the SMI to determine what's different, and to avoid accidental divergence. Framework PIB - Dave Durham Universal COPS-PR PIB concepts are placed in their own module/document. Re-usable PIBs are useful; reusable between ClientTypes - can list a PIB as "all ClientTypes" or a list of explicit ones. - Incarnation: determines which is the currently-active context, which PDP installed it and TTL policy for the information. - Roles and Interface types: shows what roles are supported on which interfaces. - Capabilities and Limits: shows restrictions on supported PRCs and their values: supportTable shows per-attribute support and what ranges/values are supported. We could also use some sort of constraint language to specify more detail - not for now though. Capabilities are sent in a COPS-PR request. Q Jeff Case: different revisions of cards in a chassis - same interface type, different capabilities: how do we model this? A: interface type" is a more general concept, not an IANA InterfaceType. Q Andrew: Capabilities are a bitmap right now - how does this get extended? A: these are probably per-PIB-module. We might need a more general language but this should suffice for now. Policy Auxiliary MIB - Kwok Chan Used for managing a policy client: contains a table to relate RoleCombination to physical interfaces. Each interface has one and only one RoleCombination. This is a mapping needed to associate feedback from the device with policy. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/chan-PolAuxMIB-0300.p pt. COPS-PR and QoS PIB Interoperability testing - Kwok Chan Tested COPS base protocol, COPS-PR-01 and QoS PIB (draft-mfine-cops-pib-02.txt). Protocol interpreted and implementation was pretty good - we have some feedback. See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/chan-COPS+PIB%20Inter Op1-0300.ppt. MCI, Nortel, Extreme, IPH, Cisco, Intel. Want to do subsequent testing, as well as COPS-RSVP. Q Yoram: how does this relate to QoS Forum work? A: this is for bug fixing in the specs, not necessarily in implementations. But we need to coordinate. Q Jeff: where do we define which subset of ASN.1 needs to be implemented? A: need to fix this. Thanks to Kwok Chan for hosting this event. Feedback needs to be folded into next revs of all drafts. COPS for Proxy-RSVP - Dinesh Dutt See slides ftp://ftp.extremenetworks.com/pub/outgoing/docs/andrew/dutt-copsproxy-0300.p df. Receiver Proxy: a new extension to RSVP. No on-the-wire changes, only message processing changes. This is to be informational RFC from RSVP WG. Need a policy decision as to whether to proxy a session or not ¡V also needs a COPS protocol extension to specify which objects to include. Adds a flag to base COPS protocol (this should be more general than "send RESV") to say "proxy it"). Q Shai Herzog: it seems wrong to be messing around with the PEP here - it is really the PDP doing the proxying. What is needed beyond "schedule this RESV message" capability? How about a more general solution. Q Silvano: sometimes need to forward the PATH as well as proxy a RESV: we haven't written that up yet. Q Andrew: Not clear on the model in use here. Q Silvano: we need to provide some support for receiver proxy functionality. Solve this problem. COPS-RSVP and COPS-PR interactions - Dave Durham Best of both worlds is RSVP/IntServ + DiffServ, all coordinated by COPS with a common model. Need deterministic roles that map to RSVP interfaces which are sent as part of COPS-RSVP messaging - seems to be scope for some informational material on this.