Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Tue, 4 Jun 2002 07:39:18 -0400

Rüdiger,
  I think you have raised an interesting and valid point.
I have not analyzed this aspect in my study.
As you can see in my last posting a few minutes ago,
signaling requirement should be one of the selection
criteria to be included in the requirements doc
to provide guidance to the protocol doc for default
decision.
Thanks, Wai Sum.

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: Monday, June 03, 2002 4:33 AM
To: [email-masked]; Lai, Wai S (Waisum), ALASO
Cc: [email-masked]
Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

Waisum, Jim

> Anyone else have any comment?

I've expected an analysis of both mechanisms to show
the results forwarded by Waisum. What I'd also expect 
is that the signaling load required by the Russian 
Doll bandwidth constraint model is higher than the 
load resulting from a maximum allocation. This could 
also mean, that processing load may be smaller with 
maximum allocation.

Waisum, did you also analyse these aspects?

Regards, Rüdiger

Rüdiger Geib
Senior Expert
Systems Integration
T-Systems Nova GmbH
Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
Fax: +49 6151 838103
mailto:[email-masked]
http://www.t-nova.de

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 4 Jun 2002 11:44:19 -0400

Hello,

It is not clear to me what the specification of
bandwidth constraint (BC) model brings to DS-TE solution
as described in this draft. Current solution assumes
that each LSP belongs to a TE-Class and the constraint
based routing uses available bandwidth for TE-Class
that is advertised in computing a path. That is all
what is needed. BC information has local significance
in computing the TE-Class available bandwidth, but need
not be propagated to other nodes.

Depending upon the network design and traffic matrix,
different bandwidth sharing models may be deployed
in a network. Do we want to enforce the same model
on every link across the whole domain ? What if the 
models are different? Do we want to reject the path setup? 
Besides, the LSP setup is based on the advertised available 
bandwidth of TE-Class. Is it not sufficent that whatever 
is the bandwidth model, as long as one computes correct 
available bandwidth for TE-Class and advertises, we can
setup paths correctly? How would one use the knowledge
of BC model for this purpose when constraint based
routing is purely based on available bandwidth per TE-Class?

Different BC models may have different implications of
call blocking etc in various scenarios. But that should
be left to network design and we should not be specifying
what a default model should be. Is there any interoperability 
issue in the network if different models are used? Actually 
I don't even see the need to advertise this as being specified 
as optional IGP TLV in the DS-TE protocol draft.
 
Therefore, a discussion on BC models in the draft 
(e.g., various models and their performance) is fine. But
I don't see a need for "mandating" or specifying what
the default model should be and the corresponding unnecessary 
protocol extensions.

Any comments??

Regards
-Sudhakar

> From: Jim Boyle [mailto:[email-masked]]
> Sent: Sunday, May 19, 2002 10:04 PM
> To: [email-masked]
> Subject: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
> 
> 
> 
> This message begins a WG last call for the following:
> 
> 	draft-ietf-tewg-diff-te-reqts-04.txt
> 
> This WG document addresses a WG milestone.  It is proposed as an
> Informational RFC.  WG last call ends May 31, 2002.
> 
> 
> 
> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 04 Jun 2002 18:30:01 +0200

Ganti,

At 11:44 04/06/2002 -0400, Sudhakar Ganti wrote:
>issue in the network if different models are used?

If one LSR believes that BC0 is a contraint for CT0 while another LSR 
believes BC0 is a constraint for CT0+CT1, it will be very hard for a 
network operator to achieve anything useful/predicatble.

Right now we are not sure if one or multiple BC models will be useful. But 
it seems clear that to achieve deployable interoperable DS-TE, all LSRs 
must have at least one BC model in common. This is the one we refer to as 
the default model. Then all implementations will be free to support many 
other models, but at least all DS-TE implementation will support the 
default BC model so they can work together.

Does it clarify?

Cheers

Francois

>Actually

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 4 Jun 2002 16:00:09 -0400

Francois,

For the DS-TE, if the LSPs are setup based directly
on bandwidths BC0 to 7, then I understand about
the problems one may face. In this case, we don't know 
how much bandwidth is available for each class as we 
don't know the BC model. But we are using TE-Class 
bandwidths which would be derived from BCs and advertised. 
So irrespective of the BC model, if TE-Class available 
bandwidth is computed correctly, I do not see the need to
advertise what BC model each LSR uses. 

Can you also explain how an LER setting up the paths
may use the knowledge of BC model? Besides, if an LSR
supports multiple BC models, how is the predictability/ 
usefulness solved for the network operator unless we
enforce the same model across the domain? 

On the otherhand, enforcing the same BC model in a domain
may be very limiting to network operators. For example,
one may want to use bandwidth partitioning on some heavily
used links (to reduce call blocking for certain traffic 
aggregates for example) while use bandwidth sharing on 
less utilized routes. But by enforcing the same model, 
we are taking away this flexibility. Are network operators 
OK with this?

Regards
-Sudhakar

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Tuesday, June 04, 2002 12:30 PM
> To: Sudhakar Ganti
> Cc: [email-masked]
> >Depending upon the network design and traffic matrix, different
> >bandwidth sharing models may be deployed in a network. Do we want to 
> >enforce the same model on every link across the whole domain
> ? What if
> >the models are different? Do we want to reject the path setup? 
> >Besides, the LSP setup is based on the advertised available bandwidth

> >of TE-Class. Is it not sufficent that whatever is the bandwidth 
> >model, as long as one computes correct available bandwidth for 
> >TE-Class and advertises, we can setup paths correctly? How would one 
> >use the knowledge of BC model for this purpose when constraint based 
> >be left to network design and we should not be specifying what a 
> >default model should be. Is there any
> interoperability issue in
> >the network if different models are used?
> 
> Right now we are not sure if one or multiple BC models will be useful.
> But it seems clear that to achieve deployable interoperable
> DS-TE, all LSRs 
> >I don't even see the need to advertise this as being specified as
> >optional IGP TLV in the DS-TE protocol draft.
> >
> >the default model should be and the corresponding
> unnecessary protocol
> >extensions.
> >
> >Any comments??
> >
> >Regards
> >-Sudhakar
> >

---

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Wed, 5 Jun 2002 08:21:03 -0400

Nabil,
  Thanks for your input.  The intent of my draft is exactly like
what you described below: to understand the trade-offs of the two
models currently described in the requirements doc, and also what
works, what breaks under different scenarios.
Thanks, Wai Sum.

-----Original Message-----
From: Nabil Seddigh [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 3:46 PM
To: Geib, Ruediger
Cc: [email-masked]; Lai, Wai S (Waisum), ALASO; [email-masked]
Subject: Re: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

Waisum

It would be nice if your draft could also explore the different
implications of the two models.

The Russian Doll model forces a network to utilize
different pre-emption levels for different classes of traffic
whereas the Maximum Allocation model does not. On the other hand,
the Russian Doll model allows borrowing between classes while
the Max Alloc model doesn't support this. The network operators
will need to analyze the tradeoffs in supporting one model
vs another.

I am concerned about this WG mandating one default model versus
another - won't it depend on the network circumstances?

Best,
Nabil Seddigh

---

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Wed, 5 Jun 2002 11:38:06 -0400

Fine.
Wai Sum.

-----Original Message-----
From: Jim Boyle [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 9:44 AM
To: Lai, Wai S (Waisum), ALASO
Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

Well, it's seems long-winded, but I suppose I can go along with that.

Let's remove the reference, and add:

(5) maximizes efficient use of the network.

Is the WG ok with that?  Waisum - would that be a workable compromise?

Jim

On Wed, 5 Jun 2002, Lai, Wai S (Waisum), ALASO wrote:

> Jim,
>    Per your request, here is the proposed text to replace the last
> but one paragraph of Section 3.3.  Comments are welcome.
> Thanks, Wai Sum.
>
> At the time of writing this document, it is not clear whether a
> single model of Bandwidth Constraints is sufficient, which one it
> should be and how flexible this model really needs to be and what
> are the implications on the DS-TE technical solution and its
> implementations.  Work is currently in progress [Reference] to
> investigate the performance and trade-offs of the different
> operational aspects of Bandwidth Constraints.  For example,
> preliminary results indicate that the use of a higher degree of
> bandwidth sharing among different services can lead to a tighter
> coupling among them, which can result in the impact of one service
> on another.  Another preliminary observation is that there is the
> need to balance overall efficiency and the avoidance of starvation
> of any one service.  These factors should be considered in the
> deployment of any bandwidth constraint model.
>
> The DS-TE technical solution must specify one
> default bandwidth constraint model which must be supported by any
> DS-TE implementation.  Having a default bandwidth constraint model
> allows for the network administrator to have at least one
> consistent behavior when working with multiple implementations of
> DS-TE.  Additional bandwidth constraint models may also be specified.
> In the selection of a default model, at least the following criteria
> must be considered:
> (1) addresses the scenarios in Section 2
> (2) works well under both normal and overload conditions
> (3) applies equally when preemption is either enabled or disabled
> (4) minimizes signaling load processing requirements
>
> [Reference] W.S. Lai, "Performance evaluation of bandwidth allocation
>   models for Diffserv-aware MPLS traffic engineering," Internet-Draft,
>   June 2002.
>
> Sent: Tuesday, June 04, 2002 3:00 PM
> To: Lai, Wai S (Waisum), ALASO
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
> You're text does not make it "clear" to me.
>
> Can you propose some text which captures what you see as objective
> criteria?
>
> My pass would be to add a sentence at the end of the paragraph such
as:
>
> "The default bandwidth model should be one that can address the
> scenarios
> in section 2 in a manner which balances bandwidth efficiency as well
as
> signaling overhead."
>
> I'm not sure if that will allow us to converge on a model, but at
least
> it
> specifies some objective criteria to judge different models by.  Plus,
> with just one sentence and no value statements on models as you had
> previously suggested, I think we can add it in and progress the draft.
>
> Does this sound ok?
>
> Jim
>
> On Tue, 4 Jun 2002, Lai, Wai S (Waisum), ALASO wrote:
>
> > Jim,
> >   I think our proposal to add some text in the requirements doc for
> > BC model is in the same spirit as in Section 4 "Solution Evaluation
> > Criteria" of this document for solutions supporting DS-TE.
> >
> >   Let me quote again the paragraph in question:
> >     "At the time of writing this document, it is not clear whether a
> >     single model of Bandwidth Constraints is sufficient, which one
it
> >     should be and how flexible this model really needs to be and
what
> >     are the implications on the DS-TE technical solution and its
> >     implementations. The DS-TE technical solution must specify one
> >     default bandwidth constraint model which must be supported by
any
> >     DS-TE implementation."
> >
> >   Regarding the first sentence, we have now some new information on
> the
> > implications of the BC models, which is contrary to what is stated
as
> > "it is not clear".
> >
> >   More importantly, the second sentence in above text only says that
> > one default needs to be specified *without going into the specific
> > selection criteria*.  We believe that some criteria to be considered
> > include at least:
> > (1) performance under normal conditions versus service protection
> >     and isolation capability under overload (as stated in my
previous
> >     email)
> > (2) signaling load processing requirements (as stated in the email
by
> >     Rudiger Geib)
> >
> >   As I explicitly stated in my previous email, we fully agree that
the
> > requirements doc is not the place to resolve what the default model
> > should be.  Thus, we have no objection to continuing this discussion
> > in the context of draft-ietf-tewg-diff-te-proto-00.txt, but see a
> > need/value in identifying criteria and referencing relevant studies
> > in the requirements document.
> >
> > Thanks, Wai Sum.
> >
> > Sent: Monday, June 03, 2002 10:15 AM
> > To: Ash, Gerald R (Jerry), ALASO
> > Cc: Lai, Wai S (Waisum), ALASO; [email-masked]
> > Jerry - it is already specified in the requirements document that
the
> > bandwidth constraint model must be specified in the technical
solution
> > document:
> >
> > 	"The DS-TE technical solution must specify one
> >    default bandwidth constraint model which must be supported by any
> >    DS-TE implementation"
> >
> > How = IETF process, Where = TEWG.  Do we really need to state that?
> >
> > As for making comparisons between models in the draft, I don't think
> > it's
> > called for.  I think making references to documents which describe
> them
> > is
> > also something that isn't necessary in the requirements document.
As
> > for
> > adding some text as to the decision must be made on "hard
information"
> -
> > I
> > see that as a no-value addition to the document.
> >
> > What objection do you and Wai have to having this discussion in the
> > context of draft-ietf-tewg-diff-te-proto-00.txt ?
> >
> > Jim
> >
> > On Mon, 3 Jun 2002, Ash, Gerald R (Jerry), ALASO wrote:
> >
> > > > The discussion on what should be the default bandwidth
constraint
> > > > model should be done in the context of the solution draft.
> > >
> > > This should be stated as a requirement in Section 3.3 of the
> > requirements draft.
> > >
> > > > The paragraph you quote makes it clear that the requirements
draft
> > leaves that
> > > > discussion squarely with the technical solution.
> > >
> > > Nowhere in Section 3.3 of the requirements draft is it stated how
or
> > where the technical solution will be decided.  It should be stated
as
> a
> > requirement in Section 3.3 that "the default BC model will be
decided
> in
> > the context of the technical solution draft."
> > >
> > > > I don't see a need for any text revision of the requirements
draft
> > before
> > > > sending it on to the IESG.
> > > Yes.  An additional requirement should be added in Section 3.3:
> > > "the default BC model must be based on available hard information,
> > such as analysis given in [forthcoming lai-id] [other relevant
> > references]."
> > >
> > > Also, Wai Sum's suggested short explanation of the essence of his
> > analysis is highly relevant to Section 3.3, and shouldn't be
rejected
> > out of hand.
> > > Jerry

---

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Wed, 5 Jun 2002 17:14:35 -0400

Francois,
  Your first two comments are fine.  Regarding your comments on
(2) works well under both normal and overload conditions,
I do NOT mean "when there is contention across CTs" in the way
you described.

By "normal condition," I mean the network is carrying traffic
at a level that it is designed to support.
There will always be contention even under normal conditions,
because of the stochastic nature of traffic flows, i.e., the
fluctuating activities of establishment and teardown of LSPs
(otherwise, why do we need to define preemption priority in
the first place).
Perhaps adding some text as follows may be suseful.
Thaks, Wai Sum.

"Normal condition" means the network is carrying traffic
at a level that it is designed to support.
"Overload condition" means that the network is carrying traffic
higher than its normal level.
"Works well" means that under these conditions, the
network should be able to sustain the expected performance,
e.g., under overload it is x times worse than its normal
performance.

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Wednesday, June 05, 2002 11:39 AM
To: Jim Boyle
Cc: Lai, Wai S (Waisum), ALASO; Ash, Gerald R (Jerry), ALASO;
[email-masked]

Jim, Waisum,

At 09:44 05/06/2002 -0400, Jim Boyle wrote:

>Is the WG ok with that?

I am OK with Jim's proposal. A few small comments/suggestions embedded 
below inside Waisum's initial proposal.

Francois

>   Waisum - would that be a workable compromise?
>
>Jim
>
> > operational aspects of Bandwidth Constraints

Should we not replace "Bandwidth Constraints" by "Bandwidth Constraints 
models"?

>.  For example,
> > on another.

Should we not replace "services" by "Class-Types" in the two occurances
above?

>Another preliminary observation is that there is the

I am not comfortable with that statement:
         - not sure what "works well" means.
         - not sure what is "overload conditions" in this context. I
guess 
this means "when there is contention across CTs, right?

If I understand correctly, perhaps we could rephrase into something
like:
"(2) addresses both the cases where CTs are contending against one
another 
for bandwidth reservation and the cases where CTs are not contending 
against one another".

If you mean something differnet, could you clarify?

as
least
it
what
any
as
previous
by
the
the
solution
any
As
information"
constraint
draft
> > > > Nowhere in Section 3.3 of the requirements draft is it stated
how or
as
decided
draft
rejected

---

From: [email-masked]
Date: Thu, 6 Jun 2002 09:30:00 +0100

Francois....I can see your point, but against which types of service are
your comments directed....public or private?  I strongly believe you cannot
use the same model for VPNs as you do for public (Internet) services.  I
have posted many times why like-DS-class merging across all traffic types is
a broken idea for VPNs (albeit in the case of LDP/mp2p case, but the same
traffic-type separation issue holds here too).

regards, Neil

> Sent: 04 June 2002 17:30
> Cc: te-wg

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Thu, 6 Jun 2002 08:04:12 -0400

Francois, all,

> At 12:30 04/06/2002 -0400, Francois Le Faucheur wrote:

> If one LSR believes that BC0 is a constraint for CT0 while another LSR 
> network operator to achieve anything useful/predictable.

I agree with Francois.  Useful/predictable (i.e., 'consistent') behavior in a domain would only be achieved by a uniform BC model used in the domain.

To Jim's question on last call, I believe we should incorporate the changes proposed by Wai Sum and send that updated version to the IESG.

Jerry

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Thu, 6 Jun 2002 16:30:29 -0400

Sudhakar,

> 1) How would an LER use the knowledge of BC model in
>    the path setup/compassion?

As one example (there are lots I believe), the LER might use the BC model in conjunction with the LSDB/TED to do constraint based routing of an LSP.

> 2) What do you do if models are different?

