Subject: [mpls-tp] ITU-T Review of MPLS-TP OAM Requirements

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 8 Jan 2009 14:27:18 +0100

In attachment the ITU-T comments on the MPLS-TP OAM Requirements draft
(draft-ietf-mpls-tp-oam-requirements-00) that was liaised by IETF to
ITU-T for review.

These comments were collected during the last ITU-T SG15 plenary meeting
(1-12 December 2008) and via conference calls.

Italo (as Editor of G.8110.1)
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 08 Jan 2009 20:16:42 +0000

Italo,

I have only taken a quick look at the document you attached but I have some
high level comments

1)
"Comment: there is a need to define more detailed scenarios for
interoperability between MPLS-TP and IP/MPLS and derive from them more
detailed requirements for interoperability/interworking in the peer case.
We think the interoperability scenarios impact not only OAM but also all the
other functionalities (data plane, protection and control plane).
ITU-T Q12/15 will provide some scenarios by end of January in order to
assist the IETF with its on-going resolution of this comment."

Mention of interworking in the peer case concerns me (for the reasons Neil
has articulated in the past). I am not convinced there is much if any
requirement for general interworking in the peer case.  I am concerned
though that the scope of work that could be done here is large and I would
like a tight scope around such work to prevent it from attempting to "boil
the ocean".

2)
"Comment: there is a need to analyse also the scenarios for interoperability
(especially for peering) between an MPLS-TP PW and an Ethernet
point-to-point VLAN and derive more detailed requirements accordingly."

Ethernet services supported over PWs have been deployed in live networks for
some time now, what additional scenarios do you forsee for MPLS-TP PWs that
are not also applicable to MPLS PWs? Is it that you think there is a gap in
the current functionality or this is just a "sanity check"?

3)
"Question: should the qualification that the vendor-specific and
experimental OAM functions are disabled by default be recorded in a solution
draft (e.g. the G-ACH/GAL draft)?"

IMO these OAM functions should be disabled by default. IMO this is an
operator requirement and belongs in the OAM requirements.

More specific "rules" may be defined by specific solutions.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 8 Jan 2009 15:35:52 -0500

> like a tight scope around such work to prevent it from attempting to  

	I agree. The initial premise for this work was co-existence of MPLS-TP
interfaces on the same LSR with "classic" MPLS interfaces. There was no
mention of interworking. Going down that road is going to be quite  
complex
unless we go back and fold-in all of the new constructs and extensions  
that
are being proposed for MPLS-TP, in which case we basically get MPLSv2.0,
which again was not on the original list of goals for this work.

> the current functionality or this is just a "sanity check"?

	Agreed. Same reasons as above. If there is something wrong with
existing ethernet PWs, we should go back and work on them first.

> More specific "rules" may be defined by specific solutions.

	It is a general rule of thumb in RFCs to disable vendor-specific
or experimental extensions to protocols by default. Likely a simple  
line in
the GAH draft is all that is needed for the code point allocations that
states they "MUST be disabled by default." is all that is necessary.

	--Tom

---

From: David Ward <[email-masked]>
Date: Thu, 8 Jan 2009 19:17:47 -0600

Experimental work should be written up in an "Experimental" track  
draft/RFC because you want to learn from interoperable experiments and  
there needs to be some spec. Vendor specific is necessarily not  
interoperable, strictly limited in deployment and the codepoint needs  
to be specified.

-DWard

On Jan 8, 2009, at 2:35 PM, Thomas Nadeau wrote:

...snip...

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Jan 2009 09:37:15 +0100

Ben,

> Mention of interworking in the peer case concerns me
> (for the reasons Neil has articulated in the past).

Neil's articulations are not correct in my opinion as I have indicated
before. It is very well possible and required to have "G.805 layer network
interworking" (referred to as service interworking or peer to peer
interworking) between the MPLS PW layer network and the MPLS-TP Channel
layer network and between the ETH Channel layer network and the MPLS-TP
Channel layer network for p2p and p2mp transport entities (i.e. the
transport entities that are common in the ETH and MPLS-TP Channel layer
networks).

The MPLS PW and MPLS-TP and ETH Channel layers are the top-of-stack layer
networks in these packet transport networks. I fully agree with your/Neil
observations that interworking is required at the three planes
- data plane,
- control plane, 
- management plane
and that this implies in the data plane that interworking is required
between 
- adapted information
- OAM
- protection switching.

Interworking in each of these three planes can be addresses however
separately. As such it is possible and required in my opinion that the
interworking aspects in the data plane be addressed first; i.e. interworking
in this data plane is a precondition for interworking in control/management
planes).

> Ethernet services supported over PWs have been deployed in live
> networks for some time now, what additional scenarios do you forsee
> for MPLS-TP PWs that are not also applicable to MPLS PWs? 

Many broadband backhaul networks deploy ethernet subnetworks in the edge and
a signle domain MPLS/VPLS subnetwork in the core, with a single segment PW.
Monitoring of the UNI-to-UNI transport entity is typically performed using
Ethernet VLAN OAM for E-LINE, E-TREE and E-LAN services. The SS-PW is in
this case not part of a MPLS PW layer netowrk, but instead the SS-PW is an
ETH link connection and the PW label carries the VLAN priority, drop
eligible and vlan_identifier information in its TC and LBL fields. The layer
stack is either:

-----------------------------------
|   Customer ETH service layer    |
-----------------------------------
  | Network ETH service layer  |
  ------------------------------ SS-PW label
  |ETH Section|   |MPLS Tunnel |
  -------------   -------------- Tunnel label
  |  Eth Phy  |   |MPLS Section|
  -------------   --------------
     802.3        |  Eth PHY   |
                  --------------
                      802.3

or (with ETH tunnel layer):

-----------------------------------
|   Customer ETH service layer    |
-----------------------------------
  | Network ETH service layer  |
  ------------------------------ SS-PW label
  |ETH Tunnel |   |MPLS Tunnel |
  -------------   -------------- Tunnel label
  |ETH Section|   |MPLS Section|
  -------------   --------------
  |  Eth PHY  |   |  Eth PHY   |
  -------------   --------------
     802.3             802.3

The introduction of a multi-domain MPLS/VPLS (MPLS-TP/VPLS-TP) network
introduces the multi-segment MPLS-PW (and the MPLS-TP Channel). This also
introduces the MPLS-PW/MPLS-TP Channel layer network into the stack. There
are now two options to build this stack. 

Option 1: maintain Network ETH service layer to monitor UNI-to-UNI the
E-LINE, E-TREE and E-LAN services; add an additional MPLS MS-PW layer
network in the MPLS/VPLS domains.

-----------------------------------
|   Customer ETH service layer    |
-----------------------------------
  | Network ETH service layer  |
  ------------------------------
  |ETH Section|   | MPLS MS-PW |
  -------------   -------------- PW label
  | Eth PHY   |   |MPLS Tunnel |
  -------------   -------------- Tunnel label
     802.3        |MPLS Section|
                  --------------
                  |  Eth PHY   |
                  --------------
                      802.3

Option 2: maintain Network ETH service layer to monitor UNI-to-UNI only for
the E-TREE and E-LAN services; add an additional MPLS MS-PW layer network in
the MPLS/VPLS domains for the E-LINE and other X-LINE (e.g. TDM, ATM, FR,
...) services with G.805 layer network interworking between p2p VLAN and p2p
MS-PW transport entities.

Layer stack for E-LINE and other X-LINE (e.g. TDM) services:
-----------------------------------
| Customer E/X-LINE service layer |
-----------------------------------
  |ETH service |X| MPLS MS-PW  |
  ------------------------------ PW label
  |ETH Section|   |MPLS Tunnel |
  -------------   -------------- Tunnel label
  |   ETY     |   |MPLS Section|
  -------------   --------------
     802.3        |    ETY     |
                  --------------
                      802.3

For MPLS-TP the MPLS MS-PW is replaced by an MPLS-TP Channel layer in which
MPLS-TP OAM and protection switching is supported.

As illustrated in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/eth-mplstp-iw/intero
p-managm-multi-technology-ptn-00.ppt G.805 layer network interworking
between p2p ETH Channel and p2p MPLS-TP Channel (i.e. between p2p service
VLAN and MS-PW) can be straightforward in the dataplane, as the adapted
information in both layer networks has a strong commonality and can be
converted as such easily.

The alternative (option 1) introduces an additional layer in the stack in
the MPLS(-TP) part of the network. This additional (MS-PW/MPLS-TP Channel)
layer is neither a tunnel nor a service layer and as such just increases the
CAPEX and OPEX of the MPLS(-TP) solution.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: donderdag 8 januari 2009 21:17
To: BUSI ITALO
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] ITU-T Review of MPLS-TP OAM Requirements

Italo,

1)

2)

3)

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 09 Jan 2009 11:49:49 +0000

Maartin,

Thanks.  I was editor & significant contributor to Y.1401 "principle of
interworking" so understand the complexities involved in trying to peer
interworking technologies.

My concern is basically "where does it end?" there are hints in your email
towards peer interworking Ethernet not being sufficient but also other
services (such as TDM). Specifying all the types of peer interworking
relationships we could have would be huge task and why I requested that any
interworking work undertaken is tightly scoped.

My other concern is that MPLS-TP/PW-TP  diverge significantly from the base
case of being a profile of MPLS/PW.  In other words if something is
inadequate in a PW specification I would rather we went back and fixed the
PW specification than produced a new PW-TP spec that is divergent from the
original PW specification.  Your comments on Ethernet services suggest that
you and I agree that what you describe is not specific to MPLS-TP/PW-TP and
therefore IMO if works needs to be done it should be done to the base PW
specifications which PW-TP inherit from.

Ben

---

From: <[email-masked]>
Date: Fri, 9 Jan 2009 12:09:17 -0000

Thanks Ben...

who wrote 08 January 2009 20:17

<snipped>
> 1)
> "Comment: there is a need to define more detailed scenarios 
> for interoperability between MPLS-TP and IP/MPLS and derive 
> from them more detailed requirements for 
> interoperability/interworking in the peer case.
> We think the interoperability scenarios impact not only OAM 
> but also all the other functionalities (data plane, 
> protection and control plane).
> ITU-T Q12/15 will provide some scenarios by end of January in 
> order to assist the IETF with its on-going resolution of this 
> comment."
> 
> Mention of interworking in the peer case concerns me (for the 
> reasons Neil has articulated in the past). I am not convinced 
> there is much if any requirement for general interworking in 
> the peer case.  I am concerned though that the scope of work 
> that could be done here is large and I would like a tight 
> scope around such work to prevent it from attempting to "boil 
> the ocean".

I really want to nail this one once and for all.  So let me restate the
BT Group Strategy position on this topic of peer interworking so that it
is very clear:

We can prove conclusively that there is no technical case whatsoever for
interworking 2 layer network partitions as peers if the layer network
(in each partition) is not a top-of-stack layer network that supports a
suite of end-system to 1st layer network adaptation functions for
message/file/stream applications.  If this advice is ignored it will
just generate a whole raft of unnecessary work/cost that we are not
prepared to pay for.

Moreover:
-	if the 2 partitions are not even the same the mode then there
will be major functional mismatch in DP and CP (aside=> we never
interwork MP between different operating parties even when top-of-stack)
-	if the 2 partitions are the same mode there is still likely to
be a significant functional mismatch in DP and CP
-	if the 2 partition are the same mode/technology there is still
no need to interwork them if the mode/technology in question is not a
top-of-stack layer network

Now a key corollary of the last point is that in non top-of-stack layer
networks (so this includes MPLS, MPLS-TP, Ethernet (all spins), SDH,
PDH, OTN etc) there is no need even for E-NNIs and UNIs between
different parties.

Further:
-	MPLS and MPLS-TP will form different layer networks....this is
even more obvious from the fact folks might want to use different access
point addressing structurs in them (re Nurit's recent mail on
this)...and neither of them will be top-of-stack so no need to interwork
them anyway.
-	Although PBB and PBB-TE have identical traffic units and may use
identical addressing formats these are different layer networks because
they are different network modes (eg CP is NOT the same, and neither is
top-of stack anyway) and cannot therefore be interworked as peers
-	IPv4 and IPv6 are both top-of-stack layer networks BUT they will
not be interworked as peers due to having different addressing fomats
and traffic unit structures....HOWEVER, providing they share common
application adaptation function for message/file/stream (eg UDP/TCP/RTP)
these DP entities could be passed transparently across an interworking
function whilst the IP v4/v6 network functions are themselves terminated
at the interworking point.

I hope that is now both comprehensive and clear.

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Jan 2009 18:43:01 +0100

Ben,

As I indicated in my slides and email, there will indeed be more then one
mode in the ETH<=>MPLS-TP Channel layer interworking function.
 
There will effectively be three modes:
1) for E-LINE service without TYPE/SA/DA header insertion
   in UNI-N of Ethernet VLAN network
2) for LINE services which include an Emulated Circuit ID
   (e.g. TDM CES in MEF8), and insert a TYPE/SA/DA header in
   the UNI-N of the Ethernet VLAN network
3) for LINE services which use a native service circuit identifier
  (e.g. VCI, VPI), and insert a TYPE/SA/DA header in the UNI-N
   of the Ethernet VLAN network.

As the PW does not support LINE services without a native service circuit
identifier. As such the second mode is necessary and in Ethernet the service
VLAN should only support a single client (e.g. a single TDM signal per
VLAN).

Three modes is not too much to handle, especially as the processing
differences are very minor.

The adaptation represented by the PW does not require any change (i.e. no
divergence). So we do not have to go back. We only have to address our
current developments.

The potential complexity of such ETH<=>MPLS-TP interworking function would
be in the OAM interworking. As the MPLS-TP OAM is not yet designed, we can
make sure that the OAM interworking complexity is minimized (and possible
becomes trivial).

The OAM interowrking complexity would become trivial if we would reuse the
Ethernet OAM PDUs and equip it with an ACH or G-ACH instead (replacing the
TYPE/SA/DA OAM header used in Ethernet).

The big advantage we would obtain with this approach is not only a trivial
interworking, but more importantly the 
1) reuse of existing (proven) OAM circuit designs
2) preventing that UNI-N, I-NNI and E-NNI ports must support two channel
layer OAM sets (one for mp2mp/rmp VLANs (VPLS) and another one for p2p/p2mp
MS-PWs); with common OAM PDUs, one set of OAM processes can be used with two
different headers (one for mp2mp/rmp and the other one for p2p/p2mp).

The current approach for MPLS-TP OAM allocates the Ethernet OAM PDU's
Version and OpCode fields in the ACH/G-ACH. The impact of this deviation can
be minimized if we maintain the Version method of Ethernet and if we select
the LSB part of the Channel Type values the same as the OpCode values in
Ethernet. I.e. the interworking function then can simply copy the OpCode
into the Channel Type and vice versa. This minimizes the interworking
complexity.

Furthermore the Ethernet OAM PDU's MEL field is replaced by label stacking.
This requires a little bit more processing complexity, as the interworking
function must potentially perform deeper packet inspection to identify if a
frame is a TCM OAM frame and at what Ethernet MEG level it operates. 

I.e. the interworking function must count the number of TCM label stack
entry headers between the MS-PW label stack entry header and the ACH (by
checking the S-bits until and including the LSE with S=1). It must then look
up in a MEG level/TCM label stacking mapping table which MEL value has to be
inserted in the Ethernet OAM PDU. 
In the other direction, the value in the MEL field will be looked up in this
mapping table and the number of TCM label stack entry headers to be inserted
will be returned. 
The theoretical maximum is 7 TCM label stack entry headers, the practical
maximum is 3 TCM LSE headers.

