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

From: Rui Costa <[email-masked]>
Date: Mon, 5 Oct 2009 10:26:46 +0100

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

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 8 Oct 2009 08:43:09 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: Monday, October 05, 2009 11:27
To: [email-masked]
Cc: Adrian Farrel
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

In SDH...	

In ETH...	

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Francesco Fondelli <[email-masked]>
Date: Thu, 8 Oct 2009 09:32:35 +0200

> Rui,

Hi all,

> rate, forcing the use of 300 packets per second at high resource cost.

hemm

--- T-REC-Y.1731-200802 ---
7.1.1 CCM (with ETH-CC information) Transmission
When ETH-CC is enabled, a MEP periodically transmits CCM frames as
often as the configured transmission period. Transmission period
can be one of the following seven values:
- 3.33ms: default transmission period for protection switching
  application (transmission rate of 300 frames/second)
- 10ms: (transmission rate is 100 frames/second)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---

Even if I'm not a big fan of it I have to say that
100 pps is foressen by Y.1731 (and even by your ID,
http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03, Section 4.1.1)

[cut]

> Y(J)S

Ciao
FF

---

From: Rui Costa <[email-masked]>
Date: Thu, 8 Oct 2009 08:46:20 +0100

Hello Yaakov,	

1. [YS]	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	

[RC] I don't understand your 1st claim. Would you be so kind as to detail it to me a bit?	In Y.1731,	
7.1.1 CCM (with ETH-CC information) Transmission	
[...]	
* 10ms: (transmission rate is 100 frames/second)
[...]	
Table 9-3 - CCM Period Values	
[...]	
Might you be referring to G.8031's "11.2.4 Transmission and acceptance of APS"? If so, isn't it true that it isn't Y.1731 that creates this but G.8031 or another standard imposing that to G.8031? Besides... Is it really imposing? I think having seen words like "desirable" or "should" there...	
[Thank you, Francesco]	

2. [YS] The other main fault with Y.1731 is its fracturing [...] among so many different OAM message types,	
[...] 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.	

[RC] And isn't CCM simplicity a worthy characteristic... The main characteristic? In SDH, the CPU gets an alarm from HW. If you could have a simple means, easily implemented in HW to give firmware the same interface, then you wouldn't need burdening uPs with extra assembling/disassembling PDUs, right? Or you would, if that was your preferred modus operandi. You could choose.	
As for your other concerns: in principle, i wouldn't oppose adding Y.1731 PDUs that could integrate several functions, if those were integrated in Y.1731 philosophy and accepted by other ITU members. However, that was proposed recently and is still under discussion, whereas we have to take a decision now.	

Thank you for your time. Best Regards,	
Rui

-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: quinta-feira, 8 de Outubro de 2009 9:33
To: Yaakov Stein
Cc: Rui Costa; [email-masked]; Adrian Farrel
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

Hi all,

hemm

--- T-REC-Y.1731-200802 ---

[cut]

Ciao
FF

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: quinta-feira, 8 de Outubro de 2009 8:43
To: Rui Costa; [email-masked]
Cc: Adrian Farrel
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

Rui, 

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: Monday, October 05, 2009 11:27
To: [email-masked]
Cc: Adrian Farrel
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

In SDH...	

In ETH...

---

From: Yaakov Stein <[email-masked]>
Date: Sat, 10 Oct 2009 19:36:35 +0200

Francesco, 

Thanks for pointing out to me how poor my memory has become.

For some reason I remembered 3, 30, and 300 per second,
instead of 10, 100, and 300 per second.

I rescind my first comment,
but stand by my second one.

Y(J)S

-----Original Message-----
From: Francesco Fondelli [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 09:33
To: Yaakov Stein
Cc: Rui Costa; [email-masked]; Adrian Farrel
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

Hi all,

hemm

--- T-REC-Y.1731-200802 ---

[cut]

Ciao
FF