Subject: Doubt on Make Before Break Concept

From: Rajesh P Jain <[email-masked]>
Date: Mon, 13 Aug 2001 20:30:07 +0530

Hi,
                    I have some doubts on Smooth Re-Routing of LSP
Tunnels.

1. As I understand the draft, the make-before-break (Smooth Re-Routing)
should be initiated by the Sender Node (Path Message is sent new with
new ERO object and ofcourse with a different LSP ID in the
SENDER_TEMPLATE ). The receiver receives this Path Message.

2. Now, the receiver HAS to send a RESERVE message with SE reservation
style (Of course with Filter spec list containing the SENDER_TEMPLATE of
the old Path Message and SENDER_TEMPLATE of new Path Message i.e they
differ only in their LSP ID's, and of course ERO's).

3. Now, the New Path Message received  is AS GOOD AS A New Sender for
this receiver and hence it MAY NOT send a RESERVE Message for this
sender (The receiver sends only if it wants some reservation for this
sender).

4. In case, if the receiver chooses not to send the reserve message,
then Smooth Re-Route WILL NOT happen.

                    So, can anyone explain whether the Smooth Re-Routing
is Sender-Based  or Receiver -Based (Who has the control of Re-Routing
the traffic ??) ???

                    In case of Increase in Band-width (For a particular
LSP), the Sender indicates the increase in band-width BUT still the
Receiver HAS to send the Reserve message for this increase in the
Band-width. So, the same problem holds good for this case also????

                    Am I missing something???? Please throw light on
this issue possibly with an example.

TIA
        Rajesh P Jain

---

From: "Kota, Ravikumar" <[email-masked]>
Date: Mon, 13 Aug 2001 17:31:17 -0400

Hi 
If u see on page no 14 of draft_ietf_mpls_lsp_tunnel_08.txt-->>
ur doubt will be cleared.
On links ( LSr s) that are held in common( old LSP , new LSP as process of
"smooth" rerouting)
, the shared SESSION object and SE style allow the LSP to be established
sharing resources with the old LSP.

SO if for the new LSP PATH message , the treatment of nodes varies depends
on its type.
If it is new node , it will take the PATH message conventionally./
Otherwise , it will allow to share the resources of old LSP with new LSP.
This is how new LSP will be established , then u can tear down the old LSP ,
once u get RESV_CONFORM messaqge for the new LSP.

NOTE : Shared SE style , Common  SESSION attribute will be helpful to do
smooth rerouting,
and also in bandwidth increase of a tunnel.
If u do not have above , ( SE style reservation and commom SESSION id ) then
this new LSP will try to get
extra BW than necessary.
Ex., One LSP link has 10 Mb/s , where as u want to increase it to 20 Mb/s.
ACtual link capacity is 21Mb/s.
It will not allow to increase the bandwidth to 20Mb/s as , the available is
only 10Mb/s.

But the Link does not know that u wanted to give up the allocated 10Mb/s
after once u finish this new reservation for 20Mb/s. This is sort of
Deadlock
The solution is : If u can make use of the allocated bw ie., 10Mb/s in the
admission control , then u can entertain the new request and after taht u
can release the old allocated bw.
for this to happen , the new pathn request should have 2 things in common to
old request(with which u got 10Mb/s)
they are : same session id( with different LSP tunnel id) , and reservation
style is SE.SO that the new and old LSPs will share the bandwidth .

Regards
Ravikumar Kota 
Cratos Networks Inc
100, NAGOG PARK
ACTON ,MA-01824

-----Original Message-----
From: Rajesh P Jain [mailto:[email-masked]]
Sent: Monday, August 13, 2001 11:00 AM
To: MPLS UUNET Mailing List; [email-masked]
Subject: Doubt on Make Before Break Concept

Hi,

TIA
        Rajesh P Jain

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

---

From: "Feng, Mark" <[email-masked]>
Date: Tue, 14 Aug 2001 14:07:32 -0700

When the receiver receives the new Path message, it triggers a state change.
A new Resv message will be sent out, with the new sender added. 

When the transit nodes process the new Resv message, since there is a new
sender in the Resv message, it also triggers a state change. Resv message
will then be sent out at each of the transit node. 

If the new path tranverses through different nodes, at the new nodes, the
Resv message also triggers a state change, since it is new, resulting in the
Resv message being sent out.

In other words, the Resv message is not absorbed anywhere, as you suggested.

Samething applies to increase of bandwidth.

Hope this helps.

-Mark

> Sent: Monday, August 13, 2001 8:00 AM