Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt
tom petch <ietfc@btconnect.com> Wed, 20 March 2019 16:18 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560C012AF80 for <idr@ietfa.amsl.com>; Wed, 20 Mar 2019 09:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.246
X-Spam-Level:
X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 H6ENgu84qzNI for <idr@ietfa.amsl.com>; Wed, 20 Mar 2019 09:18:01 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130123.outbound.protection.outlook.com [40.107.13.123]) (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 5D389127598 for <idr@ietf.org>; Wed, 20 Mar 2019 09:18:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S6/81wMKJM07I/ximwfTErhIOn3uTvk9S4MYnqEoQhQ=; b=PJ2uhQdsXw0aHTIuuKOn0aZfNdCrU7SkskNzV/Lfhq1XGDxO+tdz4mHzvLtUfGug9IEQne06EAlZL06PeSWjo+vcYpfMGFpZ6A3nVOgzW2OyJQGVhRa0QNBxaXph4WJWPFLEJtt4wTPPM8QihhX7Uy7ZL+ImwvC1CTbKedjJ/bw=
Received: from VI1PR07MB5744.eurprd07.prod.outlook.com (20.177.202.24) by VI1PR07MB3936.eurprd07.prod.outlook.com (52.134.28.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.11; Wed, 20 Mar 2019 16:17:57 +0000
Received: from VI1PR07MB5744.eurprd07.prod.outlook.com ([fe80::4532:1dbd:fc8e:9bad]) by VI1PR07MB5744.eurprd07.prod.outlook.com ([fe80::4532:1dbd:fc8e:9bad%5]) with mapi id 15.20.1730.013; Wed, 20 Mar 2019 16:17:57 +0000
From: tom petch <ietfc@btconnect.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, Xufeng Liu <xufeng.liu.ietf@gmail.com>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt
Thread-Index: AQHU3zh66C34npzoY0eM11gKVwtxIQ==
Date: Wed, 20 Mar 2019 16:17:57 +0000
Message-ID: <00c601d4df38$24105600$4001a8c0@gateway.2wire.net>
References: <155120498877.852.8582818799698080818@ietfa.amsl.com> <68805692-5B0B-4406-92DD-50529E4F8F8D@gmail.com> <CAEz6PPRvvTXOu7akEQGSCE1J+7TzLgkAOeszLhG3YroxuZ9JWw@mail.gmail.com> <F1E6C050-2592-444C-BBFF-2BD1149D3E48@gmail.com> <CAEz6PPQ1un2i4U3-AYPRS+EEaiRk+N0d-3L5A9U7Kvmg2ti=DQ@mail.gmail.com> <3D940C67-19BB-4A21-BC73-C83F6F554650@cisco.com> <38C42812-2534-452E-BDEB-5D4710BD7CDE@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0442.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::22) To VI1PR07MB5744.eurprd07.prod.outlook.com (2603:10a6:803:98::24)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b59dd079-e726-4f6a-b817-08d6ad4f9d49
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB3936;
x-ms-traffictypediagnostic: VI1PR07MB3936:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <VI1PR07MB3936C3DC03B64741950EB15BA0410@VI1PR07MB3936.eurprd07.prod.outlook.com>
x-forefront-prvs: 098291215C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(376002)(39860400002)(346002)(13464003)(51444003)(189003)(199004)(51914003)(305945005)(966005)(7736002)(486006)(68736007)(106356001)(50226002)(105586002)(3846002)(446003)(6116002)(4326008)(476003)(102836004)(25786009)(8936002)(97736004)(14496001)(9686003)(6512007)(84392002)(53546011)(44736005)(86152003)(6486002)(6306002)(52116002)(76176011)(386003)(6506007)(4720700003)(81686011)(81816011)(6436002)(5660300002)(186003)(66066001)(478600001)(14454004)(62236002)(2906002)(81156014)(26005)(53936002)(6246003)(81166006)(8676002)(14444005)(66574012)(256004)(316002)(86362001)(44716002)(1556002)(229853002)(61296003)(71190400001)(71200400001)(99286004)(93886005)(110136005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3936; H:VI1PR07MB5744.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: W0A+FOldXkI7l81WhFIUZ9zdIYhMbhfnMnOeGJOlRJB5yLlageIStUQPZs+SwHqZ8mZB0v2VJFdkF7AvjwBWpzMoBVqnn/ojWNl/a4HR8ZWk/sG4Egsu0rGX2p+P2vvD8FW4KYXSf9b+KyQizgNANmqRlcGAhzz4OcdvuVyAezJFMbHE2DUqdS9MRrp0Ynw9uBt2a48lsY7N29rJX1HdNRuyHG4/VOht2xrwE79tjenxHSUdKkVKBLmJL1Yb3ZvsXftgcELhf1Y9c208CNWqG5t9My78dokqlc+gS3VeJD22PEchavU+qnGY5qRw7ulYOYZ++kym4QFwGsEwhxNDZT0AoOBlhqRukCplVBrbzbEhv1LA0L3dy2jAqZjx3l8GBsyH3fmPRt2QmOXtvDZYEP7y9KYT7FtxURw0pYD3SHc=
Content-Type: text/plain; charset="utf-8"
Content-ID: <747CD45706E46F4D8F7C01039C08515F@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b59dd079-e726-4f6a-b817-08d6ad4f9d49
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 16:17:57.4821 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3936
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2KPOrw3L3E90sLkYYcqF9uFJi-E>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 16:18:04 -0000
----- Original Message ----- From: "Rajiv Asati (rajiva)" <rajiva@cisco.com> To: "Acee Lindem (acee)" <acee@cisco.com>; "Xufeng Liu" <xufeng.liu.ietf@gmail.com>; "Mahesh Jethanandani" <mjethanandani@gmail.com> Cc: <idr@ietf.org> Sent: Wednesday, March 20, 2019 3:04 PM Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt > Indeed. > > It would be useful to have routing protocol independent structure for address-family and minimize the duplication in abstraction (and implementations). If you can agree what an address family is. I know it as part of BGP and then came across it in other YANG modules and ended up concluding that there was no common ground as to what an address family is. I think that RFC8349 got it wrong in its use of address family. So, define an address family and I will show you why it does not apply in all cases! Tom Petch > -- > Cheers, > Rajiv > > From: Idr <idr-bounces@ietf.org> on behalf of "Acee Lindem (acee)" <acee@cisco.com> > Date: Wednesday, March 20, 2019 at 10:57 AM > To: Xufeng Liu <xufeng.liu.ietf@gmail.com>, Mahesh Jethanandani <mjethanandani@gmail.com> > Cc: "idr@ietf.org" <idr@ietf.org> > Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt > > I agree – the BGP hierarchy is wrong. Address-family is generally higher both abstractly and in implementations. > Thanks, > Acee > > From: Idr <idr-bounces@ietf.org> on behalf of Xufeng Liu <xufeng.liu.ietf@gmail.com> > Date: Wednesday, March 20, 2019 at 10:30 AM > To: Mahesh Jethanandani <mjethanandani@gmail.com> > Cc: IDR List <idr@ietf.org> > Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt > > Hi Mahesh, > > On Tue, Mar 19, 2019 at 6:48 PM Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote: > Hi Xufeng, > > > > On Mar 19, 2019, at 6:31 AM, Xufeng Liu <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>> wrote: > > Hi Mahesh, > > Thanks for the update. > > I'd like to comment on the new changes at a high level: > > > 1) rib extension > > This paradigm is inconsistent with other protocol models like ospf and isis, where the protocol specific routes are kept under the protocol instance tree, not under the /rt:routing/rt:ribs. Based on RFC8349, the /rt:routing/rt:ribs tree is used to model the routes per routing instance, which is better mapped to the Route Manager (whose name varies depending on the implementations). > > > While that might be true, routes in the BGP model currently are maintained at the per-address family level. > > It is fine that routes are maintained at per-address family level, which is also done by other routing protocols. The question is how the tree hierarchy is structured. > OSPF model has the following: > > module: ietf-routing > +--rw routing > | +--rw control-plane-protocols > | | +--rw control-plane-protocol* [type name] > | | +--rw ospf:ospf > | | +--ro ospf:protected-routes {fast-reroute}? > | | | +--ro ospf:af-stats* [af prefix alternate] > | | | +--ro ospf:af iana-rt-types:address-family > | | +--ro ospf:unprotected-routes {fast-reroute}? > | | | +--ro ospf:af-stats* [af prefix] > | | | +--ro ospf:af iana-rt-types:address-family > | | +--ro ospf:local-rib > | | | +--ro ospf:route* [prefix] > | | | +--ro ospf:prefix inet:ip-prefix > | | | +--ro ospf:next-hops > | | +--ro ospf:statistics > | | +--ro ospf:database > | | | +--ro ospf:as-scope-lsa-type* [lsa-type] > > ISIS model has the following: > > module: ietf-routing > +--rw routing > | +--rw control-plane-protocols > | | +--rw control-plane-protocol* [type name] > | | +--rw isis:isis > | | +--rw isis:interfaces > | | | +--rw isis:interface* [name] > | | | +--rw isis:name if:interface-ref > | | +--ro isis:database > | | | +--ro isis:level-db* [level] > | | | +--ro isis:level level-number > | | | +--ro isis:lsp* [lsp-id] > | | | +--ro isis:decoded-completed? boolean > | | | +--ro isis:raw-data? yang:hex-string > | | | +--ro isis:lsp-id lsp-id > | | +--ro isis:local-rib > | | | +--ro isis:route* [prefix] > | | | +--ro isis:prefix inet:ip-prefix > | | | +--ro isis:next-hops > > > This BGP model uses operational state sub-tree mostly from the OpenConfig model, but OpenConfig does not augment ietf-routing and uses separate global tree. If we keep the OpenConfig sub-tree, it would be better to structure the BGP rip as following: > > module: ietf-routing > +--rw routing > | +--rw control-plane-protocols > | | +--rw control-plane-protocol* [type name] > +--rw bgp:bgp > +--rw global! > +--rw neighbors > | +--rw neighbor* [neighbor-address] > +--rw peer-groups > +--rw peer-group* [peer-group-name] > +--ro bgp-rib > +--ro attr-sets > | +--ro attr-set* [index] > | +--ro index uint64 > +--ro afi-safis > +--ro afi-safi* [afi-safi-name] > +--ro afi-safi-name identityref > +--ro ipv4-unicast > | +--ro loc-rib > | | +--ro routes > | | +--ro route* [prefix origin path-id] > +--ro ipv6-unicast > | +--ro loc-rib > | | +--ro routes > | | +--ro route* [prefix origin path-id] > +--ro ipv4-srte-policy > | +--ro loc-rib > | | +--ro routes > | +--ro neighbors > | +--ro neighbor* [neighbor-address] > +--ro ipv6-srte-policy > +--ro loc-rib > | +--ro routes > > Thanks, > - Xufeng > > > 2) module ietf-bgp is missing > > Is it intentional to remove the main module ietf-bgp? The description says that bgp model augments the ietf-routing, but there is no such an augment statement in the draft. I assume that the augment statement is in the main module ietf-bgp. > > > That was indeed a cut-and-paste error. The next version of the draft will have the ietf-bgp module. > > Thanks. > > > > > Thanks, > - Xufeng > > On Tue, Feb 26, 2019 at 1:20 PM Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote: > This update of the draft adds support for: > > - augmentation of the Routing Management Model. > - augmentation of the routing policy model > - support for RIB > > Comments welcome. > > > On Feb 26, 2019, at 10:16 AM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Inter-Domain Routing WG of the IETF. > > > > Title : BGP YANG Model for Service Provider Networks > > Authors : Keyur Patel > > Mahesh Jethanandani > > Susan Hares > > Filename : draft-ietf-idr-bgp-model-04.txt > > Pages : 138 > > Date : 2019-02-26 > > > > Abstract: > > This document defines a YANG data model for configuring and managing > > BGP, including protocol, policy, and operational aspects based on > > data center, carrier and content provider operational requirements. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-04 > > > > > > 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<http://tools.ietf.org/>. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org<mailto:Idr@ietf.org> > > https://www.ietf.org/mailman/listinfo/idr > > Mahesh Jethanandani > mjethanandani@gmail.com<mailto:mjethanandani@gmail.com> > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org<mailto:Idr@ietf.org> > https://www.ietf.org/mailman/listinfo/idr > > Mahesh Jethanandani > mjethanandani@gmail.com<mailto:mjethanandani@gmail.com> > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
- [Idr] I-D Action: draft-ietf-idr-bgp-model-04.txt internet-drafts
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Mahesh Jethanandani
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Dale W. Carder
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Xufeng Liu
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Mahesh Jethanandani
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Mahesh Jethanandani
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Xufeng Liu
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Acee Lindem (acee)
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Rajiv Asati (rajiva)
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… tom petch
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Jeff Tantsura
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Qin Wu
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Mahesh Jethanandani
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Mahesh Jethanandani
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Susan Hares
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Susan Hares
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Susan Hares
- Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-04… Acee Lindem (acee)