The MPLS WG Archive

[Alia Atlas <aatlas@avici.com>]

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

At 11:46 AM 2/11/02 -0500, Jay Karthik wrote:
>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
>
>
>At 05:49 PM 2/11/02 +0200, Doug Degan wrote:
>>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" <jkarthik@avici.com>
>>To: "Doug Degan" <doug_degan@hotmail.com>; "Ping Pan" <pingpan@juniper.net>
>>Cc: <mpls@UU.NET>
>>Sent: Monday, February 11, 2002 5:28 PM
>>Subject: Re: fast-reroute question
>>
>>
>> > At 04:35 PM 2/11/02 +0200, Doug Degan wrote:
>> > >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.
>> >
>> > 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.
>> >
>> > >thanks again.
>> > >----- Original Message -----
>> > >From: "Ping Pan" <pingpan@juniper.net>
>> > >To: "Doug Degan" <doug_degan@hotmail.com>
>> > >Cc: <mpls@UU.NET>
>> > >Sent: Sunday, February 10, 2002 8:52 PM
>> > >Subject: Re: fast-reroute question
>> > >
>> > >
>> > > > Doug Degan wrote:
>> > > >
>> > > > > 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!
>> > > > >
>> > > >
>> > > >
>> > > > 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
>> > > >
>> > > >
>> > > > >
>> > > > >
>> > > > > thanks in advance.
>> > > > >
>> > > > > doug.
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> >
>> >
>