Yaakov, See inline... -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Yaakov Stein Sent: zondag 11 oktober 2009 10:18 To: hhelvoort@xxxxxxxxxx; ietf@xxxxxxxx Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,>(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard 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. [mv] CCM supports at the moment Error Performance monitoring (15m/24h ES, SES, BBE, UAT); for this purpose it determines the status of the MEGs and the frame loss. It does this using the real data. 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. [mv] Connectivity is checked for the VLAN, i.e. for the transport entity. Frame loss is checked for all types of frame lengths, including large frames. [mv] It seems not be useful to me to have a pro-active check for "large frame frame loss"; if there would be a problem to transfer large frames that are smaller then the maximum frame size specified in the SLA for the service, then the frame loss measurement will detect that there is a continuous frame loss level and the operator or user can then run a dedicated on-demand ETH TST OAM sequence as specified in clasue 7.7/Y.1731 to confirm that there is a problem to transfer frames above a particular size and below the maximum frame size specified in the SLA. ------ 7.7 Ethernet test signal (ETH-Test) Ethernet test signal function (ETH-Test) is used to perform one-way on-demand in-service or out of-service diagnostics tests. This includes verifying bandwidth throughput, frame loss, bit errors, etc. When configured to perform such tests, a MEP inserts frames with ETH-Test information with specified throughput, frame size and transmission patterns. When out-of-service ETH-Test function is performed, client data traffic is disrupted in the diagnosed entity. The MEP configured for the out-of-service test transmits LCK frames, as described in clause 7.6, in the immediate client (sub-) layer. When an in-service ETH-Test function is performed, data traffic is not disrupted and the frames with ETH-Test information are transmitted in such a manner that a limited part of the service bandwidth is utilized. This rate of transmission for frames with ETH-Test information is pre determined for in-service ETH-Test function. ------ [mv] Frame delay and delay variation is not checked by means of CCM at the moment as the organisations active in SG13 and SG15 in Nov. 2005 did not support the requirement for such pro-active frame delay (variation) measurement. WD33/34/35 from Alcatel proposed such pro-active delay (variation) measurement (including a process proposal) in Nov. 2005. Also an on-demand frame delay process (see C543 and C544) was rejected in Jan 2006 by SG13. It would be simple to take this proposal and introduce DM function in CCM. [mv] On the other hand, work in Q.14/15 at the beginning of this year has introduced the ability to run periodic delay (variation) measurements and report the result as performance snapshots (refer to G.7710 and revision of G.8051). I.e. there is no requirement to run delay measurement with a high repetition rate. And in many deployments "synthetic frame" packet loss is desired. [mv] SG15 has responded to MEF on the issue of SLM/SLR ("synthetic frame loss measurement") OAM. There is an issue with such SLM/SLR approach, that seems to have been overlooked so far. This issue will be addressed in further detail later this week in a conf call. 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. [mv] CCM frames are required to run between MEPs, so these implementations comply with the Y.1731 and G.8021 standards. Ethernet Ring Protection is specified in G.8032 and requires that the section layer VLAN is monitored to trigger protection; again you have seen compliant behaviour. In addition, LBMs or TSTs have to be run occasionally to check that there are not problems with large packets. [mv] As long as there is no constant frame loss detected with CCM, there seems no need to run additional large packet frame loss checks pro-actively. Then for PM there is a whole array of other messages. [mv] For 15m/24h Error Performance Monitoring there is only the CCM. [mv] Note that LMM/LMR does not contribute to this 15m/24h error performance monitoring, it only is used when such pro-active error performance monitoring is not active (i.e. not part of the SLA) and the user complains about its performance. The operator or user itself can then run such on-demand frame loss detection and gets the result after a few seconds. I expect that you understand that this momentary frame loss status measureemnt is very different from the pro-active 15m/24h ES/SES/BBE/UAS and UAT performance reports. The MEF has been trying for over a year to reduce the number of different messages needed. [mv] It seems to me that the MEF did not understand the rationale for the Etherent OAM message set, otherwise it should not have been trying to do this. 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. [mv] There is in this respect no difference with e.g. SDH, ATM and OTN OAM. All those technologies have OAM running at multiple levels, which is a necessity to manage the transport entities in the different layer networks and in the different administrative domains. OTN OAM just got extended with an ODU Delay Measurement capability, available at the ODUk Path and ODUk Tandem Connection levels. That's what I meant by a nightmare. [mv] I don't see any nightmare I must admit... The ETH_FT function supports the same pro-active OAM processes as other termination functions. The ETHDe_FT function supports a number of on-demand OAM processes to help the localization of a fault or degradation. All very simple and straigthforward in my opinion... 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. [mv] I disagree with you. You completely ignore the differences in processing requirements associated with each OAM function. 1) CCM is a pro-active 1-way measurement tool to check continuity, connectivity, frame loss in both directions and remote defect status. Only a limited number of services require such pro-active status and performance monitoring. Most services (~70% according to some operators) are not pro-actively monitored. Of the pro-actively monitored services (~30%), only a subset requires error performance monitoring; most just require status monitoring to reduce repair time. Any pro-active OAM must be lightweight to minimise complexity of its implementation. 2) If CCM is not active, an operator or user may occasionally run an on-demand test: - LBM/LBR to check momentary VLAN connectivity - LTM/LTR to check momentary status of a unicast or multicast fitlering rule within the VLAN - LMM/LMR to check momentary frame loss - DMM/DMR to check momentary frame delay (variation) - LBM/LBR with data TLV or TST to check 2-way or 1-way throughput, or transfer capability of frames with a particular frame size, or introduction of payload bit errors 3) If CCM is active and caused detection of a continuity or frame loss problem, then specific on-demand OAM tool can be run to perform faul localization. [mv] For the on-demand tests it does not matter if there is one frame which supports all OAM functions, or if there are dedicated OAM frames per OAM function. Only one of those OAM fucntions will be active at a given time. If Q.5/13 would have decided to combine all on-demand OAM functions into a signle OAM frame, then you would have less OpCodes; but there would then be a number of SubOpCodes introdcued to identify which OAM function is active in the OAM frame. Regards, Maarten Y(J)S -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Huub van Helvoort Sent: Saturday, October 10, 2009 23:15 To: ietf@xxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf