Subject: [NSIS] IETF 54 Minutes

From: [email-masked]
Date: Tue, 23 Jul 2002 15:15:02 +0300

HI all,
 
Here are the minutes, please send comments.
 
John

NEXT STEP IN SIGNALLING WG - IETF 54
  MONDAY, July 15, 2002
 0900-1130 Morning Session
(thanks to Janne Rinne for the minutes)

Requirements
 
NSIS Requirements
http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-03.txt - John Loughney
 
Open issues are 2, 4, and 44. Following open issues are discussed in draft-vandenbosh-nsis-resilence-00.txt draft: 28, 53, 59, 65, and 72. 
Other open issues in the mailing list are: terminology, removal of the requirement 5.2.2, removal of the text about network initiation from 
requirements 5.7.2 and 5.7.3. No questions or comments were provided.
 
NSIS Threats & Security requirements
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-threats-01.txt - Hannes Tschofenig.
 
Security requirements were introduced in the presentation such as eavesdropping and traffic analysis, identity spoofing, missing non-repudiation 
property, disclosing the network structure and modification of a reservation. Next steps: what issues are not addressed in the doc, is the NSIS 
threats document useful, should it be a WG item. Authorization should be considered in the future because of adding support for applications 
like middleboxes. It was supported to have this kind document as a separate doc. This would be a WG item from now on.
 
NSIS Resilience
http://www.ietf.org/internet-drafts/draft-vandenbosch-nsis-resilience-00.txt - Sven Van den Bosch.
 
In the interim meeting, there were discussions about error handling, failure and recovery and also it was requested to provide individual 
submissions on this. There is a relation to other drafts, which are the requirement draft and framework draft (hancock-nsis-fw). Latest 
comments provided in the mailing list are related to terminology, pre-class state, limited number of examples, additional failure detection 
mechanisms and clarifications. Next steps: is this good start for an NSIS resilience draft. If yes, version 01 and might be considered as a WG 
item. Chairman commented that there should have a consensus first with the requirements draft and then continue with the broader scope and 
this doc.
 
Conclusion of the requirements discussions:
 
Requirements document should be re-issued & then see if it is ready for WG last call.

Framework
 
Next Steps in Signaling: A Framework Proposal
http://www.ietf.org/internet-drafts/draft-hancock-nsis-fw-00.txt -  Robert Hancock.
 
The purpose of this document is to explain what different entities really do, how they can be used and how they can interact with other entities. 
Some of the issues for the work are addressing, on and off path signalling, sender/receive/bi-directional operation, acknowledgement options, 
authorization issues, re-using standard protocols and supporting different resource types and protocol interactions. There were concerns with 
addressing and on or off path signalling and middleboxes. It was questioned that why we need to specify only signalling and not QoS.
 
2 Level Signaling Architecture
http://www.isi.edu/~braden/draft-braden-2level-signaling-00.txt - Bob Braden.
 
What we can learn from RSVPv1: After having basic requirements and protocol design, it took 3 years...
 
RSVP is adaptable (syntactically and semantically). Due to complex problem space, mapping and partitioning this space should be the task of 
this WG. It was proposed to separate the common stuff from the application level signalling stuff (CSTP and ALSP). Functional partition 
would be that CSTP is much adapted from RFC 2961 and ALSP would be much of details and complexity, of RFC 2205. In the 
presentation, modest proposal for NSIS was that we should define the architectural framework, map the signalling problem space into a 
rational set of ALSP's and also revise the charter a WG to define CSTP and one ALSP, later WG can define additional ALSP. There were 
questions related to security and how it would work in the presence of VPN's..
 
Framework Structure for QoS Signaling
http://www.ietf.org/internet-drafts/draft-kan-qos-framework-00.txt - Kan Zhigang.
 
Off and on path signalling is relating to this and it would useful to have more discussions and get comments to this in the mailing list.
 
A Framework for Bi-Directional QoS Signaling
http://www.ietf.org/internet-drafts/draft-shahrier-nsis-framework-01.txt - Sharif Sharier.
 
It was commented that this is a very solution driven document. Also it was mentioned that MPLS group has been doing something on this. 
More comments should be sent to the mailing list.
 
Middlebox Signaling in a NSIS framework
http://www.ietf.org/internet-drafts/draft-brunner-nsis-mbox-fmwk-00.txt - Martin Stiemerling.
 
It was commented that this is useless for the general problems of NAT and firewalls and those should be covered also in framework.
 
Conclusion of the framework discussions:
The proposed way to go with the framework issue was to use Hancock draft as a base document for the work and include some input from 
Bob and Melinda to the document. After it is done, we could have a WG last call for that document.

Analysis
 
Analysis of Existing QoS Solutions
http://www.ietf.org/internet-drafts/draft-demeer-nsis-analysis-02.txt - Hannes Tschofenig.
 
Traffic Engineering group has done traffic engineering related work and some input may come from the group to this analysis document.
 
On path and off path signaling for NSIS
http://www.ietf.org/internet-drafts/draft-schelen-nsis-opopsig-00.txt - Alban Couturier
 
It was asked how the states could be installed to routers if the signalling is off path. There are cases when it is not need to install states for 
flows. Also COPS is used for configuring routers in centralized resource management cases. Middlebox case was also mentioned here. It was 
proposed to separate the solution part to own document from the analysis part. AD's were not at present, so the charter question whether to 
include off-path signalling to the charter is still pending. However the original intention of NSIS work was to concentrate only to on path 
signalling. This work would continue as an individual effort.
 
RSVP Security Properties
http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-sec-properties-00.txt - Hannes Tschofenig.
 
Some concerns were raised with VPN's, which is kind of network engineering problem.
 
Analysis on RSVP Regarding Multicast
http://www.ietf.org/internet-drafts/draft-fu-rsvp-multicast-analysis-00.txt - Xiaoming Fu.
 
It was commented that there is room for improvement of multicasting. It was commented that multicast support should not be removed, but 
there is a gread deal of room for improvement.
 
Conclusion of the analysis discussions:
 
Several important points were addressed and those should be merged into one document, thus the structure of the document is more or less 
open. It was commented that good goal for this document could be an informational RFC eventually.  Some discussion needs to take place 
about the editorship of the WG document, as no document yet meets the WG needs.

Other presentations
 
Consideration of RSVP-TE Extension for Metro Network
http://www.ietf.org/internet-drafts/draft-choi-metro-signaling-00.txt
 
Shortly presented. No comments provided.
 
The Features of IPv6 Signaling
http://opticalip.icu.ac.kr/draft-choi-ipv6-signalling-02.txt
 
No time to discuss about this after quick presentation.