Huub I strongly disagree with some of your statements, although some of the difference may be semantic.
CCM indeed supports CC and CV, but the only real PM function it support is live PLR, by virtue of the counters. One and two way delay and variation are not supported (because there is no option to put timestamps in the CCM PDU), nor does it support the data TLV to check loss of connectivity of large frames. And in many deployments "synthetic frame" packet loss is desired. In practice (and I am talking about many dozens of deployments in which we have been involved), I have encountered CCs between each pair of MEPs, and separate CCs (running at 300 per second) in a separate VLAN for ring protection when applicable. In addition, LBMs or TSTs have to be run occasionally to check that there are not problems with large packets. Then for PM there is a whole array of other messages. The MEF has been trying for over a year to reduce the number of different messages needed. Of course, this is all for one level of OAM. There are additionally Y.1731 frames running and higher and lower levels. And in many cases there are also EFM OAM frames at the edges. That's what I meant by a nightmare. Had the CCMs had (as I originally suggested in Q5/13) optional timestamps (at the front with the TLV offset indicating their presence) and data TLVs to control the length, we would have reduced all 1-way functionality to a single message. Y(J)S -----Original Message----- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: Saturday, October 10, 2009 23:15 To: ietf@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,> (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard Hello Yaacov, You wrote: > I rescind my first comment, > but stand by my second one. This was your second, with my comments [hvh] in-line: > Second, "that the mechanisms in Y.1731 are sufficiently > simple to allow some "hardwarization". [hvh] this HW already exists, as was mentioned at the IETF75 when draft-bhh-mpls-tp-oam-y1731 was discussed. > The other main fault with Y.1731 is its fracturing of > the capabilities among so many different OAM message types, > rather than realizing that there are really only two OAM types > (one way and reflecting), with options for various monitoring > or measurement functions. [hvh] a better way to divide the messages is by "pro-active" and "on-demand". The set of pro-active should be as small as possible and combine different capabilities as much as possible. > If you only need CCMs, yes Y.1731 is easy (but so is any other > heartbeat format). [hvh] note that CCM supports CC + CV (for signal fail detection) + PM (for signal degrade detection) + fault reporting (RDI) in a single message. There are only two more pro-active messages: AIS and LCK and only one of CCM, AIS and LCK will be active at the same time. > Once you want to do CCs, CCs for protection (G.8031/G.8032 > require their own), [hvh] NO. CCM is used to trigger protection, 1+1 linear protection does not need additional messages, 1:1 and ring protection require a message to synchronise the status of the nodes involved in the protection. This would be the only message that can be active at the same time as CCM, however only on the protection channel. > packet loss measurement, and delay measurement, it becomes > a nightmare. [hvh] I disagree, these are message used only on-demand and they will not be active at the same time. Only five are currently defined: LB. LT, LM, DM, 1DM. Regards, Huub. -- ================================================================ Always remember that you are unique...just like everyone else... _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