If each LSR (or link) used a different BC model I suppose the LER could take that into account in doing its constraint based routing, as in the example above.  However, I don't know how this would be beneficial.

> 3) Can I use different BC models on each link if
>    I choose to rather than one model for the whole LSR?

It seems that you could, see the earlier posting today from Francois.  But I don't know why this would be beneficial.

>    If so "consistency" broken?

Yes, I think so.

> 4) What is the impact of different models in a network?

I suppose it depends on how different the models are.  
For example, if each link in a network has 100 units of bandwidth, and:
- half the links have 1 unit of bandwidth allocated to CT1, 99 units to CT2;
- other half of the links have 99 units of bandwidth allocated to CT1, 1 unit to CT2;
That's pretty incoherent.  
Perhaps you can create an example to show how it is beneficial to use different BC models on the links.

> I have more severe problem with consistency regarding 
> the TE-Class than the BC model. What if each node is 
> configured differently such that one LSR understands 
> a TE-Class differently from another LSR? The whole 
> solution may not work correctly!!

I tend to agree with you here, that's why we wrote an I-D (now expired) proposing standardized CTs (see the presentation at IETF-51 http://ietf.org/proceedings/01dec/slides/tewg-5/index.html).  However, that's an issue separate from the DSTE requirements draft.

Jerry

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Thu, 6 Jun 2002 13:53:44 -0400

Jerry,

Basically I would like to know the following:
1) How would an LER use the knowledge of BC model in
   the path setup/compuation?
2) What do you do if models are different?
3) Can I use different BC models on each link if
   I choose to rather than one model for the whole LSR?
   If so "consistency" broken?
4) What is the impact of different models in a network?
4) If we don't have reasonable answers for the above,
   I do not see a need to mandate that for "consistency"
   a uniform BC model is a must.

-Sudhakar

> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 8:04 AM
> To: Francois Le Faucheur
> I agree with Francois.  Useful/predictable (i.e.,
> 'consistent') behavior in a domain would only be achieved by a uniform

> BC model used in the domain.
> 
> To Jim's question on last call, I believe we should incorporate the
> changes proposed by Wai Sum and send that updated version to the IESG.
> 
> Jerry
> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 06 Jun 2002 19:28:01 +0200

Waisum,

>e.g., under overload it is x times worse than its normal

I think I understand what you mean now.

It is not completetly clear to me how that would translate into an 
evaluation criteria for BC models, but I think the general idea is 
reasonable so I have no objection to adding something along those lines.

Additional suggestions on wording:
1)How about :
"Normal condition" means that the network is attempting to establish a 
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a 
volume of DS-TE LSPs beyond the the one it is designed for.
(to me "carrying traffic" can be easily misunderstood as relating to the 
actual amount of packets transmitted , when here we are more focusing on 
the amount of tunnels versus what can be setup)

