Subject: rsvp refresh question

From: Yuan Gu <[email-masked]>
Date: Thu, 11 Jul 2002 17:15:27 -0700

Hello:

In RFC2205, the refresh mechanism is defined not only to refresh the
state but also to UPDATE the state maintained by RSVP(Section 2.3, page
23). But in RFC3209 or any other document, there is no clearify about
this. Is this refresh UPDATE concept automaticly extended to RSVP-TE? If
so, beside update the QoS parameters, we also can use refresh msg to
update other parameters such as ERO, Session_Attribute and Label? Then
we don't need "make before break" any more? What's the pros and cons to
use refresh msg to modify the existing LSP? At last, can anybody
clearify how cisco and Juniper handle this issue? Do they compare every
bit of received refresh msg with exiting states?

Thanks alot!

Yuan

---

From: David Charlap <[email-masked]>
Date: Tue, 16 Jul 2002 12:29:25 -0400

Yuan Gu wrote:
> state but also to UPDATE the state maintained by RSVP(Section 2.3, page 23).

Correct.  RSVP is a soft-state protocol, which means that state may
dynamically change, simply by changing a parameter at the next refresh
message.

> But in RFC3209 or any other document, there is no clearify about
> this. Is this refresh UPDATE concept automaticly extended to RSVP-TE?

Yes, but it is not recommended.  The make-before-break mechanism is the
recommended way to modify an LSP.

An RSVP-TE implementation should be prepared to deal with modifications
that may take place as a part of refreshes, but edge routers should not
expect all transit routers to be able to properly handle such changes.

> If so, beside update the QoS parameters, we also can use refresh msg to

Changing innocuous things, like TIME_VALUES, and ADSPEC objects probably
won't break anything, since they are usually processed entirely within RSVP.

Changing things that affect a connection's properties (like
SESSION_ATTRIBUTES, LABEL, FLOWSPEC, etc.) may not be possible on some
platforms.  Not all forwarding hardware has the ability to modify an in-
place connection.  Some hardware can only modify a connection by tearing
it down, and then creating a new one - which will involve a time period
during which the data-plane is broken.  This will be unacceptible in a
production network.

Changing things that affect the LSP's route (like the ERO) will result
in a time period where the LSP may flap many times between two different
routes, or may even temporarily go down.  It's a little bit difficult to
explin the situation in e-mail, but I'll try if you insist.  Suffice it
to say that dynamically changing an ERO will almost certainly result in
an interruption of data-plane forwarding, which is unacceptible in a
production network.

-- David