Subject: [mpls-tp] Carrying traffic over an MPLS-TP network

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Dec 2008 10:38:27 -0000

Hi,

There has been various discussion among the MPLS-TP I-D editors, and also 
among some of the delegates at the current ITU-T SG15 meeting in Geneva 
about how we carry traffic over an MPLS-TP network.

The question can be highlighted by how or if we carry IP/MPLS traffic over 
an MPLS-TP network.

Some data points for this discussion are:

1. What is the service provided by an MPLS-TP network?
Is it (as described in some documents) the provision of pseudowires over an 
MPLS transport network?
Or is it the provision of services (including pseudowires) over an MPLS 
transport network?

2. It there a need to provide demarcation between server traffic and client 
traffic?
There seem to be several reasons why one might do this:
a. architectural beauty
b. consistency with the answer to point 1
   (depending on the answer!)
c. ease of OAM and general management
  (so you can see the demarcation when you sniff the network)
d. To avoid accidental misforwarding of traffic
  For example, consider an MPLS-TP network operated using
  the management plane. In this network it is possible that an
  LSR along the path of an LSP is misconfigured to pop the
  MPLS-TP LSP top label. If what is found underneath is
  either a label from the client label space, or is treated as a label
  (in the case where the payload is IP) we will not spot an error,
  but may misforward traffic.

3. If there is demarcation as suggested in point 2, what is the best way to 
provide demarcation?
a. Encode as a PW with the end of stack set and a PW header according to the 
appropriate PW encoding type.
b. Simply use the end of stack bit to say that we have reached the bottom of 
the MPLS-TP label stack.
(The alternative clearly being that the label stack runs through from the 
client label stack to the server label stack.)

Opinions are needed!

Cheers,
Adrian 

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 11 Dec 2008 16:01:06 +0100

Hi Adrian,
          w.r.t. the argument in your e-mail I'd like to solicit comments on 

http://www.ietf.org/internet-drafts/draft-martinotti-mpls-tp-interworking-00.txt

purpose of the ID is to highlight the scenarios about ip/mpls and mpls-tp interworking.

The draft is in 00 version so not all the points raised in your e-mail are covered nevertheless I think (I have also to say that I'm a co-author) could be seen as a good start.

Best Regards

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: giovedì 11 dicembre 2008 11.38
> To: [email-masked]
> Subject: [mpls-tp] Carrying traffic over an MPLS-TP network
> 
> Hi,
>

---

From: "Maarten Vissers" <[email-masked]>
Date: Thu, 11 Dec 2008 18:10:52 +0100

Adrian,

The first question to answer is what the layer stack is of a MPLS-TP
network, what domains are present and which service types are to be support
(p2p, p2mp, rmp, mp2mp). This is the starting point for specification of any
transport network (packet and circuit), and the operation of such network.

The following document provides a description of a packet transport network
architecture together with its equipment and interface types that is based
on the use of Ethernet VLAN frames. The architecture of the packet transport
netowrk will not change when another frame format is used; i.e. when the
MPLS-TP frame format is used.
http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q9/2008-12-Geneva/eth-vlan-equi
pment-types-and-characteristics-03c.doc 

The MPLS-TP network will have to support the same set of services as the
Ethernet VLAN equivalent network; i.e.
- point-to-point services
- point-to-multipoint (distribution) services
- rooted-multipoint services
- multipoint-to-multipoint services.

The MPLS-TP network will support those services with MPLS and Ethernet VLAN
technologies. The latter referred to as VPLS-TP.

The MPLS/VPLS-TP layer stack will be consisting of the following layer
networks:
- ETH Channel 
- MPLS-TP Channel
- MPLS-TP Path
- MPLS-TP Section
- Physical Media
in which the channel layers are a client layer of the path layer (and
optionally also a client of the section layer on access links), in which the
path layer is a client of the section layer, and in which the section layer
is a client of the physical media layer.

I am using the terms Channel, Path and Section to allow for a separate
discussion on the frame formats, specifically around the PW entity. I have
the impression that: 
- the SS-PW emulates an Ethernet MAC flow (identified by its DA,SA pair)
within a rooted-multipoint VLAN and that the set of LSPs carrying those
SS-PWs emulate the rooted-multipoint VLAN itself; i.e. PW label <=> DA,SA
and LSP label <=> VID. In other terms, the LSP (and not the PW) is the
connection in the MPLS-TP Channel layer. The application is the L3
aggegration, e.g. DSLAMs to service edge router, or base stations to MSC.
- the MS-PW however is a different story. This MS-PW is used to support e.g.
business services. The MS-PW is the connection in the MPLS-TP Channel layer.

True rooted-multipoint and multipoint-to-multipoint services are supported
by the ETH Channel layer in the same way as described in the above mentioned
document. The difference with the description in the above document is that
the ETH Path layer with its tunnel VLANs is in MPLS-TP replaced by the
MPLS-TP Path layer.

The MPLS-TP network, like any other transport network is build up under
control of network planning. That means that MPLS-TP equipment is installed
and interconnected on the basis of planning. Fibers get interconnected and
the connectivity get tested via the MPLS-TP Section monitoring. Then MPLS-TP
Path links become available and it is possible to set up MPLS-TP path layer
connections (tunnels) under control of network planning. Now the MPLS-TP
network is ready to accept services. Every service requests results in the
set up of either a p2p or p2mp MPLS-TP channel layer connection, or a rmp or
mp2mp ETH channel layer "connection" (formally referred to in G.8010 as
"flow domain fragment"). 

In this way it is not possible to mix up path layer and channel layer
connections, as those connections are set up at different times and under
different control (customer service request versus network planning
request). I.e. not need to add any aritificial demarcation in the label
stack.

To help the management/operation of the MPLS-TP network, we will specify the
typical functionality of I-NNI, E-NNI and UNI-N ports in MPLS-TP equipment
using functional models; you find Ethernet VLAN equivalent examples in the
above document. It is an editorial activity to create MPLS-TP versions of
those interface ports and I plan to do this once it is clear to me that this
would not be considered a controversial action. I intent to use "MT" as
acronym in the MPLS-TP atomic functions... This "MT" will then replace the
"ETH" in the green ETH path and blue ETH section layer atomic functions,
making those MPLS-TP path and section layer functions.

The yellow "ETH" atomic functions will be kept in MPLS-TP to support the rmp
and mp2mp services. These yellow "ETH" atomic functions will be complemented
by yellow "MT" atomic functions to support the p2p and p2mp services.

This is a slight complication with respect to the Ethernet VLAN case. I.e.
MPLS-TP equipment must support at every channel layer connection point, both
ETH and MT channel layer atomic functions. This will not introduce too much
complexity when the MPLS-TP OAM is a copy of the ETH OAM. But when the
MPLS-TP OAM PDUs are very different from the ETH OAM PDUs, then MPLS-TP
channel layer terminating and switching equipment must support two sets of
MEPs and MIPs; one for ETH and another one for MT. This latter will
complicate devices a lot.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: donderdag 11 december 2008 11:38
To: [email-masked]
Subject: [mpls-tp] Carrying traffic over an MPLS-TP network

Hi,

  (so you can see the demarcation when you sniff the network) d. To avoid
accidental misforwarding of traffic

Opinions are needed!

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Dec 2008 21:16:30 -0000

Maarten,

> (p2p, p2mp, rmp, mp2mp).

AFAIK, only p2p and p2mp are in scope.

> This is the starting point for specification of any

I suspect a transport network is a layer network. It is agnostic to the 
client layers and the server layers.

It *might* be interesting to consider whether the adaptation functions 
belong to the client or server layer.

> pment-types-and-characteristics-03c.doc

I am probably too simple for this document.
I find it heavily Ethernet-centric and not trivial to convert into a generic 
packet-based view. I also find the level of detail makes the document 
unreadable.
Sorry.

> - multipoint-to-multipoint services.

I am not sure that rmp and mp2mp services are in scope for MPLS-TP.
I am certain that mp2mp connections are out of scope.

> technologies. The latter referred to as VPLS-TP.

This sounds like an assertion.
There is no reason why EVLAN must be used to support these services.

If EVLAN is used, it is surely out of scope for the MPLS-TP network. It is a 
function that exists in a different layer, and is simply none of our 
business. We are building a transport network.

> is a client of the physical media layer.

Far too many assertions here.

> discussion on the frame formats, specifically around the PW entity.

Whatever.
I think it is fine if you want to take this to the architectural extremes, 
but maybe it is better to let the rest of us get on and solve the problems.

> I have the impression that:

Well, that is very unhelpful!
If we architect this, we should hope to see the PW in the same place in the 
architecutre regardless of how the transport network is used. After all, the 
network does not know how it is being used.
I don't see any reason why the PW is not the channel connection and the LSP 
the path connection.

> the ETH Path layer with its tunnel VLANs is in MPLS-TP replaced by the

How you provide services in a client layer may be interesting to mny people, 
but it is not in scope for the MPLS-TP work.

> control of network planning.

Depends what you mean by "build up", "control", and "network planning."

> That means that MPLS-TP equipment is installed
> and interconnected on the basis of planning.

Installed and physically interconnected - yes.
Logically interconnected - that depends on policy.

> Fibers get interconnected and
> the connectivity get tested via the MPLS-TP Section monitoring.

I think that this stretches the meaning of MPLS-TP Section monitoring beyond 
reasonable limits.
The testing may be done in the server layer without reference to MPLS-TP.

> Then MPLS-TP

Maarten,
I don't really have any more spare bandwidth to go through this.

Adrian

---

From: <[email-masked]>
Date: Sun, 14 Dec 2008 21:46:28 -0000

Adrian...you are essentially correct in all you say....few additional
remarks in-line: 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 14 December 2008 21:17
> To: Maarten Vissers; [email-masked]
> Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network
> 
> Maarten,
> 
> > network, what domains are present and which service types are to be 
> > support (p2p, p2mp, rmp, mp2mp).
> 
NH=> Correct.

> transport network 
> > (packet and circuit), and the operation of such network.
> 
> I suspect a transport network is a layer network. It is 
> agnostic to the client layers and the server layers.
NH=> Absolutely.....any layer network that is *not* top-of-stack should
(though I would say must) be transparent (at a binary level) to its
higher layer network client(s)...also see the post I just sent prior to
this one.

> 
> It *might* be interesting to consider whether the adaptation 
> functions belong to the client or server layer.
NH=> When not top-of-stack the adaptation required is a function of both
client mode/technology and server mode/technology.  Since there are 3
generic network modes there are in principle 9 client/server
adaptations....and although quite a bit can be made common not all
functions are relevant.  For example, when the server is co-cs and the
client is cl-ps or co-ps we have to consider whether the client traffic
units are self-delineating or not in the server payload, and here we
must always provide rate decoupling and idle fill functions....these
latter points are not relevant to a cl-ps or co-ps server layer network.

The adaptation function therefore sits logically between the client and
server, but physically it resides in the server. 

> 
> > The following document provides a description of a packet transport 
> > network architecture together with its equipment and 
> interface types 
> > that is based on the use of Ethernet VLAN frames. The 
> architecture of 
> > the packet transport netowrk will not change when another 
> frame format 
> > is used; i.e. when the MPLS-TP frame format is used.
> > 
> http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q9/2008-12-Geneva/eth-vla
> > n-equi pment-types-and-characteristics-03c.doc
> 
> I find it heavily Ethernet-centric and not trivial to convert 
> into a generic packet-based view. I also find the level of 
> detail makes the document unreadable.
> Sorry.
> 
> > The MPLS-TP network will have to support the same set of 
> services as 
> > the Ethernet VLAN equivalent network; i.e.
NH=> You are dead right they are not.  The ONLY constructs which are
relevant are p2p and p2mp, as these are the only constructs for which
one can control resource assignment...and this is a critical issue in
any network claiming to provide a transport role.  We call such (single
source) constructs 'connections'.

> I am certain that mp2mp connections are out of scope.
NH=> Correct.

> 
> > The MPLS-TP network will support those services with MPLS 
> and Ethernet 
> > VLAN technologies. The latter referred to as VPLS-TP.
> 
NH=> Agreed.

> 
> If EVLAN is used, it is surely out of scope for the MPLS-TP 
> network. It is a function that exists in a different layer, 
> and is simply none of our business. We are building a 
> transport network.
NH=> Agreed.

> > optionally also a client of the section layer on access links), in 
> > which the path layer is a client of the section layer, and in which 
> > the section layer is a client of the physical media layer.
> 
> I think it is fine if you want to take this to the 
> architectural extremes, but maybe it is better to let the 
> rest of us get on and solve the problems.
NH=> I agree.

> > - the SS-PW emulates an Ethernet MAC flow (identified by its DA,SA 
> > pair) within a rooted-multipoint VLAN and that the set of LSPs 
> > carrying those SS-PWs emulate the rooted-multipoint VLAN 
> itself; i.e. 
> > PW label <=> DA,SA and LSP label <=> VID. In other terms, 
> the LSP (and 
> > not the PW) is the connection in the MPLS-TP Channel layer. The 
> > application is the L3 aggegration, e.g. DSLAMs to service 
> edge router, or base stations to MSC.
> > business services. The MS-PW is the connection in the 
> MPLS-TP Channel 
> > layer.
> 
> If we architect this, we should hope to see the PW in the 
> same place in the architecutre regardless of how the 
> transport network is used. After all, the network does not 
> know how it is being used.
> I don't see any reason why the PW is not the channel 
> connection and the LSP the path connection.
NH=> To be brutally honest/accurate here, if folks propely understand
the full ramifications of MPLS-TP then the notion of 'PWs' is actually
redundant to the MPLS-TP transport role.  I may try and post something
in next few days to properly explain what I am meaning here.

> 
> > True rooted-multipoint and multipoint-to-multipoint services are 
> > supported by the ETH Channel layer in the same way as 
> described in the 
> > above mentioned document. The difference with the 
> description in the 
> > above document is that the ETH Path layer with its tunnel 
> VLANs is in 
> > MPLS-TP replaced by the MPLS-TP Path layer.
> 
> How you provide services in a client layer may be interesting 
> to mny people, but it is not in scope for the MPLS-TP work.
> 
> > The MPLS-TP network, like any other transport network is build up 
> > under control of network planning.
> 
> > That means that MPLS-TP equipment is installed and 
> interconnected on 
> > the basis of planning.
> 
> I think that this stretches the meaning of MPLS-TP Section 
> monitoring beyond reasonable limits.
> > Path links become available and it is possible to set up 
> MPLS-TP path 
> > layer connections (tunnels) under control of network 
> planning. Now the 
> > MPLS-TP network is ready to accept services. Every service requests 
> > results in the set up of either a p2p or p2mp MPLS-TP channel layer 
> > connection, or a rmp or mp2mp ETH channel layer 
> "connection" (formally 
> > referred to in G.8010 as "flow domain fragment").
> >
> > connections, as those connections are set up at different times and 
> > under different control (customer service request versus network 
> > planning request). I.e. not need to add any aritificial 
> demarcation in 
> > the label stack.
> >
> > To help the management/operation of the MPLS-TP network, we will 
> > specify the typical functionality of I-NNI, E-NNI and UNI-N 
> ports in 
> > MPLS-TP equipment using functional models; you find Ethernet VLAN 
> > equivalent examples in the above document. It is an 
> editorial activity 
> > to create MPLS-TP versions of those interface ports and I 
> plan to do 
> > this once it is clear to me that this would not be considered a 
> > controversial action. I intent to use "MT" as acronym in 
> the MPLS-TP 
> > atomic functions... This "MT" will then replace the "ETH" 
> in the green 
> > ETH path and blue ETH section layer atomic functions, making those 
> > MPLS-TP path and section layer functions.
> >
> > The yellow "ETH" atomic functions will be kept in MPLS-TP 
> to support 
> > the rmp and mp2mp services. These yellow "ETH" atomic 
> functions will 
> > be complemented by yellow "MT" atomic functions to support 
> the p2p and 
> > p2mp services.
> >
> > MPLS-TP equipment must support at every channel layer connection 
> > point, both ETH and MT channel layer atomic functions. This 
> will not 
> > introduce too much complexity when the MPLS-TP OAM is a copy of the 
> > ETH OAM. But when the MPLS-TP OAM PDUs are very different 
> from the ETH 
> > OAM PDUs, then MPLS-TP channel layer terminating and switching 
> > equipment must support two sets of MEPs and MIPs; one for ETH and 
> > another one for MT. This latter will complicate devices a lot.
> 
> Maarten,
NH=> I agree....and I would strongly caution that before folks get too
carried away with lots of nested MIPs/MEPs they have a very clear view
of how these get dynamically configured across failure
restoration/prot-sw events....as the ONLY points that remain invariant
across such routing changes in a network are the end (trail (co) or flow
(cl) termination) points.  The golden rule with defect
detection/handling OAM is to keep it as simple/sparse as possible as it
must be considerably more reliable than the network it is
montoring...and that means removing as much config as possible.

Also note that the OAM required for each of the 3 network modes is not
the same...though I see some folks trying to push a generic model
here....however this is just plain wrong.  I can provide examples if
need to explain why this is true.

regards, neil
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Adrian Farrel
> > There has been various discussion among the MPLS-TP I-D 
> editors, and 
> > also among some of the delegates at the current ITU-T SG15 
> meeting in 
> > Geneva about how we carry traffic over an MPLS-TP network.
> >
> > The question can be highlighted by how or if we carry 
> IP/MPLS traffic 
> > over an MPLS-TP network.
> >
> > Is it (as described in some documents) the provision of pseudowires 
> > over an MPLS transport network?
> > Or is it the provision of services (including pseudowires) over an 
> > MPLS transport network?
> >
> > 2. It there a need to provide demarcation between server 
> traffic and 
> > client traffic?
> >  (so you can see the demarcation when you sniff the network) d. To 
> > avoid accidental misforwarding of traffic  For example, consider an 
> > MPLS-TP network operated using  the management plane. In 
> this network 
> > it is possible that an  LSR along the path of an LSP is 
> misconfigured 
> > to pop the  MPLS-TP LSP top label. If what is found underneath is  
> > (in the case where the payload is IP) we will not spot an 
> error,  but 
> > may misforward traffic.
> >
> > 3. If there is demarcation as suggested in point 2, what is 
> the best 
> > way to provide demarcation?
> > a. Encode as a PW with the end of stack set and a PW header 
> according 
> > to the appropriate PW encoding type.
> > b. Simply use the end of stack bit to say that we have reached the 
> > bottom of the MPLS-TP label stack.
> > (The alternative clearly being that the label stack runs 
> through from 
> > the client label stack to the server label stack.)
> >
> > Opinions are needed!
> >
> > Cheers,
> > Adrian
> >
> >

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 15 Dec 2008 11:36:17 +0100

Adrian,

> AFAIK, only p2p and p2mp are in scope.

A packet transport network (PTN) must support p2p, p2mp, rmp and mp2mp
services. 

An Ethernet VLAN based PTN supports all those services without any problems.
An MPLS-TP based PTN must also support **all** those services. MPLS-TP can
support the rmp and mp2mp services either by introducing a MPLS-TP transport
entity with a connectionless forwarding mode (e.g. by introducting a Pseudo
LAN (PLAN)), or by using the Ethernet VLAN. The latter alternative is the
commonly used approach. As a consequence, the ETH Channel layer is part of
the MPLS-TP based PTN layer stack and needs to be fully taken into account
when developing the MPLS-TP based PTN specifications (including equipment
and network management specifications).

The Ethernet VLANs within this ETH Chanel layer use an MPLS Label Stack
Entry header as VLAN Tag when the VLAN signal is multiplexed into an MPLS-TP
Path or MPLS-TP Section layer connection. This label stack entry header
carries the 802.1Q specified EM_UNITDATA.indication/request vlan_identifier,
priority and drop_eligible parameters; the vlan_identifier is carried inside
the 20-bit label field and the priority and drop_eligible parameter values
are carried inside the EXP field. From the Ethernet VLAN (ETH) layer this
label stack entry header provides a "MPLS based VLAN TAG" ("M-Tag") with a
20-bit "M-VLAN ID" and a 3-bit "M-VLAN PCP".

In an MPLS-TP Channel layer terminating and/or switching equipment we will
find MT Channel MEP and ETH Channel MEP functions sitting next to each other
as well as MT Channel MIP and ETH Channel MIP functions. A channel label
with value X (e.g. X=1000) can be identifying either a MT Channel
connection, or an ETH Channel flow domain fragment. In the former case,
MPLS-TP OAM must be processed (MT MEP or MT MIP). In the latter case ETH OAM
must be processed (ETH MEP or ETH MIP).

A MPLS-TP based PTN will thus use 
- MPLS-TP channel MEP and MIP functions and MPLS-TP OAM to monitor its p2p
and p2mp services, and 
- G.8021 ETH channel MEP and MIP functions and Y.1731 ETH OAM to monitor its
rmp and mp2mp services.

If the MPLS-TP functions and OAM mechanisms deviate too much from the ETH
functions and OAM mechanisms, then the equipment and management of the
MPLS-TP based PTN will be more complicated then necessary. During the
development of the T-MPLS specifications in ITU-T this co-existence has been
fully recognized and resulted in strong alignment between the atomic
functions and OAM of both technologies to minimize equipment and network
management complexities.

I hope that the MPLS-TP developments will also recognize this co-existence
and result in strong alignment between the atomic functions and OAM of both
technologies to minimize MPLS-TP equipment and network management
complexities.

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: zondag 14 december 2008 22:17
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network

Maarten,

> This is the starting point for specification of any transport network 

> network architecture together with its equipment and interface types 
> that is based on the use of Ethernet VLAN frames. The architecture of 
> the packet transport netowrk will not change when another frame format 

> The MPLS-TP network will have to support the same set of services as 

> The MPLS-TP network will support those services with MPLS and Ethernet 

Whatever.

> carrying those SS-PWs emulate the rooted-multipoint VLAN itself; i.e. 
> PW label <=> DA,SA and LSP label <=> VID. In other terms, the LSP (and 
> application is the L3 aggegration, e.g. DSLAMs to service edge router, or
base stations to MSC.

> supported by the ETH Channel layer in the same way as described in the 
> above mentioned document. The difference with the description in the 
> above document is that the ETH Path layer with its tunnel VLANs is in 

> That means that MPLS-TP equipment is installed and interconnected on 
> the basis of planning.

> Then MPLS-TP
> Path links become available and it is possible to set up MPLS-TP path 
> layer connections (tunnels) under control of network planning. Now the 
> connection, or a rmp or mp2mp ETH channel layer "connection" (formally 
> planning request). I.e. not need to add any aritificial demarcation in 
> the label stack.
>
> specify the typical functionality of I-NNI, E-NNI and UNI-N ports in 
> equivalent examples in the above document. It is an editorial activity 
> to create MPLS-TP versions of those interface ports and I plan to do 
> controversial action. I intent to use "MT" as acronym in the MPLS-TP 
> atomic functions... This "MT" will then replace the "ETH" in the green 
> The yellow "ETH" atomic functions will be kept in MPLS-TP to support 
> the rmp and mp2mp services. These yellow "ETH" atomic functions will 
> be complemented by yellow "MT" atomic functions to support the p2p and 
> p2mp services.
>
> point, both ETH and MT channel layer atomic functions. This will not 
> ETH OAM. But when the MPLS-TP OAM PDUs are very different from the ETH 

Maarten,

Adrian

> There has been various discussion among the MPLS-TP I-D editors, and 
> also among some of the delegates at the current ITU-T SG15 meeting in 
> The question can be highlighted by how or if we carry IP/MPLS traffic 
> over an MPLS-TP network.
>
> 2. It there a need to provide demarcation between server traffic and 
> client traffic?
> MPLS-TP network operated using  the management plane. In this network 
> it is possible that an  LSR along the path of an LSP is misconfigured 
> (in the case where the payload is IP) we will not spot an error,  but 
> may misforward traffic.
>
> 3. If there is demarcation as suggested in point 2, what is the best 
> a. Encode as a PW with the end of stack set and a PW header according 
> (The alternative clearly being that the label stack runs through from

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 11:41:13 -0000

There is a dangerous and misleading assertion in this...snipped to key
point:

Maarten Vissers wrote 15 December 2008 10:36

> If the MPLS-TP functions and OAM mechanisms deviate too much 
> from the ETH functions and OAM mechanisms, then the equipment 
> and management of the MPLS-TP based PTN will be more 
> complicated then necessary. During the development of the 
> T-MPLS specifications in ITU-T this co-existence has been 
> fully recognized and resulted in strong alignment between the 
> atomic functions and OAM of both technologies to minimize 
> equipment and network management complexities.
> 
> I hope that the MPLS-TP developments will also recognize this 
> co-existence and result in strong alignment between the 
> atomic functions and OAM of both technologies to minimize 
> MPLS-TP equipment and network management complexities.

As a general observation it makes huge sense for the functional
components (and this is way more than just DP OAM) of technologies that
belong to the *same* network mode to migrate to the same optimised
functional components.  Indeed, as an industry we have been very poor at
achieving this and each technology has largely had a new set of
components defined for it.  However, it makes no sense to try and make
all modes 'look alike'....they can't for a whole raft of reasons, and
it's why the 3 network modes are so enduring (G.800 explains why this is
technically, from information theory considerations of how the labelling
of space/freq/time resource partitioning works).

So, to take a concrete example the OAM of a cl-ps mode network should
not try and be the same as the OAM of a co-cs or co-ps mode network.
See my recent to post to Sasha which contains one example to support
this observation.  And of course a cl-ps mode network does not have
connections (by definition) and this makes its functional specification
very different to a co-cs or co-ps mode layer network....a signalling
component is an obvious difference.....and further in the co-cs mode
this is forced to run logically OOB in an adjunct layer network whereas
this is not forced (but is desirable) in the co-ps mode.

And just to be really clear wrt to my views on OAM here I am NOT sure at
all that ITU and even IEEE have done a great job on OAM for
Ethernet.....though IEEE did at least have the very good sense to throw
out AIS which is a completely useless concept for a cl-ps mode layer
network.  My personal view is that the OAM that has been specified for
Ethernet is over-complex.....though if I had to home-in on one specific
aspect it would have to be nested TCM levels, I and most of my
collegaues here in BT don't think these are that useful (go check how
much of this old idea has been deployed in operators networks, even
where it could be argued it is most relevant, ie long-holding co-cs mode
networks).

As a minimum, folks really need to be clear just how such nested OAM
levels get dynamically configured across routing changes (ie
restoration/prot-sw) as only the end-points remain invariant across such
changes.  My view is that the OAM required needs to be as simple/sparse
as possible for the mode considered as it needs to be considerably more
reliable than the network it is monitoring....so all unecessary config
actions needs to be removed and those that are left automated as much as
possible (eg activating/deactivating OAM in sync with signalling
connection set-up/tear-down for **co** mode networks).  I can tell you
for a fact that Operations folks will turn as much unecessary OAM off as
they can....it has a processing/collection cost as well as a potential
unreliability factor.

Before closing I want to make one final and very important point here.
There is an assumption made by some people that (i) 'peer interworking'
of different modes/technologies is a good idea and that (ii) we need
UNIs/NNIs in all cases.  Both these assumptions are terribly flawed.

I can prove technically and very easily that:
-	it is a complete nonsense to try and interwork technologies that
belong to different network modes
-	unless there is very close functional alignment across *all* DP
and CP components (ie which is far more than OAM!) of technologies that
belong to the *same* network mode then peer interworking will be a
nightmare
-	unless one is dealing with a top-of-stack layer network (and the
critical observation here is that the layer network we are dealing with
has a suite of message/file/stream end-system adaptation functions...not
all have, including Ethernet and MPLS/MPLS-TP note very carefully) then
there is *no* technical requirement at all for NNIs.  

This latter point may not be immediately obvious to everyone, but let me
assure you it is a fact that can be easily proved.

So when we get around to specifying MPLS-TP let us please not load it up
with unecessary complexity, and let's try and stick with the real
operational requirements *and* try and use the important findings from
the work on unified modelling in G.800 as our guide.

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 15 Dec 2008 16:20:00 +0100

Neil,

There is no misleading assertion in my writing. Our OAM is used to monitor
Transport Entities. In Ethernet the VLAN is a Transport Entity and the
Y.1731 Ethernet OAM is used to monitor this Ethernet Transport Entity (i.e.
VLAN).

There are three types of Transport Entities:
1) transport entities in which traffic units are forwarded unconditionally
(i.e. broadcast) 
2) transport entities in which traffic units are by default broadcast, but
may have optional filtering applied
3) transport entities in which traffic units are forwarded on the basis of
configured forwarding rules; there is no default braodcast rule in this
case.

Examples of the first transport entities are the well known p2p and p2mp
connections in PDH, SDH, ATM, OTN.
Examples of the second transport entities are the well known p2p, p2mp, rmp
and mp2mp VLANs in Ethernet. For the p2p and p2mp VLANs there are no
filtering rules registered; i.e. just the default broadcast (flooding) is
present.
Example of the third transport entity is the IP VPN and the internet.

All those transport entity types are managed in the same manner in a
transport network, including their set up, monitoring, protection and fault
management.

I am summarizing those three transport entity types often by their internal
forwarding method as:
1) connection-oriented (CO) transport entity
2) connection-oriented plus connectionless (CO/CL) transport entity
3) connectionless (CL) transport entity.

OAM designed for a CO/CL transport entity is largerly the same OAM as the
OAM for a CO transport entity. 
- The CO/CL transport entity OAM set includes essentially one additional OAM
PDU; i.e. the link trace OAM PDU which allows to check the presence of a
filtering rule in the Ethernet Transport Entities (i.e. VLANs).
- The other difference between the two OAM sets is the field in the Loopback
OAM PDUs in which the MIP and MEP identifier is carried; in CO transport
entity OAM this field is located inside the LBM OAM PDU, in CO/CL transport
entity OAM this field is the DA field.

You will notice this equivalence when you compare Y.1731 with the
specifications in the latest draft version of G.8114 that was not consented.

Interworking between p2p and p2mp Ethernet and MPLS-TP transport entities is
possible and should be supported in a multi-technology packet transport
network that includes Ethernet VLAN based PTN domains and MPLS-TP based PTN
domains. This interworking capability creates hybrid Ethernet VLAN/MPLS-TP
p2p and p2mp channel layer connections. The former T-MPLS OAM and linear
protection switching specifications were designed to support such hybrid
channel layer connections.

In MPLS-TP, this implies that e.g. a p2p Ethernet Service VLAN will be
continued as a p2p MPLS-TP PW. If the MPLS-TP OAM and protection switching
are look and feel alike with the Ethernet OAM and protection switching, then
the interworking function (ETH/MT_IW) will be very simple and mainly has to
replace a VLAN Tag with a label stack entry header for Ethernet services.
When the MPLS-TP OAM and protection switching are not look and feel alike,
then the interworking function will be very complex. Interworking for the
case that a TDM service is provided requires also the removal/insertion of
DA/SA/TYPE fields, again a simple task.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 15 december 2008 12:41
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

> If the MPLS-TP functions and OAM mechanisms deviate too much from the 
> ETH functions and OAM mechanisms, then the equipment and management of 
> the MPLS-TP based PTN will be more complicated then necessary. During 
> the development of the T-MPLS specifications in ITU-T this 
> co-existence has been fully recognized and resulted in strong 
> alignment between the atomic functions and OAM of both technologies to 
> minimize equipment and network management complexities.
> 
> co-existence and result in strong alignment between the atomic 
> functions and OAM of both technologies to minimize MPLS-TP equipment 
> and network management complexities.

As a general observation it makes huge sense for the functional components
(and this is way more than just DP OAM) of technologies that belong to the
*same* network mode to migrate to the same optimised functional components.
Indeed, as an industry we have been very poor at achieving this and each
technology has largely had a new set of components defined for it.  However,
it makes no sense to try and make all modes 'look alike'....they can't for a
whole raft of reasons, and it's why the 3 network modes are so enduring
(G.800 explains why this is technically, from information theory
considerations of how the labelling of space/freq/time resource partitioning
works).

So, to take a concrete example the OAM of a cl-ps mode network should not
try and be the same as the OAM of a co-cs or co-ps mode network.
See my recent to post to Sasha which contains one example to support this
observation.  And of course a cl-ps mode network does not have connections
(by definition) and this makes its functional specification very different
to a co-cs or co-ps mode layer network....a signalling component is an
obvious difference.....and further in the co-cs mode this is forced to run
logically OOB in an adjunct layer network whereas this is not forced (but is
desirable) in the co-ps mode.

And just to be really clear wrt to my views on OAM here I am NOT sure at all
that ITU and even IEEE have done a great job on OAM for Ethernet.....though
IEEE did at least have the very good sense to throw out AIS which is a
completely useless concept for a cl-ps mode layer network.  My personal view
is that the OAM that has been specified for Ethernet is
over-complex.....though if I had to home-in on one specific aspect it would
have to be nested TCM levels, I and most of my collegaues here in BT don't
think these are that useful (go check how much of this old idea has been
deployed in operators networks, even where it could be argued it is most
relevant, ie long-holding co-cs mode networks).

As a minimum, folks really need to be clear just how such nested OAM levels
get dynamically configured across routing changes (ie
restoration/prot-sw) as only the end-points remain invariant across such
changes.  My view is that the OAM required needs to be as simple/sparse as
possible for the mode considered as it needs to be considerably more
reliable than the network it is monitoring....so all unecessary config
actions needs to be removed and those that are left automated as much as
possible (eg activating/deactivating OAM in sync with signalling connection
set-up/tear-down for **co** mode networks).  I can tell you for a fact that
Operations folks will turn as much unecessary OAM off as they can....it has
a processing/collection cost as well as a potential unreliability factor.

I can prove technically and very easily that:
-	it is a complete nonsense to try and interwork technologies that
belong to different network modes
-	unless there is very close functional alignment across *all* DP
and CP components (ie which is far more than OAM!) of technologies that
belong to the *same* network mode then peer interworking will be a nightmare
-	unless one is dealing with a top-of-stack layer network (and the
critical observation here is that the layer network we are dealing with has
a suite of message/file/stream end-system adaptation functions...not all
have, including Ethernet and MPLS/MPLS-TP note very carefully) then there is
*no* technical requirement at all for NNIs.  

So when we get around to specifying MPLS-TP let us please not load it up
with unecessary complexity, and let's try and stick with the real
operational requirements *and* try and use the important findings from the
work on unified modelling in G.800 as our guide.

regards, Neil

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 15 Dec 2008 11:15:44 -0500

I agree with Neil, peer interworking of different technologies is
flawed. It only can work under very constrained architectures. Is
Ethernet and MPLS-TP OAM/protection interworking required? While it may
look "simple" from an equipment perspective, it will be an operational
nightmare as operations are based on technology, not what functionality
a vendor's equipment supports. And this is aligned with Q9's functional
modeling which does not restrict functionality per "transport"
equipment. If this is a requirement, Q12 should provide architectural
guidance.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Monday, December 15, 2008 10:20 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network

Neil,

There is no misleading assertion in my writing. Our OAM is used to
monitor
Transport Entities. In Ethernet the VLAN is a Transport Entity and the
Y.1731 Ethernet OAM is used to monitor this Ethernet Transport Entity
(i.e.
VLAN).

There are three types of Transport Entities:
1) transport entities in which traffic units are forwarded
unconditionally
(i.e. broadcast) 
2) transport entities in which traffic units are by default broadcast,
but
may have optional filtering applied
3) transport entities in which traffic units are forwarded on the basis
of
configured forwarding rules; there is no default braodcast rule in this
case.

Examples of the first transport entities are the well known p2p and p2mp
connections in PDH, SDH, ATM, OTN.
Examples of the second transport entities are the well known p2p, p2mp,
rmp
and mp2mp VLANs in Ethernet. For the p2p and p2mp VLANs there are no
filtering rules registered; i.e. just the default broadcast (flooding)
is
present.
Example of the third transport entity is the IP VPN and the internet.

All those transport entity types are managed in the same manner in a
transport network, including their set up, monitoring, protection and
fault
management.

I am summarizing those three transport entity types often by their
internal
forwarding method as:
1) connection-oriented (CO) transport entity
2) connection-oriented plus connectionless (CO/CL) transport entity
3) connectionless (CL) transport entity.

OAM designed for a CO/CL transport entity is largerly the same OAM as
the
OAM for a CO transport entity. 
- The CO/CL transport entity OAM set includes essentially one additional
OAM
PDU; i.e. the link trace OAM PDU which allows to check the presence of a
filtering rule in the Ethernet Transport Entities (i.e. VLANs).
- The other difference between the two OAM sets is the field in the
Loopback
OAM PDUs in which the MIP and MEP identifier is carried; in CO transport
entity OAM this field is located inside the LBM OAM PDU, in CO/CL
transport
entity OAM this field is the DA field.

You will notice this equivalence when you compare Y.1731 with the
specifications in the latest draft version of G.8114 that was not
consented.

Interworking between p2p and p2mp Ethernet and MPLS-TP transport
entities is
possible and should be supported in a multi-technology packet transport
network that includes Ethernet VLAN based PTN domains and MPLS-TP based
PTN
domains. This interworking capability creates hybrid Ethernet
VLAN/MPLS-TP
p2p and p2mp channel layer connections. The former T-MPLS OAM and linear
protection switching specifications were designed to support such hybrid
channel layer connections.

In MPLS-TP, this implies that e.g. a p2p Ethernet Service VLAN will be
continued as a p2p MPLS-TP PW. If the MPLS-TP OAM and protection
switching
are look and feel alike with the Ethernet OAM and protection switching,
then
the interworking function (ETH/MT_IW) will be very simple and mainly has
to
replace a VLAN Tag with a label stack entry header for Ethernet
services.
When the MPLS-TP OAM and protection switching are not look and feel
alike,
then the interworking function will be very complex. Interworking for
the
case that a TDM service is provided requires also the removal/insertion
of
DA/SA/TYPE fields, again a simple task.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 15 december 2008 12:41
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

As a general observation it makes huge sense for the functional
components
(and this is way more than just DP OAM) of technologies that belong to
the
*same* network mode to migrate to the same optimised functional
components.
Indeed, as an industry we have been very poor at achieving this and each
technology has largely had a new set of components defined for it.
However,
it makes no sense to try and make all modes 'look alike'....they can't
for a
whole raft of reasons, and it's why the 3 network modes are so enduring
(G.800 explains why this is technically, from information theory
considerations of how the labelling of space/freq/time resource
partitioning
works).

So, to take a concrete example the OAM of a cl-ps mode network should
not
try and be the same as the OAM of a co-cs or co-ps mode network.
See my recent to post to Sasha which contains one example to support
this
observation.  And of course a cl-ps mode network does not have
connections
(by definition) and this makes its functional specification very
different
to a co-cs or co-ps mode layer network....a signalling component is an
obvious difference.....and further in the co-cs mode this is forced to
run
logically OOB in an adjunct layer network whereas this is not forced
(but is
desirable) in the co-ps mode.

And just to be really clear wrt to my views on OAM here I am NOT sure at
all
that ITU and even IEEE have done a great job on OAM for
Ethernet.....though
IEEE did at least have the very good sense to throw out AIS which is a
completely useless concept for a cl-ps mode layer network.  My personal
view
is that the OAM that has been specified for Ethernet is
over-complex.....though if I had to home-in on one specific aspect it
would
have to be nested TCM levels, I and most of my collegaues here in BT
don't
think these are that useful (go check how much of this old idea has been
deployed in operators networks, even where it could be argued it is most
relevant, ie long-holding co-cs mode networks).

As a minimum, folks really need to be clear just how such nested OAM
levels
get dynamically configured across routing changes (ie
restoration/prot-sw) as only the end-points remain invariant across such
changes.  My view is that the OAM required needs to be as simple/sparse
as
possible for the mode considered as it needs to be considerably more
reliable than the network it is monitoring....so all unecessary config
actions needs to be removed and those that are left automated as much as
possible (eg activating/deactivating OAM in sync with signalling
connection
set-up/tear-down for **co** mode networks).  I can tell you for a fact
that
Operations folks will turn as much unecessary OAM off as they can....it
has
a processing/collection cost as well as a potential unreliability
factor.

has
have, including Ethernet and MPLS/MPLS-TP note very carefully) then
there is

the

regards, Neil

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 18:18:12 -0000

Thanks Maarten,

Your major focus seems to be on defining all possible configuration
possibilities (which you then call 'transport entities') but you don't
seem that concerned about the more fundamental properties of forwarding
and transparency, and its implications on cost/complexity of the
networks that result....our focus has been on better understanding these
latter properties so that we can then better define the functional
specification of the networks we need, which includes OAM etc.

I fully stand by all I said in my earlier mail (which I don't consider
you have dealt with) and I note Deborah also shares some of my concerns
wrt the complexities that will ensue from trying to interwork different
network modes (esp given it's all rather unnecessary anyway).

I have spoken to Andy (Reid) about all this a few times today and I'm
hoping Andy can provide his views on these issues.

regards, Neil

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 15 December 2008 15:20
> To: Harrison,N,Neil,CXM R; [email-masked]
> There is no misleading assertion in my writing. Our OAM is 
> used to monitor Transport Entities. In Ethernet the VLAN is a 
> Transport Entity and the
> unconditionally (i.e. broadcast)
> 2) transport entities in which traffic units are by default 
> broadcast, but may have optional filtering applied
> 3) transport entities in which traffic units are forwarded on 
> the basis of configured forwarding rules; there is no default 
> braodcast rule in this case.
> 
> Examples of the first transport entities are the well known 
> p2p and p2mp connections in PDH, SDH, ATM, OTN.
> Examples of the second transport entities are the well known 
> p2p, p2mp, rmp and mp2mp VLANs in Ethernet. For the p2p and 
> p2mp VLANs there are no filtering rules registered; i.e. just 
> the default broadcast (flooding) is present.
> All those transport entity types are managed in the same 
> manner in a transport network, including their set up, 
> monitoring, protection and fault management.
> 
> I am summarizing those three transport entity types often by 
> their internal forwarding method as:
> OAM designed for a CO/CL transport entity is largerly the 
> same OAM as the OAM for a CO transport entity. 
> - The CO/CL transport entity OAM set includes essentially one 
> additional OAM PDU; i.e. the link trace OAM PDU which allows 
> to check the presence of a filtering rule in the Ethernet 
> Transport Entities (i.e. VLANs).
> - The other difference between the two OAM sets is the field 
> in the Loopback OAM PDUs in which the MIP and MEP identifier 
> is carried; in CO transport entity OAM this field is located 
> inside the LBM OAM PDU, in CO/CL transport entity OAM this 
> field is the DA field.
> 
> You will notice this equivalence when you compare Y.1731 with 
> the specifications in the latest draft version of G.8114 that 
> was not consented.
> 
> Interworking between p2p and p2mp Ethernet and MPLS-TP 
> transport entities is possible and should be supported in a 
> multi-technology packet transport network that includes 
> Ethernet VLAN based PTN domains and MPLS-TP based PTN 
> VLAN/MPLS-TP p2p and p2mp channel layer connections. The 
> former T-MPLS OAM and linear protection switching 
> specifications were designed to support such hybrid channel 
> layer connections.
> 
> In MPLS-TP, this implies that e.g. a p2p Ethernet Service 
> VLAN will be continued as a p2p MPLS-TP PW. If the MPLS-TP 
> OAM and protection switching are look and feel alike with the 
> Ethernet OAM and protection switching, then the interworking 
> function (ETH/MT_IW) will be very simple and mainly has to 
> When the MPLS-TP OAM and protection switching are not look 
> and feel alike, then the interworking function will be very 
> complex. Interworking for the case that a TDM service is 
> provided requires also the removal/insertion of DA/SA/TYPE 
> fields, again a simple task.
> 
> Regards,
> Maarten
> 
> 
> As a general observation it makes huge sense for the 
> functional components (and this is way more than just DP OAM) 
> of technologies that belong to the
> Indeed, as an industry we have been very poor at achieving 
> this and each technology has largely had a new set of 
> components defined for it.  However, it makes no sense to try 
> and make all modes 'look alike'....they can't for a whole 
> raft of reasons, and it's why the 3 network modes are so 
> enduring (G.800 explains why this is technically, from 
> information theory considerations of how the labelling of 
> space/freq/time resource partitioning works).
> 
> So, to take a concrete example the OAM of a cl-ps mode 
> network should not try and be the same as the OAM of a co-cs 
> or co-ps mode network.
> See my recent to post to Sasha which contains one example to 
> support this observation.  And of course a cl-ps mode network 
> does not have connections (by definition) and this makes its 
> functional specification very different to a co-cs or co-ps 
> mode layer network....a signalling component is an obvious 
> difference.....and further in the co-cs mode this is forced 
> to run logically OOB in an adjunct layer network whereas this 
> is not forced (but is
> And just to be really clear wrt to my views on OAM here I am 
> NOT sure at all that ITU and even IEEE have done a great job 
> on OAM for Ethernet.....though IEEE did at least have the 
> very good sense to throw out AIS which is a completely 
> useless concept for a cl-ps mode layer network.  My personal 
> view is that the OAM that has been specified for Ethernet is 
> over-complex.....though if I had to home-in on one specific 
> aspect it would have to be nested TCM levels, I and most of 
> my collegaues here in BT don't think these are that useful 
> (go check how much of this old idea has been deployed in 
> operators networks, even where it could be argued it is most 
> As a minimum, folks really need to be clear just how such 
> nested OAM levels get dynamically configured across routing 
> changes (ie
> restoration/prot-sw) as only the end-points remain invariant 
> across such changes.  My view is that the OAM required needs 
> to be as simple/sparse as possible for the mode considered as 
> it needs to be considerably more reliable than the network it 
> is monitoring....so all unecessary config actions needs to be 
> removed and those that are left automated as much as possible 
> (eg activating/deactivating OAM in sync with signalling 
> connection set-up/tear-down for **co** mode networks).  I can 
> tell you for a fact that Operations folks will turn as much 
> unecessary OAM off as they can....it has a 
> processing/collection cost as well as a potential 
> unreliability factor.
> 
> of different modes/technologies is a good idea and that (ii) 
> we need UNIs/NNIs in all cases.  Both these assumptions are 
> terribly flawed.
> 
> and CP components (ie which is far more than OAM!) of 
> technologies that belong to the *same* network mode then peer 
> interworking will be a nightmare
> critical observation here is that the layer network we are 
> dealing with has a suite of message/file/stream end-system 
> adaptation functions...not all have, including Ethernet and 
> MPLS/MPLS-TP note very carefully) then there is
> This latter point may not be immediately obvious to everyone, 
> but let me assure you it is a fact that can be easily proved.
> 
> So when we get around to specifying MPLS-TP let us please not 
> load it up with unecessary complexity, and let's try and 
> stick with the real operational requirements *and* try and 
> use the important findings from the work on unified modelling 
> in G.800 as our guide.
> 
> regards, Neil
> 
> 
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 16 Dec 2008 10:59:44 +0100

Deborah,

I agree with you that peer interworking can be a nightmare, but it does not
have to be a nightmare when a few rules have been applied:
1) perform peer interworking between the channel layer signals of two
technologies
2) perform peer interworking between similar channel layer transport
entities in the two technologies
2) use similar encapsulation methods for mapping a client signal into the
two channel signal types
3) use similar channel layer OAM PDUs in the two technologies
4) use similar channel layer protection switching in the two technologies.

The two main client signals of both Ethernet VLAN and MPLS-TP based packet
transport networks will be ethernet and TDM signals. The mapping of these
client signals into the ETH and MPLS-TP channel signals is very similar and
allows for peer interworking between p2p ETH and MPLS-TP channels (between
p2p service VLANs and p2p MS-PWs).

Such peer interworking is important within a multi-technology packet
transport network, as it will prevent the introduction of an additional
service/channel layer network in the layer stack. 

As an example consider an E-LINE (i.e. p2p Ethernet VLAN) service provided
in a hybrid Ethernet VLAN and MPLS-TP network. One endpoint of this E-LINE
service is located in e.g. a Provider Edge Bridge (PEB) node and the other
endpoint is located in a MPLS-TP channel terminating node. Without peer
interworking you will get the following layer stack:

  Customer Ethernet service (E-LINE)
------------------------------------
|           ETH Channel            |
------------------------------------
| MPLS-TP Channel |  | ETH Section |
-------------------  ---------------
|  MPLS-TP Path   |  |  Phy Media  |
-------------------  ---------------
| MPLS-TP Section |      ETM-n
-------------------
| Physical Media  |
-------------------
     MTM-n

The UNI-to-UNI connection is provided in this case by the ETH channel layer
and the MPLS-TP channel terminating equipment will have to support both a
MPLS-TP channel endpoint **and** an ETH channel endpoint; this complicates
the MPLS-TP equipment unnecessary. The MPLS-TP channel connection (i.e.
MS-PW) does not provide any benefit and could be removed from the layer
stack.

When the MPLS-TP design supports peer interworking, then the layer stack
will become as follows:

  Customer Ethernet service (E-LINE)
------------------------------------
| MPLS-TP Channel >IW< ETH Channel |
------------------------------------
|   MPLS-TP Path  |  | ETH Section |
-------------------  ---------------
| MPLS-TP Section |  |  Phy Media  |
-------------------  ---------------
| Physical Media  |      ETM-n
-------------------
     MTM-n

In this case, the MPLS-TP channel (MS-PW) peers with the ETH channel
(service VLAN) and there is no unnecessary layer in the stack. Also, there
is no unnecessary complexity in the MPLS-TP equipment at the edge of the
network. Also network management is less complex as there is no second
channel layer network in the stack.

The ETH/MPLS-TP InterWorking function replaces the PW Label Stack Entry
fields by the VLAN Tag and continues the MSDU, SA and DA fields as depicted
hereafter:

MSDU    <===>  MSDU
C-SA       />  VLAN Tag
C-DA      /    C-SA
PW LSE  </     C-DA

The VLAN ID and the PW Label fields have the same function and identify this
p2p channel signal. The PCP and DEI fields in the VLAN Tag and the EXP field
in the PW LSE carry the priority and drop eligible information.

Furthermore, for the case of the rmp and mp2mp Ethernet services (E-TREE and
E-LAN) the layer stack in this example with one or more PEB nodes and one or
more MPLS-TP nodes at the edges of the packet transport network would
provide a signle service/channel layer netowrk, i.e. the ETH channel layer
network as depicted in the following figure. There is as such no need for
any interworking, as both the Ethernet VLAN and the MPLS-TP based packet
transport networks deploy the same layer network for those mp service types.

Customer Ethernet service (E-TREE, E-LAN)
------------------------------------
|          ETH Channel             |
------------------------------------
|   MPLS-TP Path  |  | ETH Section |
-------------------  ---------------
| MPLS-TP Section |  |  Phy Media  |
-------------------  ---------------
| Physical Media  |      ETM-n
-------------------
     MTM-n

TDM service
===========
Due to the fact that the TDM over Ethernet (MEF8) and TDM over MPLS
encapsulation methods are similar it is straigthforward to engineer peer
interworking for p2p service VLAN and p2p MS-PW carrying such TDM service.

The ETH/MPLS-TP InterWorking function replaces the PW Label Stack Entry
fields by the following fields: ECID, TYPE, VLAN Tag, SA, DA and continues
the TDM, RTP and CW fields as depicted hereafter:

TDM        <===>  TDM
RTP (opt)  <===>  RTP (opt)
PW CW      <===>  CES CW (=PW CW)
               >  ECID (not used, fixed value)
               >  TYPE (0x88d8)
PW LSE     <===>  VLAN TAG
               >  SA
               >  DA

As it is a p2p service, the DA value can be the broadcast address, or can be
the value of the received SA. I.e. there is no need for configuration of
this DA value.

The VLAN ID and the PW Label fields have the same function and identify this
p2p channel signal. The PCP and DEI fields in the VLAN Tag and the EXP field
in the PW LSE carry the priority and drop eligible information.

