Yves, Raju,
I have attached below some comments from Mike Ainger (General Manager, Core
Network Design & Planning at Global Crossing UK) to your questionnaire,
indicating GC's continued interest in the SLS work.
Good luck with the BOF.
Best Regards
Richard
==============================================================
Question 1:
Is there a need to standardize the syntax and semantics of QoS
Service Level negotiation on the following interfaces.
- intra-domain interfaces (typical example would be a softswitch interface
towards the network management platform for automatic sizing of trunks
between voice gateways)?
- inter-domain interfaces for the customer-provider relationship (typical
example would be allowing an automated VPN configuration be flexible managed
by the customer on the provider domain) ?
- inter-domain QoS provisioning for the provider-provider relationship
(typical example would be to extend the above over multiple IP service
providers)
Q1 Response:
Global Crossing views the standardisation of the Customer-Provider interface
as the most immediately relevant to its business. The standardisation of SLS
parameters would enable means of automatic SLS negotiation between Customer
& Service Provider and would be useful in dynamic QoS provisioning of the
provider's network. Standardising the Provider-Provider relationship would
follow naturally as QoS services are offered on an inter-domain basis. The
intra-domain interface is new to us but would have obvious benefit if a
provider had developed engineering/management tools for provisioning QoS in
the network.
Question 2 :
Do you see any use for it in the timeframe that a working group
would deliver (Feb 2002)? The alternative is to leave it to each vendor to
reach agreements with their customers, or to postpone work on this to a
later date after 2002.
Q2 Response:
Standardisation of the Customer-Provider interface would be of benefit in
this timeframe for embryonic QoS based services. The alternative of each
provider developing proprietary solutions is undesirable as it inhibits the
development of third party tools/products.
Question 3:
If there is a need to standardize, should this be done in the
IETF?
Q3 Response:
The IETF would be the appropriate place to perform the standardisation
activity as it would facilitate interaction with other relevant IETF WGs,
such as Policy WG.
Question 4:
Which of the following should be the deliverables of the working
group?
- Framework document (including architecture)
- Protocol independent SLS information model document
- Negotiation Requirements and Semantics document
- Interface protocol standardization (e.g. XML/LDAP/....)
- others ?
Q4 Response:
All the above seem necessary, although the Interface Protocol
standardisation work will
introduce some diversity. For example, providers of business services, such
as Global Crossing, may have different protocol requirements from providers
of entertainment services.
Question 5:
Would your organisation be willing to actively contribute to
this effort ?
Q5 Response:
Global Crossing participates in the IST TEQUILA project, which actively
addresses SLS requirements, and will contribute to IETF standarisation
activities through TEQUILA.
==================================================================
-----Original Message-----
From: Raju Rajan [mailto:rajan@research.att.com]
Sent: 09 November 2000 16:37
To: sls@ist-tequila.org
Subject: Issues for the BoF
Hi all,
Yves and I have put together a preliminary list of issues that would help
focus the BoF, and suggest directions/guidelines for a working group. (This
is not an exhaustive list of all technical SLS related issues; just those
that will help define a charter and work-items.)
It would be good if we could get some discussion on the list around these
basic questions. Please feel free to suggest some more. Based on the
discussion here, we will send a revised list to the speakers/participants at
the BoF, and ask them to address some or all aspects below.
NOTE: We're trying to get a representative group of experts, potential users
and vendors for the BoF to help us all better understand the technical and
commecial directions. Please contact Yves or myself with any suggestions. In
particular, speakers with expertise in the Service Provider, carrier or
solution provider domains would be great! (Please be understanding of time
constraints while suggesting names.)
Thanks,
Raju and Yves
----------------------------------------------------------------------------
-------------------------------
Question 1: Is there a need to standardize the syntax and semantics of QoS
Service Level negotiation on the following interfaces.
- intra-domain interfaces (typical example would be a softswitch interface
towards the network management platform for automatic sizing of trunks
between voice gateways)?
- inter-domain interfaces for the customer-provider relationship (typical
example would be allowing an automated VPN configuration be flexible managed
by the customer on the provider domain) ?
- inter-domain QoS provisioning for the provider-provider relationship
(typical example would be to extend the above over multiple IP service
providers)
Question 2 : Do you see any use for it in the timeframe that a working group
would deliver (Feb 2002)? The alternative is to leave it to each vendor to
reach agreements with their customers, or to postpone work on this to a
later date after 2002.
Question 3: If there is a need to standardize, should this be done in the
IETF?
Question 4: Which of the following should be the deliverables of the working
group?
- Framework document (including architecture)
- Protocol independent SLS information model document
- Negotiation Requirements and Semantics document
- Interface protocol standardization (e.g. XML/LDAP/....)
- others ?
Question 5: Would your organisation be willing to actively contribute to
this effort ?
++++++++++++++++
Some more technically oriented questions (answer if you feel comfortable and
have an explicit technology choice, otherwise skip this section).
Question 5: what should be the protocol independent data representation
language ?
- PCIM
- XML
- BNF
- Any others?
Please help us focus on just one or two.
Question 6: What are the negotiation protocols that make sense in the
environment that you chose?
Choices: PPP, WAP, HTTP, SIP, RSVP, shared LDAP directories, COPS, ...
Please help us focus on just one or two.
Question 7: What negotiation model makes sense in the environment that you
chose?
Choices:
Subscriber signup w/ no confirmation
Subscriber signup with confirmation
Provider sends menu followed subscriber signup with our without
confirmation
Provider sends menu followed by subscriber signup with confirmation and
monitoring updates
Provider sends menu followed by more complex negotiation process with
confirmation and monitoring updates and potential re-negotiation
Any others ...
Again, please help us focus.
Question 8: Which formats make sense for documentation of the syntax of
negotiation elements?
Choices: XML DDTs, LDAP schemata, COPS PIBs, PPP elements (?), RSVP Policy
Elements, ...
Focus, focus, focus ;)
Question 9: any other comments/questions/hints ?
**********************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed and may
not be divulged to any third party without the express permission of
the originator. Any views expressed in this message are those of the
individual sender, except where the sender specifically states them to
be the views of Racal Research Ltd.
**********************************************************************
This archive was generated by hypermail 2b29 : Fri Dec 08 2000 - 15:01:05 CET