From exim@www1.ietf.org  Tue Sep  2 07:22:44 2003
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 HAA11781
	for <nsis-archive@odin.ietf.org>; Tue, 2 Sep 2003 07:22:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19u6SZ-0002OS-Fl
	for nsis-archive@odin.ietf.org; Tue, 02 Sep 2003 04:24:19 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h828OIZ5009159
	for nsis-archive@odin.ietf.org; Tue, 2 Sep 2003 04:24:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19u587-0006C5-NQ; Tue, 02 Sep 2003 02:59:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19u1Mo-0003BC-C1
	for nsis@optimus.ietf.org; Mon, 01 Sep 2003 22:58:02 -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 WAA04168
	for <nsis@ietf.org>; Mon, 1 Sep 2003 22:57:54 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19u1Mi-0004nY-00
	for nsis@ietf.org; Mon, 01 Sep 2003 22:57:57 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
	by ietf-mx with esmtp (Exim 4.12)
	id 19tlYT-0000Ou-00
	for nsis@ietf.org; Mon, 01 Sep 2003 06:05:01 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <QY19YBT0>; Mon, 1 Sep 2003 11:04:28 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A7093850A@rsys004a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Jukka MJ Manner'" <jmanner@cs.Helsinki.FI>, nsis@ietf.org
Subject: RE: [NSIS] RE: Crossover node discovery issue
Date: Mon, 1 Sep 2003 11:04:29 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-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>

hi jukka,

i think i agree that an important attribute of the
crossover node is that it is a node storing some
signalling application state (not just any signalling-
aware node). this is another reason why dealing with
crossover node issues (generally, mobility issues)
would have to be handled in NSLPs rather than 
in the NTLP (at least, that's what I think).

this leaves open some interesting questions about
how to deal with the nsis equivalent of 'local repair'.
suppose a node is monitoring routing state to detect
route-change events in order to react to them more
quickly than waiting on periodic refreshes. if that 
node isn't itself managing the signalling application
state, should it attempt to tell the nodes which are
that something has changed?

r.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]
> Sent: Monday, September 01, 2003 05:53
> To: nsis@ietf.org
> Cc: Hancock, Robert
> Subject: Re: [NSIS] RE: Crossover node discovery issue
> 
> 
> 
> (retry 1, first post was rejected...?)
> 
> Hi,
> 
> about the definition of x-over router, following an RSVP-style of 
> definition, the cross-over router would be defined (only?) mainly for 
> situations where a new session id/state is being established. 
> At least for 
> RSVP, the cross-over router is only meaningful when a router 
> receives a 
> Path message and notices that an existing PSB (almost) matches the 
> incoming message, but in incoming interface differs. Thus, 
> for NSIS, this 
> would be something along "the NSLP aware node which, for a 
> given incoming 
> new session establishment (or session change request) from interface 
> newIF, already has the session information stored on one or 
> more different 
> incoming interfaces. In other words, the newly arrived 
> message identifies 
> a new incoming interface for an existing session." (change 
> "interface" 
> for "NE", if you like).
> 
> Regards,
> Jukka
> 

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



From exim@www1.ietf.org  Tue Sep  2 09:14:03 2003
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 JAA20200
	for <nsis-archive@odin.ietf.org>; Tue, 2 Sep 2003 09:14:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19u6ec-0003pC-3i
	for nsis-archive@odin.ietf.org; Tue, 02 Sep 2003 04:36:46 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h828ah6L014663
	for nsis-archive@odin.ietf.org; Tue, 2 Sep 2003 04:36:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19u56p-0005vD-Fz; Tue, 02 Sep 2003 02:57:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19u1Xy-0004c6-Br
	for nsis@optimus.ietf.org; Mon, 01 Sep 2003 23:09:34 -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 XAA06909
	for <nsis@ietf.org>; Mon, 1 Sep 2003 23:09:26 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19u1Xt-0007eU-00
	for nsis@ietf.org; Mon, 01 Sep 2003 23:09:29 -0400
Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi)
	by ietf-mx with esmtp (Exim 4.12)
	id 19tggC-0002Zm-00
	for nsis@ietf.org; Mon, 01 Sep 2003 00:52:41 -0400
Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173])
  (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA)
  by mail.cs.helsinki.fi with esmtp; Mon, 01 Sep 2003 07:52:41 +0300
Date: Mon, 1 Sep 2003 07:52:40 +0300 (EEST)
From: Jukka MJ Manner <jmanner@cs.Helsinki.FI>
To: nsis@ietf.org
cc: "Hancock, Robert" <robert.hancock@roke.co.uk>
Subject: Re: [NSIS] RE: Crossover node discovery issue
Message-ID: <Pine.LNX.4.44.0309010751420.16214-100000@mannersaari.cs.Helsinki.FI>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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


(retry 1, first post was rejected...?)

Hi,

about the definition of x-over router, following an RSVP-style of 
definition, the cross-over router would be defined (only?) mainly for 
situations where a new session id/state is being established. At least for 
RSVP, the cross-over router is only meaningful when a router receives a 
Path message and notices that an existing PSB (almost) matches the 
incoming message, but in incoming interface differs. Thus, for NSIS, this 
would be something along "the NSLP aware node which, for a given incoming 
new session establishment (or session change request) from interface 
newIF, already has the session information stored on one or more different 
incoming interfaces. In other words, the newly arrived message identifies 
a new incoming interface for an existing session." (change "interface" 
for "NE", if you like).

Regards,
Jukka


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



From exim@www1.ietf.org  Tue Sep  2 17:36:33 2003
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 RAA09523
	for <nsis-archive@odin.ietf.org>; Tue, 2 Sep 2003 17:36:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uIoo-0001ou-Ii
	for nsis-archive@odin.ietf.org; Tue, 02 Sep 2003 17:36:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h82La63H006990
	for nsis-archive@odin.ietf.org; Tue, 2 Sep 2003 17:36:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uIoi-0001oH-UM; Tue, 02 Sep 2003 17:36:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uIoV-0001kE-Iy
	for nsis@optimus.ietf.org; Tue, 02 Sep 2003 17:35:48 -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 RAA09388
	for <nsis@ietf.org>; Tue, 2 Sep 2003 17:35:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19uIoS-0000H8-00
	for nsis@ietf.org; Tue, 02 Sep 2003 17:35:44 -0400
Received: from chicory.cc.columbia.edu ([128.59.59.211] ident=cu41754)
	by ietf-mx with esmtp (Exim 4.12)
	id 19uIoR-0000H1-00
	for nsis@ietf.org; Tue, 02 Sep 2003 17:35:43 -0400
Received: from president (dyn-fair-240-205.dyn.columbia.edu [160.39.240.205])
	(user=qs2005 mech=LOGIN bits=0)
	by chicory.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h82LZb4F029598
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 2 Sep 2003 17:35:37 -0400 (EDT)
From: "Charles Q. Shen" <charles@ee.columbia.edu>
To: "'Hancock, Robert'" <robert.hancock@roke.co.uk>,
        "'Jukka MJ Manner'" <jmanner@cs.Helsinki.FI>, <nsis@ietf.org>
Subject: RE: [NSIS] RE: Crossover node discovery issue
Date: Tue, 2 Sep 2003 17:35:33 -0400
Organization: Columbia University
Message-ID: <000d01c3719a$23dc7aa0$cdf027a0@president>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
In-Reply-To: <EA943CD30BCB104E9D38F5B5DC2D9A7093850A@rsys004a.roke.co.uk>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.35
Content-Transfer-Encoding: 7bit
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

Hi Robert and Jukka,

That's indeed a very interesting problem as a result of the layer split.
I tend to look at it as mainly containing two separate but closely
related cases, 

    I ) Routing change (caused by various reasons, load balancing, node
failure ..., usually inside the network ) 
    II) Host address change (typically caused by mobililty, usually at
network edge)

It looks pretty reasonable to me that the first case should be taken
care of by NTLP first. However, this low level change could also affect
specific NSLPs. There are at least two possibilies then, a) give NTLP
knowledge about whether there is related NSLP in the same node, so it
can deliver the route change signal as appropriate. b) otherwise, with
no knowlege of specific NSLP at the node, NTLP may optionally signal to
the upper layer (as a fast recovery enhancement).  

In the second case, I feel it is preferable to have the NSLP handle it.
NTLP may or may not be directly involved. One question here is probably
how the Mobility machanism exactly interacts with NSIS, through NTLP or
NSLP or both?

There could be cases that sits somewhere in between the above two cases
that need further consideration, e.g., in FMIP or HMIP.

Finally, I agree upon the high level view of the Cross-over router you
mentioned. A detailed look may need to differentiate upstream/downstream
Cross-over routers and the way they are identified etc

Best regards,

Charles 

> -----Original Message-----
> From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On 
> Behalf Of Hancock, Robert
> Sent: Monday, September 01, 2003 6:04 AM
> To: 'Jukka MJ Manner'; nsis@ietf.org
> Subject: RE: [NSIS] RE: Crossover node discovery issue
> 
> 
> hi jukka,
> 
> i think i agree that an important attribute of the
> crossover node is that it is a node storing some
> signalling application state (not just any signalling-
> aware node). this is another reason why dealing with
> crossover node issues (generally, mobility issues)
> would have to be handled in NSLPs rather than 
> in the NTLP (at least, that's what I think).
> 
> this leaves open some interesting questions about
> how to deal with the nsis equivalent of 'local repair'.
> suppose a node is monitoring routing state to detect 
> route-change events in order to react to them more quickly 
> than waiting on periodic refreshes. if that 
> node isn't itself managing the signalling application
> state, should it attempt to tell the nodes which are
> that something has changed?
> 
> r.
> 
> > -----Original Message-----
> > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]
> > Sent: Monday, September 01, 2003 05:53
> > To: nsis@ietf.org
> > Cc: Hancock, Robert
> > Subject: Re: [NSIS] RE: Crossover node discovery issue
> > 
> > 
> > 
> > (retry 1, first post was rejected...?)
> > 
> > Hi,
> > 
> > about the definition of x-over router, following an RSVP-style of
> > definition, the cross-over router would be defined (only?) 
> mainly for 
> > situations where a new session id/state is being established. 
> > At least for 
> > RSVP, the cross-over router is only meaningful when a router 
> > receives a 
> > Path message and notices that an existing PSB (almost) matches the 
> > incoming message, but in incoming interface differs. Thus, 
> > for NSIS, this 
> > would be something along "the NSLP aware node which, for a 
> > given incoming 
> > new session establishment (or session change request) from 
> interface 
> > newIF, already has the session information stored on one or 
> > more different 
> > incoming interfaces. In other words, the newly arrived 
> > message identifies 
> > a new incoming interface for an existing session." (change 
> > "interface" 
> > for "NE", if you like).
> > 
> > Regards,
> > Jukka
> > 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


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



From exim@www1.ietf.org  Wed Sep  3 23:07:29 2003
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 XAA29204
	for <nsis-archive@odin.ietf.org>; Wed, 3 Sep 2003 23:07:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ukSg-0003He-MK
	for nsis-archive@odin.ietf.org; Wed, 03 Sep 2003 23:07:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h843765m012615
	for nsis-archive@odin.ietf.org; Wed, 3 Sep 2003 23:07:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ukSb-0003FO-75; Wed, 03 Sep 2003 23:07:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19ugz9-0002EL-Hq
	for nsis@optimus.ietf.org; Wed, 03 Sep 2003 19:24:23 -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 TAA16239;
	Wed, 3 Sep 2003 19:24:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ugz7-000546-00; Wed, 03 Sep 2003 19:24:21 -0400
Received: from gamma.isi.edu ([128.9.144.145])
	by ietf-mx with esmtp (Exim 4.12)
	id 19ugz6-000543-00; Wed, 03 Sep 2003 19:24:20 -0400
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h83NOLN05960;
	Wed, 3 Sep 2003 16:24:21 -0700 (PDT)
Message-Id: <200309032324.h83NOLN05960@gamma.isi.edu>
To: IETF-Announce: ;
Cc: rfc-editor@rfc-editor.org, nsis@ietf.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 03 Sep 2003 16:24:20 -0700
Subject: [NSIS] RFC 3583 on Requirements of a Quality of Service (QoS) Solution for Mobile IP
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>


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3583

        Title:      Requirements of a Quality of Service (QoS)
                    Solution for Mobile IP
        Author(s):  H. Chaskar, Ed.
        Status:     Informational
        Date:       September 2003
        Mailbox:    hemant.chaskar@nokia.com
        Pages:      10
        Characters: 22541
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-nsis-qos-requirements-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3583.txt


Mobile IP ensures correct routing of packets to a mobile node as the
mobile node changes its point of attachment to the
Internet.  However, it is also required to provide proper Quality of
Service (QoS) forwarding treatment to the mobile node's packet stream
at the intermediate nodes in the network, so that QoS-sensitive IP
services can be supported over Mobile IP.  This document describes
requirements for an IP QoS mechanism for its satisfactory operation
with Mobile IP.

This document is a product of the Next Steps in Signaling Working
Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <030903162258.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3583

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3583.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <030903162258.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--

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



From exim@www1.ietf.org  Thu Sep  4 09:50:29 2003
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 JAA22627
	for <nsis-archive@odin.ietf.org>; Thu, 4 Sep 2003 09:50:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uuUt-0002ba-4u
	for nsis-archive@odin.ietf.org; Thu, 04 Sep 2003 09:50:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Do3HF009971
	for nsis-archive@odin.ietf.org; Thu, 4 Sep 2003 09:50:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uuUr-0002ac-OE; Thu, 04 Sep 2003 09:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uuTz-0002ZB-Il
	for nsis@optimus.ietf.org; Thu, 04 Sep 2003 09:49:07 -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 JAA22548
	for <nsis@ietf.org>; Thu, 4 Sep 2003 09:49:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19uuTx-00037a-00
	for nsis@ietf.org; Thu, 04 Sep 2003 09:49:05 -0400
Received: from mailing.unile.it ([193.204.77.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19uuTw-00037W-00
	for nsis@ietf.org; Thu, 04 Sep 2003 09:49:04 -0400
Received: from inwind.it ([193.204.86.126])
	by mailing.unile.it (8.11.7+Sun/8.11.6) with ESMTP id h84Dn2x23811
	for <nsis@ietf.org>; Thu, 4 Sep 2003 15:49:02 +0200 (CEST)
Date: Thu, 4 Sep 2003 15:50:27 +0200
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: multipart/alternative; boundary=Apple-Mail-4-624365080
From: Ivano De Luca <deluca.ivano@inwind.it>
To: nsis@ietf.org
Message-Id: <BD71250A-DEDE-11D7-94F0-000A95946ED6@inwind.it>
X-Mailer: Apple Mail (2.552)
Subject: [NSIS] Need Information
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>


--Apple-Mail-4-624365080
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi,
Is the draft-ietf-nsis-fw-03.txt
last update about nsis ?

Is there other material?

Thanx

Ivano

--Apple-Mail-4-624365080
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

Is the
<fontfamily><param>Courier</param><bigger>draft-ietf-nsis-fw-03.txt

last update about nsis ?


Is there other material?


Thanx


Ivano</bigger><smaller>

</smaller></fontfamily>
--Apple-Mail-4-624365080--


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



From exim@www1.ietf.org  Thu Sep  4 10:05:27 2003
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 KAA23805
	for <nsis-archive@odin.ietf.org>; Thu, 4 Sep 2003 10:05:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uujO-0003Qj-Vc
	for nsis-archive@odin.ietf.org; Thu, 04 Sep 2003 10:05:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h84E52NH013165
	for nsis-archive@odin.ietf.org; Thu, 4 Sep 2003 10:05:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uujO-0003QD-Et; Thu, 04 Sep 2003 10:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19uujD-0003Pj-T6
	for nsis@optimus.ietf.org; Thu, 04 Sep 2003 10:04:51 -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 KAA23697
	for <nsis@ietf.org>; Thu, 4 Sep 2003 10:04:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19uujB-0003Wg-00
	for nsis@ietf.org; Thu, 04 Sep 2003 10:04:49 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 19uujA-0003WH-00
	for nsis@ietf.org; Thu, 04 Sep 2003 10:04:49 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <SBMR7LTT>; Thu, 4 Sep 2003 15:04:16 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A7093852A@rsys004a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Ivano De Luca'" <deluca.ivano@inwind.it>, nsis@ietf.org
Subject: RE: [NSIS] Need Information
Date: Thu, 4 Sep 2003 15:04:15 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C372ED.6CEE40F8"
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>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C372ED.6CEE40F8
Content-Type: text/plain;
	charset="iso-8859-1"

hi ivano,
 
-03 is the latest framework version. a new version is in preparation - should be
out during september. but there's no reason not to comment on the current one!
 
robert h.

-----Original Message-----
From: Ivano De Luca [mailto:deluca.ivano@inwind.it]
Sent: Thursday, September 04, 2003 14:50
To: nsis@ietf.org
Subject: [NSIS] Need Information



Hi, 

Is the draft-ietf-nsis-fw-03.txt 

last update about nsis ? 


Is there other material? 


Thanx 


Ivano 


------_=_NextPart_001_01C372ED.6CEE40F8
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=570080214-04092003><FONT face=Arial color=#0000ff size=2>hi 
ivano,</FONT></SPAN></DIV>
<DIV><SPAN class=570080214-04092003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=570080214-04092003><FONT face=Arial color=#0000ff size=2>-03 is 
the latest framework version. a new version is in preparation - should 
be</FONT></SPAN></DIV>
<DIV><SPAN class=570080214-04092003><FONT face=Arial color=#0000ff size=2>out 
during september. but there's no reason not to comment on the current 
one!</FONT></SPAN></DIV>
<DIV><SPAN class=570080214-04092003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=570080214-04092003><FONT face=Arial color=#0000ff size=2>robert 
h.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Ivano De Luca 
  [mailto:deluca.ivano@inwind.it]<BR><B>Sent:</B> Thursday, September 04, 2003 
  14:50<BR><B>To:</B> nsis@ietf.org<BR><B>Subject:</B> [NSIS] Need 
  Information<BR><BR></FONT></DIV>
  <P>Hi, </P>
  <P>Is the <FONT face=Courier size=4>draft-ietf-nsis-fw-03.txt </FONT></P>
  <P><FONT face=Courier size=4>last update about nsis ? </FONT></P><BR>
  <P><FONT face=Courier size=4>Is there other material? </FONT></P><BR>
  <P><FONT face=Courier size=4>Thanx </FONT></P><BR>
  <P><FONT face=Courier size=4>Ivano</FONT><FONT face=Courier size=2> 
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C372ED.6CEE40F8--

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



From exim@www1.ietf.org  Fri Sep  5 07:48:09 2003
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 HAA15662
	for <nsis-archive@odin.ietf.org>; Fri, 5 Sep 2003 07:48:09 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vF42-0000JF-VM
	for nsis-archive@odin.ietf.org; Fri, 05 Sep 2003 07:47:43 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h85BlgXg001170
	for nsis-archive@odin.ietf.org; Fri, 5 Sep 2003 07:47:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vF3M-0000GW-MA; Fri, 05 Sep 2003 07:47:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vF27-0000FH-ET
	for nsis@optimus.ietf.org; Fri, 05 Sep 2003 07:46:03 -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 HAA15595
	for <nsis@ietf.org>; Fri, 5 Sep 2003 07:45:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19vF1w-0002sA-00
	for nsis@ietf.org; Fri, 05 Sep 2003 07:45:32 -0400
Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 19vF1W-0002rC-00
	for nsis@ietf.org; Fri, 05 Sep 2003 07:45:06 -0400
Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58])
  (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5)
  by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 05 Sep 2003 13:43:34 +0200
Message-ID: <3F58768B.9090508@cs.uni-goettingen.de>
Date: Fri, 05 Sep 2003 13:42:03 +0200
From: Xiaoming Fu <fu@cs.uni-goettingen.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: karagiannis <karagian@cs.utwente.nl>
CC: Roland Bless <bless@tm.uka.de>, nsis@ietf.org
Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft
References: <200307180954.h6I9sO622982@janus.cs.utwente.nl>
In-Reply-To: <200307180954.h6I9sO622982@janus.cs.utwente.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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

Georgios,

I just read your PFHSN paper and find it interesting. A few comments inline:

karagiannis wrote:
> 
> `Resource Management in Diffserv (RMD) [WeCs02] represents an edge to edge
> (intra-domain) QoS framework that extends the Diffserv principles with new
> ones necessary to providedynamic resource management and admission control
> in Diffserv domains.`

Perhaps "new ones" is not specific. IHMO dynamic resource management is 
not novel, e.g., RFC2998 specifies for both dynamic and statical ones. 
Do you mean the method for measurement-based (intra-domain) admission 
control for DiffServ?
> 
> `The number of required refresh messages in the RMD protocol is the same 
> as the number of required refresh messages in RSVP [RFC2205].` 
> 
Based on the same values of soft state timers?

Cheers,
Xiaoming


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



From exim@www1.ietf.org  Fri Sep  5 08:29:51 2003
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 IAA17170
	for <nsis-archive@odin.ietf.org>; Fri, 5 Sep 2003 08:29:51 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vFiQ-0001WQ-Al
	for nsis-archive@odin.ietf.org; Fri, 05 Sep 2003 08:29:26 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h85CTQ53005831
	for nsis-archive@odin.ietf.org; Fri, 5 Sep 2003 08:29:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vFi1-0001Rc-3x; Fri, 05 Sep 2003 08: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 19vFhd-0001RE-ND
	for nsis@optimus.ietf.org; Fri, 05 Sep 2003 08: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 IAA17102
	for <nsis@ietf.org>; Fri, 5 Sep 2003 08:28:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19vFhX-0003yb-00
	for nsis@ietf.org; Fri, 05 Sep 2003 08:28:31 -0400
Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 19vFh7-0003yK-00
	for nsis@ietf.org; Fri, 05 Sep 2003 08:28:05 -0400
Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58])
  (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5)
  by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 05 Sep 2003 14:28:05 +0200
Message-ID: <3F5880F9.6070103@cs.uni-goettingen.de>
Date: Fri, 05 Sep 2003 14:26:33 +0200
From: Xiaoming Fu <fu@cs.uni-goettingen.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Charles Q. Shen" <charles@ee.columbia.edu>
CC: "'Hancock, Robert'" <robert.hancock@roke.co.uk>,
        "'Jukka MJ Manner'" <jmanner@cs.Helsinki.FI>, nsis@ietf.org
Subject: Re: [NSIS] RE: Crossover node discovery issue
References: <000d01c3719a$23dc7aa0$cdf027a0@president>
In-Reply-To: <000d01c3719a$23dc7aa0$cdf027a0@president>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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

Hi Charles, Robert, Jukka & all,

Charles Q. Shen wrote:
> Hi Robert and Jukka,
> 
> That's indeed a very interesting problem as a result of the layer split.
> I tend to look at it as mainly containing two separate but closely
> related cases, 
> 
>     I ) Routing change (caused by various reasons, load balancing, node
> failure ..., usually inside the network ) 

Mobility can also cause route change, e.g., in home agent, or other 
localized mobility agents.

>     II) Host address change (typically caused by mobililty, usually at
> network edge)
> 
> It looks pretty reasonable to me that the first case should be taken
> care of by NTLP first. However, this low level change could also affect
> specific NSLPs. There are at least two possibilies then, a) give NTLP
> knowledge about whether there is related NSLP in the same node, so it
> can deliver the route change signal as appropriate. b) otherwise, with
> no knowlege of specific NSLP at the node, NTLP may optionally signal to
> the upper layer (as a fast recovery enhancement).  
> 
> In the second case, I feel it is preferable to have the NSLP handle it.
> NTLP may or may not be directly involved. One question here is probably
> how the Mobility machanism exactly interacts with NSIS, through NTLP or
> NSLP or both?

Good question. Probably it is necessary to know the changed address for 
NTLP. It would be helpful in some cases, e.g., to let the trigger of a 
local repair find out the actual route which the signaling message will 
follow. About local repair trigger - roughly there are several possible 
means (will be explained in detail in an upcoming short I-D):

a) through end-to-end soft state refresh (for both downstream & 
upstream: slow)
b) through refresh & x-router discovery due to a mobility-caused route 
change in CN or mobility agents (for downstream: fast) and MN (for 
upstream: fast)
c) through refresh due to a mobility-caused route change/address change 
in MN & MN-initiated discovery of x-router (for both downstream & 
upstream: fast but more complex).

My preference is b). As you also mentioned above, NTLP is involved in 
mobility anyway, it might make sense to have NSLP interfacing with NTLP 
for mobility info other than directly with mobility route change 
whatsoever; this can also be advantageous for clearing the 2-layer arch.
> 
> There could be cases that sits somewhere in between the above two cases
> that need further consideration, e.g., in FMIP or HMIP.

These localized mobility cases can re-apply the same scheme to MIP.

Cheers,
Xiaoming
> 
> Finally, I agree upon the high level view of the Cross-over router you
> mentioned. A detailed look may need to differentiate upstream/downstream
> Cross-over routers and the way they are identified etc
> Best regards,
> 
> Charles 
> 
> 
>>-----Original Message-----
>>From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org] On 
>>Behalf Of Hancock, Robert
>>Sent: Monday, September 01, 2003 6:04 AM
>>To: 'Jukka MJ Manner'; nsis@ietf.org
>>Subject: RE: [NSIS] RE: Crossover node discovery issue
>>
>>
>>hi jukka,
>>
>>i think i agree that an important attribute of the
>>crossover node is that it is a node storing some
>>signalling application state (not just any signalling-
>>aware node). this is another reason why dealing with
>>crossover node issues (generally, mobility issues)
>>would have to be handled in NSLPs rather than 
>>in the NTLP (at least, that's what I think).
>>
>>this leaves open some interesting questions about
>>how to deal with the nsis equivalent of 'local repair'.
>>suppose a node is monitoring routing state to detect 
>>route-change events in order to react to them more quickly 
>>than waiting on periodic refreshes. if that 
>>node isn't itself managing the signalling application
>>state, should it attempt to tell the nodes which are
>>that something has changed?
>>
>>r.
>>
>>
>>>-----Original Message-----
>>>From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]
>>>Sent: Monday, September 01, 2003 05:53
>>>To: nsis@ietf.org
>>>Cc: Hancock, Robert
>>>Subject: Re: [NSIS] RE: Crossover node discovery issue
>>>
>>>
>>>
>>>(retry 1, first post was rejected...?)
>>>
>>>Hi,
>>>
>>>about the definition of x-over router, following an RSVP-style of
>>>definition, the cross-over router would be defined (only?) 
>>
>>mainly for 
>>
>>>situations where a new session id/state is being established. 
>>>At least for 
>>>RSVP, the cross-over router is only meaningful when a router 
>>>receives a 
>>>Path message and notices that an existing PSB (almost) matches the 
>>>incoming message, but in incoming interface differs. Thus, 
>>>for NSIS, this 
>>>would be something along "the NSLP aware node which, for a 
>>>given incoming 
>>>new session establishment (or session change request) from 
>>
>>interface 
>>
>>>newIF, already has the session information stored on one or 
>>>more different 
>>>incoming interfaces. In other words, the newly arrived 
>>>message identifies 
>>>a new incoming interface for an existing session." (change 
>>>"interface" 
>>>for "NE", if you like).
>>>
>>>Regards,
>>>Jukka
>>>
>>
>>_______________________________________________
>>nsis mailing list
>>nsis@ietf.org
>>https://www1.ietf.org/mailman/listinfo/nsis


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



From exim@www1.ietf.org  Fri Sep  5 08:44:06 2003
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 IAA17751
	for <nsis-archive@odin.ietf.org>; Fri, 5 Sep 2003 08:44:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vFwE-00029k-0U
	for nsis-archive@odin.ietf.org; Fri, 05 Sep 2003 08:43:42 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Chf1T008269
	for nsis-archive@odin.ietf.org; Fri, 5 Sep 2003 08:43:41 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vFvZ-00025G-Jr; Fri, 05 Sep 2003 08:43:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19vFun-00024G-EI
	for nsis@optimus.ietf.org; Fri, 05 Sep 2003 08:42:13 -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 IAA17678
	for <nsis@ietf.org>; Fri, 5 Sep 2003 08:42:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19vFum-0004Om-00
	for nsis@ietf.org; Fri, 05 Sep 2003 08:42:12 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 19vFub-0004LN-00
	for nsis@ietf.org; Fri, 05 Sep 2003 08:42:01 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h85CdhRd007272;
	Fri, 5 Sep 2003 14:39:43 +0200 (MET DST)
Message-ID: <00aa01c373aa$c97071d0$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Xiaoming Fu" <fu@cs.uni-goettingen.de>
Cc: "Roland Bless" <bless@tm.uka.de>, <nsis@ietf.org>
References: <200307180954.h6I9sO622982@janus.cs.utwente.nl> <3F58768B.9090508@cs.uni-goettingen.de>
Subject: Re: [NSIS] input (over RMD) for NSIS Analysis draft
Date: Fri, 5 Sep 2003 14:39:45 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
Content-Transfer-Encoding: 7bit
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

Hi Xiaoming

Thank you very much for your comments!
Some answers in line:

> >
> > `Resource Management in Diffserv (RMD) [WeCs02] represents an edge to
edge
> > (intra-domain) QoS framework that extends the Diffserv principles with
new
> > ones necessary to providedynamic resource management and admission
control
> > in Diffserv domains.`
>
> Perhaps "new ones" is not specific. IHMO dynamic resource management is
> not novel, e.g., RFC2998 specifies for both dynamic and statical ones.
> Do you mean the method for measurement-based (intra-domain) admission
> control for DiffServ?

Dynamic resource management sches are not novel, but there are some
principles in the management scheme that we are using that are new.
The main one is the way of how the per traffic class aggregation
is performed.

> >
> > `The number of required refresh messages in the RMD protocol is the same
> > as the number of required refresh messages in RSVP [RFC2205].`
> >
> Based on the same values of soft state timers?

You are of course right.

>
> Cheers,
> Xiaoming
>

Best regards,
Georgios


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



From exim@www1.ietf.org  Fri Sep 12 09:42:31 2003
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 JAA21850
	for <nsis-archive@odin.ietf.org>; Fri, 12 Sep 2003 09:42:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19xoBd-0005ah-3K
	for nsis-archive@odin.ietf.org; Fri, 12 Sep 2003 09:42:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CDg9bA021464
	for nsis-archive@odin.ietf.org; Fri, 12 Sep 2003 09:42:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19xoBW-0005YH-Im; Fri, 12 Sep 2003 09:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19xoAs-0005Rv-CG
	for nsis@optimus.ietf.org; Fri, 12 Sep 2003 09:41:22 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21705;
	Fri, 12 Sep 2003 09:41:13 -0400 (EDT)
Message-Id: <200309121341.JAA21705@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: nsis@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 12 Sep 2003 09:41:13 -0400
Subject: [NSIS] I-D ACTION:draft-westberg-rmd-od-phr-04.txt
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Resource Management in Diffserv On DemAnd (RODA) PHR
	Author(s)	: L. Westberg
	Filename	: draft-westberg-rmd-od-phr-04.txt
	Pages		: 19
	Date		: 2003-9-12
	
The purpose of this draft is to present the Resource Management in
Diffserv (RMD) On DemAnd (RODA) Per Hop Reservation (PHR) protocol.
The RODA PHR protocol is used on a per-hop basis in a Differentiated
Services (Diffserv) domain and extends the Diffserv Per Hop Behavior
(PHB) with resource provisioning and control.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westberg-rmd-od-phr-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-westberg-rmd-od-phr-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-westberg-rmd-od-phr-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-9-12084510.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-westberg-rmd-od-phr-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-westberg-rmd-od-phr-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-9-12084510.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Fri Sep 12 09:42:31 2003
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 JAA21849
	for <nsis-archive@odin.ietf.org>; Fri, 12 Sep 2003 09:42:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19xoBd-0005ai-3Y
	for nsis-archive@odin.ietf.org; Fri, 12 Sep 2003 09:42:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CDg99D021469
	for nsis-archive@odin.ietf.org; Fri, 12 Sep 2003 09:42:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19xoBW-0005Y9-4g; Fri, 12 Sep 2003 09:42:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19xoAn-0005Ro-Fb
	for nsis@optimus.ietf.org; Fri, 12 Sep 2003 09:41:17 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21689;
	Fri, 12 Sep 2003 09:41:08 -0400 (EDT)
Message-Id: <200309121341.JAA21689@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: nsis@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 12 Sep 2003 09:41:08 -0400
Subject: [NSIS] I-D ACTION:draft-westberg-rmd-framework-04.txt
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Resource Management in Diffserv (RMD) Framework
	Author(s)	: L. Westberg
	Filename	: draft-westberg-rmd-framework-04.txt
	Pages		: 63
	Date		: 2003-9-12
	
This draft presents the work on the framework for the Resource
Management in Diffserv (RMD) designed for edge-to-edge resource
reservation in a Differentiated Services (Diffserv) domain.  The RMD
extends the Diffserv architecture with new resource reservation
concepts and features. Moreover, this framework enhances the Load
Control protocol described in [WeTu00].
The RMD framework defines two architectural concepts:
- the Per Hop Reservation (PHR)
- the Per Domain Reservation (PDR)
The PHR protocol is used within a Diffserv domain on a per-hop basis
to augment the Diffserv Per Hop Behavior (PHB) with resource
reservation. It is implemented in all nodes in a Diffserv domain. On
the other hand, the PDR protocol manages the resource reservation per
Diffserv domain, relying on the PHR resource reservation status in
all nodes.  The PDR is only implemented at the boundary of the domain
(at the edge nodes).
The RMD framework presented in this draft describes the new
reservation concepts and features. Furthermore it describes the:
- relationship between the PHR and PHB
- interaction between the PDR and PHR
- interoperability between the PDR and external resource
reservation schemes
This framework is an open framework in the sense that it provides the
basis for interoperability with other resource reservation schemes
and can be applied in different types of networks as long as they are
Diffserv domains. It aims at extreme simplicity and low cost of
implementation along with good scaling properties.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westberg-rmd-framework-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-westberg-rmd-framework-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-westberg-rmd-framework-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-9-12084459.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-westberg-rmd-framework-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-westberg-rmd-framework-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-9-12084459.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Mon Sep 15 11:16:31 2003
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 LAA06570
	for <nsis-archive@odin.ietf.org>; Mon, 15 Sep 2003 11:16:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19yv5D-0005I9-SI
	for nsis-archive@odin.ietf.org; Mon, 15 Sep 2003 11:16:08 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FFG7uT020321
	for nsis-archive@odin.ietf.org; Mon, 15 Sep 2003 11:16:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19yv57-0005Gb-Co; Mon, 15 Sep 2003 11:16:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19yv4I-0005Bl-Oh
	for nsis@optimus.ietf.org; Mon, 15 Sep 2003 11:15:10 -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 LAA06512
	for <nsis@ietf.org>; Mon, 15 Sep 2003 11:15:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19yv4H-0001WX-00
	for nsis@ietf.org; Mon, 15 Sep 2003 11:15:09 -0400
Received: from infres.enst.fr ([137.194.192.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19yv4H-0001WO-00
	for nsis@ietf.org; Mon, 15 Sep 2003 11:15:09 -0400
Received: from enst.fr (dragon.enst.fr [137.194.192.44])
	by infres.enst.fr (Postfix) with ESMTP id 1E73C1984
	for <nsis@ietf.org>; Mon, 15 Sep 2003 17:15:08 +0200 (MEST)
Message-ID: <3F65D6BA.87577060@enst.fr>
Date: Mon, 15 Sep 2003 17:11:54 +0200
From: Nguyen Thi Mai Trang <trnguyen@enst.fr>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: nsis@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [NSIS] comments on draft nsis-reqs-v9
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

Hello,

I read the draft of nsis-requirements-09 and have some comments:

- Section 5.7.5 (Hop-by-hop security) is not clearly explained. What is
"Channel security"? What does it mean "Channel security security needs
to be implemented"?  The use of "Security" has a too large meaning for
me.

- The word "layering" in the abstract is difficult to understand for me.
What is "layering"? while it is not explained in the document. Instead,
the document presents the requirements on Messaging and Control
Information. Do they mean "layering" ?

Regards,
Mai Trang


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



From exim@www1.ietf.org  Wed Sep 17 06:56:27 2003
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 GAA05095
	for <nsis-archive@odin.ietf.org>; Wed, 17 Sep 2003 06:56:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zZyh-0006pY-83
	for nsis-archive@odin.ietf.org; Wed, 17 Sep 2003 06:56:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HAu7R0026257
	for nsis-archive@odin.ietf.org; Wed, 17 Sep 2003 06:56:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zZyb-0006nt-PL; Wed, 17 Sep 2003 06:56:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zZyD-0006mL-9Y
	for nsis@optimus.ietf.org; Wed, 17 Sep 2003 06:55:37 -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 GAA04946
	for <nsis@ietf.org>; Wed, 17 Sep 2003 06:55:25 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19zZy7-00040V-00
	for nsis@ietf.org; Wed, 17 Sep 2003 06:55:31 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 19zZq3-0003y9-00
	for nsis@ietf.org; Wed, 17 Sep 2003 06:47:11 -0400
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h8HAlA125373
	for <nsis@ietf.org>; Wed, 17 Sep 2003 12:47:10 +0200 (MEST)
Received: from joe (corcert26.esn.sbs.de [149.246.220.26])
	by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h8HAl9Q03424
	for <nsis@ietf.org>; Wed, 17 Sep 2003 12:47:10 +0200 (MEST)
From: "Hannes Tschofenig" <Hannes.Tschofenig@siemens.com>
To: <nsis@ietf.org>
Date: Wed, 17 Sep 2003 12:47:07 +0200
Message-ID: <000101c37d09$0af9b320$010aa8c0@joe>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] Reliability and Security
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: quoted-printable

1. Introduction

During this year of work at the NSIS working group it was often argued =
that
the two layer split can lead to a signaling message communication as =
shown
in Figure 1 (see Figure 1 in [Han]). An NSIS message with "NSLP  A" =
content
is intercepted at nodes which do not understand the application specific
information (e.g. NE 2  which does not even implement any NSLP =
components or
NE 3 which implements a different NSLP).=20


               +------+    +------+    +------+    +------+=20
               |  NE1 |    |  NE2 |    |  NE3 |    |  NE4 |=20
               |+----+|    |      |    |+----+|    |+----+|=20
               ||NSLP||    |      |    ||NSLP||    ||NSLP||=20
               || A  ||    |      |    || B  ||    || A  ||=20
               |+----+|    |      |    |+----+|    |+----+|=20
               |  ||  |    |      |    |      |    |  ||  |=20
               |+----+|    |+----+|    |+----+|    |+----+|=20
           =
=3D=3D=3D=3D||NTLP||=3D=3D=3D=3D||NTLP||=3D=3D=3D=3D||NTLP||=3D=3D=3D=3D|=
|NTLP||=3D=3D=3D=3D=20
               |+----+|    |+----+|    |+----+|    |+----+|=20
               +------+    +------+    +------+    +------+=20
                                     =20
               Figure 1: Signaling with Heterogeneous NSLPs=20

This functionality is due to a lack of a discovery procedure whereby =
NSLP A
messages would only be  intercepted at NE 1 and NE 4. This does not =
sound
like a problem at the first place although some  performance issues have
been raised.=20

2. The Problem

The design decision to support such a signaling architecture leads to a
number of complications - two of  them are mentioned in this mail =
(possibly
there are more than those two).

a) Reliability

As discussed in [Han] it seems that the introduction of these NSLP =
unaware
nodes along the path together  with reliability (and other transport
protocol specific features) at the NTLP layer might not lead to  =
unexpected
results. It seems that some additional functionality has to be provided
between neighboring NSLP  peers. This introduces additional complexity =
which
is difficult to support with existing protocols.=20

b) Security

While discussing the possible security mechanisms at the NTLP and the =
NSLP
(for different applications; QoS  and NATFW) it seems to be obvious that
signaling messages need some sort of protection.=20

Securing messages at the NTLP allows to reuse existing mechanisms and to
benefit from established security  associations between neighboring NTLP =
(to
amotize authentication and key establishment). Similar to the  problem =
of
addressing reliabilty a question requestion regarding security has to be
raised:=20

Is the effect of securing multiple neighboring NTLP peers the same as
providing security between  neighboring NSLPs? (The same question can be
formulated with respect to reliability.)

With relationship to Figure 1 this means:=20

Is=20

     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3 <NTLP-Security> NE 4

the same as=20
     =20
     NE 1 <NSLP-Security> NE 4
?     =20

My perception is that it is not necessarily the same, as also argued in
[Han] concerning reliability.=20

If the working group thinks that this is not the same then it would be
necessary to provide additional  security between neighboring NSLP =
peers.=20

As a consequence a discovery mechanism is needed at the NSLP to learn =
the
next NSLP node along the path.  This is necessary to be able to secure
signaling messages efficiently (i.e. using symmetric cryptography).  =
Hence
avoiding the discovery procedure at the NTLP was not really beneficial.
Without efficient mechanism  it is likely that the mechanisms would not =
be
used at all.=20

Securing signaling messages at the NTLP and the NSLP might seem to be an
overkill to some people. Securing  signaling messages only at the NSLP =
layer
does not seem to be sufficient as recently discussed (see NSIS ML
discussion [NSIS-ML]).

3. Conclusion

This is a short summary and an attempt to ask some members of the =
working
group who have an opinion on  reliability to also raise their opinion on
security issues. =20

Furthermore, there is a question whether a more sophisticated discovery
mechanism (at the NTLP) should be  created to prevent or limit signaling
message effects as shown in Figure 1.

4. Reference

[Han] R. Hancock: "Reliability Functions in the NSIS Transport Layer
Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in =
progress),
August 2003

[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security thoughts, Date: =
Sun,
13 Jul 2003 14:47:51 +0200",  Available at:
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03106.ht=
ml,
(Sep. 2003).=20


ciao
Hannes


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



From exim@www1.ietf.org  Wed Sep 17 07:33:25 2003
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 HAA06717
	for <nsis-archive@odin.ietf.org>; Wed, 17 Sep 2003 07:33:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zaYP-0000K2-PU
	for nsis-archive@odin.ietf.org; Wed, 17 Sep 2003 07:33:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HBX1TI001236
	for nsis-archive@odin.ietf.org; Wed, 17 Sep 2003 07:33:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zaYP-0000JO-9h; Wed, 17 Sep 2003 07:33:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zaXj-0000If-JO
	for nsis@optimus.ietf.org; Wed, 17 Sep 2003 07:32:19 -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 HAA06679
	for <nsis@ietf.org>; Wed, 17 Sep 2003 07:32:12 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19zaXi-0004Y0-00
	for nsis@ietf.org; Wed, 17 Sep 2003 07:32:18 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 19zaXi-0004Xp-00
	for nsis@ietf.org; Wed, 17 Sep 2003 07:32:18 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 17 Sep 2003 13:31:43 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <S8ZTT5A4>; Wed, 17 Sep 2003 13:31:39 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB5E6@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: Hannes.Tschofenig@siemens.com, nsis@ietf.org
Subject: RE: [NSIS] Reliability and Security
Date: Wed, 17 Sep 2003 13:31:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>

Hello Hannes,

a few thoughts...

[snip]
|Is 
|
|     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3 
|<NTLP-Security> NE 4
|
|the same as 
|      
|     NE 1 <NSLP-Security> NE 4
|?      
|
|My perception is that it is not necessarily the same, as also argued in
|[Han] concerning reliability.

I share your view, this isn't the same. And your conclusion is correct:

|If the working group thinks that this is not the same then it would be
|necessary to provide additional security between neighboring 
|NSLP peers. 
|
|As a consequence a discovery mechanism is needed at the NSLP 
|to learn the next NSLP node along the path. This is necessary to be 
|able to secure signaling messages efficiently (i.e. using symmetric 
|cryptography). Hence avoiding the discovery procedure at the NTLP 
|was not really beneficial.
|Without efficient mechanism it is likely that the mechanisms 
|would not be used at all. 
|
|Securing signaling messages at the NTLP and the NSLP might 
|seem to be an overkill to some people. Securing  signaling messages only at 
|the NSLP layer
|does not seem to be sufficient as recently discussed (see NSIS ML
|discussion [NSIS-ML]).
|
|3. Conclusion
|
|This is a short summary and an attempt to ask some members of 
|the working
|group who have an opinion on  reliability to also raise their 
|opinion on
|security issues.  
|
|Furthermore, there is a question whether a more sophisticated discovery
|mechanism (at the NTLP) should be  created to prevent or limit 
|signaling
|message effects as shown in Figure 1.
|
|4. Reference
|
|[Han] R. Hancock: "Reliability Functions in the NSIS Transport Layer
|Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in 
|progress),
|August 2003
|
|[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security 
|thoughts, Date: Sun,
|13 Jul 2003 14:47:51 +0200",  Available at:
|http://www1.ietf.org/mail-archive/working-groups/nsis/current/m
|sg03106.html,
|(Sep. 2003). 
|
|
|ciao
|Hannes
|
|
|_______________________________________________
|nsis mailing list
|nsis@ietf.org
|https://www1.ietf.org/mailman/listinfo/nsis
|

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



From exim@www1.ietf.org  Wed Sep 17 08:01:35 2003
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 IAA07749
	for <nsis-archive@odin.ietf.org>; Wed, 17 Sep 2003 08:01:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zazg-0001zW-GN
	for nsis-archive@odin.ietf.org; Wed, 17 Sep 2003 08:01:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8HC1CoP007648
	for nsis-archive@odin.ietf.org; Wed, 17 Sep 2003 08:01:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zazV-0001ya-H8; Wed, 17 Sep 2003 08:01:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 19zaym-0001xK-Am
	for nsis@optimus.ietf.org; Wed, 17 Sep 2003 08:00:16 -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 IAA07706
	for <nsis@ietf.org>; Wed, 17 Sep 2003 08:00:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 19zayl-0004qP-00
	for nsis@ietf.org; Wed, 17 Sep 2003 08:00:15 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 19zayk-0004q6-00
	for nsis@ietf.org; Wed, 17 Sep 2003 08:00:14 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 17 Sep 2003 13:59:30 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <S8ZTT69Z>; Wed, 17 Sep 2003 13:59:24 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB5E7@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: Hannes.Tschofenig@siemens.com, nsis@ietf.org
Subject: RE: [NSIS] Reliability and Security
Date: Wed, 17 Sep 2003 13:59:20 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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>

Hello Hannes,

sorry, I've hit the wrong keys earlier. So I bother you again... 

[snip]
|Is 
|
|     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3 
|<NTLP-Security> NE 4
|
|the same as 
|      
|     NE 1 <NSLP-Security> NE 4
|?      
|
|My perception is that it is not necessarily the same, as also argued in
|[Han] concerning reliability.

I share your view, this isn't the same. And your conclusion is correct:

|If the working group thinks that this is not the same then it would be
|necessary to provide additional security between neighboring 
|NSLP peers. 
|
|As a consequence a discovery mechanism is needed at the NSLP 
|to learn the next NSLP node along the path. This is necessary to be 
|able to secure signaling messages efficiently (i.e. using symmetric 
|cryptography). Hence avoiding the discovery procedure at the NTLP 
|was not really beneficial.
|Without efficient mechanism it is likely that the mechanisms 
|would not be used at all. 
|
|Securing signaling messages at the NTLP and the NSLP might 
|seem to be an overkill to some people. Securing  signaling messages 
|only at the NSLP layer does not seem to be sufficient as recently 
|discussed (see NSIS ML discussion [NSIS-ML]).

Looks as if there's no solution for having a flexible architecture 
combined with security across NTLP and NSLP.

I don't think that we must protect NSLP messages. To protect 
against "simple" NSLP DoS attacks then the first NTLP node would 
have to check whether the sender of an NTLP message is allowed 
to signal for a specific NSLP (given that he's allowed to use NTLP). 
This would hold even if this NSLP isn't supported locally. Some 
policy communication is required then. 

But no matter how the solution looks like: two peering nodes 
shouldn't have to support completely separate security instances 
per NTLP/NSLP stack as a consequence of NTLP only handling messages 
with specific NSLPs. 

Regards, Rudiger

|4. Reference
|
|[Han] R. Hancock: "Reliability Functions in the NSIS Transport Layer
|Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in 
|progress),
|August 2003
|
|[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security 
|thoughts, Date: Sun,
|13 Jul 2003 14:47:51 +0200",  Available at:
|http://www1.ietf.org/mail-archive/working-groups/nsis/current/m
|sg03106.html,
|(Sep. 2003). 
|
|
|ciao
|Hannes
|
|
|_______________________________________________
|nsis mailing list
|nsis@ietf.org
|https://www1.ietf.org/mailman/listinfo/nsis
|

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



From exim@www1.ietf.org  Mon Sep 22 14:46:30 2003
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 OAA29973
	for <nsis-archive@odin.ietf.org>; Mon, 22 Sep 2003 14:46:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1VhJ-0006Fh-6T
	for nsis-archive@odin.ietf.org; Mon, 22 Sep 2003 14:46:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MIk97Y024029
	for nsis-archive@odin.ietf.org; Mon, 22 Sep 2003 14:46:09 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1VhC-0006EB-6a; Mon, 22 Sep 2003 14:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1Vh4-0006Cx-2D
	for nsis@optimus.ietf.org; Mon, 22 Sep 2003 14:45:54 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29866;
	Mon, 22 Sep 2003 14:45:44 -0400 (EDT)
Message-Id: <200309221845.OAA29866@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: nsis@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 22 Sep 2003 14:45:44 -0400
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-00.txt
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: NSLP for Quality-of-Service signaling
	Author(s)	: S. Van den Bosch et al.
	Filename	: draft-ietf-nsis-qos-nslp-00.txt
	Pages		: 30
	Date		: 2003-9-22
	
This draft describes an NSIS Signaling Layer Protocol (NSLP) for 
signaling QoS reservations in the Internet. It is in accordance with 
the framework and requirements developed in NSIS. 
Together with the NTLP, it provides functionality similar to RSVP and 
extends it. The QoS-NSLP is independent of the underlying QoS 
specification or architecture and provides support for different 
reservation models. It is simplified by the elimination of support 
for multicast flows. 
This version of the draft focuses on the basic protocol structure. It 
identifies the different message types and describes the basic 
operation of the protocol to create, refresh, modify and teardown a 
reservation or to obtain information on the characteristics of the 
associated data path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nsis-qos-nslp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-qos-nslp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-9-22141313.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-nsis-qos-nslp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-nsis-qos-nslp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-9-22141313.I-D@ietf.org>

--OtherAccess--

--NextPart--



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



From exim@www1.ietf.org  Tue Sep 23 05:17:27 2003
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 FAA01597
	for <nsis-archive@odin.ietf.org>; Tue, 23 Sep 2003 05:17:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1jI9-0004uH-8w
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 05:17:05 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N9H5Ks018857
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 05:17:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1jI5-0004tJ-3k; Tue, 23 Sep 2003 05:17:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1jHw-0004sM-PO
	for nsis@optimus.ietf.org; Tue, 23 Sep 2003 05:16: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 FAA01578
	for <nsis@ietf.org>; Tue, 23 Sep 2003 05:16:44 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1jHt-000082-00
	for nsis@ietf.org; Tue, 23 Sep 2003 05:16:49 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1jHt-00007r-00
	for nsis@ietf.org; Tue, 23 Sep 2003 05:16:49 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8N9Gm613808
	for <nsis@ietf.org>; Tue, 23 Sep 2003 12:16:48 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T64dac9bb33ac158f25172@esvir05nok.ntc.nokia.com> for <nsis@ietf.org>;
 Tue, 23 Sep 2003 12:16:23 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 23 Sep 2003 12:16:23 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Tue, 23 Sep 2003 12:16:23 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Sep 2003 12:16:22 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB320636A8B474@esebe023.ntc.nokia.com>
Thread-Topic: Internet-Draft Cutoff Dates for Minneapolis, MN, USA   
Thread-Index: AcOBRcma001qQ3o9Sd+grJ1xbwIeyQAbUpew
To: <nsis@ietf.org>
X-OriginalArrivalTime: 23 Sep 2003 09:16:23.0132 (UTC) FILETIME=[5B88B1C0:01C381B3]
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] FW: Internet-Draft Cutoff Dates for Minneapolis, MN, USA
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: quoted-printable

Hi all,

Here is info about Internet-Draft cutoff dates.  Please note, that =
anyone
wishing to have time to discuss their draft should make an effort to =
ensure
that there is some list discussion before the meeting.  Preference will
be given to those drafts that have interest / discussion on the mailing =
list.

thanks,
John

-----Original Message-----
From: ext Internet-Drafts Administrator
[mailto:internet-drafts@ietf.org]
Sent: 22 September, 2003 21:47
Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA=20



NOTE: There are two (2) Internet-Draft Cutoff dates

October 20th: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Monday, October 20th,=20
at 09:00 ET.  Initial submissions received after this time will NOT be
made available in the Internet-Drafts directory, and will have to be
resubmitted.
=20
As before, all initial submissions (-00.txt) with a filename beginning
with a draft-ietf MUST be approved by the appropriate WG Chair prior to
processing and announcing. WG Chair approval must be received by
Monday, October 13th.

 Please do NOT wait until the last minute to submit.

Be advised: NO placeholders. Updates to initial submissions received
            the week of October 20th will NOT be accepted.

October 27th: FINAL Internet-Draft Cutoff

All revised Internet-Draft submissions must be submitted by Monday,
October 27th, 2003 at 09:00 ET.  Internet-Drafts received after this
time will NOT be announced NOR made available in the Internet-Drafts
Directories.

We will begin accepting Internet-Draft submissions the week of the
meeting, though announcements will NOT be sent until the IETF meeting
is over.

Thank you for your understanding and cooperation. Please do not hesitate
to contact us if you have any questions or concenrs.

FYI: These and other significant dates can be found at
      http://www.ietf.org/meetings/cutoff_dates_58.html



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



From exim@www1.ietf.org  Tue Sep 23 09:02:42 2003
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 JAA10607
	for <nsis-archive@odin.ietf.org>; Tue, 23 Sep 2003 09:02:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1mnz-00007a-Oc
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 09:02:16 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ND2BkE000467
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 09:02:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1mnp-00005y-0I; Tue, 23 Sep 2003 09:02:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1mnR-0008VF-Sb
	for nsis@optimus.ietf.org; Tue, 23 Sep 2003 09:01:39 -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 JAA10577
	for <nsis@ietf.org>; Tue, 23 Sep 2003 09:01:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1mnP-0005bu-00
	for nsis@ietf.org; Tue, 23 Sep 2003 09:01:35 -0400
Received: from rsys001a.roke.co.uk ([193.118.192.110])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1mnP-0005YE-00
	for nsis@ietf.org; Tue, 23 Sep 2003 09:01:35 -0400
Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TNNALSAY>; Tue, 23 Sep 2003 14:00:50 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A709385D0@rsys004a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>,
        Hannes.Tschofenig@siemens.com, nsis@ietf.org
Subject: RE: [NSIS] Reliability and Security
Date: Tue, 23 Sep 2003 14:00:54 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-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>

dear colleagues,

there is actually a really hard set of questions here. as well
as the security and transport issues hannes mentions (of which
my favourite is actually congestion/flow control), there is
also a more basic point about fast-path bypassing of NSIS
messages inside aggregation regions, which we can't ignore. 

there is also the problem of how to achieve this in the case where the
intermediate node wants to some nearly-minimal processing on 
some bits of the signalling message payload (e.g. address 
translation, or some of the tricks that the RMD people want
to play when using reservation-based PHRs).

about the only thing I am certain of here is that fw-03 is
wrong on the matter. i have written some replacement text for
fw-04 partially based on fw-03 section 3.2.1. it is attached 
below. (basically it says there are some problems the NTLP
designers will have to worry about...)

cheers,

r.

==============================================================
3.x.x	Bypassing Intermediate Nodes

Because the NSIS problem includes multiple signaling
applications, it is very likely that a particular NSLP will
only be implemented on a subset of the NSIS-aware nodes on a
path, as shown in Figure 5. In addition, a node inside an
aggregation region will still wish to ignore signaling
messages which are per-flow, even if they are for a
signaling application which the node is able to process in
general.
	
            +------+    +------+    +------+    +------+
            |  NE  |    |  NE  |    |  NE  |    |  NE  |
            |+----+|    |      |    |+----+|    |+----+|
            ||NSLP||    |      |    ||NSLP||    ||NSLP||
            || 1  ||    |      |    || 2  ||    || 1  ||
            |+----+|    |      |    |+----+|    |+----+|
            |  ||  |    |      |    |      |    |  ||  |
            |+----+|    |+----+|    |+----+|    |+----+|
        ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
            |+----+|    |+----+|    |+----+|    |+----+|
            +------+    +------+    +------+    +------+

Figure 5: Signaling with Heterogeneous NSLPs

Where signaling messages traverse such NSIS-aware
intermediate nodes, it is desirable to process them at the
lowest level possible (in particular, on the fastest path).
In order to offer a non-trivial  message transfer service
(in terms of security, reliability and so on) to the peer
NSLP nodes, it is important that NTLP at intermediate nodes
is as transparent as possible, that is, it carries out
minimal processing. In addition, if intermediate nodes have
to do slow-path processing of all NSIS messages, this
eliminates many of the scaling benefits of aggregation,
unless tunneling is used.

Considering first the case of messages sent with the router
alert option, there are two complementary methods to achieve
this bypassing of intermediate NEs:

*) At the IP layer, a set of protocol numbers can be used,
or a range of values in the router alert option. In this
way, messages can be marked with an implied granularity, and
routers can choose to apply further slow-path processing
only to configured subsets of messages. This is the method
used in [3175] to distinguish per-flow and per-aggregate signaling.