Conclusion
==========
Ethernet VLAN and MPLS-TP channel layer interworking for Ethernet and TDM
client signals is trivial when MPLS-TP OAM and linear protection switching
are similar to ETH OAM and linear protection switching. Apllying such
ETH/MPLS-TP IW reduces MPLS-TP channel terminating equipment and MPLS-TP
network management complexity.

Regards,
Maarten

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: maandag 15 december 2008 17:16
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

I agree with Neil, peer interworking of different technologies is flawed. It
only can work under very constrained architectures. Is Ethernet and MPLS-TP
OAM/protection interworking required? While it may look "simple" from an
equipment perspective, it will be an operational nightmare as operations are
based on technology, not what functionality a vendor's equipment supports.
And this is aligned with Q9's functional modeling which does not restrict
functionality per "transport"
equipment. If this is a requirement, Q12 should provide architectural
guidance.

-----Original Message-----
Of Maarten Vissers

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: maandag 15 december 2008 12:41
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 16 Dec 2008 12:09:00 +0100

Neil,

A transport network's main concern is the management of of transport
entities within the multi-layer and multi-domain architecture, including
their set up, monitoring and protection. 
During the development of the OAM PDUs, protection switching and atomic
functions in standards we take care of the:
- forwarding aspects within each transport entity (non-selective or
selective forwarding), 
- value/order/timing transparency provided by each transport entity, and
necessary mitigation within adaptation functions in order to meet the client
value/order/timing transparency requirements,
- snooping transparency within each transport entity (e.g. reading of client
owned fields).

Once the atomic functions are available, the network can be constructed
using those atomic functions in compliance with their specifications and
interconnection rules. At this point in time the focus can be on management
of the possible transport entities within each layer network and domains,
without considering for every transport entity specifically the forwarding
and transparency aspects. Those aspecs have been dealt with already during
the standardisation of the layer network transport entities and atomic
functions.

As an example I would like to describe the feedback I got from several
operators on the importance and use of MAC addresses in their network
management. Individual MAC addresses I am told are not managed as part of
VLAN set up (ETH transport entity set up). Individual MAC addresses are
essentially not managed as MAC address; instead those are managed as EUI-48
identifiers of physical subsystems (resources). Network management assigns
an EUI-48 identifier to each physical subsystem when the field replaceable
unit on which it resides is installed in a network element. The atomic
functions hosted by a physical subsystem then inherit the subsystem's EUI-48
identifier as MAC Address. This is automatic and does not require any
management control.

At the points where an Ethernet VLAN transport entity ends and connects to a
non-Ethernet client layer (e.g. a 2 Mbit/s TDM layer, or an IP layer) it is
necessary to insert a destination address in the DA field of the frames. The
destination address value or values are in all cases either locally learned
(e.g. from SA field in received frames, via ARP), or be the broadcast
address, or be a broadcast emulating multicast address.

At the points where an Ethernet VLAN MEP or MIP is inserting frames, the
destination address in the DA field of the OAM frames is either a broadcast
emulating multicast address, or a MEP or MIP identifying individual MAC
address in case of a unicast loopback message.

At the points where an Ethernet VLAN transport entity ends and connects to
an Ethernet client layer there are two options:
1) re-use the client-Ethernet's DA/SA information (QinQ)
2) insert a new MAC header with new DA and SA fields (MinM).

In the first option there is again no MAC address management needed. In the
second option there is also no MAC address management needed, while the
source address is inherit from the local EUI-48 identifier and the
destination address is locally learned or is a broadcast (emulating
multicast) address (as specified in 802.1ah).

The deployment of a QinQ adaptation function or a MinM adaptation function
at the end of an Ethernet VLAN channel layer transport entity depends on the
type of Ethernet service (E-LINE or E-TREE/E-LAN) and the availability of
the MinM adaptation function in Ethernet UNI-N interface ports. For the case
of E-TREE/E-LAN type services it is beneficial to deploy the MinM adaptation
function to reduce the number of learned MAC addresses within the Ethernet
VLAN transport entity, which improves scalability of the packet transport
network. As such, if all UNI-N interface ports for such E-TREE/E-LAN service
support MinM, then this MinM can be deployed; otherwise QinQ adaptation
function has to be deployed. 

Note that the Ethernet VLAN channel layer will have no problem at all to
support a set of transport entities that have QinQ type adaptation and
another set of transport entities that have MinM type adaptation. The
Ethenret VLAN forwarding functions act namely on the outer-DA, outer-SA. 

Conclusion
==========
MAC addresses are managed as EUI-48 identifiers during the installation of
field replaceable units. MAC addresses are ignored during set up and
operation of Ethernet VLAN transport entities.

Your "more fundamental properties of forwarding and transparency" are dealt
with during standardisation of the atomic functions and their
interconnection rules, and don't require any specific attention during the
set up and deployment of transport entities.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 15 december 2008 19:18
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

Thanks Maarten,

Your major focus seems to be on defining all possible configuration
possibilities (which you then call 'transport entities') but you don't seem
that concerned about the more fundamental properties of forwarding and
transparency, and its implications on cost/complexity of the networks that
result....our focus has been on better understanding these latter properties
so that we can then better define the functional specification of the
networks we need, which includes OAM etc.

I fully stand by all I said in my earlier mail (which I don't consider you
have dealt with) and I note Deborah also shares some of my concerns wrt the
complexities that will ensue from trying to interwork different network
modes (esp given it's all rather unnecessary anyway).

I have spoken to Andy (Reid) about all this a few times today and I'm hoping
Andy can provide his views on these issues.

regards, Neil

> monitor Transport Entities. In Ethernet the VLAN is a Transport Entity 
> and the
> but may have optional filtering applied
> 3) transport entities in which traffic units are forwarded on the 
> basis of configured forwarding rules; there is no default braodcast 
> rule in this case.
> 
> Examples of the first transport entities are the well known p2p and 
> p2mp connections in PDH, SDH, ATM, OTN.
> Examples of the second transport entities are the well known p2p, 
> p2mp, rmp and mp2mp VLANs in Ethernet. For the p2p and p2mp VLANs 
> there are no filtering rules registered; i.e. just the default 
> broadcast (flooding) is present.
> fault management.
> internal forwarding method as:
> the OAM for a CO transport entity.
> additional OAM PDU; i.e. the link trace OAM PDU which allows to check 
> the presence of a filtering rule in the Ethernet Transport Entities 
> (i.e. VLANs).
> Loopback OAM PDUs in which the MIP and MEP identifier is carried; in 
> CO transport entity OAM this field is located inside the LBM OAM PDU, 
> in CO/CL transport entity OAM this field is the DA field.
> 
> entities is possible and should be supported in a multi-technology 
> packet transport network that includes Ethernet VLAN based PTN domains 
> and MPLS-TP based PTN domains. This interworking capability creates 
> hybrid Ethernet VLAN/MPLS-TP p2p and p2mp channel layer connections. 
> The former T-MPLS OAM and linear protection switching specifications 
> were designed to support such hybrid channel layer connections.
> 
> switching are look and feel alike with the Ethernet OAM and protection 
> switching, then the interworking function (ETH/MT_IW) will be very 
> simple and mainly has to replace a VLAN Tag with a label stack entry 
> header for Ethernet services.
> alike, then the interworking function will be very complex. 
> Interworking for the case that a TDM service is provided requires also 
> the removal/insertion of DA/SA/TYPE fields, again a simple task.
> 
> Regards,
> Maarten
> 
> 
> components (and this is way more than just DP OAM) of technologies 
> that belong to the
> Indeed, as an industry we have been very poor at achieving this and 
> each technology has largely had a new set of components defined for 
> it.  However, it makes no sense to try and make all modes 'look 
> alike'....they can't for a whole raft of reasons, and it's why the 3 
> network modes are so enduring (G.800 explains why this is technically, 
> from information theory considerations of how the labelling of 
> connections (by definition) and this makes its functional 
> specification very different to a co-cs or co-ps mode layer 
> network....a signalling component is an obvious difference.....and 
> further in the co-cs mode this is forced to run logically OOB in an 
> adjunct layer network whereas this is not forced (but is
> And just to be really clear wrt to my views on OAM here I am NOT sure 
> at all that ITU and even IEEE have done a great job on OAM for 
> Ethernet.....though IEEE did at least have the very good sense to 
> throw out AIS which is a completely useless concept for a cl-ps mode 
> layer network.  My personal view is that the OAM that has been 
> specified for Ethernet is over-complex.....though if I had to home-in 
> on one specific aspect it would have to be nested TCM levels, I and 
> most of my collegaues here in BT don't think these are that useful (go 
> check how much of this old idea has been deployed in operators 
> networks, even where it could be argued it is most relevant, ie 
> long-holding co-cs mode networks).
> 
> restoration/prot-sw) as only the end-points remain invariant across 
> such changes.  My view is that the OAM required needs to be as 
> simple/sparse as possible for the mode considered as it needs to be 
> considerably more reliable than the network it is monitoring....so all 
> unecessary config actions needs to be removed and those that are left 
> automated as much as possible (eg activating/deactivating OAM in sync 
> with signalling connection set-up/tear-down for **co** mode networks).  
> I can tell you for a fact that Operations folks will turn as much 
> unecessary OAM off as they can....it has a processing/collection cost 
> as well as a potential unreliability factor.
> 
> and CP components (ie which is far more than OAM!) of technologies 
> that belong to the *same* network mode then peer interworking will be 
> a nightmare
> critical observation here is that the layer network we are dealing 
> with has a suite of message/file/stream end-system adaptation 
> functions...not all have, including Ethernet and MPLS/MPLS-TP note 
> very carefully) then there is
> This latter point may not be immediately obvious to everyone, but let 
> me assure you it is a fact that can be easily proved.
> 
> So when we get around to specifying MPLS-TP let us please not load it 
> up with unecessary complexity, and let's try and stick with the real

---

From: <[email-masked]>
Date: Tue, 16 Dec 2008 11:59:35 -0000

Maarten...I suspect you have not thought this through because just
clearly don't get it.

So, let be me very clear:  If you are NOT a top-of-stack layer network
(ie a top-of-stack layer network carries end-system application
adaptation functions like UDP/TCP/RTP in IP say and there are no higher
layer networks) there is *NO* need for peer interworking at all.

If you cannot figure this out I can post a detailed explantion of why
peer interworking is not required here.  I explained all this to Huub a
while back when he was editor of the T-MPLS OAM draft Recs wrt why I
wanted all reference to Ethernet<=>T-MPLS peer interworking removed from
those drafts.  Huub was urging me to write a new Recommendation on what
I explained to him....so far however I have only written an internal
paper (in Word) on this....but I am very happy to post this if it would
be useful to the folks on the list.

You are simply creating a load of work where none is necessary.

regards, Neil  

> Sent: 16 December 2008 10:00
> To: 'BRUNGARD, DEBORAH A, ATTLABS'; Harrison,N,Neil,CXM R; 
> [email-masked]
> I agree with you that peer interworking can be a nightmare, 
> but it does not have to be a nightmare when a few rules have 
> been applied:
> 1) perform peer interworking between the channel layer 
> signals of two technologies
> 2) perform peer interworking between similar channel layer 
> transport entities in the two technologies
> 2) use similar encapsulation methods for mapping a client 
> signal into the two channel signal types
> The two main client signals of both Ethernet VLAN and MPLS-TP 
> based packet transport networks will be ethernet and TDM 
> signals. The mapping of these client signals into the ETH and 
> MPLS-TP channel signals is very similar and allows for peer 
> interworking between p2p ETH and MPLS-TP channels (between 
> Such peer interworking is important within a multi-technology 
> packet transport network, as it will prevent the introduction 
> of an additional service/channel layer network in the layer stack. 
> 
> As an example consider an E-LINE (i.e. p2p Ethernet VLAN) 
> service provided in a hybrid Ethernet VLAN and MPLS-TP 
> network. One endpoint of this E-LINE service is located in 
> e.g. a Provider Edge Bridge (PEB) node and the other endpoint 
> is located in a MPLS-TP channel terminating node. Without 
> peer interworking you will get the following layer stack:
> 
> The UNI-to-UNI connection is provided in this case by the ETH 
> channel layer and the MPLS-TP channel terminating equipment 
> will have to support both a MPLS-TP channel endpoint **and** 
> an ETH channel endpoint; this complicates the MPLS-TP 
> equipment unnecessary. The MPLS-TP channel connection (i.e.
> MS-PW) does not provide any benefit and could be removed from 
> the layer stack.
> 
> When the MPLS-TP design supports peer interworking, then the 
> layer stack will become as follows:
> 
> In this case, the MPLS-TP channel (MS-PW) peers with the ETH 
> channel (service VLAN) and there is no unnecessary layer in 
> the stack. Also, there is no unnecessary complexity in the 
> MPLS-TP equipment at the edge of the network. Also network 
> management is less complex as there is no second channel 
> layer network in the stack.
> 
> The ETH/MPLS-TP InterWorking function replaces the PW Label 
> Stack Entry fields by the VLAN Tag and continues the MSDU, SA 
> and DA fields as depicted
> hereafter:
> 
> MSDU    <===>  MSDU
> C-SA       />  VLAN Tag
> C-DA      /    C-SA
> PW LSE  </     C-DA
> 
> The VLAN ID and the PW Label fields have the same function 
> and identify this p2p channel signal. The PCP and DEI fields 
> in the VLAN Tag and the EXP field in the PW LSE carry the 
> priority and drop eligible information.
> 
> 
> 
> E-LAN) the layer stack in this example with one or more PEB 
> nodes and one or more MPLS-TP nodes at the edges of the 
> packet transport network would provide a signle 
> service/channel layer netowrk, i.e. the ETH channel layer 
> network as depicted in the following figure. There is as such 
> no need for any interworking, as both the Ethernet VLAN and 
> the MPLS-TP based packet transport networks deploy the same 
> layer network for those mp service types.
> 
> Due to the fact that the TDM over Ethernet (MEF8) and TDM 
> over MPLS encapsulation methods are similar it is 
> straigthforward to engineer peer interworking for p2p service 
> VLAN and p2p MS-PW carrying such TDM service.
> 
> The ETH/MPLS-TP InterWorking function replaces the PW Label 
> Stack Entry fields by the following fields: ECID, TYPE, VLAN 
> Tag, SA, DA and continues the TDM, RTP and CW fields as 
> depicted hereafter:
> 
> TDM        <===>  TDM
> As it is a p2p service, the DA value can be the broadcast 
> address, or can be the value of the received SA. I.e. there 
> is no need for configuration of this DA value.
> 
> The VLAN ID and the PW Label fields have the same function 
> and identify this p2p channel signal. The PCP and DEI fields 
> in the VLAN Tag and the EXP field in the PW LSE carry the 
> priority and drop eligible information.
> 
> 
> 
> Conclusion
> ==========
> Ethernet VLAN and MPLS-TP channel layer interworking for 
> Ethernet and TDM client signals is trivial when MPLS-TP OAM 
> and linear protection switching are similar to ETH OAM and 
> linear protection switching. Apllying such ETH/MPLS-TP IW 
> reduces MPLS-TP channel terminating equipment and MPLS-TP 
> I agree with Neil, peer interworking of different 
> technologies is flawed. It only can work under very 
> constrained architectures. Is Ethernet and MPLS-TP 
> OAM/protection interworking required? While it may look 
> "simple" from an equipment perspective, it will be an 
> operational nightmare as operations are based on technology, 
> not what functionality a vendor's equipment supports.
> And this is aligned with Q9's functional modeling which does 
> not restrict functionality per "transport"
> equipment. If this is a requirement, Q12 should provide 
> architectural guidance.
> 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> components defined for it.
> However,
> it makes no sense to try and make all modes 'look 
> alike'....they can't for a whole raft of reasons, and it's 
> why the 3 network modes are so enduring (G.800 explains why 
> this is technically, from information theory considerations 
> of how the labelling of space/freq/time resource partitioning works).
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 16 Dec 2008 15:46:34 +0100

Neil,

I have thought this through very well. It is very simple and doesn't require
much knowledge to understand. 

The requirement to meet is to pass the customer_CI with sufficient
value/order/timing transparency from an input port of a multi-technology
packet transport network to an output port of this network via a hybrid,
multi-technology server layer trail.

Take the 2 Mbit/s example. At one end the P12x_CI is connected to an
ETH/P12x_A function and at the other end it is connected to a MPLS-TP/P12x_A
function. There is no need at all to go to anything else then the P12x layer
network at the edges of the transport network. For the multi-technology
packet transport network the P12x layer is the "end-system application".

In the first domain of the packet transport network this P12x_CI is carried
in the ETH_AI (as per G.8010/G.8021), while in the second domain it is
carried in the MPLS-TP_AI. As the encapsulation processes in both cases are
the same, it is possible to pass the encapsulated P12x_CI between the two
domains. This is possible by replacing some Adapted Information header
fields in the interworking function as described in the email below.

To create such hybrid VLAN/MS-PW trail it is also required to interwork the
OAM. As illustrated in the T-MPLS OAM work, it is without any real problem
to make interworkable ETH/MPLS-TP OAM.

This implies that it can be straigthforward to interwork a p2p VLAN with a
p2p MS-PW for TDM services. Such interworking is also very beneficial in
such multi-technology packet transport network.

Now take the second customer_CI case: i.e. ETH_CI. The requirement is to
transport this customer ETH_CI from an input port in the Ethernet VLAN
domain of the transport network to an output port in the MPLS-TP domain of
the transport netowrk. This transport must support the required
value/order/timing transparency of the customer's ETH_CI signal. The
"end-system application" in this case is the customer's ETH layer netowrk
instance with its ETH_CI.

Also in this case the ETH/ETH-m_A and MPLS-TP/ETH-m_A functions perform a
similar encapsulation of the customer's ETH_CI, which allows the ETH to
MPLS-TP interworking function to pass through the encapsulated customer
ETH_CI (i.e. without having to go back into the customer's ETH layer network
instance).

With interworkable ETH and MPLS-TP OAM it can be straigthforward to
interwork a p2p VLAN with a p2p MS-PW for ETH services. Such interworking is
also very beneficial in such multi-technology packet transport network, as
it will reduce management complexity and reduce MPLS-TP equipment
functionality.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 16 december 2008 13:00
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

Maarten...I suspect you have not thought this through because just clearly
don't get it.

So, let be me very clear:  If you are NOT a top-of-stack layer network (ie a
top-of-stack layer network carries end-system application adaptation
functions like UDP/TCP/RTP in IP say and there are no higher layer networks)
there is *NO* need for peer interworking at all.

If you cannot figure this out I can post a detailed explantion of why peer
interworking is not required here.  I explained all this to Huub a while
back when he was editor of the T-MPLS OAM draft Recs wrt why I wanted all
reference to Ethernet<=>T-MPLS peer interworking removed from those drafts.
Huub was urging me to write a new Recommendation on what I explained to
him....so far however I have only written an internal paper (in Word) on
this....but I am very happy to post this if it would be useful to the folks
on the list.

regards, Neil  

> I agree with you that peer interworking can be a nightmare, but it 
> does not have to be a nightmare when a few rules have been applied:
> 2) use similar encapsulation methods for mapping a client signal into 
> the two channel signal types
> The two main client signals of both Ethernet VLAN and MPLS-TP based 
> packet transport networks will be ethernet and TDM signals. The 
> mapping of these client signals into the ETH and MPLS-TP channel 
> signals is very similar and allows for peer interworking between p2p 
> ETH and MPLS-TP channels (between p2p service VLANs and p2p MS-PWs).
> 
> transport network, as it will prevent the introduction of an 
> additional service/channel layer network in the layer stack.
> 
> As an example consider an E-LINE (i.e. p2p Ethernet VLAN) service 
> provided in a hybrid Ethernet VLAN and MPLS-TP network. One endpoint 
> of this E-LINE service is located in e.g. a Provider Edge Bridge (PEB) 
> node and the other endpoint is located in a MPLS-TP channel 
> terminating node. Without peer interworking you will get the following 
> layer stack:
> 
> The UNI-to-UNI connection is provided in this case by the ETH channel 
> layer and the MPLS-TP channel terminating equipment will have to 
> support both a MPLS-TP channel endpoint **and** an ETH channel 
> endpoint; this complicates the MPLS-TP equipment unnecessary. The 
> MPLS-TP channel connection (i.e.
> MS-PW) does not provide any benefit and could be removed from the 
> layer stack.
> 
> When the MPLS-TP design supports peer interworking, then the layer 
> stack will become as follows:
> 
> (service VLAN) and there is no unnecessary layer in the stack. Also, 
> there is no unnecessary complexity in the MPLS-TP equipment at the 
> edge of the network. Also network management is less complex as there 
> is no second channel layer network in the stack.
> 
> The ETH/MPLS-TP InterWorking function replaces the PW Label Stack 
> Entry fields by the VLAN Tag and continues the MSDU, SA and DA fields 
> as depicted
> hereafter:
> 
> MSDU    <===>  MSDU
> C-SA       />  VLAN Tag
> C-DA      /    C-SA
> PW LSE  </     C-DA
> 
> The VLAN ID and the PW Label fields have the same function and 
> identify this p2p channel signal. The PCP and DEI fields in the VLAN 
> Tag and the EXP field in the PW LSE carry the priority and drop 
> eligible information.
> 
> 
> 
> E-LAN) the layer stack in this example with one or more PEB nodes and 
> one or more MPLS-TP nodes at the edges of the packet transport network 
> would provide a signle service/channel layer netowrk, i.e. the ETH 
> channel layer network as depicted in the following figure. There is as 
> such no need for any interworking, as both the Ethernet VLAN and the 
> MPLS-TP based packet transport networks deploy the same layer network 
> for those mp service types.
> 
> encapsulation methods are similar it is straigthforward to engineer 
> peer interworking for p2p service VLAN and p2p MS-PW carrying such TDM 
> service.
> 
> The ETH/MPLS-TP InterWorking function replaces the PW Label Stack 
> Entry fields by the following fields: ECID, TYPE, VLAN Tag, SA, DA and 
> continues the TDM, RTP and CW fields as depicted hereafter:
> 
> TDM        <===>  TDM
> As it is a p2p service, the DA value can be the broadcast address, or 
> can be the value of the received SA. I.e. there is no need for 
> configuration of this DA value.
> 
> The VLAN ID and the PW Label fields have the same function and 
> identify this p2p channel signal. The PCP and DEI fields in the VLAN 
> Tag and the EXP field in the PW LSE carry the priority and drop 
> eligible information.
> 
> 
> 
> Conclusion
> ==========
> Ethernet VLAN and MPLS-TP channel layer interworking for Ethernet and 
> TDM client signals is trivial when MPLS-TP OAM and linear protection 
> switching are similar to ETH OAM and linear protection switching. 
> Apllying such ETH/MPLS-TP IW reduces MPLS-TP channel terminating 
> equipment and MPLS-TP network management complexity.
> 
> Regards,
> Maarten
> 
> Ethernet and MPLS-TP OAM/protection interworking required? While it 
> may look "simple" from an equipment perspective, it will be an 
> operational nightmare as operations are based on technology, not what 
> functionality a vendor's equipment supports.
> And this is aligned with Q9's functional modeling which does not 
> restrict functionality per "transport"
> it.
> for a whole raft of reasons, and it's why the 3 network modes are so 
> enduring (G.800 explains why this is technically, from information 
> theory considerations of how the labelling of space/freq/time resource 
> partitioning works).
>

---

From: "Malcolm Betts" <[email-masked]>
Date: Wed, 17 Dec 2008 10:47:35 -0500

Neil, I agree with your conclusion that this is unnecessary work.  

I also agree with the earlier comments on this thread from yourself,
Adrian and Deborah.  The arguments being presented to support this
interworking contain many unsubstantiated assertions.  When each of the
technical details are considered in isolation they look reasonable.
However, as you have demonstrated, when they are all assembled into the
full network picture the flaws in the logic and the horrendous
complexity become apparent. 

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, December 16, 2008 7:00 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network

regards, Neil

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 00:42:41 -0000

Thank you Malcolm.....whilst it's personally gratifying to hear someone
else echoing the same sentiments, it is also technically important for
the folks reading this stuff who have not made their minds up on who is
right/wrong here.  But you/I/Adrian/Deborah are far from a minority, and
I know of no one anywhere who supports what Maarten is advocating.  All
the folks I talk to in BT are in alignment with my views.   I have
considered the issue of interworking very carefully, and I would not
dare venture to post anything unless I was as close to 100% technically
sure as I could be that I was correct (and in particular had Andy Reid,
Alan McGuire and Peter Willis on-side).  So what I stated in an earlier
mail stands.

I am very happy to spell it out in great detail if need be....though for
you and many others this is clearly not necessary.  And as one of my
close colleagues here wryly pointed out to me the the other day when we
discussing this stuff "if all technologies were identical in all aspects
then why would we need them all....forget the cost of interworking them,
just get rid of them!"....quite!....but therein lies the rub, all
technolgies are NOT the same....it is their mode (as the execellent work
in G.800 shows) that points out why there are enduring and important
differences.

The trick we as an industry have yet to understand properly is how to
best exploit the modes working in concert to solve the thorny
QoS/arbitrage/etc problems..... though I am and have been working on
this...for a future discussion.

regards, neil

> [mailto:[email-masked]] On Behalf Of Malcolm Betts
> Sent: 17 December 2008 15:48
> To: [email-masked]
> I also agree with the earlier comments on this thread from 
> yourself, Adrian and Deborah.  The arguments being presented 
> to support this interworking contain many unsubstantiated 
> assertions.  When each of the technical details are 
> considered in isolation they look reasonable.
> However, as you have demonstrated, when they are all 
> assembled into the full network picture the flaws in the 
> logic and the horrendous complexity become apparent. 
> 
> 
> Malcolm Betts
> Nortel Networks
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Maarten...I suspect you have not thought this through because 
> just clearly don't get it.
> 
> So, let be me very clear:  If you are NOT a top-of-stack 
> layer network (ie a top-of-stack layer network carries 
> end-system application adaptation functions like UDP/TCP/RTP 
> in IP say and there are no higher layer networks) there is 
> *NO* need for peer interworking at all.
> 
> If you cannot figure this out I can post a detailed 
> explantion of why peer interworking is not required here.  I 
> explained all this to Huub a while back when he was editor of 
> the T-MPLS OAM draft Recs wrt why I wanted all reference to 
> Ethernet<=>T-MPLS peer interworking removed from those 
> drafts.  Huub was urging me to write a new Recommendation on 
> what I explained to him....so far however I have only written 
> an internal paper (in Word) on this....but I am very happy to 
> post this if it would be useful to the folks on the list.
> 
> nodes and 
> address, or 
> Ethernet and 
> architectural 
> broadcast,
> manner in a 
> VLAN will be
> alike'....they can't
> network should 
> nested OAM 
> processing/collection cost

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 13:34:17 +0100

