The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

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.