Subject: [Time] OAM Initiative: Situation

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Sep 2014 10:01:13 +0200

Dear all,

[Let us call this "OAM Inititiave" for now, as the mailing list is being 
renamed from TIME to LIME]

During the last IETF meeting, there were various discussions with 
different audiences regarding OAM.

Here is what we concluded:
1. Building an OAM generic protocol is impractical for multiple reasons.
2. It is desirable to have an unified view of OAM information at each 
layer, in order to correlate information, and detect the faulty element 
in the network path
3.. Consistent configuration, reporting, and presentation for the OAM 
mechanisms makes sense.
4. Using YANG as a modeling language is a logical choice. Note that 
there are already some efforts in that direction
5. A set of guidelines for future OAM developments would be welcome for 
consistency sake

We also believe that there is sufficient interest to start working on a 
charter proposal.

Regards, Joel and Benoit (OPS ADs)

·We should preserve the existing OAM technology implementations and 
behavior "on-the-wire"

·We will propose a unified management interface for multiple OAM 
technologies that will expose a common set of management interface 
capabilities for different OAM technologies (e.g. ping, traceroute)

·The management interface implementation will convert the defined common 
management capabilities to the OAM technology specific operations

·We will model OAM operations management using YANG following

·Specific OAM technology models will augment the generic OAM management 
model

·Cisco will support continued development of technology specific OAM 
standards within the appropriate IETF technology working groups

·We will promote generic OAM in the IETF OPS Working Group

·We will propose a set of guidelines new OAM technology implementations 
should follow

·We will investigate methods for scaling the return of large volumes of 
OAM data from the network

---

From: Tom Taylor <[email-masked]>
Date: Mon, 08 Sep 2014 11:36:37 -0400

It seems to me, taking Melinda's remarks into account, that the one work 
item missing from this announcement is the means whereby management is 
tied together along a path. The original TIME/LIME proposal spoke in 
terms of discovery by a centralized management application. Melinda 
suggests path-coupled management messages, possibly intercepted by 
management modules in varying sorts of devices along that path. Would 
this be an appropriate item of exploration within the charter?

Tom Taylor

> Regards, Joel and Benoit (OPS ADs)
...

---

From: Qin Wu <[email-masked]>
Date: Tue, 9 Sep 2014 03:33:22 +0000

Thank Benoit and Joel for the update of the current status.
“OAM initiative” is a good name, I think.
It remind me IESG/IAB arranged a Joint Design Session on Forwarding Plane OAM
Before to discuss tunneled forwarding plane OAM,
http://www.ietf.org/mail-archive/web/oam/current/msg00037.html

However the scope of this design session is limited to the forwarding plane. Proposals concerning
On control/management plane was not touched.

Even this, some of their proposal matches what we proposed in the PS draft right now, .e.g.,
In draft-bonica-oam-considerations-00, it said:
“
The API should insulate the user application from the following
   details:

      - The procedure that the OAM mechanism employed to obtain OAM
      information

      - Whether the OAM mechanism is integrated into the lower layer
      protocol

