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

[neil.2.harrison@bt.com]

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

> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: 04 June 2002 17:30
> To: Sudhakar Ganti
> Cc: te-wg
> Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
> 
> 
> Ganti,
> 
> At 11:44 04/06/2002 -0400, Sudhakar Ganti wrote:
> >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?
> 
> 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
> >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
> >
> > > -----Original Message-----
> > > From: Jim Boyle [mailto:jboyle@pdnets.com]
> > > Sent: Sunday, May 19, 2002 10:04 PM
> > > To: te-wg@ops.ietf.org
> > > 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.
> > >
> > >
> > >
> > >
> > >
> 
>