The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Ravi,

>    I have a couple of questions on the LSP hierarchy draft
>    These may be nitty gritty details. I thought I would ask them
>    anyway. 

Please do!  In the final analysis, nitty gritty details make or
break implementations (and drafts).

>    1) Do FA-LSPs span across multiple OSPF areas?  If the answer is
>       yes, 
>        a) the OSPF-TE draft need to be extended to support
>           summarization of TE-LSAs across areas.    

To date, not too much work has been done on multi-area TE path
computation.  There is a draft draft-fujita-ospf-te-summary-00.txt
on TE summarization; I think more work should be focussed on this
subject.

>        b) I am not sure how forwarding adjacencies can be represented
>           as unnumbered links.

We suggest that FAs are numbered with the router IDs of the two ends
in the case where they are not explicitly numbered.

>    2) Suppose, the metric on the path to FA-LSP tail-end changes such a
>       way that, there is a better TE path between head-end and the
>       tail-end. Then all the LSPs that follow FA-LSP path may need to
>       be rerouted (assuming they are not pinned).  This calls for
>       considerable reroute processing at the head-end of the FA-LSP.

If the head end of the above FA-LSP notices a better path and
reroutes the FA-LSP, yes, you are right, the burden is on the head
end to adjust the tunneled LSPs to take the new FA-LSP path.  There
is definitely some work here, but consider that the head end of a
'normal' TE LSP usually maps several hundred or thousand IP routes
to the LSP, and manages to (at least, it should!) handle reroutes
reasonably gracefully.  If the number of tunneled LSPs over a single
FA-LSP approaches 10s to 100s of thousands, this issue gets serious --
however, in this event, LSP hierarchy would have proven its worth :-)

Note that there is little signalling impact: either the Path messages
were going through the FA-LSP (small change to make them take the new
path), or they were unicast to the tail end (nothing changes).

>   Overall I think it is a good draft and, should be adopted as IETF
>   draft. 

Thanks!

Kireeti.