Minutes of RSVP Admission Policy (rap) Working Group meeting 43rd IETF, Orlando, FL, 9th December 1998 Recorded by Andrew Smith ---------------------------------------- Summary Set of 6 documents, 1 informational describing RAP framework, 5 standards' track protocol specs for COPS base protocol and its use with RSVP. Editorial and minor technical issues need to be resolved on 3 of these documents - expect to have new versions of these 3 for WG last call in early January 1999. This document set fulfills current RAP charter. Strong support within WG for a new work item to define COPS usage in DiffServ environments. This requires action from area directors and coordination with other WG chairs. Charter: http://www.ietf.org/html.charters/rap-charter.html Agenda 1. Agenda bashing, WG scope statement etc. - Chairs - 5 mins 2. RAP Framework updates - Raj Yavatkar - 10 mins 3. COPS Protocol updates/changes - Dave Durham - 20 mins 4. COPS for RSVP updates - Shai Herzog - 15 mins 5. Policy Extensions for RSVP - Shai Herzog - 15 mins 6. Priority policy objects for RSVP - Shai Herzog - 10 mins 7. Identity representation for RSVP - Satyendra Yadav - 15 mins 8. Last-call/standards'-track discussion - Chairs - 10 mins 9. Expanded charter discussion - Chairs - 15 mins 10. COPS for DiffServ - ?? - MAYBE Updates to the RAP framework - Raj Yavatkar: draft-ietf-rap-framework-01.txt No open issues. COPS-03 draft - David Durham: draft-ietf-rap-cops-03.txt Issues: 1. Who owns PEPID - writable? Open. 2. Keepalive per client-type or per-TCP connection? This is really a transport issue but there is not a fast enough notification from TCP. Open issue. 3. IANA client-type admin? Yes, but is there internal structure? Some feeling that this should be a flat space. 4. Is context needed for LocalPDP decisions? Probably not. 5. PDP Redirect to alternate port numbers? Probably not needed. What are the implications of choosing TCP as the transport (c.f. RUTS BoF)? Should we define our own ordering mechanisms just in case we choose non-TCP in future? No. Does TCP's tendency to stall get in the way? Yes but ... Smith: we could redefine COPS to have an abstracted transport service interface? No. Bradner: don't change anything at this point. COPS-RSVP usage - Shai Herzog: draft-ietf-rap-cops-rsvp-01.txt Presented motivation for allowing multiple contexts for each decision returned from PDP. No known open issues. RSVP Extensions for Policy - Shai Herzog: draft-ietf-rap-rsvp-ext-01.txt Defines RSVP rules for handling policy objects in policy-capable and policy-ignorant nodes (PINs). Flag to indicate "this is a refresh of earlier policy data" - optimisation. Option list: can indicate which FilterSpecs in the reservation this policy applies to, can indicate which originator or destination it applies to. Integrity object to prevent replay attacks. Refresh Multiplier object: allows some control over how often these policy elements will be included in refresh RSVP messages e.g. every 'n' refresh cycles. Discussion: a time-based object would be more useful; what if intermediate routers use different refresh timers? What about route changes/network errors? General feeling that this needs some more discussion or else removing - open issue. Fragmentation - not addressed: this is a potential RSVP problem although policy objects make it worse - certificates can be big. Hopefully there will not be too many PINs in between ones that are actually merging/compressing these objects. General feeling that this does not need solution as part of this work item. Policy element number space: do we need IANA to allocate these? Yes - needs description in the draft. RSVP Preemption priority - Shai Herzog: draft-ietf-rap-priority-00.txt Priority assigned by PDPs, simple to use by PEPs. Merging: cannot define a single algorithm suitable for all intended uses that solves free-rider, denial-of-service and instability problems. The object itself therefore defines one of 3 different algorithms. Examples of merging scenarios. Stability is ensured by a concept of a "defending priority" vs. new priority (hysteresis). No known open issues. COPS-RSVP Policy data for User Identity - Satyendra Yadav: draft-ietf-rap-rsvp-identity-00.txt Added encodings for "application name". Should we create a registry for user/string encodings (currently has ASCII and Unicode, Encrypted and Plain)? Should these be IANA assigned? Open issue. Issue raised later on mailing list: make sure that the RAP WG is aware of the work done in the ROAMOPS area: standard way to present a user identifier (NAI). This may be accomplished by registering NAI as a subtype through IANA - IANA considerations sections still need to be finalised. Next Steps & Timetable - chair (Smith) Documents on the agenda right now: only editorial and minor technical issues outstanding - propose to issue WG last call on all of these after spinning several drafts, hopefully early in January 1999. 1. COPS Framework - Informational 2. COPS protocol (needs spin) - Standards' track 3. COPS-RSVP - Standards' track 4. Policy Extensions for RSVP (needs spin) - Standards' track 5. Policy Extensions for preemption priority - Standards' track 6. Policy Extensions for identity (needs spin) - Standards' track Publication of these would fulfill existing RAP charter. Charter extensions? - chair (Smith) + area director (Bradner) Bradner: issue needs to be resolved by ADs and WG chairs about possible overlap with Policy WG and AAA BoF. Concerns raised by multiple people in discussion about there being significant multi-vendor momentum to extend COPS for, in particular, DiffServ control (there is existing draft but this is currently considered out of WG scope). Concern that AAA work will be long in coming. Should any DiffServ work be just a framework mechanism for transporting arbitrary DiffServ information or should it be morenarrowly defined (specific objects etc.)? Elleson - strong desire to coordinate closely between policy WG and any potential-RAP work item.