ISSLL WG - Minutes from meeting at 49th IETF - San Diego, CA, 12/13/00 *) Summary of happenings since last meeting John Wroclawski presented a status report for ISSLL work in progress: Three internet-drafts completed and published as RFC's - RFC 2996: Format of the RSVP DCLASS Object - RFC 2997: Specification of the Null Service Type - RFC 2998: A Framework for Integrated Services Operation over Diffserv Networks draft-ietf-issll-rsvp-aggr-02.txt submitted to IESG for publication as RFC, ran into some concerns. Will discuss later in the meeting. New document draft-ietf-issll-rsvp-cap-01.txt taken on as WG work, will discuss next. *) draft-ietf-issll-rsvp-cap-01.txt Hamid Syed presented this draft. The work defines a mechanism for allowing upstream and downstream elements (hosts, routers, etc) to negotiate about which one is responsible for what functions (marking, policing) when an RSVP-controlled flow enters a diffserv network. The work is intended to augment the use of the RSVP DCLASS object previously defined by the group. Discussion: - Examples are between router and upstream host - is this the only intended use? -- No, intended to be a negotiation framework between upstream and downstream boxes in general. For example, between egress router of one diffserv cloud and ingress of another. Another case - multiple markings, where different DSCP is used in different parts of the path - here negotiation might be between egress and ingress routers of two DS clouds, and simultaneously between ingress router of first DS cloud and host. - Name the RSVP object to reflect this (original proposal was HCAP). -- Yes. (now CAP object) - Why is this object really useful? -- Discussion of this question concluded that the object was useful in a number of scenarios, but that the examples given in the current draft were somewhat limiting. Draft examples focus on whether a DCLASS object should be used at all, but real questions are more complex - who marks, who filters, who polices, etc. Conclusion: need more work here, first to work out wider range of scenarios and then to present them in an informational fashion. - What path forward for the document? -- Discussion reached a concensus to split the draft into two documents, a very short standards-track document that specifies the CAP object and any related mechanism, and a longer informational document that describes a range of scenarios and uses of the object and mechanism. *) draft-ietf-issll-rsvp-aggr-02.txt Allison Mankin (Transport AD) reported briefly on concerns raised by the IESG with this draft. Basically, the draft specifies that the IP protocol field of packets be changed in flight, to allow hiding of RSVP messages within a diffserv cloud, so that they will be ignored. This is viewed as a bad precedent, and a possible security problem. The security section of the document does not discuss the issue in any detail. Discussion: - Isn't this dealt with by RSVP integrity object? -- No, it's the IP header protocol field, not covered. - Why not just use a mechanism similar to the RSVP tunnel draft? -- (from draft author) This mechanism auto-configures to routing configuration better. Tunnel draft solves a somewhat different problem. - Is there a protocol fix? -- (from author) No obvious fix. Can reconsider. - Will the IESG buy a strong security statement with no other changes? -- (From Allison) Not clear, but can try. Conclusion: Authors of document will discuss possible technical changes. Will allow one month for this. If no promising changes are emerging, will draft a strong security statement discussing this issue, add to the current draft, and resubmit. *) Disucssion of Diffserv "Service Mapping" draft. This document is a listed work item on the WG charter, and two revisions have been drafted, but work has stalled recently. The purpose of the discussion was to determine if there was interest in restarting the work. Conclusions: - Significant interest. - Knowledge lies mostly with a small number of people (Anna Charny, Jim Roberts of France Telecom are high on the list). Need to get them involved if possible. - Document should reflect reality of use of current intserv services (G, CL) rather than exactly implementing the formal definitions from the RFC's. - May be appropriate to aim for BCP rather than informational. Not standards-track. Conclusion: Chairs will contact key people, outline a way to restart work on this. Meeting concludes.