Subject: RE: Another question related to LOM as described in DS-TE-PROTO

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Tue, 18 Jun 2002 09:29:39 -0400

Francois,
I agree with your suggestion that the LOM should be reflected in the 
Unreserved Bw values (irrespective of the actual formula used by 
individual implementation to compute the unreserved bandwidth).
 
-Another reason, we should do this is for compatibility with the
 non-DS-TE implementations (current OSPF-TE draft, indicates
 that the values in the Unreserved Bw TLV should be initialized
 to Max Reservable Bandwidth -which reflects the over 
 subscription factor).
 
Thanks,
sanjay

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 6:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Another question related to LOM as described in DS-TE-PROTO

At 12:37 05/04/2002 -0500, Choudhury, Sanjaya wrote:

Hi Francois! I have one more question related to 
usage of LOM as described in the DS-TE-PROTO.

Sanjaya and all,

I did more thinking on LOM.

My conclusion is that the LOM should be reflected in the Unreserved Bw
values advertised in IGP. The LOM should be reflected as if the BCs had been
inflated by their respective local LOM.

Back to your example:
Assume (simple admission control scheme, single preemption level):
CT              LOM    BC
-----------------------------
CT0             400%    200M
CT1             200%    100M
Initially, IGP advertises:
        Unreserved CT0xLOM(0)=800
        Unreserved CT1xLOM(1)=200
After establishment of an LSP with CT=CT1 and BW=100, IGP advertises:
        Unreserved CT0xLOM(0)=800-100=700
        Unreserved CT1xLOM(1)=200-100=100

The example formulas for computing Unreserved Bw would simply become: 