2)"Works well":
Personnaly I think the above definition for "works well" is trying to be 
too precise this time (it begs questions as to what sort of "performance" , 
can the BC Model itself control that ..). I would suggest again replacing 
"works well" by something like "maintain efficient use of the network both 
under normal condition and Overload condition".
("efficient use of the network " is something we use as an other evaluation 
criteria. Here we just want to make the point that this applies both under 
normal AND overload conditions.)

So, altogether, it would read:

"
(2) maintain efficient use of the network both under Normal Condition and 
Overload Condition".
"Normal condition" means that the network is attempting to establish a 
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a 
volume of DS-TE LSPs beyond the one it is designed for.
"

What do you think?

Francois

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Fri, 7 Jun 2002 11:00:07 -0400

Jerry,

Answers in line ..

-Sudhakar

> As one example (there are lots I believe), the LER might use the BC 
> model in conjunction with the LSDB/TED to do constraint based routing 
> of an LSP.

The LSDB/TED has available bandwidth information for a TE Class. 
Let us say that there is enough bandwidth available for the TE-Class 
and the LSP maps to that TE-Class. But the links use different 
BC model. Do you reject the LSP setup because the models 
are different, though bandwidth is available?

> - other half of the links have 99 units of bandwidth
> allocated to CT1, 1 unit to CT2; That's pretty incoherent.  
> Perhaps you can create an example to show how it is 
> beneficial to use different BC models on the links.
> 

In this example say BC0 = CT1 and BC1 = CT2. Then this
example assigns different values for the same BC, that
is a local policy and cannot be checked by the DS-TE
solution. My example is on first link BC0 = 20; BC1 = 
80 (complete partitioning of link bandwidth among two 
traffc types, i.e, BC0 is for CT1 and BC1 is for CT2). 
Second link has BC0=20; BC1=100 (sharing, i.e, BC0 = CT1 and 
BC1 = CT1+CT2). It works perfectly fine as long the TE-Class 
available bandwidth is computed correctly.

-Sudhakar

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Fri, 7 Jun 2002 11:52:05 -0400

Francois,

If I understand correctly, a default BC model is
enforced so that a service provider atleast
can choose the default model as a "common" model across 
different vendor boxes. Is that correct?

If so, there should be a finite set of models that must 
be common across different boxes rather than mandating 
one. What if the service provider does not believe in 
the default model and other models are not implemented? 
Therefore, the specification need to suport two or three 
common BC models such as Max Allocation (complete 
partitioning) and Russian Doll model (partial sharing) 
and any other in the "common" set. The text in the draft 
should also clearly say the purpose of these default BC 
models.

On the other hand, a default model is mandated because 
the DS-TE solution does not work without a uniform BC model 
across the whole domain, that may take flexibility away. 
Irrespective of the BC model mix in the network, the 
DS-TE solution must work.

-Sudhakar

