The MPLS WG Archive

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

Eduard,

Resource class affinity attributes are different from PSCs. The attributes
associated with a traffic trunk can be used to specify the class of
resources which are to be explicitly included or excluded from the path of
the traffic trunk, e.g., excluding all satellite links for low-delay track
trunks. See RFC 2702.

Regards,
Angela

-----Original Message-----
From: Metz, E.T. [mailto:E.T.Metz@kpn.com]
Sent: Thursday, June 22, 2000 4:01 AM
To: 'Francois Le Faucheur'; alchiu@research.att.com
Cc: 'Darek Skalecki'; 'mpls'
Subject: RE: Bandwidth reservation per PSC



Hi,

isn't this already included in the current drafts? I thought there were
resource classes defined. This may not match with the PSC though.

In general, when (if) some form of classes are available, wouldn't it be
more efficient to map new types of classes to these? Instead of defining
extensions for new types of classes.

Just some thoughts.

cheers,
	Eduard

> -----Original Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: woensdag 21 juni 2000 16:48
> To: alchiu@research.att.com
> Cc: 'Darek Skalecki'; 'mpls'; 'Francois Le Faucheur'
> Subject: RE: Bandwidth reservation per PSC
>
>
> Darek,
> I am hoping to submit something on extensions to IGPs for
> support of "Class-types". Let me know if you're interested in
> working on this.
> Francois
>
> At 17:41 20/06/2000 -0400, Angela Chiu wrote:
> >Darek,
> >
> >I don't think it is currently included in the OSPF and ISIS
> TE extensions. I
> >am not aware of anyone who is working on it. But I could be
> wrong since
> >there are so many activities around MPLS, hard to keep track
> of all of them.
> >
> >Angela
> >
> >-----Original Message-----
> >From: Darek Skalecki [mailto:dareks@nortelnetworks.com]
> >Sent: Tuesday, June 20, 2000 4:06 PM
> >To: alchiu
> >Cc: mpls; 'Francois Le Faucheur'
> >Subject: Re: Bandwidth reservation per PSC
> >
> >
> >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
> >> > _________________________________________________________________
> >
> _________________________________________________________________
> 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
> _________________________________________________________________
>