"Unreserved TE-Class [i]" = 

        MIN  [
        [ (BCc-LOM(c)) - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <=
7,
     . . .
        [ (BC0-LOM(0)) -  SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <=
7,
          ]

My rationale is that:

        - I think the LOM needs to be factored in by the local LSR on which
they are configured because only this LSR can accurately factor their impact
across the other Class-Types. This relates to the discussion we had with
Dimitry and the point that a Head-end just cannot always guess exactly the
distribution of bandwidth across the various CTs, only the local LSR can
know it. So only the local LSR can accurately factor in the LOM of each CT
and then advertises Unreserved Bw values which reflect this.

        - I think the LOM needs to be factored as an "inflation" of the
bandwidth pool (as opposed to a "deflation" of the LSP size) because we
should make this work even if the Head-end is not aware that Local
Overbooking is used somewhere remotely in the network (or even does not
support optional Local Overbooking) and thus Head-end need to always operate
on "raw/unmodified" tunnel bandwidth. 

Properties of this approach are:
        - the Local Overbooking method can be deployed without having to
advertise the optional LOMs in the IGP (as long as the local optimisation on
HE is not required). ie I just configure LOMs locally on LSRs and this only
changes existing advertisement without necessitating additional
advertisement.
        - The LOcal Overbooking methods can be used even if the head-end
does support the "LOM" option itself. Basically if an LSR support the
optional LOM on one of its link, all the Head-end will efectively benefit
from the LOM on that link, without even knowing that their is Local
Overbookinmg on that particular link.

Note that, when BC sub-TLV is used, the BCs need not be affected by LOM.
They are advertised just as configured. Only the "unreserved Bw" values are
affected by LOM. Note that this can result in "Unreserved Bw" values being
larger than the BC values when LOM is used, but I don't think this is an
issue because:
        - either Head-end does not do local optimisation and thus will
ignore the BC values (and just use the "Unreserved Bw" values) 
        - or Head-end does local optimisation and thus it needs to be
LOM-capable and it needs to receive the optionnal LOM sub-TLV. It woudl then
understand that , when LOM is used, the Unreserved Bw values are based on BC
x LOM.

Could you think through the above approach and give me feed-back?

Thanks

Francois

Assume (simple admission control scheme):
CT              LOM    BC
-----------------------------
CT1             200%   100M
CT0(CT1+CT2)    400%    200M

1) create lsp1 BW 20M ct=ct1 then
   CT1_AVAIL_BW=100-20/2=90M
   CT0_AVAIL_BW=200-20/2=190M (and *not* 200-20/4=195m) 
Am I correct?

Thanks,
sanjay

> -----Original Message-----
> From: Choudhury, Sanjaya [ mailto:[email-masked]
<mailto:[email-masked]> ]
> Sent: Thursday, March 28, 2002 1:42 PM
> To: 'Francois Le Faucheur'; [email-masked]
> Subject: question related to DS-TE-PROTO: Does advertised 
> unreserved bw
> ta ke LOM into account ?
> 
> 
> 
>  Hi! Here is a question related to DS-TE-PROTO-3 draft. 
>   
>    Is the following assumption correct ?
> 
>    The  per-TE-Class unreserved bandwidth advertised by IGPs, are
>    the actual bandwidth available for the TE-Class [i.e 
> _without_ taking
>    the LOM into account.] 
> 
>    The PCM of the a LSR may use the advertised unreserved BW and 
>    value from the LOM TLV, to decide (/predict), whether it should use
>    a specific link.
> 
>    A simplistic example: 
>       (i)   Assume the actual link bw 100M
>       (ii)   Only CT0 is supported (and only 1 preemption priority
> supported)
>      (iii)  LOM[0] = 200%
>     
>      Case-1: No LSPs have been established
> 
>                  Assumption:
>                  -------------
>             In this case the Adv bw is   100M  (and not 200M)
>                   [Although 200M worth of CT0 connections can be 
>                    established]
> 
>       Case-2: 1 LSP with 50M bandwidth has been established
>  
>                   Assumption:
>                   --------------
>                   In this case the Adv bw is  = 100 -50/2 = 
> 75M (and not 200
> -50 = 150M)
>              
> Thanks,
> sanjay                  
> 
>    
>

---

From: "Iren, Sami" <[email-masked]>
Date: Thu, 20 Jun 2002 11:05:48 -0400

Francois:
 
Now that we are taking LOM into account when calculating
unreserved bandwidth, do you think we need to do the same
when setting out the rules for the Russian Doll model?  
The current text states that:
 "All LSPs supporting Traffic Trunks from CTb (with b<=c<7) use
  no more than BCb".
 
However, this statement does not take the LOM into account. Take
a look at the following example:
 
Assume two CTs are supported (CT0, CT1) and LOMs are set as
400% and 200% for CT0 and CT1 respectively.  Also assume that
the BC0 is set to 100% of the link capacity and BC1 is set to 60%
of the link capacity. Finally, assume we have the following TE-classes
defined:
TE-Class     CT     P.Priority
      0            0         0
      1            1         0
 
On a 100 Mbps link initially we will advertise 400Mbps and 200Mbps
unreserved bandwidth (due to overbooking).  However, if we receive 
a setup request for 150Mbps for either CT0 or CT1 we have to reject 
it according to the text above (because 150Mbps > 100Mbps and 
150Mbps > 60Mbps). Obviously when we take the LOM into account
this is not an issue, but to be consistent with the rest of the text I think
Russian Doll model section of the draft can be rephrased to include
the LOM.
 
On a related issue, do we want to allow the user to use a greater LOM
for CT(i+1) than CT(i)? In the above example can the user set LOM for
CT0 to 200% and LOM for CT1 to 400%? To me this type of configuration
does not make sense but do we want to spell this out in the draft?
 
Regards,
--Sami

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 6:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Another question related to LOM as described in DS-TE-PROTO

Sanjaya and all,

Back to your example:

        MIN  [

My rationale is that:

Thanks

Francois

Thanks,
sanjay

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 24 Jun 2002 16:00:16 +0200

Sami,

At 11:05 20/06/2002 -0400, Iren, Sami wrote:
>However, this statement does not take the LOM into account.

Agreed. The above statement assumed that LOM was not used. It is not 
correct when LOM is used.

I think the correct formula would be:
SUM [ (all LSPs of CTb)/LOM(b) ] <= BCb,    with b<=c<=7

With your example below with two CTs, this translates into:
CT0/4 + CT1/2   <= 100%link
CT1/2 <= 60% link.

agreed?

I'll reflect that somehow.

More below:

>Take

I don't think we need to explicitely rule out LOM (i+1) larger than LOM (i).
However, I think we need to explicitely rule out that:
          LOM(i+1) x BC(i+1) be larger than LOM(i) x BC(i)

This is nothing more than also reflecting LOM in the existing rule (ie 
BC(i+1) <= BC(i) )

agreed?

Thanks for your thoughts.

Francois

>values advertised in IGP. The LOM should be reflected as if the BCs had 
>been inflated by their respective local LOM.
>
>Back to your example:
>         [ (BCc-LOM(c)) - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b 
> <= 7,
>      . . .
>         [ (BC0-LOM(0)) -  SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b 
> <= 7,
>           ]
>
>My rationale is that:
>
>         - I think the LOM needs to be factored in by the local LSR on 
> which they are configured because only this LSR can accurately factor 
> their impact across the other Class-Types. This relates to the discussion 
> we had with Dimitry and the point that a Head-end just cannot always 
> guess exactly the distribution of bandwidth across the various CTs, only 
> the local LSR can know it. So only the local LSR can accurately factor in 
> the LOM of each CT and then advertises Unreserved Bw values which reflect this.
>
> support optional Local Overbooking) and thus Head-end need to always 
> operate on "raw/unmodified" tunnel bandwidth.
>
> advertise the optional LOMs in the IGP (as long as the local optimisation 
> on HE is not required). ie I just configure LOMs locally on LSRs and this 
> only changes existing advertisement without necessitating additional 
> advertisement.
>They are advertised just as configured. Only the "unreserved Bw" values 
>are affected by LOM. Note that this can result in "Unreserved Bw" values 
>being larger than the BC values when LOM is used, but I don't think this 
>is an issue because:
> LOM-capable and it needs to receive the optionnal LOM sub-TLV. It woudl 
> then understand that , when LOM is used, the Unreserved Bw values are 
> based on BC x LOM.
>
>
>> > From: Choudhury, Sanjaya [mailto:[email-masked]]