Yaakov,
See inline...
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Yaakov Stein
Sent: zondag 11 oktober 2009 10:18
To: hhelvoort(_at_)huawei(_dot_)com; ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Huub
van Helvoort
Sent: Saturday, October 10, 2009 23:15
To: ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf