Subject: [Lime] LIME -- Additional Charter Proposal

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 18 Sep 2014 14:23:02 +0000

Hi, LIME,

Nagendra and I had also been working on draft charter text for the LIME effort.

We figured we would contribute this draft write-up to the discussion, for your consideration.

Please find the full draft text below, and feel free to shoot holes at it.

~~~~~~~~~~~~~~

LIME Proposed Charter:

Network Operators have been increasingly challenged with operational and management limitations in a typical network due to siloed Operations, Administration, and Maintenance (OAM) in different layers, and a lacking architectural approach. Varying business needs results in different transport and data link technologies that developed their own unique OAM functionality for Fault Detection, Fault Isolation, Performance Management, and/or Continuity and Connectivity Management.

For example, traditional IP networks have leveraged ICMP tools for fault detection and isolation, but ICMP, even with extensions, is inadequate for the full breath of MPLS networks. While LSP Ping makes for a very useful tool for MPLS networks, certain characteristics of MPLS services like L2VPNs result in VCCV.

With the introduction of virtualization, TRILL and NVO3 are additional transports, which raise new OAM tools with unique features that satisfy the constraints of relevant transport technology.  To add to this, Service Function Chaining introduces another layer known as service layer, with its own OAM requirements.

The focus of the work in this Working Group is to emphasize the associated operational challenges in consistently handling end-to-end OAM and documents a unified OAM approach to perform consistent end-to-end Fault Management, Performance Management and Change Management that leverages and correlates information collected across different layers. This consistent approach includes configuration, reporting, and presentation of OAM, is meaningful across different layers and protocols (e.g., data link and transport), and is applicable for Fault Management, Performance Management and Configuration Management. . In addition, the use of YANG as modeling language for centralized management will be considered. It also provides a set of guidelines to flexibly accommodate any new data link or transport protocols.

The scope of this working group will be limited to commence work items that are beneficial to Network Operators by helping reduce Operational expenditures and simply network management. It also supports a unified way to accommodate any new upcoming OAM protocols in an existing or a new layer. It further gauges the benefits of network programmability and adds any relevant work items.

Specifically, the scope of this work group is chartered to deliver the following:

1. Problem Statement: This document will provide a summary of problem space to be addressed by this working group. It further analyzes the benefits and gaps in complementing network programmability from centralized manner. In addition, the working group will normalize the nomenclature and definition for unified OAM approach.

2. Use-cases: This document lists different use-cases at a high level that benefits with unified OAM approach along with the gaps. The use cases can be related to Fault Management, Performance Management and/or Change Management.

3. Architecture: This document will provide a detailed description of building blocks that satisfies operation and management constraints in different layers. It also provides a set of guidelines for future OAM development, to maximize consistency. The initial scope is restricted to a single administrative domain and may be extended for inter-domain scenarios in future as and when a need rises.

4. Modeling Language: This document is a compliment document for Architecture document but provides a detailed description of the use of YANG as modeling language for centralized management.

5. Operational Solutions:  This document will list the unified OAM data models. In addition, it also documents the relevant API extensions to augment network programmability.

~~~~~~~~~~~~~~

Thanks,

Carlos & Nagendra.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 18 Sep 2014 14:11:18 -0400

I like the text (with a few reservations marked with [PTT] below), right 
up until you get to the deliverables. These seem to go beyond our ADs' 
direction. If I have misinterpreted that direction in the other charter 
proposal, I will be happy to be corrected.

Tom Taylor

On 18/09/2014 10:23 AM, Carlos Pignataro (cpignata) wrote:
> Network Operators have been increasingly challenged with operational
> and management limitations in a typical network due to siloed
> Operations, Administration, and Maintenance (OAM) in different
> layers, and a lacking architectural approach. Varying business needs
> results in different transport and data link technologies that
> developed their own unique OAM functionality for Fault Detection,
> Fault Isolation, Performance Management, and/or Continuity and
> Connectivity Management.
>
> For example, traditional IP networks have leveraged ICMP tools for
> fault detection and isolation, but ICMP, even with extensions, is
> inadequate for the full breath of MPLS networks. While LSP Ping makes
> for a very useful tool for MPLS networks, certain characteristics of
> MPLS services like L2VPNs result in VCCV.
>
> With the introduction of virtualization, TRILL and NVO3 are
> additional transports, which raise new OAM tools with unique features
> that satisfy the constraints of relevant transport technology.  To
> add to this, Service Function Chaining introduces another layer known
> as service layer, with its own OAM requirements.
>
> The focus of the work in this Working Group is to emphasize the
> associated operational challenges in consistently handling end-to-end
> OAM and documents a unified OAM approach to perform consistent
> end-to-end Fault Management, Performance Management and Change
> Management that leverages and correlates information collected across
> different layers. This consistent approach includes configuration,
> reporting, and presentation of OAM, is meaningful across different
> layers and protocols (e.g., data link and transport), and is
> applicable for Fault Management, Performance Management and
> Configuration Management. .

[PTT] Why were Accounting but especially Security Management left out of 
this list?

In addition, the use of YANG as modeling
> language for centralized management will be considered.

[PTT] I don't think the would-be WG has a choice in the matter -- as Dan 
Romascanu pointed out when it was the TIME list, other SDOs and WGs 
related to the technology concerned are already developing YANG modules. 
I'd leave this sentence out.

It also
> provides a set of guidelines to flexibly accommodate any new data
> link or transport protocols.
>
> The scope of this working group will be limited to commence work
> items that are beneficial to Network Operators by helping reduce
> Operational expenditures and simply network management. It also
> supports a unified way to accommodate any new upcoming OAM protocols
> in an existing or a new layer. It further gauges the benefits of
> network programmability and adds any relevant work items.

[PTT] That last sentence would never get past the IESG -- too 
open-ended. And I'm not sure that anyone would listen to us if we said 
network programmability is a good or bad thing, which is what the first 
part of the sentence literally says. Maybe you meant to say that the 
current movement to network programmability will be a consideration in 
the work to be done.
> 1. Problem Statement: This document will provide a summary of problem
> space to be addressed by this working group. It further analyzes the
> benefits and gaps in complementing network programmability from
> centralized manner. In addition, the working group will normalize the
> nomenclature and definition for unified OAM approach.
>
> 2. Use-cases: This document lists different use-cases at a high level
> that benefits with unified OAM approach along with the gaps. The use
> cases can be related to Fault Management, Performance Management
> and/or Change Management.
>
> 3. Architecture: This document will provide a detailed description of
> building blocks that satisfies operation and management constraints
> in different layers. It also provides a set of guidelines for future
> OAM development, to maximize consistency. The initial scope is
> restricted to a single administrative domain and may be extended for
> inter-domain scenarios in future as and when a need rises.
>
> 4. Modeling Language: This document is a compliment document for
> Architecture document but provides a detailed description of the use
> of YANG as modeling language for centralized management.
>
> 5. Operational Solutions:  This document will list the unified OAM
> data models. In addition, it also documents the relevant API
> extensions to augment network programmability.
>
> ~~~~~~~~~~~~~~
>
> Thanks,
>
> Carlos & Nagendra.
>
>
>
>
> _______________________________________________ Lime mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/lime
>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 18 Sep 2014 20:26:25 +0000

Hi Tom,

Thanks for the response. Please see inlineŠ

>proposal, I will be happy to be corrected.

<Nagendra> We tried to segregate the deliverables into different document
but tried to not deviate from the actual direction concluded in earlier AD
email :)

In short, the deliverables is scoped towards defining the problem along
with potential use cases and discussing on data models and building
blocks. Please point us if you see any discrepancy and accordingly can be
modified.

>I'd leave this sentence out.

<Nagendra> Right. And I think it is better to define the decision of YANG
as modeling language in the charter for clarity. I will modify it to
reflect YANG as the logical choice instead of giving an imrepssion that it
³will be considered². Will that be fine?.

>current movement to network programmability will be a consideration in

<Nagendra> Yes, that is right. I think we can modify the statement to be
more clear. 

Thanks,
Nagendra

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2014 15:01:16 -0400

This isn't specifically picking on Carlos' text, but provides a point for me
to ask my question. 

> The focus of the work in this Working Group is to emphasize the associated operational challenges in consistently handling end-to-end OAM and documents a unified OAM approach to perform consistent…

Is there any intention on specifically making the exercise of multi-path
layer-X link elements specifically able to be covered for OAM purposes by
LIME?  Examples include Ethernet LAG and various layer-3 multipath.

-- Jeff

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Sep 2014 01:12:22 +0000

Hi, Jeff:
The latest version of the proposed consolidated charter posted at 
<https://github.com/danielkinguk/lime/tree/master/charter-proposal>
Which is built on the many proposals and discussions on the list so far.

The new update will come soon based on offline Charter Design team discussion
Regarding your raised question, that is an interesting question. Multi-path OAM issue has been briefly examined in the
section 4.3.2 of draft-edprop-opsawg-multi-layer-oam-ps.
https://tools.ietf.org/html/draft-edprop-opsawg-multi-layer-oam-ps-01

Regards
-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Jeffrey Haas
发送时间: 2014年9月23日 3:01
收件人: Carlos Pignataro (cpignata)
抄送: Benoit Claise (bclaise); Nagendra Kumar Nainar (naikumar); [email-masked]
主题: Re: [Lime] LIME -- Additional Charter Proposal

This isn't specifically picking on Carlos' text, but provides a point for me to ask my question. 

> The focus of the work in this Working Group is to emphasize the associated operational challenges in consistently handling end-to-end OAM and documents a unified OAM approach to perform consistent…

Is there any intention on specifically making the exercise of multi-path layer-X link elements specifically able to be covered for OAM purposes by LIME?  Examples include Ethernet LAG and various layer-3 multipath.

-- Jeff

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 23 Sep 2014 03:40:38 +0000

Hi Jeff,

> Is there any intention on specifically making the exercise of multi-path layer-X
> link elements specifically able to be covered for OAM purposes by LIME?
> Examples include Ethernet LAG and various layer-3 multipath.

[Rachel]: I think it is not clear yet how centralized management can manipulate load balancing technique. Isn't in-band mechanism better enough?
 Unless you are looking at end-to-end basis and think centralized management can:
1. provide both fault management and failure recovery
2. Help steering the traffic from a path having problems to other healthy ones.