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

[[e-mail]]

Hello Huub,

Thank you for your remarks and please see my comments inline.




Huub van Helvoort <[e-mail]> 
2010/07/21 20:48
请答复 给
[e-mail]


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






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.

<Xiao Min> I know maybe you're expert of Y.1731, and I also studied Y.1731 
as well as throughput measurement several years ago.
IMHO there is no complete and efficient solution provided in this 
recommendation to execute throughput measurement based on MEP. Actually 
the idea of Y.1731 about how to measurement throughput is already 
reflected in section 4.10 last paragraph of this draft, but it's not 
recommended due to following three main reasons:
1. The measurement resolution can't be controlled. One fixed step length 
need to be provisioned before the measurement, the operator may not know 
the approximate bandwidth of the measured connection, which will result in 
difficulty for the operator to provision the appropriate step length.
2. The measurement time can't be controlled. Same consideration as the 
reason 1.
3. When the throughput estimatioin function is initiated at one MEP, I 
assume that the operator wanna obtain complete and accurate measurement 
results for every run at the initiator MEP if possible (i.e. return path 
exists). But IMO the Y.1731 didn't provide satisfying solution.

BTW, for the concern Curtis has raised, I consulted some hardware experts 
and was told that it's not a problem, because only counting but no other 
deep processing on test packets is needed in this draft.

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

<Xiao Min> Agreed. Already reflected in section 4 first paragraph.

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.

<Xiao Min> IMO we need to bear some complexity if we expect to achieve a 
new OAM function. For the comments you raised to improve this draft I'll 
consider them when updating this draft.

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

<Xiao Min> Hope my response and explanation above have replied your 
concern.

Best Regards, Huub.

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

Best Regards,
Xiao Min