[c-nsp] GbE over SDH

[Paolo Lucente]

Hi MKS,

if the LSR hasn't visibility into the SDH layer and there is a
separate box doing EOS, there is not much accurate actions the
LSR can take by itself. For example, the LSR could send probes
across the link and detect packet loss or increased delay either
of which would be good hints for capacity reduction. SAA should
be all you need.

This can help making an educated guess that there is a possible
capacity reduction on the link. Because this is only a guess i
would stop detecting the issue and reporting it to an operator
through, say, an SNMP trap.

Alternatively, it's very likely that the EOS box would support
SNMP trap itself. As i believe these would be contextualized,
you might even think at an automatic reaction (ie. adjust policy
maps on relevant interfaces/tunnels) and not just stop to the
detection phase. 

If this option is viable, it then becomes a tradeoff between
doing things in a controlled way, importance of the link and
outage duration.

Cheers,
Paolo


On Wed, Apr 23, 2008 at 08:22:54AM +0000, MKS wrote:
> Hi list
> 
> We are getting N times STM-1 connections delivered over GbE (SDH
> network). Currently we are running MPLS-TE over these GbE for
> loadbalancing.
> The problem is that we have seen failures where we loose part of the
> capacity, e.g. loose 2 STM out of 4, and we are unable to detect this
> failure, just a flatline when looking at mrtg graphs.
> The obvious flaw in this scheme is that QoS basically stops working,
> since my equipment sends more high priority traffic than is available.
> One way of solving that is to have QoS also on the SDH GbE.
> This kind of failure is something that I would like to detect but
> don't see how it can be done. I don't know the capabilities of the SDH
> GbE equipment.
> Is there a creative network engineer out there that has a solution for
> this problem?
> 
> Regards
> MKS