The MPLS WG Archive

["Doug Degan" <doug_degan@hotmail.com>]

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" <aatlas@avici.com>
To: "Jay Karthik" <jkarthik@avici.com>
Cc: "Doug Degan" <doug_degan@hotmail.com>; "Ping Pan" <pingpan@juniper.net>;
<mpls@UU.NET>
Sent: Monday, February 11, 2002 8:14 PM
Subject: Re: fast-reroute question


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