Re: [mpls] R: R: [mpls-tp] wg last call reslution in on mpls-tp-oam framework

Italo,

Please see inline comments.

"BUSI, ITALO (ITALO)" <italo.busi@alcatel-lucent.com> 
2010/10/06 02:21

收件人
"xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
抄送
MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int>, Loa Andersson <loa@pi.nu>, 
"mpls@ietf.org" <mpls@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, 
"mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>
主题
R: R: [mpls-tp] wg last call reslution in on mpls-tp-oam framework

Xiao Min,

I have the feeling that the issue is more related to the terminology than 
technical.
<XiaoMin> I think this issue is more a technical issue.

Let me try to explain.

The two-way test is defined in such a way that the local MEP source in 
node A originates test packets; the remote MEP in node Z loopbacks them 
back to A and then the local MEP sink in node A performs the calculation.
<XiaoMin> IMHO the two-way test needs to be redefined if we find the 
original definition has explicit shortage.

As you correctly pointed out in the previous WG LC, this way of estimating 
throughput is only testing the minumum of the available throughput in the 
two directions. However, as this is common practise, we have kept this 
mode in the draft and described this issue.
<XiaoMin> AFAIK this is not a common practice and not widely deployed. 
Actually IMO we are trying to make a new toolkit of MPLS-TP OAM function 
and we can improve the existing description if needed.

Note also that this is the only way you can estimate throughput using a 
data plane loopback function.
<XiaoMin> I don't understand why we must estimate throughput using a data 
plane loopback function.

The one-way test is defined in such a way that the local MEP sink in node 
A originates test packets and the remote MEP sink in node Z performs the 
calculation of the throughput in the A->Z direction.
<XiaoMin> Also I don't agree on the described way in which one-way test is 
defined, reasons as follows:
1. The throughput can't be measured by one run of sending test traffic in 
almost all cases, the OAM message communication between node A and node Z 
is inevitable.
2. It would be better to let the MEP in node A perform the calculation, 
which makes the operator more easy to obtain the throughput result, just 
like packet loss measurement.

In the previous WG LC, you were correct in asking for a solution able to 
estimate the throughput of the two directions of a bidirectional transport 
path. In order to address this issue, we have clarified that this can be 
achieved by running two one-way tests in parallel:

1) one session where the local MEP source in node A originates test packet 
and remote MEP sink in node Z performs the calculation of the throughput 
in the A->Z direction;

2) another session where the remote MEP source in node Z originates test 
packets and local MEP sink in node A performs the calculation of the 
throughput in the Z->A direction.
<XiaoMin> The work-around that runs two one-way tests in parallel is an 
option but IMHO not a good option, because it takes the operator too much 
provisions, could you please take a little time to have a read on 
draft-xiao-mpls-tp-throughput-estimation and that draft provides another 
way to estimate the throughput of the two directions of a bidirectional 
transport path.

That's was the intent of the quoted text:
"
“ 
In order to estimate the throughput of each direction uniquely, two 
one-way throughput estimation sessions have to be setup. 
“ 
"

Therefore, I do not see any technical concerns with the text in the draft: 
in my opinion, all the tools needed to measure whatever you want are 
described there.

Did I miss something?

Thanks, Italo

Best Regards,
Xiao Min
Da: xiao.min2@zte.com.cn [mailto:xiao.min2@zte.com.cn] 
Inviato: martedì 5 ottobre 2010 4.38
A: BUSI, ITALO (ITALO)
Cc: MPLS-TP ad hoc team; Loa Andersson; mpls@ietf.org; mpls-tp@ietf.org; 
mpls-tp-bounces@ietf.org
Oggetto: Re: R: [mpls-tp] wg last call reslution in on mpls-tp-oam 
framework

Hello Italo, 

Firstly I want to clarify that my comment didn't suggest to remove the 
two-way mode. 
Secondly could you please explain why you have to restrict the two-way 
mode as estimating the minimum throughput of the two directions and where 
is the requirement? 
Thirdly my comment suggested to allow two-way mode to estimate two 
individual available throughputs of the two directions, could you let me 
know what's the defects of this suggestion? 

Best Regards, 
Xiao Min 

"BUSI, ITALO (ITALO)" <italo.busi@alcatel-lucent.com> 
2010/10/02 23:23 

收件人
"xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>, Loa Andersson <loa@pi.nu> 
抄送
"mpls@ietf.org" <mpls@ietf.org>, MPLS-TP ad hoc team 
<ahmpls-tp@lists.itu.int>, "mpls-tp-bounces@ietf.org" 
<mpls-tp-bounces@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org> 
主题
R: [mpls-tp] wg last call reslution in on mpls-tp-oam framework

Xiao Min, 

Both one‑way and two‑way modes are common practice. 

We therefore do not think we need to remove the two-way mode. 

The two-way mode by definition estimates the minimum throughput of the two 
directions. 

We understand that you are interested in getting the two individual 
available throughputs of the two directions. To address your point, we 
have clarified that: 
“ 
In order to estimate the throughput of each direction uniquely, two 
one-way throughput estimation sessions have to be setup. 
“ 

Italo 

Da: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] Per conto 
di xiao.min2@zte.com.cn
Inviato: lunedì 27 settembre 2010 3.36
A: Loa Andersson
Cc: mpls@ietf.org; MPLS-TP ad hoc team; mpls-tp-bounces@ietf.org; 
mpls-tp@ietf.org
Oggetto: Re: [mpls-tp] wg last call reslution in on mpls-tp-oam framework 

Resend following comment without attachments. 
============================================= 

Loa and all, 

I don't agree with the resolution on my comment 6 in the attached word 
document. 

Cited words start====== 
6. In "section 6.3.1" the fifth paragraph, wrt the defined two-way 
throughput estimation which can only return the minimum of available 
throughput of the two directions, I'm not sure about the need from SP. 
Instead, to my understanding it's preferred to define two-way throughput 
estimation as a function which can return two individual available 
throughput of the two directioins, just as packet loss measurement. 

Resolution: A note was added clarifying that two-way throughput estimation 
can only evaluate the minimum of available throughput of the two 
directions. In order to estimate the throughput in both directions, two 
one-way throughput estimation sessions have to be setup. 
Cited words end======= 

My comment intended to change the definition of two-way throughput 
estimation, at least not restrict it with the way that only evaluate the 
minimum of available throughput of the two directions, because I think 
that's unreasonable and I can't see the need for this kind of two-way 
throughput estimation from SP. 

Best Regards, 
Xiao Min 

Loa Andersson <loa@pi.nu> 
发件人:  mpls-tp-bounces@ietf.org 
2010/09/23 20:02 

收件人
"mpls-tp@ietf.org" <mpls-tp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, 
MPLS-TP ad hoc team <ahmpls-tp@lists.itu.int> 
抄送

主题
[mpls-tp] wg last call reslution in on mpls-tp-oam framework

All,

the editors of the mpls-tp-oam-framework has sent us these two
word documents to describe how the outstanding wg lc comments has
been resolved.

/Loa

-- 

Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                            +46 767 72 92 13
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp 