Subject: [NSIS] QoS NSLP: Stacking vs. tunneling vs.

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

Dave Oran proposed 3 options for supporting domain-local admission
control operation in NSLP/QSPEC in the following mail:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07178.html

As stated, these are meant as complete solutions:

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.

There seems to be consensus that 3 is mandatory, but 2 is still
desirable.  Does this mean that 2 would be optional in the QoS NSLP?  

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 30 Nov 2006 11:11:01 +0200 (EET)

Item 2 does not affect the QoS NSLP in any way. That was the main point. 
It is left to QOSM designers and the RMF. The NSLP doesn't care what the 
contents of the QSPEC is, and whether it is updated in some QNE or not.

Jukka

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 30 Nov 2006 13:00:21 +0100

Hi John

Option 2 will be described in the QSPEC templete draft and in the QoS models
that require 
to use this feature.

Best Regards,
Georgios

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: donderdag 30 november 2006 10:11
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] QoS NSLP: Stacking vs. tunneling vs.
> 
> 
> It is left to QOSM designers and the RMF. The NSLP doesn't 
> care what the contents of the QSPEC is, and whether it is 
> updated in some QNE or not.
> 
> Jukka
> 
> > 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.
> >