Subject: FEC element for RSVP-TE?

From: [email-masked]
Date: Fri, 19 Jan 2001 18:59:51 -0800

Hi all:
     I have one question in mind when reading the RSVP-TE draft.  Does RSVP-TE
define some object similar to FEC element in the LDP draft so that we can set up
a LSP for traffics belonging to the FEC?  If the RSVP path message does not
carry such object and it does not carry a ER object, then intermediate LSR can
only use the destination IP address in the session object to determine the next
hop.   This means the ingress RSVP initiator need to know exactly who will be
the egress router when it sends out the RSVP path message.    This does not seem
to be very pratical to me in the case where RSVP-TE is used to set up a LSP
tunnel for traffics belonging to a FEC  to meet its bandwidth requirements.

Am I missing something here?

-- James Huang

---

From: David Charlap <[email-masked]>
Date: Mon, 22 Jan 2001 10:36:11 -0500

[email-masked] wrote:
> 
>      I have one question in mind when reading the RSVP-TE draft.  Does
> RSVP-TE define some object similar to FEC element in the LDP draft so
> that we can set up a LSP for traffics belonging to the FEC?

No.

RSVP-TE is not a label-distribution protocol.  It is a tunnel setup
protocol.  This is an important semantic difference.

> If the RSVP path message does not carry such object and it does not
> carry a ER object, then intermediate LSR can only use the destination
> IP address in the session object to determine the next hop.

Correct.

> This means the ingress RSVP initiator need to know exactly who will be
> the egress router when it sends out the RSVP path message.    This
> does not seem to be very pratical to me in the case where RSVP-TE is
> used to set up a LSP tunnel for traffics belonging to a FEC  to meet
> its bandwidth requirements.

RSVP-TE is addressing a different problem from LDP.

LDP's goal is to get labels on all the switches so that they may be used
in lieu of IP best-match algorithms when forwarding traffic.  Its goal
is not to establish tunnels, although that does happen as a result of
label distribution.

RSVP-TE's goal is to establish tunnels between endpoints.  In order to
do so, it must know what those endpoints are.  Its goal is not to
distribute labels, although that does happen as a part of establishing
tunnels.

In other words, there are situations where LDP makes more sense than
RSVP.  One such situation is where you don't know, and can't determine,
where your tunnel endpoints will be.

There are also situations where RSVP makes more sense than LDP.  One
such sitation is where shared reservations (for make-before-break
rerouting) is required.

-- David