Subject: [NSIS] Alternatives for supporting domain-local admission control operation in NSLP/QSPEC

From: David R Oran <[email-masked]>
Date: Thu, 9 Nov 2006 13:59:40 -0500

Some of this I raised in a private exchange with the QSPEC authors as  
we were polishing our proposal for the QSPEC redesign. John Loughney  
asked me to clean it up and send it to the whole list, so here it is.

There seems to be a strong working group consensus to support the  
ability to have the edge-nodes at entry/exit of a domain perform a  
"full" NSLP-style admission control function, based on the standard  
QSPEC, yet allow the interior nodes to have both a simpler/customized  
data plane, *and* a simpler admission control capability in their RMF  
which is based on either a subset of the QSPEC parameters, or some  
private parameters, or both.

When Jerry/Cornelia/Dave proposed eliminating stacking, this was the  
piece of functionality on which we got strong opposition, so that  
indicates the WG consensus I noted above.

In thinking about what protocol designs could meet the above  
requirements, I discerned three. One is essentially identical to the  
former/existing QSPEC stacking functionality we wanted to eliminate.  
A second is a proposal by Roland Bless. The third is to not handle  
this in QSPECS as all, but by recursing at the NSLP level.

In more detail, the three alternatives are:

1. Do complete QSPEC stacking, and deal with the issues around what  
constraints have to be met by the stacked QSPEC, whether the QSPEC  
lower in the "stack" is opacified, and what the rules are for  
pushing, swapping, and popping.

2. Allow domain-parameters to be added to a QSPEC on domain entry and  
removed on exit. In this option one has to describe whether anything  
is opacified and which existing QSPEC parameters get "re-interpreted"  
if any.

3. Recurse at the NSLP level, have a separate domain-private NSLP  
session, and that would contain a domain-private set of paramteres  
instead of the end-to-end QSPEC. I'll note that this approach allows  
(but not requires) the two signaling state machines (end-end and edge- 
edge through interior nodes) to be decoupled.

We already have (3) for other purposes, like aggregation and tunneling.

Dave.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 09 Nov 2006 21:55:44 +0000

Hi all

I really do not understand this proposal.

Note that option 2 is not exactly what Roland proposed. Actually option 2
should say that a QOS model is able to craeate its own local/private
QSPEC and that tis local/private QSPEC can encapsulate the parameters of
the end-to-end QSPEC. Additionally the local/private QSPEc can then
piggiback its own local QSPEC parameters. In this case the parameters of
the end-to-end QSPEC parameters can be ignored.

Please also note that the discussion on stacking it is only related to
options 1 and 2.
Point 3 is a separate issue that is related to the possibility that is
given to QOS models to use/initiate their own session local/edge
-to-edge session. Note that NSIS should support edge-to-edge scenarios
and therefore this point should not be a point of consensus. Please also
note that the edge-toedge support has been introduced by this WG 3/4
years ago in the QOS-NSLP work. Note that the local (edge-to-edge)
scenario could map the end-to-end QSPEC traffic source description to
the local traffic description.

Thus regarding stacking what we have to decide is whether we use option 1
or option 2, i.e., Rolands proposal.

Please note that the motivation to use encapsulation/piggibacking  of
local QSPEc parameters in end-to-end QSPECs is to increase the
flexibility, modularity and the signaling performance. The flexibility
and modularity
increase can be achieved by providing the possibility to any existing
or future QoS model applied in a local QoS NSLP aware domain to use
and stack any required local QoS model information on QoS NSLP
signaling messages passing through the local domain (see requirement
5.4.2 in RFC3726).

For example, suppose that a QOS model uses parallel sessions (an
end-to-end session and an edge-to-edge (local) session), then the QOS
model can piggiback QoS model (local) specific control information into
the end-to-end RESPONSE message that is sent from an egress node to an
ingress node. If that will not be allowed than the egress node would
need to generate a completely new local RESPONSE message in order to
send the same QoS model specific control information.

Thus if I look to this proposal I think that we need need both otion 3
(parallel session support) and option 2, which is Rolands proposal that
encapsulates end-to-end QSPEC into a local QSPEC and gives the
possibility to the QoS model to specify which QSPEC parameters can be
ignored.

Best Regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Thu, 09 Nov 2006 23:14:56 +0100

Hi Dave and all,

