The MPLS WG Archive

[Yakov Rekhter <yakov@juniper.net>]

Sven,

> Hi,
> 
> I would like to clarify two questions regarding the hierarchy draft that is
> currently on last call:
> 
> 1. Dynamic recomputation of the path of the FA-LSP
> 
> If I understand correctly, the path information regarding the FA-LSP is
> made available to other nodes by means of the PATH TLV. 

Correct.

> This information may be used by other nodes for their own path computations. 

Correct.

> They could for instance take it into account when computing a backup path. 

Correct.

> Then if the FA-LSP changes path, primary and backup path of the client 
> LSPs may no longer be disjoint.

Correct.

> My proposal would be to foresee the possibility to restrict the
> reroutability of the FA-LSP and advertise this in the PATH-TLV. In this
> way, nodes that use this information would know whether it is subject to
> change or not.

There may be (at least) two reasons why the FA-LSP gets re-routed:

(1) the current path taken by FA-LSP becomes unfeasible (e.g., one
of the links along the path went down)

(2) there is a "better" path, so FA-LSP is re-routed as part of
optimization.
  
Do you want to restrict re-routability in both cases ? Or only
in the second one ?

> 2. Automatic setup of FA-LSP
> 
> The draft says "Otherwise (if no existing FA-LSP is found), the LSR sets up
> a new FA-LSP.  That is, it initiates a new LSP setup just for the FA-LSP."
> I would like to clarify what happens when two FA-LSPs exist that, when
> concatenated, can replace the new FA-LSP that is proposed to be set up in
> the quoted text.
> 
> I would propose to say that the LSR may set up a new FA-LSP or
> alternatively, it may replace the hop by a sequence of hops for which FAs
> are available.

that would be ok, *provided* that the the strict hop subsequence 
from the ERO carried by the new LSP matches the one resulted from
the concatenation of several FA-LSPs. Agreed ? 

Yakov.