> Sent: Thursday, June 06, 2002 12:59 PM
> To: Indra Widjaja
> Cc: Sudhakar Ganti; Jim Boyle; [email-masked]
> Indra, Ganti,
> I don't believe the current text nor the new proposed text actually 
> exclude the possibility of running different BC models in a given 
> network, if a particulat Service Provider wanted to do that for some 
> reason. What we are on about, is to avoid SPs being forced to deal 
> with multiple BCs, when most (if not all) of them probably don't want 
> that.
> 
> Assumption 1: We do not mandate a default model.
> Then, Vendor A comes out with a superb DS-TE implementation supporting
> Russian Doll model, Vendor B with a wonderful implementation 
> supporting Separate Constraint model and Vendor C with a magnificent 
> implementation supporting this Super Sophisticated BC model for which 
> his developper just did a PhD on. Practically speaking, Mr Network 
> Administrator would only have two real
> options:
>          - pick only one of these vendors and deploy DS-TE
>          - deploy multiple vendors' equipment but forget about DS-TE 
> because you have to configure different DS-TE parameters on differnet 
> LSRs and have differnet BC capabilities on different LSRs (ie this
> one can limit 
> this but not that).
> That doesn't seem like the best avenue to promote practical DS-TE 
> interoperability.
> 
> Assumption 2: We do mandate a default BC model.
> Then, Vendor A comes out with a superb DS-TE implementation supporting
> Default model, Vendor B with a wonderful implementation supporting 
> Default Model and Vendor C with a magnificent implementation 
> supporting Default Model AND this super sophisticated BC model for 
> which his developper just did a PhD on. Practically speaking, Mr 
> Network Administrator would have many options:
>          - deploy one or multiple vendors' equipment and deploy DS-TE 
> with Default BC model (with same DS-TE parameters on all LSRs and same

> BC capabilities on all LSRs ( and live happily forever)
>          - try vendor C's super sophisticated model in a lab.
>          - if the SP likes interesting stuff, deploy multiple 
> vendors' 
> equipment and deploy DS-TE with Default BC model on Vendor A 
> and vendor B 
> LSRs and start playing with super sophisticated BC model on 
> vendor C LSRs 
> and see what happens.
>          - put pressure on vendor A and B to implement super 
> sophisticated 
> model because it is proven to work well , and then deploy 
> multiple vendors 
> equipment all with super sophisticated BC model.
>          - pick only vendor C and deploy super sophisticated BC model 
> everywhere
> Does this not seem more like promoting interoperable DS-TE deployment?
> 
> Cheers
> 
> Francois
> 
> 
> At 17:32 05/06/2002 -0500, Indra Widjaja wrote:
> >Sudhakar Ganti wrote:
> > >
> > > Jim,
> > >
> > > Unless the document defines what exactly is a "consistent
> behavior"
> > > across multiple implementations and discusses what are the 
> > > implications of not having a default model, the requirements 
> > > document should not mandate that a default model
> (whatever that is)
> > > must be supported by any DS-TE implementation.
> >
> >I'd like to echo Sudhakar's concern in that the whole picture of BC 
> >models seems not fully understood yet. Wouldn't it be
> possible to have
> >multiple BC models in a domain and let an LSR optimize its
> individual
> >LSP depending on whether bandwidth sharing or isolation is more 
> >important? Would this so-called "inconsistency" have adverse
> effect on
> >the network efficiency or some other factors?
> >
> >indra
> >
> > >
> > > -Sudhakar
> > >
> > > > > any DS-TE implementation.  Having a default bandwidth
> constraint
> > > > > model allows for the network administrator to have at
> least one
> > > > consistent
> > > > > behavior when working with multiple implementations of DS-TE. 
> > > > > Additional bandwidth constraint models may also be
> > > > specified. In the
> > > > > selection of a default model, at least the following
> > > > criteria must be
> > > > > considered:
> _________________________________________________________
> Francois Le Faucheur
> Development Engineer, IOS Layer 3 Services
> Cisco Systems
> Office Phone:          +33 4 97 23 26 19
> Mobile :               +33 6 19 98 50 90
> 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: Mon, 10 Jun 2002 15:45:56 +0200

Sudhakar,

>different vendor boxes. Is that correct?

yes.

>and any other in the "common" set.

I am not opposed to specifying more than one model. But my recommendation 
is for:
         - mandating one
         - optionally allowing others
I feel we could close on one default model faster than if we try to close 
on all/multiple models.
Also, some BC models may require additional extensions, so this could delay 
specification of the base protocol extensions.

As usual, I would prefer to specify something relatively simple first so we 
get more implementations/experience before trying specifying an all 
emcompassing solution.

>The text in the draft

There is some reasonable text that explains why one default model should be 
used. If you feel you can suggest specific  text which would be clearer, 
please do so.

>DS-TE solution must work.

Do we know Service Providers who have a requirement for supporting multiple 
BC models in a given network?
Personnaly, I haven't heard any yet. (Frankly I think DS-TE is 
sophisticated enough with a single BC model at any one time, I don't see 
the point for such complexity)
So as per my earlier email:
         - let's make sure we make it work with one single BC model
         - let's allow BC model mix *IFF* it doesn't cost us anything in 
