From nobody Wed Oct 1 06:40:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926AC1A044F for ; Wed, 1 Oct 2014 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dUIDY3w-e1oq for ; Wed, 1 Oct 2014 06:40:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272C51A03D0 for ; Wed, 1 Oct 2014 06:40:20 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB218.namprd05.prod.outlook.com (10.255.206.20) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 13:39:57 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 13:39:55 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 13:39:55 +0000 From: Dean Bogdanovic To: Alia Atlas Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++RqKttL9wxEexAlDYcQgC+ZwbP/0A Date: Wed, 1 Oct 2014 13:39:54 +0000 Message-ID: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(129404003)(189002)(199003)(51704005)(82746002)(104166001)(19580395003)(107046002)(31966008)(87286001)(62966002)(1411001)(2656002)(89996001)(110136001)(4396001)(99396003)(85852003)(120916001)(87936001)(50226001)(83716003)(76176999)(101416001)(57306001)(92726001)(33656002)(88136002)(92566001)(97736003)(19580405001)(93916002)(86362001)(20776003)(76482002)(85306004)(105586002)(66066001)(77156001)(21056001)(36756003)(95666004)(64706001)(15975445006)(10300001)(80022003)(77096002)(50986999)(106116001)(106356001)(99286002)(46102003)(23603001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB218; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QLri3QvV1PZDK-fJVHcg25Qt7BQ Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:40:22 -0000 Hi Alia, today networking devices can be managed in three ways: 1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it. Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices. 2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state.=20 There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms. The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements)=20 At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it. It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot lo= ok for provisioning system and get configuration from a remote location and= then change the state of the device based on it. This has led that 3. some vendors use Linux, allow management via pseudo file system (/proc) where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that. So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed. Hope this helps Dean On Oct 1, 2014, at 12:25 AM, Alia Atlas wrote: > Hi, >=20 > I'd like to really understand why I2RS needs a datastore and what that ac= tually means. > In my initial conception of what an I2RS agent would do for, say, writing= a route in the RIB > model, is that the I2RS agent would simply parse a received request from= a standard format=20 > and model into the internal and pass that to a RIB Manager - just as an O= SPF implementation=20 > might install a route to the RIB manager. An I2RS agent could also query= the RIB Manager to=20 > read routes and there'd be events coming out. >=20 > With the introduction of priorities to handle multi-headed writers and co= llision errors, the I2RS agent would need to store what was written by whic= h client. >=20 > What benefits and rationale does a YANG datastore add? Why does using on= e need to be > standardized? >=20 > I apologize if this seems a naive question, but it's been quite a while s= ince I read up on YANG and NetConf/RestConf. =20 >=20 > Regards, > no-hats Alia >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Oct 1 06:54:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4971A19E6 for ; Wed, 1 Oct 2014 06:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 wm84Ca4AbeOm for ; Wed, 1 Oct 2014 06:54:13 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F5C1A0A6B for ; Wed, 1 Oct 2014 06:54:13 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f10so130219yha.41 for ; Wed, 01 Oct 2014 06:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SJ+5UeI6+u9yjrn25dpLdhEvlYYoWaws/sTQy4j/aa0=; b=HqZgajCinr7ic85gVWgANIPQHFCeW8A4GtnxSRusDT65JmayHufp08Uj46qDUw1A3b 3fWO8C0u9LjvTAipoGIMGalhsEdiCeUPf+Dg9Hwoen+c+AANz4VWBJMxaaCL8q2gRLkK 8e51jqA/p+xujqklyzwxPAa0Zts9nXJFfo0ZVM0/sbHN6/Wn4rAkTdUfyxNtcnXVTlHK Ez3xJfTdpUz8MU7Nu1xaJGbDKONHFtRMF4UAT15cOnG9nZGrt+Jf1xZS03+a/5OQ7Twe TdVoQoIkf2/T4kVF/JGpwQX5wtoO7iWUEoDLueLMFF8JEXeDDEVlTPi/EypsWkcl9/iN eYDw== MIME-Version: 1.0 X-Received: by 10.236.32.4 with SMTP id n4mr79007424yha.16.1412171652490; Wed, 01 Oct 2014 06:54:12 -0700 (PDT) Received: by 10.170.110.72 with HTTP; Wed, 1 Oct 2014 06:54:12 -0700 (PDT) In-Reply-To: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> Date: Wed, 1 Oct 2014 09:54:12 -0400 Message-ID: From: Alia Atlas To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a11c1bae6b56ca105045cd5a9 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CyDf1fCSTFzU_rwif9fz5huhLoI Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:54:16 -0000 --001a11c1bae6b56ca105045cd5a9 Content-Type: text/plain; charset=UTF-8 Hi Dean, Thanks for the explanation. It matches with what I understand for configuration. Where I am confused is why I2RS - which is doing ephemeral only and matches closer to the direct proprietary APIs directly to the routing processes - is being tied up in this. Regards, Alia On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic wrote: > Hi Alia, > > today networking devices can be managed in three ways: > > 1. CLI - is the UI we all know and use it quite heavily. In order for the > device to boot in a known state a set of CLI commands have to be saved > somewhere on the device. For that you have a data store. That data store > can be a flat file or a database. The datastore is then read by network > device daemons which change their state based on it. > > Before the APIs were exposed, TCL/Expect and Perl ruled the automation > world and everything was based on screen scraping. In order to make machine > to machine communication easier, NETCONF was created as a standard protocol > to communicate with the devices. > > 2. via APIs - there are several type of APIs, but most widely available > ones are providing functionalities same as CLI. The difference is that CLI > is human intended and APIs are machine intended. One of the example is > Junos XML APIs, where (almost) each CLI command is represented by XML API. > It still requires knowing how to configure device via CLI and the result of > the application written with such APIs is stored in the data store from > which daemon read how to change their state. > There are some vendors that provide APIs that allow communication with > daemons directly, bypassing management infrastructure, but those are highly > proprietary mechanisms. > The APIs that were released by vendors, were not standardized and each > vendor had different configuration models, so although communication with > devices was standardized, there was no easy way to communicate semantics, > which led to YANG, as standard language that all vendors would understand > and now standardizing configuration and operational model, so same > configuration statement can be sent to all supporting devices and be done > (instead of writing same desired functionality in several configuration > statements) > > At the end it really doesn't matter how you are communicating with the > devices, it really boils down to that you want the device to boot into a > known state. This was done by having a local data store that was containing > set of instructions what state the device should be after reading it. > > It really doesn't matter which mechanism is used (from above 2), > configuration data has to be provided. Historically, data was on the > device, as the connection between device and the network management was > slow. Today (like in MSDC), devices don't have local configuration, those > devices when boot look for provisioning system and get configuration from a > remote location and then change the state of the device based on it. This > has led that > > 3. some vendors use Linux, allow management via pseudo file system (/proc) > > where the state of the device is changed directly without having a need > for data store on the device. You have to keep in mind that only Linux > allows changing the state of non-processes data through /proc. *BSD flavors > don't allow that. > > So today, most network operators (by this I mean any entity that operates > a network, either enterprise or carrier), need to simplify network > management, make it more efficient and that devices will behave very > predictably, so that network is in a known state. Because of the legacy, > this is easiest done by having a local datastore on a device, through which > the state of the device is changed. > > Hope this helps > > Dean > > > On Oct 1, 2014, at 12:25 AM, Alia Atlas wrote: > > > Hi, > > > > I'd like to really understand why I2RS needs a datastore and what that > actually means. > > In my initial conception of what an I2RS agent would do for, say, > writing a route in the RIB > > model, is that the I2RS agent would simply parse a received request > from a standard format > > and model into the internal and pass that to a RIB Manager - just as an > OSPF implementation > > might install a route to the RIB manager. An I2RS agent could also > query the RIB Manager to > > read routes and there'd be events coming out. > > > > With the introduction of priorities to handle multi-headed writers and > collision errors, the I2RS agent would need to store what was written by > which client. > > > > What benefits and rationale does a YANG datastore add? Why does using > one need to be > > standardized? > > > > I apologize if this seems a naive question, but it's been quite a while > since I read up on YANG and NetConf/RestConf. > > > > Regards, > > no-hats Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c1bae6b56ca105045cd5a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dean,

Thanks for the explanation.=C2= =A0 It matches with what I understand for configuration.
Where I = am confused is why I2RS - which is doing ephemeral only and matches closer = to the direct proprietary APIs directly to
the routing processes = - is being tied up in this.

Regards,
Ali= a

On W= ed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state.
There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms.
The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements)

At the end it really doesn't matter how you are communicating with the = devices, it really boils down to that you want the device to boot into a kn= own state. This was done by having a local data store that was containing s= et of instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), config= uration data has to be provided. Historically, data was on the device, as t= he connection between device and the network management was slow. Today (li= ke in MSDC), devices don't have local configuration, those devices when= boot look for provisioning system and get configuration from a remote loca= tion and then change the state of the device based on it. This has led that=

3. some vendors use Linux, allow management via pseudo file system (/proc)<= br>
where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don= 9;t allow that.

So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed.

Hope this helps

Dean


On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com> wrote:

> Hi,
>
> I'd like to really understand why I2RS needs a datastore and what = that actually means.
> In my initial conception of what an I2RS agent would do for, say, writ= ing a route in the RIB
> model, is that=C2=A0 the I2RS agent would simply parse a received requ= est from a standard format
> and model into the internal and pass that to a RIB Manager - just as a= n OSPF implementation
> might install a route to the RIB manager.=C2=A0 An I2RS agent could al= so query the RIB Manager to
> read routes and there'd be events coming out.
>
> With the introduction of priorities to handle multi-headed writers and= collision errors, the I2RS agent would need to store what was written by w= hich client.
>
> What benefits and rationale does a YANG datastore add?=C2=A0 Why does = using one need to be
> standardized?
>
> I apologize if this seems a naive question, but it's been quite a = while since I read up on YANG and NetConf/RestConf.
>
> Regards,
> no-hats=C2=A0 Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


--001a11c1bae6b56ca105045cd5a9-- From nobody Wed Oct 1 06:57:42 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CB21ACDA6 for ; Wed, 1 Oct 2014 06:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ab1egi114zr6 for ; Wed, 1 Oct 2014 06:57:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B3B1ACDAC for ; Wed, 1 Oct 2014 06:57:32 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 13:57:30 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 13:57:30 +0000 From: Dean Bogdanovic To: Juergen Schoenwaelder Thread-Topic: [i2rs] Running and I2RS Ephemeral Config Interaction Thread-Index: AQHP3QmVnXLxvQS6FEaJ53gAUYkd1ZwaZQkAgAANaICAAAMuAIAAV3eAgAB4HAA= Date: Wed, 1 Oct 2014 13:57:29 +0000 Message-ID: <7788A6DD-3225-4618-9E28-E785BD253151@juniper.net> References: <542B422D.6000908@joelhalpern.com> <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> <542B577D.9080309@joelhalpern.com> <1590378A-4CB1-49D2-AD75-9CD7AD49C541@lucidvision.com> <20141001064735.GG36781@elstar.local> In-Reply-To: <20141001064735.GG36781@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(24454002)(479174003)(377454003)(50226001)(105586002)(95666004)(83716003)(107046002)(15975445006)(120916001)(92726001)(66066001)(88136002)(99396003)(36756003)(76482002)(10300001)(86362001)(87936001)(106116001)(80022003)(106356001)(85852003)(92566001)(2656002)(77156001)(57306001)(4396001)(82746002)(87286001)(97736003)(93916002)(89996001)(93886004)(99286002)(20776003)(19580395003)(19580405001)(50986999)(21056001)(110136001)(77096002)(64706001)(85306004)(31966008)(46102003)(76176999)(101416001)(33656002)(15202345003)(62966002)(104166001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OFeDRktW070fxOPl1RdalIhih4Y Cc: Thomas Nadeau , "Joel M. Halpern" , "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:57:35 -0000 I have to agree with Tom, we have to make it simple. What configuration is written where is a matter of policy. Each administrat= or can/will have different policies what is written where.=20 In my opinion config and ephemeral config are merged together with OR funct= ion (cfg || eph) =3D active config For simplicity, if there is a dependency on configuration from persistent c= onfig, minimum working cfg should be copied to ephemeral. Even if admin dec= ides to shut down that functionality, admin can go into all data stores, pe= rsistent, running and ephemeral DB and remove it from there and disallow ch= anges until further notice. It is very hard to standardize policies and I don't think we should do it. Dean On Oct 1, 2014, at 2:47 AM, Juergen Schoenwaelder wrote: > Tom, >=20 > this is correct only if the NETCONF server supports the :startup > capability. During the interim, I said that there are certain > 'synchronization points' at which the running datastore is made > persistent. What these 'synchronization points' are depends on the > capabilities of the NETCONF server. In other words, I2RS should assume > that the 'running configuration datastore' is generally persistent > (even if there may be periods where this is not true, until the next > 'synchronization points' has been reached. >=20 > The main reason we discussed ephemeral datastores is that they will > never have any 'synchronization points'. >=20 > /js >=20 > On Tue, Sep 30, 2014 at 06:34:32PM -0700, Thomas Nadeau wrote: >> The running config is by virtue not preserved until an action to save it= is made. Of the operator wishes to save the running config then yes they = "commit" it. =20 >>=20 >> I honestly think we're making this harder than it needs to be. >>=20 >> Tom=20 >>=20 >>=20 >>=20 >>=20 >>> On Sep 30, 2014, at 6:23 PM, Joel M. Halpern wrot= e: >>>=20 >>> There are multiple problems with "just copying it to running." >>> The primary one is that as per the I2RS WG rough consensus, the I2RS mo= ds are not supposed to be preserved across a restart. >>> But if they are copied to running, and an operator then does a commit, = they will get preserved. >>> In fact, if they get copied to running, and an operator then makes othe= r changes and wants to commit them, he can't help but commit the I2RS chang= es. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 9/30/14, 8:35 PM, Thomas Nadeau wrote: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern wr= ote: >>>>>=20 >>>>> I was tyring to understand the descriptions being used. >>>>>=20 >>>>> After looking back at the email, and talk to folks, there seem to be = two different issues. >>>>>=20 >>>>> The first one is what happens the complete running config disappears. >>>>> As far as I am concerned, the device can do anything it wants, and wh= atever it does is probably wrong. After all, for the running config to dis= appear there have to be very serious problems. >>>>=20 >>>> Yea >>>>=20 >>>>>=20 >>>>> The second issue is what happens when something (foo) is deleted from= the running config, but some property of that thing (foo/a) has been set b= y I2RS. Unfortunately,as far as I can tell, there is not a good general ru= le. >>>>=20 >>>> The simple solution is to make the i2rs config changes apply immediate= ly to the running config/state. >>>>=20 >>>>> Some examples: >>>>> If the operator takes down BGP, and deletes the full BGP configuratio= n, then the presence of I2RS policy rules should not cause BGP to keep runn= ing. >>>>> On the other hand, if foo is a static route create by operations, and= then I2RS modified the next hop for that route, I tend to suspect that the= route I2RS has "created" by doing so should stay around even if the operat= or goes in a deletes the static route. >>>>>=20 >>>>> I suspect that the issue is determining what scope is being created w= hen I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is = a consistent rule. >>>>=20 >>>> If you make it just write to the running config, you have no issues. >>>>=20 >>>> Tom >>>>=20 >>>>=20 >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Oct 1 07:08:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7823E1ACDB6 for ; Wed, 1 Oct 2014 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lVyAu-dC457L for ; Wed, 1 Oct 2014 07:08:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F35EB1A19FF for ; Wed, 1 Oct 2014 07:08:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A52FEC22D; Wed, 1 Oct 2014 10:08:42 -0400 (EDT) Date: Wed, 1 Oct 2014 10:08:42 -0400 From: Jeffrey Haas To: Thomas Nadeau Message-ID: <20141001140842.GB22743@pfrc> References: <542B422D.6000908@joelhalpern.com> <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-HgHAZyiP06hQLYeSQABwskoxJ0 Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:08:44 -0000 On Tue, Sep 30, 2014 at 05:35:10PM -0700, Thomas Nadeau wrote: > The simple solution is to make the i2rs config changes apply immediately to the running config/state. This is the perspective I've been working from. Even so, the semantics of what happens when an underlying change to local config invalidates the ephemeral config. What do we do? This is the point Andy Bierman keeps coming to. -- Jeff (who has opinions, but needs to hear the WG) From nobody Wed Oct 1 07:13:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFE11ACDBC for ; Wed, 1 Oct 2014 07:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 J3L16Zu5h8uG for ; Wed, 1 Oct 2014 07:13:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DAB1ACDB8 for ; Wed, 1 Oct 2014 07:13:03 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 14:13:01 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 14:13:00 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 14:13:00 +0000 From: Dean Bogdanovic To: Alia Atlas Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++RqKttL9wxEexAlDYcQgC+ZwbP/0AgAAD/wCAAAU+AA== Date: Wed, 1 Oct 2014 14:12:59 +0000 Message-ID: <5CC8BAFD-768D-4B5D-B96D-F588ED558E85@juniper.net> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(51704005)(24454002)(377454003)(51914003)(129404003)(66066001)(105586002)(77156001)(76482002)(85306004)(93916002)(20776003)(86362001)(77096002)(80022003)(46102003)(106116001)(106356001)(50986999)(99286002)(36756003)(21056001)(10300001)(15975445006)(95666004)(64706001)(16236675004)(1411001)(62966002)(82746002)(19580395003)(104166001)(87286001)(107046002)(31966008)(57306001)(101416001)(92726001)(76176999)(19580405001)(97736003)(33656002)(88136002)(92566001)(19617315012)(4396001)(110136001)(2656002)(89996001)(87936001)(83716003)(50226001)(85852003)(99396003)(120916001)(23603001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_5CC8BAFD768D4B5DB96DF588ED558E85junipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB518; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/6ewzzZEIebxNvaFmVzRecjCs7zE Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:13:07 -0000 --_000_5CC8BAFD768D4B5DB96DF588ED558E85junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 1, 2014, at 9:54 AM, Alia Atlas > wrote: Hi Dean, Thanks for the explanation. It matches with what I understand for configur= ation. Where I am confused is why I2RS - which is doing ephemeral only and matches= closer to the direct proprietary APIs directly to the routing processes - is being tied up in this. Today there is no standard protocol to expose writing to the daemons direct= ly, except through a datastore. If you would compare routing daemon in Juno= s and routing daemon in IOS or NX-OS, the data models are very different. Y= ou need a standard API to communicate to all of them. Here is a reason why a local datastore comes handy routing daemon crashes and the state is gone. The routing state has to be r= einstated. 1. replay config data from the local data store(s) and reactivate the confi= guration 2. replay config data from the local data store (single data store) and req= uest all I2RS clients to replay their data again Now if some I2RS client, during the crash, tried to execute routing changes= , with local store, those can be executed and put into wait state until dae= mon recovers. I2RS clients can be informed that their changes are pending. Both approaches have pluses and minuses. Another issue is with config statements. If you go directly to the daemons= , only few very basic things can be exposed (like interfaces, routes, state= less fw filters). If you want to expose more complex statements like L3VPN,= then you have to create a logic that will communicate to multiple daemons = to create such state on the device. You are doubling such logic on the devi= ce. I want to allow network administrators to decide by them self what is expos= ed through I2RS, not us (vendors, SDOs). Dean Regards, Alia On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: Hi Alia, today networking devices can be managed in three ways: 1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it. Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices. 2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state. There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms. The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements) At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it. It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot lo= ok for provisioning system and get configuration from a remote location and= then change the state of the device based on it. This has led that 3. some vendors use Linux, allow management via pseudo file system (/proc) where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that. So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed. Hope this helps Dean On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: > Hi, > > I'd like to really understand why I2RS needs a datastore and what that ac= tually means. > In my initial conception of what an I2RS agent would do for, say, writing= a route in the RIB > model, is that the I2RS agent would simply parse a received request from= a standard format > and model into the internal and pass that to a RIB Manager - just as an O= SPF implementation > might install a route to the RIB manager. An I2RS agent could also query= the RIB Manager to > read routes and there'd be events coming out. > > With the introduction of priorities to handle multi-headed writers and co= llision errors, the I2RS agent would need to store what was written by whic= h client. > > What benefits and rationale does a YANG datastore add? Why does using on= e need to be > standardized? > > I apologize if this seems a naive question, but it's been quite a while s= ince I read up on YANG and NetConf/RestConf. > > Regards, > no-hats Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --_000_5CC8BAFD768D4B5DB96DF588ED558E85junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <80793239EAD7B4489FD41D5FFB3A728E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Oct 1, 2014, at 9:54 AM, Alia Atlas <akatlas@gmail.com>
 wrote:

Hi Dean,

Thanks for the explanation.  It matches with what I understand fo= r configuration.
Where I am confused is why I2RS - which is doing ephemeral only and ma= tches closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Today there is no standard protocol to expose writing to the daemons direct= ly, except through a datastore. If you would compare routing daemon in Juno= s and routing daemon in IOS or NX-OS, the data models are very different. Y= ou need a standard API to communicate to all of them. 

Here is a reason why a local datastore comes handy

routing daemon crashes and the state is gone. The routing state has to= be reinstated. 

1. replay config data from the local data store(s) and reactivate the = configuration
2. replay config data from the local data store (single data store) an= d request all I2RS clients to replay their data again

Now if some I2RS client, during the crash, tried to execute routing ch= anges, with local store, those can be executed and put into wait state unti= l daemon recovers. I2RS clients can be informed that their changes are pend= ing.

Both approaches have pluses and minuses. 

Another issue is  with config statements. If you go directly to t= he daemons, only few very basic things can be exposed (like interfaces, rou= tes, stateless fw filters). If you want to expose more complex statements l= ike L3VPN, then you have to create a logic that will communicate to multiple daemons to create such state on th= e device. You are doubling such logic on the device.

I want to allow network administrators to decide by them self what is = exposed through I2RS, not us (vendors, SDOs).

Dean


Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic = <deanb@juniper.ne= t> wrote:
Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device daemons which change their state based on i= t.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It still requires knowing how to config= ure device via CLI and the result of the application written with such APIs= is stored in the data store from which daemon read how to change their sta= te.
There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms.
The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now standardizing configuration and = operational model, so same configuration statement can be sent to all suppo= rting devices and be done (instead of writing same desired functionality in= several configuration statements)

At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot look for provisioning system and ge= t configuration from a remote location and then change the state of the dev= ice based on it. This has led that

3. some vendors use Linux, allow management via pseudo file system (/proc)<= br>
where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that.

So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest done by having a local datastore on= a device, through which the state of the device is changed.

Hope this helps

Dean


On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com> wrote:

> Hi,
>
> I'd like to really understand why I2RS needs a datastore and what that= actually means.
> In my initial conception of what an I2RS agent would do for, say, writ= ing a route in the RIB
> model, is that  the I2RS agent would simply parse a received requ= est from a standard format
> and model into the internal and pass that to a RIB Manager - just as a= n OSPF implementation
> might install a route to the RIB manager.  An I2RS agent could al= so query the RIB Manager to
> read routes and there'd be events coming out.
>
> With the introduction of priorities to handle multi-headed writers and= collision errors, the I2RS agent would need to store what was written by w= hich client.
>
> What benefits and rationale does a YANG datastore add?  Why does = using one need to be
> standardized?
>
> I apologize if this seems a naive question, but it's been quite a whil= e since I read up on YANG and NetConf/RestConf.
>
> Regards,
> no-hats  Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs



--_000_5CC8BAFD768D4B5DB96DF588ED558E85junipernet_-- From nobody Wed Oct 1 07:13:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A4E1ACDBB for ; Wed, 1 Oct 2014 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8zrBpGjhtBst for ; Wed, 1 Oct 2014 07:13:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE141ACDB9 for ; Wed, 1 Oct 2014 07:13:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ECF58C22D; Wed, 1 Oct 2014 10:13:50 -0400 (EDT) Date: Wed, 1 Oct 2014 10:13:50 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20141001141350.GC22743@pfrc> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EGeGOuZRD5Zkg52wTNNePBKeLvM Cc: "i2rs@ietf.org" , Dean Bogdanovic Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:13:54 -0000 On Wed, Oct 01, 2014 at 09:54:12AM -0400, Alia Atlas wrote: > Thanks for the explanation. It matches with what I understand for > configuration. > Where I am confused is why I2RS - which is doing ephemeral only and matches > closer to the direct proprietary APIs directly to > the routing processes - is being tied up in this. The annoying fact is that we have to reconcile what we want to do with the semantics of existing netconf/yang. The property of being able to override some bit of local config with ephemeral config implies at least another data store in those semantics. Otherwise you'd have to redefine the existing semantic as "a given writer may SET a value of a higher visibility priorty and it's allowed to go away and reveal the original value of lower visibility priority". This makes sense as a merge/patch operation, but less so with a single object store. -- Jeff From nobody Wed Oct 1 07:43:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2DB1ACE17 for ; Wed, 1 Oct 2014 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 oQHlpeXdQ4lr for ; Wed, 1 Oct 2014 07:43:30 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77941ACE16 for ; Wed, 1 Oct 2014 07:43:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8FB071BC59AC for ; Wed, 1 Oct 2014 07:43:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2D3E51BC59A5 for ; Wed, 1 Oct 2014 07:43:30 -0700 (PDT) Message-ID: <542C1310.7060005@joelhalpern.com> Date: Wed, 01 Oct 2014 10:43:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> In-Reply-To: <20141001064311.GF36781@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3ONYc5lTtJ5uUyRIgHFl3YF6Vyg Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:43:32 -0000 I can live with that model. Simplified and repeated: If an object is deleted in running, and the object itself was not created as a whole in I2RS, then the object, and any changes to elements within the object, is also deleted in the I2RS ephemeral store, even if some I2RS clients had written some of those elements. I would expect I2RS to generate notifications of those deletions. This gives us a consistent operating paradigm, with a means for I2RS clients to be more explicit about their intent, without creating significant complexity. Yours, Joel On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote: > On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote: > >> The second issue is what happens when something (foo) is deleted from >> the running config, but some property of that thing (foo/a) has been set >> by I2RS. Unfortunately,as far as I can tell, there is not a good >> general rule. >> >> Some examples: >> If the operator takes down BGP, and deletes the full BGP configuration, >> then the presence of I2RS policy rules should not cause BGP to keep running. >> On the other hand, if foo is a static route create by operations, and >> then I2RS modified the next hop for that route, I tend to suspect that >> the route I2RS has "created" by doing so should stay around even if the >> operator goes in a deletes the static route. > > If I2RS only modifies the next hop and the underlying route is delete > from config, then the route should be removed from the operational > state. If I2RS wants the route to persist even if the underlying > config goes away, then the I2RS client has to inject a complete > routing record overlaying the underlying route from config. I believe > this is actually simple as long as we keep it simple. > > /js > From nobody Wed Oct 1 07:53:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AFF1ACE21 for ; Wed, 1 Oct 2014 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DmhV3yXwFDgF for ; Wed, 1 Oct 2014 07:53:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD9F1ACE37 for ; Wed, 1 Oct 2014 07:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4AAD81BC59A2; Wed, 1 Oct 2014 07:53:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CD5DD1BC59C1; Wed, 1 Oct 2014 07:53:49 -0700 (PDT) Message-ID: <542C157C.40305@joelhalpern.com> Date: Wed, 01 Oct 2014 10:53:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , "i2rs@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2mGGF6eUapjyShNfntkC1grXp-c Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 14:53:52 -0000 I had assumed that the YANG "datastore" was the repository in which the I2RS agent stored all of the operations it had applied, who had applied them, etc. This actually does lead to a related question. How does an I2RS client delte the state it has created. (Note that said state might actually include a deletion from the underlying data.) The client is not required to have the knowledge of what the config / I2RS state was before it performed its operation. And even if it were, having an I2RS client set it to a specific value is not the same as removing the I2RS state (because of priority.) I don't think we have been explicit about the need to express this, but it is implicit in the architecture. Yours, Joel On 10/1/14, 12:25 AM, Alia Atlas wrote: > Hi, > > I'd like to really understand why I2RS needs a datastore and what that > actually means. > In my initial conception of what an I2RS agent would do for, say, > writing a route in the RIB > model, is that the I2RS agent would simply parse a received request > from a standard format > and model into the internal and pass that to a RIB Manager - just as an > OSPF implementation > might install a route to the RIB manager. An I2RS agent could also > query the RIB Manager to > read routes and there'd be events coming out. > > With the introduction of priorities to handle multi-headed writers and > collision errors, the I2RS agent would need to store what was written by > which client. > > What benefits and rationale does a YANG datastore add? Why does using > one need to be > standardized? > > I apologize if this seems a naive question, but it's been quite a while > since I read up on YANG and NetConf/RestConf. > > Regards, > no-hats Alia > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Oct 1 08:04:34 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AED1ACE59 for ; Wed, 1 Oct 2014 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4DU6SFJV7xaJ for ; Wed, 1 Oct 2014 08:04:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:778]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412711ACE5A for ; Wed, 1 Oct 2014 08:04:09 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 15:03:45 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 15:03:45 +0000 From: Dean Bogdanovic To: "Joel M. Halpern" Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++RqKttL9wxEexAlDYcQgC+ZwbVKMAgAACxAA= Date: Wed, 1 Oct 2014 15:03:44 +0000 Message-ID: <2274AECC-D32A-481C-8F0B-9FE7EFD2F98B@juniper.net> References: <542C157C.40305@joelhalpern.com> In-Reply-To: <542C157C.40305@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(24454002)(479174003)(377454003)(50226001)(66066001)(95666004)(105586002)(83716003)(15975445006)(107046002)(77156001)(120916001)(92726001)(88136002)(99396003)(36756003)(76482002)(10300001)(87936001)(86362001)(80022003)(106116001)(106356001)(92566001)(2656002)(85852003)(57306001)(4396001)(82746002)(87286001)(97736003)(93916002)(89996001)(99286002)(20776003)(19580395003)(19580405001)(50986999)(21056001)(110136001)(77096002)(64706001)(85306004)(46102003)(31966008)(76176999)(101416001)(33656002)(62966002)(104166001)(23603001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <4B90D6CF96E9D14487D648139D1E01C6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/u3u9_blIuBxBQagDA2Pjtfgi8e4 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:04:32 -0000 On Oct 1, 2014, at 10:53 AM, Joel M. Halpern wrote: > I had assumed that the YANG "datastore" was the repository in which the I= 2RS agent stored all of the operations it had applied, who had applied them= , etc. >=20 > This actually does lead to a related question. > How does an I2RS client delte the state it has created. (Note that said = state might actually include a deletion from the underlying data.) How, if the client writes only into ephemeral store?=20 > The client is not required to have the knowledge of what the config / I2R= S state was before it performed its operation. And even if it were, having= an I2RS client set it to a specific value is not the same as removing the = I2RS state (because of priority.) > I don't think we have been explicit about the need to express this, but i= t is implicit in the architecture. >=20 > Yours, > Joel >=20 > On 10/1/14, 12:25 AM, Alia Atlas wrote: >> Hi, >>=20 >> I'd like to really understand why I2RS needs a datastore and what that >> actually means. >> In my initial conception of what an I2RS agent would do for, say, >> writing a route in the RIB >> model, is that the I2RS agent would simply parse a received request >> from a standard format >> and model into the internal and pass that to a RIB Manager - just as an >> OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also >> query the RIB Manager to >> read routes and there'd be events coming out. >>=20 >> With the introduction of priorities to handle multi-headed writers and >> collision errors, the I2RS agent would need to store what was written by >> which client. >>=20 >> What benefits and rationale does a YANG datastore add? Why does using >> one need to be >> standardized? >>=20 >> I apologize if this seems a naive question, but it's been quite a while >> since I read up on YANG and NetConf/RestConf. >>=20 >> Regards, >> no-hats Alia >>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Oct 1 08:08:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6821ACE55 for ; Wed, 1 Oct 2014 08:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 yTaIGu0uaMRh for ; Wed, 1 Oct 2014 08:08:05 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BCE1ACE45 for ; Wed, 1 Oct 2014 08:08:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 841C81BC59E3; Wed, 1 Oct 2014 08:08:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id EBACB1BC59DF; Wed, 1 Oct 2014 08:08:01 -0700 (PDT) Message-ID: <542C18D0.8000105@joelhalpern.com> Date: Wed, 01 Oct 2014 11:08:00 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dean Bogdanovic References: <542C157C.40305@joelhalpern.com> <2274AECC-D32A-481C-8F0B-9FE7EFD2F98B@juniper.net> In-Reply-To: <2274AECC-D32A-481C-8F0B-9FE7EFD2F98B@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-wtHYc9WkKaJv1rM192aFdBJxRo Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Client Operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:08:07 -0000 In line: On 10/1/14, 11:03 AM, Dean Bogdanovic wrote: > > On Oct 1, 2014, at 10:53 AM, Joel M. Halpern > wrote: > ... >> This actually does lead to a related question. How does an I2RS >> client delte the state it has created. (Note that said state might >> actually include a deletion from the underlying data.) > > How, if the client writes only into ephemeral store? There is nothing in the I2RS work that says that the only requests that the I2RS client can make are creation or modify operations. It seems perfectly legitimate for an I2RS client to decide that the what needs to be done is to remove some static route or policy statement, because circumstances have temporarily changed. Yours, Joel PS: THe same question still applied even if it can not delte, since having the I2RS client write new values is not the same as removing the data. And having an I2RS client issue a delete operation for something it has created does not seem to mean the same thing as "return this to its previous value" which is the required I2RS semantics. From nobody Wed Oct 1 08:08:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B511ACE3C for ; Wed, 1 Oct 2014 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zToMi0Ud24Nb for ; Wed, 1 Oct 2014 08:08:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4EF1ACE5C for ; Wed, 1 Oct 2014 08:08:04 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id 5992428AAC1D; Wed, 1 Oct 2014 11:08:02 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B6DD1610-4C55-4080-8344-F54A857ED691"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <542C1310.7060005@joelhalpern.com> Date: Wed, 1 Oct 2014 08:08:02 -0700 Message-Id: <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> <542C1310.7060005@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/m_0qa_OOQ4jYdIaSb_wG3fQqows Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:08:09 -0000 --Apple-Mail=_B6DD1610-4C55-4080-8344-F54A857ED691 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern = wrote: > I can live with that model. > Simplified and repeated: > If an object is deleted in running, and the object itself was not = created as a whole in I2RS, then the object, and any changes to elements = within the object, is also deleted in the I2RS ephemeral store, even if = some I2RS clients had written some of those elements. This is another simplification: the I2RS objects MUST be a = subset of what is available in the normal/running config. > I would expect I2RS to generate notifications of those deletions. Or just define notifications on the store as you normally can in = the yang model. Is there really a need for special "i2rs" notifications = or just config-change-related ones? > This gives us a consistent operating paradigm, with a means for I2RS = clients to be more explicit about their intent, without creating = significant complexity. Lets try! 8) --Tom >=20 > Yours, > Joel >=20 > On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote: >> On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote: >>=20 >>> The second issue is what happens when something (foo) is deleted = from >>> the running config, but some property of that thing (foo/a) has been = set >>> by I2RS. Unfortunately,as far as I can tell, there is not a good >>> general rule. >>>=20 >>> Some examples: >>> If the operator takes down BGP, and deletes the full BGP = configuration, >>> then the presence of I2RS policy rules should not cause BGP to keep = running. >>> On the other hand, if foo is a static route create by operations, = and >>> then I2RS modified the next hop for that route, I tend to suspect = that >>> the route I2RS has "created" by doing so should stay around even if = the >>> operator goes in a deletes the static route. >>=20 >> If I2RS only modifies the next hop and the underlying route is delete >> from config, then the route should be removed from the operational >> state. If I2RS wants the route to persist even if the underlying >> config goes away, then the I2RS client has to inject a complete >> routing record overlaying the underlying route from config. I believe >> this is actually simple as long as we keep it simple. >>=20 >> /js >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_B6DD1610-4C55-4080-8344-F54A857ED691 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULBjSAAoJEPcO+I7eiUJZ1cEP/1mXgF3Ii6m1zu9TetC8qR74 E83oxCe4jOjfeLO0Y9DFsU2cfyww0ySkCOzuZprB9JQ1AgA5ZyzqnaNdoeMNecg+ 1PULbrUcbGWkri+Xv6l+cYz8y9SAZk31XmGdRE19H2joJA+Rl33Ddq8iYEwxGt3G H2g8eZZ4sFZ5Utt9AxPW+dUmeTevBYAnPNMemGgcYSHKNP4aSC3y2jDx5I2maxxi 2J6UvCDYBRsAVnCErX64FEcTLVtdgQEv1p0jJf+xjIkdpG73Sm8DZiXGFQ3tCOMD qo2/EHGkh1dhb6S6jvcsOESZa6Lf5nme38tDETZgB5VUOCwD7/PX0WypmCHW0sQm /IwkniDfdibFYw3suM6aHd1a+BIeE/uJruqi0filwEqYaKgQx7E4PBkLelgN5buq gpgfb+F5EchvUhmeLeAv7saHWXJKugRtGpo/GxmaL1YVUoGOA4h5p5LAtjjyiI4T GwqQlc8MsQnQTAMmHby4BYHc1I6Qv6pALF6mE6hJX35DFimI3c6vRqdbzzIV2oC2 jHYDIfc9cSQ+/ODy/n7yDPATA0F1YoRrRaldZBCBMTgHy+/piNQj9wkghCSasYzL xCPX0pbvg0H9LCfb/3mWcTwXYtAb57hKfsJC0m5HfhQ0KiFQzyHwt8PJ2w738rGX I7C53BFLfhIR9bxAyk1l =SJLj -----END PGP SIGNATURE----- --Apple-Mail=_B6DD1610-4C55-4080-8344-F54A857ED691-- From nobody Wed Oct 1 08:11:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EE91ACE4F for ; Wed, 1 Oct 2014 08:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mPsT6js5EF8O for ; Wed, 1 Oct 2014 08:11:31 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEB61ACE51 for ; Wed, 1 Oct 2014 08:11:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 153911BC5A00; Wed, 1 Oct 2014 08:11:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9249F1BC59F8; Wed, 1 Oct 2014 08:11:30 -0700 (PDT) Message-ID: <542C19A1.40604@joelhalpern.com> Date: Wed, 01 Oct 2014 11:11:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> <542C1310.7060005@joelhalpern.com> <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> In-Reply-To: <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/M1s6_Q-kvmkK4O1AX1XkG_oDkXQ Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:11:40 -0000 What does "must be a subset" mean? There are actuyally levels of that which I think the I2RS work could accept. Prohibiting I2RS from starting OSPF when it was not running is probably reasonable. On the other hand, prohibiting I2RS from creating a new static route to a destination is clearly not workable. But both of those are creating a new portion of the tree, within an existing tree (namely the whole configuration.) So this "simplification" does not seem to mean anything. One of the nice things abotu Juergen's proposal is that it does not say "I2RS can not do X." Rather it, says "to do X, I2RS must use mechanism Y". Yours, Joel On 10/1/14, 11:08 AM, Thomas D. Nadeau wrote: > > On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern wrote: > >> I can live with that model. >> Simplified and repeated: >> If an object is deleted in running, and the object itself was not created as a whole in I2RS, then the object, and any changes to elements within the object, is also deleted in the I2RS ephemeral store, even if some I2RS clients had written some of those elements. > > This is another simplification: the I2RS objects MUST be a subset of what is available in the normal/running config. > >> I would expect I2RS to generate notifications of those deletions. > > Or just define notifications on the store as you normally can in the yang model. Is there really a need for special "i2rs" notifications or just config-change-related ones? > >> This gives us a consistent operating paradigm, with a means for I2RS clients to be more explicit about their intent, without creating significant complexity. > > Lets try! 8) > > --Tom > > From nobody Wed Oct 1 08:14:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBBB1A1A12 for ; Wed, 1 Oct 2014 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9MyiXE_TJ14B for ; Wed, 1 Oct 2014 08:14:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::747]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CDD1A1A1B for ; Wed, 1 Oct 2014 08:14:47 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 15:14:24 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 15:14:23 +0000 From: Dean Bogdanovic To: Joel Halpern Direct Thread-Topic: [i2rs] Client Operations Thread-Index: AQHP3YmBuwWwtX+qC0Cdro33/UHn5pwbWa8A Date: Wed, 1 Oct 2014 15:14:23 +0000 Message-ID: <262220F7-28DE-48BA-AF75-F51ED78C7D94@juniper.net> References: <542C157C.40305@joelhalpern.com> <2274AECC-D32A-481C-8F0B-9FE7EFD2F98B@juniper.net> <542C18D0.8000105@joelhalpern.com> In-Reply-To: <542C18D0.8000105@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(377454003)(479174003)(189002)(199003)(21056001)(64706001)(110136001)(77096002)(19580395003)(50986999)(19580405001)(101416001)(76176999)(33656002)(104166001)(62966002)(85306004)(46102003)(31966008)(10300001)(76482002)(106356001)(92566001)(2656002)(85852003)(86362001)(87936001)(106116001)(80022003)(83716003)(50226001)(105586002)(95666004)(66066001)(92726001)(36756003)(88136002)(99396003)(107046002)(120916001)(77156001)(93916002)(89996001)(93886004)(97736003)(20776003)(99286002)(4396001)(57306001)(87286001)(82746002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A574C653BA5494DB7114DDD873F8F6B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/AVpM22ZxuGwWOmgf_WpiowyGZKU Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Client Operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:14:49 -0000 On Oct 1, 2014, at 11:08 AM, Joel Halpern Direct wrote: > In line: >=20 > On 10/1/14, 11:03 AM, Dean Bogdanovic wrote: >>=20 >> On Oct 1, 2014, at 10:53 AM, Joel M. Halpern >> wrote: >>=20 > ... >>> This actually does lead to a related question. How does an I2RS >>> client delte the state it has created. (Note that said state might >>> actually include a deletion from the underlying data.) >>=20 >> How, if the client writes only into ephemeral store? >=20 > There is nothing in the I2RS work that says that the only requests that t= he I2RS client can make are creation or modify operations. It seems perfec= tly legitimate for an I2RS client to decide that the what needs to be done = is to remove some static route or policy statement, because circumstances h= ave temporarily changed. That is opening a can of worms. You can not allow deletion of data that is = not owned by the client. That can create instability of the system and the = network. Using your example, I2RS client should enter a new static route or= policy statement that would nullify the existing one. >=20 > Yours, > Joel >=20 > PS: THe same question still applied even if it can not delte, since havin= g the I2RS client write new values is not the same as removing the data. A= nd having an I2RS client issue a delete operation for something it has crea= ted does not seem to mean the same thing as "return this to its previous va= lue" which is the required I2RS semantics. From nobody Wed Oct 1 08:17:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E041A1A37 for ; Wed, 1 Oct 2014 08:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Xvqll2mH74a5 for ; Wed, 1 Oct 2014 08:16:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F231A1A42 for ; Wed, 1 Oct 2014 08:16:50 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 15:16:27 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 15:16:27 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [i2rs] Running and I2RS Ephemeral Config Interaction Thread-Index: AQHP3QmVnXLxvQS6FEaJ53gAUYkd1Zway9yAgACGMACAAAbdAIAAAliA Date: Wed, 1 Oct 2014 15:16:26 +0000 Message-ID: <968A8619-63A7-4B7E-B9D3-CB7B31C2A118@juniper.net> References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> <542C1310.7060005@joelhalpern.com> <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> In-Reply-To: <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(479174003)(377454003)(83716003)(20776003)(87286001)(77156001)(36756003)(2656002)(110136001)(99286002)(4396001)(66066001)(106356001)(77096002)(95666004)(93886004)(105586002)(85852003)(82746002)(88136002)(62966002)(80022003)(106116001)(107046002)(19580405001)(15975445006)(33656002)(87936001)(57306001)(76482002)(50986999)(76176999)(21056001)(101416001)(99396003)(19580395003)(46102003)(93916002)(92726001)(85306004)(50226001)(86362001)(92566001)(104166001)(120916001)(64706001)(89996001)(10300001)(31966008)(97736003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <0FD2D6D1531C074286EB269B7114F5B0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Nopd6nKBWz2zmZcraxPdAIMBV0Q Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:17:07 -0000 Tom, On Oct 1, 2014, at 11:08 AM, Thomas D. Nadeau wro= te: >=20 > On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern = wrote: >=20 >> I can live with that model. >> Simplified and repeated: >> If an object is deleted in running, and the object itself was not create= d as a whole in I2RS, then the object, and any changes to elements within t= he object, is also deleted in the I2RS ephemeral store, even if some I2RS c= lients had written some of those elements. >=20 > This is another simplification: the I2RS objects MUST be a subset of wha= t is available in the normal/running config. Do you mean by what is currently active in the normal running config or wha= t is possible to be in the normal running config.=20 I would say it: I2RS object CAN be any subset of what is available in the n= ormal/running config. Dean >=20 >> I would expect I2RS to generate notifications of those deletions. >=20 > Or just define notifications on the store as you normally can in the yan= g model. Is there really a need for special "i2rs" notifications or just c= onfig-change-related ones? >=20 >> This gives us a consistent operating paradigm, with a means for I2RS cli= ents to be more explicit about their intent, without creating significant c= omplexity. >=20 > Lets try! 8) >=20 > --Tom >=20 >=20 >>=20 >> Yours, >> Joel >>=20 >> On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote: >>> On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote: >>>=20 >>>> The second issue is what happens when something (foo) is deleted from >>>> the running config, but some property of that thing (foo/a) has been s= et >>>> by I2RS. Unfortunately,as far as I can tell, there is not a good >>>> general rule. >>>>=20 >>>> Some examples: >>>> If the operator takes down BGP, and deletes the full BGP configuration= , >>>> then the presence of I2RS policy rules should not cause BGP to keep ru= nning. >>>> On the other hand, if foo is a static route create by operations, and >>>> then I2RS modified the next hop for that route, I tend to suspect that >>>> the route I2RS has "created" by doing so should stay around even if th= e >>>> operator goes in a deletes the static route. >>>=20 >>> If I2RS only modifies the next hop and the underlying route is delete >>> from config, then the route should be removed from the operational >>> state. If I2RS wants the route to persist even if the underlying >>> config goes away, then the I2RS client has to inject a complete >>> routing record overlaying the underlying route from config. I believe >>> this is actually simple as long as we keep it simple. >>>=20 >>> /js >>>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Oct 1 08:19:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C651A1A3A for ; Wed, 1 Oct 2014 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 X2yCUX07jnom for ; Wed, 1 Oct 2014 08:19:12 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885821A1A2E for ; Wed, 1 Oct 2014 08:19:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 530C41BC59E9; Wed, 1 Oct 2014 08:19:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C91981BC59C5; Wed, 1 Oct 2014 08:19:11 -0700 (PDT) Message-ID: <542C1B6E.30809@joelhalpern.com> Date: Wed, 01 Oct 2014 11:19:10 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dean Bogdanovic References: <542C157C.40305@joelhalpern.com> <2274AECC-D32A-481C-8F0B-9FE7EFD2F98B@juniper.net> <542C18D0.8000105@joelhalpern.com> <262220F7-28DE-48BA-AF75-F51ED78C7D94@juniper.net> In-Reply-To: <262220F7-28DE-48BA-AF75-F51ED78C7D94@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/sOnYiWkw4-6xwhDvj6RftxjW7vk Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Client Operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:19:14 -0000 Continuing in line, although this may get too deep: On 10/1/14, 11:14 AM, Dean Bogdanovic wrote: > > On Oct 1, 2014, at 11:08 AM, Joel Halpern Direct > wrote: > >> In line: >> >> On 10/1/14, 11:03 AM, Dean Bogdanovic wrote: >>> >>> On Oct 1, 2014, at 10:53 AM, Joel M. Halpern >>> wrote: >>> >> ... >>>> This actually does lead to a related question. How does an >>>> I2RS client delte the state it has created. (Note that said >>>> state might actually include a deletion from the underlying >>>> data.) >>> >>> How, if the client writes only into ephemeral store? >> >> There is nothing in the I2RS work that says that the only requests >> that the I2RS client can make are creation or modify operations. >> It seems perfectly legitimate for an I2RS client to decide that the >> what needs to be done is to remove some static route or policy >> statement, because circumstances have temporarily changed. > > That is opening a can of worms. You can not allow deletion of data > that is not owned by the client. That can create instability of the > system and the network. Using your example, I2RS client should enter > a new static route or policy statement that would nullify the > existing one. One can argue that all of I2RS is a can of worms. But I don't think that is reasoanble. Your proposal would mean that if the goal of the I2RS client was to cause a specific route, that had been pinned by the operator, to follow dynamic routing instead, then the I2RS client would ahve to monitor the rib for any non-applied changes, mirror the rib manager logic, and manually update the static route with the answer the rib manager would have produced if the static route were not there? Seems rather complex and error prone for a reasonable policy hammer. One of the agreements reached in teh I2RS work early on is that if the operator wants to shoot his foot using I2RS and produce a really painful configuration, then he is free to do so. Yours, Joel From nobody Wed Oct 1 08:29:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EF01ACE37 for ; Wed, 1 Oct 2014 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WPhKYzODb8YF for ; Wed, 1 Oct 2014 08:29:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B491A1A43 for ; Wed, 1 Oct 2014 08:29:29 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB938.namprd05.prod.outlook.com (10.255.205.25) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 15:29:00 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 15:28:59 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 15:28:59 +0000 From: Dean Bogdanovic To: "Joel M. Halpern" Thread-Topic: [i2rs] Client Operations Thread-Index: AQHP3YmBuwWwtX+qC0Cdro33/UHn5pwbWa8AgAABVwCAAAK8gA== Date: Wed, 1 Oct 2014 15:28:59 +0000 Message-ID: <7A8B5CAD-BC59-4563-B14A-44E5626C00AC@juniper.net> References: <542C157C.40305@joelhalpern.com> <2274AECC-D32A-481C-8F0B-9FE7EFD2F98B@juniper.net> <542C18D0.8000105@joelhalpern.com> <262220F7-28DE-48BA-AF75-F51ED78C7D94@juniper.net> <542C1B6E.30809@joelhalpern.com> In-Reply-To: <542C1B6E.30809@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(54014002)(24454002)(189002)(199003)(51704005)(19580395003)(82746002)(104166001)(107046002)(31966008)(87286001)(62966002)(2656002)(89996001)(4396001)(561944003)(110136001)(99396003)(85852003)(120916001)(50226001)(87936001)(83716003)(76176999)(57306001)(101416001)(92726001)(33656002)(88136002)(92566001)(97736003)(19580405001)(93916002)(86362001)(20776003)(76482002)(85306004)(105586002)(66066001)(77156001)(21056001)(36756003)(64706001)(95666004)(10300001)(93886004)(80022003)(77096002)(99286002)(106356001)(106116001)(50986999)(46102003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB938; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Wvj3eWcuCR-iCzHCRXu7K6kyEmg Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Client Operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:29:31 -0000 Deleting some of older emails On Oct 1, 2014, at 11:19 AM, Joel M. Halpern wrote: > Continuing in line, although this may get too deep: >>=20 >> That is opening a can of worms. You can not allow deletion of data >> that is not owned by the client. That can create instability of the >> system and the network. Using your example, I2RS client should enter >> a new static route or policy statement that would nullify the >> existing one. >=20 > One can argue that all of I2RS is a can of worms. But I don't think that= is reasoanble. >=20 > Your proposal would mean that if the goal of the I2RS client was to cause= a specific route, that had been pinned by the operator, to follow dynamic = routing instead, then the I2RS client would ahve to monitor the rib for any= non-applied changes, mirror the rib manager logic, and manually update the= static route with the answer the rib manager would have produced if the st= atic route were not there? Please keep in mind that we are proposing only a single data store for I2RS= . If I2RS client has to read/write/delete from a different store, use diffe= rent mechanism to do so. >=20 > Seems rather complex and error prone for a reasonable policy hammer. > One of the agreements reached in teh I2RS work early on is that if the op= erator wants to shoot his foot using I2RS and produce a really painful conf= iguration, then he is free to do so. Yes, you are fully right on this topic and I agree with it. >=20 > Yours, > Joel From nobody Wed Oct 1 08:40:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F331ACE3E for ; Wed, 1 Oct 2014 08:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PDhO6PwI7Ngm for ; Wed, 1 Oct 2014 08:40:44 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id C89E11ACE28 for ; Wed, 1 Oct 2014 08:40:42 -0700 (PDT) Received: from [10.110.1.6] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id 87CF428AAD4E; Wed, 1 Oct 2014 11:40:40 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_28C6F2F1-572C-4D97-92B0-EBAC1C4956E4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <968A8619-63A7-4B7E-B9D3-CB7B31C2A118@juniper.net> Date: Wed, 1 Oct 2014 08:40:35 -0700 Message-Id: <6875FC82-DADD-49D1-A355-8E4F9CB6799C@lucidvision.com> References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> <542C1310.7060005@joelhalpern.com> <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> <968A8619-63A7-4B7E-B9D3-CB7B31C2A118@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/sfta20EncEWFElhSFXBtia6hcu4 Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:40:46 -0000 --Apple-Mail=_28C6F2F1-572C-4D97-92B0-EBAC1C4956E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 1, 2014:8:16 AM, at 8:16 AM, Dean Bogdanovic = wrote: > Tom, >=20 >=20 > On Oct 1, 2014, at 11:08 AM, Thomas D. Nadeau = wrote: >=20 >>=20 >> On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern = wrote: >>=20 >>> I can live with that model. >>> Simplified and repeated: >>> If an object is deleted in running, and the object itself was not = created as a whole in I2RS, then the object, and any changes to elements = within the object, is also deleted in the I2RS ephemeral store, even if = some I2RS clients had written some of those elements. >>=20 >> This is another simplification: the I2RS objects MUST be a = subset of what is available in the normal/running config. >=20 > Do you mean by what is currently active in the normal running config = or what is possible to be in the normal running config.=20 > I would say it: I2RS object CAN be any subset of what is available in = the normal/running config. >=20 > Dean Im going from a netconf/yang model perspective with the = assumption that %100 of a configuration is modeled in yang and = operationally available via netconf (or restconf). If you then think of = this configuration as a configuration set of objects, I like to think = about i2rs as a proper subset of this. Operational reality also shows = this to be the case. There seems to be no good reason to have something = you can configure/read from this set of objects that differs if you use = the i2rs "protocol" versus netconf/restconf. --Tom >=20 >>=20 >>> I would expect I2RS to generate notifications of those deletions. >>=20 >> Or just define notifications on the store as you normally can in = the yang model. Is there really a need for special "i2rs" notifications = or just config-change-related ones? >>=20 >>> This gives us a consistent operating paradigm, with a means for I2RS = clients to be more explicit about their intent, without creating = significant complexity. >>=20 >> Lets try! 8) >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote: >>>> On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote: >>>>=20 >>>>> The second issue is what happens when something (foo) is deleted = from >>>>> the running config, but some property of that thing (foo/a) has = been set >>>>> by I2RS. Unfortunately,as far as I can tell, there is not a good >>>>> general rule. >>>>>=20 >>>>> Some examples: >>>>> If the operator takes down BGP, and deletes the full BGP = configuration, >>>>> then the presence of I2RS policy rules should not cause BGP to = keep running. >>>>> On the other hand, if foo is a static route create by operations, = and >>>>> then I2RS modified the next hop for that route, I tend to suspect = that >>>>> the route I2RS has "created" by doing so should stay around even = if the >>>>> operator goes in a deletes the static route. >>>>=20 >>>> If I2RS only modifies the next hop and the underlying route is = delete >>>> from config, then the route should be removed from the operational >>>> state. If I2RS wants the route to persist even if the underlying >>>> config goes away, then the I2RS client has to inject a complete >>>> routing record overlaying the underlying route from config. I = believe >>>> this is actually simple as long as we keep it simple. >>>>=20 >>>> /js >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 --Apple-Mail=_28C6F2F1-572C-4D97-92B0-EBAC1C4956E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULCB0AAoJEPcO+I7eiUJZwtgP/jeawqbqKyJjDgnHpg/ew/oM m/G4K2VDslB3mRjxkRlG8amzU8O/80/4wrBMsqYIiT+VvCf0jV0pq3mWJ3nBey9L AeEP+NogY/Cjt/sLyTThbUBaHyO9j4b4xJlUUCYGjGtiP3EbwED1tF9vucNTmI4s 4zSZ54bKbV+arBwnGL3LcS2CNGCMSW/Pq11ka5pbZlmEGatZ5EyV4FA9353+AhPc 02FD27kj8OFdILwRviDmrBgrpsRM7ue+1hL/9UI6GimoqwJbSJHL55LIzrDFWfip 26CjPzP/1grC46GTD6cdqzH/pE/wb2B6dES6+bGOF+UsVETra/ntl5OMJwSDVpAP NYJrp+XWdIwDKYD41pFCnU2kdJLmmKpDmz61CBUTuD33KbL8whJ3DXogE/xt18OW hu7BlHjdHWiNUrri7q3Ue3GxjUE0cNHhkqL+SxSoUKpWWCzsTEpeiGzdnw3aQj7Z tOIzMDFuzMes3UlCcizC951zmIjsB83AzMcNZ8w/CXmavEX6PEC436/StYstBCx5 7bx6XU92Lg7f+e6z14qzlRIwgpal8aO6M/9ZARxBx+2+q0eqQnxH443eSvne44UL S7BcA0bmhM+WauQJ3yvd2zC843eW2v0dwIVcibLvVF5ay7QiDBMBN6MHeXU2oiI1 AykBSlXKgZfV634mf1y8 =YkYS -----END PGP SIGNATURE----- --Apple-Mail=_28C6F2F1-572C-4D97-92B0-EBAC1C4956E4-- From nobody Wed Oct 1 08:59:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26371ACE4A for ; Wed, 1 Oct 2014 08:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1fs7hFSNns45 for ; Wed, 1 Oct 2014 08:59:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E12F1ACE49 for ; Wed, 1 Oct 2014 08:59:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0BE73C22D; Wed, 1 Oct 2014 11:59:43 -0400 (EDT) Date: Wed, 1 Oct 2014 11:59:42 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20141001155942.GD22743@pfrc> References: <542C157C.40305@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542C157C.40305@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/WS6tlPIwN6t6eDu55EJSk2OOLVE Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:59:47 -0000 On Wed, Oct 01, 2014 at 10:53:48AM -0400, Joel M. Halpern wrote: > This actually does lead to a related question. > How does an I2RS client delte the state it has created. (Note that > said state might actually include a deletion from the underlying > data.) This was briefly discussed at the netmod interim. With the idea that the "creator" is metadata that is part of the configuration, it becomes possible to craft new operations (rpc? extensions to netconf?) that effectively become "purge datastore (by createor-id)" The place this sort of "by creator-id" operation becomes messy is if two different clients of differing priorities have written to overlapping state - either from a schema perspective or from a dependency perspective. In such a case, deleting the higher-priority client state may lead to inconsistent configuration from what remains of the prior lower priority client state. The I2RS architecture basically says "send a notification this has happened and let the clients sort it out". -- Jeff From nobody Wed Oct 1 09:00:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0BE1ACE91 for ; Wed, 1 Oct 2014 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 LMH_yRzkd7p4 for ; Wed, 1 Oct 2014 09:00:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94A31ACE92 for ; Wed, 1 Oct 2014 09:00:27 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB202.namprd05.prod.outlook.com (10.255.206.18) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 16:00:05 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 16:00:03 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 16:00:03 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [i2rs] Running and I2RS Ephemeral Config Interaction Thread-Index: AQHP3QmVnXLxvQS6FEaJ53gAUYkd1Zway9yAgACGMACAAAbdAIAAAliAgAAGwYCAAAVvAA== Date: Wed, 1 Oct 2014 16:00:03 +0000 Message-ID: References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> <542C1310.7060005@joelhalpern.com> <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> <968A8619-63A7-4B7E-B9D3-CB7B31C2A118@juniper.net> <6875FC82-DADD-49D1-A355-8E4F9CB6799C@lucidvision.com> In-Reply-To: <6875FC82-DADD-49D1-A355-8E4F9CB6799C@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174003)(24454002)(189002)(199003)(51704005)(19580395003)(82746002)(104166001)(107046002)(31966008)(87286001)(62966002)(2656002)(89996001)(99396003)(4396001)(110136001)(85852003)(120916001)(87936001)(50226001)(83716003)(76176999)(101416001)(57306001)(92726001)(33656002)(88136002)(92566001)(97736003)(19580405001)(93916002)(86362001)(20776003)(76482002)(85306004)(105586002)(66066001)(77156001)(36756003)(21056001)(95666004)(15975445006)(10300001)(64706001)(93886004)(80022003)(77096002)(106356001)(99286002)(50986999)(46102003)(106116001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB202; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oijAWEGzlzt3I5J4OmAh8yemeyQ Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 16:00:45 -0000 Tom, I'm in agreement with you. Thank you for clarifying it. Dean On Oct 1, 2014, at 11:40 AM, Thomas D. Nadeau wro= te: >=20 >=20 > On Oct 1, 2014:8:16 AM, at 8:16 AM, Dean Bogdanovic w= rote: >=20 >> Tom, >>=20 >>=20 >> On Oct 1, 2014, at 11:08 AM, Thomas D. Nadeau = wrote: >>=20 >>>=20 >>> On Oct 1, 2014:7:43 AM, at 7:43 AM, Joel M. Halpern wrote: >>>=20 >>>> I can live with that model. >>>> Simplified and repeated: >>>> If an object is deleted in running, and the object itself was not crea= ted as a whole in I2RS, then the object, and any changes to elements within= the object, is also deleted in the I2RS ephemeral store, even if some I2RS= clients had written some of those elements. >>>=20 >>> This is another simplification: the I2RS objects MUST be a subset of w= hat is available in the normal/running config. >>=20 >> Do you mean by what is currently active in the normal running config or = what is possible to be in the normal running config.=20 >> I would say it: I2RS object CAN be any subset of what is available in th= e normal/running config. >>=20 >> Dean >=20 > Im going from a netconf/yang model perspective with the assumption that = %100 of a configuration is modeled in yang and operationally available via = netconf (or restconf). If you then think of this configuration as a config= uration set of objects, I like to think about i2rs as a proper subset of th= is. Operational reality also shows this to be the case. There seems to be = no good reason to have something you can configure/read from this set of ob= jects that differs if you use the i2rs "protocol" versus netconf/restconf. >=20 > --Tom >=20 >=20 >=20 >>=20 >>>=20 >>>> I would expect I2RS to generate notifications of those deletions. >>>=20 >>> Or just define notifications on the store as you normally can in the y= ang model. Is there really a need for special "i2rs" notifications or just= config-change-related ones? >>>=20 >>>> This gives us a consistent operating paradigm, with a means for I2RS c= lients to be more explicit about their intent, without creating significant= complexity. >>>=20 >>> Lets try! 8) >>>=20 >>> --Tom >>>=20 >>>=20 >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 10/1/14, 2:43 AM, Juergen Schoenwaelder wrote: >>>>> On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote: >>>>>=20 >>>>>> The second issue is what happens when something (foo) is deleted fro= m >>>>>> the running config, but some property of that thing (foo/a) has been= set >>>>>> by I2RS. Unfortunately,as far as I can tell, there is not a good >>>>>> general rule. >>>>>>=20 >>>>>> Some examples: >>>>>> If the operator takes down BGP, and deletes the full BGP configurati= on, >>>>>> then the presence of I2RS policy rules should not cause BGP to keep = running. >>>>>> On the other hand, if foo is a static route create by operations, an= d >>>>>> then I2RS modified the next hop for that route, I tend to suspect th= at >>>>>> the route I2RS has "created" by doing so should stay around even if = the >>>>>> operator goes in a deletes the static route. >>>>>=20 >>>>> If I2RS only modifies the next hop and the underlying route is delete >>>>> from config, then the route should be removed from the operational >>>>> state. If I2RS wants the route to persist even if the underlying >>>>> config goes away, then the I2RS client has to inject a complete >>>>> routing record overlaying the underlying route from config. I believe >>>>> this is actually simple as long as we keep it simple. >>>>>=20 >>>>> /js >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>=20 >=20 From nobody Wed Oct 1 10:31:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D741A1A7A for ; Wed, 1 Oct 2014 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 njIMkwGJWPYE for ; Wed, 1 Oct 2014 10:31:48 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBAB1A1A77 for ; Wed, 1 Oct 2014 10:31:47 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s91HVjHR026270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 13:31:45 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 1 Oct 2014 13:31:45 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 1 Oct 2014 13:31:44 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.0995.028; Wed, 1 Oct 2014 13:31:44 -0400 From: Igor Bryskin To: Alia Atlas , Dean Bogdanovic Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++hUDOdi/jUE6MWNaif21zLpwbgwsAgAAD/wD///cFUg== Date: Wed, 1 Oct 2014 17:31:43 +0000 Message-ID: <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-01_06:2014-10-01,2014-10-01,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Xy680PpMxegWNC-Hf3nvJu9X-aU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:31:50 -0000 Alia, Your question makes sense if I2RS is limited to routing data manipulation. In this case it could be thought of as an additional routing protocol.After= all OSPF does not need any data store to install its routes, What if I2RS client want to configure other things? Igor ________________________________________ From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas [akatlas@gmail.c= om] Sent: Wednesday, October 1, 2014 9:54 AM To: Dean Bogdanovic Cc: i2rs@ietf.org Subject: Re: [i2rs] Why do we need a datastore? Hi Dean, Thanks for the explanation. It matches with what I understand for configur= ation. Where I am confused is why I2RS - which is doing ephemeral only and matches= closer to the direct proprietary APIs directly to the routing processes - is being tied up in this. Regards, Alia On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: Hi Alia, today networking devices can be managed in three ways: 1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it. Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices. 2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state. There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms. The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements) At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it. It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot lo= ok for provisioning system and get configuration from a remote location and= then change the state of the device based on it. This has led that 3. some vendors use Linux, allow management via pseudo file system (/proc) where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that. So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed. Hope this helps Dean On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: > Hi, > > I'd like to really understand why I2RS needs a datastore and what that ac= tually means. > In my initial conception of what an I2RS agent would do for, say, writing= a route in the RIB > model, is that the I2RS agent would simply parse a received request from= a standard format > and model into the internal and pass that to a RIB Manager - just as an O= SPF implementation > might install a route to the RIB manager. An I2RS agent could also query= the RIB Manager to > read routes and there'd be events coming out. > > With the introduction of priorities to handle multi-headed writers and co= llision errors, the I2RS agent would need to store what was written by whic= h client. > > What benefits and rationale does a YANG datastore add? Why does using on= e need to be > standardized? > > I apologize if this seems a naive question, but it's been quite a while s= ince I read up on YANG and NetConf/RestConf. > > Regards, > no-hats Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Oct 1 10:33:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D571A1A79 for ; Wed, 1 Oct 2014 10:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 cuDOm6roCY6G for ; Wed, 1 Oct 2014 10:33:11 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 51FAD1A1A77 for ; Wed, 1 Oct 2014 10:33:11 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id DE84428AB054; Wed, 1 Oct 2014 13:33:09 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4F0A4C77-CBC8-451A-BE46-1D179E59492E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> Date: Wed, 1 Oct 2014 10:33:06 -0700 Message-Id: <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> To: Igor Bryskin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3N7hwhsydzTFuZP-4zKTXYkR0Zo Cc: "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:33:13 -0000 --Apple-Mail=_4F0A4C77-CBC8-451A-BE46-1D179E59492E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin = wrote: > Alia, >=20 > Your question makes sense if I2RS is limited to routing data = manipulation. > In this case it could be thought of as an additional routing = protocol.After all OSPF does not need any data store to install its = routes, > What if I2RS client want to configure other things? Then just use Netconf or RestConf. --Tom >=20 > Igor > ________________________________________ > From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas = [akatlas@gmail.com] > Sent: Wednesday, October 1, 2014 9:54 AM > To: Dean Bogdanovic > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Why do we need a datastore? >=20 > Hi Dean, >=20 > Thanks for the explanation. It matches with what I understand for = configuration. > Where I am confused is why I2RS - which is doing ephemeral only and = matches closer to the direct proprietary APIs directly to > the routing processes - is being tied up in this. >=20 > Regards, > Alia >=20 > On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic = > wrote: > Hi Alia, >=20 > today networking devices can be managed in three ways: >=20 > 1. CLI - is the UI we all know and use it quite heavily. In order for = the device to boot in a known state a set of CLI commands have to be = saved somewhere on the device. For that you have a data store. That data = store can be a flat file or a database. The datastore is then read by = network device daemons which change their state based on it. >=20 > Before the APIs were exposed, TCL/Expect and Perl ruled the automation = world and everything was based on screen scraping. In order to make = machine to machine communication easier, NETCONF was created as a = standard protocol to communicate with the devices. >=20 > 2. via APIs - there are several type of APIs, but most widely = available ones are providing functionalities same as CLI. The difference = is that CLI is human intended and APIs are machine intended. One of the = example is Junos XML APIs, where (almost) each CLI command is = represented by XML API. It still requires knowing how to configure = device via CLI and the result of the application written with such APIs = is stored in the data store from which daemon read how to change their = state. > There are some vendors that provide APIs that allow communication with = daemons directly, bypassing management infrastructure, but those are = highly proprietary mechanisms. > The APIs that were released by vendors, were not standardized and each = vendor had different configuration models, so although communication = with devices was standardized, there was no easy way to communicate = semantics, which led to YANG, as standard language that all vendors = would understand and now standardizing configuration and operational = model, so same configuration statement can be sent to all supporting = devices and be done (instead of writing same desired functionality in = several configuration statements) >=20 > At the end it really doesn't matter how you are communicating with the = devices, it really boils down to that you want the device to boot into a = known state. This was done by having a local data store that was = containing set of instructions what state the device should be after = reading it. >=20 > It really doesn't matter which mechanism is used (from above 2), = configuration data has to be provided. Historically, data was on the = device, as the connection between device and the network management was = slow. Today (like in MSDC), devices don't have local configuration, = those devices when boot look for provisioning system and get = configuration from a remote location and then change the state of the = device based on it. This has led that >=20 > 3. some vendors use Linux, allow management via pseudo file system = (/proc) >=20 > where the state of the device is changed directly without having a = need for data store on the device. You have to keep in mind that only = Linux allows changing the state of non-processes data through /proc. = *BSD flavors don't allow that. >=20 > So today, most network operators (by this I mean any entity that = operates a network, either enterprise or carrier), need to simplify = network management, make it more efficient and that devices will behave = very predictably, so that network is in a known state. Because of the = legacy, this is easiest done by having a local datastore on a device, = through which the state of the device is changed. >=20 > Hope this helps >=20 > Dean >=20 >=20 > On Oct 1, 2014, at 12:25 AM, Alia Atlas = > wrote: >=20 >> Hi, >>=20 >> I'd like to really understand why I2RS needs a datastore and what = that actually means. >> In my initial conception of what an I2RS agent would do for, say, = writing a route in the RIB >> model, is that the I2RS agent would simply parse a received request = from a standard format >> and model into the internal and pass that to a RIB Manager - just as = an OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also = query the RIB Manager to >> read routes and there'd be events coming out. >>=20 >> With the introduction of priorities to handle multi-headed writers = and collision errors, the I2RS agent would need to store what was = written by which client. >>=20 >> What benefits and rationale does a YANG datastore add? Why does = using one need to be >> standardized? >>=20 >> I apologize if this seems a naive question, but it's been quite a = while since I read up on YANG and NetConf/RestConf. >>=20 >> Regards, >> no-hats Alia >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_4F0A4C77-CBC8-451A-BE46-1D179E59492E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULDrTAAoJEPcO+I7eiUJZn58QALKt9DwiGDm4NCE/hok3r4Wl Vz725oiUGfQzKIVIbqnbYnFDychh9+ICrborHPlK/DE9W+kl7JnGyK4C5+Pglf+Y /DiWYQCPsICzL29vbpN2cpbFYTGV2vxo1QqUgcfYgCjWqpAs6RwvIMX7w+eYZ/kv kwCkgA5MXHe3Q29xnxn8qgj5jnTm3H3CADmdUTXRFfOdFrCd2Hs/eiWIscHCEH/S 3gWNfNptz7irf7l2R2wpVDEPZt1Uc8C7H5OWzjiucY2D+0491JQPgc8F7/P78drb XxBL7yle4ceokQhHcx1aZNrPpgg4Ma9svNBJMJKsq0DOgmeKtHgb1qTFOUJvNY7w NX53i1JiChRgc+S0mUdLuGPRKUsW3YVvWL+fwd599jRRTpcg2sbiZ34rjamNfV83 AXctFvCF5zoR8XYD9MWGk9gY6ieCzVv14+WIpscgpGoGhvLUq9xdLuafBt57bgiV rKq9soDoPvEgaVhos/rZxio/MPe0cgm5Rzq3GfiaQJajCMeKasyfV1pbbEq+16EJ K6TGefKAkI4TP7gY1I9eyszvmGQW1GygTevhQr9JF3rvL8YtMT5RwjjwdQr86ORm htGjcrX97z/kuItDhYEsOZCXcwt4hiit5RTiibzaAi5Dy3bYnT+rdqFmvEkyrwOt K6Vaa9/mzBfaTo6gYaeI =wR7B -----END PGP SIGNATURE----- --Apple-Mail=_4F0A4C77-CBC8-451A-BE46-1D179E59492E-- From nobody Wed Oct 1 10:43:41 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A641A1A92 for ; Wed, 1 Oct 2014 10:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ibO9Le1mPivu for ; Wed, 1 Oct 2014 10:43:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:769]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747311A1A79 for ; Wed, 1 Oct 2014 10:43:36 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 17:43:12 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 17:43:12 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++RqKttL9wxEexAlDYcQgC+ZwbP/0AgAAD/wCAADzGgIAAAGMAgAAC0YA= Date: Wed, 1 Oct 2014 17:43:11 +0000 Message-ID: References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> In-Reply-To: <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(129404003)(24454002)(51914003)(86362001)(62966002)(97736003)(46102003)(80022003)(77096002)(85852003)(88136002)(95666004)(82746002)(66066001)(101416001)(50986999)(50226001)(99286002)(92566001)(19617315012)(89996001)(77156001)(110136001)(85306004)(93886004)(92726001)(93916002)(76176999)(19580395003)(16236675004)(4396001)(10300001)(2656002)(33656002)(76482002)(106356001)(120916001)(36756003)(15975445006)(106116001)(87286001)(57306001)(31966008)(107046002)(21056001)(104166001)(20776003)(83716003)(87936001)(19580405001)(64706001)(99396003)(15202345003)(105586002)(23603001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_EFD9D9C861D24EBC90D3DCD9FC01E5FEjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dxu1-4k-2aqzEJOy-QOHxGJK8ws Cc: "i2rs@ietf.org" , Igor Bryskin , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:43:39 -0000 --_000_EFD9D9C861D24EBC90D3DCD9FC01E5FEjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, On Oct 1, 2014, at 1:33 PM, Thomas D. Nadeau > wrote: On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin > wrote: Alia, Your question makes sense if I2RS is limited to routing data manipulation. In this case it could be thought of as an additional routing protocol.After= all OSPF does not need any data store to install its routes, What if I2RS client want to configure other things? Then just use Netconf or RestConf. Isn't this contradictory to your statement made in http://www.ietf.org/mail= -archive/web/i2rs/current/msg02061.html Dean --Tom Igor ________________________________________ From: i2rs [i2rs-bounces@ietf.org] on behalf = of Alia Atlas [akatlas@gmail.com] Sent: Wednesday, October 1, 2014 9:54 AM To: Dean Bogdanovic Cc: i2rs@ietf.org Subject: Re: [i2rs] Why do we need a datastore? Hi Dean, Thanks for the explanation. It matches with what I understand for configur= ation. Where I am confused is why I2RS - which is doing ephemeral only and matches= closer to the direct proprietary APIs directly to the routing processes - is being tied up in this. Regards, Alia On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: Hi Alia, today networking devices can be managed in three ways: 1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it. Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices. 2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state. There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms. The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements) At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it. It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot lo= ok for provisioning system and get configuration from a remote location and= then change the state of the device based on it. This has led that 3. some vendors use Linux, allow management via pseudo file system (/proc) where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that. So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed. Hope this helps Dean On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: Hi, I'd like to really understand why I2RS needs a datastore and what that actu= ally means. In my initial conception of what an I2RS agent would do for, say, writing a= route in the RIB model, is that the I2RS agent would simply parse a received request from a= standard format and model into the internal and pass that to a RIB Manager - just as an OSP= F implementation might install a route to the RIB manager. An I2RS agent could also query t= he RIB Manager to read routes and there'd be events coming out. With the introduction of priorities to handle multi-headed writers and coll= ision errors, the I2RS agent would need to store what was written by which = client. What benefits and rationale does a YANG datastore add? Why does using one = need to be standardized? I apologize if this seems a naive question, but it's been quite a while sin= ce I read up on YANG and NetConf/RestConf. Regards, no-hats Alia _______________________________________________ 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 --_000_EFD9D9C861D24EBC90D3DCD9FC01E5FEjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <676D7060D6E09647A0DDC4731AA9CA6F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Tom,

On Oct 1, 2014, at 1:33 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:


On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin <IBryskin@advaoptical.com> wrote:

Alia,

Your question makes sense if I2RS is limited to routing data manipulation.<= br> In this case it could be thought of as an additional routing protocol.After= all OSPF does not need any data store to install its routes,
What if I2RS client want to configure other things?

Then just u= se Netconf or RestConf.

Isn't this contradictory to your statement made in http://www.ietf.or= g/mail-archive/web/i2rs/current/msg02061.html

Dean


--Tom


Igor
________________________________________
From: i2rs [i2rs-bounces@ietf.org<= /a>] on behalf of Alia Atlas [akatlas@= gmail.com]
Sent: Wednesday, October 1, 2014 9:54 AM
To: Dean Bogdanovic
Cc: i2rs@ietf.org
Subject: Re: [i2rs] Why do we need a datastore?

Hi Dean,

Thanks for the explanation.  It matches with what I understand for con= figuration.
Where I am confused is why I2RS - which is doing ephemeral only and matches= closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <deanb@juniper.net<mailto:deanb@juniper.net>> wrote:
Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device daemons which change their state based on i= t.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It still requires knowing how to config= ure device via CLI and the result of the application written with such APIs= is stored in the data store from which daemon read how to change their sta= te.
There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms.
The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now standardizing configuration and = operational model, so same configuration statement can be sent to all suppo= rting devices and be done (instead of writing same desired functionality in= several configuration statements)

At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot look for provisioning system and ge= t configuration from a remote location and then change the state of the dev= ice based on it. This has led that

3. some vendors use Linux, allow management via pseudo file system (/proc)<= br>
where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that.

So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest done by having a local datastore on= a device, through which the state of the device is changed.

Hope this helps

Dean


On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com<mailto:= akatlas@gmail.com>> wrote:

Hi,

I'd like to really understand why I2RS needs a datastore and what that actu= ally means.
In my initial conception of what an I2RS agent would do for, say, writing a= route in the RIB
model, is that  the I2RS agent would simply parse a received request f= rom a standard format
and model into the internal and pass that to a RIB Manager - just as an OSP= F implementation
might install a route to the RIB manager.  An I2RS agent could also qu= ery the RIB Manager to
read routes and there'd be events coming out.

With the introduction of priorities to handle multi-headed writers and coll= ision errors, the I2RS agent would need to store what was written by which = client.

What benefits and rationale does a YANG datastore add?  Why does using= one need to be
standardized?

I apologize if this seems a naive question, but it's been quite a while sin= ce I read up on YANG and NetConf/RestConf.

Regards,
no-hats  Alia

_______________________________________________
i2rs mailing list
i2rs@ietf.org<mailto:i2rs@ietf.org>
https://www.ietf.org= /mailman/listinfo/i2rs


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs



--_000_EFD9D9C861D24EBC90D3DCD9FC01E5FEjunipernet_-- From nobody Wed Oct 1 10:45:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBF91A1A8B for ; Wed, 1 Oct 2014 10:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 EXgHbkqlBwdl for ; Wed, 1 Oct 2014 10:45:52 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C241A1A67 for ; Wed, 1 Oct 2014 10:45:52 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s91Hjosa001295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 13:45:50 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 1 Oct 2014 13:45:50 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 1 Oct 2014 13:45:50 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.0995.028; Wed, 1 Oct 2014 13:45:50 -0400 From: Igor Bryskin To: "Thomas D. Nadeau" Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++hUDOdi/jUE6MWNaif21zLpwbgwsAgAAD/wD///cFUoAARiQA//+/6sA= Date: Wed, 1 Oct 2014 17:45:49 +0000 Message-ID: References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com>, <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> In-Reply-To: <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-01_06:2014-10-01,2014-10-01,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7K8TM9fgodnQqUtIQCxoPlJ42F0 Cc: "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:45:54 -0000 What if these things must not survive reboots? ________________________________________ From: Thomas D. Nadeau [tnadeau@lucidvision.com] Sent: Wednesday, October 1, 2014 1:33 PM To: Igor Bryskin Cc: Alia Atlas; Dean Bogdanovic; i2rs@ietf.org Subject: Re: [i2rs] Why do we need a datastore? On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin wrote: > Alia, > > Your question makes sense if I2RS is limited to routing data manipulation= . > In this case it could be thought of as an additional routing protocol.Aft= er all OSPF does not need any data store to install its routes, > What if I2RS client want to configure other things? Then just use Netconf or RestConf. --Tom > > Igor > ________________________________________ > From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas [akatlas@gmail= .com] > Sent: Wednesday, October 1, 2014 9:54 AM > To: Dean Bogdanovic > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Why do we need a datastore? > > Hi Dean, > > Thanks for the explanation. It matches with what I understand for config= uration. > Where I am confused is why I2RS - which is doing ephemeral only and match= es closer to the direct proprietary APIs directly to > the routing processes - is being tied up in this. > > Regards, > Alia > > On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: > Hi Alia, > > today networking devices can be managed in three ways: > > 1. CLI - is the UI we all know and use it quite heavily. In order for the= device to boot in a known state a set of CLI commands have to be saved som= ewhere on the device. For that you have a data store. That data store can b= e a flat file or a database. The datastore is then read by network device d= aemons which change their state based on it. > > Before the APIs were exposed, TCL/Expect and Perl ruled the automation wo= rld and everything was based on screen scraping. In order to make machine t= o machine communication easier, NETCONF was created as a standard protocol = to communicate with the devices. > > 2. via APIs - there are several type of APIs, but most widely available o= nes are providing functionalities same as CLI. The difference is that CLI i= s human intended and APIs are machine intended. One of the example is Junos= XML APIs, where (almost) each CLI command is represented by XML API. It st= ill requires knowing how to configure device via CLI and the result of the = application written with such APIs is stored in the data store from which d= aemon read how to change their state. > There are some vendors that provide APIs that allow communication with da= emons directly, bypassing management infrastructure, but those are highly p= roprietary mechanisms. > The APIs that were released by vendors, were not standardized and each ve= ndor had different configuration models, so although communication with dev= ices was standardized, there was no easy way to communicate semantics, whic= h led to YANG, as standard language that all vendors would understand and n= ow standardizing configuration and operational model, so same configuration= statement can be sent to all supporting devices and be done (instead of wr= iting same desired functionality in several configuration statements) > > At the end it really doesn't matter how you are communicating with the de= vices, it really boils down to that you want the device to boot into a know= n state. This was done by having a local data store that was containing set= of instructions what state the device should be after reading it. > > It really doesn't matter which mechanism is used (from above 2), configur= ation data has to be provided. Historically, data was on the device, as the= connection between device and the network management was slow. Today (like= in MSDC), devices don't have local configuration, those devices when boot = look for provisioning system and get configuration from a remote location a= nd then change the state of the device based on it. This has led that > > 3. some vendors use Linux, allow management via pseudo file system (/proc= ) > > where the state of the device is changed directly without having a need f= or data store on the device. You have to keep in mind that only Linux allow= s changing the state of non-processes data through /proc. *BSD flavors don'= t allow that. > > So today, most network operators (by this I mean any entity that operates= a network, either enterprise or carrier), need to simplify network managem= ent, make it more efficient and that devices will behave very predictably, = so that network is in a known state. Because of the legacy, this is easiest= done by having a local datastore on a device, through which the state of t= he device is changed. > > Hope this helps > > Dean > > > On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: > >> Hi, >> >> I'd like to really understand why I2RS needs a datastore and what that a= ctually means. >> In my initial conception of what an I2RS agent would do for, say, writin= g a route in the RIB >> model, is that the I2RS agent would simply parse a received request fro= m a standard format >> and model into the internal and pass that to a RIB Manager - just as an = OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also quer= y the RIB Manager to >> read routes and there'd be events coming out. >> >> With the introduction of priorities to handle multi-headed writers and c= ollision errors, the I2RS agent would need to store what was written by whi= ch client. >> >> What benefits and rationale does a YANG datastore add? Why does using o= ne need to be >> standardized? >> >> I apologize if this seems a naive question, but it's been quite a while = since I read up on YANG and NetConf/RestConf. >> >> Regards, >> no-hats Alia >> >> _______________________________________________ >> 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 > From nobody Wed Oct 1 10:53:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B21E1A1ABE for ; Wed, 1 Oct 2014 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 blG4Q-157fYo for ; Wed, 1 Oct 2014 10:53:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75911A1AC7 for ; Wed, 1 Oct 2014 10:53:09 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 1 Oct 2014 17:52:46 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 17:52:46 +0000 From: Dean Bogdanovic To: Igor Bryskin Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++RqKttL9wxEexAlDYcQgC+ZwbP/0AgAAD/wCAADzGgIAAAGMAgAADjoCAAAHwgA== Date: Wed, 1 Oct 2014 17:52:46 +0000 Message-ID: <21967216-315F-4563-A987-4B1564BE4911@juniper.net> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com>, <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(129404003)(199003)(24454002)(51914003)(51704005)(377454003)(20776003)(83716003)(2656002)(77156001)(36756003)(99286002)(110136001)(66066001)(4396001)(87286001)(106356001)(77096002)(93886004)(95666004)(105586002)(88136002)(62966002)(85852003)(82746002)(80022003)(106116001)(107046002)(15975445006)(33656002)(19580405001)(87936001)(57306001)(76482002)(50986999)(76176999)(21056001)(101416001)(99396003)(19580395003)(46102003)(93916002)(89996001)(92726001)(85306004)(50226001)(86362001)(92566001)(104166001)(120916001)(64706001)(10300001)(31966008)(97736003)(23603001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <430AD7163548EB4CAD2356FBC2531560@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/cO8h8JKsH5bUCQ2Ze7EhPfl1fR4 Cc: "Thomas D. Nadeau" , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:53:12 -0000 On Oct 1, 2014, at 1:45 PM, Igor Bryskin wrote: > What if these things must not survive reboots? There are plenty of mechanisms how this can be achieved. I2RS is not the on= ly way to create such non persistent configuration changes. > ________________________________________ > From: Thomas D. Nadeau [tnadeau@lucidvision.com] > Sent: Wednesday, October 1, 2014 1:33 PM > To: Igor Bryskin > Cc: Alia Atlas; Dean Bogdanovic; i2rs@ietf.org > Subject: Re: [i2rs] Why do we need a datastore? >=20 > On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin wrote: >=20 >> Alia, >>=20 >> Your question makes sense if I2RS is limited to routing data manipulatio= n. >> In this case it could be thought of as an additional routing protocol.Af= ter all OSPF does not need any data store to install its routes, >> What if I2RS client want to configure other things? >=20 > Then just use Netconf or RestConf. >=20 > --Tom >=20 >>=20 >> Igor >> ________________________________________ >> From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas [akatlas@gmai= l.com] >> Sent: Wednesday, October 1, 2014 9:54 AM >> To: Dean Bogdanovic >> Cc: i2rs@ietf.org >> Subject: Re: [i2rs] Why do we need a datastore? >>=20 >> Hi Dean, >>=20 >> Thanks for the explanation. It matches with what I understand for confi= guration. >> Where I am confused is why I2RS - which is doing ephemeral only and matc= hes closer to the direct proprietary APIs directly to >> the routing processes - is being tied up in this. >>=20 >> Regards, >> Alia >>=20 >> On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: >> Hi Alia, >>=20 >> today networking devices can be managed in three ways: >>=20 >> 1. CLI - is the UI we all know and use it quite heavily. In order for th= e device to boot in a known state a set of CLI commands have to be saved so= mewhere on the device. For that you have a data store. That data store can = be a flat file or a database. The datastore is then read by network device = daemons which change their state based on it. >>=20 >> Before the APIs were exposed, TCL/Expect and Perl ruled the automation w= orld and everything was based on screen scraping. In order to make machine = to machine communication easier, NETCONF was created as a standard protocol= to communicate with the devices. >>=20 >> 2. via APIs - there are several type of APIs, but most widely available = ones are providing functionalities same as CLI. The difference is that CLI = is human intended and APIs are machine intended. One of the example is Juno= s XML APIs, where (almost) each CLI command is represented by XML API. It s= till requires knowing how to configure device via CLI and the result of the= application written with such APIs is stored in the data store from which = daemon read how to change their state. >> There are some vendors that provide APIs that allow communication with d= aemons directly, bypassing management infrastructure, but those are highly = proprietary mechanisms. >> The APIs that were released by vendors, were not standardized and each v= endor had different configuration models, so although communication with de= vices was standardized, there was no easy way to communicate semantics, whi= ch led to YANG, as standard language that all vendors would understand and = now standardizing configuration and operational model, so same configuratio= n statement can be sent to all supporting devices and be done (instead of w= riting same desired functionality in several configuration statements) >>=20 >> At the end it really doesn't matter how you are communicating with the d= evices, it really boils down to that you want the device to boot into a kno= wn state. This was done by having a local data store that was containing se= t of instructions what state the device should be after reading it. >>=20 >> It really doesn't matter which mechanism is used (from above 2), configu= ration data has to be provided. Historically, data was on the device, as th= e connection between device and the network management was slow. Today (lik= e in MSDC), devices don't have local configuration, those devices when boot= look for provisioning system and get configuration from a remote location = and then change the state of the device based on it. This has led that >>=20 >> 3. some vendors use Linux, allow management via pseudo file system (/pro= c) >>=20 >> where the state of the device is changed directly without having a need = for data store on the device. You have to keep in mind that only Linux allo= ws changing the state of non-processes data through /proc. *BSD flavors don= 't allow that. >>=20 >> So today, most network operators (by this I mean any entity that operate= s a network, either enterprise or carrier), need to simplify network manage= ment, make it more efficient and that devices will behave very predictably,= so that network is in a known state. Because of the legacy, this is easies= t done by having a local datastore on a device, through which the state of = the device is changed. >>=20 >> Hope this helps >>=20 >> Dean >>=20 >>=20 >> On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: >>=20 >>> Hi, >>>=20 >>> I'd like to really understand why I2RS needs a datastore and what that = actually means. >>> In my initial conception of what an I2RS agent would do for, say, writi= ng a route in the RIB >>> model, is that the I2RS agent would simply parse a received request fr= om a standard format >>> and model into the internal and pass that to a RIB Manager - just as an= OSPF implementation >>> might install a route to the RIB manager. An I2RS agent could also que= ry the RIB Manager to >>> read routes and there'd be events coming out. >>>=20 >>> With the introduction of priorities to handle multi-headed writers and = collision errors, the I2RS agent would need to store what was written by wh= ich client. >>>=20 >>> What benefits and rationale does a YANG datastore add? Why does using = one need to be >>> standardized? >>>=20 >>> I apologize if this seems a naive question, but it's been quite a while= since I read up on YANG and NetConf/RestConf. >>>=20 >>> Regards, >>> no-hats Alia >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 From nobody Wed Oct 1 11:16:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FBC1A1B84 for ; Wed, 1 Oct 2014 11:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 QgI3Lrf0x6Hm for ; Wed, 1 Oct 2014 11:15:42 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAAC1A1B82 for ; Wed, 1 Oct 2014 11:15:41 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so688979qgf.20 for ; Wed, 01 Oct 2014 11:15:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+bfGhMCKPSM+ITe6AB6siv0ht+8fLUQlNLibDpQaEwA=; b=cWaoPF6pzF9rMCMuoYxIrFBx/sqctQVT8WIsxJFpE4tUIEbjH7Kyxlz42vmr0+N8g2 l8zQ7Cv+0LqmF0nBK42j8EfBJBeWYzZnxLBXSYgRznP6FJR0rp2WjnEHrYzcAx//bCQS M0ZZ/NA2SGitH9efYofM5dtV57gRJO5qxOFII1+X/0dWG0nxmY8Y7+TME+eihoxTZRpf /EEf30LOro7X98z8nXm6aWqRXBsG0w25chViIJkLs4ajfClw/IL5t6OonGDK39lzn/MK kJssL6F66Ga42jAuePfskygw9otaKv8HRpVY3QRrfLvsUKEWXvzSRes/0HLAvN75yxiu oJRg== X-Gm-Message-State: ALoCoQn3O/bTsUgpsCsl/O7g5b1zVmd3Y6SZMgDGBvZDR1FpMfFJQZcoUqtW+jirGVm62vFDrZMK MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr34903070qgl.90.1412187340888; Wed, 01 Oct 2014 11:15:40 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 1 Oct 2014 11:15:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Oct 2014 11:15:40 -0700 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c13986cf9b6b0504607c96 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/04CQ2mRs5_k1MVfa1bFY1KiKtSg Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:16:00 -0000 --001a11c13986cf9b6b0504607c96 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas wrote: > Hi, > > I'd like to really understand why I2RS needs a datastore and what that > actually means. > In my initial conception of what an I2RS agent would do for, say, writing > a route in the RIB > model, is that the I2RS agent would simply parse a received request from > a standard format > and model into the internal and pass that to a RIB Manager - just as an > OSPF implementation > might install a route to the RIB manager. An I2RS agent could also query > the RIB Manager to > read routes and there'd be events coming out. > > With the introduction of priorities to handle multi-headed writers and > collision errors, the I2RS agent would need to store what was written by > which client. > > What benefits and rationale does a YANG datastore add? Why does using one > need to be > standardized? > > I apologize if this seems a naive question, but it's been quite a while > since I read up on YANG and NetConf/RestConf. > > It is a great question because the datastore is used for 3 reasons in NETCONF/YANG. 1) conceptual container for top-level YANG data nodes 1a) source parameter for retrieval; target parameter for editing 2) conceptual container for YANG validation rules for the running datastore 3) conceptual container for access control model I don't agree that multiple ephemeral datastores are needed. Support for multiple clients within 1 datastore is needed. YANG validation rules for the ephemeral datastore are not interesting, just the "active" config (running + ephemeral). The access control model for I2RS is different than NETCONF. Recent discussion has me confused: A) Are the YANG modules exactly the same for the running and ephemeral datastores? (Interim decided yes) B) How are the same instances of the same data model related in the running and ephemeral datastores? I thought "phase 1" was supposed to be simple and the I2RS client would just inject and remove RIB data to override the running config. So, answer to (B) is: datastores have independent instances. If ephemeral instance exists, it is used. If deleted, then the instance from the running config (if any) becomes active. As long as the ephemeral instance exists, the running config instance is ignored. Is this consistent with the architecture document? Which solution best fits the agreed upon architecture? Regards, > no-hats Alia > > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c13986cf9b6b0504607c96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi,

= I'd like to really understand why I2RS needs a datastore and what that = actually means.
In my initial conception of what an I2RS agent wo= uld do for, say, writing a route in the RIB
model, is that =A0the= I2RS agent would simply parse a received request from a standard format=A0=
and model into the internal and pass that to a RIB Manager - jus= t as an OSPF implementation=A0
might install a route to the RIB m= anager.=A0 An I2RS agent could also query the RIB Manager to=A0
r= ead routes and there'd be events coming out.

W= ith the introduction of priorities to handle multi-headed writers and colli= sion errors, the I2RS agent would need to store what was written by which c= lient.

What benefits and rationale does a YANG dat= astore add?=A0 Why does using one need to be
standardized?
<= div>
I apologize if this seems a naive question, but it's= been quite a while since I read up on YANG and NetConf/RestConf. =A0
=


It is a great questio= n because the datastore is used for 3 reasons in NETCONF/YANG.
=A0 1) conceptual container for top-level YANG data nodes
=A0 =A0 =A0 =A0=A01a) source parameter for retrieval; target paramete= r for editing
=A0 2) conceptual container for YANG validation rul= es for the running datastore
=A0 3) conceptual container for acce= ss control model
=A0=A0

I don't agre= e that multiple ephemeral datastores are needed. Support for multiple clien= ts
within 1 datastore is needed.=A0

YANG= validation rules for the ephemeral datastore are not interesting, just the= "active"
config (running + ephemeral). The access cont= rol model for I2RS is different than NETCONF.

Rece= nt discussion has me confused:

=A0 =A0A) Are the Y= ANG modules exactly the same for the running and ephemeral datastores?
=A0 =A0(Interim decided yes)

=A0 =A0B) How a= re the same instances of the same data model related in the running and eph= emeral
=A0 =A0 =A0 =A0 datastores?

I tho= ught "phase 1" was supposed to be simple and the I2RS client woul= d just inject and remove
RIB data to override the running config.= =A0 So, answer to (B) is: datastores have independent
instances. = If ephemeral instance exists, it is used. If deleted, then the instance fro= m the
running config (if any) becomes active.=A0 As long as the e= phemeral instance exists, the running config
instance is ignored.=

Is this consistent with the architecture document= ?
Which solution best fits the agreed upon architecture?





Regards,
no-hats = =A0Alia


Andy
=A0

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--001a11c13986cf9b6b0504607c96-- From nobody Wed Oct 1 12:19:35 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926A51A6FCD for ; Wed, 1 Oct 2014 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham 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 fKmjmeiordj7 for ; Wed, 1 Oct 2014 12:19:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9621A1C05 for ; Wed, 1 Oct 2014 12:19:30 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 420281280997; Wed, 1 Oct 2014 21:19:29 +0200 (CEST) Date: Wed, 01 Oct 2014 21:19:28 +0200 (CEST) Message-Id: <20141001.211928.310915377.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <542C157C.40305@joelhalpern.com> References: <542C157C.40305@joelhalpern.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/05-R8igVqQgd_5XP6DkYNjRVHYk Cc: i2rs@ietf.org, akatlas@gmail.com Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:19:32 -0000 "Joel M. Halpern" wrote: > I had assumed that the YANG "datastore" was the repository in which the I2RS > agent stored all of the operations it had applied, who had applied them, etc. Yes. > This actually does lead to a related question. > How does an I2RS client delte the state it has created. (Jeff replied to this) > (Note that said state > might actually include a deletion from the underlying data.) Right, we also discussed this at the interim. The idea we discussed was the ability to tag a subtree with an operation, which could be "merge", "replace" or "delete" (with "merge" being the default). > The client is not required to have the knowledge of what the config / I2RS > state was before it performed its operation. In this case it probably should use the "replace" operation - this ensures that the data in the "active" config is exactly what's in the ephemeral store, regardless of what was in the local config. /martin From nobody Wed Oct 1 12:23:51 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BFC1A700B for ; Wed, 1 Oct 2014 12:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1gbNoHG4iE2s for ; Wed, 1 Oct 2014 12:23:46 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7EA1A7005 for ; Wed, 1 Oct 2014 12:23:46 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id BAAA128AB442; Wed, 1 Oct 2014 15:23:44 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_90FDC301-4C4D-4216-A70A-184E80924044"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 1 Oct 2014 12:23:41 -0700 Message-Id: <1F252D5E-BA2A-42A5-8851-3A0C613C3004@lucidvision.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/fFQr1Z-951tkmFd5OcPkLy-NkZU Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:23:48 -0000 --Apple-Mail=_90FDC301-4C4D-4216-A70A-184E80924044 Content-Type: multipart/alternative; boundary="Apple-Mail=_E2565773-3604-4423-BEBD-B4AD669B02E2" --Apple-Mail=_E2565773-3604-4423-BEBD-B4AD669B02E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 1, 2014:11:15 AM, at 11:15 AM, Andy Bierman = wrote: >=20 >=20 > On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas wrote: > Hi, >=20 > I'd like to really understand why I2RS needs a datastore and what that = actually means. > In my initial conception of what an I2RS agent would do for, say, = writing a route in the RIB > model, is that the I2RS agent would simply parse a received request = from a standard format=20 > and model into the internal and pass that to a RIB Manager - just as = an OSPF implementation=20 > might install a route to the RIB manager. An I2RS agent could also = query the RIB Manager to=20 > read routes and there'd be events coming out. >=20 > With the introduction of priorities to handle multi-headed writers and = collision errors, the I2RS agent would need to store what was written by = which client. >=20 > What benefits and rationale does a YANG datastore add? Why does using = one need to be > standardized? >=20 > I apologize if this seems a naive question, but it's been quite a = while since I read up on YANG and NetConf/RestConf. =20 >=20 >=20 > It is a great question because the datastore is used for 3 reasons in = NETCONF/YANG. >=20 > 1) conceptual container for top-level YANG data nodes > 1a) source parameter for retrieval; target parameter for = editing > 2) conceptual container for YANG validation rules for the running = datastore > 3) conceptual container for access control model > =20 >=20 > I don't agree that multiple ephemeral datastores are needed. Support = for multiple clients > within 1 datastore is needed.=20 That is precisely the point I've been making. We've been making = this discussion far too complex. =20 > YANG validation rules for the ephemeral datastore are not interesting, = just the "active" > config (running + ephemeral). The access control model for I2RS is = different than NETCONF. >=20 > Recent discussion has me confused: >=20 > A) Are the YANG modules exactly the same for the running and = ephemeral datastores? > (Interim decided yes) Lets hope so, or we've gone off into the woods... > B) How are the same instances of the same data model related in the = running and ephemeral > datastores? >=20 > I thought "phase 1" was supposed to be simple and the I2RS client = would just inject and remove > RIB data to override the running config. So, answer to (B) is: = datastores have independent > instances. If ephemeral instance exists, it is used. If deleted, then = the instance from the > running config (if any) becomes active. As long as the ephemeral = instance exists, the running config > instance is ignored. >=20 > Is this consistent with the architecture document? > Which solution best fits the agreed upon architecture? >=20 >=20 >=20 >=20 >=20 > Regards, > no-hats Alia >=20 >=20 > Andy > =20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_E2565773-3604-4423-BEBD-B4AD669B02E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Oct 1, 2014:11:15 AM, at 11:15 AM, = Andy Bierman <andy@yumaworks.com> = wrote:



