Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

From: <[email-masked]>
Date: Mon, 27 Apr 2009 12:19:58 +0100

Han,
 
In his post below, Maarten is not claiming that AIS is needed for alarm suppression. He is saying that he sees it being used to distinguish faults in a server layer from faults in the client layer. As you will see in my post back to Maarten, this cannot be practically achieved.
 
I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, in the packet world of MPLS-TP, AIS/FDI cannot be simple and therefore cannot be the same as in SONET/SDH.
 
The objective is to reuse the same basic fault detection, alarm suppression, and fault localisation as SONET/SDH. This is readily achieved with the CC messages in the dataplane.
 
However, adding AIS/FDI would require a completely new configuration management system and a completely new set of fault conditions requiring localisation. Ironically, adding a packet AIS/FDI effectively removes the compatibility with SONET/SDH management systems and processes.
 
Andy

Andy Reid 
Chief Network Services Strategist 
BT Innovate 
                                                                                           
Office: +44 (0)1277 322038 
Mobile: +44 (0)7917 025451 
Fax :       +44 (0)1277 324015 
Email:  [email-masked] 

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

________________________________

	From: lihan [mailto:[email-masked]] 
	Sent: 27 April 2009 02:41
	To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R
	Cc: [email-masked]
	Subject: 答复: [mpls-tp] Associated bidirectional transport path requirements

	Support!

	AIS/FDI is very importance for network management. MPLS-TP is divided into three layers in order to enhance the scalability and OAM. It is very important to distinguish the failure is belong to server layer or client layer. AIS/FDI is a simple and well-known mechanism to realize alarm suppression and fault localization. 

	Best regards,

	    Han Li

	*****************************************************

	Han Li, Ph.D.

	R&D, CHINA MOBILE COMMUNICATIONS CORPORATION

	Tel: +86 10 66006688 ext. 3092

	Fax: +86 10 63601087

	MOBILE: 13501093385

	*****************************************************

________________________________

	发件人: [email-masked] [mailto:[email-masked]] 代表 Maarten Vissers
	发送时间: 2009年4月25日 2:15
	收件人: [email-masked]
	抄送: [email-masked]
	主题: Re: [mpls-tp] Associated bidirectional transport path requirements

	Andy,

	AIS/FDI does give additional information. Let me explain:

	The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection.

	Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection.

	As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected.

	AIS has been introduced and is used to help differentiate between the two fault cases.

	1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate. 

	2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to locate the misconfigured or failed connection function. Once this faulty connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored.

	The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. This performance monitoring information is used to verify the performance against the SLA for the connection.

	Regards,

	Maarten

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: vrijdag 24 april 2009 12:34
	To: [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

	Maarten,

	These points are irrelevant to the points I made. My point is that AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this.

	Andy

	Andy Reid 
	Chief Network Services Strategist 
	BT Innovate 
	                                                                                           
	Office: +44 (0)1277 322038 
	Mobile: +44 (0)7917 025451 
	Fax :       +44 (0)1277 324015 
	Email:  [email-masked] 

	British Telecommunications plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no. 1800000 
	This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

	Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

________________________________

		From: Maarten Vissers [mailto:[email-masked]] 
		Sent: 23 April 2009 20:42
		To: Reid,ABD,Andy,CXM R
		Cc: [email-masked]
		Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

		Andy,

		> The problem is *not* about a lack of alarm suppression in the data plane - that information is readily available.

		I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B.

		> The issue arises because the two sides of maintenance want different things. The fault fixing

		> guys want to locate the fault and don't want any other information. The service maintenance

		> guys want to know whether their customer service is working.

		This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means of the additional SSF alarm. The SSF alarm is for the service guys telling them that the service was interrupted due to a fault in a server layer. AIS suppresses the LOC alarm in those cases so that the maintenance guys don't get triggered and start looking for a fault that is outside their area.

		Regards,

		Maarten

________________________________

		From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: woensdag 22 april 2009 12:14
		To: [email-masked]; [email-masked]
		Cc: [email-masked]
		Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

		Liu,

		Allow me to jump in. You are bringing together two things which are separate and for which AIS/FDI is no help. Maintenance operations are concerned with two separate things.

		1)  Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance).

		2)  Identifying the health of end to end connections, especially when they are directly supporting customer services (service maintenance).

		The problem is *not* about a lack of alarm suppression in the data plane - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!)

		The issue arises because the two sides of maintenance want different things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working.

		This arose in the early days of SONET/SDH, when the operations guys demanded that the equipment did *not* suppress the traffic alarm even when AIS was being received as the service guys want to know about the alarms. The normal practice is for the equipment to report the alarms *including* AIS and then a filter is applied in the management system to suppress alarms to the fault fixing guys. As I'm aware, there are many different techniques applied for the filtering algorithms, especially when you consider multiple concurrent faults in a network, however, the existance of AIS/FDI doesn't add anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up simple time-stamp correlation! 

		In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most circumstances, the filter has automatically done this. So localisation you describe is only when the filter hasn't worked for some reason.

		But the bottom line is, whatever operations process you want to use, AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to fill the bit stream with something*.

		Andy

		Andy Reid 
		Chief Network Services Strategist 
		BT Innovate 
		                                                                                           
		Office: +44 (0)1277 322038 
		Mobile: +44 (0)7917 025451 
		Fax :       +44 (0)1277 324015 
		Email:  [email-masked] 

		British Telecommunications plc
		Registered office: 81 Newgate Street London EC1A 7AJ
		Registered in England no. 1800000 
		This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

		Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

________________________________

			From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
			Sent: 22 April 2009 09:15
			To: Harrison,N,Neil,CXM R
			Cc: [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

			Neil: 
			  thank you for wasting more time in describling the problems. but I think some of what you said is no relations with our problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI functions, when there is a defects in a given layer network, it can cause multiple alarm events to be raised. it is diffcult  for operators to locate and diagnose the faults. 
			 though I completely agree you on  adding new things and functions will bring some complexity . but if we have no functions, it is more complex and difcult for operators to maintence and administrator the network. so I think every new functions and things may have positive and negative effects. but we should consider it very much, don't delete some functions at random. 

			best regards 
			liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

<[email-masked]>, <[email-masked]> 

抄送

<[email-masked]> 

主题

RE: [mpls-tp] Associated bidirectional transport path requirements

			

			Liu, 
			  
			If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these. 
			  
			1    Provide a transparent client/server relationship...which means: 
			-    all client bits treated equally 
			-    client bit ordering preserved 
			-    no attempt to infer client symbol (ie sequence of client bits) meaning and no attempt to change client symbols 
			-    the traffic behaviour of client X must not impact the performance experienced by client Y 
			  
			A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs) 

			2   Since MPLS-TP is a transport network it is not a top-of-stack network (ie it does not support directly external message/file/stream applications).  MPLS-TP therefore does not require an E-NNI specification.  A key corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology. 

			Now wrt OAM MPLS-TP is a co-ps mode network.  You could argue this should have FDI/AIS....however, the merit of this is highly questionable.  When I and colleagues discussed whether PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise. 
			  
			AIS/FDI is historically linked to the early PDH co-cs mode layer networks that used TTL logic.  When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is key point.  Further, in these networks there is a fairly static/long-holding client server relationship.  Clearly this is not true in the cl-ps mode and it's why IETF have never specified AIS for IP and its why IEEE had the good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I suspect any operator planning to use Ethernet equipment would always look to IEEE stds and not ITU ones). 
			  
			AIS/FDI and the co-ps mode is debatable.  As I noted above, on balance we considered not a good idea for PBB-TE OAM because it requires a conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong. 
			  
			You should also have seen me make the point many times in the past that the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here.  Also note that the OAM required for each of the 3 network modes is not the same, despite what some claim. 
			  
			regards, Neil 

________________________________

			From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
			Sent: 21 April 2009 02:59
			To: BRUNGARD, DEBORAH A, ATTLABS
			Cc: [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

			Deborah: 
			maybe what you said is right. but I can't completely agree your opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET. 
			
			do you think so. 
			
			best regards 
			liu 

"BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> 
发件人:  [email-masked] 

2009-04-20 23:47 

收件人

"Maarten Vissers" <[email-masked]>, <[email-masked]> 

抄送

[email-masked] 

主题

Re: [mpls-tp] Associated bidirectional transport path requirements

			

			I agree with Neil, it is very questionable the value of AIS/FDI in a
			packet network- any mode. It can result in a DoS attack by an operator
			on themselves so even Y1731 recommends not to block data frames:
			"A MEP can decide whether it blocks data frames when it detects dAIS.
			The principle requirement
			that influences this decision is that data frames ought to be forwarded
			as much as possible, without
			the possibility of forwarding wrong data frames downstream."
			Table I.7-2 shows for AIS, not to block.
			
			And as Y1731 states, AIS can only be used under very constrained
			architectures - if required for MPLS-TP, it needs to have the same
			guidance as in Y1731, i.e. point-to-point and server/client one-to-one:
			"for a point-to-point ETH connection, a MEP has only a single peer MEP.
			Therefore, there
			is no ambiguity regarding the peer MEP for which it should suppress
			alarms when it receives the
			ETH-AIS information."
			So should only be within one domain - then no need.
			
			Deborah
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On
			Behalf Of Maarten Vissers
			Sent: Monday, April 20, 2009 10:05 AM
			To: [email-masked]
			Cc: [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional transport path
			requirements
			
			Neil,
			
			> but AIS/FDI in the cl mode?...do me a favour!
			
			Ethernet AIS is indeed a requirement and a necessity. And you will not
			be
			able to understand that as long as you refuse to accept that "cl-mode"
			is a
			forwarding mode within a **transport entity**. G.800 amendment 1 has
			finally
			reintroduced this transport entity into G.800. Besides that, it also
			introduced the **differentiated connection**:
			
			[G.800 am1] "A differentiated connection is a transport entity that
			transfers information belonging to multiple communications between ports
			across a subnetwork. <..> In a differentiated connection message
			contents
			are interpreted to identify (sets of) communications which receive
			different
			treatment.  The sets of communications may be distinguished by the
			forwarding identifier or other layer information.  Order is not
			necessarily
			preserved between messages belonging to sets of communications receiving
			different treatment.  Sets of communications may be identified for
			purposes
			such as traffic conditioning or preserving communication message order."

			Ethernet VLANs are in terms of G.800 "differentiated connections".
			Ethernet
			AIS provides AIS within the scope of such "differentiated connection".
			If
			you apply this to my proposed PTN layer stack, then the EVC layer
			topology
			will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and
			P-OTN
			VP trails inside metro and core domains interconnecting EVC matrices.
			When
			one of those EVC links is interrupted, e.g. in the core between metro 1
			and
			metro 4 (see attached slide), then the EVC differentiated connection
			that is
			present on this link will be interrupted. At the EVC switch/bridge node
			in
			metro 4 this interruption is noticed and EVC-AIS is inserted in the
			downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4
			and
			D5.
			
			The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address,
			which guarantees that the AIS is broadcast to the endpoints of the EVC.
			
			I believe that it is time for you to adapt your view on co and cl modes
			and
			relate it to the forwarding mode **INSIDE** a transport entity. 
			
			What we know as the internet is essentially an "IP differentiated
			connection" with a billion or more ports.
			What we know as an IP VPN is essentially an "IP differentiated
			connection"
			with e.g. n ports (n in the range of e.g. 2 to 1000).
			What we know as an Ethernet VLAN is essentially an "Ethernet
			differentiated
			connection" with n ports (n in the range of e.g. 2 to 1000).
			What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated
			connection" with 2 ports.
			What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports.
			
			Transport network OAM applies to transport entities, which are (in terms
			of
			G.800 am1) connections and differentiated connections.
			
			Regards,
			Maarten
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] 
			Sent: vrijdag 17 april 2009 22:00
			To: [email-masked]; [email-masked];
			[email-masked]; [email-masked]
			Cc: [email-masked]
			Subject: RE: [mpls-tp] Associated bidirectional transport path
			requirements
			
			John,  Thanks this is a great platform to explain why OAM for the 3
			network
			modes needs to be different.  I am getting a wee bit tired of folks
			trying
			to make all 3 network modes look alike (and then, even worse, interwork
			them
			as as peers...esp when not not top-of-stack
			networks...I mean how silly can we get?).   I am even more frustrated by
			the fact those peddling this FUD only ever seem to consider OAM and
			forget
			all other DP/CP/MP components (esp top-of-stack message/file/stream
			application adaptations).  How wrong can this get! 
			
			In the co modes a *connection* is a very specific and *constraining*
			construct.....I am assuming here we respect the rules of a connection
			(ie
			single source) though some folks don't even bother to respect this, and
			this
			is despite the fact that we all know what problems multiple-source
			constructs can cause (from LDP/PHP....ergo MPLS-TP).
			
			When we have a connection this restricts *all* DP (ie traffic and OAM)
			to
			stay within the bounds of the connection.  Which is fine under
			defect-free
			conditions, but if we have leaking traffic then the constraining nature
			of
			the connection construct is broken.  In a nutshell what this means is
			that
			OAM that is of a request/response nature cannot be trusted in co mode
			networks under misconnectivity defects.....indeed, why should a leaking
			DP
			have a symmetric go/return defect behaviour?....very likely it won't.
			So
			whilst request/response OAM is right for the cl mode it is not right for
			the
			co mode under misconnectivity defect conditions.
			
			More generally the 3 modes are different and not just in OAM
			requirements....but AIS/FDI in the cl mode?...do me a favour!...at least
			IEEE had the good sense to bin this for Ethernet even though it remains
			in
			Y.1731.  And which is why I often trot-out the rather silly (to have to
			say
			this) observation that if IP (cl mode) could do it all then why have
			IETF
			found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).  The
			answer lies in the physics...and G.800 attempts to explain that
			physics....G.805 does not.
			
			So, the 3 modes are different...please accept/rejoice in this fact as
			they
			all offer something different/important.  But do not be hoodwinked by
			those
			who peddle a story that that tries to make the OAM of the 3 modes the
			same. 
			
			regards, Neil 
			
			> -----Original Message-----
			> From: [email-masked]
			> [mailto:[email-masked]] On Behalf Of Drake, John E
			> Sent: 17 April 2009 20:02
			> To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers
			> Cc: [email-masked]
			> Subject: Re: [mpls-tp] Associated bidirectional transport path 
			> requirements
			> 
			> Italo,
			> 
			> As described in the MPLS TP OAM Requirements I-D, virtually all of the
			
			> OAM functions require a return path, and in the absence of a return 
			> path they are disabled.
			> 
			> As described in David Sinicrope's meeting minutes 
			> (http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/
			> meeting-no
			> tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an 
			> MPLS TP network needs to be capable of getting IP packets from 
			> destination to source; neither the minutes nor I stipulate that a 
			> control plane needs to be used to instantiate this forwarding.
			> 
			> As an aside, the issue of return path for unidirectional LSPs could be
			
			> charaterized as the elephant in the room.  In the MPLS TP OAM 
			> Framework I-D, unicast LSPs are only mentioned three times and return 
			> paths not at all.
			> 
			> Thanks,
			> 
			> John
			> > -----Original Message-----
			> > From: BUSI ITALO [mailto:[email-masked]]
			> > Sent: Friday, April 17, 2009 1:59 AM
			> > To: Drake, John E; Alexander Vainshtein; Maarten Vissers
			> > Cc: [email-masked]
			> > Subject: RE: [mpls-tp] Associated bidirectional transport path 
			> > requirements
			> > 
			> > John,
			> > 
			> > I might have missed the agreement of MPLS-TP being capable of 
			> > sending replies to OAM requests sent on uni-directional LSPs.
			> > 
			> > This requirement does not belong to the first set of requirements 
			> > ITU-T is expecting to be met by October.
			> > 
			> > However, I think this in a potential interesting additional 
			> > requirement to be taken into account (at worst in a
			> subsequent phase).
			> > 
			> > I think that this requirement needs to be evaluated versus other 
			> > more important requirements (e.g. the possibility to work w/o IP 
			> > forwarding and the need for OAM to continue to monitor the data 
			> > plane also in case of failures affecting the control or management 
			> > plane).
			> > 
			> > I am open to discuss it but not sure this is the right time because 
			> > I wish to avoid delaying the first phase of the design solution.
			> > 
			> > Thanks, Italo
			> > 
			> > > -----Original Message-----
			> > > From: [email-masked]
			> > > [mailto:[email-masked]] On Behalf Of Drake, John E
			> > > Sent: Thursday, April 16, 2009 8:00 PM
			> > > To: Alexander Vainshtein; Maarten Vissers
			> > > Cc: [email-masked]
			> > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
			> > > requirements
			> > > 
			> > > At the meeting last fall at Juniper in Massachusetts, I
			> > think it was
			> > > agreed that an MPLS TP network needs to have a forwarding
			> > capability
			> > > for management, control, and OAM packets (e.g., sending
			> > replies to OAM
			> > > requests sent on uni-directional LSPs) even if it does not
			> > have an IP
			> > > forwarding data plane.
			> > > 
			> > > > -----Original Message-----
			> > > > From: Alexander Vainshtein
			> > > [mailto:[email-masked]]
			> > > > Sent: Thursday, April 16, 2009 9:57 AM
			> > > > To: Maarten Vissers
			> > > > Cc: [email-masked]
			> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
			> > > > requirements
			> > > > 
			> > > > Maarten,
			> > > > It seems that you've just (implicitly and, probably,
			> > > > inadvertently) stated the following:
			> > > > 
			> > > >                  MPLS-TP OAM will not ever support MIP loopback function
			> > (and fault
			> > > > localization which requires this function ) for
			> > unidirectional P2MP
			> > > > and P2P paths.
			> > > > 
			> > > > If this statement is correct, this (IMHO and FWIW)
			> raises a valid
			> > > > question:
			> > > > 
			> > > >                  Is MPLS-TP an appropriate solution for these
			> types of transport
			> > > > paths?
			> > > > 
			> > > > For the reference, IP/MPLS provides this kind of
			> > functionality today
			> > > > for (unidirectional - but it does not know any other
			> > type) P2P LSPs
			> > > > as described in RFC 4379. And its extension to P2MP LSPs seems 
			> > > > easy...
			> > > > 
			> > > >  
			> > > > 
			> > > > Regards,
			> > > > 
			> > > >      Sasha
			> > > > 
			> > > > 
			> > > > 
			> > > > ________________________________________
			> > > > From: [email-masked] [[email-masked]]
			> > On Behalf
			> > > > Of Maarten Vissers [[email-masked]]
			> > > > Sent: Thursday, April 16, 2009 3:24 PM
			> > > > To: 'Adrian Farrel'
			> > > > Cc: [email-masked]
			> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
			> > > > requirements
			> > > > 
			> > > > Adrian,
			> > > > 
			> > > > >> <quote>
			> > > > >>      The intermediate nodes (including MEPs, MIPs and
			> > > > other internal
			> > > > >>       functions as appropriate) of a co-routed
			> > > > bidirectional transport
			> > > > >>       path at each (sub-)layer MUST be aware of the pairing
			> > > > >>       relationship of the forward and the backward
			> > > > directions of that
			> > > > >>       transport path.
			> > > > >> <end quote>
			> > > > >
			> > > > > There is no way this is a functional requirement. That
			> > > is, there is
			> > > > > *nothing* that can be observed from a black box point of
			> > > view that
			> > > > > results from adhering to this requirement.
			> > > > 
			> > > > Your understanding is not correct. It is very much
			> observable if
			> > > > this requirement is met from a black box point of view.
			> > > > The MIP functions can only perform the Loopback when there is a 
			> > > > co-routed bidirectional transport path. The MPLS-TP LBM packet 
			> > > > received at a MIP needs to be returned (as LBR
			> > > > packet) to the originating MEP function via the other
			> > direction of
			> > > > the co-routed bidirectional transport path. This other
			> direction
			> > > > would not be available in an associated bidirectional transport 
			> > > > path... and thus the loopback test
			> > > would fail.
			> > > > 
			> > > > Similarly, when we have to apply TCM MEPs to monitor a
			> > segment, then
			> > > > this is possible in a co-routed bidir transport path
			> but not in a
			> > > > associated bidir transport path. In the first case the TCM MEP 
			> > > > Source and Sink functions are co-located and can
			> exchange what is
			> > > > called "remote information" which is necessary for performance 
			> > > > monitoring.
			> > > > In the latter case the TCM MEP Source and Sink functions
			> > are in e.g. 
			> > > > different nodes in the network and TCM would not be able
			> > to provide
			> > > > performance monitoring.
			> > > > 
			> > > > > The entirety of the bracketted text "(including MEPs,
			> > > MIPs and other
			> > > > internal
			> > > > > functions as appropriate)" should be deleted. It does not
			> > > > add to "The
			> > > > > intermediate nodes."
			> > > > 
			> > > > Your understanding is not correct. This text must not be
			> > deleted at
			> > > > all.
			> > > > 
			> > > > > Actually, I am quite fed up about this persistent
			> > > insistence on the
			> > > > inclusion
			> > > > > of "Tandem Connection." The definition within the ITU-T of
			> > > > this term
			> > > > > is
			> > > > poorly
			> > > > > specified and comes from the monitoring of a path that is
			> > > > parallel (i.e.
			> > > > tandem)
			> > > > > to the data path being monitored. This definition of TC
			> > > > seems to be at
			> > > > variance,
			> > > > > and would be if the ACH was actually in band.
			> > > > 
			> > > > I don't understand where your interpretation of tandem
			> > connection is
			> > > > described in ITU-T recommendations. I.e. "from the
			> > monitoring of a
			> > > > path that is parallel (i.e. tandem) to the data path being 
			> > > > monitored."?
			> > > > 
			> > > > There is a "network connection" and this network
			> > connection is a set
			> > > > of interconnected "link connections" and "matrix
			> connections". A
			> > > > subset of those interconnected link connections and matrix 
			> > > > connections can be monitored and is then referred to as
			> a "tandem
			> > > > connection". There is no "path that is parallel to the
			> > data path". 
			> > > > There is only additional OAM inserted inside the data
			> path by the
			> > > > TCM MEP_So function and this OAM is extracted from the
			> > data path by
			> > > > the TCM MEP_Sk function.
			> > > > 
			> > > > Regards,
			> > > > Maarten
			> > > > 
			> > > > 
			> > > > -----Original Message-----
			> > > > From: [email-masked]
			> > > > [mailto:[email-masked]] On Behalf Of Adrian Farrel
			> > > > Sent: donderdag 16 april 2009 11:59
			> > > > To: Alexander Vainshtein; [email-masked]
			> > > > Cc: BUSI ITALO; [email-masked]
			> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
			> > > > requirements
			> > > > 
			> > > > Hi Sasha,
			> > > > 
			> > > > > Unfortunately I cannot fully agree with your statement:
			> > > > >
			> > > > > <quote>
			> > > > >     From the point of view of hardware, co-routed
			> > > bidirectional LSPs
			> > > > >     are a special case of associated bidirectional LSPs.
			> > > > > <end quote>
			> > > > >
			> > > > > This statement would be obviously correct, were it not for
			> > > > Requirement
			> > > > > 34 in the latest MPLS-TP requirements draft
			> > > > 
			> > > > OK. Got it.
			> > > > 
			> > > > But what is this doing in the data plane requirements section?
			> > > > 
			> > > > In fact, what is this requirement actually saying?
			> > > > 
			> > > > > <quote>
			> > > > >      The intermediate nodes (including MEPs, MIPs and
			> > > other internal
			> > > > >       functions as appropriate) of a co-routed
			> > > > bidirectional transport
			> > > > >       path at each (sub-)layer MUST be aware of the pairing
			> > > > >       relationship of the forward and the backward
			> > > > directions of that
			> > > > >       transport path.
			> > > > > <end quote>
			> > > > 
			> > > > There is no way this is a functional requirement. That
			> > is, there is
			> > > > *nothing* that can be observed from a black box point of
			> > view that
			> > > > results from adhering to this requirement.
			> > > > 
			> > > > Therefore it could be assumed that this requirement is met by 
			> > > > configuring some data plane database component through the 
			> > > > management plane. The database component is not used
			> for anything
			> > > > except to satisfy this requirement for "awareness".
			> > > > 
			> > > > Ben! Can we please try to rewrite this requirement in terms of 
			> > > > behavior?
			> > > > 
			> > > > > Please note that Requirement 34 is the ONLY item in the
			> > > > list that is
			> > > > > specific for co-routed bidirectional LSPs. (The pairing
			> > > > requirements
			> > > > > at end points for co-routed and associated bidirectional
			> > > paths are
			> > > > > exactly the same even if they appear in two different
			> > > items in the
			> > > > > requirements' list).
			> > > > > In other words, without Requirement 34 the notion of
			> co-routed
			> > > > > bidirectional paths would be void of any data plane content.
			> > > > >
			> > > > > The somewhat vague scope of this requirement ("other internal 
			> > > > > functions as appropriate") creates a suspicion that HW
			> > > > support of the
			> > > > > pairing awareness may be required in order to comply with it.
			> > > > 
			> > > > The entirety of the bracketted text "(including MEPs,
			> > MIPs and other
			> > > > internal functions as appropriate)" should be deleted. It
			> > does not
			> > > > add to "The intermediate nodes."
			> > > > 
			> > > > > The following text in the draft increases this suspicion:
			> > > > >
			> > > > > <quote>
			> > > > >   Tandem Connection: A tandem connection is an
			> > arbitrary part of a
			> > > > >   transport path that can be monitored (via OAM)
			> > > > independently from the
			> > > > >   end-to-end monitoring (OAM).  It may be a monitored
			> > segment or a
			> > > > >   monitored concatenated segment of a transport path.  
			> > The tandem
			> > > > >   connection may also include the forwarding engine(s) of
			> > > > the node(s)
			> > > > >   at the edge(s) of the segment or concatenated segment.
			> > > > > <end quote>
			> > > > 
			> > > > Actually, I am quite fed up about this persistent
			> > insistence on the
			> > > > inclusion of "Tandem Connection." The definition within
			> > the ITU-T of
			> > > > this term is poorly specified and comes from the
			> monitoring of a
			> > > > path that is parallel (i.e. tandem) to the data path being 
			> > > > monitored. This definition of TC seems to be at variance,
			> > and would
			> > > > be if the ACH was actually in band.
			> > > > 
			> > > > > Doesn't "forwarding engine" sound like hardware to you?
			> > > > 
			> > > > Yes, but so what?
			> > > > 
			> > > > > IMHO it is worth noting that neither the MPLS-TP
			> > > Requirements draft
			> > > > > nor the MPLS-TP OAM requirements one
			> > > > > 
			> > > > 
			> > > 
			> > 
			> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen
			> > > > > ts-01.txt) contain any requirements dealing with tandem
			> > > connections.
			> > > > >
			> > > > > But tandem connections are discussed in the MPLS-TP OAM
			> > Framework
			> > > > > draft
			> > > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-fr
			> > > > amework-00.txt
			> > > > ).
			> > > > 
			> > > > Right.
			> > > > Let's just get rid of an unnecessary term and bring all
			> the I-Ds
			> > > > into line.
			> > > > 
			> > > > > The bottom line, IMHO, is that some clarity regarding
			> > > co-routed vs.
			> > > > > associated
			> > > > > bidirectional paths is still required. One way to provide
			> > > > that could
			> > > > > be by explicitly limiting Requirement 34 to specific
			> > > functionality.
			> > > > 
			> > > > Agreed.
			> > > > 
			> > > > Adrian
			> > > > 
			> > > > 
			> > > > 
			> > > > 
			> > > > ________________________________________
			> > > > From: Adrian Farrel [[email-masked]]
			> > > > Sent: Thursday, April 16, 2009 12:13 AM
			> > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO
			> > > > Cc: [email-masked]
			> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
			> > > > requirements
			> > > > 
			> > > > Hi Sasha,
			> > > > 
			> > > > Not really sure whether you are misrepresenting anyone, but...
			> > > > 
			> > > > > 1. My reading of  one of Ben's  messages is that associated 
			> > > > > bidirectional paths are the only types of paths that can be
			> > > > created in
			> > > > > the existing networks; "true" co-routed bidirectional paths
			> > > > will have
			> > > > > to wait until (if ever) new equipment becomes available.
			> > > > 
			> > > > This is clearly nonsense!
			> > > > From the point of view of hardware, co-routed
			> > bidirectional LSPs are
			> > > > a special case of associated bidirectional LSPs.
			> > > > 
			> > > > If you can set up two unidirectional LSPs (e.g. using the
			> > management
			> > > > plane) you can surely set up a co-routed
			> > > bidirectional LSP.
			> > > > 
			> > > > There are shipping solutions that achieve co-routed
			> bidirectional
			> > > > LSPs using the control plane. These either use the GMPLS
			> > (which is
			> > > > cleaner) or non-standard proprietary solutions (which is
			> > messy but
			> > > > functional).
			> > > > 
			> > > > But (of course) the management plane or control plane
			> > solutions have
			> > > > nothing to do with availability of equipment as they 
			> are software
			> > > > solutions.
			> > > > 
			> > > > > 2. My reading of one of Neil's messages is that the actual
			> > > > driver for
			> > > > > co-routed bidirectional paths may be experience with existing 
			> > > > > transport networks rather than any specific benefit.
			> > > > 
			> > > > Isn't that the case with 75% of the MPLS-TP requirements?
			> > > > Which is not to say it is a bad thing.
			> > > > 
			> > > > A large driver for MPLS-TP is to give the packet network
			> > the look,
			> > > > feel, and behavioral characteristics of a "legacy"
			> > > > transport network.
			> > > > 
			> > > > > Based on these observations, I'd guess (FWIW) that:
			> > > > > * associated bidirectional paths are, at least for the time
			> > > > >    being, the most important type of bidirectional paths in
			> > > > >    MPLS-TP
			> > > > 
			> > > > I think that is wrong both given my statement above, and
			> > given that
			> > > > other upgrades to existing MPLS solutions will be
			> needed to reach
			> > > > the full function level of MPLS-TP.
			> > > > 
			> > > > > * they had a good chance to remain the only type of
			> > bidirectional
			> > > > >   paths in  real deployments.
			> > > > 
			> > > > I don't see what that follows from.
			> > > > 
			> > > > Cheers,
			> > > > Adrian
			> > > > 
			> > > > _______________________________________________
			> > > > mpls-tp mailing list
			> > > > [email-masked]
			> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
			> > > > 
			> > > > _______________________________________________
			> > > > mpls-tp mailing list
			> > > > [email-masked]
			> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
			> > > > 
			> > > > 
			> > > _______________________________________________
			> > > mpls-tp mailing list
			> > > [email-masked]
			> > > https://www.ietf.org/mailman/listinfo/mpls-tp
			> > > 
			> > 
			> _______________________________________________
			> mpls-tp mailing list
			> [email-masked]
			> https://www.ietf.org/mailman/listinfo/mpls-tp
			> 
			_______________________________________________
			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.

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Apr 2009 14:39:04 +0200

Andy,
 
Please read my response to your post. I have indicated that your
understanding of existing equipment and protection switching recommendations
is incorrect. 
 
The use of AIS/FDI and the general agreement that AIS is mandatory (i.e. not
optional) will allow us to use the same fault detection, alarm suppression
and fault localisation as in other transport network technologies (SDH, OTN,
Ethernet).
 
If AIS is optional, then operators not using AIS must find other means to
distinguish between LOC alarm due to a continuity/connectivity fault in the
layer network, or in the server layer. If such other means are not deployed
then there are two alternatives:
1) ignore every LOC alarm (assume that it is a server layer fault), until
the customer complains that his/her connection is broken
2) start fault localisation on every LOC alarm, and conclude in 90-99% of
the cases that the problem was a server layer fault.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 27 april 2009 13:20
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Han,
 
In his post below, Maarten is not claiming that AIS is needed for alarm
suppression. He is saying that he sees it being used to distinguish faults
in a server layer from faults in the client layer. As you will see in my
post back to Maarten, this cannot be practically achieved.
 
I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, in
the packet world of MPLS-TP, AIS/FDI cannot be simple and therefore cannot
be the same as in SONET/SDH.
 
The objective is to reuse the same basic fault detection, alarm suppression,
and fault localisation as SONET/SDH. This is readily achieved with the CC
messages in the dataplane.
 
However, adding AIS/FDI would require a completely new configuration
management system and a completely new set of fault conditions requiring
localisation. Ironically, adding a packet AIS/FDI effectively removes the
compatibility with SONET/SDH management systems and processes.
 
Andy

Andy Reid 

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

  _____  

From: lihan [mailto:[email-masked]] 
Sent: 27 April 2009 02:41
To: 'Maarten Vissers'; Reid,ABD,Andy,CXM R
Cc: [email-masked]
Subject: 答复: [mpls-tp] Associated bidirectional transport path
requirements

Support!

AIS/FDI is very importance for network management. MPLS-TP is divided into
three layers in order to enhance the scalability and OAM. It is very
important to distinguish the failure is belong to server layer or client
layer. AIS/FDI is a simple and well-known mechanism to realize alarm
suppression and fault localization. 

Best regards,

    Han Li

Han Li, Ph.D.

Fax: +86 10 63601087

MOBILE: 13501093385

  _____  

发件人: [email-masked] [mailto:[email-masked]] 代表
Maarten Vissers
发送时间: 2009年4月25日 2:15
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [mpls-tp] Associated bidirectional transport path requirements

Andy,

The need for AIS/FDI is a consequence of the deployment of loss of
continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of
such CCM OAM is to be able to detect a misconfiguration or fault of a
connection function (fabric) in the connection, which interrupts the
forwarding of traffic in the connection. This is a fault condition that can
only be discovered by the layer network in which the connection is
supported. It requires that the organization responsible for the layer
network takes action (i.e. locate the layer's connection function that
includes the fault) to restore the connection.

Unfortunately, an interruption of one of the link connections of such
connection (due to a fault in a server layer) will also interrupt the
forwarding of traffic in the connection.

As such, loss of CC messages (LOC defect) does not provide sufficient
information to determine if the configuration in the layer's connection
functions along the connection have to be checked and corrected.

AIS has been introduced and is used to help differentiate between the two
fault cases.

1) if LOC and AIS are detected, then there is a server layer fault. This
server layer fault is already reported by the server layer MEP detecting
this fault. No action is required, so no alarm to generate. 

2) if LOC is detected and there is no AIS, then there is a layer network
fault (i.e. continuity fault). Fault localization must be started to locate
the misconfigured or failed connection function. Once this faulty connection
function is located, the configuration fault (or hardware fault) can be
corrected, after which the connection is retored.

The interruption of the forwarding of traffic in the connection in both
fault cases is however registered as part of performance monitoring. This
performance monitoring information is used to verify the performance against
the SLA for the connection.

Regards,

Maarten

  _____  

Maarten,

These points are irrelevant to the points I made. My point is that AIS/FDI
gives no information above what is already known - it is only adds
complexity and fault liability. Neither of your points change this.

Andy

Andy Reid 

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

  _____  

Andy,

> The problem is *not* about a lack of alarm suppression in the data plane -
that information is readily available.

I don't believe that this is a correct statement in a multi-operator
transport network, or in transport networks of one operator that have more
then one administrative subdomain (each with its own network management
system). A problem occuring in admin domain A will be unknown in admin
domain B. The loss of continuaity alarms that are activated in admin domain
B due to the fault in admin domain A will appear as primary alarms,
suggesting connectivity problems in admin domain B.

> guys want to know whether their customer service is working.

This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means
of the additional SSF alarm. The SSF alarm is for the service guys telling
them that the service was interrupted due to a fault in a server layer. AIS
suppresses the LOC alarm in those cases so that the maintenance guys don't
get triggered and start looking for a fault that is outside their area.

Regards,

Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: woensdag 22 april 2009 12:14
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Liu,

Allow me to jump in. You are bringing together two things which are separate
and for which AIS/FDI is no help. Maintenance operations are concerned with
two separate things.

1)  Identifying faults in equipment, line plant, and other systems (eg
misconfigurations) and fixing them (equipment maintenance).

2)  Identifying the health of end to end connections, especially when they
are directly supporting customer services (service maintenance).

The problem is *not* about a lack of alarm suppression in the data plane -
that information is readily available. If, at an end equipment, I have a
good server/section layer and a loss of CC at the client layer, I *know* the
fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think
about, if the fault is in the end equipment, it is quite likely that the
fault means it cannot report the traffic loss to the management system!)

The issue arises because the two sides of maintenance want different things.
The fault fixing guys want to locate the fault and don't want any other
information. The service maintenance guys want to know whether their
customer service is working.

This arose in the early days of SONET/SDH, when the operations guys demanded
that the equipment did *not* suppress the traffic alarm even when AIS was
being received as the service guys want to know about the alarms. The normal
practice is for the equipment to report the alarms *including* AIS and then
a filter is applied in the management system to suppress alarms to the fault
fixing guys. As I'm aware, there are many different techniques applied for
the filtering algorithms, especially when you consider multiple concurrent
faults in a network, however, the existance of AIS/FDI doesn't add anything
to these that's not already known. In fact, I believe simple time-stamp
correlation is one of the most powerful and widely used techniques. And if
the equipment starts messing up the reporting of loss of CC because it
waiting for/persistence checking AIS/FDI, it could end up messing up simple
time-stamp correlation! 

In practice, it is often not quite a simple as this, as the service guys
like to be able to 'localise' the fault. However, under most circumstances,
the filter has automatically done this. So localisation you describe is only
when the filter hasn't worked for some reason.

But the bottom line is, whatever operations process you want to use, AIS/FDI
doesn't add anything other than complexity and fault liability to the
equipment. Remember AIS goes back to the TDM world where you *have to fill
the bit stream with something*.

Andy

Andy Reid 

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 22 April 2009 09:15
To: Harrison,N,Neil,CXM R
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Neil: 
  thank you for wasting more time in describling the problems. but I think
some of what you said is no relations with our problem.for me, maybe AIS/FDI
functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there is
no AIS/FDI functions, when there is a defects in a given layer network, it
can cause multiple alarm events to be raised. it is diffcult  for operators
to locate and diagnose the faults. 
 though I completely agree you on  adding new things and functions will
bring some complexity . but if we have no functions, it is more complex and
difcult for operators to maintence and administrator the network. so I think
every new functions and things may have positive and negative effects. but
we should consider it very much, don't delete some functions at random. 

best regards 
liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送

<[email-masked]> 

主题

 

Liu, 
  
If MPLS-TP is going to be taken seriously as a transport network (like
SDH/SONET) then the 2 key MUST HAVE requirements are these. 
  
1    Provide a transparent client/server relationship...which means: 
-    all client bits treated equally 
-    client bit ordering preserved 
-    no attempt to infer client symbol (ie sequence of client bits) meaning
and no attempt to change client symbols 
-    the traffic behaviour of client X must not impact the performance
experienced by client Y 
  
A key corollary of the above is that MPLS-TP must only support proper
connections (ie single source constructs) 

2   Since MPLS-TP is a transport network it is not a top-of-stack network
(ie it does not support directly external message/file/stream applications).
MPLS-TP therefore does not require an E-NNI specification.  A key corollary
of this is that MPLS-TP will not have any peer interworking relationship
with any other network mode/technology. 

Now wrt OAM MPLS-TP is a co-ps mode network.  You could argue this should
have FDI/AIS....however, the merit of this is highly questionable.  When I
and colleagues discussed whether PBB-TE (also a co-ps mode network) should
have FDI/AIS we concluded that on balance it was not a good idea.....and
note that initially I was in favour of having AIS, but my colleagues
provided strong technical arguments that convinced me otherwise. 
  
AIS/FDI is historically linked to the early PDH co-cs mode layer networks
that used TTL logic.  When this died it put out a +5V (all 1s) signal by
default, ie it required no conscious effort to generate it.....this is key
point.  Further, in these networks there is a fairly static/long-holding
client server relationship.  Clearly this is not true in the cl-ps mode and
it's why IETF have never specified AIS for IP and its why IEEE had the good
sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO
retained it in Y.1731....but I suspect any operator planning to use Ethernet
equipment would always look to IEEE stds and not ITU ones). 
  
AIS/FDI and the co-ps mode is debatable.  As I noted above, on balance we
considered not a good idea for PBB-TE OAM because it requires a conscious
effort to generate it (unlike the co-cs mode) so there are likely to be
scaling problems and its one more thing to go wrong. 
  
You should also have seen me make the point many times in the past that the
always-on defect detection/handling OAM needs to be as simple/sparse as
possible with as little config as possible because we need super
reliability......TCM goes completely against the grain here.  Also note that
the OAM required for each of the 3 network modes is not the same, despite
what some claim. 
  
regards, Neil 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 21 April 2009 02:59
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Deborah: 
maybe what you said is right. but I can't completely agree your opinions.
IMO. mpls-tp is regard as transport network like SDH/SONET. so it should
have AIS/FDI fuctions as SDH/SONET. 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送

[email-masked] 

主题

 

Deborah

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil 

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

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 27 Apr 2009 19:49:09 +0200

Maarten,
 
I have seen some SPs not willing to deploy AIS/FDI in their network and some SPs supporting the requirement for AIS/FDI.
 
As a consequence I think that AIS/FDI (like all OAM features) should be a feature optional to use.
 
However, this discussion has convinced myself that the most appropriate approach is to have AIS/FDI enabled by default with the option for the SP to disable it.
 
Disabling AIS/FDI, or deploying NEs that does not support the capability, has the implications you have listed below and as such it should be a conscious decision from the SP.
 
Italo

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: Monday, April 27, 2009 2:39 PM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Andy,
	 
	Please read my response to your post. I have indicated that your understanding of existing equipment and protection switching recommendations is incorrect. 
	 
	The use of AIS/FDI and the general agreement that AIS is mandatory (i.e. not optional) will allow us to use the same fault detection, alarm suppression and fault localisation as in other transport network technologies (SDH, OTN, Ethernet).
	 
	If AIS is optional, then operators not using AIS must find other means to distinguish between LOC alarm due to a continuity/connectivity fault in the layer network, or in the server layer. If such other means are not deployed then there are two alternatives:
	1) ignore every LOC alarm (assume that it is a server layer fault), until the customer complains that his/her connection is broken
	2) start fault localisation on every LOC alarm, and conclude in 90-99% of the cases that the problem was a server layer fault.
	 
	Regards,
	Maarten

	Han,

	 

	Andy

	Andy Reid 

		Support!

		 

		Best regards,

		    Han Li

		Han Li, Ph.D.

		Fax: +86 10 63601087

		MOBILE: 13501093385

		Andy,

		Regards,

		Maarten

		Maarten,

		Andy

		Andy Reid 

			 

			Andy,

			Regards,

			Maarten

			Liu,

			 

			Andy

			Andy Reid 

				 

				Neil: 

				best regards 
				liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送

<[email-masked]> 

主题

 

				Liu, 

				  

				  

				  
				regards, Neil 

				Deborah: 
				
				do you think so. 
				
				best regards 
				liu 

2009-04-20 23:47 

收件人

抄送

[email-masked] 

主题

 

				

				Deborah
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On
				Behalf Of Maarten Vissers
				Sent: Monday, April 20, 2009 10:05 AM
				To: [email-masked]
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated bidirectional transport path
				requirements
				
				Neil,

				

				

				
				Regards,
				Maarten
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] 
				Sent: vrijdag 17 april 2009 22:00
				To: [email-masked]; [email-masked];
				[email-masked]; [email-masked]
				Cc: [email-masked]
				Subject: RE: [mpls-tp] Associated bidirectional transport path
				requirements

				

				
				regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 27 Apr 2009 19:11:10 +0100

Italo,

What this discussion has convinced me of is that we do not have a common
understanding of what AIS is, what it is used for and where it is used.

Lack of such an understanding is causing confusion.

For example it is still not clear to me whether when talking about AIS/FDI
we are talking about:

