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

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Wed, 27 Feb 2013 23:59:41 +0000

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: Thu, 28 Feb 2013 08:46:01 +0100

Dear David,

I'm aware of dafft-geib-* and I'm following that work. As far as I'm concerned (not as a co-author of draft-ietf-idr-sla-exchange), I provided comments to draft-geib-* several times; see for instance:
* http://www.ietf.org/mail-archive/web/tsvwg/current/msg11713.html
* http://www.ietf.org/mail-archive/web/tsvwg/current/msg11594.html

IMHO, draft-ietf-idr-sla-exchange and dafft-geib-* are not competing approaches. 

Saying that, I fully agree with you presenting draft-ietf-idr-sla-exchange in tsvwg would help in clarifying the scope and the goals for this work. 

Cheers,
Med

>-----Message d'origine-----
>De : Black, David [mailto:[email-masked]] 
>Envoyé : mercredi 27 février 2013 18:02
>À : Brian E Carpenter; [email-masked]
>Cc : [email-masked]; [email-masked]
>Objet : RE: I-D Action: draft-ietf-idr-sla-exchange-00.txt
>Importance : Haute
>
>> >   per its network Traffic Class service definition to map 
>to advertised
>> >   point for such, signaling this code-point traffic class 
>from PE to CE
>> >   along with low latency service definition, omits 
>administrator at the
>>    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.
>>