[netmod] Comments on draft-tissa-netmod-oam-01

"Nobo Akiya (nobo)" <nobo@cisco.com> Fri, 04 July 2014 17:08 UTC

Return-Path: <nobo@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D71B2B15 for <netmod@ietfa.amsl.com>; Fri, 4 Jul 2014 10:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level:
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 QCm4E3W2Zj56 for <netmod@ietfa.amsl.com>; Fri, 4 Jul 2014 10:08:49 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C401B280F for <netmod@ietf.org>; Fri, 4 Jul 2014 10:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2817; q=dns/txt; s=iport; t=1404493729; x=1405703329; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=vdWTpQGfTnUAqexIjydPRAOFc+MCKloKa69ZAgn7pGo=; b=WLj277o87qkg9RwSBBX1rVcV6NNMduMyFWxtus8oLmx1v1FkN9ORmHtt rha1rD8YT+Bq1OIZmm3upjaUahU5D5kXGHsjQUVAKcNGyM6RhxUrJNGxp +/w6Ie+2HTIU5ylviS5z8m9IcLIg7tJ4RkpRobBLCV/iWtwyqLp/2tt5l 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAIjetlOtJA2K/2dsb2JhbABQCoJqJIEfDcYrAYELFnWEBQEEOisUEgEqFEImAQQODYg6AcpbF45GKzGDNIEWBa8Cg0OCMA
X-IronPort-AV: E=Sophos;i="5.01,602,1400025600"; d="scan'208";a="58373222"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 04 Jul 2014 17:08:48 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s64H8mSk026471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <netmod@ietf.org>; Fri, 4 Jul 2014 17:08:48 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 12:08:48 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
Thread-Topic: Comments on draft-tissa-netmod-oam-01
Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQ==
Date: Fri, 04 Jul 2014 17:08:47 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E25BFFE@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.212.73]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AcGzLSiE5ql8VgUqYo93g6OCJtc
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: [netmod] Comments on draft-tissa-netmod-oam-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 17:08:50 -0000

Hi Tissa, authors,

First of all, intent of this document seems widely beneficial. I am interested to see how and In what form this document will progress.

Please find below few comments I have on the draft-tissa-netmod-oam-01, from a quick look at the document.


Comment #1: Section 6

[snip]
     typedef CCM-Interval {
       default "interval-1min";
       type enumeration {
         enum "interval-invalid" {
           value 0;
         }
         ...
         enum "interval-10min" {
           value 7;
         }
       }
       ...
     }
[snip]

When considering all OAM tools out there, defining a hard coded set of intervals (via enum) may not be a good idea. BFD implementations (SW/HW) springs to my mind immediately. For HW based BFD, BFD WG is working on an informational document for recommended set of intervals: draft-ietf-bfd-intervals. However, intervals outside of that set can still be implemented by vendors for HW based BFD. SW based BFD, obviously, has much more flexibility in the range of intervals to use. A better approach may be to change above from enum to identify ref (or something else) which can be augmented.


Comment #2: Section 6

[snip]
     typedef ecmp-choices {
       type enumeration {
         enum "ecmp-use-platform-hash" {
           value 0;
         }
         enum "ecmp-use-round-robin" {
           value 1;
         }
       }
     }
[snip]
                 leaf ecmp-choice {
                   config true;
                   type ecmp-choices;
                   description
                     "0 means use the specified interface
                      1 means use round robin";
                 }
[snip]

Above two seems a bit conflicting for the value of zero(0). Former states that zero(0) indicates usage of platform hash but the latter indicates that specific interface is used (i.e. not hashed?). Thinking about this, I believe "ecmp-choices" is overloaded. You actually want to be able to describe 3 different things here.

1. Configuring a specific load balancing technique on a system (ex: EL, round-robin or something else).
2. Describing the output behavior on the OAM instance (ex: out to specific interface vs. load balanced).
3. Describe the setting on the path discovery OAM instance (ex: LSP tree trace using multipath 2, 4, 8, 9, 10).

Perhaps a different object for each may be a good idea. (2) can be an enum but it'll be beneficial to be able for various OAM tools to augment (1) and (3).


Comment #3: Section 6

[snip]
     typedef oam-counter32 {
       type yang:zero-based-counter32;
       description
         "defines 32 bit counter for OAM";
     }
[snip]

No 64 bit counter?


Thanks!

-Nobo