The final item of difference is the fields in which the identifier of the
MEP or MIP is carried that must perform the loopback and that had issued the
request. In the Ethernet LBM/LBR frames these identifiers are carried in the
SA/DA fields (i.e. reuse of those fields). In MPLS-TP LBM/LBR OAM these
identifiers must be located inside the OAM PDU; i.e. in an additional TLV.
An example can be found in the T-MPLS LBM/LBR frame design and more recently
in the PBB-TE LBM/LBR frame design (i.e. the TESI has the same 'issue', and
the identifiers are carried inside a TLV).

Due to the presence of the ETH channel (service VLAN/VPLS) layer in parallel
to the MPLS-TP channel (MS-PW) layer, all I-NNI and E-NNI ports and all
Ethernet UNI-N ports will be equipped with physical subsystem EUI-48
identifiers, which are deployed as MAC address. MPLS-TP LBM/LBR OAM frames
can as such reuse those EUI-48 identifiers/MAC addresses to have seamless
interworking with the ETH MEP and ETH MIPs in the hybrid ETH/MPLS-TP channel
connection. 

The TDM UNI-N ports in an MPLS-TP node can also be equipped with EUI-48
identifiers to identify the physical subsystem on which those ports are
located. Those EUI-48 identifier values can then be used in the MPLS-TP
LBM/LBR frames to identify the MPLS-TP Channel MEP and optional MPLS-TP
channel TCM MEP functions on this interface port for the case of a hybrid
ETH/MPLS-TP channel layer connection supporting a TDM service.

As you can see, it does not require too much complexity to engineer a
seamless interoperability between Ethernet MPLS-TP channel layers that are
present in a multi-technology packet transport network (MT-PTN) if the
MPLS-TP OAM PDUs have a strong commonality with the Ethernet OAM PDUs.

Next step is to create the initial specification for this ETH<=>MPLS-TP_IW
function taking the above processing into account.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: vrijdag 9 januari 2009 12:50
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] ITU-T Review of MPLS-TP OAM Requirements

Maartin,

Ben

