Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21

"Georgios Karagiannis" <karagian@cs.utwente.nl> Sat, 24 October 2009 07:33 UTC

Return-Path: <karagian@cs.utwente.nl>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8927A3A68A5 for <nsis@core3.amsl.com>; Sat, 24 Oct 2009 00:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.005
X-Spam-Level: *
X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227]
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 3CLYtWZqHxPT for <nsis@core3.amsl.com>; Sat, 24 Oct 2009 00:33:54 -0700 (PDT)
Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 985103A67AA for <nsis@ietf.org>; Sat, 24 Oct 2009 00:33:54 -0700 (PDT)
Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n9O7XuwB008954; Sat, 24 Oct 2009 09:33:57 +0200 (MEST)
Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 24 Oct 2009 07:33:56 +0000
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Gerald Ash <gash5107@yahoo.com>
Date: Sat, 24 Oct 2009 07:33:55 +0000
X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl)
Message-ID: <ng9VWQuf.1256369635.9685840.karagian@ewi.utwente.nl>
In-Reply-To: <4AE176DD.2020007@ericsson.com>
From: Georgios Karagiannis <karagian@cs.utwente.nl>
Bounce-To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
Errors-To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5
Cc: NSIS <nsis@ietf.org>, David Black <black_david@emc.com>, "draft-ietf-nsis-qspec@tools.ietf.org" <draft-ietf-nsis-qspec@tools.ietf.org>
Subject: Re: [NSIS] AD comments on draft-ietf-nsis-qspec-21
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Oct 2009 07:33:55 -0000

Hi Magnus

Regarding comment 11:
>>> 11. This may seem out of context but I do want to know the answer to how
>>> the situation is handled when QNI and QNR are neighbors on a non QoS
>>> enabled network.
>>  
>> What "situation" are you referring to here?  IMO you can't have a QNI
>> and QNR in a "non QoS enabled network".  By definition, a QNI and QNR
>> are only defined in an NSIS enabled network (i.e., a QoS enabled network).
>
>I am asking what is happening in these cases where a QNI has the QNR as
>peer and there are no network support. Clearly you will not get any QoS,
>but is it clear to both QNI and QNR that this is the situation?
>

I think that the solution for this situation is provided by QoS-NSLP. In
particular, this situation is detected by uing the generic flag BREAK
(B), see Section 5.1.1 Common header, in the QoS-NSLP draft, see below:

BREAK (B) - when set, indicates that there are routers along the path
where QoS cannot be provided.

Maybe it will be good to add a sentence in the QSPEC draft that
emphasizes."

"As specified in QoS-NSLP, when there are routers along the path between
QNI and QNR where QoS cannot be provided then the QoS-NSLP generic flag
BREAK (B) is set."

Best regards,
Georgios