Yves,
Yves T'Joens wrote:
[...]
>
> the purpose/goal of the WG would be to define a protocol independent
> representation of Service Level Specifications, and the
> requirements/procedure for the negotiation of these.
If it comes to negotiation, I am not sure, wether this should happen on
the SLS level or on a SLA. But I think you will address this in the
framework draft.
[...]
> next week, a new version of the sls draft , a framework document and
> indicative charter will be issued. based on this, we will see how much
> interest there is to go for a BoF/WG. Since we are a bit late, i will
> however already contact Bert to ask for a slot in San Diego. So far,
> from private mails prior to the activation of this list, i have seen
> quite some interest in specification of this. Also see (
> http://www.totaltele.com/view.asp?ArticleID=31724&Pub=tt
> )
I think it is time to go for this now. Iw ill take a lot of time until
any agreement can be reached.
> >
> > Some comments to Werner's
> >
> > > 1.2, page 4, paragraph 4, "(template)"
> > > Is this really a template ? Or is rather a collection of
> >
> > Would it be a good idea to model the SLS using CIM (as in the Policy
> > Framework, where the draft actually was very well placed by Bert W.)
>
> 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.
>
> as for the placing of the draft in the policy framework group : as i
> tried to explain during the presentation in Pittsburgh, I do agree that
> there is affinity with the work of the policy framework group, 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.
Look you don't need the Policy Framework WG, on the other hand, the SLS
handling/negotiation may be very well suited for policy control.
[...]
> > >3.2, list, DSCP.
> > > Why is it only a single DSCP ? Also, is there only a single Flow ID
> > > per SLS, or can there be many ?
> >
> > A set of DSCPs is definitly needed.
> >
>
> 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.
>
> why do you definitively need a set of DSCPs ? do you mean so as to
> identify PHBGs ?
Probably I have not understand, what the granularity of the SLS is. If
an SLS contains more than one flow, does all the traffic conditioning
apply to the aggregate? So this would mean you will negotiate a set of
SLS with a customer, if you want to have different conditioning for
different flows?
In general, you are right, if you allow a list of flow ids, the set of
DSCPs is not needed, but the same holds for IP address prefixes etc.
>
> > >3.2, list, page 6, Source information.
> > > This highlights some problems with the formality chosen: usually,
> > > "X" and "set of X" are distinguished. But here (and also for the
> > > destination), "set of source prefixed" only appears as a set.
> >
> > I have problems with the exclusive OR for src & dest addresses.
> >
>
> how do you mean?
>
Again I think the Werner and I have not understand that an SLS can have
multiple flow-ids (do really want to allow severel flow-ids in an SLS?)
the exclusive OR in the list of destination addresses means you can only
specify a prefix or a host address, but not both of it. But this is not
a problem if you have severel flow ids.
> > >5. (and also bits of 1.2, etc.)
> > > The discussion on signaling appears premature and probably beyond
> > > the scope of a document specifying SLS parameters and semantics.
> >
> > 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.
I think, it should be separated. It is clear that different parameters
are used in the request and the offer, but both are a service
specification. I do not doubt, that you need some additional information
for the negotation process, but this should be handled seperately.
Marcus
>
> >
> > Marcus
>
> thanks,
>
> Yves
>
> > Koch Berthold wrote:
> > >
> > > Dear all,
> > >
> > > on behalf of Werner Almesberger (EPFL) I'm sending his comments on the
> > > TEQUILA draft.
> > >
> > > Best Regards
> > >
> > > Bert
> > > <<C.C.txt>>
> > >
> > > -
> > > _____________________________________________________
> > > Bert F. Koch Siemens AG, ICN WN CS EK P
> > > Hofmannstr. 51 Voice: +49 89 722 22 465
> > > D-81359 Muenchen Fax: +49 89 722 41 920
> > > Germany Mail: Berthold.Koch@icn.siemens.de
> > > Internet: http://www-st.inf.tu-dresden.de/aquila/
> > > _____________________________________________________
> > > More news on INTERWORKING'2000 at http://www.telenor.no/fou/iw2000/
> > > _____________________________________________________
> > >
> > > ------------------------------------------------------------------------
> > > Name: C.C.txt
> > > C.C.txt Type: Plain Text (text/plain)
> > > Encoding: quoted-printable
> >
> > --
> >
> > Dr. Marcus Brunner
> > C&C Research Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: brunner@ccrle.nec.de
> > WWW: http://www.ccrle.nec.de/
> > personal home page: http://www.tik.ee.ethz.ch/~brunner
> >
> > Adenauerplatz 6
> > D-69115 Heidelberg
> > Germany
> >
> > Phone: +49 (0)6221/ 9051129
> > Fax: +49 (0)6221/ 9051155
>
> --
> +------------------------------------------------------------------+
> | Yves T'Joens |
> | Project Manager Internet Access and Edge |
> | Network Strategy Group |
> | Francis Wellesplein, 1 phone : +32 (0)3 240 7890 |
> | 2018 Antwerp fax : +32 (0)3 240 9932 |
> | Belgium email: yves.tjoens@alcatel.be |
> +------------------------------------------------------------------+
--Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd.
E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner
Adenauerplatz 6 D-69115 Heidelberg Germany
Phone: +49 (0)6221/ 9051129 Fax: +49 (0)6221/ 9051155
This archive was generated by hypermail 2b29 : Mon Oct 16 2000 - 10:35:41 CEST