Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess

From: <[email-masked]>
Date: Fri, 13 Mar 2009 13:23:22 -0000

Thanks Shahram...nice to hear from you.  Have responded in-line.

________________________________

	From: Shahram Davari [mailto:[email-masked]] 
	Sent: 13 March 2009 12:50
	To: Harrison,N,Neil,CXM R; [email-masked];
[email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAM ExtractionProcess

	Hi Neil,
	 
	I think what Martin is saying is this:
	 
	Assume there are two network providers, one is using MPLS-TP and
the other using PBB-TE as transport.  And a service provider wants to
provide a service (say IP service or ATM service) across these two
network providers. If both of these network providers first map their
services over Ethernet 
	NH=> Why do this?  If one has the stack (where X is some layer
network, any):
	 
	XoverMPLS-TPoverGFPoverSDH (for arguments sake) and
XoverGFPoverPBB-TE then we simply terminate everything up to X at the
gateway and just pass X across.
	 
	  and then over their transport technology, 
	NH=> But PBB-TE can run directly on wire.....it really can be a
transport network.
	 
	  then Ethernet could be a unifying layer and these two networks
could interwork without any problem. 
	NH=> You could make GFP the unifying *adaptation*...and I
emphasise this because we do not want to create a layer network out of
GFP....as we need a common/generic adaptation function.  And GFP is that
common/generic adaptation function for current transport networks.
	 
	  However, if one maps the service to MPLS-TP and the other maps
the same service to PBB-TE, they can't interwork (complex interworking)
because there is no shared layer. 
	NH=> This is missing the point.  *The* common layer is X.  If
you want a common adpatation then look at GFP. 
	 
	But I have another suggestions: 
	 
	Assuming that PW or any other method is used for mapping a
service to MPLs-TP, let's make sure the same mapping method (PW or
others) are used by IEEE for PBB -TE or other Ethernet based transports.

	NH=> Well, Ethernet does have an Ethertype for GFP. 
	 
	 Just remember the simple rule, and its fairly easy to figure
out:  If 2 layer networks are not top-of-stack then there is no need to
have them interwork as peers....because by definition (of not being
top-of-stack) they *must* have a common higher network (X in the example
I gave above).  If this is not understood we can end up creating huge
amounts of unncessary work/cost for no real benefit.
	 
	regards, Neil
	 
	Bets regards,
	Shahram 
	 
	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: March-13-09 5:07 AM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in
OAM ExtractionProcess
	 
	And good morning to you too Maarten.......

________________________________

		From: Maarten Vissers
[mailto:[email-masked]] 
		Sent: 13 March 2009 07:39
		To: Harrison,N,Neil,CXM R; [email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: RE: [mpls-tp] MPLS-TP protocol/payload type
usage in OAM ExtractionProcess
		Hello Neil,
		 
		Good morning.
		Thank you for responding.

________________________________

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: vrijdag 13 maart 2009 7:33
		To: [email-masked]; [email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: RE: [mpls-tp] MPLS-TP protocol/payload type
usage in OAM ExtractionProcess
		Nice pictures Maarten, but all of this is not required:
		 
		-    there cannot be MS-PWs in MPLS-TP....MS-PWs
represent a co-ps layer network above MPLS-TP.  If this is true then
MPLS-TP has failed as a transport network. 
		 
		[mv] As far as I understand the MPLS-TP requirements,
there is a "transport service layer" in MPLS-TP. Do you agree? 
		NH=> I have no idea what this term means.   MPLS-TP is
supposed to be a transport network....just like a load of others are.
		 
		[mv] It seems that we are struggling with the name of
this "transport service layer". If I understand your persistent comment
well, then you do not like to refer to this transport service layer as
the "PW" layer. 
		NH=> Let's be very clear here.  MPLS-TP is supposed to
be a transport network itself...this is whole purpose of the exercise.
PWs started life as an adaptation to get around architectural flaws in
MPLS.  Unfortunately, PWE3 decided several years ago to make PWs
multi-hop...and as soon as they did that there was a major shift in what
PWs represented....they were no longer adaptation but a full-blown co-ps
layer network.  This was a bad mistake, and I repeatedly warned PWE3 not
to do this.  
		 
		The architectural flaws in MPLS that spawned PWs *must*
be corrected in MPLS-TP...else, quite simply, it cannot be a transport
network.  I do think most folks understand this.  So, we cannot have
MS-PWs in MPLS-TP...unless we want MPLS-TP to look very silly.

		  At some point in time I got the impression that you
would like to deploy a second instance of the MPLS-TP LSP as transport
service layer. 
		NH=> We are supposed to designing MPLS-TP to be a non
top-of-stack co-ps mode transport network, so all it can do is create
higher layer network topology....nothing unusual here, we have lots of
technologies that provide such a role, esp in the co-cs mode.
		  
		When I look at what is present in a number of networks
today, then I find the use of an Ethernet VLAN layer as transport
service layer in existing MPLS networks. 
		NH=> I don't understand why you home-in on VLANs.
Ethernet in-total is used as a server to MPLS.....MPLS does not have a
physical/section layer specification and so must run over a technology
that does, ie can modulate an EM wave on radio/optics/metrallic
media.....which actually is not a great place to start for a technology
that aspires to be a *transport* network if you think about it. 
		 
		  This use of an Ethernet VLAN layer as transport
service layer would be aligned MEF's MEN model in which the EVC (i.e.
Ethernet VLAN) is providing the transport service layer role.  This EVC
layer is then supported by the MEN Transport layer, which could be
another Ethernet VLAN instance, or MPLS LSP or MPLS-TP LSP or PBB-TE
TESI, or ...,  
		NH=> I am not sure what your point is here.  There is no
such thing as 'VLAN layer networks'....there are 'Ethernet layer
networks' however. 
		 
		-    there must be no interworking of Ethernet and
MPLS-TP..... 
		 
		[mv] if we agree to deploy the EVC layer as transport
service layer in MPLS-TP there will indeed be no interworking necessary
at the transport service layer of a hybrid ethernet and mpls-tp packet
transport network. 
		 
		[mv] if we however agree to define a "MS-PW" or "LSP"
based transport service layer in the MPLS-TP stack to support p2p and
p2mp services, then there must be interworking between p2p/p2mp VLANs in
the ethernet domains and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP
domain if we want to offer at least p2p and p2mp services to customers
in such hybrid packet transport network. 
		NH=> I disagree with you.  There is no need whatsover to
peer interwork Ethernet with MPLS or MPLS-TP or (heaven forbid) a PW
layer network.  The rule is very simple:  If not top-of-stack then don't
peer interwork.  And that is really all there is to be said on the
matter.   If you don't respect this all you will do is create lots of
work and costs doing protocol conversion between all the DP/CP
functional components of technologies that have no need to do this.  I
do not want to see our industry expending effort/money on things that
are simply not necessary.
		 
		  As we discussed last month in London, the p2p/p2mp
VLAN and p2p/p2mp "MS-PW"/"LSP" reside in different partitions within
the same "transport service layer".  
		NH=> No they don't....this is stuff you have made up.  I
don't think you listened to what I and Andy said to you.  These are
things you think are sensible because they can be done.  But like
merging in the co-ps mode, just because one can do something does not
make it a sensible/worthwhile thing to do...there is a whole raft of
crazy things I could dream up for us to work on.  The bottom line is
what I stated above....if not top-of-stack then forget interworking as
peers...esp if the networks belong to different modes!.....it really is
that simple.  We cannot afford to be throwing money away on unnecessary
protocol conversion work.
		 
		 In most cases so far partitions in one layer deploy the
same technology. In this case, partitions in the transport service layer
deploy different technologies, but the information carried in both cases
is the same.
		 
		 this is more than OAM, though even that is not the
same, eg there must be no FDI/AIS in a cl-ps network like Ethernet,
which is why IEEE threw this out of .1ag.   
		 
		[mv] IEEE left out AIS because in a STP controlled
domain restoration of the VLANs is an implicit feature. This implies
that generation of AIS at the end of a failed link has to be stopped
within a few second'; i.e. as soon as the VLAN's registration on this
port is removed. 
		NH=> IEEE threw out AIS/FDI because it makes no sense
for cl-ps networks.  If you think it's such a great idea then go and try
and convince IETF to include it in IP and see what reaction you get.
And here is something else that may shock you....a couple of years ago
Andy (Reid) and I were discussing this whole notion of AIS/FDI in the 3
networks modes.  We concluded that it would be better even if the co-ps
mode did not have AIS/FDI, not just the cl-ps mode (which is obvious).
AIS/FDI is only truly sensible in the co-cs mode.  I can explain why but
this now off topic....I only mention this to illustrate that one cannot
have identical functional specifications for the 3 modes (and this is
more than OAM)....it is their differences that are the important bits.
		 
		[mv] ETH-AIS is an important feature in ethernet
transport networks that do not have end-to-end restoration active. ETH
OAM checks the status and performance of the VLAN. VLANs in a transport
network are set up under control of network management with or without
the help of a GMPLS control plane. Such VLANs have a fixed connectivity,
similar as a bidirectional point-to-multipoint connection. The ETH OAM
checks this fixed connectivity; i.e. the connection-oriented part of the
VLAN is checked (ETH OAM does not check the connectionless part (i.e.
filtering rules) pro-actively; it is however capable to check the
connectionless part on-demand via its LTM/LTR OAM). If such VLAN is
interrupted and not restored, ETH-AIS must be generated to prevent ETH
LOC alarms to be raised from the downstream MEP functions.
		NH=> I don't agree with your view of networking
expressed above.
		 
		 There is major DP/CP functional mismatch between
MPLS-TP and Ethernet so there is no way I can agree to interworking
these as peers.  And in any case neither is a top-of-stack network so
any interworking would be a wasted exercise anyway. 
		 
		[mv] Ethernet VLAN deployment in packet transport
networks is under control of network management (possibly with the help
of a GMPLS control plane). Ethernet VLANs are Traffic Engineered. 
		Such traffic engineered p2p VLANs and p2mp VLANs deploy
just a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering
Rules. Traffic engineered MPLS-TP "MS-PW"/"LSP" transport service layer
connections also deploy a Broadcast Forwarding Rule and **no**
Unicast/Multicast Filtering Rules. Both transport entities are traffic
engineered. It is as such possible to interwork these two transport
service layer transport entities without too much problems if we make
sure that the OAM PDU formats are very common.
		NH=> I do not agree with this.
		 
		[mv] But if we agree to deploy the EVC as transport
service layer in MPLS-TP, then we do not need to create interworking
between two technological different partitions in the transport service
layer, as there will be just a single technology deployed in all
partitions.
		 
		[mv] Deployment of the EVC as transport service layer
technology however requires that the EVC must support more then only
Ethernet and TDM clients. I.e. must support also ATM, FR, PPP, etc
clients as defined in PWE3. To support those other PWE3 clients, we need
to get a number of EtherType values, one for each client. 
		NH=> You may not be aware, but there is now an Ethetype
for GFP...its 891F.  Now you can use UPI codepoints for legacy
technologies without bothering IEEE for an Ethetype for every technology
that does not have one....but if you want to go and get then fine.
		 
		regards, Neil
		 
		  I will upload later a set of slides presenting those
PWe3 mappings into an EVC, inluding a list of EtherTypes that would be
required to support this.
		 
		Regards,
		Maarten
		 
		regards, Neil

________________________________

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
			Sent: 12 March 2009 22:29
			To: 'Malcolm Betts'
			Cc: [email-masked]; [email-masked]
			Subject: [mpls-tp] MPLS-TP protocol/payload type
usage in OAM ExtractionProcess
			Malcolm,
			 
			You asked the question:
			> The question is do differences create a
significant risk of undetected faults due to the different
			> treatment of OAM and the data path in either
the originating or terminating processes.
			 
			The packet formats of the LSP_CI, PW_CI and
VPLS_CI are inspected by the so called "OAM Extraction Process"
			in the termination and adaptation functions.
Refer to G.8021 and G.8121 for examples of such OAM Extraction
Processes.
			For the MPLS-TP case and assuming the packet
formats below, these OAM Extraction Processes would inspect the top 
			few rows of those packets to determine the type
of payload/protocol (e.g. OAM CCM) that is carried. 
			This can be illustrated as follows for the LSP
OAM, MS-PW OAM and VPLS OAM:
			 
			LSP OAM with GAL:
			-----------------------------

			LSP OAM without GAL:
			----------------------------------

			MS-PW OAM:
			--------------------

			VPLS (i.e. ETH) OAM:
			--------------------------------

			 
			I hope you understand that all packets are
treated the same way in a termination or adaptation OAM Extraction
process. All (OAM and DATA) packets are inspected on the six, four or
two fields and the values in those fields determine if a packet contains
OAM or DATA.
			 
			The GAL is really not required as its
information is a copy of the information in the S-bit of the label and
the first 4-bit of the ACH.
			 
			Regards,
			Maarten

			
________________________________

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
			Sent: dinsdag 10 maart 2009 18:16
			To: 'Malcolm Betts'; [email-masked]; 'Loa
Andersson'
			Cc: [email-masked]; [email-masked]
			Subject: Re: [mpls-tp] Clarifying MPLS-TP
requirements for MPLS(-TP)overMPLS(-TP)
			Malcolm,
			
			The forwarded information is the MPLS-TP LSP
Characteristic Information (LSP_CI) and the MPLS-TP MS-PW Characteristic
Information (PW_CI). 
			The GAL and ACH fields are both part of the
LSP_CI and the ACH is part of the PW_CI traffic units. 
			As per G.8110, the S-bit and TTL-bits or the
label stack entry header are also part of the CI and hide the GAL and
ACH fields during forwarding.
			The S-bit provides the first subfield of the
MPLS-TP Payload Type.
			LSP_CI packet formats are illustrated below:

			PW_CI and VPLS_CI packet formats are illustrated
below:
			 
			Regards,
			Maarten

			-----Original Message-----
			From: Malcolm Betts [mailto:[email-masked]]
			Sent: dinsdag 10 maart 2009 16:15
			To: [email-masked]; Loa Andersson
			Cc: [email-masked]; [email-masked]
			Subject: RE: [mpls-tp] Clarifying MPLS-TP
requirements for MPLS(-TP)overMPLS(-TP)
			
			First a minor digression to explain my paranoia
on this issue ;)
			
			In high availability networks (like the
Transport network) the "killer"
			faults are the ones that you do not detect.  The
