Subject: [Lime] OAM Initiative: Situation

From: Benoit Claise <[email-masked]>
Date: Tue, 16 Sep 2014 12:58:12 +0200

Dear all,

LIME is a new mailing list, transitioning from TIME (in case you want to 
read the archives).
As one of the first email to the list, let me summarize the current 
situation.

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

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)

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Sep 2014 01:11:22 +0000

Hi, all

Based on ADs suggestion on the Charter proposal, we call for a design team to write the Charter proposal after a few internal discussions.

Here is the initial version of proposed charter for discussion on the list (See below or attached).

Layer Independent OAM Management in the Multi-Layer Environment (LIME)

------------------------------------------------------------------------------------------------------------------------------------------

Operations, Administration, and Maintenance (OAM) is a general term that refers to tools created for network management.  Quoting from RFC 6291:

    Examples of tools related to "operations" are performance monitoring

    tools used for service level agreement (SLA) measurement, fault

    management tools used to monitor the health of nodes and links in the

    network, and network provisioning tools.

    Examples of "administration" tools are network discovery and planning

    tools.

    Examples of "maintenance" tools are implementations of connectivity

    check, loopback, link trace, and other tools that can be used to

    monitor and diagnose failures in a network or network element.

An operator's network is made up of layers -- consisting of OSI layers 1 through 3 in the first instance, but made more complex by the emergence of network overlays such as NVO3 [reference]. Looking along a particular layer, a path may be made up of multiple segments of differing network technologies, such as MPLS at one point, IP at another.

Traditionally, fault management and path maintenance have been achieved through a series of technology and layer specific OAM protocols together with technology and layer specific management interfaces. The latter have been based on SNMP MIB modules developed independently without coordination between them and on proprietary interfaces for configuration. The limited scope of of each management interface has made it very difficult to:

-- suppress large numbers of unnecessary alarms and notifications

    related to defects and failures

-- quickly identify root causes

-- monitor performance on an end-to-end basis

-- correlate status defects, faults and network failures between the

    different layers to improve efficiency of defect and fault

    localization and provide better OAM visibility, since it has been necessary to navigate the peculiarities of each individual technology specific management interface at each layer, then try to bring the results together into a coherent picture.

There is now a move afoot to replace the SNMP MIB modules with YANG modules instead. YANG is more flexible and extensible than SMIv2, and can more safely be used for configuration as well as information retrieval. This movement to YANG opens up the possibility of modeling OAM operations management in a more uniform fashion and creating management interfaces that are more friendly to a centralized management function than the present set.

The objective of the LIME initiative is to encourage consistent configuration, reporting, and presentation for the OAM mechanisms used to manage the network, over all layers and technologies. It will do this by preparing a set of guidelines for future OAM developments as its initial task. These guidelines will cover OAM for all five FCAPS (fault, capacity, accounting, performance, security) management areas, and will not be limited to Layer 1-3 technologies but also consider management at higher OSI layers. Two initial cases will be considered:

(1) where the centralized management function communicates directly with the managed elements;

(2) where the centralized management function communicates with a local management function.

The first case takes priority.

Development of one or more management information models may be undertaken if it is seen as necessary to move the work forward.

Out of scope initially, but potentially within subsequent scope:

  -- development of any YANG modules.

  -- development of a solution for mutual discovery of the centralized management function and the managed elements or local managers.

Related work:

  -- ANIMA very interested in the mutual discovery aspect

  -- Metro Ethernet Forum work on ...

发件人: Lime [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年9月16日 18:58
收件人: [email-masked]
主题: [Lime] OAM Initiative: Situation

Dear all,

LIME is a new mailing list, transitioning from TIME (in case you want to read the archives).
As one of the first email to the list, let me summarize the current situation.
During the last IETF meeting, there were various discussions with different audiences regarding this OAM initiative.

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)

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Sep 2014 01:34:08 +0000

Hi, all

Based on ADs suggestion on the Charter proposal, we design team write a Charter proposal after a few internal discussions.

    tools.

Related work:

发件人: Lime [mailto:[email-masked]] 代表 Benoit Claise
发送时间: 2014年9月16日 18:58
收件人: [email-masked]<mailto:[email-masked]>
主题: [Lime] OAM Initiative: Situation

Dear all,

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 17 Sep 2014 11:54:49 +0000

I am interested in this work and glad to help.

See a few comments inserted.

Regards,

Dan

From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Wednesday, September 17, 2014 4:34 AM
To: Benoit Claise; [email-masked]
Cc: Tom Taylor
Subject: Re: [Lime] LIME Charter Propsosal v1

Hi, all

DR: actually 6291 does not provide such a definition of the ‘general term’.

    tools.

DR: We are in the IETF, so I would rather use the IETF terminology rather than the OSI one.

DR: SNMP is the protocol, better say SMI MIB modules. The move is however broader and different, as it tends to replace SNMP/SMI by NETCONF/YANG for configuration operations. It does not necessarily recommends using YANG for all purposes, and certainly not ‘replace MIB modules with YANG modules’. We need some more accurate wording.

DR: what exactly this prioritization means? (1) and when finished (2)? (1) in parallel with (2) but we estimate (2) will take longer time? As a suggestion and for better focus maybe it would be better to start with (1) and move (2) into the ‘out of scope initially’ category

Related work:

Dear all,

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Sep 2014 12:55:17 +0000

Hi, Dan:
Thanks for valuable comments, see my reply inline.

Regards!
-Qin
发件人: Lime [mailto:[email-masked]] 代表 Romascanu, Dan (Dan)
发送时间: 2014年9月17日 19:55
收件人: Qin Wu; Benoit Claise; [email-masked]
抄送: Tom Taylor
主题: Re: [Lime] LIME Charter Propsosal v1

Regards,

Dan

From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Wednesday, September 17, 2014 4:34 AM
To: Benoit Claise; [email-masked]<mailto:[email-masked]>
Cc: Tom Taylor
Subject: Re: [Lime] LIME Charter Propsosal v1

Hi, all

[Qin]: Correct, RFC6291 only provides a definition of the acronym “OAM”.

    tools.

[Qin]: Yes, I think we can refer to RFC 1122 for communication protocol layer or use link layer, network layer, service layer.

[Qin]:Agree.

DR: what exactly this prioritization means? (1) and when finished (2)? (1) in parallel with (2) but we estimate (2) will take longer time?

As a suggestion and for better focus maybe it would be better to start with (1) and move (2) into the ‘out of scope initially’ category

[Qin]: Yes, more interfaces need to be defined for (2). if the local management function is legacy function, it may more rely on future evolution of legacy device.

But (2) seems to me is a distributed architecture design which can provide a good scalability.

Related work:

Dear all,

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Sep 2014 13:18:38 +0000

发件人: Stewart Bryant [mailto:[email-masked]]
发送时间: 2014年9月17日 18:35
收件人: Qin Wu; Benoit Claise; [email-masked]
抄送: Gregory Mirsky; Pradeep Jain; Mishael Wexler; Jouni; [email-masked]; Sam Aldrin; Romascanu, Dan (Dan); Ravi Shekhar; Tom Taylor; Tom Herbert; [email-masked]; Daniel King
主题: Re: [Lime] LIME Charter Propsosal v1

On 17/09/2014 02:11, Qin Wu wrote:

Hi, all

SB> I volunteer to help.

SB> Regardless of RFC6291, network discovery is normally part of routing, or of an application layer broker.

SB> Surely the normal definition of admin is configuration?
[Qin]: Yes, I agree routing protocol or application protocol provide a good functionality for network discovery.
Also I agree configuration is a good example of administration. Before configuration, management function needs to know who needs to be configured and where it is.

configuration. The limited scope of of each management interface has made it very difficult to:

SB> of of (typo)

[Qin]: Thanks.

