Yves T'Joens wrote:
> we haven't used any specification language so far, CIM is a pretty good
> candidate indeed. Internally we originally used a BNF notation scheme
> (which is a bit less heavy), but i would support going for CIM.
I was also hoping that BNF would be sufficient ... CIM is powerful but
I suspect it may add a lot of unnecessary overhead ... (hmm, I see a
specification language war coming up ;-)
> but you don't need the policy framework architecture for supporting the SLS
> negotiation. In that sense, it is different enough to allow the creation
> of a different working group.
Agreed. Also, as far as I can tell, the scope of the SLS work can
be quite clearly defined. So there is hope that things won't get
side-tracked too much. (Which is always a risk if you add work on
peripheral issues to a group with a broad spectrum.)
>>>3.1, general.
>>> Typical SLAs in use today include geographic references like "no more
>>> than X ms RTT to any of our routers in Europe". Example:
>>> http://www.uk.uu.net/customerservices/sla/tandcs/
>>>
>>> Such specifications are probably too difficult to express in a general
>>> formal way, so the current approach of ignoring them seems appropriate.
>>> Nevertheless, it may be good to mention them, simply due to their
>>> current practical relevance.
>>
>> I don't think that they are too difficult, but on an other level of
>> abstraction. (part of domain name? Some specific countries, regions etc.
What I mean is this: there are always lots of little "private" bits
showing up in an SLA. I don't think it's worth the effort to try to
integrate them all into a general SLS model.
With RTT, I see the following problems:
- it's hard to define in the context of Diffserv (besides trivial
cases where an SLS containing an RTT is constructed from two SLS'
with only one-way delays)
- it implies traffic conformance rules for the reverse direction,
which may generate references to other SLS', etc.
- the properties of the reflection procedure need to be specified
NB: not having the concept of RTT in the SLS doesn't prevent a provider
from talking about RTT in the SLA.
> you can have multiple flow IDs attached to one SLS, but then one would
> police on the aggregate of the packets that are classified as such.
> this is different from identifying multiple SLSses for which policing is
> done on any individual flow ids.
Concerning classification (in a broad sense - basically everything
you do to decide what to do with a packet, including metering), I think
we ought to be able to express everything that is in
draft-ietf-diffserv-mib-04.txt or draft-ietf-diffserv-model-04.txt
In particular, I think it would be a mistake to knowingly exclude
functionality already provided for in the drafts mentioned above.
(It's less of a problem if the SLS model exceeds the capabilities
of the drafts a bit, because a) real life will impose its
restrictions anyway, and b) some functionality may be provided by
some means beyond the scope of those drafts.)
>> I think there should be a requirements draft for the negotiation anyway.
>
> I don't know if one can really separate them, since a request for an SLS
> subscription/invocation may carry a different set of parameters then the
> ack/offer being presented by the network. we will try to clarify this in
> our next version.
At the Salzburg meeting, we had broad consensus that there should be
(at least) two documents on SLS': one dealing with what is basically at
a flow(s) level (we called this the "invoked" service), while the second
one would focus on the invocation and other things going into the
subscription. I think this distinction it useful and it will help to
keep things consistent in their respective areas.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH Werner.Almesberger@epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
This archive was generated by hypermail 2b29 : Mon Oct 16 2000 - 14:12:29 CEST