The MPLS WG Archive

["Angela Chiu" <alchiu@research.att.com>]

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