The MPLS WG Archive

["Darek Skalecki" <dareks@nortelnetworks.com>]

Thanks Angela,

Are these extensions currently defined for OSPF and ISIS?. If yes then please
provide me with a reference, and if not then is anyone working on them ?. I can
only find extensions related to advertizing bandwidth availability per priority
not resource class.

Thanks,

Darek


Angela Chiu wrote:

> Darek,
>
> These are additional requirements for IGP extensions, as stated in TE
> Framework draft
> http://www.ietf.org/internet-drafts/draft-ietf-tewg-framework-01.txt
> "In order to perform constraint-based routing on a per-class basis for LSPs,
> the conventional IGPs (e.g., IS-IS and OSPF) should provide extensions to
> propagate per-class resource information."
> Then the draft states that "per-class parameters can be aggregated into
> per-class-type parameters" for scalability improvements.
>
> Regards,
>
> Angela
>
> -----Original Message-----
> From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> Sent: Tuesday, June 20, 2000 2:51 PM
> To: Francois Le Faucheur
> Cc: mpls@UU.NET; alchiu@att.com
> Subject: Re: Bandwidth reservation per PSC
>
> Thanks Francois,
>
> My question was indeed related to the distributed model. What I am still not
> sure about is how bandwidth availability within OSPF/ISIS is advertized  per
> PSC or per family  of TE related PSCs when the TE extensions only imply
> advertizement per priority. Are colors assigned to different PSCs or
> families of TE related PSCs and bandwidth availability advertized per
> color?.
>
> Thanks,
>
> Darek
>
> Francois Le Faucheur wrote:
>
> > Darek,
> >
> > At 12:24 16/06/2000 -0400, Darek Skalecki wrote:
> > >Hi,
> > >
> > >I have a question with regard to bandwidth availability per PSC and TE
> > >extensions to OSPF/ISIS.
> > >
> > >Draft "draft-ietf-mpls-diff-ext-05.txt" talks in APPENDIX B Scenario 2
> > >about constraint based routing being
> > >performed separately for each PSC  where one of the constraints is
> > >availability of bandwidth from the bandwidth
> > >allocated to the relevant PSC.
> > >
> > >My question is how TE extensions to OSPF/ISIS support advertizing
> > >bandwidth availability per PSC. The only way I can
> > >think this can be achieved is by assigning different colors/resource
> > >classes to different PSCs thus advertizing bandwidth
> > >availability per PSC simply as bandwidth availability per color/resource
> > >class. Is this correct?.
> > >
> > >If it is correct then how serious is the scaling/operational issue at
> > >least within OSPF since N  TE LSAs are needed for  N
> > >PSCs  for every link, implying lots of LSA traffic not to mention
> > >storage within LSDB (which I gather can only store
> > >65536 TE LSAs).
> > >
> >
> > First, of course , in some environments, Constraint Based Routing may be
> performed "off-line"/"in a Centralised Manner". In these situations, per-PSC
> bandwidth availability can be determined by the centralised tool without
> relying on extensions to OSPF/ISIS.
> >
> > Where Constraint Based Routing is performed "on-line"/"in a Distributed
> Manner", then yes, OSPF/ISIS are required to propagate all necessary
> bandwidth information. This could be achieved in a number of ways:
> >         - one approach would be to advertise bandwidth information for
> every PSC. As you are pointing out above, this may lead to
> scaling/operational issues earlier than desired.
> >         - another approach would be to advertise bandwidth information
> only for each "family/class" of PSCs. A family/class of PSC would comprise
> all the PSCs which share the same bandwidth constraints. It is likely that
> multiple PSCs can share the same bandwidth constraints (eg
> "max-reservable-bandwidth"). For instance, multiple Premium/Non-real-time
> PSCs may share the same "max-reservable-bandwidth". In that case, you have
> traded a little bit of fine-grain control (you can't enforce bandwidth
> constraints which are different for absolutely every PSC), but you have
> significantly gained in scalability of OSPF/ISIS by "only" advertising 2/3
> available bandwidth information.
> >
> > You will find some text on the second approach in section "6.7 Traffic
> Engineering in Diffserv Environments" of <draft-ietf-tewg-framework-01.txt>:
> >
> >    "Instead of having per-class parameters being configured and
> >    propagated on each LSR interface, per-class parameters can be
> >    aggregated into per-class-type parameters. The main motivation for
> >    grouping a set of classes into a class-type is to improve the
> >    scalability of IGP link state advertisements by propagating
> >    information on a per-class-type basis instead of on a per-class
> >    basis, and also to allow better bandwidth sharing between  classes in
> >    the same class-type..."
> >
> > Francois
> >
> > >Thanks,
> > >
> > >Darek Skalecki
> > >Nortel Networks
> > >
> >
> > _________________________________________________________________
> > Francois Le Faucheur
> > Development Engineer, IOS Layer 3 Services
> > Cisco Systems
> > Office Phone:           +33 4 92 96 75 64
> > Home Office Phone:     +33 4 92 94 00 78
> > Mobile :               +33 6 89 108 159
> > Vmail:                 +33 1 58 04 62 66
> > Fax:                   +33 4 92 96 79 08
> > Email:                  flefauch@cisco.com
> > _________________________________________________________________
> > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
> > _________________________________________________________________