RE: [NSIS] QSPEC document

It will be a serious concern for all of us, as you have pointed out, if only so-called Y.1541 QOSM can use NSIS protocol while the other QOSM models cannot use it.

Rather, what we are proposing as follows:

We must examine how only the standard-based QOSMs what exist today in the IETF - DiffServ QOSM, CL-QOSM, Guaranteed-QOSM, RMD-QOSM, and RSVP-Ext-QOSM can use NSIS NSLP operations.

All QOSMs of item 1 must be able to operate with NSIS NSLP as those are standards QOSM of the IETF.

If NSIS NSLP operations do not support items 1 and 2, we have to revisit the NSIS NSLP spec what is the real problem and how we can solve this issue including QSPEC template.

We must NOT care what is happening to Y.1541 as we have seen that as it is not a QOS Model. Y.1541 is an implementation-specific value-based QOS-SLA and does NOT need any support of signaling scheme including NSIS QOS protocols. Any support of NSIS for Y.1541 is out-of-place.

It is extremely unfortunate, as you have found out, that NSIS NSLP can operate only for so-called Y.1541, but not for IETF standard-based QOSMs. What else can be most disappointing for all IETF members if this nightmare really becomes true at the end of all hard works?

From: nsis-bounces at ietf.org on behalf of Georgios Karagiannis
Sent: Thu 1/25/2007 7:48 AM
To: 'Jukka MJ Manner'
Cc: nsis at ietf.org
Subject: RE: [NSIS] QSPEC document

Hi Jukka

I think that we actually agree, but in my opinion
the changes that Dave proposes are going beyond that:

In particular I do not agree with the last
paragrap of a), see:
"A QOSM is *not* allowed
to simply require that the QOS-NSLP operate in a different way
than is specified in the standards track RFC(s)."

This is very vague that could mean:

If the QOS-NSLP does not specify the exact
message flow charts and the associated protocol state machines
of the following scenarios, then no QOSM can use and apply
such message flow charts and protocol state machines:

* Unidirectiona/bidirectional reservation intiation, refresh,
tear, modification of:
- bound and parallel end-to-end and edge-to-edge sessions
- bound and paralele end-to-end and end-to-edge sessions

Note that examples of an end-to-end sessions can be:
* Controlled Load QOSM
* Guaranteed Servuce QOSM

Note that examples of such edge-to-edge sessions can be:
* RSVP aggregation like QOSM
* RMD-QOSM
* interdomain and intra-domain ITU-T RACF QoS model
* PCN like congestion notifictaion and preemption QoS model.

If the above is the case then NSIS is much less felxible and modular than
RSVP.
In other words, NSIS can only be used to support Y.1541 QOSM.

I think that in this case NSIS could also not support the Controlled Load
QOSM.

Best Regards,
Georgios