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

From: <[email-masked]>
Date: Wed, 31 Dec 2008 11:55:24 -0000

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.

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