*) The NTLP could process the message but determine that
there was no local signaling application it was relevant to.
At this stage, the message can be returned unchanged to the
IP layer for normal forwarding; the intermediate NE has
effectively chosen to be transparent to the message in question.

In both cases, the existence of the intermediate NE is
totally hidden from the NSLP nodes. If later stages of the
signaling use directly addressed messages (e.g. for reverse
routing), they will not involved the intermediate NE at all,
except perhaps as a normal router.

There may be cases where the intermediate NE would like to
do some restricted protocol processing, for example:
*) Translating addresses in message payloads (compare
section 4.6.1); note this would have to be done to messages
passing both directions through a node.
*) Updating signaling application payloads with local status
information (e.g. path property measurement inside a domain).
If this can be done without fully terminating the NSIS
protocols, this would allow a more lightweight
implementation of the intermediate NE, and a more direct
'end-to-end' NTLP association between the peer NSLPs where
the signaling application is fully processed. On the other
hand, this is only possible with a limited class of possible
NTLP designs, and makes it harder for the NTLP to offer a
security service (since messages have to be partially
protected). The feasibility of this approach will be
evaluated during the NTLP design.

======================================================

> -----Original Message-----
> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Sent: Wednesday, September 17, 2003 12:59
> To: Hannes.Tschofenig@siemens.com; nsis@ietf.org
> Subject: RE: [NSIS] Reliability and Security
> 
> 
> Hello Hannes,
> 
> sorry, I've hit the wrong keys earlier. So I bother you again... 
> 
> [snip]
> |Is 
> |
> |     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3 
> |<NTLP-Security> NE 4
> |
> |the same as 
> |      
> |     NE 1 <NSLP-Security> NE 4
> |?      
> |
> |My perception is that it is not necessarily the same, as 
> also argued in
> |[Han] concerning reliability.
> 
> I share your view, this isn't the same. And your conclusion 
> is correct:
> 
> |If the working group thinks that this is not the same then 
> it would be
> |necessary to provide additional security between neighboring 
> |NSLP peers. 
> |
> |As a consequence a discovery mechanism is needed at the NSLP 
> |to learn the next NSLP node along the path. This is necessary to be 
> |able to secure signaling messages efficiently (i.e. using symmetric 
> |cryptography). Hence avoiding the discovery procedure at the NTLP 
> |was not really beneficial.
> |Without efficient mechanism it is likely that the mechanisms 
> |would not be used at all. 
> |
> |Securing signaling messages at the NTLP and the NSLP might 
> |seem to be an overkill to some people. Securing  signaling messages 
> |only at the NSLP layer does not seem to be sufficient as recently 
> |discussed (see NSIS ML discussion [NSIS-ML]).
> 
> Looks as if there's no solution for having a flexible architecture 
> combined with security across NTLP and NSLP.
> 
> I don't think that we must protect NSLP messages. To protect 
> against "simple" NSLP DoS attacks then the first NTLP node would 
> have to check whether the sender of an NTLP message is allowed 
> to signal for a specific NSLP (given that he's allowed to use NTLP). 
> This would hold even if this NSLP isn't supported locally. Some 
> policy communication is required then. 
> 
> But no matter how the solution looks like: two peering nodes 
> shouldn't have to support completely separate security instances 
> per NTLP/NSLP stack as a consequence of NTLP only handling messages 
> with specific NSLPs. 
> 
> Regards, Rudiger
> 
> |4. Reference
> |
> |[Han] R. Hancock: "Reliability Functions in the NSIS Transport Layer
> |Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in 
> |progress),
> |August 2003
> |
> |[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security 
> |thoughts, Date: Sun,
> |13 Jul 2003 14:47:51 +0200",  Available at:
> |http://www1.ietf.org/mail-archive/working-groups/nsis/current/m
> |sg03106.html,
> |(Sep. 2003). 
> |
> |
> |ciao
> |Hannes
> |
> |
> |_______________________________________________
> |nsis mailing list
> |nsis@ietf.org
> |https://www1.ietf.org/mailman/listinfo/nsis
> |
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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



From exim@www1.ietf.org  Tue Sep 23 09:49:24 2003
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 JAA13212
	for <nsis-archive@odin.ietf.org>; Tue, 23 Sep 2003 09:49:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1nXK-0004ne-4I
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 09:49:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NDn2fI018444
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 09:49:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1nXJ-0004nE-PQ; Tue, 23 Sep 2003 09:49:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1nWZ-0004gw-5r
	for nsis@optimus.ietf.org; Tue, 23 Sep 2003 09:48:15 -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 JAA13164
	for <nsis@ietf.org>; Tue, 23 Sep 2003 09:48:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1nWX-00001M-00
	for nsis@ietf.org; Tue, 23 Sep 2003 09:48:13 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1nWW-00000d-00
	for nsis@ietf.org; Tue, 23 Sep 2003 09:48:12 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 23 Sep 2003 15:09:00 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJTGV9>; Tue, 23 Sep 2003 15:08:59 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB601@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: sven.van_den_bosch@alcatel.be
Cc: nsis@ietf.org
Date: Tue, 23 Sep 2003 15:08:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] qos-nslp-00
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: quoted-printable

Hi Sven,

Chapter 7 tells the reader that the draft-nsis-qos-nslp-00 is rather =
drafty yet. Some issues I've identified:

- The rather flexible NSLP defined by the document=20
  more seems to be a generic NSLP than a QoS NSLP.
- Chapter 7.1 misses "security" as a refinement=20
  required for this version. I doubt it's a good=20
  idea to define a protocol and worry about=20
  security afterwards.
- Retransmitted "Reservation Sequence Numbers"=20
  serve as a Session ID. Why aren't=20
  the tradeoffs and benefits of combining both=20
  functions discussed?
- A table listing the maximum per session state=20
  maintenance requirements is missing.=20
- Error messages don't remove state but they may=20
  trigger state removal (see 4.5). Besides an=20
  notify message, a Reservation/Tear may travel=20
  in parallel. What's the benefit of this solution?
- 2.7 and 6.2 seem to specify NTLP functionalities.

A general comment (not related to this draft):
The Interface between NTLP and NSLP doesn't seem to be defined well. =
NSLP may need some IP and local topology information (e.g. incoming and =
outgoing IF). It should be clearly defined where it gets it from.

Regards, R=FCdiger


R=FCdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com
=20

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



From exim@www1.ietf.org  Tue Sep 23 10:47:31 2003
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 KAA17570
	for <nsis-archive@odin.ietf.org>; Tue, 23 Sep 2003 10:47:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1oRX-0000pi-6d
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 10:47:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NEl7Mu003183
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 10:47:07 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1oRS-0000ob-7N; Tue, 23 Sep 2003 10:47:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1oRD-0000oG-Px
	for nsis@optimus.ietf.org; Tue, 23 Sep 2003 10:46:47 -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 KAA17490
	for <nsis@ietf.org>; Tue, 23 Sep 2003 10:46:38 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1oRB-0000xG-00
	for nsis@ietf.org; Tue, 23 Sep 2003 10:46:45 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1oRA-0000wy-00
	for nsis@ietf.org; Tue, 23 Sep 2003 10:46:44 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 23 Sep 2003 16:21:59 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJTLQR>; Tue, 23 Sep 2003 16:21:58 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB602@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: robert.hancock@roke.co.uk
Cc: nsis@ietf.org
Subject: RE: [NSIS] Reliability and Security
Date: Tue, 23 Sep 2003 16:21:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Robert,=20

your text-proposal is ok with me.

Regards, R=FCdiger

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



From exim@www1.ietf.org  Tue Sep 23 18:03:25 2003
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 SAA09259
	for <nsis-archive@odin.ietf.org>; Tue, 23 Sep 2003 18:03:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1vFP-0000fg-SX
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 18:03:04 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NM33bF002581
	for nsis-archive@odin.ietf.org; Tue, 23 Sep 2003 18:03:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1vFN-0000f2-8y; Tue, 23 Sep 2003 18:03:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A1vFF-0000em-Pg
	for nsis@optimus.ietf.org; Tue, 23 Sep 2003 18:02:53 -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 SAA09214
	for <nsis@ietf.org>; Tue, 23 Sep 2003 18:02:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1vFC-0007eC-00
	for nsis@ietf.org; Tue, 23 Sep 2003 18:02:50 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A1vFC-0007dM-00
	for nsis@ietf.org; Tue, 23 Sep 2003 18:02:50 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TNNBRZ45>; Tue, 23 Sep 2003 23:02:15 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A708AC22A@rsys004a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis@ietf.org
Date: Tue, 23 Sep 2003 23:02:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [NSIS] Message summarisation ("summary refreshes")
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>

dear all,

there is currently an open issue in the framework about which
layer should be responsible for summarisation of refresh messages
(i.e. being able to send a message id rather than a complete
message, like 2961 does). some people have assumed that the
NTLP should provide this as a service, while others have 
felt this would be an overcoupling of state/identifiers between
the two layers.

my feeling is that we should not mandate specific functionality
in the NTLP to do this at this stage, or impose a specific 
function split or inter-layer dependency in the framework. we should
just mention the possibility of doing transparent compression
in the NTLP as a option for later consideration (it's a bit like
'advanced bundling'). since this is always possible, the issue
probably doesn't even need to be discussed in detail.

views?

robert h.

=============================================================

the outline reasoning is as follows:
*) one benefit of summary refreshing is that the receiver doesn't
have to check the incoming message against all stored state to 
see if anything has changed, it just does 'same as last time'.
since the NTLP knows nothing about signalling application state,
achieving this benefit must be an NSLP function.
*) the other benefit of summary refreshes is to get multiple 
messages into a single network layer packet (saving network and
interrupt processing load in the receiver). this is basically 
a compression function. now:
- an NSLP can do a good job of compressing a message down
to flow-id + session-id + NSLP-id + NSLP-message-tag (if it
wants to); exactly what this compression means may be 
signalling application dependent (i.e. it may be something
other than bit-transparent compression)
- the NTLP may or may not be able to compress away the remaining
identifiers into a single message tag, depending on the exact 
circumstances (e.g. is the NSLP peer one NSIS hop or one IP hop
away, how much state the remote NTLP is prepared to store and
so on). It isn't clear how much additional benefit this will 
give over the compression can be done at the NSLP, but in any
case, it is just bit-transparent compression which can be done
as a matter of choice in the NTLP design.

the IETF (rohc w.g.) has developed a remarkable set of capabilities
for bit-transparent compression over recent years; IMHO we should
consider using these, if doing more than the NSLPs can becomes 
important (which in fact I doubt will happen soon), rather than
wiring a particular approach into the protocol suite framework.
in the meantime we don't lose anything by ignoring the issue.

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



From exim@www1.ietf.org  Wed Sep 24 02:26:32 2003
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 CAA22150
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 02:26:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A236G-0004mD-PM
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:26:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O6Q8wG018342
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:26:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A236C-0004lK-Ia; Wed, 24 Sep 2003 02:26:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A235p-0004h3-N3
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 02:25:42 -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 CAA21164
	for <nsis@ietf.org>; Wed, 24 Sep 2003 02:25:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A235l-00064K-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:25:37 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A235k-00063s-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:25:37 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 24 Sep 2003 08:25:07 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJ4L2F>; Wed, 24 Sep 2003 08:25:07 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB609@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: robert.hancock@roke.co.uk
Cc: nsis@ietf.org
Subject: RE: [NSIS] Message summarisation ("summary refreshes")
Date: Wed, 24 Sep 2003 08:25:06 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Robert,

as I've raised the issue of missing consensus on the layer split
in my mail referring to the qos-nslp draft, I must object.=20

Drafts on  NTLP and NSLP now have WG status. To progress them,=20
consensus must be reached on the layer split (soon in my eyes).=20
Maybe author teams of both should meet or there should be an=20
expert team producing a proposal.=20

I agree with you that it isn't a task of a framework=20
document to define this split in detail.

I'd be interested in John's view on how/when to solve=20
the layer split issue.

Regards, R=FCdiger

|my feeling is that we should not mandate specific functionality
|in the NTLP to do this at this stage, or impose a specific=20
|function split or inter-layer dependency in the framework.=20
|views?
|
|robert h.

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



From exim@www1.ietf.org  Wed Sep 24 02:34:31 2003
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 CAA26342
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 02:34:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23E0-0005bP-SG
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:34:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O6Y8dF021509
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:34:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23Dy-0005an-Gv; Wed, 24 Sep 2003 02:34:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23DG-0005Zl-4e
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 02:33:22 -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 CAA26312
	for <nsis@ietf.org>; Wed, 24 Sep 2003 02:33:14 -0400 (EDT)
From: john.loughney@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A23DC-0006F2-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:33:18 -0400
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A23DB-0006Ez-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:33:17 -0400
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8O6XH606389
	for <nsis@ietf.org>; Wed, 24 Sep 2003 09:33:18 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T64df5abb98ac158f25172@esvir05nok.ntc.nokia.com>;
 Wed, 24 Sep 2003 09:33:15 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 24 Sep 2003 09:33:14 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 24 Sep 2003 09:33:14 +0300
Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139);
	 Wed, 24 Sep 2003 09:33:14 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [NSIS] Message summarisation ("summary refreshes")
Date: Wed, 24 Sep 2003 09:33:12 +0300
Message-ID: <DADF50F5EC506B41A0F375ABEB320636A8B491@esebe023.ntc.nokia.com>
Thread-Topic: [NSIS] Message summarisation ("summary refreshes")
Thread-Index: AcOCZM9SOP2oPAX3Qki8YpF6O0sC0gAAGR4g
To: <Ruediger.Geib@t-systems.com>, <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
X-OriginalArrivalTime: 24 Sep 2003 06:33:14.0026 (UTC) FILETIME=[BB2F68A0:01C38265]
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi R=FCdiger, Robert;

> as I've raised the issue of missing consensus on the layer split
> in my mail referring to the qos-nslp draft, I must object.=20
>
> Drafts on  NTLP and NSLP now have WG status. To progress them,=20
> consensus must be reached on the layer split (soon in my eyes).=20
> Maybe author teams of both should meet or there should be an=20
> expert team producing a proposal.=20
>=20
> I agree with you that it isn't a task of a framework=20
> document to define this split in detail.
>=20
> I'd be interested in John's view on how/when to solve=20
> the layer split issue.

Currently, there is no WG NTLP draft yet, so it is hard to=20
say anything about it.  Hopefully Henning/Robert have a
draft nearly ready for submission.  As the QoS NSLP draft
has been published, and the NAT/FW NSLP draft should be
ready shortly (I hope), it seems reasonable to try to target
discussion in Minneapolis to resolve this issue.  Discussions
in the framework doc did not produce consensus, so I think
that framework doc should list issues related to the layer
split, which should be, then, resolved in the version 01 drafts
of the NTLP/NSLP protocol(s).

Does this sound reasonable?

John

=20
> Regards, R=FCdiger
>=20
> |my feeling is that we should not mandate specific functionality
> |in the NTLP to do this at this stage, or impose a specific=20
> |function split or inter-layer dependency in the framework.=20
> |views?
> |
> |robert h.
>=20
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>=20

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



From exim@www1.ietf.org  Wed Sep 24 02:41:29 2003
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 CAA26553
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 02:41:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23Kk-0006DQ-SL
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:41:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O6f5H1023848
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:41:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23Ki-0006CX-6z; Wed, 24 Sep 2003 02:41:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23Jq-00068e-Di
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 02:40:10 -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 CAA26512
	for <nsis@ietf.org>; Wed, 24 Sep 2003 02:40:02 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A23Jm-0006JA-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:40:06 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A23Jl-0006Ij-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:40:06 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 24 Sep 2003 08:39:36 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJ4MF5>; Wed, 24 Sep 2003 08:39:34 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB60C@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: john.loughney@nokia.com
Cc: nsis@ietf.org
Subject: [NSIS] Layer split details
Date: Wed, 24 Sep 2003 08:39:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-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>

Hi John,

yes, sounds reasonable.

|Currently, there is no WG NTLP draft yet, so it is hard to 
|say anything about it.  Hopefully Henning/Robert have a
|draft nearly ready for submission.  As the QoS NSLP draft
|has been published, and the NAT/FW NSLP draft should be
|ready shortly (I hope), it seems reasonable to try to target
|discussion in Minneapolis to resolve this issue.  Discussions
|in the framework doc did not produce consensus, so I think
|that framework doc should list issues related to the layer
|split, which should be, then, resolved in the version 01 drafts
|of the NTLP/NSLP protocol(s).
|
|Does this sound reasonable?
|
|John

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



From exim@www1.ietf.org  Wed Sep 24 02:57:24 2003
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 CAA27291
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 02:57:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23a9-00076p-MV
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:57:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O6v1CW027326
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 02:57:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23a8-00076H-7v; Wed, 24 Sep 2003 02:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A23ZX-00075T-4W
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 02:56:23 -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 CAA27243
	for <nsis@ietf.org>; Wed, 24 Sep 2003 02:56:14 -0400 (EDT)
From: sven.van_den_bosch@alcatel.be
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A23ZT-0006W9-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:56:19 -0400
Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A23ZS-0006Vs-00
	for nsis@ietf.org; Wed, 24 Sep 2003 02:56:18 -0400
Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6])
	by relay4.alcatel.be (8.12.10/8.12.9) with ESMTP id h8O6vYlR025775;
	Wed, 24 Sep 2003 08:57:34 +0200
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF0A92C7D0.7967C832-ONC1256DAB.00222487@net.alcatel.be>
Date: Wed, 24 Sep 2003 08:55:38 +0200
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 09/24/2003 08:55:48
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] Re: qos-nslp-00
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: quoted-printable

Hi Ruediger,

Thanks for your comments. I have tried to address them inline.

Cheers,
Sven





"Geib, Ruediger" <Ruediger.Geib@t-systems.com> on 23/09/2003 15:08:55

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    nsis@ietf.org
Subject:    qos-nslp-00


Hi Sven,

Chapter 7 tells the reader that the draft-nsis-qos-nslp-00 is rather dr=
afty
yet. Some issues I've identified:

- The rather flexible NSLP defined by the document
  more seems to be a generic NSLP than a QoS NSLP.

Sven>> I would rather say it is intended to be a QoS NSLP that is flexi=
ble
  enough to support different QoS architectures. We have chosen to deco=
uple
  the QoS NSLP machinery from the underlying QoS model that is being
  signaled for. For this reason, all QoS model related parameters will =
be
  carried in the QSpec.

- Chapter 7.1 misses "security" as a refinement
  required for this version. I doubt it's a good
  idea to define a protocol and worry about
  security afterwards.

