Subject: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 Parameter to be Ignored

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 14 Aug 2006 16:46:03 -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:

3. agreement/consensus on whether to allow a QSPEC-1 (formerly called
"mandatory") parameter to be ignored; see Section 4.3.1

There was extensive discussion on the list RE whether to allow a QSPEC-1
parameter to be ignored, as is allowed for a QSPEC-2 (formerly called
"optional") parameter.  Reasons given for allowing this are a) use of a
QSPEC-1 parameter might be illegal, as with preemption in the U.S. PSTN,
and b) a particular QOSM might not want to support certain QSPEC-1
parameters, i.e., while it would be nice for all QOSMs to support <QoS
Class>, some have suggested that might not be practical/realistic.

Note that this issue is related to Issue #1, that is, if we retain the
QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter to be
ignored is a step toward doing away with the distinction between QSPEC-1
and QSPEC-2 parameters.  It is also related to Issue #2 in that an
alternative to "strict interpretation" of QSPEC-1 parameters is
remapping these parameters.  However, in some cases remapping QSPEC-1
parameters between classes of QSPEC parameters may not make sense, e.g.,
mapping <QoS Class> to <Token Bucket>.
 
The default resolution is that the QSPEC-1 concept is retained and that
all QSPEC-1 parameters must be strictly interpreted or remapped by all
QOSMs.  Alternatively, it is suggested in Section 4.3.1 that if ignoring
a QSPEC-1 parameter is to be allowed, that a high threshold be placed on
justification for this in the QOSM specification document:
"a QOSM may simply not want to support a QSPEC-1 parameter.  In (that)
case justification may be more difficult, however there is a filter on
reasonableness in that QOSM specifications must be reviewed and approved
by the IETF."

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

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

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

Hi Jerry

The below comments are coupled to my comments on QSPEC Issue #1:
I am in favour of havenig the possibility to ignore QSPEC-1 parameters.
The reasons are identical to the ones I mentioned in my commnets on Issue #1

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.

Thus if we allow to ignore QSPEC-1 paranmeters, then I can agree on haviong 
4 QSPEC-1 parameters.

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 #3 -- Allowing a QSPEC-1 Parameter to be Ignored

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 whether to allow a QSPEC-1
parameter to be ignored, as is allowed for a QSPEC-2 (formerly called
"optional") parameter.  Reasons given for allowing this are a) use of a
QSPEC-1 parameter might be illegal, as with preemption in the U.S. PSTN, and
b) a particular QOSM might not want to support certain QSPEC-1 parameters,
i.e., while it would be nice for all QOSMs to support <QoS
Class>, some have suggested that might not be practical/realistic.

Note that this issue is related to Issue #1, that is, if we retain the
QSPEC-1 parameter concept, then allowing a QSPEC-1 parameter to be ignored
is a step toward doing away with the distinction between QSPEC-1 and QSPEC-2
parameters.  It is also related to Issue #2 in that an alternative to
"strict interpretation" of QSPEC-1 parameters is remapping these parameters.
However, in some cases remapping QSPEC-1 parameters between classes of QSPEC
parameters may not make sense, e.g., mapping <QoS Class> to <Token Bucket>.
 
The default resolution is that the QSPEC-1 concept is retained and that all
QSPEC-1 parameters must be strictly interpreted or remapped by all QOSMs.
Alternatively, it is suggested in Section 4.3.1 that if ignoring a QSPEC-1
parameter is to be allowed, that a high threshold be placed on justification
for this in the QOSM specification document:
"a QOSM may simply not want to support a QSPEC-1 parameter.  In (that) case
justification may be more difficult, however there is a filter on
reasonableness in that QOSM specifications must be reviewed and approved by
the IETF."

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: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 25 Aug 2006 07:26:31 -0500

Hi Georgios,

See comments below. 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: Friday, August 25, 2006 5:45 AM
> To: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: [NSIS] QSPEC Issue #3 -- Allowing a QSPEC-1 
> Parameter to be Ignored
> 
> Hi Jerry
> 
> I am in favour of having the possibility to ignore QSPEC-1 
> parameters.
> The reasons are identical to the ones I mentioned in my 
> comments on Issue #1
> 
> 
> The reasons are:
> 
> Thus if we allow to ignore QSPEC-1 parameters, then I can 
> agree on having 4 QSPEC-1 parameters.

As stated below, allowing to ignore QSPEC-1 parameters would pretty much
do away with the distinction between QSPEC-1 and QSPEC-2 parameters.

Thanks,
Jerry
 
> I-D 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as
> follows:
>