normal conversation about these faults is "well that should not have
happened...." but "stuff happens".  I am not an expert on MPLS equipment
implementations or the control protocols so I am seeking expert
guidance.
			
			So with that mind set:
			
			I agree that only the top label is use
forwarding so no problems "in the network".  However at the node that
originates an terminates the MPLS-TP path we do see a difference in the
pdu structure:
			For traffic the pdu is:  {label X S=1}{Payload}
For OAM the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}
			
			Clearly these are different label stacks both at
the originating and terminating nodes.  The question is do differences
create a significant risk of undetected faults due to the different
treatment of OAM and the data path in either the originating or
terminating processes.  Remember the more successful MPLS-TP the greater
the chance that a corner case fault will appear.....
			
			The "uniform stack" for MPLS-TP would be: {label
X S=0}{GAL S=1}{ACh*; Payload} where the ACh* code point would also
include the client payload types as well as OAM, MCC, DCC etc.

			Malcolm Betts
			Nortel Networks
			Phone: +1 613 763 7860 (ESN 393)
			email: [email-masked]
			
			-----Original Message-----
			From: Stewart Bryant [mailto:[email-masked]]
			Sent: Monday, March 09, 2009 11:08 AM
			To: Loa Andersson
			Cc: Betts, Malcolm (CAR:X632);
[email-masked]; [email-masked]
			Subject: Re: [mpls-tp] Clarifying MPLS-TP
requirements for MPLS(-TP)
			overMPLS(-TP)
			
			Loa Andersson wrote:
			> Malcolm,
			>
			> Malcolm Betts wrote:
			>> Ben, see in line below - I have snipped some
text for clarity:
			> <snipped even more - Loa>
			>
			>>
			>> I think that the requirements draft should
indicate that all frames,
			>> i.e. client data, OAM, SCC, MCC, etc MUST
receive identical treatment
			
			>> in the data plane and therefore MUST use the
same header structure.
			>
			> all packets with the same label on top will
get the same treatment,
			> given that the TC field is the same, won't
they? Is this what you mean
			
			> by "header structure" or did I miss something
			>
			> /Loa
			>>
			>
			>
			
			There is a bunch of confusion about what happens
in MPLS networks.
			
			In transport networks - set up statically or via
GMPLS only the top label effects the path (although TC effects the
queuing).
			
			There are no standard methods for looking at any
other label and in any case this is only done in networks where the path
is chosen by an IGP.
			
			If we always use a PW then the requirement for
client data, OAM, SCC, MCC to receive identical treatment in the path to
the PE occurs because the label stack is identical.
			
			The only case where the label stack will be
different is when we are carrying an LSP OAM in which case the GAL needs
to be present.

			Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 13 Mar 2009 15:51:37 +0100

Shahram,
 
Both methods
1) choose the Ethernet layer as unifying layer, which is essentially what
MEF advocates with their EVC layer
2) introduce a MPLS VC (true co-ps MPLS-TP MS-PW) layer for p2p and p2mp
services 
will work if we reuse the PWE3 encapsulations to map the p2p and p2mp PWE3
clients into the EVCs.
 
What we need to do for this latter item is to request Ethertype values for
each of the PWE3 clients. 
Below is a list of such clients:
 
ATM VPC/VCC n:1 cell mode     To be assigned XX-X1
ATM VPC 1:1 cell mode         To be assigned XX-X2
ATM VCC 1:1 cell mode         To be assigned XX-X3
AAL5 CPCS-SDU mode            To be assigned XX-X4
AAL4 PDU frame mode           To be assigned XX-X5
FR 1:1                        To be assigned XX-X6
FR port                       To be assigned XX-X7
HDLC                          To be assigned XX-X9
PPP                           To be assigned XX-X8
SDH VC11                      To be assigned XX-X10
SDH VC12                      To be assigned XX-X11
SDH VC3                       To be assigned XX-X12
SDH VC4                       To be assigned XX-X13
 
The encapsulation into an EVC will use the PWE3 encapsulations as specified
in the RFCs. The TYPE field with the EtherType will then be added on top of
the Control Word. And on top of the TYPE field we will get the SA and DA
fields.
 
---------------------
|       DA          |
---------------------
|       SA          |
---------------------
|      TYPE         |
---------------------
|       CW plus     |
|   remainder of    |
|   PWE3 packet     |
---------------------
 
Refer to the attached pdf file for the PWE3 frame formats extended with
Ethernet TYPE field.
 
Regards,
Maarten

  _____  

From: Shahram Davari [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 13:50
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAMExtractionProcess

Hi Neil,

Assume there are two network providers, one is using MPLS-TP and the other
using PBB-TE as transport.  And a service provider wants to provide a
service (say IP service or ATM service) across these two network providers.
If both of these network providers first map their services over Ethernet
and then over their transport technology, then Ethernet could be a unifying
layer and these two networks could interwork without any problem. However,
if one maps the service to MPLS-TP and the other maps the same service to
PBB-TE, they can't interwork (complex interworking) because there is no
shared layer.

Assuming that PW or any other method is used for mapping a service to
MPLs-TP, let's make sure the same mapping method (PW or others) are used by
IEEE for PBB -TE or other Ethernet based transports.
 
Bets regards,
Shahram 
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: March-13-09 5:07 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

  _____  

From: Maarten Vissers [mailto:[email-masked]] 
Sent: 13 March 2009 07:39
To: Harrison,N,Neil,CXM R; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
Hello Neil,
 
Good morning.

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 7:33
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
Nice pictures Maarten, but all of this is not required:
 
-    there cannot be MS-PWs in MPLS-TP....MS-PWs represent a co-ps layer
network above MPLS-TP.  If this is true then MPLS-TP has failed as a
transport network. 
 
[mv] As far as I understand the MPLS-TP requirements, there is a "transport
service layer" in MPLS-TP. Do you agree? 
NH=> I have no idea what this term means.   MPLS-TP is supposed to be a
transport network....just like a load of others are.
 
[mv] It seems that we are struggling with the name of this "transport
service layer". If I understand your persistent comment well, then you do
not like to refer to this transport service layer as the "PW" layer. 
NH=> Let's be very clear here.  MPLS-TP is supposed to be a transport
network itself...this is whole purpose of the exercise.  PWs started life as
an adaptation to get around architectural flaws in MPLS.  Unfortunately,
PWE3 decided several years ago to make PWs multi-hop...and as soon as they
did that there was a major shift in what PWs represented....they were no
longer adaptation but a full-blown co-ps layer network.  This was a bad
mistake, and I repeatedly warned PWE3 not to do this.  
 
The architectural flaws in MPLS that spawned PWs *must* be corrected in
MPLS-TP...else, quite simply, it cannot be a transport network.  I do think
most folks understand this.  So, we cannot have MS-PWs in MPLS-TP...unless
we want MPLS-TP to look very silly.

  At some point in time I got the impression that you would like to deploy a
second instance of the MPLS-TP LSP as transport service layer. 
NH=> We are supposed to designing MPLS-TP to be a non top-of-stack co-ps
mode transport network, so all it can do is create higher layer network
topology....nothing unusual here, we have lots of technologies that provide
such a role, esp in the co-cs mode.
  
When I look at what is present in a number of networks today, then I find
the use of an Ethernet VLAN layer as transport service layer in existing
MPLS networks. 
NH=> I don't understand why you home-in on VLANs.  Ethernet in-total is used
as a server to MPLS.....MPLS does not have a physical/section layer
specification and so must run over a technology that does, ie can modulate
an EM wave on radio/optics/metrallic media.....which actually is not a great
place to start for a technology that aspires to be a *transport* network if
you think about it. 
 
  This use of an Ethernet VLAN layer as transport service layer would be
aligned MEF's MEN model in which the EVC (i.e. Ethernet VLAN) is providing
the transport service layer role.  This EVC layer is then supported by the
MEN Transport layer, which could be another Ethernet VLAN instance, or MPLS
LSP or MPLS-TP LSP or PBB-TE TESI, or ...,  
NH=> I am not sure what your point is here.  There is no such thing as 'VLAN
layer networks'....there are 'Ethernet layer networks' however. 
 
-    there must be no interworking of Ethernet and MPLS-TP..... 
 
[mv] if we agree to deploy the EVC layer as transport service layer in
MPLS-TP there will indeed be no interworking necessary at the transport
service layer of a hybrid ethernet and mpls-tp packet transport network. 
 
[mv] if we however agree to define a "MS-PW" or "LSP" based transport
service layer in the MPLS-TP stack to support p2p and p2mp services, then
there must be interworking between p2p/p2mp VLANs in the ethernet domains
and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain if we want to offer
at least p2p and p2mp services to customers in such hybrid packet transport
network. 
NH=> I disagree with you.  There is no need whatsover to peer interwork
Ethernet with MPLS or MPLS-TP or (heaven forbid) a PW layer network.  The
rule is very simple:  If not top-of-stack then don't peer interwork.  And
that is really all there is to be said on the matter.   If you don't respect
this all you will do is create lots of work and costs doing protocol
conversion between all the DP/CP functional components of technologies that
have no need to do this.  I do not want to see our industry expending
effort/money on things that are simply not necessary.
 
  As we discussed last month in London, the p2p/p2mp VLAN and p2p/p2mp
"MS-PW"/"LSP" reside in different partitions within the same "transport
service layer".  
NH=> No they don't....this is stuff you have made up.  I don't think you
listened to what I and Andy said to you.  These are things you think are
sensible because they can be done.  But like merging in the co-ps mode, just
because one can do something does not make it a sensible/worthwhile thing to
do...there is a whole raft of crazy things I could dream up for us to work
on.  The bottom line is what I stated above....if not top-of-stack then
forget interworking as peers...esp if the networks belong to different
modes!.....it really is that simple.  We cannot afford to be throwing money
away on unnecessary protocol conversion work.
 
 In most cases so far partitions in one layer deploy the same technology. In
this case, partitions in the transport service layer deploy different
technologies, but the information carried in both cases is the same.
 
 this is more than OAM, though even that is not the same, eg there must be
no FDI/AIS in a cl-ps network like Ethernet, which is why IEEE threw this
out of .1ag.   
 
[mv] IEEE left out AIS because in a STP controlled domain restoration of the
VLANs is an implicit feature. This implies that generation of AIS at the end
of a failed link has to be stopped within a few second'; i.e. as soon as the
VLAN's registration on this port is removed. 
NH=> IEEE threw out AIS/FDI because it makes no sense for cl-ps networks.
If you think it's such a great idea then go and try and convince IETF to
include it in IP and see what reaction you get.  And here is something else
that may shock you....a couple of years ago Andy (Reid) and I were
discussing this whole notion of AIS/FDI in the 3 networks modes.  We
concluded that it would be better even if the co-ps mode did not have
AIS/FDI, not just the cl-ps mode (which is obvious).  AIS/FDI is only truly
sensible in the co-cs mode.  I can explain why but this now off topic....I
only mention this to illustrate that one cannot have identical functional
specifications for the 3 modes (and this is more than OAM)....it is their
differences that are the important bits.
 
[mv] ETH-AIS is an important feature in ethernet transport networks that do
not have end-to-end restoration active. ETH OAM checks the status and
performance of the VLAN. VLANs in a transport network are set up under
control of network management with or without the help of a GMPLS control
plane. Such VLANs have a fixed connectivity, similar as a bidirectional
point-to-multipoint connection. The ETH OAM checks this fixed connectivity;
i.e. the connection-oriented part of the VLAN is checked (ETH OAM does not
check the connectionless part (i.e. filtering rules) pro-actively; it is
however capable to check the connectionless part on-demand via its LTM/LTR
OAM). If such VLAN is interrupted and not restored, ETH-AIS must be
generated to prevent ETH LOC alarms to be raised from the downstream MEP
functions.
NH=> I don't agree with your view of networking expressed above.
 
 There is major DP/CP functional mismatch between MPLS-TP and Ethernet so
there is no way I can agree to interworking these as peers.  And in any case
neither is a top-of-stack network so any interworking would be a wasted
exercise anyway. 
 
[mv] Ethernet VLAN deployment in packet transport networks is under control
of network management (possibly with the help of a GMPLS control plane).
Ethernet VLANs are Traffic Engineered. 
Such traffic engineered p2p VLANs and p2mp VLANs deploy just a Broadcast
Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Traffic
engineered MPLS-TP "MS-PW"/"LSP" transport service layer connections also
deploy a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering
Rules. Both transport entities are traffic engineered. It is as such
possible to interwork these two transport service layer transport entities
without too much problems if we make sure that the OAM PDU formats are very
common.
NH=> I do not agree with this.
 
[mv] But if we agree to deploy the EVC as transport service layer in
MPLS-TP, then we do not need to create interworking between two
technological different partitions in the transport service layer, as there
will be just a single technology deployed in all partitions.
 
[mv] Deployment of the EVC as transport service layer technology however
requires that the EVC must support more then only Ethernet and TDM clients.
I.e. must support also ATM, FR, PPP, etc clients as defined in PWE3. To
support those other PWE3 clients, we need to get a number of EtherType
values, one for each client. 
NH=> You may not be aware, but there is now an Ethetype for GFP...its 891F.
Now you can use UPI codepoints for legacy technologies without bothering
IEEE for an Ethetype for every technology that does not have one....but if
you want to go and get then fine.
 
regards, Neil
 
  I will upload later a set of slides presenting those PWe3 mappings into an
EVC, inluding a list of EtherTypes that would be required to support this.
 
Regards,
Maarten
 
regards, Neil

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: 12 March 2009 22:29
To: 'Malcolm Betts'
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
Malcolm,
 
You asked the question:
> The question is do differences create a significant risk of undetected
faults due to the different
> treatment of OAM and the data path in either the originating or
terminating processes.
 
The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by the so
called "OAM Extraction Process"
in the termination and adaptation functions. Refer to G.8021 and G.8121 for
examples of such OAM Extraction Processes.
For the MPLS-TP case and assuming the packet formats below, these OAM
Extraction Processes would inspect the top 
few rows of those packets to determine the type of payload/protocol (e.g.
OAM CCM) that is carried. 
This can be illustrated as follows for the LSP OAM, MS-PW OAM and VPLS OAM:
 
LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 
I hope you understand that all packets are treated the same way in a
termination or adaptation OAM Extraction process. All (OAM and DATA) packets
are inspected on the six, four or two fields and the values in those fields
determine if a packet contains OAM or DATA.
 
The GAL is really not required as its information is a copy of the
information in the S-bit of the label and the first 4-bit of the ACH.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: dinsdag 10 maart 2009 18:16
To: 'Malcolm Betts'; [email-masked]; 'Loa Andersson'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)
Malcolm,

The forwarded information is the MPLS-TP LSP Characteristic Information
(LSP_CI) and the MPLS-TP MS-PW Characteristic Information (PW_CI). 
The GAL and ACH fields are both part of the LSP_CI and the ACH is part of
the PW_CI traffic units. 
As per G.8110, the S-bit and TTL-bits or the label stack entry header are
also part of the CI and hide the GAL and ACH fields during forwarding.
The S-bit provides the first subfield of the MPLS-TP Payload Type.
LSP_CI packet formats are illustrated below:

PW_CI and VPLS_CI packet formats are illustrated below:

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

First a minor digression to explain my paranoia on this issue ;)

In high availability networks (like the Transport network) the "killer"
faults are the ones that you do not detect.  The normal conversation about
these faults is "well that should not have happened...." but "stuff
happens".  I am not an expert on MPLS equipment implementations or the
control protocols so I am seeking expert guidance.

So with that mind set:

I agree that only the top label is use forwarding so no problems "in the
network".  However at the node that originates an terminates the MPLS-TP
path we do see a difference in the pdu structure:
For traffic the pdu is:  {label X S=1}{Payload} For OAM the pdu is:  {label
X S=0}{GAL S=1}{ACh; Payload}

Clearly these are different label stacks both at the originating and
terminating nodes.  The question is do differences create a significant risk
of undetected faults due to the different treatment of OAM and the data path
in either the originating or terminating processes.  Remember the more
successful MPLS-TP the greater the chance that a corner case fault will
appear.....

The "uniform stack" for MPLS-TP would be: {label X S=0}{GAL S=1}{ACh*;
Payload} where the ACh* code point would also include the client payload
types as well as OAM, MCC, DCC etc.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Loa Andersson wrote:
> Malcolm,
>
> Malcolm Betts wrote:
>> Ben, see in line below - I have snipped some text for clarity:
>> I think that the requirements draft should indicate that all frames,
>> i.e. client data, OAM, SCC, MCC, etc MUST receive identical treatment

>> in the data plane and therefore MUST use the same header structure.
>
> all packets with the same label on top will get the same treatment,
> given that the TC field is the same, won't they? Is this what you mean

> by "header structure" or did I miss something

There is a bunch of confusion about what happens in MPLS networks.

In transport networks - set up statically or via GMPLS only the top label
effects the path (although TC effects the queuing).

There are no standard methods for looking at any other label and in any case
this is only done in networks where the path is chosen by an IGP.

If we always use a PW then the requirement for client data, OAM, SCC, MCC to
receive identical treatment in the path to the PE occurs because the label
stack is identical.

The only case where the label stack will be different is when we are
carrying an LSP OAM in which case the GAL needs to be present.

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 13 Mar 2009 16:06:35 +0100

Neil,
 
> *The* common layer is X. 
 
And now the question is what is this "X" layer.
 
This "X" layer is the layer that interconnects the UNI-N ports. 
It is the "transport service layer" in the MPLS-TP requirements document.
 
As indicated in my response to Tom earlier this afternoon, the best choice
for "X" is the MEF EVC (Ethernet VLAN).
The *common adaptation* is the well known and well established *TYPE
encapsulation*.
 
But it is possible to use the MEF EVC as "X" layer for mp2mp and rmp
services in an MPLS-TP domain, 
and use a "MPLS VC" (a true co-ps MPLS-TP transport service layer) as "X"
layer for p2p and p2mp services.
If you also want strong typing in the MPLS VC, we can define such MPLS VC
with a TYPE field.
 
So, if "X" is "EVC", then there is no need to interwork the X (i.e. EVC) in
MPLS-TP with the X (i.e. EVC) in Ethernet or PBB-TE.
 
If however the "X" in MPLS-TP is not "EVC", but instead an "MPLS VC", then
there is a need to interwork the 
X in MPLS-TP with the X in Ethernet or PBB-TE; this implies interworking of
"MPLS VC" with EVC.
 
Regards,
Maarten
 
  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 14:23
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAMExtractionProcess

  _____  

To: Harrison,N,Neil,CXM R; [email-masked]; [email-masked]

Hi Neil,

NH=> Why do this?  If one has the stack (where X is some layer network,
any):
 
XoverMPLS-TPoverGFPoverSDH (for arguments sake) and XoverGFPoverPBB-TE then
we simply terminate everything up to X at the gateway and just pass X
across.
 
  and then over their transport technology, 
NH=> But PBB-TE can run directly on wire.....it really can be a transport
network.
 
  then Ethernet could be a unifying layer and these two networks could
interwork without any problem. 
NH=> You could make GFP the unifying *adaptation*...and I emphasise this
because we do not want to create a layer network out of GFP....as we need a
common/generic adaptation function.  And GFP is that common/generic
adaptation function for current transport networks.
 
  However, if one maps the service to MPLS-TP and the other maps the same
service to PBB-TE, they can't interwork (complex interworking) because there
is no shared layer. 
NH=> This is missing the point.  *The* common layer is X.  If you want a
common adpatation then look at GFP. 

 
 Just remember the simple rule, and its fairly easy to figure out:  If 2
layer networks are not top-of-stack then there is no need to have them
interwork as peers....because by definition (of not being top-of-stack) they
*must* have a common higher network (X in the example I gave above).  If
this is not understood we can end up creating huge amounts of unncessary
work/cost for no real benefit.
 
regards, Neil
 
Bets regards,
Shahram 

  _____  

Good morning.

  _____  

 

  

 

 

 

 

regards, Neil

Regards,
Maarten
 
regards, Neil

  _____  

terminating processes.

LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 

Regards,
Maarten

  _____  

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 15:44:08 -0000

Thanks Maarten,

	Neil,

	And now the question is what is this "X" layer. 
	NH=> It can any layer network technology...that is why I called
it X.  X may or may-not be top-of-stack....but to its severs layer
networks this is of no consequence. 
	 
	This "X" layer is the layer that interconnects the UNI-N ports. 
	It is the "transport service layer" in the MPLS-TP requirements
document. 
	NH=> When we carry E1 over E3 we don't refer to E1 as 'the
transport layer service'...its just the PDH E1 layer.  Ditto for VC12
over VC4.  These networks don't have UNIs/E-NNIs in the strict sense of
'peer interworking' across the DP/CP/MP between different parties. 
	 
	There is, however, a need for *physical* interconnects at the
very bottom of the stack even for the client network that have real
UNIs/E-NNIs, like IP and the PSTN.  But these are simply transparent bit
pipes.  And I want to strongly emphasise the word *bit* here as this is
the smallest symbol (information unit)....the physical DP-only
interconnects just send bits *transparently* (another key word) by
modulating an EM wave on radio/metallic/optical media....they care
nothing (and indeed must care nothing) about what the *higher layer
aggregate* is (which at some higher/latent level is a mix of
message/file/stream)  and have to treat each bit equally, preserve bit
order, change nothing......there is no notion of CP or MP interworking
here. 
	 
	It is here that I think you make one basic error of assuming
there must be UNIs/E-NNIs here.  There are not.....these are simply bit
pipe interconnects because they have to exist.
	 
	Now if I carry IP over SDH VC4 on one link, ATM VP on another
link, Ethernet on another link, etc, etc.  we fully terminate all these
lower layer networks and just pass the IP layer across.  There is no
peer interworking of these lower layers.....pretty obvious yes?  This
(ie IP) would also be X in my example.  However, since IP is a
top-of-stack layer network this could have UNIs/E-NNIs...and indeed it
does when it is the *public Internet*.

	As indicated in my response to Tom earlier this afternoon, the
best choice for "X" is the MEF EVC (Ethernet VLAN).
	The *common adaptation* is the well known and well established
*TYPE encapsulation*. 
	NH=> This is your view.  I don't agree with it.   I think you
are trying to create something that is not required, and a load of
unnecessary protocol conversion costs too.  
	 
	The fundamental problem with your approach is that you do not
start at the right point...and that point is the *external* applications
that use networks.  Networks have no purpose in existing if they do not
ultimately allow communications between external (to the network)
parties.  And these communications have 3 generic types:
message/file/stream.  So, there *must* be a layer network at the
top-of-the stack that has these adaptation functions.  Networks that do
not have these are *not* top-of-stack by definition and therefore *must*
be carrying a higher layer network that does have these application
adaptation functions.  Thus, by totally copmelling logic there is no
need whatsoever to to peer interwork non top-of-stack layer networks.
	 
	I really struggle to understand why you find this hard to
grasp/accept.  But I do have some sympathy with your view, since all the
technology pushing fora like MPLSF, MEF and OIF all promote
UNIs/E-NNIs....and this is quite wrong of them IMO as it is not a
correct understanding of what networking is really all about, as none of
these technologies are currently top-of-stack.  Ask yourself a simple
question...what do all these technologies carry?  The answer is some
other layer network...like IP for example.  And if they want to be
top-of-stack the first problem they will have to deal is to displace IP
from this role and interface with external message/file/stream
applications.
	 
	That is the key issue in all this.  And you really need to grasp
this to avoid creating a load of unnecessary work/costs.
	 
	regards, Neil
	 
	But it is possible to use the MEF EVC as "X" layer for mp2mp and
rmp services in an MPLS-TP domain, 
	and use a "MPLS VC" (a true co-ps MPLS-TP transport service
layer) as "X" layer for p2p and p2mp services.
	If you also want strong typing in the MPLS VC, we can define
such MPLS VC with a TYPE field.
	 
	So, if "X" is "EVC", then there is no need to interwork the X
(i.e. EVC) in MPLS-TP with the X (i.e. EVC) in Ethernet or PBB-TE.
	 
	If however the "X" in MPLS-TP is not "EVC", but instead an "MPLS
VC", then there is a need to interwork the 
	X in MPLS-TP with the X in Ethernet or PBB-TE; this implies
interworking of "MPLS VC" with EVC.
	 
	Regards,
	Maarten

	To: [email-masked]; [email-masked];

		Hi Neil,

		Assume there are two network providers, one is using
MPLS-TP and the other using PBB-TE as transport.  And a service provider
wants to provide a service (say IP service or ATM service) across these
two network providers. If both of these network providers first map
their services over Ethernet 
		NH=> Why do this?  If one has the stack (where X is some
layer network, any):

		  and then over their transport technology, 
		NH=> But PBB-TE can run directly on wire.....it really
can be a transport network.
		 
		  then Ethernet could be a unifying layer and these two
networks could interwork without any problem. 
		NH=> You could make GFP the unifying *adaptation*...and
I emphasise this because we do not want to create a layer network out of
GFP....as we need a common/generic adaptation function.  And GFP is that
common/generic adaptation function for current transport networks.
		 
		  However, if one maps the service to MPLS-TP and the
other maps the same service to PBB-TE, they can't interwork (complex
interworking) because there is no shared layer. 
		NH=> This is missing the point.  *The* common layer is
X.  If you want a common adpatation then look at GFP. 

		Assuming that PW or any other method is used for mapping
a service to MPLs-TP, let's make sure the same mapping method (PW or
others) are used by IEEE for PBB -TE or other Ethernet based transports.

		 Just remember the simple rule, and its fairly easy to
figure out:  If 2 layer networks are not top-of-stack then there is no
need to have them interwork as peers....because by definition (of not
being top-of-stack) they *must* have a common higher network (X in the
example I gave above).  If this is not understood we can end up creating
huge amounts of unncessary work/cost for no real benefit.
		 
		regards, Neil
		 
		Bets regards,
		Shahram 
		 
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: March-13-09 5:07 AM
		To: [email-masked]; [email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] MPLS-TP protocol/payload type
usage in OAM ExtractionProcess

			From: Maarten Vissers
[mailto:[email-masked]] 
			Sent: 13 March 2009 07:39
			To: Harrison,N,Neil,CXM R; [email-masked]
			Cc: [email-masked]; [email-masked]
			Subject: RE: [mpls-tp] MPLS-TP protocol/payload
type usage in OAM ExtractionProcess
			Hello Neil,
			 
			Good morning.

			From: [email-masked]
[mailto:[email-masked]] 
			Sent: vrijdag 13 maart 2009 7:33
			To: [email-masked];
[email-masked]
			Cc: [email-masked]; [email-masked]
			Subject: RE: [mpls-tp] MPLS-TP protocol/payload
type usage in OAM ExtractionProcess
			Nice pictures Maarten, but all of this is not
required:

			[mv] As far as I understand the MPLS-TP
requirements, there is a "transport service layer" in MPLS-TP. Do you
agree? 
			NH=> I have no idea what this term means.
MPLS-TP is supposed to be a transport network....just like a load of
others are.
			 
			[mv] It seems that we are struggling with the
name of this "transport service layer". If I understand your persistent
comment well, then you do not like to refer to this transport service
layer as the "PW" layer. 
			NH=> Let's be very clear here.  MPLS-TP is
supposed to be a transport network itself...this is whole purpose of the
exercise.  PWs started life as an adaptation to get around architectural
flaws in MPLS.  Unfortunately, PWE3 decided several years ago to make
PWs multi-hop...and as soon as they did that there was a major shift in
what PWs represented....they were no longer adaptation but a full-blown
co-ps layer network.  This was a bad mistake, and I repeatedly warned
PWE3 not to do this.  
			 
			The architectural flaws in MPLS that spawned PWs
*must* be corrected in MPLS-TP...else, quite simply, it cannot be a
transport network.  I do think most folks understand this.  So, we
cannot have MS-PWs in MPLS-TP...unless we want MPLS-TP to look very
silly.

			  At some point in time I got the impression
that you would like to deploy a second instance of the MPLS-TP LSP as
transport service layer. 
			NH=> We are supposed to designing MPLS-TP to be
a non top-of-stack co-ps mode transport network, so all it can do is
create higher layer network topology....nothing unusual here, we have
lots of technologies that provide such a role, esp in the co-cs mode.
			  
			When I look at what is present in a number of
networks today, then I find the use of an Ethernet VLAN layer as
transport service layer in existing MPLS networks. 
			NH=> I don't understand why you home-in on
VLANs.  Ethernet in-total is used as a server to MPLS.....MPLS does not
have a physical/section layer specification and so must run over a
technology that does, ie can modulate an EM wave on
radio/optics/metrallic media.....which actually is not a great place to
start for a technology that aspires to be a *transport* network if you
think about it. 
			 
			  This use of an Ethernet VLAN layer as
transport service layer would be aligned MEF's MEN model in which the
EVC (i.e. Ethernet VLAN) is providing the transport service layer role.
This EVC layer is then supported by the MEN Transport layer, which could
be another Ethernet VLAN instance, or MPLS LSP or MPLS-TP LSP or PBB-TE
TESI, or ...,  
			NH=> I am not sure what your point is here.
There is no such thing as 'VLAN layer networks'....there are 'Ethernet
layer networks' however. 
			 
			-    there must be no interworking of Ethernet
and MPLS-TP..... 
			 
			[mv] if we agree to deploy the EVC layer as
transport service layer in MPLS-TP there will indeed be no interworking
necessary at the transport service layer of a hybrid ethernet and
mpls-tp packet transport network. 
			 
			[mv] if we however agree to define a "MS-PW" or
"LSP" based transport service layer in the MPLS-TP stack to support p2p
and p2mp services, then there must be interworking between p2p/p2mp
VLANs in the ethernet domains and those p2p/p2mp "MS-PW"/"LSP"s in the
MPLS-TP domain if we want to offer at least p2p and p2mp services to
customers in such hybrid packet transport network. 
			NH=> I disagree with you.  There is no need
whatsover to peer interwork Ethernet with MPLS or MPLS-TP or (heaven
forbid) a PW layer network.  The rule is very simple:  If not
top-of-stack then don't peer interwork.  And that is really all there is
to be said on the matter.   If you don't respect this all you will do is
create lots of work and costs doing protocol conversion between all the
DP/CP functional components of technologies that have no need to do
this.  I do not want to see our industry expending effort/money on
things that are simply not necessary.
			 
			  As we discussed last month in London, the
p2p/p2mp VLAN and p2p/p2mp "MS-PW"/"LSP" reside in different partitions
within the same "transport service layer".  
			NH=> No they don't....this is stuff you have
made up.  I don't think you listened to what I and Andy said to you.
These are things you think are sensible because they can be done.  But
like merging in the co-ps mode, just because one can do something does
not make it a sensible/worthwhile thing to do...there is a whole raft of
crazy things I could dream up for us to work on.  The bottom line is
what I stated above....if not top-of-stack then forget interworking as
peers...esp if the networks belong to different modes!.....it really is
that simple.  We cannot afford to be throwing money away on unnecessary
protocol conversion work.
			 
			 In most cases so far partitions in one layer
deploy the same technology. In this case, partitions in the transport
service layer deploy different technologies, but the information carried
in both cases is the same.
			 
			 this is more than OAM, though even that is not
the same, eg there must be no FDI/AIS in a cl-ps network like Ethernet,
which is why IEEE threw this out of .1ag.   
			 
			[mv] IEEE left out AIS because in a STP
controlled domain restoration of the VLANs is an implicit feature. This
implies that generation of AIS at the end of a failed link has to be
stopped within a few second'; i.e. as soon as the VLAN's registration on
this port is removed. 
			NH=> IEEE threw out AIS/FDI because it makes no
sense for cl-ps networks.  If you think it's such a great idea then go
and try and convince IETF to include it in IP and see what reaction you
get.  And here is something else that may shock you....a couple of years
ago Andy (Reid) and I were discussing this whole notion of AIS/FDI in
the 3 networks modes.  We concluded that it would be better even if the
co-ps mode did not have AIS/FDI, not just the cl-ps mode (which is
obvious).  AIS/FDI is only truly sensible in the co-cs mode.  I can
explain why but this now off topic....I only mention this to illustrate
that one cannot have identical functional specifications for the 3 modes
(and this is more than OAM)....it is their differences that are the
important bits.

			 There is major DP/CP functional mismatch
between MPLS-TP and Ethernet so there is no way I can agree to
interworking these as peers.  And in any case neither is a top-of-stack
network so any interworking would be a wasted exercise anyway. 
			 
			[mv] Ethernet VLAN deployment in packet
transport networks is under control of network management (possibly with
the help of a GMPLS control plane). Ethernet VLANs are Traffic
Engineered. 
			Such traffic engineered p2p VLANs and p2mp VLANs
deploy just a Broadcast Forwarding Rule and **no** Unicast/Multicast
Filtering Rules. Traffic engineered MPLS-TP "MS-PW"/"LSP" transport
service layer connections also deploy a Broadcast Forwarding Rule and
**no** Unicast/Multicast Filtering Rules. Both transport entities are
traffic engineered. It is as such possible to interwork these two
transport service layer transport entities without too much problems if
we make sure that the OAM PDU formats are very common.
			NH=> I do not agree with this.
			 
			[mv] But if we agree to deploy the EVC as
transport service layer in MPLS-TP, then we do not need to create
interworking between two technological different partitions in the
transport service layer, as there will be just a single technology
deployed in all partitions.
			 
			[mv] Deployment of the EVC as transport service
layer technology however requires that the EVC must support more then
only Ethernet and TDM clients. I.e. must support also ATM, FR, PPP, etc
clients as defined in PWE3. To support those other PWE3 clients, we need
to get a number of EtherType values, one for each client. 
			NH=> You may not be aware, but there is now an
Ethetype for GFP...its 891F.  Now you can use UPI codepoints for legacy
technologies without bothering IEEE for an Ethetype for every technology
that does not have one....but if you want to go and get then fine.
			 
			regards, Neil
			 
			  I will upload later a set of slides presenting
those PWe3 mappings into an EVC, inluding a list of EtherTypes that
would be required to support this.
			 
			Regards,
			Maarten
			 
			regards, Neil

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
				Sent: 12 March 2009 22:29
				To: 'Malcolm Betts'
				Cc: [email-masked];
[email-masked]
				Subject: [mpls-tp] MPLS-TP
protocol/payload type usage in OAM ExtractionProcess
				Malcolm,
				 
				You asked the question:
				> The question is do differences create
a significant risk of undetected faults due to the different
				> treatment of OAM and the data path in
either the originating or terminating processes.
				 
				The packet formats of the LSP_CI, PW_CI
and VPLS_CI are inspected by the so called "OAM Extraction Process"
				in the termination and adaptation
functions. Refer to G.8021 and G.8121 for examples of such OAM
Extraction Processes.
				For the MPLS-TP case and assuming the
packet formats below, these OAM Extraction Processes would inspect the
top 
				few rows of those packets to determine
the type of payload/protocol (e.g. OAM CCM) that is carried. 
				This can be illustrated as follows for
the LSP OAM, MS-PW OAM and VPLS OAM:
				 
				LSP OAM with GAL:

				LSP OAM without GAL:

				MS-PW OAM:
				--------------------

				VPLS (i.e. ETH) OAM:

				 
				I hope you understand that all packets
are treated the same way in a termination or adaptation OAM Extraction
process. All (OAM and DATA) packets are inspected on the six, four or
two fields and the values in those fields determine if a packet contains
OAM or DATA.

				Regards,
				Maarten

				

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
				Sent: dinsdag 10 maart 2009 18:16
				To: 'Malcolm Betts'; [email-masked];
'Loa Andersson'
				Cc: [email-masked];
[email-masked]
				Subject: Re: [mpls-tp] Clarifying
MPLS-TP requirements for MPLS(-TP)overMPLS(-TP)
				Malcolm,
				
				The forwarded information is the MPLS-TP
LSP Characteristic Information (LSP_CI) and the MPLS-TP MS-PW
Characteristic Information (PW_CI). 
				The GAL and ACH fields are both part of
the LSP_CI and the ACH is part of the PW_CI traffic units. 
				As per G.8110, the S-bit and TTL-bits or
the label stack entry header are also part of the CI and hide the GAL
and ACH fields during forwarding.
				The S-bit provides the first subfield of
the MPLS-TP Payload Type.
				LSP_CI packet formats are illustrated
below:

				PW_CI and VPLS_CI packet formats are
illustrated below:
				 
				Regards,
				Maarten

				-----Original Message-----
				From: Malcolm Betts [
mailto:[email-masked]]
				Sent: dinsdag 10 maart 2009 16:15
				To: [email-masked]; Loa Andersson
				Cc: [email-masked];
[email-masked]
				Subject: RE: [mpls-tp] Clarifying
MPLS-TP requirements for MPLS(-TP)overMPLS(-TP)
				
				First a minor digression to explain my
paranoia on this issue ;)
				
				In high availability networks (like the
Transport network) the "killer"
				faults are the ones that you do not
detect.  The normal conversation about these faults is "well that should
not have happened...." but "stuff happens".  I am not an expert on MPLS
equipment implementations or the control protocols so I am seeking
expert guidance.
				
				So with that mind set:
				
				I agree that only the top label is use
forwarding so no problems "in the network".  However at the node that
originates an terminates the MPLS-TP path we do see a difference in the
pdu structure:
				For traffic the pdu is:  {label X
S=1}{Payload} For OAM the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}
				
				Clearly these are different label stacks
both at the originating and terminating nodes.  The question is do
differences create a significant risk of undetected faults due to the
different treatment of OAM and the data path in either the originating
or terminating processes.  Remember the more successful MPLS-TP the
greater the chance that a corner case fault will appear.....
				
				The "uniform stack" for MPLS-TP would
be: {label X S=0}{GAL S=1}{ACh*; Payload} where the ACh* code point
would also include the client payload types as well as OAM, MCC, DCC
etc.

				Malcolm Betts
				Nortel Networks
				
				-----Original Message-----
				From: Stewart Bryant [
mailto:[email-masked]]
				Sent: Monday, March 09, 2009 11:08 AM
				To: Loa Andersson
				Cc: Betts, Malcolm (CAR:X632);
[email-masked]; [email-masked]
				Subject: Re: [mpls-tp] Clarifying
MPLS-TP requirements for MPLS(-TP)
				overMPLS(-TP)

				
				> by "header structure" or did I miss
something
				
				There is a bunch of confusion about what
happens in MPLS networks.
				
				In transport networks - set up
statically or via GMPLS only the top label effects the path (although TC
effects the queuing).
				
				There are no standard methods for
looking at any other label and in any case this is only done in networks
where the path is chosen by an IGP.
				
				If we always use a PW then the
requirement for client data, OAM, SCC, MCC to receive identical
treatment in the path to the PE occurs because the label stack is
identical.
				
				The only case where the label stack will
be different is when we are carrying an LSP OAM in which case the GAL
needs to be present.

				Stewart

---

From: [email-masked]
Date: Mon, 16 Mar 2009 14:46:20 +0800

Hi Neil,

you said:
XoverMPLS-TPoverGFPoverSDH (for arguments sake) and XoverGFPoverPBB-TE 
then we simply terminate everything up to X at the gateway and just pass X 
across.

'Just pass X across' means the border node should realize the adaption 
function, but if the X is TDM (such as E1), the adaption function may be 
complicated (timing recovery, E1 framer…), and there will be lots of E1 
need to be passed, this makes the border node very complicated.
Since both networks are packet transport network, exchanging packets 
between them is more reasonable than exchanging TDM signal, packets don’t 
need to change to TDM signal then change back to packets.
Of cause interworking may be complicated too, so we should balance the 
benefits and costs and choose the cheaper and easier one.
IMO, ‘Just pass X across’ is one of the options, but not the only 
option.

Regards
Suhui

<[email-masked]> 
发件人:  [email-masked]
2009-03-13 21:23

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [mpls-tp] MPLS-TP protocol/payload type usage in    OAM 
ExtractionProcess

Hi Neil,

Assume there are two network providers, one is using MPLS-TP and the other 
using PBB-TE as transport.  And a service provider wants to provide a 
service (say IP service or ATM service) across these two network 
providers. If both of these network providers first map their services 
over Ethernet 
NH=> Why do this?  If one has the stack (where X is some layer network, 
any):
 
XoverMPLS-TPoverGFPoverSDH (for arguments sake) and XoverGFPoverPBB-TE 
then we simply terminate everything up to X at the gateway and just pass X 
across.

  then Ethernet could be a unifying layer and these two networks could 
interwork without any problem. 
NH=> You could make GFP the unifying *adaptation*...and I emphasise this 
because we do not want to create a layer network out of GFP....as we need 
a common/generic adaptation function.  And GFP is that common/generic 
adaptation function for current transport networks.
 
  However, if one maps the service to MPLS-TP and the other maps the same 
service to PBB-TE, they can’t interwork (complex interworking) because 
there is no shared layer. 
NH=> This is missing the point.  *The* common layer is X.  If you want a 
common adpatation then look at GFP. 

Assuming that PW or any other method is used for mapping a service to 
MPLs-TP, let’s make sure the same mapping method (PW or others) are used 
by IEEE for PBB –TE or other Ethernet based transports. 
NH=> Well, Ethernet does have an Ethertype for GFP. 
 
 Just remember the simple rule, and its fairly easy to figure out:  If 2 
layer networks are not top-of-stack then there is no need to have them 
interwork as peers....because by definition (of not being top-of-stack) 
they *must* have a common higher network (X in the example I gave above). 
If this is not understood we can end up creating huge amounts of 
unncessary work/cost for no real benefit.
 
regards, Neil
 
Bets regards,
Shahram 

 
Good morning.

 
[mv] As far as I understand the MPLS-TP requirements, there is a 
"transport service layer" in MPLS-TP. Do you agree? 
NH=> I have no idea what this term means.   MPLS-TP is supposed to be a 
transport network....just like a load of others are.
 
network itself...this is whole purpose of the exercise.  PWs started life 
as an adaptation to get around architectural flaws in MPLS. Unfortunately, 
 
The architectural flaws in MPLS that spawned PWs *must* be corrected in 
MPLS-TP...else, quite simply, it cannot be a transport network.  I do 
think most folks understand this.  So, we cannot have MS-PWs in 
MPLS-TP...unless we want MPLS-TP to look very silly.

  At some point in time I got the impression that you would like to deploy 
a second instance of the MPLS-TP LSP as transport service layer. 
NH=> We are supposed to designing MPLS-TP to be a non top-of-stack co-ps 
mode transport network, so all it can do is create higher layer network 
topology....nothing unusual here, we have lots of technologies that 
provide such a role, esp in the co-cs mode.
 
When I look at what is present in a number of networks today, then I find 
the use of an Ethernet VLAN layer as transport service layer in existing 
MPLS networks. 
NH=> I don't understand why you home-in on VLANs.  Ethernet in-total is 
used as a server to MPLS.....MPLS does not have a physical/section layer 
specification and so must run over a technology that does, ie can modulate 
an EM wave on radio/optics/metrallic media.....which actually is not a 
great place to start for a technology that aspires to be a *transport* 
network if you think about it. 
 
  This use of an Ethernet VLAN layer as transport service layer would be 
aligned MEF's MEN model in which the EVC (i.e. Ethernet VLAN) is providing 
the transport service layer role.  This EVC layer is then supported by the 
MEN Transport layer, which could be another Ethernet VLAN instance, or 
MPLS LSP or MPLS-TP LSP or PBB-TE TESI, or ...,  
NH=> I am not sure what your point is here.  There is no such thing as 
'VLAN layer networks'....there are 'Ethernet layer networks' however. 

 
[mv] if we however agree to define a "MS-PW" or "LSP" based transport 
service layer in the MPLS-TP stack to support p2p and p2mp services, then 
there must be interworking between p2p/p2mp VLANs in the ethernet domains 
and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain if we want to 
offer at least p2p and p2mp services to customers in such hybrid packet 
transport network. 
NH=> I disagree with you.  There is no need whatsover to peer interwork 
Ethernet with MPLS or MPLS-TP or (heaven forbid) a PW layer network.  The 
rule is very simple:  If not top-of-stack then don't peer interwork.  And 
that is really all there is to be said on the matter.   If you don't 
respect this all you will do is create lots of work and costs doing 
protocol conversion between all the DP/CP functional components of 
technologies that have no need to do this.  I do not want to see our 
industry expending effort/money on things that are simply not necessary.
 
  As we discussed last month in London, the p2p/p2mp VLAN and p2p/p2mp 
"MS-PW"/"LSP" reside in different partitions within the same "transport 
service layer".  
NH=> No they don't....this is stuff you have made up.  I don't think you 
listened to what I and Andy said to you.  These are things you think are 
sensible because they can be done.  But like merging in the co-ps mode, 
just because one can do something does not make it a sensible/worthwhile 
thing to do...there is a whole raft of crazy things I could dream up for 
us to work on.  The bottom line is what I stated above....if not 
top-of-stack then forget interworking as peers...esp if the networks 
belong to different modes!.....it really is that simple.  We cannot afford 
to be throwing money away on unnecessary protocol conversion work.
 
 In most cases so far partitions in one layer deploy the same technology. 
In this case, partitions in the transport service layer deploy different 
technologies, but the information carried in both cases is the same.

[mv] IEEE left out AIS because in a STP controlled domain restoration of 
the VLANs is an implicit feature. This implies that generation of AIS at 
the end of a failed link has to be stopped within a few second'; i.e. as 
soon as the VLAN's registration on this port is removed. 
NH=> IEEE threw out AIS/FDI because it makes no sense for cl-ps networks. 
If you think it's such a great idea then go and try and convince IETF to 
include it in IP and see what reaction you get.  And here is something 
else that may shock you....a couple of years ago Andy (Reid) and I were 
discussing this whole notion of AIS/FDI in the 3 networks modes.  We 
concluded that it would be better even if the co-ps mode did not have 
AIS/FDI, not just the cl-ps mode (which is obvious).  AIS/FDI is only 
truly sensible in the co-cs mode.  I can explain why but this now off 
topic....I only mention this to illustrate that one cannot have identical 
functional specifications for the 3 modes (and this is more than 
OAM)....it is their differences that are the important bits.
 
[mv] ETH-AIS is an important feature in ethernet transport networks that 
do not have end-to-end restoration active. ETH OAM checks the status and 
performance of the VLAN. VLANs in a transport network are set up under 
control of network management with or without the help of a GMPLS control 
plane. Such VLANs have a fixed connectivity, similar as a bidirectional 
point-to-multipoint connection. The ETH OAM checks this fixed 
connectivity; i.e. the connection-oriented part of the VLAN is checked 
(ETH OAM does not check the connectionless part (i.e. filtering rules) 
pro-actively; it is however capable to check the connectionless part 
on-demand via its LTM/LTR OAM). If such VLAN is interrupted and not 
restored, ETH-AIS must be generated to prevent ETH LOC alarms to be raised 
from the downstream MEP functions.
NH=> I don't agree with your view of networking expressed above.
 
 There is major DP/CP functional mismatch between MPLS-TP and Ethernet so 
there is no way I can agree to interworking these as peers.  And in any 
case neither is a top-of-stack network so any interworking would be a 
wasted exercise anyway. 
 
[mv] Ethernet VLAN deployment in packet transport networks is under 
control of network management (possibly with the help of a GMPLS control 
plane). Ethernet VLANs are Traffic Engineered. 
Such traffic engineered p2p VLANs and p2mp VLANs deploy just a Broadcast 
Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Traffic 
engineered MPLS-TP "MS-PW"/"LSP" transport service layer connections also 
deploy a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering 
Rules. Both transport entities are traffic engineered. It is as such 
possible to interwork these two transport service layer transport entities 
without too much problems if we make sure that the OAM PDU formats are 
very common.
NH=> I do not agree with this.
 
[mv] But if we agree to deploy the EVC as transport service layer in 
MPLS-TP, then we do not need to create interworking between two 
technological different partitions in the transport service layer, as 
there will be just a single technology deployed in all partitions.
 
[mv] Deployment of the EVC as transport service layer technology however 
requires that the EVC must support more then only Ethernet and TDM 
clients. I.e. must support also ATM, FR, PPP, etc clients as defined in 
PWE3. To support those other PWE3 clients, we need to get a number of 
EtherType values, one for each client. 
NH=> You may not be aware, but there is now an Ethetype for GFP...its 
891F.  Now you can use UPI codepoints for legacy technologies without 
bothering IEEE for an Ethetype for every technology that does not have 
one....but if you want to go and get then fine.
 
regards, Neil
 
  I will upload later a set of slides presenting those PWe3 mappings into 
an EVC, inluding a list of EtherTypes that would be required to support 
this.
 
Regards,
Maarten
 
regards, Neil

terminating processes.
 
The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by the 
so called "OAM Extraction Process"
in the termination and adaptation functions. Refer to G.8021 and G.8121 
for examples of such OAM Extraction Processes.
For the MPLS-TP case and assuming the packet formats below, these OAM 
Extraction Processes would inspect the top 
few rows of those packets to determine the type of payload/protocol (e.g. 
OAM CCM) that is carried. 
This can be illustrated as follows for the LSP OAM, MS-PW OAM and VPLS 
OAM:
 
LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 
I hope you understand that all packets are treated the same way in a 
termination or adaptation OAM Extraction process. All (OAM and DATA) 
packets are inspected on the six, four or two fields and the values in 
those fields determine if a packet contains OAM or DATA.

Regards,
Maarten

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for 
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Clearly these are different label stacks both at the originating and 
terminating nodes.  The question is do differences create a significant 
risk of undetected faults due to the different treatment of OAM and the 
data path in either the originating or terminating processes.  Remember 
the more successful MPLS-TP the greater the chance that a corner case 
fault will appear.....

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

There are no standard methods for looking at any other label and in any 
case this is only done in networks where the path is chosen by an IGP.

If we always use a PW then the requirement for client data, OAM, SCC, MCC 
to receive identical treatment in the path to the PE occurs because the 
label stack is identical.

Stewart

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Mon, 16 Mar 2009 10:59:28 -0000

I am not understanding your concern here Suhui.  It seems you are worried about not respecting the timing requirements of co-cs clients...or more generally the performance expectations of such clients.  One certainly has an issure here wrt performance inheritance when all server layer (right down to the duct) are not co-cs in nature...indeed,  ITU performance HRXs have this implicit assumption (but never say so).
 
In a proper client/server relationship not only has one full functional independence between the client and server layer networks (a key thing in itself) but one needs to respect the requirements of transparency...which means:
-    the server treats all client symbols equally (I am being very generic here by saying 'symbols' but just read it as 'bits')
-    the server preserves client symbol ordering
-    the server must not try and guess the meaning of client symbols nor must it alter them
-    and (for performance transparency) the server should ensure that the traffic behaviour of client X cannot impact the performance experienced by client Y
 
BTW none of these issues change if you try peer interworking of the non top-of-stack server layers...all you do now is create work/costs that are not necessary.....and when you come to the end of a tandemed series of peer interworked networks you still have to pass the client across transparently at that point.  So what have you gained from such an exercise?
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 16 March 2009 06:46
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess

	Hi Neil, 
	
	you said: 

	XoverMPLS-TPoverGFPoverSDH (for arguments sake) and XoverGFPoverPBB-TE then we simply terminate everything up to X at the gateway and just pass X across. 

	'Just pass X across' means the border node should realize the adaption function, but if the X is TDM (such as E1), the adaption function may be complicated (timing recovery, E1 framer…), and there will be lots of E1 need to be passed, this makes the border node very complicated. 
	Since both networks are packet transport network, exchanging packets between them is more reasonable than exchanging TDM signal, packets don’t need to change to TDM signal then change back to packets. 
	Of cause interworking may be complicated too, so we should balance the benefits and costs and choose the cheaper and easier one. 
	IMO, ‘Just pass X across’ is one of the options, but not the only option. 
	
	Regards 
	Suhui 

	
