Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)

Alexander Clemm <alexander.clemm@huawei.com> Thu, 14 December 2017 18:24 UTC

Return-Path: <alexander.clemm@huawei.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 472C512704A; Thu, 14 Dec 2017 10:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 52TlfrR7QVPx; Thu, 14 Dec 2017 10:24:03 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56851200FC; Thu, 14 Dec 2017 10:24:02 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 82B79CE825921; Thu, 14 Dec 2017 18:23:57 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 14 Dec 2017 18:23:52 +0000
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.4]) with mapi id 14.03.0361.001; Thu, 14 Dec 2017 10:23:49 -0800
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, "ludwig@clemm.org" <ludwig@clemm.org>
CC: "draft-ietf-i2rs-yang-l3-topology@ietf.org" <draft-ietf-i2rs-yang-l3-topology@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "i2rs-chairs@ietf.org" <i2rs-chairs@ietf.org>
Thread-Topic: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)
Thread-Index: AQHTdM9kzzHfyGDkLkmR48fkXp0Tp6NDkt4AgAAPY4CAAALnAP//gOuA
Date: Thu, 14 Dec 2017 18:23:49 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD38E8@sjceml521-mbx.china.huawei.com>
References: <151325119823.6222.15937797893027104434.idtracker@ietfa.amsl.com> <037301d374fb$321cfc10$9656f430$@clemm.org> <20171214.184217.2108989131786731949.mbj@tail-f.com> <75ac9315-3e6b-949a-28c1-80b6001710ce@cisco.com>
In-Reply-To: <75ac9315-3e6b-949a-28c1-80b6001710ce@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.209.217.77]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD38E8sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/u99NnLf6xCT8S87NOHom_o3AoUI>
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 18:24:06 -0000

OK, thanks for mentioning inet:ip-address.  The example (that you were referring to in the email) does have dotted-quad already, so I did not know what you meant.

I will change from inet:ip-address to yang:dotted-quad and refer to imported router-id typedef.  And I assume we are now good with the example.  Is there anything else?  Will post -16 by tomorrow.

Thanks
--- Alex

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Thursday, December 14, 2017 9:53 AM
To: Martin Bjorklund <mbj@tail-f.com>; ludwig@clemm.org
Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org; iesg@ietf.org; shares@ndzh.com; i2rs-chairs@ietf.org
Subject: Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)

On 12/14/2017 6:42 PM, Martin Bjorklund wrote:

Hi,



"Alexander Clemm" <ludwig@clemm.org><mailto: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.
Right, imported from ietf-routing-types,  in https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-17

     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.";

     }
Regards, Benoit






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><mailto:iesg@ietf.org>

Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org<mailto:draft-ietf-i2rs-yang-l3-topology@ietf.org>; i2rs@ietf.org<mailto:i2rs@ietf.org>;

i2rs-chairs@ietf.org<mailto:i2rs-chairs@ietf.org>; shares@ndzh.com<mailto: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<mailto:i2rs@ietf.org>

https://www.ietf.org/mailman/listinfo/i2rs



_______________________________________________

i2rs mailing list

i2rs@ietf.org<mailto:i2rs@ietf.org>

https://www.ietf.org/mailman/listinfo/i2rs



.