Subject: Re: [mpls-tp] Addressing (my personal favorite topic)

From: <[email-masked]>
Date: Mon, 2 Feb 2009 10:22:35 -0000

Suhui,
 
I disagree with you.  There is no TTL in ATM or FR...both are co-ps and have been in existence for a long time with no looping problems.  And this is is simply due to the fact that the CP/MP can verify that no loops exist prior to establishing a connection. 
 
Aside =>
 
Wrt to your remark on the co-cs mode.  Note that in the time dim (co-cs can also have freq and space dims) this has regular time slices where both (i) the start epoch and (ii) (crucially) the duration are fixed/known.  This means labelling (which is an implicit position in time) and resource requirements are *coupled* actions and are fully deterministic....one therefore cannot create loops in the co-cs mode even if one tried, eg try and fit 2 SDH VC4s into 1 SDH VC4!
 
In the co-ps mode we can only have irregular time slices of resource.  This means both the start epoch and the duration are unknown a priori.  This means labelling has to be explicit and one has to careful with how one accounts for resource usage....and provided there is no overbooking this large translates to a higher variance in delay (overbooking can mean discard/loss is required at times of traffic peak correlation).  What all this means is that the co-ps mode is less robust to poor arch specification/design, eg we can create merging constructs, we can grossly overbook the resuorces.  However, if we use proper connections then, as I noted earlier, the CP/MP can verify there are no loops before establishing a connection.
 
regards, neil

________________________________

From: [email-masked] [mailto:[email-masked]]
Sent: Mon 02/02/2009 08:05
To: Harrison,N,Neil,CXM R
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: ??: Re: [mpls-tp] Addressing (my personal favorite topic)

Hi Neil, 

I think TTL is need in co-ps network although it is not used in co-cs network, the reason is co-cs network is a dedicated bandwidth network and co-ps network is a shared bandwidth network. If a loop occurs in co-cs network (e.g. SDH), only the looped VC is affected and other VCs are not affected. However, if a loop occurs in co-ps network (e.g. MPLS), the looped LSP will exhaust the bandwidth if there is no TTL mechanism to discard the looped packet, and then all LSPs are affected. So, I think TTL mechanism should be used in co-ps network. 

Regards, 
Suhui 

<[email-masked]> 
???:  [email-masked] 

2009-01-29 05:00 

???
<[email-masked]> 
??
[email-masked] 
??
Re: [mpls-tp] Addressing (my personal favorite topic)	

Thanks Sasha....have tried to answer: 

________________________________

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: 28 January 2009 19:44
To: Harrison,N,Neil,CXM R
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Addressing (my personal favorite topic)

Neil, 
Lots of thanks for sharing your observations with me (and the list). 
  
I would like to clarify two points related to these observations: 
  
You say that you "find the notion of TTL in what is supposed to be a co-ps *transport* network rather bizarre. " My problem with this statement is that TTL is an integral part of the MPLS DP and, as such, is inherited by MPLS-TP DP.   The framework draft states this in the most unambiguous way. 
  
NH=> To be perfectly blunt it does not matter what the framework draft or any other document says, this is a technical point that exists on its own merit....and that technical point is that a co-cs/co-ps layer network does not require a TTL field for loop mitigation..show me an existing one that does?  So if it is retained it is for other reasons...like impact on existing silicon/boxes.  I can accept that argument.....but then we should be more honest and say this and not pretend/assume it is for loop mitigation here.....it can't be if MPLS-TP is designed properly as a transport technology.  If MPLS-TP really needs a TTL for loop mitigation then we must not call it a *transport network*, because it won't be one. 
  So IMHO there are two internally consistent approaches to it: 

*	Redesign MPLS-TP DP in a way that does not provide for TTL.  
	NH=> How can one 'redesign' something that has not even yet been specified and odes not exist?....or at least it shouldn't ;-)
	This would probably require using different protocol numbers for MPLS and MPLS-TP etc. 
	NH=> Well, interesting you brought this up, because they will for sure will be different layer networks....but MPLS was never singular anyway, ie you cannot tell from the MPLS DP traffic unit header what the signalling protocol is that one has to interwork with for this header.   
