Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05

Huub van Helvoort <huubatwork@gmail.com> Sat, 27 June 2015 08:24 UTC

Return-Path: <huubatwork@gmail.com>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A1E1B3231 for <lime@ietfa.amsl.com>; Sat, 27 Jun 2015 01:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.424
X-Spam-Level: *
X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
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 4HnpJ-r_gymq for <lime@ietfa.amsl.com>; Sat, 27 Jun 2015 01:24:22 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7C61B3230 for <lime@ietf.org>; Sat, 27 Jun 2015 01:24:22 -0700 (PDT)
Received: by wgck11 with SMTP id k11so104721949wgc.0 for <lime@ietf.org>; Sat, 27 Jun 2015 01:24:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=APSp9M/RobmTokxUoGZ+sWSRug1oLd0TgXSa4htNHkc=; b=rCk2ZHF0PVCOgz0mh2490Olb1wniFcfs6sdoaXFmpzfTlhS9XIaKdiRs2myQ9vh1+T UbgYLpw87XcjUsmmWHmHCtA3U2RxRRb2Ev4rBsvgUVEQ+i61m7BFVavh5xrBdnj9ZLwj /AkEcukuq+3+J/ntYOF6X+SU0AySy26CPswjYKv6BpJbpwt3qspi+neQovH65Fq13fbN trSBie6jwkqk1yS1i/TJoHpx0diDzaTzHwNn+rIeeFNQYYXzUpa47avY3DMR5WSckFCg QZ5QUTHPXENl4ohvY3pzQwCh0NczRKQiQ/mgYLfHZjYCBRoEZ00g6FodHkWA51ir4UQ1 JDAw==
X-Received: by 10.194.205.225 with SMTP id lj1mr9980776wjc.138.1435393460965; Sat, 27 Jun 2015 01:24:20 -0700 (PDT)
Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id p2sm1962879wix.11.2015.06.27.01.24.19 for <lime@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2015 01:24:19 -0700 (PDT)
Message-ID: <558E5DB2.2080009@gmail.com>
Date: Sat, 27 Jun 2015 10:24:18 +0200
From: Huub van Helvoort <huubatwork@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: lime@ietf.org
References: <558A543A.3090106@jp.fujitsu.com>
In-Reply-To: <558A543A.3090106@jp.fujitsu.com>
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/lime/NwNFK_arEGpnwmhigB6Ps79UqXQ>
Subject: Re: [Lime] Comments on draft-tissa-lime-yang-oam-model-05
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: huubatwork@gmail.com
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2015 08:24:24 -0000

All,

Some additional remarks on draft-tissa-lime-yang-oam-model-05

In the introduction section:
1.  monitor networks --> 1. monitor connections
this because actually the connections in the network are monitored.

2. isolation --> localisation
it is not always possible to isolate a fault, but if one can locate it
one can take proper consequent actions (like isolation)

3. measure performance --> 3. monitor performance (loss, delay).
monitor implies that consequent actions may/will be taken/

Proper expansion of MEP (from 802.1):

3.93 Maintenance association End Point (MEP)

Proper expansion of MIP (from 802.1Q):

3.98 Maintenance domain Intermediate Point (MIP)

Best regards, Huub.

BTW: the latter two remarks are also applicable to
draft-tissa-nvo3-oam-fm-02 IEEE Std 802.1Q™-2011, IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks
IEEE Std 802.1Q™-2011, IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks
-------
Hi all,

The authors of draft-tissa-lime-yang-oam-model asked for comments to the authors of draft-lam-lime-summary-l0-l2-layer-independent.
So far, I, as a co-author of draft-lam..., have collected comments among us and here are attached the comments as below.

I hope the comments will contribute the progress of draft-tissa-lime-yang-oam-model.


Regards,
Yuji

------
Comments

1. Common OAM architecture

This document defines the relationship of different OAM YANG model that covers MPLS, IP, NVO3, TRILL and so on. But there seems to be no Common OAM architecture for them, but the common OAM architecture in this draft adapts those for Ethernet (IEEE802.1Q and ITU-T G.8013/Y.1731) or MPLS-TP (RFC 6371).
Given that this draft covers only Ethernet and MPLS-TP OAM, it would not have any issues. But how about other technologies like IP or (IP/)MPLS? Do they use the architecture same as Ethernet or MPLS-TP?


2. Common tools for OAM

The current draft only describes based on Ethernet CCM so that all the parameters in the draft come basically from those for configuring MEPs of Ethernet (and some for IPv4 and IPv6).
For the definition of Generic OAM, it is required to describe what kind of the tool sets are considered in this draft.
The good example is in Table 7-1 of ITU-T G.8113.2.


3. Configuration data structure for MEP (section 4.3)

Reading MEP in ietf-gen-oam, the MEP is regarded as bidirectional end point that includes both generation process and reception process.
ITU-T G.8052 (or ONF work for OAM) defines MEP that includes generation process and reception process (i.e. Source and Sink).
In fact, Ethernet CCM works as one-way (called Dual-ended) so that the clear distinction for MEP source and sink is defined in G.8052.
This draft should be consider MEP source and sink.
Also co-located sink MEP in case of a bi-directional connection should be considered.


4. Output in rpcs
Output in rpcs includes performance monitoring (i.e Delay measurement, Loss measurement)related configuration data, But it looks as a part of CC and CV functionalities.
As seen in ITU-T G.8013 (DM, LM, and Synthetic LM) and PM for Trill OAM, the output (PM related configuration data) should be regarded in more generic way.
BTW, the YANG for the output says:

    output {
      uses monitor-stats {
        description
          "Stats of continuity check is same as that of
           monitor sessions";
      }
    }
  }


What does mean by "Stats of continuity check is same as that of monitor sessions"?


5. Defect type

It describes as:
   notifications:
      +---n defect-condition-notification
         +--ro technology          identityref
:
         +--ro defect-type?        identityref

The authors are interested in what kind of types are in for defect-type.
In general, like section 4.4 (rpc), it is expected that the detailed/clarified section for notification is added.


6. Comments on Introduction (Section 1)

Three comments:

(1) Three bullets should be updated as:
1.  monitor networks --> 1. monitor connections
2. isolation --> localization
3. measure performance --> 3. monitor performance (loss, delay).

(2) "The YANG data model presented in this document occurs at the management layer."
should this be:
"The YANG data model presented in this document exists at themanagement layer."

(3) The sentence in the last paragraph "This ability to go up and down to different layers" is not a good description for "nesting".


7. Comment on Terminology (Section 2.1)

Since the model is based on IEEE802.1Q, the expansion for MEP and MIP should follow IEEE802.1Q.


8. Comments on Overview of the OAM Model (Section 4)

Three comments:

(1) What is a "parallel vertical"?
(2) What is "rpc"? (expansion is missing) And note that both rpc and RPC is used throughout the draft.
(3) The sentence "Under each MA, there can be two or more MEPs "implies that the two MEPs are the source and sink of a connection, Does this mean that for a bi-directional (transport) connection there are two MAs?


9. Comment on OAM data hierarchy (Section 4.5)

It is suggested to move the first part (from:  The following notations" until "leafs and leaf-lists ") to the front of section 4, because the notation is also used in sections 4.1... 4.4.
------
-- 
*****************************************************************
              请记住,你是独一无二的,就像其他每一个人一样