<[email-masked]> 

2009-03-13 21:23 

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]> 
抄送
[email-masked], [email-masked] 
主题
Re: [mpls-tp] MPLS-TP protocol/payload type usage in        OAM        ExtractionProcess

	Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess

	Hi Neil, 

	Assume there are two network providers, one is using MPLS-TP and the other using PBB-TE as transport.  And a service provider wants to provide a service (say IP service or ATM service) across these two network providers. If both of these network providers first map their services over Ethernet 

	NH=> Why do this?  If one has the stack (where X is some layer network, any): 

	XoverMPLS-TPoverGFPoverSDH (for arguments sake) and XoverGFPoverPBB-TE then we simply terminate everything up to X at the gateway and just pass X across. 

	NH=> But PBB-TE can run directly on wire.....it really can be a transport network. 

	  then Ethernet could be a unifying layer and these two networks could interwork without any problem. 

	NH=> You could make GFP the unifying *adaptation*...and I emphasise this because we do not want to create a layer network out of GFP....as we need a common/generic adaptation function.  And GFP is that common/generic adaptation function for current transport networks. 

	  However, if one maps the service to MPLS-TP and the other maps the same service to PBB-TE, they can’t interwork (complex interworking) because there is no shared layer. 

	NH=> This is missing the point.  *The* common layer is X.  If you want a common adpatation then look at GFP. 

	Assuming that PW or any other method is used for mapping a service to MPLs-TP, let’s make sure the same mapping method (PW or others) are used by IEEE for PBB –TE or other Ethernet based transports. 

	 Just remember the simple rule, and its fairly easy to figure out:  If 2 layer networks are not top-of-stack then there is no need to have them interwork as peers....because by definition (of not being top-of-stack) they *must* have a common higher network (X in the example I gave above).  If this is not understood we can end up creating huge amounts of unncessary work/cost for no real benefit. 

	regards, Neil 

	Bets regards, 

	Shahram 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: March-13-09 5:07 AM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess 

	

	Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess 

	Hello Neil, 

	Good morning. 

	

	Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess 

	-    there cannot be MS-PWs in MPLS-TP....MS-PWs represent a co-ps layer network above MPLS-TP.  If this is true then MPLS-TP has failed as a transport network. 

	[mv] As far as I understand the MPLS-TP requirements, there is a "transport service layer" in MPLS-TP. Do you agree? 

	NH=> I have no idea what this term means.   MPLS-TP is supposed to be a transport network....just like a load of others are. 

	[mv] It seems that we are struggling with the name of this "transport service layer". If I understand your persistent comment well, then you do not like to refer to this transport service layer as the "PW" layer. 

	NH=> Let's be very clear here.  MPLS-TP is supposed to be a transport network itself...this is whole purpose of the exercise.  PWs started life as an adaptation to get around architectural flaws in MPLS.  Unfortunately, PWE3 decided several years ago to make PWs multi-hop...and as soon as they did that there was a major shift in what PWs represented....they were no longer adaptation but a full-blown co-ps layer network.  This was a bad mistake, and I repeatedly warned PWE3 not to do this.   

	The architectural flaws in MPLS that spawned PWs *must* be corrected in MPLS-TP...else, quite simply, it cannot be a transport network.  I do think most folks understand this.  So, we cannot have MS-PWs in MPLS-TP...unless we want MPLS-TP to look very silly. 

	  At some point in time I got the impression that you would like to deploy a second instance of the MPLS-TP LSP as transport service layer. 

	NH=> We are supposed to designing MPLS-TP to be a non top-of-stack co-ps mode transport network, so all it can do is create higher layer network topology....nothing unusual here, we have lots of technologies that provide such a role, esp in the co-cs mode. 

	When I look at what is present in a number of networks today, then I find the use of an Ethernet VLAN layer as transport service layer in existing MPLS networks. 

	NH=> I don't understand why you home-in on VLANs.  Ethernet in-total is used as a server to MPLS.....MPLS does not have a physical/section layer specification and so must run over a technology that does, ie can modulate an EM wave on radio/optics/metrallic media.....which actually is not a great place to start for a technology that aspires to be a *transport* network if you think about it. 

	  This use of an Ethernet VLAN layer as transport service layer would be aligned MEF's MEN model in which the EVC (i.e. Ethernet VLAN) is providing the transport service layer role.  This EVC layer is then supported by the MEN Transport layer, which could be another Ethernet VLAN instance, or MPLS LSP or MPLS-TP LSP or PBB-TE TESI, or ...,   

	NH=> I am not sure what your point is here.  There is no such thing as 'VLAN layer networks'....there are 'Ethernet layer networks' however. 

	[mv] if we agree to deploy the EVC layer as transport service layer in MPLS-TP there will indeed be no interworking necessary at the transport service layer of a hybrid ethernet and mpls-tp packet transport network. 

	[mv] if we however agree to define a "MS-PW" or "LSP" based transport service layer in the MPLS-TP stack to support p2p and p2mp services, then there must be interworking between p2p/p2mp VLANs in the ethernet domains and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain if we want to offer at least p2p and p2mp services to customers in such hybrid packet transport network. 

	NH=> I disagree with you.  There is no need whatsover to peer interwork Ethernet with MPLS or MPLS-TP or (heaven forbid) a PW layer network.  The rule is very simple:  If not top-of-stack then don't peer interwork.  And that is really all there is to be said on the matter.   If you don't respect this all you will do is create lots of work and costs doing protocol conversion between all the DP/CP functional components of technologies that have no need to do this.  I do not want to see our industry expending effort/money on things that are simply not necessary. 

	  As we discussed last month in London, the p2p/p2mp VLAN and p2p/p2mp "MS-PW"/"LSP" reside in different partitions within the same "transport service layer".   

	NH=> No they don't....this is stuff you have made up.  I don't think you listened to what I and Andy said to you.  These are things you think are sensible because they can be done.  But like merging in the co-ps mode, just because one can do something does not make it a sensible/worthwhile thing to do...there is a whole raft of crazy things I could dream up for us to work on.  The bottom line is what I stated above....if not top-of-stack then forget interworking as peers...esp if the networks belong to different modes!.....it really is that simple.  We cannot afford to be throwing money away on unnecessary protocol conversion work. 

	 In most cases so far partitions in one layer deploy the same technology. In this case, partitions in the transport service layer deploy different technologies, but the information carried in both cases is the same. 

	 this is more than OAM, though even that is not the same, eg there must be no FDI/AIS in a cl-ps network like Ethernet, which is why IEEE threw this out of .1ag.   

	[mv] IEEE left out AIS because in a STP controlled domain restoration of the VLANs is an implicit feature. This implies that generation of AIS at the end of a failed link has to be stopped within a few second'; i.e. as soon as the VLAN's registration on this port is removed. 

	NH=> IEEE threw out AIS/FDI because it makes no sense for cl-ps networks.  If you think it's such a great idea then go and try and convince IETF to include it in IP and see what reaction you get.  And here is something else that may shock you....a couple of years ago Andy (Reid) and I were discussing this whole notion of AIS/FDI in the 3 networks modes.  We concluded that it would be better even if the co-ps mode did not have AIS/FDI, not just the cl-ps mode (which is obvious).  AIS/FDI is only truly sensible in the co-cs mode.  I can explain why but this now off topic....I only mention this to illustrate that one cannot have identical functional specifications for the 3 modes (and this is more than OAM)....it is their differences that are the important bits. 

	[mv] ETH-AIS is an important feature in ethernet transport networks that do not have end-to-end restoration active. ETH OAM checks the status and performance of the VLAN. VLANs in a transport network are set up under control of network management with or without the help of a GMPLS control plane. Such VLANs have a fixed connectivity, similar as a bidirectional point-to-multipoint connection. The ETH OAM checks this fixed connectivity; i.e. the connection-oriented part of the VLAN is checked (ETH OAM does not check the connectionless part (i.e. filtering rules) pro-actively; it is however capable to check the connectionless part on-demand via its LTM/LTR OAM). If such VLAN is interrupted and not restored, ETH-AIS must be generated to prevent ETH LOC alarms to be raised from the downstream MEP functions. 

	 There is major DP/CP functional mismatch between MPLS-TP and Ethernet so there is no way I can agree to interworking these as peers.  And in any case neither is a top-of-stack network so any interworking would be a wasted exercise anyway. 

	[mv] Ethernet VLAN deployment in packet transport networks is under control of network management (possibly with the help of a GMPLS control plane). Ethernet VLANs are Traffic Engineered. 

	Such traffic engineered p2p VLANs and p2mp VLANs deploy just a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Traffic engineered MPLS-TP "MS-PW"/"LSP" transport service layer connections also deploy a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Both transport entities are traffic engineered. It is as such possible to interwork these two transport service layer transport entities without too much problems if we make sure that the OAM PDU formats are very common. 

	[mv] But if we agree to deploy the EVC as transport service layer in MPLS-TP, then we do not need to create interworking between two technological different partitions in the transport service layer, as there will be just a single technology deployed in all partitions. 

	[mv] Deployment of the EVC as transport service layer technology however requires that the EVC must support more then only Ethernet and TDM clients. I.e. must support also ATM, FR, PPP, etc clients as defined in PWE3. To support those other PWE3 clients, we need to get a number of EtherType values, one for each client. 

	NH=> You may not be aware, but there is now an Ethetype for GFP...its 891F.  Now you can use UPI codepoints for legacy technologies without bothering IEEE for an Ethetype for every technology that does not have one....but if you want to go and get then fine. 

	regards, Neil 

	  I will upload later a set of slides presenting those PWe3 mappings into an EVC, inluding a list of EtherTypes that would be required to support this. 

	Regards, 

	Maarten 

	regards, Neil 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: 12 March 2009 22:29
	To: 'Malcolm Betts'
	Cc: [email-masked]; [email-masked]
	Subject: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess 

	Malcolm, 

	You asked the question: 

	> The question is do differences create a significant risk of undetected faults due to the different 

	> treatment of OAM and the data path in either the originating or terminating processes. 

	The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by the so called "OAM Extraction Process" 

	in the termination and adaptation functions. Refer to G.8021 and G.8121 for examples of such OAM Extraction Processes. 

	For the MPLS-TP case and assuming the packet formats below, these OAM Extraction Processes would inspect the top 

	few rows of those packets to determine the type of payload/protocol (e.g. OAM CCM) that is carried. 

	LSP OAM with GAL: 

	LSP OAM without GAL: 

	MS-PW OAM: 

	-------------------- 

	VPLS (i.e. ETH) OAM: 

	I hope you understand that all packets are treated the same way in a termination or adaptation OAM Extraction process. All (OAM and DATA) packets are inspected on the six, four or two fields and the values in those fields determine if a packet contains OAM or DATA. 

	The GAL is really not required as its information is a copy of the information in the S-bit of the label and the first 4-bit of the ACH. 

	Regards, 

	Maarten 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: dinsdag 10 maart 2009 18:16
	To: 'Malcolm Betts'; [email-masked]; 'Loa Andersson'
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)overMPLS(-TP) 

	Malcolm,
	
	The forwarded information is the MPLS-TP LSP Characteristic Information (LSP_CI) and the MPLS-TP MS-PW Characteristic Information (PW_CI). 

	The GAL and ACH fields are both part of the LSP_CI and the ACH is part of the PW_CI traffic units. 

	As per G.8110, the S-bit and TTL-bits or the label stack entry header are also part of the CI and hide the GAL and ACH fields during forwarding. 

	  

	Regards,
	Maarten

	-----Original Message-----
	From: Malcolm Betts [mailto:[email-masked] <mailto:[email-masked]> ]
	Sent: dinsdag 10 maart 2009 16:15
	To: [email-masked]; Loa Andersson
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)overMPLS(-TP)

	In high availability networks (like the Transport network) the "killer"
	faults are the ones that you do not detect.  The normal conversation about these faults is "well that should not have happened...." but "stuff happens".  I am not an expert on MPLS equipment implementations or the control protocols so I am seeking expert guidance.
	
	So with that mind set:
	
	I agree that only the top label is use forwarding so no problems "in the network".  However at the node that originates an terminates the MPLS-TP path we do see a difference in the pdu structure:
	For traffic the pdu is:  {label X S=1}{Payload} For OAM the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}
	
	Clearly these are different label stacks both at the originating and terminating nodes.  The question is do differences create a significant risk of undetected faults due to the different treatment of OAM and the data path in either the originating or terminating processes.  Remember the more successful MPLS-TP the greater the chance that a corner case fault will appear.....
	
	The "uniform stack" for MPLS-TP would be: {label X S=0}{GAL S=1}{ACh*; Payload} where the ACh* code point would also include the client payload types as well as OAM, MCC, DCC etc.

	Malcolm Betts
	Nortel Networks
	
	-----Original Message-----
	From: Stewart Bryant [mailto:[email-masked] <mailto:[email-masked]> ]
	Sent: Monday, March 09, 2009 11:08 AM
	To: Loa Andersson
	Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
	overMPLS(-TP)

	

	In transport networks - set up statically or via GMPLS only the top label effects the path (although TC effects the queuing).
	
	There are no standard methods for looking at any other label and in any case this is only done in networks where the path is chosen by an IGP.
	
	If we always use a PW then the requirement for client data, OAM, SCC, MCC to receive identical treatment in the path to the PE occurs because the label stack is identical.
	
	The only case where the label stack will be different is when we are carrying an LSP OAM in which case the GAL needs to be present.

	Stewart

---

From: "Maarten Vissers" <[email-masked]>
Date: Mon, 16 Mar 2009 13:01:04 +0100

Suhui,
 
Please consider that this "X" layer is the MEF EVC layer. With X being the
EVC layer we would get then
EVCoverMPLS-TP_LSPoverGFPoverSDH, EVCoverPBB-TE_TESIoverTPIDover802.3.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 16 maart 2009 7:46
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: 答复: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

Hi Neil, 

you said: 

'Just pass X across' means the border node should realize the adaption
function, but if the X is TDM (such as E1), the adaption function may be
complicated (timing recovery, E1 framer…), and there will be lots of E1
need to be passed, this makes the border node very complicated. 
Since both networks are packet transport network, exchanging packets between
them is more reasonable than exchanging TDM signal, packets don’t need to
change to TDM signal then change back to packets. 
Of cause interworking may be complicated too, so we should balance the
benefits and costs and choose the cheaper and easier one. 
IMO, ‘Just pass X across’ is one of the options, but not the only option. 

Regards 
Suhui 

<[email-masked]> 

2009-03-13 21:23 

收件人

抄送

主题

  _____  

Hi Neil, 

Assuming that PW or any other method is used for mapping a service to
MPLs-TP, let’s make sure the same mapping method (PW or others) are used by
IEEE for PBB –TE or other Ethernet based transports. 

regards, Neil 

Bets regards, 

Shahram 

  _____  

Hello Neil, 

Good morning. 

  _____  

  

regards, Neil 

Regards, 

Maarten 

regards, Neil 

  _____  

Malcolm, 

terminating processes. 

LSP OAM with GAL: 

 

LSP OAM without GAL: 

 

MS-PW OAM: 

-------------------- 

VPLS (i.e. ETH) OAM: 

 

Regards, 

Maarten 

  _____  

Malcolm,

 

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [ <mailto:[email-masked]> mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [ <mailto:[email-masked]>

Stewart

ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.

---

From: "Maarten Vissers" <[email-masked]>
Date: Mon, 16 Mar 2009 13:14:27 +0100

Neil,
 
The problem that you are facing is a very restricted definition of UNI and
E-NNI. Your very restricted definition is not supported by the fora as you
indicate.
 
The technical specifications of e.g. the MEF are extensively being used in
our industry as a reference and operators require compliance with those
technical specifications from their vendors. 
 
If you are unable to change the UNI and E-NNI definitions in MEF, then I
propose that we adopt those definitions in our MPLS-TP work. MPLS-TP is one
of the technologies in the emerging Carrier Ethernet Network (CEN) which MEF
is defining at the moment and consistent use of UNI and E-NNI terminology in
MEF CEN and MPLS-TP would be important in my opinion.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 16:44
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAMExtractionProcess

Thanks Maarten,

Neil,

And now the question is what is this "X" layer. 
NH=> It can any layer network technology...that is why I called it X.  X may
or may-not be top-of-stack....but to its severs layer networks this is of no
consequence. 
 
This "X" layer is the layer that interconnects the UNI-N ports. 
It is the "transport service layer" in the MPLS-TP requirements document. 
NH=> When we carry E1 over E3 we don't refer to E1 as 'the transport layer
service'...its just the PDH E1 layer.  Ditto for VC12 over VC4.  These
networks don't have UNIs/E-NNIs in the strict sense of 'peer interworking'
across the DP/CP/MP between different parties. 
 
There is, however, a need for *physical* interconnects at the very bottom of
the stack even for the client network that have real UNIs/E-NNIs, like IP
and the PSTN.  But these are simply transparent bit pipes.  And I want to
strongly emphasise the word *bit* here as this is the smallest symbol
(information unit)....the physical DP-only interconnects just send bits
*transparently* (another key word) by modulating an EM wave on
radio/metallic/optical media....they care nothing (and indeed must care
nothing) about what the *higher layer aggregate* is (which at some
higher/latent level is a mix of message/file/stream)  and have to treat each
bit equally, preserve bit order, change nothing......there is no notion of
CP or MP interworking here. 
 
It is here that I think you make one basic error of assuming there must be
UNIs/E-NNIs here.  There are not.....these are simply bit pipe interconnects
because they have to exist.
 
Now if I carry IP over SDH VC4 on one link, ATM VP on another link, Ethernet
on another link, etc, etc.  we fully terminate all these lower layer
networks and just pass the IP layer across.  There is no peer interworking
of these lower layers.....pretty obvious yes?  This (ie IP) would also be X
in my example.  However, since IP is a top-of-stack layer network this could
have UNIs/E-NNIs...and indeed it does when it is the *public Internet*.

As indicated in my response to Tom earlier this afternoon, the best choice
for "X" is the MEF EVC (Ethernet VLAN).
The *common adaptation* is the well known and well established *TYPE
encapsulation*. 
NH=> This is your view.  I don't agree with it.   I think you are trying to
create something that is not required, and a load of unnecessary protocol
conversion costs too.  
 
The fundamental problem with your approach is that you do not start at the
right point...and that point is the *external* applications that use
networks.  Networks have no purpose in existing if they do not ultimately
allow communications between external (to the network) parties.  And these
communications have 3 generic types:  message/file/stream.  So, there *must*
be a layer network at the top-of-the stack that has these adaptation
functions.  Networks that do not have these are *not* top-of-stack by
definition and therefore *must* be carrying a higher layer network that does
have these application adaptation functions.  Thus, by totally copmelling
logic there is no need whatsoever to to peer interwork non top-of-stack
layer networks.
 
I really struggle to understand why you find this hard to grasp/accept.  But
I do have some sympathy with your view, since all the technology pushing
fora like MPLSF, MEF and OIF all promote UNIs/E-NNIs....and this is quite
wrong of them IMO as it is not a correct understanding of what networking is
really all about, as none of these technologies are currently top-of-stack.
Ask yourself a simple question...what do all these technologies carry?  The
answer is some other layer network...like IP for example.  And if they want
to be top-of-stack the first problem they will have to deal is to displace
IP from this role and interface with external message/file/stream
applications.
 
That is the key issue in all this.  And you really need to grasp this to
avoid creating a load of unnecessary work/costs.
 
regards, Neil

 
 
Regards,
Maarten
 
  _____  

  _____  

Hi Neil,

 

 

 
 
regards, Neil
 
Bets regards,
Shahram 

  _____  

Good morning.

  _____  

 

  

 

 

 

 

regards, Neil

Regards,
Maarten
 
regards, Neil

  _____  

terminating processes.

LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 

Regards,
Maarten

  _____  

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

---

From: [email-masked]
Date: Wed, 18 Mar 2009 09:46:40 +0800

Hi Neil,
My concern is the complexity of XtoServer adaption function. before we 
pass X across, X_CI must be retrieved from Server_CI, this work is not 
easy when X is TDM(such as E1) and Server is a packet network(considering 
timing recovery...etc), and in some case, there may be hundreds E1 need to 
passed, i.e. hundreds adaption function need to be realized. 
So I think 'just pass X across' may be more complicated than interworking 
in some case, interworking may be useful in some case.

Regards,
Suhui.

<[email-masked]> 
2009-03-16 18:59

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>
主题
RE: Re: [mpls-tp] MPLS-TP protocol/payload type usage in        OAM 
ExtractionProcess

I am not understanding your concern here Suhui.  It seems you are worried 
about not respecting the timing requirements of co-cs clients...or more 
generally the performance expectations of such clients.  One certainly has 
an issure here wrt performance inheritance when all server layer (right 
down to the duct) are not co-cs in nature...indeed,  ITU performance HRXs 
have this implicit assumption (but never say so).
 
In a proper client/server relationship not only has one full functional 
independence between the client and server layer networks (a key thing in 
itself) but one needs to respect the requirements of transparency...which 
means:
-    the server treats all client symbols equally (I am being very generic 
here by saying 'symbols' but just read it as 'bits')
-    the server preserves client symbol ordering
-    the server must not try and guess the meaning of client symbols nor 
must it alter them
-    and (for performance transparency) the server should ensure that the 
traffic behaviour of client X cannot impact the performance experienced by 
client Y
 
BTW none of these issues change if you try peer interworking of the non 
top-of-stack server layers...all you do now is create work/costs that are 
not necessary.....and when you come to the end of a tandemed series of 
peer interworked networks you still have to pass the client across 
transparently at that point.  So what have you gained from such an 
exercise?
 
regards, Neil

Hi Neil, 

you said: 

Regards 
Suhui 

<[email-masked]> 

收件人

 

terminating processes. 

LSP OAM without GAL: 

MS-PW OAM: 
-------------------- 

VPLS (i.e. ETH) OAM: 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for 
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.