*	Explicitly define handling of MPLS-TP packets with expired TTL (including OAM packets). There are two ways to do this IMHO: 

	*	Silently discard these packets without any consequent action. At the very least this helps to break network loops 
		NH=> Network loops?  The CP/MP can check if there are any loops before establishing a connection.......how does GMPLS cope with SDH, OTN in this respect?....No TTL there. 
	*	Pass these packets for additional examination (beyond the data plane). 
	*	IMHO and FWIW Ethernet experience shows that: 
		NH=> Ethernet is not a co technology....it is cl, and it deals rather brutally with loop mitgation by topology pruning (STP) to degree 1.
		  
	*	Lack of TTL-based mechanisms requires special and dedicated effort for loop prevention 
	*	TTL-based troubleshooting (e.g., see 802.1ag linktrace method) is extremely useful for the network troubleshooting. 
		NH=> We are talking about a *co* mode network here...these factors are not relevent. 

	I must admit that I have failed to understand why troubleshooting of unidirectional failures resulting in leakage from the configured connection would not benefit from the tracing functionality, especially if it is based on TTL expiration. E.g., in your example the operator suspecting a leakage could run a trace on the path traversed by the connection packets and easily find the point where the responses (provided that any node can send them back to the originating node) leave the configured path. In the case of unintended replication you would see "extra responses" in addition to the expected ones - and this seems to be equally useful for troubleshooting of p2p and p2mp connections. This is exactly the behavior provided by LSP-ping in the traceroute mode. The fact that such functionality does not exist in co-cs networks does not mean that it is not required IMHO. 
	NH=> Please re-read what I stated and have a think about it.  And remember we are not dealing with a cl-ps mode network here....traffic/OAM leakage from a connection is NOT supposed to happen, so you cannot assume that any such fault will be bidirectionally symmetric in that one is going to get a *DP* response from any downstream node where the traffic/OAM might leak to. 
	  
	regards, neil 

	My 2c, 

	     Sasha 

