Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00

[<[e-mail]>]

Dear Curtis,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Curtis Villamizar
> Sent: Wednesday, July 14, 2010 2:20 PM
> To: [e-mail]
> Cc: MPLS TP
> Subject: Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00
> 
> 
> In message <OF3C67F8EE.D74D19A5-ON4825774C.003FA57C-
> [e-mail]>
> [e-mail] writes:
> >
> > A new Internet Draft titled "Throughput Estimation for MPLS Transport
> > Profile" has been submitted after the 77th meeting:
> >
> > http://tools.ietf.org/html/draft-xiao-mpls-tp-throughput-estimation-00
> 
> 
> Processing of ACH will typically take a slower path than forwarding of
> MPLS labeled traffic.  Any measurement based on rate of processing OAM
> traffic will therefore be invalid for all such architectures.
> 
> For example, a typical ASIC today clocks at 450-600 MHz.  Packets at
> 150 mpps (100 Gb/s small Ethernet packets) have 3-4 clock cycles to be
> processed if parallelism or pipelining is not used.  Hardware to do
> this forwarding is more specialized than hardware to handle OAM, which
> may be a set of microcoded engines or may even be a route processor.
> 
> I am familiar with designs of a number of major router (LSR) vendors
> and quite a few independent silicon suppliers.  None that I know of
> process OAM at the same continuous rate as payload traffic.  This is
> true for even some of the very lower end merchant silicon handling
> only a few Gb/s (at least afaik, since I don't work in that space).
>

[MP:] If this is as you say, then I wonder how throughput measurement can be done using Ethernet OAM (Y.1731), which has been out in the world for quite a while?

> Therefore I think this draft should not be accepted as a WG item.
>
> IMO- The notion that OAM be used for throughput measurement should be
> removed from the OAM framework if that is still possible.

[MP:] I prefer to keep that important option.

> 
> Curtis


Thanks,
Manuel