Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16

Roland Bless <bless@tm.uka.de> Tue, 13 October 2009 11:26 UTC

Return-Path: <bless@tm.uka.de>
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 2DEDA28C13F for <nsis@core3.amsl.com>; Tue, 13 Oct 2009 04:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 todsy5ZjNa-5 for <nsis@core3.amsl.com>; Tue, 13 Oct 2009 04:26:32 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 18C0D28C0E7 for <nsis@ietf.org>; Tue, 13 Oct 2009 04:26:32 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1MxfWK-0004cu-UD; Tue, 13 Oct 2009 13:26:31 +0200
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1MxfWK-0004bw-PD; Tue, 13 Oct 2009 13:26:24 +0200
Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B477D2FC00A; Tue, 13 Oct 2009 13:26:24 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 9B4511016B; Tue, 13 Oct 2009 13:26:24 +0200 (CEST)
Message-ID: <4AD463E0.8040304@tm.uka.de>
Date: Tue, 13 Oct 2009 13:26:24 +0200
From: Roland Bless <bless@tm.uka.de>
Organization: Institute of Telematics, University of Karlsruhe
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: Jukka Manner <jukka.manner@tkk.fi>
References: <4AC4B492.6070005@ericsson.com> <2727_1254489827_ZZ0KQW00H2R2JM5Q.00_4AC5FEBD.2030701@tm.uka.de> <4ACCE8A7.7050408@tkk.fi>
In-Reply-To: <4ACCE8A7.7050408@tkk.fi>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1255433191.778174000
Cc: draft-ietf-nsis-qos-nslp@tools.ietf.org, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] AD review comments of draft-ietf-nsis-qos-nslp-16
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: Tue, 13 Oct 2009 11:26:33 -0000

Hi Jukka,

Jukka Manner wrote:
> Hi Roland, thanks for the note, we'll fix this one, too.

I have additional comments you might consider, mainly
for consistency and clarification:

A) Multiple Upstream RSNs
Sec 5.2.1 State Manipulation:
RSN from the upstream peer
=> One must allow for keeping multiple RSNs from different upstream
   peers

   Reasoning: this is along the same line as the reasoning for keeping
   multiple Flow IDs in case of mobility. Usually if R=1 (Replace Flag)
   is set, you only need to consider one RSN for an upstream peer, but
   if R=0, you will usually simply dismiss the RESERVE from the new
   upstream peer in most cases. The new peer however, cannot know which
   is the latest valid RSN that was used with the previous peer.

It's not clear to me whether this will also affect the interface in
A.1. I cannot find any SII-Handle which could be used as qualifier
for the RSN.

B) Receiver-initiated reservations:
Sec. 3.2.12, p.20:
"If routing changes in the middle of the path, the QNE that notices
that its downstream path changed, the divergence point, ..."
change to:
"If routing changes in the middle of the path, the QNE that notices
that its downstream path changed (indicated by a NetworkNotification
from GIST), the divergence point, ..."

I didn't find any text that states anything about repeating the
QUERY message. State refreshes are performed by sending RESERVE
messages upstream. So basically it is not necessary to repeat
the QUERY from the sender in order to detect route changes,
since GIST probing will discover the route change even without
the QoS NLSP QUERY sent by the sender. This is a difference to
RSVP for example, where the PATH message was periodically
repeated, too.

Thus I'd like to propose adding clarifying text at the
end of sec. 4.3:
As GIST will indicate re-routing events by NetworkNotification,
it is not necessary to periodically repeat the QUERY message
for route change detection (cf. Sec 3.2.12).

more NITS:
----------
There is a typo on p.91:
"   o  authorization_info: the AUTHO_SESSION object"
=>
"   o  authorization_info: the AUTH_SESSION object"

and p. 77: spacing:
   stateful QoS NSLP QNE receives a QUERY message with the RESERVE- INIT
=>
   stateful QoS NSLP QNE receives a QUERY message with the RESERVE-INIT

Regards,
 Roland