SB> Shouldn't the instantiation of these models in a particular protocol be explicitly out of scope?
Here is what we concluded:
1. Building an OAM generic protocol is impractical for multiple reasons.
SB> Agree
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
SB> Hopefully we can achieve this, but we need to be clear that this should not be a constraint on new protocols, i.e. if we miss something that a new protocol needs, then the model has to be improved.
[Qin]: Yes, if we can get generic OAM management model, generic model should not put constraint on new protocols, but generic model doesn’t need to changed each time there is something that a new protocol needs. What we can do is to define Specific OAM technology models that is augmented from  generic model i.e.,  Specific OAM technology model extends generic model to support technology specific feature.

SB> Yes, subject to (2)
SB> Agree
SB> Agree
- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Sep 2014 14:32:27 +0100

On 17/09/2014 14:18, Qin Wu wrote:
>
> *发 件人:*Stewart Bryant [mailto:[email-masked]]
> *发 送时间:*2014年9月17日18:35
> *收件人:*Qin Wu; Benoit Claise; [email-masked]
> *抄送:*Gregory Mirsky; Pradeep Jain; Mishael Wexler; Jouni;
> [email-masked]; Sam Aldrin; Romascanu, Dan (Dan); Ravi Shekhar;
> Tom Taylor; Tom Herbert; [email-masked]; Daniel King
> *主题:*Re: [Lime] LIME Charter Propsosal v1
>
>     Based on ADs suggestion on the Charter proposal, we call for a
>     design team to write the Charter proposal after a few internal
>     discussions.
>
>
> SB> I volunteer to help.
>
>
> SB> Regardless of RFC6291, network discovery is normally part of
> routing, or of an application layer broker.
>
>
> [Qin]: Yes, I agree routing protocol or application protocol provide a
> good functionality for network discovery.
>
> Also I agree configuration is a good example of administration. Before
> configuration, management function needs to know who needs to be
> configured and where it is.
>
Doesn't this come from a network management database, or in these modern
times the orchestrator.

Perhaps we need to go up a level and understand where on the spectrum of
full manual configuration to autonomic networking we are targeting the
discovery, and what is in and out of scope in a "traditional" network.

- Stewart
> layer, in order to correlate information, and detect the faulty
> element in the network path
>
> SB> Hopefully we can achieve this, but we need to be clear that this
> should not be a constraint on new protocols, i.e. if we miss something
> that a new protocol needs, then the model has to be improved.
>
> [Qin]: Yes, if we can get generic OAM management model, generic model
> should not put constraint on new protocols, but generic model doesn’t
> need to changed each time there is something that a new protocol
> needs. What we can do is to define Specific OAM technology models that
> is augmented from generic model i.e., Specific OAM technology model
> extends generic model to support technology specific feature.
>
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 17 Sep 2014 14:26:50 +0000

+1

From: Lime [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, September 17, 2014 7:55 AM
To: Qin Wu; Benoit Claise; [email-masked]
Cc: Tom Taylor
Subject: Re: [Lime] LIME Charter Propsosal v1

Regards,

Dan

Hi, all

    tools.

Related work:

Dear all,

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Sep 2014 17:50:30 -0400

I will be glad to be a part of the charter design team. 

Sue 

From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Tuesday, September 16, 2014 9:11 PM
To: Benoit Claise; [email-masked]
Cc: Gregory Mirsky; Pradeep Jain; Mishael Wexler; Jouni;
[email-masked]; Sam Aldrin; Romascanu, Dan (Dan); Ravi Shekhar; Tom
Taylor; Tom Herbert; [email-masked]; Daniel King
Subject: [Lime] LIME Charter Propsosal v1

Hi, all

Based on ADs suggestion on the Charter proposal, we call for a design team
to write the Charter proposal after a few internal discussions.

Here is the initial version of proposed charter for discussion on the list
(See below or attached).

----------------------------------------------------------------------------
--------------------------------------------------------------

Operations, Administration, and Maintenance (OAM) is a general term that
refers to tools created for network management.  Quoting from RFC 6291:

    tools.

An operator's network is made up of layers -- consisting of OSI layers 1
through 3 in the first instance, but made more complex by the emergence of
network overlays such as NVO3 [reference]. Looking along a particular layer,
a path may be made up of multiple segments of differing network
technologies, such as MPLS at one point, IP at another.

Traditionally, fault management and path maintenance have been achieved
through a series of technology and layer specific OAM protocols together
with technology and layer specific management interfaces. The latter have
been based on SNMP MIB modules developed independently without coordination
between them and on proprietary interfaces for configuration. The limited
scope of of each management interface has made it very difficult to:

    localization and provide better OAM visibility, since it has been
necessary to navigate the peculiarities of each individual technology
specific management interface at each layer, then try to bring the results
together into a coherent picture.

There is now a move afoot to replace the SNMP MIB modules with YANG modules
instead. YANG is more flexible and extensible than SMIv2, and can more
safely be used for configuration as well as information retrieval. This
movement to YANG opens up the possibility of modeling OAM operations
management in a more uniform fashion and creating management interfaces that
are more friendly to a centralized management function than the present set.

The objective of the LIME initiative is to encourage consistent
configuration, reporting, and presentation for the OAM mechanisms used to
manage the network, over all layers and technologies. It will do this by
preparing a set of guidelines for future OAM developments as its initial
task. These guidelines will cover OAM for all five FCAPS (fault, capacity,
accounting, performance, security) management areas, and will not be limited
to Layer 1-3 technologies but also consider management at higher OSI layers.
Two initial cases will be considered:

(1) where the centralized management function communicates directly with the
managed elements;

(2) where the centralized management function communicates with a local
management function.

Development of one or more management information models may be undertaken
if it is seen as necessary to move the work forward.

  -- development of a solution for mutual discovery of the centralized
management function and the managed elements or local managers.

Related work:

 

Dear all,

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

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Sep 2014 11:35:03 +0100

On 17/09/2014 02:11, Qin Wu wrote:
>
> Hi, all
>
> Based on ADs suggestion on the Charter proposal, we call for a design 
> team to write the Charter proposal after a few internal discussions.
>

SB> I volunteer to help.

configuration. The limited scope of of each management interface has 
made it very difficult to:

SB> of of (typo)

SB> Shouldn't the instantiation of these models in a particular protocol 
be explicitly out of scope?

SB> Agree

SB> Yes, subject to (2)

SB> Agree

SB> Agree

- Stewart

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Sep 2014 00:57:14 +0000

Thanks Sue, you are in.

Regards!
-Qin
发件人: Susan Hares [mailto:[email-masked]]
发送时间: 2014年9月18日 5:51
收件人: Qin Wu
抄送: [email-masked]
主题: RE: [Lime] LIME Charter Propsosal v1

Sue

Cc: Gregory Mirsky; Pradeep Jain; Mishael Wexler; Jouni; [email-masked]<mailto:[email-masked]>; Sam Aldrin; Romascanu, Dan (Dan); Ravi Shekhar; Tom Taylor; Tom Herbert; [email-masked]<mailto:[email-masked]>; Daniel King

Hi, all

    tools.

Related work:

Dear all,

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Sep 2014 05:18:50 +0300

Qin,

> team to write the Charter proposal after a few internal discussions.

I can give some review etc help here..

- Jouni

> through 3 in the first instance, but made more complex by the emergence 
> of network overlays such as NVO3 [reference]. Looking along a particular 
> layer, a path may be made up of multiple segments of differing network 
> with technology and layer specific management interfaces. The latter 
> have been based on SNMP MIB modules developed independently without 
> coordination between them and on proprietary interfaces for 
> specific management interface at each layer, then try to bring the 
> results together into a coherent picture.
> 
> There is now a move afoot to replace the SNMP MIB modules with YANG 
> modules instead. YANG is more flexible and extensible than SMIv2, and 
> can more safely be used for configuration as well as information 
> retrieval. This movement to YANG opens up the possibility of modeling 
> OAM operations management in a more uniform fashion and creating 
> management interfaces that are more friendly to a centralized management 
> function than the present set.
> 
> configuration, reporting, and presentation for the OAM mechanisms used 
> to manage the network, over all layers and technologies. It will do this 
> by preparing a set of guidelines for future OAM developments as its 
> initial task. These guidelines will cover OAM for all five FCAPS (fault, 
> capacity, accounting, performance, security) management areas, and will 
> not be limited to Layer 1-3 technologies but also consider management at 
> higher OSI layers. Two initial cases will be considered:
> 
> Development of one or more management information models may be 
> undertaken if it is seen as necessary to move the work forward.
> 
> *发件人:*Lime [mailto:[email-masked]] *代表 *Benoit Claise
> *发送时间:*2014年9月16日18:58
> *收件人:[email-masked]
> *主题:*[Lime] OAM Initiative: Situation
> 
> Dear all,
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Sep 2014 02:20:45 +0000

Thanks, Jouni, much appreciated.

Regards!
-Qin
-----邮件原件-----
发件人: Jouni Korhonen [mailto:[email-masked]] 
发送时间: 2014年9月18日 10:19
收件人: Qin Wu; Benoit Claise; [email-masked]
抄送: Tom Taylor; Daniel King; Romascanu, Dan (Dan); Mishael Wexler; Ravi Shekhar; Pradeep Jain; [email-masked]; Sam Aldrin; Tom Herbert; Gregory Mirsky; [email-masked]
主题: Re: LIME Charter Propsosal v1

Qin,

- Jouni

> ----------------------------------------------------------------------
> --------------------------------------------------------------------
> 
> Operations, Administration, and Maintenance (OAM) is a general term 
> that refers to tools created for network management.  Quoting from RFC 6291:
> 
> An operator's network is made up of layers -- consisting of OSI layers 
> 1 through 3 in the first instance, but made more complex by the 
> emergence of network overlays such as NVO3 [reference]. Looking along 
> a particular layer, a path may be made up of multiple segments of 
> differing network technologies, such as MPLS at one point, IP at another.
> 
> Traditionally, fault management and path maintenance have been 
> achieved through a series of technology and layer specific OAM 
> protocols together with technology and layer specific management 
> interfaces. The latter have been based on SNMP MIB modules developed 
> independently without coordination between them and on proprietary 
> interfaces for configuration. The limited scope of of each management 
> interface has made it very difficult to:
> 
> management interfaces that are more friendly to a centralized 
> management function than the present set.
> 
> to manage the network, over all layers and technologies. It will do 
> this by preparing a set of guidelines for future OAM developments as 
> its initial task. These guidelines will cover OAM for all five FCAPS 
> (fault, capacity, accounting, performance, security) management areas, 
> and will not be limited to Layer 1-3 technologies but also consider 
> management at higher OSI layers. Two initial cases will be considered:
> 
>    -- development of a solution for mutual discovery of the 
> centralized management function and the managed elements or local managers.
> 
> Related work:
> 
> 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
>

---

From: Yuji Tochio <[email-masked]>
Date: Thu, 18 Sep 2014 14:07:14 +0900

Hi Qin,

I appreciate your efforts and I am also interested in this work and glad to help.

A few editoral comments on the proposed charter.

- Second sentence in 3rd paragraph (Traditionally, ...)
It says: The latter have been ....
It is hard to recognize since the previous sentence is long and includes many "and". I guess it is path maintenance and I suggest to make "the latter" clearer.

- Last sentence of 4th paragraph
It uses "OAM operations management" but is "operation(s)" used twice? or used as operational data?. I think just OAM makes sense...

- 1st sentence in 5th paragraph
It uses "OAM mechanisms" and it looks the mixture of tools and protocols for this term. Fortunatelly, RFC 7276 defines the terminologies for OAM xxx in section
2.2.3. It would be better to be in align with the section.

- 3rd sentence in 5th paragraph
C in FCAPS should be configuration. But I am not sure the former part of this sentence (i.e. covering 5 FCAPS) is needed for the chapter...

Regards, Yuji

(2014/09/17 10:34), Qin Wu wrote:
> An operator's network is made up of layers -- consisting of OSI layers 1 through 3 in the first instance, but made more complex by the emergence of network
> overlays such as NVO3 [reference]. Looking along a particular layer, a path may be made up of multiple segments of differing network technologies, such as
> MPLS at one point, IP at another.
>
> Traditionally, fault management and path maintenance have been achieved through a series of technology and layer specific OAM protocols together with
> technology and layer specific management interfaces. The latter have been based on SNMP MIB modules developed independently without coordination between them
> and on proprietary interfaces for configuration. The limited scope of of each management interface has made it very difficult to:
>
> localization and provide better OAM visibility, since it has been necessary to navigate the peculiarities of each individual technology specific management
> interface at each layer, then try to bring the results together into a coherent picture.
>
> There is now a move afoot to replace the SNMP MIB modules with YANG modules instead. YANG is more flexible and extensible than SMIv2, and can more safely be
> used for configuration as well as information retrieval. This movement to YANG opens up the possibility of modeling OAM operations management in a more
> uniform fashion and creating management interfaces that are more friendly to a centralized management function than the present set.
>
> The objective of the LIME initiative is to encourage consistent configuration, reporting, and presentation for the OAM mechanisms used to manage the network,
> over all layers and technologies. It will do this by preparing a set of guidelines for future OAM developments as its initial task. These guidelines will
> cover OAM for all five FCAPS (fault, capacity, accounting, performance, security) management areas, and will not be limited to Layer 1-3 technologies but also
> consider management at higher OSI layers. Two initial cases will be considered:
>
> *? 件人:*Lime [mailto:[email-masked]] *代 表 *Benoit Claise
> *? 送??:*2014年9月16日18:58
> *收件人:[email-masked] <mailto:[email-masked]>
> *主?:*[Lime] OAM Initiative: Situation
>
> Dear all,
>
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Sep 2014 07:05:23 +0000

Hi, Yuji:
Thanks for your support and valuable review.
See my reply inline.

Regards!
-Qin
发件人: Lime [mailto:[email-masked]] 代表 Yuji Tochio
发送时间: 2014年9月18日 13:07
收件人: [email-masked]
主题: Re: [Lime] LIME Charter Propsosal v1

Hi Qin,

[Qin]:I think it should be “technology and layer specific management interfaces”. We will fix this.

[Qin]: It looks here we intend to underline operation management, but I am okay to remove operations from “OAM operations management”. Maybe we can also say OAM and Management.

- 1st sentence in 5th paragraph
It uses "OAM mechanisms" and it looks the mixture of tools and protocols for this term. Fortunatelly, RFC 7276 defines the  terminologies for OAM xxx in section 2.2.3. It would be better to be in align with the section.

[Qin]: Good suggestions, we will use the terms in the RFC7276.

[Qin]: It is typo, C should be configuration, thanks for catching.
FCAPS is related to network management, traditional network management practices deal with a wide array of
procedures, processes, and tools for configuration, fault detection, performance monitoring, security, accounting.
OAM is an important part of network management. But I agree OAM doesn’t equal to FCAPS. We will see how to fix this.

Regards, Yuji

Hi, all

    tools.

Related work:

发 件人: Lime [mailto:[email-masked]] 代 表 Benoit Claise
发 送时间: 2014年9月16日 18:58
收件人: [email-masked]<mailto:[email-masked]>
主题: [Lime] OAM Initiative: Situation

Dear all,

Lime mailing list

[email-masked]<mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Sep 2014 08:13:15 +0000

Hi:
Thanks all who volunteer to help review or provide input to LIME Charter proposal.
Our call for Charter Design team will end on Friday in the end of this week. Let me know if you want to join.
Based on confirmation we have got earlier and now on the list, here is a list of people who are willing to help with LIME charter proposal:
<<<<<<<<<<<<<<<<<
Stewart Bryant
Romascanu, Dan
Ronald Bonica
Susan Hares
Jouni Korhonen
Yuji Tochio
Tom Taylor
Gregory Mirsky
Daniel King
Sam Aldrin
Mohamed Boucadair
Ravi Shekhar
Huub van Helvoort
Tom Herbert
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
We will add them into our Charter Design team. If anyone else who is not in this list is willing to help or I miss anyone, please let me know and send me a message to me offline.
We will see how to address comments we received on the list so far with additional text proposal.

If you have input or update to LIME Charter proposal, please send your output to me offline before September 24, next Wednesday.
We will finalized our Charter proposal one September 24 before the deadline set by the IETF.
Thanks for your support and help.

Regards!
-Qin

Hi, all

    tools.

Related work:

Dear all,

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 18 Sep 2014 09:07:44 +0000

Hi Benoit,
I agree with your initial conclusion.
I still have some further questions as inline, hoping to get your opinion.
Thanks!

B.R.
Frank

From: Lime [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, September 16, 2014 6:58 PM
To: [email-masked]
Subject: [Lime] OAM Initiative: Situation

Dear all,

[Frank] : Before we define any YANG model for this objective, does it need some basic Information Model definition firstly? Is the Information model in the scope of this work?

5. A set of guidelines for future OAM developments would be welcome for consistency sake
[Frank] : What kind of guidelines does here mean?  Does the future OAM developments only refer to OAM in management plane, or also include OAM in data plane? I think maybe both.
We also believe that there is sufficient interest to start working on a charter proposal.
Regards, Joel and Benoit (OPS ADs)

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 18 Sep 2014 10:10:27 +0000

Hi Qin,
Thanks for initiating and proposing this very valuable work to IETF!
I am very interested in it and will contribute to it. If the Charter Design Team is not too long, please add me~~
Now, I have some comments and questions to the Charter Proposal for your consideration. Please see inline:

Thanks!

B.R.
Frank

From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Wednesday, September 17, 2014 9:34 AM
To: Benoit Claise; [email-masked]
Cc: Tom Taylor
Subject: Re: [Lime] LIME Charter Propsosal v1

Hi, all

    tools.

[Frank] : I think we cannot say SNMP interfaces are proprietary interfaces, they have been standardized. So, I suggest to use “particular MIB modules” to replace “proprietary interfaces”

[Frank] : Should “status defects” be replaced by “status, defects”? One point maybe missed here is about the complexity of understanding and developing a management MIB module for the operators because of each one is technology and layer specific.

[Frank] : I personally think the description about “guidelines” is not very clear. What’s the guidelines aim for? What’s  about the future OAM developments? What’s the relation between them? Hoping it has a more clear description here.

[Frank] : maybe need a explanation of what is a local management function.

Related work:

Dear all,

---

From: Benoit Claise <[email-masked]>
Date: Tue, 23 Sep 2014 18:05:06 +0200

Hi Frank,

See my reply in-line.
> *From:*Lime [mailto:[email-masked]] *On Behalf Of *Benoit Claise
> *Sent:* Tuesday, September 16, 2014 6:58 PM
> *To:* [email-masked]
> *Subject:* [Lime] OAM Initiative: Situation
>
> Dear all,
>
> */[Frank] : Before we define any YANG model for this objective, does 
> it need some basic Information Model definition firstly? Is the 
> Information model in the scope of this work?/*
>
[benoit]
This is a very good question.
In my charter reviews since I became OPS AD, I've been stressing the 
need to have an information model before specifying the data model(s), 
especially for WGs that still need to determine their management 
requirements:
     fault, configuration, accounting, performance?
     push/pull?
     OAM or not?
     ...
Now, the LIME work is special: it's specific to configuration, and for 
configuration there is a primary language: YANG.
The growing interest in YANG throughout the industry proves YANG is the 
right way to go.
So I'm wondering if, in _this __SPECIFIC _(potential) WG, it's necessary 
to go with an information model first? I would say no, but could be 
convinced otherwise.

> *//*
> */[Frank] : What kind of guidelines does here mean?  Does the future 
> OAM developments only refer to OAM in management plane, or also 
> include OAM in data plane? I think maybe both./*
>
[Benoit] I would say both

Regards, Benoit