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

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Fri, 9 Nov 2012 05:24:52 +0000

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

Thanks
Shitanshu

On 7/13/12 6:12 PM, "Shitanshu Shah (svshah)" <[email-masked]> wrote:

>
>
>On 7/13/12 8:52 AM, "Brian E Carpenter" <[email-masked]>
>wrote:
>
>>Hi,
>>
>>On 13/07/2012 07:44, Shitanshu Shah (svshah) wrote:
>>> Hi Brian,
>>> 
>>> Sorry for the delay in the response. Keeping co-authors also in the
>>>loop.
>>> 
>>> Few clarifications
>>> - The proposal is not about end to end SLA. It is about exchanging SLA
>>> between 2 domains.
>>
>>Does that mean two adjacent domains, or two domains separated by
>>non-participating domains?
>
>It could be any. Adjacent or two domains separated by non-participating
>ones.
>
>
>>
>>This is critical, because if there are intermediate domains, we must
>>assume
>>that they will change the DSCP, because it is a mutable field.
>
>
>It makes sense for SLA exchange between those two domains, that are
>separated by
>non-participating domains, to take place only if those two domains fall
>under
>same controlled administration. I do not see otherwise why would there be
>a
>need for SLA exchange.
>
>For example, Site A and Site B are administered by Enterprise XYZ. Even
>though
>XYZ's provider for Site A means "EF" for voice and XYZ's provider for Site
>B
>means "CS5" for voice. XYZ understands those differences for voice between
>Site A and Site B. Thus SLA exchange from one site to the other in the
>context
>of any "EF" or "CS4" still is okay. A mapping may be defined at the
>receiver
>to handle the differences.
>
>If Site A and Site B are managed by two different Enterprise XYZ and ABC
>respectively then I do not see why SLA exchange to take place among them
>irrespective of what dscp they use for voice traffic.
>
>  
>>
>>> - SLA exchange does not necessarily mean automatic provision of
>>>forwarding
>>> policy. Draft does not mandate that. though a vendor may use this
>>>exchange
>>> to automatically provision forwarding policy.
>>
>>OK, these points need to be clearly stated in the Introduction, I think.
>>
>>> Couple of use-cases are described in "Deployment Considerations"
>>>section.
>>> I can clarify further that section with any clarification that comes
>>>out
>>> of this discussion.
>>> 
>>> Taking couple of use-cases to describe further in the context of
>>>Diffserv
>>> based SLA.
>>> 1.
>>> - SLA exchange between CE and PE where they are connected physically or
>>> virtually.
>>> - Customer buys voice (1 mbps), video (5 mbps) and data (2 mbps)
>>>service
>>> from the Provider.
>>> - If provider supports that voice, video and data service with EF, AF4
>>>and
>>> AF2 then instead
>>>   of telling those EF, AF4, AF2 code-points over the phone to the
>>> customer, they are, along
>>>   with rates, conveyed thru BGP
>>> 
>>>  SLA exchange here does not have any responsibility to tell CE domain
>>> which end-points should
>>>  be using which dscp code-point or which ip addresses/flows should be
>>> mapping to which dscp
>>>  Code-point. Thus there is no dscp mapping to or from to be conveyed
>>>here
>>
>>Well, you seem to expect the receiver to parse "Traffic Class Description
>>- Ascii Description of the Traffic Class" somehow and configure diffserv
>>classification and marking accordingly. So the receiver has to figure out
>>how the DSCPs that the provider accepts map to its internal DSCPs (if
>>any).
>
>Yes if receiver is using different dscp internally then mapping has to
>happen
>between Provider's dscp and internal dscp. And that is what we have
>highlighted
>in Section 6.1. Repeating what I mentioned above, aim of this proposal is
>to
>define a protocol to exchange SLA but not the provision of the mapping
>between
>sender and receiver's code-points. Yeah, if user (user here means vendor
>or
>administrator) is not able to come up with his/her own mapping to use with
>exchanged SLA and if it is left with any ambiguity then we need to look
>into
>it but then we first have to know the use-case where such condition may
>arise.
>In worst case it will be supplemental proposal which still won't not
>change
>protocol of SLA exchange.
> 
>
>>
>>> 2.
>>> - In VPN deployments where dscp code-point is preserved over VPN
>>>tunnels.
>>> - Specific Enterprise n/w let's say is spanned over different regions
>>>eg.
>>> San Jose, Atlanta,
>>>   Orlando where there is a vpn network between those sites. San Jose
>>>eg.
>>> may convey its SLA
>>>   to Atlanta, Olando for EF, AF4 and AF2 traffic.
>>> 
>>>   Here again there is no responsibility to tell which end-points should
>>>be
>>> using which dscp
>>>   Code-points. All San Jose is telling Orlando is that if it is sending
>>> any EF traffic towards
>>>   San Jose then it does not have to send more than 1 mbps
>>
>>Yes, once they agree on what "EF" is and which DSCP value it uses.
>>Again it seems to depend on the ASCII description.
>>
>>> I've looked at RFC3140. PHB id is something may make sense to be added
>>>as
>>> one of the SLA exchange
>>> Parameter. Where can I find list of PHB ids?
>>
>>There's a registry:
>>http://www.iana.org/assignments/phbid-codes/phbid-codes.xml
>>However, it's empty - in other words, nobody has found it necessary to
>>register
>>a non-default value. That means that today, only the standardised DSCP
>>values
>>at http://www.iana.org/assignments/dscp-registry/dscp-registry.xml
>>have PHB IDs.
>>
>>However, if an operator wanted its own PHB ID for use in its own SLAs,
>>it should be easy to register one. (I see that I'm a designated expert
>>for this.)
>>
>>This was set up to provide flexibility - in practice people seem to
>>prefer standard DSCPs and PHBs, but at the time people insisted on
>>flexibility.
>
>
>Sure, understood. And in those deployments that use this flexible PHB ids,
>SLA exchange needs to be in the context of such PHB ids.
>
>Regards,
>Shitanshu
>
>
>>
>>Regards
>>
>>    Brian
>>
>>> 
>>> 
>>> Thanks
>>> Shitanshu
>>> 
>>> 
>>> On 6/9/12 1:32 AM, "Brian E Carpenter" <[email-masked]>
>>>wrote:
>>> 
>>>> Hi Shitanshu,
>>>>
>>>> I think what is missing in the draft is a clear explanation of the
>>>> possible
>>>> deployment models and how they relate to the diffserv architecture,
>>>>which
>>>> is very explicit in defining the concept of diffserv domains.
>>>>Basically
>>>> that model requires DSCP mapping at every domain boundary (even if it
>>>>is
>>>> a trivial 1:1 mapping). I think you have to be very explicit that if
>>>> the BGP attribute is transmitted across a diffserv domain boundary,
>>>>the
>>>> conveyed DSCPs MUST be mapped at that boundary (with a note that
>>>>domains
>>>> could agree on a 1:1 mapping if they were within a single SLA
>>>>community).
>>>> Or you use the PHBID instead, in which case it is by definition mapped
>>>> locally inside each domain.
>>>>
>>>> By the way, as well as RFC 2475, the architecture is discussed in
>>>> RFC 3086 and in B.E. Carpenter and K. Nichols, Differentiated Services
>>>> in the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494.
>>>>
>>>> Regards
>>>>   Brian Carpenter
>>>>
>>>> On 2012-06-06 17:57, svshah wrote:
>>>>> Thanks a bunch Brian for your comments. See further inline for
>>>>>response
>>>>>
>>>>> On 6/6/12 6:00 AM, "Brian E Carpenter" <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have some comments on your draft:
>>>>>>
>>>>>>>        0x02 = IP_DSCP,   (length = 08-bits, value = 0..63)
>>>>>> 1. The DSCP is a 6 bit field (the other two bits are ECN, and you
>>>>>> can't touch them).
>>>>> If you are referring to change the length field to 6-bits, I agree.
>>>>>It
>>>>> does
>>>>> not have to be 8-bits.
>>>>>
>>>>>> 2. More seriously, the DSCP *by definition* is domain-specific. How
>>>>>> can it
>>>>>> be valid or meaningful in an end-to-end SLA?
>>>>> This question requires multiple answers, hopefully I can itemize them
>>>>> appropriately
>>>>>
>>>>> - The proposal in the draft is not specifically only for end-to-end
>>>>> SLA. The
>>>>> intentional use-case of the draft is with next hop SLA like PE to CE
>>>>> SLA,
>>>>> where PE may have SLA defined eg. for Diffserv classes which CE
>>>>>traffic
>>>>> will
>>>>> be subject to. Based on your comment I assume, you are not
>>>>>questioning
>>>>> this
>>>>> specific use case but are referring to SLA exchange across multiple
>>>>>hops
>>>>>
>>>>> - Beyond just next hop, one can envision a use-case where ASs,
>>>>>multiple
>>>>> sites spanned across multiple regions, managed by one corporate or
>>>>> provider
>>>>> may want to exchange SLAs site to site to manage traffic multi-site
>>>>>
>>>>> - Also to note that SLA exchange format is defined to send SLA to a
>>>>> specific
>>>>> one or specific list of recipients. If this SLA exchange is across
>>>>> multiple
>>>>> hops then intermediate speakers (ones that are not in the recipient
>>>>> list)
>>>>> are not subject to SLA
>>>>>
>>>>> - Receiver, for which SLA is meant to, does not have to listen to
>>>>>those
>>>>> SLA
>>>>> messages. They can ignore them. The point being that in a well
>>>>>designed
>>>>> network, SLAs will be accepted only if by design sender and receivers
>>>>> are
>>>>> expected to do so
>>>>>
>>>>>
>>>>> Please fill me in if you are referring to any specific point beyond
>>>>>ones
>>>>> described above
>>>>>
>>>>>
>>>>>
>>>>>> I realise that you say
>>>>>>
>>>>>>>    Typical use-case aimed with this proposal is for Provider to
>>>>>>>    advertise contracted SLA to Customer Edge.
>>>>>> but that is unenforceable; BGP speakers can't be expected to know
>>>>>> about QoS domain boundaries, so we must assume that this attribute
>>>>>> might cross such boundaries. In fact, you admit this in section
>>>>>> 6.1. The traffic class mapping described there MUST be applied
>>>>>> at every diffserv domain boundary that this SLA attribute crosses,
>>>>>> even to map DSCP1 to DSCP2. That seems like a bit of a deployment
>>>>>> and operational nightmare.
>>>>> While programming QoS automatically with this SLA exchange can be
>>>>>very
>>>>> helpful, there are other benefits that this method provides that
>>>>> simplifies
>>>>> administrators life specifically ones who are not very fluent on some
>>>>> of the
>>>>> QoS specifics,
>>>>>
>>>>> Taking an example Where SLA with PE is based on Diffserv classes with
>>>>> specific rates for each diffserv class
>>>>> 1) When admin has to provision QoS policy on CE, they first need to
>>>>>know
>>>>> what diffserv classes with what associated rates
>>>>>
>>>>> 2) Once that is known, translate them to Vendor specific provisioning
>>>>> (eg.
>>>>> What classification rules/configurations in Vendor's provisioning
>>>>> language
>>>>> and same for associated actions)
>>>>>
>>>>> 3) As required, define traffic class mapping as you pointed out
>>>>>
>>>>> 4) Once came up with appropriate mapping and policy, associate them
>>>>> with the
>>>>> forwarding
>>>>>
>>>>>
>>>>> While, in some cases if not all, there may be challenges for step
>>>>>(3),
>>>>> customers get it so much simplified even with step (1) and (2)
>>>>>
>>>>>
>>>>>> This is exactly what PHBIDs were intended for. Please see RFC3140.
>>>>>> You should use those instead of DSCP values. Or better still,
>>>>>> generalise the PHBID definition to cover MPLS and 802.1Q as well.
>>>>> I'll certainly look into it. I'll definitely be happy if something
>>>>>can
>>>>> be
>>>>> leveraged from RFC3140 or if can be enhanced in the context.
>>>>>
>>>>>> 3. What is the relationship of this work to
>>>>>> draft-knoll-idr-qos-attribute?
>>>>> I'll have to evaluate that. Will look into it.
>>>>>
>>>>>> 4. Finally, please run the draft through
>>>>>> http://www.ietf.org/tools/idnits/.
>>>>>> There are a lot of warnings.
>>>>> Sure, thx.
>>>>>
>>>>> Looking forward for your response/comments/suggestions
>>>>>
>>>>>
>>>>> Regards,
>>>>> Shitanshu
>>>>>
>>>>>
>>>>>> Regards
>>>>>>    Brian Carpenter
>>>>>
>>> 
>>> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2012 14:51:40 +0000

> 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. There's an active discussion on this topic in the TSVWG
(draft-polk-diffserv-stds-problem-statement, draft-geib-tsvwg-diffserv-intercon,
etc.)

>>>>> I'll have to evaluate that. Will look into it.

Still open, I think.

   Brian

---

From: "Thomas M. Knoll" <[email-masked]>
Date: Wed, 21 Nov 2012 07:36:02 +0100

Hi Brian and all,

as a short update to my mentioned BGP QoS signalling drafts, some lines 
about available resources.
1) http://tools.ietf.org/html/draft-knoll-idr-qos-attribute
2) http://tools.ietf.org/html/draft-knoll-idr-cos-interconnect

The respective BGP communities for DSCP/PHBID marking as well as class 
of service support signalling by ASes have IANA assigned numbers for 
public use.
http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xml

A quagga implementation is available and the dissection of the 
attributes is already part of the wireshark code base.

I have also made some simulations about what happens if some ASes 
support different markings and some possibly none. The outcome for the 
overall QoS achieved is dependent on the sequence of such marking 
mismatch. More background information can be found in
http://www.qucosa.de/fileadmin/data/qucosa/documents/5887/data/dissertation_knoll.pdf

So long
Thomas
--
+---------------------------------------------------------+
+ Dr.-Ing. Thomas M. Knoll                                +
+ Chemnitz University                                     +
+ of Technology              Ph. : +49 (0)371 531 33246   +
+ Reichenhainer Str. 70      Fax : +49 (0)371 531 833246  +
+ Room 416                                                +
+ 09126 Chemnitz                                          +
+ GERMANY                                                 +
+ WWW    : http://www.tu-chemnitz.de/~tkn                 +
+ E-Mail : [email-masked]                      +
+---------------------------------------------------------+

On 20.11.2012 15:51, Brian E Carpenter wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: <[email-masked]>
Date: Wed, 21 Nov 2012 08:17:18 +0100

Dear Brian,

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Brian E Carpenter
>Envoyé : mardi 20 novembre 2012 15:52
>À : Shitanshu Shah (svshah)
>Cc : [email-masked]; 
>Keyur Patel (keyupate); [email-masked]; Sandeep Bajaj
>Objet : Re: [Idr] I-D Action: 
>draft-svshah-interdomain-sla-exchange-00.txt
>
>DSCP means. 

Med: Isn't this already covered in the introduction text: 

===
   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-provisioning-profile-02
 
====

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Nov 2012 08:13:14 +0000

Hi Med,

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

    Brian

---

From: <[email-masked]>
Date: Wed, 21 Nov 2012 09:27:24 +0100

Re-,

Please see inline. 

Cheers,
Med 

>De : Brian E Carpenter [mailto:[email-masked]] 
>Envoyé : mercredi 21 novembre 2012 09:13
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Shitanshu Shah (svshah); 
>[email-masked]; Keyur 
>Patel (keyupate); [email-masked]; Sandeep Bajaj

Med: Fully agree. 

>limit for EF, for example. Without numeric parameters, the SLA

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

>> [CPP] 
>http://tools.ietf.org/html/draft-boucadair-connectivity-provisi
>oning-profile-02
>>  
>> ====
>> 
>
>

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 22 Nov 2012 00:40:33 +0000

