RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,> (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

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

 



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-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

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