Subject: Re: [mpls-tp] A best-case solution for MPLS-TP

From: <[email-masked]>
Date: Tue, 6 Jan 2009 12:15:23 -0000

mail fail indicated....trying to re-send.

________________________________

	From: 
	Sent: 06 January 2009 12:15
	To: [email-masked]'
	Cc: [email-masked]; [email-masked]
	Subject: RE: RE: [mpls-tp] A best-case solution for MPLS-TP

	Hi Su Hui.....please see my additional remarks:

________________________________

		From: [email-masked] [mailto:[email-masked]] 
		Sent: 06 January 2009 03:10
		To: Harrison,N,Neil,CXM R
		Cc: [email-masked]; [email-masked]
		Subject: 答复: RE: [mpls-tp] A best-case solution for MPLS-TP

		Hi Neil, 
		
		I feel I am a little lost in your comments of CP/MP......, it will need some time for me to get a good understanding of it.  
		NH=> OK, Not sure which bits you are not clear about.  If you ask specific questions I will try and answer.....but see if I cover some of your concerns below. 
		
		Following are my comments on other topics: 
		
		1. CSI vs PPI 
		Let’s take a look what CSI and PPI are. 
		Following figure shows a node which connects two networks. Client signal Z is carried from X to Y, i.e. ZoverX in network X and ZoverY in net work Y. 
		     _______                            _______       
		   _/       \__                       _/       \__   
		  /            \       +----+        /            \   
		 /              \      |    |       /              \ 
		 |   Network X  |------| A  |------ |   Network Y  | 
		  \   ___      _/      +----+        \   ___      _/ 
		   \_/   \____/                       \_/   \____/   
		                                                                                                          
		Some symbols are used in following figures: 
		[+]:  Connection     [x]:  Interwork      o:    CP 
		CP.*: CP of layer network *    CI.*: CI of layer network * 
		
		1. If two networks are the same layer network, the model of node A is just a connection, shown in following figure  

		CP                         CP 
		o-----------[+]-------------o  
		
		NH=> To be strictly accurate the answer is no.  A connection has a very specific meaning.  I think you mean a link connection.  Further, connection/link-connection are topological objects that are strictly only pertinent to a co mode layer network.  However, there is something else which is much more important that must not be overlooked here, and that is 'who owns the 2 network partitions X and Y?'.  If it is the same party then we have an I-NNI, but if X and Y belong to different parties then we have an E-NNI.  The crucial difference here is in the nature of the NNI across DP, CP and MP facets.  The DP is essentially transparent (this is the point you make) *but* the CP and MP are not...usually there is no peering of the MP at all at an E-NNI....and the CP usually has restrictions on topology view (ie only reachability is generally advertised across an E-NNI) and signalling messages.
		 
		This is why it is not sufficient to only think of the DP.  
		
		2.If two networks are different 
		NH=> I'll assume you mean 'technology different'....not simply 'ownership different' 
		 
		 , and the CSI model is used, 
		NH=> Indeed it MUST be, esp if the X and Y networks are not top-of-stack.
		 
		  the model of node A is shown in following figure. Node A has to extract CI.Z from CI.X  and then adapt CI.Z to CI.Y, This means Node A has to know client signal and deal with client signal. 
		            CP.Z                  CP.Z           
		            o---------[+]----------o             
		         ___|___                ___|___           
		         \     /                \     /           
		          \   /                  \   /           
		           \_/                    \_/             
		 CP.X       |                      |        CP.Y 
		  o---------|                      |----------o    
		 
		NH=> Yes.  The key point here is that the DP/CP/MP of layer network Z are carried transparently in a *DP* connection in each of the server layers X and Y, and only the DP/CP/MP of Z is passed between X and Y at the I/W point, ie all DP/CP/MP functions of server layers X and Y are terminated at the I/W point....so there are no functional interactions between layer networks X and Y.   
		
		3.If two networks are different, and the PPI model is used, the model of node A is shown in following figure. 
		NH=> Now why you even considering doing this?  I can prove that when the networks X and Y are not top-of-stack then there is no case for PPI at all.  Please don't forget that we are not simply dealing with the DP here......even ignoring the MP (since this will never be truly peered between different opereating parties) we still need to consider how to interwork the CP facets.  If the 2 technologies belong to same network mode there might be a fair degree of DP/CP functional component alignment (though usually there will not)....but if they do not belong to the same mode then there will be a significant functional mismatch.  For example, lets take a hypothetical example of trying to PPI Ethernet and SDH V4 using GMPLS CP.  For a start their traffic units have no commonality at all.  But even ignoring this showstopper, how do you propose to interwork the Ethernet CP (eg STP, BU, MAC addressing) with the SDH VC4 CP (OSPF, RSVP-TE, IP addressing)?  One can think of lots of different cases like this and there will be massive disconnect in both DP and CP components.
		 
		But as I already noted, why would you even consider trying to PPI 2 different technologies (same or, worse, different modes) if these are not top-of-stack?  There is no need to whatsover...it is simply generating unnecessary work.  I'll send you a paper off-line that explains this all better.
		 
		  In my understanding, interwork is just like a connection except interwork connects two different type of CPs.There is a precondition of interwork: AI.Z-X and AI.Z-Y must be the same. So in the PPI model, what node A need to do is just a ‘format conversion’, i.e. converting CI.X to CI.Y. Node A does not need to deal with the client signal, Node A doesn’t even need to know the type of client signal. I think interwork can be used at any layer of network stack, not only at the top layer. 
		
		CP.X                       CP.Y 
		o-----------[x]-------------o 
		
		If CI of MPLS and CI of MPLS-TP are similar enough (IMO, they can be and are supposed to be similar enough), the ‘format conversion’ will be much simpler than the adaptation (Z to MPLS, Z to MPLS-TP). Furthermore, if there are many kinds of client signal, It doesn’t matter in PPI model since PPI is independent of client signal, but it make node A very complicated in CSI model because many kinds of adaptation need to be realized. So I think the interwork between MPLS and MPLS-TP is necessary.  
		NH=> Let me try and make a plea to you.   I know there is a gut-feeling view that MPLS and MPLS-TP must be regarded as the same (or at least very similar) layer networks.....but this quite an unnecessary concern IMO.  Consider for a moment IPv4 and IPv4.  These are both 'IP' but they are quite different layer networks...they will not get interworked as 'peers' (they can't, if only from the trite observation that their layer network access points have completely different addressing formats!).  Now consider PBB and PBB-TE.  Here we have an even more striking case as they have *identical* traffic units in the DP *and* can use idetical addressing formats........however, they most definitely belong to quite different layer networks as PBB is cl-ps and PBB-TE is co-ps (consider how the CP differs if not obvious).  So we cannot interwork PBB and PBB-TE as *peers*.
		 
		Aside=> One of the problems IMO of the original func arch work in G.805 is that it is too focussed on the DP of the layer network being considered *and* is very much oriented towards a network builder scenario, ie not a top-of-stack layer network case but one of creating the topology of a higher layer network.  This means folks can easily forget to consider what happens to the CP (and MP) and there is a generally a poor understanding of what happens when we reach top-of-stack and the importance of the end-system adaptations for message/file/stream applications......as these are also usually not aligned in top-of-stack networks anyway and also will require protocol conversion attention, eg CF ATM AALs and IP's UDP/TCP/RTP.  Hope you can see what I am driving at here.
		 
		PPI of networks is not something to be considered lightly.  It is a definite no-go when not top-of-stack (just creates unnecessary work/cost).  And even when top-of-stack, not only do we have to look carefully at all the DP/CP/MP facets wrt layer network functional alignment but we also need to consider the message/file/stream end-system applications adaptations since these will also requirement alignment....though the ideal case would be if these were always identical and could simply be passed transparently.  However, with the exception of IPv4 and IPv6 all other technologies have done their own thing here, eg ATM AALs, PSTN stream A/u-law PCM encoding (+ lots of other variants)...and if you look closely at ATM and FR PPI you will find handwaving when it comes to dealing with stream application clients.
		 
		As I noted, there is much more to PPI than the DP (and for sure its more than just the DP OAM as some folks think is the only important thing).
		
		I don’t know if I express myself clear or not, I hope this can be help in our discussion. 
		
		2. PWs and the CW/AC relationships: 
		PW is already a layer network by now even without MS-PW, but it is a simple layer network because only TCP exists in it. 
		NH=> Not sure I follow you here.  The key point about MH-PWs is that there is no choice wrt to whether a further co-ps mode layer network is created or not....MH forces it.  And this has an unresolved problem wrt labelling, ie a co-ps layer network based on label swapping MUST use labels that have a DA proxy semantic for forwarding.....but in MPLS when LDP is used, the PW MUST have a SA semantic to recover the loss of (source) information due to LDP merging.  So there is problem in MPLS wrt PW labels right now.
		 
		If we got the specification of MPLS-TP correct there would be no need for PWs at all......these are only a consequence of how MPLS was originally specified, and the things that caused PWs to be created MUST be removed in MPLS-TP for other reasons.  So if we keep PWs in MPLS-TP we do so in the knowledge we are carrying over a mistake.  We can (and almost certainly will) do that (too much vested interest).......but I am more concerned that folks properly understand why they are doing this, and not simply do it because 'it was there in MPLS'.
		 
		  However MS-PW will bring CP into the PW layer network, and this will bring some very complex issues, such as TCM OAM, SNC protection, route... etc, so I don’t like the idea of MS-PW.  
		NH=> Absolutely.  I was warning PWE3 many years ago not to make PWs MH...one now has to create a full set of DP/CP/MP components to manage/operate a new co-ps layer network.  This is why I am very keen that folks truly understand WHY PWs came about in the 1st place and that if MPLS-TP was done right there would be no need to have them here.  What other 'transport network' uses a PW concept?  Answer is none.  This is not a coincidence.
		
		3. OAM indicate 
		There is no MPLS label and TTL field in section OAM packets, so how to indicate a section OAM packet without alert label?  
		NH=> Sorry I am not following you here.
		
		In addition, I think TTL is not totally useless in MPLS-TP, actually I think TTL is useful in all bandwidth-shared network. In MPLS-TP, unintended LSP loop can be made by misconfig or misconnect in server layer network, TTL can prevent these unintended LSP loop from becoming a disaster. 
		NH=> Well, all I can do is point to all co mode technologies that don't use a TTL and work just fine.  This also applies to CCAMPs work of using GMPLS CP for SDH/OTN...no TTL here in the traffic DP.  
		
		4. A transparent MPLS-TPoverMPLS-TP client server relationship 
		What I suggest is not inserting a layer network, I suggest to insert a CW which is part of adaptation information, and the first nibble of CW can indicate that the payload is another MPLS-TP or MPLS layer network, shown in following picture: 
		+-------------+ \ 
		|   Sbit=0    |  \ 
		+   ......    +    label stack of server layer 
		|   Sbit=1    |  / 
		+-------------+ / 
		|     CW      | 
		+-------------+ \ 
		|    Sbit=0   |  \ 
		+    ......   +   label stack of server layer 
		|    Sbit=1   |  / 
		+-------------+ / 
		 NH=> Yes I agree with you that we should try and avoid inserting another layer network just to isolate different MPLS or MPLS-TP sublayer stacks.   If one is happy to break the S bit rules in rfc3032 (ie more than one occurence of S=1 in LSP stack) then one can use the S bit alone to indicate where one MPLS/MPLS-TP sublayer stack ends and new one starts.  However, because of what happened in MPLS wrt LDP/ECMP we have the 1st nibble issue.  And so we can't simply stack LSPs because the label in a client LSP could be misinterpreted (in MPLS).  Moreover, because we need C/S transparency (which is recursive both up/down) we cannot impose restrictions of the labels (ie we cannot deprecate 0000, 0001, 0100 and 0110 1st nibble label cases) .  And so this is why I assume you would insert the CW.  Well I suppose you can do this, though I don't think the CW has any useful adaptation function fields (just some stuff to either deprecate or config/manage, eg Seq Nos) and this is why I proposed what I think is a cleaner separation of using a reserved label that has the clear DP semantic of isolating 2 MPLS sublayer stacks.
		 
		regards, Neil 
		Regards, 
		SU hui 

<[email-masked]> 

2008-12-31 19:55 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]> 
主题
RE: [mpls-tp] A best-case solution for MPLS-TP	

		Thank you for your comments Su Hui....much appreciated, as this is useful feedback to gauge understanding.  I have tried to answer in-line. 

________________________________

		From: [email-masked] [mailto:[email-masked]] 
		Sent: 31 December 2008 02:53
		To: Harrison,N,Neil,CXM R
		Cc: [email-masked]; [email-masked]
		Subject: 答复: [mpls-tp] A best-case solution for MPLS-TP

		Hi Neil, 
		Here are my opinions: 
		
		1. OOB CP/MP which re-uses GMPLS for the CP 
		I don’t understand why CP/MP packets need a label, CP/MP may use other DCN network or just IP packet.   
		NH=> This is actually more fundamental and important that it may appear to you.  If there are only 2 things MPLS-TP *MUST* get right they are: 
		 -    OOB CP/MP 
		-    transparent client/server relationship between nested LSPs which belong to  *different* MPLS networks. 
		  
		If these 2 things as a min don't happen then MPLS-TP will have been a complete waste of time IMO. 
		  
		Can I ask if you have ever read G.800 (unified (func) modelling of networks)?  If you have you should understand how the partitioning of resource (time/freq/space) and its labelling gives rise to the 3 network modes.....not luck/coincidence, it's just a fact of the physics going on here.   A rather deeper understanding (which is not in G.800 yet, though it will be) is how this stuff is also fundamentally related to Information (Theory), and (once we take this to the section layer and look at how an EM wave carries code space information...which BTW is THE place where all the modes MUST be truly unified) allows one to derive Shannon's seminal formula for Information of p*log(p). 
		  
		Now the reason I mention all this is because when one has a good understanding of this stuff one can see why there are important functional differences between the 3 networks modes and why we can never have a totally common treatment of each..... for example, the view some folks have held in the past of a single instance of CP running IP to Optics (which just plain won't work...indeed this is intrinsically related to this specific OOB CP/MP issue as you will see) or, the more recent view we've seen being pushed of trying to force the same OAM on all the modes and (much worse) trying to interwork them as peers.  This would be a total disaster. 
		  
		But coming back to how this relates to having an OOB CP/MP for MPLS, it makes huge sense to re-use the OOB CP approach that is forced in the co-cs mode also in the co-ps mode......this has many operational benefits besides the immediate/obvious security improvement.  So this is applying common sense wrt CP re-use....and it is every different from the current MPLS approach which started with the assumption that the cl-ps mode of IP and the co-ps mode of MPLS can somehow share a common CP.....this is beginning to unravel now, the MH-PW issue you mention later is but one symptom of this. 
		  
		The mere fact one can run IP native alongside MPLS does not make this a good idea...quite the opposite in fact.  And if you are looking for the technical term that captures which problem this is you will find it as a G.800-type of observation that 'a layer network MUST have consistent Characteristic Information (CI)'........which for simplistic example purposes here can be read as 'the traffic unit one sees at the trail (co) or flow (cl) termination point of a layer network must have consistent binary structure and semantic meaning in all fields of the traffic unit'.  This is not the case in MPLS in a few ways, but the mere fact that IP (cl structured traffic unit) can co-exist with an MPLS (co structured traffic unit), albeit *only* for carrying MPLS CP/MP information (as IP client traffic gets an MPLS traffic unit null encaps), is the most clear example of a lack of consistent CI in MPLS. 
		  
		Now this dual-mode behaviour is necessary for LDP to work.  However, LDP is not a signalling protocol...it is a label dist protocol....which is what it says on the LDP RFC tin.  It is not necessary to have this behaviour for a proper signalling protocol.....in fact you can't have this behaviour in the co-cs mode, ergo why GMPLS is defined the way it is. 
		  
		I think most folks intuitively know that MPLS must not use merging constructs....so LDP and PHP (merging on last hop) can't be used in MPLS-TP...as this creates all sorts of operational problems related to resource management.  So if we must remove these in MPLS-TP then it would foolish not use RSVP-TE with its OOB GMPLS specification, ie having had to remove the root cause of the CI problem in MPLS for other reasons then not to go that one step further and get the OOB CP design right would IMO be an unforgivable mistake now. 
		  
		And of course, to run the CP/MP protocols logically OOB between MPLS nodes requires an adjunct DP layer network (to the traffic carrying DP layer network), and this is why we need reserved labels for this function. 
		  
		You mention a 'DCN' above (like the one found in SDH)....well is exactly what I have just described, ie a logically OOB adjunct DP network for carrying CP/MP protocols. 
		  
		Hope that helps explain why we must use an OOB CP/MP in MPLS-TP (and since CCAMPs have already done the work for this wrt GMPLS, then this is what should be used in MPLS-TP). 

		2. A transparent MPLS-TPoverMPLS-TP client server relationship: 
		I agree that two independent label stacks should be used in the case of MPLS-TPoverMPLS or MPLSoverMPLS-TP. But using ‘label Y’ make it impossible to distinguish MPLS-TP packet from IP or PW packet. I prefer to use ‘S bit’ and a CW as a separator, the first nibble of CW can indicate that client is MPLS-TP, and this is compatible with MPLS.   
		NH=> Well, there are lots of ways one can create this functional separation...I am merely suggesting what I believe is the most elegant/efficient solution.  We do not need to promulgate either the notion of PWs, the S bit (sublayering) or indeed the TTL in a correctly designed co-ps layer network.  One can of course, and I was looking for a solution that kept some of these (eg S bit sublayering, possible use of AC) but recognised what was not necessary (CW and TTL.....possibly a little hard to accept?). 
		  
		Are you suggesting the insertion of some other layer network like Ethernet (as was in Stewart's original draft here)?  I assume you must be as we currently have no such entity as an 'MPLS PW' (which is a key reason this was in Stewart's draft), and I think you'd need this to avoid inserting a specific other layer network technology like Ethernet. 
		  
		If you analyse this approach however it is not very sensible from an efficiency viewpoint or the number of layer networks that need config/management (even if degenerate, ie 1-hop). 
		  
		Having said that I can understand the pull to 'use what we have already defined'.....but please try and think a little creatively, we have such a great opportunity to get things done quite a lot better in MPLS-TP that we should really think hard about these things and not simply carry past mistakes across. 
		
		3. OAM indicate: 
		I think Huub is right, we are not allowed to modify the MPLS label.  And there is no MPLS label and TTL field in section OAM packets, so I think alert label is better to indicate a OAM packet. 
		NH=> Well, this would be a mistake IMO as an MPLS layer network and an MPLS-TP layer network are completely different entities.  That is, there are no architectural reasons to carry over mistakes made in MPLS to MPLS-TP........but that is a collective call.  
		
		4. PWs and the CW/AC relationships: 
		I don’t like the idea of MS-PW either. 
		NH=> OK....but may I ask if you *really* understand why this is, ie we are creating a further co-ps layer network above MPLS/MPLS-TP?  This is a great example of what I am talking about above, ie carrying over mistakes that *had* to be made in MPLS but do not need to be made in MPLS-TP.  
		
		5. CSI vs PPI 
		I think that interwork between MPLS and MPLS-TP is necessary since MPLS-TP is a profile of MPLS. 
		NH=> Be really careful with this seemingly innocuous 'obvious' assertion.....it is wrong.  There is no need to PPI these at all, and I note Adrian has also made this point (as I suspect Adrian has understood why I keep saying this).  MPLS-TP  may be a 'profile' of MPLS (whatever one thinks that really means) but it will be a different layer network.....if it isn't then we will have failed. 
		  
		BTW - Just to be really clear here, PBB-TE is a co-ps mode layer network based on the cl-ps  Ethernet traffic unit.  You cannot *peer* interwork native Ethernet (cl-ps) and PBB-TE (co-ps)...the traffic units look identical but they belong to different layer networks.  IPv4 and IPv6 are also like this, ie different layer networks. 
		  
		  We do not need to deal with client signal if a MPLS network and a MPLS-TP network are connected as peer.   
		NH=> Not sure what you mean here.  But to be clear:  When a layer network is NOT top-of-stack (ie it carries another layer network as its client and NOT a suite of message/file/stream applications adaptation functions) there is no need whatsoever to try and interwork the (server) layer networks as peers...this would be a huge mistake.  The 'interworking' of CS cases XoverY and XoverZ require that Y and Z (server) layer network are fully terminated (all DP/CP/MP facets) and *ONLY* X is passed transparently. 
		  
		If none of this is clear I would suggest a look at G.805 (func arch co mode), G.809 (func arch cl mode), G.800 (unified func arch) and chapters 3/4 of Reid/Sexton 'BB networking'. 
		
		6. TCM OAM sublayers 
		TCM OAM may be useful in SNC protection, SNC protection protects a fragment of LSP, so monitor of fragment LSP is need. If we can handle this, I agree that the value of TCM OAM is too low relative to its complexity.   
		NH=> Good...I'm pleased about that.  We can create a lot of unnecessary work here (just like the peer interworking stuff between different modes/technologies) if we are not alert to its real cost/benefit analysis. 
		
		IMO, MPLS-TP is a PROFILE of MPLS, it should be compatible with MPLS as possible as it can be. 
		NH=> I actually agree.....but please think about what you *really* mean by a 'profile'.  I've kept the same traffic unit (perhaps the biggest 'harmony' aspect) and want to re-use the GMPLS CP suite.  MPLS-TP will create a different layer network to MPLS (MPLS is not even singular itself here!) and that point really needs to be understood.  We should not however carry-over unnecessary mistakes.  
		
		Happy new year!   
		NH=> And you too......regards, Neil 
		
		Reguards, 
		SU Hui 

<[email-masked]> 
发件人:  [email-masked] 

2008-12-24 21:15 

收件人
<[email-masked]> 
抄送
主题
[mpls-tp] A best-case solution for MPLS-TP	

		

		Folks,
		
		Here are a set of proposals that, IMO, will result in the simplest and
		best-case solution for MPLS-TP.   I've omitted any detailed
		analysis/arguments.
		
		I would like to hear opinions for/against each of these + any supporting
		arguments.

		1                 OOB CP/MP which re-uses GMPLS for the CP:
		This requires a reserved label (X say) from the 0-15 set which never
		appears in the traffic DP as a forwarding (or other semantic) label.

		2                 A transparent MPLS-TPoverMPLS-TP client server relationship:
		If folks wish to keep the notion of sublayering (ie same party CP/MP
		ownership across set of nested LSPs), which is implicit in the use of
		the S-bit in MPLS, then we need a way to functionally isolate different
		sublayer LSP stacks.  The best (for many reasons) solution here is to
		use a further reserved label (Y say) from the 0-15 set which can only
		appear in the DP as part of the (server owned/applied) client/server
		adaptation and has the globally well known semantic of "label Y
		indicates a DP/CP/MP functional separator between the LSP sublayers
		above and below label Y".
		
		This technique can also be used for the cases of MPLSoverMPLS-TP and
		MPLS-TPoverMPLS.

		3                 OAM indicate:
		The DP OAM used for defect detection/handling should be as simple/sparse
		as possible and look (and be processed) as close as possible to normal
		DP traffic units......the use of an additional DP label header
		specifically for an OAM alert function should therefore be avoided if
		possible.  This type of OAM should be inserted/extracted at LSP trail
		termination points.  There is currently no OAM indicate field in the
		MPLS header.  However, since MPLS-TP will be a co-ps mode technology
		there is no requirement for a TTL field in the traffic unit header.
		Indeed, the GMPLS CP (or the MP) will be able verify there are no loops
		prior to activating a MPLS-TP LSP (just like GMPLS does for the co mode
		technologies it controls today).  Given that the TTL field represent 25%
		of the MPLS-TP header it is important to be able to re-use this field
		wisely.  An OAM indicate function only requires 1 bit here.

		4                 PWs and the CW/AC relationships:
		PWs were a product of how MPLS was originally specified...but those
		causal drivers must be removed in MPLS-TP.  Further, it is important to
		understand that we should not create an unnecessary co-ps mode layer
		network above MPLS-TP....this rather defeats the whole purpose of
		MPLS-TP.  So if PWs are retained in MPLS-TP they must revert to a form
		of adaptation and not become a network entity (like an MPLS-TP LSP is).
		If one analyses the CW one finds little of real value worth retaining in
		an adaptation role.  The AC seems to hold more potential value
		however.....though I would suggest more thought is given to
		distinguishing functional uses that more correctly belong in the OOB
		CP/MP (ie and thus should use label X as per item 1 above) from those
		that more correctly belong in the traffic DP.
		
		If the AC is retained we need to indicate when the payload is AC.  I
		would argue this should be via a normal MPLS-TP header field...just like
		the case for the OAM noted in 3 above.  And if the TTL field is
		recovered then another bit flag here would be ideal (rather than
		imposing another DP label).

		5                 CSI vs PPI (Client/server interworking vs peer-partition
		interworking):
		When we are dealing with a non-top-of-stack layer network (and both MPLS
		and MPLS-TP are like this, but so is Ethernet...IP is NOT however, as it
		is designed to be able to fulfil a top-of-stack role) then there is no
		need whatsoever to try and interwork any of the DP/CP/MP components. 

		6                 TCM OAM sublayers:
		MPLS-TP should not use nested TCM OAM sublayers.  Just like the point
		wrt S bit noted above, TCM implies sublayers, and this in turn implies a
		common CP/MP across those sublayers....and since we have to address this
		issue as noted above in 2 for MPLS-TPoverMPLS-TP we should not allow
		this situation to be recreated with TCM when multiple different parties
		are involved.
		
		If folks want to segment an end-end LSP for OAM diagnosis purposes (this
		is NOT the same as defect detection/handling OAM) then we should look to
		use more simple ways of tapping-off an end-end OAM flow at intermediate
		points (which should a rare event anyway) instead of burdening the whole
		network with a complex set of sublayering configuration costs/problems.

		Merry Xmas everyone....look forward to hearing your views on the above.
		
		regards, Neil

		_______________________________________________
		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.

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

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