[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] QSPEC document
Hi Dave
Parts of these two proposals are new to me!
In order to uderstand the impact of these two proposals,
it might be important if you emphasize what is the impact of these
two proposals on the ongoing
NSIS specifications (QOS-NSLP, GIST, QSPEC and all QOSMs).
Furthermore, it will also be interesting if you could investigate and
discuss
the impact of these
two proposals on the following NSIS concepts:
* Unidirectiona/bidirectional reservation intiation, tear, modification of:
- bound and parallel end-to-end and edge-to-edge sessions
- bound and paralele end-to-end and end-to-edge sessions
Note that examples of an end-to-end sessions can be:
* Controlled Load QOSM
* Guaranteed Servuce QOSM
Note that examples of such edge-to-edge sessions can be:
* RSVP aggregation like QOSM
* RMD-QOSM
* interdomain and intra-domain ITU-T RACF QoS model
* PCN like congestion notifictaion and preemption QoS model.
Best Regards,
Georgios
> -----Original Message-----
> From: David R Oran [mailto:oran at cisco.com]
> Sent: woensdag 24 januari 2007 18:57
> To: Jukka MJ Manner
> Cc: john.loughney at nokia.com; nsis at ietf.org
> Subject: Re: [NSIS] QSPEC document
>
>
> On Jan 23, 2007, at 4:38 AM, Jukka MJ Manner wrote:
>
> >
> > Good. Don't we then have quite a clear statement as to what
> is allowed
> > by a QOSM to define, and what is not?
> >
> That's what I thought, but reviewing the mailing list, there
> are four people who do not think we've got it right. To some
> extent we may be just talking past each other, but to some
> extent I think there is in fact real technical disagreement.
> The best way I can think of to capture that disagreement is whether:
>
> a) The QSPEC and the RMF that operates on it have some basic,
> universally known semantics. Particular QOSMs can provide
> different semantics, but the RMF for such a QOSM is not
> permitted to admit traffic unless the parameters in the
> well-known QSPEC parameters that have been marked "mandatory"
> by the QNI can be satisfied by the QNE.
> In addition, a QNE wishing to be QOS-NSLP-compliant for
> whatever QOS Model it implements must either map its
> operation directly onto the existing API and state machine
> operation of the QOS-NSLP, or, must have a standards-track
> RFC which extends the QOS-NSLP in a backward compatible and
> interoperable way. A QOSM is *not* allowed to simply require
> that the QOS-NSLP operate in a different way than is
> specified in the standards track RFC(s).
>
> b) The QSPEC is a set of suggested useful parameters than an
> RMF can decide to use or not use at its discretion and the
> QOSM is free to add new parameters or re-interpret existing
> parameters as long as such is documented in an RFC. Further,
> if the QOSM requires new signaling functionality or a change
> to the way the QOS-NSLP operates (message flows and state
> machines) it is free to specify those as part of the QOSM
> without explicitly extending QOS-NSLP and demonstrating both
> interoperability and backward compatibility.
>
> I am firmly in camp (a). I think the existing words in the
> QSPEC document (with the exception of the one glitch we've
> already discussed and resolved) capture (a).
>
> If we have consensus around (a) I think we can move forward
> and do more word smithing if really necessary. If we don't
> and what a significant fraction of the WG wants is (b), then
> I think we really do have a problem and we are more-or-less
> back where we were before the San Diego IETF.
>
> Dave Oran.
>
> > Jukka
> >
> > On Tue, 23 Jan 2007, john.loughney at nokia.com wrote:
> >
> >> Jukka,
> >>
> >>> Isn't the fundamental issue here that a new QOSM _MUST NOT_ break
> >>> the future QSPEC and QoS NSLP standards, nor harm the
> provision of
> >>> e2e QoS.
> >>> The QOSM, or other documents,_MAY_ introduce new
> extensions - that
> >>> is why we have the so-called AB-flags in GIST and the two NSLPs.
> >>
> >> Yes basically. We want to ensure that we have e2e
> interoperability
> >> and good interworking between different QoS domains. Unbounded
> >> flexibility (and I am not claiming anyone is planning unbounded
> >> flexibility) doesn't help with interoperability.
> >>
> >> John
> >>
> >
> > _______________________________________________
> > nsis mailing list
> > nsis at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
>
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis