Subject: RE: Is the advertisement (IGP) of available BW at each pre-emptio n le vel is a DS-TE- requirement ?

From: [email-masked]
Date: Tue, 13 Nov 2001 23:05:13 -0000

Francois,  I don't think its that simple.
 
1st, there is no relationship between a packets up-state fowarding (QoS)
requirements and its 'importance' (vis-a-vis its need to survive over some
other packet, in either the same or different DS class)....DS classes simply
do not give this information.  For example, using LDP and like-DS-class
merging across  VPN populations allows no control over per VPN topology
survivability.  This is a problem IMO.
 
2nd, largest BW packing of 'path entities' is the most efficient way to do
things if all path entities have the same survivability attribute.  I can
imagine a case of large(r) L-LSP carrying BE traffic and a small(er) E-LSP
carrying VPN traffic.......if I have an availability SLA to meet for the VPN
LSP, then irrespective of the size of the BE LSP I ought to restore the VPN
traffic before I even consider the BE traffic.
 
regards, Neil

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: 13 November 2001 12:56
To: Choudhury, Sanjaya; Jim Boyle
Cc: te-wg
Subject: Re: Is the advertisement (IGP) of available BW at each pre-emption
le vel is a DS-TE- requirement ?

Choudhury,

At 20:17 09/11/2001 -0500, Jim Boyle wrote:

On Fri, 9 Nov 2001, Choudhury, Sanjaya wrote:

>       Q3. In a DiffServ TE domain, where the network administrator
>       initiates the creation the TE tunnels (using MPLS-TE-MIB ),
>       when/how can he take advantage of the following pre-emption
>       scheme:
>               a) Preemption within the same DiffServ traffic class
>               b) Preemption across different DiffServ traffic classes

I'm not sure how people use the MPLS-TE-MIB to setup TE tunnels, so I
can't help you there.  I think you mean class-type above, so again, that
is a specific proposal.

I am not sure I fully get the question (in particular I don't see the
relationship with the fact that you set up tunnels using MIB or not), but
let me quote some draft text from teh drafts we're working on as it may
help:

"
First, a Service Provider using two Class-Types (one for Voice and one for
Data), may elect to configure the following to ensure that Voice LSPs are
never driven away from their shortest path because of Data LSPs:
        -all Voice LSPs to preemption priority 0
        -all Data LSPs to preemption priority 1

Another Service Provider may elect to configure the following in order to
optimize global network resource utilization by favoring placement of large
LSPs first:
-       all large size Voice LSPs to preemption priority 0
-       all large size Data LSPs to preemption priority 1
-       all small size Voice LSPs to preemption priority 2
-       all small size Data LSPs to preemption priority 3
"

Note that this is based on the observation that, today, a common use for
preemption is to give higher preemption to large LSPs in order to get better
global utilisation. You get a much better network utilisation by fitting big
things first and then small ones (just like filling up the boot of the
family car when going away on holidays, really).

Hope that helps.

Francois

>       Thanks,
>       sanjay

_________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 89 108 159
Fax:                   +33 4 97 23 26 26
Email:                 [email-masked]
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis 
FRANCE
_________________________________________________________

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Nov 2001 10:37:44 +0100

Neil,

>Francois,  I don't think its that simple.

Let me clarify :
The two scenarios below were just meant to be simple examples of what an SP 
may want to do. It is not meant to restrict other scenarios in any way. 
Text will be adjusted to make it clear that those are just examples.

>carrying VPN traffic.......if I have an availability SLA to meet for the 
>VPN LSP, then irrespective of the size of the BE LSP I ought to restore 
>the VPN traffic before I even consider the BE traffic.

Perhaps, we could add a 3rd example based on your above scenario with 
something like this.

"Yet another Service Provider may elect to configure the following in order 
to (i) ensure that Premium Data LSPs are never driven away from their 
shortest path because of Best-Effort LSPs while (ii) optimize global 
network resource utilization by favoring placement of large LSPs first:
-       all large size Premium Data LSPs to preemption priority 0
-       all small size Premium Data LSPs to preemption priority 1
-       all large size Best-Effort LSPs to preemption priority 2
-       all small size Best-Effort LSPs to preemption priority 3"

Is that in line with the scenario you described?

Thanks for your input

Francois

>>Subject: Re: Is the advertisement (IGP) of available BW at each 
>>pre-emption le vel is a DS-TE- requirement ?
>>
>>Choudhury,
>>
>>let me quote some draft text from teh drafts we're working on as it may help:
>>
>>"
>>First, a Service Provider using two Class-Types (one for Voice and one 
>>for Data), may elect to configure the following to ensure that Voice LSPs 
>>are never driven away from their shortest path because of Data LSPs:
>>optimize global network resource utilization by favoring placement of 
>>large LSPs first:
>>preemption is to give higher preemption to large LSPs in order to get 
>>better global utilisation. You get a much better network utilisation by 
>>fitting big things first and then small ones (just like filling up the 
>>boot of the family car when going away on holidays, really).
>>
>>
>>Hope that helps.
>>
>>Francois
>>
>>> >
>>> >       Thanks,
>>> >       sanjay
>>> >
>>> >
>>

---

From: [email-masked]
Date: Wed, 14 Nov 2001 14:44:47 -0000

Hi Francois, you wrote 14 November 2001 09:38:

NH=> 2nd, largest BW packing of 'path entities' is the most efficient way to
do things if all path entities have the same survivability attribute.  I can
imagine a case of large(r) L-LSP carrying BE traffic and a small(er) E-LSP
carrying VPN traffic.......if I have an availability SLA to meet for the VPN
LSP, then irrespective of the size of the BE LSP I ought to restore the VPN
traffic before I even consider the BE traffic.

FLF=> Perhaps, we could add a 3rd example based on your above scenario with
something like this.

"Yet another Service Provider may elect to configure the following in order
to (i) ensure that Premium Data LSPs are never driven away from their
shortest path because of Best-Effort LSPs while (ii) optimize global network
resource utilization by favoring placement of large LSPs first:
-       all large size Premium Data LSPs to preemption priority 0
-       all small size Premium Data LSPs to preemption priority 1
-       all large size Best-Effort LSPs to preemption priority 2
-       all small size Best-Effort LSPs to preemption priority 3"

NH=> Sort-of, but not quite.......the key point was actually the 1st item
that you snipped.  So I have re-inserted it here:
"1st, there is no relationship between a packets up-state forwarding (QoS)
requirements and its 'importance' (vis-a-vis its need to survive over some
other packet, in either the same or different DS class)....DS classes simply
do not give this information.  For example, using LDP and like-DS-class
merging across  VPN populations allows no control over per VPN topology
survivability.  This is a problem IMO."

If you look at what I have written here there is no attempt made to
associate Voice, Data or BE classifications with a survivability metric (for
the reasons I alluded to above).  Further, voice in VPN_X may be mission
critical and in another VPN_Y it may not.  Likewise, or vice-versa, some
data applications.  If I were a VPN customer I would not be happy to learn
that the probability of my traffic surviving a failure was an
indeterministic function of all other VPN/other traffic of class_Z active at
the time, and in the region of, a failure.  I would simply want my VPN
traffic in total to survive (irrespective of its DS classifications)
according to some contract I had with the SP.

Now whilst this does not immediately address what you were discussing, it is
an important factor when LDP and VPNs are considered....since unless you
have the ability to manipulate the 'survivability attribute' of an LSP
entity irrespective of some arbitrary 'voice/data/BE' badge you can't really
start to address the problem (note that I am talking about VPNs here, not
some public service offerings which can be aggregated).

So, with LDP and like-DS-class merging across VPNs we have an intractable
problem IMO.  If however one used E-LSPs and associated an 'effective BW'
and 'survivability' attribute with that LSP now you can start to address the
issue meaningfully, ie the object that is being prioritised for restoration
is the LSP, not the pkts therein which as I noted you can't rank in
survivability needs anyway.

regards, Neil