Hi Brian,

The intention of the proposal is certainly to exchange full SLA
parameters, including if DSCP is signaled, what that DSCP means. That is
eg. capacity limit for EF and any other service (eg. relative priority,
worst case latency) that may associated with it. It is captured in the
full SLA details defined in the draft. If you mean that to be captured in
the text, it certainly can be done. Probably we can elaborate somewhere in
the text that Med highlighted.

Regarding, draft-knoll-idr-qos-attribute, after reading it through more
carefully, the purpose and usage of it is fundamentally quite different
from the purpose/usage of proposal in draft-svshah-interdomain-sla-exchange

What draft-knoll-idr-qos-attribute seems to propose is to signal eg. DSCP
(or any other relevant QoS code-point) along with IP prefix. I suspect
that would mean if one AS to advertise DSCP for an IP prefix, receiver AS
to trust advertised code-point for that IP prefix and install that for
forwarding purpose. In another words, contract is being established
through signaling (unless assumption is to have off-band contract between
AS to establish for what list of IP prefix, advertised code-point to be
trusted?). Thomas please feel free to correct me if I've not got it right.
Proposal/use-case in draft-svshah-interdomain-sla-exchange, is to exchange
after contract SLA between 2 AS.

Regards,
Shitanshu

On 11/21/12 12:13 AM, "Brian E Carpenter" <[email-masked]>
wrote:

>>http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-prof
>>ile-02
>>  
>> ====
>> 
>

---

From: "Thomas M. Knoll" <[email-masked]>
Date: Thu, 22 Nov 2012 10:46:31 +0100

Hi Shitanshu,

thank you for your comment and I will just address your section in the 
email regarding my QoS signalling drafts.
1) http://tools.ietf.org/html/draft-knoll-idr-qos-attribute
2) http://tools.ietf.org/html/draft-knoll-idr-cos-interconnect

The reasoning behind those drafts in a nutshell are as follows:

a) having even just 2 QoS classes distinguished in the global Internet 
traffic forwarding will make a huge difference in the experienced 
quality for delay sensitive services

b) signalling too detailed QoS parameters might quickly get too complex, 
which will hinder its deployment

c) prioritizing packets will often be sufficient to make the difference 
and strict reservations, delay budgets etc. create unnecessary 
complexity for the involved parties, even more so, when measurements, 
agreement validations and resulting violation charges get into place.
Hence, priority marking only is a good compromise between complexity and 
resulting service quality improvement.
--> Keeping (QoS signalling) things simple was the design guideline

d) priority marking should be aligned across layers. Thus, IP DSCP, 
Etherner prio and MPLS prio are signalled together for a homogeneous 
setup of frame/packet prioritisation across the layers.

Having said this, you are right, Shitanshu, that my drafts only address 
proper marking signalling only.
The prefix originating AS signals its supported classes (DSCPs and 
possibly L2 prios) alongside with the BGP update.
Neighbouring ASes will relay the prefixes and update the associated QoS 
class marking information as they forward the reachability information 
to their neighbours.

Finally, the operators AS might now receive several AS paths towards the 
originating AS and can see, which transit path will support which set of 
QoS classes along the way. This information can now be used to select 
the best path (QoS wise) towards the prefix originator. At the same 
time, this could also steer the wholesale decision for transit path 
contracts in the long run.

As a last remark, each forwarding AS can signal in the process of 
updating the QoS marking information in the BGP update, whether it will 
ignore a certain marking (or even all) or do a remapping into a 
different set of classes as traffic will traverse its AS.

I am not sure, whether my drafts are of relevance for your work, 
Shitanshu. However, if you regard it as related work, feel free to 
reference it in your drafts.

Best regards
Thomas