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

["BUSI, ITALO (ITALO)" <[e-mail]>]

Xiao Min,

I have the feeling that the issue is more related to the terminology than technical.

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.

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.

Note also that this is the only way you can 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.

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.

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

________________________________
Da: [e-mail] [mailto:[e-mail]]
Inviato: martedì 5 ottobre 2010 4.38
A: BUSI, ITALO (ITALO)
Cc: MPLS-TP ad hoc team; Loa Andersson; [e-mail]; [e-mail]; [e-mail]
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)" <[e-mail]>

2010/10/02 23:23

收件人
"[e-mail]" <[e-mail]>, Loa Andersson <[e-mail]>
抄送
"[e-mail]" <[e-mail]>, MPLS-TP ad hoc team <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
主题
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: [e-mail] [mailto:[e-mail]] Per conto di [e-mail]
Inviato: lunedì 27 settembre 2010 3.36
A: Loa Andersson
Cc: [e-mail]; MPLS-TP ad hoc team; [e-mail]; [e-mail]
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 <[e-mail]>
发件人:  [e-mail]

2010/09/23 20:02

收件人
"[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, MPLS-TP ad hoc team <[e-mail]>
抄送

主题
[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: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                            [phone]
_______________________________________________
mpls-tp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-tp