[c-nsp] MPLS best practices question

[Peter Rathlev]

On Tue, 2010-06-22 at 09:49 -0500, cisconsp at secureobscure.com wrote:
> 2) OSPF timers or BFD? Currently my approach has been ospf timers of
> 1/4, its fast and seems pretty compatible with everything I have tried
> it on. All of my links are direct between routed ports so there are no
> intermediate devices that would keep a link lit after equipment
> failure. I know BFD makes sense but some of my code is old and
> linecards are flakey so I'm curious to know who has ditched low timers
> for BFD or vice versa. 

We ditched BFD in favour of low (IS-IS) timers, since 6500/Sup720 SXF
couldn't handle low BFD timers well. We're running SXI now, but haven't
changed back. We would actually like to, since some of our (leased)
amplified/DWDM links are very slow to see link down.

Question: Is fast BFD timers a good idea on Sup720/SXI?

Another question: Is adjusting IGP timers (or using BFD) enough in an
MPLS network? How does the network invalidate allocated labels and
choosing a new LSP, disregarding FRR? Does it make sense to adjust the
holdtime or backoff timers in LDP for faster convergence?

> 3) OSPF costing, automatic bandwidth-based or manual costing of PE-P
> and P-P links? I have seen both used in production before, I do have
> 10gig interfaces and 40gig port-channels so I would need to alter the
> ospf reference bandwidth if auto-costing.

We also use manually configured costs. Auto cost cannot account for link
latency based on e.g. path length.

> 4) MTU on p2p gigabit ethernet links. Currently I have stolen another
> list members MTU settings using 1530 for global & mpls MTU, and 1524
> as IP MTU on all PE-P and P-P interfaces. I don't have any jumbo frame
> requirements, but do have upstream providers that may not support
> jumbo so I'm trying to keep the MTU fairly low.

We generally use the highest supported MTU (often 9216 bytes) on all
internal links, in an effort to make an eventual transition easier
later. All external (customer/access) links use 1500 bytes.

-- 
Peter