Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Robert Wilton <rwilton@cisco.com> Fri, 23 June 2017 16:37 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431E71296B3 for <i2rs@ietfa.amsl.com>; Fri, 23 Jun 2017 09:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 etkL3buq17bh for <i2rs@ietfa.amsl.com>; Fri, 23 Jun 2017 09:37:19 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF95C1200B9 for <i2rs@ietf.org>; Fri, 23 Jun 2017 09:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5967; q=dns/txt; s=iport; t=1498235838; x=1499445438; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WMOrQWQG7jxIIbrVaafGQG4irYrDHu1r3+Z5VqcWL0s=; b=kJXlF67v77dUDs0oLR5wLfgZatE/zF0M98DA4mrVw1iPJYJHr02Iri8H 0xkScwYiZLWTF+nAuUFmokYP5qKOqQza685I9C3oP9A21J8wZA5n610sA n4HBkOBJmbK4OgDpxojVyHAeOh9Ft4QePq7/Vwk+YOdXqXMmQzzA11u/U 8=;
X-IronPort-AV: E=Sophos;i="5.39,379,1493683200"; d="scan'208";a="655635406"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2017 16:37:17 +0000
Received: from [10.61.196.171] ([10.61.196.171]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v5NGbGb7028403; Fri, 23 Jun 2017 16:37:16 GMT
To: Alexander Clemm <ludwig@clemm.org>, i2rs@ietf.org
References: <149810775944.30654.3855289160631916559@ietfa.amsl.com> <01a101d2eb18$8efea040$acfbe0c0$@clemm.org> <37626ce1-f10e-0357-e749-cfa9de40951a@cisco.com> <004c01d2ec3d$839a1880$8ace4980$@clemm.org>
Cc: 'Nitin Bahadur' <nitin_bahadur@yahoo.com>, 'Russ White' <russ@riw.us>, 'Xufeng Liu' <Xufeng_Liu@jabil.com>, hari@packetdesign.com, "'Jan Medved (jmedved)'" <jmedved@cisco.com>, robert.varga@pantheon.sk, 'Susan Hares' <shares@ndzh.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <57e09803-3fb5-c4aa-f274-a53871a2dee2@cisco.com>
Date: Fri, 23 Jun 2017 17:37:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <004c01d2ec3d$839a1880$8ace4980$@clemm.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/1TL0v69orVp0tGqsbV8TwUY6Dww>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 16:37:22 -0000

Hi Alex,

Good questions, please see inline ...


On 23/06/2017 17:26, Alexander Clemm wrote:
> Hi Robert,
>
> We will do whatever is required to make the model future proof.
>
> However, I am not quite sure of the particular ask.  Perhaps this is my
> limited understanding of NMDA.  The following is really more of an NMDA
> question: why would we require to duplicate the entire model under a -state
> namespace, when we have different datastores and e.g. what is contained in
> operational is "by definition" read-only?  (Data that originated from
> configuration is marked as intended)  What would really be gained from that?
This extra -state tree is an interim solution only.  I.e. it is to make 
the NMDA model usable today on current devices that don't yet support 
the operational datastore, rather than having to wait for NMDA 
implementations to be available before the models are usable.

Once the devices support NMDA that they (probably) wouldn't implement 
the extra "-state" module, as you say the same information is available 
in the <operational> datastore with the same semantics.

Effectively what is reported in the extra "-state" tree is the same 
information that would be reported in <operational>, and the semantics 
should be the same.

Thanks,
Rob

>
> The issue we were facing in the topology was that different instantiations
> of the same (in the model) list element can originate from an intended
> configuration, or it can be learned.  If it is intended, it shows up in the
> intended / config datastore, but ultimately all topology that is in effect
> shows up in the operational datastore.  It is not clear to me what this NMDA
> guideline would provide in addition; it seems to not be needed and if
> anything seems it would result in redundant operspecification of what's in
> the operational datastore?
>
> --- Alex
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Robert Wilton
> Sent: Thursday, June 22, 2017 3:44 AM
> To: Alexander Clemm <ludwig@clemm.org>; i2rs@ietf.org
> Cc: 'Nitin Bahadur' <nitin_bahadur@yahoo.com>; 'Russ White' <russ@riw.us>;
> 'Xufeng Liu' <Xufeng_Liu@jabil.com>; hari@packetdesign.com; 'Jan Medved
> (jmedved)' <jmedved@cisco.com>; robert.varga@pantheon.sk; 'Susan Hares'
> <shares@ndzh.com>
> Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
>
> Hi Alex,
>
> Do you think that it would be useful if the draft also included the extra
> transient "-state" modules in an appendix (e.g. as per
> draft-dsdt-nmda-guidelines-01 section 2)?
>
> Specifically, I'm thinking to help make the topology module fully usable by
> modules that augment it (e.g. by the TE modules if/when they adopt the NMDA
> conventions), until NMDA implementations before widely available.
>
> Thanks,
> Rob
>
>
> On 22/06/2017 06:29, Alexander Clemm wrote:
>> Hello I2RS Working Group,
>>
>> This draft contains the updates to topology model as discussed in Chicago.
>> This concerned the issue about how to deal with the fact that we can
>> have configurable overlay topologies that are layered on top of
>> discovered, or "learned", underlay topologies.  The solution simply relies
> on the the
>> revised datastore architecture.   The "server-provided" data node has been
>> removed; other than that the structure of the model can remain exactly
>> the same.  The text has been updated accordingly to provide the
> explanations.
>> --- Alex
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: Wednesday, June 21, 2017 10:03 PM
>> To: i-d-announce@ietf.org
>> Cc: i2rs@ietf.org
>> Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Interface to the Routing System of
>> the IETF.
>>
>>           Title           : A Data Model for Network Topologies
>>           Authors         : Alexander Clemm
>>                             Jan Medved
>>                             Robert Varga
>>                             Nitin Bahadur
>>                             Hariharan Ananthakrishnan
>>                             Xufeng Liu
>> 	Filename        : draft-ietf-i2rs-yang-network-topo-13.txt
>> 	Pages           : 35
>> 	Date            : 2017-06-21
>>
>> Abstract:
>>      This document defines an abstract (generic) YANG data model for
>>      network/service topologies and inventories.  The model serves as a
>>      base model which is augmented with technology-specific details in
>>      other, more specific topology and inventory models.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-13
>> https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-network-top
>> o-13
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-13
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
> tools.ietf.org.
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>> .
>>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
> .
>