Subject: ISSLL WG Meeting minutes, 50th IETF

From: John Wroclawski <[email-masked]>
Date: Mon, 16 Apr 2001 16:00:43 -0400

Minutes of the ISSLL WG Meeting
50th IETF - Minneapolis, MN.
Tuesday, March 20, 2001 13:00-14:00

ISSLL held a one-hour meeting at the 50th IETF. Issues related to several
Intserv/Diffserv documents were discussed.

* draft-ietf-issll-rsvp-aggr-03.txt

The chair gave a short summary of the status of this draft.  It was
submitted to the IESG for publication as a RFC months ago.  At the
December, 2000 WG meeting the cognizant AD (Allison Mankin) gave a short
presentation explaining the concerns, which focused around the draft's
requirement that the IP next-protocol field be altered as the packet
traveled through routers.  She suggesting that the concerns could be
resolved either through technical revision or through a more detailed
security concerns section.

After some discussion at the 49th IETF meeting and consideration among the
authors, a new security section was drafted and a revised version of the
document was submitted before the deadline for this meeting. No further
comments on the revised version have been received on the mailing list.

At the time of the WG meeting, the IESG was still reviewing this revised
version.

[Ed. after the meeting, the IESG approved publication of the draft, subject
only to some clarification of the IANA considerations section. That
clarification led to a -04 version draft being submitted. This version will
now go to the RFC editor.]

* draft-ietf-issll-rsvp-cap-02.txt

This draft defines the RSVP CAP object.  The -02 version of this draft,
incorporating previous comments, was submitted in February.  A key change
was removing most of the explanatory material into a separate document,
draft-hamid-issll-rsvp-cap-dsmark-00.txt, leaving this one as a standalone
spec.

Comments from the mailing list and the chairs identified several small
issues with this document. These points include:

1) Sections of the previous document that specified bit assignments were
incorrectly removed to the explanatory document. Bit assignments should be
part of the standard, not the explanation

2) The document presently implies that each capability will only require
one bit. There is no reason that this need be true, and the limitation is
not needed.

3) Message processing rule descriptions need to be either completely
generic or specified per-capability, rather than in a general section.

The author of the draft was unable to attend the meeting.  In his absense,
the chairs proposed revising the document to address these issues by a)
editing the present definition of the CAP object itself to include only
generic (not per-capability) information and to not limit the definition
of a particular capability, and b) adding new sections for each defined
capability, giving bit assignments and message processing rules for that
capability. The intent is that new revisions of the document would be
issued if and when new capabilities are defined.

A brief discussion did not reveal any objections to this approach from
meeting attendees.  The chairs will draft a note to the mailing list and
forward comments to the draft author.

* draft-ietf-issll-ds-map-01.txt

[Ed. The chairs note that one of them is also an author of the current
version of this draft.]

This is the "service mapping" draft, which gives advice about using
diffserv technologies to cause a DS cloud to effectively emulate an
intserv "network element" and thus play a part in an intserv end-to-end QoS
path.

The current version of the document was written some time ago and has not
been modified in any significant way in some time.  However, in the view of
the authors, it is missing some important sections and thus is still work
in progress. At this meeting, the chairs raised the question of whether to
continue work on the document, and if so, what path forward would be most
useful:

Specifically, the chair raised three questions as a starting point for
discussion.

1: Is the document, either as it stands or as it might stand, useful?

2: Present practice is to implement and use the defined intserv services,
particularly Guaranteed, in ways that do not completely match the RFC
definitions.  Should the document focus on mapping diffserv to the defined
services, or to some approximation of these services that is emerging from
current practice? If so, should we attempt to write down these
approximations, either in this document or in a separate one?

3: One specific technical area that is not addressed in the current
document is statistical approximations of G-like services. (CL is already
defined in this way). Should the document specifically attempt to capture
the current state of knowledge in this area, even though that knowledge is
evolving fast?

A vigorous discussion ensued. The results of this discussion can be
summarised as:

1) There was substantial concensus in the meeting that the document is
useful and should be completed.  Some speakers expressed the opinion that
the document is useful as it stands now, and should be published as is even
if no further technical work is done.

2) There was substantial concensus in the meeting that the document should
focus on implementing the intserv services as they are actually being
used, rather than strictly following the RFC definition.

3) There was substantial concensus that it would be useful to crisply
document the assumptions and approximations made by current implementations
of the intserv services, as a starting point for doing the above. The
question of whether this should be a separate document or a section of the
mapping draft was left open.

4) Some speakers suggested that the intserv service definitions themselves
were subject to misunderstandings that led to problems.  A document or
section of the current draft discussing these issues was suggested.

5) There was an extended discussion of whether it would be useful to define
one or more new IntServ services with definitions that captured what people
perceive as the current requirements for VoIP. The meeting was more or less
evenly split on this topic, with several speakers arguing for a new service
at the Intserv level and several others arguing that appropriate selection,
implementation and approximation of the existing services in different
environments is a simpler and adequate approach.  A complicating factor in
this discussion was point 4, above, which raised the possibility that some
concerns about the current specs were based on interpretation of the spec
document rather than technical unsuitability.

Based on this discussion, and followup discussions with the document
authors and people that expressed interest in the meeting, the chairs will
draft a proposal for revising this I-D and forward it to the mailing list
for discussion as soon as practical.