David R Oran wrote:
> former/existing QSPEC stacking functionality we wanted to eliminate. A
> second is a proposal by Roland Bless. The third is to not handle this in
> QSPECS as all, but by recursing at the NSLP level.
> 
> constraints have to be met by the stacked QSPEC, whether the QSPEC lower
> in the "stack" is opacified, and what the rules are for pushing,
> swapping, and popping.

> removed on exit. In this option one has to describe whether anything is
> opacified and which existing QSPEC parameters get "re-interpreted" if any.

It's actually not the _same_ QSPEC with added parameters,
but it would be a "new" QSPEC (type). So to give an
example in order to make it clear, an RMD-QSPEC would
look like this:
----------------------------------
| QSPEC-Type = RMD-QSPEC         |  Common QSPEC header
+================================+\
|  RMD-specific Parameter 1      | \
+--------------------------------+  \
|             ....               |   local QSPEC parameters
+--------------------------------+  /
|  RMD-specific Parameter n      | /
+--------------------------------+/
| +----------------------------+ |
| | QSPEC-Type = Generic QSPEC | |
| +============================+ |
| |                            | | Encapsulated "external" QSPEC
| |          ....              | |
| +----------------------------+ |
+--------------------------------+
The important difference to 1 is that QoS-NSLP only sees
and passes one QSPEC up to the RMF. The type of the
QSPEC thus may change within a domain. As written in my earlier
mail:
1. QNI signals its QoS requirements with its Generic QSPEC
2. The ingress edge QNE will map these to its own QoS model, e.g.
   choosing the corresponding DiffServ or Y.1541 class.
   The mapped parameter values may be carried within
   the above described local RMD-QSPEC.
3. The egress QNE will process the RMD-QSPEC and pass only
    the encapsulated Generic QSPEC to the next domain, that
    may perform its own mapping again possibly without requiring
    to transmit its own local QSPEC.

> (but not requires) the two signaling state machines (end-end and
> edge-edge through interior nodes) to be decoupled.

> We already have (3) for other purposes, like aggregation and tunneling.

But Georgios point was probably more to avoid having a
separate signaling and to piggyback additional information instead.
So this would be an optimization, not possible with approach 3 only.

My view is the following:
1 is more complicated than 2, at least for the QoS NSLP.
2 could be used in addition to 3.
I'm really open to hear cases were approach 2 fails badly
or is disadvantageous over approach 1.

Regards,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 9 Nov 2006 16:49:03 -0600

Hi Roland,

The picture for option 2 is very helpful.  Could you send an example
picture for option 1 for comparison?

Thanks,
Jerry 

-----Original Message-----
From: Roland Bless [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 5:15 PM
To: David R Oran
Cc: NSIS Group
Subject: Re: [NSIS] Alternatives for supporting domain-local admission
controloperation in NSLP/QSPEC

Hi Dave and all,

> constraints have to be met by the stacked QSPEC, whether the QSPEC
lower

> removed on exit. In this option one has to describe whether anything
is

Regards,
 Roland

---

From: Stephane Ouellette <[email-masked]>
Date: Thu, 09 Nov 2006 18:16:35 -0500

Georgios, David and all,

  see my comments inline.

Stephane.

> the end-to-end QSPEC parameters can be ignored.

[STEPHANE] I read Roland's proposal and its description by Georgios is exactly
what I understood.

Roland's proposal can be found here:

http://www1.ietf.org/mail-archive/web/nsis/current/msg07158.html

> or option 2, i.e., Rolands proposal.

[STEPHANE] I also think that recursion is out of scope of this debate, as it is
always possible to create a NSIS session between the edge nodes of a domain to
emulate local QSPEC stacking. However, recursion increases the number of states
that must be managed by the edge nodes.

> signaling messages passing through the local domain (see requirement

[STEPHANE] I think that what the RFC states is unambiguous: reuse the existing
session to avoid creating unnecessary states in the edge nodes.

> send the same QoS model specific control information.

[STEPHANE] That's right.

> possibility to the QoS model to specify which QSPEC parameters can be

[STEPHANE]
I would vote for a combination of Roland's proposal and option 3.

Thanks for your attention,

Stephane.

---

From: Roland Bless <[email-masked]>
Date: Fri, 10 Nov 2006 00:49:34 +0100

Hi,

> picture for option 1 for comparison?

Sure. I thought that the backers of the stack proposal would have to do
it :-)
Stacking:
+--------------------------------+
| QSPEC-Type = RMD-QSPEC         |\
+================================+ \
|  RMD-specific Parameter 1      |  \
+--------------------------------+   1) RMD-QSPEC
|             ....               |  /
+--------------------------------+ /
|  RMD-specific Parameter n      |/
+--------------------------------+
+--------------------------------+\
| QSPEC-Type = Generic QSPEC     | \
+================================+  \
|                                |   2) Generic QSPEC
|             ....               |  /
|                                | /
+--------------------------------+/

-- 
Dr. Roland Bless -- WWW: http://www.tm.uka.de/~bless
Institut für Telematik, Universität Karlsruhe (TH), Germany
Zirkel 2, D-76128 Karlsruhe -- Geb. 20.20, 3.OG, Raum 358
Tel.: +49 721 608-6413 Fax: +49 721 608-6789

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 10 Nov 2006 19:08:52 +0200 (EET)

Hi all,

I'd very much like to see approach "2" in addition to approach "3".

In addition to what Roland discussed below, a reason to have the "local 
vs. e2e" QSPEC together inside a single QSPEC is that local QoS objects 
and piggybacking is a functionality of a particular QoS model. If a QoS 
Model needs those functionality, they should be in the RMF, not in the 
base protocol, the NSLP.

Jukka

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 13 Nov 2006 05:34:29 -0600

Hi All,

I agree that we should go with option 2 (encapsulated QSPEC) versus
option 1 (stacked QSPEC) as the easier one to implement (according to
discussions with Roland).  We should also retain option 3 (tunneled
QSPEC) as currently specified.

IMO we should retain the QoS class parameters as optional parameters in
the QSPEC document.  One reason is that support for DiffServ was an
original basic requirement on the QSPEC, and that requirement still must
be met.  Additionally, it would require initiating new QOSM
specification documents if these parameters are moved elsewhere -- it is
far simpler, and appropriate, to retain them as is in the QSPEC
document.

Hopefully we are now ready to revise the QSPEC document according to the
agreements summarized in the presentation at IETF-67
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
(subject to the revisions of including option 2/encapsulated QSPEC).

Thanks,
Jerry

