[NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1

Marcus Brunner <brunner@ccrle.nec.de> Wed, 23 July 2003 16:29 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18965 for <nsis-archive@odin.ietf.org>; Wed, 23 Jul 2003 12:29:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMU9-0001lh-Me for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:29:01 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NGT1jV006771 for nsis-archive@odin.ietf.org; Wed, 23 Jul 2003 12:29:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMU9-0001l6-2Y; Wed, 23 Jul 2003 12:29:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fMU0-0001ku-3A for nsis@optimus.ietf.org; Wed, 23 Jul 2003 12:28:52 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18948 for <nsis@ietf.org>; Wed, 23 Jul 2003 12:28:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fMTy-000606-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:28:50 -0400
Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19fMTn-000600-00 for nsis@ietf.org; Wed, 23 Jul 2003 12:28:39 -0400
Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NGRlVI013413; Wed, 23 Jul 2003 18:27:48 +0200 (CEST)
Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F06594D481; Wed, 23 Jul 2003 18:07:52 +0200 (CEST)
Date: Wed, 23 Jul 2003 18:27:47 +0200
From: Marcus Brunner <brunner@ccrle.nec.de>
Reply-To: Marcus Brunner <brunner@ccrle.nec.de>
To: mankin@psg.com, harald@alvestrand.no
Cc: john.loughney@nokia.com, nsis@ietf.org
Message-ID: <29712564.1058984867@[10.1.1.130]>
In-Reply-To: <E19Vktk-000Obw-9I@psg.com>
References: <E19Vktk-000Obw-9I@psg.com>
X-Mailer: Mulberry/3.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Subject: [NSIS] Re: IESG Review of draft-ietf-nsis-req-08.txt - Comments 1
Sender: nsis-admin@ietf.org
Errors-To: nsis-admin@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

See comments inline.

--On Donnerstag, 26. Juni 2003 21:31 -0700 Allison Mankin <mankin@psg.com> 
wrote:

> The IESG reviewed the NSIS Requirements.  There was some concern over
> the readability.  In addition, there were a few technical comments that
> should be addressed.  Here are Harald Alvestrand's.
>
> Allison
>
> ------- Forwarded Message
>
>
> Date: Thu, 26 Jun 2003 08:35:22 -0700
> From: Harald Tveit Alvestrand <harald@alvestrand.no>
> To: iesg@ietf.org
> Subject: A couple of comments on draft-ietf-nsis-req
>
>
> This section, from the start of section 5, worries me:
>
>
>    The parts of the networks we differentiate are the host-to-first
>    router, the access network, and the core network. The host to first
>    router part includes all the layer 2 technologies to access to the
>    Internet. This part of the division is especially informal and may
>    incorporate several access segments. In many cases, there is an
>    application and/or user running on the host initiating signaling.
>    The access network can be characterized by low capacity links,
>    medium speed IP processing capabilities, and it might consist of a
>    complete layer 2 network as well. The core network characteristics
>    include high-speed forwarding capacities and inter-domain issues.
>    These divisions between network types are not strict and do not
>    appear in all networks, but where they do exist they may influence
>    signaling requirements and will be highlighted as necessary.
>
> First of all, the grammar is sufficiently convoluted that I have problems
> parsing it.
>
> Second, I have definitional problems.
>
> I have problems imagining how an access network can work if it does NOT
> contain a "complete layer 2 network" - after all, a link is, in its way,
> a  layer 2 network. OTOH, I don't think GSM/GPRS can fairly be called a
> "layer  2 network" - it's more complex than that - but it's definitely
> being used  as an access network.
>
> The sentence "host to first router part includes all the layer 2
> technologies to access to the Internet" does not parse, and makes the
> definition only make sense when the first router is connected to the
> Internet - I don't think that was intended.
>
> Since this paragraph is key to the overall architectural constraints, I
> think it's rather important to make it crystal clear.
>

Actually, I don't think the paragraph is that much a key to the whole 
architecture. However in the consensus finding phase it help to make a 
number of people happy. It has been heavily discussed during the lifetime 
of the draft, therefore it went grammatically wrong. At this point in time, 
I think that the whole paragraph can be removed.

Anybody objecting to this?


> Section 5.5.1 on scalability worries me a lot, because it uses "scalable"
> without referring to a scale; while it may be appropriate to "scale" an
> end-system-to-first-router protocol to 10.000 users and say "good
> enough",  I think core routers have scalability requirements to millions
> of active  participants (which argues for them not having to see their
> state....)
>
> I would like to see some hand-wringing here like:
>
> "The NSIS protocols MUST be scalable up to the level of ubiquity - that
> is,  if every end-user on the network uses NSIS functions, the system
> MUST NOT  be brought to a catastrophic failure, but continue to give
> service  appropriate to the resources available."
>
> There might be more than this, but this is at least worrying.....

I understand the worry, but your proposal does at least for me not say 
something different that what is stated in the draft. Some people regarded 
the requirement as motherhood and apple pie anyway.

Actually, what I think you are referring to is the robustness of the 
system, where as salability is concerned more with the performance of it.

Somebody from the WG has an idea how to resolve that?

Marcus

--------------------------------------
Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: brunner@ccrle.nec.de
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus





_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis