Subject: OAM Interworking [Was: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC]

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 10 Oct 2011 10:32:48 +0100

Huub sed:

> Section 6 focusses on the interworking between two toolsets
> 
> In transport networks we *never* have peer-2-peer OAM interworking.
> If it was required it would have explicitly been mentioned in
> the MPLS-TP requirements RFC.

Can I just ask for some clarification of this.

We have become accustomed to refer to various in-band protection mechanisms
(such as G.8031, etc.) as OAM. Although I can't say I am happy with this
description (I prefer "n-band control plane") I can see how there is a close
relationship with the OAM messages especially as far as triggers are concerned.

If we allow that these protection mechanisms are a form of OAM, then you will be
aware of the work in Question 9/15 on what is being called G.iwk. This is
examining the interworking of a variety of protection mechanisms at domain
boundaries.

So I suppose my questions are:

- Do you consider protection mechanisms part of OAM?
- Do you consider "peer OAM interworking" to be different from the
  work in G.iwk (and to some extent G.873.2)?

> Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B
> of G.8110.1 where it is documented how different toolsets can
> be deployed in a network without any issues.

Are you saying that "coexistence" is only about providing e2e services across
mixed networks? When you say that "Section 6 is totally irrelevant" are you
saying that there is no need to establish the various issues and concerns wrt
coexistence? You are (I assume!) not saying that draft-tsb-mpls-tp-ach-ptn is
totally irrelevant.

It certainly seems to me that Section 6 reaches many of the same conclusions for
e2e delivery of OAM as are found in draft-tsb-mpls-tp-ach-ptn: perhaps the main
difference is that this draft shows its workings.

Thanks,
Adrian