Re: [Time] OAM Initiative: Situation - Sketch of a charter

[Tom Taylor <[e-mail]>]

On 09/09/2014 10:37 AM, Benoit Claise wrote:
> 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.

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

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

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

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

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

>
> Regards, Benoit
>>
>> Tom Taylor
>>
>> On 08/09/2014 4:01 AM, Benoit Claise wrote:
>>> 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)
>>>
>> ...
>> .
>>
>
>