”
Regards!
-Qin
发件人: Time [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年9月8日 16:01
收件人: [email-masked]
抄送: [email-masked]
主题: [Time] OAM Initiative: Situation

Dear all,

[Let us call this "OAM Inititiave" for now, as the mailing list is being renamed from TIME to LIME]
During the last IETF meeting, there were various discussions with different audiences regarding OAM.

Here is what we concluded:
1. Building an OAM generic protocol is impractical for multiple reasons.
2. It is desirable to have an unified view of OAM information at each layer, in order to correlate information, and detect the faulty element in the network path
3.. Consistent configuration, reporting, and presentation for the OAM mechanisms makes sense.
4. Using YANG as a modeling language is a logical choice. Note that there are already some efforts in that direction
5. A set of guidelines for future OAM developments would be welcome for consistency sake
We also believe that there is sufficient interest to start working on a charter proposal.
Regards, Joel and Benoit (OPS ADs)

*         We should preserve the existing OAM technology implementations and behavior “on-the-wire”

*         We will propose a unified management interface for multiple OAM technologies that will expose a common set of management interface capabilities for different OAM technologies (e.g. ping, traceroute)

*         The management interface implementation will convert the defined common management capabilities to the OAM technology specific operations

*         We will model OAM operations management using YANG following

*         Specific OAM technology models will augment the generic OAM management model

*         Cisco will support continued development of technology specific OAM standards within the appropriate IETF technology working groups

*         We will promote generic OAM in the IETF OPS Working Group

*         We will propose a set of guidelines new OAM technology implementations should follow
*         We will investigate methods for scaling the return of large volumes of OAM data from the network

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Sep 2014 16:37:45 +0200

Hi Tom,

> It seems to me, taking Melinda's remarks into account, that the one 
> work item missing from this announcement is the means whereby 
> management is tied together along a path. The original TIME/LIME 
> proposal spoke in terms of discovery by a centralized management 
> application. 
Exactly. Interesting that the problem statement changed along the time.
> Melinda suggests path-coupled management messages, possibly 
> intercepted by management modules in varying sorts of devices along 
> that path. Would this be an appropriate item of exploration within the 
> charter?
This point was not discussed in details during the last meeting. Let's 
keep in mind that there were no BoF but two quick presentations in 
OPSAWG and the Routing Area.
My point is: shouldn't we start by walking before running, i.e. focusing 
first on consistent configuration, reporting, and presentation for the 
centralized management?

Regards, Benoit
> .

---

From: Tom Taylor <[email-masked]>
Date: Tue, 09 Sep 2014 22:33:56 -0400

> Exactly. Interesting that the problem statement changed along the time.

[PTT] Personally, I'd be happy to go with discovery by a centralized 
management application as the objective.

>> that path. Would this be an appropriate item of exploration within the

[PTT] I had not intended to focus on Melinda's proposal in my note, but 
on the whole topic of discovery. In any event, I can see where discovery 
can be carved off, though it has to be done eventually.

> first on consistent configuration, reporting, and presentation for the

[PTT] Yes, this has clear priority given that there may be related work 
in progress already.

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Sep 2014 02:03:33 +0000

I agree, we should focus on consistent configuration, reporting and presentation for the centralized management at the first step,
But how?
I think we should use YANG Language to provide consistent presentation if we can model all the technology specific OAM in the same way

To provide consistent reporting, we can stitch OAM at different layer in the management platform, we can allow OAM test and reporting work together,
One of example, we can allow test(e.g.,ping) can be initiated from centralized management, centralized management can convert test into technology specific operation(e.g., IP ping),
And then in-band mechanism can be activated in the data plane, when test results return, the test results can be reported to centralized management through unified management interface.
Another example, if the path can be divided into two segment and centralized management can stitch two segment together, when the same fault is detected by segment A and segment B,
And segment A and segment B report the same fault to the centralized management, centralized management should the same fault is detected by two segments.

To provide consistent configuration, we need to figure out how to install and configure, activate various OAM functions at the different layer in the same way,
Model all the OAM information in the same way using YANG is a good way, also we need to figure out how to convert common OAM information to technology specific configuration.

Regards!
-Qin
-----邮件原件-----
发件人: Time [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年9月9日 22:38
收件人: Tom Taylor; [email-masked]
主题: Re: [Time] OAM Initiative: Situation - Sketch of a charter

Hi Tom,

> that path. Would this be an appropriate item of exploration within the 
This point was not discussed in details during the last meeting. Let's keep in mind that there were no BoF but two quick presentations in OPSAWG and the Routing Area.
My point is: shouldn't we start by walking before running, i.e. focusing first on consistent configuration, reporting, and presentation for the centralized management?

Regards, Benoit
>> layer, in order to correlate information, and detect the faulty 
>> element in the network path 3.. Consistent configuration, reporting, 
>> and presentation for the OAM mechanisms makes sense.
>> there are already some efforts in that direction 5. A set of 
>> guidelines for future OAM developments would be welcome for 
>> consistency sake
>>

_______________________________________________
Time mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/time