On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas <akatlas@gmail.com> wrote:
Hi,

I'd= like to really understand why I2RS needs a datastore and what that = actually means.
In my initial conception of what an I2RS agent = would do for, say, writing a route in the RIB
model, is that =  the I2RS agent would simply parse a received request from a = standard format 
and model into the internal and pass = that to a RIB Manager - just as an OSPF = implementation 
might install a route to the RIB = manager.  An I2RS agent could also query the RIB Manager = to 
read routes and there'd be events coming = out.

With the introduction of priorities to = handle multi-headed writers and collision errors, the I2RS agent would = need to store what was written by which = client.

What benefits and rationale does a YANG = datastore add?  Why does using one need to = be
standardized?

I apologize if this = seems a naive question, but it's been quite a while since I read up on = YANG and NetConf/RestConf. =  


It is = a great question because the datastore is used for 3 reasons in = NETCONF/YANG.

  1) conceptual container = for top-level YANG data nodes
      =   1a) source parameter for retrieval; target parameter for = editing
  2) conceptual container for YANG validation = rules for the running datastore
  3) conceptual container = for access control = model
  

I don't agree that = multiple ephemeral datastores are needed. Support for multiple = clients
within 1 datastore is = needed. 

That is = precisely the point I've been making. We've been making this discussion = far too complex.  

YANG validation rules for the ephemeral = datastore are not interesting, just the "active"
config = (running + ephemeral). The access control model for I2RS is different = than NETCONF.

Recent discussion has me = confused:

   A) Are the YANG modules = exactly the same for the running and ephemeral = datastores?
   (Interim decided = yes)

Lets hope = so, or we've gone off into the woods...

   B) How are the same instances of = the same data model related in the running and = ephemeral
        = datastores?

I thought "phase 1" was supposed to = be simple and the I2RS client would just inject and remove
RIB = data to override the running config.  So, answer to (B) is: = datastores have independent
instances. If ephemeral instance = exists, it is used. If deleted, then the instance from = the
running config (if any) becomes active.  As long as = the ephemeral instance exists, the running config
instance is = ignored.

Is this consistent with the = architecture document?
Which solution best fits the agreed = upon = architecture?




<= /div>

Regards,
no-hats =  Alia


Andy=
 

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/ma= ilman/listinfo/i2rs

= --Apple-Mail=_E2565773-3604-4423-BEBD-B4AD669B02E2-- --Apple-Mail=_90FDC301-4C4D-4216-A70A-184E80924044 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULFS+AAoJEPcO+I7eiUJZGQcQALR8FoZOprOGWwXCKifcbLiX dP/Q4PJ+ZFvhMlTUflw57xlKveYrpdMK7kzvrQ2XaJavTjMwc62+vALg/t7SQGbb PBHwaTmhtDwQKqxe3lcTDiTvTdxuMXS3HrjNPF1JqaP1uf+fsgQNCVHw6iUayieN XfqPjsqCk1VozJfoNBzjLGUZvGjqaK28EsG1MD8Tgu3v6+VbI+Ek+wcv+KF0UBfo uEtmDkENYieOhHJcD0Kx7331brkqpS99WsjB5H5UjFsBTgiBw2PnpNvkhNVSdQhG eM5z71EftNVDka53qrRuMkuHH2wph+x253tfIrYSvwwAj6KBoBQJmTDy4ffV3bde cWmC8u3ou8B1fiFyY5pv3derMM6QHzM5QsmnZ59PBbSlK8qvmpbZ3COrCk44fUb1 rPu2nFWnHjiEKMKJOkRzYyBPRGtXXT/+xBDGQZdJ6PrNY0LWzLzISkJzsvaaLpYZ tsjV/x/5Vs7l+GMk8d7R9WyQ0OwoZ+RaCix/K1KZlXETU1ChRs9jtz8DRPoH9mGN CIsco/qnZdxn2frm+xZRkFjScBjw/XiyP4Bqp3uyez7VG3zfyovTtj/UrksWLHcU siNz0PjdYhztZ/I2xJV2LxQ3w2RShF+MXbmxLqFdCMoHQZH8XISIZX6av1wriyN9 j+LeYf7eR+AO3YuyydPW =sD1r -----END PGP SIGNATURE----- --Apple-Mail=_90FDC301-4C4D-4216-A70A-184E80924044-- From nobody Wed Oct 1 12:25:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4E51A701F for ; Wed, 1 Oct 2014 12:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 g1jDzk6Fh2yR for ; Wed, 1 Oct 2014 12:25:17 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A73BD1A700C for ; Wed, 1 Oct 2014 12:25:16 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id 50FF828AB457; Wed, 1 Oct 2014 15:25:15 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DDE5622D-1395-44C7-89A8-1A96A22DC7A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Wed, 1 Oct 2014 12:25:12 -0700 Message-Id: <5A60C18F-DC9E-4839-9B3F-8D341B4D2208@lucidvision.com> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com>, <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> To: Igor Bryskin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tunwFgrM19v6Yk06GwLOa-Uy6e8 Cc: "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:25:18 -0000 --Apple-Mail=_DDE5622D-1395-44C7-89A8-1A96A22DC7A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is where the "copy to running config" discussion has = arrived at. We either need a special i2rs "operation" or just a "write = to config" object that can be set and triggers the action. But by = default, the changes are ephemeral and thus do not survive reboots. --Tom On Oct 1, 2014:10:45 AM, at 10:45 AM, Igor Bryskin = wrote: > What if these things must not survive reboots? > ________________________________________ > From: Thomas D. Nadeau [tnadeau@lucidvision.com] > Sent: Wednesday, October 1, 2014 1:33 PM > To: Igor Bryskin > Cc: Alia Atlas; Dean Bogdanovic; i2rs@ietf.org > Subject: Re: [i2rs] Why do we need a datastore? >=20 > On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin = wrote: >=20 >> Alia, >>=20 >> Your question makes sense if I2RS is limited to routing data = manipulation. >> In this case it could be thought of as an additional routing = protocol.After all OSPF does not need any data store to install its = routes, >> What if I2RS client want to configure other things? >=20 > Then just use Netconf or RestConf. >=20 > --Tom >=20 >>=20 >> Igor >> ________________________________________ >> From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas = [akatlas@gmail.com] >> Sent: Wednesday, October 1, 2014 9:54 AM >> To: Dean Bogdanovic >> Cc: i2rs@ietf.org >> Subject: Re: [i2rs] Why do we need a datastore? >>=20 >> Hi Dean, >>=20 >> Thanks for the explanation. It matches with what I understand for = configuration. >> Where I am confused is why I2RS - which is doing ephemeral only and = matches closer to the direct proprietary APIs directly to >> the routing processes - is being tied up in this. >>=20 >> Regards, >> Alia >>=20 >> On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic = > wrote: >> Hi Alia, >>=20 >> today networking devices can be managed in three ways: >>=20 >> 1. CLI - is the UI we all know and use it quite heavily. In order for = the device to boot in a known state a set of CLI commands have to be = saved somewhere on the device. For that you have a data store. That data = store can be a flat file or a database. The datastore is then read by = network device daemons which change their state based on it. >>=20 >> Before the APIs were exposed, TCL/Expect and Perl ruled the = automation world and everything was based on screen scraping. In order = to make machine to machine communication easier, NETCONF was created as = a standard protocol to communicate with the devices. >>=20 >> 2. via APIs - there are several type of APIs, but most widely = available ones are providing functionalities same as CLI. The difference = is that CLI is human intended and APIs are machine intended. One of the = example is Junos XML APIs, where (almost) each CLI command is = represented by XML API. It still requires knowing how to configure = device via CLI and the result of the application written with such APIs = is stored in the data store from which daemon read how to change their = state. >> There are some vendors that provide APIs that allow communication = with daemons directly, bypassing management infrastructure, but those = are highly proprietary mechanisms. >> The APIs that were released by vendors, were not standardized and = each vendor had different configuration models, so although = communication with devices was standardized, there was no easy way to = communicate semantics, which led to YANG, as standard language that all = vendors would understand and now standardizing configuration and = operational model, so same configuration statement can be sent to all = supporting devices and be done (instead of writing same desired = functionality in several configuration statements) >>=20 >> At the end it really doesn't matter how you are communicating with = the devices, it really boils down to that you want the device to boot = into a known state. This was done by having a local data store that was = containing set of instructions what state the device should be after = reading it. >>=20 >> It really doesn't matter which mechanism is used (from above 2), = configuration data has to be provided. Historically, data was on the = device, as the connection between device and the network management was = slow. Today (like in MSDC), devices don't have local configuration, = those devices when boot look for provisioning system and get = configuration from a remote location and then change the state of the = device based on it. This has led that >>=20 >> 3. some vendors use Linux, allow management via pseudo file system = (/proc) >>=20 >> where the state of the device is changed directly without having a = need for data store on the device. You have to keep in mind that only = Linux allows changing the state of non-processes data through /proc. = *BSD flavors don't allow that. >>=20 >> So today, most network operators (by this I mean any entity that = operates a network, either enterprise or carrier), need to simplify = network management, make it more efficient and that devices will behave = very predictably, so that network is in a known state. Because of the = legacy, this is easiest done by having a local datastore on a device, = through which the state of the device is changed. >>=20 >> Hope this helps >>=20 >> Dean >>=20 >>=20 >> On Oct 1, 2014, at 12:25 AM, Alia Atlas = > wrote: >>=20 >>> Hi, >>>=20 >>> I'd like to really understand why I2RS needs a datastore and what = that actually means. >>> In my initial conception of what an I2RS agent would do for, say, = writing a route in the RIB >>> model, is that the I2RS agent would simply parse a received request = from a standard format >>> and model into the internal and pass that to a RIB Manager - just as = an OSPF implementation >>> might install a route to the RIB manager. An I2RS agent could also = query the RIB Manager to >>> read routes and there'd be events coming out. >>>=20 >>> With the introduction of priorities to handle multi-headed writers = and collision errors, the I2RS agent would need to store what was = written by which client. >>>=20 >>> What benefits and rationale does a YANG datastore add? Why does = using one need to be >>> standardized? >>>=20 >>> I apologize if this seems a naive question, but it's been quite a = while since I read up on YANG and NetConf/RestConf. >>>=20 >>> Regards, >>> no-hats Alia >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_DDE5622D-1395-44C7-89A8-1A96A22DC7A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULFUYAAoJEPcO+I7eiUJZE1YP/iGwfw4vD1nDjCeCRyatrKcM 8R/E1P7EHfnfTdUCoKQ53k9iwmrSOAqhT9BqHzMiU1M0CphNnAMJf6i4UjwT81rE JHlktRpOYlNi7jq14x5NQ/9zA2cObi7wsqYFvd+vR6aH8wyjbTaDRBwpiiTVpMsL 9R9jbhRZ2qVkV1SrjsHPOM3xU8Ynwn0PlibZsACgBHYOWvcqSZIWGVdkpE6KbVEO LgWfkcDZAvGgwAfc4/8Ry5TN3vrNfImQFndYmWUzoCpWP8Sg5KoPzG9/TvSiSoCN SXAzkq5gZWBfH6DfCCiodzuY5JYTcHm1gsNk8h5pr/pLVN/DvIAWpH+OaqxNShdZ MUK9eC1JUZ7h8ymbduKnnN7NmAFN7rIQ/P4lmYmFceCxJBeW/AxcTN7/RBAH7AOW IQONsmleTmq5Jl5lEAnKK44zzSubm8FpMuwnCLiKeb/QPFN/zAh2tR5THydhyzBX 95l2Zi94arGj4m2ibGZ7biUSOqdDc7IUV8nJCRaAT2KBGtT3TlscxIutvGgPeWPm z6kti0/w5oN31xj4mMjvU816E515+dX1+e+UsCxkFDqWP+wdE1jMv3JNxxZLN27L qm/3O2feZiQq/IMp/JB4zkIQ3ceMc5kt9hwUeXCZcal648qXW6m5pxHp7Bs/odQL izY5WfR0BmDMBvprH42B =oslF -----END PGP SIGNATURE----- --Apple-Mail=_DDE5622D-1395-44C7-89A8-1A96A22DC7A7-- From nobody Wed Oct 1 13:35:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF031A8785 for ; Wed, 1 Oct 2014 13:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pkgkjk519xxB for ; Wed, 1 Oct 2014 13:35:02 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E2E1A86E1 for ; Wed, 1 Oct 2014 13:35:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3F8BE24014D; Wed, 1 Oct 2014 13:35:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 8D6F4240399; Wed, 1 Oct 2014 13:35:01 -0700 (PDT) Message-ID: <542C6574.9040608@joelhalpern.com> Date: Wed, 01 Oct 2014 16:35:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Igor Bryskin , Alia Atlas , Dean Bogdanovic References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net>, <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EyO9STf43N6oD4_OXHDOFk5dG-8 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:35:08 -0000 Actually, in most OSPF implementations, there are two relevant data stores. OSPF often has one data store internally, and routes get installed into a common RIB, managed by a RIB manager, which is clearly a datastore. It seems to me that "datastore" is just a descriptive term for the set of manipulable state information. It has been clear from the outset that I2RS had to store the operations it applied in some meaningful fashion. Otherwise it could not do collision detection, or operation removal. Yours, Joel On 10/1/14, 1:31 PM, Igor Bryskin wrote: > Alia, > > Your question makes sense if I2RS is limited to routing data manipulation. > In this case it could be thought of as an additional routing protocol.After all OSPF does not need any data store to install its routes, > What if I2RS client want to configure other things? > > Igor > ________________________________________ > From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas [akatlas@gmail.com] > Sent: Wednesday, October 1, 2014 9:54 AM > To: Dean Bogdanovic > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Why do we need a datastore? > > Hi Dean, > > Thanks for the explanation. It matches with what I understand for configuration. > Where I am confused is why I2RS - which is doing ephemeral only and matches closer to the direct proprietary APIs directly to > the routing processes - is being tied up in this. > > Regards, > Alia > > On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: > Hi Alia, > > today networking devices can be managed in three ways: > > 1. CLI - is the UI we all know and use it quite heavily. In order for the device to boot in a known state a set of CLI commands have to be saved somewhere on the device. For that you have a data store. That data store can be a flat file or a database. The datastore is then read by network device daemons which change their state based on it. > > Before the APIs were exposed, TCL/Expect and Perl ruled the automation world and everything was based on screen scraping. In order to make machine to machine communication easier, NETCONF was created as a standard protocol to communicate with the devices. > > 2. via APIs - there are several type of APIs, but most widely available ones are providing functionalities same as CLI. The difference is that CLI is human intended and APIs are machine intended. One of the example is Junos XML APIs, where (almost) each CLI command is represented by XML API. It still requires knowing how to configure device via CLI and the result of the application written with such APIs is stored in the data store from which daemon read how to change their state. > There are some vendors that provide APIs that allow communication with daemons directly, bypassing management infrastructure, but those are highly proprietary mechanisms. > The APIs that were released by vendors, were not standardized and each vendor had different configuration models, so although communication with devices was standardized, there was no easy way to communicate semantics, which led to YANG, as standard language that all vendors would understand and now standardizing configuration and operational model, so same configuration statement can be sent to all supporting devices and be done (instead of writing same desired functionality in several configuration statements) > > At the end it really doesn't matter how you are communicating with the devices, it really boils down to that you want the device to boot into a known state. This was done by having a local data store that was containing set of instructions what state the device should be after reading it. > > It really doesn't matter which mechanism is used (from above 2), configuration data has to be provided. Historically, data was on the device, as the connection between device and the network management was slow. Today (like in MSDC), devices don't have local configuration, those devices when boot look for provisioning system and get configuration from a remote location and then change the state of the device based on it. This has led that > > 3. some vendors use Linux, allow management via pseudo file system (/proc) > > where the state of the device is changed directly without having a need for data store on the device. You have to keep in mind that only Linux allows changing the state of non-processes data through /proc. *BSD flavors don't allow that. > > So today, most network operators (by this I mean any entity that operates a network, either enterprise or carrier), need to simplify network management, make it more efficient and that devices will behave very predictably, so that network is in a known state. Because of the legacy, this is easiest done by having a local datastore on a device, through which the state of the device is changed. > > Hope this helps > > Dean > > > On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: > >> Hi, >> >> I'd like to really understand why I2RS needs a datastore and what that actually means. >> In my initial conception of what an I2RS agent would do for, say, writing a route in the RIB >> model, is that the I2RS agent would simply parse a received request from a standard format >> and model into the internal and pass that to a RIB Manager - just as an OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also query the RIB Manager to >> read routes and there'd be events coming out. >> >> With the introduction of priorities to handle multi-headed writers and collision errors, the I2RS agent would need to store what was written by which client. >> >> What benefits and rationale does a YANG datastore add? Why does using one need to be >> standardized? >> >> I apologize if this seems a naive question, but it's been quite a while since I read up on YANG and NetConf/RestConf. >> >> Regards, >> no-hats Alia >> >> _______________________________________________ >> 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 > From nobody Wed Oct 1 15:06:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99571A87C2 for ; Wed, 1 Oct 2014 15:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 ks6h-EeQY7g6 for ; Wed, 1 Oct 2014 15:05:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CDE1A87C1 for ; Wed, 1 Oct 2014 15:05:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AEC00F91; Thu, 2 Oct 2014 00:05:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W7pOHrRg6mI4; Thu, 2 Oct 2014 00:05:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Oct 2014 00:05:49 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C34D020036; Thu, 2 Oct 2014 00:05:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1BV8LMcTGAUV; Thu, 2 Oct 2014 00:05:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6159B20035; Thu, 2 Oct 2014 00:05:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 71C4E2EBF05B; Thu, 2 Oct 2014 00:05:47 +0200 (CEST) Date: Thu, 2 Oct 2014 00:05:46 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141001220545.GA39249@elstar.local> Mail-Followup-To: Andy Bierman , Alia Atlas , "i2rs@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FM2weqwllvJpyLMVqhgkRCwjcSA Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:05:57 -0000 On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote: > > I don't agree that multiple ephemeral datastores are needed. Support for > multiple clients within 1 datastore is needed. > We can punt this but I believe we will be back discussing this again in a couple of years. If multiple clients inject state (in an uncoordinated way), certain things will go wrong. If we have no way to separate multipe uncoordinated I2RS clients (e.g., by controlling the priorities of different ephemeral datastores), then we will need hacks with metadata to work around this. Perhaps it is OK to ignore multiple ephemeral datastores now in order to make progress. But I believe we are better off if things are designed such that there can be multiple ephemeral datastores when they are useful, that is we should not do anything to prevent having multiple ephemeral datastores. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Oct 1 15:19:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F901A87BF for ; Wed, 1 Oct 2014 15:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hrr_gLs4FKJB for ; Wed, 1 Oct 2014 15:18:53 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8BC1A87CC for ; Wed, 1 Oct 2014 15:18:52 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so1012600qap.32 for ; Wed, 01 Oct 2014 15:18:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pIAbjC/tXclObcBRhuJ6S5H2+T5xP+54DJC/HAMo4Ns=; b=c6Vj4+7SvcWhCH+y1r2AuDUWuvngXJOxi8WMTawa3dxu74Itp+YlLFlmeORc33uV63 vV8iFyFbWQe5f2/SS/4X5PfH784F3TEbMIqRbqeB65NVjMuIDkPt/JxfQqD2gH40dPoF piq1T3PS9teqWfRYO7MoCFD3t1WzhaANNkWxqQqFHj9UuPqTFoOces2H1OGovA71g8Lt 8OMR8MWraIR/nL+YLKvYhEF0iNiXw3svMceUAtwlODJCT4ecRru4GrYe/YwoiF35qd2X GNclOtZhCTuy1c468Wzm5Vqf0Dz3Fp6VlRUzG4kALlOJc8KrzFdg6H8/rU5cnZVkS3k7 Uh2Q== X-Gm-Message-State: ALoCoQl6NyuP1rHpwuken09VL7gZXzZP0vA+fY3RJ9zbwh2Ba68MNXCZuB0GMerYFe93QDRSQ9zn MIME-Version: 1.0 X-Received: by 10.140.102.235 with SMTP id w98mr6460412qge.35.1412201931919; Wed, 01 Oct 2014 15:18:51 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 1 Oct 2014 15:18:51 -0700 (PDT) In-Reply-To: <20141001220545.GA39249@elstar.local> References: <20141001220545.GA39249@elstar.local> Date: Wed, 1 Oct 2014 15:18:51 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Alia Atlas , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1664c80f7e3050463e2a7 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UBKnlIji8vFoQNZmQXWNbCxNbkM Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 22:18:57 -0000 --001a11c1664c80f7e3050463e2a7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 1, 2014 at 3:05 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote: > > > > I don't agree that multiple ephemeral datastores are needed. Support for > > multiple clients within 1 datastore is needed. > > > > We can punt this but I believe we will be back discussing this again > in a couple of years. If multiple clients inject state (in an > uncoordinated way), certain things will go wrong. If we have no way to > separate multipe uncoordinated I2RS clients (e.g., by controlling the > priorities of different ephemeral datastores), then we will need hacks > with metadata to work around this. > > There are different priorities for clients. The collision management and cleanup are basically the same either way, because the agent is not required to remember state that got bumped. It that were true, then a separate datastore per client would be a feature instead of an implementation detail. Perhaps it is OK to ignore multiple ephemeral datastores now in order > to make progress. But I believe we are better off if things are > designed such that there can be multiple ephemeral datastores when > they are useful, that is we should not do anything to prevent having > multiple ephemeral datastores. > It's hard enough to agree on 1 ;-) IMO the ephemeral config always overrides the running config. That means in order to remove a static entry from the active config (but not the running config), there needs to be an operation for creating a "data instance deleted" entry in the ephemeral datastore. (Not a way to have I2RS actually delete entries from the running config). > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c1664c80f7e3050463e2a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 1, 2014 at 3:05 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierma= n wrote:
>
> I don't agree that multiple ephemeral datastores are needed. Suppo= rt for
> multiple clients within 1 datastore is needed.
>

We can punt this but I believe we will be back discussing this again
in a couple of years. If multiple clients inject state (in an
uncoordinated way), certain things will go wrong. If we have no way to
separate multipe uncoordinated I2RS clients (e.g., by controlling the
priorities of different ephemeral datastores), then we will need hacks
with metadata to work around this.


There are different priorities for cli= ents.
The collision management and cleanup are basically the same= either way,
because the agent is not required to remember state = that got bumped.
It that were true, then a separate datastore per= client would be a feature
instead of an implementation detail.

Perhaps it is OK to ignore multiple ephemeral datastores now in order
to make progress. But I believe we are better off if things are
designed such that there can be multiple ephemeral datastores when
they are useful, that is we should not do anything to prevent having
multiple ephemeral datastores.

It's= hard enough to agree on 1 ;-)

IMO the ephemeral c= onfig always overrides the running config.
That means in order to= remove a static entry from the active config
(but not the runnin= g config), there needs to be an operation
for creating a "da= ta instance deleted" entry in the ephemeral datastore.
(Not = a way to have I2RS actually delete entries from the running config).
<= div>



/js


