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

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

Thanks Shahram for trying to help here.  However, I do stand by what I
said as it stems from pure logic........if a layer network is not
top-of-stack (ie has adaptation functions for real *external*
message/file/stream communications like IP has) then it has no need for
peer-interworking...even with itself across E-NNI's between different
parties, let alone with a different network technology/mode.  A non
top-of-stack network must, by the very definition of it, be carrying a
higher layer network (which may or may-not be top-of-stack itself).
 
I find this so obvious that I can't believe it needs spelling out like
this again and again.
 
What you can do however is look for a common adaptation for client layer
networks and make this the common glue.  For example PDH, SDH and OTN
all use GFP in this role.  But this adaptation must *never* be
networked...that was the mistake made with PWs in MPLS, as you now lose
the common adaptation and just create a new layer network...though one
could never classify the CW used here as an example of good adaptation
function IMO.  A next generation co-ps mode transport network should
consisder using GFP to align/migrate from current co-cs mode transport
networks.
 
Ethernet now has a GFP Ethertype (891F).
 
regards, Neil

________________________________

	From: Shahram Davari [mailto:[email-masked]] 
	Sent: 13 March 2009 17: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
OAMExtractionProcess

	Hi Neil and Marteen,
	 
	I think the difference of opinion between you can better be
characterized as following:
	 
	We have technology X as end-to-end service. We have transport
technologies Y and Z to carry X  (XoY or XoZ). I think what you are
saying Neil is that the interface point between these two networks,
terminated Y and Z and do forwarding based on lookup of X. And what
Marteen is saying is that there is no need to do X lookup if some
intermediate layer such as T is introduced and is used in both networks
as following XoToY and XoToZ. In such case T can be looked up and used
for forwarding, instead of doing X lookup for all different X
technologies. In this example T can be the PW label or the Ethernet
header. 
	 
	Although this may be true, but I think it should not affect the
specification of the lowest layer (Y or Z). So it should not affect the
specification of MPLS-TP. 
	 
	Regards,
	Shahram
	 
	From: [email-masked] [mailto:[email-masked]] 
	Sent: March-13-09 11:44 AM
	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,
		 
		> *The* common layer is X. 
		 
		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

________________________________

		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
		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: Mon, 16 Mar 2009 13:21:53 +0100

Shahram,
 
For me X is the transport service layer technology, which is the EVC
(Ethernet VC) in the MEF carrier ethernet netowrk (CEN).
 
If we would introduce in MPLS-TP a co-ps MS-PW layer as transport service
layer, then we would introduce essentially a MPLS VC (MVC) that will be able
to support p2p and p2mp services.
 
In the hybrid Ethernet/MPLS-TP carrier ethernet networks, the presence of a
MVC in some domains to support p2p/p2mp services would require an EVC-to-MVC
interworking function at the boudary between MPLS-TP and Ethernet domains
when those services have endpoints in both domains.
 
Regards,
Maarten

  _____  

From: Shahram Davari [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 18: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 and Marteen,
 
I think the difference of opinion between you can better be characterized as
following:
 
We have technology X as end-to-end service. We have transport technologies Y
and Z to carry X  (XoY or XoZ). I think what you are saying Neil is that the
interface point between these two networks, terminated Y and Z and do
forwarding based on lookup of X. And what Marteen is saying is that there is
no need to do X lookup if some intermediate layer such as T is introduced
and is used in both networks as following XoToY and XoToZ. In such case T
can be looked up and used for forwarding, instead of doing X lookup for all
different X technologies. In this example T can be the PW label or the
Ethernet header. 

Regards,
Shahram
 
To: [email-masked]; [email-masked]; [email-masked]
 
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

  _____  

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
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,

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. 

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

  _____  

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
>
> /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: "Howard Green" <[email-masked]>
Date: Tue, 17 Mar 2009 12:11:17 -0500

Hi Neil.
I think I partly disagree with your "top of stack" argument here. Of
course it's true that if we think of the entire galactic networking of
everything, then  applications on client machines are connected to each
other by what you call message/file/stream communications. However, we
are (I think) specifying the behaviour of services (in the widest sense)
to be provided by network operators to customers (which generally means
client networks). It may very well be (and usually is) the case that
these services do not perform the full job of interfacing to the client
services you describe, because part of that job is done by the client
network. So, for example, a L2VPN service is not a "top of stack"
service in your sense, since the customer can clearly send messages,
files and streams (given latency constraints) across it as they wish. 
Nonetheless, it is clear in this example that the natural way of
interworking inside and between service provider networks for this
service is to return to the basic L2VPN - that is, to bridge the
service. I agree with you that we should avoid "peer interworking" of
networks carrying such a service, if by this you mean recreating a
similar (but not the same) function in another technology (you might
worry about VPLS because of this?!)
regards Howard

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Friday, March 13, 2009 12:24 PM
	To: [email-masked]; [email-masked];
[email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage
inOAMExtractionProcess

	Thanks Shahram for trying to help here.  However, I do stand by
what I said as it stems from pure logic........if a layer network is not
top-of-stack (ie has adaptation functions for real *external*
message/file/stream communications like IP has) then it has no need for
peer-interworking...even with itself across E-NNI's between different
parties, let alone with a different network technology/mode.  A non
top-of-stack network must, by the very definition of it, be carrying a
higher layer network (which may or may-not be top-of-stack itself).
	 
	I find this so obvious that I can't believe it needs spelling
out like this again and again.
	 
	What you can do however is look for a common adaptation for
client layer networks and make this the common glue.  For example PDH,
SDH and OTN all use GFP in this role.  But this adaptation must *never*
be networked...that was the mistake made with PWs in MPLS, as you now
lose the common adaptation and just create a new layer network...though
one could never classify the CW used here as an example of good
adaptation function IMO.  A next generation co-ps mode transport network
should consisder using GFP to align/migrate from current co-cs mode
transport networks.

	regards, Neil

		Hi Neil and Marteen,
		 
		I think the difference of opinion between you can better
be characterized as following:
		 
		We have technology X as end-to-end service. We have
transport technologies Y and Z to carry X  (XoY or XoZ). I think what
you are saying Neil is that the interface point between these two
networks, terminated Y and Z and do forwarding based on lookup of X. And
what Marteen is saying is that there is no need to do X lookup if some
intermediate layer such as T is introduced and is used in both networks
as following XoToY and XoToZ. In such case T can be looked up and used
for forwarding, instead of doing X lookup for all different X
technologies. In this example T can be the PW label or the Ethernet
header. 
		 
		Although this may be true, but I think it should not
affect the specification of the lowest layer (Y or Z). So it should not
affect the specification of MPLS-TP. 
		 
		Regards,
		Shahram

		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

			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
			Thanks Shahram...nice to hear from you.  Have
responded in-line.

				From: Shahram Davari
[mailto:[email-masked]] 

				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. 

				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 
				 
				Subject: Re: [mpls-tp] MPLS-TP
				 
				And good morning to you too
Maarten.......

				From: Maarten Vissers
				 
				Good morning.

				 

				 

				 

				 

				 

				 

				 
				 
				regards, Neil

				Regards,
				Maarten
				 
				regards, Neil

				 

				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 [

				
				So with that mind set:

				

				Malcolm Betts
				Nortel Networks
				
				-----Original Message-----
				From: Stewart Bryant [

				
something

				

				Stewart

---

From: "Maarten Vissers" <[email-masked]>
Date: Tue, 17 Mar 2009 18:26:55 +0100

Howard,
 
VPLS is a VLAN of which the VLAN Tag is replaced by a PW label stack entry
header.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Howard Green
Sent: dinsdag 17 maart 2009 18:11
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS-TP protocol/payload type
usageinOAMExtractionProcess

Hi Neil.
I think I partly disagree with your "top of stack" argument here. Of course
it's true that if we think of the entire galactic networking of everything,
then  applications on client machines are connected to each other by what
you call message/file/stream communications. However, we are (I think)
specifying the behaviour of services (in the widest sense) to be provided by
network operators to customers (which generally means client networks). It
may very well be (and usually is) the case that these services do not
perform the full job of interfacing to the client services you describe,
because part of that job is done by the client network. So, for example, a
L2VPN service is not a "top of stack" service in your sense, since the
customer can clearly send messages, files and streams (given latency
constraints) across it as they wish. 
Nonetheless, it is clear in this example that the natural way of
interworking inside and between service provider networks for this service
is to return to the basic L2VPN - that is, to bridge the service. I agree
with you that we should avoid "peer interworking" of networks carrying such
a service, if by this you mean recreating a similar (but not the same)
function in another technology (you might worry about VPLS because of
this?!)
regards Howard

  _____  

Thanks Shahram for trying to help here.  However, I do stand by what I said
as it stems from pure logic........if a layer network is not top-of-stack
(ie has adaptation functions for real *external* message/file/stream
communications like IP has) then it has no need for peer-interworking...even
with itself across E-NNI's between different parties, let alone with a
different network technology/mode.  A non top-of-stack network must, by the
very definition of it, be carrying a higher layer network (which may or
may-not be top-of-stack itself).
 
I find this so obvious that I can't believe it needs spelling out like this
again and again.
 
What you can do however is look for a common adaptation for client layer
networks and make this the common glue.  For example PDH, SDH and OTN all
use GFP in this role.  But this adaptation must *never* be networked...that
was the mistake made with PWs in MPLS, as you now lose the common adaptation
and just create a new layer network...though one could never classify the CW
used here as an example of good adaptation function IMO.  A next generation
co-ps mode transport network should consisder using GFP to align/migrate
from current co-cs mode transport networks.

regards, Neil

  _____  

Hi Neil and Marteen,

 
 
Regards,
Shahram

Thanks Maarten,

Neil,

 

 

 

regards, Neil

 
 
Regards,
Maarten

  _____  

  _____  

 

 

 

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:18:43 +0800

Hi Marrten，

I think I get your points, your suggestion is XoverEVCoverMPLS-TP(X is 
everything), and this will make it easier to interwork with other network 
which use EVC as service layer. 
But, IMO, this introduces a new extra layer network(EVC), and a new layer 
network will bring a new set of OAM mechanism and a new protection 
mechanism ...etc.  So the extra layer makes a MPLS-TP equipment more 
complicated than XoverMPLS-TP,I am wondering if it is worth to make every 
equipment complicated just for interworking. 

Regards,
Suhui

"Maarten Vissers" <[email-masked]> 
发件人:  [email-masked]
2009-03-16 20:21

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

Shahram,

If we would introduce in MPLS-TP a co-ps MS-PW layer as transport service 
layer, then we would introduce essentially a MPLS VC (MVC) that will be 
able to support p2p and p2mp services.
 
In the hybrid Ethernet/MPLS-TP carrier ethernet networks, the presence of 
a MVC in some domains to support p2p/p2mp services would require an 
EVC-to-MVC interworking function at the boudary between MPLS-TP and 
Ethernet domains when those services have endpoints in both domains.
 
Regards,
Maarten

Hi Neil and Marteen,
 
I think the difference of opinion between you can better be characterized 
as following:
 
We have technology X as end-to-end service. We have transport technologies 
Y and Z to carry X  (XoY or XoZ). I think what you are saying Neil is that 
the interface point between these two networks, terminated Y and Z and do 
forwarding based on lookup of X. And what Marteen is saying is that there 
is no need to do X lookup if some intermediate layer such as T is 
introduced and is used in both networks as following XoToY and XoToZ. In 
such case T can be looked up and used for forwarding, instead of doing X 
lookup for all different X technologies. In this example T can be the PW 
label or the Ethernet header. 

Regards,
Shahram

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. 

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.

regards, Neil

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

 
 
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

-----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: Wed, 18 Mar 2009 11:27:21 +0800

maarten:
why you only consider the problem of interworking between ETH VLAN and 
MPLS-TP? why not consider the problem of interworking between ATM, SDH,FR 
etc and MPLS-TP? in your opinion, maybe there be both ETH and MPLS-TP 
transport network technology in the future?
thanks
liu

2009-03-18 01:26

收件人
"'Howard Green'" <[email-masked]>, <[email-masked]>
抄送

主题
Re: [mpls-tp] MPLS-TP protocol/payload type usageinOAMExtractionProcess

Howard,

Regards,
Maarten

Hi Neil.
I think I partly disagree with your "top of stack" argument here. Of 
course it's true that if we think of the entire galactic networking of 
everything, then  applications on client machines are connected to each 
other by what you call message/file/stream communications. However, we are 
(I think) specifying the behaviour of services (in the widest sense) to be 
provided by network operators to customers (which generally means client 
networks). It may very well be (and usually is) the case that these 
services do not perform the full job of interfacing to the client services 
you describe, because part of that job is done by the client network. So, 
for example, a L2VPN service is not a "top of stack" service in your 
sense, since the customer can clearly send messages, files and streams 
(given latency constraints) across it as they wish. 
Nonetheless, it is clear in this example that the natural way of 
interworking inside and between service provider networks for this service 
is to return to the basic L2VPN - that is, to bridge the service. I agree 
with you that we should avoid "peer interworking" of networks carrying 
such a service, if by this you mean recreating a similar (but not the 
same) function in another technology (you might worry about VPLS because 
of this?!)
regards Howard

 
 
use GFP in this role.  But this adaptation must *never* be 

regards, Neil

Hi Neil and Marteen,

 
 
Regards,
Shahram

Thanks Maarten,

Neil,

 

 

 

regards, Neil

 
 
Regards,
Maarten

 

 

 

 
regards, Neil
 
Bets regards,
Shahram 

 
Good morning.

 

 

 

 

 

 

regards, Neil

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:

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: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Mar 2009 11:49:51 -0000

All,

Is it really necessary to attach 700k of files to every email in the thread 
"MPLS-TP protocol/payload typeusageinOAMExtractionProcess" ?

I know that it is our intention to increase the amount of traffic in the 
Internet to ensure that we all have jobs for years to come, but this is just 
a function of using HTML-enabled email and hitting "reply all" without 
tidying up the baggage.

Thanks,
Adrian

---

From: "Maarten Vissers" <[email-masked]>
Date: Wed, 18 Mar 2009 13:59:09 +0100

Suhui,
 
As described in the MPLS-TP requirements document a transport network will
contain a
- transport service layer, which connects UNI-N ports
- transport path layer, which connects PE (i.e. transport service layer
switching/bridging) nodes located at the edge of e.g. a metro or core domain
- transport section layer, which monitors the physical media link
- physical media layer, which connects adjacent nodes.
 
MPLS-TP LSP layer is a transport path layer. An LSP starts/ends at S-PE
nodes and may traverse one or more P nodes. An LSP may be present between a
T-PE and a S-PE, but that is not necessary. The small network termination
type T-PE nodes will typically have the transport service layer signals
mapped directly into the section layer signal (without LSP or similar
transport path type VLAN). Larger T-PE nodes (e.g. wholesale access point
T-PEs) will carry the transport service layer signals in LSPs (or in similar
transport path type VLANs).
 
MEF has specified that the transport service layer is an Ethernet VC (EVC)
layer, and that the customer service signals are carried over this EVC. The
EVC is as such not a *new extra layer network*. The EVC is *the
implementation of the mandatory transport service layer*. Without such EVC
it is not possible to support customer services in a network with more then
one domain.
 
MPLS-TP does not have an MPLS equivalent transport service layer; i.e.
MPLS-TP does not have an MPLS VC (MVC) layer that is capable to support the
p2p, p2mp, rmp and mp2mp services. MEF has understood that and has selected
the Ethernet VC (EVC) as the global transport service layer.
 
It is possible to define an MPLS VC layer that is capable to support a
subset of the required services; i.e. that is capable to support p2p and
p2mp services. If we would do so this MPLS VC layer must still be
complemented by an Ethernet VC layer to support rmp and mp2mp services. The
consequence of this would be that MPLS-TP PE nodes must support two
transport service layer technologies: MPLS VC and Ethernet VC. Furthermore,
MPLS-TP PE interface ports must support an MPLS VC to Ethernet VC
interworking function when the MPLS-TP domain is connected to an Ethernet or
PBB-TE domain. The presence of two transport service layer technolies plus
MPLS VC to Ethernet VC interworking functions would make the MPLS-TP PE
nodes more complex then necessary.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 18 maart 2009 2:19
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: 答复: Re: [mpls-tp] MPLS-TP protocol/payload type usage in
OAMExtractionProcess

Hi Marrten， 

I think I get your points, your suggestion is XoverEVCoverMPLS-TP(X is
everything), and this will make it easier to interwork with other network
which use EVC as service layer. 
But, IMO, this introduces a new extra layer network(EVC), and a new layer
network will bring a new set of OAM mechanism and a new protection mechanism
...etc.  So the extra layer makes a MPLS-TP equipment more complicated than
XoverMPLS-TP,I am wondering if it is worth to make every equipment
complicated just for interworking. 

Regards, 
Suhui 

2009-03-16 20:21 

收件人
<[email-masked]> 

抄送

主题
Re: [mpls-tp] MPLS-TP protocol/payload type usage in
OAMExtractionProcess

Shahram, 

  
  
Regards, 
Maarten 

  _____  

Hi Neil and Marteen, 

  
  
Regards, 
Shahram

---

From: "Maarten Vissers" <[email-masked]>
Date: Wed, 18 Mar 2009 14:22:13 +0100

Suhui,
 
> why not consider the problem of interworking between ATM, SDH,FR etc and
MPLS-TP?
 
If you look at the mef-cen-00.pdf file that I attached to my response on
Monday 16 March, you will find that there is a (client/server) interworking
function located between the Application Services layer and the Ethernet
Services layer (EVC), which takes care of the interworking of ATM, SDH, FR,
etc and the Ethernet Services layer (EVC). In my response to Shahram Davari
on Friday 13 March I have described how those interworking functions will
encapsulate the ATM, SDH, FR, etc signals into an EVC. These encapsulations
use the PWE3 encapsulations as basis and extend the PWE3 packets with a TYPE
field and SA/DA fields. The DA field can carry the broadcast address, so
there is no configuration necessary of a unicast DA.
 
> in your opinion, maybe there be both ETH and MPLS-TP transport network
technology in the future?

When you look into the networks of operators today you find both Ethernet
(typically in metro and access) and MPLS (typically in core). Both those
technologies are used in a transport mode. For Ethernet that implies that
VLANs are traffic engineered and set up under control of network management.
The transport services layer in those multi domain networks is the Ethernet
Services layer (EVC). The EVCs are single tagged in the access link, double
tagged in the metro domain and double labelled in the core domain.
 
MPLS-TP could be extended with an MPLS VC type transport service layer, but
such layer can not support the rmp and mp2mp services. As such there is
always the need to support an Ethernet VC (EVC) layer in a MPLS-TP domain.
 
My understanding is therefore that the packet transport network will contain
both Ethernet and MPLS-TP transport technologies.
 
Regards,
Maarten
 
  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 18 maart 2009 4:27
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP protocol/payload type
usageinOAMExtractionProcess

maarten: 

2009-03-18 01:26 

收件人

抄送

主题
Re: [mpls-tp] MPLS-TP protocol/payload type
usageinOAMExtractionProcess

Howard, 

Regards, 
Maarten 

  _____  

Hi Neil.

---

From: [email-masked]
Date: Fri, 20 Mar 2009 17:04:27 +0800

Hi maarten：

 Please see the on-line...

regards,
Suhui.

Suhui,
 
switching/bridging) nodes located at the edge of e.g. a metro or core 
domain
 
MPLS-TP LSP layer is a transport path layer. An LSP starts/ends at S-PE 
nodes and may traverse one or more P nodes. An LSP may be present between 
a T-PE and a S-PE, but that is not necessary. The small network 
termination type T-PE nodes will typically have the transport service 
layer signals mapped directly into the section layer signal (without LSP 
or similar transport path type VLAN). Larger T-PE nodes (e.g. wholesale 
access point T-PEs) will carry the transport service layer signals in LSPs 
(or in similar transport path type VLANs).
 
MEF has specified that the transport service layer is an Ethernet VC (EVC) 
layer, and that the customer service signals are carried over this EVC. 
The EVC is as such not a *new extra layer network*. The EVC is *the 
implementation of the mandatory transport service layer*. Without such EVC 
it is not possible to support customer services in a network with more 
then one domain.
 
[SH] I think service layer of MPLS-TP is also a MPLS-TP LSP, just like the 
TMC in T-MPLS.

MPLS-TP does not have an MPLS equivalent transport service layer; i.e. 
MPLS-TP does not have an MPLS VC (MVC) layer that is capable to support 
the p2p, p2mp, rmp and mp2mp services. MEF has understood that and has 
selected the Ethernet VC (EVC) as the global transport service layer.
 
It is possible to define an MPLS VC layer that is capable to support a 
subset of the required services; i.e. that is capable to support p2p and 
p2mp services. If we would do so this MPLS VC layer must still be 
complemented by an Ethernet VC layer to support rmp and mp2mp services. 
The consequence of this would be that MPLS-TP PE nodes must support two 
transport service layer technologies: MPLS VC and Ethernet VC. 
Furthermore, MPLS-TP PE interface ports must support an MPLS VC to 
Ethernet VC interworking function when the MPLS-TP domain is connected to 
an Ethernet or PBB-TE domain. The presence of two transport service layer 
technolies plus MPLS VC to Ethernet VC interworking functions would make 
the MPLS-TP PE nodes more complex then necessary.
 
[SH] AFAIK, MPLS-TP is a co-ps layer network, it only provides p2p and 
p2mp connections. It can carry MP2MP client service through L2VPN, but the 
service layer of MPLS-TP itself is not a MP2MP VC. And in this case, ETH 
is not a service layer of MPLS-TP, it is a client of MPLS-TP.

To carry a MP2MP ETH client, If ETH VC is used as service layer, MPLS-TP 
PE have to support ETH (as service layer) and MPLS-TP(as path layer);If 
MPLS-TP VC is used as service layer , MPLS-TP PE also have to support 
ETH(as client layer) and MPLS-TP(as service/path layer),I don’t think the 
latter is more complex than the former. But to carry other client（such as 
E1）, the latter is simpler than the former. 

Regards,
Maarten

---

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

Suhui,
 
If we specify the presence of an MPLS VC as transport service layer, the
layer stack of MPLS-TP contains two transport service layers:
1) Ethernet VC (EVC)
2) MPLS VC.
 
The presence of two transport service layers is more complex for the
equipment and network management then the presence of one transport service
layer.
Transport networks have only one transport service layer (e.g. SDH LOVC, OTN
LO ODU). 
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 20 maart 2009 10:04
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: 答复: Re: [mpls-tp] MPLS-TP protocol/payload type
usageinOAMExtractionProcess

Hi maarten： 

regards, 
Suhui. 

Suhui, 

  

 

[SH] AFAIK, MPLS-TP is a co-ps layer network, it only provides p2p and p2mp
connections. It can carry MP2MP client service through L2VPN, but the
service layer of MPLS-TP itself is not a MP2MP VC. And in this case, ETH is
not a service layer of MPLS-TP, it is a client of MPLS-TP. 

To carry a MP2MP ETH client, If ETH VC is used as service layer, MPLS-TP PE
have to support ETH (as service layer) and MPLS-TP(as path layer);If MPLS-TP
VC is used as service layer , MPLS-TP PE also have to support ETH(as client
layer) and MPLS-TP(as service/path layer),I don’t think the latter is more
complex than the former. But to carry other client（such as E1）, the latter
is simpler than the former. 

Regards, 
Maarten 

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.