[Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Thu, 15 January 2009 08:22 UTC

Return-Path: <tsvwg-bounces@ietf.org>
X-Original-To: tsvwg-archive@optimus.ietf.org
Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1363A6839; Thu, 15 Jan 2009 00:22:48 -0800 (PST)
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C6A3A67D6 for <tsvwg@core3.amsl.com>; Thu, 15 Jan 2009 00:22:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.694
X-Spam-Level:
X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_05=-1.11]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4YjrRZcgDIh for <tsvwg@core3.amsl.com>; Thu, 15 Jan 2009 00:22:46 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 98A303A6839 for <tsvwg@ietf.org>; Thu, 15 Jan 2009 00:22:45 -0800 (PST)
Received: (qmail invoked by alias); 15 Jan 2009 08:22:29 -0000
Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp024) with SMTP; 15 Jan 2009 09:22:29 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18REMcGqB4R2IiSci2Hfr60GuGkRwBTrhdB8nEmPv +kwmjUOrMOjL2n
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: tsvwg@ietf.org
Date: Thu, 15 Jan 2009 10:24:21 +0200
Message-ID: <001701c976ea$ab75aad0$80b5b70a@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: Acl26qph0wBcJ3qqQWeFAXcqVAXFMQ==
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.59
Subject: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org

By coincident I ran into the following draft: 
http://tools.ietf.org/html/draft-ietf-tsvwg-admitted-realtime-dscp-05

Section 2.3 says: 

"
   On the point of what protocols and procedures are required for
   authentication, authorization, and capacity admission, we note that
   clear standards do not at this time exist for bandwidth brokers, NSIS
   has not at this time been finalized and in any event is limited to
   unicast sessions, and that RSVP has been standardized and has the
   relevant services.  We therefore recommend the use of RSVP at the
   UNI.  Procedures at the NNI are business matters to be discussed
   between the relevant networks, and are recommended but not required.
"

and the IANA consideration section says:

"
   This traffic class requires the use of capacity admission such as
   RSVP services together with AAA services at the User/Network
   Interface (UNI); the use of such services at the NNI is at the option
   of the interconnected networks.
"

The text (to me) sounds like that this DSCP essentially requires RSVP to be
implemented in order to get this to work. This is IMHO not correct. 

To give you one other example of a standardized mechanism that would do the
job: Rx/Gx (3GPP)

Ciao
Hannes