Andy
=A0
=
--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c1664c80f7e3050463e2a7-- From nobody Thu Oct 2 04:50:12 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A331A1ACE for ; Thu, 2 Oct 2014 04:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 3LMciuZetizC for ; Thu, 2 Oct 2014 04:50:06 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 B88B41A1AD0 for ; Thu, 2 Oct 2014 04:49:59 -0700 (PDT) Received: from cpe-076-182-054-123.nc.res.rr.com ([76.182.54.123]:60754 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1XZetO-0007Lp-8U; Thu, 02 Oct 2014 11:49:54 +0000 From: "Russ White" To: "'Jeffrey Haas'" , "'Alexander Clemm \(alex\)'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <20140929150110.GD7854@pfrc> In-Reply-To: <20140929150110.GD7854@pfrc> Date: Thu, 2 Oct 2014 07:49:51 -0400 Message-ID: <07d001cfde36$fba839a0$f2f8ace0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHoMTP8chsklMLfoVKSkSiC97qaUgH4M+fGAYZnjisBptWYPwIGj9ikAeIyNrMC47LlKZuMejiA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tRtRaTaen5c29l3tDbSgLhpMaO0 Cc: i2rs@ietf.org, 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" , 'Andy Bierman' Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 11:50:11 -0000 > If objects that are always intended to be ephemeral are never going to > conflict (but may lie on top of) local config, there is never a conflict. > There is simply referential integrity issues if the underlying local config is > deleted and ephemeral config remains. > > If the objects are always disjoint, there is never a conflict. > > But if you permit an ephemeral object to override a local config one within > the schema, we have this issue. Our options would appear to be: A lot of this discussion centers around the concept of a "configuration change" and, more specifically, "static routes." This is actually what I was trying to avoid early on by separating the concept of configuration state from the concept of forwarding state... But, since we are here, one possible point -- If I2RS is treated as, essentially, an alternate "protocol process" running off box, rather than "yet another configuration mechanism," then this problem falls out. There would be no such thing as a "static route installed by I2RS," there would only be routes installed in the local routing table that would be persistent only if the I2RS agent makes certain to reinstall it after any "system event" that causes the route to fall out of the table. Policy within a protocol (though I generally don't like the idea of modifying individual routes at the protocol level) would be treated the same way -- not as a route map or RPL statement "configured" on the device, but as an individual change to an individual route. If an update is received for this route, the local agent must remodify the route, rather than assuming any modifications made would be persistent across updates to that specific reachability information. If this is all true, then there _should be_ no problems with something being configured in two places -- if a single piece of reachability information is installed into the local routing table twice, normal processing rules apply, regardless of the source (generally speaking, the route with the lower admin distance wins, no matter the source). I2RS would never "configure" a "static route," but rather attempt to install a piece of reachability information into the routing table, which then either succeeds or fails, depending on the processing rules involved. The static route configuration isn't touched by I2RS, so there's no issue of "which configuration wins." I hope all that made sense. :-) Russ From nobody Thu Oct 2 07:03:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5981A0389 for ; Thu, 2 Oct 2014 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DB5PxWLDj73R for ; Thu, 2 Oct 2014 07:03:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3D81A034A for ; Thu, 2 Oct 2014 07:03:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 100BAC22C; Thu, 2 Oct 2014 10:03:34 -0400 (EDT) Date: Thu, 2 Oct 2014 10:03:33 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20141002140333.GA27185@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <20140929150110.GD7854@pfrc> <07d001cfde36$fba839a0$f2f8ace0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07d001cfde36$fba839a0$f2f8ace0$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3bAgj8AR7G7u2DU2-HiaUdOUdJg Cc: i2rs@ietf.org, 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" , "'Alexander Clemm \(alex\)'" , 'Andy Bierman' , 'Jeffrey Haas' Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:03:37 -0000 Russ, On Thu, Oct 02, 2014 at 07:49:51AM -0400, Russ White wrote: > A lot of this discussion centers around the concept of a "configuration > change" and, more specifically, "static routes." It's important to be really cautious and not conflate this as being just as simple as "static routes". For cases that look just like a routing protocol, sure. But some of these cases are closer to extending existing configuration state, not injecting new forwarding state. From nobody Thu Oct 2 07:08:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2270B1A036C for ; Thu, 2 Oct 2014 07:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tJYI-xD8CxQ1 for ; Thu, 2 Oct 2014 07:08:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7461A033D for ; Thu, 2 Oct 2014 07:08:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C99C4C22C; Thu, 2 Oct 2014 10:08:23 -0400 (EDT) Date: Thu, 2 Oct 2014 10:08:23 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20141002140823.GB27185@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vhth00qRNbMEEnhvb_rOtz3vOw4 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:08:26 -0000 Andy, On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote: > B) How are the same instances of the same data model related in the > running and ephemeral > datastores? > > I thought "phase 1" was supposed to be simple and the I2RS client would > just inject and remove > RIB data to override the running config. So, answer to (B) is: datastores > have independent > instances. If ephemeral instance exists, it is used. If deleted, then the > instance from the > running config (if any) becomes active. As long as the ephemeral instance > exists, the running config > instance is ignored. I believe this to be the case. Discussion has suggested people aren't quite convinced in all cases. Working through the cases will hopefully push us to agreement. > Is this consistent with the architecture document? > Which solution best fits the agreed upon architecture? The architecture basically says state and user priority and client priority. It's abstract because we were requested to not argue architecture within the context of an underlying modeling language or protocol. Now that we've selected those, we have to figure out what reality we can live with. Much like any software engineering, architecture documents don't fully survive implementation. :-) -- Jeff From nobody Thu Oct 2 07:11:16 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438331A0324 for ; Thu, 2 Oct 2014 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 qrxWvrn0WTL8 for ; Thu, 2 Oct 2014 07:11:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D906C1A033D for ; Thu, 2 Oct 2014 07:11:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A9E2CC22C; Thu, 2 Oct 2014 10:11:13 -0400 (EDT) Date: Thu, 2 Oct 2014 10:11:13 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20141002141113.GC27185@pfrc> References: <542B422D.6000908@joelhalpern.com> <20141001064311.GF36781@elstar.local> <542C1310.7060005@joelhalpern.com> <5BAC61D6-5479-42F0-B7E8-B110444BB607@lucidvision.com> <968A8619-63A7-4B7E-B9D3-CB7B31C2A118@juniper.net> <6875FC82-DADD-49D1-A355-8E4F9CB6799C@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6875FC82-DADD-49D1-A355-8E4F9CB6799C@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/v6Lb-c7tSiaAFJZENFSi-sS54Oc Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Dean Bogdanovic Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 14:11:15 -0000 On Wed, Oct 01, 2014 at 08:40:35AM -0700, Thomas D. Nadeau wrote: > Im going from a netconf/yang model perspective with the assumption that > %100 of a configuration is modeled in yang and operationally available via > netconf (or restconf). If you then think of this configuration as a > configuration set of objects, I like to think about i2rs as a proper > subset of this. Operational reality also shows this to be the case. There > seems to be no good reason to have something you can configure/read from > this set of objects that differs if you use the i2rs "protocol" versus > netconf/restconf. I've intentionally not been prodding at a second half of the "option 4" conversation: What is the impact on netconf protocol operations. Per the interim, a significant portion of the semantics we want simply are addressed by having an ephemeral data store using existing "source" or "target" semantics in netconf. GET operations have some ambiguity and may require extension to allow one to get a given view - merged or not. -- Jeff From nobody Fri Oct 3 04:44:35 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEB31A02F8 for ; Fri, 3 Oct 2014 04:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 JoueRWxrXwSe for ; Fri, 3 Oct 2014 04:44:32 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 608CD1A02F4 for ; Fri, 3 Oct 2014 04:44:32 -0700 (PDT) Received: from cpe-076-182-054-123.nc.res.rr.com ([76.182.54.123]:61400 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Xa1HX-00041P-RF; Fri, 03 Oct 2014 11:44:20 +0000 From: "Russ White" To: "'Jeffrey Haas'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <20140929150110.GD7854@pfrc> <07d001cfde36$fba839a0$f2f8ace0$@riw.us> <20141002140333.GA27185@pfrc> In-Reply-To: <20141002140333.GA27185@pfrc> Date: Fri, 3 Oct 2014 07:44:14 -0400 Message-ID: <022e01cfdeff$5e0f1ff0$1a2d5fd0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHoMTP8chsklMLfoVKSkSiC97qaUgH4M+fGAYZnjisBptWYPwIGj9ikAeIyNrMC47LlKQCjnjL2Ad9LFOSbee7mgA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/c_OvlVSkHE2E8KUQHzoD7Kd65-M Cc: i2rs@ietf.org, "'Alexander Clemm \(alex\)'" , 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" , 'Andy Bierman' Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 11:44:34 -0000 > It's important to be really cautious and not conflate this as being just as > simple as "static routes". For cases that look just like a routing protocol, sure. > But some of these cases are closer to extending existing configuration state, > not injecting new forwarding state. So the case we're aiming for is to be able to change, say, the community string on a BGP route that's sitting in the BGP table, rather than in the RIB... Two things: - I consider this use case unwise. If you want to change the community string (or MED, or Local Pref, or AS Path) on a BGP route, then change the config so the route is impacted through normal processing on the router, rather than touching the route directly through an outside interface. Changing the config so the route is modified moves the problem out of the (strict bounds of the) I2RS space, and into configuration proper, where the operator can see the change in the config, etc. Playing with routes as they sit in the local protocol table without changing the configuration, and hence without telling the protocol what we're doing, is just asking for routing loops and other problems, and doing so from the outside so the operator must look in multiple places to figure out why the problem occurred is just asking for trouble and long MTTRs, IMHO. - If we insist on playing with routes in the local protocol tables, then we need to restrict ourselves to touching _routes_, those individual ephemeral things that change over time, don't persist over a reboot, and aren't configured on the box in any static way. Here, again, just like when interacting with the RIB, we should touch the _route_, not the policy, so the same rules apply as I pointed out in my original email -- if the route is updated, the agent needs to be notified, which then needs to notify the application, which needs to re-apply the policy if needed. Some implementations might allow the agent to be programed to react to route changes, but that's completely out of scope here -- it's a local agent problem. To put it another way -- we're trying to implement a policy from an external box by way of directly touching routing information. We are _not_ trying to influence how the router processes routes. We're _not_ configuring or modifying policy, we're modifying routing information in various tables. Different things entirely. Where we are running into problems is that we didn't start with a clearly defined set of objectives or definitions. "Configuration" means "slow," while "control plane" means "fast" -- a poor definition that's essentially opened every possible configuration semantic up to I2RS control. "Policy" is the community string on a BGP route -- not, it isn't. Policy is what happens to that route because it carries a specific community string or the reason the community string is changed, not the community string itself. We're mixing all these different things up; expecting to have a clear cut solution to a muddy problem. Ain't happenin'. If we back up and think through what it is we're trying to _do_, we can take this whole problem of "when do we write to the configuration" off the table. We're touching _routes_, not policy, no matter which table or database they happen to live in. Routes are _always_ ephemeral, and the policy indicators (those things policies use to do things to a route, or expressions of policy) carried in the route are always ephemeral -- so there shouldn't even be a discussion about writing something to a configuration. There shouldn't be anything "writable" in anything I2RS modifies on the router, plain and simple. If there is, then we've gone out of scope, IMHO. :-) Russ From nobody Fri Oct 3 07:24:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0A21A0049 for ; Fri, 3 Oct 2014 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Fs_VtlZbOZM2 for ; Fri, 3 Oct 2014 07:24:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 250AB1A0004 for ; Fri, 3 Oct 2014 07:24:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9C0B2C4DE; Fri, 3 Oct 2014 10:24:51 -0400 (EDT) Date: Fri, 3 Oct 2014 10:24:51 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20141003142451.GI11252@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <20140929150110.GD7854@pfrc> <07d001cfde36$fba839a0$f2f8ace0$@riw.us> <20141002140333.GA27185@pfrc> <022e01cfdeff$5e0f1ff0$1a2d5fd0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022e01cfdeff$5e0f1ff0$1a2d5fd0$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/p9pa9Ca4eyv1NjILaaAkUbLvwxo Cc: i2rs@ietf.org, 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" , "'Alexander Clemm \(alex\)'" , 'Andy Bierman' , 'Jeffrey Haas' Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 14:24:55 -0000 On Fri, Oct 03, 2014 at 07:44:14AM -0400, Russ White wrote: > So the case we're aiming for is to be able to change, say, the community > string on a BGP route that's sitting in the BGP table, rather than in the > RIB... Two things: And from there you pick an example and play reductio ad absurdum. :-) That's fine, doing that to specific use cases is helpful. However, I think part of the issue is that at the end of the day, this is an *interface* to the routing system. Being able to read state has always been pretty clear. We're spending all of our time debating the *write* semantics. They're tricky when they're crossing boundaries. The use cases where the configuration state we're injecting (configuration in the netconf sense, basically we've done a write operation) and it's completely disjoint from existing local configuration has always been pretty clear. Whether such things like in a unified datastore with local config or in something that requires a completely new protocol to set has never been an issue. Our issues all come when we want to interact with that local config - whether in an augmentation sense or a referential sense. For the moment, let's work through your reductio. > - I consider this use case unwise. If you want to change the community > string (or MED, or Local Pref, or AS Path) on a BGP route, then change the > config so the route is impacted through normal processing on the router, > rather than touching the route directly through an outside interface. We already have BGP attributes getting "config" via other mechanisms. AIGP metric and the bandwidth extended communities are examples of these. We've previously talked about influencing of routing via programmatic changes to the cost community. > Changing the config so the route is modified moves the problem out of the > (strict bounds of the) I2RS space, and into configuration proper, where the > operator can see the change in the config, etc. Playing with routes as they > sit in the local protocol table without changing the configuration, and > hence without telling the protocol what we're doing, I don't recall any cases where we're saying "go forth and meddle with things in a way that the underlying system isn't aware of". Matter of fact, for the IGP cases, we've explicitly put interference with the underlying LSAs as out of bounds because the protocols wouldn't deal with it. If you think we're specifically chartered to meddle with state in ways that don't make sense, I think you've gotten a bit lost. Not to mention I can't see someone supporting a model that has such impact. > - If we insist on playing with routes in the local protocol tables, then we > need to restrict ourselves to touching _routes_, those individual ephemeral > things that change over time, don't persist over a reboot, and aren't > configured on the box in any static way. Here, again, just like when > interacting with the RIB, we should touch the _route_, not the policy, Policy is dynamically changed in lots of ways. Again, it has to make sense in the system. As a random example, JUNOS has had ephemeral policy configuration for years. > To put it another way -- we're trying to implement a policy from an external > box by way of directly touching routing information. We are _not_ trying to > influence how the router processes routes. We're _not_ configuring or > modifying policy, we're modifying routing information in various tables. Policy is a table depending on one's perspective. > Where we are running into problems is that we didn't start with a clearly > defined set of objectives or definitions. "Configuration" means "slow," > while "control plane" means "fast" -- a poor definition that's essentially > opened every possible configuration semantic up to I2RS control. "Policy" is > the community string on a BGP route -- not, it isn't. Policy is what happens > to that route because it carries a specific community string or the reason > the community string is changed, not the community string itself. We're > mixing all these different things up; expecting to have a clear cut solution > to a muddy problem. Ain't happenin'. I want a way to be able to write "state" into boxes that influences behaviors based on configuration models. Those models define what one is trying to do. People want to do lots of things. And it's not so much "I". I already work on a platform that has a defined protocol and currently one language that lets me do this sort of thing. Customers want more broadly supported versions of such a thing and better models to get at and influence the device. > If we back up and think through what it is we're trying to _do_, we can take > this whole problem of "when do we write to the configuration" off the table. > We're touching _routes_, not policy, Perhaps you are. Go forth with the knowledge that others want to do different things. - Jeff From nobody Fri Oct 3 11:57:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B321A1AD8 for ; Fri, 3 Oct 2014 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] autolearn=ham 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 021zAkFeO3wX for ; Fri, 3 Oct 2014 11:57:10 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 270E71A1A62 for ; Fri, 3 Oct 2014 11:57:09 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:62189 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Xa82K-0000lR-Q5; Fri, 03 Oct 2014 18:57:05 +0000 From: "Russ White" To: "'Jeffrey Haas'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <20140929150110.GD7854@pfrc> <07d001cfde36$fba839a0$f2f8ace0$@riw.us> <20141002140333.GA27185@pfrc> <022e01cfdeff$5e0f1ff0$1a2d5fd0$@riw.us> <20141003142451.GI11252@pfrc> In-Reply-To: <20141003142451.GI11252@pfrc> Date: Fri, 3 Oct 2014 14:57:02 -0400 Message-ID: <016a01cfdf3b$d2b167a0$781436e0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHoMTP8chsklMLfoVKSkSiC97qaUgH4M+fGAYZnjisBptWYPwIGj9ikAeIyNrMC47LlKQCjnjL2Ad9LFOQCP98aIgIf4a/Sm1dqlcA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wQfRIT3832IEvPJYCBjm8TySxr8 Cc: i2rs@ietf.org, "'Alexander Clemm \(alex\)'" , 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" , 'Andy Bierman' Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 18:57:11 -0000 > Policy is dynamically changed in lots of ways. Again, it has to make sense in > the system. What we need to do is separate policy from policy instruments... A community string, metric, etc., is _not_ a policy, it's a "policy instrument." In other words, an I2RS policy can change a community, but the reason you set the community is a policy, not the community. So what we are saying is two different things: 1. Find routes with a destination of 10.1.1.0/24; add community 1 to them. Do this this one time to route currently in the table. 2. For any route with a destination of 10.1.1.0/24, add community 1 to them starting now, and lasing until I tell you to do otherwise. The difference is subtle, but important. The first can take the semantic -- "set community 1 on routes matching 10.1.1.0/24." The second must take the semantic, "install a policy that examines inbound routes and sets community 1 on them if they match 10.1.1.0/24." If we're trying to do the second, we're trying to do the wrong thing. We shouldn't be programming policy into the box -- that's what netconf is for. We should be trying adjust individual routes based on a policy that's opaque to the box -- the routing process on box only sees the result of the policy, not the policy itself. > And it's not so much "I". I already work on a platform that has a defined > protocol and currently one language that lets me do this sort of thing. > Customers want more broadly supported versions of such a thing and better > models to get at and influence the device. So in JUNOS, you have the ability to instruct BGP to install a route map or RPL statement to change inbound routes, or to set a filter on inbound routes in addition to existing CLI configured filters, that the user can only see by examining the scripts running on the box as well as the actual CLI configured filters? I don't actually think you do... You probably have a set of instructions that configure something so new filters and policies show up in the CLI, and another set of options that will let you change actual routes, but I don't think you have a set of options that allow you to put in what is essentially an RPL statement without actually having that RPL statement show up in the configuration, or modify the inbound filter of BGP without modifying the configuration the user sees through other interfaces. Again, the difference is subtle, but important. If I2RS' goal is to replace RPL configurations in the CLU, then we've already stepped outside the bounds of the routing system, and into the bounds of netconf and the configuration/network management systems. > > If we back up and think through what it is we're trying to _do_, we > > can take this whole problem of "when do we write to the configuration" off > the table. > > We're touching _routes_, not policy, > > Perhaps you are. Go forth with the knowledge that others want to do > different things. Sorry, Jeff, but I don't think the WG actually knows what it wants to do -- we don't have a carefully articulated well defined set of goals or definitions. As I read the use cases, I don't see _any_ use case that says, "I want to set an RPL based filter that changes every route received by the process, or acts as a nonconfigured filter on the box." What I see is, "I need to inject this route here, remove that route there, or modify that route over there." Completely different things. We need to know what "policy" means, and we need to know what a "route" means. We need to be able to state clearly and easily where I2RS ends, and where NETCONF begins. It's not that configuring policy is a "bad thing," it's that we need to scope the work to a reasonable set of actual work items, especially when there are other WG's working in the same space. Otherwise, we're just trying to boil the ocean -- a sure recipe for failure. To bring this back to the beginning -- we can play with how to build, store, etc., the YANG models all day long -- but unless we put some definitions around what I2RS is _not_ doing, we're never going to be able to make progress. :-) Russ From nobody Fri Oct 3 13:40:31 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401C81A7012 for ; Fri, 3 Oct 2014 13:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 f7uNJWZ5NScG for ; Fri, 3 Oct 2014 13:40:27 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369AC1A1F04 for ; Fri, 3 Oct 2014 13:40:27 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so634066yha.32 for ; Fri, 03 Oct 2014 13:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p+/gIcRm9xx7QaAAL2IuZOVF21Sl7lBSwUt/qqjQ5OU=; b=kWt2v4AdKZL0dEEeBl+eFNBSfaJgZ7r/2ONJSxRV9eGe0l7uDccjw2OYVLUEgwsrU0 9siLpENaj3IH4usbR21OJDNkamD2d21jViyAEMA8LJIBNnz7PbGm33cA1uAxoTm89W9a VtjbNvpHlx3FwBVn2WIJnJBBZCy4lIbetS8SDlhJPOPq4nVzoQBbeo27QgF3O8ypFYch xOEBlTY5BGkRLhrxrIo/taF0CszUsDAW1sXokD9brxjBH5c80dRCiJksJxWrBnIRb+Tx Q/Y1EMYto5YWQll5MZdwrVqlAeCJXK+D+EU/uFDfkGZTOLbU6NzG/oHFPH8smcLBiYTW oHew== MIME-Version: 1.0 X-Received: by 10.236.150.19 with SMTP id y19mr11089094yhj.94.1412368826332; Fri, 03 Oct 2014 13:40:26 -0700 (PDT) Received: by 10.170.113.134 with HTTP; Fri, 3 Oct 2014 13:40:26 -0700 (PDT) In-Reply-To: <5CC8BAFD-768D-4B5D-B96D-F588ED558E85@juniper.net> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> <5CC8BAFD-768D-4B5D-B96D-F588ED558E85@juniper.net> Date: Fri, 3 Oct 2014 16:40:26 -0400 Message-ID: From: Alia Atlas To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=20cf303a2dbb2f7b4905048abe4c Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Puq8zTCl-w8yMy5aVfnCt50LWGE Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:40:30 -0000 --20cf303a2dbb2f7b4905048abe4c Content-Type: text/plain; charset=UTF-8 Hi Dean, Sorry for the delay in responding. Telechats do that to one. On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic wrote: > > On Oct 1, 2014, at 9:54 AM, Alia Atlas > wrote: > > Hi Dean, > > Thanks for the explanation. It matches with what I understand for > configuration. > Where I am confused is why I2RS - which is doing ephemeral only and > matches closer to the direct proprietary APIs directly to > the routing processes - is being tied up in this. > > > Today there is no standard protocol to expose writing to the daemons > directly, except through a datastore. If you would compare routing daemon > in Junos and routing daemon in IOS or NX-OS, the data models are very > different. You need a standard API to communicate to all of them. > Right - but that's what I2RS is asking and trying to do. I'm sure I didn't just hear you say that we can't do it because it doesn't exist yet. > Here is a reason why a local datastore comes handy > > routing daemon crashes and the state is gone. The routing state has to > be reinstated. > > 1. replay config data from the local data store(s) and reactivate the > configuration > 2. replay config data from the local data store (single data store) and > request all I2RS clients to replay their data again > > Now if some I2RS client, during the crash, tried to execute routing > changes, with local store, those can be executed and put into wait state > until daemon recovers. I2RS clients can be informed that their changes are > pending. > I do understand that a datastore is useful for config. For I2RS, if the relevant routing crashes, then the I2RS clients are just notified that their state is gone. If an I2RS client tries to request a change and the routing daemon isn't up, then the change fails! This is part of being in a dynamic and distributed system. > Both approaches have pluses and minuses. > > Another issue is with config statements. If you go directly to the > daemons, only few very basic things can be exposed (like interfaces, > routes, stateless fw filters). If you want to expose more complex > statements like L3VPN, then you have to create a logic that will > communicate to multiple daemons to create such state on the device. You are > doubling such logic on the device. > Right - but here I have to pull our attention back to the charter. We can do: RIB, topology (read only), BGP, DDOS mitigation, hub-and-spoke routing improvement, and traffic exit point optimization. If there are proprietary mechanism for everything else, that's ok. Let's get this designed correctly - given the WG agreement on the architecture and the charter constraints on the use-cases. I want to allow network administrators to decide by them self what is > exposed through I2RS, not us (vendors, SDOs). > Then we boil the ocean, claim everything is safe, try and solve all the hard problems instead of taking reasonable efforts with the simple parts first. Let's get something done that can be implemented. Regards, Alia > > Dean > > > Regards, > Alia > > On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic wrote: > >> Hi Alia, >> >> today networking devices can be managed in three ways: >> >> 1. CLI - is the UI we all know and use it quite heavily. In order for the >> device to boot in a known state a set of CLI commands have to be saved >> somewhere on the device. For that you have a data store. That data store >> can be a flat file or a database. The datastore is then read by network >> device daemons which change their state based on it. >> >> Before the APIs were exposed, TCL/Expect and Perl ruled the automation >> world and everything was based on screen scraping. In order to make machine >> to machine communication easier, NETCONF was created as a standard protocol >> to communicate with the devices. >> >> 2. via APIs - there are several type of APIs, but most widely available >> ones are providing functionalities same as CLI. The difference is that CLI >> is human intended and APIs are machine intended. One of the example is >> Junos XML APIs, where (almost) each CLI command is represented by XML API. >> It still requires knowing how to configure device via CLI and the result of >> the application written with such APIs is stored in the data store from >> which daemon read how to change their state. >> There are some vendors that provide APIs that allow communication with >> daemons directly, bypassing management infrastructure, but those are highly >> proprietary mechanisms. >> The APIs that were released by vendors, were not standardized and each >> vendor had different configuration models, so although communication with >> devices was standardized, there was no easy way to communicate semantics, >> which led to YANG, as standard language that all vendors would understand >> and now standardizing configuration and operational model, so same >> configuration statement can be sent to all supporting devices and be done >> (instead of writing same desired functionality in several configuration >> statements) >> >> At the end it really doesn't matter how you are communicating with the >> devices, it really boils down to that you want the device to boot into a >> known state. This was done by having a local data store that was containing >> set of instructions what state the device should be after reading it. >> >> It really doesn't matter which mechanism is used (from above 2), >> configuration data has to be provided. Historically, data was on the >> device, as the connection between device and the network management was >> slow. Today (like in MSDC), devices don't have local configuration, those >> devices when boot look for provisioning system and get configuration from a >> remote location and then change the state of the device based on it. This >> has led that >> >> 3. some vendors use Linux, allow management via pseudo file system (/proc) >> >> where the state of the device is changed directly without having a need >> for data store on the device. You have to keep in mind that only Linux >> allows changing the state of non-processes data through /proc. *BSD flavors >> don't allow that. >> >> So today, most network operators (by this I mean any entity that operates >> a network, either enterprise or carrier), need to simplify network >> management, make it more efficient and that devices will behave very >> predictably, so that network is in a known state. Because of the legacy, >> this is easiest done by having a local datastore on a device, through which >> the state of the device is changed. >> >> Hope this helps >> >> Dean >> >> >> On Oct 1, 2014, at 12:25 AM, Alia Atlas wrote: >> >> > Hi, >> > >> > I'd like to really understand why I2RS needs a datastore and what that >> actually means. >> > In my initial conception of what an I2RS agent would do for, say, >> writing a route in the RIB >> > model, is that the I2RS agent would simply parse a received request >> from a standard format >> > and model into the internal and pass that to a RIB Manager - just as an >> OSPF implementation >> > might install a route to the RIB manager. An I2RS agent could also >> query the RIB Manager to >> > read routes and there'd be events coming out. >> > >> > With the introduction of priorities to handle multi-headed writers and >> collision errors, the I2RS agent would need to store what was written by >> which client. >> > >> > What benefits and rationale does a YANG datastore add? Why does using >> one need to be >> > standardized? >> > >> > I apologize if this seems a naive question, but it's been quite a while >> since I read up on YANG and NetConf/RestConf. >> > >> > Regards, >> > no-hats Alia >> > >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> > > --20cf303a2dbb2f7b4905048abe4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dean,

Sorry for the delay in respond= ing.=C2=A0 Telechats do that to one.

On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic <= span dir=3D"ltr"><deanb@juniper.net> wrote:

On Oct 1, 2014, at 9:54 AM, Alia Atlas <akatlas@gmail.com>
=C2=A0wrote:

Hi Dean,

Thanks for the explanation.=C2=A0 It matches with what I understand fo= r configuration.
Where I am confused is why I2RS - which is doing ephemeral only and ma= tches closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

 Today there is no standard protocol to expose writing to the daemons direct= ly, except through a datastore. If you would compare routing daemon in Juno= s and routing daemon in IOS or NX-OS, the data models are very different. Y= ou need a standard API to communicate to all of them.=C2=A0

Right - = but that's what I2RS is asking and trying to do.=C2=A0 I'm sure I d= idn't just hear you say that we can't do it because it doesn't = exist yet.=C2=A0
=C2=A0
Here is a reason why a local datastore comes handy

routing daemon crashes and the state is gone. The routing state has to= be reinstated.=C2=A0

1. replay config data from the local data store(s) and reactivate the = configuration
2. replay config data from the local data store (single data store) an= d request all I2RS clients to replay their data again

Now if some I2RS client, during the crash, tried to execute routing ch= anges, with local store, those can be executed and put into wait state unti= l daemon recovers. I2RS clients can be informed that their changes are pend= ing.

I do understand that a dat= astore is useful for config.=C2=A0 For I2RS, if the relevant routing crashe= s, then the I2RS clients are just notified that their state is gone.=C2=A0 = If an I2RS client tries to request a change and the routing daemon isn'= t up, then the change fails!=C2=A0 This is part =C2=A0of being in a dynamic= and distributed system.
=C2=A0
Both approaches have pluses and minuses.=C2=A0

Another issue is =C2=A0with config statements. If you go directly to t= he daemons, only few very basic things can be exposed (like interfaces, rou= tes, stateless fw filters). If you want to expose more complex statements l= ike L3VPN, then you have to create a logic that will communicate to multiple daemons to create such state on th= e device. You are doubling such logic on the device.

Right - but here I have to pull our attention back to= the charter.=C2=A0 We can do:
=C2=A0 =C2=A0RIB, topology (read o= nly), BGP, DDOS mitigation, hub-and-spoke routing improvement, and traffic = exit point optimization.

If there are proprietary = mechanism for everything else, that's ok.=C2=A0 Let's get this desi= gned correctly - given the WG agreement on the architecture and the charter= constraints on the use-cases.=C2=A0

I want to allow network administrators to decide by them self what is = exposed through I2RS, not us (vendors, SDOs).
=
Then we boil the ocean, claim everything is safe, try and so= lve all the hard problems instead of taking reasonable efforts with the sim= ple parts first.

Let's get something done that= can be implemented.

Regards,
Alia
=
=C2=A0

Dean


Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic = <deanb@juniper.ne= t> wrote:
Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device daemons which change their state based on i= t.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It still requires knowing how to config= ure device via CLI and the result of the application written with such APIs= is stored in the data store from which daemon read how to change their sta= te.
There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms.
The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now standardizing configuration and = operational model, so same configuration statement can be sent to all suppo= rting devices and be done (instead of writing same desired functionality in= several configuration statements)

At the end it really doesn't matter how you are communicating with the = devices, it really boils down to that you want the device to boot into a kn= own state. This was done by having a local data store that was containing s= et of instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), config= uration data has to be provided. Historically, data was on the device, as t= he connection between device and the network management was slow. Today (li= ke in MSDC), devices don't have local configuration, those devices when boot look for provisioning system and ge= t configuration from a remote location and then change the state of the dev= ice based on it. This has led that

3. some vendors use Linux, allow management via pseudo file system (/proc)<= br>
where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don= 9;t allow that.

So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest done by having a local datastore on= a device, through which the state of the device is changed.

Hope this helps

Dean


On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com> wrote:

> Hi,
>
> I'd like to really understand why I2RS needs a datastore and what = that actually means.
> In my initial conception of what an I2RS agent would do for, say, writ= ing a route in the RIB
> model, is that=C2=A0 the I2RS agent would simply parse a received requ= est from a standard format
> and model into the internal and pass that to a RIB Manager - just as a= n OSPF implementation
> might install a route to the RIB manager.=C2=A0 An I2RS agent could al= so query the RIB Manager to
> read routes and there'd be events coming out.
>
> With the introduction of priorities to handle multi-headed writers and= collision errors, the I2RS agent would need to store what was written by w= hich client.
>
> What benefits and rationale does a YANG datastore add?=C2=A0 Why does = using one need to be
> standardized?
>
> I apologize if this seems a naive question, but it's been quite a = while since I read up on YANG and NetConf/RestConf.
>
> Regards,
> no-hats=C2=A0 Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs




--20cf303a2dbb2f7b4905048abe4c-- From nobody Fri Oct 3 14:19:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C11A871A for ; Fri, 3 Oct 2014 14:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 ag1tGtHaP_B5 for ; Fri, 3 Oct 2014 14:19:39 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8FE1A8745 for ; Fri, 3 Oct 2014 14:19:01 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 10so652615ykt.0 for ; Fri, 03 Oct 2014 14:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M+jMuSibcDhm+xlT4ZqIC+U87PAeZi8WKZBDvggRdb8=; b=SOzxpaDQ5OGxDvNlJYzzMOSuryoodDqbE91eodLL3oGqg820zKyNGFyXs4xswd54Wh nfyIli5/cLjFsxQ/ZhAEuJimyqQL7+rzrfSF6CVlqMoj1NHsrvBuuaQW4HsWzG6GeKAI yByQHS2vF6si7pYrlDaME/+21/v5ljMcAzb8wiVZnKZWaNcwyzzp1Evn6sTzrDdcBF9E akWcZ+pguUPmnjIPiuqqUMMUKwkWv6tNxf5eNOE2QqWLEAF/YY6Pl4E1nTojjSILuddo T/aljRCpSqog16xv3hwFV5HlB5se3/CoP7ggEbs3oVQjSBE4hcPOd/30z91jGqaK0bKl dfaw== MIME-Version: 1.0 X-Received: by 10.236.131.134 with SMTP id m6mr11408780yhi.3.1412371139869; Fri, 03 Oct 2014 14:18:59 -0700 (PDT) Received: by 10.170.113.134 with HTTP; Fri, 3 Oct 2014 14:18:59 -0700 (PDT) In-Reply-To: <20141001141350.GC22743@pfrc> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> <20141001141350.GC22743@pfrc> Date: Fri, 3 Oct 2014 17:18:59 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: multipart/alternative; boundary=20cf300e507115432205048b4892 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/74D_-gk6woJ3qtx-YVfGDJFkunY Cc: "i2rs@ietf.org" , Dean Bogdanovic Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:19:41 -0000 --20cf300e507115432205048b4892 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 10:13 AM, Jeffrey Haas wrote: > On Wed, Oct 01, 2014 at 09:54:12AM -0400, Alia Atlas wrote: > > Thanks for the explanation. It matches with what I understand for > > configuration. > > Where I am confused is why I2RS - which is doing ephemeral only and > matches > > closer to the direct proprietary APIs directly to > > the routing processes - is being tied up in this. > > The annoying fact is that we have to reconcile what we want to do with the > semantics of existing netconf/yang. > We do? I agree that NetConf/RestConf/YANG are the bases that the WG wants to use to build I2RS. I don't think that anyone has the idea that they match perfectly or wouldn't need modification for this use. > The property of being able to override some bit of local config with > ephemeral config implies at least another data store in those semantics. > Otherwise you'd have to redefine the existing semantic as "a given writer > may SET a value of a higher visibility priorty and it's allowed to go away > and reveal the original value of lower visibility priority". > We had that semantic initially (I forget which draft) - and there was serious WG pushback that it was too complicated. I think that a LOT of this simplifies if you make one of two assumptions. Either the CLI/NetConf-for-config overrides I2RS or I2RS overrides the CLI/NetConf-for-config. If I2RS is lower priority than CLI/NetConf, then when config comes in, any I2RS state is preempted and the appropriate I2RS client is notified. If I2RS overrides, then when I2RS state comes in, the associated CLI state is deleted. I grant that the latter case is more complicated - and I'd be really surprised to see implementations that were comfortable going there yet. Regards, Alia This makes sense as a merge/patch operation, but less so with a single > object store. > > -- Jeff > --20cf300e507115432205048b4892 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 1, 2014 at 10:13 AM, Jeffrey Haas <jhaas@pfrc.org> wrot= e:
On Wed, Oct 01, 2014 = at 09:54:12AM -0400, Alia Atlas wrote:
> Thanks for the explanation.=C2=A0 It matches with what I understand fo= r
> configuration.
> Where I am confused is why I2RS - which is doing ephemeral only and ma= tches
> closer to the direct proprietary APIs directly to
> the routing processes - is being tied up in this.

The annoying fact is that we have to reconcile what we want to do wi= th the
semantics of existing netconf/yang.

We = do?=C2=A0 I agree that NetConf/RestConf/YANG are the bases that the WG want= s to use
to build I2RS.=C2=A0 I don't think that anyone has t= he idea that they match perfectly or
wouldn't need modificati= on for this use.
=C2=A0
The property of being able to override some bit of local config with
ephemeral config implies at least another data store in those semantics. Otherwise you'd have to redefine the existing semantic as "a given= writer
may SET a value of a higher visibility priorty and it's allowed to go a= way
and reveal the original value of lower visibility priority".

We had that semantic initially (I forget which d= raft) - and there was serious WG
pushback that it was too complic= ated.

I think that a LOT of this simplifies if you= make one of two assumptions.=C2=A0 Either
the CLI/NetConf-for-co= nfig overrides I2RS or I2RS overrides the CLI/NetConf-for-config.

If I2RS is lower priority than CLI/NetConf, then when confi= g comes in, any I2RS
state is preempted and the appropriate I2RS = client is notified.=C2=A0 If I2RS overrides,
then when I2RS state= comes in, the associated CLI state is deleted.=C2=A0 I grant that
the latter case is more complicated - and I'd be really surprised to = see implementations
that were comfortable going there yet.
<= div>=C2=A0
Regards,
Alia

This makes sense as a merge/patch operation, but less so with a single
object store.

-- Jeff

--20cf300e507115432205048b4892-- From nobody Fri Oct 3 14:23:02 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCB1A8919 for ; Fri, 3 Oct 2014 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 lX0VdB9ILYlE for ; Fri, 3 Oct 2014 14:22:55 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A101A8916 for ; Fri, 3 Oct 2014 14:22:54 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id a1so2523641wgh.9 for ; Fri, 03 Oct 2014 14:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hZEckkFwLlE1eZjgB1P3uSNlKH/5RlMCGIuOM6+soBU=; b=y2NpkFBIUc4zC+h7khG/luVYIOQ+tsZIla+yqmJYczF0j5IrpyGkCLl7oGEPUgqmPs RzymsaZLl94ldDizCUUo3elt1Lcey3fM9MQKg3xUBovvQ91LqlwAowkqAwj72LiaoaE7 Pa+MYjJTgEupq0U7xVZBAOOvUGi8Q0ev/PihRekfRtcwGy0Flu5rbg253Fc0nlANAOYi m7HEkulbaNdfE7PzH0sN11dQdOaKdrQVK0DL5QqrQE9zb3h07tSkQhLeVbSTFelUGSoY A0Rx8XqSGEoM60Z1/WWY5eubvTuh4AfkLgggmqOZQnO1kAySnN9Ym7e6jYH7YVYqLqi6 kyFw== MIME-Version: 1.0 X-Received: by 10.194.184.111 with SMTP id et15mr10905904wjc.14.1412371370706; Fri, 03 Oct 2014 14:22:50 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Fri, 3 Oct 2014 14:22:50 -0700 (PDT) In-Reply-To: <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> Date: Fri, 3 Oct 2014 17:22:50 -0400 Message-ID: From: Alia Atlas To: Igor Bryskin Content-Type: multipart/alternative; boundary=047d7ba97e9ad78bdc05048b559f Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_9QCZ4COl60QZFM9f11C837lCGA Cc: "i2rs@ietf.org" , Dean Bogdanovic Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:22:59 -0000 --047d7ba97e9ad78bdc05048b559f Content-Type: text/plain; charset=UTF-8 Hi Igor, On Wed, Oct 1, 2014 at 1:31 PM, Igor Bryskin wrote: > Alia, > > Your question makes sense if I2RS is limited to routing data manipulation. > In this case it could be thought of as an additional routing > protocol.After all OSPF does not need any data store to install its routes, > Exactly - and that is what I2RS is chartered to do. > What if I2RS client want to configure other things? > I'd like to see us crawl and get the basics right instead of trying to do everything. Different mechanisms may apply and be relevant. Regards, Alia Igor > ________________________________________ > From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas [ > akatlas@gmail.com] > Sent: Wednesday, October 1, 2014 9:54 AM > To: Dean Bogdanovic > Cc: i2rs@ietf.org > Subject: Re: [i2rs] Why do we need a datastore? > > Hi Dean, > > Thanks for the explanation. It matches with what I understand for > configuration. > Where I am confused is why I2RS - which is doing ephemeral only and > matches closer to the direct proprietary APIs directly to > the routing processes - is being tied up in this. > > Regards, > Alia > > On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic deanb@juniper.net>> wrote: > Hi Alia, > > today networking devices can be managed in three ways: > > 1. CLI - is the UI we all know and use it quite heavily. In order for the > device to boot in a known state a set of CLI commands have to be saved > somewhere on the device. For that you have a data store. That data store > can be a flat file or a database. The datastore is then read by network > device daemons which change their state based on it. > > Before the APIs were exposed, TCL/Expect and Perl ruled the automation > world and everything was based on screen scraping. In order to make machine > to machine communication easier, NETCONF was created as a standard protocol > to communicate with the devices. > > 2. via APIs - there are several type of APIs, but most widely available > ones are providing functionalities same as CLI. The difference is that CLI > is human intended and APIs are machine intended. One of the example is > Junos XML APIs, where (almost) each CLI command is represented by XML API. > It still requires knowing how to configure device via CLI and the result of > the application written with such APIs is stored in the data store from > which daemon read how to change their state. > There are some vendors that provide APIs that allow communication with > daemons directly, bypassing management infrastructure, but those are highly > proprietary mechanisms. > The APIs that were released by vendors, were not standardized and each > vendor had different configuration models, so although communication with > devices was standardized, there was no easy way to communicate semantics, > which led to YANG, as standard language that all vendors would understand > and now standardizing configuration and operational model, so same > configuration statement can be sent to all supporting devices and be done > (instead of writing same desired functionality in several configuration > statements) > > At the end it really doesn't matter how you are communicating with the > devices, it really boils down to that you want the device to boot into a > known state. This was done by having a local data store that was containing > set of instructions what state the device should be after reading it. > > It really doesn't matter which mechanism is used (from above 2), > configuration data has to be provided. Historically, data was on the > device, as the connection between device and the network management was > slow. Today (like in MSDC), devices don't have local configuration, those > devices when boot look for provisioning system and get configuration from a > remote location and then change the state of the device based on it. This > has led that > > 3. some vendors use Linux, allow management via pseudo file system (/proc) > > where the state of the device is changed directly without having a need > for data store on the device. You have to keep in mind that only Linux > allows changing the state of non-processes data through /proc. *BSD flavors > don't allow that. > > So today, most network operators (by this I mean any entity that operates > a network, either enterprise or carrier), need to simplify network > management, make it more efficient and that devices will behave very > predictably, so that network is in a known state. Because of the legacy, > this is easiest done by having a local datastore on a device, through which > the state of the device is changed. > > Hope this helps > > Dean > > > On Oct 1, 2014, at 12:25 AM, Alia Atlas akatlas@gmail.com>> wrote: > > > Hi, > > > > I'd like to really understand why I2RS needs a datastore and what that > actually means. > > In my initial conception of what an I2RS agent would do for, say, > writing a route in the RIB > > model, is that the I2RS agent would simply parse a received request > from a standard format > > and model into the internal and pass that to a RIB Manager - just as an > OSPF implementation > > might install a route to the RIB manager. An I2RS agent could also > query the RIB Manager to > > read routes and there'd be events coming out. > > > > With the introduction of priorities to handle multi-headed writers and > collision errors, the I2RS agent would need to store what was written by > which client. > > > > What benefits and rationale does a YANG datastore add? Why does using > one need to be > > standardized? > > > > I apologize if this seems a naive question, but it's been quite a while > since I read up on YANG and NetConf/RestConf. > > > > Regards, > > no-hats Alia > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > --047d7ba97e9ad78bdc05048b559f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Igor,

On Wed, Oct 1, 2014 at 1:31 PM, Igor Bryskin <= IBryskin@adva= optical.com> wrote:
Alia,
Your question makes sense if I2RS is limited to routing data manipulation.<= br> In this case it could be thought of as an additional routing protocol.After= all OSPF does not need any data store to install its routes,

Exactly - and that is what I2RS is chartered to do.<= /div>
=C2=A0
What if I2RS client want to configure other things?
I'd like to see us crawl and get the basics right instead = of trying to do everything.
Different mechanisms may apply and be= relevant.

Regards,
Alia

<= /div>
Igor
________________________________________
From: i2rs [i2rs-bounces@ietf.org<= /a>] on behalf of Alia Atlas [akatlas@= gmail.com]
Sent: Wednesday, October 1, 2014 9:54 AM
To: Dean Bogdanovic
Cc: i2rs@ietf.org
Subject: Re: [i2rs] Why do we need a datastore?

Hi Dean,

Thanks for the explanation.=C2=A0 It matches with what I understand for con= figuration.
Where I am confused is why I2RS - which is doing ephemeral only and matches= closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <= ;deanb@juniper.net<mailto:deanb@juniper.net>> wrote:
Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state.
There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms.
The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements)

At the end it really doesn't matter how you are communicating with the = devices, it really boils down to that you want the device to boot into a kn= own state. This was done by having a local data store that was containing s= et of instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), config= uration data has to be provided. Historically, data was on the device, as t= he connection between device and the network management was slow. Today (li= ke in MSDC), devices don't have local configuration, those devices when= boot look for provisioning system and get configuration from a remote loca= tion and then change the state of the device based on it. This has led that=

3. some vendors use Linux, allow management via pseudo file system (/proc)<= br>
where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don= 9;t allow that.

So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed.

Hope this helps

Dean


On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> wrote:

> Hi,
>
> I'd like to really understand why I2RS needs a datastore and what = that actually means.
> In my initial conception of what an I2RS agent would do for, say, writ= ing a route in the RIB
> model, is that=C2=A0 the I2RS agent would simply parse a received requ= est from a standard format
> and model into the internal and pass that to a RIB Manager - just as a= n OSPF implementation
> might install a route to the RIB manager.=C2=A0 An I2RS agent could al= so query the RIB Manager to
> read routes and there'd be events coming out.
>
> With the introduction of priorities to handle multi-headed writers and= collision errors, the I2RS agent would need to store what was written by w= hich client.
>
> What benefits and rationale does a YANG datastore add?=C2=A0 Why does = using one need to be
> standardized?
>
> I apologize if this seems a naive question, but it's been quite a = while since I read up on YANG and NetConf/RestConf.
>
> Regards,
> no-hats=C2=A0 Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org<mailto:i2rs@ietf.org>
> https://www.ietf.org/mailman/listinfo/i2rs



--047d7ba97e9ad78bdc05048b559f-- From nobody Fri Oct 3 14:31:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0331A6FD5 for ; Fri, 3 Oct 2014 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 Z1MwQbgorI_c for ; Fri, 3 Oct 2014 14:31:36 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A641A86E7 for ; Fri, 3 Oct 2014 14:31:35 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id k14so1210419wgh.7 for ; Fri, 03 Oct 2014 14:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4SGTCFvWeZC8QGJ/aoCdjg1zWYFPLWzz7zDmd8GhaRQ=; b=la0qZ9irxTxcgbJ3yBzbnkdHYwUnq7apJ9jKTNRt3y6sCaTQiEVnjz2XL++3mVQdKk e5IBdz2qHRlyoaOkPfVO+lfzdmcvXuNkc+lpLLxKA1g49cmfhLSOM/bABWLsVmJDoU/5 w9lGikXi+PDeTdEU+LfiTyUjbfEK2J/TSdOvBp8Lirp5ybJlUS+qXTBGHFSfVEF6uMyx aHrMSNbQas9yBalDmYt209cPcuEs9wbP7YJeRmwxbjNK/cfW3ZjKN1ju/yFYTGa50i4s jHRb3OFRLuuTxkEcyPE+8+ZiW5/HxSJTdCZ01QMTq2RmFxbpeCTXXI1sT+8DNgQmLEYz flFQ== MIME-Version: 1.0 X-Received: by 10.180.188.102 with SMTP id fz6mr1022395wic.83.1412371894361; Fri, 03 Oct 2014 14:31:34 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Fri, 3 Oct 2014 14:31:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Oct 2014 17:31:34 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11c37b9a0de43305048b75ba Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gsIYcT3NodWvEpD2RbQjQhPU7R0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:31:38 -0000 --001a11c37b9a0de43305048b75ba Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 2:15 PM, Andy Bierman wrote: > > > On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas wrote: > >> Hi, >> >> I'd like to really understand why I2RS needs a datastore and what that >> actually means. >> In my initial conception of what an I2RS agent would do for, say, writing >> a route in the RIB >> model, is that the I2RS agent would simply parse a received request from >> a standard format >> and model into the internal and pass that to a RIB Manager - just as an >> OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also query >> the RIB Manager to >> read routes and there'd be events coming out. >> >> With the introduction of priorities to handle multi-headed writers and >> collision errors, the I2RS agent would need to store what was written by >> which client. >> >> What benefits and rationale does a YANG datastore add? Why does using >> one need to be >> standardized? >> >> I apologize if this seems a naive question, but it's been quite a while >> since I read up on YANG and NetConf/RestConf. >> >> > It is a great question because the datastore is used for 3 reasons in > NETCONF/YANG. > > 1) conceptual container for top-level YANG data nodes > 1a) source parameter for retrieval; target parameter for editing > Since I2RS is based on single operations - sort of like what I understand is the case for RestConf - I don't see this applying to I2RS. Am I missing something? > 2) conceptual container for YANG validation rules for the running > datastore > Again, I don't think that I2RS really is doing YANG validation. I guess this is a detail that isn't really discussed in the architecture, but my assumptions have been that it would negatively impact the desired speed and throughput of operations in I2RS. > 3) conceptual container for access control model > And as you say below, this is different for I2RS. So again - why does I2RS need a datastore? > > I don't agree that multiple ephemeral datastores are needed. Support for > multiple clients > within 1 datastore is needed. > > YANG validation rules for the ephemeral datastore are not interesting, > just the "active" > config (running + ephemeral). The access control model for I2RS is > different than NETCONF. > > Recent discussion has me confused: > > A) Are the YANG modules exactly the same for the running and ephemeral > datastores? > (Interim decided yes) > I understand that the NETMOD interim decided it'd be nice. But I'm not yet convinced or hearing reasons that convince me that it is the case for I2RS. For instance, the type of events or functionality and abstractions that make sense in I2RS may be quite different. Certainly, what we have for a RIB model is not what you'd see for a static routes configuration model. > B) How are the same instances of the same data model related in the > running and ephemeral > datastores? > > I thought "phase 1" was supposed to be simple and the I2RS client would > just inject and remove > RIB data to override the running config. So, answer to (B) is: datastores > have independent > instances. If ephemeral instance exists, it is used. If deleted, then the > instance from the > running config (if any) becomes active. As long as the ephemeral instance > exists, the running config > instance is ignored. > It depends on the priorities between the config and I2RS. > Is this consistent with the architecture document? > Which solution best fits the agreed upon architecture? > The architecture lets the implementation determine what priority the CLI/NetConf-config is at compared to any I2RS client. If it is better, the the I2RS client would have its state rejected in case of an overlap. Cheers, Alia > Regards, >> no-hats Alia >> >> > Andy > > >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --001a11c37b9a0de43305048b75ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 1, 2014 at 2:15 PM, Andy Bierman <andy@yumaworks.com&= gt; wrote:


On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas <akatlas@gmail.com>= wrote:
Hi,

= I'd like to really understand why I2RS needs a datastore and what that = actually means.
In my initial conception of what an I2RS agent wo= uld do for, say, writing a route in the RIB
model, is that =C2=A0= the I2RS agent would simply parse a received request from a standard format= =C2=A0
and model into the internal and pass that to a RIB Manager= - just as an OSPF implementation=C2=A0
might install a route to = the RIB manager.=C2=A0 An I2RS agent could also query the RIB Manager to=C2= =A0
read routes and there'd be events coming out.
<= br>
With the introduction of priorities to handle multi-headed wr= iters and collision errors, the I2RS agent would need to store what was wri= tten by which client.

What benefits and rationale = does a YANG datastore add?=C2=A0 Why does using one need to be
st= andardized?

I apologize if this seems a naive ques= tion, but it's been quite a while since I read up on YANG and NetConf/R= estConf. =C2=A0


It is a great question because the datastore is used for 3 reas= ons in NETCONF/YANG.

=C2=A0 1) conceptual containe= r for top-level YANG data nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= 1a) source parameter for retrieval; target parameter for editing

Since I2RS is based on single= operations - sort of like what I understand is the case
for Rest= Conf - I don't see this applying to I2RS.=C2=A0 Am I missing something?=
=C2=A0
=C2=A0 2) conceptual= container for YANG validation rules for the running datastore

Again, I don't t= hink that I2RS really is doing YANG validation.=C2=A0 I guess this is a det= ail
that isn't really discussed in the architecture, but my a= ssumptions have been that
it would negatively impact the desired = speed and throughput of operations in I2RS.
=C2=A0
=C2=A0 3) conceptual container for access control mo= del

And as you say = below, this is different for I2RS.

So again - why = does I2RS need a datastore?=C2=A0
<= div dir=3D"ltr">
= =C2=A0=C2=A0
I don't agree that multiple ephemeral datastores are needed. Supp= ort for multiple clients
within 1 datastore is needed.=C2=A0

YANG validation rules for the ephemeral datastore are = not interesting, just the "active"
config (running + ep= hemeral). The access control model for I2RS is different than NETCONF.

Recent discussion has me confused:

=C2=A0 =C2=A0A) Are the YANG modules exactly the same for the running= and ephemeral datastores?
=C2=A0 =C2=A0(Interim decided yes)

I understand that the = NETMOD interim decided it'd be nice.=C2=A0 But I'm not yet convince= d or hearing reasons that convince me that it is the case for I2RS.=C2=A0 F= or instance, the type of events or functionality and abstractions that make= sense in I2RS may be quite different. =C2=A0 Certainly,
what we = have for a RIB model is not what you'd see for a static routes configur= ation model.

=C2=A0
=C2=A0 =C2=A0B) How are the same instances of the same da= ta model related in the running and ephemeral
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 datastores?

I thought "phase 1&quo= t; was supposed to be simple and the I2RS client would just inject and remo= ve
RIB data to override the running config.=C2=A0 So, answer to (= B) is: datastores have independent
instances. If ephemeral instan= ce exists, it is used. If deleted, then the instance from the
run= ning config (if any) becomes active.=C2=A0 As long as the ephemeral instanc= e exists, the running config
instance is ignored.

It depends on the priorities betwe= en the config and I2RS.=C2=A0
=C2=A0
Is this consistent with the architecture document?
Which solution best fits the agreed upon architecture?

The architecture lets the impleme= ntation determine what priority the CLI/NetConf-config
is at comp= ared to any I2RS client.=C2=A0 If it is better, the the I2RS client would h= ave its state
rejected in case of an overlap.

Cheers,
Alia

=C2=A0
Regards,
no-hats =C2=A0Alia


Andy
=
=C2=A0
=

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--001a11c37b9a0de43305048b75ba-- From nobody Fri Oct 3 14:36:49 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0434C1A892B for ; Fri, 3 Oct 2014 14:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 Ev3FKFFcfgSK for ; Fri, 3 Oct 2014 14:36:45 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DE81A8916 for ; Fri, 3 Oct 2014 14:36:40 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so63218wid.4 for ; Fri, 03 Oct 2014 14:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a33pdn2hzDXvqU/kRHXGMjqxIU7Ux8E4h2uMyMdQwck=; b=yRsBnkY/iEAgTKB7ZpZrpHd9+9Ts8mWiQBPimDZAmg4DSq3/DLfxvy0SSeLsc3bAHZ 4iO7k8L60t8i8+5bPFrKsopRbogalqta1k/AeYqS1FJGDHVBzNzr6ehN9H1EficqKGEe rpBeIa7hmuNCJpXfmIHc5octacCZ8v2z+XzzA5aMVlUKG9Z1YkKUv6dHw+7p3bZcqyHP HXUyIfbfh5gmku8Na6JSa8CCiWQCAV/C1DVRVx09a0y3OUNEdVsBuquO55yJua6JKA3z OYG23EM61PxC9hpCpocgTtwrEMhyf2q/jeVdT7p8JVoOeN34y9NIb/8iZ1Gsofglb4jE 08eg== MIME-Version: 1.0 X-Received: by 10.180.100.38 with SMTP id ev6mr1042849wib.83.1412372199670; Fri, 03 Oct 2014 14:36:39 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Fri, 3 Oct 2014 14:36:39 -0700 (PDT) In-Reply-To: <1F252D5E-BA2A-42A5-8851-3A0C613C3004@lucidvision.com> References: <1F252D5E-BA2A-42A5-8851-3A0C613C3004@lucidvision.com> Date: Fri, 3 Oct 2014 17:36:39 -0400 Message-ID: From: Alia Atlas To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=f46d0418270a408baf05048b8744 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/w11z7a-M1c-2eYGwXswEy4pqsnI Cc: "i2rs@ietf.org" , Andy Bierman Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:36:48 -0000 --f46d0418270a408baf05048b8744 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 3:23 PM, Thomas D. Nadeau wrote: > > On Oct 1, 2014:11:15 AM, at 11:15 AM, Andy Bierman > wrote: > > > > On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas wrote: > >> Hi, >> >> I'd like to really understand why I2RS needs a datastore and what that >> actually means. >> In my initial conception of what an I2RS agent would do for, say, writing >> a route in the RIB >> model, is that the I2RS agent would simply parse a received request from >> a standard format >> and model into the internal and pass that to a RIB Manager - just as an >> OSPF implementation >> might install a route to the RIB manager. An I2RS agent could also query >> the RIB Manager to >> read routes and there'd be events coming out. >> >> With the introduction of priorities to handle multi-headed writers and >> collision errors, the I2RS agent would need to store what was written by >> which client. >> >> What benefits and rationale does a YANG datastore add? Why does using >> one need to be >> standardized? >> >> I apologize if this seems a naive question, but it's been quite a while >> since I read up on YANG and NetConf/RestConf. >> >> > It is a great question because the datastore is used for 3 reasons in > NETCONF/YANG. > > 1) conceptual container for top-level YANG data nodes > 1a) source parameter for retrieval; target parameter for editing > 2) conceptual container for YANG validation rules for the running > datastore > 3) conceptual container for access control model > > > I don't agree that multiple ephemeral datastores are needed. Support for > multiple clients > within 1 datastore is needed. > > > That is precisely the point I've been making. We've been making this > discussion far too complex. > Yes - this does not need to be as complex. > > YANG validation rules for the ephemeral datastore are not interesting, > just the "active" > config (running + ephemeral). The access control model for I2RS is > different than NETCONF. > > Recent discussion has me confused: > > A) Are the YANG modules exactly the same for the running and ephemeral > datastores? > (Interim decided yes) > > > Lets hope so, or we've gone off into the woods... > That is my concern. I've seen no reasoning beyond wishful thinking and a desire to allow anything to be done quickly and ephemerally. > B) How are the same instances of the same data model related in the > running and ephemeral > datastores? > > I thought "phase 1" was supposed to be simple and the I2RS client would > just inject and remove > RIB data to override the running config. So, answer to (B) is: datastores > have independent > instances. If ephemeral instance exists, it is used. If deleted, then the > instance from the > running config (if any) becomes active. As long as the ephemeral instance > exists, the running config > instance is ignored. > > Is this consistent with the architecture document? > Which solution best fits the agreed upon architecture? > > > > > > Regards, >> no-hats Alia >> >> > Andy > > >> >> _______________________________________________ >> 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 > > > --f46d0418270a408baf05048b8744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 1, 2014 at 3:23 PM, Thomas D. Nadeau <= tnadeau@lucidv= ision.com> wrote:

On Oct 1, 2014:1= 1:15 AM, at 11:15 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas <akatlas@gma= il.com> wrote:
Hi,
<= br>
I'd like to really understand why I2RS needs a datastore = and what that actually means.
In my initial conception of what an= I2RS agent would do for, say, writing a route in the RIB
model, = is that =C2=A0the I2RS agent would simply parse a received request from a s= tandard format=C2=A0
and model into the internal and pass that to= a RIB Manager - just as an OSPF implementation=C2=A0
might insta= ll a route to the RIB manager.=C2=A0 An I2RS agent could also query the RIB= Manager to=C2=A0
read routes and there'd be events coming ou= t.

With the introduction of priorities to handle m= ulti-headed writers and collision errors, the I2RS agent would need to stor= e what was written by which client.

What benefits = and rationale does a YANG datastore add?=C2=A0 Why does using one need to b= e
standardized?

I apologize if this seem= s a naive question, but it's been quite a while since I read up on YANG= and NetConf/RestConf. =C2=A0

<= br>
It is a great question because the datastore is used for 3 re= asons in NETCONF/YANG.

=C2=A0 1) conceptual contai= ner for top-level YANG data nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A01a) source parameter for retrieval; target parameter for editing
=C2=A0 2) conceptual container for YANG validation rules for the running= datastore
=C2=A0 3) conceptual container for access control mode= l
=C2=A0=C2=A0

I don't agree that mu= ltiple ephemeral datastores are needed. Support for multiple clients
<= div>within 1 datastore is needed.=C2=A0

That is= precisely the point I've been making. We've been making this discu= ssion far too complex. =C2=A0

Y= es - this does not need to be as complex. =C2=A0
=C2=A0

YANG validation rules for the ephe= meral datastore are not interesting, just the "active"
= config (running + ephemeral). The access control model for I2RS is differen= t than NETCONF.

Recent discussion has me confused:=

=C2=A0 =C2=A0A) Are the YANG modules exactly the = same for the running and ephemeral datastores?
=C2=A0 =C2=A0(Inte= rim decided yes)

Lets hope so, or we've gon= e off into the woods...

That is= my concern. =C2=A0 I've seen no reasoning beyond wishful thinking and = a desire to allow anything to be done quickly and ephemerally.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0B) How are the same in= stances of the same data model related in the running and ephemeral
=C2=A0 =C2=A0 =C2=A0 =C2=A0 datastores?

I thoug= ht "phase 1" was supposed to be simple and the I2RS client would = just inject and remove
RIB data to override the running config.= =C2=A0 So, answer to (B) is: datastores have independent
instance= s. If ephemeral instance exists, it is used. If deleted, then the instance = from the
running config (if any) becomes active.=C2=A0 As long as= the ephemeral instance exists, the running config
instance is ig= nored.

Is this consistent with the architecture do= cument?
Which solution best fits the agreed upon architecture?





Regards,
no-= hats =C2=A0Alia


= Andy
=C2=A0

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://= www.ietf.org/mailman/listinfo/i2rs


--f46d0418270a408baf05048b8744-- From nobody Fri Oct 3 14:38:45 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9FA1A892B for ; Fri, 3 Oct 2014 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 S5Ki39LSOSLV for ; Fri, 3 Oct 2014 14:38:40 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7D91A8916 for ; Fri, 3 Oct 2014 14:38:39 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hi2so2552209wib.5 for ; Fri, 03 Oct 2014 14:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uUkN4wPsWpXCFWl+buv46KBRI5jmIqe7PaD3D/xZcVc=; b=w2K3fp0I/wcb7UmLWgpjW+Gdfptype84ttXPvF/KMV1OOwgSSPwyOhIJhenmfGWuUA LCFGOu3yr6evGleNobB6Ur8ZatwgZbY0pK/4qZPQiB7iyNoTPnssk20U9wFGq2GOfnOi SUcBo/QuEcVqmKVWREReee1wGOJvdrHFCEIWZs3z3BaFVO6CakcT2IF3hYKER92DyPm1 8osfpqsnvo7Gz9U+93ZV2yP2JIf8akT8V/sEwlIqrVWeHcrzlEF3bsQ6KDdrrS/eoPDT rCzsQL+OXxYJYrSY6t4CGS72sFYH85vuiOMq16Xufgi0Fda0QUFSo2E8+Tr8I448+7c1 ugag== MIME-Version: 1.0 X-Received: by 10.194.184.111 with SMTP id et15mr10980962wjc.14.1412372318583; Fri, 03 Oct 2014 14:38:38 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Fri, 3 Oct 2014 14:38:38 -0700 (PDT) In-Reply-To: <5A60C18F-DC9E-4839-9B3F-8D341B4D2208@lucidvision.com> References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> <46f9a05b0f3b4d3e8ba3bfda2d2b94d2@ATL-SRV-MBX1.advaoptical.com> <4E07CDAC-E90D-4DE7-B929-834264163D2B@lucidvision.com> <5A60C18F-DC9E-4839-9B3F-8D341B4D2208@lucidvision.com> Date: Fri, 3 Oct 2014 17:38:38 -0400 Message-ID: From: Alia Atlas To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=047d7ba97e9a56ff8905048b8ee3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3x6TZ9GKryM0xR9GU-5L10zBnR4 Cc: "i2rs@ietf.org" , Igor Bryskin , Dean Bogdanovic Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:38:44 -0000 --047d7ba97e9a56ff8905048b8ee3 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 3:25 PM, Thomas D. Nadeau wrote: > > This is where the "copy to running config" discussion has arrived > at. We either need a special i2rs "operation" or just a "write to config" > object that can be set and triggers the action. But by default, the > changes are ephemeral and thus do not survive reboots. > The initial I2RS framework went down this path of allowing permanent as well as ephemeral - as you well know - and the WG consensus was to take it out as too complex. Frankly, we're almost 2 years since the BoF and don't have anything that is implementable. I think we need to stay simple. Regards, Alia > --Tom > > > On Oct 1, 2014:10:45 AM, at 10:45 AM, Igor Bryskin < > IBryskin@advaoptical.com> wrote: > > > What if these things must not survive reboots? > > ________________________________________ > > From: Thomas D. Nadeau [tnadeau@lucidvision.com] > > Sent: Wednesday, October 1, 2014 1:33 PM > > To: Igor Bryskin > > Cc: Alia Atlas; Dean Bogdanovic; i2rs@ietf.org > > Subject: Re: [i2rs] Why do we need a datastore? > > > > On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin < > IBryskin@advaoptical.com> wrote: > > > >> Alia, > >> > >> Your question makes sense if I2RS is limited to routing data > manipulation. > >> In this case it could be thought of as an additional routing > protocol.After all OSPF does not need any data store to install its routes, > >> What if I2RS client want to configure other things? > > > > Then just use Netconf or RestConf. > > > > --Tom > > > >> > >> Igor > >> ________________________________________ > >> From: i2rs [i2rs-bounces@ietf.org] on behalf of Alia Atlas [ > akatlas@gmail.com] > >> Sent: Wednesday, October 1, 2014 9:54 AM > >> To: Dean Bogdanovic > >> Cc: i2rs@ietf.org > >> Subject: Re: [i2rs] Why do we need a datastore? > >> > >> Hi Dean, > >> > >> Thanks for the explanation. It matches with what I understand for > configuration. > >> Where I am confused is why I2RS - which is doing ephemeral only and > matches closer to the direct proprietary APIs directly to > >> the routing processes - is being tied up in this. > >> > >> Regards, > >> Alia > >> > >> On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: > >> Hi Alia, > >> > >> today networking devices can be managed in three ways: > >> > >> 1. CLI - is the UI we all know and use it quite heavily. In order for > the device to boot in a known state a set of CLI commands have to be saved > somewhere on the device. For that you have a data store. That data store > can be a flat file or a database. The datastore is then read by network > device daemons which change their state based on it. > >> > >> Before the APIs were exposed, TCL/Expect and Perl ruled the automation > world and everything was based on screen scraping. In order to make machine > to machine communication easier, NETCONF was created as a standard protocol > to communicate with the devices. > >> > >> 2. via APIs - there are several type of APIs, but most widely available > ones are providing functionalities same as CLI. The difference is that CLI > is human intended and APIs are machine intended. One of the example is > Junos XML APIs, where (almost) each CLI command is represented by XML API. > It still requires knowing how to configure device via CLI and the result of > the application written with such APIs is stored in the data store from > which daemon read how to change their state. > >> There are some vendors that provide APIs that allow communication with > daemons directly, bypassing management infrastructure, but those are highly > proprietary mechanisms. > >> The APIs that were released by vendors, were not standardized and each > vendor had different configuration models, so although communication with > devices was standardized, there was no easy way to communicate semantics, > which led to YANG, as standard language that all vendors would understand > and now standardizing configuration and operational model, so same > configuration statement can be sent to all supporting devices and be done > (instead of writing same desired functionality in several configuration > statements) > >> > >> At the end it really doesn't matter how you are communicating with the > devices, it really boils down to that you want the device to boot into a > known state. This was done by having a local data store that was containing > set of instructions what state the device should be after reading it. > >> > >> It really doesn't matter which mechanism is used (from above 2), > configuration data has to be provided. Historically, data was on the > device, as the connection between device and the network management was > slow. Today (like in MSDC), devices don't have local configuration, those > devices when boot look for provisioning system and get configuration from a > remote location and then change the state of the device based on it. This > has led that > >> > >> 3. some vendors use Linux, allow management via pseudo file system > (/proc) > >> > >> where the state of the device is changed directly without having a need > for data store on the device. You have to keep in mind that only Linux > allows changing the state of non-processes data through /proc. *BSD flavors > don't allow that. > >> > >> So today, most network operators (by this I mean any entity that > operates a network, either enterprise or carrier), need to simplify network > management, make it more efficient and that devices will behave very > predictably, so that network is in a known state. Because of the legacy, > this is easiest done by having a local datastore on a device, through which > the state of the device is changed. > >> > >> Hope this helps > >> > >> Dean > >> > >> > >> On Oct 1, 2014, at 12:25 AM, Alia Atlas akatlas@gmail.com>> wrote: > >> > >>> Hi, > >>> > >>> I'd like to really understand why I2RS needs a datastore and what that > actually means. > >>> In my initial conception of what an I2RS agent would do for, say, > writing a route in the RIB > >>> model, is that the I2RS agent would simply parse a received request > from a standard format > >>> and model into the internal and pass that to a RIB Manager - just as > an OSPF implementation > >>> might install a route to the RIB manager. An I2RS agent could also > query the RIB Manager to > >>> read routes and there'd be events coming out. > >>> > >>> With the introduction of priorities to handle multi-headed writers and > collision errors, the I2RS agent would need to store what was written by > which client. > >>> > >>> What benefits and rationale does a YANG datastore add? Why does using > one need to be > >>> standardized? > >>> > >>> I apologize if this seems a naive question, but it's been quite a > while since I read up on YANG and NetConf/RestConf. > >>> > >>> Regards, > >>> no-hats Alia > >>> > >>> _______________________________________________ > >>> 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 > > > > --047d7ba97e9a56ff8905048b8ee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 1, 2014 at 3:25 PM, Thomas D. Nadeau <= tnadeau@lucidv= ision.com> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is where the "copy to running config&= quot; discussion has arrived at. We either need a special i2rs "operat= ion" or just a "write to config" object that can be set and = triggers the action.=C2=A0 But by default, the changes are ephemeral and th= us do not survive reboots.

The initial = I2RS framework went down this path of allowing permanent as well as ephemer= al - as you well know - and the WG consensus =C2=A0was to take it out as to= o complex.

Frankly, we're almost 2 years since= the BoF and don't have anything that is implementable.=C2=A0 I think w= e need to stay simple.

Regards,
Alia

=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Tom


On Oct 1, 2014:10:45 AM, at 10:45 AM, Igor Bryskin <IBryskin@advaoptical.com> wrote:

> What if these things must not survive reboots?
> ________________________________________
> From: Thomas D. Nadeau [tna= deau@lucidvision.com]
> Sent: Wednesday, October 1, 2014 1:33 PM
> To: Igor Bryskin
> Cc: Alia Atlas; Dean Bogdanovic; i2rs= @ietf.org
> Subject: Re: [i2rs] Why do we need a datastore?
>
> On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin <IBryskin@advaoptical.com> wrote:
>
>> Alia,
>>
>> Your question makes sense if I2RS is limited to routing data manip= ulation.
>> In this case it could be thought of as an additional routing proto= col.After all OSPF does not need any data store to install its routes,
>> What if I2RS client want to configure other things?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Then just use Netconf or RestConf.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 --Tom
>
>>
>> Igor
>> ________________________________________
>> From: i2rs [i2rs-bounces@= ietf.org] on behalf of Alia Atlas [akatlas@gmail.com]
>> Sent: Wednesday, October 1, 2014 9:54 AM
>> To: Dean Bogdanovic
>> Cc: i2rs@ietf.org
>> Subject: Re: [i2rs] Why do we need a datastore?
>>
>> Hi Dean,
>>
>> Thanks for the explanation.=C2=A0 It matches with what I understan= d for configuration.
>> Where I am confused is why I2RS - which is doing ephemeral only an= d matches closer to the direct proprietary APIs directly to
>> the routing processes - is being tied up in this.
>>
>> Regards,
>> Alia
>>
>> On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic <deanb@juniper.net<mailto:deanb@juniper.net>> wrote:
>> Hi Alia,
>>
>> today networking devices can be managed in three ways:
>>
>> 1. CLI - is the UI we all know and use it quite heavily. In order = for the device to boot in a known state a set of CLI commands have to be sa= ved somewhere on the device. For that you have a data store. That data stor= e can be a flat file or a database. The datastore is then read by network d= evice daemons which change their state based on it.
>>
>> Before the APIs were exposed, TCL/Expect and Perl ruled the automa= tion world and everything was based on screen scraping. In order to make ma= chine to machine communication easier, NETCONF was created as a standard pr= otocol to communicate with the devices.
>>
>> 2. via APIs - there are several type of APIs, but most widely avai= lable ones are providing functionalities same as CLI. The difference is tha= t CLI is human intended and APIs are machine intended. One of the example i= s Junos XML APIs, where (almost) each CLI command is represented by XML API= . It still requires knowing how to configure device via CLI and the result = of the application written with such APIs is stored in the data store from = which daemon read how to change their state.
>> There are some vendors that provide APIs that allow communication = with daemons directly, bypassing management infrastructure, but those are h= ighly proprietary mechanisms.
>> The APIs that were released by vendors, were not standardized and = each vendor had different configuration models, so although communication w= ith devices was standardized, there was no easy way to communicate semantic= s, which led to YANG, as standard language that all vendors would understan= d and now standardizing configuration and operational model, so same config= uration statement can be sent to all supporting devices and be done (instea= d of writing same desired functionality in several configuration statements= )
>>
>> At the end it really doesn't matter how you are communicating = with the devices, it really boils down to that you want the device to boot = into a known state. This was done by having a local data store that was con= taining set of instructions what state the device should be after reading i= t.
>>
>> It really doesn't matter which mechanism is used (from above 2= ), configuration data has to be provided. Historically, data was on the dev= ice, as the connection between device and the network management was slow. = Today (like in MSDC), devices don't have local configuration, those dev= ices when boot look for provisioning system and get configuration from a re= mote location and then change the state of the device based on it. This has= led that
>>
>> 3. some vendors use Linux, allow management via pseudo file system= (/proc)
>>
>> where the state of the device is changed directly without having a= need for data store on the device. You have to keep in mind that only Linu= x allows changing the state of non-processes data through /proc. *BSD flavo= rs don't allow that.
>>
>> So today, most network operators (by this I mean any entity that o= perates a network, either enterprise or carrier), need to simplify network = management, make it more efficient and that devices will behave very predic= tably, so that network is in a known state. Because of the legacy, this is = easiest done by having a local datastore on a device, through which the sta= te of the device is changed.
>>
>> Hope this helps
>>
>> Dean
>>
>>
>> On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com<mailto:akatlas@gmail.com>> wrote:
>>
>>> Hi,
>>>
>>> I'd like to really understand why I2RS needs a datastore a= nd what that actually means.
>>> In my initial conception of what an I2RS agent would do for, s= ay, writing a route in the RIB
>>> model, is that=C2=A0 the I2RS agent would simply parse a recei= ved request from a standard format
>>> and model into the internal and pass that to a RIB Manager - j= ust as an OSPF implementation
>>> might install a route to the RIB manager.=C2=A0 An I2RS agent = could also query the RIB Manager to
>>> read routes and there'd be events coming out.
>>>
>>> With the introduction of priorities to handle multi-headed wri= ters and collision errors, the I2RS agent would need to store what was writ= ten by which client.
>>>
>>> What benefits and rationale does a YANG datastore add?=C2=A0 W= hy does using one need to be
>>> standardized?
>>>
>>> I apologize if this seems a naive question, but it's been = quite a while since I read up on YANG and NetConf/RestConf.
>>>
>>> Regards,
>>> no-hats=C2=A0 Alia
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org<mailto:<= a href=3D"mailto:i2rs@ietf.org">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
>


--047d7ba97e9a56ff8905048b8ee3-- From nobody Fri Oct 3 14:43:32 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630441A893E for ; Fri, 3 Oct 2014 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 LF7yYJHrqX24 for ; Fri, 3 Oct 2014 14:43:29 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B201A892B for ; Fri, 3 Oct 2014 14:43:28 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so2493500wgg.25 for ; Fri, 03 Oct 2014 14:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PIoWJKQ8xWMERsxZoFkAnC7uzlJtESFeqrUSKYzQJqE=; b=B0XjwMm4QZbJKk8pZLewNBIkmz1VtmI/LaRQXk3KoS7DPdqO3WQjHCGiUuxPQ2xGkI gboKJW4zeD1xpRZYCodvJSfdhXeS0ZALk4H+2LYXZamPa3B1fAlwctLjoVN92xxSfHLS 0WhbnYe7UhqDHKAWX7iuaBvMrEn5t4s4IhjCGvwACaJVXXeQDrsXnKQu5xs/f5ambY5O 0q1DaDJAvWW8Ll0FmUBYJI1snbtpb17TfKSWgdd9EC5k3ApK3fFUjZMtSH8JI3Vm8wFJ Pv2+kx5ascndxntXDq2b/YYa0pzmSQ027oif0+D2Ntk1b2TGt7MaaR3vlDW0aZ/Hwwgq s8fQ== MIME-Version: 1.0 X-Received: by 10.180.188.102 with SMTP id fz6mr1074042wic.83.1412372607271; Fri, 03 Oct 2014 14:43:27 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Fri, 3 Oct 2014 14:43:27 -0700 (PDT) In-Reply-To: References: <20141001220545.GA39249@elstar.local> Date: Fri, 3 Oct 2014 17:43:27 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11c37b9a8c0a2305048b9fa5 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0MoojYbAdNnAZVyvo6GVoZizs_A Cc: "i2rs@ietf.org" , Juergen Schoenwaelder Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:43:31 -0000 --001a11c37b9a8c0a2305048b9fa5 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 1, 2014 at 6:18 PM, Andy Bierman wrote: > > > On Wed, Oct 1, 2014 at 3:05 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote: >> > >> > I don't agree that multiple ephemeral datastores are needed. Support for >> > multiple clients within 1 datastore is needed. >> > >> >> We can punt this but I believe we will be back discussing this again >> in a couple of years. If multiple clients inject state (in an >> uncoordinated way), certain things will go wrong. If we have no way to >> separate multipe uncoordinated I2RS clients (e.g., by controlling the >> priorities of different ephemeral datastores), then we will need hacks >> with metadata to work around this. >> >> > There are different priorities for clients. > The collision management and cleanup are basically the same either way, > because the agent is not required to remember state that got bumped. > It that were true, then a separate datastore per client would be a feature > instead of an implementation detail. > > Perhaps it is OK to ignore multiple ephemeral datastores now in order >> to make progress. But I believe we are better off if things are >> designed such that there can be multiple ephemeral datastores when >> they are useful, that is we should not do anything to prevent having >> multiple ephemeral datastores. >> > > It's hard enough to agree on 1 ;-) > > IMO the ephemeral config always overrides the running config. > That means in order to remove a static entry from the active config > (but not the running config), there needs to be an operation > for creating a "data instance deleted" entry in the ephemeral datastore. > (Not a way to have I2RS actually delete entries from the running config). > To quote the I2RS Architecture, "6.3. Interactions with Local Config Changes may originate from either Local Config or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved in a deterministic manner that respects operator-applied policy. That policy can determine whether Local Config overrides a particular I2RS client's request or vice versa. To achieve this end, either by default Local Config always wins or, optionally, a routing element may permit a priority to be configured on the device for the Local Config mechanism. The policy mechanism in the later case is comparing the I2RS client's priority with that priority assigned to the Local Config. When the Local Config always wins, some communication between that subsystem and the I2RS Agent is still necessary. That communication contains the details of each specific device configuration change that the I2RS Agent is permitted to modify. In addition, when the system determines, that a client's I2RS state is preempted, the I2RS agent must notify the affected I2RS clients; how the system determines this is implementation-dependent. It is critical that policy based upon the source is used because the resolution cannot be time-based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic." Now - if we have to decide that the CLI always wins, that is one option. I, personally, would be quite opposed to the idea that I2RS would always win. That does not give recovery mechanisms to the operators when and if something goes wrong. Regards, Alia > > > >> /js >> >> > Andy > > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > --001a11c37b9a8c0a2305048b9fa5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 1, 2014 at 6:18 PM, Andy Bierman <andy@yumaworks.com&= gt; wrote:


On Wed, Oct 1, 2= 014 at 3:05 PM, Juergen Schoenwaelder <j.schoenwaelder@= jacobs-university.de> wrote:
On Wed, Oct = 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote:
>
> I don't agree that multiple ephemeral datastores are needed. Suppo= rt for
> multiple clients within 1 datastore is needed.
>

We can punt this but I believe we will be back discussing this again
in a couple of years. If multiple clients inject state (in an
uncoordinated way), certain things will go wrong. If we have no way to
separate multipe uncoordinated I2RS clients (e.g., by controlling the
priorities of different ephemeral datastores), then we will need hacks
with metadata to work around this.


There are different priorities = for clients.
The collision management and cleanup are basically t= he same either way,
because the agent is not required to remember= state that got bumped.
It that were true, then a separate datast= ore per client would be a feature
instead of an implementation de= tail.

Perhaps it is OK to ignore multiple ephemeral datastores now in order
to make progress. But I believe we are better off if things are
designed such that there can be multiple ephemeral datastores when
they are useful, that is we should not do anything to prevent having
multiple ephemeral datastores.

I= t's hard enough to agree on 1 ;-)

IMO the ephe= meral config always overrides the running config.
That means in o= rder to remove a static entry from the active config
(but not the= running config), there needs to be an operation
for creating a &= quot;data instance deleted" entry in the ephemeral datastore.
(Not a way to have I2RS actually delete entries from the running config).=

To quote the I2RS = Architecture,

"6.3.=C2=A0 Interactions with Local = Config

=C2=A0 =C2=A0Changes may originate from either Local Config o= r from I2RS.=C2=A0 The
=C2=A0 =C2=A0modifications and data stored by I2R= S are separate from the local
=C2=A0 =C2=A0device configuration, but con= flicts between the two must be resolved

=C2=A0 =C2=A0in a determinis= tic manner that respects operator-applied policy.
=C2=A0 =C2=A0That poli= cy can determine whether Local Config overrides a particular
=C2=A0 =C2= =A0I2RS client's request or vice versa.=C2=A0 To achieve this end, eith= er by
=C2=A0 =C2=A0default Local Config always wins or, optionally, a ro= uting element
=C2=A0 =C2=A0may permit a priority to be configured on the= device for the Local
=C2=A0 =C2=A0Config mechanism.=C2=A0 The policy me= chanism in the later case is
=C2=A0 =C2=A0comparing the I2RS client'= s priority with that priority assigned to
=C2=A0 =C2=A0the Local Config.=

=C2=A0 =C2=A0When the Local Config always wins, some communication = between that
=C2=A0 =C2=A0subsystem and the I2RS Agent is still necessar= y.=C2=A0 That communication
=C2=A0 =C2=A0contains the details of each sp= ecific device configuration change
=C2=A0 =C2=A0that the I2RS Agent is p= ermitted to modify.=C2=A0 In addition, when the
=C2=A0 =C2=A0system dete= rmines, that a client's I2RS state is preempted, the I2RS
=C2=A0 =C2= =A0agent must notify the affected I2RS clients; how the system
=C2=A0 = =C2=A0determines this is implementation-dependent.

=C2=A0 =C2=A0It i= s critical that policy based upon the source is used because the
=C2=A0 = =C2=A0resolution cannot be time-based.=C2=A0 Simply allowing the most recen= t
=C2=A0 =C2=A0state to prevail could cause race conditions where the fi= nal state is
=C2=A0 =C2=A0not repeatably deterministic."

Now - if we hav= e to decide that the CLI always wins, that is one option.
I, personally, would be quite opposed to the idea that I2R= S would always
win.=C2=A0 That does not giv= e recovery mechanisms to the operators when and
if something goes wrong.

Regards,
Alia
=C2=A0



/js


Andy
=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus= Ring 1, 28759 Bremen, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<ht= tp://www.jacobs-university.de/>


--001a11c37b9a8c0a2305048b9fa5-- From nobody Fri Oct 3 15:06:02 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C801A89E7 for ; Fri, 3 Oct 2014 15:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 93UwwdRpOEjw for ; Fri, 3 Oct 2014 15:05:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::714]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D99A1A89E1 for ; Fri, 3 Oct 2014 15:05:56 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 3 Oct 2014 22:05:33 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.64]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.64]) with mapi id 15.00.1039.011; Fri, 3 Oct 2014 22:05:32 +0000 From: Dean Bogdanovic To: Alia Atlas Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++RqKttL9wxEexAlDYcQgC+ZwbP/0AgAAD/wCAAAU+AIADkOwAgAAXxAA= Date: Fri, 3 Oct 2014 22:05:32 +0000 Message-ID: References: <42FD4D5C-D285-4723-B284-E72C6797595C@juniper.net> <5CC8BAFD-768D-4B5D-B96D-F588ED558E85@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(377454003)(129404003)(189002)(24454002)(199003)(89996001)(46102003)(99396003)(19580395003)(92566001)(93916002)(92726001)(76176999)(57306001)(85306004)(87936001)(101416001)(76482002)(21056001)(1411001)(50986999)(10300001)(40100001)(31966008)(97736003)(104166001)(86362001)(50226001)(15975445006)(120916001)(66066001)(64706001)(19580405001)(33656002)(4396001)(87286001)(2656002)(77156001)(16236675004)(36756003)(106356001)(83716003)(20776003)(110136001)(99286002)(106116001)(82746002)(107046002)(19617315012)(62966002)(77096002)(105586002)(80022003)(95666004)(88136002)(85852003)(93886004)(23603001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_A006FEABA7D84A878DEA8EFC447D3A53junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7XTP-iY2KA3X8a3ZOeLmAILOFEU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 22:06:01 -0000 --_000_A006FEABA7D84A878DEA8EFC447D3A53junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 3, 2014, at 4:40 PM, Alia Atlas > wrote: Hi Dean, Sorry for the delay in responding. Telechats do that to one. On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic > wrote: On Oct 1, 2014, at 9:54 AM, Alia Atlas > wrote: Hi Dean, Thanks for the explanation. It matches with what I understand for configur= ation. Where I am confused is why I2RS - which is doing ephemeral only and matches= closer to the direct proprietary APIs directly to the routing processes - is being tied up in this. Today there is no standard protocol to expose writing to the daemons direct= ly, except through a datastore. If you would compare routing daemon in Juno= s and routing daemon in IOS or NX-OS, the data models are very different. Y= ou need a standard API to communicate to all of them. Right - but that's what I2RS is asking and trying to do. I'm sure I didn't= just hear you say that we can't do it because it doesn't exist yet. I didn't say it is not possible. Every vendor will have to create an I2RS a= gent that will be directly connected to daemons and create a translation fr= om internal to external APIs. Essentially create a parallel control/managem= ent plane to existing ones. Here is a reason why a local datastore comes handy routing daemon crashes and the state is gone. The routing state has to be r= einstated. 1. replay config data from the local data store(s) and reactivate the confi= guration 2. replay config data from the local data store (single data store) and req= uest all I2RS clients to replay their data again Now if some I2RS client, during the crash, tried to execute routing changes= , with local store, those can be executed and put into wait state until dae= mon recovers. I2RS clients can be informed that their changes are pending. I do understand that a datastore is useful for config. For I2RS, if the re= levant routing crashes, then the I2RS clients are just notified that their = state is gone. If an I2RS client tries to request a change and the routing= daemon isn't up, then the change fails! This is part of being in a dynam= ic and distributed system. agree with this. Both approaches have pluses and minuses. Another issue is with config statements. If you go directly to the daemons= , only few very basic things can be exposed (like interfaces, routes, state= less fw filters). If you want to expose more complex statements like L3VPN,= then you have to create a logic that will communicate to multiple daemons = to create such state on the device. You are doubling such logic on the devi= ce. Right - but here I have to pull our attention back to the charter. We can = do: RIB, topology (read only), BGP, DDOS mitigation, hub-and-spoke routing i= mprovement, and traffic exit point optimization. two questions are coming out: how do you plan to do DDoS mitigation: stateless or statefull? And you have= to get more details about traffic exit point optimization. If any of the c= onstructs require more then one daemon involvement, it complicates the case= . If there are proprietary mechanism for everything else, that's ok. Let's g= et this designed correctly - given the WG agreement on the architecture and= the charter constraints on the use-cases. I want to allow network administrators to decide by them self what is expos= ed through I2RS, not us (vendors, SDOs). Then we boil the ocean, claim everything is safe, try and solve all the har= d problems instead of taking reasonable efforts with the simple parts first= . I disagree with you to certain extent, but am fine with your statement. In = case WG changes its mind later, it might not be easy to achieve those goals= . Let's get something done that can be implemented. Regards, Alia Dean Regards, Alia On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic > wrote: Hi Alia, today networking devices can be managed in three ways: 1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device dae= mons which change their state based on it. Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices. 2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It stil= l requires knowing how to configure device via CLI and the result of the ap= plication written with such APIs is stored in the data store from which dae= mon read how to change their state. There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms. The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now= standardizing configuration and operational model, so same configuration s= tatement can be sent to all supporting devices and be done (instead of writ= ing same desired functionality in several configuration statements) At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it. It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot lo= ok for provisioning system and get configuration from a remote location and= then change the state of the device based on it. This has led that 3. some vendors use Linux, allow management via pseudo file system (/proc) where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that. So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest d= one by having a local datastore on a device, through which the state of the= device is changed. Hope this helps Dean On Oct 1, 2014, at 12:25 AM, Alia Atlas > wrote: > Hi, > > I'd like to really understand why I2RS needs a datastore and what that ac= tually means. > In my initial conception of what an I2RS agent would do for, say, writing= a route in the RIB > model, is that the I2RS agent would simply parse a received request from= a standard format > and model into the internal and pass that to a RIB Manager - just as an O= SPF implementation > might install a route to the RIB manager. An I2RS agent could also query= the RIB Manager to > read routes and there'd be events coming out. > > With the introduction of priorities to handle multi-headed writers and co= llision errors, the I2RS agent would need to store what was written by whic= h client. > > What benefits and rationale does a YANG datastore add? Why does using on= e need to be > standardized? > > I apologize if this seems a naive question, but it's been quite a while s= ince I read up on YANG and NetConf/RestConf. > > Regards, > no-hats Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --_000_A006FEABA7D84A878DEA8EFC447D3A53junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <57E2A428247CF9418D6CF9A65D6FD61D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On Oct 3, 2014, at 4:40 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi Dean,

Sorry for the delay in responding.  Telechats do that to one.

On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic= <deanb@juniper.ne= t> wrote:

On Oct 1, 2014, at 9:54 AM, Alia Atlas <akatlas@gmail.com>
 wrote:

Hi Dean,

Thanks for the explanation.  It matches with what I understand fo= r configuration.
Where I am confused is why I2RS - which is doing ephemeral only and ma= tches closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Today there is no standard protocol to expose writing to the daemons= directly, except through a datastore. If you would compare routing daemon = in Junos and routing daemon in IOS or NX-OS, the data models are very diffe= rent. You need a standard API to communicate to all of them. 

Right - but that's what I2RS is asking and trying to do.  I'm sur= e I didn't just hear you say that we can't do it because it doesn't exist y= et. 

I didn't say it is not possible. Every vendor will have to create an I2RS a= gent that will be directly connected to daemons and create a translation fr= om internal to external APIs. Essentially create a parallel control/managem= ent plane to existing ones.
 
Here is a reason why a local datastore comes handy

routing daemon crashes and the state is gone. The routing state has to= be reinstated. 

1. replay config data from the local data store(s) and reactivate the = configuration
2. replay config data from the local data store (single data store) an= d request all I2RS clients to replay their data again

Now if some I2RS client, during the crash, tried to execute routing ch= anges, with local store, those can be executed and put into wait state unti= l daemon recovers. I2RS clients can be informed that their changes are pend= ing.

I do understand that a datastore is useful for config.  For I2RS,= if the relevant routing crashes, then the I2RS clients are just notified t= hat their state is gone.  If an I2RS client tries to request a change = and the routing daemon isn't up, then the change fails!  This is part  of being in a dynamic and distribut= ed system.

agree with this.
 
Both approaches have pluses and minuses. 

Another issue is  with config statements. If you go directly to t= he daemons, only few very basic things can be exposed (like interfaces, rou= tes, stateless fw filters). If you want to expose more complex statements l= ike L3VPN, then you have to create a logic that will communicate to multiple daemons to create such state on th= e device. You are doubling such logic on the device.

Right - but here I have to pull our attention back to the charter.&nbs= p; We can do:
   RIB, topology (read only), BGP, DDOS mitigation, hub-and-= spoke routing improvement, and traffic exit point optimization.

two questions are coming out:
how do you plan to do DDoS mitigation: stateless or statefull? And you= have to get more details about traffic exit point optimization. If any of = the constructs require more then one daemon involvement, it complicates the= case.

If there are proprietary mechanism for everything else, that's ok.&nbs= p; Let's get this designed correctly - given the WG agreement on the archit= ecture and the charter constraints on the use-cases. 

I want to allow network administrators to decide by them self what is = exposed through I2RS, not us (vendors, SDOs).

Then we boil the ocean, claim everything is safe, try and solve all th= e hard problems instead of taking reasonable efforts with the simple parts = first.

I disagree with you to certain extent, but am fine with your statement. In = case WG changes its mind later, it might not be easy to achieve those goals= .

Let's get something done that can be implemented.

Regards,
Alia
 

Dean


Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic = <deanb@juniper.ne= t> wrote:
Hi Alia,

today networking devices can be managed in three ways:

1. CLI - is the UI we all know and use it quite heavily. In order for the d= evice to boot in a known state a set of CLI commands have to be saved somew= here on the device. For that you have a data store. That data store can be = a flat file or a database. The datastore is then read by network device daemons which change their state based on i= t.

Before the APIs were exposed, TCL/Expect and Perl ruled the automation worl= d and everything was based on screen scraping. In order to make machine to = machine communication easier, NETCONF was created as a standard protocol to= communicate with the devices.

2. via APIs - there are several type of APIs, but most widely available one= s are providing functionalities same as CLI. The difference is that CLI is = human intended and APIs are machine intended. One of the example is Junos X= ML APIs, where (almost) each CLI command is represented by XML API. It still requires knowing how to config= ure device via CLI and the result of the application written with such APIs= is stored in the data store from which daemon read how to change their sta= te.
There are some vendors that provide APIs that allow communication with daem= ons directly, bypassing management infrastructure, but those are highly pro= prietary mechanisms.
The APIs that were released by vendors, were not standardized and each vend= or had different configuration models, so although communication with devic= es was standardized, there was no easy way to communicate semantics, which = led to YANG, as standard language that all vendors would understand and now standardizing configuration and = operational model, so same configuration statement can be sent to all suppo= rting devices and be done (instead of writing same desired functionality in= several configuration statements)

At the end it really doesn't matter how you are communicating with the devi= ces, it really boils down to that you want the device to boot into a known = state. This was done by having a local data store that was containing set o= f instructions what state the device should be after reading it.

It really doesn't matter which mechanism is used (from above 2), configurat= ion data has to be provided. Historically, data was on the device, as the c= onnection between device and the network management was slow. Today (like i= n MSDC), devices don't have local configuration, those devices when boot look for provisioning system and ge= t configuration from a remote location and then change the state of the dev= ice based on it. This has led that

3. some vendors use Linux, allow management via pseudo file system (/proc)<= br>
where the state of the device is changed directly without having a need for= data store on the device. You have to keep in mind that only Linux allows = changing the state of non-processes data through /proc. *BSD flavors don't = allow that.

So today, most network operators (by this I mean any entity that operates a= network, either enterprise or carrier), need to simplify network managemen= t, make it more efficient and that devices will behave very predictably, so= that network is in a known state. Because of the legacy, this is easiest done by having a local datastore on= a device, through which the state of the device is changed.

Hope this helps

Dean


On Oct 1, 2014, at 12:25 AM, Alia Atlas <akatlas@gmail.com> wrote:

> Hi,
>
> I'd like to really understand why I2RS needs a datastore and what that= actually means.
> In my initial conception of what an I2RS agent would do for, say, writ= ing a route in the RIB
> model, is that  the I2RS agent would simply parse a received requ= est from a standard format
> and model into the internal and pass that to a RIB Manager - just as a= n OSPF implementation
> might install a route to the RIB manager.  An I2RS agent could al= so query the RIB Manager to
> read routes and there'd be events coming out.
>
> With the introduction of priorities to handle multi-headed writers and= collision errors, the I2RS agent would need to store what was written by w= hich client.
>
> What benefits and rationale does a YANG datastore add?  Why does = using one need to be
> standardized?
>
> I apologize if this seems a naive question, but it's been quite a whil= e since I read up on YANG and NetConf/RestConf.
>
> Regards,
> no-hats  Alia
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs





--_000_A006FEABA7D84A878DEA8EFC447D3A53junipernet_-- From nobody Mon Oct 6 06:32:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4153B1A6F45 for ; Mon, 6 Oct 2014 06:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 fGSUCQZHeRQQ for ; Mon, 6 Oct 2014 06:32:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEE01A6F42 for ; Mon, 6 Oct 2014 06:32:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 06206C21A; Mon, 6 Oct 2014 09:32:04 -0400 (EDT) Date: Mon, 6 Oct 2014 09:32:03 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20141006133203.GA1280@pfrc> References: <20141001220545.GA39249@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-BhsxEsKlXY86AXUMG4-GgasklU Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Andy Bierman Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:32:05 -0000 On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote: > Now - if we have to decide that the CLI always wins, that is one option. > I, personally, would be quite opposed to the idea that I2RS would always > win. That does not give recovery mechanisms to the operators when and > if something goes wrong. So, what is your proposal to allow CLI/local config to win over ephemeral state? If not something comparable to "option 4", what then? -- Jeff From nobody Mon Oct 6 08:01:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2BB1A6FBF for ; Mon, 6 Oct 2014 08:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 aiYzj3EZMxgl for ; Mon, 6 Oct 2014 08:01:41 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9294D1A6FBC for ; Mon, 6 Oct 2014 08:01:41 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so4910069wiv.3 for ; Mon, 06 Oct 2014 08:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ab54/eY5eBC+WOfkjpjQBy6DiHacX5xphCelhZ3GY7Y=; b=FWip5X3VVXJRsp7ya3AJ+g9mJAOaC0rSkRjTQsXPYVqyIh4kj/lVEFS7buFA8r/ne5 BPC+rxT6VwYJ7UokVZD3PGEPy5h9a017JdVB7q5+f7Va14L5SwZaktry1T8Jghabhc80 S8pyj4J1qoTpZ4dB0gNcCPM1rrYzFSuGBVnVci1OU9U5SCATuVsKK5mg6RVzeGVZtn2F /c+mAQRtjGBTFdJ+FodV334Ry4GcPJ26Vb9sTswGGKBJpWSq2L5A6ixhNwu6BtKX3tFQ G88uxqS2rMU8QXgZ+Y9OGdJYENDJOn1GqzuhoT+5Gk2okOvqv2MT2uL7LsNs+DDq5aHY KJwA== MIME-Version: 1.0 X-Received: by 10.194.189.115 with SMTP id gh19mr3990988wjc.119.1412607700166; Mon, 06 Oct 2014 08:01:40 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 6 Oct 2014 08:01:40 -0700 (PDT) In-Reply-To: <20141006133203.GA1280@pfrc> References: <20141001220545.GA39249@elstar.local> <20141006133203.GA1280@pfrc> Date: Mon, 6 Oct 2014 11:01:40 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7bb70a402cee100504c25cfd Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oyfrNZS-YbWqCzjXzgijBRW2XAE Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Andy Bierman Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:01:43 -0000 --047d7bb70a402cee100504c25cfd Content-Type: text/plain; charset=UTF-8 On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas wrote: > On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote: > > Now - if we have to decide that the CLI always wins, that is one option. > > I, personally, would be quite opposed to the idea that I2RS would always > > win. That does not give recovery mechanisms to the operators when and > > if something goes wrong. > > So, what is your proposal to allow CLI/local config to win over ephemeral > state? If not something comparable to "option 4", what then? > Jeff, It's a good question. I have been sweeping it under "implementation-specific" since it is up to an implementation to decide what collides. If we were talking about vendor-specific CLI vs. YANG models for I2RS, how would it work? At the end of the day, there has to be understanding of what internally is impacted. I can picture different abstractions or subsets being exposed for I2RS rather than CLI or NetConf-for-config. I do go more towards Russ's idea of I2RS as a routing protocol that cooperates with the other routing protocols rather than just another name for a management protocol. Regards, Alia > -- Jeff > --047d7bb70a402cee100504c25cfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 6, 2014 at 9:32 AM, Jeffrey Haas <jhaas@pfrc.org> wrote= :
On Fri, Oct 03, 2014 a= t 05:43:27PM -0400, Alia Atlas wrote:
> Now - if we have to decide that the CLI always wins, that is one optio= n.
> I, personally, would be quite opposed to the idea that I2RS would alwa= ys
> win.=C2=A0 That does not give recovery mechanisms to the operators whe= n and
> if something goes wrong.

So, what is your proposal to allow CLI/local config to win over ephe= meral
state?=C2=A0 If not something comparable to "option 4", what then= ?

Jeff,

It'= ;s a good question.=C2=A0 I have been sweeping it under "implementatio= n-specific"
since it is up to an implementation to decide wh= at collides.=C2=A0 If we were talking about
vendor-specific CLI v= s. YANG models for I2RS, how would it work?=C2=A0 At the end of
t= he day, there has to be understanding of what internally is impacted.
=

I can picture different abstractions or subsets being e= xposed for I2RS rather than
CLI or NetConf-for-config.=C2=A0 I do= go more towards Russ's idea of I2RS as a routing
protocol th= at cooperates with the other routing protocols rather than just another nam= e
for a management protocol.

Regards,
Alia
=C2=A0
-- Jeff

--047d7bb70a402cee100504c25cfd-- From nobody Mon Oct 6 08:32:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1231A6FD9 for ; Mon, 6 Oct 2014 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 Tk_yvC_YCO_r for ; Mon, 6 Oct 2014 08:32:06 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.99]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F2B1A007F for ; Mon, 6 Oct 2014 08:32:06 -0700 (PDT) Received: from [216.82.253.147:28992] by server-3.bemta-7.messagelabs.com id D0/2A-01770-5F5B2345; Mon, 06 Oct 2014 15:32:05 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-13.tower-165.messagelabs.com!1412609525!21536984!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20283 invoked from network); 6 Oct 2014 15:32:05 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-13.tower-165.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Oct 2014 15:32:05 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01.corp.global.level3.com", Issuer "VIDCCERT0001" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id DB0812BE62; Mon, 6 Oct 2014 15:32:04 +0000 (GMT) Received: from USADCWVEHT02.corp.global.level3.com (10.2.36.142) by USIDCWVEHT01.corp.global.level3.com (10.1.142.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Oct 2014 09:32:04 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht02.corp.global.level3.com ([::1]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 11:32:04 -0400 From: "Osborne, Eric" To: Alia Atlas , Jeffrey Haas Thread-Topic: [i2rs] Why do we need a datastore? Thread-Index: AQHP3S++tytt+LzLG0SlM33mV8w1fJwb8Z8AgABASgCAAAOogIADGsWAgAQts4CAABkKAP//n1gA Date: Mon, 6 Oct 2014 15:32:02 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF90490@USIDCWVEMBX08.corp.global.level3.com> References: <20141001220545.GA39249@elstar.local> <20141006133203.GA1280@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.205] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF90490USIDCWVEMBX08corp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/mvoJhFx9Mylsx-PE-7ZlDoHBn1g Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Andy Bierman Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:32:08 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF90490USIDCWVEMBX08corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIHdpdGggRU8jDQoNCkZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMDYsIDIw MTQgMTE6MDIgQU0NClRvOiBKZWZmcmV5IEhhYXMNCkNjOiBpMnJzQGlldGYub3JnOyBKdWVyZ2Vu IFNjaG9lbndhZWxkZXI7IEFuZHkgQmllcm1hbg0KU3ViamVjdDogUmU6IFtpMnJzXSBXaHkgZG8g d2UgbmVlZCBhIGRhdGFzdG9yZT8NCg0KT24gTW9uLCBPY3QgNiwgMjAxNCBhdCA5OjMyIEFNLCBK ZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0BwZnJjLm9yZz4+IHdyb3Rl Og0KT24gRnJpLCBPY3QgMDMsIDIwMTQgYXQgMDU6NDM6MjdQTSAtMDQwMCwgQWxpYSBBdGxhcyB3 cm90ZToNCj4gTm93IC0gaWYgd2UgaGF2ZSB0byBkZWNpZGUgdGhhdCB0aGUgQ0xJIGFsd2F5cyB3 aW5zLCB0aGF0IGlzIG9uZSBvcHRpb24uDQo+IEksIHBlcnNvbmFsbHksIHdvdWxkIGJlIHF1aXRl IG9wcG9zZWQgdG8gdGhlIGlkZWEgdGhhdCBJMlJTIHdvdWxkIGFsd2F5cw0KPiB3aW4uICBUaGF0 IGRvZXMgbm90IGdpdmUgcmVjb3ZlcnkgbWVjaGFuaXNtcyB0byB0aGUgb3BlcmF0b3JzIHdoZW4g YW5kDQo+IGlmIHNvbWV0aGluZyBnb2VzIHdyb25nLg0KDQpTbywgd2hhdCBpcyB5b3VyIHByb3Bv c2FsIHRvIGFsbG93IENMSS9sb2NhbCBjb25maWcgdG8gd2luIG92ZXIgZXBoZW1lcmFsDQpzdGF0 ZT8gIElmIG5vdCBzb21ldGhpbmcgY29tcGFyYWJsZSB0byAib3B0aW9uIDQiLCB3aGF0IHRoZW4/ DQoNCkplZmYsDQoNCkl0J3MgYSBnb29kIHF1ZXN0aW9uLiAgSSBoYXZlIGJlZW4gc3dlZXBpbmcg aXQgdW5kZXIgImltcGxlbWVudGF0aW9uLXNwZWNpZmljIg0Kc2luY2UgaXQgaXMgdXAgdG8gYW4g aW1wbGVtZW50YXRpb24gdG8gZGVjaWRlIHdoYXQgY29sbGlkZXMuICBJZiB3ZSB3ZXJlIHRhbGtp bmcgYWJvdXQNCnZlbmRvci1zcGVjaWZpYyBDTEkgdnMuIFlBTkcgbW9kZWxzIGZvciBJMlJTLCBo b3cgd291bGQgaXQgd29yaz8gIEF0IHRoZSBlbmQgb2YNCnRoZSBkYXksIHRoZXJlIGhhcyB0byBi ZSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgaW50ZXJuYWxseSBpcyBpbXBhY3RlZC4NCg0KDQpFTyMg IElmIHRoZXJlIGlzbuKAmXQgc29tZSBjb21tb25hbGl0eSBvciBzb21lIHdheSB0byBjb250cm9s IHRoaXMgdGhlbiBpdCBiZWNvbWVzIGEgbmlnaHRtYXJlIGZvciBvcGVyYXRvcnMuICBJIGhhdmUg dG8gdGVhY2ggbXkgdG9vbHMgdGhhdCBkaWZmZXJlbnQgcGxhdGZvcm1zIG5lZWQgZGlmZmVyZW50 IGNhcmUgYW5kIGZlZWRpbmcgdXBvbiByZXN0YXJ0LiAgQ2FuIHdlIGF0IGxlYXN0IGhhdmUgc29t ZSAyMTE5LXN0eWxlIE1VU1RzIGZvciBkZWZhdWx0IGFuZCBhIHdlbGwtc3RydWN0dXJlZCBmbGFn IGZvciBhbnkgY29uZmlnIHdoaWNoIGRldmlhdGVzIGZyb20gdGhhdCBkZWZhdWx0Pw0KDQoNCkkg Y2FuIHBpY3R1cmUgZGlmZmVyZW50IGFic3RyYWN0aW9ucyBvciBzdWJzZXRzIGJlaW5nIGV4cG9z ZWQgZm9yIEkyUlMgcmF0aGVyIHRoYW4NCkNMSSBvciBOZXRDb25mLWZvci1jb25maWcuICBJIGRv IGdvIG1vcmUgdG93YXJkcyBSdXNzJ3MgaWRlYSBvZiBJMlJTIGFzIGEgcm91dGluZw0KcHJvdG9j b2wgdGhhdCBjb29wZXJhdGVzIHdpdGggdGhlIG90aGVyIHJvdXRpbmcgcHJvdG9jb2xzIHJhdGhl ciB0aGFuIGp1c3QgYW5vdGhlciBuYW1lDQpmb3IgYSBtYW5hZ2VtZW50IHByb3RvY29sLg0KDQpS ZWdhcmRzLA0KQWxpYQ0KDQotLSBKZWZmDQoNCg== --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF90490USIDCWVEMBX08corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSB3 aXRoIEVPIzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBpMnJz IFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGlh IEF0bGFzPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAwNiwgMjAxNCAxMTowMiBB TTxicj4NCjxiPlRvOjwvYj4gSmVmZnJleSBIYWFzPGJyPg0KPGI+Q2M6PC9iPiBpMnJzQGlldGYu b3JnOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXI7IEFuZHkgQmllcm1hbjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW2kycnNdIFdoeSBkbyB3ZSBuZWVkIGEgZGF0YXN0b3JlPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBPY3QgNiwgMjAx NCBhdCA5OjMyIEFNLCBKZWZmcmV5IEhhYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGFhc0BwZnJj Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBPY3Qg MDMsIDIwMTQgYXQgMDU6NDM6MjdQTSAtMDQwMCwgQWxpYSBBdGxhcyB3cm90ZTo8YnI+DQomZ3Q7 IE5vdyAtIGlmIHdlIGhhdmUgdG8gZGVjaWRlIHRoYXQgdGhlIENMSSBhbHdheXMgd2lucywgdGhh dCBpcyBvbmUgb3B0aW9uLjxicj4NCiZndDsgSSwgcGVyc29uYWxseSwgd291bGQgYmUgcXVpdGUg b3Bwb3NlZCB0byB0aGUgaWRlYSB0aGF0IEkyUlMgd291bGQgYWx3YXlzPGJyPg0KJmd0OyB3aW4u Jm5ic3A7IFRoYXQgZG9lcyBub3QgZ2l2ZSByZWNvdmVyeSBtZWNoYW5pc21zIHRvIHRoZSBvcGVy YXRvcnMgd2hlbiBhbmQ8YnI+DQomZ3Q7IGlmIHNvbWV0aGluZyBnb2VzIHdyb25nLjxicj4NCjxi cj4NClNvLCB3aGF0IGlzIHlvdXIgcHJvcG9zYWwgdG8gYWxsb3cgQ0xJL2xvY2FsIGNvbmZpZyB0 byB3aW4gb3ZlciBlcGhlbWVyYWw8YnI+DQpzdGF0ZT8mbmJzcDsgSWYgbm90IHNvbWV0aGluZyBj b21wYXJhYmxlIHRvICZxdW90O29wdGlvbiA0JnF1b3Q7LCB3aGF0IHRoZW4/PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KZWZmLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdz IGEgZ29vZCBxdWVzdGlvbi4mbmJzcDsgSSBoYXZlIGJlZW4gc3dlZXBpbmcgaXQgdW5kZXIgJnF1 b3Q7aW1wbGVtZW50YXRpb24tc3BlY2lmaWMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNpbmNlIGl0IGlzIHVwIHRvIGFuIGltcGxlbWVu dGF0aW9uIHRvIGRlY2lkZSB3aGF0IGNvbGxpZGVzLiZuYnNwOyBJZiB3ZSB3ZXJlIHRhbGtpbmcg YWJvdXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnZlbmRvci1zcGVjaWZpYyBDTEkgdnMuIFlBTkcgbW9kZWxzIGZvciBJMlJTLCBob3cgd291bGQg aXQgd29yaz8mbmJzcDsgQXQgdGhlIGVuZCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGRheSwgdGhlcmUgaGFzIHRvIGJlIHVuZGVyc3Rh bmRpbmcgb2Ygd2hhdCBpbnRlcm5hbGx5IGlzIGltcGFjdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+RU8jJm5ic3A7IElmIHRoZXJlIGlzbuKAmXQgc29tZSBjb21t b25hbGl0eSBvciBzb21lIHdheSB0byBjb250cm9sIHRoaXMgdGhlbiBpdCBiZWNvbWVzIGEgbmln aHRtYXJlIGZvciBvcGVyYXRvcnMuJm5ic3A7IEkgaGF2ZSB0byB0ZWFjaCBteSB0b29scyB0aGF0 IGRpZmZlcmVudCBwbGF0Zm9ybXMNCiBuZWVkIGRpZmZlcmVudCBjYXJlIGFuZCBmZWVkaW5nIHVw b24gcmVzdGFydC4mbmJzcDsgQ2FuIHdlIGF0IGxlYXN0IGhhdmUgc29tZSAyMTE5LXN0eWxlIE1V U1RzIGZvciBkZWZhdWx0IGFuZCBhIHdlbGwtc3RydWN0dXJlZCBmbGFnIGZvciBhbnkgY29uZmln IHdoaWNoIGRldmlhdGVzIGZyb20gdGhhdCBkZWZhdWx0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIHBpY3R1cmUgZGlmZmVyZW50IGFic3RyYWN0aW9ucyBv ciBzdWJzZXRzIGJlaW5nIGV4cG9zZWQgZm9yIEkyUlMgcmF0aGVyIHRoYW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNMSSBvciBOZXRDb25mLWZv ci1jb25maWcuJm5ic3A7IEkgZG8gZ28gbW9yZSB0b3dhcmRzIFJ1c3MncyBpZGVhIG9mIEkyUlMg YXMgYSByb3V0aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5wcm90b2NvbCB0aGF0IGNvb3BlcmF0ZXMgd2l0aCB0aGUgb3RoZXIgcm91dGluZyBw cm90b2NvbHMgcmF0aGVyIHRoYW4ganVzdCBhbm90aGVyIG5hbWU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciBhIG1hbmFnZW1lbnQgcHJvdG9j b2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbGlhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIEplZmY8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF90490USIDCWVEMBX08corp_-- From nobody Mon Oct 6 08:36:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7A71A02ED for ; Mon, 6 Oct 2014 08:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 V_YsIBjnvU-e for ; Mon, 6 Oct 2014 08:36:06 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F1E1A02DF for ; Mon, 6 Oct 2014 08:36:05 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id x13so4132485qcv.32 for ; Mon, 06 Oct 2014 08:36:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=odJ9E5tmVLNS9WytaC9Tq/bFYNOhNO++m9DP5Xsmu50=; b=mOzILMVg3NNJWApNjE+W20sdx4kT0qx0232/lK849cVrGH2FHY14SWXLHEzxKnmJrW Rh342AmuCbnw8WdWrrHp3kaiSFkMo25R4qHtzCE1TrkqSYwCrUwHurOYk1WyEDpzp8zO ghvgpyy98uh19W0RpXzJIjCZlcMrSOG7wFy0MaHcnhTYxVoxzWQjWx13bo0B3j9fRX4x pZnZd8+V7MAMEkmwFvuX0JJdID+pZQznL8+x7OXRvsW2Xo0jJvZhlKLB0CjT7Otlhhg2 vWWdAZ4kJp355LE5HGghmV4pD0CCuOyWYj81q57YHUrA60Hbp5ADOEVwNdcW1PF4gXJR PhXg== X-Gm-Message-State: ALoCoQk5WrpnEa0JVr7sxVpps3ik4Niq+L7DLNVywbL5ORoVqgFQyNMXdvTgC/o7Ot307Qc/csLO MIME-Version: 1.0 X-Received: by 10.140.102.235 with SMTP id w98mr28661072qge.35.1412609764838; Mon, 06 Oct 2014 08:36:04 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 6 Oct 2014 08:36:04 -0700 (PDT) In-Reply-To: References: <20141001220545.GA39249@elstar.local> <20141006133203.GA1280@pfrc> Date: Mon, 6 Oct 2014 08:36:04 -0700 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c1664c3d9ef10504c2d797 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4nulvYtxfAB-4yIikHoUWS3FRKk Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:36:07 -0000 --001a11c1664c3d9ef10504c2d797 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 6, 2014 at 8:01 AM, Alia Atlas wrote: > On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas wrote: > >> On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote: >> > Now - if we have to decide that the CLI always wins, that is one option. >> > I, personally, would be quite opposed to the idea that I2RS would always >> > win. That does not give recovery mechanisms to the operators when and >> > if something goes wrong. >> >> So, what is your proposal to allow CLI/local config to win over ephemeral >> state? If not something comparable to "option 4", what then? >> > > Jeff, > > It's a good question. I have been sweeping it under > "implementation-specific" > since it is up to an implementation to decide what collides. If we were > talking about > vendor-specific CLI vs. YANG models for I2RS, how would it work? At the > end of > the day, there has to be understanding of what internally is impacted. > > If an I2RS client needs to monitor system state, local config changes, and also know the proprietary CLI in order to function, it will be too complicated to implement. If the CLI or local config has disabled I2RS for some or all clients, then the requests will get rejected by the agent. Proprietary data models and CLI should be out of scope. I can picture different abstractions or subsets being exposed for I2RS > rather than > CLI or NetConf-for-config. I do go more towards Russ's idea of I2RS as a > routing > protocol that cooperates with the other routing protocols rather than just > another name > for a management protocol. > I was surprised at the interim that every config=true schema node could apply to running config or ephemeral data, and it is always an operator decision as to which instances go in which datastore. This seems like a vendor decision first. I also figured I2RS would ignore local config and just attempt to inject routing state. It is up to the agent to resolve local config with ephemeral config to produce operational state. I can see local CLI disabling I2RS, but not competing with it to insert data, so I don't understand the "CLI wins over I2RS" use-case. > Regards, > Alia > > >> -- Jeff >> > > Andy --001a11c1664c3d9ef10504c2d797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 6, 2014 at 8:01 AM, Alia Atlas <akatlas@gmail.com><= /span> wrote:
On Mon, Oct 6, 2014 at 9:32 AM,= Jeffrey Haas <jhaas@pfrc.org> wrote:
On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote:<= br> > Now - if we have to decide that the CLI always wins, that is one optio= n.
> I, personally, would be quite opposed to the idea that I2RS would alwa= ys
> win.=A0 That does not give recovery mechanisms to the operators when a= nd
> if something goes wrong.

So, what is your proposal to allow CLI/local config to win over ephe= meral
state?=A0 If not something comparable to "option 4", what then?

Jeff,

It's = a good question.=A0 I have been sweeping it under "implementation-spec= ific"
since it is up to an implementation to decide what col= lides.=A0 If we were talking about
vendor-specific CLI vs. YANG m= odels for I2RS, how would it work?=A0 At the end of
the day, ther= e has to be understanding of what internally is impacted.


If an I2RS client nee= ds to monitor system state, local config changes,
and also know t= he proprietary CLI in order to function, it will be too complicated
to implement. If the CLI or local config has disabled I2RS for some or a= ll clients,
then the requests will get rejected by the agent. Pro= prietary data models and
CLI should be out of scope.

I can pic= ture different abstractions or subsets being exposed for I2RS rather than
CLI or NetConf-for-config.=A0 I do go more towards Russ's idea= of I2RS as a routing
protocol that cooperates with the other rou= ting protocols rather than just another name
for a management pro= tocol.

I was surpri= sed at the interim that every config=3Dtrue schema node could apply
to running config or ephemeral data, and it is always an operator decisi= on as to
which instances go in which datastore.=A0 This seems lik= e a vendor decision first.

I also figured I2RS wou= ld ignore local config and just attempt to inject routing state.
= It is up to the agent to resolve local config with ephemeral config to prod= uce
operational state.=A0 I can see local CLI disabling I2RS, but= not competing with
it to insert data, so I don't understand = the "CLI wins over I2RS" use-case.


Regards,
Alia
=A0<= /div>
-- Jeff


Andy

--001a11c1664c3d9ef10504c2d797-- From nobody Mon Oct 6 09:55:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9436D1A86E2 for ; Mon, 6 Oct 2014 09:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 dpyuE80cLwe0 for ; Mon, 6 Oct 2014 09:55:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C70181A0350 for ; Mon, 6 Oct 2014 09:55:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B1B0C200; Mon, 6 Oct 2014 12:55:56 -0400 (EDT) Date: Mon, 6 Oct 2014 12:55:56 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20141006165556.GB2962@pfrc> References: <20141001220545.GA39249@elstar.local> <20141006133203.GA1280@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/I7H88sTSv6nIYaZPbx_ISmrsLdA Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , Alia Atlas Subject: Re: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:55:57 -0000 On Mon, Oct 06, 2014 at 08:36:04AM -0700, Andy Bierman wrote: > I was surprised at the interim that every config=true schema node could > apply to running config or ephemeral data, and it is always an operator > decision as to which instances go in which datastore. This seems like a > vendor decision first. As I keep mentioning, fully disjoint data models from local config are likely. That case is easy. Models that augment or use information in local/running config have been proposed and defining their semantics are where we spent a lot of time. If the WG can't manage to converge on the details of such interaction, it may be simpler to say we're going to refuse to solve it and simple declare such interactions out of scope. This would leave us with *only* disjoint models, although with the possibility of using elements from config models, e.g. groupings. -- Jeff From nobody Mon Oct 6 15:19:32 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484851A8AB6; Mon, 6 Oct 2014 15:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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, SPF_PASS=-0.001] autolearn=ham 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 zRXaCB5fpe6S; Mon, 6 Oct 2014 15:19:29 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A4C1A8913; Mon, 6 Oct 2014 15:19:29 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 131so2347320ykp.41 for ; Mon, 06 Oct 2014 15:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=1fPiCtUO5Bu1eDzi8oncCocfnYFwXKjBjZT9JwNBsg4=; b=EKIEMRO2azqh11/TpJWPpvXOG5A4WuqaYpU0gbowzuWeFQgeP5zyMBXLm4gqFz0nQZ +RjMxzurQWnjHS0lnpcZN82lg24wPK2JNIcyO3SJMpedM4ZpCPDi7lJwipXUTbm44iMT NZVYSzArFnDr5elTVWsOTZZO+ZgT/0N4iDgQI74p3uIQ3qrH7IBRz+HDzUJFQeQTEt2o DtHFkY5WGkDjhnUPcFoZBHfaH+pJw8boNOhzCcvZf+H8KBX+/OBVURqeyjPyEST73mXb UIUSuP0u1iK47OI4/YjL2eWCXS61/zMw6iHMMMKP+JaJ5QrbZpZ78BB7byozWm/9jCo1 aKCw== MIME-Version: 1.0 X-Received: by 10.236.87.227 with SMTP id y63mr28746561yhe.25.1412633968630; Mon, 06 Oct 2014 15:19:28 -0700 (PDT) Received: by 10.170.113.134 with HTTP; Mon, 6 Oct 2014 15:19:28 -0700 (PDT) Date: Mon, 6 Oct 2014 18:19:28 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" , "netmod@ietf.org" , "rtgwg@ietf.org" , "isis-wg@ietf.org" , OSPF List , "idr@ietf. org" , "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary=20cf3010eabde5e0fb0504c879ae Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/x6WZmPo7nHFPTLgxElgDIFN7wTU Cc: Benoit Claise , Adrian Farrel Subject: [i2rs] Creation of rtg-yang-coord mailing list X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:19:31 -0000 --20cf3010eabde5e0fb0504c879ae Content-Type: text/plain; charset=UTF-8 The rtg-yang-coord mailing list will provide a forum for coordination of the development of YANG models being worked on for Routing, in order to provide a consistent view to the NMS. The intended participants are people active in Routing working groups and interested in the associated YANG models, and YANG experts assisting with Routing YANG models. While this list will help with the synchronization, WGs with responsibility for core routing protocols are expected to also be responsible for the development of YANG models for those protocols. To subscribe, visit: https://www.ietf.org/mailman/listinfo/rtg-yang-coord Regards, Alia --20cf3010eabde5e0fb0504c879ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The rtg-yang-coord mailing list will provide a f= orum for coordination of the development=C2=A0=C2=A0of YANG models being wo= rked on for Routing, in order to provide a=C2=A0consistent view to the NMS.= =C2=A0 The intended participants are people active in Routing working group= s and interested in the=C2=A0associated YANG models, and YANG experts assis= ting with Routing YANG=C2=A0models. While this list=C2=A0will help with the= synchronization, WGs with responsibility for core=C2=A0routing protocols a= re expected=C2=A0=C2=A0to also be responsible for the development of YANG m= odels for those=C2=A0=C2=A0protocols.=C2=A0

To subscribe, visi= t:

= https://ww= w.ietf.org/mailman/listinfo/rtg-yang-coord

Regar= ds,

Alia

--20cf3010eabde5e0fb0504c879ae-- From nobody Fri Oct 24 09:12:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D111A1BC2 for ; Fri, 24 Oct 2014 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=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 DNNtQezliduY for ; Fri, 24 Oct 2014 09:11:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 885571A0271 for ; Fri, 24 Oct 2014 09:11:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: Date: Fri, 24 Oct 2014 12:11:50 -0400 Message-ID: <04fa01cfefa5$398ba890$aca2f9b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04FB_01CFEF83.B27AF2F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac/vpQ0e5G37M1UQT6W4fKmoX+XlGQ== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lCaAbLD7fhcw3wFAYpNruiW-a9M Cc: 'Jeffrey Haas' , edc.ietf@gmail.com Subject: [i2rs] draft-hares-i2rs-bgp-compare-yang - comparison of two BGP yang modules X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:11:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04FB_01CFEF83.B27AF2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A Draft comparing the following two yang modules https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/ (config) https://datatracker.ietf.org/doc/draft-wang-i2rs-bgp-dm/ (i2rs state-focused) is at: https://datatracker.ietf.org/doc/draft-hares-i2rs-bgp-compare-yang/ The draft compares the two yang modules against each other, and against the I2rs bgp use case requirements. A summary of draft is: zdhankin draft (98% config, 2% status), wang (98% status, 2% config). Need wang draft to fulfill i2 bpg use case requirements. I'm looking for feedback on the comparison. Sue ------=_NextPart_000_04FB_01CFEF83.B27AF2F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

A Draft = comparing the following two yang modules  

 

= https://datatracker.ietf.org/doc/draft-zhdankin-netmod-bgp-cfg/ = (config)

 

https:/= /datatracker.ietf.org/doc/draft-wang-i2rs-bgp-dm/  (i2rs = state-focused)

 

is at: =

 

https://datatracker.ietf.org/doc/draft-hares-i2rs-bgp-compare-yang/

 

The draft compares the two yang modules against each = other, and against the I2rs bgp use case requirements.

 

A summary of = draft is: zdhankin draft (98% config, 2% status), wang (98% status, 2% = config).   Need wang draft to fulfill i2 bpg use case = requirements.  I’m looking for feedback on the comparison. =  

 

Sue

 

------=_NextPart_000_04FB_01CFEF83.B27AF2F0-- From nobody Fri Oct 24 12:25:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FF31A1A38 for ; Fri, 24 Oct 2014 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 T4n3bp3f1UKj for ; Fri, 24 Oct 2014 12:25:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5D99B1A19F1 for ; Fri, 24 Oct 2014 12:25:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 101A5C2A0; Fri, 24 Oct 2014 15:25:54 -0400 (EDT) Date: Fri, 24 Oct 2014 15:25:53 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20141024192553.GX30433@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_XSx3VH3J_z8ajuLoMwrCWKwVqM Subject: [i2rs] Document status on Architecture and Problem Statement X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 19:25:56 -0000 Working Group, Your chairs have been having an extraordinarily busy last few weeks and haven't been able to take the time to actively push on work. Please take the opportunity to drive some of it yourself. :-) Especially what to do about ephemeral state. As soon as I can arrange to do the shepherd writeup, we will be submitting the Architecture document and Problem Statement to the IESG. Both had passed WGLC. -- Jeff & Ed