Service Level Specifications and Usage BOF (sls)
Wednesday, December 13 at 1530-1730
CHAIRS:
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
- 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
conclusions:
-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.
Discussion
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