________________________________

	From: [email-masked] [[email-masked]]
	Sent: Wednesday, January 28, 2009 4:48 PM
	To: Alexander Vainshtein; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Addressing (my personal favorite topic)
	
	Sasha,  I have some observations here: 

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
	Sent: 28 January 2009 13:36
	To: BRUNGARD, DEBORAH A, ATTLABS
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Addressing (my personal favorite topic)
	
	Debora (and all), 
	I've read the Addressing and Forwarding sections in the Framework draft, and I would like to ask several questions: 
	1.        The text (and the diagram) seem to suggest that node addressing for network management and for control/signaling may be different. 

	*	Is this understanding correct? 
	*	I so, what is the justification for having two distinct addressing schemes?

	2.        The forwarding plane of MPLS-TP seems to be the same as that of (regular) MPLS. Does this mean that the data plane destination address of an MPLS-TP packet (including OAM packets) is its label stack?   
	NH=> A DP label is not an address...it is a proxy for a real address. A label only has to be unique on a single link-connection (==hop), and its size is determined by how many client instances one wants to distinguish on a link. In most co-ps mode networks the only label that is used is a forwarding label that is proxy for the connection DA access point. Since a connection *must* only have a single source one does not need to provide a SA in normal co-ps mode traffic units ....which in any case are only forwarded on the DA proxy label..... as the connection itself carries the SA semantic. This works fine until there is misconnectivity....which is why one has to run a SA in a CV OAM flow on *all* connections in a label-swapping co-ps technology. If the traffic units already carry a SA (like PBB-TE does say, and obviously all cl-ps mode network do too) then one does not have to run an adjunct CV OAM flow to detect/protect-against misconnectivity...this now comes 'for free'  with no OAM running . 

	The label in a PW is *not* a DA fowarding proxy but a SA proxy....this is necessary to recover  the SA information lost from merging that LDP/PHP create. And this is why when PWs go multi-hop  (ie become another co-ps mode network) there is problem here because the label now need to become a DA proxy for forwarding .   Aside=>This is not a problem when only carrying IP, since IP is cl-ps and always carries a SA....so this can resolve any lower layer LDP/PHP merging that causes a loss of SA information 

	3.        The text states that OAM packets must carry identifier of the source. At the same time it states that addressing of OAM packets must be that of the forwarding (data) plane. 

	*	Source address of which entity should be carried in the  OAM packets? That of the source node or that of the source LSP end-point?  
		NH=> CV OAM pkts should carry the SA of the connection, ie the trail/access point address
		  
	*	With distinct addressing schemes for the data, management and control/signaling planes of MPLS-TP, which source address must be included in the OAM packets? 
		NH=> The DP OAM CV SA has nothing to do with the logically OOB CP/MP network...that must run its own OAM in the 1-hop server links it uses between logically adjacent CP/MP nodes.
		  
	*	Is there a requirement for the source address in the OAM packet to be understandable by all nodes in the MPLS-TP domain?  
		NH=> No...not by the nodes.  But the addresses must be unique in the network (and a real access point address not some locally generated string) so that if there is misconnectivity the SA gives immediate identification (to operations folks) of the offending connection.
		  
	*	Is it required for any MPLS-TP node that terminates an OAM packet (e.g., due to TTL expiration or because the last label  in the label stack has been popped) 
		NH=>I have to say I find the notion of TTL in what is supposed to be a co-ps *transport* network rather bizarre.
		
		 to be able to send a "response" to its source based on the source address contained in this packet? 
		NH=> If the DP detects a problem from the CV flow it should flag this to the NMS MP at the node where the problem is detected.  So there will be a *different* communications in the OOB MP network in this respect....not directly in the traffic DP.  The only DP OAM traffic that should result under such defects is a BDI OAM flow back towards the sink (and then only in the case of p2p connections....BDI makes no sense for p2mp connections in the direction leaf->root....which is also why piggybacking BDI in CV OAM pkts that one sees in Y.1731 is not a good idea for p2mp connections)   Note that this question is different from the previous one: e.g., if the source address used in the OAM packets is IP address of the source node in the management plane, it would be globally understandable, but the terminating node may not be able to send a response back to the source node because ability to map management pane IP addresses to data plane addresses is not required.

	4.        RFC 4379 defines the traceroute mode for MPLS, thus providing the operators with the ability to trace actual paths traversed by the labeled packets in an IP/MPLS network. The Framework draft explicitly states that the mechanisms defined for that purpose in 4379 are not applicable to MPLS-TP. But it does not state whether the traceroute functionality itself is required for MPLS-TP, and a scan for the word "trace" on the MPLS-TP OAM requirements draft did not find any hits. Does this imply that traceroute functionality is not required for (and hence will not be supported with) MPLS-TP? 
	NH=> This is a very important point Sasha as co networks are *not* the same as cl networks wrt tracing function OAM.  Let me explain.  When we create a connection in a co mode network it is a "constraining construct"...in the sense that traffic/OAM sent from the source of such a connection is never supposed to leave that connection.  However, if we have a defect which results in traffic leaking from one connection to another one (eg unintentend replication where the connection the traffic is leaking from may see no impact) then this is almost certainly going to be a unidirectional fault.  What this means is that any OAM pkts that are of a request/response nature will for sure leave the connection at the point of leaking but they will never come back.  This is why I have always insisted that there should some warining in the OAM for co mode networks that makes it clear that request/response OAM cannot be trusted under misconnectivity defects.  This is not the same a cl-ps mode network, where request/response OAM pkts are fine for a tracing pupose.
	
	regards, Neil 

	
________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
	Sent: Tuesday, January 27, 2009 10:26 PM
	To: Eric Gray; [email-masked]
	Subject: Re: [mpls-tp] Addressing (my personal favorite topic)
	
	Hi Eric, 
	  
	It's captured in the framework document. 
	Deborah 
	  
	From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
	Sent: Tuesday, January 27, 2009 2:56 PM
	To: [email-masked]
	Subject: [mpls-tp] Addressing (my personal favorite topic) 
	  
	On several occasions, the issue of required and default addressing has been raised. 
	  
	In the latest round of design team meetings, several people pointed out that a management 
	channel (as a practical consideration, at least) require addresses. 
	  
	One thing I anticipate as a comment is what addressing scheme is the default.  I expect 
	that we all know that the answer to that question is IP addressing, but I do not feel that 
	the NM requirements draft is the appropriate place to make such a statement - except as 
	a potential qualification of multiple choices offered in some other document. 
	  
	The question is: what document is the natural home for a statement on addressing, both 
	required and default? 
	  
	I looked in the MPLS-TP requirements draft, and did not find it there.  Where else might it 
	be found?  Given the number of times this issue has been raised, I am sure it should be 
	somewhere._______________________________________________
	mpls-tp mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/mpls-tp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp