Subject: [Time] Editor's proposed draft of TIME/LIME Problem Statement

From: Tom Taylor <[email-masked]>
Date: Fri, 05 Sep 2014 11:43:00 -0400

Qin Wu drafted me as editor of the Problem Statement I-D.

There has been a lot of activity behind the scenes. When I  was brought 
into the picture, I was given a version -03 of 
draft-ww-opsawg-multi-layer-oam as a starting point. This built on the 
published -02 version but had a lot more text up front and in the future 
work section. It also dropped "Architecture" from the title, removing it 
as a focus.

My view was that the Problem Statement had to be tightly focussed 
precisely on that topic, and the future work section would become the 
core of a gap analysis document. This view was accepted. As a result, I 
have prepared an Editor's Proposal, 
draft-edprop-opsawg-multi-layer-oam-ps-00, which I plan to submit on 
Monday after some people have looked it over. It is much stripped down 
from the original text and has a lot of new text, but I hope it is not a 
shock to TIME/LIME participants. A key issue was extremely careful 
attention to terminology and nuances of meaning.

The concluding Problem Statement section is fairly brief, so I'll quote 
it here:

5.  Problem Statement

    Operators have a need for a management subsystem satisfying the
    objectives stated in Section 3.  The analysis presented above
    indicates that the solution lies in the direction of a consolidated
    management function that operates in the first instance on a
    technology and layer independent view of network and service
    performance.

    There is value in attempting to define an architecture for
    consolidated management that may reasonably be argued to meet the
    stated objectives.  If this attempt succeeds, it can be followed up
    with a gap analysis, which in turn will define a further program of
    standardization.

    At the detailed level, Section 4.3.1 and Section 4.3.2 deal with the
    matter of abstraction and its relationship to the specification of
    YANG modules.  This is work beyond the initial definition of
    architecture and awaits justification and prioritization by the gap
    analysis.  A similar consideration relates to the solution to the
    ECMP problem.

    The remaining issue is the OAM interworking issue identified in
    Section 4.3.3.  This is architectural in nature, and should be
    addressed by the proposed work on architecture.

Tom Taylor

---

From: Qin Wu <[email-masked]>
Date: Sat, 6 Sep 2014 09:37:50 +0000

Hi, Tom:
Yes, we need to split architecture and gap analysis from this draft and we need a clear scoped problem statement. 
Architecture will give us a whole picture for what consolidated management looks like.
I am happy to see this PS draft did discuss what architecture MUST define. I think It is a very good starting point.
I have shared some of my thoughts on the architecture through this list(e.g., model all the OAM technologies in the same way by applying some template).
I would be interested to know what other people think about the architecture for consolidated management?

Regards!
-Qin
-----邮件原件-----
发件人: Time [mailto:[email-masked]] 代表 Tom Taylor
发送时间: 2014年9月5日 23:43
收件人: [email-masked]
主题: [Time] Editor's proposed draft of TIME/LIME Problem Statement

There has been a lot of activity behind the scenes. When I  was brought into the picture, I was given a version -03 of draft-ww-opsawg-multi-layer-oam as a starting point. This built on the published -02 version but had a lot more text up front and in the future work section. It also dropped "Architecture" from the title, removing it as a focus.

My view was that the Problem Statement had to be tightly focussed precisely on that topic, and the future work section would become the core of a gap analysis document. This view was accepted. As a result, I have prepared an Editor's Proposal, draft-edprop-opsawg-multi-layer-oam-ps-00, which I plan to submit on Monday after some people have looked it over. It is much stripped down from the original text and has a lot of new text, but I hope it is not a shock to TIME/LIME participants. A key issue was extremely careful attention to terminology and nuances of meaning.

The concluding Problem Statement section is fairly brief, so I'll quote it here:

5.  Problem Statement

Tom Taylor		

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

---

From: Jouni <[email-masked]>
Date: Sat, 6 Sep 2014 13:10:54 +0300

Tom,

I had a read on this document. Good stuff. I have one lame comment though. The preamble building the "background and justification" is just too verbose and tries to address to many cases. When we get to problem statement part and the architecture part it was hard to put everything together in my head. I admit I have not spent much time on this specific topic but still.. I would try to illustrate the background with one concrete use case example that people can easily relate to and then state "there are other out there..".

- Jouni

---

From: Tom Taylor <[email-masked]>
Date: Sat, 06 Sep 2014 06:41:35 -0400

Thanks, Jouni. We can work on that.

Tom

---

From: Tom Taylor <[email-masked]>
Date: Sun, 07 Sep 2014 20:30:42 -0400

How about if the following text goes into the Introduction?

1.1 A Vision of Layer and Technology Independent Management

What follows is based on the assumption of a network supported by a 
strict hierarchy of underlying layers in the data plane. There may be 
multiple layers at a given level of the OSI layer 1-2-3 hierarchy, but 
that is irrelevant to the vision.

A management application presents to an user a view of this network and 
its supporting layers that is strictly topological, free of any 
technology specific information. The user notes a defect along a path 
serving a particular customer. Looking at the next lower path, the user 
also sees a defect. Looking the next lower path again, there is also a 
defect. No lower defect is noted.

At this point it is appropriate to indicate what the user can see along 
a given path. The path is divided into one or more segments, each 
spanned by a specific transport technology. However, as already stated, 
the user does not see any technology specific information. Instead, as 
well as distinguishing the segments, the user can identify the managed 
elements at the beginning and end of each segment.

To clarify the situation, the user issues an abstract Continuity Check 
command, directed toward the initial managed element of the segment in 
which a fault appears to lie (i.e., in the lowest layer where a defect 
was observed). By means to be determined by architectural choice, this 
command is converted into a technology-specific request which is 
executed across the selected segment. Possible outcomes include:

(1) The fault could come clear as a result of the test. The immediate 
problem is solved (and may have affected multiple upper paths besides 
the one of initial interest) and the point at which it occurred could be 
flagged for follow-up maintenance.

(2) Local craft action to clear the fault is available in timely fashion.

(3) Timely local craft action is not possible, and capacity is 
reallocated on other paths to ensure that service levels are maintained. 
Note that capacity reallocation can be done based on the topological 
view of the network, still on a layer and technology independent basis.

In case (2), technology specific management capabilities are likely to 
be required by the craftperson following up on the problem.

The remainder of this document defines the problem that motivates a 
layer and technology independent view of the network, and provides 
guidelines for the creation of a management architecture that would make 
such a view possible.

Tom

---

From: Melinda Shore <[email-masked]>
Date: Sun, 07 Sep 2014 19:22:00 -0800

> 1.1 A Vision of Layer and Technology Independent Management

I just had a thorough read of a recent version of the problem statement
and I think that the terminology around the problem really needs to be
tweaked.  In some sense we've already got layer- and technology-
independent management, in the form of several highly modular protocols
that can convey management and/or configuration information for all
sorts of devices and protocols.  What's unique here is that there's
a proposal to path-couple management messages and possibly have them
intercepted by management modules in varying sorts of devices along that
path.  It's been proposed before (for example, I proposed it here:
draft-shore-nls-tl-06.txt) but has never been developed.  What's
significant about this proposal that it attempts to deal with managing
and diagnosing problems that may be related to topology, perhaps
without foreknowledge of topology or routing.

I'd try to be clearer about why this is interesting.  "Layer and
Technology Independence" is one aspect of it but not one that's
unique to this proposal.

Melinda

---

From: "Daniel King" <[email-masked]>
Date: Mon, 8 Sep 2014 20:52:37 +0100

Hi Tom and Jouni, 

The vision statement for layer/technology independent management would be a
useful addition in the P-S document.  

Br, Dan. 
	
-----Original Message-----
From: Time [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: 08 September 2014 01:31
To: Jouni
Cc: [email-masked]
Subject: Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement

What follows is based on the assumption of a network supported by a strict
hierarchy of underlying layers in the data plane. There may be multiple
layers at a given level of the OSI layer 1-2-3 hierarchy, but that is
irrelevant to the vision.

A management application presents to an user a view of this network and its
supporting layers that is strictly topological, free of any technology
specific information. The user notes a defect along a path serving a
particular customer. Looking at the next lower path, the user also sees a
defect. Looking the next lower path again, there is also a defect. No lower
defect is noted.

At this point it is appropriate to indicate what the user can see along a
given path. The path is divided into one or more segments, each spanned by a
specific transport technology. However, as already stated, the user does not
see any technology specific information. Instead, as well as distinguishing
the segments, the user can identify the managed elements at the beginning
and end of each segment.

To clarify the situation, the user issues an abstract Continuity Check
command, directed toward the initial managed element of the segment in which
a fault appears to lie (i.e., in the lowest layer where a defect was
observed). By means to be determined by architectural choice, this command
is converted into a technology-specific request which is executed across the
selected segment. Possible outcomes include:

(1) The fault could come clear as a result of the test. The immediate
problem is solved (and may have affected multiple upper paths besides the
one of initial interest) and the point at which it occurred could be flagged
for follow-up maintenance.

(3) Timely local craft action is not possible, and capacity is reallocated
on other paths to ensure that service levels are maintained. 
Note that capacity reallocation can be done based on the topological view of
the network, still on a layer and technology independent basis.

In case (2), technology specific management capabilities are likely to be
required by the craftperson following up on the problem.

The remainder of this document defines the problem that motivates a layer
and technology independent view of the network, and provides guidelines for
the creation of a management architecture that would make such a view
possible.

Tom

On 06/09/2014 6:10 AM, Jouni wrote:
>
> Tom,
>
> I had a read on this document. Good stuff. I have one lame comment though.
The preamble building the "background and justification" is just too verbose
and tries to address to many cases. When we get to problem statement part
and the architecture part it was hard to put everything together in my head.
I admit I have not spent much time on this specific topic but still.. I
would try to illustrate the background with one concrete use case example
that people can easily relate to and then state "there are other out
there..".
into the picture, I was given a version -03 of
draft-ww-opsawg-multi-layer-oam as a starting point. This built on the
published -02 version but had a lot more text up front and in the future
work section. It also dropped "Architecture" from the title, removing it as
a focus.
>> My view was that the Problem Statement had to be tightly focussed
precisely on that topic, and the future work section would become the core
of a gap analysis document. This view was accepted. As a result, I have
prepared an Editor's Proposal, draft-edprop-opsawg-multi-layer-oam-ps-00,
which I plan to submit on Monday after some people have looked it over. It
is much stripped down from the original text and has a lot of new text, but
I hope it is not a shock to TIME/LIME participants. A key issue was
extremely careful attention to terminology and nuances of meaning.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 08 Sep 2014 21:08:06 -0400

Thanks, Dan

I also had a few helpful comments from Mishael Wexler regarding 
terminology and the problem statement itself to fold in. Given the 
announcement from the ADs, the work on the current PS seems to be 
overtaken by events, and attention should shift to drafting a charter.

I'll do the updates to draft-edprop and submit it as a matter of record. 
Some of it should be useful in the charter drafting.

Tom

> useful addition in the P-S document.
...

---

From: Qin Wu <[email-masked]>
Date: Tue, 9 Sep 2014 01:53:44 +0000

Good stuff, I love it.
Talked with Tom earlier, I really like to see management application can provide adaptation layer and shield all the technologies specific information in the underlying network that is using different OAM technology at this adaption layer since User don't need to really care about what specific OAM technologies are used. What is more important is to quickly identify fault and provide more efficient fault management automation.

Regards!
-Qin
-----邮件原件-----
发件人: Time [mailto:[email-masked]] 代表 Tom Taylor
发送时间: 2014年9月8日 8:31
收件人: Jouni
抄送: [email-masked]
主题: Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement

What follows is based on the assumption of a network supported by a strict hierarchy of underlying layers in the data plane. There may be multiple layers at a given level of the OSI layer 1-2-3 hierarchy, but that is irrelevant to the vision.

A management application presents to an user a view of this network and its supporting layers that is strictly topological, free of any technology specific information. The user notes a defect along a path serving a particular customer. Looking at the next lower path, the user also sees a defect. Looking the next lower path again, there is also a defect. No lower defect is noted.

At this point it is appropriate to indicate what the user can see along a given path. The path is divided into one or more segments, each spanned by a specific transport technology. However, as already stated, the user does not see any technology specific information. Instead, as well as distinguishing the segments, the user can identify the managed elements at the beginning and end of each segment.

To clarify the situation, the user issues an abstract Continuity Check command, directed toward the initial managed element of the segment in which a fault appears to lie (i.e., in the lowest layer where a defect was observed). By means to be determined by architectural choice, this command is converted into a technology-specific request which is executed across the selected segment. Possible outcomes include:

(1) The fault could come clear as a result of the test. The immediate problem is solved (and may have affected multiple upper paths besides the one of initial interest) and the point at which it occurred could be flagged for follow-up maintenance.

(3) Timely local craft action is not possible, and capacity is reallocated on other paths to ensure that service levels are maintained. 
Note that capacity reallocation can be done based on the topological view of the network, still on a layer and technology independent basis.

In case (2), technology specific management capabilities are likely to be required by the craftperson following up on the problem.

The remainder of this document defines the problem that motivates a layer and technology independent view of the network, and provides guidelines for the creation of a management architecture that would make such a view possible.

Tom

---

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

-----邮件原件-----
>发件人: Time [mailto:[email-masked]] 代表 Melinda Shore
>发送时间: 2014年9月8日 11:22
>收件人: [email-masked]

>I just had a thorough read of a recent version of the problem statement and I think that the terminology around the problem really needs to be tweaked.  
>In some sense we've already got layer- and technology- independent management, in the form of several highly modular protocols that can convey management and/or configuration >information for all sorts of devices and protocols.

[Qin]: Today we see a large number of Managed objects (called SNMP MIBs) be developed, each MIB is developed for each technology. When a new technology is introduced, there is little reuse of any SNMP MIB designed for the existing technologies.

Therefore I am not sure we can call SNMP is layer and technology independent management protocol.
NETCONF can provide layer and technology independent management feature since it use modeling language to define operation data, configuration data and notification.
One model defined by NETCONF can be reused by another model if we allow model to be extended. What addition you need to do is to define technology specific feature.

Secondly what we like to see is management plane to provide adaption layer between user and managed element, user doesn't need to care about what specific OAM technologies are used,
Adaption layer can provide mapping and translation between technologies specific information and technologies independent information(e.g., CFM model related information)

>  What's unique here is that there's a proposal to path-couple management messages and possibly have them intercepted by management modules in varying sorts of devices along that path. 

[Qin]: Our proposal is to couple with multi-layer network, allow stitching OAM systems in different layer, correlate faults in different layer and provide abstract view of OAM information to the user.

It looks your proposal is additional to our proposal in the draft-edprop-opsawg-multi-layer-oam-ps-00 and more related to forwarding plane OAM, I remember there was some discussion before on forwarding plane OAM, it was organized by IESG and IAB.
http://www.ietf.org/mail-archive/web/oam/current/msg00030.html
http://www.ietf.org/mail-archive/web/oam/current/msg00067.html

It might be interesting to see how local management entity interact with managed entity for technology specific information when such path couple message is exchanged between management entities. But not sure it should be in the scope of our current proposal.

>It's been proposed before (for example, I proposed it here:
>draft-shore-nls-tl-06.txt) but has never been developed.  What's significant about this proposal that it attempts to deal with managing and diagnosing problems that may be related to >topology, perhaps without foreknowledge of topology or routing.

[Qin]:Yes, it is not necessary to rely on routing protocol. Management interface can also be used to gather such kind of information(e.g., supporting layer, layer identifier).

>I'd try to be clearer about why this is interesting.  "Layer and Technology Independence" is one aspect of it but not one that's unique to this proposal.

[Qin]: See above. 

Melinda