Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-00.txt

From: [email-masked]
Date: Thu, 03 Jan 2013 12:56:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Inter-domain SLA Exchange
	Author(s)       : Shitanshu Shah
                          Keyur Patel
                          Sandeep Bajaj
                          Luis Tomotaki
                          Mohamed Boucadair
	Filename        : draft-ietf-idr-sla-exchange-00.txt
	Pages           : 23
	Date            : 2013-01-03

Abstract:
   Network administrators typically provision QoS policies for their
   application traffic (such as voice, video) based on SLAs negotiated
   with their providers, and translate those SLAs to vendor specific
   configuration language.  Both learning of SLA, either thru SLA
   documents or via some other out-of-band method, and translating them
   to vendor specific configuration language is a complex, many times
   manual, process and prone to errors.  This document proposes an in-
   band method of SLA signaling which can help to simplify some of the
   complexities.

   This document defines an operational transitive attribute to signal
   SLA details in-band, across administrative boundaries (considered as
   Autonomous Systems (AS)), and thus simplify/speed-up some of the
   complex tasks.

   Though the use-case with the proposed attribute is explicitly defined
   in this document, purpose of this attribute is not limited to this
   use-case only.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jan 2013 15:25:13 +0000

Hi,

I don't understand which reference model for inter-domain SLAs
is being used here. There is an arbitrary list of element types
(IP_DSCP,  MPLS_TC,  802_1Q_COS, 802_1Q_DEI, PHB_ID) and then
an arbitrary list of some QoS metrics. Presumably some of those
metrics map on to some of the element types, but it isn't obvious
and I am certain there are gaps.

I don't think you can answer this with the text at the end of
Section 6:

>   There are well-defined recommendations that exist for traffic class
>   mapping between two technologies.  Receiver MAY use those defined
>   recommendations for traffic class mapping or MAY define its own as
>   per its network Traffic Class service definition to map to advertised
>   Traffic Classes.  It is completely up to the receiver how to define
>   such traffic class mapping.

Firstly, if there are such recommendations, they should be given as
references. Secondly, why was the arbitrary set of QoS metrics chosen
and how do we know that they are necessary and sufficient? (For
example, I don't see any metric for drop rate, and for some traffic
classes that is an important metric.)

I think this draft needs to be discussed in TSVWG before it goes
much further. A consistent model for QoS metric signalling is needed
before we standardise a mapping onto IDR.

Nits
----

[RFC2474], [RFC2475]  and [RFC3140] are listed as references
(presumably for IP_DSCP and PHB_ID) but they are not cited in the
text. That will not get through the final ID-nits check.

Also [RFC2475] is listed as a Normative reference, but it should
be Informative.

Why is [RFC3552] listed as a reference?

Why is *obsoleted* [RFC1771] listed as a reference?

Why is [RFC4760] *not* listed, since this needs to work for IPv6?

The English in this draft is quite painful in many places. Here
is one sentence chosen at random:

>   Taking same voice service as an
>   example, given Provider already may provision definition of EF code-
>   point for such, signaling this code-point traffic class from PE to CE
>   along with low latency service definition, omits administrator at the
>   CE to worry about such translation.

I'm guessing that this means:

   Taking voice service as an
   example, a given provider might already provision the EF code-
   point for such traffic. Signaling the code-point for this traffic class from PE to CE,
   with a low latency service definition, would avoid manual operations by the administrator at the
   CE.

Please run ID-nits and fix the 2 errors and 11 warnings.

Regards
   Brian Carpenter

---

From: James Polk <[email-masked]>
Date: Tue, 08 Jan 2013 23:07:47 -0600

Brian

I, for one, want to thank you for pointing this draft out to the 
TSVWG chairs. It is now on our radar. Speaking for me, individually, 
and as a chair of TSVWG, I want to see this run by TSVWG as a whole 
for the reasons you mention.

James