Re: A question regarding rsvp-te

Xiaoning He wrote:
> Some parts of my research require some knowledge of RSVP-TE and MPLS. I
> have a simple question and I appreciate if you can give me some idea or
> link so that I can read the right draft or RFC.
>
> My questions is
>
> If there is an existing LSP established by RSVP-TE. Now, some segments
> of the link have to be changed as shown as follows:
>
> a--->b--->c to a--->b--->d
>
> my question is that is there anyway we don't have to tear down the old
> path, I mean the label from a-->b doesn't have to be changed? Is that
> something allowed in RSVP-TE? 

If there are no explicit routes involved, then the LSP follows the 
routing table.  When the route change propagates to router B, it will 
send a PathTear to C and a Path to D.  When the Resv comes back from D, 
router B does not have to propagate it further upstream.

If there is an explicit route, then the ERO must be changed by the 
ingress node (A).  It can choose to do this in one of three ways.

The preferable way is make-before-break.  In this, A signals a new LSP 
along the new ERO.  When the new LSP comes up, A redirects data-plane 
traffic from the old LSP to the new LSP.  Then it tears down the 
original LSP.  If the two LSPs belong to the same session and SE-style 
is used for the reservation, then this can be done without wasting 
bandwidth on the links that are shared between the two LSPs.

A less preferable way is break-before-make.  A tears the original LSP, 
and then establishes a new one with the new ERO.  This obviously has the 
problem of disrupting data-plane traffic.

A third way (which I also don't like) is for A to simple change the ERO 
in a Path refresh.  When B gets the updated Path message, it will send a 
PathTear to C and a Path to D, and the LSP will reroute.

The problem with changing the ERO is not obvious from your topology, 
since you also changed the destination router (which changes the session 
address, BTW).  Most of the time, however, a reroute like this is 
expected to preserve traffic flow to the same destination.  For example, 
you might have a topology like this:


        /---C-------D---\
A-----B<                 >F-----G
        \-------E-------/

Now, suppose we have an ERO sending traffic along the path A-B-E-F-G. 
Now we want to reroute it to A-B-C-D-F-G.

If we use the make-before-break method, there's no problem.  We briefly 
have two LSPs - one using eath ERO.  If SE-style is used, Bandwidth is 
shared between them on the links that are in common (A-B and F-G).  The 
traffic reroutes when A makes the switchover.

If we use break-before-make, obviously, there's an interruption.

But observe what happens if we just change the ERO in-line:

B receives a Path message where the ERO specifies a new next-hop.  B 
sends a Path message to C and a PathTear to E.  C propagates the Path 
message to D, and then to F.  Meanwhile, E propagates a PathTear to F.

If the PathTear reaches F before the Path message, F will tear the 
connection and propagate the PathTear to G.  Then the Path arrives at F, 
which sends it to G.  G sends back a Resv, which propagates back to F, 
then to D, C and B.  The data-plane is broken for the time interval 
between when the PathTear reaches F and when the Resv makes its way back 
to B.

If the Path reaches F before the PathTear message, it may or may not be 
better.  F will receive the Path message and see that the previous-hop 
router for the LSP has changed.  It will then generate a Resv message to 
send back to D, propagating to C and B.  When the Resv reaches B, the 
data-plane traffic will start following the new Path.

But then the PathTear arrives at F.  F might ignore the PathTear, since 
it is arriving on a different interface from the (new) PHOP, but I think 
it's also legal for it to process that PathTear.  This causes the Path 
from F to G to be torn.  When D sends its next refresh, it will then be 
re-established, but this might not happen for a long time - especially 
if features like RSVP-Hello and refresh reduction are operating between 
D and F.

In other words, if A simply changes the ERO, there is a very real 
possibility that the data-plane will be broken for at least a short 
time, and possibly for a long time.

IMO, make-before-break is the only good way to change the route of an 
LSP with an ERO.

-- David