terms of complexity, but let's not make the spec more complicated for 
something which is not required -at least now-.

Cheers

Francois

---

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Mon, 10 Jun 2002 11:18:48 -0400

Francois,
  Sorry for my delayed response, as I just got back from vacation.
  Thanks for rewording "normal" and "overload" to reflect LSP
setup.  It's a good suggestion.  I think changing "works well"
as I defined below to mean only "efficient use" would leave out
significant aspects of overall network operation.  This same
comment applies also to Jim's suggestion of
"(5) maximizes efficient use of the network."

  For example, the impact of one service on another would not
be adequately covered.  I prefer my original wording, as I
think it implies efficiency under this and other conditions.
The effect of coupling in BC and their interlocking impact on
the network's capability to set up LSPs for different services
will be expounded in my draft.
Thanks, Wai Sum.

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Thursday, June 06, 2002 1:28 PM
To: Lai, Wai S (Waisum), ALASO
Cc: Francois Le Faucheur; Jim Boyle; Ash, Gerald R (Jerry), ALASO;
[email-masked]

Waisum,

2)"Works well":

too precise this time (it begs questions as to what sort of
"performance" , 
can the BC Model itself control that ..). I would suggest again
replacing 
"works well" by something like "maintain efficient use of the network
both 
under normal condition and Overload condition".
("efficient use of the network " is something we use as an other
evaluation 
criteria. Here we just want to make the point that this applies both
under 
normal AND overload conditions.)

"
(2) maintain efficient use of the network both under Normal Condition
and 
Overload Condition".
"Normal condition" means that the network is attempting to establish a 
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a

What do you think?

Francois

> > > >     "At the time of writing this document, it is not clear
whether

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 11 Jun 2002 17:04:49 -0400

Francois,

> 
> >The text in the draft
> >should also clearly say the purpose of these default BC models.
> 
> There is some reasonable text that explains why one default model 
> should be used. If you feel you can suggest specific  text which would

> be clearer, please do so.

I would like to see the following text:

"  The DS-TE technical solution must specify one 
   default bandwidth constraint model which must be 
   supported by any DS-TE implementation. However, 
   additional bandwidth constraint models may also be 
   specified. The purpose of such a default model is to
   ensure that there is at least one common BC model 
   implementation across various vendors equipment
   and allows for easier deployment of DS-TE.
   However, this does not preclude a network operator 
   to configure different BC models on different links 
   in a network, if the provider wishes to do so. "

-Sudhakar

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 11 Jun 2002 17:23:27 -0400

Francois,

> Do we know Service Providers who have a requirement for supporting 
> multiple BC models in a given network? Personnaly, I haven't heard any

> yet. (Frankly I think DS-TE is sophisticated enough with a single BC 
> model at any one time, I don't see the point for such complexity)

It is not a question of sophistication, but of flexibility. 
Can you explain to me the point of complexity? 
For me, as long as one computes correctly the 
unreserved bandwidth for the TE-Class and 
advertises, the solution should work. 
That should be the only "requirement". This is a 
local computation on the node considering the 
BC model used on a given link. There is no need 
to advertise the BC model to anybody. So how does
it increase complexity by allowing multiple models
in the network?

-Sudhakar

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 11 Jun 2002 17:23:27 -0400

Francois,

-Sudhakar

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 13 Jun 2002 11:39:32 +0200

Sudhakar,

>    in a network, if the provider wishes to do so. "

that works for me.
Francois

---

From: "Sudhakar Ganti" <[email-masked]>
Date: Tue, 11 Jun 2002 17:04:49 -0400

Francois,

-Sudhakar