The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Feb> msg00207



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

another ping's fast-reroute draft question

  • From: "Doug Degan" <doug_degan@hotmail.com>
  • Date: Wed, 27 Feb 2002 19:14:27 +0200
  • Cc: <mpls@UU.NET>
  • X-OriginalArrivalTime: 27 Feb 2002 17:14:32.0484 (UTC) FILETIME=[3905A640:01C1BFB2]
  • X-Originating-IP: [212.25.110.131]


> Doug Degan wrote:
>
> >  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?
> >
>
>
> The proposal describes how protocol works. How to setup bypass LSPs
> 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...



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