Re: [Time] draft-tissa-netmod-oam

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> Thu, 28 August 2014 15:24 UTC

Return-Path: <tsenevir@cisco.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9C1A030A; Thu, 28 Aug 2014 08:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.168
X-Spam-Level:
X-Spam-Status: No, score=-13.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDtdGBpeqD9G; Thu, 28 Aug 2014 08:24:33 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C96D1A06FC; Thu, 28 Aug 2014 08:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29477; q=dns/txt; s=iport; t=1409239473; x=1410449073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UUaWlJnTkIdT2jpeN2ooo6VAdPLfWpG3/ZUrZmZ7C7o=; b=haYGHHnGj4B1Y2Tx04CiPsMf2sKsQxzuhGAmkkvXrElFO6Ra94bOS4kG Ixc5ncHRZAYdoLggiZwDsm7CGKbmDBFuh2tpXZUkyqR0ctCz4DaFZjEsQ SlLkPv3Szn64ip29nnzxCJdyT1A+W37xaLUC3Jhge7MjN4QaQQTvbgU1G 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FACFJ/1OtJV2R/2dsb2JhbABbgkdGU1cE03YBgRkWd4QDAQEBBC05DAcQAgEIEQEDAQELFgcHMhQDBggBAQQBDQUIE4gnv0oXjnQnMQYBgy+BHQWRL6BIg15sgQYCHgYcgQcBAQE
X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208,217";a="351062464"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2014 15:24:15 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7SFOF8Q007812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:24:15 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:24:15 -0500
From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "'draft-tissa-netmod-oam@tools.ietf.org'" <draft-tissa-netmod-oam@tools.ietf.org>
Thread-Topic: draft-tissa-netmod-oam
Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1w
Date: Thu, 28 Aug 2014 15:24:14 +0000
Message-ID: <FBEA3E19AA24F847BA3AE74E2FE193562EF118C6@xmb-rcd-x08.cisco.com>
References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.89.14.1]
Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/time/DZ4f2s12Zvhy_jWGYdjxfspRxwM
X-Mailman-Approved-At: Thu, 28 Aug 2014 18:48:06 -0700
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "time@ietf.org" <time@ietf.org>, "'netmod@ietf.org'" <netmod@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: [Time] draft-tissa-netmod-oam
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 15:24:39 -0000

Greg

Before answering the specific questions below,  would like explain few aspects related to the extended CFM model used here. CFM  originally was designed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressing independent. That is the CFM model that is referred here.

CFM defines a complete fault model that include fault domains, Test point, Layering etc. Strict definition of such is needed to develop a complete OAM solution regardless of the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We are leveraging that model.

The word generic OAM is utilized here to indicate that the model can be applied regardless of the underlying technology.

YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is defined with address independent and extensibility in mind.

With the above in mind, specific answers in-line:

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

Dear Authors, et.al,
please kindly consider my comments and questions to this document:

*         Introduction

o    "... it is a reasonable choice to develop the unified OAM framework based on those (CFM) concepts." I agree that for packet switching connection-oriented networks that are based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless packet switching networks. Thus extending CFM model onto arbitrary networks without consideration whether these are connection-oriented or connectionless is very questionable approach, IMO;


[Answer] As stated above it is the OAM Model that is leveraged here. Regardless of connection oriented or not the model on Fault domains, Test points etc is valid.

In theory connection oriented can be broken in to connection establishment and data forwarding. With that in mind, one can define Fault domain and test points. Followed by definition of the Fault identifications tools accordingly.

Do you have a preferred OAM tool  for fault verification/isolation and loss and performance monitoring for connection oriented connectuons ?. If so would like to review and map to the model.



o   "...CFM, it is a reasonable choice to develop the unified OAM framework based on those concepts" IP OAM is not based on Ethernet Service OAM model or principles but, IMO, OAM of overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

[Answer]  Please see the answer above and extended CFM model. It is the model that is presented here, regardless of the connectioness,  OAM tools need fault domains and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addressing is decoupled.


o   "The YANG model presented in this document is the base model and supports IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scope of the document, then, I believe, the title may say something like "YANG model of on-demand OAM tool to detect and localize Loss of Continuity defect". Referring to ping/traceroute as "generic OAM" comes as stretch too far;

[Answer] I think there is a miss understanding this model is not limited to Ping and Trace route. Ping and traceroute are only examples to get the work stared and discussion going. As we go along other tools will be mapped to the model.

o    "...initiate a performance monitoring session can do so in the same manner regardless of the underlying protocol or technology" I'd point to work of LMAP WG on informational model of performance measurements in large-scale access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stopped after "... or a Traceroute".
[Answer] I did not fully understand your point.


o   "In this document we define the YANG model for Generic OAM" Can you provide definition or reference to the definition of the "Generic OAM"? It is challenging to validate informational model of something that not been sufficiently defined.

[Answer]  As explained earlier terminology generic OAM is used to indicate that the presented OAM model can be applied independent of the underlying technology. In section 1, we have stated the following: "..In this document, we take the [8021Q] CFM model and extend it to a technology independent framework and build the corresponding YANG model accordingly. The YANG model presented in this document is the base model and supports IP Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various technologies. Technology dependent nodes and RPC commands are defined in technology specific YANG models, which use and extend the base model defined here. .... "



*         Section 3

o   "This allows users to traverse between OAM of different technologies at ease through a uniform API set." Usually relationships between OAM layers referred and viewed as OAM interworking. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only scenarios of nested OAM layers but peering layers and thus is broader than introduced in the document "nested OAM".
[Answer]  Can you please provide some example here, I am not quite clear.

Guessing from the word peering, if we are referring to cascaded sections of different technologies such as IP Cloud, MPLS cloud and another IP cloud. Then the model presented here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can have separate OAM at a lower MD-Level. These can be utilized for fault isolation.


o   Figure 1 depicts OAM of both connection-oriented and connectionless networks. What you see common, generic in respective OAM of these networks?

[Answer] Please see the answers above.


*         Section 4

o   "In IP, the MA can be per IP Subnet ..." As there's no definition of MA in IP, is this the definition or one of examples. Can MA in IP network be other than per IP Subnet?
[Answer] It is ".. can be", so it meant to be an example and other possibilities are not ruled out and model does not assume any such limitation.


o   "Under each MA, there can be two or more MEPs (Maintenance End Points)" Firstly, since you adopt MA-centric terminology, MEP stands for Maintenance Association End Point. Secondly, in some OAM models Down and Up MEP being distinguished. Would your model consider that? As there's no definition of MEP for several networks you've listed, e.g. IP, how the YANG model will abstract something that is not defined? And thirdly, how and where MIPs are located in IP OAM?

[Answer] Yes model accept both UP/Down.

One cannot say for IP there is no MEP. MEP is a functional abstraction of a test point that generate and respond to OAM messages. In that regard IP devices today have an implicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per interface or other scope, hence providing more granularity in fault isolation/verification and monitoring.

Thank you for your consideration of my notes and looking forward to the interesting discussion.

Thank you for spending time to review and comment. We are updating the next version with comments received so far and specifically during IETF in Canada. We are more than happy enhance where applicable or need more clarity.

Regards,
        Greg