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 – 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.