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

["Daniel King" <[e-mail]>]

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:[e-mail]] On Behalf Of Tom Taylor
Sent: 08 September 2014 01:31
To: Jouni
Cc: [e-mail]
Subject: Re: [Time] Editor's proposed draft of TIME/LIME Problem Statement

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

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..".
>
> - Jouni
>
>
> On Sep 5, 2014, at 6:43 PM, Tom Taylor wrote:
>
>> 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		
>>
>> _______________________________________________
>> Time mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/time
>
>

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