The MPLS WG Archive

[neil.2.harrison@bt.com]

Giles Heron wrote 13 December 2001 10:48
<snip>
> Again, I would compare this to IP networks.  In the IP case we don't
> send pings constantly to every prefix in our networks to 
> check that they
> are still reachable, so I'm not 100% convinced we should be 
> sending CVs
> constantly in MPLS?
> 
> > Seems like we disagree on how small that niche is.
> 
> looks like it :)
Hi Giles...

IP networks (and I mean at the IP level) have not until recently been asked
to deliver carrier-strength services.  Customer's of trad VPNs (ie managed
BW services by another name) do expect a certain level of robustness and
determinism....and they expect the carriers to be able to offer SLAs, know
about problems before they have to report them and fix problems fast.  And
even with the technologies that have (supposedly) been designed with these
factors in mind, we still fall short of customer expectations in these areas
IMO.

There is also a big difference between a basic fault handling capability and
QoS monitoring.  The former is, in my experience, an expected must-have from
any carrier worthy of the name and needs building into the basic user-plane
and control-plane protocols from the outset, eg the trail trace identifier
was put in SDH VCs for a good reason, it was not put there just for the sake
of it....similarly just have a look at the exception handling in Q.2931,
again it was put there for very good reasons.  As regards QoS monitoring,
this is simply not needed (nor indeed cost-effective) on a per connection
basis.....sampling and ad hoc 2nd level tools are required here.

Do I therefore conclude that your company is happy to use customers as
defect detectors and 1st level fault management tools?  But maybe your
network has never, and will never, have failures (I wish I could say the
same for the ones I have knowledge of).

In any case, if one operator chooses not to employ pro-active
fault-management tools then that's OK providing they don't deny other
operators the ability to have them. (Did you see the list of carriers saying
they wanted the OAM work?....I hope you are not telling me they have all got
this requirement wrong?)

Further, if you have no well defined defect detection mechanisms, I'm
curious to know how you define/measure availability in a consistent manner
and how QoS metrics are started/stopped on availability state change (since
they are only valid in the available state).  Responsibility for the
standardised definition of these metrics (note **not** objectives) cannot be
abdicated by any stds body working in this area, since these metrics have to
be standardised so that operators/vendors can interwork (and interface with
OSS) in a consistent manner (and I am sure customers would like to see
standardised metrics so that they can compare services from operator X and
operator Y).  This latter requirement (ie metric standardisation) seems not
to have been understood I would say, and it is actually rather important.

thanks & regards, Neil
<snipped to end>