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

From: <[email-masked]>
Date: Mon, 4 Dec 2006 10:46:13 +0200

So, I assume that you are supporting option 2, correct?

John 

>-----Original Message-----
>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 30 November, 2006 14:00
>To: 'Jukka MJ Manner'; Loughney John (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: RE: [NSIS] QoS NSLP: Stacking vs. tunneling vs.
>
>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.
>> 
>> 
>> 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
>> 
>> On Thu, 30 Nov 2006, [email-masked] wrote:
>> 
>> > 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
>> 
>
>
>

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 4 Dec 2006 10:21:50 +0100

Hi John

>From the three options listed below, option 3 is considered any way. 
Thus in addition to option 3 also option 2 has to be considered.

Best Regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: maandag 4 december 2006 9:46
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> >Option 2 will be described in the QSPEC templete draft and 
> in the QoS 
> >models that require to use this feature.
> >
> >
> >Best Regards,
> >Georgios
> > 
> >
> >> Item 2 does not affect the QoS NSLP in any way. That was the main 
> >> point.
> care what 
> >> the contents of the QSPEC is, and whether it is updated in 
> some QNE 
> >> or not.
> >> 
> >> Jukka
> >>