Subject: [mpls-tp] Minimizing peer-interworking cases

From: Maarten Vissers <[email-masked]>
Date: Wed, 25 Mar 2009 08:51:23 +0100

I have created a few slides to illustrate the peer-interworking cases 
that are associated with the Ethernet and PDH Circuit Emulation service
cases.

The number of peer-interworking cases depends on the choice of 
transport service layer in/associated with MPLS-TP.

A) we select the EVC layer as generic transport service layer in/associated 
   with MPLS-TP. The EVC supports in this case p2p, p2mp, rmp and mp2mp
services.

B) we select the EVC layer as rmp/mp2mp transport service layer and 
   we select the MPLS-TP VC (MS-PW) as p2p/p2mp transport service layer
   in/associated with MPLS-TP.

NOTE - it is not clear to me if the transport service layer is considered to
be 
an integral part of MPLS-TP or is outside of MPLS-TP. If the former, then
the
transport service layer is "in MPLS-TP", if the latter then the transport 
service layer is "associated with MPLS-TP".

For case A there is a need to provide peer-interworking
1) between IP/MPLS and the Ethernet/MPLS-TP packet transport networks 
   for the PDH Circuit Emulation services.

For case B there is a need to provide peer-interworking
1) between IP/MPLS and the Ethernet/MPLS-TP packet transport networks 
   for the PDH Circuit Emulation services
2) Ethernet and MPLS-TP for PDH Circuit Emulation services
3) Ethernet and MPLS-TP for E-LINE services
4) IP/MPLS and MPLS-TP for E-LINE services
5) IP/MPLS and MPLS-TP for PDH Circuit Emulation services.

My conclusion is therefore that the introduction of a MPLS-TP VC (MS-PW)
transport
service layer for p2p and p2mp services (case B) requires more
peer-interworking 
then the case A in which the EVC is deployed as generic transport service
layer 
in/associated with MPLS-TP.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 26 Mar 2009 05:54:18 +0100

Neil,

I have not yet seen a response from you on those peer-interworking cases.
- Case 1 is a real case present today.
- Cases 2 to 5 could become real cases if we decide to introduce a MPLS-TP
  based transport service layer (I refer to it as an MPLS(-TP) VC layer in
  analogy with the Ethernet VC (EVC) layer).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: woensdag 25 maart 2009 8:51
To: [email-masked]
Subject: [mpls-tp] Minimizing peer-interworking cases

I have created a few slides to illustrate the peer-interworking cases that
are associated with the Ethernet and PDH Circuit Emulation service cases.

The number of peer-interworking cases depends on the choice of transport
service layer in/associated with MPLS-TP.

NOTE - it is not clear to me if the transport service layer is considered to
be an integral part of MPLS-TP or is outside of MPLS-TP. If the former, then
the transport service layer is "in MPLS-TP", if the latter then the
transport service layer is "associated with MPLS-TP".

My conclusion is therefore that the introduction of a MPLS-TP VC (MS-PW)
transport service layer for p2p and p2mp services (case B) requires more
peer-interworking then the case A in which the EVC is deployed as generic
transport service layer in/associated with MPLS-TP.

Regards,
Maarten

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 09:12:34 -0000

Maarten Vissers wrote 26 March 2009 04:54 <snipped>
>   analogy with the Ethernet VC (EVC) layer).

You know my view here...which is simply this:

**Peer-interworking of networks that are not top-of-stack is unnecessary
and will simply generate problems/costs.**

I will repeat the logic here for one last time:

1	All networks exist to serve one purpose and one purposes
only....to allow communications (in message/file/stream form) between
external entities.

2	Any networks we create have therefore only one of two roles (i)
they are designed to directly support these external communications
(what I have called 'top-of-stack' networks, eg Internet/IP) or (ii)
they create the topology of higher level networks (that may or may not
be top-of-stack, eg OTN/PDH/SDH/Ethernet/MPLS)
.....**but ultimately there MUST be a top-of-stack network present else
there is no point in networking at all.**

3	When we are considering a network that is NOT top-of-stack then
we are providing a *transport* network role....and the key (topology
creation) service that such networks provide is client/server
transparency.  Transparency is THE key word here, and it means this:
	* all client bits (more generally symbols) MUST be treated
equally by the server
	* the sequence ordering of client bits MUST be preserved
	* there MUST NOT be any attempt to infer meaning of the client
bits and they MUST NOT be changed by the server
	* the traffic behaviour of client X SHOULD NOT impact the
performance experienced by client Y (this becomes MUST NOT for
full-sufficiency wrt performance transparency)

4	It therefore follows that for networks that are NOT top-of-stack
they MUST be supporting a higher layer network (which may or may not be
top-of-stack).  And this means that there is no need whatsoever to peer
interwork networks that are NOT top-of-stack.....they should simply be
transporting their client layer networks in a transparent manner and
passing these across at the interworking point.  In fact, creating
peer-interworking (which MUST consider all DP/CP/MP components and not
simply DP OAM) can be seen to achieve nothing useful, as at the end of
such a sequence of peer-interworked networks we still have to go up to
the client layer network and pass it transparently anyway.....and so we
clearly observe that we might as well have done this in the first place
and avoided all the peer-interworking problems/costs.

The logic here is totally irrefutable and IMO very simple/obvious.

There are 3 increasingly more crazy cases for peer-interworking here:
-	where the 2 networks belong to the SAME mode and have identical
DP/CP/MP components but are nevertheless not top-of-stack.....so this is
the UNI/E-NNI stuff advocated by OIF, MEF and MPLSF as all these
networks are not top-of-stack
-	where the 2 networks belong to the SAME mode but are different
technologies and thus have a varying degree of functional mismatch
between DP/CP/MP components, and at least one of these networks is not
top-of-stack 
-	where the 2 networks belong to DIFFERENT modes with a generally
large functional mismatch between DP/CP/MP components and at least one
of these networks is not top-of-stack.....this is the
MPLS/MPLS-TP/Ethernet(PBB/PBB-TE) case

I would say those who are advocating peer-interworking in full knowledge
of the above facts are acting in a professionally irresponsible manner
IMO.

So I see no point in discussing this any further with you and that is
why I stopped responding to you on this topic.

I know of no one in BT who agrees with you on this, but I know plenty of
people in BT (and outside BT) who disagree with you. 

regards, Neil

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 26 Mar 2009 08:49:52 -0700

+1 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, March 26, 2009 2:13 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Minimizing peer-interworking cases
> 
> **Peer-interworking of networks that are not top-of-stack is 
> unnecessary and will simply generate problems/costs.**
> 
> only....to allow communications (in message/file/stream form) 
> between external entities.
> 
> 
> they are designed to directly support these external 
> communications (what I have called 'top-of-stack' networks, 
> eg Internet/IP) or (ii) they create the topology of higher 
> level networks (that may or may not be top-of-stack, eg 
> OTN/PDH/SDH/Ethernet/MPLS) .....**but ultimately there MUST 
> be a top-of-stack network present else there is no point in 
> networking at all.**
> 
> 
> 	* all client bits (more generally symbols) MUST be 
> treated equally by the server
> 	* there MUST NOT be any attempt to infer meaning of the 
> client bits and they MUST NOT be changed by the server
> 	* the traffic behaviour of client X SHOULD NOT impact 
> the performance experienced by client Y (this becomes MUST 
> NOT for full-sufficiency wrt performance transparency)
> 
> 
> they MUST be supporting a higher layer network (which may or 
> may not be top-of-stack).  And this means that there is no 
> need whatsoever to peer interwork networks that are NOT 
> top-of-stack.....they should simply be transporting their 
> client layer networks in a transparent manner and passing 
> these across at the interworking point.  In fact, creating 
> peer-interworking (which MUST consider all DP/CP/MP 
> components and not simply DP OAM) can be seen to achieve 
> nothing useful, as at the end of such a sequence of 
> peer-interworked networks we still have to go up to the 
> client layer network and pass it transparently anyway.....and 
> so we clearly observe that we might as well have done this in 
> the first place and avoided all the peer-interworking problems/costs.
> 
> DP/CP/MP components but are nevertheless not 
> top-of-stack.....so this is the UNI/E-NNI stuff advocated by 
> OIF, MEF and MPLSF as all these networks are not top-of-stack
> technologies and thus have a varying degree of functional 
> mismatch between DP/CP/MP components, and at least one of 
> these networks is not top-of-stack 
> large functional mismatch between DP/CP/MP components and at 
> least one of these networks is not top-of-stack.....this is the
> I would say those who are advocating peer-interworking in 
> full knowledge of the above facts are acting in a 
> professionally irresponsible manner IMO.
> 
> 
> So I see no point in discussing this any further with you and 
> that is why I stopped responding to you on this topic.
> 
> I know of no one in BT who agrees with you on this, but I 
> know plenty of people in BT (and outside BT) who disagree with you. 
> 
> regards, Neil
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 26 Mar 2009 13:16:50 -0400