Malcolm,

This interworking complies with the clause 5.5/G.805 specified "Layer
network interworking" and is described as:
"The objective of layer network interworking is to provide an end-to-end
trail between different types of layer network trail terminations. This
requires interworking of characteristic information as different layer
networks have per definition different characteristic information. In
general the adapted information of different layer networks for the same
client layer network is also different, although this is not necessarily the
case. Layer networking may therefore require the interworking of adapted
information."

Such layer network interworking has been specified for a number of layer
networks in the past: i.e. VC-4-4c and VC-4, ATM and FR, ATM and MPLS. Now
we have to extend this set with a layer network interworking for ETH and
MPLS-TP MS-PW.

The rationale for such layer network interworking is the reduction of
equipment and network management complexity, in this case the reduction of
MPLS-TP equipment and network management.

MEF8, page 8 already includes a note referring to interworking between
Ethernet based circuit emulaiton service and MPLS based circuit emulation
service.

I have created a couple of slides to illustrate the interoperability in and
unified management of a multi-technology PTN, including this ETH/MPLS-TP PW
interworking function and its basic operation.
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/eth-mplstp-iw/ or
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/eth-mplstp-iw/intero
p-managm-multi-technology-ptn-00.ppt

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Malcolm Betts
Sent: woensdag 17 december 2008 16:48
To: [email-masked]
Subject: Re: [mpls-tp] Carrying traffic over an MPLS-TP network

I also agree with the earlier comments on this thread from yourself, Adrian
and Deborah.  The arguments being presented to support this interworking
contain many unsubstantiated assertions.  When each of the technical details
are considered in isolation they look reasonable.
However, as you have demonstrated, when they are all assembled into the full
network picture the flaws in the logic and the horrendous complexity become
apparent. 

Malcolm Betts
Nortel Networks

-----Original Message-----
Of [email-masked]

regards, Neil

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 13:27:56 -0000

Maarten,

You are wrong about all this.

> Such layer network interworking has been specified for a 
> number of layer networks in the past: i.e. VC-4-4c and VC-4, 
> ATM and FR, ATM and MPLS. Now we have to extend this set with 
> a layer network interworking for ETH and MPLS-TP MS-PW.

NH=> Have you really studied these I wonder?  One has to consider every
aspect of the DP and CP (we would usually never interwork the MP), and
one area that is generally overlooked are the end-system DP application
adaptation functions....and if the technology in question is NOT
top-of-stack there is no case for interworking the server layers at all,
period....one merely terminates them and passes the higher layer network
client across transparently.

So we only need to consider interworking for top-of-stack layer
networks.  And if these are going to interwork successfully then one
needs to pay special attention to the end-system applications adaptation
functions for the message/file/stream cases.  IP has UDP/TCP/RTP, ATM
had several AALs, Eth has none, MPLS has none, SDH has none, etc,
etc....and those with 'none' have no interworking case to
consider...sure you can force it (many folks keep pushing this, esp
yourself) but there is no requirement for such unnecessary work/cost. 

Let's consider THE most (only?) real case of peer interworking to
date....ATM/FR as found in FRF8 say.  Most of this is concerned with
mitigating all the differences between DP/CP functions of the 2
technologies, eg no BECN in ATM, etc....and please don't tell me this is
easy/simple as it's not.

However, its quite clear that when writing this they realised they had
better pay some attention to what application clients were being
carried.  If you look in here you will find out how the message/file
adaptation interworking is handled (largely a protocol conversion job),
but when it comes to the stream case all there is handwaving.  Hardly
satisfactory IMO. 

I'm not quite sure where the ATM/MPLS interworking stuff is at, but way
back Dave Allan and I wrote Y.1712 that discusses merely the OAM
interworking (because I.610 and Y.1711 have a lot of similarities).
However, I told Dave at the time that I was not at all happy with doing
this as interworking is far more than just OAM....it is every DP/CP
component and we would NOT have any sort of close alignment here even
though both technologies belong to the same (co-ps) mode.  In particular
MPLS has no applications adaptation functions for message/file/stream,
whereas ATM has all the AALs. So pray tell me what would do about this?

> 
> The rationale for such layer network interworking is the 
> reduction of equipment and network management complexity,

NH=> Total rot.  You are simply going to create massive complexity and
interworking costs....and none of this is necessary.  Please learn from
history and the hints I have given you a glimpse of above.

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 18:03:09 +0100

Neil,

> "if all technologies were identical in all aspects then why would we need
> them all....forget the cost of interworking them, just get rid of them!" 

Initially in 2002 NTT and Lucent introduced Ethernet VLAN technology as
packet transport network technology in ITU-T SG13 and SG15. Then in 2003
Alcatel and BT kicked of work on T-MPLS as an alternative packet transport
technology in Q.12/15. Then in 2005 BT and Nortel introduced yet another
alternative packet transport network technology: PBT. In 2008 T-MPLS
development got redirected to MPLS-TP. All those technologies are intended
to support the same set of services and deploy the same SDH-like network
management. These technologies will be equal with only minor differences.

Looking into the networks today, I find Ethernet VLAN and MPLS technologies
being deployed extensively. Both technologies are being upgraded at the
moment to support packet transport networking; Ethernet VLAN transport
profile standardization work is mostly completed (we have Y.1731, G.8021,
G.8031, G.8032 and G.8051 done and G.8052 is udner development), MPLS-TP
standardization work is progressing rapidly at this moment.

Most operators have more then one packet (transport) network technology in
their networks. One technology would be sufficient, but I don't see any
indication that all operators agree to use just one technology. I don't
believe that each operator will just use one technology; most likely a mix
of Ethernet VLAN and MPLS based packet transport technologies will be
deployed in the coming years... 

Standards organisations should recognize that there are at least two
technologies being deployed for a long term and make sure that those
technologies interoperate seamlessly, which will keep the cost of
interworking very low. 

Equipment manufacturers will have to build in the near future UNI-N, I-NNI
and E-NNI port cards that support Ethernet VLAN and MPLS-TP to support
existing operator demands, and perhaps also PBT if there would be a real
demand. Switch fabrics today already support those technologies. Any
unnecessary difference between Ethernet VLAN and MPLS-TP will complicate the
future UNI-N, I-NNI and E-NNI ports and should as such be prevented. 

Future packet transport network equipment, specifically the S-PE type of
equipment, will have to be able to talk Ethernet VLAN at one set of I-NNI
ports (e.g. facing metro) and MPLS-TP on another set of I-NNI ports (e.g.
facing core). Within a core or metro domain I expect to find a single
technology; either Ethernet VLAN, or MPLS-TP. 

In carrier-carrier applications I expect to see Ethernet tunnel or section
VLANs to be carried as a service instance through another Ethernet VLAN
network or through an MPLS-TP network, as well as MPLS-TP tunnel or section
LSPs to be carried as a service instance through another MPLS-TP network or
through an Ethernet VLAN network.

The Ethernet VLAN and MPLS-TP equipment models I am working on will support
the above cases. For Ethernet VLAN I have published a first version and I am
now translating this into an MPLS-TP version (which will be available early
January).

As long as the operators do not agree to use a single technology, it seems
important (in my opinion) to restrict the complexity of the unavoidable
interworking to a minimum. And it is possible to meet this objective, as I
have been showing.

Regards,
Maarten

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 09:16:36 -0800

Maarten,

Actually, I think MPLS TP boxes might use ethernet VLAN p2p connections,
along with many other technologies, for trunking.  This reduces the
internetworking cost, both development and deployment to zero.

They really are different layer networks. 

Thanks,

John 

>Sent: Thursday, December 18, 2008 9:03 AM
>> "if all technologies were identical in all aspects then why would we 
>> need them all....forget the cost of interworking them, just 
>get rid of them!"
>
>Initially in 2002 NTT and Lucent introduced Ethernet VLAN 
>technology as packet transport network technology in ITU-T 
>SG13 and SG15. Then in 2003 Alcatel and BT kicked of work on 
>T-MPLS as an alternative packet transport technology in 
>Q.12/15. Then in 2005 BT and Nortel introduced yet another 
>alternative packet transport network technology: PBT. In 2008 
>T-MPLS development got redirected to MPLS-TP. All those 
>technologies are intended to support the same set of services 
>and deploy the same SDH-like network management. These 
>technologies will be equal with only minor differences.
>
>Looking into the networks today, I find Ethernet VLAN and MPLS 
>technologies being deployed extensively. Both technologies are 
>being upgraded at the moment to support packet transport 
>networking; Ethernet VLAN transport profile standardization 
>work is mostly completed (we have Y.1731, G.8021, G.8031, 
>G.8032 and G.8051 done and G.8052 is udner development), 
>MPLS-TP standardization work is progressing rapidly at this moment.
>
>Most operators have more then one packet (transport) network 
>technology in their networks. One technology would be 
>sufficient, but I don't see any indication that all operators 
>agree to use just one technology. I don't believe that each 
>operator will just use one technology; most likely a mix of 
>Ethernet VLAN and MPLS based packet transport technologies 
>will be deployed in the coming years... 
>
>Standards organisations should recognize that there are at 
>least two technologies being deployed for a long term and make 
>sure that those technologies interoperate seamlessly, which 
>will keep the cost of interworking very low. 
>
>Equipment manufacturers will have to build in the near future 
>UNI-N, I-NNI and E-NNI port cards that support Ethernet VLAN 
>and MPLS-TP to support existing operator demands, and perhaps 
>also PBT if there would be a real demand. Switch fabrics today 
>already support those technologies. Any unnecessary difference 
>between Ethernet VLAN and MPLS-TP will complicate the future 
>UNI-N, I-NNI and E-NNI ports and should as such be prevented. 
>
>Future packet transport network equipment, specifically the 
>S-PE type of equipment, will have to be able to talk Ethernet 
>VLAN at one set of I-NNI ports (e.g. facing metro) and MPLS-TP 
>on another set of I-NNI ports (e.g.
>facing core). Within a core or metro domain I expect to find a 
>single technology; either Ethernet VLAN, or MPLS-TP. 
>
>In carrier-carrier applications I expect to see Ethernet 
>tunnel or section VLANs to be carried as a service instance 
>through another Ethernet VLAN network or through an MPLS-TP 
>network, as well as MPLS-TP tunnel or section LSPs to be 
>carried as a service instance through another MPLS-TP network 
>or through an Ethernet VLAN network.
>
>The Ethernet VLAN and MPLS-TP equipment models I am working on 
>will support the above cases. For Ethernet VLAN I have 
>published a first version and I am now translating this into 
>an MPLS-TP version (which will be available early January).
>
>As long as the operators do not agree to use a single 
>technology, it seems important (in my opinion) to restrict the 
>complexity of the unavoidable interworking to a minimum. And 
>it is possible to meet this objective, as I have been showing.
>
>Regards,
>Maarten
>
>
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 18:36:53 +0100

Neil,

I have presented the ETH/MPLS-TP PW Data Plane interworking aspects in
previous posts. Those interworking aspects can be absolutely trivial when we
choose the MPLS-TP OAM carefully. The ETH/MPLS-TP Management Plane
itnerworking aspects will be essentially zero as both technologies follow
the same SDH-like transport network management principles. The ETH/MPLS-TP
PW control plane itnerworking aspects will be essentially zero as well as
both technologies follow the same ASON/GMPLS transport network control plane
principles.

The major difference between this ETH<=>MPLS-TP PW interworking case and the
previous interworking cases is that
- the encapsulation of client signals into the two types of adapted
information was specified with interworking in mind and
- the specification of one of the two OAM message sets is still to be
developed.
This implies that we are ahead of the game and can make sure that this
interworking is trivial.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 18 december 2008 14:28
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] ETH and MS-PW layer network interworking [was: RE:
Carrying traffic over an MPLS-TP network]

Maarten,

> Such layer network interworking has been specified for a number of 
> layer networks in the past: i.e. VC-4-4c and VC-4, ATM and FR, ATM and 
> MPLS. Now we have to extend this set with a layer network interworking 
> for ETH and MPLS-TP MS-PW.

NH=> Have you really studied these I wonder?  One has to consider every
aspect of the DP and CP (we would usually never interwork the MP), and one
area that is generally overlooked are the end-system DP application
adaptation functions....and if the technology in question is NOT
top-of-stack there is no case for interworking the server layers at all,
period....one merely terminates them and passes the higher layer network
client across transparently.

So we only need to consider interworking for top-of-stack layer networks.
And if these are going to interwork successfully then one needs to pay
special attention to the end-system applications adaptation functions for
the message/file/stream cases.  IP has UDP/TCP/RTP, ATM had several AALs,
Eth has none, MPLS has none, SDH has none, etc, etc....and those with 'none'
have no interworking case to consider...sure you can force it (many folks
keep pushing this, esp
yourself) but there is no requirement for such unnecessary work/cost. 

However, its quite clear that when writing this they realised they had
better pay some attention to what application clients were being carried.
If you look in here you will find out how the message/file adaptation
interworking is handled (largely a protocol conversion job), but when it
comes to the stream case all there is handwaving.  Hardly satisfactory IMO. 

I'm not quite sure where the ATM/MPLS interworking stuff is at, but way back
Dave Allan and I wrote Y.1712 that discusses merely the OAM interworking
(because I.610 and Y.1711 have a lot of similarities).
However, I told Dave at the time that I was not at all happy with doing this
as interworking is far more than just OAM....it is every DP/CP component and
we would NOT have any sort of close alignment here even though both
technologies belong to the same (co-ps) mode.  In particular MPLS has no
applications adaptation functions for message/file/stream, whereas ATM has
all the AALs. So pray tell me what would do about this?

> equipment and network management complexity,

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 18:41:31 +0100

John,

Thanks for this feedback. Can you present the layer stack when MPLS-TP boxes
use ethernet VLAN p2p connections for trunking (i.e. as tunnel VLANs)...
Will this tunnel VLAN layer replace the MPLS-TP tunnel layer? 

Regards,
Maarten

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: donderdag 18 december 2008 18:17
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

Maarten,

Thanks,

John 

>packet transport network technology in ITU-T
>SG13 and SG15. Then in 2003 Alcatel and BT kicked of work on T-MPLS as 
>an alternative packet transport technology in Q.12/15. Then in 2005 BT 
>and Nortel introduced yet another alternative packet transport network 
>technology: PBT. In 2008 T-MPLS development got redirected to MPLS-TP. 
>All those technologies are intended to support the same set of services 
>and deploy the same SDH-like network management. These technologies 
>will be equal with only minor differences.
>
>technologies being deployed extensively. Both technologies are being 
>upgraded at the moment to support packet transport networking; Ethernet 
>VLAN transport profile standardization work is mostly completed (we 
>have Y.1731, G.8021, G.8031,
>G.8032 and G.8051 done and G.8052 is udner development), MPLS-TP 
>Most operators have more then one packet (transport) network technology 
>in their networks. One technology would be sufficient, but I don't see 
>any indication that all operators agree to use just one technology. I 
>don't believe that each operator will just use one technology; most 
>likely a mix of Ethernet VLAN and MPLS based packet transport 
>technologies will be deployed in the coming years...
>
>Equipment manufacturers will have to build in the near future UNI-N, 
>I-NNI and E-NNI port cards that support Ethernet VLAN and MPLS-TP to 
>support existing operator demands, and perhaps also PBT if there would 
>be a real demand. Switch fabrics today already support those 
>technologies. Any unnecessary difference between Ethernet VLAN and 
>MPLS-TP will complicate the future UNI-N, I-NNI and E-NNI ports and 
>should as such be prevented.
>
>Future packet transport network equipment, specifically the S-PE type 
>of equipment, will have to be able to talk Ethernet VLAN at one set of 
>I-NNI ports (e.g. facing metro) and MPLS-TP on another set of I-NNI 
>ports (e.g.
>In carrier-carrier applications I expect to see Ethernet tunnel or 
>section VLANs to be carried as a service instance through another 
>Ethernet VLAN network or through an MPLS-TP network, as well as MPLS-TP 
>tunnel or section LSPs to be carried as a service instance through 
>another MPLS-TP network or through an Ethernet VLAN network.
>
>The Ethernet VLAN and MPLS-TP equipment models I am working on will 
>support the above cases. For Ethernet VLAN I have published a first 
>version and I am now translating this into an MPLS-TP version (which 
>will be available early January).
>
>As long as the operators do not agree to use a single technology, it 
>seems important (in my opinion) to restrict the complexity of the 
>unavoidable interworking to a minimum. And it is possible to meet this 
>objective, as I have been showing.
>
>Regards,
>Maarten
>
>
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 18 Dec 2008 12:45:38 -0500

Maarten:

>> need them all....forget the cost of interworking them, just get rid
of them!"

<snipped> 
>All those technologies are intended to support the same set of services
and deploy the same SDH-like network management. 
>These technologies will be equal with only minor differences.

While I get your point that there are many hammers for a given nail, I
have trouble believing these technologies are the same with only minor
differences, that is a gross simplification...the quality of information
in the frame is different in scope for just about every technology
enumerated (PBT included), implying different modes of failure and other
differences in operational characteristics. Artificially attempting to
harmonize the quality of both operational behavior and quality of
information that can be abstracted, while noble, is doomed to failure.
So what they do may have commonalities, how they do it is significantly
different, which is one reason for the plethora of solutions on the
market today.

<snipped>

> Equipment manufacturers will have to build in the near future UNI-N,
I-NNI and E-NNI port cards that support Ethernet 
> VLAN and MPLS-TP to support existing operator demands, and perhaps
also PBT if there would be a real demand. 

If multiple vendors PBT implementations being deployed can be
interpreted as demand, count PBT in...Your comment suggests there is
some other definition of "demand"...

> Switch fabrics today already support those technologies. Any
unnecessary difference between Ethernet VLAN and MPLS-TP 
> will complicate the future UNI-N, I-NNI and E-NNI ports and should as
such be prevented. 

If we are discussing IEEE standard Ethernet, there are more differences
than commonalities...in terms of the hierarchy of identifiers you can
possibly use in the network the dataplanes operate at different points
in the stack.... 

<snipped>

> As long as the operators do not agree to use a single technology, it
seems important (in my opinion) to restrict the 
> complexity of the unavoidable interworking to a minimum. And it is
possible to meet this objective, as I have been 
> showing.

What you appear to be arguing for is that there is no differentation
between technologies, in which case your plea for harmonization holds
water....

However the belief that technologies are not differentiated, and each
has been deployed for whimsical or undefined reasons does not....so the
cards at the bottom of the house in your argument are not stable....

Cheers
Dave

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 09:47:01 -0800

>Sent: Thursday, December 18, 2008 9:42 AM
>To: Drake, John E; [email-masked]; [email-masked]
>Thanks for this feedback. Can you present the layer stack when 
>MPLS-TP boxes use ethernet VLAN p2p connections for trunking 
>(i.e. as tunnel VLANs)...

JD:  Imagine today's use of ethernet VLANs by MPLS.   

>Will this tunnel VLAN layer replace the MPLS-TP tunnel layer?

JD:  Um, no.  
 
>Actually, I think MPLS TP boxes might use ethernet VLAN p2p 
>connections, along with many other technologies, for trunking. 
> This reduces the internetworking cost, both development and 
>deployment to zero.
>
>technology as 
>T-MPLS as 
>technology

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 18:55:48 -0000

Dave,  largely agree.

If anyone truly wants to understand why we have the 3 networks modes etc
then I would urge them to try and get to grips with G.800 (unified
modelling of networks).  This is mostly the work of Andy Reid and it's
one of the most profound pieces of work I have seen in a very long time.
More recently I've also seen a recent internal paper where Andy derives
Shannon's classical result for defining information content (ie p log
(p)) from this stuff (in Shannon's original paper he just presents this
result as a fait accomplii with no real justification for where it comes
from, just that 'it fits' and what its consequences are)....however this
is not in G.800 right now.  I expect he'll publish this in due course
however.

Anyway, and as I seem to have to keep saying, ...the 3 network modes
have fundamental differences (it's why they are so enduring) and it
would the height of folly/madness to try and do what Maarten seems to
want to do by making them all look alike and then attempting to
interwork them.  And if you did achieve this (which you won't) then the
ONLY logical conclusion is that all of them apart from one are
unncessary, ie if they are truly alike why have them and (more
foolishly) incur the costs of interworking them.

Totally barking....

regards, neil 

> From: David Allan [mailto:[email-masked]] 
> Sent: 18 December 2008 17:46
> To: Maarten Vissers; Harrison,N,Neil,CXM R; [email-masked]
> While I get your point that there are many hammers for a 
> given nail, I have trouble believing these technologies are 
> the same with only minor differences, that is a gross 
> simplification...the quality of information in the frame is 
> different in scope for just about every technology enumerated 
> (PBT included), implying different modes of failure and other 
> differences in operational characteristics. Artificially 
> attempting to harmonize the quality of both operational 
> behavior and quality of information that can be abstracted, 
> while noble, is doomed to failure.
> So what they do may have commonalities, how they do it is 
> significantly different, which is one reason for the plethora 
> of solutions on the market today.
> 
> <snipped>
> 
> interpreted as demand, count PBT in...Your comment suggests 
> there is some other definition of "demand"...
> 
> If we are discussing IEEE standard Ethernet, there are more 
> differences than commonalities...in terms of the hierarchy of 
> identifiers you can possibly use in the network the 
> dataplanes operate at different points in the stack.... 
> 
> <snipped>
> 
> What you appear to be arguing for is that there is no 
> differentation between technologies, in which case your plea 
> for harmonization holds water....
> 
> However the belief that technologies are not differentiated, 
> and each has been deployed for whimsical or undefined reasons 
> does not....so the cards at the bottom of the house in your 
> argument are not stable....
> 
> Cheers
> Dave
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 08:40:13 +0100

Dave,

Every multi-domain transport network technology has 
1) a service related layer in which each transport entity has a 1-to-1
relationship with a customer service
2) a tunnel related layer
3) a transmission media related layer, consisting of a physical media layer
and a physical media monitoring layer.

The packet transport network technologies differ mainly in the applied
tunnel technology; i.e.
A) p2p VLAN tunnel
B) p2p MAC tunnel (called TESI)
C) p2p MPLS-TP tunnel.

The packet transport netowrk technologies have large commonality in the
applied service technology; i.e.
A) service VLAN (p2p, p2mp, rmp, mp2mp)
B) service VLAN (p2p, p2mp, rmp, mp2mp)
C) service VLAN (called VPLS, rmp, mp2mp) and MS-PW (p2p, p2mp).

Interworking is required between the transport entities in these service
layers... Between service VLAN transport entities interworking is
guaranteed... So that only leaves itnerworking between p2p and p2mp service
VLAN and p2p and p2mp MS-PW... And those two transport entities are similar
and itnerworking can be performed without problems.

Regards,
Maarten

-----Original Message-----
From: David Allan [mailto:[email-masked]] 
Sent: donderdag 18 december 2008 18:46
To: Maarten Vissers; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Carrying traffic over an MPLS-TP network

of them!"

<snipped> 
>These technologies will be equal with only minor differences.

While I get your point that there are many hammers for a given nail, I have
trouble believing these technologies are the same with only minor
differences, that is a gross simplification...the quality of information in
the frame is different in scope for just about every technology enumerated
(PBT included), implying different modes of failure and other differences in
operational characteristics. Artificially attempting to harmonize the
quality of both operational behavior and quality of information that can be
abstracted, while noble, is doomed to failure.
So what they do may have commonalities, how they do it is significantly
different, which is one reason for the plethora of solutions on the market
today.

<snipped>

If multiple vendors PBT implementations being deployed can be interpreted as
demand, count PBT in...Your comment suggests there is some other definition
of "demand"...

such be prevented. 

If we are discussing IEEE standard Ethernet, there are more differences than
commonalities...in terms of the hierarchy of identifiers you can possibly
use in the network the dataplanes operate at different points in the
stack.... 

<snipped>

> showing.

What you appear to be arguing for is that there is no differentation between
technologies, in which case your plea for harmonization holds water....

However the belief that technologies are not differentiated, and each has
been deployed for whimsical or undefined reasons does not....so the cards at
the bottom of the house in your argument are not stable....

Cheers
Dave

---

From: <[email-masked]>
Date: Mon, 22 Dec 2008 10:29:51 -0000

Maarten,  You are just so very wrong in your assertions here.  I and my
fellow BT colleagues cannot afford to let you steer the industry down
another path of expensive mistakes.  I have so far seen no support
(operator or vendor) for your position.

I will not repeat my arguments here, but refer you to my previous posts
wher I have irrefutably shown why interworking between non-top-of stack
layer networks (public service network if this makes it easier to
visualise) is a technical non-issue.  

regards, Neil 

> Sent: 22 December 2008 07:40
> To: 'David Allan'; Harrison,N,Neil,CXM R; [email-masked]
> 1) a service related layer in which each transport entity has 
> a 1-to-1 relationship with a customer service
> 3) a transmission media related layer, consisting of a 
> physical media layer and a physical media monitoring layer.
> 
> The packet transport network technologies differ mainly in 
> the applied tunnel technology; i.e.
> A) p2p VLAN tunnel
> The packet transport netowrk technologies have large 
> commonality in the applied service technology; i.e.
> Interworking is required between the transport entities in 
> these service layers... Between service VLAN transport 
> entities interworking is guaranteed... So that only leaves 
> itnerworking between p2p and p2mp service VLAN and p2p and 
> p2mp MS-PW... And those two transport entities are similar