[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> >
> >
> >
> >
> >