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

From: "Black, David" <[email-masked]>
Date: Sun, 28 Jul 2013 08:57:29 -0400

Shitanshu,

The use of the IPFIX IANA registry and the TSpec are significant improvements.

I noticed one more thing:

The 0x07  = DROP_THRESHOLD Classifier Element value in a Traffic Class appears
to allow mixing of different types of drop thresholds.  That seems like a bad
idea, as I would expect most networks to be managed with a single primary type
of drop thresholds.  I'd suggest one of two approaches:

	- Put the drop threshold type in the classifier element, and remove it
		from each drop-priority record.
	- Leave the type where it is, and state that mixing types SHOULD NOT be
		done, with a warning that inconsistent and unexpected behavior
		may result if types are mixed because the mappings between types
		may vary by network.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shitanshu Shah (svshah)
> Sent: Thursday, June 27, 2013 10:37 AM
> To: [email-masked]; [email-masked]
> Subject: [tsvwg] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt
> 
> 
> Dear WG,
> 
> Following is a revised draft incorporating feed-back/comments from the
> last IETF.
> 
> Notable changes from the last revision,
> - use of IPFIX IANA registry for Classifier Elements
> - use of Tspec for SLA rates
> - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2
> rates
> 
> Please provide comments,
> 
> Regards,
> Shitanshu
> 
> 
> On 6/27/13 7:28 AM, "[email-masked]" <[email-masked]>
> wrote:
> 
> >
> >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-01.txt
> >	Pages           : 24
> >	Date            : 2013-06-27
> >
> >Abstract:
> >   Network administrators typically provision QoS (Quality of Service)
> >   policies for their application traffic (such as voice, video) based
> >   on SLAs (Service Level Agreements) 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)), thus simplify and speed-up some of the
> >   complex provisioning 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-01
> >
> >A diff from the previous version is available at:
> >http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-sla-exchange-01
> >
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >_______________________________________________
> >I-D-Announce mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/i-d-announce
> >Internet-Draft directories: http://www.ietf.org/shadow.html
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Mon, 29 Jul 2013 14:23:23 +0000

Thank you David for your review and comments..

Regarding drop thresholds, indeed intention is to provide a facility to
take multiple (type-value, burst) pairs but for a single primary type.
Agreed, current definition in the draft is loose to interpret eligible use
of multiple types for drop thresholds.

I'll modify the structure for drop thresholds to take type definition once
with multiple (type-value, burst) pairs.

Regards,
Shitanshu