1) Injecting an artificial (i.e. Not generated by the client or the
transport path ingress) packet stream into a transport path by some piece of
equipment along the transport path.
2) A northbound message from a piece of equipment into the management
system.
3) Both.
4) Something entirely different.

Without such clarity of understanding I don't see how it's possible to
articulate a functional requirement, if such a requirement exists.

It is also not clear to me how having some SPs not wanting AIS/FDI and
others apparently[1] wanting it leads to a conclusion it should be turned on
by default.

Ben

[1] No SP I have seen has stated on the list they want it but we are waiting
for Andy to double check back with his transport experts.

On 27/04/2009 18:49, "BUSI ITALO" <[email-masked]> wrote:

> Maarten,
>  
> I have seen some SPs not willing to deploy AIS/FDI in their network and some
> SPs supporting the requirement for AIS/FDI.
>  
> However, this discussion has convinced myself that the most appropriate
> approach is to have AIS/FDI enabled by default with the option for the SP to
> disable it.
>  
> Disabling AIS/FDI, or deploying NEs that does not support the capability, has
> the implications you have listed below and as such it should be a conscious
> decision from the SP.
>  
> Italo
> 
> 
> Please read my response to your post. I have indicated that your understanding
> of existing equipment and protection switching recommendations is incorrect.
> 
> optional) will allow us to use the same fault detection, alarm suppression and
> fault localisation as in other transport network technologies (SDH, OTN,
> Ethernet).
> 
> 1) ignore every LOC alarm (assume that it is a server layer fault), until the
> customer complains that his/her connection is broken
> 2) start fault localisation on every LOC alarm, and conclude in 90-99% of the
> cases that the problem was a server layer fault.
> 
> Regards,
> Maarten
> 
> suppression. He is saying that he sees it being used to distinguish faults in
> a server layer from faults in the client layer. As you will see in my post
> back to Maarten, this cannot be practically achieved.
> 
> I agree, in SONET/SDH, AIS/FDI is simple and well known. Unfortunately, in the
> packet world of MPLS-TP, AIS/FDI cannot be simple and therefore cannot be the
> same as in SONET/SDH.
> 
> plc which may be privileged or confidential. The information is intended to be
> for the use of the individual(s) or entity named above. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or use
> of the contents of this information is prohibited. If you have received this
> electronic message in error, please notify us by telephone or email (to the
> numbers or address above) immediately.
> 
> recorded to secure effective operation and for other lawful business purposes.
> 
> 
> 
> 
> three layers in order to enhance the scalability and OAM. It is very important
> to distinguish the failure is belong to server layer or client layer. AIS/FDI
> is a simple and well-known mechanism to realize alarm suppression and fault
> localization. 
> 
> 
> 
> 
> 
> Best regards,
> 
>    Han Li
> 
> The need for AIS/FDI is a consequence of the deployment of loss of continuity
> checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of such CCM OAM
> is to be able to detect a misconfiguration or fault of a connection function
> (fabric) in the connection, which interrupts the forwarding of traffic in the
> connection. This is a fault condition that can only be discovered by the layer
> network in which the connection is supported. It requires that the
> organization responsible for the layer network takes action (i.e. locate the
> layer's connection function that includes the fault) to restore the
> connection.
> 
> 
> 
> server layer fault is already reported by the server layer MEP detecting this
> fault. No action is required, so no alarm to generate.
> 
> 2) if LOC is detected and there is no AIS, then there is a layer network fault
> (i.e. continuity fault). Fault localization must be started to locate the
> misconfigured or failed connection function. Once this faulty connection
> The interruption of the forwarding of traffic in the connection in both fault
> cases is however registered as part of performance monitoring. This
> gives no information above what is already known - it is only adds complexity
> and fault liability. Neither of your points change this.
> 
> 
> 
> Andy
> 
> 
> 
> 
> 
> Andy Reid 
> plc which may be privileged or confidential. The information is intended to be
> for the use of the individual(s) or entity named above. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or use
> of the contents of this information is prohibited. If you have received this
> electronic message in error, please notify us by telephone or email (to the
> numbers or address above) immediately.
> 
> recorded to secure effective operation and for other lawful business purposes.
> 
> 
> 
> 
> 
> 
> I don't believe that this is a correct statement in a multi-operator transport
> network, or in transport networks of one operator that have more then one
> administrative subdomain (each with its own network management system). A
> problem occuring in admin domain A will be unknown in admin domain B. The loss
> of continuaity alarms that are activated in admin domain B due to the fault in
> admin domain A will appear as primary alarms, suggesting connectivity problems
> in admin domain B.
> 
> 
> 
>> The fault fixing
> This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means of
> the additional SSF alarm. The SSF alarm is for the service guys telling them
> that the service was interrupted due to a fault in a server layer. AIS
> suppresses the LOC alarm in those cases so that the maintenance guys don't get
> triggered and start looking for a fault that is outside their area.
> 
> 
> 
> Regards,
> 
> Maarten
> 
> 
> 
> 
> 
> 
> 2)  Identifying the health of end to end connections, especially when they are
> directly supporting customer services (service maintenance).
> 
> 
> 
> that information is readily available. If, at an end equipment, I have a good
> server/section layer and a loss of CC at the client layer, I *know* the fault
> is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think about,
> if the fault is in the end equipment, it is quite likely that the fault means
> it cannot report the traffic loss to the management system!)
> 
> 
> 
> information. The service maintenance guys want to know whether their customer
> service is working.
> 
> 
> 
> practice is for the equipment to report the alarms *including* AIS and then a
> filter is applied in the management system to suppress alarms to the fault
> fixing guys. As I'm aware, there are many different techniques applied for the
> filtering algorithms, especially when you consider multiple concurrent faults
> in a network, however, the existance of AIS/FDI doesn't add anything to these
> that's not already known. In fact, I believe simple time-stamp correlation is
> one of the most powerful and widely used techniques. And if the equipment
> starts messing up the reporting of loss of CC because it waiting
> for/persistence checking AIS/FDI, it could end up messing up simple time-stamp
> correlation! 
> 
> 
> 
> In practice, it is often not quite a simple as this, as the service guys like
> to be able to 'localise' the fault. However, under most circumstances, the
> filter has automatically done this. So localisation you describe is only when
> the filter hasn't worked for some reason.
> 
> 
> 
> equipment. Remember AIS goes back to the TDM world where you *have to fill the
> bit stream with something*.
> 
> 
> 
> 
> 
> 
> 
> Andy
> 
> 
> 
> Andy Reid 
> plc which may be privileged or confidential. The information is intended to be
> for the use of the individual(s) or entity named above. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or use
> of the contents of this information is prohibited. If you have received this
> electronic message in error, please notify us by telephone or email (to the
> numbers or address above) immediately.
> 
> recorded to secure effective operation and for other lawful business purposes.
> 
> 
> 
> 
> 
> 
>  thank you for wasting more time in describling the problems. but I think some
> of what you said is no relations with our problem.for me, maybe AIS/FDI
> functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there is no
> AIS/FDI functions, when there is a defects in a given layer network, it can
> cause multiple alarm events to be raised. it is diffcult  for operators to
> locate and diagnose the faults.
> though I completely agree you on  adding new things and functions will bring
> some complexity . but if we have no functions, it is more complex and difcult
> for operators to maintence and administrator the network. so I think every new
> functions and things may have positive and negative effects. but we should
> consider it very much, don't delete some functions at random.
> 
> 
> best regards 
> liu 
> 
> 
> 
> <[email-masked]>
> 
> 2009-04-21 20:30 
> 
> 收件人
> 
> 2   Since MPLS-TP is a transport network it is not a top-of-stack network (ie
> it does not support directly external message/file/stream applications).
> MPLS-TP therefore does not require an E-NNI specification.  A key corollary of
> this is that MPLS-TP will not have any peer interworking relationship with any
> other network mode/technology.
>  
>  
> Now wrt OAM MPLS-TP is a co-ps mode network.  You could argue this should have
> FDI/AIS....however, the merit of this is highly questionable.  When I and
> colleagues discussed whether PBB-TE (also a co-ps mode network) should have
> FDI/AIS we concluded that on balance it was not a good idea.....and note that
> initially I was in favour of having AIS, but my colleagues provided strong
> technical arguments that convinced me otherwise.
>  
> AIS/FDI is historically linked to the early PDH co-cs mode layer networks that
> used TTL logic.  When this died it put out a +5V (all 1s) signal by default,
> ie it required no conscious effort to generate it.....this is key point.
> Further, in these networks there is a fairly static/long-holding client server
> relationship.  Clearly this is not true in the cl-ps mode and it's why IETF
> have never specified AIS for IP and its why IEEE had the good sense to
> throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO retained
> it in Y.1731....but I suspect any operator planning to use Ethernet equipment
> would always look to IEEE stds and not ITU ones).
>  
> the OAM required for each of the 3 network modes is not the same, despite what
> some claim. 
>  
> regards, Neil 
>  
> 
> 
> maybe what you said is right. but I can't completely agree your opinions. IMO.
> mpls-tp is regard as transport network like SDH/SONET. so it should have
> AIS/FDI fuctions as SDH/SONET.
> 
> do you think so. 
> 
> best regards 
> liu 
> 
> confidential. Recipients named above are obligated to maintain secrecy and are 
> not permitted to disclose the contents of this communication to others.
> 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 
> confidential. Recipients named above are obligated to maintain secrecy and are 
> not permitted to disclose the contents of this communication to others.
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Apr 2009 20:17:21 +0100

Isn't the solution here the same as the one I proposed for "TCM"?

Stop using short-cut terms that have definitions in other venues, but for 
which there is plenty of confusion because different interpretations have 
grown up over the years (some of them requirement/architecture, some of them 
solution).

Just write down the real, separate, modular functional requirements.

These can be partitioned, examined, discussed and agreed.

It would really help me personally if one of the proponents of AIS/FDI could 
set out a list of simple single sentence requirements (just like we have in 
the requirements I-Ds already). I would then be able to understand exactly 
what functions are being asked for.

It would be my guess, that such a decomposition would also bring an end to 
the "yes it is," "no it isn't" style of discussion.

Cheers,
Adrian

----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "BUSI ITALO" <[email-masked]>; "Maarten Vissers" 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 27, 2009 7:11 PM
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

>> Behalf Of
>> understanding
>> important
>> Vissers
>> continuity
>> fault
>> fault
>> complexity
>> transport
>> Behalf Of
>> [email-masked]
>> good
>> like
>> Behalf Of
>> [email-masked]
>> some
>> bring
>> have
>> what
>> Behalf Of
>> [email-masked]
>> IMO.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 27 Apr 2009 23:26:40 +0200

Hi Adrian,

> Isn't the solution here the same as the one I proposed for "TCM"?

Indeed, and that we do not have to around in circles about TCM.

How about:
the requirement is that a server layer shall inform its clients
that it has detected a service interuption, this to ensure that
the clients can inhibit (unnecessary) alarms.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Apr 2009 22:34:30 +0100

WFM (although I am not an OAM expert).

A
----- Original Message ----- 
From: "Huub van Helvoort" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 27, 2009 10:26 PM
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 28 Apr 2009 06:56:22 +0200

Huub,
I think that the requirement is to provide a mechanism to suppress
alarms in the networks, to ensure that alarms that may be generated by
client layers as a result of a failure condition in the server layer may
be suppressed.
Every thing else is a solution, etc. 
I propose to phrase the requirement appropriately and conclude the
discussion on this in the context of the requirements (until we are
getting to the solution phase). 
This requirement is included in the OAM requirement draft. 
Best regards,
NUrit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Huub van Helvoort
Sent: Tuesday, April 28, 2009 12:27 AM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
path requirements)

Hi Adrian,

How about:

Cheers, Huub.

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 07:43:28 +0100

Huub wrote 27 April 2009 22:27
> the clients can inhibit (unnecessary) alarms.

NH=> This only applies if the client/server binding is fixed.  And of
course way back in the 70s when binary all 1s popped out of the failed
TTL logic into the PDH transport hierarchy this was true.  Also: no
labels here and no client traffic units to create.   

Where the client can dynamically be re-routed in response to a server
failure the proposed text is not valid.  It is also not necessary that
the server has to keep track of where its client traffic routings have
moved to.  For example, if I create the topology of an IP layer network
with links provided by SDH, Ethernet, ATM, OTN, etc servers, and each of
these server links is provided by a different operator, then why should
the servers need have knowledge of where the IP flows have moved to in
response to a server layer failure when the new routes have been
calculated by the IGP in the IP layer network?  I can apply the same
logic to an SVC-based co-ps/co-cs mode client....indeed the co-cs mode
PSTN is like this.

These observations make it quite clear to me at least that just copying
the AIS behaviour of the old transport hierarchies that had fixed
client/server relationships is not a sensible thing to do.

IMO the only essential DP OAM requirement is that each layer network
should be self-sufficient wrt OAM and not rely on any server layer
primitives being passed upwards.

Moreover, it should also be noted that (i) the defects that can occur in
each of the 3 network modes are not the same and (ii) their OAM
requirements are not identically the same. So the OAM that applies to
the cl-ps mode (eg IP) is not the same as the OAM that applies to the
co-ps mode (eg MPLS-TP) and neither of these is identically the same as
the OAM that applies to the co-cs mode (eg SDH).

Note - The only point being considered here is the real client and
server traffic relationship.  The creation of a hierarchy of TCM
sublayers is a separate topic.  Further, it is quite clear from a simple
technical analysis that any non top-of-stack network has no need for
E-NNI peer-partition working between different operating parties.  So
this is also a separate issue.  However, I propose that this latter
point be captured in the MPLS-TP requirements draft due to its
stand-alone and generic importance, ie this applies to more than just DP
OAM.  Ben can you please consider this point as/when the MPLS-TP
requirements draft is updated.

regards, Neil

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 28 Apr 2009 09:43:37 +0200

I think that the requirements are defined in section 2.2.8 of
draft-ietf-mpls-tp-oam-requirements-01

Italo

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: Tuesday, April 28, 2009 6:56 AM
> To: [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
> transport pathrequirements)
> 
> Huub,

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 28 Apr 2009 09:46:13 +0200

If we agree that the requirement is included, so why do we keep with the
endless discussions on this requirement?

-----Original Message-----
From: ext BUSI ITALO [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 10:44 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; Adrian
Farrel
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport
pathrequirements)

Italo

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 09:07:11 +0100

Nurit,

I believe the reason we need this discussion is that there is an
unstated assumption here that the client/server relationship is fixed.
However, if the client can dynamically change its routing in response to
link failures in its topology (because some server layer network has
failed....which may or may not belong to the same operating party as the
client) then there is no fixed client/server relationship.

Refer to my post earlier today and consider what this means in the case
of a cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode
client layer network.  The key point here is the *routing process* in
the client is independent of the server layer network....so there is not
a fixed client/server relationship.  Further, there is also no
requirement for the server to keep track of where its client traffic
routings are at any epoch.....indeed why should it in the general case
where these are independent layer networks?

So the only OAM requirement that is critical is that the OAM of the
client and server layer networks are independent.  It is thus not
sensible to make client layer alarm supression a 'requirement' here...in
fact if this is in the OAM requirements then it is technically wrong and
should be removed IMO.

regards, Neil 
> Sent: 28 April 2009 08:46
> To: ext BUSI ITALO; [email-masked]; Adrian Farrel
> Cc: [email-masked]
> transportpathrequirements)
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Apr 2009 09:33:54 +0100

Huub,

On mature reflection...

> the clients can inhibit (unnecessary) alarms.

I believe that the use made of the information is out of scope. That would 
reduce us to...

> that it has detected a service interruption.

We might note that "service" is possibly ambiguous. Some people regard a 
"service" as being what exists in the client layer. Some people see it as 
what the server layer delivers to the client layer. Could we restate this in 
terms of server layer trails?

A

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 28 Apr 2009 13:20:21 +0200

Neil,

> labels here and no client traffic units to create.   

This is again very academic.
In real life failed TTL could get stuck at "1" or "0".
Between the TTL and the line there is analog circuitry
that can detect this "stuck at" and replace consequently the
HDB3 output by a 1.024 Mbit/s sinusoidal signal which in binary
is an all ONEs signal. The "stuck at" defect is reported and
the all ONEs is used to inhibit alarm reporting.
At the receiver side of the line it is similar, when a line
signal defect (e.g. LOS, LOC, LOF) is detected consequently
an all ONEs signal replaces the original. When there is a line
defect noise is received generating an arbitrary 0/1 pattern.
Replacing this noise by an all ONEs pattern again inhibits alarm
reporting. The LOS/LOC/LOF is the only alarm important for
fault localisation.

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 28 Apr 2009 13:31:11 +0200

Hi Adrian,

> On mature reflection...

;-)

> I believe that the use made of the information is out of scope. That 
> would reduce us to...
> 

The second part could be a separate requirement because MPLS-TP
is also a client layer:

If a client layer is informed by its server layer that a defect
in the server layer trail has been detected the client layer shall
not raise an alarm related to that defect.

> "service" as being what exists in the client layer. Some people see it 
> as what the server layer delivers to the client layer. Could we restate 
> this in terms of server layer trails?

If you think it is more appropriate and less ambiguous:

The server layer shall inform its clients that it has detected
that the trail transporting the client signal is has a defect.

Cheers, Huub.

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 12:33:27 +0100

Thanks Hubb....but the key point is the 1st sentence, ie:
"This only applies if the client/server binding is fixed. "

.....and the related bits you snipped regarding the ability of the
client layer network to re-route traffic without any involvement of the
server.

I agree the nature of the actual PDH AIS signal is somewhat academic and
it is of far less importance than the other observations...indeed when
the other observations apply then we can't meaningfully send AIS to the
client anyway, and that is the key point.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: 28 April 2009 12:20
> Cc: [email-masked]
> transport path requirements)
> 
> Neil,
> 
> You wrote:
>

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 28 Apr 2009 13:46:52 +0200

Dear Nurit,

> endless discussions on this requirement?

The endless discussion is caused by the use of certain three
letter abbreviations (which I will not repeat to avoid another
round of discussions).

We agreed to write the requirements without mentioning the
solutions related to these three letter abbreviations.

Regards, Huub.

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 28 Apr 2009 08:21:08 -0400

All,

I support these proposals with a minor refinement.  I suggest that the
following wording should be included in the MPLS-TP OAM requirements
draft.

R1) A MPLS-TP server layer shall inform its clients when a defect is
detected in the MPLS-TP trail being used to support those clients.

R2) When a MPLS-TP client layer is informed of the failure of a server
layer trail it should propagate that information to the MPLS-TP trail
termination.  It may use this information to suppress alarms.

As we develop the OAM Implementation draft we need to determine if and
how this requirement can be met reliably.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Huub van Helvoort
Sent: Tuesday, April 28, 2009 7:31 AM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
path requirements)

Hi Adrian,

;-)

>> How about:
>> the requirement is that a server layer shall inform its clients that 
>> it has detected a service interuption, this to ensure that the 
>> clients can inhibit (unnecessary) alarms.
> 
>> the requirement is that a server layer shall inform its clients that 
>> it has detected a service interruption.

The second part could be a separate requirement because MPLS-TP is also
a client layer:

If a client layer is informed by its server layer that a defect in the
server layer trail has been detected the client layer shall not raise an
alarm related to that defect.

> We might note that "service" is possibly ambiguous. Some people regard

> a "service" as being what exists in the client layer. Some people see 
> it as what the server layer delivers to the client layer. Could we 
> restate this in terms of server layer trails?

The server layer shall inform its clients that it has detected that the
trail transporting the client signal is has a defect.

Cheers, Huub.

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 28 Apr 2009 08:23:25 -0400

Neil,

I think that this important point should be captured/considered in the
context of the OAM implementation draft.  I don't think it belongs in
the OAM requirements draft.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, April 28, 2009 7:33 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
pathrequirements)

regards, Neil

> Between the TTL and the line there is analog circuitry that can detect

> this "stuck at" and replace consequently the
> HDB3 output by a 1.024 Mbit/s sinusoidal signal which in binary is an 
> all ONEs signal. The "stuck at" defect is reported and the all ONEs is

> used to inhibit alarm reporting.
> At the receiver side of the line it is similar, when a line signal 
> defect (e.g. LOS, LOC, LOF) is detected consequently an all ONEs 
> signal replaces the original. When there is a line defect noise is 
> received generating an arbitrary 0/1 pattern.
> reporting. The LOS/LOC/LOF is the only alarm important for fault 
> localisation.
> 
> Regards, Huub.
> 
> --

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 14:47:34 +0200

Neil,

> However, if the client can dynamically change its routing in response
> to link failures in its topology (because some server layer network has

I believe there is a fixed client/server relationship also in this case in
the network. This relationship is broken when the connection is rerouted.
Such reroute will remove the CP/FP and as such will stop the AIS generation.

There is no difference with what we do today in SDH and OTN. A client/server
relationship is fixed until the point in time that the connection is either
teardown or rerouted. When either of the two cases occur, the AIS generation
is stopped. Until such action is performed, AIS is generated during signal
fail condition period and inserted into the connection.

In MPLS-TP we have the requirement that MPLS-TP must be able to operate
without control plane. This implies that it will operate without
restoration, and that there will not be frequent rerouteing ongoing. Result
is that client/server relationships will last until the connection is
teardown.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 28 april 2009 10:07
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Nurit,

I believe the reason we need this discussion is that there is an unstated
assumption here that the client/server relationship is fixed.
However, if the client can dynamically change its routing in response to
link failures in its topology (because some server layer network has
failed....which may or may not belong to the same operating party as the
client) then there is no fixed client/server relationship.

Refer to my post earlier today and consider what this means in the case of a
cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client
layer network.  The key point here is the *routing process* in the client is
independent of the server layer network....so there is not a fixed
client/server relationship.  Further, there is also no requirement for the
server to keep track of where its client traffic routings are at any
epoch.....indeed why should it in the general case where these are
independent layer networks?

So the only OAM requirement that is critical is that the OAM of the client
and server layer networks are independent.  It is thus not sensible to make
client layer alarm supression a 'requirement' here...in fact if this is in
the OAM requirements then it is technically wrong and should be removed IMO.

regards, Neil 
> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - 
> IL/Hod HaSharon)
> If we agree that the requirement is included, so why do we keep with 
> the endless discussions on this requirement?
> 
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; 
> Adrian Farrel
> Cc: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN 
> > - IL/Hod HaSharon)
> > client layers as a result of a failure condition in the server layer 
> > may be suppressed.

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 28 Apr 2009 06:40:30 -0700

Why do we want to stipulate what the client layer does? 

> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
> [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 9:56 PM
> I think that the requirement is to provide a mechanism to 
> suppress alarms in the networks, to ensure that alarms that 
> may be generated by client layers as a result of a failure 
> condition in the server layer may be suppressed.
> I propose to phrase the requirement appropriately and 
> conclude the discussion on this in the context of the 
> requirements (until we are getting to the solution phase). 
> [mailto:[email-masked]] On Behalf Of ext Huub van Helvoort
> the requirement is that a server layer shall inform its 
> clients that it has detected a service interuption, this to 
> ensure that the clients can inhibit (unnecessary) alarms.
> 
> Cheers, Huub.
> 
> --

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 15:09:43 +0100

Thanks Maarten...a couple of further observations in-line: 

Maarten wrote 28 April 2009 13:48
> fail condition period and inserted into the connection.

NH=> I'm pretty uneasy about these ideas.  I know this was the case in
the largely static PDH/SDH networks but I'm very uncomfortable with
carrying this idea through to packet based networks like MPLS-TP....and
in the case of a cl-ps mode packet network then I really cannot see how
anyone could seriously suggest AIS/FDI had any validity at all.
 
> without control plane.

NH=> True, but we must also design the OAM to work with a CP.  And
looking forward to the case of MPLS-TPoverMPLS-TP (which will sure as
anything be required) it will be essential IMO that we can have
independent routing/restoration processes in both the client and server
MPLS-TP networks.  And in such a case it will not be a good idea to try
force permament client/server bindings here....the client MPLS-TP layer
network will want to run its own routing/restoration processes quite
independently of the server MPLS-TP network.

Once upon a time I used to think AIS was a good idea in co mode
networks, but having been forced to really think about this over the
last few years I am now of the firm view that AIS is not a good idea at
all.  The only essential thing we need with the defect
detection/handling OAM is CV and BDI....and of course the requirement
that each layer network has its own independent OAM.

I truly believe we will be making a mistake in carrying the concept of
AIS over into MPLS-TP when have the opportunity not to make this mistake
here.

We should not do things just because they are either (i) possible and/or
(ii) it's how we did stuff historically if we can see there are
technical problems.

regards, Neil

   This implies that it will operate without
> [mailto:[email-masked]] On Behalf
> suppress 
> conclude the 
> clients that

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 16:22:16 +0200

Neil,

> if I create the topology of an IP layer network with links provided by
SDH,
> Ethernet, ATM, OTN, etc servers, and each of these server links is
provided
> by a different operator, then why should the servers need have knowledge
of
> where the IP flows have moved to in response to a server layer failure
when
> the new routes have been calculated by the IGP in the IP layer network? 

In an IP layer network there are typically a number of IP transport
entities; i.e. the INTERNET is one IP transport entity and an IP VPN is
another IP transport entity. Within this scope, I agree with you that the
servers don't need to know where the IP flows within an IP transport entity
have moved to. But the servers must know when an IP transport entity (e.g.
IP VPN) has moved. Rationale for the latter is that the label identifying
the IP VPN has to be withdrawn.

And the same applies to an Ethernet layer network. The Ethernet transport
entities are the VLANs. The servers of the Ethernet layer network don't need
to know where the MAC flows within a VLAN have moved to. But the servers
must know when an Ethernet transport entity (i.e. VLAN) has moved. Rationale
for the latter is that the VLAN ID identifying the VLAN has to be withdrawn.

Ethernet AIS is associated with the VLAN, not with the individual MAC flows
within a VLAN. In Ethernet transport networks (which use network management
for VLAN setup) there is as such a fixed client/server relationship between
a VLAN in the Ethernet layer netowrk and the servers over which this VLAN is
supported. This fixed client/server relationship enables the deployment of
Etherent AIS as an alarm suppression mechanism within VLANs.

So you have to adapt your understanding of the entity on which AIS acts in
Ethernet. AIS acts on the Ethernet transport entity (i.e. VLAN); AIS does
not act on the MAC flows that exist within the Ethernet transport entity.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 28 april 2009 8:43
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
pathrequirements)

> it has detected a service interuption, this to ensure that the clients 
> can inhibit (unnecessary) alarms.

NH=> This only applies if the client/server binding is fixed.  And of course
way back in the 70s when binary all 1s popped out of the failed TTL logic
into the PDH transport hierarchy this was true.  Also: no
labels here and no client traffic units to create.   

Where the client can dynamically be re-routed in response to a server
failure the proposed text is not valid.  It is also not necessary that the
server has to keep track of where its client traffic routings have moved to.
For example, if I create the topology of an IP layer network with links
provided by SDH, Ethernet, ATM, OTN, etc servers, and each of these server
links is provided by a different operator, then why should the servers need
have knowledge of where the IP flows have moved to in response to a server
layer failure when the new routes have been calculated by the IGP in the IP
layer network?  I can apply the same logic to an SVC-based co-ps/co-cs mode
client....indeed the co-cs mode PSTN is like this.

These observations make it quite clear to me at least that just copying the
AIS behaviour of the old transport hierarchies that had fixed client/server
relationships is not a sensible thing to do.

IMO the only essential DP OAM requirement is that each layer network should
be self-sufficient wrt OAM and not rely on any server layer primitives being
passed upwards.

Moreover, it should also be noted that (i) the defects that can occur in
each of the 3 network modes are not the same and (ii) their OAM requirements
are not identically the same. So the OAM that applies to the cl-ps mode (eg
IP) is not the same as the OAM that applies to the co-ps mode (eg MPLS-TP)
and neither of these is identically the same as the OAM that applies to the
co-cs mode (eg SDH).

Note - The only point being considered here is the real client and server
traffic relationship.  The creation of a hierarchy of TCM sublayers is a
separate topic.  Further, it is quite clear from a simple technical analysis
that any non top-of-stack network has no need for E-NNI peer-partition
working between different operating parties.  So this is also a separate
issue.  However, I propose that this latter point be captured in the MPLS-TP
requirements draft due to its stand-alone and generic importance, ie this
applies to more than just DP OAM.  Ben can you please consider this point
as/when the MPLS-TP requirements draft is updated.

regards, Neil

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Apr 2009 11:04:34 -0400

Neil.

I actually agree with Maarten on this. I don't quite understand why do you keep talking about fixed client-server relationship. It is fixed as long as the client layer connection configured this way (statically or dynamically). As soon as the connection is re-routed, this relationship is broken (because this is a part of the re-routing process) and hence the server trail termination points will know that the server trail now serves one connection less, whereas some other server trail(s) will learn that they serve from now on one connection more. These new client-server relationships are fixed until the next re-routing.

Cheers,
Igor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, April 28, 2009 8:48 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Apr 2009 11:27:28 -0400

Shahram,

Let's assume that connection A-B-C-D-E is dynamically provisioned by a control plane. As part of such provisioning a binding is created between this connection and network C at the two adaptation points on either side of the link provided by network C. When the connection is torn down, this binding is removed as a part of the cleanup process. The re-routing of the connection onto A-F-G-E is indistinguishable from the connection tear down as far as link C is concerned.

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Hi Igor,

How does the server know the client is rerouted? Assume the following
networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its
own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that network
C uses MPLS-TP as server layer. Network C will never know there was a
protection switching done for the client layer. 

-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: April-28-09 11:05 AM
To: Maarten Vissers; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Neil.

I actually agree with Maarten on this. I don't quite understand why do you
keep talking about fixed client-server relationship. It is fixed as long as
the client layer connection configured this way (statically or dynamically).
As soon as the connection is re-routed, this relationship is broken (because
this is a part of the re-routing process) and hence the server trail
termination points will know that the server trail now serves one connection
less, whereas some other server trail(s) will learn that they serve from now
on one connection more. These new client-server relationships are fixed
until the next re-routing.

Cheers,
Igor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: Tuesday, April 28, 2009 8:48 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 17:32:50 +0200

Thanks Neil, let me add a bit more to your observations in line... including
a proposal to change the objective of CC, which will result in the dropping
of the requirement for AIS... I hope that this could resolve this
discussion...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 28 april 2009 16:10
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

> I believe there is a fixed client/server relationship also in this 
> case in the network. This relationship is broken when the connection 
> is rerouted.
> relationship is fixed until the point in time that the connection is 
> either teardown or rerouted. When either of the two cases occur, the 
> AIS generation is stopped. Until such action is performed, AIS is 
> generated during signal fail condition period and inserted into the 
> connection.

NH=> I'm pretty uneasy about these ideas.  I know this was the case in the
largely static PDH/SDH networks but I'm very uncomfortable with carrying
this idea through to packet based networks like MPLS-TP....and in the case
of a cl-ps mode packet network then I really cannot see how anyone could
seriously suggest AIS/FDI had any validity at all.

[MV] I have replied to another email from you a couple of minutes ago. In
that reply I have tried to describe the cl-ps mode packet networks have two
entities that we need to analyse separately:
1) transport entity, which is set up under connection management control
(with or without help of a control plane) and are traffic engineered
2) flows, which exist within the transport entity but are not under control
of connection management and are not traffic engineered.

[MV] Examples of cl-ps transport entities are: IP VPN and Ethernet VLAN.
     Examples of cl-ps flows are: IP flow and MAC flow.

[MV] I fully agree with you that you do not generate AIS for each of the MAC
flows inside an Ethernet VLAN when the server of the VLAN fails. 

[MV] I do however strongly believe that a transport network must generate
AIS for the Ethernet VLAN (i.e. for the Ethernet transport entity) when the
server of the VLAN fails. Rationale is the fixed cleint/server relationship
between the VLAN and its servers, the use of CCM OAM in the VLAN and the LOC
defect that is detected also when the server fails which results in alarm
storms if not suppressed.

> 
> In MPLS-TP we have the requirement that MPLS-TP must be able to 
> operate without control plane.

NH=> True, but we must also design the OAM to work with a CP.  And looking
forward to the case of MPLS-TPoverMPLS-TP (which will sure as anything be
required) it will be essential IMO that we can have independent
routing/restoration processes in both the client and server MPLS-TP
networks.  And in such a case it will not be a good idea to try force
permament client/server bindings here....the client MPLS-TP layer network
will want to run its own routing/restoration processes quite independently
of the server MPLS-TP network.

[MV] Yes, and these independent routing/restoration processes would not be
hindered by registered client/server relationships, as those relationships
can be broken and replaced by alternative relationships. And alarm
suppression by means of AIS/FDI will not be impacted by such independence,
nor will it impact such independence. AIS is inserted into MPLS-TP
connections (that have been interrupted due to a server fault) for which
there is a client/server registration and as long as there is this
registration. That's the beauty of this mechanism and that's why it works
good in existing technologies.

Once upon a time I used to think AIS was a good idea in co mode networks,
but having been forced to really think about this over the last few years I
am now of the firm view that AIS is not a good idea at all.  The only
essential thing we need with the defect detection/handling OAM is CV and
BDI....and of course the requirement that each layer network has its own
independent OAM.

[MV] I do not understand whay caused you to change your idea? Some
pre-condition must have been changed? Can you indicate which one? E.g. is it
the believe that every connection is restored almost immediately using a
control plane? 

I truly believe we will be making a mistake in carrying the concept of AIS
over into MPLS-TP when have the opportunity not to make this mistake here.

We should not do things just because they are either (i) possible and/or
(ii) it's how we did stuff historically if we can see there are technical
problems.

[MV] Neither of those two cases is a rationale for my promotion of AIS in
MPLS-TP. The rationale for MPLS-TP AIS is proper and scalable fault
management in a transport network. CC is there to detect faults in the
connectivity of the matrices in the layer network. But most of the times
that CC is lost is due to a fault in a server layer. AIS provides the
necessary filter information to discover the matrix faults.

[MV] It would be possible to drastically change the nature and objective of
CC... i.e. it is possible to declare that 
1) there are no layer network continuity faults; i.e. any interruption
   of the connection that is not due to a server fault is intentional, 
   and as such does not need to be alarmed
2) all continuity faults are due to server layer interruptions
3) loss of continuity is not longer a primary alarm; i.e. LOC is a service
   status indication and will not cause any fault localization procedure
   to be initiated
4) loss of continuity detection will by default not be alarmed
5) loss of continuity will trigger protection switching and performance
monitoring.

[MV] In the above scenario we do not need to deploy AIS as there is nothing
to suppress (LOC is not longer alarmed as a primary fault that needs
immediate fixing).

[MV] Any misconnections are still alarmed as a primary fault (i.e. MisMerge
(MMG) alarm).

Regards,
Maarten

regards, Neil

> restoration, and that there will not be frequent rerouteing ongoing. 
> Result is that client/server relationships will last until the 
> connection is teardown.
> 
> Regards,
> Maarten
> 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> to link failures in its topology (because some server layer network 
> has failed....which may or may not belong to the same operating party 
> as the
> Refer to my post earlier today and consider what this means in the 
> case of a cl-ps IP client layer network or a some SVC-based 
> co-ps/co-cs mode client layer network.  The key point here is the 
> *routing process* in the client is independent of the server layer 
> network....so there is not a fixed client/server relationship.  
> Further, there is also no requirement for the server to keep track of 
> where its client traffic routings are at any epoch.....indeed why 
> should it in the general case where these are independent layer 
> networks?
> 
> sensible to make client layer alarm supression a 'requirement' 
> here...in fact if this is in the OAM requirements then it is 
> technically wrong and should be removed IMO.
> 
> regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 18:08:50 +0200

Shahram,

When you apply protection you will not change the binding between client and
server layers when you switch from e.g. working to protection. All
client/server bindings are still present. What you changed is the
connectivity in the connection function. You find this illustrated in e.g.
G.806.

When the working connection would fail, then AIS would be inserted e.g. at
the end of the server layer connection that carries the working connection.
AIS is inserted independent of the state of the next protection switch
selector process. If the selector is not moved to the protection connection,
then AIS inserted into the working connection is forwarded through the
protection switch selector to the far end of the protected connection. If
the selector is moved to read from the protection connection, then AIS is
still inserted intto the working connection, but the selector is not reading
from working, so AIS will drop dead at the input of the selector.

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: dinsdag 28 april 2009 17:57
To: 'Igor Bryskin'; 'Maarten Vissers'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Igor,

Your assumption is that there is a control plane that sets up the binding
between client and server layer and that such binding will be removed via
the control plane when a reroute happens. I think this assumption is not
always true. For example in a linear 1:1 or 1+1 protection, there is no
signalling to withdraw the binding at intermediate nodes. In 1:1 there is
APS, but that is end-to-end and is sent on the backup path not working path.

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Shahram,

Let's assume that connection A-B-C-D-E is dynamically provisioned by a
control plane. As part of such provisioning a binding is created between
this connection and network C at the two adaptation points on either side of
the link provided by network C. When the connection is torn down, this
binding is removed as a part of the cleanup process. The re-routing of the
connection onto A-F-G-E is indistinguishable from the connection tear down
as far as link C is concerned.

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Hi Igor,

-Shahram

-----Original Message-----

Neil.

Cheers,
Igor 

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Apr 2009 12:20:03 -0400

Shahram,

I was addressing Neil's comments about the dynamic re-routing, which is different from protection switchover onto pre-provisioned protection connection. True, in the latter case the server layer wouldn't notice that and will keep notifying the client that the trail is broken. But this does not change anything. The big 2 questions in my mind are:

a) Is the OAM of a given layer is (i) self-sufficient and (ii) scalable enough, so that operator can rely on it completely and independently from what is happening in the lower layers?

b) Is it beneficial if a server trail notifies its clients about a detected problem to suppress the OAM traffic and possibly unnecessary switchovers until the server trail corrects itself?

Cheers,
Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 11:57 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Igor,

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Hi Igor,

-Shahram

-----Original Message-----

Neil.

Cheers,
Igor 

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 21:24:52 +0200

Igor,

> b) Is it beneficial if a server trail notifies its clients about
     a detected problem to suppress the OAM traffic 

The suppression we have been talking about is alarm suppression, not OAM
traffic suppression.

Loss of CC is intended to detect an open connection fault in a matrix. 
E.g. assume a connection that starts in node A, passes through nodes B and C
and ends in node D.
Nodes A, B, C and D have a connection function in which a matrix connection
is to be set up to support this connection from A to D.

What is now possible is that the matrix connection in node B is
unintentionally removed (i.e. a continuity fault).
Node D will now detect a loss of CC. Node D does not detect any other
faults.
Node C will not detect any fault.
Node B will not detect any fault.
Node A will not detect any fault if the matrix connection in B is removed in
one direction only.

In order to detect this open matrix connection fault it is required to
report the loss of CC to the management system and to start a fault
localization procedure to locate the faulty matrix (i.e. in node B). If such
reporting is not done, then there is a hidden fault, which keeps the
connection interrupted much longer; i.e. until one or more customers start
to complain that their connections are lost. Then you hae to find in a big
network without any fault report which node has the fault.

What happens now if the fault is not an open matrix connection but a server
layer fault (e.g. a link fault between nodes A and B).
Node D will now detect a loss of CC. Node D does not detect any other
faults.
Node C will not detect any fault.
Node B will detect a loss of signal fault.
Node A will not detect any fault if the link from A to B is broken in one
direction only.

If loss of CC is unconditionally reported, then node D will report loss of
CC. Node B will report loss of signal.
- If node B and node D are managed by the same management system it is
possible to perform a fault correlation in this management system to filter
out the loss of CC from node D. What is necessary is to know that connection
A-D is supported by the link A to B. In larger multi-layer networks such
correlations become complex. If such correlations are not performed, then
the loss of CC will trigger a fault localisation action, which of course
will not find a matrix fault (i.e. waste of time).
- If node B is managed by another management system then node D, there is no
correlation possible. Node D's management system will see only the loss of
CC and will start fault localization, and will not find any fault in its
part of the network. 

Use of AIS will help in distinguishing between connection interruption due
to an open matrix connection fault and due to server fault. AIS provides the
necessary filter for loss of CC.

What happens for the case a port detects a signal fail condition is the
following; assume a 10G port that detects a signal fail condition. This
implies that all traffic is lost. Assume that there are 1000 client
connections active (e.g. with an average bandwidth of 5 Mbit/s). When AIS is
to be generated for those 1000 client conenctions the port has to generate
1000 AIS frames/packets per second. Each AIS frame/packet is 64 bytes/512
bits. Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005
Gbit/s) of traffic in a further empty 10G port. This isn't any real
complexity.

---------

The alternative is to declare that open matrix connections are never a fault
condition (i.e. are always intentional and thus known by network
management). Under such starting point it is not necessary to detect an open
matrix connection as a fault condition. Now it is not longer necessary to
distinguish between connection interruption due to open matrix and server
layer fault as the first condition isn't a fault anylonger. Under this
condition it is not useful that a server trail informs its clients about a
detected server trail problem that interrupts the client connections.

If we go for this latter approach and if in future an open matrix connection
would be a fault condition, then this is a hidden fault and you need a lot
more work to locate the fault (there are no alarms that help you).

Regards,
Maarten

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]] 
Sent: dinsdag 28 april 2009 18:20
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

I was addressing Neil's comments about the dynamic re-routing, which is
different from protection switchover onto pre-provisioned protection
connection. True, in the latter case the server layer wouldn't notice that
and will keep notifying the client that the trail is broken. But this does
not change anything. The big 2 questions in my mind are:

a) Is the OAM of a given layer is (i) self-sufficient and (ii) scalable
enough, so that operator can rely on it completely and independently from
what is happening in the lower layers?

b) Is it beneficial if a server trail notifies its clients about a detected
problem to suppress the OAM traffic and possibly unnecessary switchovers
until the server trail corrects itself?

Cheers,
Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:57 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Igor,

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Hi Igor,

-Shahram

-----Original Message-----

Neil.

Cheers,
Igor 

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Apr 2009 15:54:01 -0400

Marten thanks,

Yes, when I said OAM traffic suppression, I meant actually the alarm suppression.

Andy wrote that the AIS provides no additional information, and I disagree.
The two cases:
a) CC fails, no AIS;
b) CC fails, AIS is present

are different, and the difference IMHO is in the time to react on CC failure. In case b) I would allow more time to let the server to attempt to repair itself. In case a) I would react faster.

So I agree with you, there could be a multi-layer correlation recovery-wise.

What if you have a multi-layer network and a failure happens in the lowest layer? It seams reasonable to let the lowest layer to try to recover  before recovering clients and clients of clients.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, April 28, 2009 3:25 PM
To: Igor Bryskin
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Igor,

---------

Regards,
Maarten

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: dinsdag 28 april 2009 18:20
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Cheers,
Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:57 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Igor,

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Hi Igor,

-Shahram

-----Original Message-----

Neil.

Cheers,
Igor

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Apr 2009 17:22:08 -0400

Shahram,

OSPF will react on Hello miss or a fault indication from the server layer serving IP link. The only reason why you need the latter is that it comes earlier that the former. So, IMO you can delay the fault indication by the layer serving IP link if it receives some sort of AIS from its own server layer.

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 4:13 PM
To: Igor Bryskin; 'Maarten Vissers'
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Hi Igore,

If client layer is using a dynamic routing such as RSTP or OSPF, I don't
think AIS could slow down the convergence of RSTP or OSPF.

Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: April-28-09 3:54 PM
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Marten thanks,

Yes, when I said OAM traffic suppression, I meant actually the alarm
suppression.

are different, and the difference IMHO is in the time to react on CC
failure. In case b) I would allow more time to let the server to attempt to
repair itself. In case a) I would react faster.

What if you have a multi-layer network and a failure happens in the lowest
layer? It seams reasonable to let the lowest layer to try to recover  before
recovering clients and clients of clients.

Cheers,
Igor

-----Original Message-----

Igor,

---------

Regards,
Maarten

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: dinsdag 28 april 2009 18:20
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Cheers,
Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:57 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Igor,

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Hi Igor,

-Shahram

-----Original Message-----

Neil.

Cheers,
Igor

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 29 Apr 2009 00:15:40 +0200

Shahram,

C will insert AIS toward E. This is correct because we wish to suppress
the reporting of the LOC alarm at E on the working transport entity.

However the LOC condition still triggers the protection switching action
so the traffic is rerouted on the protection path.

Italo

> Sent: Tuesday, April 28, 2009 5:15 PM
> To: 'Igor Bryskin'; 'Maarten Vissers'; 
> [email-masked]; [email-masked]; BUSI ITALO;

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 23:26:20 +0100

Maarten, Igor,

Before dealing with the specific scenarios, let me go through again what
I said in an earlier posting about the way alarm 'suppression' actually
works.

There are two sides to maintenance - the faulty kit guys who fix faulty
cards, mend cable breaks, etc, etc, and end service guys who deal with
customer service. 'Suppressed' alarms are only suppressed to the faulty
kit guys who fix cards, etc. The distinction between 'local' and
'remote' alarms is very important to ensure that these faulty kit guys
are directed to the place where the actual fault lies and not to places
affected by, but remote from the actual fault.

However, these 'suppressed' alarms are still forwarded to the service
maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they want
to know whether the end service is 'up' or 'down' irrespective of the
cause and irrespective of the presence of AIS. AIS most emphatically
does not suppress this alarm! These guys wants to know that the service
is 'down' before the customer is on the phone!

So to go to Maarten's first example, the faulty kit guys are not getting
any alarms telling them to fix broken kit - which is correct.

The service maintenance guys *have* got an alarm - the customer has not
got their service! They also notice that it is not fixing itself. So
they investigate, ie start localising. In practice, the first thing they
will do (and most management systems will do it automatically by some
form of correlation engine) is check for any corresponding faulty kit
alarms. In this case, they will find no faulty kit alarms and suspect a
misconfiguration, localise it, and fix it.

To go to Maarten's second example, the faulty kit guys are getting an
alarm telling them to fix the link between A and B.

The service maintenance guys have also got an alarm - again the customer
has not got their service. They also notice that it is not fixing
itself. So they investigate, ie start localising. Again, the first thing
they will do (and most management systems will do it automatically by
some form of correlation engine) is check for any corresponding faulty
kit alarms. In this case, they will find the corresponding faulty kit
alarm and can check of the repair plan and status should the customer
call and ask.

As these particular scenarios illustrate, the right alarms have been
directed to the right maintenance guys. The service guys deal with the
service configurations, the faulty kit guys deal with faulty kit.

Occasionally, there will be faulty kit which is not reporting itself
despite the best design efforts in the equipment. In this case, the
service maintenance guys are likely to have a series of alarms which can
be correlated to help localise the fault and the diagnosed fault can
then be passed to the faulty kit guys for fixing.

Another important point. There is little room here for *false*
information coming to either set of maintenance guys. When trying to
localise a fault, no additional information is better than wrong
additional information.

That is my concern with the trying to inject packet based AIS. There is
significant room for creating false information. As I've already
indicted there is AIS specific configuration to do which will be prone
to misconfiguration. We should then note that the thing that the AIS is
supposed to be identifying is the present of misconfiguration - but
achieving this requires configuration. So why should one configuration
be more reliable than the other?

But there are other scenarios. For example, consider port mapping (or in
ITU-T speak, a degenerate subnetwork) where we terminate the section
layer on one interface and blindly ship all the packets out on an other
interface in a new section. If we assume AIS is being used, a fault in
the incoming section should result in the injection of AIS. But how does
it know what label values to use? Or does it not inject AIS? In which
case we have the poor service maintenance guys actively looking for a
configuration error which does not exist. A similar scenario would exist
if we choose to use a sort of ADM where the forwarding table was made up
of exception (add/drop) label values and a default outgoing port. Again,
the same dilemma exists.

Andy

Andy Reid

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.
Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful
business purposes. Communications using this system will also be
monitored and may be recorded to secure effective operation and for
other lawful business purposes.

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 28 April 2009 20:25
> To: 'Igor Bryskin'
> Cc: [email-masked]
> The suppression we have been talking about is alarm 
> suppression, not OAM traffic suppression.
> 
> E.g. assume a connection that starts in node A, passes 
> through nodes B and C and ends in node D.
> Nodes A, B, C and D have a connection function in which a 
> matrix connection is to be set up to support this connection 
> from A to D.
> 
> What is now possible is that the matrix connection in node B 
> is unintentionally removed (i.e. a continuity fault).
> Node D will now detect a loss of CC. Node D does not detect 
> any other faults.
> Node A will not detect any fault if the matrix connection in 
> B is removed in one direction only.
> 
> In order to detect this open matrix connection fault it is 
> required to report the loss of CC to the management system 
> and to start a fault localization procedure to locate the 
> faulty matrix (i.e. in node B). If such reporting is not 
> done, then there is a hidden fault, which keeps the 
> connection interrupted much longer; i.e. until one or more 
> customers start to complain that their connections are lost. 
> Then you hae to find in a big network without any fault 
> report which node has the fault.
> 
> What happens now if the fault is not an open matrix 
> connection but a server layer fault (e.g. a link fault 
> between nodes A and B).
> Node D will now detect a loss of CC. Node D does not detect 
> any other faults.
> Node A will not detect any fault if the link from A to B is 
> broken in one direction only.
> 
> If loss of CC is unconditionally reported, then node D will 
> report loss of CC. Node B will report loss of signal.
> - If node B and node D are managed by the same management 
> system it is possible to perform a fault correlation in this 
> management system to filter out the loss of CC from node D. 
> What is necessary is to know that connection A-D is supported 
> by the link A to B. In larger multi-layer networks such 
> correlations become complex. If such correlations are not 
> performed, then the loss of CC will trigger a fault 
> localisation action, which of course will not find a matrix 
> fault (i.e. waste of time).
> - If node B is managed by another management system then node 
> D, there is no correlation possible. Node D's management 
> system will see only the loss of CC and will start fault 
> localization, and will not find any fault in its part of the network. 
> 
> Use of AIS will help in distinguishing between connection 
> interruption due to an open matrix connection fault and due 
> to server fault. AIS provides the necessary filter for loss of CC.
> 
> What happens for the case a port detects a signal fail 
> condition is the following; assume a 10G port that detects a 
> signal fail condition. This implies that all traffic is lost. 
> Assume that there are 1000 client connections active (e.g. 
> with an average bandwidth of 5 Mbit/s). When AIS is to be 
> generated for those 1000 client conenctions the port has to 
> generate 1000 AIS frames/packets per second. Each AIS 
> frame/packet is 64 bytes/512 bits. Those 1000 AIS 
> frames/packets thus generate 512 kbit/s (i.e. 0.0005
> Gbit/s) of traffic in a further empty 10G port. This isn't 
> any real complexity.
> 
> ---------
> 
> The alternative is to declare that open matrix connections 
> are never a fault condition (i.e. are always intentional and 
> thus known by network management). Under such starting point 
> it is not necessary to detect an open matrix connection as a 
> fault condition. Now it is not longer necessary to 
> distinguish between connection interruption due to open 
> matrix and server layer fault as the first condition isn't a 
> fault anylonger. Under this condition it is not useful that a 
> server trail informs its clients about a detected server 
> trail problem that interrupts the client connections.
> 
> If we go for this latter approach and if in future an open 
> matrix connection would be a fault condition, then this is a 
> hidden fault and you need a lot more work to locate the fault 
> (there are no alarms that help you).
> 
> Regards,
> Maarten
> 
> 
> To: [email-masked]; 'Maarten Vissers'; 
> [email-masked]; [email-masked]; 
> I was addressing Neil's comments about the dynamic 
> re-routing, which is different from protection switchover 
> onto pre-provisioned protection connection. True, in the 
> latter case the server layer wouldn't notice that and will 
> keep notifying the client that the trail is broken. But this 
> does not change anything. The big 2 questions in my mind are:
> 
> a) Is the OAM of a given layer is (i) self-sufficient and 
> (ii) scalable enough, so that operator can rely on it 
> completely and independently from what is happening in the 
> lower layers?
> 
> b) Is it beneficial if a server trail notifies its clients 
> about a detected problem to suppress the OAM traffic and 
> possibly unnecessary switchovers until the server trail 
> corrects itself?
> 
> Cheers,
> Igor
> 
> 
> 
> [email-masked]; [email-masked]; 
> Your assumption is that there is a control plane that sets up 
> the binding between client and server layer and that such 
> binding will be removed via the control plane when a reroute 
> happens. I think this assumption is not always true. For 
> example in a linear 1:1 or 1+1 protection, there is no 
> signalling to withdraw the binding at intermediate nodes. In 
> 1:1 there is APS, but that is end-to-end and is sent on the 
> backup path not working path.
> 
> -Shahram
> 
>  
> 
> To: [email-masked]; 'Maarten Vissers'; 
> [email-masked]; [email-masked]; 
> Let's assume that connection A-B-C-D-E is dynamically 
> provisioned by a control plane. As part of such provisioning 
> a binding is created between this connection and network C at 
> the two adaptation points on either side of the link provided 
> by network C. When the connection is torn down, this binding 
> is removed as a part of the cleanup process. The re-routing 
> of the connection onto A-F-G-E is indistinguishable from the 
> connection tear down as far as link C is concerned.
> 
> Igor
> 
> [email-masked]; [email-masked]; 
> networks: A-B-C-D-E (working) and A-F-G-E (protection). 
> Assume each has its own server layer such as MPLS, MPLS-TP, 
> ATM, SONET, etc. Assume that network C uses MPLS-TP as server 
> layer. Network C will never know there was a protection 
> switching done for the client layer. 
> 
> -Shahram
> 
> [mailto:[email-masked]] On Behalf Of Igor Bryskin
> To: Maarten Vissers; [email-masked]; 
> [email-masked]; [email-masked]; 
> I actually agree with Maarten on this. I don't quite 
> understand why do you keep talking about fixed client-server 
> relationship. It is fixed as long as the client layer 
> connection configured this way (statically or dynamically).
> As soon as the connection is re-routed, this relationship is 
> broken (because this is a part of the re-routing process) and 
> hence the server trail termination points will know that the 
> server trail now serves one connection less, whereas some 
> other server trail(s) will learn that they serve from now on 
> one connection more. These new client-server relationships 
> are fixed until the next re-routing.
> 
> Cheers,
> Igor 
> 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> I believe there is a fixed client/server relationship also in 
> this case in the network. This relationship is broken when 
> the connection is rerouted.
> There is no difference with what we do today in SDH and OTN. 
> A client/server relationship is fixed until the point in time 
> that the connection is either teardown or rerouted. When 
> either of the two cases occur, the AIS generation is stopped. 
> Until such action is performed, AIS is generated during 
> signal fail condition period and inserted into the connection.
> 
> In MPLS-TP we have the requirement that MPLS-TP must be able 
> to operate without control plane. This implies that it will 
> operate without restoration, and that there will not be 
> frequent rerouteing ongoing. Result is that client/server 
> relationships will last until the connection is teardown.
> 
> Regards,
> Maarten
> 
> I believe the reason we need this discussion is that there is 
> an unstated assumption here that the client/server 
> relationship is fixed.
> However, if the client can dynamically change its routing in 
> response to link failures in its topology (because some 
> server layer network has failed....which may or may not 
> belong to the same operating party as the
> Refer to my post earlier today and consider what this means 
> in the case of a cl-ps IP client layer network or a some 
> SVC-based co-ps/co-cs mode client layer network.  The key 
> point here is the *routing process* in the client is 
> independent of the server layer network....so there is not a 
> fixed client/server relationship.  Further, there is also no 
> requirement for the server to keep track of where its client 
> traffic routings are at any epoch.....indeed why should it in 
> the general case where these are independent layer networks?
> 
> So the only OAM requirement that is critical is that the OAM 
> of the client and server layer networks are independent.  It 
> is thus not sensible to make client layer alarm supression a 
> 'requirement' here...in fact if this is in the OAM 
> requirements then it is technically wrong and should be removed IMO.
> 
> regards, Neil

---

From: [email-masked]
Date: Wed, 29 Apr 2009 09:36:48 +0800

Hi Neil,

I think client/server relationship is fixed in co-cs/co-ps. once a 
connection is established, the client/server relationship will not change 
until the connection is teardown. server can get the server/client 
relationship information when connection is established/teardown, there is 
no need of more configuration. 

Regards,
Suhui

<[email-masked]> 
2009-04-28 16:07

收件人
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
transportpathrequirements)

Nurit,

regards, Neil

---

From: [email-masked]
Date: Wed, 29 Apr 2009 10:22:13 +0800

Hi Neil,

‘it is quite clear from a simple technical analysis that any non 
top-of-stack network has no need for E-NNI peer-partition working between 
different operating parties.’

I cannot agree this statement. 
For example, there are two IP networks belonging to two operators, a E1 is 
transported from A network to B network (e.g. E1overPWoverIP ), IP 
packet(not E1) pass across form A to B at border node, so there is a E-NNI 
between these  two IP network. In this case, is IP a top-of-stack network?
Now let us replace IP networks by MPLS-TP networks (e.g. 
E1overPWoverMPL-TP), MPLS-TP network is at same position in the stack as 
IP network is, why can IP network have E-NNI but MPLS-TP cannot?

Regard,
Suhui

<[email-masked]> 
2009-04-28 14:43

收件人
<[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 29 Apr 2009 08:10:15 +0200

Andy,

> significant room for creating false information. As I've already indicted
> there is AIS specific configuration to do which will be prone to
> misconfiguration. 

Can you list what the "AIS specific configuration" is that we have to do?
I don't know of any such "AIS specific configuration".

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

> For example, consider port mapping (or in ITU-T speak, a degenerate
> subnetwork) where we terminate the section layer on one interface
> and blindly ship all the packets out on an other interface in a
> new section.

I am interested to learn in which types of equipment this occurs,
or at which location in a network this occurs. I have not come
across this so far in transport network equipment designs. I.e. 
this seems to be a non-existing case in transport networks.

I have come across a port-based service. In this port-based service 
you terminate the Physical Media layer and forward the Section_CI.  
There is now a single Characteristic Information stream and AIS 
insertion is done in this single connection. 
An example are the port-based Ethernet services; the Section VLAN 
(EVS_CI) is the service and this service is forwarded through the 
network as an EVC.
An example is also the port-based SDH and 802.3 services provided 
by the OTN. In those cases the STM-N bit streams and 802.3 bit or 
codeword streams are forwarded.

> A similar scenario would exist if we choose to use a sort of 
> ADM where the forwarding table was made up of exception (add/drop)
> label values and a default outgoing port.

Again, I don't know of any such design in transport equipment. 
It is kind of useless to make this type of equipment in my understanding.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 29 april 2009 0:26
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated

Maarten, Igor,

Before dealing with the specific scenarios, let me go through again what I
said in an earlier posting about the way alarm 'suppression' actually works.

There are two sides to maintenance - the faulty kit guys who fix faulty
cards, mend cable breaks, etc, etc, and end service guys who deal with
customer service. 'Suppressed' alarms are only suppressed to the faulty kit
guys who fix cards, etc. The distinction between 'local' and 'remote' alarms
is very important to ensure that these faulty kit guys are directed to the
place where the actual fault lies and not to places affected by, but remote
from the actual fault.

However, these 'suppressed' alarms are still forwarded to the service
maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they want to
know whether the end service is 'up' or 'down' irrespective of the cause and
irrespective of the presence of AIS. AIS most emphatically does not suppress
this alarm! These guys wants to know that the service is 'down' before the
customer is on the phone!

So to go to Maarten's first example, the faulty kit guys are not getting any
alarms telling them to fix broken kit - which is correct.

The service maintenance guys *have* got an alarm - the customer has not got
their service! They also notice that it is not fixing itself. So they
investigate, ie start localising. In practice, the first thing they will do
(and most management systems will do it automatically by some form of
correlation engine) is check for any corresponding faulty kit alarms. In
this case, they will find no faulty kit alarms and suspect a
misconfiguration, localise it, and fix it.

To go to Maarten's second example, the faulty kit guys are getting an alarm
telling them to fix the link between A and B.

The service maintenance guys have also got an alarm - again the customer has
not got their service. They also notice that it is not fixing itself. So
they investigate, ie start localising. Again, the first thing they will do
(and most management systems will do it automatically by some form of
correlation engine) is check for any corresponding faulty kit alarms. In
this case, they will find the corresponding faulty kit alarm and can check
of the repair plan and status should the customer call and ask.

Occasionally, there will be faulty kit which is not reporting itself despite
the best design efforts in the equipment. In this case, the service
maintenance guys are likely to have a series of alarms which can be
correlated to help localise the fault and the diagnosed fault can then be
passed to the faulty kit guys for fixing.

Another important point. There is little room here for *false* information
coming to either set of maintenance guys. When trying to localise a fault,
no additional information is better than wrong additional information.

That is my concern with the trying to inject packet based AIS. There is
significant room for creating false information. As I've already indicted
there is AIS specific configuration to do which will be prone to
misconfiguration. We should then note that the thing that the AIS is
supposed to be identifying is the present of misconfiguration - but
achieving this requires configuration. So why should one configuration be
more reliable than the other?

But there are other scenarios. For example, consider port mapping (or in
ITU-T speak, a degenerate subnetwork) where we terminate the section layer
on one interface and blindly ship all the packets out on an other interface
in a new section. If we assume AIS is being used, a fault in the incoming
section should result in the injection of AIS. But how does it know what
label values to use? Or does it not inject AIS? In which case we have the
poor service maintenance guys actively looking for a configuration error
which does not exist. A similar scenario would exist if we choose to use a
sort of ADM where the forwarding table was made up of exception (add/drop)
label values and a default outgoing port. Again, the same dilemma exists.

Andy

Andy Reid

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ Registered in England
no. 1800000 This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately.
Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

> The suppression we have been talking about is alarm suppression, not 
> OAM traffic suppression.
> 
> E.g. assume a connection that starts in node A, passes through nodes B 
> and C and ends in node D.
> Nodes A, B, C and D have a connection function in which a matrix 
> connection is to be set up to support this connection from A to D.
> 
> Node A will not detect any fault if the matrix connection in B is 
> removed in one direction only.
> 
> localization procedure to locate the faulty matrix (i.e. in node B). 
> If such reporting is not done, then there is a hidden fault, which 
> keeps the connection interrupted much longer; i.e. until one or more 
> Then you hae to find in a big network without any fault report which 
> node has the fault.
> 
> What happens now if the fault is not an open matrix connection but a 
> server layer fault (e.g. a link fault between nodes A and B).
> Node A will not detect any fault if the link from A to B is broken in 
> one direction only.
> 
> If loss of CC is unconditionally reported, then node D will report 
> loss of CC. Node B will report loss of signal.
> possible to perform a fault correlation in this management system to 
> filter out the loss of CC from node D.
> What is necessary is to know that connection A-D is supported by the 
> link A to B. In larger multi-layer networks such correlations become 
> complex. If such correlations are not performed, then the loss of CC 
> will trigger a fault localisation action, which of course will not 
> find a matrix fault (i.e. waste of time).
> - If node B is managed by another management system then node D, there 
> is no correlation possible. Node D's management system will see only 
> the loss of CC and will start fault localization, and will not find 
> any fault in its part of the network.
> 
> Use of AIS will help in distinguishing between connection interruption 
> due to an open matrix connection fault and due to server fault. AIS 
> provides the necessary filter for loss of CC.
> 
> What happens for the case a port detects a signal fail condition is 
> the following; assume a 10G port that detects a signal fail condition. 
> This implies that all traffic is lost.
> with an average bandwidth of 5 Mbit/s). When AIS is to be generated 
> for those 1000 client conenctions the port has to generate 1000 AIS 
> frames/packets per second. Each AIS frame/packet is 64 bytes/512 bits. 
> Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005
> The alternative is to declare that open matrix connections are never a 
> fault condition (i.e. are always intentional and thus known by network 
> management). Under such starting point it is not necessary to detect 
> an open matrix connection as a fault condition. Now it is not longer 
> necessary to distinguish between connection interruption due to open 
> matrix and server layer fault as the first condition isn't a fault 
> anylonger. Under this condition it is not useful that a server trail 
> informs its clients about a detected server trail problem that 
> interrupts the client connections.
> 
> If we go for this latter approach and if in future an open matrix 
> connection would be a fault condition, then this is a hidden fault and 
> you need a lot more work to locate the fault (there are no alarms that 
> help you).
> 
> Regards,
> Maarten
> 
> 
> I was addressing Neil's comments about the dynamic re-routing, which 
> is different from protection switchover onto pre-provisioned 
> protection connection. True, in the latter case the server layer 
> wouldn't notice that and will keep notifying the client that the trail 
> is broken. But this does not change anything. The big 2 questions in 
> my mind are:
> 
> (ii) scalable enough, so that operator can rely on it completely and 
> independently from what is happening in the lower layers?
> 
> b) Is it beneficial if a server trail notifies its clients about a 
> detected problem to suppress the OAM traffic and possibly unnecessary 
> switchovers until the server trail corrects itself?
> 
> Cheers,
> Igor
> 
> 
> 
> Your assumption is that there is a control plane that sets up the 
> binding between client and server layer and that such binding will be 
> removed via the control plane when a reroute happens. I think this 
> assumption is not always true. For example in a linear 1:1 or 1+1 
> protection, there is no signalling to withdraw the binding at 
> intermediate nodes. In
> 1:1 there is APS, but that is end-to-end and is sent on the backup 
> path not working path.
> 
> -Shahram
> 
>  
> 
> control plane. As part of such provisioning a binding is created 
> between this connection and network C at the two adaptation points on 
> either side of the link provided by network C. When the connection is 
> torn down, this binding is removed as a part of the cleanup process. 
> The re-routing of the connection onto A-F-G-E is indistinguishable 
> from the connection tear down as far as link C is concerned.
> 
> Igor
> 
> Assume each has its own server layer such as MPLS, MPLS-TP, ATM, 
> SONET, etc. Assume that network C uses MPLS-TP as server layer. 
> Network C will never know there was a protection switching done for 
> the client layer.
> 
> -Shahram
> 
> I actually agree with Maarten on this. I don't quite understand why do 
> you keep talking about fixed client-server relationship. It is fixed 
> as long as the client layer connection configured this way (statically 
> or dynamically).
> As soon as the connection is re-routed, this relationship is broken 
> (because this is a part of the re-routing process) and hence the 
> server trail termination points will know that the server trail now 
> serves one connection less, whereas some other server trail(s) will 
> learn that they serve from now on one connection more. These new 
> client-server relationships are fixed until the next re-routing.
> 
> Cheers,
> Igor
> 
> A client/server relationship is fixed until the point in time that the 
> connection is either teardown or rerouted. When either of the two 
> cases occur, the AIS generation is stopped.
> Until such action is performed, AIS is generated during signal fail 
> condition period and inserted into the connection.
> 
> operate without control plane. This implies that it will operate 
> without restoration, and that there will not be frequent rerouteing 
> ongoing. Result is that client/server relationships will last until 
> the connection is teardown.
> 
> Regards,
> Maarten
>

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 07:40:37 +0100

Thanks Shuhui,
 
Do not confuse physical interconnect with E-NNI.....I'll come back on this shortly when discussing the bottom-of-stack section layer.
 
The first thing to understand is that *all* networks are there to ultimately support one purpose.....and that is to allow communications between parties that are *external* to the networks.  So everything we do in networking is there to ultimately support this objective.  What this means is that the DP of some network (what I call the top-of-stack network) MUST be providing adaptation functions for these external applications.......and these can generically be classified as messages, files and streams. 
 
We can see that IP is a top-of-stack network as it has UDP/TCP/RTP (for example) adaptations.  ATM was also once (~90s) intended to be a top-of-stack network and it had its own application adaptations in the form of AALs.  At one stage there were 5 of these, but in practice only a couple were really successful because of the generic nature of message/file/stream classification.  The PSTN is also top-of-stack, and its application adaptation was mainly for voice (stream) support.
 
Most other networks do not have these application adaptation functions....so they do not directly support applications.  What this means in practice is that these networks (a list which includes PDH, SDH, OTN, Ethernet, MPLS) MUST carry a further layer network above them that is top-of-stack....like IP.  There is no choice in the matter here.  So whilst we might say that an MPLS network is carrying an E1 PW the E1 entity must in turn be carrying some other top-of-stack network (like IP or PSTN), else it is serving no ultimate purpose.
 
Now in order to transmit information over geographic distance we must modulate an EM wave on some metallic/optical/radio media....this is the bottom-of-stack section layer.  These are high bit rate transport pipes whose function is to provide transparent (which I have defined previously) transport to whatever client layers networks sit above them....and where, as I noted above, there MUST be a top-of-stack network present as the ultimate layer network client else there is not external party communication possible.
 
So when we connect together 2 top-of-stack networks we do so at a section layer which is invariably carrying a very large aggregate of applications.....and of course these applications can be a time varying mix of message/file/stream cases with a set of unknown (to the section layer) importance's (ergo why transparency is an essential requirement in transport networks).
 
The real E-NNIs (which considers both DP and CP components....we never usually peer the MP, and we restrict the scope of the CP) exist in the top-of-stack layer network.  The section layer interconnect is a dumb DP pipe...it just shifts bits transparently and maintains their ordering.  There is no concept of CP (or MP) peering on these bottom-of-stack section layer interconnects.
Aside=> In some countries these interconnects have to be carefully specified in order to distinguish regulated and unregulated services.....so there are important legal/commercial considerations here, it is not simply a technical issue.
 
We can of course create E-NNIs in non top-of-stack layer networks (we can do many things that are not useful).  So lets assume we do this.....and lets assume we choose MPLS since you mention this in the mail below. 
 
Now how do external parties who wish to communicate interface with this MPLS network?  Can you support all types of message/file/stream applications *directly* into MPLS?  In principle you could if you allowed MPLS to have end system application adaptations such as UDP/TCP/RTP or the like.  But these don't exist today, and in the most usual case the MPLS network will carry an IP layer network because this can support the message/file/stream applications.
 
We can go through exactly the same analysis with any network that is not top-of-stack, eg Ethernet.  And when you do this what you realise is that although we can create peer interworking of MPLS (or whatever) this has not really helped since we might as well have just terminated the MPLS network and passed the IP layer across.
 
Now the above becomes even more striking in its importance if you consider peer interworking of 2 different non top-of-stack networks....lets pick MPLS and Ethernet because that is what is often mentioned.  
 
What we have to do now at the E-NNIs between Ethernet and MPLS is go through each DP and CP component and do a 'protocol conversion' exercise where required......and the first problem you will encounter is that there will be lots of functional mismatch.  Moreover if one or both of the networks can support multiple CP types like MPLS can, eg RSVP-TE signalling, LDP signalling, BGP4 'signalling', OSPF routing, IS-IS routing.....and I could list similar for Ethernet.....you are going to have to consider each pairing case in turn.  A lot of work.
 
And when you have done all this you ask the question 'what is it that carries the real external message/file/stream applications in the DP here?'.......and now you find no native support for these in MPLS or Ethernet, but what we do find is that both of them are carrying IP because this does support the external applications.  Now at this point we have discovered what is the common thing between MPLS and Ethernet....it is the top-of-stack IP layer network.  And so we ultimately realise we could have save ourselves a load of unnecessary work by simply terminating the MPLS and Ethernet layer network at the interworking point and just passed the IP layer network across.
 
Sorry I've had to go through all this yet again (esp for all the folks that have already understood the point) but I do hope its clear now and we can put this issue to bed.
 
regards, Neil 

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 29 April 2009 03:22
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil, 
	
	‘it is quite clear from a simple technical analysis that any non top-of-stack network has no need for E-NNI peer-partition working between different operating parties.’ 
	
	I cannot agree this statement. 
	For example, there are two IP networks belonging to two operators, a E1 is transported from A network to B network (e.g. E1overPWoverIP ), IP packet(not E1) pass across form A to B at border node, so there is a E-NNI between these  two IP network. In this case, is IP a top-of-stack network? 
	Now let us replace IP networks by MPLS-TP networks (e.g. E1overPWoverMPL-TP), MPLS-TP network is at same position in the stack as IP network is, why can IP network have E-NNI but MPLS-TP cannot? 
	
	Regard, 
	Suhui 

<[email-masked]> 

2009-04-28 14:43 

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]> 
抄送
[email-masked] 
主题
Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	

	

	regards, Neil

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 29 Apr 2009 09:03:59 +0200

I agree
 
Italo

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Wednesday, April 29, 2009 3:37 AM
	To: [email-masked]
	Cc: [email-masked]; BUSI ITALO; [email-masked]
	Subject: [mpls-tp] 答复: Re: AIS/FDI (was Associated bidirectional transportpathrequirements)

	Hi Neil, 
	
	I think client/server relationship is fixed in co-cs/co-ps. once a connection is established, the client/server relationship will not change until the connection is teardown. server can get the server/client relationship information when connection is established/teardown, there is no need of more configuration. 
	
	Regards, 
	Suhui 

<[email-masked]> 

2009-04-28 16:07 

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
抄送
[email-masked] 
主题
Re: [mpls-tp] AIS/FDI (was Associated bidirectional        transportpathrequirements)

	Nurit,

	
	
	regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 29 Apr 2009 09:18:24 +0200

Andy,

You speak about "local" and "remote" alarms. I had to read the rest of the
sentence three times before I understood that you meant "primary" and
"secondary/consequential" alarms. 
A primary alarm is an alarm that reports a fault cause that needs fixing,
whereas a secondary/consequential alarm is a report from a client that it's
connection is interrupted due to a server fault.
Do I understand your use of "local" and "remote" correct?

I agree with you that the main task of fault management is to know if there
is a fault that they can repair, what the fault is, where the location of
this fault is and then who to send to repair the fault.

I agree with you that service management needs to know about the status of
the service when the customer calls. I do not agree with you that in general
"these guys wants to know that the service is 'down' **before** the customer
is on the phone!".

I have very explicit information of a few operators that a large number of
service contracts will not be as you describe. Values given to me are 90% of
service contracts (representing 70% of service connections) are without
pro-active monitoring. In those contracts the repair time starts after the
report of the customer and verification by the operator. What is important
in those cases is that the service manager can simply retrieve status
information when the customer is on the phone.

The other 10% of service contracts (representing 30% of service connections)
are with pro-active monitoring. In those contracts the repair time starts
after the defect is detected. I assume that "these guys wants to know that
the service is 'down' **before** the customer is on the phone!" is
applicable for a subset of those service connections. For the other subset I
have understood that it is sufficient when the status/performance
information of the service connection can be retrieved instantaneously when
the customer is on the phone. Is this also the case in BT?

Besides the service connections, we have tunnel/path connections, section
connections and physical media connections. Those connections have no direct
"service" associated with it; i.e. those connections are part of the
network's infrastructure. There is as such no "service manager" interested
in the status of those infrastructure connections. The only people
interested in alarms from those infrastructure connections are the fault
management people. Do I understand this correct?

> they investigate, ie start localising.

I do not understand why a service maintenance guy will have to do the fault
localization... I have always been told that fault management is responsible
for locating a fault. If the fault is an open matrix connection (which
either interrupts a tunnel/path connection or a service/channel connection),
then the fault management people responsible for the layer network will be
triggered by the loss of CC alarm and start the localization procedure.

When a network deploys AIS, it is possible to trigger this open matrix fault
localization procedure without any complex network correlation procedure.
Seems to be advantages...

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 29 april 2009 0:26
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated

Maarten, Igor,

Andy

Andy Reid

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 29 Apr 2009 09:58:27 +0200

Neil,
Thanks for the very good explanation. It really helps me to understand
better the context of the long discussion. 
Personally I got many feedbacks from Tier-1 SPs that they would like to
have the capability to suppress alarms in a packet transport
environment. Their requirement was that if a server layer (e.g. MPLS-TP
link) fails, there is a way to notify the client layer (e.g. LSPs) in
order to be able to suppress alarms at the client layer that may result
from the fault at the server layer (e.g. MPLS-TP link). 
Isn't it a logical and reasonable requirement in a transport profile?
Also I saw general requirements for inter-layer fault correlation. So
can I understand from your mail that you are not happy from such a
requirement as well?
Best regards,
Nurit

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 11:07 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon);
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional
transportpathrequirements)

Nurit,

regards, Neil

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 10:31:17 +0100

Thanks Nurit.  Did you see Andy Reid's post dated  Tue 28/04/2009 23:26.
I believe Andy is addressing your questions here.  Andy is out right now
but will be responding to any further questions on the explantion he
gave later today (I see Maarten has already posted some further
questions to Andy).

regards, Neil

> Sent: 29 April 2009 08:58
> response to
> in the case
> > [email-masked]; Adrian
> > Farrel
> > Cc: [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 29 Apr 2009 12:36:58 +0300

Igor, Maarten, Neil and all,

I may be completely wrong,  but why should the server (MPLS-TP transport path) be aware of any specific clients that use it, be it a the path termination point or in the intermediate node?

To the best of my understanding,

 1.  MPLS (not TP) data plane architecture does not require this:
    *   As long as the server LSP is not terminated, LSR does not looks only on the top label
    *   Once the server LSP is terminated (which, IMO, is equivalent to the top label being popped), switching is done on the next label without "keeping in mind" the popped label
 2.  The MPLS-TP requirements draft does not contain an appropriate requirement of such awareness. On the contrary, Requirement 25A seems to make such awareness undesirable.
 3.  In SONET/SDH the server is not aware of any specific clients: if a server failure is detected, its consequent action spreads "all ones" over all potential clients. But this is somewhat difficult to imitate in packet networks
 4.  In ATM, the server (VPC) termination point is, indeed, fully aware of all its clients (VPC). But this awareness is dictated by the ATM data plane where VPI is link-local and VCI is link-  and VPI-local.

In other words, IMHO and FWIW, server awareness of its clients (or lack thereof) is dictated by the data plane specifics. As long as we state that MPLS-TP data plane is the same as that of MPLS, such awareness does not exist in MPLS-TP. And I do not think that it is correct to derive data plane requirements from OAM concepts.

Did I miss something important here?

Regards, and thanks in advance,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Igor Bryskin [[email-masked]]
Sent: Tuesday, April 28, 2009 6:04 PM
To: Maarten Vissers; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Neil.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, April 28, 2009 8:48 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: [email-masked]
Date: Wed, 29 Apr 2009 17:30:48 +0800

Hi Neil，

Thanks for your rapid reply.
I am confused by your comments, are you suggesting 
EverythingoverIPoverMPLS-TP? AFAIK, MPLS-TP can carry many kinds of 
clients, not just IP.In my example, E1overPWoverMPLS-TP, there is no IP 
layer at all.
And you don’t answer my question: IP is a top-of-stack network in the 
case of E1overPWoverIP, why doesn't MPLS-TP be a top-of-stack network in 
the case of E1overPWoverMPLS-TP? They are at the same position in the 
stack, and I think E1 is ‘real external stream applications’

Regards,
Suhui.

<[email-masked]> 
2009-04-29 14:40

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
主题
RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

Thanks Shuhui,
 
Do not confuse physical interconnect with E-NNI.....I'll come back on this 
shortly when discussing the bottom-of-stack section layer.
 
The first thing to understand is that *all* networks are there to 
ultimately support one purpose.....and that is to allow communications 
between parties that are *external* to the networks.  So everything we do 
in networking is there to ultimately support this objective.  What this 
means is that the DP of some network (what I call the top-of-stack 
network) MUST be providing adaptation functions for these external 
applications.......and these can generically be classified as messages, 
files and streams. 
 
We can see that IP is a top-of-stack network as it has UDP/TCP/RTP (for 
example) adaptations.  ATM was also once (~90s) intended to be a 
top-of-stack network and it had its own application adaptations in the 
form of AALs.  At one stage there were 5 of these, but in practice only a 
couple were really successful because of the generic nature of 
message/file/stream classification.  The PSTN is also top-of-stack, and 
its application adaptation was mainly for voice (stream) support.
 
Most other networks do not have these application adaptation 
functions....so they do not directly support applications.  What this 
means in practice is that these networks (a list which includes PDH, SDH, 
OTN, Ethernet, MPLS) MUST carry a further layer network above them that is 
top-of-stack....like IP.  There is no choice in the matter here.  So 
whilst we might say that an MPLS network is carrying an E1 PW the E1 
entity must in turn be carrying some other top-of-stack network (like IP 
or PSTN), else it is serving no ultimate purpose.
 
Now in order to transmit information over geographic distance we must 
modulate an EM wave on some metallic/optical/radio media....this is the 
bottom-of-stack section layer.  These are high bit rate transport pipes 
whose function is to provide transparent (which I have defined previously) 
transport to whatever client layers networks sit above them....and where, 
as I noted above, there MUST be a top-of-stack network present as the 
ultimate layer network client else there is not external party 
communication possible.
 
So when we connect together 2 top-of-stack networks we do so at a section 
layer which is invariably carrying a very large aggregate of 
applications.....and of course these applications can be a time varying 
mix of message/file/stream cases with a set of unknown (to the section 
layer) importance's (ergo why transparency is an essential requirement in 
transport networks).
 
The real E-NNIs (which considers both DP and CP components....we never 
usually peer the MP, and we restrict the scope of the CP) exist in the 
top-of-stack layer network.  The section layer interconnect is a dumb DP 
pipe...it just shifts bits transparently and maintains their ordering. 
There is no concept of CP (or MP) peering on these bottom-of-stack section 
layer interconnects.
Aside=> In some countries these interconnects have to be carefully 
specified in order to distinguish regulated and unregulated 
services.....so there are important legal/commercial considerations here, 
it is not simply a technical issue.
 
We can of course create E-NNIs in non top-of-stack layer networks (we can 
do many things that are not useful).  So lets assume we do this.....and 
lets assume we choose MPLS since you mention this in the mail below. 
 
Now how do external parties who wish to communicate interface with this 
MPLS network?  Can you support all types of message/file/stream 
applications *directly* into MPLS?  In principle you could if you allowed 
MPLS to have end system application adaptations such as UDP/TCP/RTP or the 
like.  But these don't exist today, and in the most usual case the MPLS 
network will carry an IP layer network because this can support the 
message/file/stream applications.
 
We can go through exactly the same analysis with any network that is not 
top-of-stack, eg Ethernet.  And when you do this what you realise is that 
although we can create peer interworking of MPLS (or whatever) this has 
not really helped since we might as well have just terminated the MPLS 
network and passed the IP layer across.
 
Now the above becomes even more striking in its importance if you consider 
peer interworking of 2 different non top-of-stack networks....lets pick 
MPLS and Ethernet because that is what is often mentioned. 
 
What we have to do now at the E-NNIs between Ethernet and MPLS is go 
through each DP and CP component and do a 'protocol conversion' exercise 
where required......and the first problem you will encounter is that there 
will be lots of functional mismatch.  Moreover if one or both of the 
networks can support multiple CP types like MPLS can, eg RSVP-TE 
signalling, LDP signalling, BGP4 'signalling', OSPF routing, IS-IS 
routing.....and I could list similar for Ethernet.....you are going to 
have to consider each pairing case in turn.  A lot of work.
 
And when you have done all this you ask the question 'what is it that 
carries the real external message/file/stream applications in the DP 
here?'.......and now you find no native support for these in MPLS or 
Ethernet, but what we do find is that both of them are carrying IP because 
this does support the external applications.  Now at this point we have 
discovered what is the common thing between MPLS and Ethernet....it is the 
top-of-stack IP layer network.  And so we ultimately realise we could have 
save ourselves a load of unnecessary work by simply terminating the MPLS 
and Ethernet layer network at the interworking point and just passed the 
IP layer network across.
 
Sorry I've had to go through all this yet again (esp for all the folks 
that have already understood the point) but I do hope its clear now and we 
can put this issue to bed.
 
regards, Neil 

From: [email-masked] [mailto:[email-masked]] 
Sent: 29 April 2009 03:22
To: Harrison,N,Neil,CXM R
Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; 
[email-masked]; [email-masked]
Subject: 答复: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
transport path requirements)

Hi Neil, 

Regard, 
Suhui 

<[email-masked]> 

收件人

regards, Neil

--------------------------------------------------------
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: Thomas Nadeau <[email-masked]>
Date: Wed, 29 Apr 2009 06:01:08 -0400

It would be best is these "Tier-1 SPs" would comment directly on the  
list or contribute to the requirements draft.

	--Tom

On Apr 29, 2009, at 3:58 AM, Sprecher, Nurit (NSN - IL/Hod HaSharon)  
wrote:

> case
> here...in

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 11:21:52 +0100

Thanks Suhui......sorry I missed your specific question....have a look in-line and see if this helps.

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 29 April 2009 10:31
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil， 
	
	Thanks for your rapid reply. 
	I am confused by your comments, are you suggesting EverythingoverIPoverMPLS-TP? AFAIK, MPLS-TP can carry many kinds of clients, not just IP.In my example, E1overPWoverMPLS-TP, there is no IP layer at all.  
	  
	NH=> Fully understand.  I was giving IP as an *example* of a technology that can support real external applications because it has message/file/stream application adaptation functions in the form of UDP/TCP/RTP.   In the case of E1 that you note (as E1overPWoverMPLS-TP) you have to ask yourself what specific *external* applications does the E1 support here?.....always remembering that *any* networking technology MUST ultimately support some form of *externally sourced* information source else it is not serving any purpose.  So just supporting E1 on its own does not provide this....for example ask yourself how voice or any type of message/file data gets carried by the E1.
	 
	And you don’t answer my question: IP is a top-of-stack network in the case of E1overPWoverIP, why doesn't MPLS-TP be a top-of-stack network in the case of E1overPWoverMPLS-TP? They are at the same position in the stack, and I think E1 is ‘real external stream applications’ 
	 
	NH=> The point here is that *any* network mode/technology (be it cl-ps, co-ps or co-cs) can act as the server for any other mode/technology.  However, not all technologies can support external applications.....to support these the technology must have application adaptation functions for the message/file/stream information sources that are generated in external CPE, eg phone, PC, etc.
	 
	Most technologies do not have these external application adaptation functions and so the only job they can do is create the topology of other layer networks.
	 
	So yes we can use IP (cl-ps) to carry SDH VC4 (co-cs) if we want.......probably not a good idea but it is for sure possible.  However, an SDH VC4 network cannot *directly* support either voice or data but an IP network can.....because IP has UDP/TCP/RTP applications adaptations and SDH VC4 does not have these.  Having said that, there is in principle no reason why any mode/technology (even SDH VC4) cannot support external message/file/stream applications......its just that for most technologies these have never been specified because they were only ever intended to provide a 'network builder' transport role.
	 
	Aside=> If a technology X can support message/file/stream applications directly then here we would most definitely have to consider peer-interworking technology X with both IP (Internet) and PSTN (voice case only).  In all other cases (ie where technology X is not top-of-stack, ie does not have message/file/stream application adaptation functions) there is no need for peer-interworking it with any other technology, including IP (Internet) and PSTN.

	Your final point ("I think E1 is ‘real external stream applications’" ) is not strictly correct but I can fully understand why you say this.  E1 belongs to the co-cs mode.  When you analyse this (as is done in G.800, which explains why the 3 network modes arise from information/systems theory considerations) you find that in the time dimension the co-cs mode partitions resource (time) up into regular time slices....so this means both the start epoch (an implicit label) and (most crucially) its duration are fixed.  
	 
	Without going into major detail here (I have paper on this I can send you if you want...just ask) what this means is that the co-cs mode is the ultimate 'smoother/shaper' for client traffic......so as you rightly observe this looks like a stream case.  It's not a specific external application however like human voice or video (these must generate real *information* that communicating parties understand) but it for sure has the CBR behaviour of a stream. 
	 
	BTW the reason the co-cs mode has been enduringly successful as a transport network is because it provides *transparency* to all clients (which is exactly the similar behaviour of a stream as you note), ie
	-    all client bits treated equally (a really key point this, as this means it provides equal 'importance' treatment of the ultimate higher level (and unseen/unknown by the co-cs transport network) message/file/stream applications)
	-    client bit ordering is preserved
	-    does not try an infer meaning of client bits nor change them
	-    ensures the traffic behaviour of client X cannot impact the performance experienced by party Y.

	regards, Neil 
	
	Regards, 
	Suhui. 

<[email-masked]> 

2009-04-29 14:40 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	Thanks Shuhui, 

	  

	  

	  

	  

	  
	regards, Neil 

	Hi Neil, 

	
	Regard, 
	Suhui 

<[email-masked]> 

2009-04-28 14:43 

收件人

	

	

	

	regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 29 Apr 2009 14:04:58 +0200

Sasha,
 
See inline..

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 29 april 2009 11:37
To: Igor Bryskin; Maarten Vissers; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

I may be completely wrong,  but why should the server (MPLS-TP transport
path) be aware of any specific clients that use it, be it a the path
termination point or in the intermediate node? 

[mv] The MPLS-TP LSP itself is not aware of any of its clients. It is the
LSP-to-client adaptation function that is aware of the clients of the LSP.
And this adaptation function has to be aware of the clients as it has to
demultiplex and decapsulate the client signals from the LSP.

*	As long as the server LSP is not terminated, LSR does not looks only
on the top label  

	[mv] correct. 

*	Once the server LSP is terminated (which, IMO, is equivalent to the
top label being popped), switching is done on the next label without
"keeping in mind" the popped label  

*	[mv] correct. This next label identifies a client and the adaptation
function which extracts this client is aware of the client type; e.g. LSP,
PW, EVC,..  

2.	The MPLS-TP requirements draft does not contain an appropriate
requirement of such awareness. On the contrary, Requirement 25A seems to
make such awareness undesirable.  [mv] You have to distinguish between the
layer network and the interlayer adaptation function which interconnects
layer networks. Within the layer network (i.e. within the LSP trails) there
is no client awareness. Within the adaptation functions at the end of the
LSP trail there is complete client awareness.  

3.	In SONET/SDH the server is not aware of any specific clients: if a
server failure is detected, its consequent action spreads "all ones" over
all potential clients. But this is somewhat difficult to imitate in packet
networks  [mv] If you look at OTN equipment standard G.798, you will see
that client specific AIS is inserted in the adaptation sink functions. AIS
is not longer inserted in the termination sink functions in G.798 (see e.g.
14.2.1.2/G.798). This change with respect to AIS insertion in termination
sink functions was introduced first in the ATM equipment specifications
(I.732), which followed in time the SDH equipment specification (G.783). In
the case of Ethernet, you also find that the ETHx_FT_Sk function does not
insert AIS; AIS is inserted by the next adaptation sink function (G.8021). 

4.	In ATM, the server (VPC) termination point is, indeed, fully aware
of all its clients (VPC). But this awareness is dictated by the ATM data
plane where VPI is link-local and VCI is link-  and VPI-local.  [mv] In ATM
the VPI and VCI are "per interface" labels. In MPLS-TP the Labels should
also be per interface labels. I.e. when an LSP to EVC adaptation sink
function receives a packet with an EVC (i.e. PW) label value that is not
registered it has to discard this packet and increment an unexpected packet
counter. Not discarding such packets with unregistered label values on a
port will introduce a security risk in a transport network.

In other words, IMHO and FWIW, server awareness of its clients (or lack
thereof) is dictated by the data plane specifics. As long as we state that
MPLS-TP data plane is the same as that of MPLS, such awareness does not
exist in MPLS-TP. And I do not think that it is correct to derive data plane
requirements from OAM concepts.  [mv] MPLS-TP dataplane should use the
per-interface label space. Then there is no problem, as all active client
labels are registered on every port. 

REgards,

Maarten

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Igor
Bryskin [[email-masked]]
Sent: Tuesday, April 28, 2009 6:04 PM
To: Maarten Vissers; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Neil.

Cheers,
Igor

-----Original Message-----

Neil,

Regards,
Maarten

-----Original Message-----

Nurit,

regards, Neil

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 14:38:07 +0100

Maarten, 

> I don't know of any such "AIS specific configuration".

Forwarding is a lookup keyed on the label value giving back an outgoing
port and a new label value followed by passing of the packet to the port
and swapping the label value.

AIS insertion is a lookup keyed on a server trail id (if this is not
implicit) of a set of label values followed by the creation of packets
with these label values followed by either passing the packets to the
forwarding engine (if the lookup is of incoming labels) or to output
port (if the lookup is of outgoing labels).

These are quite different operations even if there are some
circumstances when entries may be inserted into each lookup table at the
same time - locked as you put it.

Also, in circuit switching, AIS does not require any label look up
operation.

> > subnetwork) where we terminate the section layer on one 
> interface and 
> > blindly ship all the packets out on an other interface in a new 
> > section.
> 
> I am interested to learn in which types of equipment this 
> occurs, or at which location in a network this occurs. I have 
> not come across this so far in transport network equipment 
> designs. I.e. 
> I have come across a port-based service.

No this is not a port-based service. The Ethernet equivalent would be a
two port bridge. The sections are terminated, packets are passed, but
there is no bridge learning.

Andy

Andy Reid

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 14:38:07 +0100

Maarten, 

Andy

Andy Reid

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 15:45:52 +0100

Maarten,

>From this, you are agreeing the basic operational model. I was trying to
be both concise and reasonably general to different maintenance
scenarios (and the posting was still pretty long). In the detailed
scenario you describe, the distinction between 'proactive' and
'reactive' maintenance is whether the guy wants the alarm raised to him
immediately and he will deal with it ahead of any trouble ticket raised
by a customer or whether the guy only wants to know the alarm status in
front of him at the time the customer raises the trouble ticket. In both
cases the 'suppressed' alarm is still needed in the higher level
management system.

Exact procedures for fault locations will vary, I'm sure, as do the
systems available to help. Importantly, there will inevitably be a
variety of residual faults which occur which do also sit neatly into
prior assumptions of what can go wrong. So fault localisation *must*
include procedures to deal with things which do not say 'I am broken,
fix me'. What is damaging to the fault localisation process is if there
is false information around.

Andy

Andy Reid

> Sent: 29 April 2009 08:18
> To: Reid,ABD,Andy,CXM R; [email-masked]
> Cc: [email-masked]
> You speak about "local" and "remote" alarms. I had to read 
> the rest of the sentence three times before I understood that 
> you meant "primary" and "secondary/consequential" alarms. 
> A primary alarm is an alarm that reports a fault cause that 
> needs fixing, whereas a secondary/consequential alarm is a 
> report from a client that it's connection is interrupted due 
> to a server fault.
> I agree with you that the main task of fault management is to 
> know if there is a fault that they can repair, what the fault 
> is, where the location of this fault is and then who to send 
> to repair the fault.
> 
> I agree with you that service management needs to know about 
> the status of the service when the customer calls. I do not 
> agree with you that in general "these guys wants to know that 
> the service is 'down' **before** the customer is on the phone!".
> 
> I have very explicit information of a few operators that a 
> large number of service contracts will not be as you 
> describe. Values given to me are 90% of service contracts 
> (representing 70% of service connections) are without 
> pro-active monitoring. In those contracts the repair time 
> starts after the report of the customer and verification by 
> the operator. What is important in those cases is that the 
> service manager can simply retrieve status information when 
> the customer is on the phone.
> 
> The other 10% of service contracts (representing 30% of 
> service connections) are with pro-active monitoring. In those 
> contracts the repair time starts after the defect is 
> detected. I assume that "these guys wants to know that the 
> service is 'down' **before** the customer is on the phone!" 
> is applicable for a subset of those service connections. For 
> the other subset I have understood that it is sufficient when 
> the status/performance information of the service connection 
> can be retrieved instantaneously when the customer is on the 
> phone. Is this also the case in BT?
> 
> Besides the service connections, we have tunnel/path 
> connections, section connections and physical media 
> connections. Those connections have no direct "service" 
> associated with it; i.e. those connections are part of the 
> network's infrastructure. There is as such no "service 
> manager" interested in the status of those infrastructure 
> connections. The only people interested in alarms from those 
> infrastructure connections are the fault management people. 
> Do I understand this correct?
> 
> > The service maintenance guys *have* got an alarm - the customer has 
> > not got their service! They also notice that it is not 
> fixing itself. 
> > So they investigate, ie start localising.
> 
> I do not understand why a service maintenance guy will have 
> to do the fault localization... I have always been told that 
> fault management is responsible for locating a fault. If the 
> fault is an open matrix connection (which either interrupts a 
> tunnel/path connection or a service/channel connection), then 
> the fault management people responsible for the layer network 
> will be triggered by the loss of CC alarm and start the 
> localization procedure.
> 
> When a network deploys AIS, it is possible to trigger this 
> open matrix fault localization procedure without any complex 
> network correlation procedure.
> Before dealing with the specific scenarios, let me go through 
> again what I said in an earlier posting about the way alarm 
> 'suppression' actually works.
> 
> There are two sides to maintenance - the faulty kit guys who 
> fix faulty cards, mend cable breaks, etc, etc, and end 
> service guys who deal with customer service. 'Suppressed' 
> alarms are only suppressed to the faulty kit guys who fix 
> cards, etc. The distinction between 'local' and 'remote' 
> alarms is very important to ensure that these faulty kit guys 
> are directed to the place where the actual fault lies and not 
> to places affected by, but remote from the actual fault.
> 
> However, these 'suppressed' alarms are still forwarded to the 
> service maintenance guys. So when SONET/SDH is carrying an E1 
> or a T3, they want to know whether the end service is 'up' or 
> 'down' irrespective of the cause and irrespective of the 
> presence of AIS. AIS most emphatically does not suppress this 
> alarm! These guys wants to know that the service is 'down' 
> before the customer is on the phone!
> 
> So to go to Maarten's first example, the faulty kit guys are 
> not getting any alarms telling them to fix broken kit - which 
> is correct.
> 
> The service maintenance guys *have* got an alarm - the 
> customer has not got their service! They also notice that it 
> is not fixing itself. So they investigate, ie start 
> localising. In practice, the first thing they will do (and 
> most management systems will do it automatically by some form 
> of correlation engine) is check for any corresponding faulty 
> kit alarms. In this case, they will find no faulty kit alarms 
> and suspect a misconfiguration, localise it, and fix it.
> 
> To go to Maarten's second example, the faulty kit guys are 
> getting an alarm telling them to fix the link between A and B.
> 
> The service maintenance guys have also got an alarm - again 
> the customer has not got their service. They also notice that 
> it is not fixing itself. So they investigate, ie start 
> localising. Again, the first thing they will do (and most 
> management systems will do it automatically by some form of 
> correlation engine) is check for any corresponding faulty kit 
> alarms. In this case, they will find the corresponding faulty 
> kit alarm and can check of the repair plan and status should 
> the customer call and ask.
> 
> As these particular scenarios illustrate, the right alarms 
> have been directed to the right maintenance guys. The service 
> guys deal with the service configurations, the faulty kit 
> guys deal with faulty kit.
> 
> Occasionally, there will be faulty kit which is not reporting 
> itself despite the best design efforts in the equipment. In 
> this case, the service maintenance guys are likely to have a 
> series of alarms which can be correlated to help localise the 
> fault and the diagnosed fault can then be passed to the 
> faulty kit guys for fixing.
> 
> Another important point. There is little room here for 
> *false* information coming to either set of maintenance guys. 
> When trying to localise a fault, no additional information is 
> better than wrong additional information.
> 
> That is my concern with the trying to inject packet based 
> AIS. There is significant room for creating false 
> information. As I've already indicted there is AIS specific 
> configuration to do which will be prone to misconfiguration. 
> We should then note that the thing that the AIS is supposed 
> to be identifying is the present of misconfiguration - but 
> achieving this requires configuration. So why should one 
> configuration be more reliable than the other?
> 
> But there are other scenarios. For example, consider port 
> mapping (or in ITU-T speak, a degenerate subnetwork) where we 
> terminate the section layer on one interface and blindly ship 
> all the packets out on an other interface in a new section. 
> If we assume AIS is being used, a fault in the incoming 
> section should result in the injection of AIS. But how does 
> it know what label values to use? Or does it not inject AIS? 
> In which case we have the poor service maintenance guys 
> actively looking for a configuration error which does not 
> exist. A similar scenario would exist if we choose to use a 
> sort of ADM where the forwarding table was made up of 
> exception (add/drop) label values and a default outgoing 
> port. Again, the same dilemma exists.
> 
> Andy
> 
> 
> 
> 
> Andy Reid
> Registered in England no. 1800000 This electronic message 
> contains information from British Telecommunications plc 
> which may be privileged or confidential. The information is 
> intended to be for the use of the individual(s) or entity 
> named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the 
> contents of this information is prohibited. If you have 
> received this electronic message in error, please notify us 
> by telephone or email (to the numbers or address above) immediately.
> Activity and use of the British Telecommunications plc email 
> system is monitored to secure its effective operation and for 
> other lawful business purposes. Communications using this 
> system will also be monitored and may be recorded to secure 
> effective operation and for other lawful business purposes.
> 
>  
> 
> any other 
> required to 
> connection but a 
> any other 
> system it is 
> interruption 
> are never a 
> re-routing, which 
> completely and 
> provisioned by a 
> [email-masked]; 
> understand why do

---

From: "Malcolm Betts" <[email-masked]>
Date: Wed, 29 Apr 2009 11:11:15 -0400

Andy, Maarten,

Without going into all of the details, I think that you are describing a
function that should be performed by the element management alarm
reporting and control function. 

i.e. does a certain condition, or combination of conditions, result in
an autonomous notification to a management system, or is it simply a
condition that is reported "on demand".

>From the perspective of this discussion we should focus on the
primitives that are delivered to the alarm reporting and control
function.

The key "information elements" that must be provided are:
1) Has the trail failed
2) Has the failure been caused by i) a "local" fault i.e. in the
equipment or on an incoming link:  or ii) by a "remote" fault i.e. in
another node or on an incoming link that terminates on a remote node.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, April 29, 2009 10:46 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

Maarten,

Andy

Andy Reid

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ Registered in
England no. 1800000 This electronic message contains information from
British Telecommunications plc which may be privileged or confidential.
The information is intended to be for the use of the individual(s) or
entity named above. If you are not the intended recipient be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.
Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful
business purposes. Communications using this system will also be
monitored and may be recorded to secure effective operation and for
other lawful business purposes.

> You speak about "local" and "remote" alarms. I had to read the rest of

> the sentence three times before I understood that you meant "primary" 
> and "secondary/consequential" alarms.
> A primary alarm is an alarm that reports a fault cause that needs 
> fixing, whereas a secondary/consequential alarm is a report from a 
> client that it's connection is interrupted due to a server fault.
> I agree with you that the main task of fault management is to know if 
> there is a fault that they can repair, what the fault is, where the 
> location of this fault is and then who to send to repair the fault.
> 
> I agree with you that service management needs to know about the 
> status of the service when the customer calls. I do not agree with you

> that in general "these guys wants to know that the service is 'down' 
> **before** the customer is on the phone!".
> 
> I have very explicit information of a few operators that a large 
> number of service contracts will not be as you describe. Values given 
> to me are 90% of service contracts (representing 70% of service 
> connections) are without pro-active monitoring. In those contracts the

> repair time starts after the report of the customer and verification 
> by the operator. What is important in those cases is that the service 
> manager can simply retrieve status information when the customer is on

> the phone.
> 
> The other 10% of service contracts (representing 30% of service 
> connections) are with pro-active monitoring. In those contracts the 
> repair time starts after the defect is detected. I assume that "these 
> guys wants to know that the service is 'down' **before** the customer 
> is on the phone!"
> is applicable for a subset of those service connections. For the other

> subset I have understood that it is sufficient when the 
> status/performance information of the service connection can be 
> retrieved instantaneously when the customer is on the phone. Is this 
> also the case in BT?
> 
> Besides the service connections, we have tunnel/path connections, 
> section connections and physical media connections. Those connections 
> have no direct "service"
> associated with it; i.e. those connections are part of the network's 
> infrastructure. There is as such no "service manager" interested in 
> the status of those infrastructure connections. The only people 
> interested in alarms from those infrastructure connections are the 
> fault management people.
> I do not understand why a service maintenance guy will have to do the 
> fault localization... I have always been told that fault management is

> responsible for locating a fault. If the fault is an open matrix 
> connection (which either interrupts a tunnel/path connection or a 
> service/channel connection), then the fault management people 
> responsible for the layer network will be triggered by the loss of CC 
> alarm and start the localization procedure.
> 
> When a network deploys AIS, it is possible to trigger this open matrix

> fault localization procedure without any complex network correlation 
> procedure.
> Before dealing with the specific scenarios, let me go through again 
> what I said in an earlier posting about the way alarm 'suppression' 
> actually works.
> 
> There are two sides to maintenance - the faulty kit guys who fix 
> faulty cards, mend cable breaks, etc, etc, and end service guys who 
> deal with customer service. 'Suppressed'
> alarms are only suppressed to the faulty kit guys who fix cards, etc. 
> The distinction between 'local' and 'remote'
> alarms is very important to ensure that these faulty kit guys are 
> directed to the place where the actual fault lies and not to places 
> maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they 
> want to know whether the end service is 'up' or 'down' irrespective of

> the cause and irrespective of the presence of AIS. AIS most 
> emphatically does not suppress this alarm! These guys wants to know 
> that the service is 'down'
> So to go to Maarten's first example, the faulty kit guys are not 
> getting any alarms telling them to fix broken kit - which is correct.
> 
> not got their service! They also notice that it is not fixing itself. 
> So they investigate, ie start localising. In practice, the first thing

> kit alarms. In this case, they will find no faulty kit alarms and 
> suspect a misconfiguration, localise it, and fix it.
> 
> The service maintenance guys have also got an alarm - again the 
> customer has not got their service. They also notice that it is not 
> fixing itself. So they investigate, ie start localising. Again, the 
> first thing they will do (and most management systems will do it 
> automatically by some form of correlation engine) is check for any 
> corresponding faulty kit alarms. In this case, they will find the 
> corresponding faulty kit alarm and can check of the repair plan and 
> status should the customer call and ask.
> 

> service maintenance guys are likely to have a series of alarms which 
> can be correlated to help localise the fault and the diagnosed fault 
> can then be passed to the faulty kit guys for fixing.
> 
> When trying to localise a fault, no additional information is better 
> than wrong additional information.
> 
> That is my concern with the trying to inject packet based AIS. There 
> is significant room for creating false information. As I've already 

> to misconfiguration.
> We should then note that the thing that the AIS is supposed to be 
> identifying is the present of misconfiguration - but achieving this 
> requires configuration. So why should one configuration be more 
> reliable than the other?
> 
> But there are other scenarios. For example, consider port mapping (or 
> in ITU-T speak, a degenerate subnetwork) where we terminate the 
> section layer on one interface and blindly ship all the packets out on

> an other interface in a new section.
> If we assume AIS is being used, a fault in the incoming section should

> result in the injection of AIS. But how does it know what label values

> to use? Or does it not inject AIS?
> In which case we have the poor service maintenance guys actively 
> looking for a configuration error which does not exist. A similar 
> scenario would exist if we choose to use a sort of ADM where the 
> forwarding table was made up of exception (add/drop) label values and 
> a default outgoing port. Again, the same dilemma exists.
> 
> Andy
> 
> 
> 
> 
> Andy Reid
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
> England no. 1800000 This electronic message contains information from 
> British Telecommunications plc which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) or entity named above. If you are not the intended 
> recipient be aware that any disclosure, copying, distribution or use 
> of the contents of this information is prohibited. If you have 
> received this electronic message in error, please notify us by 
> telephone or email (to the numbers or address above) immediately.

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 17:06:52 +0100

Malcolm,

I think this could be suitable way forward.

Andy

Andy Reid

> From: Malcolm Betts [mailto:[email-masked]] 
> Sent: 29 April 2009 16:11
> To: Reid,ABD,Andy,CXM R; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] AIS/FDI (was 
> Without going into all of the details, I think that you are 
> describing a function that should be performed by the element 
> management alarm reporting and control function. 
> 
> i.e. does a certain condition, or combination of conditions, 
> result in an autonomous notification to a management system, 
> or is it simply a condition that is reported "on demand".
> 
> From the perspective of this discussion we should focus on 
> the primitives that are delivered to the alarm reporting and 
> control function.
> 
> 2) Has the failure been caused by i) a "local" fault i.e. in 
> the equipment or on an incoming link:  or ii) by a "remote" 
> fault i.e. in another node or on an incoming link that 
> terminates on a remote node.
> 
> Malcolm Betts
> Nortel Networks
> [mailto:[email-masked]] On Behalf Of [email-masked]
> From this, you are agreeing the basic operational model. I 
> was trying to be both concise and reasonably general to 
> different maintenance scenarios (and the posting was still 
> pretty long). In the detailed scenario you describe, the 
> distinction between 'proactive' and 'reactive' maintenance is 
> whether the guy wants the alarm raised to him immediately and 
> he will deal with it ahead of any trouble ticket raised by a 
> customer or whether the guy only wants to know the alarm 
> status in front of him at the time the customer raises the 
> trouble ticket. In both cases the 'suppressed' alarm is still 
> needed in the higher level management system.
> 
> Exact procedures for fault locations will vary, I'm sure, as 
> do the systems available to help. Importantly, there will 
> inevitably be a variety of residual faults which occur which 
> do also sit neatly into prior assumptions of what can go 
> wrong. So fault localisation *must* include procedures to 
> deal with things which do not say 'I am broken, fix me'. What 
> is damaging to the fault localisation process is if there is 
> false information around.
> 
> Andy
>  
> 
> Andy Reid
> which may be privileged or confidential.
> The information is intended to be for the use of the 
> individual(s) or entity named above. If you are not the 
> intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information is 
> prohibited. If you have received this electronic message in 
> error, please notify us by telephone or email (to the numbers 
> or address above) immediately.
> the rest of
> network's 
> customer has 
> to do the 
> open matrix
> cards, etc. 
> getting an 
> have been 
> AIS. There 
> mapping (or 
> section should
> condition is 
> generated 
> [email-masked]; 
> [email-masked]; 
> signal fail 
> [email-masked];

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 17:16:10 +0100

It also works for me Malcolm.

regards, Neil

> Sent: 29 April 2009 17:07
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI 
> (wasAssociatedbidirectionaltransportpathrequirements)
> 
> Malcolm,
> 
> Registered in 
> > > > Such reroute will remove the CP/FP and as such will 
> stop the AIS 
> > > > generation.
> > > >

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 29 Apr 2009 19:57:12 +0200

I agree!

-----Original Message-----
From: ext Thomas Nadeau [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 1:01 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional

	It would be best is these "Tier-1 SPs" would comment directly on
the  
list or contribute to the requirements draft.

	--Tom

---

From: [email-masked]
Date: Thu, 30 Apr 2009 09:59:44 +0800

Hi Neil,

I think I misunderstood the words ‘top-of-stack network’ , It doesn’t 
mean a network is actually at top of the stack, so no matter what layer IP 
network is actually at, IP network is always a ‘top-of-stack network’ 
because it can ‘support external message/file/stream applications’. Is 
my understanding right?

But I still cannot agree the assertion that ‘any non top-of-stack network 
has no need for E-NNI peer-partition working between different operating 
parties’. As you said SDH is not a top-of-stack network, but VC4 
connections can pass through multi operator’s domains, so the interface 
between different domains is E-NNI. 

Regards,
Suhui.

<[email-masked]> 
2009-04-29 18:21

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
主题
RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path 
requirements)

Thanks Suhui......sorry I missed your specific question....have a look 
in-line and see if this helps.

Subject: 答复: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 

Hi Neil， 

NH=> Fully understand.  I was giving IP as an *example* of a technology 
that can support real external applications because it has 
message/file/stream application adaptation functions in the form of 
UDP/TCP/RTP.   In the case of E1 that you note (as E1overPWoverMPLS-TP) 
you have to ask yourself what specific *external* applications does the E1 
support here?.....always remembering that *any* networking technology MUST 
ultimately support some form of *externally sourced* information source 
else it is not serving any purpose.  So just supporting E1 on its own does 
not provide this....for example ask yourself how voice or any type of 
message/file data gets carried by the E1.

NH=> The point here is that *any* network mode/technology (be it cl-ps, 
co-ps or co-cs) can act as the server for any other mode/technology. 
However, not all technologies can support external applications.....to 
support these the technology must have application adaptation functions 
for the message/file/stream information sources that are generated in 
external CPE, eg phone, PC, etc.
 
Most technologies do not have these external application adaptation 
functions and so the only job they can do is create the topology of other 
layer networks.
 
So yes we can use IP (cl-ps) to carry SDH VC4 (co-cs) if we 
want.......probably not a good idea but it is for sure possible.  However, 
an SDH VC4 network cannot *directly* support either voice or data but an 
IP network can.....because IP has UDP/TCP/RTP applications adaptations and 
SDH VC4 does not have these.  Having said that, there is in principle no 
reason why any mode/technology (even SDH VC4) cannot support external 
message/file/stream applications......its just that for most technologies 
these have never been specified because they were only ever intended to 
provide a 'network builder' transport role.
 
Aside=> If a technology X can support message/file/stream applications 
directly then here we would most definitely have to consider 
peer-interworking technology X with both IP (Internet) and PSTN (voice 
case only).  In all other cases (ie where technology X is not 
top-of-stack, ie does not have message/file/stream application adaptation 
functions) there is no need for peer-interworking it with any other 
technology, including IP (Internet) and PSTN.

Your final point ("I think E1 is ‘real external stream applications’" ) 
is not strictly correct but I can fully understand why you say this.  E1 
belongs to the co-cs mode.  When you analyse this (as is done in G.800, 
which explains why the 3 network modes arise from information/systems 
theory considerations) you find that in the time dimension the co-cs mode 
partitions resource (time) up into regular time slices....so this means 
both the start epoch (an implicit label) and (most crucially) its duration 
are fixed. 
 
Without going into major detail here (I have paper on this I can send you 
if you want...just ask) what this means is that the co-cs mode is the 
ultimate 'smoother/shaper' for client traffic......so as you rightly 
observe this looks like a stream case.  It's not a specific external 
application however like human voice or video (these must generate real 
*information* that communicating parties understand) but it for sure has 
the CBR behaviour of a stream. 
 
BTW the reason the co-cs mode has been enduringly successful as a 
transport network is because it provides *transparency* to all clients 
(which is exactly the similar behaviour of a stream as you note), ie
-    all client bits treated equally (a really key point this, as this 
means it provides equal 'importance' treatment of the ultimate higher 
level (and unseen/unknown by the co-cs transport network) 
message/file/stream applications)
-    client bit ordering is preserved
-    does not try an infer meaning of client bits nor change them
-    ensures the traffic behaviour of client X cannot impact the 
performance experienced by party Y.

regards, Neil 

Regards, 
Suhui. 

<[email-masked]> 
2009-04-29 14:40 

收件人
<[email-masked]> 
抄送

Thanks Shuhui, 

  

  

  

  

  
regards, Neil 

Hi Neil, 

Regard, 
Suhui 

<[email-masked]> 

收件人

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 30 Apr 2009 06:26:30 +0200

We are discussing a change of a general fault management principle. This
change will impact the following recommendations: G.806 (generic), G.7710
(generic), G.705 (PDH), G.783/G.784 (SDH), G.798/G.874 (OTN),
G.8021/Y.1731/G.8051 (Ethernet), I.732/I.610 (ATM) and G.8121/G.8112/G.8151
(MPLS-TP). This proposed change has implications beyond the scope of MPLS-TP
and should be addressed in Q.9/15, Q.10/15, Q.11/15 and Q.14/15.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: woensdag 29 april 2009 19:57
To: ext Thomas Nadeau
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

I agree!

-----Original Message-----
From: ext Thomas Nadeau [mailto:[email-masked]]
Sent: Wednesday, April 29, 2009 1:01 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional

	--Tom

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 29 Apr 2009 23:59:22 -0500

All I can say is that the impact of this proposed change is very
serious. 
Doesn't MPLS-TP suppose to meet the ITU-T transport requirements instead
of changing the ITU-T transport requirements?

Regards,
Kam

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Maarten Vissers
> Sent: Thursday, April 30, 2009 12:27 AM
> To: [email-masked]
> (MPLS-TP). This proposed change has implications beyond the scope of
MPLS-
> TP
Behalf
> > environment. Their requirement was that if a server layer (e.g.
MPLS-
> > TP

---

From: <[email-masked]>
Date: Thu, 30 Apr 2009 07:28:03 +0100

Thanks Suhui

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 30 April 2009 03:00
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Niven-jenkins,B,Ben,DMF R; [email-masked]; [email-masked]; [email-masked]
	Subject: 答复: RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

	Hi Neil, 
	
	I think I misunderstood the words ‘top-of-stack network’ , It doesn’t mean a network is actually at top of the stack, so no matter what layer IP network is actually at, IP network is always a ‘top-of-stack network’ because it can ‘support external message/file/stream applications’. Is my understanding right? 
	 
	NH=> Yes.   There is probably a better term for it, but it was the expression that first came to mind when I wanted a shorthand way to define:
	-    the network that directly supports external applications -  top-of-stack.
	-    the  network that modulates the EM wave on metallic/optical/radio media - bottom-of-stack
	 
	Note - some network technologies cannot currently fulfil either of these roles....indeed MPLS is like this. 
	
	Both these networks must be present in all practical networking situations:
	-    if the former is not present the networking of the lower layers is serving no purposes;
	-    if the latter is not present we cannot send information across geographic distance......and just as I and Deborah have repeatedly pointed out the mere that there is physical interface/connection here does *not* mean this is an E-NNI. 
	 
	An E-NNI must consider all DP and CP components that are used by an operating party in their own domain for some network mode/technology X.....so this is much more than simply OAM.  In particular it must consider the DP interworking of the end-system application adaptation functions that support external message/file/stream applications, and if these are *not* present then network X MUST be supporting a higher layer network Y by definition.  We therefore observe that peer-partition interworking at network X is not necessary.  Network X can be fully terminated at the interworking point and network Y passed transparently.  The above is recursive upwards until we come to the real top-of-stack network and it is here that E-NNIs are essential.....and indeed this is exactly what we see for the public networks of the Internet and the PSTN.

	But I still cannot agree the assertion that ‘any non top-of-stack network has no need for E-NNI peer-partition working between different operating parties’. As you said SDH is not a top-of-stack network, but VC4 connections can pass through multi operator’s domains, so the interface between different domains is E-NNI.  
	 
	NH=> No, this is not correct.  We can of course create E-NNIs for any network/mode we like, but what I am showing is that this is not technically necessary for networks that are not top-of-stack.  In fact it is actually much more serious than simply "not necessary", because when you create such peer-partitions between different parties you are forcing them to evolve their networks (that have such peer partitions) in lock-step (and there are also regulatory factors to consider here - also see Aside below).   For the vast majority of practical situations a client/server relationship is more relevant, safer and important.
	 
	This situation would be even more unacceptable should such peer-partitions be between different modes/technologies, eg Ethernet and MPLS interworking.  This is most definitely not a good idea and we in BT will not support this. 
	 
	Aside=> This does not prevent operating parties having private bilateral peer-partition relationships in some non top-of-stack network technology.   However, this would need to consider any legal/commercial regulatory framework that is in force where this is being considered.
	 
	Neil Harrison
	Chief Network Operations Strategist
	BT Innovate
	
	Tel: +44 (0) 1 604 820 052
	Email: [email-masked] <mailto:[email-masked]> 
	Web: www.bt.com <http://www.bt.com/>  
	This email contains BT information, which may be privileged or confidential.
	It's meant only for the individual(s) or entity named above. If you're not the intended
	recipient, note that disclosing, copying, distributing or using this information
	is prohibited. If you've received this email in error, please let me know immediately
	on the email address above. Thank you.
	We monitor our email system, and may record your emails. 
	British Telecommunications plc
	Registered office: 81 Newgate Street London EC1A 7AJ
	Registered in England no: 1800000 

	Regards, 
	Suhui. 

	
<[email-masked]> 

2009-04-29 18:21 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: RE: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path        requirements)

	Hi Neil， 

	 

	  

	  

	regards, Neil 
	
	Regards, 
	Suhui. 

<[email-masked]> 

2009-04-29 14:40 

收件人
<[email-masked]> 
抄送

	

	Thanks Shuhui, 

	 

	 

	 

	 

	 
	regards, Neil 

	Hi Neil, 

	
	Regard, 
	Suhui 
	
<[email-masked]> 

2009-04-28 14:43 

收件人

	

	

	

	
	regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 30 Apr 2009 08:07:57 +0100

Eh?

Tom & Nurit (and I) agree that SPs should speak for themselves on what their
requirements are for MPLS-TP.

I am supporting PDH, Ethernet and ATM services over my MPLS network today
and my MPLS network does not perform AIS insertion at all so I do not see
how a lack of AIS in MPLS (or MPLS-TP) impacts those standards.

Maybe the issue is between an understanding of the theoretical and of the
practical. As stated, in practice I am supporting the network types above
without problems even though the MPLS network supporting them does not
support AIS.
 
Let's not confuse things and let's not scare monger huge changes that IMO do
not exist.

Ben

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 30 Apr 2009 08:33:44 -0400

ad hoc MPLS-TP co chair hat on:

All, the agreement between the IETF and the ITU is that the IETF will
develop MPLS-TP to fully meet the requirements of the transport network.
Clearly the requirements for MPLS-TP cannot and will not retroactively
change the requirements and functionality already deployed in transport
network.

A few days (and probably a few hundred messages) ago I thought we had
reached convergence on this issue.  We need to separate the requirement
from the implementation.  AIS is an implementation with an implicit
requirement.

>From the perspective of the requirements:

When a MPLS-TP equipment (or node) detects a loss of CC messages it
MUST be able to determine if that loss is caused by a fault that's a) in
the local node or locally terminated link: or b) a fault in a remote
node or remotely terminated link.  The mechanism used to provide this
local/remote fault distinction SHOULD be highly reliable.

This is the function performed by AIS in PDH/SDH networks.

When we start working on the solutions draft we can decide how this
requirement can be met, we may also consider if the complexity of the
implementation is such that meeting this requirement is not a good
"engineering decision" - e.g. the implementation would not yield a
highly reliable result.

I will draft provide some draft text for the OAM requirements draft to
reflect this.  So for the moment can we please focus the discussion on
the requirement. I hope that this will allow us to close this point with
respect to the requirement.

Malcolm Betts
ad hoc MPLS-TP co chair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lam, Hing-Kam (Kam)
Sent: Thursday, April 30, 2009 12:59 AM
To: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

Regards,
Kam

Behalf
MPLS-
Behalf
the 
> > Personally I got many feedbacks from Tier-1 SPs that they would like

> > to have the capability to suppress alarms in a packet transport 
MPLS-
> > order to be able to suppress alarms at the client layer that may 
> > result from the fault at the server layer (e.g. MPLS-TP link).
> > response to link failures in its topology (because some server layer

> > network has failed....which may or may not belong to the same 
> > operating party as the
> > *routing process*
in
> > the client is independent of the server layer network....so there is

> > not a fixed client/server relationship.  Further, there is also no 

> > fact if this is in the OAM requirements then it is technically wrong

> > and should be removed IMO.
> >
> > regards, Neil

> >> If we agree that the requirement is included, so why do we keep 
> >> with the endless discussions on this requirement?
> >>
> >>> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit 
> >>> (NSN - IL/Hod HaSharon)

> >>> client layers as a result of a failure condition in the server 
> >>> layer may be suppressed.

---

From: George Newsome <[email-masked]>
Date: Thu, 30 Apr 2009 09:15:46 -0400

> of changing the ITU-T transport requirements?
Hi Kam,

AIS, which we are so very comfortable with, is a solution to a rather 
poorly stated requirement. The requirement is to distinguish between 
local faults (things that can be fixed here) and remote faults (things 
that have to be fixed elsewhere).

PDH (and SDH/OTN) emits bits whatever the state of the incoming signal 
and in the days of TTL, an open input was pulled up to 1. So extremely 
old PDH equipment, emitted a stream of all 1's when its input was open.

This allowed a convenient simple distinction between a valid traffic 
signal, which has at least some 0's in it, and a remote failed signal. 
It also provided a signal which checked the media between regenerators, 
and coincidentally, was propagated downstream for free.

And so we got AIS. It wasn't introduced to do stuff; it was just there 
as a result of an open input.

Today we are trying to capture the requirements that the AIS 
implementation satisfies ,so that we do not repeat the common mistake of 
copying SDH solutions directly into a fundamentally different technology.

mpls-tp is not about changing what a transport network does, but it is 
quite fundamentally changing how it does it.

Regards,

	George

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 30 Apr 2009 06:31:33 -0700

George,

An excellent note.

Thanks,

John 

> From: George Newsome [mailto:[email-masked]] 
> Sent: Thursday, April 30, 2009 6:16 AM
> To: Lam, Hing-Kam (Kam)
> Cc: [email-masked]
> > Doesn't MPLS-TP suppose to meet the ITU-T transport requirements 
> > instead of changing the ITU-T transport requirements?
> > 
> >
> Hi Kam,
> 
> AIS, which we are so very comfortable with, is a solution to 
> a rather poorly stated requirement. The requirement is to 
> distinguish between local faults (things that can be fixed 
> here) and remote faults (things that have to be fixed elsewhere).
> 
> PDH (and SDH/OTN) emits bits whatever the state of the 
> incoming signal and in the days of TTL, an open input was 
> pulled up to 1. So extremely old PDH equipment, emitted a 
> stream of all 1's when its input was open.
> 
> This allowed a convenient simple distinction between a valid 
> traffic signal, which has at least some 0's in it, and a 
> remote failed signal. 
> It also provided a signal which checked the media between 
> regenerators, and coincidentally, was propagated downstream for free.
> 
> And so we got AIS. It wasn't introduced to do stuff; it was 
> just there as a result of an open input.
> 
> implementation satisfies ,so that we do not repeat the common 
> mistake of copying SDH solutions directly into a 
> fundamentally different technology.
> 
> mpls-tp is not about changing what a transport network does, 
> but it is quite fundamentally changing how it does it.
> 
> Regards,
> 
> 	George

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 30 Apr 2009 09:51:18 -0400

George, 

I agree, a good historical perspective of how, in transport networks we
have arrived in the state where AIS is an implementation with an
implicit requirement rooted in TDM networks.

The discussion on MPLS-TP has forced us to separate out the requirement
(local vs. remote fault) from the implementation - insert all "1"s" in
TDM signals.

Given that MPLS-TP will be used in a transport network I see no reason
to change the requirement.

However, as you point out, the inherent differences between TDM and
packet networks forces us to consider alternate implementations - all
"1's" is not a valid packet signal.....

So as I suggested in my previous post can we agree on the requirement.
We can then discuss the implementation.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Thursday, April 30, 2009 9:32 AM
To: George Newsome; Lam, Hing-Kam (Kam)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

George,

An excellent note.

Thanks,

John 

> local faults (things that can be fixed

> implementation satisfies ,so that we do not repeat the common mistake 
> of copying SDH solutions directly into a fundamentally different 
> technology.
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 30 Apr 2009 10:19:44 -0400

I completely agree with George and Malcolm.

        There is one thing to say 
a) we don't like AIS in MPLS-TP the way it is implemented in SDH 
        and quite different thing to say
b) we don't like AIS in MPLS-TP because it brings nothing but complexity and confusion 

My vote would be "Yes" to the requirements for MPLS-TP LSP layer: 
a) to notify its clients about failures detected in the MPLS-TP LSP layer;
b) to honor such notifications from its own server(s) by (temporarily) suppressing recovery operations in the MPLS-TP LSP layer that would occur in the absence of such notifications.

Igor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm Betts
Sent: Thursday, April 30, 2009 9:51 AM
To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

George, 

Malcolm Betts
Nortel Networks

-----Original Message-----

George,

An excellent note.

Thanks,

John

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 30 Apr 2009 15:22:51 +0100

Malcolm,

As always the approach you propose is reasonable and I support it (i.e. We
specify the functional requirements not the solution at this stage).

I look forward to your proposed text for the OAM requirements.

Thanks
Ben

---

From: <[email-masked]>
Date: Thu, 30 Apr 2009 15:24:18 +0100

I support your proposal Malcolm.

regards, Neil
 
Neil Harrison

Tel: +44 (0) 1 604 820 052
Email: [email-masked]
Web: www.bt.com
This email contains BT information, which may be privileged or
confidential.
It's meant only for the individual(s) or entity named above. If you're
not the intended
recipient, note that disclosing, copying, distributing or using this
information
is prohibited. If you've received this email in error, please let me
know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> [mailto:[email-masked]] On Behalf Of Malcolm Betts
> Sent: 30 April 2009 13:34
> To: [email-masked]
> server layer
> Nurit (NSN

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 30 Apr 2009 16:36:57 +0200

Malcolm,
Thanks for trying resolving the issue.
I propose you first go over the requirement which is already specified
in the MPLS-TP requirement draft on "Alarm Notification".
IMO, it specifies a requirement which is in the sprit of what was
written in your e-mail and not do not refer to any implementation.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Malcolm Betts
Sent: Thursday, April 30, 2009 4:51 PM
To: Drake, John E; George Newsome; Lam, Hing-Kam (Kam)
Cc: [email-masked]
Subject: Re: [mpls-tp]
AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements)

George, 

Malcolm Betts
Nortel Networks

-----Original Message-----

George,

An excellent note.

Thanks,

John

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 30 Apr 2009 16:40:45 +0200

exactly, and it has been there for some time.

It is however perfectible and following this week mead
call I'll rework it a bit, using Malcolm's help of course ;-)

-m

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 30 Apr 2009 10:42:38 -0400

Working on the text right now.... 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 10:37 AM
To: Betts, Malcolm (CAR:X632); Drake, John E; George Newsome; Lam,
Hing-Kam (Kam)
Cc: [email-masked]
Subject: RE: [mpls-tp]
AIS/FDI(wasAssociatedbidirectionaltransportpathrequirements)

Malcolm,

-----Original Message-----

George, 

Malcolm Betts
Nortel Networks

-----Original Message-----

George,

An excellent note.

Thanks,

John

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 30 Apr 2009 16:53:25 +0200

Hi George,

I can imagine that you lost track in all messages.

You replied to Kam:

>> serious. Doesn't MPLS-TP suppose to meet the ITU-T transport 
>> requirements instead

I have already proposed text in a reply to Adrian.
because AIS is not mentioned you may have missed that.

You are just starting another round of discussions.

> old PDH equipment, emitted a stream of all 1's when its input was open.

I already replied to Neil that AIS is a (deliberate) consequent
action to a number of possible defects, e.g. loss of clock, loss
of lock, loss of signal, loss of frame.
BTW: DS3 AIS is *NOT* an all ONEs signal.

> as a result of an open input.

No, see above.

> copying SDH solutions directly into a fundamentally different technology.

There were already several attempts to provide text, did
you miss those?

De groeten, Huub.
-----------------

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 30 Apr 2009 15:57:28 -0400

Agree, I think this is already covered in the MPLS-TP OAM requirements
draft. 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 3:23 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; 'George Newsome'; 'Lam,
Hing-Kam (Kam)'
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

Hi Malcom,

Isn't it a requirement to distinguish between a layer failure or its
serve layer failure?

Shahram

-----Original Message-----
Behalf Of Malcolm Betts
Sent: April-30-09 9:51 AM

George, 

Malcolm Betts
Nortel Networks

-----Original Message-----

George,

An excellent note.

Thanks,

John