ietf
[Top] [All Lists]

RE: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

2011-10-16 04:46:16
In transport networks we *never* have peer-2-peer OAM interworking.
If it was required it would have explicitly been mentioned in
the MPLS-TP requirements RFC.

Indeed, to have any peer to peer OAM simply removes the ability of the OAM to 
do its job.

Neither of these statements is completely accurate.

For example, the ITU produced Y.1712 that details the peer-peer interworking 
of ATM OAM per I.610 with the MPLS OAM described in Y.171.

I think that the accurate statement is that OAM interworking is perhaps 
undesirable
but trivial when the OAM semantics matches so that the interworking is 
syntactic translation,
but very challenging (and perhaps sometimes impossible) when the semantics are 
different.
(For "semantics to be different" it is enough for timer values to be different,
 let alone different fault states.)

However, there are many cases where several OAM types co-exist in a single 
deployment.
Perhaps the most relevant case is the widespread use of both EFM OAM (802.3 
Section 57) with Y.1731 OAM.

Y(J)S
 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>