-----Original Message-----
From: Roland Bless [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 5:15 PM
To: David R Oran
Cc: NSIS Group
Subject: Re: [NSIS] Alternatives for supporting domain-local admission

Hi Dave and all,

lower

is

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 13 Nov 2006 12:56:46 +0100

Hi Jerry

I agree with you!
I think that we now have reached a consensus on all open issues and we can 
proceed on finalizing all NSIS base drafts!

Best Regards,
Georgios 

> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: maandag 13 november 2006 12:34
> To: Roland Bless; David R Oran
> Cc: Ash, Gerald R (Jerry), ALABS; NSIS Group
> Subject: RE: [NSIS] Alternatives for supporting domain-local 
> admissioncontroloperation in NSLP/QSPEC
> 
> Hi All,
> 
> I agree that we should go with option 2 (encapsulated QSPEC) 
> versus option 1 (stacked QSPEC) as the easier one to 
> implement (according to discussions with Roland).  We should 
> also retain option 3 (tunneled
> IMO we should retain the QoS class parameters as optional 
> parameters in the QSPEC document.  One reason is that support 
> for DiffServ was an original basic requirement on the QSPEC, 
> and that requirement still must be met.  Additionally, it 
> would require initiating new QOSM specification documents if 
> these parameters are moved elsewhere -- it is far simpler, 
> and appropriate, to retain them as is in the QSPEC document.
> 
> Hopefully we are now ready to revise the QSPEC document 
> according to the agreements summarized in the presentation at IETF-67
> Subject: Re: [NSIS] Alternatives for supporting domain-local 
> admission controloperation in NSLP/QSPEC
> 
> Hi Dave and all,
> 
> David R Oran wrote:
> > second is a proposal by Roland Bless. The third is to not 
> handle this
> in
> > opacified and which existing QSPEC parameters get 
> "re-interpreted" if
> any.
> 
> It's actually not the _same_ QSPEC with added parameters, but 
> it would be a "new" QSPEC (type). So to give an example in 
> order to make it clear, an RMD-QSPEC would look like this:
> The important difference to 1 is that QoS-NSLP only sees and 
> passes one QSPEC up to the RMF. The type of the QSPEC thus 
> may change within a domain. As written in my earlier
> mail:
> 1. QNI signals its QoS requirements with its Generic QSPEC 2. 
> The ingress edge QNE will map these to its own QoS model, e.g.
> I'm really open to hear cases were approach 2 fails badly or 
> is disadvantageous over approach 1.
> 
> Regards,
>  Roland
>

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Mon, 13 Nov 2006 16:39:16 +0100

Hi All, I also think it is good compromise. Option 3 is important feature, so we should keep it. Option 2 is OK to replace stacking.

Best regards, Attila 

>Sent: Monday, November 13, 2006 12:34 PM
>versus option 1 (stacked QSPEC) as the easier one to implement 
>(according to discussions with Roland).  We should also retain 
>option 3 (tunneled
>these parameters are moved elsewhere -- it is far simpler, and 
>appropriate, to retain them as is in the QSPEC document.
>
>passes one QSPEC up to the RMF. The type of the QSPEC thus may 
>change within a domain. As written in my earlier
>mail:

---

From: Roland Bless <[email-masked]>
Date: Tue, 14 Nov 2006 17:13:40 +0100

Hi Jerry,

> QSPEC) as currently specified.

Ok, great. However, I'm still interested if someone comes up
with a need for real stacking in QoS NSLP.

> far simpler, and appropriate, to retain them as is in the QSPEC

I don't agree here, as already expressed in the meeting. I'd really
like to see different QSPEC definitions for internal signaling if
required. The QoSM/QSPEC documents don't need to be long and they
could give guidelines on the mapping from the "generic" QSPEC to it's
specific classes. Furthermore, we already have drafts for This would be
IMHO a cleaner approach. I really
don't see a benefit in signaling these parameters from end to end.

There are several reasons for this (but I may have only a very
limited view, so please other people like operators: comment
on that):
As a provider I would not trust the end-system to choose the correct
Diffserv class (PHB). Furthermore, this will vary depending on the
providers network, e.g., although two different domains use DiffServ,
they may use a totally different service provisioning, e.g. one uses
6 classes, the other 12 classes. I don't really think that the
end-system should try to get this mapping correct. The end-system
should stick to the generic QSPEC (TMOD+constraints) that can be
mapped by the edge router to the according DiffServ classes, which
are supported in the particular DiffServ domain.
Consequently, if a domain attaches such a class parameter for
internal use, it is of limited use for other domains. So my guess
is that leaving these QoSM-specific parameters in the spec doesn't
help interoperability that much.

If there is, however, consensus for keeping the QoS class parameters
in the generic QSPEC as optional, I'd like to see something like a
"scope" parameter flag like Jukka proposed.

> (subject to the revisions of including option 2/encapsulated QSPEC).

As expressed in the meeting and above, I agree with the
presentation for the most part of it.

Regards,
 Roland

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2006 17:24:04 +0100

Hi Roland,

I agree with your observation regarding the QoS class parameters. I 
think it would be much cleaner to remove them from the QSPEC document as 
I commented already in the past. I don't know how complicated the 
"scope" flag is but I would appreciate not to introduce additional 
complexity into protocols.

I also agree with your comment about stacking of QSPECs. An analysis 
would be appropriate.

Ciao
Hannes

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 14 Nov 2006 14:00:59 -0600

Hi Roland,

> > parameters in
 
> specific classes. Furthermore, we already have drafts for 
> This would be IMHO a cleaner approach. I really

You have a point regarding signaling PHB class across domains using
inconsistent classes.  However IMO it should still be possible for a QNI
to signal a PHB class if called for by the QNI's QOSM, and in which
end-to-end interoperability/consistency may be achieved.  

In addition, the Y.1541 parameter can be regarded as a 'summary'
constraint parameter encompassing the latency, jitter, PLR, and PER
constraints (as stated in the summary slides at IETF-67).  These
parameters are intended to be signaled end-to-end across multiple
domains.

Therefore the QNI needs to signal these end-to-end parameters in some
cases.

It seems that the proposal is to introduce a QoS NSLP specific 'generic
QOSM', and everybody must map to this new QOSM.  We have tried
oftentimes to standardize a 'generic QOSM' and have not succeeded.  OTOH
we have for a long time specified these parameters in a single document.
I don't see the advantage in having multiple documents specify these
QSPEC parameters.  

Thanks,
Regards,
Jerry
 
> > according to the

---

From: Roland Bless <[email-masked]>
Date: Wed, 15 Nov 2006 10:51:52 +0100

Hi Jerry,

> end-to-end interoperability/consistency may be achieved.  

As far as I know from old DiffServ times, each domain is free to
use its own DSCPs and PHBs (i.e. it may even remap PHBs on each other).
Furthermore, the "service" usually doesn't only depend on the PHB,
but also on the PDB, i.e. PHBs + traffic conditioning mechanisms.
I guess that it makes quite a difference what traffic conditioning
a domain is using. So signaling a PHB-ID alone isn't very meaningful
between different DiffServ domains (unless they are a DS region under
the same administration/provider) IMHO. So if end-to-end is within
a single domain or consistent DS region this may work, but between
different ASes?

> parameters are intended to be signaled end-to-end across multiple

Hmm. so it's only an abbreviation for the generic QSPEC parameters?
I see it as a profile description how to set the generic QSPEC
parameter values for different QoS classes defined in Y.1541.
But why not simply use the generic QSPEC?
I'm not against having a separate Y1541-QSPEC.
If this is going to get wide support, great!

> QOSM', and everybody must map to this new QOSM.  We have tried

Oh no, please, big misunderstanging here!
I'm NOT talking about a generic QoSM, I'm talking about
a generic _QSPEC_. This is a really significant difference. While the
generic QSPEC may be mapped to any QoSM, mapping between QoSMs is not
going to work. I believe that it is really essential to allow different
QoSMs to be used. However, we need a common understanding of what
service is required between domains and I see the generic QSPEC as
a viable means to express that. In my understanding a QOSM is a means
to provide services, e.g. as proposed in Appendix VI of Y.1541 (using
a mapping from Y.1541 classes to Y.1221/DiffServ PHBs). This must be
completed, however, by specifying resource admission control algorithms
and traffic conditioning mechanisms.

> I don't see the advantage in having multiple documents specify these

So we must check for consensus to leave Y.1541 in the generic QSPEC.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 15 Nov 2006 11:17:24 +0100

Hi Roland

But the QSPEC template draft is not a generic QSPEC draft.
The Token Bucket and the constraints can be seen as something 
that can be common and can be used for the interoperability and the rest of
the encoded 
parameters can just be used as 
guidelines on how the QoS models can encode their parameters.

Thus maybe Jerry could separate the QSEOPC template draft into:
A section/part that describes the Token Bucket + constraints. 
This part could then emphasize that the described parameters can 
be used for interoperability purposes.

Another part of the QSPEC template draft will describe the other parameters.

The goal of this part is to provide guidelines to QoS models on how to
encode the different 
parameters, with the currently available parameters used as examples.

Best Regards,
Georgios

> Sent: woensdag 15 november 2006 10:52
> To: Ash, Gerald R (Jerry), ALABS
> Cc: NSIS Group
> > inconsistent classes.  However IMO it should still be 
> possible for a 
> > QNI to signal a PHB class if called for by the QNI's QOSM, and in 
> > which end-to-end interoperability/consistency may be achieved.
> 
> As far as I know from old DiffServ times, each domain is free 
> to use its own DSCPs and PHBs (i.e. it may even remap PHBs on 
> each other).
> Furthermore, the "service" usually doesn't only depend on the 
> PHB, but also on the PDB, i.e. PHBs + traffic conditioning mechanisms.
> I guess that it makes quite a difference what traffic 
> conditioning a domain is using. So signaling a PHB-ID alone 
> isn't very meaningful between different DiffServ domains 
> (unless they are a DS region under the same 
> administration/provider) IMHO. So if end-to-end is within a 
> single domain or consistent DS region this may work, but 
> between different ASes?
> 
> I see it as a profile description how to set the generic 
> QSPEC parameter values for different QoS classes defined in Y.1541.
> > It seems that the proposal is to introduce a QoS NSLP specific 
> > 'generic QOSM', and everybody must map to this new QOSM.  We have 
> > tried
> 
> I'm NOT talking about a generic QoSM, I'm talking about a 
> generic _QSPEC_. This is a really significant difference. 
> While the generic QSPEC may be mapped to any QoSM, mapping 
> between QoSMs is not going to work. I believe that it is 
> really essential to allow different QoSMs to be used. 
> However, we need a common understanding of what service is 
> required between domains and I see the generic QSPEC as a 
> viable means to express that. In my understanding a QOSM is a 
> means to provide services, e.g. as proposed in Appendix VI of 
> Y.1541 (using a mapping from Y.1541 classes to 
> Y.1221/DiffServ PHBs). This must be completed, however, by 
> specifying resource admission control algorithms and traffic 
> conditioning mechanisms.
> 
> > oftentimes to standardize a 'generic QOSM' and have not succeeded.  
> > OTOH we have for a long time specified these parameters in 
> a single document.

---

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 15 Nov 2006 08:50:48 -0500

Georgios and Ronald:

Please see inline [RRR].

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Georgios Karagiannis
Sent: Wednesday, November 15, 2006 5:17 AM
To: 'Roland Bless'; 'Ash, Gerald R (Jerry), ALABS'
Cc: 'NSIS Group'
Subject: RE: [NSIS] Alternatives for supporting domain-local
admissioncontroloperation in NSLP/QSPEC

Hi Roland

But the QSPEC template draft is not a generic QSPEC draft.
The Token Bucket and the constraints can be seen as something 
that can be common and can be used for the interoperability and the rest
of
the encoded parameters can just be used as guidelines on how the QoS
models can encode their parameters.

[RRR] It depends. Of course, this QSPEC draft is a "generic" one. If it
is a generic guideline without referring to any particular QOS model, it
is OK. However, to go through for all QOS models individually, it is
out-of-scope because it is a kind of implementation how to use this
QSPEC. Moreover, we have problems to accept Y.1451, DSTE, and
3GPP/Y.1451 as QOS models because they do not qualify as ones, but do
qualify as QOS SLAs.

[RRR] The use of token bucket with required constraints by any
individual QOS model is also QOS model implementation-specific criteria.
It MUST be done right, not saying some rudimentary extensions here or
there in this "generic" draft. There has to be separate drafts for all
QOS models. Moreover, there are a lot of other things need to be
addressed for each QOS model in connection with the encoding.

[RRR] It is permissible as long as it is generic one without referring
to any particular QOS models.

Another part of the QSPEC template draft will describe the other
parameters.
The goal of this part is to provide guidelines to QoS models on how to
encode the different  parameters, with the currently available
parameters used as examples.

[RRR] Again, as explained above, it has to be "generic one" without
referring to any particular QOS model. To mention any particular QOS
model is known as "use case," and any use case is out-of-scope of this
draft. If DiffServ QOS model is taken as the baseline for
interoperability, any mention of this model should also be avoided
unless it is unavoidable.

[RRR] The reason is simple: RSVP, IntServ, and DiffServ are qualified as
QOS models. They also interwork among themselves. Even for these, there
are separate QOSM drafts and more individual drafts will come out in
NSIS along this line. So, let us do it right separately without messing
up this "generic" draft.

[RRR] Y.1451, DSTE, and 3GPP/Y.1451 are QOS SLAs, not QOS models. These
QOS SLAs MUST not be included for any "standard" track RFCs. Period.
They are not interoperable either. They need a lot of works just to
prove how they will work using NSIS QOS signaling protocols and need
extensions here and there as they do not have any signaling messages of
their own. Is this clear?

Best Regards,
Georgios

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 09:38:20 +0200

Dave proposed the following:

>1. Do complete QSPEC stacking, and deal with the issues around 
>what constraints have to be met by the stacked QSPEC, whether 
>the QSPEC lower in the "stack" is opacified, and what the 
>rules are for pushing, swapping, and popping.
>
>2. Allow domain-parameters to be added to a QSPEC on domain 
>entry and removed on exit. In this option one has to describe 
>whether anything is opacified and which existing QSPEC 
>parameters get "re-interpreted"  
>if any.
>
>3. Recurse at the NSLP level, have a separate domain-private 
>NSLP session, and that would contain a domain-private set of 
>paramteres instead of the end-to-end QSPEC. I'll note that 
>this approach allows (but not requires) the two signaling 
>state machines (end-end and edge- edge through interior nodes) 
>to be decoupled.

Re-reading responses to this thread, I am left slightly confused
as to what people are supporting.  I think we need to break this
up into two questions, one that affects the QSPEC document
and one that affects the QoS NLSP.  I will send separate mails
asking for consensus on this issue.

thanks,
John