On 09/01/2009 08:37, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
> 
>> Mention of interworking in the peer case concerns me (for the reasons 
>> Neil has articulated in the past).
> 
> before. It is very well possible and required to have "G.805 layer 
> network interworking" (referred to as service interworking or peer to 
> peer
> interworking) between the MPLS PW layer network and the MPLS-TP 
> Channel layer network and between the ETH Channel layer network and 
> the MPLS-TP Channel layer network for p2p and p2mp transport entities 
> (i.e. the transport entities that are common in the ETH and MPLS-TP 
> Channel layer networks).
> 
> The MPLS PW and MPLS-TP and ETH Channel layers are the top-of-stack 
> layer networks in these packet transport networks. I fully agree with 
> your/Neil observations that interworking is required at the three 
> planes
> - data plane,
> - control plane,
> - management plane
> interworking aspects in the data plane be addressed first; i.e. 
> interworking in this data plane is a precondition for interworking in 
> control/management planes).
> 
> Many broadband backhaul networks deploy ethernet subnetworks in the 
> edge and a signle domain MPLS/VPLS subnetwork in the core, with a single
segment PW.
> Monitoring of the UNI-to-UNI transport entity is typically performed 
> using Ethernet VLAN OAM for E-LINE, E-TREE and E-LAN services. The 
> SS-PW is in this case not part of a MPLS PW layer netowrk, but instead 
> the SS-PW is an ETH link connection and the PW label carries the VLAN 
> priority, drop eligible and vlan_identifier information in its TC and 
> LBL fields. The layer stack is either:
> 
> introduces the multi-segment MPLS-PW (and the MPLS-TP Channel). This 
> also introduces the MPLS-PW/MPLS-TP Channel layer network into the 
> stack. There are now two options to build this stack.
> 
> Option 2: maintain Network ETH service layer to monitor UNI-to-UNI 
> only for the E-TREE and E-LAN services; add an additional MPLS MS-PW 
> layer network in the MPLS/VPLS domains for the E-LINE and other X-LINE 
> (e.g. TDM, ATM, FR,
> ...) services with G.805 layer network interworking between p2p VLAN 
> and p2p MS-PW transport entities.
> 
> For MPLS-TP the MPLS MS-PW is replaced by an MPLS-TP Channel layer in 
> which MPLS-TP OAM and protection switching is supported.
> 
> As illustrated in
> http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/eth-mplstp-iw/
> intero p-managm-multi-technology-ptn-00.ppt G.805 layer network 
> interworking between p2p ETH Channel and p2p MPLS-TP Channel (i.e. 
> between p2p service VLAN and MS-PW) can be straightforward in the 
> dataplane, as the adapted information in both layer networks has a 
> strong commonality and can be converted as such easily.
> 
> The alternative (option 1) introduces an additional layer in the stack 
> in the MPLS(-TP) part of the network. This additional (MS-PW/MPLS-TP 
> Channel) layer is neither a tunnel nor a service layer and as such 
> just increases the CAPEX and OPEX of the MPLS(-TP) solution.
> 
> Regards,
> Maarten
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ben Niven-Jenkins
> I have only taken a quick look at the document you attached but I have 
> some high level comments
> 
> 1)
> We think the interoperability scenarios impact not only OAM but also 
> all the other functionalities (data plane, protection and control plane).
> Mention of interworking in the peer case concerns me (for the reasons 
> Neil has articulated in the past). I am not convinced there is much if 
> any requirement for general interworking in the peer case.  I am 
> concerned though that the scope of work that could be done here is 
> large and I would like a tight scope around such work to prevent it 
> from attempting to "boil the ocean".
> 
> 2)
> "Comment: there is a need to analyse also the scenarios for 
> interoperability (especially for peering) between an MPLS-TP PW and an 
> Ethernet point-to-point VLAN and derive more detailed requirements
accordingly."
> for MPLS-TP PWs that are not also applicable to MPLS PWs? Is it that 
> you think there is a gap in the current functionality or this is just a
"sanity check"?
> experimental OAM functions are disabled by default be recorded in a 
> solution draft (e.g. the G-ACH/GAL draft)?"
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 09 Jan 2009 20:45:59 +0000

Maarten,

Thanks.

> mode in the ETH<=>MPLS-TP Channel layer interworking function.

I think this is getting to my point, you say we need 3 modes for
ETH<=>MPLS-TP, no doubt in time that will also expand to (for example)
TDM<=>MPLS-TP, ATM<=>MPLS-TP, FOO<=>MPLS-TP and so on hence my question
"where does it end". That is why I want any work on interworking that is
undertaken to be tightly scoped.

The other thing is that I don't see anything in what you write that is
specific to MPLS-TP.  If I understand correctly then you hold the view that
because MPLS-TP OAM may be different to MPLS OAM then that could make the
OAM interworking simpler, possibly (iff MPLS-TP OAM aligns with Ethernet
OAM) but then that is only for the Ethernet case.

I don't want new work to be labelled MPLS-TP because it is new.  IMO if it
applies equally to MPLS & MPLS-TP then it should be dealt with in the base
MPLS/PW specifications (where it can be naturally inherited by MPLS-TP).  If
it is something specific to MPLS-TP then it gets the MPLS-TP moniker.

Ben

---

From: <[email-masked]>
Date: Mon, 12 Jan 2009 10:21:20 -0000

I'll bite, against my better judgement, on this one....but I'll going to
leave the rest as I don't believe we have any basis for further
technical/logical discussion.

Maarten Vissers wrote to Ben 09 January 2009 08:37
> Neil's articulations are not correct in my opinion

NH=> I'm sorry Maarten, but they are simply technically accurate....I
suspect the real reason you don't like them is that they show why what
you keep proposing is not a good idea.  They are not 'my opinion'
either, as I am only working through a series of logical steps to arise
at my conclusions. 

> as I have 
> indicated before. It is very well possible
NH=> Many things are 'possible' Maarten but not all make
operational/commercial sense.  

> and required to 
> have "G.805 layer network interworking" (referred to as 
> service interworking or peer to peer
> interworking) between the MPLS PW layer network and the 
> MPLS-TP Channel layer network and between the ETH Channel 
> layer network and the MPLS-TP Channel layer network for p2p 
> and p2mp transport entities (i.e. the transport entities that 
> are common in the ETH and MPLS-TP Channel layer networks).

NH=> This is actually FUD.  I can prove that peer interworking between
non top-of-stack networks is NOT required (even if *same
mode/technology*, let alone the mayhem that would result if this were
not the case), whereas you can only assert, with no technical basis for
how this will be achieved across all DP/CP/MP facets, that 'this is
possible and *required*'.

I agree that lots of things are 'possible' but many of them are *not
required*.  They offer no advantage, but I can see the problems and
costs they will incur.  So I cannot agree with you on these
points....and AFAI can tell there does not seem to be anyone else
supporting your views either.  But let's ask again just to be sure: 'how
many folks support what Maarten is proposing?'.
 
> The MPLS PW and MPLS-TP and ETH Channel layers are the 
> top-of-stack layer networks in these packet transport 
> networks.

NH=> This observation is rather meaningless.  "Top-of-stack" means *no
higher layer networks* exist, that is, a top-of-stack layer network has
application adaptation functions for the suite of message/file/stream
(*external* to the network) applications.  IP is like this, PSTN is like
this, and some folks once upon a time had aspirations for ATM to be like
this (ie the AALs).  But outside this rather small list no other layer
network is top-of-stack.  And for sure SDH, PDH, Ethernet and
MPLS/MPLS/TP are not top-of-stack.  I can very easily prove there is no
technical basis (let alone commercial basis) for interworking as peer
non-top-of-stack layer networks.  

> I fully agree with your/Neil observations that 
> interworking is required at the three planes
> - data plane,
> - control plane,
NH=> yes....but we MUST be careful with what is exchanged and what can
be controlled in the CP.

> - management plane
NH=> I know this has been an aspiration for a long time (eg the NMS X
interfaces from way back), but in practice this simply does not
happen.....it carries far too much of a security risk.

But I would also add this is *only* for top-of-stack layer networks.
There is no need to consider these issues when this is not the case.

> and that this implies in the data plane that interworking is 
> required between
> - adapted information
> - OAM
> - protection switching.
NH=> No.  And the reason for this is your very first bullet here, ie
'adapted information'.  If the adapted information is another layer
network (which itself may or may not be top-of-stack) then it is this
(all 3 planes) AND ONLY THIS we pass transparently across and we fully
terminate the lower layer network technologies.

The only time we have to consider peer-interworking is when:
-	the mode/technology is top-of-stack and contains a full suite of
message/file/stream end-system application adaptation functions (ideally
the same for both peer partitions)

In this case we can justifiably consider peer interworking of the
technologies...and they normally go under the name of 'public service
networks'...of which the PSTN (64k co-cs) and Internet (IP cl-ps) are
the only 2 enduring examples.

In all other cases there is no need for interworking.  For example let's
consider building an IP layer network with N nodes.  I can arbitrarily
mesh these N nodes with link connections using various server layer
technologies, eg SDH VC4 on one link, PDH T3 on another link, Ethernet
on another link, MPLS/MPLS-TP on another link, etc. etc.  All these
lower layer technologies DO NOT get interworked in any
way/shape/form....their trail/flows are fully terminated at an IP
(higher layer) node and it is only the IP layer information that gets
passed across transparently.

