[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NSIS] QSPEC document

Hi Georgios, all,

I'm jumping late in this discussion as I have had problems in getting to the core of the problems discussed here. While I'm not fully confident that I have managed to grasp issues I have still a question:

Am 25.01.2007 um 13:48 schrieb Georgios Karagiannis:

Hi Jukka

I think that we actually agree, but in my opinion
the changes that Dave proposes are going beyond that:

In particular I do not agree with the last
paragrap of a), see:
"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)."

I'm actually for Dave's text suggestion, because it reflects my understanding on how the QOSM/QSPEC/NSLP interworking is actually working. However, I'm willing to learn more why it is a technical issue. More below.


This is very vague that could mean:

If the QOS-NSLP does not specify the exact
message flow charts and the associated protocol state machines
of the following scenarios, then no QOSM can use and apply
such message flow charts and protocol state machines:

* Unidirectiona/bidirectional reservation intiation, refresh,
  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

I know that the QoS NSLP is defining semantics on when and which message should be sent. But the trigger, i.e., when a message sequence is fired, is at the discretion of the RMF).

One example: If the RMF decides to tunnel the original NSLP message and start a new domain-locally signalling session in parallel, the RMF needs to tell this the QoS NSLP.

[...]


If the above is the case then NSIS is much less felxible and modular than
RSVP.
In other words, NSIS can only be used to support Y.1541 QOSM.

I think that in this case NSIS could also not support the Controlled Load
QOSM. 

An easy example could help me to follow this conclusion.

Thanks

  Martin



Best Regards,
Georgios





-----Original Message-----
From: Jukka MJ Manner [mailto:jmanner at cs.Helsinki.FI]
Sent: donderdag 25 januari 2007 13:31
To: Georgios Karagiannis
Cc: nsis at ietf.org
Subject: RE: [NSIS] QSPEC document


Hi Georgios,

Could you specify a bit? :)

We can't have unbounded flexibility, especially regarding
interoperability and e2e QoS provisioning. But we do already
provide flexibility in adding new objects to the protocols,
which, obviously as a result change typical message processing rules.

Jukka

On Thu, 25 Jan 2007, Georgios Karagiannis wrote:

Hi Jukka

What we aimed from the beginning is a combinbation of a) and b)!

Best Regards,
Georgios

-----Original Message-----
From: Jukka MJ Manner [mailto:jmanner at cs.Helsinki.FI]
Sent: donderdag 25 januari 2007 9:46
To: David R Oran
Cc: john.loughney at nokia.com; nsis at ietf.org
Subject: Re: [NSIS] QSPEC document


Hi Dave,

it seems people are truly talking past each other. I hope no one
belongs to camp (b).

Camp (a) is truly what we are aiming for, and we should end this
discussion, and move forward.

Jukak


On Wed, 24 Jan 2007, David R Oran wrote:


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



_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis