Subject: RE: Traffic engineering and RSVP

From: Shen Gangxiang <[email-masked]>
Date: Tue, 24 Oct 2000 00:11:59 +0800

Hi, David,

Please see my comments below.

-----Original Message-----
From: David Charlap
To: [email-masked]
Sent: 23/10/00 10:03 PM
Subject: Re: Traffic engineering and RSVP

Shen Gangxiang wrote:
> 
> Conventional RSVP doesn't support explicit path. In fact, it find its
> path based on the route table provided by those routing protocols hop
> by hop (e.g.OSPF).

Traditional RSVP is not a routing protocol.  It isn't supposed to in any
way change the way data packets are routed.  It's only supposed to make
reservations.

=>Agree. In fact, I guess you have misunderstood me. I didn't mean that RSVP
is a routing protocol. I just wanted to point out that RSVP needs
information from the routing ptotocols (e.g. PATH message)

> So it can't support traffic engineering.

But it doesn't dictate what other routing protocols might be used.  If
you don't want to use MPLS, you can still use some form of constraint-
based routing to make the data follow a traffic-engineered path.  A
proper RSVP implementation should make reservations along that routed
path, just like it would on any other routed path.

=>Agree. However, to support traffic engineering, some extentions are still
needed, e.g. ER.

> However,in MPLS people extended RSVP to let it support explicit path,
> that is RSVP-TE, so it can support traffic engineering now. Besides
> RSVP-TE, CR-LDP also have the functionlity to support traffic
> engineering.

RSVP-TE is designed for a completely different purpose.  It is meant to
carry traffic engineering information (labels and explicit paths), in
addition to QoS values.  It is designed to carry this information
through a network where every node is running RSVP-TE.

Straight RSVP is designed to carry QoS values through the internet,
where many nodes will not be running RSVP.  Needless to say, traffic
engineering is impossible if some routers along the data path don't
participate.
=>Agree.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 23 Oct 2000 14:23:14 -0400

Shen Gangxiang wrote:
> 
> Agree. However, to support traffic engineering, some extentions are
> still needed, e.g. ER.

But an extension like the ERO object (which changes the nature of RSVP -
allowing it to change the path that data packets follow) is not the only
way.

It is also possible if the routes are determined through some TE routing
protocol.  Leaving RSVP with its original duties of only making
reservations.

But this is not relevant here in an MPLS mailing list.

-- David