Subject: Re: [Time] I-D Action: draft-ww-opsawg-multi-layer-oam-00.txt

From: Qin Wu <[email-masked]>
Date: Fri, 13 Jun 2014 04:46:55 +0000

Hi, folks:
We have submitted a new draft which discuss problem statement of technology independent OAM in the multi-layer network
http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-00
Your comments or feedback are welcome!

Regards!
-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年6月5日 19:58
收件人: [email-masked]
主题: I-D Action: draft-ww-opsawg-multi-layer-oam-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Problem Statement and Architecture for Transport Independent OAM in the multiple layer network
        Authors         : Qin Wu
                          Mishael Wexler
                          Pradeep Jain
	Filename        : draft-ww-opsawg-multi-layer-oam-00.txt
	Pages           : 12
	Date            : 2014-06-05

Abstract:
   Operations, Administration, and Maintenance (OAM) mechanisms
   [RFC6291] are basic building blocks for every communication layer and
   technology.  The current practice is that many technologies and
   layers have their own OAM protocols.  In the current situation there
   is a little or no re-use of software and hardware in the existing OAM
   protocols.  Vendors and operators waste a lot through the whole OAM
   life-cycle when a new technology is introduced.  Integration of OAM
   across multiple technologies is extremely difficult.  In many cases
   it is desirable to have a generic OAM to cover heterogeneous
   networking technologies.  An example to this generic approach is the
   Bidirectional Forwarding Detection [BFD] mechanism that offers a way
   to monitor, troubleshoot and maintain the network and services in
   support multi-layer OAM independent of media, data protocols, and
   routing protocols.  Generic OAM tools can be deployed over various
   encapsulating protocols, and in various medium types.

   An example of an environment in which a generic and integrated OAM
   protocol would be valuable is Service Function Chaining.  A Service
   Function Chaining is composed by series of service Functions, that
   can act in different layers but providing an end-to-end chain or path
   from a source to destination in a given order [I.D-ietf-sfc-problem-
   statement].  In service function chaining environment it is necessary
   to provide end to end OAM across certain or all entities and
   involving many layers.  OAM information should be exchanged between
   service functions in different layers while using various
   encapsulating protocols.  In some cases OAM should cross different
   administration and/or maintenance domains.

   This document sets out the problem statement and architecture for the
   Generic OAM in the Service Layer Routing.  This document will cover
   at least the basic OAM functions and information such as Connectivity
   Verification (CV), Path Verification and Continuity Checks (CC),Path
   Discovery / Fault Localization and Performance Monitoring necessary
   to monitor and maintain the network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ww-opsawg-multi-layer-oam/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-00

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Jun 2014 21:23:33 -0800

> Your comments or feedback are welcome!

Hi, Qin:

I think this is potentially an extremely rich area for
new work, with the caveat that I think that if you say
that there aren't multi-layer OAM technologies now you're
likely to run into disagreement from the SNMP experts,
YANG experts, and so on.  I do think that you've isolated
one particularly interesting and not-very-well explored
area, which is path-coupled diagnostics and management.
I did some work in this area a long time ago
(see http://tools.ietf.org/html/draft-shore-nls-tl-06)
and while it moved ahead in a proprietary context not
much was standardized.  The IETF developed a similar
mechanism (NSIS) but it's complex, has messy layers,
and is quite heavy-weight.  Still, the notion of triggering
device management actions or diagnostics along a network
path remains extremely interesting and insufficiently
investigated.  It's likely there may be some work there
but I think there needs to be some strongly-stated use
cases.

Melinda

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Jun 2014 07:02:48 +0000

Hi, Melinda:
Please see my reply below.

Regards!
-Qin
-----邮件原件-----
发件人: Time [mailto:[email-masked]] 代表 Melinda Shore
发送时间: 2014年6月13日 13:24
收件人: [email-masked]
主题: Re: [Time] I-D Action: draft-ww-opsawg-multi-layer-oam-00.txt

On 6/12/14 8:46 PM, Qin Wu wrote:
>> Hi, folks:
>> We have submitted a new draft which discuss problem statement of 
>> technology independent OAM in the multi-layer network

>I think this is potentially an extremely rich area for new work, with the caveat that I think that if you say that there aren't multi-layer OAM technologies now you're likely to run into 
>disagreement from the SNMP experts, YANG experts, and so on.  

[Qin]: That's a very good question I want to ask all SNMP, YANG experts on this list.
The idea proposed in draft-ww-opsawg-multi-layer-oam-00 is built on top of draft-ietf-opsawg-oam-overview which has just being published as RFC7276.
RFC7276 did allow networks supporting multi-layer architecture, however two assumptions it made is
(1) each layer has its own OAM protocols.  
(2) OAM can be used at different levels of
   hierarchy in the network to form a multi-layer OAM solution
However how to integrate OAM covering various hetegeneous network technology, deployed over various encapsulating protocols, and in various medium types.
How to abstract OAM information from various layer or OAM protocol to get unfied overview.
This is not well addressed in RFC7276. That's why we propose this new work.

>I do think that you've isolated one particularly interesting and not-very-well explored area, which is path-coupled diagnostics and management.
>I did some work in this area a long time ago (see http://tools.ietf.org/html/draft-shore-nls-tl-06)
>and while it moved ahead in a proprietary context not much was standardized. 

[Qin]: Interesting draft. I think two interesting aspects we really like to look into are:
1.	OPS related aspect: Management and control of OAM, i..e, abstract OAM information common to different layer and provide to management via unified management plane interface
2.	RTG related aspect, Technology independent OAM mechanisms, I think BFD and SFC header carrying various OAM information are two good candidate OAM we are thinking in mind.
It likes what you proposed in draft-shore-nls-tl-06 is much close to OAM using the control plane flavor, e.g.,RSVP-TE.
we may need a survey for all these OAM tools, whether it is data plane OAM or control plane OAM, and then sort out all the technology independent OAMs.

> The IETF developed a similar mechanism (NSIS) but it's complex, has messy layers, and is quite heavy-weight.  Still, the notion of triggering device management actions or diagnostics along a 
>network path remains extremely interesting and insufficiently investigated.  It's likely there may be some work there but I think there needs to be some strongly-stated use cases.

[Qin]: Interesting aspect, I believe it is related to how OAM is managed or controlled. We did have two use cases described in section 3.1 and section 3.2 of draft-ww-opsawg-multi-layer-oam-00.
Let me know what your use case looks like? It would be great you can help contribute a use case draft.

Melinda

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