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

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 7 Dec 2006 12:59:28 -0500

Dave and Roland:

The stacking will create problems as Roland explained below. Stacking is
not only complex, it will also create problems from the simple elegant
e2e-QSPEC model implementation point of view.

Best regards,
Radhika

PS: 

1. People can see the example that I have provided using Y.1451 QOS SLA
implementation point of view. Similarly, anyone can use e2e-QSPEC as a
reference for implementations of many other things as DiffSev specs are
used as a reference for many implementations.

2. People can create many BCP drafts for implementations of QOS in the
different local domains using e2e-QSPEC spec as their references.
However, a generalized solution using QSPEC-stacking is NOT going to
happen because there are so many others ways that people can implement
in a local QOS domain.

3. One example could be: RSVP-over-DiffServ network. Two QOS models
evolved independently: Now, we have created another standard for
RSVP-over-DiffServ looking to the fact RSVP is scalable in the small
local access network and DiffServ is scalable even for the large
network. Since DiffSev is not being implemented on e2e-basis now,
RSVP-over-DiffServ standard was created (but it wan not necessary though
if e2e support of DiffServ is available).

4. NSIS e2e-QSPEC, like DiffServ, needs to be work on e2e basis making
it simple and scalable for e2e-implementations. If local QOS domains are
there, let us see what those are. If they are QOS SLAs like Y.1451 or
DSTE, they do not need QSPEC of their own. People can bring some
specific examples, we can look into those. Otherwise, let us not break
the e2e-QSPEC template model.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roland Bless
Sent: Thursday, December 07, 2006 12:02 PM
To: David R Oran
Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS;
[email-masked]; [email-masked]
Subject: Re: [NSIS] QoS NSLP: Stacking vs. tunneling vs.

Hi Dave,

please see comments inline.

David R Oran wrote:
> 
> On Dec 6, 2006, at 3:17 AM, Roland Bless wrote:
> 
>> Hi John,
>>
>> [email-masked] wrote:
>>> Could you summize your proposal, making it easier just to verify
>>> that we can come to consensus on this? It looked like there
>>> was some meandering on the email threads about some parts
>>> of your proposal, so it wasn't clear that we had complete
>>> consensus on your initial proposal.
>>
>> Ok, I'll try once again.
>>
>> 1. each QSPEC has a type (QSPEC-ID) instead of this QOSM-ID
>>    because I think that some QSPECs are applicable to more
>>    than one QOSM (e.g., the e2e QSPEC) and some QOSM may understand
>>    more than one QSPEC type.
>>
>> 2. Instead of supporting stacking QSPEC objects in QoS-NSLP
>>    I suggest to have only a "single" QSPEC object in a QoS-NSLP.
>>    If one wants to carry other QSPECs transparently or simply
>>    add parameters of local meaning etc. one could
>>    simply define an "encapsulation" for its own QSPEC type
>>    like this:
> This strikes me as really ugly and bug-prone, but it would work and
give
> the necessary functionality. In my opinion, it'sbetter to have either
an

It would be interesting to hear why it's ugly and bug-prone in
more technical detail.

> explicit stack (so you don't have to figure out whether you've escaped
> from the closed environment and generate errors), or multiple QSPEC
> objects that an RMF can fetch from QNLSP by registered type (so you
> don't have to co-mingle parsers).

Maybe I don't get your points completely, let's see, so I have a couple
of questions:
If a local QSPEC escapes, the next domain will probably not
understand the QSPEC type and send back an error indicating the
leakage. Is this a problem? Are there better ways to handle this?
What would happen in the case of stacking?
Would the RMF in the next ingress QNE simply search through the stack of
QSPECs until it hits one of the supported QSPEC types or the e2e QSPECs?
Would it ignore (an/or pass on) unknown QSPECs within the stack?
Should QoS-NSLP pass always the whole QSPEC stack up to the RMF
or only registered types?
How can we guarantee that the QSPECs are still "matching" the request if
some of them are ignored and not adapted in intermediate domains?

With this kludgy encapsulation thing, an RMF should know that
there is an e2e QSPEC (or other QSPECs) enclosed and either may ignore
it completely or process it accordingly, so the semantics should be
clear. But maybe I'm missing something or a lot of things completely,
so if you have more rationale, it would be good to hear that.

> I don't want to make a big deal about how kludgy this encoding
approach
> is - if this can get WG consensus it isn't a make-or-break design
issue.

We shouldn't really go there if this is really kludgy and ugly.
My understanding was that most people in the WG seemed to
dislike QSPEC stacking and thought it would be too complex
(that's why stacking was limited to two QSPECs only). So Georgios
and his colleagues want to have a functionality like this.
But probably there are better ways to do that...

Regards,
 Roland

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

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