Subject: fast-reroute question

From: "Doug Degan" <[email-masked]>
Date: Sun, 10 Feb 2002 19:30:54 +0200

hi. 
I have another question regarding pan's draft in BYPASS method:
1) how does upstream routers act upon receiving of PATH TEAR message? there should be different activity between normal router and MP - but how does a router know he is active MP for a given LSP?
if he does - he shouldn't tear it, but if he is just transit router - he should tear it!

thanks in advance.
doug.

---

From: Ping Pan <[email-masked]>
Date: Sun, 10 Feb 2002 10:52:37 -0800

Doug Degan wrote:

> 1) how does upstream routers act upon receiving of PATH TEAR message? 
> there should be different activity between normal router and MP - but 
> how does a router know he is active MP for a given LSP?
> 

When there is a network problem, the protected LSPs will use the bypass 
LSP, and initiate Path Messages that will merge at MP. At this point, 
it's a bunch of RSVP sessions using SE. When you get a PathTear, just 
act according to what RSVP had defined.... kill the session and 
associated branches.

- Ping

---

From: "Doug Degan" <[email-masked]>
Date: Mon, 11 Feb 2002 16:35:17 +0200

ping, thanks for the quick answer but looks like I didn't understand it or
wasn't clear enough in my question :

I was refering to the time of failure. not to the time after failure when
the bypass is being used already.

I assume bypass LSP is ready, and primary LSP is protected by it.
then a failure occures somewhere between the PLR and the MP.
the MP will probably get PATH-TEAR message because of it (also all the
routers between the failure and the MP will get it) but the MP shouldn't
send it downstream!!! because the lsp is not going to be teared from the MP
to the Egress.

to this problem I didn't find solution in the draft.

thanks again.

---

From: Jay Karthik <[email-masked]>
Date: Mon, 11 Feb 2002 10:28:41 -0500

>to this problem I didn't find solution in the draft.

Doug,

As you said, the PathTear message will not be propagated downstream
until the MP  has received tear-down from all merging LSPs and
Section 3.2.2. (Procedures for the Merge Point) does describe it.

---

From: "Doug Degan" <[email-masked]>
Date: Mon, 11 Feb 2002 17:49:56 +0200

hi jay, thanks for your answer.
I know that MP shouldn't propagate the path-tear message.
but how does he know upon a path-tear message arrival - that it belong to a
protected  LSP which this router acts as MP for it?
what exactly he checks in the path-tear message and in the  path-state to
know if to propagate it or not?

thanks.

----- Original Message -----
From: "Jay Karthik" <[email-masked]>
To: "Doug Degan" <[email-masked]>; "Ping Pan" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 11, 2002 5:28 PM
Subject: Re: fast-reroute question

> > > > if he does - he shouldn't tear it, but if he is just transit
router - he
> > > > should tear it!

---

From: Jay Karthik <[email-masked]>
Date: Mon, 11 Feb 2002 11:46:35 -0500

Doug,

The LSP ID in the sender_template object as well as the
Tunnel end point / Tunnel ID in the session object will be
matching for all the LSPs while the tunnel sender address
in the sender_template would vary in the path messages
that the MP receives.

The path tear message is also holding the session as well
as the sender_template object and the MP can figure out
whether or not the path tear message that it receives
belongs to a protected LSP.

-Jay

---

From: Alia Atlas <[email-masked]>
Date: Mon, 11 Feb 2002 12:14:10 -0600

Doug,

There is an issue for the MP for a primary LSP protected by a bypass
tunnel.  Until the failure occurs, the MP will not know that it is a merge
node for the primary LSP, because the backup tunnel will not have been
signaled through the bypass tunnel.

This is resolved by having every node along the primary LSP assume that the
LSP is protected.  So, if a failure is detected by a node, it will not send
a PathTear until the primary LSP's state has timed out.  This delay allows
the backup tunnel to be signaled through the bypass tunnel to the merge
node.  In this way, when the merge node receives the PathTear, the merge
node will have already received the Path message for the backup tunnel and
therefore will not forward the PathTear.

Does that clarify the issue?

Alia

---

From: "Doug Degan" <[email-masked]>
Date: Tue, 12 Feb 2002 16:23:48 +0200

well, this clarify the issue.
now just to summarize it all and to make sure I understood it fully:
1) each router upon receiving PATH_MSG with the session attribute flags of
protection desired - set, will assume upon receiving the RESV_MSG that this
LSP is protected at any place of failure - even if at this node a bypass
tunnel couldn't be associated and even if not all the nodes downstream are
protected.
2) when recognising a failure - (all for considered protected LSP) routers
will not send PATH_TEAR messages downstream, but only RESV_TEAR messages
upstream - those messages will stop at the closest upstream PLR that will
switch to use the bypass.
3) the bypass LSP's signaling mechanism will cause the MP to know that the
LSP is active and may arrives from  2 different interfaces (in other words
to know he is a MPfor this LSP). when one of them will go down - thats no
reason to shut the LSP. only when the other go down too he will shut it.
4) the PATH TEAR (for a considered protected LSP) will be sent only because
of time out, not because of fail detection.

if all this correct I remained with 2 issues:
a. Is it insured that the bypass controll messages will arrive before the
primary lsp's timeout message to the MP?(ensuring that the MP will not tear
down the LSP)
b. Isn't it (intuitively)wrong to assume a LSP is protected at all point
when it doesn't?(the described act in 1)

and finally - I think it should be more detailed described in the draft, as
this is a change in the existing rsvp protocol behavior.(section 2 and 4)

thanks.
Douglas

----- Original Message -----
From: "Alia Atlas" <[email-masked]>
To: "Jay Karthik" <[email-masked]>
Cc: "Doug Degan" <[email-masked]>; "Ping Pan" <[email-masked]>;
<[email-masked]>
Sent: Monday, February 11, 2002 8:14 PM
Subject: Re: fast-reroute question

> >> > >ping, thanks for the quick answer but looks like I didn't understand
it
> >>or
> >> > >send it downstream!!! because the lsp is not going to be teared from
the
> >>MP
> >> > > > > there should be different activity between normal router and
MP -
> >>but