Subject: another ping's fast-reroute draft question

From: "Doug Degan" <[email-masked]>
Date: Sun, 24 Feb 2002 13:22:26 +0200

in section 4.3  it is said that the PLR should try to find the bypass tunnel. NHOP/NNHOP one.

 my question is what are the assumptions that are made when saying that the PLR is capable to do so?

1.a) The PLR should choose from the Bypass tunnels available, meaning tunnels which this router is their Ingress. should it know their explicit route, or their recorded route is enough?

1.b) It should parse the current (protected) LSP's recorded route. does it gives enough information?
the PLR needs to know which node/link to avoid and what bypass destinations are good.
as far as I know - the recorded route doesn't have to include router's ID/addresses.

2.a) what happens if TE is not enabled in the PLR or in another node along the protected lsp's path - does it mean that FRR wil not work?

2.b) what if TE is enabled anywhere but CSPF is not used (and no explicit path is found in the candidate for bypass tunnels)

thanks alot again.
douglas

---

From: Ping Pan <[email-masked]>
Date: Sun, 24 Feb 2002 08:27:39 -0800

Doug Degan wrote:

> 1.a) The PLR should choose from the Bypass tunnels available, meaning 
> tunnels which this router is their Ingress. 

Yes.

> should it know their 
> explicit route, or their recorded route is enough?
>

The bypass LSPs can be established independent from the protected LSPs. 
When protecting a LSP, a PLR just uses a bypass LSP as an alternative 
route for the protected LSP. Knowing ERO or RRO is an implementation issue.

> as far as I know - the recorded route doesn't have to include router's 

Huh? RRO, Subtype = 1.

>  
> 
> 2.a) what happens if TE is not enabled in the PLR or in another node 
> along the protected lsp's path - does it mean that FRR wil not work?
> 
>  
> 
> 2.b) what if TE is enabled anywhere but CSPF is not used (and no 
> explicit path is found in the candidate for bypass tunnels)
> 
> 

The most important task for bypass LSPs is to avoid some links or nodes. 
   If this cannot be doe intelligently, I would recommend to use 
whatever the means available to get the job done.... (type the path by 
hand, for example ...: -))

- Ping

---

From: "Doug Degan" <[email-masked]>
Date: Wed, 27 Feb 2002 17:48:43 +0200

hi. and thanks for the quick answer.
 I look at the proposed methods as such that should enable fully automatic
 FRR protection establishement for a LSP.
 meaning automatic bypass association and de-association (upon the bypass
 shutting) and automatic detour computations.
 I know it is possible to configure almost everything manually but I think
it
 is ugly for example to associate the pre established bypass to the
protected
 LSP manually in the PLR.

 Are the proposed methods enable this automatic establishing?

 and if so - what are the assumptions about the other relevant routers in
the
 network?
 should they push routers addresses/id in the RRO object?
 shoult the bypass tunnels be configured with ERO object?

thanks in forward.

---

From: Ping Pan <[email-masked]>
Date: Wed, 27 Feb 2002 08:32:23 -0800

>  Are the proposed methods enable this automatic establishing?

The proposal describes how protocol works. How to setup bypass LSPs 
seems to be an implementation issue.

>  should they push routers addresses/id in the RRO object?

The draft has defined RRO requirements.

>  shoult the bypass tunnels be configured with ERO object?

It's an implementation issue.

- Ping

---

From: "Doug Degan" <[email-masked]>
Date: Wed, 27 Feb 2002 19:14:27 +0200

> seems to be an implementation issue.

I wasn't referring to the BYPASS's setup.
I was referring to the BYPASS association or the DETOUR setup. (section 7 in
the new draft).
you need to know the requirements from both - what node/link to avoid. and
what node to reach.

I quote:

<!--StartFragment-->
     ,the following information should be collected at a PLR:

    - The list of downstream nodes that the protected LSP passes
       through. This information is readily available from the
       RECORD_ROUTE objects during LSP setup. Note, a protected LSP's
       ERO may not provide adequate information since the LSP could
       be a loose routed path.

     - The downstream links/nodes that we want to protect against. Once
       again, this information is learnt from the RECORD_ROUTE objects.
<!--EndFragment-->

the node's id may not be found in the RECORD_ROUTE .
so both of the methods will not work automatically...

> The draft has defined RRO requirements.

I couldn't find it even in the new draft - is "including routers ip address"
is a requirement of RRO?
Is it missing in purpose?or by mistake?

thanks.
douglas degan.