Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

<neil.2.harrison@bt.com> Thu, 01 July 2010 07:44 UTC

Return-Path: <neil.2.harrison@bt.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8023A6828; Thu, 1 Jul 2010 00:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level:
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNazVK99aYaN; Thu, 1 Jul 2010 00:44:11 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 7BEDE3A680F; Thu, 1 Jul 2010 00:44:10 -0700 (PDT)
Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 08:44:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB18F1.37663215"
Date: Thu, 1 Jul 2010 08:44:17 +0100
Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0606C99B@E03MVB2-UKBR.domain1.systemhost.net>
In-Reply-To: <4C2C0A08.4060904@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls-tp] [PWE3] Proposal of using GAL for PW
Thread-Index: AcsY0a9XXbcGfUOzRUmRQarMRsvisQAGTTaA
From: <neil.2.harrison@bt.com>
To: <lmartini@cisco.com>, <amalis@gmail.com>
X-OriginalArrivalTime: 01 Jul 2010 07:44:21.0088 (UTC) FILETIME=[37B36600:01CB18F1]
Cc: lihan@chinamobile.com, pwe3@ietf.org, Feng.f.Huang@alcatel-sbell.com.cn, mpls-tp@ietf.org
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 07:44:12 -0000

I support your view Luca (and others who have said the same) for several reasons, 2 important ones being:
 
-    The CW has largely useless functional fields even with MPLS IMO...ergo why it could indeed be optional there.  But with MPLS-TP this is even more starkly true.  For example, a key requirement of a transport network is ordered delivery of client symbols (this is part of a larger 'transparency' requirement) so we should have no use for the Seq No. field of the CW.  Similarly, a major use of the CW was the unfortunate 1st nibble PID-type hack to avoid ECMP problems.  Again, since MPLS-TP is supposed to be a transport network we must have control over the vector of a connection's routing and its resource management.  So ECMP, and hence the 1st nibble hack, is not required.
 
-    MPLS-TP should have critical CP/MP protocols run logically OOB wrt the traffic DP.  This not only applies to MPLS-TP LSPs but also LSPs supporting PWs....but see note below:
 
 
Note:    In a properly designed co-ps mode MPLS-TP transport network all clients should be treated equally/transparently.   This has 2 immediate consequences:
    * PWs should not exist as a special case of a client
    * We should not have traditional LSP nested sublayering...again this is a special case of a (MPLS) client.
 
There are some rather important issues related to misconnectivity across all combinations of nested MPLS-TP layers, nested MPLS-TP sublayers and PW layers here (noting that all look alike in the traffic DP)....put simply, we must have exactly the same CV OAM containing consistent SA (relating to the layer network concerned, eg PW access points have AII-based addresses whereas MPLS-TP has global ID or ICC based addressing).  This is important for 2 reasons:
-    we cannot predict a priori where misconnectivity will happen across a set of nested LSPs which can contain some arbitrary combination of MPLS-TP layers, MPLS-TP sublayers and PW layers...so a trail termination point of any of these entities must be able to parse/understand what arrives in DP OAM messages under misconnectivity
-    in order to accurately/quickly identify an offending source of misconnectivity, network operators require that a CV message carry absolute SA information of the misconnected source....and to be quite clear here, this cannot be some some locally/node-unique-only generated 'discriminator' value...it must be a pukka SA.
 
Further....although PWs should not exist if MPLS-TP was a properly designed transport network, since these will continue to exist we should be reusing the same CP/MP protocols and reusing the same OOB techniques to set-up/tear-down MPLS-TP LSPs and PW LSPs.  Specifically we should only be using RSVP-TE signalling in both cases.  However, I understand we have a problem here in that RSVP-TE signalling does not currently support the AII based addressing of PWs and so we have to also have T-LDP signalling.  
 
regards, Neil


________________________________

	From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Luca Martini
	Sent: 01 July 2010 04:23
	To: Andrew G. Malis
	Cc: lihan@chinamobile.com; pwe3@ietf.org; HUANG Feng F; mpls-tp@ietf.org
	Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW
	
	
	Andy,
	
	I have to disagree that there was any consensus about this issue.
	If anything , there was consensus that there is no written statement that we must  to use the CW in MPLS-TP.
	
	At the end we needed more input from service providers that have deployed PWs.  The point is not whether there is hardware support for the CW, but whether we even want to use it in many cases where it adds absolutely no value. For example ATM PWs in cell mode , where it add almost 10% overhead with no benefit. Another case where the CW is not useful is the ethernet PW without network link load balancing, where we add 4 bytes to every packet just to occasionally send a status , or OAM message.
	
	I would like to propose update the rfc5586 to allow the use of the GAL in PWs without the CW.
	
	This makes the use of the GAL very symmetric among PWs and MPLS-TP LSPs. This makes it easy to process by hardware based implementations.
	
	Luca
	
	
	Andrew G. Malis wrote: 

		Larry and Feng,
		
		This issue has previously been discussed at length by the working
		group, both at the Anaheim meeting and by email, for example in emails
		with the subject line "Possible Contradiction re use of GAL in
		pwe3-static-pw-status". There was rough consensus that for MPLS-TP
		applications and/or when PW OAM is desired, PW implementations are
		mature enough (it has been 10 years now, after all) that the time has
		come to require the implementation of the CW for all PWs, including
		Ethernet.
		
		Cheers,
		Andy
		
		On Wed, Jun 30, 2010 at 6:34 AM, HUANG Feng F
		<Feng.f.Huang@alcatel-sbell.com.cn> <mailto:Feng.f.Huang@alcatel-sbell.com.cn>  wrote:
		  

			it is reasonable to support GAL in MPLS-TP PW OAM, it is more generic, because CW is an option RFC4448 for Ethernet over MPLS.
			
			4.6.  The Control Word
			
			xxxx
			
			
			The features that the control word provides may not be needed for a
			  given Ethernet PW.  For example, ECMP may not be present or active on
			  a given MPLS network, strict frame sequencing may not be required,
			  etc.  If this is the case, the control word provides little value and
			  is therefore optional.  Early Ethernet PW implementations have been
			  deployed that do not include a control word or the ability to process
			  one if present.  To aid in backwards compatibility, future
			  implementations MUST be able to send and receive frames without the
			  control word present.
			xxxx
			
			
			
			B.R.
			Feng Huang
			
			
			-----Original Message-----
			From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Larry
			Sent: 2010年6月30日 17:38
			To: mpls-tp@ietf.org; pwe3@ietf.org
			Cc: lihan@chinamobile.com
			Subject: [PWE3] Proposal of using GAL for PW
			
			Dear all:
			
			    In section 4.2 in RFC5586, it is defined that GAL MUST NOT be used with PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be present when the ACH is used to realize the associated control channel.
			    In real application, a lot of MPLS and MPLS-TP equipments do not support control word. It is proposed to use the GAL to identify associated control channel in PW layer.
			
			Best regards,
			
			                Han Li
			
			********************************************************************
			Han Li, Ph.D
			China Mobile Research Institute
			Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
			Fax: +86 10 63601087
			MOBILE: 13501093385
			********************************************************************
			
			    

		_______________________________________________
		pwe3 mailing list
		pwe3@ietf.org
		https://www.ietf.org/mailman/listinfo/pwe3