Hello Yaakov,
You replied:
I strongly disagree with some of your statements,
[hvh] I think the disagreement is not as strong as you suggest.
although some of the difference may be semantic.
[hvh] right
CCM indeed supports CC and CV, but the only real PM function it support is live PLR,
by virtue of the counters.
[hvh] correct, and this is done to keep CCM lean and mean so processing
of CCM frames will cost least effort.
One and two way delay and variation are not supported
(because there is no option to put timestamps in the CCM PDU),
[hvh] correct, and the reason is that these measurements will be
made on-demand, if done pro-actively will require more
processing power.
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.
[hvh] In the ITU-T plenary of the last two weeks several liaisons
from MEF, Q17/12 and contributions proposed these, so I expect
Y.1731 will support these soon.
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,
[hvh] CCM can only run between MEPs.
and separate CCs (running at 300 per second) in a separate VLAN for ring
> protection when applicable.
[hvh] these run in a separate server layer between the MEPs on each link
between two adjacent ring nodes.
In addition, LBMs or TSTs have to be run occasionally to check that there
> are not problems with large packets.
[hvh] indeed, these are pro-active tools and the operator is warned
about the effect these tools may have on throughput.
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.
[hvh] each tool, on-demand and pro-active can be enabled/disabled by
the operator, so he is in full control of the effect that OAM
tools have on bandwidth utilisation.
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.
[hvh] indeed, that is the reason why CCM is kept lean and mean, at
300 packets per second, 64 bytes will require 155 kbit/s
That's what I meant by a nightmare.
[hvh] it will be less of a nightmare if the behaviour of the tools
is the same in each layer, from top to bottom.
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.
[hvh] with the possibility that the CCM message becomes larger
than 64 bytes, requiring more bandwidth, and the additional
functionality requires more processing power, so what you
propose will indeed be a nightmare.
Best regards, Huub.
-----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