Sven>> We are very concerned about security (note that Hannes is also
  involved ;-) ). In fact, we have two security sections; one will cove=
r
  security components (NSLP-specific security measures, e.g. to protect=
 QoS
  NSLP objects), the other will cover the security solution more in
  general, taking into account what is available from the NTLP. Obvious=
ly,
  we can't write that section just yet but note that there are referenc=
es
  to some drafts that contain discussion on this and that we will inclu=
de
  the outcome of these discussions.

- Retransmitted "Reservation Sequence Numbers"
  serve as a Session ID. Why aren't
  the tradeoffs and benefits of combining both
  functions discussed?

Sven>> We took special care not to use the RSN for anything else but
  ensuring that QoS NSLP message reordering could be detected. They hav=
e
  nothing to do with any session ID at the NTLP. Afaik, it is an open i=
ssue
  how NTLP sessions will relate to NSLP message exchanges. Also note th=
at
  the RSN has local significance only. It is not end-to-end unique.

- A table listing the maximum per session state
  maintenance requirements is missing.

Sven>> I think it is a bit early for that. I am not completely sure wha=
t
  you mean: an analysis of the maximum amount of reservation state
  associated with a QoS reservation maybe? That might depend on the QoS=

  model though.

- Error messages don't remove state but they may
  trigger state removal (see 4.5). Besides an
  notify message, a Reservation/Tear may travel
  in parallel. What's the benefit of this solution?

Sven>> We chose to let every QNE consider his immediate neighbour as th=
e
  requestor of the reservation. The requestor of the reservation is the=
 one
  that is allowed to tear it down. Therefore, tearing RESERVEs travel i=
n
  one direction (say 'downstream'). The QNE that initiates the tearing
  RESERVE indicates the fact that it is tearing down to its requestor (=
say
  'upstream'). This QNE then has to decide for itself whether it wants =
to
  tear down its state as well and whether it wants to notify its upstre=
am
  neighbour.

- 2.7 and 6.2 seem to specify NTLP functionalities.

Sven>> You are certainly right about 6.2. In fact the whole section sta=
tes
requirements/desires we have for the NTLP and is meant as input for the=

NTLP design. Section 2.7 introduces the fact that some QoS models suppo=
rted
by the QoS NSLP might not keep (per-flow) state. This operation makes m=
ost
sense when the NTLP is able to . It makes the most sense when the NTLP =
is
able to make use of the fact that e.g. the QoS NSLP will never use reve=
rse
path state. This is explained in section 6.1

A general comment (not related to this draft):
The Interface between NTLP and NSLP doesn't seem to be defined well. NS=
LP
may need some IP and local topology information (e.g. incoming and outg=
oing
IF). It should be clearly defined where it gets it from.

Sven>> Section 6 is an effort in this direction. It states requirement =
for
the NTLP in this version but we assume it will evolve to a description =
of
the interface between the two once NTLP becomes more clear.

Regards, R=FCdiger


R=FCdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com




=



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



From exim@www1.ietf.org  Wed Sep 24 03:48:26 2003
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 DAA29455
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 03:48:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A24NV-0002sV-V8
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 03:48:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7m12w011060
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 03:48:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A24NU-0002rv-K6; Wed, 24 Sep 2003 03:48:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A24Mx-0002jM-NP
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 03:47:27 -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 DAA29436
	for <nsis@ietf.org>; Wed, 24 Sep 2003 03:47:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A24Mv-0007DG-00
	for nsis@ietf.org; Wed, 24 Sep 2003 03:47:25 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A24Mu-0007DD-00
	for nsis@ietf.org; Wed, 24 Sep 2003 03:47:24 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h8O7lFaK015509;
	Wed, 24 Sep 2003 09:47:17 +0200 (MET DST)
Message-ID: <001101c38270$14af32c0$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>, <nsis@ietf.org>
References: <EA943CD30BCB104E9D38F5B5DC2D9A709385D0@rsys004a.roke.co.uk>
Subject: Re: [NSIS] Reliability and Security
Date: Wed, 24 Sep 2003 09:47:16 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
Content-Transfer-Encoding: 7bit
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

Hi Robert

I agree with your proposed text!

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>;
<Hannes.Tschofenig@siemens.com>; <nsis@ietf.org>
Sent: Tuesday, September 23, 2003 3:00 PM
Subject: RE: [NSIS] Reliability and Security


> dear colleagues,
>
> there is actually a really hard set of questions here. as well
> as the security and transport issues hannes mentions (of which
> my favourite is actually congestion/flow control), there is
> also a more basic point about fast-path bypassing of NSIS
> messages inside aggregation regions, which we can't ignore.
>
> there is also the problem of how to achieve this in the case where the
> intermediate node wants to some nearly-minimal processing on
> some bits of the signalling message payload (e.g. address
> translation, or some of the tricks that the RMD people want
> to play when using reservation-based PHRs).
>
> about the only thing I am certain of here is that fw-03 is
> wrong on the matter. i have written some replacement text for
> fw-04 partially based on fw-03 section 3.2.1. it is attached
> below. (basically it says there are some problems the NTLP
> designers will have to worry about...)
>
> cheers,
>
> r.
>
> ==============================================================
> 3.x.x Bypassing Intermediate Nodes
>
> Because the NSIS problem includes multiple signaling
> applications, it is very likely that a particular NSLP will
> only be implemented on a subset of the NSIS-aware nodes on a
> path, as shown in Figure 5. In addition, a node inside an
> aggregation region will still wish to ignore signaling
> messages which are per-flow, even if they are for a
> signaling application which the node is able to process in
> general.
>
>             +------+    +------+    +------+    +------+
>             |  NE  |    |  NE  |    |  NE  |    |  NE  |
>             |+----+|    |      |    |+----+|    |+----+|
>             ||NSLP||    |      |    ||NSLP||    ||NSLP||
>             || 1  ||    |      |    || 2  ||    || 1  ||
>             |+----+|    |      |    |+----+|    |+----+|
>             |  ||  |    |      |    |      |    |  ||  |
>             |+----+|    |+----+|    |+----+|    |+----+|
>         ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
>             |+----+|    |+----+|    |+----+|    |+----+|
>             +------+    +------+    +------+    +------+
>
> Figure 5: Signaling with Heterogeneous NSLPs
>
> Where signaling messages traverse such NSIS-aware
> intermediate nodes, it is desirable to process them at the
> lowest level possible (in particular, on the fastest path).
> In order to offer a non-trivial  message transfer service
> (in terms of security, reliability and so on) to the peer
> NSLP nodes, it is important that NTLP at intermediate nodes
> is as transparent as possible, that is, it carries out
> minimal processing. In addition, if intermediate nodes have
> to do slow-path processing of all NSIS messages, this
> eliminates many of the scaling benefits of aggregation,
> unless tunneling is used.
>
> Considering first the case of messages sent with the router
> alert option, there are two complementary methods to achieve
> this bypassing of intermediate NEs:
>
> *) At the IP layer, a set of protocol numbers can be used,
> or a range of values in the router alert option. In this
> way, messages can be marked with an implied granularity, and
> routers can choose to apply further slow-path processing
> only to configured subsets of messages. This is the method
> used in [3175] to distinguish per-flow and per-aggregate signaling.
>
> *) The NTLP could process the message but determine that
> there was no local signaling application it was relevant to.
> At this stage, the message can be returned unchanged to the
> IP layer for normal forwarding; the intermediate NE has
> effectively chosen to be transparent to the message in question.
>
> In both cases, the existence of the intermediate NE is
> totally hidden from the NSLP nodes. If later stages of the
> signaling use directly addressed messages (e.g. for reverse
> routing), they will not involved the intermediate NE at all,
> except perhaps as a normal router.
>
> There may be cases where the intermediate NE would like to
> do some restricted protocol processing, for example:
> *) Translating addresses in message payloads (compare
> section 4.6.1); note this would have to be done to messages
> passing both directions through a node.
> *) Updating signaling application payloads with local status
> information (e.g. path property measurement inside a domain).
> If this can be done without fully terminating the NSIS
> protocols, this would allow a more lightweight
> implementation of the intermediate NE, and a more direct
> 'end-to-end' NTLP association between the peer NSLPs where
> the signaling application is fully processed. On the other
> hand, this is only possible with a limited class of possible
> NTLP designs, and makes it harder for the NTLP to offer a
> security service (since messages have to be partially
> protected). The feasibility of this approach will be
> evaluated during the NTLP design.
>
> ======================================================
>
> > -----Original Message-----
> > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> > Sent: Wednesday, September 17, 2003 12:59
> > To: Hannes.Tschofenig@siemens.com; nsis@ietf.org
> > Subject: RE: [NSIS] Reliability and Security
> >
> >
> > Hello Hannes,
> >
> > sorry, I've hit the wrong keys earlier. So I bother you again...
> >
> > [snip]
> > |Is
> > |
> > |     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3
> > |<NTLP-Security> NE 4
> > |
> > |the same as
> > |
> > |     NE 1 <NSLP-Security> NE 4
> > |?
> > |
> > |My perception is that it is not necessarily the same, as
> > also argued in
> > |[Han] concerning reliability.
> >
> > I share your view, this isn't the same. And your conclusion
> > is correct:
> >
> > |If the working group thinks that this is not the same then
> > it would be
> > |necessary to provide additional security between neighboring
> > |NSLP peers.
> > |
> > |As a consequence a discovery mechanism is needed at the NSLP
> > |to learn the next NSLP node along the path. This is necessary to be
> > |able to secure signaling messages efficiently (i.e. using symmetric
> > |cryptography). Hence avoiding the discovery procedure at the NTLP
> > |was not really beneficial.
> > |Without efficient mechanism it is likely that the mechanisms
> > |would not be used at all.
> > |
> > |Securing signaling messages at the NTLP and the NSLP might
> > |seem to be an overkill to some people. Securing  signaling messages
> > |only at the NSLP layer does not seem to be sufficient as recently
> > |discussed (see NSIS ML discussion [NSIS-ML]).
> >
> > Looks as if there's no solution for having a flexible architecture
> > combined with security across NTLP and NSLP.
> >
> > I don't think that we must protect NSLP messages. To protect
> > against "simple" NSLP DoS attacks then the first NTLP node would
> > have to check whether the sender of an NTLP message is allowed
> > to signal for a specific NSLP (given that he's allowed to use NTLP).
> > This would hold even if this NSLP isn't supported locally. Some
> > policy communication is required then.
> >
> > But no matter how the solution looks like: two peering nodes
> > shouldn't have to support completely separate security instances
> > per NTLP/NSLP stack as a consequence of NTLP only handling messages
> > with specific NSLPs.
> >
> > Regards, Rudiger
> >
> > |4. Reference
> > |
> > |[Han] R. Hancock: "Reliability Functions in the NSIS Transport Layer
> > |Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in
> > |progress),
> > |August 2003
> > |
> > |[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security
> > |thoughts, Date: Sun,
> > |13 Jul 2003 14:47:51 +0200",  Available at:
> > |http://www1.ietf.org/mail-archive/working-groups/nsis/current/m
> > |sg03106.html,
> > |(Sep. 2003).
> > |
> > |
> > |ciao
> > |Hannes
> > |
> > |
> > |_______________________________________________
> > |nsis mailing list
> > |nsis@ietf.org
> > |https://www1.ietf.org/mailman/listinfo/nsis
> > |
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>


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



From exim@www1.ietf.org  Wed Sep 24 03:56:24 2003
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 DAA00690
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 03:56:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A24VF-0003Wy-AR
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 03:56:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7u1Z5013557
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 03:56:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A24VE-0003WZ-Su; Wed, 24 Sep 2003 03:56:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A24Up-0003WJ-SC
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 03:55:35 -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 DAA00675
	for <nsis@ietf.org>; Wed, 24 Sep 2003 03:55:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A24Un-0007WJ-00
	for nsis@ietf.org; Wed, 24 Sep 2003 03:55:33 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A24Uk-0007WF-00
	for nsis@ietf.org; Wed, 24 Sep 2003 03:55:30 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h8O7tSaK015869;
	Wed, 24 Sep 2003 09:55:29 +0200 (MET DST)
Message-ID: <004001c38271$39852bd0$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>, <nsis@ietf.org>
References: <EA943CD30BCB104E9D38F5B5DC2D9A708AC22A@rsys004a.roke.co.uk>
Subject: Re: [NSIS] Message summarisation ("summary refreshes")
Date: Wed, 24 Sep 2003 09:55:30 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
Content-Transfer-Encoding: 7bit
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

Hi Robert

Your proposal regarding the optional/mandatory functionality
in the NTLP is very reasonable and I agree with it.

Best regards,
Georgios



----- Original Message ----- 
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: <nsis@ietf.org>
Sent: Wednesday, September 24, 2003 12:02 AM
Subject: [NSIS] Message summarisation ("summary refreshes")


> dear all,
> 
> there is currently an open issue in the framework about which
> layer should be responsible for summarisation of refresh messages
> (i.e. being able to send a message id rather than a complete
> message, like 2961 does). some people have assumed that the
> NTLP should provide this as a service, while others have 
> felt this would be an overcoupling of state/identifiers between
> the two layers.
> 
> my feeling is that we should not mandate specific functionality
> in the NTLP to do this at this stage, or impose a specific 
> function split or inter-layer dependency in the framework. we should
> just mention the possibility of doing transparent compression
> in the NTLP as a option for later consideration (it's a bit like
> 'advanced bundling'). since this is always possible, the issue
> probably doesn't even need to be discussed in detail.
> 
> views?
> 
> robert h.
> 
> =============================================================
> 
> the outline reasoning is as follows:
> *) one benefit of summary refreshing is that the receiver doesn't
> have to check the incoming message against all stored state to 
> see if anything has changed, it just does 'same as last time'.
> since the NTLP knows nothing about signalling application state,
> achieving this benefit must be an NSLP function.
> *) the other benefit of summary refreshes is to get multiple 
> messages into a single network layer packet (saving network and
> interrupt processing load in the receiver). this is basically 
> a compression function. now:
> - an NSLP can do a good job of compressing a message down
> to flow-id + session-id + NSLP-id + NSLP-message-tag (if it
> wants to); exactly what this compression means may be 
> signalling application dependent (i.e. it may be something
> other than bit-transparent compression)
> - the NTLP may or may not be able to compress away the remaining
> identifiers into a single message tag, depending on the exact 
> circumstances (e.g. is the NSLP peer one NSIS hop or one IP hop
> away, how much state the remote NTLP is prepared to store and
> so on). It isn't clear how much additional benefit this will 
> give over the compression can be done at the NSLP, but in any
> case, it is just bit-transparent compression which can be done
> as a matter of choice in the NTLP design.
> 
> the IETF (rohc w.g.) has developed a remarkable set of capabilities
> for bit-transparent compression over recent years; IMHO we should
> consider using these, if doing more than the NSLPs can becomes 
> important (which in fact I doubt will happen soon), rather than
> wiring a particular approach into the protocol suite framework.
> in the meantime we don't lose anything by ignoring the issue.
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 


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



From exim@www1.ietf.org  Wed Sep 24 04:47:31 2003
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 EAA02189
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 04:47:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25Ig-0006Mg-VW
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 04:47:09 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O8l6qW024465
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 04:47:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25Ie-0006M6-Gk; Wed, 24 Sep 2003 04:47:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25Ht-0006L7-15
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 04:46:17 -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 EAA02154
	for <nsis@ietf.org>; Wed, 24 Sep 2003 04:46:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25Hp-0000E3-00
	for nsis@ietf.org; Wed, 24 Sep 2003 04:46:13 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25Hp-0000Dq-00
	for nsis@ietf.org; Wed, 24 Sep 2003 04:46:13 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TNNBRZ97>; Wed, 24 Sep 2003 09:45:44 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A709385D5@rsys004a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        Ruediger.Geib@t-systems.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] Message summarisation ("summary refreshes")
Date: Wed, 24 Sep 2003 09:45:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

hi all,

i may have missed something here, my (fairly consistent) view
is that the f/w should *propose* a layer split as much is
possible to work out in a protocol vacuum. how successful we
have been depends on the area of functionality we are talking
about, for example:
*) for fragmentation, we had a long argument which i think
led to some agreed text.
*) for reliability/congestion control we have had a number=20
of very long arguments for which I have proposed some conclusions
(which no one has objected to and which i intend to use for
the issue in f/w-04);
*) for this summary refresh issue we have had some short=20
arguments for which I propose the conclusion 'it doesn't matter';
*) for the intermediate node problem we have identified the=20
issue (at last) and will just explain the problem. there is no
easy solution so far as I can tell.
[please send objections to any of the above assertions, or
raise them as issues when -04 comes out.]

it's clear that the f/w can't *define* the layer split, since
that's an issue for standards track documents. i don't believe
it's possible to do it formally without completing the NTLP
design (and should be done in conjunction with NSLP designs
going on in parallel). in other words, a formal definition of
the layer split in its own right will come nearer the end of
the work than the beginning. in the meantime, the f/w provides
guidance, within which the designers of the different protocols
can fine tune the divisions.

i see this as the application of 'rough consensus and running code'
(in the context of the design of a family of protocols rather than
just a single one).

cheers,

r.

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Wednesday, September 24, 2003 07:33
> To: Ruediger.Geib@t-systems.com; Hancock, Robert
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] Message summarisation ("summary refreshes")
>=20
>=20
> Hi R=FCdiger, Robert;
>=20
> > as I've raised the issue of missing consensus on the layer split
> > in my mail referring to the qos-nslp draft, I must object.=20
> >
> > Drafts on  NTLP and NSLP now have WG status. To progress them,=20
> > consensus must be reached on the layer split (soon in my eyes).=20
> > Maybe author teams of both should meet or there should be an=20
> > expert team producing a proposal.=20
> >=20
> > I agree with you that it isn't a task of a framework=20
> > document to define this split in detail.
> >=20
> > I'd be interested in John's view on how/when to solve=20
> > the layer split issue.
>=20
> Currently, there is no WG NTLP draft yet, so it is hard to=20
> say anything about it.  Hopefully Henning/Robert have a
> draft nearly ready for submission.  As the QoS NSLP draft
> has been published, and the NAT/FW NSLP draft should be
> ready shortly (I hope), it seems reasonable to try to target
> discussion in Minneapolis to resolve this issue.  Discussions
> in the framework doc did not produce consensus, so I think
> that framework doc should list issues related to the layer
> split, which should be, then, resolved in the version 01 drafts
> of the NTLP/NSLP protocol(s).
>=20
> Does this sound reasonable?
>=20
> John
>=20
> =20
> > Regards, R=FCdiger
> >=20
> > |my feeling is that we should not mandate specific functionality
> > |in the NTLP to do this at this stage, or impose a specific=20
> > |function split or inter-layer dependency in the framework.=20
> > |views?
> > |
> > |robert h.
> >=20
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >=20
>=20

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



From exim@www1.ietf.org  Wed Sep 24 05:04:24 2003
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 FAA03081
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 05:04:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25Z3-0007OV-LA
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 05:04:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O9412o028419
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 05:04:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25Z2-0007OG-Ru; Wed, 24 Sep 2003 05:04:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25Yr-0007O3-IK
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 05:03:49 -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 FAA03063
	for <nsis@ietf.org>; Wed, 24 Sep 2003 05:03:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25Yo-0000Wk-00
	for nsis@ietf.org; Wed, 24 Sep 2003 05:03:46 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25Yn-0000Wh-00
	for nsis@ietf.org; Wed, 24 Sep 2003 05:03:45 -0400
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120])
	by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8O93j31006466;
	Wed, 24 Sep 2003 11:03:46 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <TNY76NFS>; Wed, 24 Sep 2003 11:04:30 +0200
Message-ID: <F005CD411D18D3119C8F00508B0874800E170940@ehubunt100.eth.ericsson.se>
From: =?iso-8859-1?Q?Attila_B=E1der_=28IJ/ETH=29?=
	 <attila.bader@ericsson.com>
To: "Hancock, Robert" <robert.hancock@roke.co.uk>,
        "'Geib, Ruediger'"
	 <Ruediger.Geib@t-systems.com>,
        Hannes.Tschofenig@siemens.com, nsis@ietf.org
Subject: RE: [NSIS] Reliability and Security
Date: Wed, 24 Sep 2003 11:01:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-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>

Hi Robert,

I like the idea of restricted protocol operation, which really allow more lightweight implementation of our applications.

Best regards, Attila

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: Tuesday, September 23, 2003 3:01 PM
> To: 'Geib, Ruediger'; Hannes.Tschofenig@siemens.com; nsis@ietf.org
> Subject: RE: [NSIS] Reliability and Security
> 
> 
> dear colleagues,
> 
> there is actually a really hard set of questions here. as well
> as the security and transport issues hannes mentions (of which
> my favourite is actually congestion/flow control), there is
> also a more basic point about fast-path bypassing of NSIS
> messages inside aggregation regions, which we can't ignore. 
> 
> there is also the problem of how to achieve this in the case where the
> intermediate node wants to some nearly-minimal processing on 
> some bits of the signalling message payload (e.g. address 
> translation, or some of the tricks that the RMD people want
> to play when using reservation-based PHRs).
> 
> about the only thing I am certain of here is that fw-03 is
> wrong on the matter. i have written some replacement text for
> fw-04 partially based on fw-03 section 3.2.1. it is attached 
> below. (basically it says there are some problems the NTLP
> designers will have to worry about...)
> 
> cheers,
> 
> r.
> 
> ==============================================================
> 3.x.x	Bypassing Intermediate Nodes
> 
> Because the NSIS problem includes multiple signaling
> applications, it is very likely that a particular NSLP will
> only be implemented on a subset of the NSIS-aware nodes on a
> path, as shown in Figure 5. In addition, a node inside an
> aggregation region will still wish to ignore signaling
> messages which are per-flow, even if they are for a
> signaling application which the node is able to process in
> general.
> 	
>             +------+    +------+    +------+    +------+
>             |  NE  |    |  NE  |    |  NE  |    |  NE  |
>             |+----+|    |      |    |+----+|    |+----+|
>             ||NSLP||    |      |    ||NSLP||    ||NSLP||
>             || 1  ||    |      |    || 2  ||    || 1  ||
>             |+----+|    |      |    |+----+|    |+----+|
>             |  ||  |    |      |    |      |    |  ||  |
>             |+----+|    |+----+|    |+----+|    |+----+|
>         ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
>             |+----+|    |+----+|    |+----+|    |+----+|
>             +------+    +------+    +------+    +------+
> 
> Figure 5: Signaling with Heterogeneous NSLPs
> 
> Where signaling messages traverse such NSIS-aware
> intermediate nodes, it is desirable to process them at the
> lowest level possible (in particular, on the fastest path).
> In order to offer a non-trivial  message transfer service
> (in terms of security, reliability and so on) to the peer
> NSLP nodes, it is important that NTLP at intermediate nodes
> is as transparent as possible, that is, it carries out
> minimal processing. In addition, if intermediate nodes have
> to do slow-path processing of all NSIS messages, this
> eliminates many of the scaling benefits of aggregation,
> unless tunneling is used.
> 
> Considering first the case of messages sent with the router
> alert option, there are two complementary methods to achieve
> this bypassing of intermediate NEs:
> 
> *) At the IP layer, a set of protocol numbers can be used,
> or a range of values in the router alert option. In this
> way, messages can be marked with an implied granularity, and
> routers can choose to apply further slow-path processing
> only to configured subsets of messages. This is the method
> used in [3175] to distinguish per-flow and per-aggregate signaling.
> 
> *) The NTLP could process the message but determine that
> there was no local signaling application it was relevant to.
> At this stage, the message can be returned unchanged to the
> IP layer for normal forwarding; the intermediate NE has
> effectively chosen to be transparent to the message in question.
> 
> In both cases, the existence of the intermediate NE is
> totally hidden from the NSLP nodes. If later stages of the
> signaling use directly addressed messages (e.g. for reverse
> routing), they will not involved the intermediate NE at all,
> except perhaps as a normal router.
> 
> There may be cases where the intermediate NE would like to
> do some restricted protocol processing, for example:
> *) Translating addresses in message payloads (compare
> section 4.6.1); note this would have to be done to messages
> passing both directions through a node.
> *) Updating signaling application payloads with local status
> information (e.g. path property measurement inside a domain).
> If this can be done without fully terminating the NSIS
> protocols, this would allow a more lightweight
> implementation of the intermediate NE, and a more direct
> 'end-to-end' NTLP association between the peer NSLPs where
> the signaling application is fully processed. On the other
> hand, this is only possible with a limited class of possible
> NTLP designs, and makes it harder for the NTLP to offer a
> security service (since messages have to be partially
> protected). The feasibility of this approach will be
> evaluated during the NTLP design.
> 
> ======================================================
> 
> > -----Original Message-----
> > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> > Sent: Wednesday, September 17, 2003 12:59
> > To: Hannes.Tschofenig@siemens.com; nsis@ietf.org
> > Subject: RE: [NSIS] Reliability and Security
> > 
> > 
> > Hello Hannes,
> > 
> > sorry, I've hit the wrong keys earlier. So I bother you again... 
> > 
> > [snip]
> > |Is 
> > |
> > |     NE 1 <NTLP-Security> NE 2 <NTLP-Security> NE 3 
> > |<NTLP-Security> NE 4
> > |
> > |the same as 
> > |      
> > |     NE 1 <NSLP-Security> NE 4
> > |?      
> > |
> > |My perception is that it is not necessarily the same, as 
> > also argued in
> > |[Han] concerning reliability.
> > 
> > I share your view, this isn't the same. And your conclusion 
> > is correct:
> > 
> > |If the working group thinks that this is not the same then 
> > it would be
> > |necessary to provide additional security between neighboring 
> > |NSLP peers. 
> > |
> > |As a consequence a discovery mechanism is needed at the NSLP 
> > |to learn the next NSLP node along the path. This is 
> necessary to be 
> > |able to secure signaling messages efficiently (i.e. using 
> symmetric 
> > |cryptography). Hence avoiding the discovery procedure at the NTLP 
> > |was not really beneficial.
> > |Without efficient mechanism it is likely that the mechanisms 
> > |would not be used at all. 
> > |
> > |Securing signaling messages at the NTLP and the NSLP might 
> > |seem to be an overkill to some people. Securing  signaling 
> messages 
> > |only at the NSLP layer does not seem to be sufficient as recently 
> > |discussed (see NSIS ML discussion [NSIS-ML]).
> > 
> > Looks as if there's no solution for having a flexible architecture 
> > combined with security across NTLP and NSLP.
> > 
> > I don't think that we must protect NSLP messages. To protect 
> > against "simple" NSLP DoS attacks then the first NTLP node would 
> > have to check whether the sender of an NTLP message is allowed 
> > to signal for a specific NSLP (given that he's allowed to 
> use NTLP). 
> > This would hold even if this NSLP isn't supported locally. Some 
> > policy communication is required then. 
> > 
> > But no matter how the solution looks like: two peering nodes 
> > shouldn't have to support completely separate security instances 
> > per NTLP/NSLP stack as a consequence of NTLP only handling messages 
> > with specific NSLPs. 
> > 
> > Regards, Rudiger
> > 
> > |4. Reference
> > |
> > |[Han] R. Hancock: "Reliability Functions in the NSIS 
> Transport Layer
> > |Protocol",  <draft-hancock-nsis-reliability-00.txt>,  (work in 
> > |progress),
> > |August 2003
> > |
> > |[NSIS-ML] IETF NSIS Mailing List, "[NSIS] ntlp security 
> > |thoughts, Date: Sun,
> > |13 Jul 2003 14:47:51 +0200",  Available at:
> > |http://www1.ietf.org/mail-archive/working-groups/nsis/current/m
> > |sg03106.html,
> > |(Sep. 2003). 
> > |
> > |
> > |ciao
> > |Hannes
> > |
> > |
> > |_______________________________________________
> > |nsis mailing list
> > |nsis@ietf.org
> > |https://www1.ietf.org/mailman/listinfo/nsis
> > |
> > 
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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



From exim@www1.ietf.org  Wed Sep 24 05:27:23 2003
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 FAA03684
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 05:27:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25vJ-0000Z1-Ic
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 05:27:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O9R14L002148
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 05:27:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25vI-0000YB-OZ; Wed, 24 Sep 2003 05:27:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25uo-0000Xf-K8
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 05:26:30 -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 FAA03658
	for <nsis@ietf.org>; Wed, 24 Sep 2003 05:26:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25ul-0000lA-00
	for nsis@ietf.org; Wed, 24 Sep 2003 05:26:27 -0400
Received: from utrhcs.cs.utwente.nl ([130.89.10.247])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25uk-0000l7-00
	for nsis@ietf.org; Wed, 24 Sep 2003 05:26:26 -0400
Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76])
	by utrhcs.cs.utwente.nl (8.12.10/8.12.9) with SMTP id h8O9QPaK020543;
	Wed, 24 Sep 2003 11:26:25 +0200 (MET DST)
Message-ID: <00a001c3827d$edb2d970$4c0d5982@dynamic.cs.utwente.nl>
From: "Georgios Karagiannis" <karagian@cs.utwente.nl>
To: <john.loughney@nokia.com>
Cc: <nsis@ietf.org>
References: <DADF50F5EC506B41A0F375ABEB320636A8B491@esebe023.ntc.nokia.com>
Subject: Re: [NSIS] Message summarisation ("summary refreshes")
Date: Wed, 24 Sep 2003 11:26:26 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4922.1500
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by utrhcs.cs.utwente.nl id h8O9QPaK020543
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi John

It is a very reasonable proposal.
I also agree with it.

Best Regards,
Georgios

----- Original Message -----
From: <john.loughney@nokia.com>
To: <Ruediger.Geib@t-systems.com>; <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
Sent: Wednesday, September 24, 2003 8:33 AM
Subject: RE: [NSIS] Message summarisation ("summary refreshes")


> Hi R=FCdiger, Robert;
>
> > as I've raised the issue of missing consensus on the layer split
> > in my mail referring to the qos-nslp draft, I must object.
> >
> > Drafts on  NTLP and NSLP now have WG status. To progress them,
> > consensus must be reached on the layer split (soon in my eyes).
> > Maybe author teams of both should meet or there should be an
> > expert team producing a proposal.
> >
> > I agree with you that it isn't a task of a framework
> > document to define this split in detail.
> >
> > I'd be interested in John's view on how/when to solve
> > the layer split issue.
>
> Currently, there is no WG NTLP draft yet, so it is hard to
> say anything about it.  Hopefully Henning/Robert have a
> draft nearly ready for submission.  As the QoS NSLP draft
> has been published, and the NAT/FW NSLP draft should be
> ready shortly (I hope), it seems reasonable to try to target
> discussion in Minneapolis to resolve this issue.  Discussions
> in the framework doc did not produce consensus, so I think
> that framework doc should list issues related to the layer
> split, which should be, then, resolved in the version 01 drafts
> of the NTLP/NSLP protocol(s).
>
> Does this sound reasonable?
>
> John
>
>
> > Regards, R=FCdiger
> >
> > |my feeling is that we should not mandate specific functionality
> > |in the NTLP to do this at this stage, or impose a specific
> > |function split or inter-layer dependency in the framework.
> > |views?
> > |
> > |robert h.
> >
> > _______________________________________________
> > nsis mailing list
> > nsis@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>


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



From exim@www1.ietf.org  Wed Sep 24 05:30:25 2003
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 FAA03793
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 05:30:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25yE-0000l4-FL
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 05:30:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O9U20q002895
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 05:30:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25yD-0000kE-FT; Wed, 24 Sep 2003 05:30:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A25xR-0000em-Iz
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 05:29:13 -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 FAA03779
	for <nsis@ietf.org>; Wed, 24 Sep 2003 05:29:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25xO-0000nv-00
	for nsis@ietf.org; Wed, 24 Sep 2003 05:29:10 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A25xN-0000n9-00
	for nsis@ietf.org; Wed, 24 Sep 2003 05:29:09 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 24 Sep 2003 11:28:26 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJ4Z2V>; Wed, 24 Sep 2003 11:28:26 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB612@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: sven.van_den_bosch@alcatel.be
Cc: nsis@ietf.org
Date: Wed, 24 Sep 2003 11:28:24 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] RE: qos-nslp-00
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: quoted-printable

Hi Sven,

again some in-line comments

|- Retransmitted "Reservation Sequence Numbers"
|  serve as a Session ID. Why aren't
|  the tradeoffs and benefits of combining both
|  functions discussed?
|
|Sven>> We took special care not to use the RSN for anything else but
|ensuring that QoS NSLP message reordering could be detected.=20
|They have nothing to do with any session ID at the NTLP. Afaik, it is=20
|an open issue how NTLP sessions will relate to NSLP message exchanges. =


[Rudi]: Section 4.2 introduces a summary refresh using the RSN to=20
identify a reservation. This isn't related to reordering.

|- A table listing the maximum per session state
|  maintenance requirements is missing.
|
|Sven>> I think it is a bit early for that. I am not completely=20
|sure what you mean: an analysis of the maximum amount of reservation=20
|state associated with a QoS reservation maybe? That might depend on=20
|the QoS model though.

[Rudi]: Leave out the QoS information you don't know. Just inform the=20
reader about the state per reservation as required by the protocol=20
without QoS specific information. I think state maintenance=20
requirements should be considered during early protocol design.=20
This may help to prevent patchwork during a later stage (consider=20
IntServ/RSVP as an example how not to do it).

Regards, R=FCdiger

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



From exim@www1.ietf.org  Wed Sep 24 06:27:23 2003
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 GAA05550
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 06:27:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A26rN-0004CV-S3
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 06:27:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OAR1JQ016141
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 06:27:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A26rN-0004CE-7L; Wed, 24 Sep 2003 06:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A26r2-0004Bu-SB
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 06:26:40 -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 GAA05531
	for <nsis@ietf.org>; Wed, 24 Sep 2003 06:26:31 -0400 (EDT)
From: sven.van_den_bosch@alcatel.be
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A26qy-0001NW-00
	for nsis@ietf.org; Wed, 24 Sep 2003 06:26:36 -0400
Received: from alc240.alcatel.be ([195.207.101.240] helo=relay1.alcatel.be)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A26qy-0001NC-00
	for nsis@ietf.org; Wed, 24 Sep 2003 06:26:36 -0400
Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6])
	by relay1.alcatel.be (8.12.10/8.12.9) with ESMTP id h8OAQ6hj005034
	for <nsis@ietf.org>; Wed, 24 Sep 2003 12:26:06 +0200 (MEST)
To: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF222C7491.3F6D2CB1-ONC1256DAB.0038AC02@net.alcatel.be>
Date: Wed, 24 Sep 2003 12:25:55 +0200
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 09/24/2003 12:26:06
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] RE: qos-nslp-00
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: quoted-printable

Hi Rudi,

Again, in-line ...

Cheers,
Sven





"Geib, Ruediger" <Ruediger.Geib@t-systems.com> on 24/09/2003 11:28:24

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    nsis@ietf.org
Subject:    RE: qos-nslp-00


Hi Sven,

again some in-line comments



|- Retransmitted "Reservation Sequence Numbers"
|  serve as a Session ID. Why aren't
|  the tradeoffs and benefits of combining both
|  functions discussed?
|
|Sven>> We took special care not to use the RSN for anything else but
|ensuring that QoS NSLP message reordering could be detected.
|They have nothing to do with any session ID at the NTLP. Afaik, it is
|an open issue how NTLP sessions will relate to NSLP message exchanges.=


[Rudi]: Section 4.2 introduces a summary refresh using the RSN to
identify a reservation. This isn't related to reordering.

Sven>> It is used in the summary refresh, but this is purely a QoS NSLP=

matter that is unrelated to the session ID. Note that we see the summar=
y
refresh with RSN as a minimal case but that other objects or parameters=
 may
be part of it.

|- A table listing the maximum per session state
|  maintenance requirements is missing.
|
|Sven>> I think it is a bit early for that. I am not completely
|sure what you mean: an analysis of the maximum amount of reservation
|state associated with a QoS reservation maybe? That might depend on
|the QoS model though.

[Rudi]: Leave out the QoS information you don't know. Just inform the
reader about the state per reservation as required by the protocol
without QoS specific information. I think state maintenance
requirements should be considered during early protocol design.
This may help to prevent patchwork during a later stage (consider
IntServ/RSVP as an example how not to do it).

Sven>> We can take it up in the discussions for the next version.

 Regards, R=FCdiger



=



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



From exim@www1.ietf.org  Wed Sep 24 07:28:25 2003
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 HAA07622
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 07:28:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27oP-0000Bz-E7
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 07:28:01 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBS18P000733
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 07:28:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27oO-0000BU-Ny; Wed, 24 Sep 2003 07:28:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27nh-0008SV-3M
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 07:27:17 -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 HAA07518
	for <nsis@ietf.org>; Wed, 24 Sep 2003 07:27:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A27ng-00024T-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:27:16 -0400
Received: from lion.seas.upenn.edu ([158.130.12.194])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A27nf-000247-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:27:15 -0400
Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176])
	by lion.seas.upenn.edu (8.12.10/8.12.8) with ESMTP id h8OBQpr2010842
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT);
	Wed, 24 Sep 2003 07:26:52 -0400
Received: from red.seas.upenn.edu (localhost [127.0.0.1])
	by red.seas.upenn.edu (8.12.10/8.12.9) with ESMTP id h8OBQp7q013477;
	Wed, 24 Sep 2003 07:26:51 -0400 (EDT)
Received: from localhost (rsofia@localhost)
	by red.seas.upenn.edu (8.12.10/8.12.9/Submit) with ESMTP id h8OBQpO4013474;
	Wed, 24 Sep 2003 07:26:51 -0400 (EDT)
Date: Wed, 24 Sep 2003 07:26:51 -0400 (EDT)
From: "Rute C. Sofia" <rsofia@seas.upenn.edu>
To: sven.van_den_bosch@alcatel.be
cc: nsis@ietf.org
Subject: Re: [NSIS] Re: qos-nslp-00
In-Reply-To: <OF0A92C7D0.7967C832-ONC1256DAB.00222487@net.alcatel.be>
Message-ID: <Pine.GSO.4.58.0309240709220.29102@red.seas.upenn.edu>
References: <OF0A92C7D0.7967C832-ONC1256DAB.00222487@net.alcatel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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>

Hi Sven,

great work for a 00 version. Some general comments:

- Abstract:
* would change "provides functionality similar to RSVP and extends it" to
something less RSVP-oriented :)

* would change "it is simplified by the elimination of support for
multicast" to something as "it does not address multicast support" (which
you actually say a couple of paragraphs after)

- section 1.1, 2nd paragraph:
* soft-state is mentioned as "the primary state management". Which are the
other options? From what I've read, it seems that qos-nslp is thought to
operate in either a state or stateless mode; for the former, soft-state is
the only choice.

- section 1.3 Terminology:
would simply change the order of the items, so the QNE would appear as the
first item;

- section 2. Protocol design
this part is a bit confusing; 2.1 simply describes the set of messages;
section 2.2 describes the concept of "QoS model" (which again, seems
confusing and out of place here). Perhaps an example would help here.

- section 3. messages
*couldn't the four messages used be simplified to two? It seems to me that
a Notify or a Response purpose could be served by a Reserve.
* also, this section overlaps a bit with 2., in the sense that the
reservation setup, queries, notifications and so on are exemplified
here...perhaps these two sections should be re-written...

Regards,
Rute

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



From exim@www1.ietf.org  Wed Sep 24 07:29:26 2003
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 HAA07694
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 07:29:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27pO-0000JJ-DW
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 07:29:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBT2T5001174
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 07:29:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27pO-0000IC-2X; Wed, 24 Sep 2003 07:29:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27oN-0000BE-Ug
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 07:27:59 -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 HAA07595
	for <nsis@ietf.org>; Wed, 24 Sep 2003 07:27:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A27oN-00025t-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:27:59 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A27oM-00025L-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:27:58 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 24 Sep 2003 13:26:32 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJVBZZ>; Wed, 24 Sep 2003 13:26:31 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB613@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: sven.van_den_bosch@alcatel.be
Cc: nsis@ietf.org
Date: Wed, 24 Sep 2003 13:26:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Subject: [NSIS] RE: qos-nslp-00
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: quoted-printable

Hi Sven,

maybe we have different concepts of what a session ID identifies.=20
To me it identifies the flow of packets for which you request a=20
service by NSIS signaling. I think that is exactly what you use=20
the RSN for in the case of refreshes.
What is your definition of session ID?

Regards, R=FCdiger

||- Retransmitted "Reservation Sequence Numbers"
||  serve as a Session ID. Why aren't
||  the tradeoffs and benefits of combining both
||  functions discussed?
||
||Sven>> We took special care not to use the RSN for anything else but
||ensuring that QoS NSLP message reordering could be detected.
||They have nothing to do with any session ID at the NTLP. Afaik, it is
||an open issue how NTLP sessions will relate to NSLP message =
exchanges.
|
|[Rudi]: Section 4.2 introduces a summary refresh using the RSN to
|identify a reservation. This isn't related to reordering.
|
|Sven>> It is used in the summary refresh, but this is purely a QoS =
NSLP
|matter that is unrelated to the session ID. Note that we see=20
|the summary refresh with RSN as a minimal case but that other objects
|or parameters may be part of it.

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



From exim@www1.ietf.org  Wed Sep 24 07:36:24 2003
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 HAA08060
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 07:36:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27w8-0001CQ-Ov
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 07:36:00 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBa0rX004575
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 07:36:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27w8-0001Bf-Cw; Wed, 24 Sep 2003 07:36:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A27vW-0000zC-5G
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 07:35:22 -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 HAA07985
	for <nsis@ietf.org>; Wed, 24 Sep 2003 07:35:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A27vV-0002DP-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:35:21 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A27vU-0002DK-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:35:20 -0400
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h8OBZ9p28668;
	Wed, 24 Sep 2003 13:35:10 +0200 (MEST)
Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h8OBZ9n21996;
	Wed, 24 Sep 2003 13:35:09 +0200 (MEST)
Received: from mchh274e.mchh.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84])
	by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id NAA08329;
	Wed, 24 Sep 2003 13:33:41 +0200 (MET DST)
Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59)
	id <SW3M7AJW>; Wed, 24 Sep 2003 13:34:20 +0200
Message-ID: <4D486782CA36D4118A530000D11EA42A022C79B4@blns204e.bln.icn.siemens.de>
From: Kappler Cornelia <cornelia.kappler@siemens.com>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>,
        sven.van_den_bosch@alcatel.be
Cc: nsis@ietf.org
Subject: AW: [NSIS] RE: qos-nslp-00
Date: Wed, 24 Sep 2003 13:34:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Ruediger,=20

the RSN identifies a specific RESERVE message, whereas the session ID =
identifies a session, during which many RESERVE messages may be issued.

Cornelia

> -----Urspr=FCngliche Nachricht-----
> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Gesendet: Mittwoch, 24. September 2003 13:26
> An: sven.van_den_bosch@alcatel.be
> Cc: nsis@ietf.org
> Betreff: [NSIS] RE: qos-nslp-00
>=20
>=20
> Hi Sven,
>=20
> maybe we have different concepts of what a session ID identifies.=20
> To me it identifies the flow of packets for which you request a=20
> service by NSIS signaling. I think that is exactly what you use=20
> the RSN for in the case of refreshes.
> What is your definition of session ID?
>=20
> Regards, R=FCdiger
>=20
> ||- Retransmitted "Reservation Sequence Numbers"
> ||  serve as a Session ID. Why aren't
> ||  the tradeoffs and benefits of combining both
> ||  functions discussed?
> ||
> ||Sven>> We took special care not to use the RSN for anything else =
but
> ||ensuring that QoS NSLP message reordering could be detected.
> ||They have nothing to do with any session ID at the NTLP.=20
> Afaik, it is
> ||an open issue how NTLP sessions will relate to NSLP message=20
> exchanges.
> |
> |[Rudi]: Section 4.2 introduces a summary refresh using the RSN to
> |identify a reservation. This isn't related to reordering.
> |
> |Sven>> It is used in the summary refresh, but this is purely=20
> a QoS NSLP
> |matter that is unrelated to the session ID. Note that we see=20
> |the summary refresh with RSN as a minimal case but that other =
objects
> |or parameters may be part of it.
>=20
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>=20

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



From exim@www1.ietf.org  Wed Sep 24 08:00:33 2003
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 IAA09260
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 08:00:33 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28JS-0004Tb-EC
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:00:07 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OC03vY017120
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:00:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28JO-0004Rn-Ce; Wed, 24 Sep 2003 08:00:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28JH-0004R3-L1
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 07:59:55 -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 HAA09197
	for <nsis@ietf.org>; Wed, 24 Sep 2003 07:59:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28JG-0002cL-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:59:54 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28JG-0002ba-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:59:54 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TNNBR52G>; Wed, 24 Sep 2003 12:59:18 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A709385DA@rsys004a.roke.co.uk>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Rute C. Sofia'" <rsofia@seas.upenn.edu>, sven.van_den_bosch@alcatel.be
Cc: nsis@ietf.org
Subject: RE: [NSIS] Re: qos-nslp-00
Date: Wed, 24 Sep 2003 12:59:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-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>

hi all,

a specific comment:

> - section 3. messages
> *couldn't the four messages used be simplified to two? It 
> seems to me that
> a Notify or a Response purpose could be served by a Reserve.
> * also, this section overlaps a bit with 2., in the sense that the
> reservation setup, queries, notifications and so on are exemplified
> here...perhaps these two sections should be re-written...
> 
> Regards,
> Rute

you wouldn't believe the amount of discussion there was about
this sort of thing. in the end, some of the message distinctions
can get slightly blurred, but I'm very keen to keep a clear 
border around 'RESERVE' because that message has a number of
unique properties:
*) processing it is supposed to change signalling application state
*) therefore in particular authorisation for a RESERVE matters more
than for most other messages
*) also, RESERVEs need to have lifetimes associated (whereas no
other message does) to represent the lifetime of the state
*) you only care about the latest in sequence you have received
*) probably some other differences too.

in formally analysing protocol behaviour - especially a protocol
which is at least partly a container protocol (for qspecs and
policy objects and so on, whose details are deliberately not
constrained) - I think it's very important to have conceptual
distinctions between different message types laid down like this.

(you could also ask if these distinctions should be encoded in 
message types or object types. for near term activities i prefer
the former, but it's a good question.)

cheers,

r.

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



From exim@www1.ietf.org  Wed Sep 24 08:00:34 2003
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 IAA09275
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 08:00:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28JW-0004aW-C3
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:00:10 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OC08xp017304
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:00:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28JR-0004Sb-D7; Wed, 24 Sep 2003 08:00:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28JJ-0004R9-UP
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 07:59:57 -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 HAA09200
	for <nsis@ietf.org>; Wed, 24 Sep 2003 07:59:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28JI-0002cQ-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:59:56 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28JI-0002bb-00
	for nsis@ietf.org; Wed, 24 Sep 2003 07:59:56 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 24 Sep 2003 13:59:15 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJV1HS>; Wed, 24 Sep 2003 13:59:15 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB614@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: cornelia.kappler@siemens.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: qos-nslp-00
Date: Wed, 24 Sep 2003 13:59:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Cornelia,

if it is important to identify a reserve message by a=20
refresh instead of a session, then I'd appreciate text=20
on the protocol reaction if the refresh's RSN can't=20
be matched with local state. The following occasions=20
may occur:
- no similar RSN
- local RSN bigger then refresh RSN
- local RSN smaller then refresh RSN

I'd suggest at least a placeholder for the issue in the next=20
version.=20

Regards, R=FCdiger

|the RSN identifies a specific RESERVE message, whereas the=20
|session ID identifies a session, during which many RESERVE=20
|messages may be issued.
|
|Cornelia
|
|> -----Urspr=FCngliche Nachricht-----
|> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
|> Gesendet: Mittwoch, 24. September 2003 13:26
|> An: sven.van_den_bosch@alcatel.be
|> Cc: nsis@ietf.org
|> Betreff: [NSIS] RE: qos-nslp-00
|>=20
|>=20
|> Hi Sven,
|>=20
|> maybe we have different concepts of what a session ID identifies.=20
|> To me it identifies the flow of packets for which you request a=20
|> service by NSIS signaling. I think that is exactly what you use=20
|> the RSN for in the case of refreshes.
|> What is your definition of session ID?
|>=20
|> Regards, R=FCdiger
|>=20
|> ||- Retransmitted "Reservation Sequence Numbers"
|> ||  serve as a Session ID. Why aren't
|> ||  the tradeoffs and benefits of combining both
|> ||  functions discussed?
|> ||
|> ||Sven>> We took special care not to use the RSN for=20
|anything else but
|> ||ensuring that QoS NSLP message reordering could be detected.
|> ||They have nothing to do with any session ID at the NTLP.=20
|> Afaik, it is
|> ||an open issue how NTLP sessions will relate to NSLP message=20
|> exchanges.
|> |
|> |[Rudi]: Section 4.2 introduces a summary refresh using the RSN to
|> |identify a reservation. This isn't related to reordering.
|> |
|> |Sven>> It is used in the summary refresh, but this is purely=20
|> a QoS NSLP
|> |matter that is unrelated to the session ID. Note that we see=20
|> |the summary refresh with RSN as a minimal case but that=20
|other objects
|> |or parameters may be part of it.
|>=20
|> _______________________________________________
|> nsis mailing list
|> nsis@ietf.org
|> https://www1.ietf.org/mailman/listinfo/nsis
|>=20
|

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



From exim@www1.ietf.org  Wed Sep 24 08:20:30 2003
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 IAA10308
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 08:20:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28cn-0006Pt-K7
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:20:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OCK4Xp024623
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:20:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28cl-0006P3-6j; Wed, 24 Sep 2003 08:20:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28cY-0006KU-7S
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 08:19:50 -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 IAA10299
	for <nsis@ietf.org>; Wed, 24 Sep 2003 08:19:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28cX-00031I-00
	for nsis@ietf.org; Wed, 24 Sep 2003 08:19:49 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28cW-00031F-00
	for nsis@ietf.org; Wed, 24 Sep 2003 08:19:48 -0400
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h8OCJkp16704;
	Wed, 24 Sep 2003 14:19:46 +0200 (MEST)
Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206])
	by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h8OCJkn14993;
	Wed, 24 Sep 2003 14:19:46 +0200 (MEST)
Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57])
	by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA16927;
	Wed, 24 Sep 2003 14:18:18 +0200 (MET DST)
Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59)
	id <SWNB41DB>; Wed, 24 Sep 2003 14:18:57 +0200
Message-ID: <4D486782CA36D4118A530000D11EA42A022C79B5@blns204e.bln.icn.siemens.de>
From: Kappler Cornelia <cornelia.kappler@siemens.com>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
Subject: AW: [NSIS] RE: qos-nslp-00
Date: Wed, 24 Sep 2003 14:18:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Ruediger,

We deliberately refer to the state to be refreshed by the RSN =
(minimally) rather than by the session ID.=20

Summary refreshes should be handled with caution, we should be sure it =
is the correct state that is being refreshed. If we just use session =
ID, we dont know what possibly obsolete state might be refreshed. By =
matching the RSN in the summary refresh with the locally stored RSN, a =
nodes knows whether it is refreshing the correct state.=20

Vice versa, when the RSN in the summary refresh does not match the =
local RSN, the refresh will be disregared - which makes sense, because =
a problem must have occurred (i.e. a node does not have the most =
up-to-date state information).

Originally the idea was to make RSNs monotonically increasing (remember =
they have only local significance), so the newest RESERVE can always be =
identified. For some reason this idea didnt make it into the current =
version of the ID (I just noticed) I am not sure this was on purpose.

Of course all this should become clear from reading the ID. We should =
check where it can be clarified.=20

Does this address your concerns?

Cornelia

> -----Urspr=FCngliche Nachricht-----
> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Gesendet: Mittwoch, 24. September 2003 13:59
> An: cornelia.kappler@siemens.com
> Cc: nsis@ietf.org
> Betreff: RE: [NSIS] RE: qos-nslp-00
>=20
>=20
> Hi Cornelia,
>=20
> if it is important to identify a reserve message by a=20
> refresh instead of a session, then I'd appreciate text=20
> on the protocol reaction if the refresh's RSN can't=20
> be matched with local state. The following occasions=20
> may occur:
> - no similar RSN
> - local RSN bigger then refresh RSN
> - local RSN smaller then refresh RSN
>=20
> I'd suggest at least a placeholder for the issue in the next=20
> version.=20
>=20
> Regards, R=FCdiger
>=20
> |the RSN identifies a specific RESERVE message, whereas the=20
> |session ID identifies a session, during which many RESERVE=20
> |messages may be issued.
> |
> |Cornelia
> |
> |> -----Urspr=FCngliche Nachricht-----
> |> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> |> Gesendet: Mittwoch, 24. September 2003 13:26
> |> An: sven.van_den_bosch@alcatel.be
> |> Cc: nsis@ietf.org
> |> Betreff: [NSIS] RE: qos-nslp-00
> |>=20
> |>=20
> |> Hi Sven,
> |>=20
> |> maybe we have different concepts of what a session ID identifies.=20
> |> To me it identifies the flow of packets for which you request a=20
> |> service by NSIS signaling. I think that is exactly what you use=20
> |> the RSN for in the case of refreshes.
> |> What is your definition of session ID?
> |>=20
> |> Regards, R=FCdiger
> |>=20
> |> ||- Retransmitted "Reservation Sequence Numbers"
> |> ||  serve as a Session ID. Why aren't
> |> ||  the tradeoffs and benefits of combining both
> |> ||  functions discussed?
> |> ||
> |> ||Sven>> We took special care not to use the RSN for=20
> |anything else but
> |> ||ensuring that QoS NSLP message reordering could be detected.
> |> ||They have nothing to do with any session ID at the NTLP.=20
> |> Afaik, it is
> |> ||an open issue how NTLP sessions will relate to NSLP message=20
> |> exchanges.
> |> |
> |> |[Rudi]: Section 4.2 introduces a summary refresh using the RSN to
> |> |identify a reservation. This isn't related to reordering.
> |> |
> |> |Sven>> It is used in the summary refresh, but this is purely=20
> |> a QoS NSLP
> |> |matter that is unrelated to the session ID. Note that we see=20
> |> |the summary refresh with RSN as a minimal case but that=20
> |other objects
> |> |or parameters may be part of it.
> |>=20
> |> _______________________________________________
> |> nsis mailing list
> |> nsis@ietf.org
> |> https://www1.ietf.org/mailman/listinfo/nsis
> |>=20
> |
>=20

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



From exim@www1.ietf.org  Wed Sep 24 08:35:26 2003
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 IAA10896
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 08:35:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28rH-0007II-8A
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:35:03 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OCZ3SR028020
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:35:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28rG-0007Hi-J2; Wed, 24 Sep 2003 08:35:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28qy-0007H9-0l
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 08:34:44 -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 IAA10879
	for <nsis@ietf.org>; Wed, 24 Sep 2003 08:34:36 -0400 (EDT)
From: sven.van_den_bosch@alcatel.be
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28qw-0003DX-00
	for nsis@ietf.org; Wed, 24 Sep 2003 08:34:42 -0400
Received: from alc240.alcatel.be ([195.207.101.240] helo=relay1.alcatel.be)
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28qv-0003D6-00
	for nsis@ietf.org; Wed, 24 Sep 2003 08:34:41 -0400
Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6])
	by relay1.alcatel.be (8.12.10/8.12.9) with ESMTP id h8OCY9hj019623;
	Wed, 24 Sep 2003 14:34:09 +0200 (MEST)
Subject: Re: AW: [NSIS] RE: qos-nslp-00
To: Kappler Cornelia <cornelia.kappler@siemens.com>
Cc: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>, nsis@ietf.org
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <OF6469B4DE.F75C1AB8-ONC1256DAB.00449652@net.alcatel.be>
Date: Wed, 24 Sep 2003 14:33:57 +0200
X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11  |July 24, 2002) at
 09/24/2003 14:34:08
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Cornelia, Ruediger,

Just a slight clarification to Cornelia's mail. We discussed the need t=
o
increase the RSN for refreshes. It is not needed for ordering purposes =
in
case of pure refreshes because it doesn't really matter in which order =
they
arrive. So the RSN needs to be increased only when you change something=
 in
the reservation state.

Cheers,
Sven






Kappler Cornelia <cornelia.kappler@siemens.com>@ietf.org on 24/09/2003
14:18:55

Sent by:    nsis-admin@ietf.org


To:    "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>
cc:    nsis@ietf.org
Subject:    AW: [NSIS] RE: qos-nslp-00


Hi Ruediger,

We deliberately refer to the state to be refreshed by the RSN (minimall=
y)
rather than by the session ID.

Summary refreshes should be handled with caution, we should be sure it =
is
the correct state that is being refreshed. If we just use session ID, w=
e
dont know what possibly obsolete state might be refreshed. By matching =
the
RSN in the summary refresh with the locally stored RSN, a nodes knows
whether it is refreshing the correct state.

Vice versa, when the RSN in the summary refresh does not match the loca=
l
RSN, the refresh will be disregared - which makes sense, because a prob=
lem
must have occurred (i.e. a node does not have the most up-to-date state=

information).

