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

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Fri, 1 Mar 2013 17:09:58 +0000

Hi David,

Please find response inline ##svshah

On 2/28/13 6:03 PM, "Black, David" <[email-masked]> wrote:

>(+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.

##svshah, While provider-customer relationships and purchased destination
service has been primary motivation for the idr-sla-exchange, the proposal
is generic enough to support any AS to any AS including (not limited to),

- provider-provider
- Site-Site with one Customer's own multi-site network

>
>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

##svshah, well plethora may be too extreme. The intention is not to exclude
any parameter that limits describing SLA.

The key is to be able to describe SLA through in band signaling without
requiring administrators have multi-level manual interaction to get SLA
of interest.

>	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.

##svshah, one of the key value adds from diffserv-intercon is standardizing
preferred inter-connection DSCPs. I personally think that is useful.

To define QoS SLA, though I think we need more than just a definition of
PHBs.
The intention of idr-sla-exchange draft is not to standardize DSCP and PHBs
(which should come from Diffserv standards outside the context of
sla-exchange
draft) but the intention is to convey SLA parameters, in-band, based on
those
standards.

Exception - In non-diffserv domains, SLA exchange may be based on other
types
of standards (e.g. MPLS, Ethernet .1q).. Or in cases like Site-Site (within
one Customer's domain), the class definition may be more granular than just
a code-point.

>
>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.

##svshah, Thanks for the reference. It is desirable to re-use any existing
specification that can meet the needs. I'll be happy to evaluate them. I'll
take a look at the specification.

Regards,
Shitanshu

>
>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
>> >
>> 
>

---

From: <[email-masked]>
Date: Wed, 6 Mar 2013 10:54:38 +0100

David,

I agree, relationship between both documents needs more discussion.
As diffserv-intercon already refers to work of Thomas Knoll, a
future reference to idr-sla-exchange certainly isn't an issue.
But I'd prefer to look at both as separate activities which
may benefit from each other for the time being.

Regards,

Rüdiger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Friday, March 01, 2013 3:03 AM
To: Shitanshu Shah (svshah)
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-idr-sla-exchange-00.txt

<snip>

concerned with interconnection of carrier networks - while that's primarily

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.

<snip>