Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-00.txt]

From: [email-masked]
Date: Tue, 10 Jul 2001 16:21:54 +0100

Ping/Ken,

Ken wrote 10 July 2001 07:06
<snipped>
> If you don't use an MPLS control
> message(RSVP-TE, LDP) for the LSP-ping, this mechanism can be used for
> all kind of LSP, such as a static LSP and an LSP established by LDP.

NH=>I agree.  Here are some further comments on the draft and the problem it
is trying to address:

1	MPLS traffic-plane defect handling should, as a design principle, be
independent of the signalling protocol used in the control-plane (or indeed
any other functional component of the control-plane, eg routing protocol, or
the management-plane).  So whether we are considering LDP, RSVP-TE or CR-LDP
(or other) signalling (routing) protocols the defect handling of the
traffic-plane should be independent of these and identical (as far as
practicably possible) in all cases.

2	One specific limit case of 1 is where there is no control-plane.
Traffic-plane defect handling must be still valid and consistent in this
case.

3	An aside corollary of 1 and 2 is that any trails provisioned by
network management (be these with or without a control-plane component, eg
so-called 'hard' and 'soft' permanent connections) must not be taken down by
failures of any control-plane components.  In the case of this draft (see
section 6.2), one would not wish to remove soft permanent LSPs due to a
failure of the returned ICMP-like objects in the RESV messages....either due
to (i) a failure of the (return) data-plane of the control-plane or (ii) a
failure of the (returned) RSVP protocol itself.

4	Before defining specific solutions for defect handling of the
traffic-plane (or indeed the control-plane functional components, eg its
data-plane or the specific signalling or routing protocols used thereon) one
must first identify/agree what defect types are relevant.  For
standardisation/interworking, and subsequent specification of outage metrics
which might be used in SLAs and thus require linking with NMS/OSS activities
like fault-management and billing, operators will need to clear entry and
exit criteria specified for defects, and the consequent actions that need to
be taken on specific defect entry.  For example, for some defect types it
may be vital to squelch the traffic-plane data (of the client layer
networks) to protect the security of customer traffic, eg traffic leaking
out of a VPN say.  Alarm handling must also be considered to suppress alarm
storms in higher layer networks.

The defects that need defining for MPLS layer trails are:
-	simple breaks sourced from layer networks below the MPLS fabric, eg
SDH
-	simple breaks sourced from layer networks within the MPLS fabric, ie
at a lower or peer LSP level to the LSP level considered
-	swapped LSPs at a given LSP level
-	mismerged LSPs at a given LSP level	(where the offending LSP
traffic may or may not be affected, ie mis-direction or unintended
replication respectively)

Currently the draft does not address any of the above.

6	Of perhaps more minor note......the control-plane gets continuously
loaded with traffic-plane OAM traffic (it has to since defect detection must
be proactive, ie should not rely on user to complain).

Please see draft-harrison-mpls-oam-req-00.txt (problem defintion) and
draft-harrison-mpls-oam-00.txt (solution to problem definition) which take
all the above points into account.

regards, Neil