Originally the idea was to make RSNs monotonically increasing (remember=

they have only local significance), so the newest RESERVE can always be=

identified. For some reason this idea didnt make it into the current
version of the ID (I just noticed) I am not sure this was on purpose.

Of course all this should become clear from reading the ID. We should c=
heck
where it can be clarified.

Does this address your concerns?

Cornelia

> -----Urspr=FCngliche Nachricht-----
> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> Gesendet: Mittwoch, 24. September 2003 13:59
> An: cornelia.kappler@siemens.com
> Cc: nsis@ietf.org
> Betreff: RE: [NSIS] RE: qos-nslp-00
>
>
> Hi Cornelia,
>
> if it is important to identify a reserve message by a
> refresh instead of a session, then I'd appreciate text
> on the protocol reaction if the refresh's RSN can't
> be matched with local state. The following occasions
> may occur:
> - no similar RSN
> - local RSN bigger then refresh RSN
> - local RSN smaller then refresh RSN
>
> I'd suggest at least a placeholder for the issue in the next
> version.
>
> Regards, R=FCdiger
>
> |the RSN identifies a specific RESERVE message, whereas the
> |session ID identifies a session, during which many RESERVE
> |messages may be issued.
> |
> |Cornelia
> |
> |> -----Urspr=FCngliche Nachricht-----
> |> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
> |> Gesendet: Mittwoch, 24. September 2003 13:26
> |> An: sven.van_den_bosch@alcatel.be
> |> Cc: nsis@ietf.org
> |> Betreff: [NSIS] RE: qos-nslp-00
> |>
> |>
> |> Hi Sven,
> |>
> |> maybe we have different concepts of what a session ID identifies.
> |> To me it identifies the flow of packets for which you request a
> |> service by NSIS signaling. I think that is exactly what you use
> |> the RSN for in the case of refreshes.
> |> What is your definition of session ID?
> |>
> |> Regards, R=FCdiger
> |>
> |> ||- Retransmitted "Reservation Sequence Numbers"
> |> ||  serve as a Session ID. Why aren't
> |> ||  the tradeoffs and benefits of combining both
> |> ||  functions discussed?
> |> ||
> |> ||Sven>> We took special care not to use the RSN for
> |anything else but
> |> ||ensuring that QoS NSLP message reordering could be detected.
> |> ||They have nothing to do with any session ID at the NTLP.
> |> Afaik, it is
> |> ||an open issue how NTLP sessions will relate to NSLP message
> |> exchanges.
> |> |
> |> |[Rudi]: Section 4.2 introduces a summary refresh using the RSN to=

> |> |identify a reservation. This isn't related to reordering.
> |> |
> |> |Sven>> It is used in the summary refresh, but this is purely
> |> a QoS NSLP
> |> |matter that is unrelated to the session ID. Note that we see
> |> |the summary refresh with RSN as a minimal case but that
> |other objects
> |> |or parameters may be part of it.
> |>
> |> _______________________________________________
> |> nsis mailing list
> |> nsis@ietf.org
> |> https://www1.ietf.org/mailman/listinfo/nsis
> |>
> |
>

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


=



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



From exim@www1.ietf.org  Wed Sep 24 08:36:25 2003
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 IAA10949
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 08:36:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28sE-0007Oz-71
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:36:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OCa2bK028392
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 08:36:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28sD-0007NK-NG; Wed, 24 Sep 2003 08:36:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A28s5-0007Mz-SY
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 08:35:53 -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 IAA10924
	for <nsis@ietf.org>; Wed, 24 Sep 2003 08:35:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28s4-0003Ei-00
	for nsis@ietf.org; Wed, 24 Sep 2003 08:35:52 -0400
Received: from rsys002a.roke.co.uk ([193.118.192.251])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A28s4-0003Du-00
	for nsis@ietf.org; Wed, 24 Sep 2003 08:35:52 -0400
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19)
	id <TNNBR5J4>; Wed, 24 Sep 2003 13:35:21 +0100
Message-ID: <EA943CD30BCB104E9D38F5B5DC2D9A7014AEB3@rsys004a.roke.co.uk>
From: "McDonald, Andrew" <andrew.mcdonald@roke.co.uk>
To: "'Kappler Cornelia'" <cornelia.kappler@siemens.com>,
        "'Geib, Ruediger'"
	 <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: qos-nslp-00
Date: Wed, 24 Sep 2003 13:35:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hi Cornelia, Ruediger,

I'm sure the phrase "monotonically increasing sequence number" was used =
to describe the RSN at some point, but it appears to have got lost in =
one of the rewrites.

Andrew


Kappler Cornelia wrote:
> Hi Ruediger,
>=20
> We deliberately refer to the state to be refreshed by the RSN
> (minimally) rather than by the session ID.=20
>=20
> Summary refreshes should be handled with caution, we should be sure
> it is the correct state that is being refreshed. If we just use
> session ID, we dont know what possibly obsolete state might be
> refreshed. By matching the RSN in the summary refresh with the
> locally stored RSN, a nodes knows whether it is refreshing the
> correct state.    =20
>=20
> Vice versa, when the RSN in the summary refresh does not match the
> local RSN, the refresh will be disregared - which makes sense,
> because a problem must have occurred (i.e. a node does not have the
> most up-to-date state information).  =20
>=20
> Originally the idea was to make RSNs monotonically increasing
> (remember they have only local significance), so the newest RESERVE
> can always be identified. For some reason this idea didnt make it
> into the current version of the ID (I just noticed) I am not sure
> this was on purpose.   =20
>=20
> Of course all this should become clear from reading the ID. We should
> check where it can be clarified.=20
>=20
> Does this address your concerns?
>=20
> Cornelia
>=20
>> -----Urspr=FCngliche Nachricht-----
>> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
>> Gesendet: Mittwoch, 24. September 2003 13:59
>> An: cornelia.kappler@siemens.com
>> Cc: nsis@ietf.org
>> Betreff: RE: [NSIS] RE: qos-nslp-00
>>=20
>>=20
>> Hi Cornelia,
>>=20
>> if it is important to identify a reserve message by a
>> refresh instead of a session, then I'd appreciate text
>> on the protocol reaction if the refresh's RSN can't
>> be matched with local state. The following occasions
>> may occur:
>> - no similar RSN
>> - local RSN bigger then refresh RSN
>> - local RSN smaller then refresh RSN
>>=20
>> I'd suggest at least a placeholder for the issue in the next =
version.
>>=20
>> Regards, R=FCdiger
>>=20
>>> the RSN identifies a specific RESERVE message, whereas the
>>> session ID identifies a session, during which many RESERVE messages
>>> may be issued.=20
>>>=20
>>> Cornelia
>>>=20
>>>> -----Urspr=FCngliche Nachricht-----
>>>> Von: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com]
>>>> Gesendet: Mittwoch, 24. September 2003 13:26
>>>> An: sven.van_den_bosch@alcatel.be
>>>> Cc: nsis@ietf.org
>>>> Betreff: [NSIS] RE: qos-nslp-00
>>>>=20
>>>>=20
>>>> Hi Sven,
>>>>=20
>>>> maybe we have different concepts of what a session ID identifies.
>>>> To me it identifies the flow of packets for which you request a
>>>> service by NSIS signaling. I think that is exactly what you use
>>>> the RSN for in the case of refreshes.
>>>> What is your definition of session ID?
>>>>=20
>>>> Regards, R=FCdiger
>>>>=20
>>>>>> - Retransmitted "Reservation Sequence Numbers"
>>>>>>  serve as a Session ID. Why aren't
>>>>>>  the tradeoffs and benefits of combining both
>>>>>>  functions discussed?
>>>>>>=20
>>>>>> Sven>> We took special care not to use the RSN for anything else
>>>>>> but ensuring that QoS NSLP message reordering could be detected.
>>>>>> They have nothing to do with any session ID at the NTLP. Afaik,
>>>>>> it is an open issue how NTLP sessions will relate to NSLP
>>>>>> message exchanges.=20
>>>>>=20
>>>>> [Rudi]: Section 4.2 introduces a summary refresh using the RSN to
>>>>> identify a reservation. This isn't related to reordering.
>>>>>=20
>>>>> Sven>> It is used in the summary refresh, but this is purely a
>>>>> QoS NSLP matter that is unrelated to the session ID. Note that we
>>>>> see=20
>>>>> the summary refresh with RSN as a minimal case but that other
>>>>> objects or parameters may be part of it.
>>>>=20
>>>> _______________________________________________
>>>> nsis mailing list
>>>> nsis@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/nsis
>>>>=20
>>>=20
>>=20
>=20
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis

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



From exim@www1.ietf.org  Wed Sep 24 09:04:25 2003
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 JAA11972
	for <nsis-archive@odin.ietf.org>; Wed, 24 Sep 2003 09:04:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A29JK-0000wg-84
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 09:04:02 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OD42WL003615
	for nsis-archive@odin.ietf.org; Wed, 24 Sep 2003 09:04:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A29JJ-0000w9-N4; Wed, 24 Sep 2003 09:04:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A29IT-0000vQ-59
	for nsis@optimus.ietf.org; Wed, 24 Sep 2003 09:03:09 -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 JAA11950
	for <nsis@ietf.org>; Wed, 24 Sep 2003 09:03:01 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A29IR-0003Yx-00
	for nsis@ietf.org; Wed, 24 Sep 2003 09:03:07 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A29IQ-0003YR-00
	for nsis@ietf.org; Wed, 24 Sep 2003 09:03:07 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 24 Sep 2003 14:59:13 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJVJAW>; Wed, 24 Sep 2003 14:59:13 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB615@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: cornelia.kappler@siemens.com
Cc: nsis@ietf.org
Subject: RE: [NSIS] RE: qos-nslp-00
Date: Wed, 24 Sep 2003 14:59:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hello Cornelia,

my comments may be found in line.

Regards, R=FCdiger

|We deliberately refer to the state to be refreshed by the RSN=20
|(minimally) rather than by the session ID.=20
|
|Summary refreshes should be handled with caution, we should be=20
|sure it is the correct state that is being refreshed. If we=20
|just use session ID, we dont know what possibly obsolete state=20
|might be refreshed. By matching the RSN in the summary refresh=20
|with the locally stored RSN, a nodes knows whether it is=20
|refreshing the correct state.=20
|
|Vice versa, when the RSN in the summary refresh does not match=20
|the local RSN, the refresh will be disregared - which makes=20
|sense, because a problem must have occurred (i.e. a node does=20
|not have the most up-to-date state information).

Yes, and this node could be the one ignoring the refresh with=20
the sequence number not matching the on in his local database.

|Originally the idea was to make RSNs monotonically increasing=20
|(remember they have only local significance), so the newest=20
|RESERVE can always be identified. For some reason this idea=20
|didnt make it into the current version of the ID (I just=20
|noticed) I am not sure this was on purpose.
|
|Of course all this should become clear from reading the ID. We=20
|should check where it can be clarified.=20
|
|Does this address your concerns?

Not quite. But I'll wait for the authors to produce some=20
more text.

|Cornelia
|

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



From exim@www1.ietf.org  Thu Sep 25 04:37:36 2003
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 EAA13940
	for <nsis-archive@odin.ietf.org>; Thu, 25 Sep 2003 04:37:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A2Rcd-00081V-MT
	for nsis-archive@odin.ietf.org; Thu, 25 Sep 2003 04:37:12 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8P8bBfP030812
	for nsis-archive@odin.ietf.org; Thu, 25 Sep 2003 04:37:11 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A2RcV-0007zb-SM; Thu, 25 Sep 2003 04:37:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A2RcO-0007z1-IZ
	for nsis@optimus.ietf.org; Thu, 25 Sep 2003 04:36:56 -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 EAA13893
	for <nsis@ietf.org>; Thu, 25 Sep 2003 04:36:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A2RcK-0002i7-00
	for nsis@ietf.org; Thu, 25 Sep 2003 04:36:52 -0400
Received: from goliath.siemens.de ([192.35.17.28])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A2RcJ-0002i4-00
	for nsis@ietf.org; Thu, 25 Sep 2003 04:36:52 -0400
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11])
	by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h8P8aop18452;
	Thu, 25 Sep 2003 10:36:50 +0200 (MEST)
Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206])
	by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h8P8amZ24543;
	Thu, 25 Sep 2003 10:36:48 +0200 (MEST)
Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83])
	by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA04324;
	Thu, 25 Sep 2003 10:35:20 +0200 (MET DST)
Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2656.59)
	id <SW32XZ75>; Thu, 25 Sep 2003 10:36:00 +0200
Message-ID: <4D486782CA36D4118A530000D11EA42A022C79B9@blns204e.bln.icn.siemens.de>
From: Kappler Cornelia <cornelia.kappler@siemens.com>
To: "'Geib, Ruediger'" <Ruediger.Geib@t-systems.com>
Cc: nsis@ietf.org
Subject: AW: [NSIS] RE: qos-nslp-00
Date: Thu, 25 Sep 2003 10:35:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-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>

One comment inline. Cornelia
 
> |We deliberately refer to the state to be refreshed by the RSN 
> |(minimally) rather than by the session ID. 
> |
> |Summary refreshes should be handled with caution, we should be 
> |sure it is the correct state that is being refreshed. If we 
> |just use session ID, we dont know what possibly obsolete state 
> |might be refreshed. By matching the RSN in the summary refresh 
> |with the locally stored RSN, a nodes knows whether it is 
> |refreshing the correct state. 
> |
> |Vice versa, when the RSN in the summary refresh does not match 
> |the local RSN, the refresh will be disregared - which makes 
> |sense, because a problem must have occurred (i.e. a node does 
> |not have the most up-to-date state information).
> 
> Yes, and this node could be the one ignoring the refresh with 
> the sequence number not matching the on in his local database.

Exactly. Do I take it correctly you consider this a drawback rather than a virtue? Why that?

> 
> |Originally the idea was to make RSNs monotonically increasing 
> |(remember they have only local significance), so the newest 
> |RESERVE can always be identified. For some reason this idea 
> |didnt make it into the current version of the ID (I just 
> |noticed) I am not sure this was on purpose.
> |
> |Of course all this should become clear from reading the ID. We 
> |should check where it can be clarified. 
> |
> |Does this address your concerns?
> 
> Not quite. But I'll wait for the authors to produce some 
> more text.
> 
> |Cornelia
> |
> 

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



From exim@www1.ietf.org  Thu Sep 25 06:05:29 2003
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 GAA16587
	for <nsis-archive@odin.ietf.org>; Thu, 25 Sep 2003 06:05:27 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A2Szi-0004Da-Av
	for nsis-archive@odin.ietf.org; Thu, 25 Sep 2003 06:05:06 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PA56SS016195
	for nsis-archive@odin.ietf.org; Thu, 25 Sep 2003 06:05:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A2Szd-0004CX-S5; Thu, 25 Sep 2003 06:05:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A2Syn-0004Bi-QV
	for nsis@optimus.ietf.org; Thu, 25 Sep 2003 06:04:09 -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 GAA16539
	for <nsis@ietf.org>; Thu, 25 Sep 2003 06:04:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A2Syj-0003a3-00
	for nsis@ietf.org; Thu, 25 Sep 2003 06:04:05 -0400
Received: from mail1.telekom.de ([62.225.183.202])
	by ietf-mx with esmtp (Exim 4.12)
	id 1A2Syj-0003ZV-00
	for nsis@ietf.org; Thu, 25 Sep 2003 06:04:05 -0400
Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 25 Sep 2003 11:55:43 +0200
Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <TNCJWY07>; Thu, 25 Sep 2003 11:55:42 +0200
Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB61A@G8PQD.blf01.telekom.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: cornelia.kappler@siemens.com
Cc: nsis@ietf.org
Subject:  [NSIS] RE: qos-nslp-00
Date: Thu, 25 Sep 2003 11:55:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
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: quoted-printable

Hello Cornelia,

it is not clear to me how the local node reacts once it learns=20
that it maintains stale state. If the only answer is "not at all"=20
I can't see a benefit of the RSN method against session ID based=20
refreshes. On the opposite, the state you have to maintain=20
locally will increase (besides session ID you will have to store=20
incoming and outgoing RSN).

Regards, R=FCdiger=20

|> |We deliberately refer to the state to be refreshed by the RSN=20
|> |(minimally) rather than by the session ID.=20
|> |
|> |Summary refreshes should be handled with caution, we should be=20
|> |sure it is the correct state that is being refreshed. If we=20
|> |just use session ID, we dont know what possibly obsolete state=20
|> |might be refreshed. By matching the RSN in the summary refresh=20
|> |with the locally stored RSN, a nodes knows whether it is=20
|> |refreshing the correct state.=20
|> |
|> |Vice versa, when the RSN in the summary refresh does not match=20
|> |the local RSN, the refresh will be disregared - which makes=20
|> |sense, because a problem must have occurred (i.e. a node does=20
|> |not have the most up-to-date state information).
|>=20
|> Yes, and this node could be the one ignoring the refresh with=20
|> the sequence number not matching the on in his local database.
|
|Exactly. Do I take it correctly you consider this a drawback=20
|rather than a virtue? Why that?

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



From exim@www1.ietf.org  Mon Sep 29 15:40:05 2003
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 PAA06828
	for <nsis-archive@odin.ietf.org>; Mon, 29 Sep 2003 15:40:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A43ry-000703-Do
	for nsis-archive@odin.ietf.org; Mon, 29 Sep 2003 15:39:42 -0400
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TJdgqO026901
	for nsis-archive@odin.ietf.org; Mon, 29 Sep 2003 15:39:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A43rK-0006pz-8N; Mon, 29 Sep 2003 15:39:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1A43qf-0006dq-9a
	for nsis@optimus.ietf.org; Mon, 29 Sep 2003 15:38:21 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06562;
	Mon, 29 Sep 2003 15:38:13 -0400 (EDT)
Message-Id: <200309291938.PAA06562@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: nsis@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 29 Sep 2003 15:38:13 -0400
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-fw-04.txt
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Steps in Signaling Working Group of the IETF.

	Title		: Next Steps in Signaling: Framework
	Author(s)	: R. Hancock et al.
	Filename	: draft-ietf-nsis-fw-04.txt
	Pages		: 47
	Date		: 2003-9-29
	
The Next Steps in Signaling working group is considering protocols 
for signaling information about a data flow along its path in the 
network. Based on existing work on signaling requirements, this 
document proposes an architectural framework for such signaling 
protocols. 
This document provides a model for the network entities that take 
part in such signaling, and the relationship between signaling and 
the rest of network operation. We decompose the overall signaling 
protocol suite into a generic (lower) layer, with a separate upper 
layers for each specific signaling application. An initial proposal 
for the split between these layers is given, describing the overall 
functionality of the lower layer, and discussing the ways that upper 
layer behavior can be adapted to specific signaling application 
requirements. 
This framework also considers the general interactions between 
signaling and other network layer functions, specifically routing and 
mobility. The different routing and mobility events that impact 
signaling operation are described, along with how their handling 
should be divided between the generic and application-specific 
layers. Finally, an example signaling application (for Quality of 
Service) is described in more detail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nsis-fw-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-fw-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-9-29153042.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-nsis-fw-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-nsis-fw-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-9-29153042.I-D@ietf.org>

--OtherAccess--

--NextPart--



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