2.4.15 Service Level Specification and Usage BOF (sls)

Current Meeting Report

Service Level Specifications and Usage BOF (sls)

Wednesday, December 13 at 1530-1730

Yves T'Joens (yves.tjoens@alcatel.be)

Raju Rajan (rajan@research.att.com)

discussion list : sls@ist-tequila.org Subscription to e-mail list via http://www.ist-tequila.org/sls.html

notes taken by Emmanuel Desmet (Alcatel)


- Agenda Bashing / Introduction - yves Tjoens (5')

- Presentations on requirements for the SLS from providers
Christian Jacquenet - France Telecom (10')
Hamid Gharib - British Telecom (10')
Victor Mendoza - AT&T (10')
Raju Rajan - feedback from the mailing list

- Short intro to various efforts and related work
Policy Framework Group - Ed Elleson (10')
Internet2 QBone Effort - Ben Teitelbaum (10')
draft-tequila-sls-00.txt - Danny Goderis (10')
draft-salsano-aquila-00.txt - Martin Winter (10')

- Proposed charter review / Discussion of the proposed WG goals (35')

- Determine whether there is enough interest to form a WG

[YT: the questions from the room have the speakers names attached where we knew them or said their names]

BoF report

attendance : +/- 340 (after starting in room for capacity 80 for 20 minutes)

Yves Tjoens presented an introduction to the objectives of both the bof session and the proposed WG.

SLSU BoF Minutes

What's needed to agree on a service an info model that represents the service and a protocol to negotiate it and why do we need a WG on this ?

Today only static SLAs exist, a need for automation is perceived.

Widespread consensus on need for standardization of SLS syntax, semantics and mechanisms

Considerable interest and support from service providers, equipment manufacturers and user organizations

Not covered by other working groups

Issues for the bof

Do we need WG to standardize syntax and semantics of SLS and their negotiation in February 2002 timeframe

Interdomain / Intradomain / peering interfaces

What should be the scope of the WG

Framework document
Info model
Protocol requirements
Protocol instantiation
other issues...

Question from the room : who's doing the negotiation, a human being ?

A YT: not necessarily, it is the customer that might trigger the negotiation with the provider, this can either be a human being or a process or something else

Christian Jacquenet - France Telecom

presentation available at http://www.ist-tequila.org/sls.html

Christian presented the interest from FT to see this work being done in the IETF.

Enforcing QoS policies : the contractual issue

requirements for SLS related standardization

- high level of automation

- enforcing commitment because provisioning of (different levels) of QoS implies the ability to honor those

- deploying QoS based IP services worldwide upon a common understanding of QoS where to standardize the SLS ? IETF is the most natural place, because it involves IP

Support strongly the creation of a SLS WG : charter should include framework doc / SLS template specification doc / protocol analysis doc and applicability statement doc.

Q from the room : what percentage of customers desires such an SLS ?

A: mostly the corporate market : require strong commitments in terms of QoS from the providers. between 80 and 90% of the corporate customers require SLA.

Q (room) do you envision currency is in the SLS ?

A: ideally the answer is yes

Q: Bandwidth broker integral part of the solution ?

A : we are investigating this.

[YT: then we got the message we could move to ballroom A, which took a few minutes to get started again]

Hamid Gharib - Britisch Telecom

presentation available at http://www.ist-tequila.org/sls.html

Automated SLS negotiation is required

increasing # of customers demand a diverse range of QoS

SLS is the basis for this

need semantics (vocabulary) for defining SLS

roles and interfaces : customer provider and provider provider

negotiation model required

generic B2B , not IP specific technology should be used

SLS syntax : XML

transfer of the SLS : http and https

other initiatives : ebXML, xCBL, W3C XML

schema definitions

deliverables required from WG :

framework / SLS vocabulary and info model negotiation feb2002 is acceptable deadline

Also shortly presented the eurescom project EQUIP, among which a negotiation scenario as this project saw it. include parameters involved in traffic forecasting

Q room : do you really expect customers to forecast their traffic for the provider ? traffic on the wire is rather unpredictable.

A : yes, can give customer discount if they are able to do so.

Q room : what is the difference between QoS and coal/gas trading. These are all commodities, why should the IETF be involved in this

A from the room : I don't think the customer knows what it wants precisely when discussing QoS, whereas for coal he does.

Q: will the results of the EQUIP project be fed into IETF

A: no final decision yet about writing an IETF-draft on it, but yes, our deliverables will be publicly available once finished

Victor Mendoza AT&T

presentation available at http://www.ist-tequila.org/sls.html

Victor gave an overview of AT&Ts great interest in seeing the SLS work being specified.

Victor showed a range of protocols that can be used for the negotiation of SLSses as well as a couple of deployment scenarios

no questions from the room

YT indicated that global crossing was invited to talk at this session, but unfortunately no participant could be in san diego. however they expressed their firm interest in seeing this go to WG at the email list.

feedback from the list - Raju Rajan AT&T

presentation available at http://www.ist-tequila.org/sls.html

Raju presented the feedback (8 individuals for service providers and general) received on the list on the questions raised in preparation of this bof

Need for SLS specification and negotiation in the timeframe of 02/2002:

consensus was yes to interdomain negotiation

- provider to provider about 50%

- provider to customer about 50%

- leave intra-domain for later

Deliverables required :
framework doc : yes, including the architecture and terminology

protocol independent SLS information model : yes, preference for PCIM or XML

SLS negotiation semantics doc : yes

protocol specific instantiation : yes to cops, http ; no to ldap

how do existing protocols satisfy requirements - possible informational rfc

management considerations and terminology docs also required

discussion on this referred to the last 35 minutes

Ed Ellison : relation to the policy WG

presentation available at http://www.ist-tequila.org/sls.html

Ed presented an overview of the policy WG

Comment from the room : cees de laat : the research group of the IRTF on AAAARCH is looking at interdomain QoS and policy and also at SLA, you can find our work via the irtf homepage

A YT: if it proves relevant, we shall see to use it.

Ben teitelbaum - Internet2 Qbone

presentation available at http://www.ist-tequila.org/sls.html

Ben introduced the I2 and Qbone initiatives and thier view on SLS.

He also gave comments on the embryonic state of Abiline and other networks.

Hopes that this will be a place to experiment with QoS SLSses and where experience is gained and shared.

he further introduced some SLS basics an SLS is the technical part of the SLA bilateral and private, not a reservation for resources.

the Qbone solution : define 'services' and 'reservations' services globally well known and specified, include many parameters from the tequila draft on sls. reservations : identify a service id, specify service parameters

treat the SLS as a black box

Simple Interdomain Bandwidth Broker Signalling (SIBBS) : not mature enough to be submitted as an ID


-limited DS implementation experiences -even less with DS peering
-need to specify a few internet-wide services -automated negotiation of SLS is premature

Q: what will be the effect on BGP of SLS specification between domains

A: we specify services not SLSses, it remains a local decision of the cloud

remark Kathy Nichols: PSINET and UUNet are right now doing service level guarantee for best effort traffic. Personal notion is that the SLS containers that are to be defined must be a superset of what is allready existing. so make sure that in your definition you include such parameters as RTT specification for BE traffic, as provided today by UUNET and PSINET.

Danny Goderis - alcatel

presentation available at http://www.ist-tequila.org/sls.html

Danny presented the parameters discussed in the tequila-sls draft

Q: is there a draft about ipv6 issues ?

A : no, currently limited to v4

Q: security considerations statement in the draft. can you have a look at it.

A: this is the first version of the draft, and only basic.

comment brian carpenter : the DSCP is locally mappable => DSCP accros interfaces is basically wrong. that is why the DS WG has standardized the PHB identifiers.

Q room : are these semantics for static or dynamic SLSses

A: basically should be capable of doing dynamic SLSses

Martin Winter - siemens

presentation available at http://www.ist-tequila.org/sls.html

a service can hardly be described (and negotiated) by just using its parameters. predefined sls types , simplifies sls invocation

comment from the room : predefined SLSses have default values, i think this is to be mandatorily supported

Q: it is not clear if predefined SLSses need to be standardized as it is provider specific

A: that's exactly why also aquila has not the intention to do so

Q: in favour of well known services

A: not necessarily meaningfull across the world.

yves tjoens - discussion on the goals and milestones

YT indicated that a charter shall be drafted from the below discussions. watch the list.


Brian Carpenter : It is pretty obvious that this work should be done, but allready start today and see this resolved in 14 months time ?

The deployment today is relatively minor and there is a concern that we might be starting too soon.

Kathy nichols : confused about the goals and non-goals. Especially about no new protocol development while there is a protocol instantiation. If you specify the containers too much then what about the current proprietary stuff that will maybe not fit in what you define

A YT: it is obvious that we will start with the generic basics and that it must be extensible to accomodate new elements. further on the instantiation, it will follow from the requirements capture whether known protocols can be extended, so no new protocol work envisaged.

Q room : you should not do this, it is very difficult to specify QoS in a multidimensional space that some boxes support but others not. Either it will be too general, or it will be too basic and thus we will be continually updating the draft. We don't have enough experience today to be ready to undertake this effort, not even sure if it belongs to the IETF.

A YT: we need to come up with a basic set, in order to learn and extend

Q : it is too premature. SLAs will have a clause what happens when the SLA is breached. I'd like to see more about that and also about monitoring and measurement techniques in order to determine whether SLAs are met or not

A YT: IPPM have allready worked on these items, so we have basic set of parameters. The contractual part of the SLA is definitely outside the charter.

Q: what measurements to take to verify whether the SLS is met or not

A raju: for some services we do know what to do, and the infrastructure is in place

Comment from room : i am in favour of this work, and would like to contribute

Comment from room : also in favour and very usefull to standardize

Even though the information modela and terminology are the most important parts that need to be dealt with while negotiation may be premature.

comment from room : the most interesting part is the inter-domain and is very usefull

comment dan grossman : in favour, the DS WG is just starting on intra-domain issues and has not even thought about inter-domain. as we need to forward in parallel this might require the involvement of the IESG

comment from room : we must leverage as much as possible from the expertise of the IPPM WG. our milestones should reflect the status of standardization of the other concerned wg and the charter may be adopted that way.

YT conclusions:
we will take into account comments made during the bof, and will go and write a charter to be discussed on the mailing ngds


None received.