SDH and EoSDH networks are widely used by Portugal Telecom Comunicacoes 
(PTC) and TMN (respectively the incumbent operator in Portugal and PT   
group's mobile operator), as well as foreign PT's clients (Brazilian "Vivo",    
for instance). These operators are used to both SDH and Ethernet's OAM  
paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST      
allow equivalent OAM mechanisms.        

Being more precise, we would like to use the same protocol messages, to 
give/have       
the same "touch&feel" we had in SDH and for less time in ETH.   

In SDH...       
-it allows you at each end to check you have signal reception and notify the 
other end when you don't (RDI)  
-it does so at different levels (in SDH you can have it both for each VC and 
for the STM)    
-it has a means by which to exchange an APS protocol    

In ETH...       
-we've been using Y.1731 in EoSDH systems; it was the ITU standard developed 
for this purpose and was thought in the same principles stated for SDH; the 
most logical evolution would hence be to use the same PDUs and mechanisms as 
faithfully as possible with an adequate MPLS-TP encapsulation   
-MEF defined performance monitoring functions for frame loss measurement 
[FL], delay measurement, delay variation measurement, which are also addressed  
in Y.1731       

The main reason to use the same PDUs as in Y.1731 is probably the same i guess  
and respect     in RFC5654 2nd general requirements: economy. We can't though 
forget this       
requirement list will have impact on ITU standards and that, although much of   
the work in MPLS-TP is IETF's merit and sweat, probably no one would need it if 
ITU     
didn't start T-MPLS (whose interoperability problems with MPLS/IP were 
afterwards       
pointed out by IETF and originated all the work we can see now).        

I would also like to point out that the mechanisms in Y.1731 are sufficiently 
simple    
to allow some "hardwarization", which would ease more vendor's implementations 
to       
converge to the 50ms protection timescale, allowing a way to do this in a 
cheaper,      
more scalable and miniaturized way.     

Thank You for your time. Best Regards,  
Rui Costa       

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

Reply via email to