Subject: RE: LSP failure detection

From: [email-masked]
Date: Thu, 9 Nov 2000 10:07:50 -0000

What is the defect entry criteria on these rapid Hellos?  I would strongly
suggest that if anyone is thinking of trying to get very fast reactions
times to be used for restoration they should be very careful.  In my view
restoration times above the L1 (ie PDH/SDH/OTN) should not be faster than
somewhere in the region of 2-3s.....otherwise you are going to get a lot of
unecessary hits when the event would of have self-healed.  And if anyone is
using some multi-level priority bumping scheme then (esp at highish
utilisations) this can lead to significant network disruptions felt far
beyoind the initial event source.

neil

> -----Original Message-----
> From:	David Charlap [SMTP:[email-masked]]
> Sent:	Wednesday, November 08, 2000 6:18 PM
> To:	[email-masked]
> Subject:	Re: LSP failure detection
> 
> Wayne wrote:
> > 
> > I think the RSVP hello is one of the enhancements from a vendor. Not a
> > RFC as the moment. Is that true? Though the hello packet is small,
> > 17.5ms seems a bit aggressive for a large network with a lot of RSVP
> > enabled routers/links.
> 
> It's not part of the RSVP working group at all.  It's not
> vendor-specific, either, however.  It's part of the RSVP-TE draft, and
> is part of the MPLS working group.
> 
> As for 17.5ms, where do you get that number?  I didn't see it in the
> draft anywhere.  I found a 5ms interval, but that's not a requirement -
> it's a recommended default value for a user-configurable parameter.
> 
> That aside, 17.5ms isn't that terrible.  It's a worst-case of sending 57
> hellos per second.  This is substantially less overhead than not using
> hellos.
> 
> A link with 500 inbound and 500 outbound LSPs, configured with a 30s
> refresh interval will generate 34 refresh messages per second (17 Path
> refresh, and 17 Resv refresh).  Given that refresh messages are around
> 100-150 bytes long, and hello messages are 12 bytes long, we're talking
> about generating 3400-5100 bytes per second for refreshes, vs. 684 bytes
> per second for hellos.  Even with the recommended a 5ms interval
> (worst-case of 200 messages per second), hellos would still only
> generate 2400 bytes per second worth of control traffic.
> 
> And, of course, the amount of bandwidth consumed by hello traffic won't
> increse as the number of LSPs increases.
> 
> -- David

---

From: Glen Turner <[email-masked]>
Date: Fri, 10 Nov 2000 00:10:10 +1030

> beyoind the initial event source.

[this is my first port to the WG, please don't flame me if i've missed
 the point too badly]

Hi Neil,

One of the reasons for improving the reaction time, and the OAM performance
in general, is to dispense with protection at the SDH layer and move protection
into MPLS.

For a start this gives the ability to drive a SDH Main and Protect pair at
more than just the Main bandwidth.  Of course, we still have to engineer
the traffic so that the bandwidth falls below Main on a incident, but
that's not too hard.

MPLS also allows a wider range of topologies -- SDH is quite limited and
can't implement all the desirable layer two topologies without having
huge amounts of idle bandwidth.

We're going to use MPLS to implement protection to get the most of out of
our multi-million dollar undersea capacity between Australia, Hawaii and
Continental USA.  We want to run VoIP across this link, so we need sub-second
restoration.  I don't believe that our requirements are unusual, being a
research network we just encounter them early.

Perhaps the best tactic is to allow the lower MPLS LSPs to inform the upper
LSPs of their typical restoration period  [1].  This would be part of the OAM
protocol that propogates the failure [there seem to be multiple groups working
on this?].  The upper LSP can then decide if it is faster to allow restoration
or to select its fast re-route path (or to do a routing update).  It would then
propogate the typical restoration delay of the selected restoration mechanism
to any MPLS LSPs above itself.  A timer would be needed to ensure that the
contracted resoration time is met, if it expires the LSP should fast re-route.

This would allow customers to take redundant LSPs across multiple ISPs to
implement protection from configuration error and other ISP-wide outages.

Regards,
Glen

 [1] The "typical restoration period" would default to a constant that
     depends upon the media type.  Long-haul links could be configured
     to add in the link's latency constant.

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised