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

["Tissa Senevirathne (tsenevir)" <[e-mail]>]

Hi Nobo

Thanks for the comments, please see in-line

-----Original Message-----
From: Nobo Akiya (nobo) 
Sent: Friday, July 04, 2014 10:09 AM
To: Tissa Senevirathne (tsenevir)
Cc: [e-mail]
Subject: Comments on draft-tissa-netmod-oam-01

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.

[Answer] good point shall update in the next revision

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).
[Answer] agree on #1 and #2, let me think how to  best bring that in into the next revisions. #3 is part of flow-entropy discovery, which is independent of how it is treated. Way it is done is to have each of the technology to have its specific way of ECMP discovery, which is more like an RPC command. In the base YANG model, use can populate the flow entropy why XML imterface and #1 and #2 will dictates the behavior.

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?

[Answer] most counters in CFM are 32 bit hence taken this. But we can extend to 64 bit very easily. We can consider for next revision making the counters 64 bit.

Thanks!

-Nobo