Werner Almesberger wrote:
>
> [ Retrying ... this was blackholed by the list processor last Monday ]
>
> 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 ;-)
don't forget XML.
>
> > 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
certainly the latter makes me worried as well, since this might be out
of control of the network.
>
> 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.)
>
agreed.
> >> 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.
the framework should clarify the above
cheers
Yves
>
> - 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 : Fri Oct 20 2000 - 11:16:32 CEST