Re: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Greg Mirsky <> Wed, 07 February 2018 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 310B212D77E; Wed, 7 Feb 2018 07:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ctqp-8jdh2_i; Wed, 7 Feb 2018 07:05:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E126D126B72; Wed, 7 Feb 2018 07:05:32 -0800 (PST)
Received: by with SMTP id q17so1779762lfa.9; Wed, 07 Feb 2018 07:05:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ee5rdzD8GFJA5uuUu/TCqsE8ICxwgo4mTdIP+P/Ytc=; b=OQQhnjR0Q3WQU80fKqD72zzMwRs+A/9iijL0i1hrmFHQ81qiKbjq6CJoaLauxlXAkk olZ+8VBaHneAxIW+VeGAxB09Lf5WXLRdqZyh8mc4Zb8f2DviLuBsrBPY0wtIplwVGUM+ mNG+HqlYMI5V2iyYvjUMIr1cT6cawflCz8AaO1VxFDYQOYStsVu+Z0026VlcvMqpnWUf 7aStq5VVq8ipyHHfQBm4KpgGSsg/1VMPPTOdV7EZ7Em4Mo2hrCTv7mCNSIZoCei3fMYC BVaXpCTfY1kspecOZmCYDFfFsfM2AEAfWayvTm+LVkc8JGnvw4/Fv7lecmfHnY6AK4mo 3rTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ee5rdzD8GFJA5uuUu/TCqsE8ICxwgo4mTdIP+P/Ytc=; b=snBvuMR9IQT1fzu+61zq/KgLwF7AQ0g3uxch7IIJEXmVGAWcXJSWJ/ndGU3vd1Oa50 GoTiJ4UHmjjL+91jAm+/7G1cM61Wdr/9FSaZsOdnY+qIhRBZyXGV1O8lZMneaZWjU8kj M1wIEj6wD44gHarPqi87J5cwgYe0oINOh7bydIfOBEpNFXIhNv3gR9D3+wJRPhX4q2nn pNqGs8H0phKSntnWSl2a8jFJ6ELRAKzcN54Gz0O4qkeMflGNNB2SX/E7WEuBCbjJcywE zpSdSrPwsu5BkM5LnajkdqzgqOIEbP2zXdXiHXS1CIl4ZaKN9YP1ZHmXnrWRBqtTvVFf 0SHw==
X-Gm-Message-State: APf1xPADZkTgGcQTL/yhkdWTl/qcDBJmqfDzLCsVkp+sV30sSEPRSxY3 Puo3+nAc+V5lNdwkzT+aJLukjKrsrourDeEKCKQ=
X-Google-Smtp-Source: AH8x225Jgdm50q8ahNwFS6bc+hB5FfwWh9Z1WyOHdcF3ysi+DsxfjElIVdGwUpAwTbsp/kG6YJ3DqcbBaMN4kkchzRA=
X-Received: by with SMTP id c29mr4428807ljd.116.1518015930798; Wed, 07 Feb 2018 07:05:30 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Feb 2018 07:05:30 -0800 (PST)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Wed, 7 Feb 2018 23:05:30 +0800
Message-ID: <>
Cc: IETF-Announce <>, Benoit Claise <>, Ronald Bonica <>,,,
Content-Type: multipart/alternative; boundary="94eb2c1aba685196ee0564a0a0ec"
Archived-At: <>
Subject: Re: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Feb 2018 15:05:41 -0000

 Dear Authors, et. al,
thank you for your dedication to this work. Please kindly consider my
comments, as I've shared them January 31st, for the IETF LC :
- this document introduces YANG data model of connection-oriented OAM
protocols. I couldn't find the definition or reference to normative
definition of the connection-oriented OAM. As we've discussed, I
believe that the definition of the channel forwarding in G.800 in
section 6.3.1, specifically for connection-oriented packet switching,
is the one we can use similarly to the definition of connectionless
OAM in draft-ietf-lime-yang-connectionless-oam. And the fact that both
documents share one source of definitions, in my view, is advantage of
consistent dictionary.
- "This is the base identy of technology types which are
TRILL,MPLS-TP,vpls etc" Had VPLS been characterized as CO-PS? Not to
get into the discussion, perhaps stop after MPLS-TP be acceptable. And
I encourage to omit other references to VPLS in the document:
            - "... or for VPLS this can be per VPLS instance [RFC6136]."
            - " a VRF for VPLS,"
- what is the benefit to have specific ipv4-address and ipv6-address
in 'choice mep-address' rather than ip-address imported from
- I think that 'leaf packet-size' is related to packet padding, not
the actual size of the test packet as there's always minimum size
determined by the corresponding technology and thus the packet size
cannot be smaller than the minimum size of, for example, LBM. Current
range for the leaf packet-size in rpc continuity-check is 0...10000
and in rpc continuity-verification the range is 64 ... 10000 (why such
inconsistency?). Test packet of 0 bytes doesn't seem practical while
test packet with 0 bytes of padding/payload does. And though we'd like
to use default for zero-touch (almost zero-touch), this is very
technology-specific parameter (compare Ethernet LBM and MPLS LSP

- s/interface)/interface)./
- consistency in using YANG vs. Yang throughout the document should be
- s/../maintenance-domain]/co-oam:mas/co-oam:ma[/../maintenanc
- s/CoS field in MPLS-TP/TC field in MPLS-TP/

On Mon, Feb 5, 2018 at 11:07 PM, The IESG <> wrote:

> The IESG has received a request from the Layer Independent OAM Management
> in
> the Multi-Layer Environment WG (lime) to consider the following document: -
> 'Generic YANG Data Model for Connection Oriented Operations,
>    Administration, and Maintenance(OAM) protocols'
>   <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> as Proposed
>   Standard
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> mailing lists by 2018-02-19. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
> Abstract
>    This document presents a base YANG Data model for connection oriented
>    OAM protocols.  It provides a technology-independent abstraction of
>    key OAM constructs for such protocols.  The model presented here can
>    be extended to include technology specific details.  This guarantees
>    uniformity in the management of OAM protocols and provides support
>    for nested OAM workflows (i.e., performing OAM functions at different
>    levels through a unified interface)
>    The YANG model in this document conforms to the Network Management
>    Datastore Architecture defined in
>    [I-D.ietf-netmod-revised-datastores].
> The file can be obtained via
> tion-oriented-oam-model/
> IESG discussion can be tracked via
> tion-oriented-oam-model/ballot/
> No IPR declarations have been submitted directly on this I-D.
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     rfc6905: Requirements for Operations, Administration, and Maintenance
> (OAM) in Transparent Interconnection of Lots of Links (TRILL)
> (Informational - IETF stream)
> _______________________________________________
> Lime mailing list