Subject: RE: LSP hierarchy with MPLS TE

From: Kireeti Kompella <[email-masked]>
Date: Fri, 23 Jun 2000 10:10:36 -0700 (PDT)

Hi Jeff,

> I find this draft a useful addition to the discussion of TE, and would
> support it's adoption as an MPLS group document.

Thanks!

> However, I am a bit puzzled by the last paragraph before
> section 4.3 (bottom of page 5).

> 	"Route computation procedures should not perform two-way
> 	 connectivity check on the links used by the procedures.
> 	 That is, the two way check should not be performed on
> 	 one-way pipes, as they will fail."

Here's the deal: if you have a unidirectional FA-LSP from A to B,
but no LSP from B to A, and you want to compute a _TE_ path for
another LSP to tunnel over the FA-LSP, the two-way check will not
allow the FA-LSP to be used.  Hence the above statement.

> I agree that relaxing this test for one-way links is a Good Thing.

Note that for CSPF (i.e., TE path) computation, discarding the two-way
check will not cause routing loops.  However, it's trivial to come up
with an example where if a router doesn't do the two-way check for
'regular' SPF but other routers do, you will get permanent routing
loops.  Yes, it might be a Good Thing to eventually relax the two-way
check for regular SPF as well, but that would take much more work.

> looking at the aged out draft "IS-IS extensions for Traffic Engineering"
> <draft-ietf-isis-traffic-01.txt> I don't understand how we distinguish 
> "forward adjacencies" that are unidirectional LSPs from point-to-point 
> adjacencies, where we should retain the test.  

Forwarding adjacencies are (almost) indistinguishable from point-to-point
links.  However, the distinction we're making is CSPF vs. regular
SPF, not FAs vs. p2p links.  For *all* CSPF computations, we recommend
not doing the two-way check.  For all SPF computations, we _highly_
recommend doing the two-way check (for fear of routing loops) until
such time that there is means to achieve consensus among *all* the
routers in an ISIS level/OSPF area not to do the two-way check.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 23 Jun 2000 11:20:58 -0700 (PDT)

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.