Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)
Martin Bjorklund <mbj@tail-f.com> Thu, 14 December 2017 17:42 UTC
Return-Path: <mbj@tail-f.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 C541412943E; Thu, 14 Dec 2017 09:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 1q68i14qIM5m; Thu, 14 Dec 2017 09:42:20 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 18AA2129439; Thu, 14 Dec 2017 09:42:20 -0800 (PST)
Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id CB07D1AE0144; Thu, 14 Dec 2017 18:42:17 +0100 (CET)
Date: Thu, 14 Dec 2017 18:42:17 +0100
Message-Id: <20171214.184217.2108989131786731949.mbj@tail-f.com>
To: ludwig@clemm.org
Cc: bclaise@cisco.com, iesg@ietf.org, draft-ietf-i2rs-yang-l3-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org, shares@ndzh.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <037301d374fb$321cfc10$9656f430$@clemm.org>
References: <151325119823.6222.15937797893027104434.idtracker@ietfa.amsl.com> <037301d374fb$321cfc10$9656f430$@clemm.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/OSagNU5UdUMaiYgF-u8rLdJFiPw>
Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)
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: Thu, 14 Dec 2017 17:42:23 -0000
Hi, "Alexander Clemm" <ludwig@clemm.org> wrote: > Hi Benoit, > > I am not sure I understand your comment? I think the issue is that the leaf-list router-id should be of type yang:dotted-quad, and not inet:ip-address. > I was referring to the typedef > router-id, which we define in example-ospf-topology. There is no such typedef. There's an area-id though. /martin We made many changes > to make it clear that this is just an example, not a part of the actual > model, reflected in the description, naming, removal of contact and revision > information, etc. > > The tree diagram in section 5 is for the ietf-l3-unicast-topology module. > It is not part of an example. The same is true for the grouping > l3-node-attributes. It is part of the model. > > The example-ospf-topology model serves as an example as to how the model > might be refined/extended for other topologies. As stated: "This module is > intended to serve as an example that illustrates how the general topology > model can be refined across multiple levels." The sentence at the top of > the section "Extending the model - Example OSPF Topology - Model Overview" > states (slightly rephrased with inserted ", in this case") to "The following > model shows how the Layer 3 Unicast topology model can be extended, in this > case to cover OSFP topologies." > > Does this clarify or did you mean something else? > > Thanks > --- Alex > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, December 14, 2017 3:33 AM > To: The IESG <iesg@ietf.org> > Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; > i2rs-chairs@ietf.org; shares@ndzh.com > Subject: [i2rs] Benoit Claise's Discuss on > draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS) > > Benoit Claise has entered the following ballot position for > draft-ietf-i2rs-yang-l3-topology-14: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > We're making progress. Thanks. > > >> > >> 4. > >> > >> leaf-list router-id { > >> type inet:ip-address; > >> description > >> "Router-id for the node"; > >> } > >> > >> My initial DISCUSS was: We don't want to wait for > >> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, > >> we should expedite this publication), but any good reason why this is > >> aligned with its definition? > >> typedef router-id { > >> type yang:dotted-quad; > >> description > >> "A 32-bit number in the dotted quad format assigned to each > >> router. This number uniquely identifies the router within an > >> Autonomous System."; > >> } > >> > >> My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, > >> it makes sense to import its router-id > > > > <ALEX> This is only used in the example. The point of the example is > > to show how the model can be extended, not to define something > > normative, hence I don't think there is a need to introduce a > > dependency here which would only be distracting. > > </ALEX> > Can you help me understand how this is an example? > Section 5 > > module: ietf-l3-unicast-topology > augment /nw:networks/nw:network/nw:network-types: > +--rw l3-unicast-topology! > augment /nw:networks/nw:network: > +--rw l3-topology-attributes > +--rw name? string > +--rw flag* l3-flag-type > augment /nw:networks/nw:network/nw:node: > +--rw l3-node-attributes > +--rw name? inet:domain-name > +--rw flag* node-flag-type > +--rw router-id* inet:ip-address > +--rw prefix* [prefix] > +--rw prefix inet:ip-prefix > +--rw metric? uint32 > +--rw flag* prefix-flag-type > > And section 6: > > grouping l3-node-attributes { > description "L3 node scope attributes"; > container l3-node-attributes { > description > "Containing node attributes"; > leaf name { > type inet:domain-name; > description > "Node name"; > } > leaf-list flag { > type node-flag-type; > description > "Node flags"; > } > leaf-list router-id { > type inet:ip-address; > description > "Router-id for the node"; > } > list prefix { > key "prefix"; > description > "A list of prefixes along with their attributes"; > uses l3-prefix-attributes; > } > } > } > > A different view at > https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-l3-unicast > -topology# > > > > > _______________________________________________ > 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] Benoit Claise's Discuss on draft-ietf-i2rs… Benoit Claise
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Alexander Clemm
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Martin Bjorklund
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Benoit Claise
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Alexander Clemm
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Alexander Clemm
- Re: [i2rs] Benoit Claise's Discuss on draft-ietf-… Benoit Claise