Subject: RE: IETF54- Informal discussion on BC Model for DS-TE

From: Francois Le Faucheur <[email-masked]>
Date: Sun, 14 Jul 2002 23:23:36 +0200

Dimitry,

Thanks very much for your input. It's a good way to kick start the 
discussion on BC models. My thoughts below:

At 13:38 12/07/2002 -0400, Dimitry Haskin wrote:
>Francois,
>
>Consider this posting as my input into the informal discussion that I will
>no be able to attend.
>
>The Russian Doll BC model is a  fine model in its own rights. However it may
>not be suitable as the default BC model that is mandated for diff-serv
>capable MPLS devices.  My concern is that, due the nested nature of its
>bandwidth constraints, the RD model does not make much sense if preemption
>of established LSPs is not used as a part of a given diff-serv deployment.

I don't follow you. Russian Dolls model does not "mandate" the use of 
preemption. It just uses it for what it has been specified for (ie bounce 
off LSPs when needed).

My impression is that it is just not possible to simultanesouly :
         -(i) ensure bandwidth sharing (ie no bandwidth wastage)
         -(ii) ensure bandwidth isolation (ie a CT cannot have some of its 
bandwidth taken by another CT)
         -(iii) refuse to use preemption

I believe SPs have requirements for (i) and (ii) and don't have a problem 
with using preemption, which is an existing TE mechanism.
I believe the Russian Doll model is a very good way to achieve (i) and 
(ii).  Yes it involves preemption to do so, but that is exactly why 
preemption was specified for (ie let some LSPs which arrive later bounce 
earlier LSPs).
More generally, as discussed in draft-lefaucheur-tewg-russian-dolls-00.txt, 
the Russian Dolls model appears as a very efficient way to address the most 
important SP requirements (using preemption where necessary).

I don't think it would make any sense to sacrifice (i) or (ii) just for the 
sake of not using preemption. Do you?

Cheers

Francois

>The question really boils down to whether support of preemption is to be
>required (at least in the IETF framework) from the diff-serv capable MPLS
>devices. So far support of preemption was optional. Moreover, IMHO,
>diff-serv can be deployed in quite satisfactory way without use of
>preemption. Furthermore, preemption of established LSPs may not be even
>desirable in some deployments.
>
>Given that the RD BC model implicitly requires use of preemption for it to
>work, the posted question should be explicitly addressed one way or another
>before the RD model can be selected as the model that every diff-serv
>capable LR must implement.
>
>Thanks,
>   Dimitry
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:[email-masked]]
> > Sent: Friday, July 12, 2002 5:59 PM
> > To: [email-masked]
> > Subject: IETF54- Informal discussion on BC Model for DS-TE
> >
> >
> > Hello,
> >
> > TEWG will not meet in Yokohama/IETF54.
> >
> > I'd like to invite the people who will be in Yokohama and
> > have thoughts on
> > default Bandwidth Constraints model for DS-TE, to get
> > together for a very
> > informal discussion on that topic.
> >
> > Let's meet in the lobby of the main hotel at 17:30pm on Monday.
> >
> > See you there
> >
> > Francois
> >
> >

---

From: "Dimitry Haskin" <[email-masked]>
Date: Sun, 14 Jul 2002 15:59:10 -0400

Francois,

> >The Russian Doll BC model is a  fine model in its own rights. However
it
> may

I think you would agree that the bouncing off LSPs is necessary for the
RD model to work. For simplicity consider two CTs, CT1 and CT0, and two
BCs, BC1 and BC0 where BC1 < BC0. According to the model, the sum of
normalized CT1 and CT0 reservations cannot exceed BC0 and at the same
time CT0 can be booked up to BC0. So when accepting a new CT1 call would
cause the combined CT1 and CT0 reservation to exceed BC0, the only way
to comply with the model is to preempt some of the CT0 LSPs.

>          -(iii) refuse to use preemption

I respectfully disagree. I believe that (i) and (ii) can be achieved
simultaneously with (iii). Preemption of LSPs at a lower service level
in order to allow LSP calls at a higher service level is not the only
way to achieve (i) and (ii). An alternative would be to allow a
potential service degradation of the already established LSPs at a lower
service level without totally removing (often in an arbitrary way) any
particular LSP from the service. Given my example, the sum of normalized
CT1 and CT0 reservations would be allowed to exceed BC0. One may even
argue that in the face of bursty traffic this might be a good way to
achieve higher link utilization when hard service guaranties at a lower
service level are not required.

> important SP requirements (using preemption where necessary).

Except that the RD model also may impose use of the preemption when it
is not necessary or even desirable. Would you agree?

Regards,
 Dimitry

> 
> I don't think it would make any sense to sacrifice (i) or (ii) just
for
> the
> >Given that the RD BC model implicitly requires use of preemption for
it
> to

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 15 Jul 2002 03:37:24 +0200

Dimitry,

>CT1 and CT0 reservations would be allowed to exceed BC0.

Let's see if I understand exactly what you are proposing. If I understand 
correctly, you're arguing in favor of the Max Allocation model where you 
would configure the sum of the constraints much larger than the total capacity.
For example, on a link of 100, you would configure something like:
         - Sum (CT0) <= BC0 = 100
         - Sum (CT1) <= BC1 = 50
And then you are saying:
         - you can always make full use of the link (ie even if there is no 
CT1 you can setup 100 of CT0)
         - you can always achieve 50 worth of CT1 without preemption (even 
if you have a 100 of CT0, you will accept 50 of CT1 and then CT0 will just 
get degraded).

Is this right? or are you proposing another BC model and if so can you 
detail it for us?

Thanks

Francois

---

From: Nabil Seddigh <[email-masked]>
Date: Mon, 15 Jul 2002 12:49:59 -0400

Francois,

> sake of not using preemption. Do you?

I agree with what Dimitry wrote and remains along the
line of what I posted about a month ago:

http://psg.com/lists/te-wg/te-wg.2002/msg00099.html

I think the primary tradeoff between the RD and MA models is in
(i) and (iii). (ii) is supported by both RD and MA.

The MA model is actually easier to conceptualize and understand
in relation to network operations - albeit somewhat wasteful
as it does not allow bandwidth sharing across classes. 
As such it would appear to be a better choice if a default model
is chosen. I would think the simplicity of operation would be 
a key criteria for a default model.

Operators who wish to deploy the RD model can of course do so
via configuring something other than the default model.

Nabil

Nabil