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

[Huub van Helvoort <[e-mail]>]

Hello Xiao,

See my remarks in-line [hvh]

You wrote:

> 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.

[hvh] I am not a 100% HW expert, but I know a lot about Y.1731.

This recommendation provides two OAM functions to test
throughput, using unicast loopback LBM/LBR (section 7.2.1.1) and
using TST (section 7.1.1).
By varying the transmission period and/or the size (of the test TLV)
the througput can be estimated. They contain sequence numbers
so the limit of the throughput is reached when packets are dropped,
i.e. sequence numbers are missing.

It is recommended to perform this test out-of-service by administrative
locking (LCK function) of the connection. See RFC 2544.

In your draft you propose to add an OAM function that controls
(start/stop) the throughput test. This makes the operation more complex,
because the equipment now have to look for this additional OAM function
while performing the test. You need also to specify what happens if
the periodicity of these frames is wrong, and cases where start or
stop is not received.

> 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.

[hvh] you have to separate the throughput measurement procedure,
i.e. how to prepare for the test, provision the OAM functions, interpret
the data provided by the OAM functions, and finalise the test, from
the actual used OAM functions, i.e LBM/LBR and TST.
Then it will be more clear what can be done in HW and what not.

Best Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...