Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt

From: [email-masked]
Date: Mon, 14 Aug 2006 15:50:02 -0400

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		: QoS NSLP QSPEC Template
	Author(s)	: J. Ash, et al.
	Filename	: draft-ietf-nsis-qspec-11.txt
	Pages		: 62
	Date		: 2006-8-14
	
The QoS NSLP protocol is used to signal QoS reservations and is
independent of a specific QoS model (QOSM) such as IntServ or
DiffServ.  Rather, all information specific to a QOSM is encapsulated
in a separate object, the QSPEC.  This document defines a template
for the QSPEC, which contains both the QoS description and QSPEC
control information. The QSPEC format is defined, as are a number of
QSPEC parameters.  The QSPEC-1 parameters provide a common language
to be re-used in several QOSMs.  QSPEC-2 parameters aim to ensure
the extensibility of QoS NSLP to other QOSMs in the future.  To a
certain extent QSPEC parameters ensure interoperability of QOSMs. 
The node initiating the NSIS signaling adds an Initiator QSPEC that
must not be removed, thereby ensuring the intention of the NSIS
initiator is preserved along the signaling path.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-qspec-11.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nsis-qspec-11.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.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 14 Aug 2006 15:28:32 -0500

Hi All,

The updated 'QoS NSLP QSPEC Template' I-D is available at
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt.

The updates are in response to a very large number of comments and
discussion on the list since the last update (-10 version) in June.  We
have tried to incorporate all comments/agreements into the updated -11
version.  

Given the large number of comments and extensive discussion, please
check to be sure that the agreed-to changes/comments are properly
incorporated.  

The main changes are as follows:

1. 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter'
2. 'QSPEC-2 parameter' replaces 'optional QSPEC parameter'
3. R-flag ('remapped parameter flag') introduced to denote remapping,
approximating, or otherwise not strictly interpreting a QSPEC parameter
3. T-flag ('tunneled parameter flag') eliminated and incorporated within
the R-flag
4. Section 4 rewritten on QOSM concept, QSPEC processing, etc. to
provide a more logical flow of information
5. read-write/read-only flag associated with QSPEC objects eliminated
and object itself defined as rw or ro without a flag
6. <Non QOSM Hop> parameter redefined as non-QOSM-hop Q-flag
7. Section 7 on QSPEC parameter definitions revised to clearly separate
QSPEC-1 parameter coding from QSPEC-2 parameter coding
8. <Traffic>, <QoS Class>, and <Priority> QSPEC-1 parameters mapped to
container parameters
9. references updated to include normative references defining
procedures to 'strictly interpret' each QSPEC parameter
10. Section 7.2.1 on PHB class updated to specify additional RFC 3140
cases
11. Section 7.2.1 on excess treatment updated to specify excess
treatment behaviors

There are still 4 open issues currently identified based on the list
discussion:

1. agreement/consensus on 4 QSPEC-1 (formerly called 'mandatory')
parameters; see Section 7.2
2. agreement/consensus on what is allowed by remapping QSPEC parameters;
see Section 4.3.1
3. agreement/consensus on whether to allow a QSPEC-1 parameter to be
ignored; see Section 4.3.1

I will soon start a separate thread on each of the above issues so that
we may reach final consensus.

Please review the document and let us know of any further comments or
suggestions.  At this point comments/suggestions should be accompanied
by suggested text changes, if any.

Thanks,
Regards,
Jerry  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 14, 2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt 

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.

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 14 Aug 2006 16:45:31 -0500

Hi All,

One of the issues identified in the updated 'QoS NSLP QSPEC Template'
I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is
as follows:

There was extensive discussion on the list RE "Any resolution of QSPEC
mandatory parameter list," which started at
http://www1.ietf.org/mail-archive/web/nsis/current/msg06542.html.

Various opinions were expressed as to a) whether the QSPEC-1 (mandatory)
parameter concept was useful, and b) how many QSPEC-1 parameters there
should be.

Most opinions expressed on (a) supported the QSPEC-1 parameter concept
as a means for a "common language" among different QOSMs and to enhance
interoperability.

Most opinions expressed on (b) did not oppose the 4 QSPEC parameters now
included in the updated QSPEC draft:
<Excess Treatment> Parameter (Section 7.2.1)
<Traffic> Parameter (Section 7.2.2)
<QoS Class> Parameter (Section 7.2.3)
<Priority> Parameter (Section 7.2.4)
Note that the <Traffic>, <QoS Class>, and <Priority> parameters are
"container" parameters.

Please express any further comments in support of the proposed
resolution, or otherwise, so that we may reach consensus on this issue.

Thanks,
Regards,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 25 Aug 2006 11:40:36 +0200

Hi Jerry

I have doubts on the need of having all these 4 parameters as being
mandatory parameters.
The reasons are:

* Excess treatment parameter.  
It should be possible to ignore this parameter in certain domains.
For example, when a Diffserv domain is using PCN or RMD it should be able to
ignore this parameter.
The reason of this is that the way of how the remarking or the dropping of
packets 
is influencing e.g., the PCN or RMD solution. Therefore, it should be
possible that the 
QNEs that are located in such regions to ignore this parameter.

* QoS class:
It should be possible for some QNEs 
to ignore this parameter.
E.g., problematic when:
* a non Diffserv aware QNE receives a PHB class parameter
* a non Y.1541 aware QNE receives a Y.1541 class parameter
* a non MPLS aware QNE receives a DSTE class parameter.
In such situations such QNEs should be able to ignore this parameter.

* Priority
You already mentioned some reasons on why it should be possible to ignore
this parameter.

Best regards,
Georgios

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: maandag 14 augustus 2006 23:46
To: [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] QSPEC Issue #1 -- Number of QSPEC-1 (formerly
called"mandatory") Parameters

Hi All,

One of the issues identified in the updated 'QoS NSLP QSPEC Template'
I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as
follows:

Most opinions expressed on (a) supported the QSPEC-1 parameter concept as a
means for a "common language" among different QOSMs and to enhance
interoperability.

Most opinions expressed on (b) did not oppose the 4 QSPEC parameters now
included in the updated QSPEC draft:
<Excess Treatment> Parameter (Section 7.2.1) <Traffic> Parameter (Section
7.2.2) <QoS Class> Parameter (Section 7.2.3) <Priority> Parameter (Section
7.2.4) Note that the <Traffic>, <QoS Class>, and <Priority> parameters are
"container" parameters.

Please express any further comments in support of the proposed resolution,
or otherwise, so that we may reach consensus on this issue.

Thanks,
Regards,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 25 Aug 2006 11:58:44 +0200

Hi all

Looking to the last version of QSPEC template (v.11) submitted I can see
that NSIS 
is not able to detect that a RESERVE message passed a node that is
NSIS/QoS-NSLP unaware. 
I think that we have to include a solution in the QoS-NSLP draft (solution
similar to RSVP) 
to support this feature. 

Best Regards,
Georgios

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: maandag 14 augustus 2006 22:29
To: [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt 

Hi All,

The updates are in response to a very large number of comments and
discussion on the list since the last update (-10 version) in June.  We have
tried to incorporate all comments/agreements into the updated -11 version.  

Given the large number of comments and extensive discussion, please check to
be sure that the agreed-to changes/comments are properly incorporated.  

1. 'QSPEC-1 parameter' replaces 'mandatory QSPEC parameter'
2. 'QSPEC-2 parameter' replaces 'optional QSPEC parameter'
3. R-flag ('remapped parameter flag') introduced to denote remapping,
approximating, or otherwise not strictly interpreting a QSPEC parameter 3.
T-flag ('tunneled parameter flag') eliminated and incorporated within the
R-flag 4. Section 4 rewritten on QOSM concept, QSPEC processing, etc. to
provide a more logical flow of information 5. read-write/read-only flag
associated with QSPEC objects eliminated and object itself defined as rw or
ro without a flag 6. <Non QOSM Hop> parameter redefined as non-QOSM-hop
Q-flag 7. Section 7 on QSPEC parameter definitions revised to clearly
separate
QSPEC-1 parameter coding from QSPEC-2 parameter coding 8. <Traffic>, <QoS
Class>, and <Priority> QSPEC-1 parameters mapped to container parameters 9.
references updated to include normative references defining procedures to
'strictly interpret' each QSPEC parameter 10. Section 7.2.1 on PHB class
updated to specify additional RFC 3140 cases 11. Section 7.2.1 on excess
treatment updated to specify excess treatment behaviors

1. agreement/consensus on 4 QSPEC-1 (formerly called 'mandatory')
parameters; see Section 7.2 2. agreement/consensus on what is allowed by
remapping QSPEC parameters; see Section 4.3.1 3. agreement/consensus on
whether to allow a QSPEC-1 parameter to be ignored; see Section 4.3.1

I will soon start a separate thread on each of the above issues so that we
may reach final consensus.

Please review the document and let us know of any further comments or
suggestions.  At this point comments/suggestions should be accompanied by
suggested text changes, if any.

Thanks,
Regards,
Jerry  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, August 14, 2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-11.txt 

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.

The QoS NSLP protocol is used to signal QoS reservations and is independent
of a specific QoS model (QOSM) such as IntServ or DiffServ.  Rather, all
information specific to a QOSM is encapsulated in a separate object, the
QSPEC.  This document defines a template for the QSPEC, which contains both
the QoS description and QSPEC control information. The QSPEC format is
defined, as are a number of QSPEC parameters.  The QSPEC-1 parameters
provide a common language to be re-used in several QOSMs.  QSPEC-2
parameters aim to ensure the extensibility of QoS NSLP to other QOSMs in the
future.  To a certain extent QSPEC parameters ensure interoperability of
QOSMs. 
The node initiating the NSIS signaling adds an Initiator QSPEC that must not
be removed, thereby ensuring the intention of the NSIS initiator is
preserved along the signaling path.