[PWE3] Thoughts on adoption of draft-zhang-mpls-tp-pw-oam-config-06

["Adrian Farrel" <[e-mail]>]

Hi,

<Speaking as individual contributor>

It seems to me very clear that the PWE3 working group has accepted the value of
the role of a control plane in configuring, establishing, activating, and
tearing down point-to-point pseudowires.

Let us be clear that a control is not a requirement for such pseudowires. It is
perfectly possible for "static" pseudowires to be established using the
management plane. In fact, if you judge on the grounds of scalability alone,
there is not a lot in favour of using the control plane. In the management plane
case, four messages flow tough the network (NMS to ingress and response, NMS to
egress and response). In the control plane case, four messages also flow (NMS to
ingress, ingress to egress and response, ingress response to NMS), but in this
case, although the traffic at the NMS is reduced, the ingress and egress must
also implement LDP. Furthermore, even in the case of the use of a control plane,
the ACs probably require manual configuration.

Nevertheless, we appreciate the use of a control plane for a number of reasons.
Not least is the automated cross-checking that we get to ensure that the ingress
and egress are not subject to misconfiguration. Also included is the
extensibility to multi-segment pseudowires with more significant scalability
benefits and dynamic location of S-PEs.

If people want to debate the value of a control plane for pseudowires, that is
OK with me. But I wish they would do it in the open and clearly, not by hiding
behind a discussion of OAM configuration.

Which brings us on the matter in hand. As Andy has pointed out, the (small) I-D
offers two functions:
- OAM capability advertisement to handle the new OAM tools from MPLS-TP.
- Configuration of those tools using the control plane.

It defeats me why these two functions are regarded as radically different from
any other element of data plane capability exchange or configuration that is
currently available in Targeted LDP for pseudowire establishment and control.

The detailed requirements for OAM configuration have been questioned. Maybe
these questions come from folk more used to the application of OAM as a
post-facto research tool than as an interactive trigger. Pseudowires are
increasingly being used to provide "wire emulation" (which should not be a
surprise" and need to offer similar services to those we have become used to in
circuit-switched environments. If you want to get a better handle on the
requirements, I suggest you read
http://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk/

FWIW, I have recently heard questions from the field about how to determine
whether a pseudowire is actually up, correctly connected, and ready to transmit
data. You will note that turning on OAM by hand is slow and requires
intervention. Turning on OAM automatically during provisioning will lead to
bogus alarms. Thus, the requirements seem pretty clear to me.

In summary, I support adoption of this work by the working group so long as
there is intention to include the function in at least one implementation.

Thanks,
Adrian