Re: Hard questions (was: Diffserv PIB approved as Informational RFC)

Brian E Carpenter wrote:

> Dan Grossman wrote:
> >
> > We _already_ have service definitions ( RFC 2211 and RFC 2212).  A small number of
> > additional ones  would be useful, but I agree that a signalling WG is not the place to be
> > defining them.
> >
> > My point was that the Diffserv work is complete enough to confuse the innocent,  but not
> > complete enough to be useful.     We have not defined any end-to-end (or even edge-to-edge)
> > services... er.... behaviors, much less the complete set of mechanisms to offer them or
> > even a sound architectural framework.  I don't think that NSIS can or should be expected to
> > resolve all that.
>
> That is really work for a trade association, not for the IETF, imho.

Perhaps you'd care to point out where in RFC2026, or RFC 2418 or in any IESG position statement
there is a statement that the IETF will defer technical work to a trade association?  Especially
since the Diffserv WG had consensus to start work on PDBs (after  jumping through hoops to throw
off this canard that such work is non-technical),  published several necessary-but-not-sufficient
RFCs on mechanism to support PDBs, and did the easy part of an architecture framework.   Do you
have a trade association in mind?   And if you do, why do you feel that they are more qualified
than the IETF to address the hard questions that the Diffserv working group chose not to address?

>
>
> >
> > There may be some cause for hope that the NSIS work will ultimately provide much of the
> > needed mechanism to allow capacity reservation.
>
> You're begging the question of whether that is an appropriate mechanism for the Internet.

I believe that that is in NSIS' charter.  And in any event, this is a tired debate.  There is a
significant portion of the community (not necessarily tier-1 ISPs) that does believe in bandwidth
reservations to support telephony and multimedia services.

>
>
> > It may even fill in some of the nagging
> > holes in the Diffserv architecture (for example, the ability to nail a path,
>
> Again, begging the question.

As was pointed out many years ago in the framework draft, nailed up paths are a necessary
mechanism for supporting QoS guarantees.  I am mildly hopeful that NSIS will provide that bit of
machinery in their protocols.

>
>
> > mechanisms to
> > manage DSCP mappings between DS domains,
>
> Again, trade association work.

So RFC2836 (which is necessary but not sufficient to the solution to the problem) should have
been done by a trade association?   Again, I'm mildly hopeful that the NSIS protocol(s) will
prove helpful in this regard.

>
>
> > and ability to discover what services... er...
> > PDBs...  might be available between two or more hosts).
>
> Unclear that this is soluble even in principle.

I'm personally not sure whether this is a routing problem or a signalling problem or both, but am
sure that there is at least one (albeit perhaps sub-optimal) solution.

>
>
> Hence, it's my view that there is no work item that is both mature
> enough and suitable for IETF action.

Unfortunately, none of the Diffserv RFCs are Experimental, which says that the group claims a
degree of maturity for them.  Equally unfortunately, they are at best necessary but not
sufficient to actually providing useful services, even within a Diffserv domain, much less
between domains.  Worse, there is a perception -- which neither the Diffserv working group nor
the IESG has acted to counter -- that they actually are sufficient to do anything useful.   This,
IMHO, has been a disservice to the community.




_______________________________________________
diffserv mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html