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

"Nobo Akiya (nobo)" <nobo@cisco.com> Thu, 10 July 2014 13:17 UTC

Return-Path: <nobo@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 280C21B289E; Thu, 10 Jul 2014 06:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -112.363
X-Spam-Level:
X-Spam-Status: No, score=-112.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, 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 uflrtYMWvBLe; Thu, 10 Jul 2014 06:17:03 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5C51A01CA; Thu, 10 Jul 2014 06:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7402; q=dns/txt; s=iport; t=1404998226; x=1406207826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tjQ8yhYXe5FDUsjno/cUyQUZLfOi+1T67af9okBpeww=; b=Cv6IlNcGtb9k2vuKSa/5cd/bhEWkAo38ncM6nRMbr5mY8uPAmaG0fP7v pInR9YM8hDb4/K4O34iQM7WmmVf8mpSlja5mq+TahV3VvaQMh4fI4wS7j rGSOlYbYoCDoDltHt1uk66F2tVzGhbvFRtSf3pkd2eHW+5D8xTSNO899U s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FADORvlOtJA2E/2dsb2JhbABPCoJqJIEsgm/DfwEZchZ1hAMBAQEENDEUDAQCAQYCDgMEAQEFBh0FAgIwFAkIAQEEAQ0FCIg6AZIynCEImRgXgSiNQCsxBwaCbTqBFgEErxWDQ4Iw
X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208";a="59762749"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 10 Jul 2014 13:17:06 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6ADH2LI007090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 13:17:02 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 08:17:01 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
Thread-Topic: Comments on draft-tissa-netmod-oam-01
Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQDA2OqgAGTQxQA=
Date: Thu, 10 Jul 2014 13:17:01 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E26257A@xmb-aln-x01.cisco.com>
References: <CECE764681BE964CBE1DFF78F3CDD3941E25BFFE@xmb-aln-x01.cisco.com> <B8F9A780D330094D99AF023C5877DABA84580544@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA84580544@nkgeml501-mbs.china.huawei.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="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/time/CC6rIjFL5FvsW5fA0LVFX_pKvqA
Cc: "time@ietf.org" <time@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [Time] Comments on draft-tissa-netmod-oam-01
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, 10 Jul 2014 13:17:05 -0000

Hi Qin,

Please see in-line with [NOBO].

> -----Original Message-----
> From: Qin Wu [mailto:bill.wu@huawei.com]
> Sent: Tuesday, July 08, 2014 9:10 AM
> To: Nobo Akiya (nobo); Tissa Senevirathne (tsenevir)
> Cc: netmod@ietf.org; time@ietf.org
> Subject: RE: Comments on draft-tissa-netmod-oam-01
> 
> Sorry to chime in.
> See some comments inline below.
> -----邮件原件-----
> >发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Nobo Akiya
> (nobo)
> >发送时间: 2014年7月5日 1:09
> >收件人: Tissa Senevirathne (tsenevir)
> >抄送: netmod@ietf.org
> >主题: [netmod] 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.
> 
> 
> >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).
> 
> [Qin]: are you proposing to replace ecmp-use-platform-hash with EL and
> have the following change to ecmp-choices typdef NEW TEXT:

[NOBO] We should probably take a step back, and decide if configuring load balancing behaviors on systems is something that belongs within draft-tissa-netmod-oam or not.

> "
>      typedef ecmp-choices {
>        type enumeration {
>          enum "Entropy Lable" {
>            value 0;
>          }
>          enum "ecmp-use-round-robin" {
>            value 1;
>          }
>        }
>      }
> "
> However draft-tissa also has flow-entropy grouping to be defined "
>      grouping flow-entropy {
>        description
>          "defines the grouping statement for flow-entropy";
>        choice flow-entropy {
>          case flow-entropy-null;
>        }
>      }
> "
> Which make me difficult to understand how flow-entropy grouping is
> related to ecmp-choices
> 
> >2. Describing the output behavior on the OAM instance (ex: out to specific
> interface vs. load balanced).
> 
> [Qin]: I am wondering why not consider input behavior or input key to load
> balancing technique.

[NOBO] The goal here is to describe how OAM packets are sent from the system, so it's not that input behavior but it's the output behavior that we need to describe. Additionally, if the OAM packet is to get load balanced out from the system, then the fields from the packet contents should be used for load balancing, and not a separate input key. We will need to set certain fields of the OAM packets (ex: EL value, IP address, port), so if you meant "input key" to set those fields, then I agree.

> 
> >3. Describe the setting on the path discovery OAM instance (ex: LSP tree
> trace using multipath 2, 4, 8, 9, 10).
> 
> [Qin]: Is this setting on path discovery OAM instance common setting? Or
> different OAM tool have different setting for path discovery mechanism.
> Or you are just talking about different path have different setting?
> I am trying to understand this.

[NOBO] Probably both. At least with RFC4379, it is one mechanism but allows multiple path discovery techniques within it.

> 
> >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).
> 
> [Qin]: I tend to agree with this.

:)

Thanks!

-Nobo