The MPLS WG Archive

[Koling Chang <kchang@axiowave.com>]

Hi! Alia,

According to the draft:

Last 4 lines of 4.2 on Page 17:

   rerouted LSP's data packets.  When MPs use per interface label space,
   the PLR must send Path messages (for each Reroutable LSP) via the
   bypass tunnel prior to the failure in order to discover the
   appropriate MP label.

Last 2 lines of 4.3 on Page 18:

   Note that when global labels are used, no Path message need be sent
   via the bypass tunnel prior to failure.

Both indicates path messages are sent prior to failure if
per-interface labels are used. So they are signalled in advance.

For lsps using global label space, can an LSR assumes it's a MP for
them if there are bypass tunnels terminating there?

If it really wants to make sure, an RRO of the lsp contains matching
address of the head-end of the bypass tunnel may be a hint.

Please comment.


Koling


On Mon, 11 Feb 2002, Alia Atlas wrote:

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