Re: [Lime-oam-model] Design Team report

[Qin Wu <[e-mail]>]

Based on RFC7276,IP OAM is not primarily used for performance measurement.
RFC7276 Table 4 summarizes the OAM functions that are supported in each of
the OAM toolsets.
Toolset support one or several of these OAM functions including CC, CV, path discovery, performance measurement, other function.
Take IP OAM as example, CC can be supported by IP Ping Toolset using Echo request/reply messages and path discovery can be supported
By IP Traceroute toolset using Traceroute.

-Qin
-----邮件原件-----
发件人: Tom Taylor [mailto:[e-mail]] 
发送时间: 2015年3月20日 4:22
收件人: Gregory Mirsky; Qin Wu; Ronald Bonica; [e-mail]
抄送: Deepak Kumar (dekumar)
主题: Re: [Lime-oam-model] Design Team report

The bottom line is this:
  -- what service does the IP layer provide? (Datagram service, of course, with no guarantees of ordering or delivery.)
  -- what are the observable defects in that service? I'd say loss, delay, and maybe jitter (or is that a transport-level (L4) defect?) beyond expected levels.
  -- what management tools do we need to detect these defects? To localize them? Do they fall into the alphabet soup of operations Qin is so keen on?

Obviously, ping and traceroute are the prime IP-level working tools. But I wouldn't call ping a matter of Connectivity Check except in the grossest sense. It's not normally a matter of 0% loss vs. 100% loss, but loss exceeding, say, 5%. You would have to redefine connectivity failure to mean "loss above expected level" to make ping fit into that framework. In the absence of such a definition, I would say that Connectivity Check has limited usefulness at the IP level. Connectivity Verification is, of course, totally irrelevant. One can think of some aspects of ICMP as Backward Defect Indication (e.g., Destination Unreachable).

Ping can certainly be seen as a performance measurement tool, for both delay and loss. And both ping and traceroute effectively use loopback.

Linktrace is a recurring issue, assuming it means tracing the exact path taken by packets. The ECMP problem was noted in the problem statement. 
IP OAM is missing a tool for that.

My conclusion is that IP OAM is implemented within limits. Performance measurement is the primary means to detect defects at the IP level. As a result, I don't quite agree with the entries in the IP column of Greg's table (in his message received at the IETF Tue,  3 Feb 2015 17:22:29
-0800 (PST)). Specifically, the Continuity Check items have to be qualified (Note 1), Connectivity Verification has to be a "No", there should be a qualified "Yes" for Backward Defect Indication (Note 2), and the Loss of Continuity Defect "Yes" should be qualified (Note 1 again).

Note 1: for IP OAM, "loss of continuity" is redefined to be an observed packet loss rate higher than the expected/engineered level for a duration of x seconds.

Note 2: some ICMP messages (e.g., Destination unreachable) can be interpreted as Backward Defect Indication.

Tom Taylor





On 19/03/2015 11:22 AM, Gregory Mirsky wrote:
> Hi Qin,
>
> I’m not aware of “IP for VPN” whether OAM or network. I believe 
> there’s IP regardless it is overlay or not. And the draft you’re 
> supporting so strongly does not apply to IP OAM.
>
>                  Regards,
>
>                                  Greg
>
...