The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

Yuan Gu wrote:
> 
> 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).

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

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