Re: [Idr] I-D Action: draft-svshah-interdomain-sla-exchange-00.txt

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : Brian E Carpenter [mailto:[e-mail]] 
>Envoyé : mercredi 21 novembre 2012 09:13
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Shitanshu Shah (svshah); 
>[e-mail]; Keyur 
>Patel (keyupate); [e-mail]; Sandeep Bajaj
>Objet : Re: [Idr] I-D Action: 
>draft-svshah-interdomain-sla-exchange-00.txt
>
>Hi Med,
>
>On 21/11/2012 07:17, [e-mail] wrote:
>> Dear Brian,
>> 
>> Please see inline. 
>> 
>> Cheers,
>> Med 
>> 
>>> -----Message d'origine-----
>>> De : [e-mail] [mailto:[e-mail]] De la 
>>> part de Brian E Carpenter
>>> Envoyé : mardi 20 novembre 2012 15:52
>>> À : Shitanshu Shah (svshah)
>>> Cc : [e-mail]; 
>>> Keyur Patel (keyupate); [e-mail]; Sandeep Bajaj
>>> Objet : Re: [Idr] I-D Action: 
>>> draft-svshah-interdomain-sla-exchange-00.txt
>>>
>>> On 09/11/2012 05:24, Shitanshu Shah (svshah) wrote:
>>>> Keeping idr in the loop..
>>>>
>>>> Brian,
>>>> Your review comments are addressed in the revised draft:
>>>> 
>http://datatracker.ietf.org/doc/draft-svshah-interdomain-sla-exchange
>>>> Please review and suggest/comment if any..
>>> I think you still need to state somewhere that if a DSCP is 
>signalled,
>>> the two parties must have an out-of-band agreement about what that
>>> DSCP means. 
>> 
>> Med: Isn't this already covered in the introduction text: 
>
>I don't believe that is specific enough. The correspondence between
>a DSCP and a PHB is locally defined and the exact parameters of
>a PHB are locally defined - that is the nature of diffserv.

Med: Fully agree. 

>While there is a move in TSVWG to define standard inter-operator
>semantics for diffserv, at the moment it is quite insufficient
>to agree on the "nature" - you need to agree on the capacity
>limit for EF, for example. Without numeric parameters, the SLA
>is incomplete.

Med: Agreed. This is the purpose of http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profile-02 which is cited in draft-svshah-interdomain-sla-exchange (See Section 3 of the CPP draft). 

>
>    Brian
>
>> 
>> ===
>>    Typically there is a contractual Service Level Agreement (SLA)
>>    negotiated between Customer and Provider or between one 
>Provider to
>>    another Provider [CPP].  This contractual agreement defines the
>>    nature of the various traffic classes (i.e. traffic match 
>conditions)
>>    and services needed for each traffic class.  The contract 
>may exist
>>    at different levels of traffic granularity.  The contract could be
>>    full line-rate or sub rate for aggregate traffic.  Or it could be
>>    even finer granular traffic distinction with services defined for
>>    standard code-points or for specific set of prefix or for set of
>>    well-known application types.
>> 
>> [CPP] 
>http://tools.ietf.org/html/draft-boucadair-connectivity-provisi
>oning-profile-02
>>  
>> ====
>> 
>
>