All, I will not comment on the need for peer interworking in a Packet
Transport Network. However, I would like to focus on one point that
should allow us to decouple this debate from the development of MPLS-TP.

The key point I would like to get agreement on is that, MPLS-TP only
supports client server interworking. i.e. all client are encapsulated by
an adaptation at the edge of an instance of a MPLS-TP network and are
carried transparently across that MPLS-TP network.

This is strictly client server interworking.  Any peer interworking
between different packet transport network domains, if required, is
performed by the client specific part of the adaptation function.
Clearly a common implementation will place all of these functions in a
single "box".  However, these separable logical function that we can
define independently.

If we can agree on this point then we can continue with the definition
of MPLS-TP without first having to reach agreement on the peer
interworking cases. 

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: Thursday, March 26, 2009 5:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

2	Any networks we create have therefore only one of two roles (i)
they are designed to directly support these external communications
(what I have called 'top-of-stack' networks, eg Internet/IP) or (ii)
they create the topology of higher level networks (that may or may not
be top-of-stack, eg OTN/PDH/SDH/Ethernet/MPLS) .....**but ultimately
there MUST be a top-of-stack network present else there is no point in
networking at all.**

regards, Neil

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 26 Mar 2009 11:47:56 -0700

+1 

> From: Malcolm Betts [mailto:[email-masked]] 
> Sent: Thursday, March 26, 2009 10:17 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> All, I will not comment on the need for peer interworking in 
> a Packet Transport Network. However, I would like to focus on 
> one point that should allow us to decouple this debate from 
> the development of MPLS-TP.
> 
> The key point I would like to get agreement on is that, 
> MPLS-TP only supports client server interworking. i.e. all 
> client are encapsulated by an adaptation at the edge of an 
> instance of a MPLS-TP network and are carried transparently 
> across that MPLS-TP network.
> 
> This is strictly client server interworking.  Any peer 
> interworking between different packet transport network 
> domains, if required, is performed by the client specific 
> part of the adaptation function.
> Clearly a common implementation will place all of these 
> functions in a single "box".  However, these separable 
> logical function that we can define independently.
> 
> If we can agree on this point then we can continue with the 
> definition of MPLS-TP without first having to reach agreement 
> on the peer interworking cases. 
> 
> 
> Malcolm Betts
> Nortel Networks
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 20:00:38 -0000

Make that +2....let's get MPLS-TP defined as best we can and park any
notion of peer interworking it with anything else....though for non
top-of-stack technologies this is really a no brainer IMO.  regards,
Neil 

> From: Drake, John E [mailto:[email-masked]] 
> Sent: 26 March 2009 18:48
> To: Malcolm Betts; Harrison,N,Neil,CXM R; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] Minimizing peer-interworking cases
> 
> +1 
> 
> > > I have not yet seen a response from you on those 
> peer-interworking 
> > > cases.
> > > - Cases 2 to 5 could become real cases if we decide to 
> introduce a 
> > > MPLS-TP

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Mar 2009 23:06:29 +0000

Malcolm,

You know my view but for the benefit of the list I completely agree with you
here.

Ben

---

From: "Mark Sandstrom" <[email-masked]>
Date: Thu, 26 Mar 2009 20:20:18 -0400

+3

Regards,
Mark Sandstrom
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, March 26, 2009 2:01 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 26 Mar 2009 20:35:12 -0400

+4

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Sandstrom
Sent: Thursday, March 26, 2009 8:20 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

+3

Regards,
Mark Sandstrom

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 27 Mar 2009 10:03:18 -0400

Malcolm,

Very well put. Completely agree.

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Thursday, March 26, 2009 7:06 PM
To: Malcolm Betts; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

Malcolm,

Ben

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 28 Mar 2009 08:51:16 -0400

Malcolm,

Your point could be illustrated by the following consideration. According to MPLS-TP requirements both statically and dynamically provisioned LSPs must be supported. Although it was not explicitly stated this way, my understanding is that both static and dynamic LSPs could co-exist in the same network. The questions to ask are:
1) Is it OK if a dynamically provisioned MPLS-TP LSP serves static PWs?
2) Can a static MPLS-TP LSP serve dynamic PWs?
3) Generally speaking, can an MPLS-TP LSP (static or dynamic) serve multiple clients (PWs and other) some of them static and some dynamic managed by possibly different CPs?

My answer is Yes to all three, and if you agree with me, then it is obvious that MPLS-TP LSP layer and PW layer have nothing in common except for server-client relationship at the points of adaptation, and therefore should have separate requirements, frameworks, control planes, OAM, etc.

Cheers,
Igor  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm Betts
Sent: Thursday, March 26, 2009 1:17 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

Malcolm Betts
Nortel Networks

-----Original Message-----

regards, Neil

---

From: <[email-masked]>
Date: Sat, 28 Mar 2009 13:35:22 -0000

Hi Igor,

This is separate point which is very important in its own right.

What I was originally showing was that any layer network that is not
(what I have started to call) 'top-of-stack' has no need for
peer-partition interworking with any other layer network (including
itself between different parties....which is why the E-NNI stuff
advocated by technology promoting fora such as MEF, OIF and MPLSF is
quite unnecessary).  So this is just one technical fact.

You are raising quite a different technical fact here and it's something
I flagged to PWE3 a very long time ago now...and that is when PWs become
multi-hop they change their nature dramatically from simple adaptation
to a full-blown co-ps layer network.  This very nearly happened to GFP
way back, but folks alert to the problems this would create stopped it
in time.

So what you say below is quite accurate.  Moreover, you are correct in
observing that one now requires a full set of functional components
across the DP/CP/MP to manage PWs that are independent of their
server....which could be MPLS-TP.

The most disturbing thing here for me is that the architectural
behaviours in MPLS that gave rise to PWs in the first place must be
removed in MPLS-TP (indeed it can hardly be called a 'transport profile'
if it generates another co-ps layer network above it).  So to be
technically accurate PWs should not even exist in MPLS-TP.

However, knowing what shock/horror this will generate I am sure we will
keep them in name.  But what we must not do is create a co-ps mode PW
layer network above MPLS-TP.

Aside=> There is also an outstanding issue wrt to the nature of the PW
label here that is not properly resolved IMO.  I went through this in
some detail in my mail to PWE3 29 Nov 2008
http://www.ietf.org/mail-archive/web/pwe3/current/msg10115.html

regards, Neil

> From: Igor Bryskin [mailto:[email-masked]] 
> Sent: 28 March 2009 12:51
> Your point could be illustrated by the following 
> consideration. According to MPLS-TP requirements both 
> statically and dynamically provisioned LSPs must be 
> supported. Although it was not explicitly stated this way, my 
> understanding is that both static and dynamic LSPs could 
> co-exist in the same network. The questions to ask are:
> 3) Generally speaking, can an MPLS-TP LSP (static or dynamic) 
> serve multiple clients (PWs and other) some of them static 
> and some dynamic managed by possibly different CPs?
> 
> My answer is Yes to all three, and if you agree with me, then 
> it is obvious that MPLS-TP LSP layer and PW layer have 
> nothing in common except for server-client relationship at 
> the points of adaptation, and therefore should have separate 
> requirements, frameworks, control planes, OAM, etc.
> 
> Cheers,
> Igor  
> 
> [mailto:[email-masked]] On Behalf Of Malcolm Betts
> unnecessary
> may not be
> top-of-stack.....so this is
> full knowledge
> know plenty of

---

From: Maarten Vissers <[email-masked]>
Date: Sun, 29 Mar 2009 04:17:57 +0200

> So to be technically accurate PWs should not even exist in MPLS-TP.>
keep
> them in name.  But what we must not do is create a co-ps mode PW layer 
> network above MPLS-TP.

If we want global interconnectivity to support e.g. Ethernet Line/LAN/Tree
and 
TDM Line services, then we should put an EVC layer above the MPLS-TP LSP
layer. 
If we put a co-ps mode PW layer above the MPLS-TP LSP layer to support p2p
and 
p2mp Ethernet and TDM services, then we will jeopardize such global
interconnectivity
for those p2p and p2mp services. Note that global interconnectivity for rmp
and
mp2mp Ethernet services will not be jeopardized as those can only be
supported 
by EVCs.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: zaterdag 28 maart 2009 14:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

Hi Igor,

What I was originally showing was that any layer network that is not (what I
have started to call) 'top-of-stack' has no need for peer-partition
interworking with any other layer network (including itself between
different parties....which is why the E-NNI stuff advocated by technology
promoting fora such as MEF, OIF and MPLSF is quite unnecessary).  So this is
just one technical fact.

You are raising quite a different technical fact here and it's something I
flagged to PWE3 a very long time ago now...and that is when PWs become
multi-hop they change their nature dramatically from simple adaptation to a
full-blown co-ps layer network.  This very nearly happened to GFP way back,
but folks alert to the problems this would create stopped it in time.

So what you say below is quite accurate.  Moreover, you are correct in
observing that one now requires a full set of functional components across
the DP/CP/MP to manage PWs that are independent of their server....which
could be MPLS-TP.

The most disturbing thing here for me is that the architectural behaviours
in MPLS that gave rise to PWs in the first place must be removed in MPLS-TP
(indeed it can hardly be called a 'transport profile'
if it generates another co-ps layer network above it).  So to be technically
accurate PWs should not even exist in MPLS-TP.

However, knowing what shock/horror this will generate I am sure we will keep
them in name.  But what we must not do is create a co-ps mode PW layer
network above MPLS-TP.

Aside=> There is also an outstanding issue wrt to the nature of the PW label
here that is not properly resolved IMO.  I went through this in some detail
in my mail to PWE3 29 Nov 2008
http://www.ietf.org/mail-archive/web/pwe3/current/msg10115.html

regards, Neil

> Your point could be illustrated by the following consideration. 
> According to MPLS-TP requirements both statically and dynamically 
> provisioned LSPs must be supported. Although it was not explicitly 
> stated this way, my understanding is that both static and dynamic LSPs 
> could co-exist in the same network. The questions to ask are:
> 3) Generally speaking, can an MPLS-TP LSP (static or dynamic) serve 
> multiple clients (PWs and other) some of them static and some dynamic 
> managed by possibly different CPs?
> 
> My answer is Yes to all three, and if you agree with me, then it is 
> obvious that MPLS-TP LSP layer and PW layer have nothing in common 
> except for server-client relationship at the points of adaptation, and 
> therefore should have separate requirements, frameworks, control 
> planes, OAM, etc.
> 
> Cheers,
> Igor
> 
> supports client server interworking. i.e. all client are encapsulated 
> by an adaptation at the edge of an instance of a MPLS-TP network and 
> are carried transparently across that MPLS-TP network.
> 
> 	* all client bits (more generally symbols) MUST be treated equally
by 
> the server
> 	* there MUST NOT be any attempt to infer meaning of the client bits 
> and they MUST NOT be changed by the server
performance 
> experienced by client Y (this becomes MUST NOT for full-sufficiency 
> wrt performance transparency)
> 
> 
> they MUST be supporting a higher layer network (which may or may not 
> be top-of-stack).  And this means that there is no need whatsoever to 
> peer interwork networks that are NOT top-of-stack.....they should 
> simply be transporting their client layer networks in a transparent 
> manner and passing these across at the interworking point.  In fact, 
> creating peer-interworking (which MUST consider all DP/CP/MP 
> components and not simply DP OAM) can be seen to achieve nothing 
> useful, as at the end of such a sequence of peer-interworked networks 
> we still have to go up to the client layer network and pass it 
> transparently anyway.....and so we clearly observe that we might as 
> well have done this in the first place and avoided all the 
> peer-interworking problems/costs.
> 
> DP/CP/MP components but are nevertheless not top-of-stack.....so this 
> is the UNI/E-NNI stuff advocated by OIF, MEF and MPLSF as all these 
> I would say those who are advocating peer-interworking in full 
> knowledge of the above facts are acting in a professionally 
> irresponsible manner IMO.
> 
> 
> I know of no one in BT who agrees with you on this, but I know plenty 
> of people in BT (and outside BT) who disagree with you.
> 
> regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 29 Mar 2009 16:03:02 +0000

Maarten,

I took a look but I am confused.

It looks to me that your "peer interworking" is in essence just handing a
PDH PW between domains?

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 30 Mar 2009 09:18:49 +0200

Ben,

My "peer interworking" cases illustrated are the handling of PDH CES between

different domains and handling of E-LINE service between different domains.
Other LINE service case handling (e.g. ATM, FR, ..) between different
domains
Can be derived from the PDH CES case.

1) slides 5: PDH circuit emulation service handling between a MPLS domain 
   carrying PDH signal over LSP (with PW label identifying client singal) 
   and either a MPLS-TP, or Ethernet domain carrying PDH signal over EVC.

2) slide 10: E-Line service handling between a MPLS-TP domain carrying the 
   Ethernet VLAN signal over a MS-PW and either a MPLS or Ethernet domain 
   carrying the Ethernet VLAN signal over an EVC. Peer interworking is 
   between MS-PW and EVC characteristic information.

3) slide 11: (A) PDH circuit emulation service handling between a MPLS
domain 
   carrying PDH signal over LSP (with PW label identifying client singal) 
   and Ethernet domain carrying PDH signal over EVC (i.e. copy of slide 5
case).

   (B) PDH circuit emulation service handling between a MPLS-TP domain 
   carrying PDH signal over MS-PW and Ethernet domain carrying PDH signal 
   over EVC.

   (C) PDH circuit emulation service handling between a MPLS-TP domain 
   carrying PDH signal over MS-PW and MPLS domain carrying PDH signal 
   over LSP.

Slide 6 illustrates the data frame/packet formats that are present on the 
wires at each side of the IWF #1. This IWF must interwork those frame/packet

formats to establish the end-to-end PDH CES connection. 

Slide 7 illustrates the data frame/packet formats that are present on the 
wires at each side of the IWF #2. This IWF must interwork those frame/packet

formats to establish the end-to-end PDH CES connection.

Slides 12/13 illustrate the data and OAM frame/packet formats that are 
present on the wires at each side of the IWF #5. This IWF must interwork 
those frame/packet formats to establish the end-to-end PDH CES connection.

It is possible to illustrate in the same detail the data and OAM
frame/packet
formats (associated with the Ethernet Line service) that are present on the 
wires at each side of IWF #3/#4.

Peer interworking is G.805 layer network interworking and is in essence a
very simple application.
Complexity arrives as soon as the two types of characteristic information
are very different.
Simplicity is present when the two types of characteristic information are
very common. 

And as we will have to guarantee interworking between ethernet and mpls
domains, 
we can not ignore the above layer network interworking cases.

The need for interworking is minimized when we choose the EVC as transport
service 
layer and carry everything in Ethernet domains, MPLS-TP domains and MPLS 
domains over an EVC.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: zondag 29 maart 2009 18:03
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] Minimizing peer-interworking cases

Maarten,

Ben

On 25/03/2009 07:51, "Maarten Vissers" <[email-masked]> wrote:

> that are associated with the Ethernet and PDH Circuit Emulation 
> service cases.
> 
>    with MPLS-TP. The EVC supports in this case p2p, p2mp, rmp and 
> mp2mp services.
> 
> NOTE - it is not clear to me if the transport service layer is 
> considered to be an integral part of MPLS-TP or is outside of MPLS-TP. 
> If the former, then the transport service layer is "in MPLS-TP", if 
> the latter then the transport service layer is "associated with 
> MPLS-TP".
> 
> My conclusion is therefore that the introduction of a MPLS-TP VC 
> (MS-PW) transport service layer for p2p and p2mp services (case B) 
> requires more peer-interworking then the case A in which the EVC is 
> deployed as generic transport service layer in/associated with 
> MPLS-TP.
> 
> Regards,
> Maarten