So, the very simple rules are:
-	When a technology is NOT top-of-stack there is no requirement
for peer interworking with any other technology, BUT there is a
requirement for transparent C/S carriage of other technologies.
-	When a technology is top-of-stack it may peer interwork with
other technologies that are also top-of-stack.....HOWEVER, if the 2
technologies are not the same mode (and usually even they are the same
mode, cf ATM/FR) there will be a significant functional mistmatch across
all DP/CP facets (including the specification of the end-system
message/file/stream application adaptation functions).
-	When a single mode/technology is top-of-stack it may be easily
(horizontally) partitioned to create UNIs/E-NNIs between various parties
and peer interworked...and today the only examples of this are the
public service networks called the PSTN and the Internet.

> 
> Interworking in each of these three planes can be addresses 
> however separately. As such it is possible and required in my 
> opinion that the interworking aspects in the data plane be 
> addressed first; i.e. interworking in this data plane is a 
> precondition for interworking in control/management planes).

NH=> I totally disagree.  You MUST consider both the DP and CP
together....we don't usually interwork the MP.  And if the technology in
question does NOT possess end system application adaptation functions
(like IP does (all 3 cases) and PSTN does (only stream/voice case)) then
there is NO case for peer interworking PERIOD....this is a plain/stark
technical fact as I have briefly explained above.

I'm going to stop here as there is no point in any further discussion
until the above is clear to all and accepted as the basis for moving
forward.

Regards, Neil
<snipped to end>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 13 Jan 2009 15:52:04 +0100

Ben,

I am talking of a single "ETH<>MPLS-TP(X) InterWorking" function, which
includes three modes to support all defined clients (i.e. all types of "X").
There is no need to develop within the multi-technology PTN scope
interworking functions TDM<>MPLS-TP_IW, ATM<>MPLS-TP_IW, or FOO<>MPLS-TP_IW.
None of these TDM, ATM and FOO layer networks are network service/channel
layer netowrks in the PTN, so there is no need to interwork those.

Within the scope of the MPLS-TP OAM development, it has been indicated that
MPLS-TP will have to interwork with MPLS PW. As such you will need an MPLS
PW<>MPLS-TP(X)_IW function. The interworking of adapted information is
ofcourse trivial in this case as it is the same in both cases. The
interworking of MPLS PW OAM and MPLS-TP Channel OAM (includes MPLS-TP PW and
PW TCM (i.e. LSP) OAM) is thus the issue in the DP interworking.

My suggestion is to terminate the MPLS-TP PW TCM OAM at the IW function, as
this type of OAM is not supported in MPLS PW layer. The only OAM that can be
continued is PW NCM OAM, but here there is a large difference between the
OAM set in MPLS PW and in MPLS-TP PW. Simplest would be to require that the
MPLS-TP PW MEP supports both CCM and BFD, in which BFD is used when
interworking with a MPLS PW MEP; otherwise MPLS-TP CCM is used. Note that
the CCM PDU processing is already required for the VPLS (VLAN) functionality
sitting in parallel to the PW.

In theory it would be required to interwork ETH with MPLS PW, if one
endpoint of the service is in an Ethernet VLAN domain and the other endpoint
is in a MPLS domain (but this is outside the MPLS-TP scope). If there is no
layer network interworking between the two signals, then ETH layer network
will be the network service layer netowrk that is present between both UNI-N
ports. The MPLS PW layer is then obsolete; i.e. it is not a network service
layer and it is not a network tunnel layer. If it is neither of these two,
but sits in between these two layers, then it can be removed without loosing
anything necessary.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
Niven-Jenkins
Sent: vrijdag 9 januari 2009 21:46
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] ITU-T Review of MPLS-TP OAM Requirements

Maarten,

Thanks.

On 09/01/2009 17:43, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
> 
> As I indicated in my slides and email, there will indeed be more then 
> one mode in the ETH<=>MPLS-TP Channel layer interworking function.

Ben