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

From: "Sudhakar Ganti" <[email-masked]>
Date: Wed, 5 Jun 2002 14:31:00 -0400

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. 

-Sudhakar

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

---

From: Indra Widjaja <[email-masked]>
Date: Wed, 05 Jun 2002 17:32:42 -0500

> model (whatever that is) must be supported by any DS-TE

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

---

From: Indra Widjaja <[email-masked]>
Date: Thu, 06 Jun 2002 14:54:12 -0500

Francois:

Francois Le Faucheur wrote:
> 
> 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.

Just for a clarification, are you saying that a "uniform BC model" 
(i.e., all LSRs use the same BC) is not required in a given network?
or are you saying that a different BC model may be used in a given
network as long as the BC is the same for all LSRs?

indra

> 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,
> > >
> _________________________________________________________
> 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: Thu, 06 Jun 2002 18:59:29 +0200

Indra, Ganti,

Cheers

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 10 Jun 2002 14:54:15 +0200

Indra,

>network as long as the BC is the same for all LSRs?

I'm saying:
         - I expect SPs will want to run a single BC model throughout their 
DS-TE domain
         - thus, I feel we ought to ensure that all implementations have 
one BC model in common
         - while I don't expect it will be commonly used in practise, I 
don't see a need to exclude running multiple BC models in a given network. 
In such situations, it must be understood that overall behaviour may be 
hard to predict and some features will simply not be possible at all (e.g. 
optimisation by head-end in the case of multiple LSP path computation). I 
don't think we should go out of our way to change the spec to allow this, 
but conversely I don't see a need to exclude it.

Francois

> > because you have to confiure different DS-TE parameters on differnet LSRs

---

From: Indra Widjaja <[email-masked]>
Date: Mon, 10 Jun 2002 13:49:08 -0500

> don't see a need to exclude running multiple BC models in a given network.

Thanks; you clarified my original question posted a couple of iterations
ago.

indra

> but conversely I don't see a need to exclude it.

<rest deleted>

---

From: Indra Widjaja <[email-masked]>
Date: Mon, 10 Jun 2002 13:49:08 -0500

indra

<rest deleted>