Re: Opsdir last call review of draft-ietf-rtgwg-lne-model-05

Dan Romascanu <> Fri, 16 February 2018 06:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC03712AF77; Thu, 15 Feb 2018 22:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 N6uj3jbnyh4j; Thu, 15 Feb 2018 22:35:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 652D3124217; Thu, 15 Feb 2018 22:35:58 -0800 (PST)
Received: by with SMTP id i184so2604055qkf.10; Thu, 15 Feb 2018 22:35:58 -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=01zRIBnAO5z6cgTGpSS0gkl1KDiFSJEqa0qE0Kwmsm4=; b=N48Sk7gtqiZDbUkned7s5jzKOu3q+JHZ9ebyKkRBF9URe6Npl/pSpc/pwW+mfzjd81 ExH/XJsHXf7g3hw4i4eLj4Wr8SwjrJJp5UY6I65D5w0fcII1hB9DqRA4lz+d8I/dmIiK ve27CJiAtSDqoqjUCz3CM4XyJG8ftVnhCFAoqLXQuMinKyx6WKNmtoJnVfkaZHlb8N57 LYZ04pK1IqynE4p8o4Zed/libTik7Pd0HHS3ogLXrcMzmopTdWOBggkhgK5XM/C18SiE WqVvfFgWmD5qe3uHl25QxAumxtTLiE6qjbKrfO6eCQ9YpoR9IAQhb0eEVSGLel4M6rdd ej0Q==
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=01zRIBnAO5z6cgTGpSS0gkl1KDiFSJEqa0qE0Kwmsm4=; b=mc34+PuZBIA9KHAc1wMlQTqNHFPZynXWpSdwbwuh/0eyD2tCXMRZiUhVzjsw94Djjr mJA/JdkI6Gpn4ZtnOe5hUDiZgUOc2Bdrue3DqCFka1/b/OObQSDXAE164cd4gCnzqcHb VycWy/gY4tI53YtpQ1PN3uD+ZeJz+wkXhsR7WHsLiDNXfVM8ybMMFFd4Fh/AE7ZrqaK8 vKrMvweoxR8ZVvWhgZA+5MhNygAXOELkjs2FlrGmRonU9+f5NF51FO60X0Yjd3l/WCnp /rAwFxvaNBO8M17pSXpPl21tARHQMJL+ppJnZxQAslnB0IEJClV84tirPsVCd4vO8/Jh /YFQ==
X-Gm-Message-State: APf1xPB//2xMMLGG1qMHbVA7wjtRpBvf8NZgIWGJLTmjsBEnKRx7Wv++ qLbbAAiLnKXrJF+07Fm4L5GJGmWt1ULzTC2KsVkTJw==
X-Google-Smtp-Source: AH8x224XHw6Xrd7J+Ael9hUObdIWT1AfTOMuShC3+rHI2X7liPFHJeL+swOQYioDKc6D8JHXIKVakBzuIediERWvL3U=
X-Received: by with SMTP id e3mr8250436qkb.13.1518762957452; Thu, 15 Feb 2018 22:35:57 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Feb 2018 22:35:56 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Dan Romascanu <>
Date: Fri, 16 Feb 2018 08:35:56 +0200
Message-ID: <>
Subject: Re: Opsdir last call review of draft-ietf-rtgwg-lne-model-05
To: Lou Berger <>
Cc:,, ietf <>,
Content-Type: multipart/alternative; boundary="001a114a7f5893bcbc05654e8e22"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Feb 2018 06:36:01 -0000

Hi Lou,

Thank you for addressing my comments.

About #4. I read again the document and I confess that I missed the two
paragraphs in the Example appendices that begin with 'By using the
implementation of the YANG schema mount, an operator ... '. Sorry for this.
These two paragraphs contain actually most of the information that I was
looking for from the perspective of operators. Maybe bringing them together
in the main document and pointing to the two example appendices would help
from an operator reader point of view, but this is now an editorial and not
a technical comment.



On Thu, Feb 15, 2018 at 3:21 AM, Lou Berger <>; wrote:

> Hi Dan,
>     Sorry about the slow response.
> On 1/25/2018 11:47 AM, Dan Romascanu wrote:
>> Reviewer: Dan Romascanu
>> Review result: Has Issues
>> This is a very useful, well thought and well written document, which
>> reflects
>> work and discussions within the RTG and OPS areas. From an operational
>> point of
>> view it's a very useful tool in support of network operators that will
>> manage
>> and configure logical elements. I believe that the document is almost
>> ready,
>> but there are a number of issues that are worth being discussed and
>> addressed
>> before approval by the IESG.
>> 1. The name and scope of the document as presented in the title and
>> Abstract
>> are not exactly reflecting the content. LNEs are not YANG LNEs as the
>> title
>> says, and the type of module (a YANG module) being defined is not stated
>> in the
>> Abstract.
> This is fixed in -06.
> I would suggest that the document actually defines 'A Data Model and
>> YANG Module for Logical Network Elements'.
> okay, changed to  'YANG Module for Logical Network Elements'.
> 2. There is no reference and relationship definition in the document to the
>> YANG Data Model for Hardware Management defined in
>> Actually the
>> LNEs are
>> almost similar with the 'logical entities' that were dropped from the
>> netmod-entity work. It is expected that in the future network operators
>> will
>> use both data models and the respective YANG modules when managing
>> hardware
>> devices on which logical network entities are being run. Even if this
>> relationship is not explicitly present in the DM, I believe that it needs
>> to be
>> looked at and mentioned in the document.
> okay, it's been added to the example section as a possible model to be
> mounted.
> 3. In Section 2 I see:
>> 'The logical-network-element module augments existing
>>     interface management model by adding an identifier which is used on
>>     physical interface types to identify an associated LNE.'
>> I am wondering why the mentioning of 'physical interface types' here.
>> What if
>> the interface type in not 'physical' representing a protocol layer or
>> sublayer
>> on the device? After all, if all interfaces to be considered were
>> 'physical' we
>> could have augmented the entity hardware module rather than the interfaces
>> module, as all physical interfaces are represented there as well.
> excellent catch!  it should just say interfaces, it's up to an
> implementation to choose which can be bound to an LNE.
> 4. Sections 3.2 and 3.3 seem to be written for the benefit and the
>> perspective
>> of the implementations writers rather than of the operators. Are there any
>> hints, advice, or indications for the operators using the module to manage
>> their LNEs? These could be described also in the examples appendices,
>> which are
>> otherwise very useful to illustrate and explain the models.
> I reread these sections as well as the examples and the read to me to be
> almost completely applicable/useful to both client and server - so am at a
> bit of a loss on how best to address this comment. Perhaps I'm just too
> close to the material. Can you provide a specific example of the type of
> improvement you'd like to see?
> Thank you for the comments!
> Lou
>> _______________________________________________
>> rtgwg mailing list