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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]