planes Re: I-D Action:draft-nadeau-ccamp-gmpls-oam-requirements-02.txt

["tom.petch" <cfinss@dial.pipex.com>]

Now that this has been accepted as a WG I-D, I want to return to the point about
planes.

This I-D is an extension to RFC4377, which does a good job of teasing out the
extras needed for MPLS OAM - because a LSP is not quite like any other link or
path - and it does it with scarce a mention of planes..  The distinguishing
feature of GMPLS is the separation of control and data planes, different
topology, technology etc so perforce, this I-D will make reference to the data
and control planes.

But I think it then goes wrong in two ways.  One is the frequent reference to
management plane, something which RFC4377 avoids entirely and I think that this
I-D should do too.

The other is that first sentence, which used to refer to data plane
and now refers to control plane.  I think that neither term is right, that what
ought to be different about GMPLS is for the control plane and data plane to
stay in synch
so what ought to be different about GMPLS OAM is being able to compare the
operational state of the two and determine whether or not that is the case ie
the key feature is neither data plane nor control plane but the relationship
between the two.  You say that the data plane will already have its OAM - well,
so can the control plane.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Saturday, October 13, 2007 3:14 PM
Subject: Re: I-D Action:draft-nadeau-ccamp-gmpls-oam-requirements-02.txt


> Hi Tom,
>
>
> > Yes, I find this version clearer.
>
> Good. Thanks.
>
> > I was struck by two semantic changes, for which I am happy to leave any
> > discussion to when it is a WG I-D.  One is the change of the first
> > sentence from
> > 'This document describes requirements for data plane OAM for GMPLS'
> > to
> > 'This document describes requirements for control plane OAM for GMPLS'
> > which sounds quite a change.   In practice, this does not reflect a
> > dramatic
> > change of contents, but then again, I do not think either sentence gets it
> > quite
> > right.
>
> This tackled a comment from Don O'Connor.
>
> I think the essence of Don's point was that the techniques being described
> were not data plane OAM. In fact, while we may leverage data plane OAM, for
> most (all?) technologies with which we are dealing, the data plane OAM is
> already defined (stroke being defined) by other bodies or other working
> groups.
>
> We'd be happy to see another formulation of this text.
>
> > Second, I notice a much stronger emphasis on (SNMP) MIB modules; I presume
> > it is
> > too early to accommodate other forms, such as the nascent NETCONF.
>
> Ah. Hmm.
>
> As you say, NetConf is nascent. It would be a trifle premature to *require*
> NetConf conformance. In fact, the requirements would perhaps be a little
> more abstract (e.g., "standardised tools for operational management") if
> there wasn't also the general IETF "SHOULD" applied to the development of
> MIB modules for all protocols and protocol extensions.
>
> Cheers,
> Adrian