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

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

Jukka,

I could be wrong, but I assumed that the differences between
1) & 2) would be that that in 1) the NSLP would need to pop
the top-most QSPEC and send that to the RMF.  For 2), the
NSLP would just send the entire QSPEC to the RMF, and the
RMF would manipulate what it needed from the QSPEC.

So, I think that there is a difference between 1 & 2.  Are you meaning
that as the QoS NSLP is currently specified, that item 2 could
be managed with no changes to the QoS NSLP?

John

>-----Original Message-----
>From: ext Jukka MJ Manner [mailto:[email-masked]] 
>Sent: 30 November, 2006 11:11
>To: Loughney John (Nokia-NRC/Helsinki)
>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

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 4 Dec 2006 11:49:12 +0200 (EET)

Hi,

yes, that is what we want.

The point is that item 1 is not really wanted, since it affects the logic 
of the NSLP spec itself, and you need to have different NSLP-deployments 
in nodes. Thus, with item 2 the NSLP is not affect, and therefore the 
better option for NSLP designers - all NSLPs operate the same way with 
regard to the QSPEC. With item 2, what happens inside the RMF is not 
visible to the NSLP, and should stay like that.

Jukka