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

[[e-mail]]

Dear Curtis,

Please let me try to summarize your comment on this draft:
Due to the hardware limitation of processing the test packets that are 
encapsulated as OAM packets in this draft, you oppose this draft is 
accepted as a WG item, and even more, you suggest to remove the function 
of throughput measurement from the OAM framework (maybe also from OAM 
requirements [RFC5860]?).
Do I misunderstand your opinion?

My response to your viewpoint is as follow:
1. I think the reason you oppose this draft is a topic that can be 
discussed far and wide, and actually I agree with you to some extent. But 
as Manuel Paul has pointed out, the notion  that the test packets are 
encapsulated as OAM packets is introduced from Ethernet OAM (ITU-T Y.1731) 
several years ago, so I think we need to hear some comments from other 
hardware experts.
2. I think the reason you oppose this draft can't support your proposal to 
remove the throughput measurement from MPLS-TP OAM functions. To my 
understanding, your comment only affect the test packet format defined in 
section 3.2 of this draft, and will not block the adoption of throughput 
measurement as an OAM function, also will not block other parts of this 
draft IMO, unless you can raise other compellent reasons.

Best Regards,
Xiao Min




Curtis Villamizar <[e-mail]> 
发件人:  [e-mail]
2010-07-14 20:20
请答复 给
[e-mail]


收件人
[e-mail]
抄送
MPLS TP <[e-mail]>
主题
Re: [mpls-tp] New ID draft-xiao-mpls-tp-throughput-estimation-00







In message 
<[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).

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.

Curtis