Rui,
While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP,
and quite understanding the reasoning behind reusing existing formats,
I am puzzled by two of your statements.
First, that Y.1731 CCMs "would ease more vendor's implementations to
converge to the 50ms protection timescale".
One of the major problems with Y.1731 is the lack of a 100 packet per second
rate, forcing the use of 300 packets per second at high resource cost.
I feel that 50 ms protection requirements are the best reason NOT to use Y.1731.
Second, "that the mechanisms in Y.1731 are sufficiently simple
to allow some "hardwarization".
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.
If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat
format).
Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own),
packet loss measurement, and delay measurement, it becomes a nightmare.
Y(J)S
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Rui Costa
Sent: Monday, October 05, 2009 11:27
To: ietf(_at_)ietf(_dot_)org
Cc: Adrian Farrel
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard
SDH and EoSDH networks are widely used by Portugal Telecom Comunicacoes
(PTC) and TMN (respectively the incumbent operator in Portugal and PT
group's mobile operator), as well as foreign PT's clients (Brazilian "Vivo",
for instance). These operators are used to both SDH and Ethernet's OAM
paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST
allow equivalent OAM mechanisms.
Being more precise, we would like to use the same protocol messages, to
give/have
the same "touch&feel" we had in SDH and for less time in ETH.
In SDH...
-it allows you at each end to check you have signal reception and notify the
other end when you don't (RDI)
-it does so at different levels (in SDH you can have it both for each VC and
for the STM)
-it has a means by which to exchange an APS protocol
In ETH...
-we've been using Y.1731 in EoSDH systems; it was the ITU standard developed
for this purpose and was thought in the same principles stated for SDH; the
most logical evolution would hence be to use the same PDUs and mechanisms as
faithfully as possible with an adequate MPLS-TP encapsulation
-MEF defined performance monitoring functions for frame loss measurement
[FL], delay measurement, delay variation measurement, which are also addressed
in Y.1731
The main reason to use the same PDUs as in Y.1731 is probably the same i guess
and respect in RFC5654 2nd general requirements: economy. We can't though
forget this
requirement list will have impact on ITU standards and that, although much of
the work in MPLS-TP is IETF's merit and sweat, probably no one would need it if
ITU
didn't start T-MPLS (whose interoperability problems with MPLS/IP were
afterwards
pointed out by IETF and originated all the work we can see now).
I would also like to point out that the mechanisms in Y.1731 are sufficiently
simple
to allow some "hardwarization", which would ease more vendor's implementations
to
converge to the 50ms protection timescale, allowing a way to do this in a
cheaper,
more scalable and miniaturized way.
Thank You for your time. Best Regards,
Rui Costa
_______________________________________________
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