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

From: "Black, David" <[email-masked]>
Date: Thu, 28 Feb 2013 21:03:04 -0500

(+tsvwg list)

For context this is about the relationship of draft-ietf-idr-sla-exchange-00
and draft-geib-tsvwg-diffserv-intercon-02.  Both are currently on the tsvwg
WG agenda for Monday afternoon in Orlando (idr conflicts w/tsvarea on Wed,
so the idr session won't work well for looking at both drafts).  The purpose
of this note is to start some discussion in preparation for that session.

This message is sent as an individual with <tsvwg WG co-chair hat OFF>.

The drafts appear to be aimed at different, but overlapping use cases -
the idr-sla-exchange draft appears to be primarily concerned with
provider-customer relationships and purchased destination (AS) specific
service (e.g., see Section 7).  The diffserv-intercon draft is primarily
concerned with interconnection of carrier networks - while that's primarily
a provider-provider case that appears to be of less interest to the
idr-sla-exchange draft, both the provider-customer and purchased service
(e.g., in the form of transit) cases may occur in provider-provider
relationships.

As already noted in the thread, the drafts support rather different SLA
frameworks among networks:

- idr-sla-exchange is descriptive and broad - it anticipates a plethora
	of possible multi-class SLA specifications that may need to be
	described based on specific contracts with customers and other
	network operators.  It includes bandwidth thresholds and remarking
	instructions for a variety of marking mechanisms (e.g., diffserv,	
	Ethernet priority).
- diffserv-intercon prescribes a single multi-class SLA specification
	and a single set of diffserv PHBs (which have preferred DSCPs)
	intended for widespread use by a single carrier.

Based on the above, the drafts could well be complementary, although more
discussion of the relationship among them seems like a good idea in Orlando.

In addition, I concur with Brian's conclusion on the idr-sla-exchange draft:

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

In particular the various rates in that idr-sla-exchange draft appear to be
inventing a new rate-based QoS specification framework, and the draft isn't
particularly precise job of specifying it (as Brian's comments point out).

This sort of work is not new to IETF, e.g., see the FLOWSPEC concept in
RFC 2210, and the QSPEC concept in RFC 5975, which reuses the basic 
FLOWSPEC concept in a completely different protocol framework.

Thanks,
--David

> -----Original Message-----
> From: Shitanshu Shah (svshah) [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2013 7:00 PM
> To: Black, David; Brian E Carpenter; draft-ietf-idr-sla-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: I-D Action: draft-ietf-idr-sla-exchange-00.txt
> Importance: High
> 
> 
> Hi David,
> 
> In the context of this discussion, couple of important points of
> motivation/consideration for sla-exchange draft
> 
> - It is critical to have Diffserv support in SLA exchange. However, at the
> same time, it should not be limited to Diffserv only. The SLA exchange
> language in draft-ietf-idr-sla-exchange-00.txt should work for other types
> of classification rules as well
> 
> - Current stat of SLA exchange draft does not intend to standardize any
> code-point or PHB. Rather defined language in the draft merely refers
> standards defined outside the context. You have precisely captured in your
> comments that
> SLA exchange draft is more descriptive in contrast to diffserv-intercon
> which is more prescriptive
> 
> An additional note, SLA exchange may be among nodes in the same
> administrative domain or across. To support earlier use-case, draft should
> not have to mandate traffic class definition exchanged be based on
> specific standards only.
> 
> 
> Unfortunately, I will not be able to make it to IETF this time. However, I
> know Keyur (co-author) will be there and possibly other co-authors of the
> draft. It surely will be good to have a conversation among key people and
> as per outcome, we can have a further follow-up?
> 
> Regards,
> Shitanshu
> 
> 
> 
> On 2/27/13 9:01 AM, "Black, David" <[email-masked]> wrote:
> 
> >With my tsvwg WG co-chair hat on, I strongly concur with Brian that this
> >idr-sla-exchange draft needs to be discussed in the tsvwg WG.  In Orlando,
> >the tsvwg WG meeting expects to take up:
> >
> >  draft-geib-tsvwg-diffserv-intercon-02.txt
> >  https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/
> >
> >which is considerably more prescriptive, in contrast to the
> >idr-sla-exchange draft's descriptive approach.
> >
> >While that diffserv-intercon draft is not a WG draft, the tsvwg WG does
> >intend to do work in this area, so some coordination to have a single
> >overall approach seems advisable.  This does *not* imply a priori that
> >we need to select one draft and drop the other, and I surely do not want
> >to work on BGP details in tsvwg ;-).
> >
> >Unfortunately the idr and tsvarea (Transport Area open meeting) sessions
> >conflict on Wednesday morning in Orlando - would it make sense to take an
> >initial look at this idr-sla-exchange draft during the Monday afternoon
> >tsvwg session where there are conflicts with any routing WG meeting, and
> >perhaps have key people talk privately afterwards ?
> >
> >Thanks,
> >--David (tsvwg WG co-chair)
> >----------------------------------------------------
> >David L. Black, Distinguished Engineer
> >EMC Corporation, 176 South St., Hopkinton, MA  01748
> >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> >[email-masked]        Mobile: +1 (978) 394-7754
> >----------------------------------------------------
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[email-masked]]
> >> Sent: Monday, January 07, 2013 10:25 AM
> >> To: [email-masked]
> >> Cc: [email-masked]; [email-masked]
> >> Subject: Re: I-D Action: draft-ietf-idr-sla-exchange-00.txt
> >>
> >> 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
> >
>