From nobody Thu May 1 05:47: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 844BC1A076C for ; Thu, 1 May 2014 03:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 8HaK58AhuPBq for ; Thu, 1 May 2014 03:04:35 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3332E1A076B for ; Thu, 1 May 2014 03:04:34 -0700 (PDT) Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 10:04:31 +0000 Message-ID: <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> Date: Thu, 1 May 2014 10:01:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA0030.eurprd07.prod.outlook.com (10.141.45.158) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Forefront-PRVS: 01986AE76B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(13464003)(51704005)(24454002)(44716002)(92566001)(62236002)(92726001)(86362001)(79102001)(93916002)(20776003)(47776003)(50226001)(44736004)(74502001)(50466002)(31966008)(74662001)(84392001)(19580395003)(83322001)(19580405001)(88136002)(87286001)(87976001)(80976001)(81816999)(89996001)(81686999)(50986999)(76176999)(85852003)(83072002)(101416001)(99396002)(77156001)(61296002)(66066001)(23756003)(46102001)(33646001)(14496001)(62966002)(4396001)(77982001)(76482001)(81342001)(42186004)(81542001)(80022001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0111HT004.eurprd01.prod.exchangelabs.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ox8bPZ03nWcdjfcpMNQvdpI3afQ Cc: i2rs@ietf.org Subject: Re: [i2rs] Operational State 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, 01 May 2014 10:04:37 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: "t.petch" Cc: Sent: Thursday, May 01, 2014 1:34 AM > On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote: > > This tri-partite split has been the norm for Ops Area for many years > > now. > > It may or may not be appropriate for I2RS but I do think that I2RS > > should > > at least take cognizance of this in deciding what terms to use > > I think this is one of the clearest description of one of our problems - and > thus requirements - that I've seen thus far. :-) Yeah, problems are my speciality - I then look to Andy, Juergen, Lada and Martin for solutions:-) But, Jeff, you then say, in a parallel post "The issues then comes back to the ones noted in draft-bjorklund-netmod-operational-00: How do we distinguish operational, config or ephemeral config states? " whereas I see operational state, config and read-only statistics, with state (unqualified) referring to the first and last collectively! 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - I don't see it as a concept in YANG/NETCONF. There is a separate issue of persistent and ephemeral in YANG, or, arguably, in NETCONF, which is also not documented AFAICS. This is probably of less interest to I2RS at this time. If there is one running datastore, then, presumably, it is persistent (across reboots) - the documents appear not to say. If there is running and startup, presumably startup is persistent and running is not. But if you have running and acme-special datastores, then which is persistent? This is one of several issues, like operational state, that have surfaced from time to time and, for me, have not got nailed down as well as I would like, and so - surface from time to time. Tom Petch > -- Jeff From nobody Thu May 1 05:47: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 0D0A61A076B for ; Thu, 1 May 2014 03:04: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 sdqeVrXxlt5t for ; Thu, 1 May 2014 03:04:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id D71F61A0770 for ; Thu, 1 May 2014 03:04:35 -0700 (PDT) Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 10:04:32 +0000 Message-ID: <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> Date: Thu, 1 May 2014 10:17:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA0030.eurprd07.prod.outlook.com (10.141.45.158) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Forefront-PRVS: 01986AE76B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(13464003)(51704005)(24454002)(44716002)(92566001)(62236002)(92726001)(86362001)(79102001)(93916002)(20776003)(47776003)(50226001)(44736004)(74502001)(50466002)(31966008)(74662001)(84392001)(19580395003)(15975445006)(83322001)(19580405001)(88136002)(87286001)(87976001)(80976001)(81816999)(89996001)(81686999)(50986999)(76176999)(85852003)(83072002)(101416001)(99396002)(77156001)(61296002)(66066001)(23756003)(46102001)(33646001)(14496001)(62966002)(4396001)(77982001)(15202345003)(76482001)(81342001)(42186004)(81542001)(80022001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0111HT004.eurprd01.prod.exchangelabs.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PTahXPYo_OuEIO4A3MmN6Pi97mQ Cc: i2rs@ietf.org, edc@google.com Subject: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model 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, 01 May 2014 10:04:39 -0000 Going in a slightly different direction with a change subject line. Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: "Martin Bjorklund" Cc: ; ; Sent: Thursday, May 01, 2014 1:24 AM > On Thu, Apr 24, 2014 at 01:12:44PM +0200, Martin Bjorklund wrote: > > > http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt > > > > > > Figure 1 and Figure 2 show. What YANG does not have is a way of > > > correlating the two trees > > > > See also Lada's reply. > > > > What kind of correlation are you looking for? The point is that these > > are *different* structures, with different semantics. If an entry > > exists in the operational state, it doesn't imply there is a > > corresponding entry in the config, and vice versa. And just b/c a > > config entry also exists in operational state doesn't mean that it is > > *exactly* as configured; some other dynamic mechanism might have > > changed it. It all depends on what you model. > > As I try to work through my reading of netconf and yang, the use case we're > discussing here is the one that troubles me the most. Let me pick two > specific examples of injecting i2rs state on top of something that may have > coverage within existing yang configuration models: static routes and BGP. Jeff If I2RS updates the routing table, do we expect it to persist for any length of time? That is, the routing table is stable, the result of the convergence of the routing protocols (and configuration) across the relevant routers in the routing system and is reflected in the operational state of a router. A stable system in engineering is one that when perturbs, returns to its original state. So make a change in one router and I would expect the rest of the system to gang up on that router and reinstate the status quo. For example, what I have in Adj-RIB-Out comes from someone else via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I will refresh it from Adj-RIB-In and be back where I started, while if I change Adj-RIB-In, then the other router will repeat its advertisement - and I will be back where I started. If I think of the changes I might want to make, it seems to me that they have to be changes to what NETCONF/YANG refer to as config and not to the operational state. Ephemeral or persistent, which I take to refer to what happens after a reboot, is then a question of which NETCONF datastore I update, running or startup or both. Tom Petch > > It would be very convenient for purposes of configuring static routes in > i2rs where the semantic is ephemeral configuration to not have to duplicate > the existing yang model. If the model in question was design to use > groupings, it appears that it would be easy to have one instance for normal > configuration and a second one specifically for i2rs. It would be even more > convenient if we had a semantic that was not only "config true", but > potentially "config true|ephemeral". > > The issues then comes back to the ones noted in > draft-bjorklund-netmod-operational-00: How do we distinguish operational, > config or ephemeral config states? When there are different precedences > (ephemeral overrides static, e.g.), how could you do a get that presents the > implemented order? > > The BGP example to my mind may only go slightly further than this. For > some types of i2rs configuration state, I can foresee wanting some portion > of it to be based upon non-ephemeral configuration - for example base BGP > state that should not be modified by i2rs. Presuming that base state > exists, it may be desirable to permit something like BGP peer configuration > to re-use the existing BGP yang model for configuration, just in an > ephemeral context. Thus, some portions of the configuration are > instantiated ephemerally and some require underlying non-i2rs config. > > > I don't think a separate structure for i2rs routes are needed, b/c it > > is supposed to directly modify the operational state. > > This is where I think we're getting stuck. There is some vagueness between > operational state that can be modified and ephemeral configuration. But the > real issue is when multiple forms exist, how do we operate upon it/see it in > a useful fashion? > > -- Jeff From nobody Thu May 1 07:14: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 E16E01A08DA for ; Thu, 1 May 2014 07:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 QyTigZyZgCc5 for ; Thu, 1 May 2014 07:14:37 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by ietfa.amsl.com (Postfix) with ESMTP id 58EC21A08D4 for ; Thu, 1 May 2014 07:14:37 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so3392398qga.11 for ; Thu, 01 May 2014 07:14:35 -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=G479plhFla3tMyGsOxqL05jqG4kEFrnkFdkoKG6gRNk=; b=NIvih4CSGrxiGcrXFZfffe8rJEyeQ6vtIeK/hlOrNRzmPmFC3pjSMYt6dIVaqIbTWm xB6q+Bk38byLecCAEiPlSSsSIerQ7xIRQjgiocO0e9PJeJ4ybQDFUduXExWAzfN2ztkO 04KDBt1ceKHtRHca4nMfZpFQ0JkOJvU9ZZp1gbrArZgZEZpgtSaWvlDW/l3oapUgEbNF r2w40M2dp5WIrz+vt/dzvWUh1IurUdhBX4CRNpMQ3HmfkU/ChDFjUVmlHzkw689WJe5x OBTSB3FN6zYw/B1Q5/ko22/4sQKD+MYuX0ufHBJ1nhMnv6+pONYxKZy/Wlf8ba6s7yc+ xP3g== X-Gm-Message-State: ALoCoQl8kjeZbhDoEgFhuQWtD16w6iKsGNfNLdGo6umVEcULVhFbpbbUiwF58t2a1PhfDCgmDVXF MIME-Version: 1.0 X-Received: by 10.140.36.86 with SMTP id o80mr12998037qgo.25.1398953675165; Thu, 01 May 2014 07:14:35 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 07:14:35 -0700 (PDT) In-Reply-To: <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> Date: Thu, 1 May 2014 07:14:35 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c16c1eddadc604f857484e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/VVp-vYMZuaNFgypljS4SZ954lq4 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Operational State 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, 01 May 2014 14:14:39 -0000 --001a11c16c1eddadc604f857484e Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 2:01 AM, t.petch wrote: > ----- Original Message ----- > From: "Jeffrey Haas" > To: "t.petch" > Cc: > Sent: Thursday, May 01, 2014 1:34 AM > > On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote: > > > This tri-partite split has been the norm for Ops Area for many years > > > now. > > > It may or may not be appropriate for I2RS but I do think that I2RS > > > should > > > at least take cognizance of this in deciding what terms to use > > > > I think this is one of the clearest description of one of our > problems - and > > thus requirements - that I've seen thus far. :-) > > Yeah, problems are my speciality - I then look to Andy, Juergen, Lada > and Martin for solutions:-) > > But, Jeff, you then say, in a parallel post > > "The issues then comes back to the ones noted in > draft-bjorklund-netmod-operational-00: How do we distinguish > operational, > config or ephemeral config states? " > > whereas I see operational state, config and read-only statistics, with > state (unqualified) referring to the first and last collectively! > 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - > I don't see it as a concept in YANG/NETCONF. > > There is a separate issue of persistent and ephemeral in YANG, or, > arguably, in NETCONF, which is also not documented AFAICS. This is > probably of less interest to I2RS at this time. > > N/Y treats config=true data nodes as special. Collectively these data nodes form a configuration datastore. This is only important for validation purposes -- determining what is a "valid" running configuration. If there is one running datastore, then, presumably, it is persistent > (across reboots) - the documents appear not to say. If there is running > and startup, presumably startup is persistent and running is not. But > if you have running and acme-special datastores, then which is > persistent? This is one of several issues, like operational state, that > have surfaced from time to time and, for me, have not got nailed down as > well as I would like, and so - surface from time to time. > > There is no "acme-special" sort of datastore. There are only the standard datastores. If the server supports the "startup" datastore, then all configuration changes are saved manually to NV-storage. If the client does not save changes, they are lost at the next reboot. If the server does not support the "startup" datastore then the NV-storage must mirror the running configuration. All config changes are saved automatically and immediately. Operational state is different than config because only config is validated according the the YANG constraints. The operational datastore may need some validation (e.g. field syntax check) but it is not in anyway considered when validating the running datastore. IMO the difference between ephemeral config and operational state is not the NV-storage, but the validation procedure that accepts or rejects the write request. Tom Petch > > > -- Jeff > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c16c1eddadc604f857484e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 2:01 AM, t.petch <ietfc@btconnect.com= > wrote:
----- Original Message -----
From: "Jeffrey Haas" <jhaas@= pfrc.org>
To: "t.petch" <ietfc@bt= connect.com>
Cc: <i2rs@ietf.org>
Sent: Thursday, May 01, 2014 1:34 AM
> On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote:
> > This tri-partite split has been the norm for Ops Area for many ye= ars
> > now.
> > It may or may not be appropriate for I2RS but I do think that I2R= S
> > should
> > at least take cognizance of this in deciding what terms to use >
> I think this is one of the clearest description of one of our
problems - and
> thus requirements - that I've seen thus far. :-)

Yeah, problems are my speciality - I then look to Andy, Juergen, Lada
and Martin for solutions:-)

But, Jeff, you then say, in a parallel post

"The issues then comes back to the ones noted in
draft-bjorklund-netmod-operational-00: How do we distinguish
operational,
config or ephemeral config states? "

whereas I see operational state, config and read-only statistics, with
state (unqualified) referring to the first and last collectively!
'ephemeral' does not appear in Martin's I-D, nor would I expect= it to -
I don't see it as a concept in YANG/NETCONF.

There is a separate issue of persistent and ephemeral in YANG, or,
arguably, in NETCONF, which is also not documented AFAICS. =A0This is
probably of less interest to I2RS at this time.


N/Y treats config=3Dtrue data nodes as= special.
Collectively these data nodes form a configuration data= store.
This is only important for validation purposes -- determin= ing
what is a "valid" running configuration.


If there is one running datastore, then, presumably, it is persistent
(across reboots) - the documents appear not to say. =A0If there is running<= br> and startup, presumably startup is persistent and running is not. =A0But if you have running and acme-special datastores, then which is
persistent? =A0This is one of several issues, like operational state, that<= br> have surfaced from time to time and, for me, have not got nailed down as well as I would like, and so - surface from time to time.



There is no "acme-= special" sort of datastore.
There are only the standard data= stores.

If the server supports the "startup&q= uot; datastore, then
all configuration changes are saved manually to NV-storage.
= If the client does not save changes, they are lost at the next reboot.

If the server does not support the "startup"= datastore then
the NV-storage must mirror the running configuration. All
co= nfig changes are saved automatically and immediately.

<= div>Operational state is different than config because only config
is validated according the the YANG constraints. =A0The operational
datastore may need some validation (e.g. field syntax check)
<= div>but it is not in anyway considered when validating the running datastor= e.

IMO the difference between ephemeral config and operati= onal state
is not the NV-storage, but the validation procedure th= at accepts or rejects
the write request.


Tom Petch

> -- Jeff


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

--001a11c16c1eddadc604f857484e-- From nobody Thu May 1 07:46:19 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 22F031A08D0 for ; Thu, 1 May 2014 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, 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 FznXq7B9IOE7 for ; Thu, 1 May 2014 07:46:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 779F41A084B for ; Thu, 1 May 2014 07:46:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 796B0C2E0; Thu, 1 May 2014 10:46:14 -0400 (EDT) Date: Thu, 1 May 2014 10:46:14 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20140501144614.GC1705@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/zBPiuVlDo5VWbcYiRqKF871NXYE Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Operational State 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, 01 May 2014 14:46:17 -0000 Tom, On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote: > But, Jeff, you then say, in a parallel post > > "The issues then comes back to the ones noted in > draft-bjorklund-netmod-operational-00: How do we distinguish > operational, > config or ephemeral config states? " > > whereas I see operational state, config and read-only statistics, with > state (unqualified) referring to the first and last collectively! > 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - > I don't see it as a concept in YANG/NETCONF. I agree it is not currently part of Netconf/Yang. This is part of why I raise the question. > There is a separate issue of persistent and ephemeral in YANG, or, > arguably, in NETCONF, which is also not documented AFAICS. This is > probably of less interest to I2RS at this time. I actually think it's one of our bigger sticking points - or at least something we need a clear answer on if N/Y is to be considered for i2rs use. I2RS state is intended to be ephemeral. (See architecture document.) > If there is one running datastore, then, presumably, it is persistent > (across reboots) - the documents appear not to say. If there is running > and startup, presumably startup is persistent and running is not. But > if you have running and acme-special datastores, then which is > persistent? This is one of several issues, like operational state, that > have surfaced from time to time and, for me, have not got nailed down as > well as I would like, and so - surface from time to time. This covers my point. Moving this particular bit of discussion to Juergen's response to me in another thread. -- Jeff From nobody Thu May 1 07:57: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 4716B1A6F6F for ; Thu, 1 May 2014 07:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 sJL1CGqGfOp9 for ; Thu, 1 May 2014 07:57:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2981E1A6F1E for ; Thu, 1 May 2014 07:57:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5FD3BC2E0; Thu, 1 May 2014 10:57:48 -0400 (EDT) Date: Thu, 1 May 2014 10:57:48 -0400 From: Jeffrey Haas To: Jeffrey Haas , Martin Bjorklund , i2rs@ietf.org, edc@google.com, ietfc@btconnect.com Message-ID: <20140501145748.GD1705@pfrc> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <20140501053839.GA33275@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140501053839.GA33275@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ynPh4EdVNF6JcTW2JfFcDxM1oEU Subject: Re: [i2rs] consensus on I2RS protocol and model 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, 01 May 2014 14:57:51 -0000 On Thu, May 01, 2014 at 07:38:39AM +0200, Juergen Schoenwaelder wrote: > On Wed, Apr 30, 2014 at 08:24:51PM -0400, Jeffrey Haas wrote: > > > > This is where I think we're getting stuck. There is some vagueness between > > operational state that can be modified and ephemeral configuration. > > Are you saying there is a difference between 'writable operational > state' and 'ephemeral configuration' but the difference is still > unclear and hence vague? Yes and no. I'm still absorbing appropriate terminology from the N/Y RFCs so please have patience with me. State that I2RS injects into a system may be intended to be ephemeral. That state may overlap with state that is otherwise configured in the usual configuration based datastore. E.g. static routes. It is clearly possible to generate yang for I2RS that duplicates as much of the yang for that configured state (e.g. static routes). Yang provides mechanisms to allow for re-use of the yang inputs (e.g. grouping) in another module, provided that the original module was authored to enable re-use. My observation is that in cases where there may be significant overlap of I2RS injected ephemeral state, e.g. static routes, that it might be desirable to not have to have a separate I2RS yang module unless there are differences that necessitate a new module. Effective, if I have my terminology correct, to permit more than one datastore to be manipulated using the same module. I.e. "running configuration" and "I2RS ephemeral". If such a thing were possible, then it would only compound the issues noted in draft-bjorklund-netmod-operational since the configuration state for the overlapping datastores also had related potentialy overlap in the operational state. To offer an older analogy for comparison, if I can configure static routes via CLI and simultaneously by SNMP and both configurations can serve as inputs to the RIB, the installed static route may come from either of the candidates and the active entry will be selected by a preference. In such a scenario, I still need to be able to see my configuration for the CLI route and the SNMP installed route along with the actual route installed in the RIB as active. -- Jeff From nobody Thu May 1 08:02:21 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 09D551A08E9 for ; Thu, 1 May 2014 08:02:21 -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_15=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 Eezx-skySjL5 for ; Thu, 1 May 2014 08:02:20 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id D09DD1A08E1 for ; Thu, 1 May 2014 08:02:19 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j5so508707qaq.1 for ; Thu, 01 May 2014 08:02:17 -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=1OQ1BwSlLm4sMCOSJrcAu9TVttY1/iAasinABcod/tM=; b=DErEbo04VRcmPJiR8BQGdT/IhPoP5s6MnG1ygWRy7Ahe6tanaFurKEI3zQMacqB5ky Ei1jyTMLyvgHdjqVwgveO/Twqr6hvGTT9sy6hq60PBT4pLFapZL7z/sSqwci29QrLADy vkeVUOzBjy/90pn8ALTn4VZiZcl34meh/9fmltetU7dBGRwF/ABZq876k0BCswuyUSCp 7uiZQhCqGQVv7goxT6XyWHKVpa61KcR/lEcuQ2iNuXaQZEikKrlZb5qJ/IOWHPCdWzv0 R4Msd/6FRD9Mk/Ea7DrKN5XN5xlsYPtrBcgi1FfnnjSXiUZtWPucowbp7JoZP221JRNf yPSQ== X-Gm-Message-State: ALoCoQk0pjItRYgaXkzVTG8ZG20rW2vTmwtZXyCI+pTfWU6WS6AARiGoRPjdhyN3yXBS+158pmgk MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr13411495qge.34.1398956537540; Thu, 01 May 2014 08:02:17 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 08:02:17 -0700 (PDT) In-Reply-To: <20140501144614.GC1705@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> Date: Thu, 1 May 2014 08:02:17 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a113abfd87aafe904f857f368 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ky7ohU6Ji7kKxeS_Hp9C4yI4ALA Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 15:02:21 -0000 --001a113abfd87aafe904f857f368 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas wrote: > Tom, > > On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote: > > But, Jeff, you then say, in a parallel post > > > > "The issues then comes back to the ones noted in > > draft-bjorklund-netmod-operational-00: How do we distinguish > > operational, > > config or ephemeral config states? " > > > > whereas I see operational state, config and read-only statistics, with > > state (unqualified) referring to the first and last collectively! > > 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - > > I don't see it as a concept in YANG/NETCONF. > > I agree it is not currently part of Netconf/Yang. This is part of why I > raise the question. > > > There is a separate issue of persistent and ephemeral in YANG, or, > > arguably, in NETCONF, which is also not documented AFAICS. This is > > probably of less interest to I2RS at this time. > > I actually think it's one of our bigger sticking points - or at least > something we need a clear answer on if N/Y is to be considered for i2rs > use. > I2RS state is intended to be ephemeral. (See architecture document.) > > I think this has been explained several times already, starting in the IETF 89 slides. I don't think anybody has said NC/RC/YANG could be used as the I2RS protocol without a single change. People has said it is the best starting point for I2RS. There seemed to be an overwhelming consensus in the London meeting and on this mailing list to use NC or RC + YANG as the I2RS starting point. IMO, there needs to be a new datastore in the architecture that contains I2RS data. The I2RS protocol will define how this data is accessed. It's really not that complicated. There are many implementations using NC/RC + YANG, and many of these vendors have stated that they believe this approach can be made to work for I2RS. > If there is one running datastore, then, presumably, it is persistent > > (across reboots) - the documents appear not to say. If there is running > > and startup, presumably startup is persistent and running is not. But > > if you have running and acme-special datastores, then which is > > persistent? This is one of several issues, like operational state, that > > have surfaced from time to time and, for me, have not got nailed down as > > well as I would like, and so - surface from time to time. > > I2RS does not have any interaction with the "local config" except maybe to read it. The NETCONF configuration datastores (candidate, running, startup) are not going to be used by I2RS. Nothing I2RS does is going to even slightly alter the definition of any NETCONF configuration procedures. This covers my point. Moving this particular bit of discussion to Juergen's > response to me in another thread. > > -- Jeff > Andy --001a113abfd87aafe904f857f368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
Tom,

On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote:
> But, Jeff, you then say, in a parallel post
>
> "The issues then comes back to the ones noted in
> draft-bjorklund-netmod-operational-00: How do we distinguish
> operational,
> config or ephemeral config states? "
>
> whereas I see operational state, config and read-only statistics, with=
> state (unqualified) referring to the first and last collectively!
> 'ephemeral' does not appear in Martin's I-D, nor would I e= xpect it to -
> I don't see it as a concept in YANG/NETCONF.

I agree it is not currently part of Netconf/Yang. =A0This is part of why I<= br> raise the question.

> There is a separate issue of persistent and ephemeral in YANG, or,
> arguably, in NETCONF, which is also not documented AFAICS. =A0This is<= br> > probably of less interest to I2RS at this time.

I actually think it's one of our bigger sticking points - or at least something we need a clear answer on if N/Y is to be considered for i2rs use= .
I2RS state is intended to be ephemeral. (See architecture document.)


I think this has been explained severa= l times already,
starting in the IETF 89 slides.

I don't think anybody has said NC/RC/YANG could be used
as the I2RS protocol without a single change. =A0People has said
=
it is the best starting point for I2RS. =A0There seemed to be an overw= helming
consensus in the London meeting and on this mailing list = to
use NC or RC + YANG as the I2RS starting point.

IMO, there needs to be a new datastore in the architecture that
contains I2RS data. The I2RS protocol will define how this data is access= ed.
It's really not that complicated.

There a= re many implementations using NC/RC + YANG, and many of
these ven= dors have stated that they believe this approach can
be made to w= ork for I2RS.


> If there is one running datastore, then, presumably, it is persistent<= br> > (across reboots) - the documents appear not to say. =A0If there is run= ning
> and startup, presumably startup is persistent and running is not. =A0B= ut
> if you have running and acme-special datastores, then which is
> persistent? =A0This is one of several issues, like operational state, = that
> have surfaced from time to time and, for me, have not got nailed down = as
> well as I would like, and so - surface from time to time.


I2RS does not have any interaction wit= h the "local config" except maybe
to read it. =A0The NE= TCONF configuration datastores (candidate, running, startup) are
not going to be used by I2RS. =A0Nothing I2RS does is going to even slightl= y
alter the definition of any NETCONF configuration procedures.


This covers my point. =A0Moving this particular bit of discussion to Juerge= n's
response to me in another thread.

-- Jeff

Andy

=
--001a113abfd87aafe904f857f368-- From nobody Thu May 1 08:23:37 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 4F5F81A6F83 for ; Thu, 1 May 2014 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, 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 L7mv-yXB6mOp for ; Thu, 1 May 2014 08:23:34 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 226BF1A08ED for ; Thu, 1 May 2014 08:23:34 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 19E57278B8CF; Thu, 1 May 2014 11:23:32 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_968A9F85-60ED-406C-BA53-C92BB72675FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Thu, 1 May 2014 11:23:30 -0400 Message-Id: References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/71ne3BdPyIgecS0LuHNRKKsg5vw Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 15:23:36 -0000 --Apple-Mail=_968A9F85-60ED-406C-BA53-C92BB72675FA Content-Type: multipart/alternative; boundary="Apple-Mail=_5BDC1623-A4F7-4BD2-9DEF-FE14464EBB1B" --Apple-Mail=_5BDC1623-A4F7-4BD2-9DEF-FE14464EBB1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 1, 2014:11:02 AM, at 11:02 AM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas wrote: > Tom, >=20 > On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote: > > But, Jeff, you then say, in a parallel post > > > > "The issues then comes back to the ones noted in > > draft-bjorklund-netmod-operational-00: How do we distinguish > > operational, > > config or ephemeral config states? " > > > > whereas I see operational state, config and read-only statistics, = with > > state (unqualified) referring to the first and last collectively! > > 'ephemeral' does not appear in Martin's I-D, nor would I expect it = to - > > I don't see it as a concept in YANG/NETCONF. >=20 > I agree it is not currently part of Netconf/Yang. This is part of why = I > raise the question. >=20 > > There is a separate issue of persistent and ephemeral in YANG, or, > > arguably, in NETCONF, which is also not documented AFAICS. This is > > probably of less interest to I2RS at this time. >=20 > I actually think it's one of our bigger sticking points - or at least > something we need a clear answer on if N/Y is to be considered for = i2rs use. > I2RS state is intended to be ephemeral. (See architecture document.) >=20 >=20 > I think this has been explained several times already, > starting in the IETF 89 slides. >=20 > I don't think anybody has said NC/RC/YANG could be used > as the I2RS protocol without a single change. People has said > it is the best starting point for I2RS. There seemed to be an = overwhelming > consensus in the London meeting and on this mailing list to > use NC or RC + YANG as the I2RS starting point. >=20 > IMO, there needs to be a new datastore in the architecture that > contains I2RS data. The I2RS protocol will define how this data is = accessed. > It's really not that complicated. >=20 > There are many implementations using NC/RC + YANG, and many of > these vendors have stated that they believe this approach can > be made to work for I2RS. I agree. I am not sure why we keep going round and round about = these issues. Its been clear from the start that while yang/netconf is a modeling language and protocol that can be used as a solid basis to = solve the problems here, both need some minor modifications.=20 In the case of yang, we've gone over many of the mods needed recently. = NetMod is *currently* working on yang 1.1 which are minor=20 changes that are probably a good vehicle to catch those changes, but = waiting for another 9 months while we debate using the other 9 options will miss that window. As for NetConf, we need to be able to = relax the commit sequence/locking/back-out operations so we have a "cut through" mechanism for fast programming. It is that = simple. This has all been discussed at length over a year ago.=20 We cannot wait forever for this WG to debate things ad infinitum. When = can we get to producing some relevant solutions? --Tom >=20 > > If there is one running datastore, then, presumably, it is = persistent > > (across reboots) - the documents appear not to say. If there is = running > > and startup, presumably startup is persistent and running is not. = But > > if you have running and acme-special datastores, then which is > > persistent? This is one of several issues, like operational state, = that > > have surfaced from time to time and, for me, have not got nailed = down as > > well as I would like, and so - surface from time to time. >=20 >=20 > I2RS does not have any interaction with the "local config" except = maybe > to read it. The NETCONF configuration datastores (candidate, running, = startup) are > not going to be used by I2RS. Nothing I2RS does is going to even = slightly > alter the definition of any NETCONF configuration procedures. >=20 >=20 > This covers my point. Moving this particular bit of discussion to = Juergen's > response to me in another thread. >=20 > -- Jeff >=20 > Andy >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_5BDC1623-A4F7-4BD2-9DEF-FE14464EBB1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On May 1, 2014:11:02 AM, at 11:02 AM, = Andy Bierman <andy@yumaworks.com> = wrote:




On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas = <jhaas@pfrc.org> wrote:
Tom,

On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote:
> But, Jeff, you then say, in a parallel post
>
> "The issues then comes back to the ones noted in
> draft-bjorklund-netmod-operational-00: How do we distinguish
> operational,
> config or ephemeral config states? "
>
> whereas I see operational state, config and read-only statistics, = with
> state (unqualified) referring to the first and last = collectively!
> 'ephemeral' does not appear in Martin's I-D, nor would I expect it = to -
> I don't see it as a concept in YANG/NETCONF.

I agree it is not currently part of Netconf/Yang.  This is part of = why I
raise the question.

> There is a separate issue of persistent and ephemeral in YANG, = or,
> arguably, in NETCONF, which is also not documented AFAICS. =  This is
> probably of less interest to I2RS at this time.

I actually think it's one of our bigger sticking points - or at = least
something we need a clear answer on if N/Y is to be considered for i2rs = use.
I2RS state is intended to be ephemeral. (See architecture document.)


I think this has been explained = several times already,
starting in the IETF 89 = slides.

I don't think anybody has said = NC/RC/YANG could be used
as the I2RS protocol without a single change.  People has = said
it is the best starting point for I2RS.  There = seemed to be an overwhelming
consensus in the London meeting = and on this mailing list to
use NC or RC + YANG as the I2RS starting = point.

IMO, there needs to be a new datastore = in the architecture that
contains I2RS data. The I2RS protocol = will define how this data is accessed.
It's really not that complicated.

There = are many implementations using NC/RC + YANG, and many of
these = vendors have stated that they believe this approach can
be = made to work for = I2RS.

I agree. = I am not sure why we keep going round and round about these issues. Its = been clear from the start that while yang/netconf
is a = modeling language and protocol that can be used as a solid basis to = solve the problems here, both need some minor = modifications. 
In the case of yang, we've gone over many = of the mods needed recently. NetMod is *currently* working on yang 1.1 = which are minor 
changes that are probably a good vehicle = to catch those changes, but waiting for another 9 months while we debate = using the other
9 options will miss that window.  As for = NetConf, we need to be able to relax the commit = sequence/locking/back-out operations
so we have a "cut = through" mechanism for fast programming. It is that simple. This has all = been discussed at length over a year ago. 
We cannot wait = forever for this WG to debate things ad infinitum.  When can we get = to producing some relevant solutions?

= --Tom




> If there is one running datastore, then, presumably, it = is persistent
> (across reboots) - the documents appear not to say.  If there = is running
> and startup, presumably startup is persistent and running is not. =  But
> if you have running and acme-special datastores, then which is
> persistent?  This is one of several issues, like operational = state, that
> have surfaced from time to time and, for me, have not got nailed = down as
> well as I would like, and so - surface from time to time.


I2RS does not have any interaction = with the "local config" except maybe
to read it.  The = NETCONF configuration datastores (candidate, running, startup) = are
not going to be used by I2RS.  Nothing I2RS does is going to even = slightly
alter the definition of any NETCONF configuration = procedures.


This covers my point.  Moving this particular bit of discussion to = Juergen's
response to me in another thread.

-- = Jeff

Andy

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

= --Apple-Mail=_5BDC1623-A4F7-4BD2-9DEF-FE14464EBB1B-- --Apple-Mail=_968A9F85-60ED-406C-BA53-C92BB72675FA 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 iQIcBAEBCgAGBQJTYmbyAAoJEPcO+I7eiUJZL1sP/0rfu8vt8Yx3/4Uv2exenMpe hmfpkgkzHMaBGPYEGWUbx9DZnPiCS3RLhNmoyBYtSZ/daqJNSMWRqpRgtERUwAAL afB9kQzqiu1wBaji9GCIxteMKgKHb9UztWpfnDAcJNXG40Mv8HRFH8eo+12iQNgZ jLkK7waM4XN/AnObXM+fMVjMsKgnbF2CrHLUrAaRbH6cQLEgJBTgUnzeSE+WBYkb IGl//1Bo4ZdkQ6vE/K7IuiXppLTGEI/DCOhZKUsspFleHFuDJ3NXfvqfIVsgxuW/ 1yyH7lGSmF50cljXKXdRMTqErUTyYSETNA4NpVNEQSEpmWuS1EHI37c1PnHA1JrY NKceg63AYXkR/xEv2OGWOrsqW0QAiFK7Q1cguj/o8msfij5ALflENBP2Y0NrdzfR tKJFti5/SH6HEU/fEil/U4sEZ5o4SxmEtliw8GPg0C6/9AXRM4WZv6XgrF+RDorj YGasom6PHmWN2guZi3wn7m1uxN0r2355OIxOQTspyLlY6zxy8O45mdKBjt+dmKRr yMxs6FKzPS2bUQoQt/m/EuhiuLc8epxXZz1ZiXyP5AFGOCk1q02yOZGfDFtQHlNs vjySUuL35ZYPA+Pv6jL1fh80FJeVMxzpTLQ/5LdN5iRzAAH25WyBNnO5XWBAW2nF Uz8YrH0MHIOFUmQbwDt9 =alCW -----END PGP SIGNATURE----- --Apple-Mail=_968A9F85-60ED-406C-BA53-C92BB72675FA-- From nobody Thu May 1 08:23: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 0A1F71A6F91 for ; Thu, 1 May 2014 08:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 iP69bbIUs5Eg for ; Thu, 1 May 2014 08:23:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB03F1A08ED for ; Thu, 1 May 2014 08:23:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0CB31C458; Thu, 1 May 2014 11:23:36 -0400 (EDT) Date: Thu, 1 May 2014 11:23:36 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140501152335.GB29842@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@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/6ikWKP6Hwz1MI1GrkFYrTO8jWTE Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 15:23:39 -0000 Andy, On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote: > I think this has been explained several times already, > starting in the IETF 89 slides. > > I don't think anybody has said NC/RC/YANG could be used > as the I2RS protocol without a single change. People has said > it is the best starting point for I2RS. There seemed to be an overwhelming > consensus in the London meeting and on this mailing list to > use NC or RC + YANG as the I2RS starting point. Since we've not been very good about getting requirements explicitly listed, part of the point of my questions is to tease out those details. > IMO, there needs to be a new datastore in the architecture that > contains I2RS data. The I2RS protocol will define how this data is accessed. > It's really not that complicated. And thus, "we need a new data store". How it interacts with similarly configured objects in other datastores is another detail I'm trying to tease out as a requirement. > I2RS does not have any interaction with the "local config" except maybe > to read it. The NETCONF configuration datastores (candidate, running, > startup) are > not going to be used by I2RS. Nothing I2RS does is going to even slightly > alter the definition of any NETCONF configuration procedures. Consider my BGP example noted elsewhere. If I want to say "create a BGP peer" as an I2RS operation and some of that behavior relies on other underlying configuration (autonomous system, security policies, etc.) my choices appear to be either to have some amount of shadowed configuration objects on top of an existing BGP module or have a somewhat parallel module (perhaps inheriting configuration objects from the main BGP module). Which would you do? -- Jeff From nobody Thu May 1 08:30: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 125011A6F03 for ; Thu, 1 May 2014 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 rsj49HoYagag for ; Thu, 1 May 2014 08:30:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BCE121A0904 for ; Thu, 1 May 2014 08:30:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 01F47C2E0; Thu, 1 May 2014 11:30:40 -0400 (EDT) Date: Thu, 1 May 2014 11:30:39 -0400 From: Jeffrey Haas To: Thomas Nadeau Message-ID: <20140501153039.GC29842@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@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/lhcwCGDQ-JTP8h3GMjTUQemenXM Cc: Jeffrey Haas , "i2rs@ietf.org" , Andy Bierman , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 15:30:43 -0000 On Thu, May 01, 2014 at 11:23:30AM -0400, Thomas Nadeau wrote: > I agree. I am not sure why we keep going round and round about these issues. Its been clear from the start that while yang/netconf > is a modeling language and protocol that can be used as a solid basis to solve the problems here, both need some minor modifications. [grumpily] Then if someone would please edit the wiki page to enumerate them and thus to help tie-back to the requirements, I can stop asking my leading questions. > In the case of yang, we've gone over many of the mods needed recently. NetMod is *currently* working on yang 1.1 which are minor > changes that are probably a good vehicle to catch those changes, but waiting for another 9 months while we debate using the other > 9 options will miss that window. As for NetConf, we need to be able to relax the commit sequence/locking/back-out operations > so we have a "cut through" mechanism for fast programming. It is that simple. This has all been discussed at length over a year ago. > We cannot wait forever for this WG to debate things ad infinitum. When can we get to producing some relevant solutions? Perhaps when the damned things are written down and work chartered to do them. If you have time to complain about the debate, you have time to generate a short enumerated list. -- Jeff From nobody Thu May 1 09:03: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 5E0CF1A6F6E for ; Thu, 1 May 2014 09:03:12 -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 OijQ68I51E1a for ; Thu, 1 May 2014 09:03:10 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id EAFC21A08E6 for ; Thu, 1 May 2014 09:03:09 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so3526525qcz.16 for ; Thu, 01 May 2014 09:03:07 -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=6siW43Oia0qzvwtRfOyJ1MoxliOW7+eMhgLtV7CH6is=; b=K2KGrR0SXdychuVqjwy0ppNIqK9Fj7koU7gt9aOKmfeNZEyVKY1Yoolz+xy6nn5Oyw Bekp9eZG8K4du2zgDSxKj2gEkIFhCz1b6C8qXw6xwZDv2dLCo0a3Qrnq6/8YKrpUUepY dtoksX56B074Wizx3h1uIvyM8j6VPFNLga4t7ezNztFggWETHJkyIlzeeYrpPga5e6RU SherqTqbZOlVxlrs4o438fGcjpyh+j0DW1CWnX+pu12lLMtlkZutEQvEpi5yof+VEW4I Nb9wrmILc6zdY8kpwF6D3684olr83v0EQIyNyUJ9bZne6EpMLsv3ZNyqhT1bNB8DeoZl gimQ== X-Gm-Message-State: ALoCoQmc3StGG85zhrPrKDEtnO3AIAOiyfF9EFSKXCS4P9JDwB8zryevA/NQ26rdQHz2ezeG7ooA MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr15087348qai.16.1398960187689; Thu, 01 May 2014 09:03:07 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 09:03:07 -0700 (PDT) In-Reply-To: <20140501152335.GB29842@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> Date: Thu, 1 May 2014 09:03:07 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c20e7a0ae69204f858cd83 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/IfQlqBWHuvn-YBj6sQ92NxUhuRY Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 16:03:12 -0000 --001a11c20e7a0ae69204f858cd83 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 8:23 AM, Jeffrey Haas wrote: > Andy, > > On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote: > > I think this has been explained several times already, > > starting in the IETF 89 slides. > > > > I don't think anybody has said NC/RC/YANG could be used > > as the I2RS protocol without a single change. People has said > > it is the best starting point for I2RS. There seemed to be an > overwhelming > > consensus in the London meeting and on this mailing list to > > use NC or RC + YANG as the I2RS starting point. > > Since we've not been very good about getting requirements explicitly > listed, > part of the point of my questions is to tease out those details. > > > IMO, there needs to be a new datastore in the architecture that > > contains I2RS data. The I2RS protocol will define how this data is > accessed. > > It's really not that complicated. > > And thus, "we need a new data store". How it interacts with similarly > configured objects in other datastores is another detail I'm trying to > tease > out as a requirement. > > OK -- I hope this ASCII art helps. NC/RC I2RS | | V V +-------------------+ +----------------+ | local config | | i2rs-config | +-------------------+ +----------------+ | | V V +-------------------------------------------+ | operational state | +-------------------------------------------+ The operational state contains a data-model dependent mix of local and i2rs configuration, + learned data from protocols. The "i2rs-config" datastore is like a "fastpath" config (as Tom described). The operations on the local-config datastore use different rules and the 2 only mix in the operational state. > I2RS does not have any interaction with the "local config" except maybe > > to read it. The NETCONF configuration datastores (candidate, running, > > startup) are > > not going to be used by I2RS. Nothing I2RS does is going to even > slightly > > alter the definition of any NETCONF configuration procedures. > > Consider my BGP example noted elsewhere. If I want to say "create a BGP > peer" as an I2RS operation and some of that behavior relies on other > underlying configuration (autonomous system, security policies, etc.) my > choices appear to be either to have some amount of shadowed configuration > objects on top of an existing BGP module or have a somewhat parallel module > (perhaps inheriting configuration objects from the main BGP module). > > Which would you do? > > I would start by making sure the management of the local config and the I2RS config were fully aligned, because it is inevitable (if not obvious) that definitions in all 3 boxes above need to share data naming, data types, and even data nodes. A YANG grouping would be the starting point for sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt). -- Jeff > Andy --001a11c20e7a0ae69204f858cd83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 8:23 AM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
Andy,

On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote:
> I think this has been explained several times already,
> starting in the IETF 89 slides.
>
> I don't think anybody has said NC/RC/YANG could be used
> as the I2RS protocol without a single change. =A0People has said
> it is the best starting point for I2RS. =A0There seemed to be an overw= helming
> consensus in the London meeting and on this mailing list to
> use NC or RC + YANG as the I2RS starting point.

Since we've not been very good about getting requirements explicitly li= sted,
part of the point of my questions is to tease out those details.

> IMO, there needs to be a new datastore in the architecture that
> contains I2RS data. The I2RS protocol will define how this data is acc= essed.
> It's really not that complicated.

And thus, "we need a new data store". =A0How it interacts with si= milarly
configured objects in other datastores is another detail I'm trying to = tease
out as a requirement.


OK -- I hope this ASCII art helps.

=A0 =A0 =A0 =A0NC/RC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = I2RS
=A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 V =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0V
=A0 =A0 +-------------------+ =A0+----------------+
=A0 =A0 = =A0| =A0local config =A0| =A0 | i2rs-config |
=A0 =A0 +------= -------------+ =A0+----------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 V =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V
=A0 =A0 +-------------------------------------------+
=A0 = =A0 =A0| =A0 =A0 =A0operational state =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 +-------------------------------------------+

The operational state contains a data-model dependent mix
of local and i2rs configuration, + learned data from protocols.
The "i2rs-config" datastore is like a "fastpath"= config (as Tom described).
The operations on the local-config datastore use different rules and t= he 2 only
mix in the operational state.

=
> I2RS does not have any interaction with the "local config" e= xcept maybe
> to read it. =A0The NETCONF configuration datastores (candidate, runnin= g,
> startup) are
> not going to be used by I2RS. =A0Nothing I2RS does is going to even sl= ightly
> alter the definition of any NETCONF configuration procedures.

Consider my BGP example noted elsewhere. =A0If I want to say "create a= BGP
peer" as an I2RS operation and some of that behavior relies on other underlying configuration (autonomous system, security policies, etc.) my choices appear to be either to have some amount of shadowed configuration objects on top of an existing BGP module or have a somewhat parallel module=
(perhaps inheriting configuration objects from the main BGP module).

Which would you do?


I would start by making sure the management of the local config and
<= div class=3D"gmail_quote">the I2RS config were fully aligned, because it is= inevitable (if not obvious)
that definitions in all 3 boxes above need to sh= are data naming, data types,
and even data = nodes. =A0A YANG grouping would be the starting point for
sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt).=


<= /div>

-- Jeff


Andy

--001a11c20e7a0ae69204f858cd83-- From nobody Thu May 1 09:09: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 6B1FF1A6FC1 for ; Thu, 1 May 2014 09:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 9Gx6bX_KTdAk for ; Thu, 1 May 2014 09:09:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 613E61A6FA7 for ; Thu, 1 May 2014 09:09:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7FC69C2E0; Thu, 1 May 2014 12:09:52 -0400 (EDT) Date: Thu, 1 May 2014 12:09:52 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140501160952.GA31629@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@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/WFxA7c-e72GrQ9TrtOudKDDYTZU Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 16:09:55 -0000 Andy, On Thu, May 01, 2014 at 09:03:07AM -0700, Andy Bierman wrote: > > And thus, "we need a new data store". How it interacts with similarly > > configured objects in other datastores is another detail I'm trying to > > tease > > out as a requirement. > > > > > OK -- I hope this ASCII art helps. > > NC/RC I2RS > | | > V V > +-------------------+ +----------------+ > | local config | | i2rs-config | > +-------------------+ +----------------+ > | | > V V > +-------------------------------------------+ > | operational state | > +-------------------------------------------+ > > The operational state contains a data-model dependent mix > of local and i2rs configuration, + learned data from protocols. > The "i2rs-config" datastore is like a "fastpath" config (as Tom described). > The operations on the local-config datastore use different rules and the 2 > only > mix in the operational state. Fully parallel, which was the detail I was trying to get to. Thanks. [...] > > Consider my BGP example noted elsewhere. If I want to say "create a BGP > > peer" as an I2RS operation and some of that behavior relies on other > > underlying configuration (autonomous system, security policies, etc.) my > > choices appear to be either to have some amount of shadowed configuration > > objects on top of an existing BGP module or have a somewhat parallel module > > (perhaps inheriting configuration objects from the main BGP module). > > > > Which would you do? > > > > > I would start by making sure the management of the local config and > the I2RS config were fully aligned, because it is inevitable (if not > obvious) > that definitions in all 3 boxes above need to share data naming, data types, > and even data nodes. A YANG grouping would be the starting point for > sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt). I'm not sure this fully answers my question. In the case they are congruent, would you ever want to have I2RS simply share the yang config (obviously needing some syntax changes that permits such overlap) or would you prefer that they be simply use language inheritance features across modules? Perhaps that is a better way to ask it: Within the same module or using two modules? If within the same module, there is the implication of a requirement for changes to the language to permit them to do so harmoniously. If across different modules, there is the suggestion but not requirement that as Working Groups provide yang modules for managing their components that they are structured in such a way to permit I2RS re-use in our modules. -- Jeff From nobody Thu May 1 09:44: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 D234D1A08F2 for ; Thu, 1 May 2014 09:44:39 -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 zM_EpsTgBVyp for ; Thu, 1 May 2014 09:44:37 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id B29D81A073F for ; Thu, 1 May 2014 09:44:37 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id j15so3177361qaq.21 for ; Thu, 01 May 2014 09:44:35 -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=QHQDy6UvL+iN7LqUA8mUpaNgNvhMyD7PwSnkUCqKzIA=; b=MDbD0z1LHPbZvBo1cgCLRi7ezolbhpx/63SgFWTcfSMMxGcWZ4XaK/jV7vDUp8MEDj mQIDZUV/ff5if+AOot8qYZ7u5Q41qfOu3G9BmIiODhVGAWrbCt2TVqQynRAdcrdb2jDP pWOtvZUazzTshs6/6BaV4GQYLEO4v2fa3wuXaegaCS5OBVBy9hhVUp8O79008Y70OG1u rMr3ALO8PE4vhB/krCrDt/GAz8K+/MG1eP2luaotIDuxVgt4h6jiqXq+KcoZWc4E6JT2 ZMWxmWc0W7hsaUef6rLxxBCu8c4i90TxsrkwGUBq52vCfv4krlqEEannUzprXmTDa/OV z8Xg== X-Gm-Message-State: ALoCoQlD8rdpMVh5ybazoiKr0OLQTp6yCxuHIe5Gj1DXwxIx2yAcqMqhM5sVGRCGUTyoKTenU2PS MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr15431704qai.16.1398962675436; Thu, 01 May 2014 09:44:35 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 09:44:35 -0700 (PDT) In-Reply-To: <20140501160952.GA31629@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> Date: Thu, 1 May 2014 09:44:35 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c20e7a52deb604f859619a Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lhLvSeroajppl6acUt_YmITIb1A Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 16:44:40 -0000 --001a11c20e7a52deb604f859619a Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 9:09 AM, Jeffrey Haas wrote: > Andy, > > On Thu, May 01, 2014 at 09:03:07AM -0700, Andy Bierman wrote: > > > And thus, "we need a new data store". How it interacts with similarly > > > configured objects in other datastores is another detail I'm trying to > > > tease > > > out as a requirement. > > > > > > > > OK -- I hope this ASCII art helps. > > > > NC/RC I2RS > > | | > > V V > > +-------------------+ +----------------+ > > | local config | | i2rs-config | > > +-------------------+ +----------------+ > > | | > > V V > > +-------------------------------------------+ > > | operational state | > > +-------------------------------------------+ > > > > The operational state contains a data-model dependent mix > > of local and i2rs configuration, + learned data from protocols. > > The "i2rs-config" datastore is like a "fastpath" config (as Tom > described). > > The operations on the local-config datastore use different rules and the > 2 > > only > > mix in the operational state. > > Fully parallel, which was the detail I was trying to get to. Thanks. > > [...] > > > > Consider my BGP example noted elsewhere. If I want to say "create a > BGP > > > peer" as an I2RS operation and some of that behavior relies on other > > > underlying configuration (autonomous system, security policies, etc.) > my > > > choices appear to be either to have some amount of shadowed > configuration > > > objects on top of an existing BGP module or have a somewhat parallel > module > > > (perhaps inheriting configuration objects from the main BGP module). > > > > > > Which would you do? > > > > > > > > I would start by making sure the management of the local config and > > the I2RS config were fully aligned, because it is inevitable (if not > > obvious) > > that definitions in all 3 boxes above need to share data naming, data > types, > > and even data nodes. A YANG grouping would be the starting point for > > sharing objects. (Not sure if any tweaks needed to support I2RS > uses-stmt). > > I'm not sure this fully answers my question. > > In the case they are congruent, would you ever want to have I2RS simply > share the yang config (obviously needing some syntax changes that permits > such > overlap) or would you prefer that they be simply use language inheritance > features across modules? > > Perhaps that is a better way to ask it: Within the same module or using two > modules? > > If within the same module, there is the implication of a requirement for > changes to the language to permit them to do so harmoniously. > > I prefer 1 module, but it is not that simple. The user-defined typedefs and identities (for identityref data type) can be shared (e.g. imported from a common-types module). Even if the data nodes are separate, the definitions can share YANG semantics in various ways. New YANG statements (or extensions) to identify data affected by I2RS will allow the data models to be mixed in the same module, augment across modules, etc. > If across different modules, there is the suggestion but not requirement > that as Working Groups provide yang modules for managing their components > that they are structured in such a way to permit I2RS re-use in our > modules. > > I think it would be most efficient if a WG considered complete management of a new protocol feature, and chartered configuration, I2RS, monitoring, and notification support at the same time. The IETF approach for the last 2 decades has been to leave most of the management to the vendor CLI. The problem with this approach is that over-laying monitoring systems (vendor + standard) is easy, but not true for APIs that change the system. Once the vendor API is in place, it is very difficult to overlay an incompatible standard API. -- Jeff > Andy --001a11c20e7a52deb604f859619a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 9:09 AM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
Andy,

On Thu, May 01, 2014 at 09:03:07AM -0700, Andy Bierman wrote:
> > And thus, "we need a new data store". =A0How it interac= ts with similarly
> > configured objects in other datastores is another detail I'm = trying to
> > tease
> > out as a requirement.
> >
> >
> OK -- I hope this ASCII art helps.
>
> =A0 =A0 =A0 =A0NC/RC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I2RS
> =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |
> =A0 =A0 =A0 =A0 =A0 V =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V=
> =A0 =A0 +-------------------+ =A0+----------------+
> =A0 =A0 =A0| =A0local config =A0| =A0 | i2rs-config |
> =A0 =A0 +-------------------+ =A0+----------------+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 V =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V=
> =A0 =A0 +-------------------------------------------+
> =A0 =A0 =A0| =A0 =A0 =A0operational state =A0 =A0 =A0 =A0 =A0 =A0 =A0|=
> =A0 =A0 +-------------------------------------------+
>
> The operational state contains a data-model dependent mix
> of local and i2rs configuration, + learned data from protocols.
> The "i2rs-config" datastore is like a "fastpath" c= onfig (as Tom described).
> The operations on the local-config datastore use different rules and t= he 2
> only
> mix in the operational state.

Fully parallel, which was the detail I was trying to get to. Thanks.

[...]

> > Consider my BGP example noted elsewhere. =A0If I want to say &quo= t;create a BGP
> > peer" as an I2RS operation and some of that behavior relies = on other
> > underlying configuration (autonomous system, security policies, e= tc.) my
> > choices appear to be either to have some amount of shadowed confi= guration
> > objects on top of an existing BGP module or have a somewhat paral= lel module
> > (perhaps inheriting configuration objects from the main BGP modul= e).
> >
> > Which would you do?
> >
> >
> I would start by making sure the management of the local config and > the I2RS config were fully aligned, because it is inevitable (if not > obvious)
> that definitions in all 3 boxes above need to share data naming, data = types,
> and even data nodes. =A0A YANG grouping would be the starting point fo= r
> sharing objects. (Not sure if any tweaks needed to support I2RS uses-s= tmt).

I'm not sure this fully answers my question.

In the case they are congruent, would you ever want to have I2RS simply
share the yang config (obviously needing some syntax changes that permits s= uch
overlap) or would you prefer that they be simply use language inheritance features across modules?

Perhaps that is a better way to ask it: Within the same module or using two=
modules?

If within the same module, there is the implication of a requirement for changes to the language to permit them to do so harmoniously.


I prefer 1 module, but it is not that = simple. The user-defined typedefs and
identities (for identityref= data type) can be shared (e.g. imported from
a common-types modu= le). Even if the data nodes are separate, the
definitions can share YANG semantics in various ways.


New YANG statements (or extensions) to identify dat= a affected by I2RS
will allow the data models to be mixed in the = same module, augment across
modules, etc.

=A0
If across different modules, there is the suggestion but not requirement that as Working Groups provide yang modules for managing their components that they are structured in such a way to permit I2RS re-use in our modules= .


I think it would be most efficient if = a WG considered complete management
of a new protocol feature, an= d chartered configuration, I2RS, monitoring,
and notification sup= port at the same time. =A0

The IETF approach for the last 2 decades has been to le= ave most
of the management to the vendor CLI. The problem with th= is approach=A0
is that over-laying monitoring systems (vendor + s= tandard)
is easy, but not true for APIs that change the system. =A0Once the ven= dor API is in
place, it is very difficult to overlay an incompati= ble standard API.



-- Jeff

Andy

--001a11c20e7a52deb604f859619a-- From nobody Thu May 1 09:49: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 0A3311A6F9F for ; Thu, 1 May 2014 09:49:02 -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 UsBGB9UXbAxP for ; Thu, 1 May 2014 09:48:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) by ietfa.amsl.com (Postfix) with ESMTP id B75241A0903 for ; Thu, 1 May 2014 09:48:58 -0700 (PDT) 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.929.12; Thu, 1 May 2014 16:48:55 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.215]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.215]) with mapi id 15.00.0929.001; Thu, 1 May 2014 16:48:55 +0000 From: Dean Bogdanovic To: Jamal Hadi Salim Thread-Topic: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model Thread-Index: AQHPX6gAN4nxTXmJ50qCjM9BhMCPLpsgwwyAgAADEYCAAAM6AIAABJaAgABjK4CAAGKyAIAF7HOAgAEjtoCAA1c0gA== Date: Thu, 1 May 2014 16:48:54 +0000 Message-ID: <14331372-5EB5-428D-9851-C76E72E2AE7C@juniper.net> References: <535916F0.3050206@joelhalpern.com> <55AA400B-3D5A-4980-8330-3541A1663586@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-originating-ip: [66.129.241.10] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(479174003)(24454002)(199002)(189002)(51704005)(57306001)(551934002)(93916002)(20776003)(74502001)(62966002)(81542001)(89996001)(79102001)(76482001)(86362001)(31966008)(4396001)(83072002)(85852003)(46102001)(92726001)(99396002)(99286001)(77982001)(92566001)(50226001)(81342001)(15975445006)(82746002)(33656001)(76176999)(50986999)(101416001)(88136002)(87286001)(36756003)(83716003)(87936001)(2656002)(77156001)(80022001)(66066001)(80976001)(19580405001)(83322001)(19580395003)(100906001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:F6F4F124.ABF6D1C3.FADDBF8B.42EAC848.205BC; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <8BE71AB1FB394C48AD577C1AE2CB228E@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/CfVmsS3ZaAuFZP0as1XPnf3ajUI Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model 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, 01 May 2014 16:49:02 -0000 Jamal, On Apr 29, 2014, at 9:47 AM, Jamal Hadi Salim wrote: > Dean, >=20 > In your slides, IIRC, at the meeting you illustrated several daemons > all interacting with the > agent doing different things. Not completely correct. I have only one agent talking to multiple daemons a= nd that is the analytics agent. Routing and filtering agents in the picture= are talking only to its respective daemons. With the analytics agent, havi= ng one for each daemon is an overhead imo. Dean > In our case it will very likely be > multiple daemons doing > different things for the agent (and sometimes remote machines). In any > case, this may end up being > an implementation issue. > I have another issue I will post probably under a separate topic: > Prioritization. >=20 > cheers, > jamal >=20 > On Mon, Apr 28, 2014 at 4:23 PM, Dean Bogdanovic wrot= e: >> Jamal, >>=20 >> There is only one agent to one daemon. There is no scenario of one agent= to multiple daemons. >>=20 >> There are multiple clients to one agent. >>=20 >> So agent is depending on the speed of daemon and agent should protect ov= erloading daemon with requests, so it can police requests from clients. >>=20 >> Dean >>=20 >>=20 >> On Apr 24, 2014, at 9:56 PM, Jamal Hadi Salim wrote: >>=20 >>> I was mostly referring to overload conditions (of both compute and >>> wire resources). >>> It is feasible for a client not to be able to keep up (eg a table dump >>> response; i.e a single >>> request resulting in a large fast bulk response). However, >>> the more interesting case is for a daemon overload as a result of some >>> client transaction; >>> assuming possibly N daemons talk to an agent on the south bound >>> multiplexing to M clients >>> on the northbound, where M>>N - and how to deal with the client(s) >>> that are responsible for the >>> overload without adversely affecting the other clients that dont >>> contribute to overload. >>> Some of this could be implementation issues. >>>=20 >>> I think l misunderstood what you and Andy were saying to imply you >>> meant M equals N equals 1. >>>=20 >>> cheers, >>> jamal >>>=20 >>>=20 >>> On Thu, Apr 24, 2014 at 4:03 PM, Dean Bogdanovic wr= ote: >>>>=20 >>>> On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim wro= te: >>>>=20 >>>>> I was more looking at the agent - it brokers between clients and the >>>>> RIB subsystem >>>>> as shown in figure 1 of the architecture doc. Different clients bring >>>>> different latencies/capacities. >>>>> Congestions will kick in, >>>> how does client latency influence agent? The agent sees request coming= in from different authorized clients at a rate and it is processing those = requests. The agent will depend on the daemon performance, but not on clien= t. >>>>=20 >>>>> reliability requirements will need to be >>>>> considered. And there may >>>>> be need to signal these details to the clients (SIP proxying is the >>>>> closest i can think of). >>>>> You cant solve this problem by just inserting a reliable transport >>>>> where the i2rs protocol >>>>> runs. >>>>>=20 >>>>> cheers, >>>>> jamal >>>>>=20 >>>>> On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern wrote: >>>>>> No, there is no requirement that the client is a broker. He may be,= or he >>>>>> may not. And the scope of his brokering, if he is a broker, may be >>>>>> application specific or more general. >>>>>>=20 >>>>>> We have placed requirements to be able to provide traceability when = the >>>>>> client is brokering. This is as much because even a non-broker may = be >>>>>> acting on behalf of several different applications. >>>>>>=20 >>>>>> As far as I can tell, the fact that a client may itneract with multi= ple >>>>>> agents does not in itself palce new protocol or model requirements o= n the >>>>>> system. If we wanted inter-agent atomicity, then there would be >>>>>> requirements. But we explicitly decided that was out of scope. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>>=20 >>>>>> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>>>>>>=20 >>>>>>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>>>>>> across N locked I2RS agents? >>>>>>>>=20 >>>>>>>=20 >>>>>>> There is a requirement to allow only one client to own write access= to >>>>>>> a specified object in order to avoid locking. There is nothing obje= cting >>>>>>> to a client being able to write to multiple objects as long as that= rule >>>>>>> is met. >>>>>>>=20 >>>>>>>> The agents do not coordinate with each other. >>>>>>>> The clients do not coordinate with each other. >>>>>>>>=20 >>>>>>>> This is currently out of scope for the I2RS protocol. >>>>>>>>=20 >>>>>>>=20 >>>>>>> Both assertions true. >>>>>>> But what i was responding to is: >>>>>>> There are multiple clients that connect to the same agent. >>>>>>> And a client can connect to multiple agents. >>>>>>>=20 >>>>>>> I believe that such a requirement _may_ call out certain features i= n >>>>>>> the protocol. Essentially the agent is a broker. >>>>>>>=20 >>>>>>> cheers, >>>>>>> jamal >>>>>>>=20 >>>>>>>>> cheers, >>>>>>>>> jamal >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>> From: Jamal Hadi Salim >>>>>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>>>>>> To: Dean Bogdanovic >>>>>>>>> Cc: Andy Bierman , "" >>>>>>>>> , Martin Bjorklund , "" >>>>>>>>> , "" >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman w= rote: >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Dont think so. >>>>>>>>>=20 >>>>>>>>>> Network locking across devices is out of scope. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I have same opinion as you on this one, just wanted to spell it = out one >>>>>>>>>> more >>>>>>>>>> time explicitly, as I heard some discussions where network locki= ng was >>>>>>>>>> coming up. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Either I am misunderstanding both of you or both of you misunders= tood >>>>>>>>> the >>>>>>>>> requirement. >>>>>>>>> The idea is to allow a single writer per object as a starting poi= nt. >>>>>>>>> OTOH, if you really mean what you say then I violently disagree. >>>>>>>>>=20 >>>>>>>>> cheers, >>>>>>>>> jamal >>>>>>>>>=20 >>>>>>>>> PS:- Changing the topic so this is not lost in the noise because = i think >>>>>>>>> that >>>>>>>>> the many clients-single agent brings needs for other protocol >>>>>>>>> requirements. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> i2rs mailing list >>>>>>>>> i2rs@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> i2rs mailing list >>>>>>> i2rs@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>=20 From nobody Thu May 1 10:11:21 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 E64991A6FAD for ; Thu, 1 May 2014 10:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 s5mqwmFY2utl for ; Thu, 1 May 2014 10:11:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id D81461A6FA3 for ; Thu, 1 May 2014 10:11:11 -0700 (PDT) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (10.255.75.36) by DB3PR07MB156.eurprd07.prod.outlook.com (10.242.132.152) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 17:11:08 +0000 Received: from pc6 (109.153.84.37) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.453.0; Thu, 1 May 2014 17:11:08 +0000 Message-ID: <005001cf6560$090c4aa0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net><20140501003449.GA1256@pfrc><032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> Date: Thu, 1 May 2014 17:56:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.153.84.37] X-Forefront-PRVS: 01986AE76B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(24454002)(51704005)(377454003)(189002)(199002)(31966008)(19580395003)(19580405001)(83322001)(74502001)(76482001)(81816999)(77982001)(46102001)(80976001)(50466002)(66066001)(23756003)(80022001)(77156001)(88136002)(87286001)(81686999)(50226001)(93916002)(50986999)(87936001)(4396001)(99396002)(86362001)(101416001)(81542001)(76176999)(62966002)(33646001)(81342001)(20776003)(85852003)(47776003)(83072002)(92566001)(61296002)(44716002)(92726001)(15975445006)(14496001)(79102001)(89996001)(62236002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB156; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; FPR:2C3CF16A.A3325D71.31DDAE4B.8AE5F2FF.204E6; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/KquigOwdvvvE0g-EHMBfMD9_vvI Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Operational State 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, 01 May 2014 17:11:19 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "Jeffrey Haas" ; Sent: Thursday, May 01, 2014 3:14 PM > On Thu, May 1, 2014 at 2:01 AM, t.petch wrote: > > > ----- Original Message ----- > > From: "Jeffrey Haas" > > To: "t.petch" > > Cc: > > Sent: Thursday, May 01, 2014 1:34 AM > > > On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote: > > > > This tri-partite split has been the norm for Ops Area for many years > > > > now. > > > > It may or may not be appropriate for I2RS but I do think that I2RS > > > > should > > > > at least take cognizance of this in deciding what terms to use > > > > > > I think this is one of the clearest description of one of our > > problems - and > > > thus requirements - that I've seen thus far. :-) > > > > Yeah, problems are my speciality - I then look to Andy, Juergen, Lada > > and Martin for solutions:-) > > > > But, Jeff, you then say, in a parallel post > > > > "The issues then comes back to the ones noted in > > draft-bjorklund-netmod-operational-00: How do we distinguish > > operational, > > config or ephemeral config states? " > > > > whereas I see operational state, config and read-only statistics, with > > state (unqualified) referring to the first and last collectively! > > 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - > > I don't see it as a concept in YANG/NETCONF. > > > > There is a separate issue of persistent and ephemeral in YANG, or, > > arguably, in NETCONF, which is also not documented AFAICS. This is > > probably of less interest to I2RS at this time. > > N/Y treats config=true data nodes as special. > Collectively these data nodes form a configuration datastore. > This is only important for validation purposes -- determining > what is a "valid" running configuration. > > > If there is one running datastore, then, presumably, it is persistent > > (across reboots) - the documents appear not to say. If there is running > > and startup, presumably startup is persistent and running is not. But > > if you have running and acme-special datastores, then which is > > persistent? This is one of several issues, like operational state, that > > have surfaced from time to time and, for me, have not got nailed down as > > well as I would like, and so - surface from time to time. > > > There is no "acme-special" sort of datastore. > There are only the standard datastores. > > If the server supports the "startup" datastore, then > all configuration changes are saved manually to NV-storage. > If the client does not save changes, they are lost at the next reboot. > > If the server does not support the "startup" datastore then > the NV-storage must mirror the running configuration. All > config changes are saved automatically and immediately. > > Operational state is different than config because only config > is validated according the the YANG constraints. The operational > datastore may need some validation (e.g. field syntax check) > but it is not in anyway considered when validating the running datastore. > > IMO the difference between ephemeral config and operational state > is not the NV-storage, but the validation procedure that accepts or rejects > the write request. > Andy I was being sloppy in my use of the terminology. I was referring to the capability of NETCONF to copy to from one entire datastore to another where either or both may be urls. In that looser sense, there could be one or more of user-defined datastores somewhere, alongside the running. I would expect the persistence of running to be unaltered by this but ... I don't know I do see the persistence of 'config true' data as an important feature thereof, as important as the validity checking that you highlight above; and while I have seen consensus on the netconf WG list about persistence, I have not seen the details make it into an I-D, so while you and others (and I) may know it, those on this list with just the documents to go on may have a few gaps; so I think it worth re-iterating, as I started to do and you have followed up on. Tom Petch > Tom Petch > > > > > -- Jeff > > > > > Andy > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > From nobody Thu May 1 10:11:26 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 72D341A6FC5 for ; Thu, 1 May 2014 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 NX01-22GatqJ for ; Thu, 1 May 2014 10:11:15 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id 96EA21A6FA9 for ; Thu, 1 May 2014 10:11:12 -0700 (PDT) Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (10.255.75.36) by DB3PR07MB156.eurprd07.prod.outlook.com (10.242.132.152) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 17:11:09 +0000 Received: from pc6 (109.153.84.37) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.453.0; Thu, 1 May 2014 17:11:08 +0000 Message-ID: <005101cf6560$095895e0$4001a8c0@gateway.2wire.net> From: t.petch To: Thomas Nadeau , Andy Bierman References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> Date: Thu, 1 May 2014 18:07:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.153.84.37] X-Forefront-PRVS: 01986AE76B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(24454002)(51704005)(377454003)(189002)(199002)(31966008)(19580395003)(19580405001)(83322001)(74502001)(76482001)(81816999)(77982001)(46102001)(80976001)(50466002)(66066001)(23756003)(80022001)(77156001)(88136002)(87286001)(81686999)(50226001)(93916002)(50986999)(87936001)(4396001)(99396002)(86362001)(101416001)(81542001)(76176999)(62966002)(33646001)(81342001)(20776003)(85852003)(47776003)(83072002)(92566001)(61296002)(44716002)(92726001)(15975445006)(14496001)(79102001)(89996001)(62236002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB156; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; FPR:EEB2F12D.93EA91B3.B1E1AD47.88F4D5C1.20511; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xdXnYIZuKpkZoCiF8vOCCmhziZM Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Operational State 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, 01 May 2014 17:11:21 -0000 ----- Original Message ----- From: "Thomas Nadeau" To: "Andy Bierman" Cc: "Jeffrey Haas" ; ; "t.petch" Sent: Thursday, May 01, 2014 4:23 PM On May 1, 2014:11:02 AM, at 11:02 AM, Andy Bierman wrote: > On Thu, May 1, 2014 at 7:46 AM, Jeffrey Haas wrote: > Tom, > > On Thu, May 01, 2014 at 10:01:38AM +0100, t.petch wrote: > > There is a separate issue of persistent and ephemeral in YANG, or, > > arguably, in NETCONF, which is also not documented AFAICS. This is > > probably of less interest to I2RS at this time. > > I actually think it's one of our bigger sticking points - or at least > something we need a clear answer on if N/Y is to be considered for i2rs use. > I2RS state is intended to be ephemeral. (See architecture document.) > > I think this has been explained several times already, > starting in the IETF 89 slides. > > I don't think anybody has said NC/RC/YANG could be used > as the I2RS protocol without a single change. People has said > it is the best starting point for I2RS. There seemed to be an overwhelming > consensus in the London meeting and on this mailing list to > use NC or RC + YANG as the I2RS starting point. > > IMO, there needs to be a new datastore in the architecture that > contains I2RS data. The I2RS protocol will define how this data is accessed. > It's really not that complicated. > > There are many implementations using NC/RC + YANG, and many of > these vendors have stated that they believe this approach can > be made to work for I2RS. I agree. I am not sure why we keep going round and round about these issues. Its been clear from the start that while yang/netconf is a modeling language and protocol that can be used as a solid basis to solve the problems here, both need some minor modifications. In the case of yang, we've gone over many of the mods needed recently. NetMod is *currently* working on yang 1.1 which are minor changes that are probably a good vehicle to catch those changes, but waiting for another 9 months while we debate using the other 9 options will miss that window. As for NetConf, we need to be able to relax the commit sequence/locking/back-out operations so we have a "cut through" mechanism for fast programming. It is that simple. This has all been discussed at length over a year ago. We cannot wait forever for this WG to debate things ad infinitum. When can we get to producing some relevant solutions? Tom I agree that we have gone over the modifications we need at a high level but we then need someone in some working group to write the I-D, fleshing out the details, outlining what is needed. I have thought about 'operational true' as Andy suggested at IETF89, and find I have too many open issues to try and write anything (and this has driven much of my posting to this list in the past six weeks). Of course, there are others better equipped than I on this list; it just needs someone to start. Tom Petch --Tom > > > If there is one running datastore, then, presumably, it is persistent > > (across reboots) - the documents appear not to say. If there is running > > and startup, presumably startup is persistent and running is not. But > > if you have running and acme-special datastores, then which is > > persistent? This is one of several issues, like operational state, that > > have surfaced from time to time and, for me, have not got nailed down as > > well as I would like, and so - surface from time to time. > > > I2RS does not have any interaction with the "local config" except maybe > to read it. The NETCONF configuration datastores (candidate, running, startup) are > not going to be used by I2RS. Nothing I2RS does is going to even slightly > alter the definition of any NETCONF configuration procedures. > > > This covers my point. Moving this particular bit of discussion to Juergen's > response to me in another thread. > > -- Jeff > > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 1 10:14: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 9D04F1A6FA9 for ; Thu, 1 May 2014 10:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 IN-eS5H5xNHY for ; Thu, 1 May 2014 10:14:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 064291A6F78 for ; Thu, 1 May 2014 10:14:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 23AF7C2E0; Thu, 1 May 2014 13:14:42 -0400 (EDT) Date: Thu, 1 May 2014 13:14:42 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140501171442.GA32492@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@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/tBqfKODbYIvrh0E1de_wZtYGk10 Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 17:14:45 -0000 On Thu, May 01, 2014 at 09:44:35AM -0700, Andy Bierman wrote: > > If within the same module, there is the implication of a requirement for > > changes to the language to permit them to do so harmoniously. > > > > > I prefer 1 module, but it is not that simple. The user-defined typedefs and > identities (for identityref data type) can be shared (e.g. imported from > a common-types module). Even if the data nodes are separate, the > definitions can share YANG semantics in various ways. > > > New YANG statements (or extensions) to identify data affected by I2RS > will allow the data models to be mixed in the same module, augment across > modules, etc. Enumerating those changes would be helpful. > > If across different modules, there is the suggestion but not requirement > > that as Working Groups provide yang modules for managing their components > > that they are structured in such a way to permit I2RS re-use in our > > modules. > > > > > I think it would be most efficient if a WG considered complete management > of a new protocol feature, and chartered configuration, I2RS, monitoring, > and notification support at the same time. That was a likely outcome. Since other WGs aren't (to my knowledge) heavily focused on building their protocol management in yang yet, this suggests a significant amount of coordination with the related WGs if we want to define I2RS functionality impacting them. In effect, they might get their yang written for free. :-) This does, obviously, have charter impact. > The IETF approach for the last 2 decades has been to leave most > of the management to the vendor CLI. The problem with this approach > is that over-laying monitoring systems (vendor + standard) > is easy, but not true for APIs that change the system. Once the vendor API > is in > place, it is very difficult to overlay an incompatible standard API. Been there, done that and had it... "shape" my opinion of SNMP. I'll leave it at that. -- Jeff From nobody Thu May 1 10:47: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 3B3781A6FD9 for ; Thu, 1 May 2014 10:47:34 -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 4VksI4Rqt_Tf for ; Thu, 1 May 2014 10:47:32 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7051A6FCF for ; Thu, 1 May 2014 10:47:32 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ih12so3219266qab.24 for ; Thu, 01 May 2014 10:47:30 -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=eT8fbFfwuLetNhdaxI/NR2EiSwc+TJV1PLgs/5yjrfs=; b=ZaFmutxswH9cByzzlaZfJ/9d1PrRH8mtTujKaXcnFr1r3P73RtXFQtXJups1kiAH4/ qeI6q5nNaziTP1c2LDkdmhFIgMKE5t8MRzN3a89VkmPBUaGx0Pt/dD0vqL3baZUifk4o vSmmysez982q7tFxvyDEMS3azsvibnGDaHM8wSm4BO1EiwQUSk/TsZtA/ri2FwqW+BzX Wrg8KSl18yNvrXGiTU5e9S6bhfODRFE5aGR/FPaf5uVAmMDb2peLprzTOAx206eUO8Wr zDyKdB1vYU2H3UVzG0oo6WjfouLZ4BwGsja2Yrj13id3DOqZSN/ikPGbimklNyKA2vRJ gRVw== X-Gm-Message-State: ALoCoQmgzhT1GtySl8taehJd3R16R4mKY2UpEkFQUbLax0n47nfjV+oX5ae2X2b6tzzEMwjDtZOX MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr15591429qaa.7.1398966449949; Thu, 01 May 2014 10:47:29 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 10:47:29 -0700 (PDT) In-Reply-To: <20140501171442.GA32492@pfrc> References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> Date: Thu, 1 May 2014 10:47:29 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7bea39864d5f6304f85a42f3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wBd4oU4QprYIWy0F1ZXMhsslBcY Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 17:47:34 -0000 --047d7bea39864d5f6304f85a42f3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 10:14 AM, Jeffrey Haas wrote: > On Thu, May 01, 2014 at 09:44:35AM -0700, Andy Bierman wrote: > > > If within the same module, there is the implication of a requirement > for > > > changes to the language to permit them to do so harmoniously. > > > > > > > > I prefer 1 module, but it is not that simple. The user-defined typedefs > and > > identities (for identityref data type) can be shared (e.g. imported from > > a common-types module). Even if the data nodes are separate, the > > definitions can share YANG semantics in various ways. > > > > > > New YANG statements (or extensions) to identify data affected by I2RS > > will allow the data models to be mixed in the same module, augment across > > modules, etc. > > Enumerating those changes would be helpful. > This has been done a few times. Most recently April 22: http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > > > If across different modules, there is the suggestion but not > requirement > > > that as Working Groups provide yang modules for managing their > components > > > that they are structured in such a way to permit I2RS re-use in our > > > modules. > > > > > > > > I think it would be most efficient if a WG considered complete management > > of a new protocol feature, and chartered configuration, I2RS, monitoring, > > and notification support at the same time. > > That was a likely outcome. Since other WGs aren't (to my knowledge) > heavily > focused on building their protocol management in yang yet, this suggests a > significant amount of coordination with the related WGs if we want to > define > I2RS functionality impacting them. In effect, they might get their yang > written for free. :-) > > This does, obviously, have charter impact. > > > The IETF approach for the last 2 decades has been to leave most > > of the management to the vendor CLI. The problem with this approach > > is that over-laying monitoring systems (vendor + standard) > > is easy, but not true for APIs that change the system. Once the vendor > API > > is in > > place, it is very difficult to overlay an incompatible standard API. > > Been there, done that and had it... "shape" my opinion of SNMP. > I'll leave it at that. > I don't see how standard I2RS data could use local config data unless it was also standardized. > > -- Jeff > Andy --047d7bea39864d5f6304f85a42f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 10:14 AM, Jeffrey Haas <= ;jhaas@pfrc.org>= wrote:
On Thu, May 01, 2014 at 09:44:35AM -0700, Andy Bierman wro= te:
> > If within the same module, there is the implication of a requirem= ent for
> > changes to the language to permit them to do so harmoniously.
> >
> >
> I prefer 1 module, but it is not that simple. The user-defined typedef= s and
> identities (for identityref data type) can be shared (e.g. imported fr= om
> a common-types module). Even if the data nodes are separate, the
> definitions can share YANG semantics in various ways.
>
>
> New YANG statements (or extensions) to identify data affected by I2RS<= br> > will allow the data models to be mixed in the same module, augment acr= oss
> modules, etc.

Enumerating those changes would be helpful.

=
This has been done a few times.
Most recently April 22:
http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html<= /div>

=A0

> > If across different modules, there is the suggestion but not requ= irement
> > that as Working Groups provide yang modules for managing their co= mponents
> > that they are structured in such a way to permit I2RS re-use in o= ur
> > modules.
> >
> >
> I think it would be most efficient if a WG considered complete managem= ent
> of a new protocol feature, and chartered configuration, I2RS, monitori= ng,
> and notification support at the same time.

That was a likely outcome. =A0Since other WGs aren't (to my knowledge) = heavily
focused on building their protocol management in yang yet, this suggests a<= br> significant amount of coordination with the related WGs if we want to defin= e
I2RS functionality impacting them. =A0In effect, they might get their yang<= br> written for free. :-)

This does, obviously, have charter impact.

> The IETF approach for the last 2 decades has been to leave most
> of the management to the vendor CLI. The problem with this approach > is that over-laying monitoring systems (vendor + standard)
> is easy, but not true for APIs that change the system. =A0Once the ven= dor API
> is in
> place, it is very difficult to overlay an incompatible standard API.
Been there, done that and had it... "shape" my opinion of SNMP. I'll leave it at that.

I don't = see how standard I2RS data could use local config data unless it
= was also standardized.

=A0

-- Jeff

Andy

--047d7bea39864d5f6304f85a42f3-- From nobody Thu May 1 10:57:46 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 4F0D11A6FCF for ; Thu, 1 May 2014 10:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 2tz-e6hhGfdJ for ; Thu, 1 May 2014 10:57:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 047E51A0919 for ; Thu, 1 May 2014 10:57:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D2B7C453; Thu, 1 May 2014 13:57:41 -0400 (EDT) Date: Thu, 1 May 2014 13:57:41 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140501175741.GB32492@pfrc> References: <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@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/Wuc69bKx8zNelLADQLXxRGAp9iQ Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 17:57:44 -0000 Andy, On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: > This has been done a few times. > Most recently April 22: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html I should respond there, but this was one of the messages that prompted my question about data (operational state) vs. ephemeral config. I don't believe we want to say "this is the module for monitoring the rib and now you can write to it". IMO, I think we want multiple data stores for configuration for adding routes to the rib. (I also thought the notification example was clear and didn't need further comment.) > I don't see how standard I2RS data could use local config data unless it > was also standardized. Basically, we want to make sure there is WG coordination on modules. If WG has a module and it makes sense for I2RS to use it/extend it, that's great when it makes sense. Similarly, if we find the need to create an I2RS module for work covered by another WG, we want to make sure we leave as much re-usable infra for them as we can. -- Jeff From nobody Thu May 1 10:59: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 48C641A7001 for ; Thu, 1 May 2014 10:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 DnooNI8v85O1 for ; Thu, 1 May 2014 10:59:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E72331A6FFB for ; Thu, 1 May 2014 10:59:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1C96CC2E0; Thu, 1 May 2014 13:59:47 -0400 (EDT) Date: Thu, 1 May 2014 13:59:47 -0400 From: Jeffrey Haas To: Jeffrey Haas Message-ID: <20140501175947.GC32492@pfrc> References: <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140501175741.GB32492@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/90udw6y8WIJj9_q0wtQkS5SYIRk Cc: "i2rs@ietf.org" , Andy Bierman , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 17:59:50 -0000 [followup to myself since I hit send too quickly] On Thu, May 01, 2014 at 01:57:41PM -0400, Jeffrey Haas wrote: > Andy, > > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: > > This has been done a few times. > > Most recently April 22: > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > I should respond there, but this was one of the messages that prompted my > question about data (operational state) vs. ephemeral config. > > I don't believe we want to say "this is the module for monitoring the rib > and now you can write to it". > > IMO, I think we want multiple data stores for configuration for adding > routes to the rib. Unless the implication is that the i2rs ephemeral data store is simply using the operational state model to implement "edit-data". If that was implied, I missed it first time around. -- Jeff From nobody Thu May 1 11:04: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 ABE311A701E for ; Thu, 1 May 2014 11:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 CZkg5mDAXZZU for ; Thu, 1 May 2014 11:04:48 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6F1A7018 for ; Thu, 1 May 2014 11:04:48 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D4099278BF22; Thu, 1 May 2014 14:04:45 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B4F071EB-5F87-4B46-9D71-206BA3062A67"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <20140501175741.GB32492@pfrc> Date: Thu, 1 May 2014 14:04:43 -0400 Message-Id: <06CE1970-AFED-4DE1-A966-062287551BC6@lucidvision.com> References: <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pITsNsvfvE14iEMee8KeRzvmLFo Cc: "i2rs@ietf.org" , Andy Bierman , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 18:04:50 -0000 --Apple-Mail=_B4F071EB-5F87-4B46-9D71-206BA3062A67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 1, 2014:1:57 PM, at 1:57 PM, Jeffrey Haas wrote: > Andy, >=20 > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: >> This has been done a few times. >> Most recently April 22: >> http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html >=20 > I should respond there, but this was one of the messages that prompted = my > question about data (operational state) vs. ephemeral config. >=20 > I don't believe we want to say "this is the module for monitoring the = rib > and now you can write to it". >=20 > IMO, I think we want multiple data stores for configuration for adding > routes to the rib. >=20 > (I also thought the notification example was clear and didn't need = further > comment.) There was another important point in Andy's post: that its = possible to model that with Yang. > I don't see how standard I2RS data could use local config data unless = it >> was also standardized. >=20 > Basically, we want to make sure there is WG coordination on modules. > If WG has a module and it makes sense for I2RS to use it/extend it, = that's > great when it makes sense. Similarly, if we find the need to create = an I2RS > module for work covered by another WG, we want to make sure we leave > as much re-usable infra for them as we can. For sure, but again, the point is that it is possible - and this = could be a good starting point to move forward with rather than debating = the theory of other models/etc...=20 --Tom >=20 > -- Jeff >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_B4F071EB-5F87-4B46-9D71-206BA3062A67 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 iQIcBAEBCgAGBQJTYoy7AAoJEPcO+I7eiUJZipkQAKeRvdst+hinz7patdbW/XXf xLzfdeEOYu7b+/My8bc4pK7OTXgd5jdRAHetJ4m7/mtdfK9ytqczyC3EJxrOmGht zJ9NPlraWtKqKR9hgRRLBkDlQaTKAVpCnAVSv+6l9sWcDq7XCDgf8bBsUhqlyVpl X5/NMJ1k61OR7qEO8ic3G45ThJnDUal7LbKD74/2VQOz9Y8RC30HUkbEpiaKxscd JOP/zP8ElfKZlV4ICN25MtgrrQ/9wBnxFanXAoYuYZZPFQe2diRXmaj+0sUkH9KG g+JvWaL3CW+2qy2QryjIPUo6mwUTjgxPNnVK4ApshoZ4SJbUzkwMlDGoOboQBYwY r6iKffAc0SznUm6ccMNaHR2qVNPYIRv4TUGZ1MG1zblL9XyWn97KFXDO4UBTbPjZ jh2TRVgakLiGjVuw+EuRydy66cmdLOrExwIzR1SYQZoW6tFJ6MWrMGGlreN6aP9H Y2kITAveDhWDn+V0TLbct7nFxD62L0/2ZrlwnivzCZh+pojgPEqopxFgS0UG76q6 ddKhJh+0WfUfnEctVZRS5OokfPP0UnrrbbWpYaOjH8+47vYHdnE16/skp2foSBvA r3WT6NTzoKI3CTtGU/74btb2PAGhgDklaDkA/HqU7ox3vJEX871KJ06cjuyJmYv6 xd5UhbvGf2BE/XOvGCyv =KDA2 -----END PGP SIGNATURE----- --Apple-Mail=_B4F071EB-5F87-4B46-9D71-206BA3062A67-- From nobody Thu May 1 11:10:19 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 4DA501A702A for ; Thu, 1 May 2014 11:10:15 -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 E7pOqNPUBQk4 for ; Thu, 1 May 2014 11:10:14 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1911C1A093A for ; Thu, 1 May 2014 11:10:14 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so3324733qap.9 for ; Thu, 01 May 2014 11:10:12 -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=nnz0X3Jn1xI1ObrqIp/L4LIuxIAFLIS5RLckOldkHqY=; b=QosWmDbJ5mTDSGoq7X6BkyHnsuVSe3AdXQcAL1xUDktXIBEVGc/g6QDZZG0OLZxwDq xOin6BkukCOOiFxriJ3kzRMyQbzYuh0Tm+DPtvP0CPYYIRTYxYCktNUaqtaW0FC+rsIp Kovmxy04PCcrSHfF+2zjFqsEX8ynGf/Z83kQy3rsT24cXVNhMHt8s3pec5Cx2Qu5x3uI xdRHVlv60Yp34oBIt7K5Lb+Ae/JdrgrKdaEphr5X9gu8SzMr57WQMbGFsjI7pSRGxzLs poYXKt9H8IUwG7OFVXSwvQHpYbKQcJMg8B57UdbHqob/Kmwf5QdU3y99H/VKDd+J1b/b rWQg== X-Gm-Message-State: ALoCoQnxVbI1LPCgcXoRoFL2QctAOlqhZHO4m/8dySht5z/OWyhMce+VWKHHPftj5MvJphB89Xoe MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr14809809qge.34.1398967811936; Thu, 01 May 2014 11:10:11 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 11:10:11 -0700 (PDT) In-Reply-To: <20140501175741.GB32492@pfrc> References: <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> Date: Thu, 1 May 2014 11:10:11 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a113abfd87bbd6b04f85a934a Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/aDLAs-SENOZvL5e7Ca3nFA6gZrU Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 18:10:15 -0000 --001a113abfd87bbd6b04f85a934a Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas wrote: > Andy, > > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: > > This has been done a few times. > > Most recently April 22: > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > I should respond there, but this was one of the messages that prompted my > question about data (operational state) vs. ephemeral config. > > I don't believe we want to say "this is the module for monitoring the rib > and now you can write to it". > that is not what the "edit-data" extension does. It is a sub-statement that identifies I2RS editable data no matter what YANG module is used to define the data. The YANG config=true statement identifies a data node as part of the configuration datastore. The edit-data extension cannot be used on a config=true node, only non-configuration. module foo { ... import i2rs { prefix i2rs; } container config-data { // NETCONF definitions here } container i2rs-data { config false; i2rs:edit-data; } container oper-data { config false; // plain read-only data } } Nesting is also possible -- up to the data modeler to decide what to use: 1) i2rs-data inside config-data 2) i2rs-data inside oper-data 3) oper-data inside i2rs-data > IMO, I think we want multiple data stores for configuration for adding > routes to the rib. > How many does I2RS need for itself? > > (I also thought the notification example was clear and didn't need further > comment.) > > > I don't see how standard I2RS data could use local config data unless it > > was also standardized. > > Basically, we want to make sure there is WG coordination on modules. > If WG has a module and it makes sense for I2RS to use it/extend it, that's > great when it makes sense. Similarly, if we find the need to create an > I2RS > module for work covered by another WG, we want to make sure we leave > as much re-usable infra for them as we can. > > -- Jeff > Andy --001a113abfd87bbd6b04f85a934a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas <= ;jhaas@pfrc.org>= wrote:
Andy,

On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote:
> This has been done a few times.
> Most recently April 22:
> http://www.ietf.org/mail-archive/web/i2rs/current/m= sg01474.html

I should respond there, but this was one of the messages that prompted my question about data (operational state) vs. ephemeral config.

I don't believe we want to say "this is the module for monitoring = the rib
and now you can write to it".

that= is not what the "edit-data" extension does.
It is a su= b-statement that identifies I2RS editable data no matter what
YANG module is used to define the data. =A0The YANG config=3Dtrue statement=
identifies a data node as part of the configuration datastor= e. The edit-data
extension cannot be used on a config=3Dtrue node= , only non-configuration.

module foo {
=A0 =A0...
=A0 =A0impo= rt i2rs { prefix i2rs; }

=A0 =A0container config-d= ata {
=A0 =A0 =A0 =A0// NETCONF definitions here
=A0 = =A0 }

=A0 =A0 container i2rs-data {
=A0 =A0 =A0 =A0config false;
=A0 =A0 =A0 =A0i2rs:edit-data;
=A0 =A0 }

<= /div>
=A0 =A0 container oper-data {
=A0 =A0 =A0 config false;=
=A0 =A0 =A0 =A0// plain read-only data
=A0 =A0 }
}


Nesting = is also possible -- up to the data modeler to decide what to use:

=A0 =A01) i2rs-data inside config-data
=A0 =A02) = i2rs-data inside oper-data
=A0 =A03) oper-data inside i2rs-data


IMO, I think we want multiple data stores for configuration for adding
routes to the rib.


How m= any does I2RS need for itself?

=A0

(I also thought the notification example was clear and didn't need furt= her
comment.)

> I don't see how standard I2RS data could use local config data unl= ess it
> was also standardized.

Basically, we want to make sure there is WG coordination on modules.
If WG has a module and it makes sense for I2RS to use it/extend it, that= 9;s
great when it makes sense. =A0Similarly, if we find the need to create an I= 2RS
module for work covered by another WG, we want to make sure we leave
as much re-usable infra for them as we can.

-- Jeff

Andy

--001a113abfd87bbd6b04f85a934a-- From nobody Thu May 1 11:17: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 2BC2D1A08E3 for ; Thu, 1 May 2014 11:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.651, 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 ss5CdjWwJykX for ; Thu, 1 May 2014 11:17:09 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 35F931A08B3 for ; Thu, 1 May 2014 11:17:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 56021C2E0; Thu, 1 May 2014 14:17:06 -0400 (EDT) Date: Thu, 1 May 2014 14:17:06 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140501181706.GA4456@pfrc> References: <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@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/ykfa0Ef1TLIhCdfyGd9URNRhKds Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 18:17:10 -0000 Andy, On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote: > that is not what the "edit-data" extension does. > It is a sub-statement that identifies I2RS editable data no matter what > YANG module is used to define the data. The YANG config=true statement > identifies a data node as part of the configuration datastore. The edit-data > extension cannot be used on a config=true node, only non-configuration. > > module foo { > ... > import i2rs { prefix i2rs; } > > container config-data { > // NETCONF definitions here > } > > container i2rs-data { > config false; > i2rs:edit-data; > } You're crystal clear to me now. Thank you. This was not permitting I2RS to be able to interact with/overlay part of config-data (per your example) as I had hoped. > Nesting is also possible -- up to the data modeler to decide what to use: > > 1) i2rs-data inside config-data > 2) i2rs-data inside oper-data > 3) oper-data inside i2rs-data What I had been hoping was for config-data to permit elements that were effectively config true,i2rs. (Or s/i2rs/ephemeral/ as per previous messagees.) > > IMO, I think we want multiple data stores for configuration for adding > > routes to the rib. > > How many does I2RS need for itself? To clarify, a config-data data store, an i2rs-data datastore where the i2rs portion may overlap. Since I'm apparently not making my point well, I'll see if I can mockup my understanding in a netconf like transaction. (For Dean, I haven't caught up in my reading to restconf, else I'd do that.) -- Jeff From nobody Thu May 1 11:29:01 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 5B92A1A092D for ; Thu, 1 May 2014 11:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 DPv31bAtk9_o for ; Thu, 1 May 2014 11:28:58 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A228B1A0919 for ; Thu, 1 May 2014 11:28:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DB6BE1CA60B2; Thu, 1 May 2014 11:28:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-103.clppva.east.verizon.net [70.106.134.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D37161CA60B1; Thu, 1 May 2014 11:28:55 -0700 (PDT) Message-ID: <53629259.1080101@joelhalpern.com> Date: Thu, 01 May 2014 14:28:41 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , Andy Bierman References: <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <20140501181706.GA4456@pfrc> In-Reply-To: <20140501181706.GA4456@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/62oMZVPdCS977b0tuczgJr49FmU Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 18:29:00 -0000 Jeff, I think the problem is subtler. Even if I2RS wants to manipulate data represented in the config-true (CLI equivalent) tree, the I2RS data is still actually separate. If you ask what the CLI has set, you get one answer. If you ask what I2rS has set you get a different answer. And if you ask what is actually operating you get the result of the arbitration. At least that is what the architecture describes. This clearly can be modeled in YANG. It may take a little more effort. Yours, Joel On 5/1/14, 2:17 PM, Jeffrey Haas wrote: > Andy, > > On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote: >> that is not what the "edit-data" extension does. >> It is a sub-statement that identifies I2RS editable data no matter what >> YANG module is used to define the data. The YANG config=true statement >> identifies a data node as part of the configuration datastore. The edit-data >> extension cannot be used on a config=true node, only non-configuration. >> >> module foo { >> ... >> import i2rs { prefix i2rs; } >> >> container config-data { >> // NETCONF definitions here >> } >> >> container i2rs-data { >> config false; >> i2rs:edit-data; >> } > > You're crystal clear to me now. Thank you. This was not permitting I2RS to > be able to interact with/overlay part of config-data (per your example) as I > had hoped. > >> Nesting is also possible -- up to the data modeler to decide what to use: >> >> 1) i2rs-data inside config-data >> 2) i2rs-data inside oper-data >> 3) oper-data inside i2rs-data > > What I had been hoping was for config-data to permit elements that > were effectively config true,i2rs. > > (Or s/i2rs/ephemeral/ as per previous messagees.) > >>> IMO, I think we want multiple data stores for configuration for adding >>> routes to the rib. >> >> How many does I2RS need for itself? > > To clarify, a config-data data store, an i2rs-data datastore where > the i2rs portion may overlap. > > Since I'm apparently not making my point well, I'll see if I can mockup my > understanding in a netconf like transaction. (For Dean, I haven't caught up > in my reading to restconf, else I'd do that.) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu May 1 12:08:21 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 F237F1A6F78 for ; Thu, 1 May 2014 12:08:19 -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 4Phi75laz5qu for ; Thu, 1 May 2014 12:08:18 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id D27781A0928 for ; Thu, 1 May 2014 12:08:17 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id j7so3372962qaq.34 for ; Thu, 01 May 2014 12:08:15 -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=P9x8tVYMgNmF2M4Q16IauvhZH614VEFYIMPtHmzCraY=; b=IeSaHoCCIxWrhcP5pRS/Fzy/CTXXgozI344r225GopZsl/vCjBRfCEWyanLrfWsGnQ ytWVS1vFys2NiUyuBDL0ElcZuXNVfW8q0ZyhOKdJMv05JUXsd/W75XrRFtpvao5w8XoD qRa/rJSy7ydbdYNieG9qo+2XUP1+1SMlXshrhl7BDWvkrz29GZ3r0ecIpdurXQHEOQtH SozhRuvxCGqe4d4e4lYmPqB/k+fD/PbYRXZGmT0Szp4JB8gmxQtbdr50xVujaqSONcFb DWkb+OwwOl/veZ/oGb4jHait1BYaMGfFsldNvNRTm+oHrIi67bmQFTTqi42pSKO4GfSR VN6A== X-Gm-Message-State: ALoCoQlhmmtDyShuHMxv9xSAL0Qp2DEV4TqPy1USUROLlrkjb5DI8qQREC5Fk3hT8IjGDiFL0N26 MIME-Version: 1.0 X-Received: by 10.140.92.99 with SMTP id a90mr15180536qge.34.1398971295682; Thu, 01 May 2014 12:08:15 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Thu, 1 May 2014 12:08:15 -0700 (PDT) In-Reply-To: <53629259.1080101@joelhalpern.com> References: <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <20140501181706.GA4456@pfrc> <53629259.1080101@joelhalpern.com> Date: Thu, 1 May 2014 12:08:15 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113abfd8216b0a04f85b63c5 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7YtX3q0s-nClTgHTz5T_VXAAZGA Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 19:08:20 -0000 --001a113abfd8216b0a04f85b63c5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern wrote: > Jeff, I think the problem is subtler. > Even if I2RS wants to manipulate data represented in the config-true (CLI > equivalent) tree, the I2RS data is still actually separate. If you ask > what the CLI has set, you get one answer. If you ask what I2rS has set you > get a different answer. And if you ask what is actually operating you get > the result of the arbitration. > At least that is what the architecture describes. > > This clearly can be modeled in YANG. It may take a little more effort. > > I didn't think the I2RS charter covered writing to the local configuration, that is maintained by NETCONF. I hope not. But if there is some intent to support a "copy-to-local-config" option in the I2RS protocol, then a mapping from the I2RS data to the local config data would be needed. Yours, > Joel > Andy > > On 5/1/14, 2:17 PM, Jeffrey Haas wrote: > >> Andy, >> >> On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote: >> >>> that is not what the "edit-data" extension does. >>> It is a sub-statement that identifies I2RS editable data no matter what >>> YANG module is used to define the data. The YANG config=true statement >>> identifies a data node as part of the configuration datastore. The >>> edit-data >>> extension cannot be used on a config=true node, only non-configuration. >>> >>> module foo { >>> ... >>> import i2rs { prefix i2rs; } >>> >>> container config-data { >>> // NETCONF definitions here >>> } >>> >>> container i2rs-data { >>> config false; >>> i2rs:edit-data; >>> } >>> >> >> You're crystal clear to me now. Thank you. This was not permitting I2RS >> to >> be able to interact with/overlay part of config-data (per your example) >> as I >> had hoped. >> >> Nesting is also possible -- up to the data modeler to decide what to use: >>> >>> 1) i2rs-data inside config-data >>> 2) i2rs-data inside oper-data >>> 3) oper-data inside i2rs-data >>> >> >> What I had been hoping was for config-data to permit elements that >> were effectively config true,i2rs. >> >> (Or s/i2rs/ephemeral/ as per previous messagees.) >> >> IMO, I think we want multiple data stores for configuration for adding >>>> routes to the rib. >>>> >>> >>> How many does I2RS need for itself? >>> >> >> To clarify, a config-data data store, an i2rs-data datastore where >> the i2rs portion may overlap. >> >> Since I'm apparently not making my point well, I'll see if I can mockup my >> understanding in a netconf like transaction. (For Dean, I haven't caught >> up >> in my reading to restconf, else I'd do that.) >> >> -- Jeff >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> --001a113abfd8216b0a04f85b63c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern = <jmh@joelhalper= n.com> wrote:
Jeff, I think the problem is subtler.
Even if I2RS wants to manipulate data represented in the config-true (CLI e= quivalent) tree, the I2RS data is still actually separate. =A0If you ask wh= at the CLI has set, you get one answer. =A0If you ask what I2rS has set you= get a different answer. =A0And if you ask what is actually operating you g= et the result of the arbitration.
At least that is what the architecture describes.

This clearly can be modeled in YANG. =A0It may take a little more effort.

I didn't think the I2RS charter co= vered writing to the local configuration,
that is maintained by N= ETCONF. =A0I hope not.

But if there is some intent= to support a "copy-to-local-config" option
in the I2RS protocol, then a mapping from the I2RS data to the
local config data would be needed.


Yours,
Joel

Andy
=A0

On 5/1/14, 2:17 PM, Jeffrey Haas wrote:
Andy,

On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote:
that is not what the "edit-data" extension does.
It is a sub-statement that identifies I2RS editable data no matter what
YANG module is used to define the data. =A0The YANG config=3Dtrue statement=
identifies a data node as part of the configuration datastore. The edit-dat= a
extension cannot be used on a config=3Dtrue node, only non-configuration.
module foo {
=A0 =A0 ...
=A0 =A0 import i2rs { prefix i2rs; }

=A0 =A0 container config-data {
=A0 =A0 =A0 =A0 // NETCONF definitions here
=A0 =A0 =A0}

=A0 =A0 =A0container i2rs-data {
=A0 =A0 =A0 =A0 config false;
=A0 =A0 =A0 =A0 i2rs:edit-data;
=A0 =A0 =A0}

You're crystal clear to me now. Thank you. =A0This was not permitting I= 2RS to
be able to interact with/overlay part of config-data (per your example) as = I
had hoped.

Nesting is also possible -- up to the data modeler to decide what to use:
=A0 =A0 1) i2rs-data inside config-data
=A0 =A0 2) i2rs-data inside oper-data
=A0 =A0 3) oper-data inside i2rs-data

What I had been hoping was for config-data to permit elements that
were effectively config true,i2rs.

(Or s/i2rs/ephemeral/ as per previous messagees.)

IMO, I think we want multiple data stores for configuration for adding
routes to the rib.

How many does I2RS need for itself?

To clarify, a config-data data store, an i2rs-data datastore where
the i2rs portion may overlap.

Since I'm apparently not making my point well, I'll see if I can mo= ckup my
understanding in a netconf like transaction. =A0(For Dean, I haven't ca= ught up
in my reading to restconf, else I'd do that.)

-- Jeff

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


--001a113abfd8216b0a04f85b63c5-- From nobody Thu May 1 12:10: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 E933F1A6FF6 for ; Thu, 1 May 2014 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.651, 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 lK7eghEawkjJ for ; Thu, 1 May 2014 12:10:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 086F51A0928 for ; Thu, 1 May 2014 12:10:43 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id CB37F278C188; Thu, 1 May 2014 15:10:40 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_60D1B12E-CE2A-4919-BD6A-19F4BC607641"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Thu, 1 May 2014 15:10:38 -0400 Message-Id: <5BF94065-DC78-4A4B-82EB-3FBBF8A1052B@lucidvision.com> References: <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <20140501181706.GA4456@pfrc> <53629259.1080101@joelhalpern.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/iWZVvvUgXHlFA8mcfoJCKKh_EII Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 19:10:45 -0000 --Apple-Mail=_60D1B12E-CE2A-4919-BD6A-19F4BC607641 Content-Type: multipart/alternative; boundary="Apple-Mail=_86BBA682-5072-4DF5-9589-4A194BE83E9F" --Apple-Mail=_86BBA682-5072-4DF5-9589-4A194BE83E9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 1, 2014:3:08 PM, at 3:08 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern = wrote: > Jeff, I think the problem is subtler. > Even if I2RS wants to manipulate data represented in the config-true = (CLI equivalent) tree, the I2RS data is still actually separate. If you = ask what the CLI has set, you get one answer. If you ask what I2rS has = set you get a different answer. And if you ask what is actually = operating you get the result of the arbitration. > At least that is what the architecture describes. >=20 > This clearly can be modeled in YANG. It may take a little more = effort. >=20 >=20 > I didn't think the I2RS charter covered writing to the local = configuration, > that is maintained by NETCONF. I hope not. >=20 > But if there is some intent to support a "copy-to-local-config" option > in the I2RS protocol, then a mapping from the I2RS data to the > local config data would be needed. Right. The thinking was to include some option in the protocol = extensions to trigger a copy-to-local-config "later" either of the = entire running config, or parts of it. But the normal operation was only = (and as quickly as possible) to the running config/rib/system. --Tom >=20 >=20 > Yours, > Joel >=20 > Andy > =20 >=20 > On 5/1/14, 2:17 PM, Jeffrey Haas wrote: > Andy, >=20 > On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote: > that is not what the "edit-data" extension does. > It is a sub-statement that identifies I2RS editable data no matter = what > YANG module is used to define the data. The YANG config=3Dtrue = statement > identifies a data node as part of the configuration datastore. The = edit-data > extension cannot be used on a config=3Dtrue node, only = non-configuration. >=20 > module foo { > ... > import i2rs { prefix i2rs; } >=20 > container config-data { > // NETCONF definitions here > } >=20 > container i2rs-data { > config false; > i2rs:edit-data; > } >=20 > You're crystal clear to me now. Thank you. This was not permitting = I2RS to > be able to interact with/overlay part of config-data (per your = example) as I > had hoped. >=20 > Nesting is also possible -- up to the data modeler to decide what to = use: >=20 > 1) i2rs-data inside config-data > 2) i2rs-data inside oper-data > 3) oper-data inside i2rs-data >=20 > What I had been hoping was for config-data to permit elements that > were effectively config true,i2rs. >=20 > (Or s/i2rs/ephemeral/ as per previous messagees.) >=20 > IMO, I think we want multiple data stores for configuration for adding > routes to the rib. >=20 > How many does I2RS need for itself? >=20 > To clarify, a config-data data store, an i2rs-data datastore where > the i2rs portion may overlap. >=20 > Since I'm apparently not making my point well, I'll see if I can = mockup my > understanding in a netconf like transaction. (For Dean, I haven't = caught up > in my reading to restconf, else I'd do that.) >=20 > -- Jeff >=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=_86BBA682-5072-4DF5-9589-4A194BE83E9F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On May 1, 2014:3:08 PM, at 3:08 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Jeff, I think the problem is subtler.
Even if I2RS wants to manipulate data represented in the config-true (CLI equivalent) tree, the I2RS data is still actually separate.  If you ask what the CLI has set, you get one answer.  If you ask what I2rS has set you get a different answer.  And if you ask what is actually operating you get the result of the arbitration.
At least that is what the architecture describes.

This clearly can be modeled in YANG.  It may take a little more effort.


I didn't think the I2RS charter covered writing to the local configuration,
that is maintained by NETCONF.  I hope not.

But if there is some intent to support a "copy-to-local-config" option
in the I2RS protocol, then a mapping from the I2RS data to the
local config data would be needed.

Right. The thinking was to include some option in the protocol extensions to trigger a copy-to-local-config "later" either of the entire running config, or parts of it. But the normal operation was only (and as quickly as possible) to the running config/rib/system.

--Tom




Yours,
Joel

Andy
 

On 5/1/14, 2:17 PM, Jeffrey Haas wrote:
Andy,

On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote:
that is not what the "edit-data" extension does.
It is a sub-statement that identifies I2RS editable data no matter what
YANG module is used to define the data.  The YANG config=true statement
identifies a data node as part of the configuration datastore. The edit-data
extension cannot be used on a config=true node, only non-configuration.

module foo {
    ...
    import i2rs { prefix i2rs; }

    container config-data {
        // NETCONF definitions here
     }

     container i2rs-data {
        config false;
        i2rs:edit-data;
     }

You're crystal clear to me now. Thank you.  This was not permitting I2RS to
be able to interact with/overlay part of config-data (per your example) as I
had hoped.

Nesting is also possible -- up to the data modeler to decide what to use:

    1) i2rs-data inside config-data
    2) i2rs-data inside oper-data
    3) oper-data inside i2rs-data

What I had been hoping was for config-data to permit elements that
were effectively config true,i2rs.

(Or s/i2rs/ephemeral/ as per previous messagees.)

IMO, I think we want multiple data stores for configuration for adding
routes to the rib.

How many does I2RS need for itself?

To clarify, a config-data data store, an i2rs-data datastore where
the i2rs portion may overlap.

Since I'm apparently not making my point well, I'll see if I can mockup my
understanding in a netconf like transaction.  (For Dean, I haven't caught up
in my reading to restconf, else I'd do that.)

-- Jeff

_______________________________________________
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

--Apple-Mail=_86BBA682-5072-4DF5-9589-4A194BE83E9F-- --Apple-Mail=_60D1B12E-CE2A-4919-BD6A-19F4BC607641 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 iQIcBAEBCgAGBQJTYpwuAAoJEPcO+I7eiUJZJ3MQALBD8U76GK6bWHLrQOWp7g1Z Cy/R6LPqn7BeHMIZaCRKhWn1geSKONuRDmcpKwo2XFQMHcURBR4+ggrf74maP3MB y3Ioemt9DlG+tQY/H293l7Xng5rLrO1B0oylbCJ7WZY58XkqvtFlAip7+805oA2G ska459qkXGUPBMVTV4piAuzvIC28GcwDkUELk56fcUh+ZCfMyFxuMhNKmGEVcRKR B2PDRi6mH8TMTcFvaniu/+ncQ+JEvEwAstspFjdXCBRDxiRq8sZT5RnfVqlvgrJ5 rm6gP1y2PNT5Qg7LNMNC0jP0HbuQEZVz5RvqH791SSySEEMyQj+SFTi0dn4iT93P cBNVLje0X8MxtiT9DFzaz4dTUPZDWPjO7K2pZgxondXfhEsrbz2RsLsyD6CfvZli nAEkpEqqRIg/Aa0E6I0uuwnJPY+eldNnoooxePG9f1SKYPjF1XC8DBc+dMtdIF3J Q8kWZ8zVJMQEcTFhTRnajFhUOD2JObNnPt6T7MSZQsLYDCFRtH6sReR16OgrBIa8 Ws3F3LxoGDEz4Tq78ZXG0y7V/3Ta/EagCjJe+gUa2AmzmoN/70RU2f0UkFWDFDFy F8ybxxccx3lAfVrQZrHA8ZCdja25z4vykytw3/SfQD9b6e0D/yjyV1uV12ilXvq+ Y6VpFO1t5rQG71uedWoy =pPE7 -----END PGP SIGNATURE----- --Apple-Mail=_60D1B12E-CE2A-4919-BD6A-19F4BC607641-- From nobody Thu May 1 12:28:18 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 740E31A700F for ; Thu, 1 May 2014 12:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 pjF-CYFycBNv for ; Thu, 1 May 2014 12:28:15 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF5B1A6FC7 for ; Thu, 1 May 2014 12:28:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 82A611CA696A; Thu, 1 May 2014 12:28:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-103.clppva.east.verizon.net [70.106.134.103]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 728811CA696D; Thu, 1 May 2014 12:28:12 -0700 (PDT) Message-ID: <5362A03D.1090907@joelhalpern.com> Date: Thu, 01 May 2014 15:27:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andy Bierman References: <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <20140501181706.GA4456@pfrc> <53629259.1080101@joelhalpern.com> 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/mLls5swlWw8TVH6eRt2UpBZ27Fg Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 01 May 2014 19:28:16 -0000 For clarity, I was trying to make sure we understood that they need to be separate stores. As far as I can tell there is no need for 'copy-to-local'. Yours, Joel On 5/1/14, 3:08 PM, Andy Bierman wrote: > > > > On Thu, May 1, 2014 at 11:28 AM, Joel M. Halpern > wrote: > > Jeff, I think the problem is subtler. > Even if I2RS wants to manipulate data represented in the config-true > (CLI equivalent) tree, the I2RS data is still actually separate. If > you ask what the CLI has set, you get one answer. If you ask what > I2rS has set you get a different answer. And if you ask what is > actually operating you get the result of the arbitration. > At least that is what the architecture describes. > > This clearly can be modeled in YANG. It may take a little more effort. > > > I didn't think the I2RS charter covered writing to the local configuration, > that is maintained by NETCONF. I hope not. > > But if there is some intent to support a "copy-to-local-config" option > in the I2RS protocol, then a mapping from the I2RS data to the > local config data would be needed. > > > Yours, > Joel > > > Andy > > > On 5/1/14, 2:17 PM, Jeffrey Haas wrote: > > Andy, > > On Thu, May 01, 2014 at 11:10:11AM -0700, Andy Bierman wrote: > > that is not what the "edit-data" extension does. > It is a sub-statement that identifies I2RS editable data no > matter what > YANG module is used to define the data. The YANG > config=true statement > identifies a data node as part of the configuration > datastore. The edit-data > extension cannot be used on a config=true node, only > non-configuration. > > module foo { > ... > import i2rs { prefix i2rs; } > > container config-data { > // NETCONF definitions here > } > > container i2rs-data { > config false; > i2rs:edit-data; > } > > > You're crystal clear to me now. Thank you. This was not > permitting I2RS to > be able to interact with/overlay part of config-data (per your > example) as I > had hoped. > > Nesting is also possible -- up to the data modeler to decide > what to use: > > 1) i2rs-data inside config-data > 2) i2rs-data inside oper-data > 3) oper-data inside i2rs-data > > > What I had been hoping was for config-data to permit elements that > were effectively config true,i2rs. > > (Or s/i2rs/ephemeral/ as per previous messagees.) > > IMO, I think we want multiple data stores for > configuration for adding > routes to the rib. > > > How many does I2RS need for itself? > > > To clarify, a config-data data store, an i2rs-data datastore where > the i2rs portion may overlap. > > Since I'm apparently not making my point well, I'll see if I can > mockup my > understanding in a netconf like transaction. (For Dean, I > haven't caught up > in my reading to restconf, else I'd do that.) > > -- Jeff > > _________________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/__listinfo/i2rs > > > From nobody Thu May 1 13:44: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 59F811A0990 for ; Thu, 1 May 2014 13:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 b7UMDTFqa_KP for ; Thu, 1 May 2014 13:44:04 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id EB8291A093E for ; Thu, 1 May 2014 13:44:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3427311F9; Thu, 1 May 2014 22:44:01 +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 UstfGITpbxbK; Thu, 1 May 2014 22:44:00 +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, 1 May 2014 22:44:00 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59C0C20017; Thu, 1 May 2014 22:44:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t-bDZUjmGSW1; Thu, 1 May 2014 22:43:59 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD15B20013; Thu, 1 May 2014 22:43:58 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id BBD9F2CC7BF9; Thu, 1 May 2014 22:43:57 +0200 (CEST) Date: Thu, 1 May 2014 22:43:57 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140501204357.GD34524@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Jeffrey Haas , Martin Bjorklund , i2rs@ietf.org, edc@google.com, ietfc@btconnect.com References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <20140501053839.GA33275@elstar.local> <20140501145748.GD1705@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140501145748.GD1705@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/si1n0xZKS-rc3uFjHrW2QJFSNqA Cc: i2rs@ietf.org, Martin Bjorklund , edc@google.com, ietfc@btconnect.com Subject: Re: [i2rs] consensus on I2RS protocol and model 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: Thu, 01 May 2014 20:44:06 -0000 On Thu, May 01, 2014 at 10:57:48AM -0400, Jeffrey Haas wrote: > On Thu, May 01, 2014 at 07:38:39AM +0200, Juergen Schoenwaelder wrote: > > On Wed, Apr 30, 2014 at 08:24:51PM -0400, Jeffrey Haas wrote: > > > > > > This is where I think we're getting stuck. There is some vagueness between > > > operational state that can be modified and ephemeral configuration. > > > > Are you saying there is a difference between 'writable operational > > state' and 'ephemeral configuration' but the difference is still > > unclear and hence vague? > > Yes and no. I'm still absorbing appropriate terminology from the N/Y RFCs > so please have patience with me. > > State that I2RS injects into a system may be intended to be ephemeral. > That state may overlap with state that is otherwise configured in the usual > configuration based datastore. E.g. static routes. > > It is clearly possible to generate yang for I2RS that duplicates as much of > the yang for that configured state (e.g. static routes). Yang provides > mechanisms to allow for re-use of the yang inputs (e.g. grouping) in another > module, provided that the original module was authored to enable re-use. > > My observation is that in cases where there may be significant overlap of > I2RS injected ephemeral state, e.g. static routes, that it might be > desirable to not have to have a separate I2RS yang module unless there are > differences that necessitate a new module. Effective, if I have my > terminology correct, to permit more than one datastore to be manipulated > using the same module. I.e. "running configuration" and "I2RS ephemeral". > > If such a thing were possible, then it would only compound the issues noted > in draft-bjorklund-netmod-operational since the configuration state for the > overlapping datastores also had related potentialy overlap in the > operational state. > > To offer an older analogy for comparison, if I can configure static routes > via CLI and simultaneously by SNMP and both configurations can serve as > inputs to the RIB, the installed static route may come from either of the > candidates and the active entry will be selected by a preference. > > In such a scenario, I still need to be able to see my configuration for the > CLI route and the SNMP installed route along with the actual route installed > in the RIB as active. All fine but the question was whether you see a difference between 'writable operational state' and 'ephemeral configuration'. You are concerned about YANG module organization, how to maintain generic reusable parts and stuff that is config or i2rs specific. And yes, this requires careful engineering and we will not always get it right (and in particular in the IETF this might happen since WGs run at different pace). But on the other hand, if I2RS chooses a different technology, there will likely be no reuse at all (and we could only hope to at least have consistent underlying information models). /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 Thu May 1 13:48:47 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 1586F1A7004; Thu, 1 May 2014 13:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Hq1o5V7Sa3sa; Thu, 1 May 2014 13:48:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5641A093E; Thu, 1 May 2014 13:48:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140501204842.13579.36939.idtracker@ietfa.amsl.com> Date: Thu, 01 May 2014 13:48:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gdY0lhOFxiq6yjcrw86WRgqeItw Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 20:48:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Interface to the Routing System Problem Statement Authors : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-ietf-i2rs-problem-statement-01.txt Pages : 10 Date : 2014-05-01 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 2 01:52: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 4AEA81A2130 for ; Fri, 2 May 2014 01:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6] 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 RosblqSThXvT for ; Fri, 2 May 2014 01:52:52 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCBF21A0371 for ; Fri, 2 May 2014 01:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4B14054054E; Fri, 2 May 2014 10:52:49 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcqVTEiGxmkE; Fri, 2 May 2014 10:52:44 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E140E5400EF; Fri, 2 May 2014 10:52:43 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "t.petch" In-Reply-To: References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 02 May 2014 10:52:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CZPdcBeoU_wgRpQZRFp89IJmZoU Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Operational State 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, 02 May 2014 08:52:53 -0000 Andy Bierman writes: > On Thu, May 1, 2014 at 2:01 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Jeffrey Haas" >> To: "t.petch" >> Cc: >> Sent: Thursday, May 01, 2014 1:34 AM >> > On Fri, Mar 28, 2014 at 10:48:13AM +0000, t.petch wrote: >> > > This tri-partite split has been the norm for Ops Area for many years >> > > now. >> > > It may or may not be appropriate for I2RS but I do think that I2RS >> > > should >> > > at least take cognizance of this in deciding what terms to use >> > >> > I think this is one of the clearest description of one of our >> problems - and >> > thus requirements - that I've seen thus far. :-) >> >> Yeah, problems are my speciality - I then look to Andy, Juergen, Lada >> and Martin for solutions:-) >> >> But, Jeff, you then say, in a parallel post >> >> "The issues then comes back to the ones noted in >> draft-bjorklund-netmod-operational-00: How do we distinguish >> operational, >> config or ephemeral config states? " >> >> whereas I see operational state, config and read-only statistics, with >> state (unqualified) referring to the first and last collectively! >> 'ephemeral' does not appear in Martin's I-D, nor would I expect it to - >> I don't see it as a concept in YANG/NETCONF. >> >> There is a separate issue of persistent and ephemeral in YANG, or, >> arguably, in NETCONF, which is also not documented AFAICS. This is >> probably of less interest to I2RS at this time. >> >> > N/Y treats config=true data nodes as special. > Collectively these data nodes form a configuration datastore. > This is only important for validation purposes -- determining > what is a "valid" running configuration. > > > If there is one running datastore, then, presumably, it is persistent >> (across reboots) - the documents appear not to say. If there is running >> and startup, presumably startup is persistent and running is not. But >> if you have running and acme-special datastores, then which is >> persistent? This is one of several issues, like operational state, that >> have surfaced from time to time and, for me, have not got nailed down as >> well as I would like, and so - surface from time to time. >> >> > > There is no "acme-special" sort of datastore. > There are only the standard datastores. Hmm, RFC 6241 says in sec. 5.1: "Additional configuration datastores MAY be defined by capabilities." I think Tom's points are valid. It's been my impression that the NETCONF spec remained somewhat underspecified in order to be able to accommodate different logics and data organizations of existing CLIs. Maybe it's time to set stricter rules because now it seems we will soon be dealing with different protocols accessing and changing the same data. Lada > > If the server supports the "startup" datastore, then > all configuration changes are saved manually to NV-storage. > If the client does not save changes, they are lost at the next reboot. > > If the server does not support the "startup" datastore then > the NV-storage must mirror the running configuration. All > config changes are saved automatically and immediately. > > Operational state is different than config because only config > is validated according the the YANG constraints. The operational > datastore may need some validation (e.g. field syntax check) > but it is not in anyway considered when validating the running datastore. > > IMO the difference between ephemeral config and operational state > is not the NV-storage, but the validation procedure that accepts or rejects > the write request. > > > Tom Petch >> >> > -- Jeff >> >> > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 2 02:10: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 54AC41A08DC for ; Fri, 2 May 2014 02:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 aCFtpbnzDb9B for ; Fri, 2 May 2014 02:09:59 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 403641A0371 for ; Fri, 2 May 2014 02:09:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 521E354054E; Fri, 2 May 2014 11:09:56 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTyfXM2equbo; Fri, 2 May 2014 11:09:52 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 3D63E5400EF; Fri, 2 May 2014 11:09:51 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Jeffrey Haas In-Reply-To: References: <000401cf4a96$e2e768c0$4001a8c0@gateway.2wire.net> <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Fri, 02 May 2014 11:09:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Zj5lMbnlK0BV-t6mYVejMSZSYkQ Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Operational State 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, 02 May 2014 09:10:02 -0000 Andy Bierman writes: > On Thu, May 1, 2014 at 8:23 AM, Jeffrey Haas wrote: > >> Andy, >> >> On Thu, May 01, 2014 at 08:02:17AM -0700, Andy Bierman wrote: >> > I think this has been explained several times already, >> > starting in the IETF 89 slides. >> > >> > I don't think anybody has said NC/RC/YANG could be used >> > as the I2RS protocol without a single change. People has said >> > it is the best starting point for I2RS. There seemed to be an >> overwhelming >> > consensus in the London meeting and on this mailing list to >> > use NC or RC + YANG as the I2RS starting point. >> >> Since we've not been very good about getting requirements explicitly >> listed, >> part of the point of my questions is to tease out those details. >> >> > IMO, there needs to be a new datastore in the architecture that >> > contains I2RS data. The I2RS protocol will define how this data is >> accessed. >> > It's really not that complicated. >> >> And thus, "we need a new data store". How it interacts with similarly >> configured objects in other datastores is another detail I'm trying to >> tease >> out as a requirement. >> >> > OK -- I hope this ASCII art helps. > > NC/RC I2RS > | | > V V > +-------------------+ +----------------+ > | local config | | i2rs-config | > +-------------------+ +----------------+ > | | > V V > +-------------------------------------------+ > | operational state | > +-------------------------------------------+ > > The operational state contains a data-model dependent mix > of local and i2rs configuration, + learned data from protocols. > The "i2rs-config" datastore is like a "fastpath" config (as Tom described). > The operations on the local-config datastore use different rules and the 2 > only > mix in the operational state. Right, but then some rules have to be stated for dealing with the operational state so that NC/RC and I2RS (or another protocol, for that matter) don't step on each other's toes. > > >> I2RS does not have any interaction with the "local config" except maybe >> > to read it. The NETCONF configuration datastores (candidate, running, >> > startup) are >> > not going to be used by I2RS. Nothing I2RS does is going to even >> slightly >> > alter the definition of any NETCONF configuration procedures. >> >> Consider my BGP example noted elsewhere. If I want to say "create a BGP >> peer" as an I2RS operation and some of that behavior relies on other >> underlying configuration (autonomous system, security policies, etc.) my >> choices appear to be either to have some amount of shadowed configuration >> objects on top of an existing BGP module or have a somewhat parallel module >> (perhaps inheriting configuration objects from the main BGP module). >> >> Which would you do? >> >> > I would start by making sure the management of the local config and > the I2RS config were fully aligned, because it is inevitable (if not > obvious) > that definitions in all 3 boxes above need to share data naming, data types, > and even data nodes. A YANG grouping would be the starting point for > sharing objects. (Not sure if any tweaks needed to support I2RS uses-stmt). This needn't necessarily be true - I think the common denominator really is the operational state. I can imagine different configuration protocols/systems speaking completely different languages. Just an example: OpenWRT defines a UCI format for configuring a firewall that is quite different from the standard configuration of iptables, although under the hood OpenWRT uses iptables as well. Lada > > > > -- Jeff >> > > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri May 2 02:32: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 7BD1D1A09A6 for ; Fri, 2 May 2014 02:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 qM4RWTGIECjL for ; Fri, 2 May 2014 02:32:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8914A1A030E for ; Fri, 2 May 2014 02:32:06 -0700 (PDT) Received: from AMSPR07MB146.eurprd07.prod.outlook.com (10.242.86.148) by AMSPR07MB375.eurprd07.prod.outlook.com (10.242.21.15) with Microsoft SMTP Server (TLS) id 15.0.929.12; Fri, 2 May 2014 09:32:03 +0000 Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (10.255.75.37) by AMSPR07MB146.eurprd07.prod.outlook.com (10.242.86.148) with Microsoft SMTP Server (TLS) id 15.0.929.12; Fri, 2 May 2014 09:32:02 +0000 Received: from pc6 (109.153.84.37) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.453.0; Fri, 2 May 2014 09:32:01 +0000 Message-ID: <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Jeffrey Haas References: <20140501003449.GA1256@pfrc><032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net><20140501144614.GC1705@pfrc><20140501152335.GB29842@pfrc><20140501160952.GA31629@pfrc><20140501171442.GA32492@pfrc><20140501175741.GB32492@pfrc> Date: Fri, 2 May 2014 10:29:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.153.84.37] X-Forefront-PRVS: 019919A9E4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51704005)(51444003)(54094003)(57704003)(199002)(189002)(24454002)(13464003)(50986999)(81816999)(76176999)(31966008)(23756003)(81342001)(14496001)(81686999)(88136002)(15202345003)(62966002)(44736004)(77982001)(33646001)(44716002)(84392001)(101416001)(79102001)(50226001)(74662001)(87936001)(87286001)(47776003)(50466002)(19580395003)(20776003)(62236002)(92566001)(86362001)(92726001)(76482001)(19580405001)(93916002)(4396001)(61296002)(89996001)(83322001)(81542001)(99396002)(85852003)(66066001)(80022001)(77156001)(74502001)(83072002)(80976001)(15975445006)(46102001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB146; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; FPR:AFF4FDDA.ACE61A3B.32D797BB.16E1C9FD.20445; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PsvipGn8xqDr11JHaoy_cq_2t0s Cc: i2rs@ietf.org Subject: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 09:32:09 -0000 ---- Original Message ----- From: "Andy Bierman" To: "Jeffrey Haas" Cc: "t.petch" ; Sent: Thursday, May 01, 2014 7:10 PM > On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas wrote: > > > Andy, > > > > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: > > > This has been done a few times. > > > Most recently April 22: > > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > > > I should respond there, but this was one of the messages that prompted my > > question about data (operational state) vs. ephemeral config. > > > > I don't believe we want to say "this is the module for monitoring the rib > > and now you can write to it". > > > > that is not what the "edit-data" extension does. > It is a sub-statement that identifies I2RS editable data no matter what > YANG module is used to define the data. The YANG config=true statement > identifies a data node as part of the configuration datastore. The edit-data > extension cannot be used on a config=true node, only non-configuration. > > module foo { > ... > import i2rs { prefix i2rs; } > > container config-data { > // NETCONF definitions here > } > > container i2rs-data { > config false; > i2rs:edit-data; > } > > container oper-data { > config false; > // plain read-only data > } > } > > Nesting is also possible -- up to the data modeler to decide what to use: > > 1) i2rs-data inside config-data > 2) i2rs-data inside oper-data > 3) oper-data inside i2rs-data Andy, Jeff I wonder if edit-data on its own will be enough. 'config true' in base YANG allows the data to be written, but it also makes it very easy for NETCONF to read what it wants to, with a get-config RPC. Strictly such a function is unnecessary, it could all be done with filters, which would be a nightmare and error-prone. So we have get-config that gets the 'config true' subset of leafs etc. And, with no apparent downside, there is just the one substatement, 'config true', the two sets are identical. With I2RS, we need writable operational state so we need an edit-data substatement added to YANG but what about getting the data that I2RS wants to see? Do we need an i2rs-data substatement so that we can readily tag the parts of the model that i2rs wants to get, e.g. with a new 'get-i2rs' RPC? I think that we will, that is the set of YANG leafs etc that I2RS will want to edit and the sets of leafs that I2RS will want to get in a straightforward manne will not be the same (eg the latter will include read-only statistics and 'config true'). And yes, it could all be done with filters, which could be a nightmare. Tom Petch p.s. this is one of the issues that I have been wrestling with that I alluded to in my response to Tom Narten > > IMO, I think we want multiple data stores for configuration for adding > > routes to the rib. > > > > > How many does I2RS need for itself? > > > > > > > (I also thought the notification example was clear and didn't need further > > comment.) > > > > > I don't see how standard I2RS data could use local config data unless it > > > was also standardized. > > > > Basically, we want to make sure there is WG coordination on modules. > > If WG has a module and it makes sense for I2RS to use it/extend it, that's > > great when it makes sense. Similarly, if we find the need to create an > > I2RS > > module for work covered by another WG, we want to make sure we leave > > as much re-usable infra for them as we can. > > > > -- Jeff > > > > Andy > From nobody Fri May 2 08:29: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 07BFB1A6FF5 for ; Fri, 2 May 2014 08:29:05 -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_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 I-O9BaK5VzNG for ; Fri, 2 May 2014 08:29:03 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id E30371A09AF for ; Fri, 2 May 2014 08:29:02 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id x13so5019628qcv.29 for ; Fri, 02 May 2014 08:29:00 -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=XM+7i4K/Px5crP4chmwz4iikH8/ZLW7d/B+AvzKDFYw=; b=Z8oJTH3lO7D5wnIfyBzfEOwkmrFrfkc9vpwmtx5UjzlTlE/zDqpHPwaTTvVU4ADLx6 vba0t6qxINJMAlf4jnWXhWFC99OE2EV0fKejNLP/VklVTH/i9ehK80n/RONq4Ieqox6F pSmbWq0xTKRdX1+BlKqH8oqPPDlHa7QqOhJRGbTC3y4g6bKAFI5h2JTjIzg5NIj9pa/C K85qFtHUIO16Z2NmtOIIoEmHKKwkMXidw6mxGU53QiIvzz8n4QWYYyREnd6cIxqC/L06 WrzIJd9vqOOHZX96uOnv9NKLMFrxwAoc0iByPLyGNeOtaOTjvi0znONGfrmNxqiIwOQU Mpyw== X-Gm-Message-State: ALoCoQnMgRdhykRiTMUTJvjsksOmuQVPhMGYbg8X+X03FeapeouE5GJ9RPTojf1So/g/JfutkmxG MIME-Version: 1.0 X-Received: by 10.224.16.69 with SMTP id n5mr23033736qaa.7.1399044540366; Fri, 02 May 2014 08:29:00 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Fri, 2 May 2014 08:29:00 -0700 (PDT) In-Reply-To: <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> References: <20140501003449.GA1256@pfrc> <032d01cf6524$70e94ec0$4001a8c0@gateway.2wire.net> <20140501144614.GC1705@pfrc> <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> Date: Fri, 2 May 2014 08:29:00 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=047d7bea3986da9abf04f86c709d Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tWQU1vXNyQGa-e5zatxIQ6W6uBw Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 15:29:05 -0000 --047d7bea3986da9abf04f86c709d Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 2, 2014 at 2:29 AM, t.petch wrote: > ---- Original Message ----- > From: "Andy Bierman" > To: "Jeffrey Haas" > Cc: "t.petch" ; > Sent: Thursday, May 01, 2014 7:10 PM > > On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas wrote: > > > > > Andy, > > > > > > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote: > > > > This has been done a few times. > > > > Most recently April 22: > > > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01474.html > > > > > > I should respond there, but this was one of the messages that > prompted my > > > question about data (operational state) vs. ephemeral config. > > > > > > I don't believe we want to say "this is the module for monitoring > the rib > > > and now you can write to it". > > > > > > > that is not what the "edit-data" extension does. > > It is a sub-statement that identifies I2RS editable data no matter > what > > YANG module is used to define the data. The YANG config=true > statement > > identifies a data node as part of the configuration datastore. The > edit-data > > extension cannot be used on a config=true node, only > non-configuration. > > > > module foo { > > ... > > import i2rs { prefix i2rs; } > > > > container config-data { > > // NETCONF definitions here > > } > > > > container i2rs-data { > > config false; > > i2rs:edit-data; > > } > > > > container oper-data { > > config false; > > // plain read-only data > > } > > } > > > > Nesting is also possible -- up to the data modeler to decide what to > use: > > > > 1) i2rs-data inside config-data > > 2) i2rs-data inside oper-data > > 3) oper-data inside i2rs-data > > Andy, Jeff > > I wonder if edit-data on its own will be enough. > > 'config true' in base YANG allows the data to be written, but it also > makes it very easy for NETCONF to read what it wants to, with a > get-config RPC. Strictly such a function is unnecessary, it could all > be done with filters, which would be a nightmare and error-prone. So we > have get-config that gets the 'config true' subset of leafs etc. And, > with no apparent downside, there is just the one substatement, 'config > true', the two sets are identical. > > With I2RS, we need writable operational state so we need an edit-data > substatement added to YANG but what about getting the data that I2RS > wants to see? Do we need an i2rs-data substatement so that we can > readily tag the parts of the model that i2rs wants to get, e.g. with a > new 'get-i2rs' RPC? > If definitions are combined in the same module(s), then there is no way to prevent NETCONF from skipping over these special config=false nodes. I doubt that is a problem. I picture the operational state as the mixing bowl for the 2 config sources and data learned from protocols and system events. It seems both NETCONF and I2RS would be able to pick the data is cares about out of that. This is a weakness in YANG that may get improved in YANG 1.1. Since it is officially just for NETCONF, there are no mechanisms (other than vendor extensions) to tag the data as specific to some subset of protocols. > I think that we will, that is the set of YANG leafs etc that I2RS will > want to edit and the sets of leafs that I2RS will want to get in a > straightforward manne will not be the same (eg the latter will include > read-only statistics and 'config true'). And yes, it could all be done > with filters, which could be a nightmare. > > Examples of read-only data that only I2RS would want to get would help. > Tom Petch > > Andy > p.s. this is one of the issues that I have been wrestling with that I > alluded to in my response to Tom Narten > > > > > IMO, I think we want multiple data stores for configuration for > adding > > > routes to the rib. > > > > > > > > > How many does I2RS need for itself? > > > > > > > > > > > > (I also thought the notification example was clear and didn't need > further > > > comment.) > > > > > > > I don't see how standard I2RS data could use local config data > unless it > > > > was also standardized. > > > > > > Basically, we want to make sure there is WG coordination on modules. > > > If WG has a module and it makes sense for I2RS to use it/extend it, > that's > > > great when it makes sense. Similarly, if we find the need to create > an > > > I2RS > > > module for work covered by another WG, we want to make sure we leave > > > as much re-usable infra for them as we can. > > > > > > -- Jeff > > > > > > > Andy > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7bea3986da9abf04f86c709d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 2, 2014 at 2:29 AM, t.petch <ietfc@btconnect.com= > wrote:
---- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "Jeffrey Haas" <jhaas@pf= rc.org>
Cc: "t.petch" <ietfc@bt= connect.com>; <i2rs@ietf.org= >
Sent: Thursday, May 01, 2014 7:10 PM
> On Thu, May 1, 2014 at 10:57 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > Andy,
> >
> > On Thu, May 01, 2014 at 10:47:29AM -0700, Andy Bierman wrote:
> > > This has been done a few times.
> > > Most recently April 22:
> > > http://www.ietf.org/mail-archive/web/i2rs= /current/msg01474.html
> >
> > I should respond there, but this was one of the messages that
prompted my
> > question about data (operational state) vs. ephemeral config.
> >
> > I don't believe we want to say "this is the module for m= onitoring
the rib
> > and now you can write to it".
> >
>
> that is not what the "edit-data" extension does.
> It is a sub-statement that identifies I2RS editable data no matter
what
> YANG module is used to define the data. =A0The YANG config=3Dtrue
statement
> identifies a data node as part of the configuration datastore. The
edit-data
> extension cannot be used on a config=3Dtrue node, only
non-configuration.
>
> module foo {
> =A0 =A0...
> =A0 =A0import i2rs { prefix i2rs; }
>
> =A0 =A0container config-data {
> =A0 =A0 =A0 =A0// NETCONF definitions here
> =A0 =A0 }
>
> =A0 =A0 container i2rs-data {
> =A0 =A0 =A0 =A0config false;
> =A0 =A0 =A0 =A0i2rs:edit-data;
> =A0 =A0 }
>
> =A0 =A0 container oper-data {
> =A0 =A0 =A0 config false;
> =A0 =A0 =A0 =A0// plain read-only data
> =A0 =A0 }
> }
>
> Nesting is also possible -- up to the data modeler to decide what to use:
>
> =A0 =A01) i2rs-data inside config-data
> =A0 =A02) i2rs-data inside oper-data
> =A0 =A03) oper-data inside i2rs-data

Andy, Jeff

I wonder if edit-data on its own will be enough.

'config true' in base YANG allows the data to be written, but it al= so
makes it very easy for NETCONF to read what it wants to, with a
get-config RPC. =A0Strictly such a function is unnecessary, it could all be done with filters, which would be a nightmare and error-prone. =A0So we<= br> have get-config that gets the 'config =A0true' subset of leafs etc.= =A0And,
with no apparent downside, there is just the one substatement, 'config<= br> true', the two sets are identical.

With I2RS, we need writable operational state so we need an edit-data
substatement added to YANG but what about getting the data that I2RS
wants to see? =A0Do we need an i2rs-data substatement so that we can
readily tag the parts of the model that i2rs wants to get, e.g. with a
new 'get-i2rs' RPC?

If definiti= ons are combined in the same module(s), then there is
no way to p= revent NETCONF from skipping over these special config=3Dfalse
nodes. =A0I doubt that is a problem.

I picture the= operational state as the mixing bowl for the 2 config sources
an= d data learned from protocols and system events. =A0It seems
both= NETCONF and I2RS would be able to pick the data is cares about
out of that.

This is a weakness in YANG that = may get improved in YANG 1.1.
Since it is officially just for NET= CONF, there are no mechanisms
(other than vendor extensions) to t= ag the data as specific to
some subset of protocols.



I think that we will, that is the set of YANG leafs etc that I2RS will
want to edit and the sets of leafs that I2RS will want to get in a
straightforward manne will not be the same (eg the latter will include
read-only statistics and 'config true'). =A0And yes, it could all b= e done
with filters, which could be a nightmare.


Examples of read-only data that only I= 2RS would want to get would help.

=A0
Tom Petch



Andy

=A0
p.s. this is one of the issues that I have been wrestling with that I
alluded to in my response to Tom Narten


> > IMO, I think we want multiple data stores for configuration for adding
> > routes to the rib.
> >
>
>
> How many does I2RS need for itself?
>
>
>
> >
> > (I also thought the notification example was clear and didn't= need
further
> > comment.)
> >
> > > I don't see how standard I2RS data could use local confi= g data
unless it
> > > was also standardized.
> >
> > Basically, we want to make sure there is WG coordination on modul= es.
> > If WG has a module and it makes sense for I2RS to use it/extend i= t,
that's
> > great when it makes sense. =A0Similarly, if we find the need to c= reate
an
> > I2RS
> > module for work covered by another WG, we want to make sure we le= ave
> > as much re-usable infra for them as we can.
> >
> > -- Jeff
> >
>
> Andy
>

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

--047d7bea3986da9abf04f86c709d-- From nobody Fri May 2 08:40: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 3D3E71A6F6B for ; Fri, 2 May 2014 08:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 qFmvIpSYvc8i for ; Fri, 2 May 2014 08:40:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD9881A6F1E for ; Fri, 2 May 2014 08:40:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 92C08C2A7; Fri, 2 May 2014 11:40:36 -0400 (EDT) Date: Fri, 2 May 2014 11:40:36 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140502154036.GD17078@pfrc> References: <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.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/y9z-5cIpHS-p4eca4NUNaWKvVmQ Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 15:40:40 -0000 On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > I picture the operational state as the mixing bowl for the 2 config sources > and data learned from protocols and system events. It seems > both NETCONF and I2RS would be able to pick the data is cares about > out of that. I think this is what I'd like to see personally. > This is a weakness in YANG that may get improved in YANG 1.1. > Since it is officially just for NETCONF, there are no mechanisms > (other than vendor extensions) to tag the data as specific to > some subset of protocols. As I mentioned elsewhere, I'm hoping we don't go down the path of "editable operational state", instead configuration semantics for our purposes. > > I think that we will, that is the set of YANG leafs etc that I2RS will > > want to edit and the sets of leafs that I2RS will want to get in a > > straightforward manne will not be the same (eg the latter will include > > read-only statistics and 'config true'). And yes, it could all be done > > with filters, which could be a nightmare. > > > > > Examples of read-only data that only I2RS would want to get would help. I believe that it would largely overlap config false state desired for normal module purposes in many cases. For example, interface statistics would likely be part of the standard interface module. Where things get interesting are specific augmentations that tie different information domains together - interface stats correlated against routing, for example. (For prefix X, traffic is seen - similar to IPFIX exports.) -- Jeff From nobody Fri May 2 09:00: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 0CB7A1A7008 for ; Fri, 2 May 2014 09:00:13 -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 Ha30gWIB-BOr for ; Fri, 2 May 2014 09:00:11 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id DFD291A6FF5 for ; Fri, 2 May 2014 09:00:10 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so4412685qap.23 for ; Fri, 02 May 2014 09:00:08 -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=VcRbFShffukiwCyF8IFTpOSBOsAN987dUjtfvtpzTwE=; b=TdV87uhElUGn/M9OWrwCLob1rLGm60Z5ey1TeanO5awXxMnoqQDVzaHyATw6yvmxOi GElQ08nUXB8RgVh6FnRnCz407IC4QUtWnZPLGz8rUbCNUy2Xjm9ukGyFwX/rJkyQ3PIR 4kuzVN3sJsho/cNxB2fsB95p7qV3PM7EjyjXQ6thYgYjj8t0HS2F0vkm8gkTj5tYcr5e ZY8d4Z8l3xwpjptu8JjIXJANj6nd7z3qWVd5swHpMe7ZA30KEpH1DAGra29sTRo9L5Tg nxazjaOm6HAR8wdIdCY9AmpL0I+el89+FzCc0dGnUY1jsL2Ww/RZZqicPnki5RFqGlL9 dp+w== X-Gm-Message-State: ALoCoQn+VBzD+Pze23WmH+WyQaNZbs8zZseF5dZnCzSHB+ZOg8ItAvtYOYsj0gh3UBuXQrdCWzKQ MIME-Version: 1.0 X-Received: by 10.224.64.132 with SMTP id e4mr23740554qai.16.1399046408204; Fri, 02 May 2014 09:00:08 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Fri, 2 May 2014 09:00:08 -0700 (PDT) In-Reply-To: <20140502154036.GD17078@pfrc> References: <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> Date: Fri, 2 May 2014 09:00:08 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c20e7a2f86e704f86ce08c Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0tIBJyPlWxn8BV1lhYFvrgCXtgA Cc: "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 16:00:13 -0000 --001a11c20e7a2f86e704f86ce08c Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 2, 2014 at 8:40 AM, Jeffrey Haas wrote: > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > > I picture the operational state as the mixing bowl for the 2 config > sources > > and data learned from protocols and system events. It seems > > both NETCONF and I2RS would be able to pick the data is cares about > > out of that. > > I think this is what I'd like to see personally. > > > This is a weakness in YANG that may get improved in YANG 1.1. > > Since it is officially just for NETCONF, there are no mechanisms > > (other than vendor extensions) to tag the data as specific to > > some subset of protocols. > > As I mentioned elsewhere, I'm hoping we don't go down the path of "editable > operational state", instead configuration semantics for our purposes. > > I guess I agree, because when trying to figure out some corner-cases, I changed the datastore name to "i2rs-config". IMO this makes it easier to conceptualize the underlying system as the result of the priority-based arbitration between local-config and i2rs-config. It is easier to see that the system is going to have to re-install an entry from local-config when an I2RS client removes a higher-priority entry from i2rs-config (e.g., your BGP peer example). Both configs exist in parallel, and the oper-state has the entry that is higher priority. > > I think that we will, that is the set of YANG leafs etc that I2RS will > > > want to edit and the sets of leafs that I2RS will want to get in a > > > straightforward manne will not be the same (eg the latter will include > > > read-only statistics and 'config true'). And yes, it could all be done > > > with filters, which could be a nightmare. > > > > > > > > Examples of read-only data that only I2RS would want to get would help. > > I believe that it would largely overlap config false state desired for > normal module purposes in many cases. For example, interface statistics > would likely be part of the standard interface module. Where things get > interesting are specific augmentations that tie different information > domains together - interface stats correlated against routing, for example. > (For prefix X, traffic is seen - similar to IPFIX exports.) > > -- Jeff > Andy --001a11c20e7a2f86e704f86ce08c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 2, 2014 at 8:40 AM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
On Fri, May 02, 2014 at 08:29:00AM -0700, An= dy Bierman wrote:
> I picture the operational state as the mixing bowl for the 2 config so= urces
> and data learned from protocols and system events. =A0It seems
> both NETCONF and I2RS would be able to pick the data is cares about > out of that.

I think this is what I'd like to see personally.

> This is a weakness in YANG that may get improved in YANG 1.1.
> Since it is officially just for NETCONF, there are no mechanisms
> (other than vendor extensions) to tag the data as specific to
> some subset of protocols.

As I mentioned elsewhere, I'm hoping we don't go down the path of &= quot;editable
operational state", instead configuration semantics for our purposes.<= br>

I guess I agree, because when trying t= o figure out some corner-cases,
I changed the datastore name to &= quot;i2rs-config".

IMO this makes it easier t= o conceptualize the underlying system as
the result of the priority-based arbitration between local-config and = i2rs-config.
It is easier to see that the system is going to have= to re-install an entry
from local-config when an I2RS client rem= oves a higher-priority
entry from i2rs-config (e.g., your BGP peer example). =A0Both configs<= /div>
exist in parallel, and the oper-state has the entry that is highe= r priority.


> > I think that we will, that is the set of YANG leafs etc that I2RS= will
> > want to edit and the sets of leafs that I2RS will want to get in = a
> > straightforward manne will not be the same (eg the latter will in= clude
> > read-only statistics and 'config true'). =A0And yes, it c= ould all be done
> > with filters, which could be a nightmare.
> >
> >
> Examples of read-only data that only I2RS would want to get would help= .

I believe that it would largely overlap config false state desired for
normal module purposes in many cases. =A0For example, interface statistics<= br> would likely be part of the standard interface module. =A0Where things get<= br> interesting are specific augmentations that tie different information
domains together - interface stats correlated against routing, for example.=
(For prefix X, traffic is seen - similar to IPFIX exports.)

-- Jeff

Andy

--001a11c20e7a2f86e704f86ce08c-- From nobody Fri May 2 09:09: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 411D81A6FA0 for ; Fri, 2 May 2014 09:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 vRTcRsR5gyrf for ; Fri, 2 May 2014 09:09:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2548F1A09E8 for ; Fri, 2 May 2014 09:09:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 957F01169; Fri, 2 May 2014 18:09:45 +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 VgEeYoauOgDc; Fri, 2 May 2014 18:09:44 +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; Fri, 2 May 2014 18:09:44 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0DB720017; Fri, 2 May 2014 18:09:44 +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 IABalWRQRkGK; Fri, 2 May 2014 18:09:43 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8E6520013; Fri, 2 May 2014 18:09:42 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id C29CF2CC8341; Fri, 2 May 2014 18:09:42 +0200 (CEST) Date: Fri, 2 May 2014 18:09:42 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Jeffrey Haas , Andy Bierman , "i2rs@ietf.org" , "t. petch" References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140502154036.GD17078@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Z_rYA9u4MvBDYBENkrHMsCXNUmU Cc: "i2rs@ietf.org" , Andy Bierman , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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: Fri, 02 May 2014 16:09:51 -0000 On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > > I picture the operational state as the mixing bowl for the 2 config sources > > and data learned from protocols and system events. It seems > > both NETCONF and I2RS would be able to pick the data is cares about > > out of that. > > I think this is what I'd like to see personally. > > > This is a weakness in YANG that may get improved in YANG 1.1. > > Since it is officially just for NETCONF, there are no mechanisms > > (other than vendor extensions) to tag the data as specific to > > some subset of protocols. > > As I mentioned elsewhere, I'm hoping we don't go down the path of "editable > operational state", instead configuration semantics for our purposes. At some point in time, we need to get the terminology sorted out. NC has well defined configuration datastores and YANG has a well defined concept of configuration data (config true). NC kind of assumes that data in configuration datastores has an associated concept of persistence (e.g., changes to persist unless you have an explicit , is a temporary scratch pad). We are talking about another writable datastore (or potentially multiple of them). Some call the data in this writable datastore configuration, others prefer to use a different term to avoid a clash with what NC and YANG consider configuration. If we could find a good name for such writable datastores, I likely make communication much simpler. And yes, I think the model that the contents of the configuration datastore, the writable datastore(s) as well as the information learned dynamically from various control plane protocols all lead to the final operational state. (In fact, one could consider a model where control plane protocols all conceptually come into the system via additional control protocol specific writable datastores.) So, can we find a name for these 'other writable datastores' and then use that term instead of 'writable operational state', 'ephemeral config', 'i2rs datastore', etc.? /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 Fri May 2 09:26:30 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 9DB391A09E8 for ; Fri, 2 May 2014 09:26:28 -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 0W58Z7hQgztY for ; Fri, 2 May 2014 09:26:26 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5C10E1A0915 for ; Fri, 2 May 2014 09:26:26 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id ih12so522815qab.26 for ; Fri, 02 May 2014 09:26:23 -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=2xtKjtkadVLFERXY08PxVP7oinu/GIfCXZA60ANhKuU=; b=F4xXBtrxVkGtJNaNKJJXujdJZQWblnHTXOzRRu13YGOHHkMO5e+OBTcG2juDJ3Az4l s+M0knO9un4j1/P+fJCZ5xXQcfDVcGo1jbntMm5uHRO+nwsMYgyShDIlk1EfHnuze+sT O5zZQbVqKBlWzdfuVZxkguPGeuWqgM05uHICiBTZA1u0QHNyHL26pv+TD7d16MP+IsRU nEnD11W2YIra+ePc9k/iH0REyaB6QofuRMduad/xeVXA4ThvMiqn4b5IEK/fAQohSRga TG7OyJdeQ9lPuDpbUIdFcDUp5PuvxXvpYdwx9rbAG2miTLejCRdM3YBCpmkecXVfK5wC KvLg== X-Gm-Message-State: ALoCoQlzbKVrOC9NXYLge5IljZOrKzZgXIZyQ25Y/X7cb7hB+J+lAQXQrGiNYTFW0P8tjAA4q7Al MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr23714613qat.78.1399047983865; Fri, 02 May 2014 09:26:23 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Fri, 2 May 2014 09:26:23 -0700 (PDT) In-Reply-To: <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> Date: Fri, 2 May 2014 09:26:23 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jeffrey Haas , Andy Bierman , "i2rs@ietf.org" , "t. petch" Content-Type: multipart/alternative; boundary=047d7b672b441a349904f86d3efc Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_MWFiU9oek2-cOHw6eMw5aBwV1I Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 16:26:28 -0000 --047d7b672b441a349904f86d3efc Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: > > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > > > I picture the operational state as the mixing bowl for the 2 config > sources > > > and data learned from protocols and system events. It seems > > > both NETCONF and I2RS would be able to pick the data is cares about > > > out of that. > > > > I think this is what I'd like to see personally. > > > > > This is a weakness in YANG that may get improved in YANG 1.1. > > > Since it is officially just for NETCONF, there are no mechanisms > > > (other than vendor extensions) to tag the data as specific to > > > some subset of protocols. > > > > As I mentioned elsewhere, I'm hoping we don't go down the path of > "editable > > operational state", instead configuration semantics for our purposes. > > At some point in time, we need to get the terminology sorted out. NC > has well defined configuration datastores and YANG has a well defined > concept of configuration data (config true). NC kind of assumes that > data in configuration datastores has an associated concept of > persistence (e.g., changes to persist unless you have an > explicit , is a temporary scratch pad). > > We are talking about another writable datastore (or potentially > multiple of them). Some call the data in this writable datastore > configuration, others prefer to use a different term to avoid a clash > with what NC and YANG consider configuration. If we could find a good > name for such writable datastores, I likely make communication much > simpler. > > And yes, I think the model that the contents of the configuration > datastore, the writable datastore(s) as well as the information > learned dynamically from various control plane protocols all lead to > the final operational state. (In fact, one could consider a model > where control plane protocols all conceptually come into the system > via additional control protocol specific writable datastores.) > > So, can we find a name for these 'other writable datastores' and then > use that term instead of 'writable operational state', 'ephemeral > config', 'i2rs datastore', etc.? > > I imagine I2RS will be completely separate from NETCONF and it should have its own datastore -- so "i2rs-config" is appropriate because I2RS is the only protocol using that datastore. The combined "operational state" is not editable. It is tempting to generalize the problem so the solution works for any protocol (not specifically I2RS) and any data (not specifically RIB data). But that would be out of scope. Understanding the interaction between local-config and i2rs-config is certainly in scope. There is lots of work left to be done there, so if it seems fuzzy to you, that's probably why ;-) > /js > Andy --047d7b672b441a349904f86d3efc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, May 02, 2014 at 11:40:36AM -0400, Je= ffrey Haas wrote:
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 conf= ig sources
> > and data learned from protocols and system events. =A0It seems > > both NETCONF and I2RS would be able to pick the data is cares abo= ut
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG 1.1.
> > Since it is officially just for NETCONF, there are no mechanisms<= br> > > (other than vendor extensions) to tag the data as specific to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path= of "editable
> operational state", instead configuration semantics for our purpo= ses.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have an explicit <startup/>, <candidate/> is a temporary scratch pad).<= br>
We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a clash
with what NC and YANG consider configuration. If we could find a good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and th= en
use that term instead of 'writable operational state', 'ephemer= al
config', 'i2rs datastore', etc.?


I imagine I2RS will be completely separate from NETC= ONF and it should
have its own datastore -- so "i2rs-config&= quot; is appropriate because I2RS is the
only protocol using that datastore. The combined "operational sta= te"
is not editable.

It is tempting= to generalize the problem so the solution works for any
protocol= (not specifically I2RS) and any data (not specifically RIB data).
But that would be out of scope. =A0Understanding the interaction betwe= en
local-config and i2rs-config is certainly in scope. There is l= ots of work
left to be done there, so if it seems fuzzy to you, t= hat's probably why ;-)


=A0
= /js

Andy

--047d7b672b441a349904f86d3efc-- From nobody Fri May 2 09:39:07 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 772081A08DA for ; Fri, 2 May 2014 09:39:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 c0NJZroXQWyR for ; Fri, 2 May 2014 09:39:03 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3283C1A6F6B for ; Fri, 2 May 2014 09:39:02 -0700 (PDT) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.0.934.12; Fri, 2 May 2014 16:38:59 +0000 Message-ID: <029301cf6624$b566c220$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas , Andy Bierman References: <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> Date: Fri, 2 May 2014 17:36:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMXPR07CA001.eurprd07.prod.outlook.com (10.242.64.41) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Forefront-PRVS: 019919A9E4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(51704005)(377454003)(51444003)(189002)(199002)(24454002)(13464003)(81816999)(50986999)(87286001)(81686999)(76176999)(84392001)(101416001)(89996001)(83072002)(87976001)(88136002)(23756003)(4396001)(62966002)(74662001)(74502001)(47776003)(77982001)(80022001)(66066001)(61296002)(81542001)(20776003)(81342001)(86362001)(85852003)(93916002)(19580405001)(80976001)(83322001)(14496001)(19580395003)(76482001)(33646001)(79102001)(50226001)(46102001)(77156001)(92566001)(92726001)(50466002)(44716002)(99396002)(62236002)(31966008)(42186004)(44736004)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB062; H:AMXPRD0310HT003.eurprd03.prod.outlook.com; FPR:; MLV:ovr; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kzIO9JT0PkMIdHXBl76EF9PTgAM Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 16:39:06 -0000 - Original Message ----- From: "Jeffrey Haas" To: "Andy Bierman" Cc: "t.petch" ; "Jeffrey Haas" ; Sent: Friday, May 02, 2014 4:40 PM > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > > I picture the operational state as the mixing bowl for the 2 config sources > > and data learned from protocols and system events. It seems > > both NETCONF and I2RS would be able to pick the data is cares about > > out of that. > > I think this is what I'd like to see personally. > > > This is a weakness in YANG that may get improved in YANG 1.1. > > Since it is officially just for NETCONF, there are no mechanisms > > (other than vendor extensions) to tag the data as specific to > > some subset of protocols. > > As I mentioned elsewhere, I'm hoping we don't go down the path of "editable > operational state", instead configuration semantics for our purposes. > > > > I think that we will, that is the set of YANG leafs etc that I2RS will > > > want to edit and the sets of leafs that I2RS will want to get in a > > > straightforward manne will not be the same (eg the latter will include > > > read-only statistics and 'config true'). And yes, it could all be done > > > with filters, which could be a nightmare. > > > > > > > > Examples of read-only data that only I2RS would want to get would help. > > I believe that it would largely overlap config false state desired for > normal module purposes in many cases. For example, interface statistics > would likely be part of the standard interface module. Where things get > interesting are specific augmentations that tie different information > domains together - interface stats correlated against routing, for example. > (For prefix X, traffic is seen - similar to IPFIX exports.) Using my usual terminology, of read only statistics as being the part of state (YANG leafs etc with a substatement of 'config false') that is not operational state, and turning to the I2RS use case documents, I see: in -keyupdate " There are a variety of statistics related to the operation of BGP that are invaluable to network operators. These statistics generally help operators, and developers, understand the present state and future scalability of BGP." or in draft-white " o The ability to interact with traffic flow and other network traffic level measurement protocols and systems, in order to determine path performance, top talkers, and other information required to make an informed path decision based on locally configured policy." or in -mbb " The I2RS architecture (client-agent) should solve the two problems mentioned above naturally by enabling the use of centralized controllers, which control and manage the entire network's devices and store the whole routing and service information directly. Meanwhile, the outages and traffic congestion or discards can be detected real-time with I2RS Client(s) connected to the I2RS agents in each node which provide real-time status via notification service. An I2RS client with this ability will allow the I2RS clients to keep optimal state dynamically all the time." while I would expect it to be required for anything to do with ECMP/SRLG etc so yes, I see a need for I2RS to access read-only statistics. Tom Petch > -- Jeff From nobody Fri May 2 10:10: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 D33B31A6F5A for ; Fri, 2 May 2014 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 y8hfNjhoty86 for ; Fri, 2 May 2014 10:10:38 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9831A6F34 for ; Fri, 2 May 2014 10:10:38 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4B4D7278D9F4; Fri, 2 May 2014 13:10:35 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AE227BD4-06FB-46E9-BCEF-6593F4D941F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 2 May 2014 13:10:33 -0400 Message-Id: <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HO1ErfHVDrP6ox2KpzcfchyTQGI Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 17:10:41 -0000 --Apple-Mail=_AE227BD4-06FB-46E9-BCEF-6593F4D941F0 Content-Type: multipart/alternative; boundary="Apple-Mail=_D238706A-3FD4-4DD8-B3BA-444AAD25577B" --Apple-Mail=_D238706A-3FD4-4DD8-B3BA-444AAD25577B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder = wrote: > On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: > > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > > > I picture the operational state as the mixing bowl for the 2 = config sources > > > and data learned from protocols and system events. It seems > > > both NETCONF and I2RS would be able to pick the data is cares = about > > > out of that. > > > > I think this is what I'd like to see personally. > > > > > This is a weakness in YANG that may get improved in YANG 1.1. > > > Since it is officially just for NETCONF, there are no mechanisms > > > (other than vendor extensions) to tag the data as specific to > > > some subset of protocols. > > > > As I mentioned elsewhere, I'm hoping we don't go down the path of = "editable > > operational state", instead configuration semantics for our = purposes. >=20 > At some point in time, we need to get the terminology sorted out. NC > has well defined configuration datastores and YANG has a well defined > concept of configuration data (config true). NC kind of assumes that > data in configuration datastores has an associated concept of > persistence (e.g., changes to persist unless you have an > explicit , is a temporary scratch pad). >=20 > We are talking about another writable datastore (or potentially > multiple of them). Some call the data in this writable datastore > configuration, others prefer to use a different term to avoid a clash > with what NC and YANG consider configuration. If we could find a good > name for such writable datastores, I likely make communication much > simpler. >=20 > And yes, I think the model that the contents of the configuration > datastore, the writable datastore(s) as well as the information > learned dynamically from various control plane protocols all lead to > the final operational state. (In fact, one could consider a model > where control plane protocols all conceptually come into the system > via additional control protocol specific writable datastores.) >=20 > So, can we find a name for these 'other writable datastores' and then > use that term instead of 'writable operational state', 'ephemeral > config', 'i2rs datastore', etc.? >=20 >=20 > I imagine I2RS will be completely separate from NETCONF and it should > have its own datastore -- so "i2rs-config" is appropriate because I2RS = is the > only protocol using that datastore. The combined "operational state" > is not editable. Yes, that makes sense. Then if at some point in time you want to = save=20 the running config (i2rs), the system has to explicitly copy it over. = But until then, its separate. The only question is: what is the complete running config = represented as? And what if Netconf wants to modify the running config (i.e.: and the = RIB in particular)? --Tom > It is tempting to generalize the problem so the solution works for any > protocol (not specifically I2RS) and any data (not specifically RIB = data). > But that would be out of scope. Understanding the interaction between > local-config and i2rs-config is certainly in scope. There is lots of = work > left to be done there, so if it seems fuzzy to you, that's probably = why ;-) >=20 >=20 > =20 > /js >=20 > Andy >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_D238706A-3FD4-4DD8-B3BA-444AAD25577B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote:
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 config sources
> > and data learned from protocols and system events.  It seems
> > both NETCONF and I2RS would be able to pick the data is cares about
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG 1.1.
> > Since it is officially just for NETCONF, there are no mechanisms
> > (other than vendor extensions) to tag the data as specific to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path of "editable
> operational state", instead configuration semantics for our purposes.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have an
explicit <startup/>, <candidate/> is a temporary scratch pad).

We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a clash
with what NC and YANG consider configuration. If we could find a good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and then
use that term instead of 'writable operational state', 'ephemeral
config', 'i2rs datastore', etc.?


I imagine I2RS will be completely separate from NETCONF and it should
have its own datastore -- so "i2rs-config" is appropriate because I2RS is the
only protocol using that datastore. The combined "operational state"
is not editable.

Yes, that makes sense. Then if at some point in time you want to save 
the running config (i2rs), the system has to explicitly copy it over. But until then,
its separate.  The only question is: what is the complete running config represented as?
And what if Netconf wants to modify the running config (i.e.: and the RIB in particular)?

--Tom


It is tempting to generalize the problem so the solution works for any
protocol (not specifically I2RS) and any data (not specifically RIB data).
But that would be out of scope.  Understanding the interaction between
local-config and i2rs-config is certainly in scope. There is lots of work
left to be done there, so if it seems fuzzy to you, that's probably why ;-)


 
/js

Andy

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

--Apple-Mail=_D238706A-3FD4-4DD8-B3BA-444AAD25577B-- --Apple-Mail=_AE227BD4-06FB-46E9-BCEF-6593F4D941F0 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 iQIcBAEBCgAGBQJTY9GKAAoJEPcO+I7eiUJZW7MP+gIo9YX6+1I1idnrhjtfJF8d VgL2R6X/iIoV4kWXlHxNcZUz+2LzW0BYIKzbFneEO4EIwtQPZTPuGqgrCf8XD5Cn r/ZTsHJ69Z+mIJVCcTjzIQkzgOHk/X6CjklT/6mzbKaeO5tDVuJOkJm9hlXEacAw McStJgf6Xd2a1tpmHS7MopcUGjB0f/UdL5BdjXWrIkZCKCx2cDNTwLpB5w3+ezAc XdOWFRJlDeA51c9apxccU5KuRt7G2JpidCg0X1NEB20PFUjW2cuy01sXgnL64pD6 H2BUjUSzigtsF6G4R7uaQA+YnG3xDCowuSafMa3BL6z6fjlP/iwRPsZNB8RDfPaZ N23JAJqsongKMZWYVFzl9oEdyKnDUIhlTM1es0nIkkbF+S+IXN96m0+u9LYsQa89 krWzhMxpJwQ+LqxMelvB1Hancj7tjENwC4NqOhYRlyKFIM17pIMp7oMsgf/tXHu6 jnf1jsR5TThnXzodlC7b8RSwS9aJcEPqsugHm5VzQO8vi2ux9UfYivmY9+QGGA6G hjhk8I4j1QNF+RbMMTPLs1Z5iPi89R6ELO4WtSmitLnXsAYDyf6b/fqX+2cfIg/R 77N1pdpHjA6aiZKU5EEv03HYXi5XX/GngjukciIlOSjQd5rph6U3S3tBuCwZPgDr vpG7vYKBN70EnpRo//cp =Jpmt -----END PGP SIGNATURE----- --Apple-Mail=_AE227BD4-06FB-46E9-BCEF-6593F4D941F0-- From nobody Fri May 2 10:33: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 3D89A1A0902 for ; Fri, 2 May 2014 10:33:43 -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 u1X8fbl979b3 for ; Fri, 2 May 2014 10:33:40 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 625A21A08DA for ; Fri, 2 May 2014 10:33:40 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so5154178qcx.32 for ; Fri, 02 May 2014 10:33:37 -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=iBKk3pQONnhW61SqoTrUkrpwL3/+kH79TqVjDevFpAQ=; b=Hsi6uOusBru8yupi1YETHxjf5/4PinGJn+IHYFRXgH9/LTv3qwNpN6S2E1isFJ3So2 txZzD1mPPrnbTuuKdo3Dta+DSIbvlC5q+fMN3Pz82zIG1E9C9Rxe2u8mzvz3kqy1zee9 Lq9ydz+XMHE9O40JxApAHkFJooSXYX6aNRpPErq6LpwDLISQIR6r24+2rY1LLoFPypc5 FJmPJbJb3lmt9MNGdiz+VtsZWLEUnZmQmfrxzAmq9O/yeaYUduyK7s/HCE25+mpcFbL8 4H0ireyTNw1XTUuBHce0O67tdA6A16syG76edL2dkPkm/p9L9t8IzD02+LRcRsMy6nHk Et8g== X-Gm-Message-State: ALoCoQkzlXoRIp+l1GQZ45wurxL7LACp92NeZtVJc423twKBg2Qy99Wy88oJwUt+BwTXIvui37zp MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr24282796qat.78.1399052017790; Fri, 02 May 2014 10:33:37 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Fri, 2 May 2014 10:33:37 -0700 (PDT) In-Reply-To: <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> Date: Fri, 2 May 2014 10:33:37 -0700 Message-ID: From: Andy Bierman To: Thomas Nadeau Content-Type: multipart/alternative; boundary=047d7b672b448b1c9504f86e2ecc Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/N_-HBgORq1ngtaiHnnmlFZe1hew Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 17:33:43 -0000 --047d7b672b448b1c9504f86e2ecc Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau wrote: > > On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman > wrote: > > > > > On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: >> > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: >> > > I picture the operational state as the mixing bowl for the 2 config >> sources >> > > and data learned from protocols and system events. It seems >> > > both NETCONF and I2RS would be able to pick the data is cares about >> > > out of that. >> > >> > I think this is what I'd like to see personally. >> > >> > > This is a weakness in YANG that may get improved in YANG 1.1. >> > > Since it is officially just for NETCONF, there are no mechanisms >> > > (other than vendor extensions) to tag the data as specific to >> > > some subset of protocols. >> > >> > As I mentioned elsewhere, I'm hoping we don't go down the path of >> "editable >> > operational state", instead configuration semantics for our purposes. >> >> At some point in time, we need to get the terminology sorted out. NC >> has well defined configuration datastores and YANG has a well defined >> concept of configuration data (config true). NC kind of assumes that >> data in configuration datastores has an associated concept of >> persistence (e.g., changes to persist unless you have an >> explicit , is a temporary scratch pad). >> >> We are talking about another writable datastore (or potentially >> multiple of them). Some call the data in this writable datastore >> configuration, others prefer to use a different term to avoid a clash >> with what NC and YANG consider configuration. If we could find a good >> name for such writable datastores, I likely make communication much >> simpler. >> >> And yes, I think the model that the contents of the configuration >> datastore, the writable datastore(s) as well as the information >> learned dynamically from various control plane protocols all lead to >> the final operational state. (In fact, one could consider a model >> where control plane protocols all conceptually come into the system >> via additional control protocol specific writable datastores.) >> >> So, can we find a name for these 'other writable datastores' and then >> use that term instead of 'writable operational state', 'ephemeral >> config', 'i2rs datastore', etc.? >> >> > I imagine I2RS will be completely separate from NETCONF and it should > have its own datastore -- so "i2rs-config" is appropriate because I2RS is > the > only protocol using that datastore. The combined "operational state" > is not editable. > > > Yes, that makes sense. Then if at some point in time you want to save > the running config (i2rs), the system has to explicitly copy it over. But > until then, > its separate. The only question is: what is the complete running config > represented as? > And what if Netconf wants to modify the running config (i.e.: and the RIB > in particular)? > > That copy-to-local-config feature would be extra, outside the scope of the i2rs-config. IMO, the i2rs-config datastore has these properties: - editable with I2RS using the I2RS owner-priority access control model - only field validation; YANG datastore validation is ignored, except for mandatory=true|false and min/max-elements - data is never saved across a reboot; never saved to NV-storage like NETCONF config - data does not time out; The system or external I2RS client must remove any data to cleanup - the system uses the priority values to determine if local-config or i2rs-config wins wrt/ operational values; the system must install the correct config if priorities change --Tom > > Andy > > It is tempting to generalize the problem so the solution works for any > protocol (not specifically I2RS) and any data (not specifically RIB data). > But that would be out of scope. Understanding the interaction between > local-config and i2rs-config is certainly in scope. There is lots of work > left to be done there, so if it seems fuzzy to you, that's probably why ;-) > > > > >> /js >> > > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --047d7b672b448b1c9504f86e2ecc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman <andy@yumaworks.com> wrote:=




On Fri, May 2, 2014 at 9:09 AM, Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
On Fri, May 02, 2014 at 11:40:36AM -0400, Je= ffrey Haas wrote:
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 conf= ig sources
> > and data learned from protocols and system events. =A0It seems > > both NETCONF and I2RS would be able to pick the data is cares abo= ut
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG 1.1.
> > Since it is officially just for NETCONF, there are no mechanisms<= br> > > (other than vendor extensions) to tag the data as specific to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path= of "editable
> operational state", instead configuration semantics for our purpo= ses.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have an explicit <startup/>, <candidate/> is a temporary scratch pad).<= br>
We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a clash
with what NC and YANG consider configuration. If we could find a good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and th= en
use that term instead of 'writable operational state', 'ephemer= al
config', 'i2rs datastore', etc.?


I imagine I2RS will be completely separate from NETCONF and it should=
have its own datastore -- so "i2rs-config" is appropri= ate because I2RS is the
only protocol using that datastore. The combined "operational sta= te"
is not editable.

the running config (i2rs), the system has to explicitly copy it over. = But until then,
its separate. =A0The only question is: what is th= e complete running config represented as?
And what if Netconf wan= ts to modify the running config (i.e.: and the RIB in particular)?


That copy-to-lo= cal-config feature would be extra, outside the scope of the i2rs-config.
IMO, the i2rs-config datastore has these properties:
=A0 =A0- editable with I2RS using the I2RS owner-priority access control mo= del
=A0 =A0- only field validation; YANG datastore validation is = ignored,
=A0 =A0 =A0except for mandatory=3Dtrue|false and min/max= -elements
=A0 =A0- data is never saved across a reboot; never saved to NV-storag= e like NETCONF config
=A0 =A0- data does not time out; The system= or external I2RS client must remove any data
=A0 =A0 =A0to clean= up
=A0 =A0- the system uses the priority values to determine if local-config o= r i2rs-config
=A0 =A0 =A0wins wrt/ operational values; the system= must install the correct config if

--047d7b672b448b1c9504f86e2ecc-- From nobody Fri May 2 11:07:18 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 EEACB1A6FBE for ; Fri, 2 May 2014 11:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 vvEjSRHiLY7o for ; Fri, 2 May 2014 11:07:12 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 38DB81A6F7B for ; Fri, 2 May 2014 11:07:12 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A2595278DB8F; Fri, 2 May 2014 14:07:09 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BFE5218C-EEC8-4BB2-B2ED-A9BF71405A5B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 2 May 2014 14:07:08 -0400 Message-Id: <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/heD7Br3o6rZcRa3AM2xW8MfXQSg Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 18:07:15 -0000 --Apple-Mail=_BFE5218C-EEC8-4BB2-B2ED-A9BF71405A5B Content-Type: multipart/alternative; boundary="Apple-Mail=_F027F149-1719-4CA2-90A5-15FD474B7E49" --Apple-Mail=_F027F149-1719-4CA2-90A5-15FD474B7E49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau = wrote: >=20 > On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman = wrote: >=20 >>=20 >>=20 >>=20 >> On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder = wrote: >> On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: >> > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: >> > > I picture the operational state as the mixing bowl for the 2 = config sources >> > > and data learned from protocols and system events. It seems >> > > both NETCONF and I2RS would be able to pick the data is cares = about >> > > out of that. >> > >> > I think this is what I'd like to see personally. >> > >> > > This is a weakness in YANG that may get improved in YANG 1.1. >> > > Since it is officially just for NETCONF, there are no mechanisms >> > > (other than vendor extensions) to tag the data as specific to >> > > some subset of protocols. >> > >> > As I mentioned elsewhere, I'm hoping we don't go down the path of = "editable >> > operational state", instead configuration semantics for our = purposes. >>=20 >> At some point in time, we need to get the terminology sorted out. NC >> has well defined configuration datastores and YANG has a well defined >> concept of configuration data (config true). NC kind of assumes that >> data in configuration datastores has an associated concept of >> persistence (e.g., changes to persist unless you have an >> explicit , is a temporary scratch pad). >>=20 >> We are talking about another writable datastore (or potentially >> multiple of them). Some call the data in this writable datastore >> configuration, others prefer to use a different term to avoid a clash >> with what NC and YANG consider configuration. If we could find a good >> name for such writable datastores, I likely make communication much >> simpler. >>=20 >> And yes, I think the model that the contents of the configuration >> datastore, the writable datastore(s) as well as the information >> learned dynamically from various control plane protocols all lead to >> the final operational state. (In fact, one could consider a model >> where control plane protocols all conceptually come into the system >> via additional control protocol specific writable datastores.) >>=20 >> So, can we find a name for these 'other writable datastores' and then >> use that term instead of 'writable operational state', 'ephemeral >> config', 'i2rs datastore', etc.? >>=20 >>=20 >> I imagine I2RS will be completely separate from NETCONF and it should >> have its own datastore -- so "i2rs-config" is appropriate because = I2RS is the >> only protocol using that datastore. The combined "operational state" >> is not editable. >=20 > Yes, that makes sense. Then if at some point in time you want to = save=20 > the running config (i2rs), the system has to explicitly copy it over. = But until then, > its separate. The only question is: what is the complete running = config represented as? > And what if Netconf wants to modify the running config (i.e.: and the = RIB in particular)? >=20 >=20 > That copy-to-local-config feature would be extra, outside the scope of = the i2rs-config. > IMO, the i2rs-config datastore has these properties: > - editable with I2RS using the I2RS owner-priority access control = model > - only field validation; YANG datastore validation is ignored, > except for mandatory=3Dtrue|false and min/max-elements > - data is never saved across a reboot; never saved to NV-storage = like NETCONF config > - data does not time out; The system or external I2RS client must = remove any data > to cleanup > - the system uses the priority values to determine if local-config = or i2rs-config > wins wrt/ operational values; the system must install the correct = config if > priorities change Right. If we take that approach we need to have a way of the = i2rs "protocol" to signal that the config=20 needs to be saved "soon". That is, its not done in real time, but = rather as a background process.=20 Its probably. This can either be through a single keyword that is added = under the i2rs-config section, or per element or even per-element, if we decide to be more granular.=20 --Tom >=20 >=20 >=20 > --Tom >=20 >=20 >=20 > Andy > =20 >=20 >> It is tempting to generalize the problem so the solution works for = any >> protocol (not specifically I2RS) and any data (not specifically RIB = data). >> But that would be out of scope. Understanding the interaction = between >> local-config and i2rs-config is certainly in scope. There is lots of = work >> left to be done there, so if it seems fuzzy to you, that's probably = why ;-) >>=20 >>=20 >> =20 >> /js >>=20 >> Andy >>=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=_F027F149-1719-4CA2-90A5-15FD474B7E49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On May 2, 2014:1:33 PM, at 1:33 PM, = Andy Bierman <andy@yumaworks.com> = wrote:




On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau = <tnadeau@lucidvision.com> wrote:

On May 2, 2014:12:26 PM, at = 12:26 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Fri, May 2, = 2014 at 9:09 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:
On Fri, May 02, 2014 = at 11:40:36AM -0400, Jeffrey Haas wrote:
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 = config sources
> > and data learned from protocols and system events.  It = seems
> > both NETCONF and I2RS would be able to pick the data is cares = about
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG = 1.1.
> > Since it is officially just for NETCONF, there are no = mechanisms
> > (other than vendor extensions) to tag the data as specific = to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path of = "editable
> operational state", instead configuration semantics for our = purposes.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well = defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have = an
explicit <startup/>, <candidate/> is a temporary scratch = pad).

We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a = clash
with what NC and YANG consider configuration. If we could find a = good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and = then
use that term instead of 'writable operational state', 'ephemeral
config', 'i2rs datastore', etc.?


I = imagine I2RS will be completely separate from NETCONF and it = should
have its own datastore -- so "i2rs-config" is = appropriate because I2RS is the
only protocol using that datastore. The combined "operational = state"
is not = editable.

Yes, that makes sense. Then if at = some point in time you want to save 
the running config (i2rs), the system has to explicitly copy it = over. But until then,
its separate.  The only question = is: what is the complete running config represented as?
And = what if Netconf wants to modify the running config (i.e.: and the RIB in = particular)?


That = copy-to-local-config feature would be extra, outside the scope of the = i2rs-config.


IMO, the = i2rs-config datastore has these properties:
   - editable with I2RS using the I2RS owner-priority access = control model
   - only field validation; YANG = datastore validation is ignored,
     except = for mandatory=3Dtrue|false and min/max-elements
   - data is never saved across a reboot; never saved to = NV-storage like NETCONF config
   - data does not = time out; The system or external I2RS client must remove any = data
     to cleanup
   - the system uses the priority values to determine if = local-config or i2rs-config
     wins wrt/ = operational values; the system must install the correct config = if
     priorities = change

Right. If = we take that approach we need to have a way of the i2rs "protocol" to = signal that the config 
needs to be saved "soon". =  That is, its not done in real time, but rather as a background = process. 
Its probably. This can either be through a = single keyword that is added under the i2rs-config section, = or
per element or even per-element, if we decide to be more = granular. 

= --Tom





--Tom
=



Andy<= /div>
 

It is tempting to = generalize the problem so the solution works for any
protocol = (not specifically I2RS) and any data (not specifically RIB data).
But that would be out of scope.  Understanding the interaction = between
local-config and i2rs-config is certainly in scope. = There is lots of work
left to be done there, so if it seems = fuzzy to you, that's probably why ;-)


 
= /js

Andy

<= /div>
_______________________________________________
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=_F027F149-1719-4CA2-90A5-15FD474B7E49-- --Apple-Mail=_BFE5218C-EEC8-4BB2-B2ED-A9BF71405A5B 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 iQIcBAEBCgAGBQJTY97MAAoJEPcO+I7eiUJZcTcP/1/Q+Nbh6efWeX8TcsAxhTGX tHigvkUcLnwLSYpfNZARoEixSXMvEkO69vXNMx/1bjfAeBwzio7GSPEL+BEiGIYW VNjiMv8gsitjGH0Qx9ZJY/auO+fkH3So5GFgnSkT429d4/WSwUQ2KTlZsW9ysQyL snU0nn8DnvT8Znf9JGgZ7F5icGutVOCVrhxDNUJg6hxcT0utFlTwwiu7hV9oPMsx 3Sx46tDaC4iUJt/uRMtYAMc4ssnT4qyqHuKHZLep4pLx5W4RX1fd/0ZiUEGqADRz BCwodZXlixOpiQ+GikkHKGFAyG989Zx2qypizBqK8uaIHfIYYtsNUOuGQEaVmxH0 /ETVIdTNGGV7dV6ydpnEs6ivylgv3ND8LGV73t0QgtcKJDhKcS+KJTQ8P88Va9/Y Oko/YCfySUeT3b6AH/gFKsaim02ciuSb3YIztDyqu7W72WK4t9XZx/4IGyPDvA2p dlHxu2SmzR7lCJzYOxL2/F5acC5O9lvCMOzmmfnYp03CsrnUF8Vow6lYA62YlQed TyKz4yNvsUf/PsbACTwQhNgYxLYGudL/dDyjayt/25FZHfIAKJj03VmgvN3H+8oy Sw+0ERNcHi7W6GFUMry4u8h3o5zuC+P4A8JNJ5DMjwbTKmEEkX5/igq+97C0lwRl A5VHFsVCaxaSpiSdtt3z =Obil -----END PGP SIGNATURE----- --Apple-Mail=_BFE5218C-EEC8-4BB2-B2ED-A9BF71405A5B-- From nobody Fri May 2 11:49:29 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 E0E761A6FD8 for ; Fri, 2 May 2014 11:49:26 -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 N84KZcWHkmJd for ; Fri, 2 May 2014 11:49:24 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 65F971A08CA for ; Fri, 2 May 2014 11:49:24 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id c9so5298043qcz.30 for ; Fri, 02 May 2014 11:49:21 -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=bx4pILbfmiAbasVbK2JcywmVJdqrvxHsU5qc2kKHzoo=; b=braxFdidtHfkkk+pK0AXJdsX14noJ88qUnYUgf2901Pqot+VGT6LwHYBPfl2kKSMd4 SDxgqNQqIwKE5Y9fzXRVSFLx37lwF0jaNhYxJpdxnUEkBi4J0gEnPsilE4Gwtplpuvd6 o+i39HjRDmpUzIJ8vQ7D+vv1h3SkngBysLxQDFPwENqJFs2DzSo5NmS3vyy5rOdDWIr0 5oxH5h9pBmI7mW78VhwIyvs0+KTTRMWPczEHMcYieAFlNyvW07n99sfp5kzUWVt+RlHN AbuqyOXMPLUkZg6n93DJ9bBl1652De18tAfek0Ssu96FmCz0uEhoxsmVY5HNcicWrs3n 76+g== X-Gm-Message-State: ALoCoQmHG5fnxyqnL01HfscQH9hU01t6DbZqtmJi3Xrl8p0AsNzfLOjPkH7SpeBsg6lHKt4FlWYh MIME-Version: 1.0 X-Received: by 10.229.72.10 with SMTP id k10mr24874032qcj.2.1399056561859; Fri, 02 May 2014 11:49:21 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Fri, 2 May 2014 11:49:21 -0700 (PDT) In-Reply-To: <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> Date: Fri, 2 May 2014 11:49:21 -0700 Message-ID: From: Andy Bierman To: Thomas Nadeau Content-Type: multipart/alternative; boundary=089e0168131864012004f86f3d08 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/AJ3O0uBGF8tUPBgo8DvsppWZTAw Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 18:49:27 -0000 --089e0168131864012004f86f3d08 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 2, 2014 at 11:07 AM, Thomas Nadeau wrote: > > On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman > wrote: > > > > > On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau wrote: > >> >> On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman >> wrote: >> >> >> >> >> On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: >>> > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: >>> > > I picture the operational state as the mixing bowl for the 2 config >>> sources >>> > > and data learned from protocols and system events. It seems >>> > > both NETCONF and I2RS would be able to pick the data is cares about >>> > > out of that. >>> > >>> > I think this is what I'd like to see personally. >>> > >>> > > This is a weakness in YANG that may get improved in YANG 1.1. >>> > > Since it is officially just for NETCONF, there are no mechanisms >>> > > (other than vendor extensions) to tag the data as specific to >>> > > some subset of protocols. >>> > >>> > As I mentioned elsewhere, I'm hoping we don't go down the path of >>> "editable >>> > operational state", instead configuration semantics for our purposes. >>> >>> At some point in time, we need to get the terminology sorted out. NC >>> has well defined configuration datastores and YANG has a well defined >>> concept of configuration data (config true). NC kind of assumes that >>> data in configuration datastores has an associated concept of >>> persistence (e.g., changes to persist unless you have an >>> explicit , is a temporary scratch pad). >>> >>> We are talking about another writable datastore (or potentially >>> multiple of them). Some call the data in this writable datastore >>> configuration, others prefer to use a different term to avoid a clash >>> with what NC and YANG consider configuration. If we could find a good >>> name for such writable datastores, I likely make communication much >>> simpler. >>> >>> And yes, I think the model that the contents of the configuration >>> datastore, the writable datastore(s) as well as the information >>> learned dynamically from various control plane protocols all lead to >>> the final operational state. (In fact, one could consider a model >>> where control plane protocols all conceptually come into the system >>> via additional control protocol specific writable datastores.) >>> >>> So, can we find a name for these 'other writable datastores' and then >>> use that term instead of 'writable operational state', 'ephemeral >>> config', 'i2rs datastore', etc.? >>> >>> >> I imagine I2RS will be completely separate from NETCONF and it should >> have its own datastore -- so "i2rs-config" is appropriate because I2RS is >> the >> only protocol using that datastore. The combined "operational state" >> is not editable. >> >> >> Yes, that makes sense. Then if at some point in time you want to save >> the running config (i2rs), the system has to explicitly copy it over. But >> until then, >> its separate. The only question is: what is the complete running config >> represented as? >> And what if Netconf wants to modify the running config (i.e.: and the RIB >> in particular)? >> >> > That copy-to-local-config feature would be extra, outside the scope of the > i2rs-config. > > > > IMO, the i2rs-config datastore has these properties: > - editable with I2RS using the I2RS owner-priority access control model > - only field validation; YANG datastore validation is ignored, > except for mandatory=true|false and min/max-elements > - data is never saved across a reboot; never saved to NV-storage like > NETCONF config > - data does not time out; The system or external I2RS client must > remove any data > to cleanup > - the system uses the priority values to determine if local-config or > i2rs-config > wins wrt/ operational values; the system must install the correct > config if > priorities change > > > Right. If we take that approach we need to have a way of the i2rs > "protocol" to signal that the config > needs to be saved "soon". That is, its not done in real time, but rather > as a background process. > Its probably. This can either be through a single keyword that is added > under the i2rs-config section, or > per element or even per-element, if we decide to be more granular. > > You seem to be suggesting that the I2RS behavior of forgetting all injected state if the router happens to reboot is not that useful, and therefore it needs to be saved in the background (best-effort). I think it is up to all the I2RS clients to always be around to receive some sort of agent-reboot event, and re-install any required I2RS config. I can't imagine any use cases where the operator thinks "I only need to install this RIB data until that router accidentally reboots". --Tom > > Andy --089e0168131864012004f86f3d08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 2, 2014 at 11:07 AM, Thomas Nadeau &l= t;tnadeau@luci= dvision.com> wrote:

On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, May 2, 2014 at 10:10 AM, Thom= as Nadeau <tnadeau@lucidvision.com> wrote:

On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman <andy@yumaworks.com> wrote:=




On Fri, May 2, 2014 at 9:09 AM, Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
On Fri, May 02, 2014 at 11:40:36AM -0400, Je= ffrey Haas wrote:
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 conf= ig sources
> > and data learned from protocols and system events. =A0It seems > > both NETCONF and I2RS would be able to pick the data is cares abo= ut
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG 1.1.
> > Since it is officially just for NETCONF, there are no mechanisms<= br> > > (other than vendor extensions) to tag the data as specific to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path= of "editable
> operational state", instead configuration semantics for our purpo= ses.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have an explicit <startup/>, <candidate/> is a temporary scratch pad).<= br>
We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a clash
with what NC and YANG consider configuration. If we could find a good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and th= en
use that term instead of 'writable operational state', 'ephemer= al
config', 'i2rs datastore', etc.?


I imagine I2RS will be completely separate from NETCONF and it should=
have its own datastore -- so "i2rs-config" is appropri= ate because I2RS is the
only protocol using that datastore. The combined "operational sta= te"
is not editable.

the running config (i2rs), the system has to explicitly copy it over. = But until then,
its separate. =A0The only question is: what is th= e complete running config represented as?
And what if Netconf wan= ts to modify the running config (i.e.: and the RIB in particular)?




IMO, the i2rs-config datastore has these properties:
=A0 =A0- editable with I2RS using the I2RS owner-priority access control mo= del
=A0 =A0- only field validation; YANG datastore validation is = ignored,
=A0 =A0 =A0except for mandatory=3Dtrue|false and min/max= -elements
=A0 =A0- data is never saved across a reboot; never saved to NV-storag= e like NETCONF config
=A0 =A0- data does not time out; The system= or external I2RS client must remove any data
=A0 =A0 =A0to clean= up
=A0 =A0- the system uses the priority values to determine if local-config o= r i2rs-config
=A0 =A0 =A0wins wrt/ operational values; the system= must install the correct config if
=A0 =A0 =A0priorities change<= /div>

Right. If we take that approach we need to have a way o= f the i2rs "protocol" to signal that the config=A0
need= s to be saved "soon". =A0That is, its not done in real time, but = rather as a background process.=A0
Its probably. This can either be through a single keyword that is adde= d under the i2rs-config section, or
per element or even per-eleme= nt, if we decide to be more granular.=A0



sort of agent-reboot event, and re-install any required I2RS config.
I can't imagine any use cases where the operator thinks "I on= ly need to
install this RIB data until that router accidentally r= eboots".


--Tom


Andy

=A0
=
--089e0168131864012004f86f3d08-- From nobody Fri May 2 13:51:19 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 828251A098B for ; Fri, 2 May 2014 13:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 XIpQf2R3j2mQ for ; Fri, 2 May 2014 13:51:16 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 14CB51A091A for ; Fri, 2 May 2014 13:51:16 -0700 (PDT) Received: from [192.168.1.112] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2AF79278DF04; Fri, 2 May 2014 16:51:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C74DC9F8-F005-4118-82EB-5FBDE1EED2D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Fri, 2 May 2014 16:51:11 -0400 Message-Id: <6476959F-81DA-4ED5-9729-2F1764AE3AD3@lucidvision.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wTc3kUhY46p5nQ3gvcIkvSt7lZs Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 02 May 2014 20:51:18 -0000 --Apple-Mail=_C74DC9F8-F005-4118-82EB-5FBDE1EED2D1 Content-Type: multipart/alternative; boundary="Apple-Mail=_F186BC6C-1956-46E2-A4D0-EE9D83F030F5" --Apple-Mail=_F186BC6C-1956-46E2-A4D0-EE9D83F030F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 2, 2014:2:49 PM, at 2:49 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Fri, May 2, 2014 at 11:07 AM, Thomas Nadeau = wrote: >=20 > On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman = wrote: >=20 >>=20 >>=20 >>=20 >> On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau = wrote: >>=20 >> On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman = wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder = wrote: >>> On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote: >>> > On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: >>> > > I picture the operational state as the mixing bowl for the 2 = config sources >>> > > and data learned from protocols and system events. It seems >>> > > both NETCONF and I2RS would be able to pick the data is cares = about >>> > > out of that. >>> > >>> > I think this is what I'd like to see personally. >>> > >>> > > This is a weakness in YANG that may get improved in YANG 1.1. >>> > > Since it is officially just for NETCONF, there are no mechanisms >>> > > (other than vendor extensions) to tag the data as specific to >>> > > some subset of protocols. >>> > >>> > As I mentioned elsewhere, I'm hoping we don't go down the path of = "editable >>> > operational state", instead configuration semantics for our = purposes. >>>=20 >>> At some point in time, we need to get the terminology sorted out. NC >>> has well defined configuration datastores and YANG has a well = defined >>> concept of configuration data (config true). NC kind of assumes that >>> data in configuration datastores has an associated concept of >>> persistence (e.g., changes to persist unless you have an >>> explicit , is a temporary scratch pad). >>>=20 >>> We are talking about another writable datastore (or potentially >>> multiple of them). Some call the data in this writable datastore >>> configuration, others prefer to use a different term to avoid a = clash >>> with what NC and YANG consider configuration. If we could find a = good >>> name for such writable datastores, I likely make communication much >>> simpler. >>>=20 >>> And yes, I think the model that the contents of the configuration >>> datastore, the writable datastore(s) as well as the information >>> learned dynamically from various control plane protocols all lead to >>> the final operational state. (In fact, one could consider a model >>> where control plane protocols all conceptually come into the system >>> via additional control protocol specific writable datastores.) >>>=20 >>> So, can we find a name for these 'other writable datastores' and = then >>> use that term instead of 'writable operational state', 'ephemeral >>> config', 'i2rs datastore', etc.? >>>=20 >>>=20 >>> I imagine I2RS will be completely separate from NETCONF and it = should >>> have its own datastore -- so "i2rs-config" is appropriate because = I2RS is the >>> only protocol using that datastore. The combined "operational state" >>> is not editable. >>=20 >> Yes, that makes sense. Then if at some point in time you want to = save=20 >> the running config (i2rs), the system has to explicitly copy it over. = But until then, >> its separate. The only question is: what is the complete running = config represented as? >> And what if Netconf wants to modify the running config (i.e.: and the = RIB in particular)? >>=20 >>=20 >> That copy-to-local-config feature would be extra, outside the scope = of the i2rs-config. >=20 >=20 >> IMO, the i2rs-config datastore has these properties: >> - editable with I2RS using the I2RS owner-priority access control = model >> - only field validation; YANG datastore validation is ignored, >> except for mandatory=3Dtrue|false and min/max-elements >> - data is never saved across a reboot; never saved to NV-storage = like NETCONF config >> - data does not time out; The system or external I2RS client must = remove any data >> to cleanup >> - the system uses the priority values to determine if local-config = or i2rs-config >> wins wrt/ operational values; the system must install the = correct config if >> priorities change >=20 > Right. If we take that approach we need to have a way of the = i2rs "protocol" to signal that the config=20 > needs to be saved "soon". That is, its not done in real time, but = rather as a background process.=20 > Its probably. This can either be through a single keyword that is = added under the i2rs-config section, or > per element or even per-element, if we decide to be more granular.=20 >=20 >=20 > You seem to be suggesting that the I2RS behavior of forgetting all = injected state > if the router happens to reboot is not that useful, and therefore it = needs to be > saved in the background (best-effort). =09 Not necessarily. I am just saying that its an option that = someone might want to use.=20 > I think it is up to all the I2RS clients to always be around to = receive some > sort of agent-reboot event, and re-install any required I2RS config. > I can't imagine any use cases where the operator thinks "I only need = to > install this RIB data until that router accidentally reboots". Yes, exactly. I didn't mean to imply it was mandatory to = eventually save the running config; just that if you want to,=20 we should bake this capability in. =09 --Tom >=20 >=20 > --Tom >=20 >=20 > Andy >=20 > =20 --Apple-Mail=_F186BC6C-1956-46E2-A4D0-EE9D83F030F5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1




On Fri, May 2, 2014 at 11:07 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

On May 2, 2014:1:33 PM, at 1:33 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Fri, May 2, 2014 at 10:10 AM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

On May 2, 2014:12:26 PM, at 12:26 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Fri, May 2, 2014 at 9:09 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, May 02, 2014 at 11:40:36AM -0400, Jeffrey Haas wrote:
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 config sources
> > and data learned from protocols and system events.  It seems
> > both NETCONF and I2RS would be able to pick the data is cares about
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG 1.1.
> > Since it is officially just for NETCONF, there are no mechanisms
> > (other than vendor extensions) to tag the data as specific to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path of "editable
> operational state", instead configuration semantics for our purposes.

At some point in time, we need to get the terminology sorted out. NC
has well defined configuration datastores and YANG has a well defined
concept of configuration data (config true). NC kind of assumes that
data in configuration datastores has an associated concept of
persistence (e.g., changes to <running/> persist unless you have an
explicit <startup/>, <candidate/> is a temporary scratch pad).

We are talking about another writable datastore (or potentially
multiple of them). Some call the data in this writable datastore
configuration, others prefer to use a different term to avoid a clash
with what NC and YANG consider configuration. If we could find a good
name for such writable datastores, I likely make communication much
simpler.

And yes, I think the model that the contents of the configuration
datastore, the writable datastore(s) as well as the information
learned dynamically from various control plane protocols all lead to
the final operational state. (In fact, one could consider a model
where control plane protocols all conceptually come into the system
via additional control protocol specific writable datastores.)

So, can we find a name for these 'other writable datastores' and then
use that term instead of 'writable operational state', 'ephemeral
config', 'i2rs datastore', etc.?


I imagine I2RS will be completely separate from NETCONF and it should
have its own datastore -- so "i2rs-config" is appropriate because I2RS is the
only protocol using that datastore. The combined "operational state"
is not editable.

Yes, that makes sense. Then if at some point in time you want to save 
the running config (i2rs), the system has to explicitly copy it over. But until then,
its separate.  The only question is: what is the complete running config represented as?
And what if Netconf wants to modify the running config (i.e.: and the RIB in particular)?


That copy-to-local-config feature would be extra, outside the scope of the i2rs-config.


IMO, the i2rs-config datastore has these properties:
   - editable with I2RS using the I2RS owner-priority access control model
   - only field validation; YANG datastore validation is ignored,
     except for mandatory=true|false and min/max-elements
   - data is never saved across a reboot; never saved to NV-storage like NETCONF config
   - data does not time out; The system or external I2RS client must remove any data
     to cleanup
   - the system uses the priority values to determine if local-config or i2rs-config
     wins wrt/ operational values; the system must install the correct config if
     priorities change

Right. If we take that approach we need to have a way of the i2rs "protocol" to signal that the config 
needs to be saved "soon".  That is, its not done in real time, but rather as a background process. 
Its probably. This can either be through a single keyword that is added under the i2rs-config section, or
per element or even per-element, if we decide to be more granular. 


You seem to be suggesting that the I2RS behavior of forgetting all injected state
if the router happens to reboot is not that useful, and therefore it needs to be
saved in the background (best-effort).
Not necessarily. I am just saying that its an option that someone might want to use. 

I think it is up to all the I2RS clients to always be around to receive some
sort of agent-reboot event, and re-install any required I2RS config.
I can't imagine any use cases where the operator thinks "I only need to
install this RIB data until that router accidentally reboots".

Yes, exactly. I didn't mean to imply it was mandatory to eventually save the running config; just that if you want to, 
we should bake this capability in.

--Tom





--Tom


Andy

 

--Apple-Mail=_F186BC6C-1956-46E2-A4D0-EE9D83F030F5-- --Apple-Mail=_C74DC9F8-F005-4118-82EB-5FBDE1EED2D1 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 iQIcBAEBCgAGBQJTZAU/AAoJEPcO+I7eiUJZd7sP/RZjRtIusPypPKfflw7PO355 tEHfMI/LbwA8MZGt+RVzhrIBuuvOUqslX5Q3jQ+01cee1I8Yv2wkn7QFa0G6310J R68sxlo2DR+jL/4ESEOW7a6DQNbmQd5pbf6nNEoJE4z+A8vL47A+/OIFf0RmHexU +rjuYw+6wEqi4tr4fO7volTRR2qO4iqCxdNLBS24uzVWKllYHmNNDWyF1hQOPg0m x6rmGJhFN12XBXCAr3AnF7B0g3JtmJg9c4ZYkSSD18xReJ8cpM4TVhhAfh4kwu4T eVH6lPgKfKkgac++qHZhtAwGzZsAs+qNpNuEdDWUleNxKITBneqaki59WBES240V gbQNvbnjd7HguP/HEEUChkSoRBBRUhh2utgymejdtOnx1+QsQbOVAEjhTkDxuDZA KlL5Y3TtI7FwMhFZ7RC+98EwCsXO4YJVbbQndRnfSk/Ke43fRGaIRiTXoDgG/wOk U3vOkAwE059roj8z0cOEJPVsYPFiMo8PTkRA63VuZyTi1Dazwc/VjhnnIXbGTaW2 Bvr3mFmJ1i8unmfEaY4d+Y7SixfRPtgyBMDJ5w5lHNdJJn/fkE0hSTjqqrgLdJJk TMxgYb9qwxgVfif927O7v5HNvKil83YDR+IjoPpZlI4W7DAlfGuOUG8eyGGxrRK3 KRm6BV/RsVdD9Ifz1KGB =fmCG -----END PGP SIGNATURE----- --Apple-Mail=_C74DC9F8-F005-4118-82EB-5FBDE1EED2D1-- From nobody Sat May 3 02:23: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 8000E1A0055 for ; Sat, 3 May 2014 02:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 N_-87MXZo_Io for ; Sat, 3 May 2014 02:23:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3BA1A0024 for ; Sat, 3 May 2014 02:23:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 922121135; Sat, 3 May 2014 11:23:08 +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 Pq1sDNkP8Kr1; Sat, 3 May 2014 11:23:08 +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; Sat, 3 May 2014 11:23:07 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E813520017; Sat, 3 May 2014 11:23:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tXDlK33zMMaX; Sat, 3 May 2014 11:23:07 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0134420013; Sat, 3 May 2014 11:23:05 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 4A5CA2CC8713; Sat, 3 May 2014 11:23:03 +0200 (CEST) Date: Sat, 3 May 2014 11:23:03 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140503092303.GA38137@elstar.local> Mail-Followup-To: Andy Bierman , Thomas Nadeau , Jeffrey Haas , "i2rs@ietf.org" , "t. petch" References: <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> 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/Zf_fmUSDtFe_O9hwbKTGjECBI48 Cc: Jeffrey Haas , Thomas Nadeau , "t. petch" , "i2rs@ietf.org" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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: Sat, 03 May 2014 09:23:14 -0000 On Fri, May 02, 2014 at 10:33:37AM -0700, Andy Bierman wrote: > > I imagine I2RS will be completely separate from NETCONF and it > > should have its own datastore -- so "i2rs-config" is appropriate > > because I2RS is the only protocol using that datastore. The > > combined "operational state" is not editable. Separate datastore, yes. Is it a config datastore? I thought no. The name "i2rs-config" seems to imply that so I am confused. Perhaps you should simply call it "i2rs" datastore. > That copy-to-local-config feature would be extra, outside the scope of the > i2rs-config. > IMO, the i2rs-config datastore has these properties: > - editable with I2RS using the I2RS owner-priority access control model > - only field validation; YANG datastore validation is ignored, > except for mandatory=true|false and min/max-elements > - data is never saved across a reboot; never saved to NV-storage like > NETCONF config > - data does not time out; The system or external I2RS client must remove > any data > to cleanup > - the system uses the priority values to determine if local-config or > i2rs-config > wins wrt/ operational values; the system must install the correct > config if > priorities change With all this, I am not sure how copy to local config will work. You will then likely get all the validation errors and there may be interesting access control issues with it. I also do not know what the "I2RS owner-priority access control model" really is. Where are the priority values that control whether the running configuration datastore or the i2rs datastore value is taken? May I presume that this is configured in the configuration datastore (e.g. there is going to be a YANG data model to configure the priority rules)? /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 Sat May 3 03:16: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 40F611A0064 for ; Sat, 3 May 2014 03:16:31 -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 v7jj7L9rxuj4 for ; Sat, 3 May 2014 03:16:30 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id D9C351A0062 for ; Sat, 3 May 2014 03:16:29 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id i17so5213977qcy.11 for ; Sat, 03 May 2014 03:16:27 -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=4VD0Qmb8bT0hCOQfw+LJDktPMYcsxYyCZuSOHZWCOyo=; b=CvK/ZszRaqROmiqfj3cjjNX/2SXG1RRbLnDJDP+9jv1aksa+qE+Bl8AqSSFr28sZhQ UWC3s/oznaQNNIvK6ZTrnDsjvMyC5Wk96uiS84vq3rhpTNDJHie0/g4JT7tPJJ9PAsPg ZoqEfZHMncui+tw0E/EwLMd3vRZgleWok3lCQTPs/tRm4QwKXYAA/y3KHrj9jvXPQa1b PX9tkv7tNS/CrlZ3Qgmm25dtyLn/SjvOGL5XUAtsngDgHHDLNWFIs7h1Zqt8GEckH9Sq lmIWVNYM0AA2A7XhboYCiJXdphQ3C1AFJD8gkM7BdeYfSnUiq8RDVKGckh8v+8LrdjME Ru1A== X-Gm-Message-State: ALoCoQnSllS7SvHyYdkAV9NH6ZQmOo7wfrGILqdF3Q2oKymgqBazVAnsmdDLoqH9mYsfYCNp8vr5 MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr26535178qad.88.1399112187123; Sat, 03 May 2014 03:16:27 -0700 (PDT) Received: by 10.140.104.14 with HTTP; Sat, 3 May 2014 03:16:27 -0700 (PDT) In-Reply-To: <20140503092303.GA38137@elstar.local> References: <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <20140503092303.GA38137@elstar.local> Date: Sat, 3 May 2014 03:16:27 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Thomas Nadeau , Jeffrey Haas , "i2rs@ietf.org" , "t. petch" Content-Type: multipart/alternative; boundary=089e0158a9e4ea2e3b04f87c30b5 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/BXrDHUD0t8DpvzySUfkaVoZQ6Kw Subject: Re: [i2rs] edit-data substatement Re: Operational State 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: Sat, 03 May 2014 10:16:31 -0000 --089e0158a9e4ea2e3b04f87c30b5 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 3, 2014 at 2:23 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, May 02, 2014 at 10:33:37AM -0700, Andy Bierman wrote: > > > > I imagine I2RS will be completely separate from NETCONF and it > > > should have its own datastore -- so "i2rs-config" is appropriate > > > because I2RS is the only protocol using that datastore. The > > > combined "operational state" is not editable. > > Separate datastore, yes. Is it a config datastore? I thought no. The > name "i2rs-config" seems to imply that so I am confused. Perhaps you > should simply call it "i2rs" datastore. > > > That copy-to-local-config feature would be extra, outside the scope of > the > > i2rs-config. > > IMO, the i2rs-config datastore has these properties: > > - editable with I2RS using the I2RS owner-priority access control > model > > - only field validation; YANG datastore validation is ignored, > > except for mandatory=true|false and min/max-elements > > - data is never saved across a reboot; never saved to NV-storage like > > NETCONF config > > - data does not time out; The system or external I2RS client must > remove > > any data > > to cleanup > > - the system uses the priority values to determine if local-config or > > i2rs-config > > wins wrt/ operational values; the system must install the correct > > config if > > priorities change > > With all this, I am not sure how copy to local config will work. You > will then likely get all the validation errors and there may be > interesting access control issues with it. I also do not know what the > "I2RS owner-priority access control model" really is. Where are the > priority values that control whether the running configuration > datastore or the i2rs datastore value is taken? May I presume that > this is configured in the configuration datastore (e.g. there is going > to be a YANG data model to configure the priority rules)? > > I was not defining something out of scope for I2RS. That is up to the vendor implementing this extension. Obviously the YANG validation rules are not ignored for config=true nodes. I2RS uses its own access control, not NACM. You ask about minor details of a protocol that has not been written yet. The priorities are set somehow. (I am not convinced the trivial I2RS priority scheme will actually work -- using 1 numeric value for all of local-config. It seems like the priority could be data-dependent.) /js > > Andy --089e0158a9e4ea2e3b04f87c30b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, May 3, 2014 at 2:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, May 02, 2014 at 10:33:37AM -0700, An= dy Bierman wrote:

> > I imagine I2RS will be completely separate from NETCONF and it > > should have its own datastore -- so "i2rs-config" is ap= propriate
> > because I2RS is the only protocol using that datastore. The
> > combined "operational state" is not editable.

Separate datastore, yes. Is it a config datastore? I thought no. The
name "i2rs-config" seems to imply that so I am confused. Perhaps = you
should simply call it "i2rs" datastore.

> That copy-to-local-config feature would be extra, outside the scope of= the
> i2rs-config.
> IMO, the i2rs-config datastore has these properties:
> =A0 =A0- editable with I2RS using the I2RS owner-priority access contr= ol model
> =A0 =A0- only field validation; YANG datastore validation is ignored,<= br> > =A0 =A0 =A0except for mandatory=3Dtrue|false and min/max-elements
> =A0 =A0- data is never saved across a reboot; never saved to NV-storag= e like
> NETCONF config
> =A0 =A0- data does not time out; The system or external I2RS client mu= st remove
> any data
> =A0 =A0 =A0to cleanup
> =A0 =A0- the system uses the priority values to determine if local-con= fig or
> i2rs-config
> =A0 =A0 =A0wins wrt/ operational values; the system must install the c= orrect
> config if
> =A0 =A0 =A0priorities change

With all this, I am not sure how copy to local config will work. You
will then likely get all the validation errors and there may be
interesting access control issues with it. I also do not know what the
"I2RS owner-priority access control model" really is. Where are t= he
priority values that control whether the running configuration
datastore or the i2rs datastore value is taken? May I presume that
this is configured in the configuration datastore (e.g. there is going
to be a YANG data model to configure the priority rules)?


I was not defining something out of scope for I2RS.<= /div>
That is up to the vendor implementing this extension.
Obviously the YANG validation rules are not ignored for config=3Dtrue nodes= .

I2RS uses its own access control, not NACM.
You ask about minor details of a protocol that has not been written y= et.
The priorities are set somehow. =A0(I am not convinced the trivial I2R= S priority
scheme will actually work -- using 1 numeric value for= all of local-config.
It seems like the priority could be data-de= pendent.)

/js


Andy
=A0
=
--089e0158a9e4ea2e3b04f87c30b5-- From nobody Sun May 4 03:50: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 066941A0061 for ; Sun, 4 May 2014 03:50:51 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 8nM9kHOfXrgr for ; Sun, 4 May 2014 03:50:48 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id BBAFF1A005D for ; Sun, 4 May 2014 03:50:48 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hr9so7524941vcb.29 for ; Sun, 04 May 2014 03:50:45 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=eXQBkuXblmuNnlUg8/u9oXg8pQ4DrpSfoN5/ZLnKIMQ=; b=UmpCSJ8eJ3jC+aFZ8VZlsfp7cC3sCCBOhQ/1jG/0390Lcp9jKWvUvklv6WcQNu6L7x ZaLC19fyf5FF30bp6CyJQU2jUHCTB/rLDLNXBNOaf33kYZ/kopMQEEx5xaHUkwkC1P/P H51D0/xffyZFrbbXsOsd8QLSHIfhhBhKp/UMwy4kLfRmne2MdAV20DBhCkTOwSTya+ou k1KSgtZP4RiAXTGYaJWziwGpvNldAobCs9QmSW3z1ZzUkmhZqfNButpA1z3GWhfuhqvm 8taUkD3WnHpHHBjJ+ae5oNh/zeWmqq04btSsnbJ0jBLw/bhAv86OffLKCDX3ywbxT6yo d46w== X-Gm-Message-State: ALoCoQkCFVyV411CwLO/gX9CIQ2vn+rRlHRL5/DMrXAJaYVjFuMpt10ntuOKVFZ1ncQkxhCq1Vfw X-Received: by 10.58.111.163 with SMTP id ij3mr223176veb.26.1399200645317; Sun, 04 May 2014 03:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sun, 4 May 2014 03:50:25 -0700 (PDT) In-Reply-To: <14331372-5EB5-428D-9851-C76E72E2AE7C@juniper.net> References: <535916F0.3050206@joelhalpern.com> <55AA400B-3D5A-4980-8330-3541A1663586@juniper.net> <14331372-5EB5-428D-9851-C76E72E2AE7C@juniper.net> From: Jamal Hadi Salim Date: Sun, 4 May 2014 06:50:25 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pICQJRfYiOK3BWwifGnP7DdwG9c Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model 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: Sun, 04 May 2014 10:50:51 -0000 Hi Dean, I stand corrected then. So let me instead use figure 1 of the statement problem doc that just got published. Or use figure 1 of arch document. If any of the resources accessed via the agent are daemons (which translates to async access) then this (proxying) issue will surface. But again this may all be implementation specific. To make it clear: the apps C-E of client P on figure 1 of the architecture doc *is* susceptible to such a challenge. cheers, jamal. On Thu, May 1, 2014 at 12:48 PM, Dean Bogdanovic wrote: > Jamal, > > On Apr 29, 2014, at 9:47 AM, Jamal Hadi Salim wrote: > >> Dean, >> >> In your slides, IIRC, at the meeting you illustrated several daemons >> all interacting with the >> agent doing different things. > > Not completely correct. I have only one agent talking to multiple daemons= and that is the analytics agent. Routing and filtering agents in the pictu= re are talking only to its respective daemons. With the analytics agent, ha= ving one for each daemon is an overhead imo. > > Dean > >> In our case it will very likely be >> multiple daemons doing >> different things for the agent (and sometimes remote machines). In any >> case, this may end up being >> an implementation issue. >> I have another issue I will post probably under a separate topic: >> Prioritization. >> >> cheers, >> jamal >> >> On Mon, Apr 28, 2014 at 4:23 PM, Dean Bogdanovic wro= te: >>> Jamal, >>> >>> There is only one agent to one daemon. There is no scenario of one agen= t to multiple daemons. >>> >>> There are multiple clients to one agent. >>> >>> So agent is depending on the speed of daemon and agent should protect o= verloading daemon with requests, so it can police requests from clients. >>> >>> Dean >>> >>> >>> On Apr 24, 2014, at 9:56 PM, Jamal Hadi Salim wrote= : >>> >>>> I was mostly referring to overload conditions (of both compute and >>>> wire resources). >>>> It is feasible for a client not to be able to keep up (eg a table dump >>>> response; i.e a single >>>> request resulting in a large fast bulk response). However, >>>> the more interesting case is for a daemon overload as a result of some >>>> client transaction; >>>> assuming possibly N daemons talk to an agent on the south bound >>>> multiplexing to M clients >>>> on the northbound, where M>>N - and how to deal with the client(s) >>>> that are responsible for the >>>> overload without adversely affecting the other clients that dont >>>> contribute to overload. >>>> Some of this could be implementation issues. >>>> >>>> I think l misunderstood what you and Andy were saying to imply you >>>> meant M equals N equals 1. >>>> >>>> cheers, >>>> jamal >>>> >>>> >>>> On Thu, Apr 24, 2014 at 4:03 PM, Dean Bogdanovic w= rote: >>>>> >>>>> On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim wr= ote: >>>>> >>>>>> I was more looking at the agent - it brokers between clients and the >>>>>> RIB subsystem >>>>>> as shown in figure 1 of the architecture doc. Different clients brin= g >>>>>> different latencies/capacities. >>>>>> Congestions will kick in, >>>>> how does client latency influence agent? The agent sees request comin= g in from different authorized clients at a rate and it is processing those= requests. The agent will depend on the daemon performance, but not on clie= nt. >>>>> >>>>>> reliability requirements will need to be >>>>>> considered. And there may >>>>>> be need to signal these details to the clients (SIP proxying is the >>>>>> closest i can think of). >>>>>> You cant solve this problem by just inserting a reliable transport >>>>>> where the i2rs protocol >>>>>> runs. >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>> On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern wrote: >>>>>>> No, there is no requirement that the client is a broker. He may be= , or he >>>>>>> may not. And the scope of his brokering, if he is a broker, may be >>>>>>> application specific or more general. >>>>>>> >>>>>>> We have placed requirements to be able to provide traceability when= the >>>>>>> client is brokering. This is as much because even a non-broker may= be >>>>>>> acting on behalf of several different applications. >>>>>>> >>>>>>> As far as I can tell, the fact that a client may itneract with mult= iple >>>>>>> agents does not in itself palce new protocol or model requirements = on the >>>>>>> system. If we wanted inter-agent atomicity, then there would be >>>>>>> requirements. But we explicitly decided that was out of scope. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> >>>>>>> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>>>>>>> >>>>>>>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman = wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>>>>>>> across N locked I2RS agents? >>>>>>>>> >>>>>>>> >>>>>>>> There is a requirement to allow only one client to own write acces= s to >>>>>>>> a specified object in order to avoid locking. There is nothing obj= ecting >>>>>>>> to a client being able to write to multiple objects as long as tha= t rule >>>>>>>> is met. >>>>>>>> >>>>>>>>> The agents do not coordinate with each other. >>>>>>>>> The clients do not coordinate with each other. >>>>>>>>> >>>>>>>>> This is currently out of scope for the I2RS protocol. >>>>>>>>> >>>>>>>> >>>>>>>> Both assertions true. >>>>>>>> But what i was responding to is: >>>>>>>> There are multiple clients that connect to the same agent. >>>>>>>> And a client can connect to multiple agents. >>>>>>>> >>>>>>>> I believe that such a requirement _may_ call out certain features = in >>>>>>>> the protocol. Essentially the agent is a broker. >>>>>>>> >>>>>>>> cheers, >>>>>>>> jamal >>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> jamal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>>> From: Jamal Hadi Salim >>>>>>>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>>>>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>>>>>>> To: Dean Bogdanovic >>>>>>>>>> Cc: Andy Bierman , "" >>>>>>>>>> , Martin Bjorklund , "" >>>>>>>>>> , "" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman = wrote: >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent= . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dont think so. >>>>>>>>>> >>>>>>>>>>> Network locking across devices is out of scope. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I have same opinion as you on this one, just wanted to spell it= out one >>>>>>>>>>> more >>>>>>>>>>> time explicitly, as I heard some discussions where network lock= ing was >>>>>>>>>>> coming up. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Either I am misunderstanding both of you or both of you misunder= stood >>>>>>>>>> the >>>>>>>>>> requirement. >>>>>>>>>> The idea is to allow a single writer per object as a starting po= int. >>>>>>>>>> OTOH, if you really mean what you say then I violently disagree. >>>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> jamal >>>>>>>>>> >>>>>>>>>> PS:- Changing the topic so this is not lost in the noise because= i think >>>>>>>>>> that >>>>>>>>>> the many clients-single agent brings needs for other protocol >>>>>>>>>> requirements. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>> >>> > From nobody Sun May 4 04:02: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 C17AB1A006B for ; Sun, 4 May 2014 04:02:36 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 ZmPecwVLrn4l for ; Sun, 4 May 2014 04:02:32 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5518F1A0067 for ; Sun, 4 May 2014 04:02:32 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id pa12so6288867veb.4 for ; Sun, 04 May 2014 04:02:29 -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:from:date :message-id:subject:to:cc:content-type; bh=mmVq6ZjyUJi50+g0JqYCxCS+70D8KIYhAznjInnqmD0=; b=QdKmy0IwO5KkyucF946tgZR2Uv97fPioZAHNjxzpkScLjc1KWYyLstZ0LgtKOufvpf 1IYM+vcTNWhq+TnpUSt7JpSuGI1ZpAqCuWaUmdOi2DEpLd5i3gxacgiN4CC0Ya3OL38f R907mD0ARjboUVkCoDn1jCo5vvVCM/1zY4NX/SnaW7ZVSiEf9xTR+nckgAJv9+yrWsXO mAG4POZ+IZ3hG17zjf5a/2fGvehrhrmsfuXge2ZgJfa/62XoFp/0mXsKAhOjv2fuVLJR zvYxFf+2/ZwQ70m8tOvIUbEc2y3eIVcQbYcbT/jmzsqlTHPp83p7LuFuzhmRwypxWul6 +Nww== X-Gm-Message-State: ALoCoQncLq4APuRcsteVhixb56i89Z0rm5SSoReArRcCZ8FfxG7mDNypDdSrxhn2+dKrnwQWojoI X-Received: by 10.52.253.75 with SMTP id zy11mr19389723vdc.10.1399201349102; Sun, 04 May 2014 04:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sun, 4 May 2014 04:02:09 -0700 (PDT) In-Reply-To: <20140501003021.GZ1256@pfrc> References: <20140501003021.GZ1256@pfrc> From: Jamal Hadi Salim Date: Sun, 4 May 2014 07:02:09 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LGjIsYczLRiQJriajZW-N_M01vU Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model Requirements WAS(Re: consensus on I2RS protocol and model 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: Sun, 04 May 2014 11:02:36 -0000 Jeff, I have been travelling and didnt have time to do this - but it helped me reflect a little more on the topic. I think it would be best to come up with some form of pseudo requirements first then do the analysis. I will work on a set of requirements for protocol then model and post them on the list. I will try to extract them from the differrent docs; some of what i put out will be a matter of opinion so i may get shot down but at least we would have one smell test for everyone. cheers, jamal On Wed, Apr 30, 2014 at 8:30 PM, Jeffrey Haas wrote: > On Sat, Apr 19, 2014 at 06:43:33AM -0400, Jamal Hadi Salim wrote: >> So 54 emails later.... > [...] > And now I'm many beyond that... :-) > >> Andy, Dean and myself included presented based on our view of what the >> requirements are. >> There are no requirements spelt out anywhere. Why is this such a hard >> question to ask >> around an engineering forum? > > I have to agree that we're not converging on requirements in an explicit > form. > > What I do see is that we're covering implicit forms of the requirements by > discussing the proposed solutions and the issues with them. > > I'll remind all sides that I created wiki stubs for these to be documented. > In the absence of someone filling them in, I'll write down some of my own > observations early next week. > > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/NetconfYangAnalysis > > -- Jeff From nobody Sun May 4 05:09:36 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 568761A0117 for ; Sun, 4 May 2014 05:09:34 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 P-HdlCsl8ELq for ; Sun, 4 May 2014 05:09:32 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3AD91A0077 for ; Sun, 4 May 2014 05:09:32 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id id10so7495391vcb.31 for ; Sun, 04 May 2014 05:09:29 -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:from:date :message-id:subject:to:cc:content-type; bh=kXYCIXBlZjCpx9c0LAbtfREImqPyVdVze60KNGOWhMU=; b=XKsRqbJETELMEZ7/gXrs+2Y289CHaMwn7s9I0Yknvfa2TK1QoCGoJZLPCNSaXLgBj+ GffcQBTlVtvqBJwDoIp8c1DxQFRmbKed0qg5Y/MI2XDw/Bbd2MbLeccnctGfAIPxmpEE Ge9luXbD77VPETdqWk0PeGoCKuExIGk0m0i15SUaVc0mK5WJdV3ICZmAJKX9Jlt9UHCn ke5ybzWSIlpge4oTaDgVdnGstwNm+bt3iusCROIfQ9SDT1Sr7zM3EIt0P7sw3dzNT1Op RkOxlSFLoiZskSBnAsG9vBgc2aOz0zlf7kP5mCIx2fOA0UenTDY4koMIPfffxNqSOX+g wcjQ== X-Gm-Message-State: ALoCoQm+dKvxEJTXjVvWl7ZRru/uN8PYSgQZTBsilCeT81xlsWNRgfAwroS99lYl3V0nuzQ97LPP X-Received: by 10.52.163.145 with SMTP id yi17mr11488vdb.46.1399205369410; Sun, 04 May 2014 05:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sun, 4 May 2014 05:09:09 -0700 (PDT) In-Reply-To: <20140430234841.GW1256@pfrc> References: <20140430234841.GW1256@pfrc> From: Jamal Hadi Salim Date: Sun, 4 May 2014 08:09:09 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/33f3w5wKYuocdfKW-m6ZTwZHZTk Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Dean Bogdanovic , Andy Bierman Subject: Re: [i2rs] Clients-Agents protocol prioritization 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: Sun, 04 May 2014 12:09:34 -0000 You expressed the issues well. On Wed, Apr 30, 2014 at 7:48 PM, Jeffrey Haas wrote: > On Tue, Apr 29, 2014 at 10:19:14AM -0400, Jamal Hadi Salim wrote: >> This is back again with node overload. >> Our experience with ForCES made us prioritize events and request-response >> differently. This is important only when there is an overload case. >> As an example if i had sufficient cycles/bandwith/ram space to respond to either >> an ADD or an event - I choose to use those resources to process and respond >> to the ADD; which means events are not reliably delivered to the clients. >> >> I think something like this would be needed for I2RS. > > In our architecture, we are permitting multiple clients to communicate with > one agent, so this somewhat compounds the issue. Given the nature of what I2RS serves, it is a challenge (the problem domain is simpler when serving files as an example). > It does permit some amount > of discussion of what we can do about a few issues in this problem space: > > - Pipelining: If you can submit multiple requests but they must be satisfied > in the order submitted (e.g. as per netconf), the amount of work that a > given request implies has impact on overall throughput. I think we should allow pipelining and batching to improve throughput. pipelining should be window-ed in general and based on the transaction in flight manageable by the client. [I will add these to the "protocol requirements" i promised to send]. > - Even if you're able to bypass this to some extent using multiple client > sessions, if the resources you're working with rendezvous at a common > blocking point (e.g. some RIB service that has internal mutual exclusion > semantics), then this can be problematic. We're not doing locking and > thus we're not exploring the semantic of saying "would block". > You expressed this better than i did. It was a point i was trying to get across in my earlier post. Essentially access to the rendezvous point is shared by many users/clients and the agent is acting as a dispatcher. If the access is asynchronous, something along the request or response path is going to overload at some point and then the typical remedy is to start dropping. I think most of this is implementation-resolvable e.g. If you are using windowed transport (like tcp/sctp) then you can stop reading from the source (source) that is creating work and there will be backpressure build up. But i dont think this resolves the issue if the source is a shared resource. > - The work in a reply may be huge. Consider a single client having in its > work queue a "add route" and a "give me the entire BGP RIB". Ordering > will clearly have impacts on how quickly the add route operation > completes. Indeed. There is also the other direction (client->agent). e.g a client doing 500K route updates (say in batches of 1K routes per msg) vs one that is doing a single route update. This is a fairness challenge which is likely addressable via implementation. > I suspect that (mutex example aside), operational semantics across more than > one client session may address many of these issues. What isn't clear is > what needs to be addressed in our documents about such issues. There are no issue to address if there is no overload. So what needs to be addressed is "agent overload" I think. Priorities become important to manage in such a case (regardless of whether you use multiple or a single session). cheers, jamal > -- Jeff From nobody Sun May 4 07:49: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 1A39F1A00B4 for ; Sun, 4 May 2014 07:49:08 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 6p-kEOx6Xjpd for ; Sun, 4 May 2014 07:49:04 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5832C1A00A8 for ; Sun, 4 May 2014 07:49:04 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lg15so4726831vcb.35 for ; Sun, 04 May 2014 07:49:01 -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:from:date:message-id:subject:to:cc :content-type; bh=NJoweAzZ7Pho1KeHCiSVYodewUdLHiBkEJSx7qYSJaw=; b=RPg/ZKvYg3g3VmxIWvYihUZlA3uBhSWGM66mcRLeRko8nbwFzABo6JY087CntwYPyk Hb34dd3TYRluib4Xe4/TCRycJCHXEGT5U4YvWoaqMxp1G/3td1fku3bD8Dx9s1b4QcEB jMm6E/o2ZKyxLm0a5XQRKhDfe/kOoggFKQPFPXOypKZ7QnHm837cRgjjZsgIBnpOiFhL WRM4PCjS0ts4Em2gYRyXo3w2dMUbDZ0raH0pz7wEz5grcB8IpWJ7q3eHFbMaqodvm8j/ 83i85CpfYYXhMrgFJiAMi1b40Nr9AXaLppNrrul/zpMfIgsI2hdZ1heKRDLZ+VkgpQ02 oO3A== X-Gm-Message-State: ALoCoQmPwj0mKEpdFEi4IOnXBvcTYITzhnLdJKJB7iyVYsI63yOq+ZtYQjd2EjduRJ4yM8x1XxJJ X-Received: by 10.221.67.67 with SMTP id xt3mr273906vcb.41.1399214941006; Sun, 04 May 2014 07:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sun, 4 May 2014 07:48:39 -0700 (PDT) From: Jamal Hadi Salim Date: Sun, 4 May 2014 10:48:39 -0400 Message-ID: To: i2rs Content-Type: multipart/mixed; boundary=001a113383e8861d0104f8941d6f Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UYNllE1ziElFeFOqiEh-ols5_sM Cc: Jeffrey Haas , Edward Crabbe , Dean Bogdanovic , Andy Bierman Subject: [i2rs] protocol requirements 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: Sun, 04 May 2014 14:49:08 -0000 --001a113383e8861d0104f8941d6f Content-Type: text/plain; charset=UTF-8 Jeff, I could add this to the wiki and we could keep updating it. Next i will do something similar for the model. Dean/Andy - Feel free to throw rotten tomatoes; at least that way we have something to talk about. cheers, jamal --001a113383e8861d0104f8941d6f Content-Type: text/plain; charset=US-ASCII; name="proto-reqs.txt" Content-Disposition: attachment; filename="proto-reqs.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_husgexkv0 ClRoZSBJMlJTIHByb3RvY29sIG11c3Qgc2F0aXNmeSB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50 cy4KCjEpIE1vZGVsLURyaXZlbiBQcm9ncmFtbWF0aWMgSW50ZXJmYWNlcwpUaGUgSTJSUyBwcm90 b2NvbCBNVVNUIHdvcmsgaW4gY29uanVuY3Rpb24gd2l0aCBJMlJTIGRhdGEgbW9kZWwKdG8gZmFj aWxpdGF0ZSBwcm9ncmFtbWF0aWMgaW50ZXJmYWNlcwoKMikgRXh0ZW5zaWJpbGl0eQpUaGUgSTJS UyBwcm90b2NvbCBNVVNUIGJlIGV4dGVuc2libGUKCjMpIFByb3RvY29sIG9wZXJhdGlvbnMKClRo ZSBJMlJTIHByb3RvY29sLCB1c2luZyB0aGUgSTJSUyBkYXRhIG1vZGVsLCBNVVNUIGFsbG93IGNs aWVudHMgdG86CmEpIGRldGVybWluZSB0aGUgY2FwYWJpbGl0aWVzIGFuZCBjYXBhY2l0aWVzIGV4 cG9zZWQgYnkgZWFjaCBhZ2VudC4KYikgY29udHJvbChhZGRpbmcvdXBkYXRpbmcvZGVsZXRpbmcp IGFuZCBxdWVyeSB0aGUgdmFyaW91cyBJMlJTIG9iamVjdHMKb3duZWQgYnkgYW4gYWdlbnQKYykg c3Vic2NyaWJlIHRvIGFuZCByZWNlaXZlIGFnZW50LWdlbmVyYXRlZCBldmVudHMgCmQpIGFuYWx5 dGljcywgYXVkaXRzIGFuZCBsb2dnaW5nCipwcm90b2NvbCByZXF1aXJlbWVudHMgYmVpbmcgYWJp bGl0eSB0byBleHByZXNzIHRpbWUgc3RhbXBzIGFuZCBpZGVudGl0eQoqKiBub3Qgc3VyZSBpZiB0 aGlzIGNhbGxzIG91dCBmb3IgInN0cmVhbWluZyIgb2YgZGF0YSAoYXMgb3Bwb3NlZCB0bwptZXNz YWdlIGJhc2VkKSBhbmQgd2hldGhlciBhIHJlcXVpcmVtZW50IHRvIGNhbGwgb3V0IGhlcmUgaXMg c2VwYXJhdGUKImNoYW5uZWwiIGZvciB0aGlzIGtpbmQgb2YgYWN0aXZpdHkuCgo0KSBTdXBwb3J0 IGZvciBTZWN1cmUgQ29tbXVuaWNhdGlvbiBiZXR3ZWVuIGNsaWVudHMgYW5kIGFnZW50LgpJMlJT IHByb3RvY29sIGNvbW11bmljYXRpb25zIG11c3QgYWxsb3cgZm9yIG11dHVhbCBtZXNzYWdlIGF1 dGhlbnRpY2F0aW9uLAphbmQgZGlmZmVyZW50IGxldmVscyBvZiBpbnRlZ3JpdHksIGNvbmZpZGVu dGlhbGl0eSwgYW5kIHJlcGxheSBwcm90ZWN0aW9uCm9mIHBhY2tldHMuCgo1KSBDbGllbnQgSWRl bnRpdHkgYW5kIEF1dGhlbnRpY2F0aW9uCkFueSBjbGllbnQgdG8gYWdlbnQgb2JqZWN0IGFjY2Vz cyBtdXN0IGJlIHN1YmplY3QgdG8gbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCAKYXV0aG9yaXphdGlv biBhbmQgcmVzb3VyY2UgYWNjb3VudGFiaWxpdHkuIApUaGUgcHJvdG9jb2wgTUFZIG5lZWQgdG8g Y2FycnkgaW5mb3JtYXRpb24gdG8gZW5hYmxlIHRoaXMgcmVxdWlyZW1lbnQuCgo2KSBTY2FsYWJp bGl0eQphKSBUaGUgSTJSUyBwcm90b2NvbCBNVVNUIGJlIGNhcGFibGUgb2Ygc3VwcG9ydGluZyAK ICAgYXQgbGVhc3QgdGhvdXNhbmRzIG9mIGNsaWVudHMgZW5kIHBvaW50cy4gaS5lIHRoZXJlIHNo b3VsZCBiZSAKICAgbm8gbGltaXRhdGlvbiBpbiB0aGUgcHJvdG9jb2wgZGVmaW5pdGlvbiB3aGlj aCByZXN0cmljdHMgdGhlIGFnZW50CiAgIGZyb20gaGFuZGxpbmcgbWFueSBjbGllbnRzIChlLmcg aW4gYSBoZWFkZXIgZGVmaW5pdGlvbiBkb250IHVzZQogICBhbiA4Yml0IGZpZWxkIHRvIGRlZmlu ZSBhIGNsaWVudCBpZCkKYikgTXVsdGlwbGUgcGlwZWxpbmVkIE9wZXJhdGlvbnM6ICAgQSBzaW5n bGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIAogICB0byBzZW5kIG11bHRpcGxlIG9wZXJhdGlvbnMg dmlhIEkyUlMgd2l0aG91dCBiZWluZwogICByZXF1aXJlZCB0byB3YWl0IGZvciBlYWNoIHRvIGNv bXBsZXRlIGJlZm9yZSBzZW5kaW5nIHRoZSBuZXh0LiBUaGUKICAgcHJvdG9jb2wgU0hBTEwgcHJv dmlkZSBzdWNoIG1lY2hhbmlzbXMgKGVnIHdpbmRvd2luZyBldGMpCmMpIEhpZ2gtVGhyb3VnaHB1 dDogICBBdCBhIG1pbmltdW0sIHRoZSBJMlJTIEFnZW50IGFuZCBhc3NvY2lhdGVkIHJvdXRlcgog ICBzaG91bGQgYmUgYWJsZSB0byBoYW5kbGUgYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mIG9wZXJh dGlvbnMgcGVyCiAgIHNlY29uZCBhYm92ZSB3aGF0IGJhc2ljIE5ldGNvbmYgb3IgYSBwcm9wcmV0 aWFyeSBDTEkgY2FuLgogICBYWFg6IEkgdGhpbmsgd2UgbmVlZCB0byB0aHJvdyBpbiBzb21lIG51 bWJlcnMgaGVyZSAuLgogICBbYWNoaWV2aW5nIDEwcyB0byAxMDBzIG9mIHRob3VzYW5kcyBvZiB0 YWJsZSB1cGRhdGVzL3NlY29uZCBzaG91bGQgYmUKICAgIHBvc3NpYmxlXS4KICAgcHJvdG9jb2wg cmVxdWlyZW1lbnQgaGVyZSB3b3VsZCBiZSBhbGxvd2luZyBmb3IgYmF0Y2hpbmcuCmQpIExvdyBM YXRlbmN5OiAgIEl0IE1VU1QgYmUgcG9zc2libGUgdG8gY29tcGxldGUgc2ltcGxlIEkyUlMgb3Bl cmF0aW9ucwogICB3aXRoaW4gYSBzdWItc2Vjb25kIHRpbWUtc2NhbGUuIEl0IFNIT1VMRCBiZSBw b3NzaWJsZSB0byB0byBwb3NzaWJsZSB0bwogICBwcm9jZXNzIGJ1bGsgZGF0YSBpbnRlbnNpdmUg b3BlcmF0aW9ucyAoZWcgYSB0YWJsZSBkdW1wIG9yIHVwZGF0ZSkgd2l0aAogICBsb3cgbGF0ZW5j eS4KZSkgRmlsdGVyYWJsZSBJbmZvcm1hdGlvbiBBY2Nlc3M6ICBUaGUgcHJvdG9jb2wgTVVTVCBh bGxvdyB0byBleHRyYWN0IAogICBpbmZvcm1hdGlvbiBpbiBhIHNjYWxhYmxlIGZhc2hpb24gdGhh dCBpcyBtb3JlIGVhc2lseSB1c2VkIGJ5IGNsaWVudHMsIHRoZQogICBhYmlsaXR5IHRvIHNwZWNp ZnkgZmlsdGVyaW5nIGNvbnN0cnVjdHMgaW4gdGhlIEkyUlMgcHJvdG9jb2wgcmVxdWVzdAogICBN VVNUIGJlIHBvc3NpYmxlLgoKNykgTXVsdGktSGVhZGVkIENvbnRyb2w6ICAgTXVsdGlwbGUgY2xp ZW50cyBtYXkgY29tbXVuaWNhdGUgdG8gdGhlCiAgIHNhbWUgSTJSUyBhZ2VudC4gSXQgaXMgbmVj ZXNzYXJ5IHRoYXQgdGhlIEkyUlMgYWdlbnQgY2FuIGhhbmRsZSAKICAgcmVxdWVzdHMgZnJvbSBt dWx0aXBsZSBjbGllbnRzIHRvIHRoZSBzYW1lIG9iamVjdCB3aXRoaW4gY29uc3RyYWludHMgb2Yg CiAgIHRoZSBjbGllbnQgYWNjZXNzIGF1dGhvcml6YXRpb24uCgo4KSBSZWxpYWJpbGl0eQogIFRo ZSBJMlJTIHByb3RvY29sIHdpbGwgYmUgdXNlZCB0byB0cmFuc3BvcnQgaW5mb3JtYXRpb24gdGhh dAogIHJlcXVpcmVzIHZhcnlpbmcgbGV2ZWxzIG9mIHJlbGlhYmlsaXR5LiAgQnkgc3RyaWN0IG9y IHJvYnVzdAogIHJlbGlhYmlsaXR5IGluIHRoaXMgcmVxdWlyZW1lbnQgd2UgbWVhbiwgbm8gbG9z c2VzLCBubwogIGNvcnJ1cHRpb24sIG5vIHJlLW9yZGVyaW5nIG9mIGluZm9ybWF0aW9uIGJlaW5n IHRyYW5zcG9ydGVkIGFuZAogIGRlbGl2ZXJ5IGluIGEgdGltZWx5IGZhc2hpb24uCgogICAgYSkg U29tZSBpbmZvcm1hdGlvbiBvciBwYXlsb2Fkcywgc3VjaCBhcyBzdWJzY3JpYmVkLXRvIGV2ZW50 cwogICAgICAgbWF5IG5vdCByZXF1aXJlIHJvYnVzdCByZWxpYWJpbGl0eSAoY2FuIHRvbGVyYXRl IHNvbWUgZGVncmVlIG9mIGxvc3NlcykuCiAgICBjKSBQYXlsb2FkcyBzdWNoIGFzIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24gZnJvbSBjbGllbnRzCiAgICAgICB0byB0aGUgSTJSUyBhZ2VudCBv ciByZXNwb25zZXMgZnJvbSB0aGUgSTJSUyBhZ2VudAogICAgICAgYXJlIG1pc3Npb24gY3JpdGlj YWwgYW5kIG11c3QgYmUgZGVsaXZlcmVkIGluIGEgcm9idXN0CiAgICAgICByZWxpYWJsZSBmYXNo aW9uLiAgVGh1cywgZm9yIGluZm9ybWF0aW9uIG9mIHRoaXMgc29ydCwgSTJSUwogICAgICAgTVVT VCBlaXRoZXIgcHJvdmlkZSBidWlsdC1pbiBwcm90b2NvbCBtZWNoYW5pc21zIG9yIHVzZSBhCiAg ICAgICByZWxpYWJsZSB0cmFuc3BvcnQgcHJvdG9jb2wgZm9yIGFjaGlldmluZyByb2J1c3Qvc3Ry aWN0CiAgICAgICByZWxpYWJpbGl0eS4KCjkpIE1lc3NhZ2UgUHJpb3JpdHkKICAgVGhlIEkyUlMg cHJvdG9jb2wgTVVTVCBwcm92aWRlIGEgbWVhbnMgdG8gZXhwcmVzcyB0aGUgcHJvdG9jb2wKICAg bWVzc2FnZSBwcmlvcml0aWVzLiBBcyB2YXJpb3VzIHR5cGVzIG9mIG1lc3NhZ2VzIGFyZSBleHBl Y3RlZCwKICAgdGhlaXIgbGV2ZWwgb2YgaW1wb3J0YW5jZSB3aWxsIGJlIGRpZmZlcmVudCBkZXBl bmRpbmcgb24gY29uZ2VzdGlvbi4KCgoxMCkgUHJvdGVjdGlvbiBhZ2FpbnN0IG5vZGUgb3Zlcmxv YWQgCiAgIGJhc2VkIG9uIENQVSBvdmVybG9hZCBvciBxdWV1ZSBvdmVyZmxvdyB0byBlaXRoZXIg YW4gYWdlbnQgcmVzb3VyY2UKICAgb3IgY2xpZW50KHMpLgogICBYWFg6IFRoaXMgbWF5IGVuZCB1 cCBiZWluZyBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS8KICAgQWdlbnRzL2NsaWVudHMgdXRpbGl6 aW5nIHRoZSBJMlJTIHByb3RvY29sIGNhbiBiZSBzdWJqZWN0ZWQKICAgQ1BVIG92ZXJsb2FkIG9y IHF1ZXVlIG92ZXJmbG93LiBUaGUgSTJSUyBhZ2VudCBNVVNUIGJlIHJvYnVzdAogICB1bmRlciBz dWNoIGNvbmRpdGlvbnMuCgoxMSkgVHJhbnNhY3Rpb25zIGNhcGFiaWxpdHkgKHNlY3Rpb24gNy45 IG9mIGFyY2hpdGVjdHVyZSBkb2MpClRoZSBwcm90b2NvbCBtdXN0IGJlIGFibGUgdG8gZXhwcmVz cyBlcnJvciBoYW5kbGluZyBmb3IgYmF0Y2hlZApvcGVyYXRpb25zLiBUaGVzZSBhcmU6Ci0gUGVy Zm9ybSBhbGwgb3Igbm9uZQotIFBlcmZvcm0gdW50aWwgZXJyb3IKLSBQZXJmb3JtIGFsbCBzdG9y aW5nIGVycm9ycwoKMTIpIFRyYW5zcG9ydCBpbmRlcGVuZGVuY2UKTm90IHN1cmUgaG93IHdlbGwg dGhpcyBpcyBhIGZpdC4gSXQgbWF5IGNvbXBsaWNhdGUgdGhpbmdzLgpJZiB3ZSB3ZXJlIHRvIHNl cGFyYXRlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIEkyUlMgcHJvdG9jb2wgZnJvbSB0aGUgdW5kZXJs eWluZwp0cmFuc3BvcnQgcHJvdG9jb2wgdGhlbiB3ZSBjb3VsZCBhbGxvdyBmb3IgbW9yZSBmbGV4 aWJpbGl0eSBvZiBkaWZmZXJlbnQgCmNoYXJhY3RlcmlzdGljcy4KCg== --001a113383e8861d0104f8941d6f-- From nobody Sun May 4 09:29:54 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 DBCA81A0177 for ; Sun, 4 May 2014 09:29:49 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 cnRgjDaxT7XO for ; Sun, 4 May 2014 09:29:46 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id C1CE11A01B1 for ; Sun, 4 May 2014 09:29:46 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so570877vcb.27 for ; Sun, 04 May 2014 09:29:43 -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:from:date:message-id:subject:to:cc :content-type; bh=UBysB4OwHAcxi6Hr0BWSxX2vzV4uYlOQt4Q+whmbKJI=; b=a7QCGjbGqSB0Pd0bwfOKXQhtJfjC5K6aIa70wPZEC2/0syD1nuUu1Xu6MqPdIDXxs7 yfmJwB66N30D1E74mf7YmYhj85dt76bNbxpROO1PymUPj3Uk8nz0FBd7WUlzMxr1Yz1i rtUx1eWaX0bS3WLw5xZBg8qNr+uUcd9GbLvHYQ5Wc70iML2cLHeXGBnigLNlgfL9YDay /CcNTpWDWHa37iYnglfboxLSSlAGMZEuUk8n2hQay/dkqwjqWa9Pu10/S5Uj274CgU9e SF2ls4HGy1ynod7+Vf5Pcxbfq5iyxnC+MZsxJCzr9Su1wgkokYHY3bKa52kda4o2jhnd TsIA== X-Gm-Message-State: ALoCoQl0boJK9jGRMKn5iZ6kNkKQ4R8HOSRUwFSiLM5Kl7EL17cA2GGY/m9QKSjBFiVBl2fBbGrZ X-Received: by 10.58.150.68 with SMTP id ug4mr579459veb.50.1399220983470; Sun, 04 May 2014 09:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Sun, 4 May 2014 09:29:23 -0700 (PDT) From: Jamal Hadi Salim Date: Sun, 4 May 2014 12:29:23 -0400 Message-ID: To: "i2rs@ietf.org" , Jeffrey Haas , Edward Crabbe Content-Type: multipart/mixed; boundary=047d7b672242aec27b04f89585d1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/8YvxJO1iJaJoBpX3oK0QEkCP5MA Cc: Dean Bogdanovic , Andy Bierman Subject: [i2rs] Model requirements 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: Sun, 04 May 2014 16:29:50 -0000 --047d7b672242aec27b04f89585d1 Content-Type: text/plain; charset=UTF-8 Ok, here's the model version. I extracted some of this information from the architecture mostly. I didnt put as much energy on this as i did on the protocol version. But it is a starting point. cheers, jamal --047d7b672242aec27b04f89585d1 Content-Type: text/plain; charset=US-ASCII; name="model-reqs.txt" Content-Disposition: attachment; filename="model-reqs.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_husk0o9o0 CjEpIFRoZSBkYXRhIG1vZGVsIE1VU1QgYmUgYWJsZSB0byBkZXNjcmliZSB0aGUgdGFyZ2V0IG9i amVjdHMgCmEpIHdpdGggZm9ybWFsIGNvbnN0cmFpbnRzIGZvciB2YWxpZGF0aW9uIHB1cnBvc2UK YikgYmFzaWMgcmVhZC13cml0ZSBhY2Nlc3MgcGVybWlzc2lvbnMKYykgY2xhc3Mgb2JqZWN0IGNh cGFiaWxpdGllcyBhbmQgY2FwYWNpdGllcwpkKSBldmVudCBvYmplY3QgZGVmaW5pdGlvbnMgd2l0 aCBwdWJsaXNoLXN1YnNjcmliZSBzZW1hbnRpY3MKCjIpIFRoZSBtb2RlbCBNVVNUIGJlIG9iamVj dCBvcmllbnRlZC4KVGhpcyBhbGxvd3MgaXQgdG8gZXh0ZW5zaWJsZSBpbiB0aGUgZm9ybSBvZiB0 ZW1wbGF0aW5nIGFuZApzdWItY2xhc3NpbmcuCgozKSBUaGUgZGF0YSBtb2RlbCBNVVNUIGJlIGFi bGUgdG8gZXhwcmVzcyBzZW1hbnRpY3Mgb2YgaW5zdGFuY2VzLgpUaGlzIGlzIGEgc2lkZSBwcm9k dWN0IG9mIGJlaW5nIG9iamVjdCBvcmllbnRlZC4KCjQpIFRoZSBkYXRhIG1vZGVsIE1VU1QgYmUg YWJsZSB0byBtYW5hZ2UgdmFyaWF0aW9uCmEpIFByZXNlbmNlIGNvbXBsaWFuY2Ugb2YgZGVmaW5l ZCBvYmplY3RzIHNob3VsZCBiZSBwb3NzaWJsZSB0byBleHByZXNzLgooZWcgb3B0aW9uYWwgdnMg bWFuZGF0b3J5KQpiKSBEZWZhdWx0IHZhbHVlcyBNVVNUIGJlIHBvc3NpYmxlIHRvIHNwZWNpZnkK YykgSGllcmFyY2hpZXMgTVVTVCBiZSBwb3NzaWJsZSB0byBzcGVjaWZ5Cgo1KSBEYXRhIE1vZGVs IE1VU1QgYmUgYWJsZSB0byBoYW5kbGUgT2JqZWN0IExpZmUgY3ljbGUgbWFuYWdlbWVudC4KVHlw aWNhbGx5IHRoaXMgbWVhbnM6CmEpIFZlcnNpb25pbmcgc3VwcG9ydApiKSBiZWluZyBhYmxlIHRv IGhhbmRsZSBib3RoIGJhY2t3YXJkIGFuZCBmb3J3YXJkIGNvbXBhdGliaWxpdHkKCgo= --047d7b672242aec27b04f89585d1-- From nobody Mon May 5 11:47:46 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 897761A0424 for ; Mon, 5 May 2014 11:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 nHb7SepNBzOf for ; Mon, 5 May 2014 11:47:35 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE931A0443 for ; Mon, 5 May 2014 11:47:33 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so6963461wes.2 for ; Mon, 05 May 2014 11:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=fCGUof+hinAKDM3iv+lMx0bRWMh14O1UZCxHL49LxQ0=; b=ercDe//8InKyhMIRJOk+3xiJMKv/vlI+IXLmbCYOxXXbciW/LxLAijUxzkoaJoTGmp 4Uh6bb97LvOGMTwNns9XVLwQ0P+skL6y0tPnftQh/40BlkfgkKFanYUnP5FYnYLZf7Px nz6TENsgcsUacY4t4tEiniUPyf0NyOUGjTsfIAZ116zJgwqdcB+ts1EhK4m41zBoykKg C4wiFG3wGf1AOvkiXOR6UopLuMpHlh98rwKYLdOrTj+1UJJNCcqqjPSSrVVO5AZkVfuc kShm4XNX9m/aKgPUxaKJAB3RxWPf0gvfwq5jHZvVy3Wsiu1YVmphvGdD95EBnvwLc9xm SmWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=fCGUof+hinAKDM3iv+lMx0bRWMh14O1UZCxHL49LxQ0=; b=DdYb7ITvDf+qvMt4uIJTk7mzkexXz7OAdi6i1s8o5Rk9iKngT29exj5PPdhorXShIm fgIr9jN16kvvA8nP0eboyPLjlGtxhHR5RFJdtL6qbH4HV133TMmCHp8+1mlC2UzzAx+V ohygn3fbApwR2rnbuY25O9JD4qYTn5kxWr99T2585Ltx3w+A+Gj71K0abZgeIahNvoOo YuSsbwXirEqKOpYPdoAqVLEy9pbNz2i3mh9pGbRzoMVfslFGNi9aW+ZW7AaOtex0fcj5 mOdo/EUYpxk9JvHB2vIWUw6dbTlO19waOsmPsNrjQNJOiEHrsMEU7EQCGqBwxMfI20xp /FYw== X-Gm-Message-State: ALoCoQlJk1VzgqfT0b9OXh/NVgg6XuMT7u5wtyBm/Xm8llVfkySEsVHMl1Y73AWnEo+961TC5Cw9 X-Received: by 10.180.73.140 with SMTP id l12mr17382146wiv.3.1399315649593; Mon, 05 May 2014 11:47:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.222.131 with HTTP; Mon, 5 May 2014 11:46:49 -0700 (PDT) From: Edward Crabbe Date: Mon, 5 May 2014 11:46:49 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7e2c39349b04f8ab90dd Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/WH5n29ytukmzogsgKepelOuAZqY Subject: [i2rs] I2RS protocol & model selection 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, 05 May 2014 18:47:40 -0000 --f46d043c7e2c39349b04f8ab90dd Content-Type: text/plain; charset=ISO-8859-1 I2RSers; We've used the time allocated for review of existing standards-based mechanisms. We are now heading into the week used for selection of a protocol & modeling language for I2RS. A few interesting points have been raised on either side, but no real deal breakers in either direction. We hope that the remainder of the week can be spent in substantive conversation on specific deficiencies in protocols and modeling languages. A number of people have already expressed an opinion one way or another. It should be implied (but is explicitly stated here) that folks showing support for a particular protocol do so with reasonable knowledge of / confidence in that protocol, especially relative to the core set of I2RS requirements. Both Jeff and I, from our own reading as well as conversations with protocol experts, continue to believe that both netconf/restconf and ForCES protocols, as well as ForCES and YANG, are technically capable of providing the underlying functionality I2RS requires. Given this, utility, familiarity and yes, expedience, will very probably play a role in the selection process ( as they have clearly already have.) Looking forward to another interesting week of conversation; we're very close now folks. ^_^ cheers, -ed & Jeff --f46d043c7e2c39349b04f8ab90dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I2RSers;
=
We've used the time allocate= d for review of existing standards-based mechanisms.  We are now heading = into the week used for selection of a protocol & modeling language for&= nbsp;I2R= S. = A few interesting points have been raised on either side, but no real deal= breakers in either direction.  We hope that the remainder of the week= can be spent in substantive conversation on specific deficiencies in proto= cols and modeling languages.  

A number of people have already = expressed an opinion one way or another.  It should be implied (but is= explicitly stated here)  that folks showing support for a particular = protocol do so with reasonable knowledge of / confidence in that protocol, = especially relative to the core set of I2RS requirements.  

Both Jeff and I, from our own re= ading as well as conversations with protocol experts, continue to believe t= hat both netconf/restconf and ForCES protocols, as well as ForCES and YANG,= are technically capable of providing the underlying functionality I2RS req= uires.  Given this, utility, familiarity and yes, expedience, will ver= y probably play a role in the selection process ( as they have clearly alre= ady have.)  

Looking forward to another inter= esting week of conversation;  we’re very close now folks.  = ^_^


cheers,

   -ed & Jeff
--f46d043c7e2c39349b04f8ab90dd-- From nobody Tue May 6 02: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 1402A1A029B for ; Tue, 6 May 2014 02:57:41 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 H_iezO8jVdhb for ; Tue, 6 May 2014 02:57:39 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE4A1A0784 for ; Tue, 6 May 2014 02:57:39 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jw12so3363112veb.19 for ; Tue, 06 May 2014 02:57:35 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sKAkOSvy4lIaJ56cv88Z6rOo+giA+HqJSewCHr9Oqz8=; b=YlPLobulksk4jg8kX7e62GFl3CsSQnOdhN29HgelKTtmsiJ4HqPftk/qFu6qxfkbLG WmprYOmtUNpT2fmhopuDE41rLqJRBVtxp0GaqzBemGr1qD9X+ZrjTS48GGW8iCN/quIb 3ei3eslX3LvTmpJ2BoRr96CsIOGxvp70QAxkxoc7O38dkIFlXRXmtKF9uBi13++Z3D6E yoMRHilLFpBVI3wnfY8lotD47B/D+TCfwfbcQNOiw95x9zpJF6c+HmVi7VIiuW6WrJN0 7twc8tHSvJ3p1yquYiQ/LL1CyYGSBbu0zAlDxuI1qNhF6qtNMjSX66+1q/LpYh44qKng 2L9g== X-Gm-Message-State: ALoCoQmOM+/yviW1EHc3X/BFx1fndSMOnEXHZs09jh2rGoPI9IBCWPNX3Kc8AbdnvOwCZjyRLmOn X-Received: by 10.52.34.4 with SMTP id v4mr197875vdi.42.1399370255670; Tue, 06 May 2014 02:57:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Tue, 6 May 2014 02:57:15 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 6 May 2014 05:57:15 -0400 Message-ID: To: Edward Crabbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ptFSvHpXF-HvV5fvQUIJmDiSYVU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] I2RS protocol & model selection 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: Tue, 06 May 2014 09:57:41 -0000 I sent some "requirements" on the list. Would those two lists be reasonable to compare against for gaps? cheers, jamal On Mon, May 5, 2014 at 2:46 PM, Edward Crabbe wrote: > I2RSers; > > We've used the time allocated for review of existing standards-based > mechanisms. We are now heading into the week used for selection of a > protocol & modeling language for I2RS. A few interesting points have bee= n > raised on either side, but no real deal breakers in either direction. We > hope that the remainder of the week can be spent in substantive conversat= ion > on specific deficiencies in protocols and modeling languages. > > A number of people have already expressed an opinion one way or another. = It > should be implied (but is explicitly stated here) that folks showing > support for a particular protocol do so with reasonable knowledge of / > confidence in that protocol, especially relative to the core set of I2RS > requirements. > > Both Jeff and I, from our own reading as well as conversations with proto= col > experts, continue to believe that both netconf/restconf and ForCES > protocols, as well as ForCES and YANG, are technically capable of providi= ng > the underlying functionality I2RS requires. Given this, utility, > familiarity and yes, expedience, will very probably play a role in the > selection process ( as they have clearly already have.) > > Looking forward to another interesting week of conversation; we=E2=80=99= re very > close now folks. ^_^ > > > cheers, > > -ed & Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue May 6 16:05:22 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 53AF81A02A3 for ; Tue, 6 May 2014 16:05:21 -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 OPZGlOL6P8GR for ; Tue, 6 May 2014 16:05:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) by ietfa.amsl.com (Postfix) with ESMTP id AC3421A02FB for ; Tue, 6 May 2014 16:05:18 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB204.namprd05.prod.outlook.com (10.255.206.17) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 6 May 2014 23:05:13 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) with mapi id 15.00.0939.000; Tue, 6 May 2014 23:05:01 +0000 From: Dean Bogdanovic To: Alia Atlas , Thomas Nadeau , "wardd@cisco.com" Thread-Topic: draft-ietf-i2rs-problem-statement-01 Thread-Index: AQHPaX+bhQIOsizXJUKTwqU0W/slNw== Date: Tue, 6 May 2014 23:05:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(199002)(189002)(46102001)(16236675002)(99396002)(92726001)(74502001)(86362001)(31966008)(93916002)(74662001)(83322001)(81342001)(77982001)(99286001)(81542001)(76482001)(57306001)(79102001)(62966002)(92566001)(101416001)(82746002)(87936001)(551934002)(4396001)(87286001)(20776003)(1941001)(36756003)(2656002)(77156001)(50986999)(50226001)(80022001)(66066001)(85852003)(88136002)(89996001)(83072002)(83716003)(33656001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB204; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:FE26FE99.A4E667C7.B2F72D4B.5AEA6140.2037E; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_C35B762AC9C843C9834B691A2A59827Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/aFuvslHLuiP2tM3FY8GlbOyh0gw Cc: "" Subject: [i2rs] draft-ietf-i2rs-problem-statement-01 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: Tue, 06 May 2014 23:05:21 -0000 --_000_C35B762AC9C843C9834B691A2A59827Fjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alia, Tom, Dave, Have few comments on chapter 5 in the draft The following requirement is fine, but some consideration have to be put in= . Example, creating a filter construct or routing table has to be finished,= before the next operation like add term to the filter or add route to the = routing table is possible. Multiple Simultaneous Asynchronous Operations: A single application should be able to send multiple operations via I2RS without being required to wait for each to complete before sending the next. So would suggest changing from multiple operations to multiple independent = operations High-throughput is always nice to have, but the quantification is a bit wis= hy washy. High-Throughput: At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second above what basic Netconf or a propretiary CLI can. What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over N= ETCONF. Question: what is RPC doing? Is it simple operational get or large = config push? Or some other complex RPC? There is also difference in creating logical interfaces and adding term to = a filter or adding route to a routing table. Creating interface is most tax= ing one and adding term is fastest create operation. IMO, NETCONF has no pr= oblem with throughput, it is the instrumentation and that is something we s= hould focus in I2RS. What constructs do we want to control via I2RS and depending on that, make = sure that the protocol can sustain max throughput. In the next chapter you are mentioning Responsive: It should be possible to complete simple operations within a sub-second time-scale. Here you are stating simple operation, so why not define few simple operati= ons and put some quantification with it (in the below examples I'm pulling = the numbers out of my hat) example: read routes - single prefix per transaction < 0.5sec - multiple prefixes per transaction < time on the wire + 0.5sec add route - single prefix per transaction < 0.5 sec - multiple prefixes per transaction 1000 routes/sec get filter info - single filter per transaction < 0.5sec - multiple filters and terms per transaction < time on the wire + 0.5sec create filter - single filter per transaction < 0.5 sec - multiple filters per transaction 2000/sec add term to filter - single term per transaction < 0.5sec - multiple terms per transaction 3000/sec get interface info - single interface per transaction < 0.5 sec - multiple interfaces per transaction < time on the wire + 0.5 sec create interface - single interface per transaction < 0.5 sec - multiple interfaces per transaction 100/sec I'm thinking how can you do assurance for i2rs. It looks as it is covered i= n following paragraph Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs in an operation requesting data or requesting an asynchronous notification is very valuable. but it is not spelled out. Dean --_000_C35B762AC9C843C9834B691A2A59827Fjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Alia, Tom, Dave,

Have few comments on chapter 5 in the draft

The following requirement is fine, but some consideration have to be p= ut in. Example, creating a filter construct or routing table has to be fini= shed, before the next operation like add term to the filter or add route to= the routing table is possible. 
Multiple Simultaneous Asynchronous Operations:   A s=
ingle application
      should be able to send multiple operations via I2RS without being
      required to wait for each to complete before sending the next.
So would suggest changing from multiple operations to multiple indepen= dent operations

High-throughput is always nice to have, but the quantification is a bi= t wishy washy. 
 High-Throughput:   At a minimum, the I2RS Agent and=
 associated router
      should be able to handle a considerable number of operations per
      second above what basic Netconf or a propretiary CLI can.
What does mean basic NETCONF? Today I can do couple hundred RPCs/sec o= ver NETCONF. Question: what is RPC doing? Is it simple operational get or l= arge config push? Or some other complex RPC?
There is also difference in creating logical interfaces and adding ter= m to a filter or adding route to a routing table. Creating interface is mos= t taxing one and adding term is fastest create operation. IMO, NETCONF has = no problem with throughput, it is the instrumentation and that is something we should focus in I2RS.
What constructs do we want to control via I2RS and depending on that, = make sure that the protocol can sustain max throughput.

In the next chapter you are mentioning 
Responsive:   It should be possible to complete simp=
le operations
      within a sub-second time-scale.

Here you are stating simple operation, so why not define few simple op= erations and put some quantification with it (in the below examples I'm pul= ling the numbers out of my hat)

example:

read routes <= /span>- single prefix per transaction < 0.5sec
- mult= iple prefixes per transaction < time on the wire + 0.5sec
add route - single prefix per transaction < 0.5 sec
- = ;multiple prefixes per transaction 1000 routes/sec

get filter info - single filter per transaction < 0.5sec
- m= ultiple filters and terms per transaction  < time on the wire = + 0.5sec
create filter= - single filter per transaction < 0.5 sec
- m= ultiple filters per transaction  2000/sec
add term to filter - single term per transaction < 0.5sec
- m= ultiple terms per transaction  3000/sec

get interface info  - single interface per transaction < 0.5 sec
- m= ultiple interfaces per transaction < time on the wire + 0.5 sec
create interface - single interface per transaction < 0.5 sec
- m= ultiple interfaces per transaction 100/sec

I'm thinking how can you do assurance for i2rs. It looks as it is cove= red in following paragraph

  Scalable, Filterable Information Access:  To extra=
ct information in a
      scalable fashion that is more easily used by applications, the
      ability to specify filtering constructs in an operation requesting
      data or requesting an asynchronous notification is very=
 valuable.

but it is not spelled out. 

Dean



--_000_C35B762AC9C843C9834B691A2A59827Fjunipernet_-- From nobody Tue May 6 16:24: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 A43F71A0643 for ; Tue, 6 May 2014 16:24:30 -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 XkqTLGaRKD3A for ; Tue, 6 May 2014 16:24:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE461A0662 for ; Tue, 6 May 2014 16:24:25 -0700 (PDT) Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BLUPR05MB418.namprd05.prod.outlook.com (10.141.27.16) with Microsoft SMTP Server (TLS) id 15.0.934.12; Tue, 6 May 2014 23:24:20 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.205]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.205]) with mapi id 15.00.0929.001; Tue, 6 May 2014 23:24:20 +0000 From: Alia Atlas To: Dean Bogdanovic , Thomas Nadeau , "wardd@cisco.com" Thread-Topic: draft-ietf-i2rs-problem-statement-01 Thread-Index: AQHPaX+bhQIOsizXJUKTwqU0W/slN5s0MZ21 Date: Tue, 6 May 2014 23:24:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(479174003)(377454003)(189002)(199002)(16236675002)(85852003)(83072002)(76482001)(21056001)(54356999)(99396002)(50986999)(551934002)(101416001)(76176999)(99286001)(43066003)(77982001)(53806999)(33646001)(95246002)(86362001)(92726001)(87936001)(2656002)(80022001)(20776003)(74662001)(74502001)(64706001)(46102001)(81342001)(19580405001)(83322001)(19580395003)(63666003)(79102001)(4396001)(81542001)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB418; H:BL2PR05MB193.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=akatlas@juniper.net; Content-Type: multipart/alternative; boundary="_000_e763obkw5tyn37r9x8cpr3fq1399418657118emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pLefa9xOi6bgDz_9TTmXZ_cuieE Cc: "" Subject: Re: [i2rs] draft-ietf-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Alia Atlas List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 23:24:30 -0000 --_000_e763obkw5tyn37r9x8cpr3fq1399418657118emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dean, Thanks for the thorough review! I'm traveling so will take until Friday fo= r a full response. Alia -------- Original message -------- From: Dean Bogdanovic Date: 05/06/2014 6:05 PM (GMT-06:00) To: Alia Atlas ,Thomas Nadeau ,wardd@cisco.com Cc: "" Subject: draft-ietf-i2rs-problem-statement-01 Alia, Tom, Dave, Have few comments on chapter 5 in the draft The following requirement is fine, but some consideration have to be put in= . Example, creating a filter construct or routing table has to be finished,= before the next operation like add term to the filter or add route to the = routing table is possible. Multiple Simultaneous Asynchronous Operations: A single application should be able to send multiple operations via I2RS without being required to wait for each to complete before sending the next. So would suggest changing from multiple operations to multiple independent = operations High-throughput is always nice to have, but the quantification is a bit wis= hy washy. High-Throughput: At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second above what basic Netconf or a propretiary CLI can. What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over N= ETCONF. Question: what is RPC doing? Is it simple operational get or large = config push? Or some other complex RPC? There is also difference in creating logical interfaces and adding term to = a filter or adding route to a routing table. Creating interface is most tax= ing one and adding term is fastest create operation. IMO, NETCONF has no pr= oblem with throughput, it is the instrumentation and that is something we s= hould focus in I2RS. What constructs do we want to control via I2RS and depending on that, make = sure that the protocol can sustain max throughput. In the next chapter you are mentioning Responsive: It should be possible to complete simple operations within a sub-second time-scale. Here you are stating simple operation, so why not define few simple operati= ons and put some quantification with it (in the below examples I'm pulling = the numbers out of my hat) example: read routes - single prefix per transaction < 0.5sec - multiple prefixes per transaction < time on the wire + 0.5sec add route - single prefix per transaction < 0.5 sec - multiple prefixes per transaction 1000 routes/sec get filter info - single filter per transaction < 0.5sec - multiple filters and terms per transaction < time on the wire + 0.5sec create filter - single filter per transaction < 0.5 sec - multiple filters per transaction 2000/sec add term to filter - single term per transaction < 0.5sec - multiple terms per transaction 3000/sec get interface info - single interface per transaction < 0.5 sec - multiple interfaces per transaction < time on the wire + 0.5 sec create interface - single interface per transaction < 0.5 sec - multiple interfaces per transaction 100/sec I'm thinking how can you do assurance for i2rs. It looks as it is covered i= n following paragraph Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs in an operation requesting data or requesting an asynchronous notification is very valuable. but it is not spelled out. Dean --_000_e763obkw5tyn37r9x8cpr3fq1399418657118emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dean,

Thanks for the thorough review!  I'm traveling so will take until= Friday for a full response.

Alia



-------- Original message --------
From: Dean Bogdanovic <deanb@juniper.net>
Date: 05/06/2014 6:05 PM (GMT-06:00)
To: Alia Atlas <akatlas@juniper.net>,Thomas Nadeau <tnadeau@lucidv= ision.com>,wardd@cisco.com
Cc: "<i2rs@ietf.org>" <i2rs@ietf.org>
Subject: draft-ietf-i2rs-problem-statement-01


Alia, Tom, Dave,

Have few comments on chapter 5 in the draft

The following requirement is fine, but some consideration have to be p= ut in. Example, creating a filter construct or routing table has to be fini= shed, before the next operation like add term to the filter or add route to= the routing table is possible. 
Multiple Simultaneous Asynchronous Operations:   A s=
ingle application
      should be able to send multiple operations via I2RS without being
      required to wait for each to complete before sending the next.
So would suggest changing from multiple operations to multiple indepen= dent operations

High-throughput is always nice to have, but the quantification is a bi= t wishy washy. 
 High-Throughput:   At a minimum, the I2RS Agent and=
 associated router
      should be able to handle a considerable number of operations per
      second above what basic Netconf or a propretiary CLI can.
What does mean basic NETCONF? Today I can do couple hundred RPCs/sec o= ver NETCONF. Question: what is RPC doing? Is it simple operational get or l= arge config push? Or some other complex RPC?
There is also difference in creating logical interfaces and adding ter= m to a filter or adding route to a routing table. Creating interface is mos= t taxing one and adding term is fastest create operation. IMO, NETCONF has = no problem with throughput, it is the instrumentation and that is something we should focus in I2RS.
What constructs do we want to control via I2RS and depending on that, = make sure that the protocol can sustain max throughput.

In the next chapter you are mentioning 
Responsive:   It should be possible to complete simp=
le operations
      within a sub-second time-scale.

Here you are stating simple operation, so why not define few simple op= erations and put some quantification with it (in the below examples I'm pul= ling the numbers out of my hat)

example:

read routes <= /span>- single prefix per transaction < 0.5sec
- mult= iple prefixes per transaction < time on the wire + 0.5sec
add route - single prefix per transaction < 0.5 sec
- = ;multiple prefixes per transaction 1000 routes/sec

get filter info - single filter per transaction < 0.5sec
- mult= iple filters and terms per transaction  < time on the wire = 3; 0.5sec
create filter= - single filter per transaction < 0.5 sec
- mult= iple filters per transaction  2000/sec
add term to filter - single term per transaction < 0.5sec
- mult= iple terms per transaction  3000/sec

get interface info  - single interface per transaction < 0.5 sec
- mult= iple interfaces per transaction < time on the wire + 0.5 sec
create interface - single interface per transaction < 0.5 sec
- mult= iple interfaces per transaction 100/sec

I'm thinking how can you do assurance for i2rs. It looks as it is cove= red in following paragraph

  Scalable, Filterable Information Access:  To extra=
ct information in a
      scalable fashion that is more easily used by applications, the
      ability to specify filtering constructs in an operation requesting
      data or requesting an asynchronous notification is very=
 valuable.

but it is not spelled out. 

Dean



--_000_e763obkw5tyn37r9x8cpr3fq1399418657118emailandroidcom_-- From nobody Wed May 7 03:57: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 2C74F1A06D7 for ; Wed, 7 May 2014 03:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 bPzPQqWwEq5C for ; Wed, 7 May 2014 03:57:48 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED2D1A06D6 for ; Wed, 7 May 2014 03:57:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=98.174.216.153; From: "Susan Hares" To: "'Andy Bierman'" , "'Thomas Nadeau'" References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> In-Reply-To: Date: Wed, 7 May 2014 06:56:41 -0400 Message-ID: <003101cf69e3$07e84930$17b8db90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CF69C1.80D808C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIiInceux1/icGCg1CUZyO5f86QKgIetHVcA4TL51EBHeXw7wDo5H7bASQ7P90CDXSWDALMjbjgAtApag0BU9wuzAHEWPffAc95QUABRK3/3AIlYtkJAuWItq4CPGlTtZmgFxuQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dNLa6nuMFvriMjLVD5PQMh7RTg0 Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Juergen Schoenwaelder' , "'t. petch'" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 07 May 2014 10:57:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0032_01CF69C1.80D808C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau: I imagine I2RS will be completely separate from NETCONF and it should have its own datastore -- so "i2rs-config" is appropriate because I2RS is the only protocol using that datastore. The combined "operational state" is not editable. Yes, that makes sense. Then if at some point in time you want to save the running config (i2rs), the system has to explicitly copy it over. But until then, its separate. The only question is: what is the complete running config represented as? And what if Netconf wants to modify the running config (i.e.: and the RIB in particular)? That copy-to-local-config feature would be extra, outside the scope of the i2rs-config. ----- Why only is the copy-to-local-config feature out of scope for the I2rs-config? How can the work be interoperable if this feature (required or optional) does not work the same in different vendor's boxes? If the implementations are different, this is great (differentiated products = good); but IMHO this feature actions has to be interoperable. that is give the same effective response in the different vendors. Can you explain further? Right. If we take that approach we need to have a way of the i2rs "protocol" to signal that the config needs to be saved "soon". That is, its not done in real time, but rather as a background process. Its probably. This can either be through a single keyword that is added under the i2rs-config section, or per element or even per-element, if we decide to be more granular. IMHO it is important to know when the write to local-config is done even if done in background. Are you indicating there is no write-config/ack-complete-write config interaction? You seem to be suggesting that the I2RS behavior of forgetting all injected state if the router happens to reboot is not that useful, and therefore it needs to be saved in the background (best-effort). I think it is up to all the I2RS clients to always be around to receive some sort of agent-reboot event, and re-install any required I2RS config. I can't imagine any use cases where the operator thinks "I only need to install this RIB data until that router accidentally reboots". If you re-install any required I2RS config, are you sure this is what the I2RS client wants? Sue ------=_NextPart_000_0032_01CF69C1.80D808C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom = Nadeau:

 

<snip>

I imagine I2RS will be completely separate from = NETCONF and it should have its own = datastore -- so "i2rs-config" is appropriate because I2RS is = the only protocol using that = datastore. The combined "operational state" is not editable.

 

Yes, that makes sense. Then if at some point in time = you want to save  the running = config (i2rs), the system has to explicitly copy it over. But until = then, its separate.  The only = question is: what is the complete running config represented as? And what if Netconf wants to modify the = running config (i.e.: and the RIB in particular)?

 

That copy-to-local-config feature would be extra, = outside the scope of the i2rs-config.

</snip>

-----

 

Why only = is the copy-to-local-config feature out of scope for the = I2rs-config?   How can the work be interoperable if this = feature (required or optional) does not work the same in different = vendor’s boxes?  If the implementations are different, this = is great (differentiated products =3D good); but IMHO this feature = actions has to be interoperable… that is give the same effective = response in the different vendors.  

 =

Can you = explain further?

 


<snip> =

 

Right. If we take that approach we need to have a way = of the i2rs "protocol" to signal that the = config 

needs to be = saved "soon".  That is, its not done in real time, but = rather as a background process. 

Its probably. This can either be through a single = keyword that is added under the i2rs-config section, = or

per element or even = per-element, if we decide to be more granular. 

</snip>

 

IMHO it is important to know when the write to local-config is done = even if done in background.   Are you indicating there is no = write-config/ack-complete-write config interaction? =

 

<snip> =

You seem to be = suggesting that the I2RS behavior of forgetting all injected = state

if the router = happens to reboot is not that useful, and therefore it needs to = be

saved in the background = (best-effort).

 

I = think it is up to all the I2RS clients to always be around to receive = some

sort of agent-reboot = event, and re-install any required I2RS = config.

I can't imagine = any use cases where the operator thinks "I only need = to

install this RIB data = until that router accidentally reboots".

</snip>

 

If you re-install any required I2RS config, are = you sure this is what the I2RS client wants?

 

Sue

 

------=_NextPart_000_0032_01CF69C1.80D808C0-- From nobody Wed May 7 03:59:00 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 11EAD1A06CB for ; Wed, 7 May 2014 03:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] 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 AjImotrcbfgf for ; Wed, 7 May 2014 03:58: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 0C2931A064E for ; Wed, 7 May 2014 03:58:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=98.174.216.153; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Andy Bierman'" References: <20140501152335.GB29842@pfrc> <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> In-Reply-To: <20140502154036.GD17078@pfrc> Date: Wed, 7 May 2014 06:58:47 -0400 Message-ID: <003e01cf69e3$52cef020$f86cd060$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgZg0Ew/Z4psCDWcD1MmdS5qBHcAIiInceAh60dVwDhMvnUQEd5fDvAOjkftsBJDs/3QINdJYMAsyNuOAC0ClqDQFT3C7MmnOEshA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vuSr3_XiJ6n4NAg8auEe1JxtQ30 Cc: i2rs@ietf.org, "'t.petch'" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 07 May 2014 10:58:58 -0000 Comment 2 And this: Jeff: Do you consider the question from Ken's original post below to be answered? "In contrast, although multiple I2RS clients may need to supply data into the same list (e.g. a prefix or filter list), this is not considered an error and must be correctly handled. The nuances so that writers do not normally collide should be handled in the information models." Do you mean data model? Can you provide an example for how this can be handled in an info/data model? - are lists expected to be sorted-by-system to prevent shadowing This a logical description and not a model description. ---------- Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, May 02, 2014 11:41 AM To: Andy Bierman Cc: Jeffrey Haas; i2rs@ietf.org; t.petch Subject: Re: [i2rs] edit-data substatement Re: Operational State On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote: > I picture the operational state as the mixing bowl for the 2 config > sources and data learned from protocols and system events. It seems > both NETCONF and I2RS would be able to pick the data is cares about > out of that. I think this is what I'd like to see personally. > This is a weakness in YANG that may get improved in YANG 1.1. > Since it is officially just for NETCONF, there are no mechanisms > (other than vendor extensions) to tag the data as specific to some > subset of protocols. As I mentioned elsewhere, I'm hoping we don't go down the path of "editable operational state", instead configuration semantics for our purposes. > > I think that we will, that is the set of YANG leafs etc that I2RS > > will want to edit and the sets of leafs that I2RS will want to get > > in a straightforward manne will not be the same (eg the latter will > > include read-only statistics and 'config true'). And yes, it could > > all be done with filters, which could be a nightmare. > > > > > Examples of read-only data that only I2RS would want to get would help. I believe that it would largely overlap config false state desired for normal module purposes in many cases. For example, interface statistics would likely be part of the standard interface module. Where things get interesting are specific augmentations that tie different information domains together - interface stats correlated against routing, for example. (For prefix X, traffic is seen - similar to IPFIX exports.) -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 7 04:27: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 0E9131A06EC for ; Wed, 7 May 2014 04:27:19 -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 SDDihD1bGpuv for ; Wed, 7 May 2014 04:27:18 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D98651A06ED for ; Wed, 7 May 2014 04:27:17 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lc6so1051374vcb.30 for ; Wed, 07 May 2014 04:27:13 -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:content-type; bh=9z1rSyc0+zbWdhAJ6G8HXbAvGeBlB5fxvwz8SHeBG6I=; b=U6WupBn+FJP3nZzOHlj8hC6cSYV+Fu09XtYpGZupHYcg+AHANiEBJH8PhUHJyHavxX fIL2b0kT6yAUPPORtbMPtc1W3kEdeemmI/vm4VqjCZ1nXD1ujFmsvyJEa648lU1IkE4a ctOcQzAR6dmexMaSq7hJBJXgmq02ToxSSpDjjCRHaPj4Lax/Th3z+FDUi1Lod9CZBL21 Bd6nTXMQPbjeHMIYYriPcnPVTugJTrD2Uj1sYUb0gfJqBacn0b/Ls7Pk2sEIFk2AM2HU trANgv93lagPkIQtTPS75ytZvxE+wAWXUWLzfYylbD8BmmcgZpGPjwFDfQ9C5Q4fFchF fO3w== MIME-Version: 1.0 X-Received: by 10.58.23.6 with SMTP id i6mr37886059vef.12.1399462033611; Wed, 07 May 2014 04:27:13 -0700 (PDT) Received: by 10.221.19.129 with HTTP; Wed, 7 May 2014 04:27:13 -0700 (PDT) Date: Wed, 7 May 2014 08:27:13 -0300 Message-ID: From: FABIO ZACCANTTE To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=047d7b339db163e1de04f8cda5a9 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/grSvl5vqew1-kFXPbAAeteAXl_Y Subject: [i2rs] Interface to The Internet Routing System (IRS) 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, 07 May 2014 11:27:19 -0000 --047d7b339db163e1de04f8cda5a9 Content-Type: text/plain; charset=UTF-8 I am starting in the I2RS and my question is where stay I2RS, in the router or controller. Someone has picture that represents the controller, the router, the network and I2RS Regards, Fabio. --047d7b339db163e1de04f8cda5a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am starting in the I2RS and my question is whe= re stay I2RS, in the router or controller.

Someone= has picture that represents the controller, the router, the network =C2=A0= and I2RS

Regards,
Fabio.
--047d7b339db163e1de04f8cda5a9-- From nobody Wed May 7 06:13:38 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 6A4981A02C5 for ; Wed, 7 May 2014 06:13:34 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 CKRHBWKDk3ID for ; Wed, 7 May 2014 06:13:32 -0700 (PDT) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by ietfa.amsl.com (Postfix) with ESMTP id 889921A02AF for ; Wed, 7 May 2014 06:13:32 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so1206268veb.24 for ; Wed, 07 May 2014 06:13:28 -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:from:date :message-id:subject:to:cc:content-type; bh=QuF2+Cv4wt6JUMpZmoIItL0jdfPwZjSoGf+mFyk9NEQ=; b=UXzeJuuITgBz5CvLcrdiSx6fazC9vgXP0ULs4aF72tzpTSpjbaJ+H4b2FWa8nYJCeB NjMyDS5Cek5/KeExnCMVuV0cgxu84GkYd7G716zqWNJHtinjhhmTKcJp0GhrEtboU7VP 9x4bmVhqkXYSRfM3qpwFsGLIkZTZ4cdnEaaWbI43MZkkXccIBKfw/DOEvIR1b4ljRBCq StXVOPwW8JHAv/iaE3N7tS9nhydu5q30ZN1U/d+ZlMrqNM1xatv72OpOxuqI7UZ4N6WZ iLyjizkq3vuzrMoAqysrnsWNnJf71gIKDl84//aa03YkWFHz87AxUlRtF8wfrVD1aksO nzEA== X-Gm-Message-State: ALoCoQl6CdbnVnUFCPa1BK0lwCI77V1OKnTbdFfOyG7MTS7DbarwGgFhFHBLIdRYOOk47RUp20k6 X-Received: by 10.58.150.68 with SMTP id ug4mr605236veb.50.1399468408137; Wed, 07 May 2014 06:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Wed, 7 May 2014 06:13:08 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Wed, 7 May 2014 09:13:08 -0400 Message-ID: To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/khWpHYYYDcJO3nCnejfXB6dlf3E Cc: Thomas Nadeau , Alia Atlas , "" , "wardd@cisco.com" Subject: Re: [i2rs] draft-ietf-i2rs-problem-statement-01 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, 07 May 2014 13:13:34 -0000 On Tue, May 6, 2014 at 7:05 PM, Dean Bogdanovic wrote: > High-throughput is always nice to have, Is it "nice to have" or "must have"? >but the quantification is a bit wishy washy. > Agreed. > High-Throughput: At a minimum, the I2RS Agent and associated router > should be able to handle a considerable number of operations per > second above what basic Netconf or a propretiary CLI can. > > What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over > NETCONF. Question: what is RPC doing? Is it simple operational get or large > config push? > Or some other complex RPC? > There is also difference in creating logical interfaces and adding term to a > filter or adding route to a routing table. Creating interface is most taxing > one and adding term is fastest create operation. >IMO, NETCONF has no problem > with throughput, it is the instrumentation and that is something we should > focus in I2RS. > What constructs do we want to control via I2RS and depending on that, make > sure that the protocol can sustain max throughput. > We need to pick something as a metric since as you say it will depend on the object type. The RIB table sounds like a reasonable object to standardize on. Pick a number like 1M table entries (large enough so as to be measurable). Throughput: This refers to some bulk table create/updates/dumps. Very few transactions/sec are needed, essentially in this case the agent and client are engaged in batching the entries they send to the other party. To handwave some numbers performance numbers: I am going to pick say 10s to 100s of thousands rows per/sec. We need bidirectional numbers. Transactions rate: This is a measure of request/response. Again using the RIB example - this would mean taking each of the 1M rows and send them one at a time (i.e window of 1). Eg a request from the client to create/update is sent to the agent and when a success response is received by the client the next request is issued ..... until all of 1M transactions are complete > In the next chapter you are mentioning > > Responsive: It should be possible to complete simple operations > within a sub-second time-scale. > > > Here you are stating simple operation, so why not define few simple > operations and put some quantification with it (in the below examples I'm > pulling the numbers out of my hat) > > example: > > read routes - single prefix per transaction < 0.5sec > - multiple prefixes per transaction < time on the wire + 0.5sec > add route - single prefix per transaction < 0.5 sec > - multiple prefixes per transaction 1000 routes/sec > > get filter info - single filter per transaction < 0.5sec > - multiple filters and terms per transaction < time on the wire + 0.5sec > create filter - single filter per transaction < 0.5 sec > - multiple filters per transaction 2000/sec > add term to filter - single term per transaction < 0.5sec > - multiple terms per transaction 3000/sec > > get interface info - single interface per transaction < 0.5 sec > - multiple interfaces per transaction < time on the wire + 0.5 sec > create interface - single interface per transaction < 0.5 sec > - multiple interfaces per transaction 100/sec > We need to have some quantification numbers. They dont have to be precise but could be in the ranges. I think what you describe above matches my thinking. Your "multiple per transaction" is essentially a batching artifact which falls under "throughput" metric. The " single per transaction" is a transaction metric. Having said that: I know you gave those numbers as examples, but they are way too low ;-> > I'm thinking how can you do assurance for i2rs. It looks as it is covered in > following paragraph > > Scalable, Filterable Information Access: To extract information in a > scalable fashion that is more easily used by applications, the > ability to specify filtering constructs in an operation requesting > data or requesting an asynchronous notification is very valuable. > > > but it is not spelled out. > I would consider the throughput, transaction rate and latency in that category as well. cheers, jamal From nobody Wed May 7 08:42: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 7025C1A0388 for ; Wed, 7 May 2014 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 RhaY_ReM9kSl for ; Wed, 7 May 2014 08:42:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7E1A0387 for ; Wed, 7 May 2014 08:42:47 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l6so1336498qcy.31 for ; Wed, 07 May 2014 08:42:43 -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=gqArBVlc4vxXcbqJz4c87APEO3JegXj1WXiowLLljNo=; b=O2aXUr7VV8FRhrxsMAblGa4TYfvewoiGhdlSlGKt5JZOOFRx9BypnZGqD5WhH3aql+ nsR7YC86iqQDwyCN4NQ9CWIhXDD3Xe4XJe5sxq0wHDEyrLxVWjxHJYNZ0RDMSERZ+qG6 LR/iUPoX+/AsMsxKZsZzeD6vNaBZjsQhIBxt1JwOP1WIDLKqk+QumbrEGcHsdLQry9ii NkxvpfgSJsmSKVj6UWdx/cy3j7kGimWlVWmpilEgcRdRMt5yEKC/8anK8SWJPjgZvBWq ufqracJwh1IU2EFFkM8pIHC1LvxW3411kW+HzEqTJC541PmtRdFsI/fRyKaLHD6QfTuM cwwg== X-Gm-Message-State: ALoCoQmL6R7N+cIEL+7p31I1z6M9VjoxqHPI8gmZ9F5T69ORzVXefbtO24F53DZfACbu81V8Z5Ll MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr24872986qgx.18.1399477363411; Wed, 07 May 2014 08:42:43 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 7 May 2014 08:42:43 -0700 (PDT) In-Reply-To: <003101cf69e3$07e84930$17b8db90$@ndzh.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> Date: Wed, 7 May 2014 08:42:43 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c152601e20ba04f8d13755 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tG6w6eUZBLwtdHej_VXi7L6kS44 Cc: Jeffrey Haas , Thomas Nadeau , Juergen Schoenwaelder , "t. petch" , "i2rs@ietf.org" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 07 May 2014 15:42:50 -0000 --001a11c152601e20ba04f8d13755 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 7, 2014 at 3:56 AM, Susan Hares wrote: > Andy: > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau: > > > > > > I imagine I2RS will be completely separate from NETCONF and it should have > its own datastore -- so "i2rs-config" is appropriate because I2RS is the only > protocol using that datastore. The combined "operational state" is not > editable. > > > > Yes, that makes sense. Then if at some point in time you want to save the > running config (i2rs), the system has to explicitly copy it over. But until > then, its separate. The only question is: what is the complete running > config represented as? And what if Netconf wants to modify the running > config (i.e.: and the RIB in particular)? > > > > That copy-to-local-config feature would be extra, outside the scope of the > i2rs-config. > > > > ----- > > > > Why only is the copy-to-local-config feature out of scope for the > I2rs-config? How can the work be interoperable if this feature (required > or optional) does not work the same in different vendor's boxes? If the > implementations are different, this is great (differentiated products = > good); but IMHO this feature actions has to be interoperable... that is give > the same effective response in the different vendors. > > > > Can you explain further? > > > Writing to the local config is the charter of the NETCONF WG, not I2RS. In order to copy from the I2RS data model to the configuration data model, a detailed mapping is required. Since the local-config is out of scope, the config data corresponding to the I2RS data is not required to exist. If it does exist, it can be vendor-specific, right? So the mapping is vendor specific. I would agree with you if I2RS was planning on standardizing data models for configuration and RIB editing. It that were the case, then I would re-ask the question Ron Bonica raised in London -- why would we want to write config data models with 1 language and I2RS data models with a different language? > > > > > Right. If we take that approach we need to have a way of the i2rs > "protocol" to signal that the config > > needs to be saved "soon". That is, its not done in real time, but rather > as a background process. > > Its probably. This can either be through a single keyword that is added > under the i2rs-config section, or > > per element or even per-element, if we decide to be more granular. > > > > > > IMHO it is important to know when the write to local-config is done even > if done in background. Are you indicating there is no > write-config/ack-complete-write config interaction? > > > > > > You seem to be suggesting that the I2RS behavior of forgetting all > injected state > > if the router happens to reboot is not that useful, and therefore it needs > to be > > saved in the background (best-effort). > > > > I think it is up to all the I2RS clients to always be around to receive > some > > sort of agent-reboot event, and re-install any required I2RS config. > > I can't imagine any use cases where the operator thinks "I only need to > > install this RIB data until that router accidentally reboots". > > > > > > If you re-install any required I2RS config, are you sure this is what the > I2RS client wants? > The protocol request would indicate what the client wants (e,g, copy-to-local config flag set). Since notifications are unreliable, a client will poll the 'agent-boots' counter frequently to see if needs to re-install lost state. This design does not scale well and introduces significant latency. It is much more convenient to have the agent deal with reinstall-after-reboot. > > Sue > > > Andy --001a11c152601e20ba04f8d13755 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 7, 2014 at 3:56 AM, Susan Hares <<= a href=3D"mailto:shares@ndzh.com" target=3D"_blank">shares@ndzh.com>= wrote:

Andy:<= u>

 

Thank you for detai= led discussion with Tom Petch/Jeff/Juergen/Tom Nadeau:

 

<snip>

<= div>

I imagine I2RS will be completely separate from = NETCONF and it should have its own dat= astore -- so "i2rs-config" is appropriate because I2RS is the only protocol using that datastore. The c= ombined "operational state" = is not editable.

 

Yes, that makes sense. Then if at some p= oint in time you want to save  th= e running config (i2rs), the system has to explicitly copy it over. But unt= il then, its separate.  The only = question is: what is the complete running config represented as? And what if Netconf wants to modify the running = config (i.e.: and the RIB in particular)?<= /u>

 

That copy-to-local-config feature would be ext= ra, outside the scope of the i2rs-config.

</snip>

-----

 

Why only is the copy-to-local-con= fig feature out of scope for the I2rs-config?   How can the work = be interoperable if this feature (required or optional) does not work the s= ame in different vendor’s boxes?  If the implementations are dif= ferent, this is great (differentiated products =3D good); but IMHO this fea= ture actions has to be interoperable… that is give the same effectiv= e response in the different vendors.  

 

Can you explain further? <= /p>

 

=

= Writing to the local config is the charter of the NETCONF WG, not I2RS.
In order to copy from the I2RS data model to the configuration data model,<= /div>
a detailed mapping is required.  Since the local-config is o= ut of scope,
the config data corresponding to the I2RS data is no= t required to exist.
If it does exist, it can be vendor-specific, right? So the mapping is = vendor specific.

I would agree with you if I2RS wa= s planning on standardizing data models
for configuration and RIB= editing.  It that were the case, then I would re-ask
the question Ron Bonica raised in London -- why would we want to write=
config data models with 1 language and I2RS data models with a d= ifferent language?


<snip> <= /u>

 

Right. If we take that approach we need to have a way of the i2r= s "protocol" to signal that the config 

needs to be saved "soon".  That is, its not done in real tim= e, but rather as a background process. 

Its probably. This can either be through a single keyw= ord that is added under the i2rs-config section, or

per element or even per-element, if we de= cide to be more granular. 

</snip>

 

IMHO it is importan= t to know when the write to local-config is done even if done in background= .   Are you indicating there is no write-config/ack-complete-writ= e config interaction?

 

=
 

<= div>

<snip>

You seem to be suggesting that the I2RS b= ehavior of forgetting all injected state

if the router happens to reboot is not that useful, and th= erefore it needs to be

saved in the background (best-effort).=

 

I think it is up to all the I2RS clients to= always be around to receive some

sort of agent-reboot event, and re-instal= l any required I2RS config.

I can't imagine any use cases where the operator thinks "I onl= y need to

install this RIB data until that router a= ccidentally reboots".

</snip>

 

If yo= u re-install any required I2RS config, are you sure this is what the I2RS c= lient wants?


The pr= otocol request would indicate what the client wants (e,g, copy-to-local con= fig flag set).
Since notifications are unreliable, a client will = poll the 'agent-boots' counter frequently to
see if needs to re-install lost state.  This design does not scal= e well and introduces significant
latency.  It is much more = convenient to have the agent deal with reinstall-after-reboot.

 

Sue <= /span>

 


= Andy

--001a11c152601e20ba04f8d13755-- From nobody Wed May 7 09:20: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 BC1881A07A6 for ; Wed, 7 May 2014 09:20:43 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 BhEvkjA_Zw4N for ; Wed, 7 May 2014 09:20:42 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 486321A032F for ; Wed, 7 May 2014 09:20:42 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ib6so1615939vcb.33 for ; Wed, 07 May 2014 09:20:38 -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:from:date:message-id:subject:to:cc :content-type; bh=q6m+4Nbo6k0CrlAJbTLxnTZndG9UDw3v14jdrnL4o3U=; b=Hi1vUY69daBPs9VXzWc2+eAqOLuGGwM1icQwoMdonLhk+90LUwWJaeiuXyuZXgEA6B VxCiaIrUpmSUaCX6IrOEXt1zC/+KWn7zK1hTuwDZzyYNjwIg5kSRJsN3Wx6QY2HNp4WF wVX5xYUNpTbEXIs2ux7AfdqlKrM2B0MK3j2Cp0iElzXdErFrfYdp+vKQOaxqTUo/6r2O CqRZTBVrWuhSNAkOvJ5Jw7AefupQx+UM7/zN07iWq1rgyI+sYh0N31GLf/S1VIV42gt0 6VWiADPuqD5Z0gR1NUvkgjwl0GU/r2xpGtLaONkaWsSV574g/rOcTOp98yv8t3V5/Og3 Cs5A== X-Gm-Message-State: ALoCoQlFsD2SLYvAUj6DWo7+rvOkJ/kbPIpsX+g9b15qchvi4Nyvk4BVEEfe+1KwkjEfHyC9zwGu X-Received: by 10.52.163.145 with SMTP id yi17mr2335632vdb.46.1399479637836; Wed, 07 May 2014 09:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Wed, 7 May 2014 09:20:17 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 7 May 2014 12:20:17 -0400 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oubFh50xHhy4RlXLa6DaqFldhb0 Cc: Jeffrey Haas , "forces@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic Subject: [i2rs] Update to Wiki (ForCES for I2RS) 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, 07 May 2014 16:20:43 -0000 I have started updating the I2RS wiki on viability of using ForCES for I2RS. I posted those requirements on the list over the weekend and checking against them. To the other proposals (netconf, restconf, yang), it would be nice if we have a common set of requirements to check against. I will be updating the wiki as more discussions for requirements come up as well as put more commentary. Enjoy! http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis cheers, jamal From nobody Wed May 7 09:42: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 18CB01A035A for ; Wed, 7 May 2014 09:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 R9S4jNJ97bnp for ; Wed, 7 May 2014 09:41:58 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A51AC1A02BE for ; Wed, 7 May 2014 09:41:58 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so1116961yha.38 for ; Wed, 07 May 2014 09:41:54 -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=poJPvH/SM0vKVNgV/gbMvaNErT5/F8YucB3SjloQGTA=; b=R9cy5C/qTeGNboJahnGDr/4///At3tTFYzBfs3YAbitYQ0BKRMZOOJ4v3b1LxjqKYG 6k5ZLwLgVHTPuaGum4tQGhU+ZVRop50ZLkrbicUnu//wT0CCAlQwv6RmiIEiA8QCY4Rv WN7T0rX/94GB+mgs+YnSU0MtU1bV9na3YXrs2knn/6QLqP3i27X5PNBKVV8G46c7Zk0/ ioBzQiB9Y6tsrb+yMO1roF9g/4y7qrR25Nxu8irrM2UZsJe7NFAR/AGqnBXwzznw1pk2 mxwWvQZGH/dEFn9j0r2SBdE4kHLHqCjOsQA7t8LaNGS9Q896EBsHCUI9itYCxkqQwmtH 0Jgw== MIME-Version: 1.0 X-Received: by 10.236.197.68 with SMTP id s44mr67225860yhn.109.1399480914275; Wed, 07 May 2014 09:41:54 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Wed, 7 May 2014 09:41:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 May 2014 12:41:54 -0400 Message-ID: From: Alia Atlas To: FABIO ZACCANTTE Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7apphrTeOQYxwO_BDkI1ABxWlAo Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 07 May 2014 16:42:00 -0000 Hi Fabio, Take a read through the architecture (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and problem-statement (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). If you can provide your questions and review after that, it would be quite helpful to know how solid a job the drafts do of explaining the work. Regards, Alia On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE wrote: > I am starting in the I2RS and my question is where stay I2RS, in the router > or controller. > > Someone has picture that represents the controller, the router, the network > and I2RS > > Regards, > Fabio. > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed May 7 10:09:00 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 744B81A078D for ; Wed, 7 May 2014 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 mQ1UgN8-OjQy for ; Wed, 7 May 2014 10:08:56 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id B99161A04A2 for ; Wed, 7 May 2014 10:08:55 -0700 (PDT) Received: from [192.168.1.105] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 020E32796BC3; Wed, 7 May 2014 13:08:50 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_07AD16B2-DEB7-40EA-B8F6-E2BD91553C58"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <003101cf69e3$07e84930$17b8db90$@ndzh.com> Date: Wed, 7 May 2014 13:08:49 -0400 Message-Id: <8A76E7FA-4CBC-4232-A7EB-D8D5468A6FB1@lucidvision.com> References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pxw8XBfEJj_yKu_MkuNiHXdeXZY Cc: Jeffrey Haas , i2rs@ietf.org, Juergen Schoenwaelder , Andy Bierman , "t. petch" Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 07 May 2014 17:08:58 -0000 --Apple-Mail=_07AD16B2-DEB7-40EA-B8F6-E2BD91553C58 Content-Type: multipart/alternative; boundary="Apple-Mail=_F96220A9-C777-441E-8E11-925E2F956163" --Apple-Mail=_F96220A9-C777-441E-8E11-925E2F956163 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 7, 2014:6:56 AM, at 6:56 AM, Susan Hares wrote: > Andy: > =20 > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom = Nadeau: > =20 > > I imagine I2RS will be completely separate from NETCONF and it should = have its own datastore -- so "i2rs-config" is appropriate because I2RS = is the only protocol using that datastore. The combined "operational = state" is not editable. > =20 > Yes, that makes sense. Then if at some point in time you want to save = the running config (i2rs), the system has to explicitly copy it over. = But until then, its separate. The only question is: what is the = complete running config represented as? And what if Netconf wants to = modify the running config (i.e.: and the RIB in particular)? > =20 > That copy-to-local-config feature would be extra, outside the scope of = the i2rs-config. > > ----- > =20 > Why only is the copy-to-local-config feature out of scope for the = I2rs-config? How can the work be interoperable if this feature = (required or optional) does not work the same in different vendor=92s = boxes? If the implementations are different, this is great = (differentiated products =3D good); but IMHO this feature actions has to = be interoperable=85 that is give the same effective response in the = different vendors. =20 > =20 > Can you explain further? > =20 >=20 > > =20 > Right. If we take that approach we need to have a way of the i2rs = "protocol" to signal that the config=20 > needs to be saved "soon". That is, its not done in real time, but = rather as a background process.=20 > Its probably. This can either be through a single keyword that is = added under the i2rs-config section, or > per element or even per-element, if we decide to be more granular.=20 > > =20 > IMHO it is important to know when the write to local-config is done = even if done in background. Are you indicating there is no = write-config/ack-complete-write config interaction? There needs to be some sort of confirmation mechanism. Whether = this is an async notification, the state of a variable changed that the = writer can check (or both) is up for debate.=20 --Tom > > You seem to be suggesting that the I2RS behavior of forgetting all = injected state > if the router happens to reboot is not that useful, and therefore it = needs to be > saved in the background (best-effort). > =20 > I think it is up to all the I2RS clients to always be around to = receive some > sort of agent-reboot event, and re-install any required I2RS config. > I can't imagine any use cases where the operator thinks "I only need = to > install this RIB data until that router accidentally reboots". > > =20 > If you re-install any required I2RS config, are you sure this is what = the I2RS client wants? > =20 > Sue --Apple-Mail=_F96220A9-C777-441E-8E11-925E2F956163 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 7, 2014:6:56 AM, at 6:56 AM, = Susan Hares <shares@ndzh.com>= wrote:

Andy:
 
Thank you for detailed = discussion with Tom Petch/Jeff/Juergen/Tom = Nadeau:
 
<snip>
I imagine I2RS will be completely separate from = NETCONF and it should have its own datastore -- so "i2rs-config" is = appropriate because I2RS is the only protocol using that datastore. The combined = "operational state" is not editable.
 
Yes, = that makes sense. Then if at some point in time you want to = save  the = running config (i2rs), the system has to explicitly copy it over. But = until then, its = separate.  The only question is: what is the complete running = config represented as? And what if Netconf wants to modify the running = config (i.e.: and the RIB in particular)?
 
That = copy-to-local-config feature would be extra, outside the scope of the = i2rs-config.
</snip>
-----
 
Why only is = the copy-to-local-config feature out of scope for the I2rs-config?  =  How can the work be interoperable if this feature (required or = optional) does not work the same in different vendor=92s boxes?  If = the implementations are different, this is great (differentiated = products =3D good); but IMHO this feature actions has to be = interoperable=85 that is give the same effective response in the = different vendors.  
 
Can you = explain further?
 

<snip>
 
Right. If we take that approach we need to have a way of the = i2rs "protocol" to signal that the = config 
needs = to be saved "soon".  That is, its not done in real time, but rather = as a background process. 
Its probably. This can either be through a single = keyword that is added under the i2rs-config section, = or
per element or = even per-element, if we decide to be more = granular. 
</snip>
 
IMHO it is important to = know when the write to local-config is done even if done in background. =   Are you indicating there is no = write-config/ack-complete-write config = interaction?

There needs to be some sort of = confirmation mechanism. Whether this is an async notification, the state = of a variable changed that the writer can check (or both) is up for = debate. 

= --Tom


<snip>
You = seem to be suggesting that the I2RS behavior of forgetting all injected = state
if the router = happens to reboot is not that useful, and therefore it needs to = be
saved in the = background (best-effort).
 
I = think it is up to all the I2RS clients to always be around to receive = some
sort of = agent-reboot event, and re-install any required I2RS = config.
I = can't imagine any use cases where the operator thinks "I only need = to
install this = RIB data until that router accidentally reboots".
</snip>
 
If you re-install any required I2RS = config, are you sure this is what the I2RS client = wants?
 
Sue

= --Apple-Mail=_F96220A9-C777-441E-8E11-925E2F956163-- --Apple-Mail=_07AD16B2-DEB7-40EA-B8F6-E2BD91553C58 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 iQIcBAEBCgAGBQJTamihAAoJEPcO+I7eiUJZyHIP/3PkKCCnF7KM0wEJT7l5wv2W 4r/ZCMrHRJuOVvHBUis1gC5B025O7l9caT7YuUBVf2RQg+yuISp/yhWSwmws1nMJ 1MDfaPkdAhfh+htMEK6TotKi7twP7W2D6O0l1hX11avje/WTUuqYa+9FaK9TJJUO v1/hojCoItO99V85fTdVsWyWZBi3v2/XJlFakugQtTRSV0p+nEb/fQzsdd8C0fk1 buo7UhANb/9udEItL3a5P1TvdyWbakkSL9+g1pDZno+Ju96Ov4O/jdhRo/QXX0ZN M7disBlGbYczQelaSMC/PoWZfXB7GE7hyDryAAuNScuazS3vY+od9piH066Yhua/ 3Tl6jK/Y0hym8QtJ7HqqoCU28rgK5Ll0+SRSLb3r5ZTIdRivJuwAnDC34S30/aG1 xf4hdIXrLNEhERiIGfqyClEKcWbj/g7JcYIi+YE7u/7GJeWqPUiyD7MgAbsI3h4V 2xKUQkdZzs4HT40u70c7j8HYOR3Xlx4aNOkEFzziGxesgjfizJnruv9TcV1qtX7E 4TOkhbrpV+1P2vtyq7iFmvGYifUN/Yc1FNKivbc9PVELlBwPFwu6YLYUWel6SWHU p0YuVb3x1/YXLenFIxILiLY/m8PIFK3wD/bGk+eRlwepNmvcjxl8aXlSp15lR3Fv Krp1vfW1+ofNoJkCJlpY =5I+F -----END PGP SIGNATURE----- --Apple-Mail=_07AD16B2-DEB7-40EA-B8F6-E2BD91553C58-- From nobody Wed May 7 21:03: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 1ACE01A0218 for ; Wed, 7 May 2014 21:03:32 -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 cNUFdPK-qRxp for ; Wed, 7 May 2014 21:03:30 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 477831A0213 for ; Wed, 7 May 2014 21:03:30 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ib6so2565398vcb.33 for ; Wed, 07 May 2014 21:03:25 -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=L/y0Q9yN+NUVLWrtJKh6XeX11eZrdw69aayCDraydWc=; b=uGRFazLvOqr5CFRPLGJIwewTBpfH+csMRK9fcA+qcv+bmdd/dJlgTtRuc9oQYkViKU GjtV+Ey+SJ5S2D6qU57f0JBshid0LGuXExaiWJ/VmUkIO4ux9wyB8Ogl39qVqSgqAy8q UaAlIcWskW8U/u3s0gvS03vgbnIeVAkOOd7QPCg/8OP9k1FxGdGyTsJm6vjoipzGXcml cVu7TS6A64Licp3/2s98zBHXgpz+gshPk7QtWYr1hjogb1Ygmv35pixdnnXm2m3S3oTc HkvaAH+h8v+647C7bUSffJxKziOIWJn+BblEJnG4K9fPqGwE6jFjdW0HHamvPq+s2nrN mk9Q== MIME-Version: 1.0 X-Received: by 10.52.227.138 with SMTP id sa10mr835047vdc.25.1399521805686; Wed, 07 May 2014 21:03:25 -0700 (PDT) Received: by 10.221.19.129 with HTTP; Wed, 7 May 2014 21:03:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 01:03:25 -0300 Message-ID: From: FABIO ZACCANTTE To: Alia Atlas Content-Type: multipart/alternative; boundary=089e0111d816155fce04f8db909a Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3mnRoHLyVnh4YS8ts8ruR4VYhWc Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 08 May 2014 04:03:32 -0000 --089e0111d816155fce04f8db909a Content-Type: text/plain; charset=UTF-8 Hi Alia What is the biggest difference in SDN when I have I2RS and when i not have? Regards, Fabio On Wed, May 7, 2014 at 1:41 PM, Alia Atlas wrote: > Hi Fabio, > > Take a read through the architecture > (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and > problem-statement > (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). > > If you can provide your questions and review after that, it would be > quite helpful to know how solid a job the drafts do of explaining the > work. > > Regards, > Alia > > On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE > wrote: > > I am starting in the I2RS and my question is where stay I2RS, in the > router > > or controller. > > > > Someone has picture that represents the controller, the router, the > network > > and I2RS > > > > Regards, > > Fabio. > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > --089e0111d816155fce04f8db909a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alia=C2=A0


What = is the biggest difference in SDN when I have I2RS and when i not have?


Regards,
Fabio



O= n Wed, May 7, 2014 at 1:41 PM, Alia Atlas <akatlas@gmail.com> wrote:
Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) an= d
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-stateme= nt).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
> I am starting in the I2RS and my question is where stay I2RS, in the r= outer
> or controller.
>
> Someone has picture that represents the controller, the router, the ne= twork
> and I2RS
>
> Regards,
> Fabio.
>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

--089e0111d816155fce04f8db909a-- From nobody Thu May 8 04:12:00 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 5C3FB1A049D for ; Thu, 8 May 2014 04:11:57 -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_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 m8eZebA8Oilk for ; Thu, 8 May 2014 04:11:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2E37D1A0462 for ; Thu, 8 May 2014 04:11:54 -0700 (PDT) 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.939.12; Thu, 8 May 2014 11:11:42 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) with mapi id 15.00.0939.000; Thu, 8 May 2014 11:11:37 +0000 From: Dean Bogdanovic To: FABIO ZACCANTTE Thread-Topic: [i2rs] Interface to The Internet Routing System (IRS) Thread-Index: AQHPaedgqDUse6UVrki0f0WgcXPYj5s1UrIAgAC+aoCAAHefgA== Date: Thu, 8 May 2014 11:11:36 +0000 Message-ID: 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-originating-ip: [66.129.241.14] x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(377454003)(51704005)(24454002)(199002)(189002)(62966002)(86362001)(64706001)(92726001)(2656002)(20776003)(21056001)(99396002)(77982001)(15202345003)(93916002)(89996001)(87936001)(88136002)(36756003)(4396001)(99286001)(33656001)(50226001)(79102001)(87286001)(83716003)(15975445006)(81542001)(57306001)(16236675002)(101416001)(81342001)(19580405001)(83322001)(19580395003)(1411001)(82746002)(76482001)(77156001)(66066001)(46102001)(50986999)(74502001)(80022001)(74662001)(76176999)(85852003)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: multipart/alternative; boundary="_000_DB1B7DCA76AA4DE08958C40C3B02BAADjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gF9HJ3GVvBbuswtBVNd4otDDceU Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 08 May 2014 11:11:57 -0000 --_000_DB1B7DCA76AA4DE08958C40C3B02BAADjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fabio, Alia was nice to give you some starting points, essentially taught you how = to fish, but you are asking to be given the fish. Dean On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE > wrote: Hi Alia What is the biggest difference in SDN when I have I2RS and when i not have? Regards, Fabio On Wed, May 7, 2014 at 1:41 PM, Alia Atlas > wrote: Hi Fabio, Take a read through the architecture (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and problem-statement (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). If you can provide your questions and review after that, it would be quite helpful to know how solid a job the drafts do of explaining the work. Regards, Alia On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE > wrote: > I am starting in the I2RS and my question is where stay I2RS, in the rout= er > or controller. > > Someone has picture that represents the controller, the router, the netwo= rk > and I2RS > > Regards, > Fabio. > > _______________________________________________ > 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_DB1B7DCA76AA4DE08958C40C3B02BAADjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <425B34DF75B6F74A9FD7A24157D02F09@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Fabio,

Alia was nice to give you some starting points, essentially taught you= how to fish, but you are asking to be given the fish.

Dean

On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:

Hi Alia 


What is the biggest difference in SDN when I have I2RS and when i not = have?


Regards,
Fabio



On Wed, May 7, 2014 at 1:41 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) an= d
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-stateme= nt).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
> I am starting in the I2RS and my question is where stay I2RS, in the r= outer
> or controller.
>
> Someone has picture that represents the controller, the router, the ne= twork
> and I2RS
>
> Regards,
> Fabio.
>
> _______________________________________________
> 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_DB1B7DCA76AA4DE08958C40C3B02BAADjunipernet_-- From nobody Thu May 8 04:41: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 11D3F1A04A2 for ; Thu, 8 May 2014 04:41:55 -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 DWDubUu7WdRC for ; Thu, 8 May 2014 04:41:53 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0651A049D for ; Thu, 8 May 2014 04:41:52 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id ld13so2527109vcb.12 for ; Thu, 08 May 2014 04:41:48 -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=4qzhShgPNLxnBzJ7v79QB5ig/R77rbNUS19ymQGvXnA=; b=MlpaFUuDgDkzlyEkT53B6yUM1PcAnnD7fA6ztriottU5gOJ68YdjGK0dNzuVT3Cc07 YcEHDDL+kqL46RfUgWdo7MO0SYxuYcZXC87+jMG+L196gD927lm38i13QWp9PigMJtiJ WQiVEbrfPZmgDkBIfXK16qC040vHUXACU+vNee940/nbugMPRDwVwo5n0QqrqUSa+III wtQNrZkHAukSTcNhlhN9aFWnwW8idqtzZSuvk56gwwInuPX2Mt1jJSu3BuLMRLhwDD05 mJwsz0SF+TkLXltv7xHXdP4pwoGQXJmMVhiHlOtBI+oD7hPuyJ8q4fNEFg0W//COC6e5 Wd1Q== MIME-Version: 1.0 X-Received: by 10.220.105.4 with SMTP id r4mr2442892vco.27.1399549308406; Thu, 08 May 2014 04:41:48 -0700 (PDT) Received: by 10.221.19.129 with HTTP; Thu, 8 May 2014 04:41:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 08:41:48 -0300 Message-ID: From: FABIO ZACCANTTE To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=089e0122f3325fa17204f8e1f71e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UVvLsOpeI8Z1kH87B3AVMlju1cQ Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 08 May 2014 11:41:55 -0000 --089e0122f3325fa17204f8e1f71e Content-Type: text/plain; charset=UTF-8 Hi Dean I need to present I2RS in the next week to my teacher to convince him to guide me in my master's degree and this is why many issues that at first I should try to understand, is due to lack of time to study. I need have overview about SDN and I2RS. If someone has a tutorial for an overview of I2RS would help me a lot. Regards, Fabio. On Thu, May 8, 2014 at 8:11 AM, Dean Bogdanovic wrote: > Fabio, > > Alia was nice to give you some starting points, essentially taught you > how to fish, but you are asking to be given the fish. > > Dean > > On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE wrote: > > Hi Alia > > > What is the biggest difference in SDN when I have I2RS and when i not > have? > > > Regards, > Fabio > > > > On Wed, May 7, 2014 at 1:41 PM, Alia Atlas wrote: > >> Hi Fabio, >> >> Take a read through the architecture >> (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and >> problem-statement >> (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). >> >> If you can provide your questions and review after that, it would be >> quite helpful to know how solid a job the drafts do of explaining the >> work. >> >> Regards, >> Alia >> >> On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE >> wrote: >> > I am starting in the I2RS and my question is where stay I2RS, in the >> router >> > or controller. >> > >> > Someone has picture that represents the controller, the router, the >> network >> > and I2RS >> > >> > Regards, >> > Fabio. >> > >> > _______________________________________________ >> > 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 > > > --089e0122f3325fa17204f8e1f71e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dean=C2=A0
=

I need to present I2RS in the next week to my= teacher to convince him to guide me in my master's degree =C2=A0and th= is is why many issues that at first I should try to understand, is due to l= ack of time to study.

I need have overview about SDN and I2RS.

If someone has a tutorial for an overview = of I2RS would help me a lot.=C2=A0

Regards,
Fabio.




On Thu, May 8, 2014 at 8:11 AM, Dean Bogdanovic <deanb@juniper= .net> wrote:
Fabio,

Alia was nice to give you some starting points, essentially taught you= how to fish, but you are asking to be given the fish.

Dean

On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
Hi Alia=C2=A0


What is the biggest difference in SDN when I have I2RS and when i not = have?


Regards,
Fabio



On Wed, May 7, 2014 at 1:41 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) an= d
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-stateme= nt).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
> I am starting in the I2RS and my question is where stay I2RS, in the r= outer
> or controller.
>
> Someone has picture that represents the controller, the router, the ne= twork
> and I2RS
>
> Regards,
> Fabio.
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs
>

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


--089e0122f3325fa17204f8e1f71e-- From nobody Thu May 8 07:02:22 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 891441A068A for ; Thu, 8 May 2014 07:02:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 HU09KmvSWYDQ for ; Thu, 8 May 2014 07:02:16 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3808A1A0686 for ; Thu, 8 May 2014 07:02:15 -0700 (PDT) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Thu, 8 May 2014 14:02:09 +0000 Message-ID: <002f01cf6ac5$c6909760$4001a8c0@gateway.2wire.net> From: t.petch To: Date: Thu, 8 May 2014 14:59:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AMSPR07CA010.eurprd07.prod.outlook.com (10.242.77.178) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(199002)(189002)(377454003)(13464003)(377424004)(50226001)(81686999)(66066001)(62236002)(79102001)(50466002)(99396002)(20776003)(89996001)(88136002)(15975445006)(50986999)(44736004)(84392001)(93916002)(19580395003)(46102001)(76482001)(74502001)(42186004)(101416001)(87976001)(31966008)(86362001)(19580405001)(4396001)(83322001)(44716002)(92726001)(33646001)(77982001)(81342001)(85852003)(61296002)(81816999)(62966002)(80022001)(83072002)(47776003)(74662001)(87286001)(15202345003)(64706001)(92566001)(21056001)(23756003)(14496001)(77156001)(81542001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QiwqE2AVjJbQyImHo92wtYXeabA Subject: [i2rs] Fw: I-D Action: draft-tp-i2rs-yang-00.txt 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, 08 May 2014 14:02:19 -0000 I have made a number of posts to the I2RS list over the past two months offering information and opinion on what YANG and NETCONF are and how they might interact with I2RS. This I-D brings them together in a single place. I did call it 'NETCONF Surprises' at first - as I have said before, YANG and NETCONF do an excellent job in the role for which they were defined, that of config, but might surprise those who are not over familiar with them. Tom Petch ----- Original Message ----- From: To: Sent: Thursday, May 08, 2014 2:47 PM > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Interactions of I2RS with NETCONF and YANG > Author : Tom Petch > Filename : draft-tp-i2rs-yang-00.txt > Pages : 9 > Date : 2014-05-08 > > Abstract: > This memo looks at some possible interactions between the > requirements of I2RS and the current capabilities (and data models) > of YANG and NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-tp-i2rs-yang/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-tp-i2rs-yang-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu May 8 10:25: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 914811A0075 for ; Thu, 8 May 2014 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 6sJdHYUhTs3w for ; Thu, 8 May 2014 10:24:57 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CA4BD1A0074 for ; Thu, 8 May 2014 10:24:56 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so2847558wgg.30 for ; Thu, 08 May 2014 10:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UXMjnw+yAa3+bH6i2kymsSLaWv+V8IyzFuLd+mq4Prw=; b=XPugoXWtoLLBVZFOwkMX+qiPREnFHLM+QjHS7hbv1yR7OLmLW2HSe/7B9jJXHeAqo4 iNtboQX6quAhrAblUmYV3O30HDmWb/2obomUkRA8d7rf/8sfeN2yxY2dUVKehRtPB3RA 1BEAX2OISlVBVP92zENXH3I4akXvgw+Zv5EqwzClB+GyhVyvDVGC3kIJoT5xyPd9RJeD TQ0leTRUDaoAge8BL15D3HaX87SmqcqAb/IDobrzFwy/fvjKRP97L1evtz1J+NmBYCFU gddbpy8jZKmA1ZqKplj5XRKalWxxBj72IgW44UUvBhb51/HMJUmyViDJIXQ6oU+jUjr0 CSqw== 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:from:date :message-id:subject:to:cc:content-type; bh=UXMjnw+yAa3+bH6i2kymsSLaWv+V8IyzFuLd+mq4Prw=; b=DveKmrPo1JKxu1pi26LvtPiwSKmnVkcLuV7wBdLClW2UOUyaJLGZ7jAov1qLq+lPpL 8GAD24DEOh1aUKGXjQphKvZrqf4h5m1stW7PvTCljaFFA6/cPfe7WXMjSeSnb+Xo+zsn 4kbSLAUFuG0wywFWgls38cvnmAK0ZoIGPwIbiBqDfY0hPAHzN7XEINVegpMgpX+PZtn5 Ery/isjgw1SNYkfxzcsBYfkpKx9TJo/CM2b8IHj3ancKZYU3CIvT1Cszm9OPZCBlPoxP /sAY0ikwwKaQT2iJ1UCMtIn2FF/w45ms4AXo9AOfaHcvO0hZgC6Xu2MTpahY6+KZtxZ5 d6RA== X-Gm-Message-State: ALoCoQmU5lyoc2aNlnqlacwjtQYeErep1VHwGWsFkGAxLNcBf62fTinK0SbXIPL1yfVoBgGPQ8BA X-Received: by 10.180.208.52 with SMTP id mb20mr980030wic.34.1399569891758; Thu, 08 May 2014 10:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.222.131 with HTTP; Thu, 8 May 2014 10:24:11 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Thu, 8 May 2014 10:24:11 -0700 Message-ID: To: FABIO ZACCANTTE Content-Type: multipart/alternative; boundary=001a11c38e463cc22f04f8e6c20e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3VL8XilehW6yd2kivl9OZ39BRFE Cc: "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 08 May 2014 17:24:59 -0000 --001a11c38e463cc22f04f8e6c20e Content-Type: text/plain; charset=ISO-8859-1 Fabio; Please read the drafts Alia referred you to. They should provide you with a fairly comprehensive introduction w/r/t both intent and functionality. cheers, -ed On Thu, May 8, 2014 at 4:41 AM, FABIO ZACCANTTE wrote: > Hi Dean > > I need to present I2RS in the next week to my teacher to convince him to > guide me in my master's degree and this is why many issues that at first I > should try to understand, is due to lack of time to study. > > I need have overview about SDN and I2RS. > > If someone has a tutorial for an overview of I2RS would help me a lot. > > Regards, > Fabio. > > > > > On Thu, May 8, 2014 at 8:11 AM, Dean Bogdanovic wrote: > >> Fabio, >> >> Alia was nice to give you some starting points, essentially taught you >> how to fish, but you are asking to be given the fish. >> >> Dean >> >> On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE >> wrote: >> >> Hi Alia >> >> >> What is the biggest difference in SDN when I have I2RS and when i not >> have? >> >> >> Regards, >> Fabio >> >> >> >> On Wed, May 7, 2014 at 1:41 PM, Alia Atlas wrote: >> >>> Hi Fabio, >>> >>> Take a read through the architecture >>> (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and >>> problem-statement >>> (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). >>> >>> If you can provide your questions and review after that, it would be >>> quite helpful to know how solid a job the drafts do of explaining the >>> work. >>> >>> Regards, >>> Alia >>> >>> On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE >>> wrote: >>> > I am starting in the I2RS and my question is where stay I2RS, in the >>> router >>> > or controller. >>> > >>> > Someone has picture that represents the controller, the router, the >>> network >>> > and I2RS >>> > >>> > Regards, >>> > Fabio. >>> > >>> > _______________________________________________ >>> > 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 > > --001a11c38e463cc22f04f8e6c20e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fabio;

Please read the drafts Alia refe= rred you to. =A0They should provide you with a fairly comprehensive introdu= ction w/r/t both intent and functionality. =A0

che= ers,
=A0 =A0-ed


On Thu, May 8, 2014 at 4:41 AM, FABIO ZACCANTTE <zaccantte= @gmail.com> wrote:
H= i Dean=A0

I need to present I2RS in the next week to my teacher to = convince him to guide me in my master's degree =A0and this is why many = issues that at first I should try to understand, is due to lack of time to = study.

I need have overview about SDN and I2RS.
=

If someone has a tutorial for an overview = of I2RS would help me a lot.=A0

Regards,
Fabio.




On Thu, May 8, 2014 at = 8:11 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
Fabio,

Alia was nice to give you some starting points, essentially taught you= how to fish, but you are asking to be given the fish.

Dean

On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
Hi Alia=A0


What is the biggest difference in SDN when I have I2RS and when i not = have?


Regards,
Fabio



On Wed, May 7, 2014 at 1:41 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) an= d
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-stateme= nt).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
> I am starting in the I2RS and my question is where stay I2RS, in the r= outer
> or controller.
>
> Someone has picture that represents the controller, the router, the ne= twork
> and I2RS
>
> Regards,
> Fabio.
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs
>

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



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


--001a11c38e463cc22f04f8e6c20e-- From nobody Thu May 8 10:31:47 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 430E31A00CB for ; Thu, 8 May 2014 10:31:46 -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 Tg3UHJJ_xbS0 for ; Thu, 8 May 2014 10:31:44 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 58ED91A00BE for ; Thu, 8 May 2014 10:31:44 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lc6so3717260vcb.16 for ; Thu, 08 May 2014 10:31: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=aYzBAOSbHs9aTwNV6onhkVRLPhztMPgKHBLJkXXEyKY=; b=KcCT61p+qwEWd4GPkoDePlPewPN0uMuNgziACNbLxkC4m4PNsu5NpuIOFudmB/qE7N TUvzmuV5vkA0j0RoOrTVskGR8HwnxYwcswpoj8C0I+QX+N5vwA5P8bKTNur0hObRo0sG 0Mq8k0NX7Lr7O0X/zTo/eG/++JGWtThNzukkNRxYo8O4/7rNdGxJWB+7UXR3UB/WCdl3 fT5jiXoduXiQh4iIBnhldWUpj4ln71BqDPGXO7M2jqpgAV6B0AwW5tU2yHPR5ryv4OH7 34vLwBHZBm8th9kGjV/NHlJxwB0hssy3u+zDaO0ss45cxAtZS9s3A6gmqe1dpbvbf/78 gu6w== MIME-Version: 1.0 X-Received: by 10.58.54.12 with SMTP id f12mr1810627vep.75.1399570299628; Thu, 08 May 2014 10:31:39 -0700 (PDT) Received: by 10.58.107.33 with HTTP; Thu, 8 May 2014 10:31:39 -0700 (PDT) Received: by 10.58.107.33 with HTTP; Thu, 8 May 2014 10:31:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 19:31:39 +0200 Message-ID: From: Rui Bernardo To: FABIO ZACCANTTE Content-Type: multipart/alternative; boundary=089e012942228c2ffc04f8e6da1a Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-LcB3I67uAMASQoddpo31MrG4LY Cc: "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 08 May 2014 17:31:46 -0000 --089e012942228c2ffc04f8e6da1a Content-Type: text/plain; charset=UTF-8 Hi Fabio. As you know in live we have to work and study a lot. So, before asking here this questions you should read the basic documentation 1st. Regards, Rui On May 8, 2014 1:41 PM, "FABIO ZACCANTTE" wrote: > Hi Dean > > I need to present I2RS in the next week to my teacher to convince him to > guide me in my master's degree and this is why many issues that at first I > should try to understand, is due to lack of time to study. > > I need have overview about SDN and I2RS. > > If someone has a tutorial for an overview of I2RS would help me a lot. > > Regards, > Fabio. > > > > > On Thu, May 8, 2014 at 8:11 AM, Dean Bogdanovic wrote: > >> Fabio, >> >> Alia was nice to give you some starting points, essentially taught you >> how to fish, but you are asking to be given the fish. >> >> Dean >> >> On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE >> wrote: >> >> Hi Alia >> >> >> What is the biggest difference in SDN when I have I2RS and when i not >> have? >> >> >> Regards, >> Fabio >> >> >> >> On Wed, May 7, 2014 at 1:41 PM, Alia Atlas wrote: >> >>> Hi Fabio, >>> >>> Take a read through the architecture >>> (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and >>> problem-statement >>> (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). >>> >>> If you can provide your questions and review after that, it would be >>> quite helpful to know how solid a job the drafts do of explaining the >>> work. >>> >>> Regards, >>> Alia >>> >>> On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE >>> wrote: >>> > I am starting in the I2RS and my question is where stay I2RS, in the >>> router >>> > or controller. >>> > >>> > Someone has picture that represents the controller, the router, the >>> network >>> > and I2RS >>> > >>> > Regards, >>> > Fabio. >>> > >>> > _______________________________________________ >>> > 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 > > --089e012942228c2ffc04f8e6da1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Fabio.

As you know in live we have to work and study a lot. So, bef= ore asking here this questions you should read the basic documentation 1st.=

Regards,
Rui

On May 8, 2014 1:41 PM, "FABIO ZACCANTTE&qu= ot; <zaccantte@gmail.com> = wrote:
Hi Dean=C2=A0
<= span style=3D"line-height:20px">
I need to present I2RS in the next week to my teacher to convin= ce him to guide me in my master's degree =C2=A0and this is why many iss= ues that at first I should try to understand, is due to lack of time to stu= dy.

I need have overview about SDN and I2RS.
=

If someone has a tutorial for an overview = of I2RS would help me a lot.=C2=A0

Regards,
Fabio.




On Thu, May 8, 2014 at 8:11 AM, Dean Bogdanovic <deanb@juniper= .net> wrote:
Fabio,

Alia was nice to give you some starting points, essentially taught you= how to fish, but you are asking to be given the fish.

Dean

On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
Hi Alia=C2=A0


What is the biggest difference in SDN when I have I2RS and when i not = have?


Regards,
Fabio



On Wed, May 7, 2014 at 1:41 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) an= d
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-stateme= nt).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
> I am starting in the I2RS and my question is where stay I2RS, in the r= outer
> or controller.
>
> Someone has picture that represents the controller, the router, the ne= twork
> and I2RS
>
> Regards,
> Fabio.
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs
>

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



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

--089e012942228c2ffc04f8e6da1a-- From nobody Thu May 8 10:48:23 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 03F8F1A0078 for ; Thu, 8 May 2014 10:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 qvhk52GKsx1r for ; Thu, 8 May 2014 10:48:14 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9387B1A0096 for ; Thu, 8 May 2014 10:48:13 -0700 (PDT) Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Thu, 8 May 2014 17:48:07 +0000 Message-ID: <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> Date: Thu, 8 May 2014 18:45:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AMXPR07CA010.eurprd07.prod.outlook.com (10.242.64.50) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377454003)(51704005)(189002)(199002)(81816999)(85852003)(81342001)(14496001)(23756003)(81542001)(77156001)(21056001)(83072002)(62966002)(61296002)(80022001)(92566001)(64706001)(74662001)(87286001)(47776003)(88136002)(89996001)(50466002)(20776003)(99396002)(44736004)(84392001)(50986999)(50226001)(81686999)(76176999)(66066001)(62236002)(79102001)(19580405001)(4396001)(83322001)(86362001)(31966008)(77982001)(33646001)(44716002)(92726001)(46102001)(76482001)(19580395003)(93916002)(87976001)(101416001)(42186004)(74502001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DBXPRD0510HT005.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rbdWPUUJC4g5IdDJU7I35LvwFkc Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 08 May 2014 17:48:19 -0000 Sue I am afraid I cannot parse this e-mail to see where the text is yours and where it is something earlier and where the questions are unanswered:-( Datastores in NETCONF/YANG are a NETCONF construct and define a set of configuration information. YANG has no concept of where data is or its persistence except to a limited extent when it is applying validation logic, as in RFC6020 s7.5.3 (which probably does not make much sense in isolation - my I-D might help). So a datastore is a set of 'config true' data nodes stored somewhere. Move away from configuration and there is no other concept, apart from everything else, all the statistics, routing tables and so on. Hence my suggestion that I2RS will need a YANG substatement to mark out the data of interest to I2RS, perhaps with a name attached so that there can be multiple sets of I2RS data, to read, to write, to copy and so on as a meaningful unit; it would probably be a mistake to call that a datastore given the more specific meaning that that term has acquired in NETCONF, of a unit of configuration data. Tom Petch ----- Original Message ----- From: "Susan Hares" To: "'Andy Bierman'" ; "'Thomas Nadeau'" Cc: "'Jeffrey Haas'" ; ; "'Juergen Schoenwaelder'" ; "'t. petch'" Sent: Wednesday, May 07, 2014 11:56 AM > Andy: > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau: > > > > > > I imagine I2RS will be completely separate from NETCONF and it should have > its own datastore -- so "i2rs-config" is appropriate because I2RS is the > only protocol using that datastore. The combined "operational state" is not > editable. > > > > Yes, that makes sense. Then if at some point in time you want to save the > running config (i2rs), the system has to explicitly copy it over. But until > then, its separate. The only question is: what is the complete running > config represented as? And what if Netconf wants to modify the running > config (i.e.: and the RIB in particular)? > > > > That copy-to-local-config feature would be extra, outside the scope of the > i2rs-config. > > > > ----- > > > > Why only is the copy-to-local-config feature out of scope for the > I2rs-config? How can the work be interoperable if this feature (required > or optional) does not work the same in different vendor's boxes? If the > implementations are different, this is great (differentiated products = > good); but IMHO this feature actions has to be interoperable. that is give > the same effective response in the different vendors. > > > > Can you explain further? > > > > > > > > > Right. If we take that approach we need to have a way of the i2rs "protocol" > to signal that the config > > needs to be saved "soon". That is, its not done in real time, but rather as > a background process. > > Its probably. This can either be through a single keyword that is added > under the i2rs-config section, or > > per element or even per-element, if we decide to be more granular. > > > > > > IMHO it is important to know when the write to local-config is done even if > done in background. Are you indicating there is no > write-config/ack-complete-write config interaction? > > > > > > You seem to be suggesting that the I2RS behavior of forgetting all injected > state > > if the router happens to reboot is not that useful, and therefore it needs > to be > > saved in the background (best-effort). > > > > I think it is up to all the I2RS clients to always be around to receive some > > sort of agent-reboot event, and re-install any required I2RS config. > > I can't imagine any use cases where the operator thinks "I only need to > > install this RIB data until that router accidentally reboots". > > > > > > If you re-install any required I2RS config, are you sure this is what the > I2RS client wants? > > > > Sue > From nobody Thu May 8 12:17:47 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 4A00C1A0104 for ; Thu, 8 May 2014 12:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 wJmTeo7GW_r2 for ; Thu, 8 May 2014 12:17:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 27B051A00FE for ; Thu, 8 May 2014 12:17:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88D74E7B; Thu, 8 May 2014 21:17:36 +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 2sFoSgCiLvN3; Thu, 8 May 2014 21:17:35 +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, 8 May 2014 21:17:35 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D12D920017; Thu, 8 May 2014 21:17:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ycg6BjpqDIlx; Thu, 8 May 2014 21:17:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 382D620013; Thu, 8 May 2014 21:17:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A76002CCC079; Thu, 8 May 2014 21:17:33 +0200 (CEST) Date: Thu, 8 May 2014 21:17:33 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20140508191733.GA75343@elstar.local> Mail-Followup-To: "t. petch" , Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org References: <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_Q8QAb3hlwLMFkWyMsW2Mb1IL7Y Cc: 'Jeffrey Haas' , i2rs@ietf.org, Susan Hares Subject: Re: [i2rs] edit-data substatement Re: Operational State 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: Thu, 08 May 2014 19:17:44 -0000 On Thu, May 08, 2014 at 06:45:34PM +0100, t. petch wrote: > Sue > > I am afraid I cannot parse this e-mail to see where the text is yours > and where it is something earlier and where the questions are > unanswered:-( > > Datastores in NETCONF/YANG are a NETCONF construct and define a set of > configuration information. YANG has no concept of where data is or its > persistence except to a limited extent when it is applying validation > logic, as in RFC6020 s7.5.3 (which probably does not make much sense in > isolation - my I-D might help). > > So a datastore is a set of 'config true' data nodes stored somewhere. > Move away from configuration and there is no other concept, apart from > everything else, all the statistics, routing tables and so on. Hence my > suggestion that I2RS will need a YANG substatement to mark out the data > of interest to I2RS, perhaps with a name attached so that there can be > multiple sets of I2RS data, to read, to write, to copy and so on as a > meaningful unit; it would probably be a mistake to call that a datastore > given the more specific meaning that that term has acquired in NETCONF, > of a unit of configuration data. Tom, RFC 6241 says: o datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. Note the distinction between a datastore and a configuration datastore. /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 Thu May 8 17:54: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 637131A01C2; Thu, 8 May 2014 17:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] 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 Ri_DAFmuDr3D; Thu, 8 May 2014 17:54:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E4AF61A01DB; Thu, 8 May 2014 17:54:14 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 35B95127C587; Fri, 9 May 2014 08:54:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s490s2qM025372; Fri, 9 May 2014 08:54:02 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> References: <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359 <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> To: "t.petch" MIME-Version: 1.0 X-KeepSent: A4577A28:833DC190-48257CD3:0004A32F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Fri, 9 May 2014 08:54:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-09 08:54:03, Serialize complete at 2014-05-09 08:54:03 Content-Type: multipart/alternative; boundary="=_alternative 0004F2BD48257CD3_=" X-MAIL: mse02.zte.com.cn s490s2qM025372 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/X_o__-GIwbVfb5QImB0ThNU2S_w Cc: 'Jeffrey Haas' , i2rs@ietf.org, i2rs , Susan Hares Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 09 May 2014 00:54:24 -0000 This is a multipart message in MIME format. --=_alternative 0004F2BD48257CD3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJhaXNlZCBhIGlzc3VlIGFib3V0IHRoaXMgaW4gbmV0bW9kIFdHLA0Kc2VlOiAgaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzA5NzE2 Lmh0bWwNCi9mcmFuaw0KDQoiaTJycyIgPGkycnMtYm91bmNlc0BpZXRmLm9yZz4g0LTT2iAyMDE0 LTA1LTA5IDAxOjQ1OjM0Og0KDQoNCj4gDQo+IFN1ZQ0KPiANCj4gSSBhbSBhZnJhaWQgSSBjYW5u b3QgcGFyc2UgdGhpcyBlLW1haWwgdG8gc2VlIHdoZXJlIHRoZSB0ZXh0IGlzIHlvdXJzDQo+IGFu ZCB3aGVyZSBpdCBpcyBzb21ldGhpbmcgZWFybGllciBhbmQgd2hlcmUgdGhlIHF1ZXN0aW9ucyBh cmUNCj4gdW5hbnN3ZXJlZDotKA0KPiANCj4gRGF0YXN0b3JlcyBpbiBORVRDT05GL1lBTkcgYXJl IGEgTkVUQ09ORiBjb25zdHJ1Y3QgYW5kIGRlZmluZSBhIHNldCBvZg0KPiBjb25maWd1cmF0aW9u IGluZm9ybWF0aW9uLiAgWUFORyBoYXMgbm8gY29uY2VwdCBvZiB3aGVyZSBkYXRhIGlzIG9yIGl0 cw0KPiBwZXJzaXN0ZW5jZSBleGNlcHQgdG8gYSBsaW1pdGVkIGV4dGVudCB3aGVuIGl0IGlzIGFw cGx5aW5nIHZhbGlkYXRpb24NCj4gbG9naWMsIGFzIGluIFJGQzYwMjAgczcuNS4zICh3aGljaCBw cm9iYWJseSBkb2VzIG5vdCBtYWtlIG11Y2ggc2Vuc2UgaW4NCj4gaXNvbGF0aW9uIC0gbXkgSS1E IG1pZ2h0IGhlbHApLg0KPiANCj4gU28gYSBkYXRhc3RvcmUgaXMgYSBzZXQgb2YgJ2NvbmZpZyB0 cnVlJyBkYXRhIG5vZGVzIHN0b3JlZCBzb21ld2hlcmUuDQo+IE1vdmUgYXdheSBmcm9tIGNvbmZp Z3VyYXRpb24gYW5kIHRoZXJlIGlzIG5vIG90aGVyIGNvbmNlcHQsIGFwYXJ0IGZyb20NCj4gZXZl cnl0aGluZyBlbHNlLCBhbGwgdGhlIHN0YXRpc3RpY3MsIHJvdXRpbmcgdGFibGVzIGFuZCBzbyBv bi4gIEhlbmNlIG15DQo+IHN1Z2dlc3Rpb24gdGhhdCBJMlJTIHdpbGwgbmVlZCBhIFlBTkcgc3Vi c3RhdGVtZW50IHRvIG1hcmsgb3V0IHRoZSBkYXRhDQo+IG9mIGludGVyZXN0IHRvIEkyUlMsIHBl cmhhcHMgd2l0aCBhIG5hbWUgYXR0YWNoZWQgc28gdGhhdCB0aGVyZSBjYW4gYmUNCj4gbXVsdGlw bGUgc2V0cyBvZiBJMlJTIGRhdGEsIHRvIHJlYWQsIHRvIHdyaXRlLCB0byBjb3B5IGFuZCBzbyBv biBhcyBhDQo+IG1lYW5pbmdmdWwgdW5pdDsgaXQgd291bGQgcHJvYmFibHkgYmUgYSBtaXN0YWtl IHRvIGNhbGwgdGhhdCBhIGRhdGFzdG9yZQ0KPiBnaXZlbiB0aGUgbW9yZSBzcGVjaWZpYyBtZWFu aW5nIHRoYXQgdGhhdCB0ZXJtIGhhcyBhY3F1aXJlZCBpbiBORVRDT05GLA0KPiBvZiAgYSB1bml0 IG9mIGNvbmZpZ3VyYXRpb24gZGF0YS4NCj4gDQo+IFRvbSBQZXRjaA0KPiANCj4gLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6aC5j b20+DQo+IFRvOiAiJ0FuZHkgQmllcm1hbiciIDxhbmR5QHl1bWF3b3Jrcy5jb20+OyAiJ1Rob21h cyBOYWRlYXUnIg0KPiA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+DQo+IENjOiAiJ0plZmZyZXkg SGFhcyciIDxqaGFhc0BwZnJjLm9yZz47IDxpMnJzQGlldGYub3JnPjsgIidKdWVyZ2VuDQo+IFNj aG9lbndhZWxkZXInIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsgIid0 LiBwZXRjaCciDQo+IDxpZXRmY0BidGNvbm5lY3QuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIE1h eSAwNywgMjAxNCAxMTo1NiBBTQ0KPiANCj4gDQo+ID4gQW5keToNCj4gPg0KPiA+DQo+ID4NCj4g PiBUaGFuayB5b3UgZm9yIGRldGFpbGVkIGRpc2N1c3Npb24gd2l0aCBUb20gUGV0Y2gvSmVmZi9K dWVyZ2VuL1RvbQ0KPiBOYWRlYXU6DQo+ID4NCj4gPg0KPiA+DQo+ID4gPHNuaXA+DQo+ID4NCj4g PiBJIGltYWdpbmUgSTJSUyB3aWxsIGJlIGNvbXBsZXRlbHkgc2VwYXJhdGUgZnJvbSBORVRDT05G IGFuZCBpdCBzaG91bGQNCj4gaGF2ZQ0KPiA+IGl0cyBvd24gZGF0YXN0b3JlIC0tIHNvICJpMnJz LWNvbmZpZyIgaXMgYXBwcm9wcmlhdGUgYmVjYXVzZSBJMlJTIGlzDQo+IHRoZQ0KPiA+IG9ubHkg cHJvdG9jb2wgdXNpbmcgdGhhdCBkYXRhc3RvcmUuIFRoZSBjb21iaW5lZCAib3BlcmF0aW9uYWwg c3RhdGUiDQo+IGlzIG5vdA0KPiA+IGVkaXRhYmxlLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFllcywg dGhhdCBtYWtlcyBzZW5zZS4gVGhlbiBpZiBhdCBzb21lIHBvaW50IGluIHRpbWUgeW91IHdhbnQg dG8gc2F2ZQ0KPiB0aGUNCj4gPiBydW5uaW5nIGNvbmZpZyAoaTJycyksIHRoZSBzeXN0ZW0gaGFz IHRvIGV4cGxpY2l0bHkgY29weSBpdCBvdmVyLiBCdXQNCj4gdW50aWwNCj4gPiB0aGVuLCBpdHMg c2VwYXJhdGUuICBUaGUgb25seSBxdWVzdGlvbiBpczogd2hhdCBpcyB0aGUgY29tcGxldGUNCj4g cnVubmluZw0KPiA+IGNvbmZpZyByZXByZXNlbnRlZCBhcz8gQW5kIHdoYXQgaWYgTmV0Y29uZiB3 YW50cyB0byBtb2RpZnkgdGhlIHJ1bm5pbmcNCj4gPiBjb25maWcgKGkuZS46IGFuZCB0aGUgUklC IGluIHBhcnRpY3VsYXIpPw0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYXQgY29weS10by1sb2NhbC1j b25maWcgZmVhdHVyZSB3b3VsZCBiZSBleHRyYSwgb3V0c2lkZSB0aGUgc2NvcGUgb2YNCj4gdGhl DQo+ID4gaTJycy1jb25maWcuDQo+ID4NCj4gPiA8L3NuaXA+DQo+ID4NCj4gPiAtLS0tLQ0KPiA+ DQo+ID4NCj4gPg0KPiA+IFdoeSBvbmx5IGlzIHRoZSBjb3B5LXRvLWxvY2FsLWNvbmZpZyBmZWF0 dXJlIG91dCBvZiBzY29wZSBmb3IgdGhlDQo+ID4gSTJycy1jb25maWc/ICAgSG93IGNhbiB0aGUg d29yayBiZSBpbnRlcm9wZXJhYmxlIGlmIHRoaXMgZmVhdHVyZQ0KPiAocmVxdWlyZWQNCj4gPiBv ciBvcHRpb25hbCkgZG9lcyBub3Qgd29yayB0aGUgc2FtZSBpbiBkaWZmZXJlbnQgdmVuZG9yJ3Mg Ym94ZXM/ICBJZg0KPiB0aGUNCj4gPiBpbXBsZW1lbnRhdGlvbnMgYXJlIGRpZmZlcmVudCwgdGhp cyBpcyBncmVhdCAoZGlmZmVyZW50aWF0ZWQgcHJvZHVjdHMNCj4gPQ0KPiA+IGdvb2QpOyBidXQg SU1ITyB0aGlzIGZlYXR1cmUgYWN0aW9ucyBoYXMgdG8gYmUgaW50ZXJvcGVyYWJsZS4gdGhhdCBp cw0KPiBnaXZlDQo+ID4gdGhlIHNhbWUgZWZmZWN0aXZlIHJlc3BvbnNlIGluIHRoZSBkaWZmZXJl bnQgdmVuZG9ycy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBDYW4geW91IGV4cGxhaW4gZnVydGhlcj8N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IDxzbmlwPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFJpZ2h0 LiBJZiB3ZSB0YWtlIHRoYXQgYXBwcm9hY2ggd2UgbmVlZCB0byBoYXZlIGEgd2F5IG9mIHRoZSBp MnJzDQo+ICJwcm90b2NvbCINCj4gPiB0byBzaWduYWwgdGhhdCB0aGUgY29uZmlnDQo+ID4NCj4g PiBuZWVkcyB0byBiZSBzYXZlZCAic29vbiIuICBUaGF0IGlzLCBpdHMgbm90IGRvbmUgaW4gcmVh bCB0aW1lLCBidXQNCj4gcmF0aGVyIGFzDQo+ID4gYSBiYWNrZ3JvdW5kIHByb2Nlc3MuDQo+ID4N Cj4gPiBJdHMgcHJvYmFibHkuIFRoaXMgY2FuIGVpdGhlciBiZSB0aHJvdWdoIGEgc2luZ2xlIGtl eXdvcmQgdGhhdCBpcw0KPiBhZGRlZA0KPiA+IHVuZGVyIHRoZSBpMnJzLWNvbmZpZyBzZWN0aW9u LCBvcg0KPiA+DQo+ID4gcGVyIGVsZW1lbnQgb3IgZXZlbiBwZXItZWxlbWVudCwgaWYgd2UgZGVj aWRlIHRvIGJlIG1vcmUgZ3JhbnVsYXIuDQo+ID4NCj4gPiA8L3NuaXA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4gSU1ITyBpdCBpcyBpbXBvcnRhbnQgdG8ga25vdyB3aGVuIHRoZSB3cml0ZSB0byBsb2Nh bC1jb25maWcgaXMgZG9uZQ0KPiBldmVuIGlmDQo+ID4gZG9uZSBpbiBiYWNrZ3JvdW5kLiAgIEFy ZSB5b3UgaW5kaWNhdGluZyB0aGVyZSBpcyBubw0KPiA+IHdyaXRlLWNvbmZpZy9hY2stY29tcGxl dGUtd3JpdGUgY29uZmlnIGludGVyYWN0aW9uPw0KPiA+DQo+ID4NCj4gPg0KPiA+IDxzbmlwPg0K PiA+DQo+ID4gWW91IHNlZW0gdG8gYmUgc3VnZ2VzdGluZyB0aGF0IHRoZSBJMlJTIGJlaGF2aW9y IG9mIGZvcmdldHRpbmcgYWxsDQo+IGluamVjdGVkDQo+ID4gc3RhdGUNCj4gPg0KPiA+IGlmIHRo ZSByb3V0ZXIgaGFwcGVucyB0byByZWJvb3QgaXMgbm90IHRoYXQgdXNlZnVsLCBhbmQgdGhlcmVm b3JlIGl0DQo+IG5lZWRzDQo+ID4gdG8gYmUNCj4gPg0KPiA+IHNhdmVkIGluIHRoZSBiYWNrZ3Jv dW5kIChiZXN0LWVmZm9ydCkuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSB0aGluayBpdCBpcyB1cCB0 byBhbGwgdGhlIEkyUlMgY2xpZW50cyB0byBhbHdheXMgYmUgYXJvdW5kIHRvDQo+IHJlY2VpdmUg c29tZQ0KPiA+DQo+ID4gc29ydCBvZiBhZ2VudC1yZWJvb3QgZXZlbnQsIGFuZCByZS1pbnN0YWxs IGFueSByZXF1aXJlZCBJMlJTIGNvbmZpZy4NCj4gPg0KPiA+IEkgY2FuJ3QgaW1hZ2luZSBhbnkg dXNlIGNhc2VzIHdoZXJlIHRoZSBvcGVyYXRvciB0aGlua3MgIkkgb25seSBuZWVkDQo+IHRvDQo+ ID4NCj4gPiBpbnN0YWxsIHRoaXMgUklCIGRhdGEgdW50aWwgdGhhdCByb3V0ZXIgYWNjaWRlbnRh bGx5IHJlYm9vdHMiLg0KPiA+DQo+ID4gPC9zbmlwPg0KPiA+DQo+ID4NCj4gPg0KPiA+IElmIHlv dSByZS1pbnN0YWxsIGFueSByZXF1aXJlZCBJMlJTIGNvbmZpZywgYXJlIHlvdSBzdXJlIHRoaXMg aXMgd2hhdA0KPiB0aGUNCj4gPiBJMlJTIGNsaWVudCB3YW50cz8NCj4gPg0KPiA+DQo+ID4NCj4g PiBTdWUNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gaTJycyBtYWlsaW5nIGxpc3QNCj4gaTJyc0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 0004F2BD48257CD3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSByYWlzZWQgYSBpc3N1ZSBhYm91 dCB0aGlzIGluIG5ldG1vZA0KV0csPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5zZWU6ICZuYnNwOzwvZm9udD48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMDk3MTYuaHRtbCI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9u ZXRtb2QvY3VycmVudC9tc2cwOTcxNi5odG1sPC9mb250PjwvYT4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+L2ZyYW5rPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+JnF1b3Q7aTJycyZxdW90OyAmbHQ7aTJycy1ib3VuY2VzQGlldGYub3JnJmd0OyDQtNPaDQoy MDE0LTA1LTA5IDAxOjQ1OjM0Ojxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFN1ZTxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIGFm cmFpZCBJIGNhbm5vdCBwYXJzZSB0aGlzIGUtbWFpbCB0byBzZWUgd2hlcmUgdGhlIHRleHQgaXMg eW91cnM8YnI+DQomZ3Q7IGFuZCB3aGVyZSBpdCBpcyBzb21ldGhpbmcgZWFybGllciBhbmQgd2hl cmUgdGhlIHF1ZXN0aW9ucyBhcmU8YnI+DQomZ3Q7IHVuYW5zd2VyZWQ6LSg8YnI+DQomZ3Q7IDxi cj4NCiZndDsgRGF0YXN0b3JlcyBpbiBORVRDT05GL1lBTkcgYXJlIGEgTkVUQ09ORiBjb25zdHJ1 Y3QgYW5kIGRlZmluZSBhIHNldA0Kb2Y8YnI+DQomZ3Q7IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRp b24uICZuYnNwO1lBTkcgaGFzIG5vIGNvbmNlcHQgb2Ygd2hlcmUgZGF0YQ0KaXMgb3IgaXRzPGJy Pg0KJmd0OyBwZXJzaXN0ZW5jZSBleGNlcHQgdG8gYSBsaW1pdGVkIGV4dGVudCB3aGVuIGl0IGlz IGFwcGx5aW5nIHZhbGlkYXRpb248YnI+DQomZ3Q7IGxvZ2ljLCBhcyBpbiBSRkM2MDIwIHM3LjUu MyAod2hpY2ggcHJvYmFibHkgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlDQppbjxicj4NCiZndDsg aXNvbGF0aW9uIC0gbXkgSS1EIG1pZ2h0IGhlbHApLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTbyBh IGRhdGFzdG9yZSBpcyBhIHNldCBvZiAnY29uZmlnIHRydWUnIGRhdGEgbm9kZXMgc3RvcmVkIHNv bWV3aGVyZS48YnI+DQomZ3Q7IE1vdmUgYXdheSBmcm9tIGNvbmZpZ3VyYXRpb24gYW5kIHRoZXJl IGlzIG5vIG90aGVyIGNvbmNlcHQsIGFwYXJ0DQpmcm9tPGJyPg0KJmd0OyBldmVyeXRoaW5nIGVs c2UsIGFsbCB0aGUgc3RhdGlzdGljcywgcm91dGluZyB0YWJsZXMgYW5kIHNvIG9uLiAmbmJzcDtI ZW5jZQ0KbXk8YnI+DQomZ3Q7IHN1Z2dlc3Rpb24gdGhhdCBJMlJTIHdpbGwgbmVlZCBhIFlBTkcg c3Vic3RhdGVtZW50IHRvIG1hcmsgb3V0IHRoZQ0KZGF0YTxicj4NCiZndDsgb2YgaW50ZXJlc3Qg dG8gSTJSUywgcGVyaGFwcyB3aXRoIGEgbmFtZSBhdHRhY2hlZCBzbyB0aGF0IHRoZXJlIGNhbg0K YmU8YnI+DQomZ3Q7IG11bHRpcGxlIHNldHMgb2YgSTJSUyBkYXRhLCB0byByZWFkLCB0byB3cml0 ZSwgdG8gY29weSBhbmQgc28gb24gYXMNCmE8YnI+DQomZ3Q7IG1lYW5pbmdmdWwgdW5pdDsgaXQg d291bGQgcHJvYmFibHkgYmUgYSBtaXN0YWtlIHRvIGNhbGwgdGhhdCBhIGRhdGFzdG9yZTxicj4N CiZndDsgZ2l2ZW4gdGhlIG1vcmUgc3BlY2lmaWMgbWVhbmluZyB0aGF0IHRoYXQgdGVybSBoYXMg YWNxdWlyZWQgaW4gTkVUQ09ORiw8YnI+DQomZ3Q7IG9mICZuYnNwO2EgdW5pdCBvZiBjb25maWd1 cmF0aW9uIGRhdGEuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvbSBQZXRjaDxicj4NCiZndDsgPGJy Pg0KJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KJmd0OyBGcm9tOiAmcXVv dDtTdXNhbiBIYXJlcyZxdW90OyAmbHQ7c2hhcmVzQG5kemguY29tJmd0Ozxicj4NCiZndDsgVG86 ICZxdW90OydBbmR5IEJpZXJtYW4nJnF1b3Q7ICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7OyAm cXVvdDsnVGhvbWFzDQpOYWRlYXUnJnF1b3Q7PGJyPg0KJmd0OyAmbHQ7dG5hZGVhdUBsdWNpZHZp c2lvbi5jb20mZ3Q7PGJyPg0KJmd0OyBDYzogJnF1b3Q7J0plZmZyZXkgSGFhcycmcXVvdDsgJmx0 O2poYWFzQHBmcmMub3JnJmd0OzsgJmx0O2kycnNAaWV0Zi5vcmcmZ3Q7Ow0KJnF1b3Q7J0p1ZXJn ZW48YnI+DQomZ3Q7IFNjaG9lbndhZWxkZXInJnF1b3Q7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGUmZ3Q7Ow0KJnF1b3Q7J3QuIHBldGNoJyZxdW90Ozxicj4NCiZndDsg Jmx0O2lldGZjQGJ0Y29ubmVjdC5jb20mZ3Q7PGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE1h eSAwNywgMjAxNCAxMTo1NiBBTTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg QW5keTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgVGhhbmsgeW91IGZvciBkZXRhaWxlZCBkaXNjdXNzaW9uIHdpdGggVG9tIFBldGNo L0plZmYvSnVlcmdlbi9Ub208YnI+DQomZ3Q7IE5hZGVhdTo8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O3NuaXAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgaW1hZ2luZSBJMlJTIHdpbGwgYmUgY29tcGxldGVs eSBzZXBhcmF0ZSBmcm9tIE5FVENPTkYgYW5kIGl0DQpzaG91bGQ8YnI+DQomZ3Q7IGhhdmU8YnI+ DQomZ3Q7ICZndDsgaXRzIG93biBkYXRhc3RvcmUgLS0gc28gJnF1b3Q7aTJycy1jb25maWcmcXVv dDsgaXMgYXBwcm9wcmlhdGUNCmJlY2F1c2UgSTJSUyBpczxicj4NCiZndDsgdGhlPGJyPg0KJmd0 OyAmZ3Q7IG9ubHkgcHJvdG9jb2wgdXNpbmcgdGhhdCBkYXRhc3RvcmUuIFRoZSBjb21iaW5lZCAm cXVvdDtvcGVyYXRpb25hbA0Kc3RhdGUmcXVvdDs8YnI+DQomZ3Q7IGlzIG5vdDxicj4NCiZndDsg Jmd0OyBlZGl0YWJsZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgWWVzLCB0aGF0IG1ha2VzIHNlbnNlLiBUaGVuIGlmIGF0IHNvbWUg cG9pbnQgaW4gdGltZSB5b3Ugd2FudA0KdG8gc2F2ZTxicj4NCiZndDsgdGhlPGJyPg0KJmd0OyAm Z3Q7IHJ1bm5pbmcgY29uZmlnIChpMnJzKSwgdGhlIHN5c3RlbSBoYXMgdG8gZXhwbGljaXRseSBj b3B5IGl0IG92ZXIuDQpCdXQ8YnI+DQomZ3Q7IHVudGlsPGJyPg0KJmd0OyAmZ3Q7IHRoZW4sIGl0 cyBzZXBhcmF0ZS4gJm5ic3A7VGhlIG9ubHkgcXVlc3Rpb24gaXM6IHdoYXQgaXMgdGhlIGNvbXBs ZXRlPGJyPg0KJmd0OyBydW5uaW5nPGJyPg0KJmd0OyAmZ3Q7IGNvbmZpZyByZXByZXNlbnRlZCBh cz8gQW5kIHdoYXQgaWYgTmV0Y29uZiB3YW50cyB0byBtb2RpZnkgdGhlDQpydW5uaW5nPGJyPg0K Jmd0OyAmZ3Q7IGNvbmZpZyAoaS5lLjogYW5kIHRoZSBSSUIgaW4gcGFydGljdWxhcik/PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRo YXQgY29weS10by1sb2NhbC1jb25maWcgZmVhdHVyZSB3b3VsZCBiZSBleHRyYSwgb3V0c2lkZSB0 aGUNCnNjb3BlIG9mPGJyPg0KJmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsgaTJycy1jb25maWcuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZsdDsvc25pcCZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgLS0tLS08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2h5IG9ubHkgaXMgdGhlIGNvcHktdG8tbG9jYWwtY29u ZmlnIGZlYXR1cmUgb3V0IG9mIHNjb3BlIGZvcg0KdGhlPGJyPg0KJmd0OyAmZ3Q7IEkycnMtY29u ZmlnPyAmbmJzcDsgSG93IGNhbiB0aGUgd29yayBiZSBpbnRlcm9wZXJhYmxlIGlmIHRoaXMNCmZl YXR1cmU8YnI+DQomZ3Q7IChyZXF1aXJlZDxicj4NCiZndDsgJmd0OyBvciBvcHRpb25hbCkgZG9l cyBub3Qgd29yayB0aGUgc2FtZSBpbiBkaWZmZXJlbnQgdmVuZG9yJ3MgYm94ZXM/DQombmJzcDtJ Zjxicj4NCiZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9ucyBhcmUgZGlmZmVy ZW50LCB0aGlzIGlzIGdyZWF0IChkaWZmZXJlbnRpYXRlZA0KcHJvZHVjdHM8YnI+DQomZ3Q7ID08 YnI+DQomZ3Q7ICZndDsgZ29vZCk7IGJ1dCBJTUhPIHRoaXMgZmVhdHVyZSBhY3Rpb25zIGhhcyB0 byBiZSBpbnRlcm9wZXJhYmxlLg0KdGhhdCBpczxicj4NCiZndDsgZ2l2ZTxicj4NCiZndDsgJmd0 OyB0aGUgc2FtZSBlZmZlY3RpdmUgcmVzcG9uc2UgaW4gdGhlIGRpZmZlcmVudCB2ZW5kb3JzLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBDYW4geW91IGV4cGxhaW4gZnVydGhlcj88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O3NuaXAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFJpZ2h0LiBJZiB3ZSB0YWtlIHRoYXQgYXBwcm9hY2ggd2UgbmVlZCB0byBoYXZlIGEgd2F5 IG9mIHRoZQ0KaTJyczxicj4NCiZndDsgJnF1b3Q7cHJvdG9jb2wmcXVvdDs8YnI+DQomZ3Q7ICZn dDsgdG8gc2lnbmFsIHRoYXQgdGhlIGNvbmZpZzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBuZWVkcyB0byBiZSBzYXZlZCAmcXVvdDtzb29uJnF1b3Q7LiAmbmJzcDtUaGF0IGlzLCBpdHMg bm90IGRvbmUNCmluIHJlYWwgdGltZSwgYnV0PGJyPg0KJmd0OyByYXRoZXIgYXM8YnI+DQomZ3Q7 ICZndDsgYSBiYWNrZ3JvdW5kIHByb2Nlc3MuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IEl0cyBwcm9iYWJseS4gVGhpcyBjYW4gZWl0aGVyIGJlIHRocm91Z2ggYSBzaW5nbGUga2V5d29y ZCB0aGF0DQppczxicj4NCiZndDsgYWRkZWQ8YnI+DQomZ3Q7ICZndDsgdW5kZXIgdGhlIGkycnMt Y29uZmlnIHNlY3Rpb24sIG9yPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHBlciBlbGVt ZW50IG9yIGV2ZW4gcGVyLWVsZW1lbnQsIGlmIHdlIGRlY2lkZSB0byBiZSBtb3JlIGdyYW51bGFy Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7L3NuaXAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElNSE8gaXQg aXMgaW1wb3J0YW50IHRvIGtub3cgd2hlbiB0aGUgd3JpdGUgdG8gbG9jYWwtY29uZmlnIGlzDQpk b25lPGJyPg0KJmd0OyBldmVuIGlmPGJyPg0KJmd0OyAmZ3Q7IGRvbmUgaW4gYmFja2dyb3VuZC4g Jm5ic3A7IEFyZSB5b3UgaW5kaWNhdGluZyB0aGVyZSBpcyBubzxicj4NCiZndDsgJmd0OyB3cml0 ZS1jb25maWcvYWNrLWNvbXBsZXRlLXdyaXRlIGNvbmZpZyBpbnRlcmFjdGlvbj88YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmx0O3Nu aXAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlvdSBzZWVtIHRvIGJlIHN1Z2dl c3RpbmcgdGhhdCB0aGUgSTJSUyBiZWhhdmlvciBvZiBmb3JnZXR0aW5nDQphbGw8YnI+DQomZ3Q7 IGluamVjdGVkPGJyPg0KJmd0OyAmZ3Q7IHN0YXRlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IGlmIHRoZSByb3V0ZXIgaGFwcGVucyB0byByZWJvb3QgaXMgbm90IHRoYXQgdXNlZnVsLCBh bmQgdGhlcmVmb3JlDQppdDxicj4NCiZndDsgbmVlZHM8YnI+DQomZ3Q7ICZndDsgdG8gYmU8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgc2F2ZWQgaW4gdGhlIGJhY2tncm91bmQgKGJlc3Qt ZWZmb3J0KS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgSSB0aGluayBpdCBpcyB1cCB0byBhbGwgdGhlIEkyUlMgY2xpZW50cyB0byBh bHdheXMgYmUgYXJvdW5kDQp0bzxicj4NCiZndDsgcmVjZWl2ZSBzb21lPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IHNvcnQgb2YgYWdlbnQtcmVib290IGV2ZW50LCBhbmQgcmUtaW5zdGFs bCBhbnkgcmVxdWlyZWQgSTJSUw0KY29uZmlnLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBJIGNhbid0IGltYWdpbmUgYW55IHVzZSBjYXNlcyB3aGVyZSB0aGUgb3BlcmF0b3IgdGhpbmtz ICZxdW90O0kNCm9ubHkgbmVlZDxicj4NCiZndDsgdG88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgaW5zdGFsbCB0aGlzIFJJQiBkYXRhIHVudGlsIHRoYXQgcm91dGVyIGFjY2lkZW50YWxs eSByZWJvb3RzJnF1b3Q7Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbHQ7L3NuaXAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IElmIHlvdSByZS1pbnN0YWxsIGFueSByZXF1aXJlZCBJMlJTIGNvbmZpZywgYXJlIHlv dSBzdXJlIHRoaXMNCmlzIHdoYXQ8YnI+DQomZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyBJMlJTIGNs aWVudCB3YW50cz88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgU3VlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBp MnJzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgaTJyc0BpZXRmLm9yZzxicj4NCiZndDsgPC9mb250 PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM+ PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ky cnM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg0K PGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0 dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVu dGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNz ZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9z dXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu ICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUg aXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0004F2BD48257CD3_=-- From nobody Thu May 8 21:52: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 AD6BC1A01D5 for ; Thu, 8 May 2014 21:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] 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 ihzQX0QUNwx7 for ; Thu, 8 May 2014 21:52:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF21A01C7 for ; Thu, 8 May 2014 21:52:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=98.174.216.153; From: "Susan Hares" To: "'t.petch'" References: <20140501160952.GA31629@pfrc> <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> In-Reply-To: <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> Date: Fri, 9 May 2014 00:52:40 -0400 Message-ID: <006d01cf6b42$8258e070$870aa150$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIiInceux1/icGCg1CUZyO5f86QKgIetHVcA4TL51EBHeXw7wDo5H7bASQ7P90CDXSWDALMjbjgAtApag0BU9wuzAHEWPffAc95QUABRK3/3AIlYtkJAuWItq4CPGlTtQKZTOJ0AVNv9tmZgsBE0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Up7KLyvzqZXkaV9zYg5bnuaPWY4 Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 09 May 2014 04:52:54 -0000 Tom: Thank you for your note of your preference email reading, and I've also read earlier of your need for html compliant i2rs notes rather than a pdf form. Please let me know if your format issues regarding email have been addressed by the format of this email. Thank you for your comments on yang. My questions were: 1) Why only is the copy-to-local-config feature out of scope for the I2rs-config? 2) Are you indicating that there is no write-config/ack and complete-write config interactions? My questions did not have to do with Yang's functionality, but with your statements/assumptions with I2RS. If you answered these questions, please send email clip (private/public). -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Thursday, May 08, 2014 1:46 PM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org Subject: Re: [i2rs] edit-data substatement Re: Operational State Sue I am afraid I cannot parse this e-mail to see where the text is yours and where it is something earlier and where the questions are unanswered:-( Datastores in NETCONF/YANG are a NETCONF construct and define a set of configuration information. YANG has no concept of where data is or its persistence except to a limited extent when it is applying validation logic, as in RFC6020 s7.5.3 (which probably does not make much sense in isolation - my I-D might help). So a datastore is a set of 'config true' data nodes stored somewhere. Move away from configuration and there is no other concept, apart from everything else, all the statistics, routing tables and so on. Hence my suggestion that I2RS will need a YANG substatement to mark out the data of interest to I2RS, perhaps with a name attached so that there can be multiple sets of I2RS data, to read, to write, to copy and so on as a meaningful unit; it would probably be a mistake to call that a datastore given the more specific meaning that that term has acquired in NETCONF, of a unit of configuration data. Tom Petch ----- Original Message ----- From: "Susan Hares" To: "'Andy Bierman'" ; "'Thomas Nadeau'" Cc: "'Jeffrey Haas'" ; ; "'Juergen Schoenwaelder'" ; "'t. petch'" Sent: Wednesday, May 07, 2014 11:56 AM > Andy: > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom Nadeau: > > > > > > I imagine I2RS will be completely separate from NETCONF and it should have > its own datastore -- so "i2rs-config" is appropriate because I2RS is the > only protocol using that datastore. The combined "operational state" is not > editable. > > > > Yes, that makes sense. Then if at some point in time you want to save the > running config (i2rs), the system has to explicitly copy it over. But until > then, its separate. The only question is: what is the complete running > config represented as? And what if Netconf wants to modify the running > config (i.e.: and the RIB in particular)? > > > > That copy-to-local-config feature would be extra, outside the scope of the > i2rs-config. > > > > ----- > > > > Why only is the copy-to-local-config feature out of scope for the > I2rs-config? How can the work be interoperable if this feature (required > or optional) does not work the same in different vendor's boxes? If the > implementations are different, this is great (differentiated products = > good); but IMHO this feature actions has to be interoperable. that is give > the same effective response in the different vendors. > > > > Can you explain further? > > > > > > > > > Right. If we take that approach we need to have a way of the i2rs "protocol" > to signal that the config > > needs to be saved "soon". That is, its not done in real time, but rather as > a background process. > > Its probably. This can either be through a single keyword that is added > under the i2rs-config section, or > > per element or even per-element, if we decide to be more granular. > > > > > > IMHO it is important to know when the write to local-config is done even if > done in background. Are you indicating there is no > write-config/ack-complete-write config interaction? > > > > > > You seem to be suggesting that the I2RS behavior of forgetting all injected > state > > if the router happens to reboot is not that useful, and therefore it needs > to be > > saved in the background (best-effort). > > > > I think it is up to all the I2RS clients to always be around to receive some > > sort of agent-reboot event, and re-install any required I2RS config. > > I can't imagine any use cases where the operator thinks "I only need to > > install this RIB data until that router accidentally reboots". > > > > > > If you re-install any required I2RS config, are you sure this is what the > I2RS client wants? > > > > Sue > From nobody Fri May 9 03:19: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 770921A0275 for ; Fri, 9 May 2014 03:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 qIN8vVHrnB3h for ; Fri, 9 May 2014 03:19:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD1751A024F for ; Fri, 9 May 2014 03:19:11 -0700 (PDT) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 10:19:05 +0000 Message-ID: <010401cf6b6f$c6cb7c40$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> <20140508191733.GA75343@elstar.local> Date: Fri, 9 May 2014 11:16:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: DBXPR07CA013.eurprd07.prod.outlook.com (10.141.8.171) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51914003)(13464003)(51704005)(24454002)(189002)(199002)(31966008)(62966002)(61296002)(74502001)(23756003)(88136002)(76482001)(46102001)(50466002)(4396001)(21056001)(44736004)(89996001)(50226001)(92566001)(79102001)(44716002)(74662001)(81542001)(101416001)(33646001)(62236002)(47776003)(14496001)(84392001)(83322001)(99396002)(19580395003)(80022001)(19580405001)(77982001)(66066001)(64706001)(87286001)(81342001)(92726001)(76176999)(20776003)(86362001)(87976001)(77156001)(42186004)(93916002)(81816999)(81686999)(85852003)(83072002)(50986999)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/RSRJY7oCKYKwZOqgze2Yqy9P2WY Cc: 'Jeffrey Haas' , i2rs@ietf.org, Susan Hares Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 09 May 2014 10:19:14 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Susan Hares" ; "'Jeffrey Haas'" ; Sent: Thursday, May 08, 2014 8:17 PM > On Thu, May 08, 2014 at 06:45:34PM +0100, t. petch wrote: > > Sue > > > > I am afraid I cannot parse this e-mail to see where the text is yours > > and where it is something earlier and where the questions are > > unanswered:-( > > > > Datastores in NETCONF/YANG are a NETCONF construct and define a set of > > configuration information. YANG has no concept of where data is or its > > persistence except to a limited extent when it is applying validation > > logic, as in RFC6020 s7.5.3 (which probably does not make much sense in > > isolation - my I-D might help). > > > > So a datastore is a set of 'config true' data nodes stored somewhere. > > Move away from configuration and there is no other concept, apart from > > everything else, all the statistics, routing tables and so on. Hence my > > suggestion that I2RS will need a YANG substatement to mark out the data > > of interest to I2RS, perhaps with a name attached so that there can be > > multiple sets of I2RS data, to read, to write, to copy and so on as a > > meaningful unit; it would probably be a mistake to call that a datastore > > given the more specific meaning that that term has acquired in NETCONF, > > of a unit of configuration data. > > Tom, > > RFC 6241 says: > > o datastore: A conceptual place to store and access information. A > datastore might be implemented, for example, using files, a > database, flash memory locations, or combinations thereof. > > o configuration datastore: The datastore holding the complete set of > configuration data that is required to get a device from its > initial default state into a desired operational state. > > Note the distinction between a datastore and a configuration > datastore. Juergen Thanks for the correction. I note that the YANG RFC does not draw the distinction and that all NETCONF RPC refer to configuration datastores so while we could use datastore unqualified to mean something different, such as a set of I2RS data, I would rather avoid that usage. Tom Petch > /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 Fri May 9 03:19:18 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 13CBA1A0277 for ; Fri, 9 May 2014 03:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 hU5j6o4_duQH for ; Fri, 9 May 2014 03:19:11 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) by ietfa.amsl.com (Postfix) with ESMTP id CDD931A023A for ; Fri, 9 May 2014 03:19:10 -0700 (PDT) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 10:19:04 +0000 Message-ID: <010301cf6b6f$c655fe20$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares References: <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> <006d01cf6b42$8258e070$870aa150$@ndzh.com> Date: Fri, 9 May 2014 11:13:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: DBXPR07CA013.eurprd07.prod.outlook.com (10.141.8.171) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(13464003)(51704005)(189002)(199002)(51444003)(31966008)(62966002)(61296002)(74502001)(23756003)(88136002)(76482001)(46102001)(50466002)(4396001)(21056001)(44736004)(89996001)(50226001)(92566001)(79102001)(44716002)(74662001)(81542001)(101416001)(33646001)(62236002)(47776003)(14496001)(84392001)(83322001)(99396002)(19580395003)(80022001)(19580405001)(77982001)(66066001)(64706001)(87286001)(81342001)(92726001)(76176999)(20776003)(86362001)(87976001)(77156001)(42186004)(93916002)(81816999)(81686999)(85852003)(83072002)(50986999)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ERlS7oUS3Hohqjkn0_AdzbbID74 Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 09 May 2014 10:19:15 -0000 ---- Original Message ----- From: "Susan Hares" To: "'t.petch'" Cc: "'Jeffrey Haas'" ; Sent: Friday, May 09, 2014 5:52 AM > Tom: > > Thank you for your note of your preference email reading, and I've also read > earlier of your need for html compliant i2rs notes rather than a pdf form. > Please let me know if your format issues regarding email have been addressed > by the format of this email. Thank you for your comments on yang. > > My questions were: 1) Why only is the copy-to-local-config feature out of > scope for the I2rs-config? 2) Are you indicating that there is no > write-config/ack and complete-write config interactions? My questions did > not have to do with Yang's functionality, but with your > statements/assumptions with I2RS. If you answered these questions, please > send email clip (private/public). I think that we are in uncharted territory. My thanks to Juergen for correcting my terminology. The NETCONF RFC does define datastore as distinct from configuration datastore but then defines all its operations in terms of configuration datastores while the YANG RFC uses datastore without qualification but clearly means configuration ones. Um. So configuration datastores only contain 'config true' nodes and contain a complete set thereof, in accordance with a schema tree. is one such datastore, along with and user-defined ones; these can be copied in their entirety and the nature of them means that I see it as practical for a device to lock them against any changes during a copy - the copy is atomic, no acknowledgements needed. The rest of the data in the device, state, is not a datastore, cannot be edited, cannot be copied can only be (selectively) gotten, NETCONF get RPC, and is not because that is a term with a special meaning, of a specific configuration datastore. Likewise 'config' is a term with special meaning of what goes into a configuration datastore (so I am uncertain what is meant by config or running in the context of I2RS). So that is the model at the back of my mind, which I find hard to let go of. If I2RS wants to edit state (eg the RIB entries learnt from BGP), which the use-cases clearly describe, then that is a new ballgame, needing, if YANG is used, a new substatement to mark those data nodes and a new protocol, perhaps a NETCONF extension, to write to them. Or else we do not use the existing data models as a base, and create new ones with only data nodes of interest to I2RS in them in whatever language we choose, perhaps a new protocol (quite easily done). If I2RS wants to operate on sets of data (I would avoid the term datastores because I still see it as a a technical term with a special meaning in Ops Area), and I am uncertain whether or not it should - the use cases seem silent on this - well that is another new ballgame. There is nothing in NETCONF or YANG to guide us here, we would need to tag (e.g. YANG substatement) the data nodes that form such a dataset, or datasets, and define new protocols, perhaps extensions to NETCONF, to copy those datasets from somewhere to somewhere. This could be fraught on a practical level. My experience of routers is that the storage used for state, eg the full BGP table, is greater than that used for (NETCONF type) config (typically semi-permanent storage), so there might be nowhere for the state to be copied to on the device, nowhere that survives a restart. Likewise, in a parallel context, one trick I play is an SNMP get-next on RMON tables - it never ends, because new entries are being added to the tables faster than the get-next can retrieve them! Would an attempt to copy the full BGP table meet the same fate? I do not know, but it is these practical thoughts that colour my thinking which is perhaps why I think that I2RS does not want a copy function because it would be a challenge to implement - but I would be happy to be corrected by manufacturers of high-end routers. Um. Tom Petch > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, May 08, 2014 1:46 PM > To: Susan Hares > Cc: 'Jeffrey Haas'; i2rs@ietf.org > Subject: Re: [i2rs] edit-data substatement Re: Operational State > > Sue > > I am afraid I cannot parse this e-mail to see where the text is yours and > where it is something earlier and where the questions are unanswered:-( > > Datastores in NETCONF/YANG are a NETCONF construct and define a set of > configuration information. YANG has no concept of where data is or its > persistence except to a limited extent when it is applying validation logic, > as in RFC6020 s7.5.3 (which probably does not make much sense in isolation - > my I-D might help). > > So a datastore is a set of 'config true' data nodes stored somewhere. > Move away from configuration and there is no other concept, apart from > everything else, all the statistics, routing tables and so on. Hence my > suggestion that I2RS will need a YANG substatement to mark out the data of > interest to I2RS, perhaps with a name attached so that there can be multiple > sets of I2RS data, to read, to write, to copy and so on as a meaningful > unit; it would probably be a mistake to call that a datastore given the more > specific meaning that that term has acquired in NETCONF, of a unit of > configuration data. > > Tom Petch > > ----- Original Message ----- > From: "Susan Hares" > To: "'Andy Bierman'" ; "'Thomas Nadeau'" > > Cc: "'Jeffrey Haas'" ; ; "'Juergen > Schoenwaelder'" ; "'t. petch'" > > Sent: Wednesday, May 07, 2014 11:56 AM > > > > Andy: > > > > > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom > Nadeau: > > > > > > > > > > > > I imagine I2RS will be completely separate from NETCONF and it should > have > > its own datastore -- so "i2rs-config" is appropriate because I2RS is > the > > only protocol using that datastore. The combined "operational state" > is not > > editable. > > > > > > > > Yes, that makes sense. Then if at some point in time you want to save > the > > running config (i2rs), the system has to explicitly copy it over. But > until > > then, its separate. The only question is: what is the complete > running > > config represented as? And what if Netconf wants to modify the running > > config (i.e.: and the RIB in particular)? > > > > > > > > That copy-to-local-config feature would be extra, outside the scope of > the > > i2rs-config. > > > > > > > > ----- > > > > > > > > Why only is the copy-to-local-config feature out of scope for the > > I2rs-config? How can the work be interoperable if this feature > (required > > or optional) does not work the same in different vendor's boxes? If > the > > implementations are different, this is great (differentiated products > = > > good); but IMHO this feature actions has to be interoperable. that is > give > > the same effective response in the different vendors. > > > > > > > > Can you explain further? > > > > > > > > > > > > > > > > > > Right. If we take that approach we need to have a way of the i2rs > "protocol" > > to signal that the config > > > > needs to be saved "soon". That is, its not done in real time, but > rather as > > a background process. > > > > Its probably. This can either be through a single keyword that is > added > > under the i2rs-config section, or > > > > per element or even per-element, if we decide to be more granular. > > > > > > > > > > > > IMHO it is important to know when the write to local-config is done > even if > > done in background. Are you indicating there is no > > write-config/ack-complete-write config interaction? > > > > > > > > > > > > You seem to be suggesting that the I2RS behavior of forgetting all > injected > > state > > > > if the router happens to reboot is not that useful, and therefore it > needs > > to be > > > > saved in the background (best-effort). > > > > > > > > I think it is up to all the I2RS clients to always be around to > receive some > > > > sort of agent-reboot event, and re-install any required I2RS config. > > > > I can't imagine any use cases where the operator thinks "I only need > to > > > > install this RIB data until that router accidentally reboots". > > > > > > > > > > > > If you re-install any required I2RS config, are you sure this is what > the > > I2RS client wants? > > > > > > > > Sue > > > > From nobody Fri May 9 04:18: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 9E5531A0283 for ; Fri, 9 May 2014 04:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 DwafuVHrUnsR for ; Fri, 9 May 2014 04:18:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id EFF641A0277 for ; Fri, 9 May 2014 04:18:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 934BC6DB; Fri, 9 May 2014 13:17:59 +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 zkEnvJTxtaif; Fri, 9 May 2014 13:17:59 +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; Fri, 9 May 2014 13:17:59 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E65902002C; Fri, 9 May 2014 13:17:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UQy3kW1uJ74W; Fri, 9 May 2014 13:17:58 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 822DD20013; Fri, 9 May 2014 13:17:57 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id AD2FC2CCCA43; Fri, 9 May 2014 13:17:56 +0200 (CEST) Date: Fri, 9 May 2014 13:17:56 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20140509111756.GA77358@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "t. petch" , Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org References: <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359ED2B5BE5@lucidvision.com> <003101cf69e3$07e84930$17b8db90$@ndzh.com> <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> <20140508191733.GA75343@elstar.local> <010401cf6b6f$c6cb7c40$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010401cf6b6f$c6cb7c40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4IFpkKKKYC6LnjhqKSJf0J9ZkV8 Cc: 'Jeffrey Haas' , i2rs@ietf.org, Susan Hares Subject: Re: [i2rs] edit-data substatement Re: Operational State 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: Fri, 09 May 2014 11:18:07 -0000 On Fri, May 09, 2014 at 11:16:21AM +0100, t. petch wrote: > > > > Tom, > > > > RFC 6241 says: > > > > o datastore: A conceptual place to store and access information. > A > > datastore might be implemented, for example, using files, a > > database, flash memory locations, or combinations thereof. > > > > o configuration datastore: The datastore holding the complete set > of > > configuration data that is required to get a device from its > > initial default state into a desired operational state. > > > > Note the distinction between a datastore and a configuration > > datastore. > > Juergen > > Thanks for the correction. I note that the YANG RFC does not draw the > distinction and that all NETCONF RPC refer to configuration datastores > so while we could use datastore unqualified to mean something different, > such as a set of I2RS data, I would rather avoid that usage. > All I can tell is that N/Y documents try to make a distinction between the concept of a datastore and a configuration datastore. The word datastore shows up 13 times in RFC 6020 and in a number of the occurances the context is rather clear whether a configuration datastore or a general datastore is meant I think. But yes, the YANG RFC might not have gotton the wording right everywhere. That said, I believe at least one widely deployed commercial implementation supports the notion of non-configuration datastores. But your mileage might vary. /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 Fri May 9 11:22: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 D9CB01A00D7; Fri, 9 May 2014 11:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 IQ4qkVkxg6rA; Fri, 9 May 2014 11:22:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) by ietfa.amsl.com (Postfix) with ESMTP id 833D81A00B4; Fri, 9 May 2014 11:22:36 -0700 (PDT) Received: from AMXPRD0310HT005.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 18:22:29 +0000 Message-ID: <005001cf6bb3$4e8fd200$4001a8c0@gateway.2wire.net> From: t.petch To: References: <20140501171442.GA32492@pfrc> <20140501175741.GB32492@pfrc> <051501cf65e9$0fd77ec0$4001a8c0@gateway.2wire.net> <20140502154036.GD17078@pfrc> <20140502160942.GA36708@elstar.jacobs.jacobs-university.de> <62922728-11F8-4BB8-877E-7E27FB8A8418@lucidvision.com> <90DF56F5-1061-4E77-A518-C359 <00b201cf6ae5$57631500$4001a8c0@gateway.2wire.net> Date: Fri, 9 May 2014 19:20:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: DBXPR07CA012.eurprd07.prod.outlook.com (10.141.8.170) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377424004)(377454003)(51704005)(189002)(199002)(54094003)(81816999)(47136003)(85852003)(81342001)(47776003)(61296002)(92566001)(81542001)(77156001)(21056001)(80022001)(83072002)(87286001)(62966002)(15202345003)(14496001)(89996001)(50466002)(74662001)(64706001)(20776003)(44736004)(84392001)(50226001)(15975445006)(48336001)(81686999)(4396001)(88136002)(83322001)(66066001)(50986999)(76176999)(62236002)(79102001)(92726001)(19580405001)(86362001)(77982001)(46102001)(44716002)(99396002)(23696002)(33646001)(19580395003)(93916002)(101416001)(74502001)(42186004)(87976001)(31966008)(76482001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:AMXPRD0310HT005.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/bfImmSpiYSIg5sbiSiiissYOVSA Cc: 'Jeffrey Haas' , i2rs@ietf.org, i2rs , Susan Hares Subject: Re: [i2rs] edit-data substatement Re: Operational State 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, 09 May 2014 18:22:41 -0000 ----- Original Message ----- From: To: "t.petch" Cc: ; "i2rs" ; "'Jeffrey Haas'" ; "Susan Hares" Sent: Friday, May 09, 2014 1:54 AM Subject: Re: [i2rs] edit-data substatement Re: Operational State > I have raised a issue about this in netmod WG, > see: http://www.ietf.org/mail-archive/web/netmod/current/msg09716.html > /frank I see. I have speculated on something similar for I2RS, to be able to group meaningful sets of data, into datasets, perhaps with an optional name assuming that once we move away from the 'config true' dataset/datastore, then the floodgates are open and we are likely to want many such datasets. But I disagree that YANG should get into datastores of any kind; where this logical collection of data is copied to and from currently rests with NETCONF and that seems right, that the copy function, not the schema tree, specifies the two localities as part of the protocol, the schema tree specifies what the data set is. There are other issues, about how much sense it makes to have this set of data. The 'config true' dataset does make sense, it is a logical whole, what it takes to get a box up and running, in a way that no other dataset I can think of does. It may make sense to have an easy to read set of data for I2RS, so perhaps a new YANG substatement for data nodes to identify this and a get-i2rs function to go with it, but writing it back seems fraught with potential pitfalls. So underneath this, I wonder if a copy function makes any sense for I2RS because there is no meaningful set of data. Use cases would help (have you got any?). I have yet to see anyhing in the current I-Ds that requires a copy function. Tom Petch > "i2rs" дÓÚ 2014-05-09 01:45:34: > > > > > > Sue > > > > I am afraid I cannot parse this e-mail to see where the text is yours > > and where it is something earlier and where the questions are > > unanswered:-( > > > > Datastores in NETCONF/YANG are a NETCONF construct and define a set of > > configuration information. YANG has no concept of where data is or its > > persistence except to a limited extent when it is applying validation > > logic, as in RFC6020 s7.5.3 (which probably does not make much sense in > > isolation - my I-D might help). > > > > So a datastore is a set of 'config true' data nodes stored somewhere. > > Move away from configuration and there is no other concept, apart from > > everything else, all the statistics, routing tables and so on. Hence my > > suggestion that I2RS will need a YANG substatement to mark out the data > > of interest to I2RS, perhaps with a name attached so that there can be > > multiple sets of I2RS data, to read, to write, to copy and so on as a > > meaningful unit; it would probably be a mistake to call that a datastore > > given the more specific meaning that that term has acquired in NETCONF, > > of a unit of configuration data. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Susan Hares" > > To: "'Andy Bierman'" ; "'Thomas Nadeau'" > > > > Cc: "'Jeffrey Haas'" ; ; "'Juergen > > Schoenwaelder'" ; "'t. petch'" > > > > Sent: Wednesday, May 07, 2014 11:56 AM > > > > > > > Andy: > > > > > > > > > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom > > Nadeau: > > > > > > > > > > > > > > > > > > I imagine I2RS will be completely separate from NETCONF and it should > > have > > > its own datastore -- so "i2rs-config" is appropriate because I2RS is > > the > > > only protocol using that datastore. The combined "operational state" > > is not > > > editable. > > > > > > > > > > > > Yes, that makes sense. Then if at some point in time you want to save > > the > > > running config (i2rs), the system has to explicitly copy it over. But > > until > > > then, its separate. The only question is: what is the complete > > running > > > config represented as? And what if Netconf wants to modify the running > > > config (i.e.: and the RIB in particular)? > > > > > > > > > > > > That copy-to-local-config feature would be extra, outside the scope of > > the > > > i2rs-config. > > > > > > > > > > > > ----- > > > > > > > > > > > > Why only is the copy-to-local-config feature out of scope for the > > > I2rs-config? How can the work be interoperable if this feature > > (required > > > or optional) does not work the same in different vendor's boxes? If > > the > > > implementations are different, this is great (differentiated products > > = > > > good); but IMHO this feature actions has to be interoperable. that is > > give > > > the same effective response in the different vendors. > > > > > > > > > > > > Can you explain further? > > > > > > > > > > > > > > > > > > > > > > > > > > > Right. If we take that approach we need to have a way of the i2rs > > "protocol" > > > to signal that the config > > > > > > needs to be saved "soon". That is, its not done in real time, but > > rather as > > > a background process. > > > > > > Its probably. This can either be through a single keyword that is > > added > > > under the i2rs-config section, or > > > > > > per element or even per-element, if we decide to be more granular. > > > > > > > > > > > > > > > > > > IMHO it is important to know when the write to local-config is done > > even if > > > done in background. Are you indicating there is no > > > write-config/ack-complete-write config interaction? > > > > > > > > > > > > > > > > > > You seem to be suggesting that the I2RS behavior of forgetting all > > injected > > > state > > > > > > if the router happens to reboot is not that useful, and therefore it > > needs > > > to be > > > > > > saved in the background (best-effort). > > > > > > > > > > > > I think it is up to all the I2RS clients to always be around to > > receive some > > > > > > sort of agent-reboot event, and re-install any required I2RS config. > > > > > > I can't imagine any use cases where the operator thinks "I only need > > to > > > > > > install this RIB data until that router accidentally reboots". > > > > > > > > > > > > > > > > > > If you re-install any required I2RS config, are you sure this is what > > the > > > I2RS client wants? > > > > > > > > > > > > Sue > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > From nobody Mon May 12 07:04: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 8FB011A0711 for ; Mon, 12 May 2014 07:04:11 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 D18VFEWk2L6o for ; Mon, 12 May 2014 07:04:10 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 015451A071A for ; Mon, 12 May 2014 07:04:06 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hy4so7820750vcb.25 for ; Mon, 12 May 2014 07:04:00 -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:from:date :message-id:subject:to:cc:content-type; bh=LMkimW4Hg77ElYv78U8ZF5eJ/lgQBmiw/aDgb7xuSVE=; b=jGDEjHwABAH4Z1IpzbAsMQ5U+DrBbbkWl6V74gpTHmm24n86DPx8WVXVJjVP21uD5o 4AkGEAuZR3kvCt73PuAcB0cTMhewkj5iXiLZG0u6OUG6AWHUguCSxb8K93fyYbJPl/8t ip5QThfnghiDakZQggHFq1j6FbU1otIjk7/hwdb31hDr+Aceve1Hv+waDp4mGbXFCeKe IHcITztADb/83jKLB0QLd7XjxA5+9TzKKobD2fhVncnq0vjNn0gKlCqX6gDAY7hLX3er YOSFO2fayaDVzFS7qLzf6MOUE6w2MhUZA9F6TOolfdgP3boWLbw+5BoPGq0iA2oV3vLS D0xw== X-Gm-Message-State: ALoCoQmuEY8QdnhpImahqMCTUcluVI1DwiBnn+h0aXtIzMt1Rp2bRh8LaI/nI5JYI2qRwIhU9vYB X-Received: by 10.52.173.165 with SMTP id bl5mr19356470vdc.13.1399903440854; Mon, 12 May 2014 07:04:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Mon, 12 May 2014 07:03:40 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Mon, 12 May 2014 10:03:40 -0400 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/k0g_PXBFRnxEttJWVW4FpqqhCZY Cc: Jeffrey Haas , "forces@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 12 May 2014 14:04:11 -0000 I have made another update. question to chairs - if there are none of Restconf/netconf/yang updates to the wiki does that mean you are going to disqualify them from the process ? (/me runs). cheers, jamal On Wed, May 7, 2014 at 12:20 PM, Jamal Hadi Salim wrote: > I have started updating the I2RS wiki on viability of using ForCES > for I2RS. I posted those requirements on the list over the weekend > and checking against them. > To the other proposals (netconf, restconf, yang), it would be nice > if we have a common set of requirements to check against. > I will be updating the wiki as more discussions for requirements come up > as well as put more commentary. > > Enjoy! > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis > > cheers, > jamal From nobody Tue May 13 18:26: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 E16571A0316 for ; Thu, 8 May 2014 07:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 NJhd4oXpmF6n for ; Thu, 8 May 2014 07:10:44 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2EF1A02F3 for ; Thu, 8 May 2014 07:10:43 -0700 (PDT) Received: from mail-qa0-f41.google.com ([209.85.216.41]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKU2uQX0Dhgcb5fK3l+H8rmZzvt7jQ+BWy@postini.com; Thu, 08 May 2014 07:10:39 PDT Received: by mail-qa0-f41.google.com with SMTP id dc16so2596639qab.28 for ; Thu, 08 May 2014 07:10:38 -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=gq17JniYTcKT19lgYvrng/zmI5HOan8hFA7pptMfsEM=; b=RcirSnPqiEdPLI2LiuRR9O2mR9RU8sLKLl2SIdC0Bw/rHZ5E8IP8wtAWfSb8h0okE5 jg/+GTpIzXQ5ZZrtgPk3pkSvDO/MMbcYVAHDF14Qa36bJ9JwlHfPzAifFglhlXK3iNjS u3LWeDXyGaQIIxuh7hOVdVA3s0f4eoLAaKpnzREvzPM5T7h27mNfZNdez4yI5g4qYJj6 S2QzbrIv8Mjeh2JNOXElj+oCce9njbXkt2K+svtSxZ7m6x7BQkxO7wq//ypJuUQxd+H+ 1nIoFezZVPcH5JEikFXspvEJNGEFHY9jKcxtJID3Ni+8qQMLu4M2NO17CdK4xjK8YOT5 VFVg== X-Gm-Message-State: ALoCoQnOFtkye6U5xHgAVUA8Wl5nZkaYivqtP09EPoOH5eQTTwcQouZWiM5AWGFgzls6/x+2bHLE4GiCOb5tGjj079zJxgi5VjnilEfE3G9zn7G9vhDrUTWzEZK9Em2VnlpUE2NRLGYC X-Received: by 10.140.86.178 with SMTP id p47mr4974676qgd.66.1399558238846; Thu, 08 May 2014 07:10:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.86.178 with SMTP id p47mr4974652qgd.66.1399558238726; Thu, 08 May 2014 07:10:38 -0700 (PDT) Received: by 10.140.94.11 with HTTP; Thu, 8 May 2014 07:10:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 May 2014 10:10:38 -0400 Message-ID: From: Russell Harrison To: FABIO ZACCANTTE Content-Type: multipart/alternative; boundary=001a11c13d5ca9a03404f8e40b75 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4dl3yYRDqZkbAkN93zQgahvTLeU X-Mailman-Approved-At: Tue, 13 May 2014 18:26:02 -0700 Cc: "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Interface to The Internet Routing System (IRS) 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, 08 May 2014 14:10:47 -0000 --001a11c13d5ca9a03404f8e40b75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fabio, Tom Nadeau and Ken Gray wrote a good book that provides the overview of the landscape you are looking for. As far as i2rs, the drafts, the wiki, and the mailing list archives are all that there is at this point=E2=80=A6 -rh On Thu, May 8, 2014 at 7:41 AM, FABIO ZACCANTTE wrote= : > Hi Dean > > I need to present I2RS in the next week to my teacher to convince him to > guide me in my master's degree and this is why many issues that at first= I > should try to understand, is due to lack of time to study. > > I need have overview about SDN and I2RS. > > If someone has a tutorial for an overview of I2RS would help me a lot. > > Regards, > Fabio. > > > > > On Thu, May 8, 2014 at 8:11 AM, Dean Bogdanovic wrote= : > >> Fabio, >> >> Alia was nice to give you some starting points, essentially taught you >> how to fish, but you are asking to be given the fish. >> >> Dean >> >> On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE >> wrote: >> >> Hi Alia >> >> >> What is the biggest difference in SDN when I have I2RS and when i not >> have? >> >> >> Regards, >> Fabio >> >> >> >> On Wed, May 7, 2014 at 1:41 PM, Alia Atlas wrote: >> >>> Hi Fabio, >>> >>> Take a read through the architecture >>> (http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and >>> problem-statement >>> (http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement). >>> >>> If you can provide your questions and review after that, it would be >>> quite helpful to know how solid a job the drafts do of explaining the >>> work. >>> >>> Regards, >>> Alia >>> >>> On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE >>> wrote: >>> > I am starting in the I2RS and my question is where stay I2RS, in the >>> router >>> > or controller. >>> > >>> > Someone has picture that represents the controller, the router, the >>> network >>> > and I2RS >>> > >>> > Regards, >>> > Fabio. >>> > >>> > _______________________________________________ >>> > 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 > > --001a11c13d5ca9a03404f8e40b75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fabio,

Tom Nadeau and Ken Gray wrote a = good book that provides the overview of the landscape you are looking for. = As far as i2rs, the drafts, the wiki, and the mailing list archives are all= that there is at this point=E2=80=A6

-rh


On Thu, May 8, 2014 at 7:41 AM, FABIO ZACCANTTE <= zaccantte@gmail.com> wrote:
H= i Dean=C2=A0

I need to present I2RS in the next week to my teacher to = convince him to guide me in my master's degree =C2=A0and this is why ma= ny issues that at first I should try to understand, is due to lack of time = to study.

I need have overview about SDN and I2RS.
=

If someone has a tutorial for an overview = of I2RS would help me a lot.=C2=A0

Regards,
Fabio.




On Thu, May 8, 2014 at = 8:11 AM, Dean Bogdanovic <deanb@juniper.net> wrote:
Fabio,

Alia was nice to give you some starting points, essentially taught you= how to fish, but you are asking to be given the fish.

Dean

On May 8, 2014, at 12:03 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
Hi Alia=C2=A0


What is the biggest difference in SDN when I have I2RS and when i not = have?


Regards,
Fabio



On Wed, May 7, 2014 at 1:41 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) an= d
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-stateme= nt).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE <zaccantte@gmail.com> wrote:
> I am starting in the I2RS and my question is where stay I2RS, in the r= outer
> or controller.
>
> Someone has picture that represents the controller, the router, the ne= twork
> and I2RS
>
> Regards,
> Fabio.
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs
>

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



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


--001a11c13d5ca9a03404f8e40b75-- From nobody Tue May 13 18:37: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 AA31C1A0125; Tue, 13 May 2014 18:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 untMZ1WQaDRO; Tue, 13 May 2014 18:37:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 415521A0160; Tue, 13 May 2014 18:37:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C7AAFC1FF; Tue, 13 May 2014 21:37:37 -0400 (EDT) Date: Tue, 13 May 2014 21:37:37 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140514013737.GB13387@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/35EDMhOIa42EwnFaNMMW-zuCLdE Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 01:37:45 -0000 Jamal, On Mon, May 12, 2014 at 10:03:40AM -0400, Jamal Hadi Salim wrote: > I have made another update. > question to chairs - if there are none of Restconf/netconf/yang > updates to the wiki > does that mean you are going to disqualify them from the process ? > (/me runs). Probably not. :-) Thank you for taking the time to fill in the wiki entry. I'd like to encourage the WG to spend a few moments looking over the information Jamal entered. (And, if our Netconf/Yang champions would care to crib his text and use it as the basis for their own, that would be similarly helpful.) The breakdown of Data Model Requirements is particularly a good one. -- Jeff > > cheers, > jamal > > On Wed, May 7, 2014 at 12:20 PM, Jamal Hadi Salim wrote: > > I have started updating the I2RS wiki on viability of using ForCES > > for I2RS. I posted those requirements on the list over the weekend > > and checking against them. > > To the other proposals (netconf, restconf, yang), it would be nice > > if we have a common set of requirements to check against. > > I will be updating the wiki as more discussions for requirements come up > > as well as put more commentary. > > > > Enjoy! > > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis > > > > cheers, > > jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 13 22:43:27 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 1D06A1A0233; Tue, 13 May 2014 22:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 8eGNUF8AfyKO; Tue, 13 May 2014 22:43:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AF0091A022F; Tue, 13 May 2014 22:43:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8E588FD1; Wed, 14 May 2014 07:43:14 +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 pp56MO6ITgaP; Wed, 14 May 2014 07:43:13 +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; Wed, 14 May 2014 07:43:13 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32A0220017; Wed, 14 May 2014 07:43:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zDtesCw3-BeG; Wed, 14 May 2014 07:43:12 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF7D920013; Wed, 14 May 2014 07:43:11 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id B8BEC2CD1365; Wed, 14 May 2014 07:43:10 +0200 (CEST) Date: Wed, 14 May 2014 07:43:10 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , "forces@ietf.org" References: <20140514013737.GB13387@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140514013737.GB13387@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kKnPFuDPStasLuKIzN_WFfgPzhI Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 05:43:24 -0000 On Tue, May 13, 2014 at 09:37:37PM -0400, Jeffrey Haas wrote: > Jamal, > > On Mon, May 12, 2014 at 10:03:40AM -0400, Jamal Hadi Salim wrote: > > I have made another update. > > question to chairs - if there are none of Restconf/netconf/yang > > updates to the wiki > > does that mean you are going to disqualify them from the process ? > > (/me runs). > > Probably not. :-) > > Thank you for taking the time to fill in the wiki entry. > > I'd like to encourage the WG to spend a few moments looking over the > information Jamal entered. (And, if our Netconf/Yang champions would care > to crib his text and use it as the basis for their own, that would be > similarly helpful.) > > The breakdown of Data Model Requirements is particularly a good one. > I do not understand the meaning of the following: 3) The data model MUST be able to express semantics of instances. I am not sure why this is a MUST: 2) The model MUST be object oriented. This allows it to extensible in the form of templating and sub-classing. In particular, if 'object oriented' means classes and sub-classes, what does this have to do with templating? Perhaps this is backwards and the requirement really is: 2a) The model MUST be extensible. 2b) The model MUST allow templating. But even then I am not even sure what 'templating' means. /js PS: I may regret having sent this message. I believe requirement discussions like this are not helpful in making a decision since this just leads to an endless debate about the requirements. -- 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 May 14 05:42: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 57D311A006D; Wed, 14 May 2014 05:42:30 -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 D9y-3Y62AnDZ; Wed, 14 May 2014 05:42:29 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7751A006B; Wed, 14 May 2014 05:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BB2A71BD1987; Wed, 14 May 2014 05:42:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8631E1BD1980; Wed, 14 May 2014 05:42:21 -0700 (PDT) Message-ID: <537364AB.5040702@joelhalpern.com> Date: Wed, 14 May 2014 08:42:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , "forces@ietf.org" References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gH8xMMsTSUpIJlXGavyxoFRdWic Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 12:42:30 -0000 Templating is described in the archtiecture document. However, as I said when i presented the material, this is a topic on which the authors disagree. I personally do not think it should be a protocol behavior, and therefore do not see it as something the model needs to represent. The basic idea of templating is to allow the I2RS client to say to the I2RS agent "I want to set this instance to these values, but for all the things I don't specify, use this template over here to determine what values to set." This clearly has power. Equally clearly, it can be done at the client rather than at the agent. Yours, Joel On 5/14/14, 1:43 AM, Juergen Schoenwaelder wrote: ... > > 2b) The model MUST allow templating. > > But even then I am not even sure what 'templating' means. ... From nobody Wed May 14 06:22: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 6AAE51A0095; Wed, 14 May 2014 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 g6QU7xJ1P15A; Wed, 14 May 2014 06:22:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 880481A009C; Wed, 14 May 2014 06:22:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D8BF9C26A; Wed, 14 May 2014 09:22:09 -0400 (EDT) Date: Wed, 14 May 2014 09:22:09 -0400 From: Jeffrey Haas To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , "forces@ietf.org" Message-ID: <20140514132209.GD16861@pfrc> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QQ8ScfT9vs-a-4W7SWCn4auQvYg Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 13:22:17 -0000 Juergen, On Wed, May 14, 2014 at 07:43:10AM +0200, Juergen Schoenwaelder wrote: > PS: I may regret having sent this message. I believe requirement > discussions like this are not helpful in making a decision since > this just leads to an endless debate about the requirements. The goal is not to endlessly debate requirements, it's to converge on the understood set of minimum requirements. While we've had significant good discussion about each proposed mechanism, it has largely been in a "compare and contrast existing mechanisms" format. At the end of the day (or perhaps week, I believe), we will have made our choice and will hopefully be crystal clear on what work is missing so we can move forward in an expeditious fashion. Thanks for contributing. -- Jeff From nobody Wed May 14 06:27:37 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 CE6351A0095 for ; Wed, 14 May 2014 06:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 NxVHz17D7vPc for ; Wed, 14 May 2014 06:27:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C25A31A0066 for ; Wed, 14 May 2014 06:27:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 37305C26A; Wed, 14 May 2014 09:27:28 -0400 (EDT) Date: Wed, 14 May 2014 09:27:28 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140514132728.GF16861@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/yjJCSzgZN5Hw9gfcnesppJtj3Ko Subject: [i2rs] [bclaise@cisco.com: [netmod] YANG Advice and Editing Session at the next IETF meeting] 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, 14 May 2014 13:27:36 -0000 Of likely interest to the Working Group. ----- Forwarded message from Benoit Claise ----- To: undisclosed-recipients: ; Subject: [netmod] YANG Advice and Editing Session at the next IETF meeting [Sorry for the potential cross-posting] http://www.ietf.org/meeting/90/tutorials/yang-session.html Let me stress that this should be an interactive session, and not a tutorial. So come with your (plan to create) YANG modules. Regards, Benoit _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ----- End forwarded message ----- From nobody Wed May 14 06:59: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 ADADC1A00A7 for ; Wed, 14 May 2014 06:59:10 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 2tHJivOkN0vV for ; Wed, 14 May 2014 06:59:09 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9251A009A for ; Wed, 14 May 2014 06:59:09 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu19so2466174vcb.34 for ; Wed, 14 May 2014 06:59:02 -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:from:date :message-id:subject:to:cc:content-type; bh=ZDTxvaS6t3fBo9tGs5serCo49B6FRxa4KbbxpRc/THs=; b=J+DzPzEJxFZwacz7P5TfwegvdRmKHntq3OyAWBJ4wyFFZnAy6Q7yOqnEvMiHFU5O6V +BLquyMD6V2cNXW2OZI/EnqGD3d8PnuKPqtsgA7pAHPEoVv3hhvCMM2CdyBeLp2nLuFW ri8uicrOckBjDOV9ofBf6ZuCMVTrXjfDlebu1D0oIZT75aocjqBSF4nKU0IRaWY5JCoH bFWvbpe9qkb893xKocR0pgmd7FUYCyYJw5SySnScsZeL29SawcOAMR2WQ9u9pVwdeHmj qxXXGhBe3c217wnQGAZVGt059LEytTCi4s+f1j0/EA1EF5z/3Wyer9ecwu5+EraUfHbk k7TQ== X-Gm-Message-State: ALoCoQkLHyUYp8OUFl5/JZPeC088aNC9DN+mogcAMAYqLJSS7ftmKyRL//8nv5dzBIefQDHi6gqS X-Received: by 10.58.74.38 with SMTP id q6mr3171828vev.7.1400075942436; Wed, 14 May 2014 06:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Wed, 14 May 2014 06:58:42 -0700 (PDT) In-Reply-To: <537364AB.5040702@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 14 May 2014 09:58:42 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E4hd0q17_MJLxob6Usuq1RwKvu4 Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 13:59:10 -0000 On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern wrote: > Templating is described in the archtiecture document. > However, as I said when i presented the material, this is a topic on which > the authors disagree. > I personally do not think it should be a protocol behavior, and therefore do > not see it as something the model needs to represent. > > The basic idea of templating is to allow the I2RS client to say to the I2RS > agent "I want to set this instance to these values, but for all the things I > don't specify, use this template over here to determine what values to set." > This clearly has power. Equally clearly, it can be done at the client > rather than at the agent. > Seems like i abused the term "template". I.e it seems to me that would fall under " Default values MUST be possible to specify" - which is described in the wiki. Shouldnt this be a model problem? I will fix the wiki entry and remove it from that sub-section. On the OO class/instances: The motivation is to be able to describe "set blah to RIB instance foo". The concept for abstracting a "factory" which is essentially a "class" vs an "instance" of that class seems to belong to the model. cheers, jamal From nobody Wed May 14 07:29: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 F0AAA1A00D5; Wed, 14 May 2014 07:29:09 -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 zuAwUwRLyelf; Wed, 14 May 2014 07:29:08 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6341A00D4; Wed, 14 May 2014 07:29:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 157581BD6855; Wed, 14 May 2014 07:29:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C31B51BD6850; Wed, 14 May 2014 07:28:59 -0700 (PDT) Message-ID: <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 10:28:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xAMW72p1vR8MM60BiBdq5GXYtng Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 14:29:10 -0000 (Alia, correct me if I mis-represent this concept.) No, temnplating is not just "Default values must be possible to specify." An example is that you might have a scheduling structure. it has a set of defaults which create a specific scheduling discipling. The Client can create a scheduling instance, and can over-ride any and all of those defaults. So far, that is just modeling with defaults. The idea with templates is that the Client could also say "For all the values I don't specify, use the WFQ template" or the EF template, or ... If the client does that, the agent would treat the values from that template which are specified in the template and are not specified in the request from the controller as if they had been specified by the controller, rather than using the base defaults. Coupled with this, some mechanism would provide these templates. The power here is that there might be different templates for the "EF Scheduling template" on different boxes to reflect how each box should be configured to achieve the policy goal. Conversely, clearly, all of this data can be on the client and the client can do the inclusion. Yours, Joel On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: > On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern wrote: >> Templating is described in the archtiecture document. >> However, as I said when i presented the material, this is a topic on which >> the authors disagree. >> I personally do not think it should be a protocol behavior, and therefore do >> not see it as something the model needs to represent. >> >> The basic idea of templating is to allow the I2RS client to say to the I2RS >> agent "I want to set this instance to these values, but for all the things I >> don't specify, use this template over here to determine what values to set." >> This clearly has power. Equally clearly, it can be done at the client >> rather than at the agent. >> > > Seems like i abused the term "template". I.e it seems to me that would > fall under > " Default values MUST be possible to specify" - which is described in the wiki. > Shouldnt this be a model problem? > I will fix the wiki entry and remove it from that sub-section. > > On the OO class/instances: > The motivation is to be able to describe "set blah to RIB instance foo". The > concept for abstracting a "factory" which is essentially a "class" vs > an "instance" of > that class seems to belong to the model. > > > cheers, > jamal > From nobody Wed May 14 07:49: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 8F92F1A0296 for ; Wed, 14 May 2014 07:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Zwd_9AxFhuOP for ; Wed, 14 May 2014 07:49:41 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0B67D1A008F for ; Wed, 14 May 2014 07:49:40 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z60so2926041qgd.23 for ; Wed, 14 May 2014 07:49:34 -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=8G5x3btDJf/YHMHsIeN+pemvCUMsfF15tAmjTe4feWk=; b=k7ttqhYcS07VlXjsosnrpTbFsU+WZkI3XK9vzvUydO+YjpRuy4/X9i16D7RSHB/NPO YTftLbYJTqnR/BazBzq96XJJoDSGGK6BvQkCk+1pjZePT3glR4XLTotsoOJ9kHclr14G oDwMytc5/2tYAnp7cOqioh9mUAawyaXqAvzYmNB7vT0N3MNxrXtM/anuukYl6wBUZUf4 NVO/OJMXYhavt0r7CA2JDrNXfofx1PBVPhY/aJuLoXCXj2+j+vjsEW6msocvACyWvM4e IPAdVF0Uhp8yE0XEKXuzliX7iqmIzqwMzeOhAGYTU26PSe1vc5NL0EeJSrtHisDqsaY+ GFpw== X-Gm-Message-State: ALoCoQmuTzyKDgZhOaL+z64gjFhhlfL0WAOuY0AvU5Iip47tzwQqN1szYWRQ2ox5eWSoE5mTSSU/ MIME-Version: 1.0 X-Received: by 10.229.96.199 with SMTP id i7mr6814062qcn.20.1400078974120; Wed, 14 May 2014 07:49:34 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 14 May 2014 07:49:33 -0700 (PDT) In-Reply-To: <53737DAA.1040809@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 07:49:33 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a1133886ee906f304f95d49af Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HscF7OviZ9nbUVglurOU7HZS-I0 Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 14:49:42 -0000 --001a1133886ee906f304f95d49af Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 14, 2014 at 7:28 AM, Joel M. Halpern wrote: > (Alia, correct me if I mis-represent this concept.) > > No, temnplating is not just "Default values must be possible to specify." > > An example is that you might have a scheduling structure. it has a set of > defaults which create a specific scheduling discipling. > The Client can create a scheduling instance, and can over-ride any and all > of those defaults. > So far, that is just modeling with defaults. > > The idea with templates is that the Client could also say "For all the > values I don't specify, use the WFQ template" or the EF template, or ... > If the client does that, the agent would treat the values from that > template which are specified in the template and are not specified in the > request from the controller as if they had been specified by the > controller, rather than using the base defaults. > > Coupled with this, some mechanism would provide these templates. The > power here is that there might be different templates for the "EF > Scheduling template" on different boxes to reflect how each box should be > configured to achieve the policy goal. > > Conversely, clearly, all of this data can be on the client and the client > can do the inclusion. > A generic template feature would be interesting, and may not be a lot of work. If a template includes lots of data, then it could be much faster (CPU, on-the-wire) than inline edits. Templates are usually just for convenience and consistency, but consistency (even across clients) is important. In the generic sense, a YANG template would be a sub-tree without keys. Whatever nodes were missing from the client request would get merged in by the server. (Some NETCONF servers are designed to do this merge very quickly). The protocol operation would say "edit that data with this patch and template X". > Yours, > Joel > Andy > > On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: > >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >> wrote: >> >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on >>> which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and >>> therefore do >>> not see it as something the model needs to represent. >>> >>> The basic idea of templating is to allow the I2RS client to say to the >>> I2RS >>> agent "I want to set this instance to these values, but for all the >>> things I >>> don't specify, use this template over here to determine what values to >>> set." >>> This clearly has power. Equally clearly, it can be done at the client >>> rather than at the agent. >>> >>> >> Seems like i abused the term "template". I.e it seems to me that would >> fall under >> " Default values MUST be possible to specify" - which is described in the >> wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >> >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance foo". >> The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >> >> >> cheers, >> jamal >> >> --001a1133886ee906f304f95d49af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 14, 2014 at 7:28 AM, Joel M. Halpern = <jmh@joelhalper= n.com> wrote:
(Alia, correct me if I mis-represent this co= ncept.)

No, temnplating is not just "Default values must be possible to specif= y."

An example is that you might have a scheduling structure. =A0it has a set o= f defaults which create a specific scheduling discipling.
The Client can create a scheduling instance, and can over-ride any and all = of those defaults.
So far, that is just modeling with defaults.

The idea with templates is that the Client could also say "For all the= values I don't specify, use the WFQ template" or the EF template,= or ... =A0If the client does that, the agent would treat the values from t= hat template which are specified in the template and are not specified in t= he request from the controller as if they had been specified by the control= ler, rather than using the base defaults.

Coupled with this, some mechanism would provide these templates. =A0The pow= er here is that there might be different templates for the "EF Schedul= ing template" on different boxes to reflect how each box should be con= figured to achieve the policy goal.

Conversely, clearly, all of this data can be on the client and the client c= an do the inclusion.


A g= eneric template feature would be interesting, and may not be
a lot of work. If a template includes lots of data, then it
could= be much faster (CPU, on-the-wire) than inline edits.

<= div>Templates are usually just for convenience and consistency,
but consistency (even across clients) is important.

In the generic sense, a YANG template would be a sub-tree
witho= ut keys. Whatever nodes were missing from the client request
would get merged in by the server. (Some NETCONF servers are designed
=
to do this merge very quickly). =A0The protocol operation would say
"edit that data with this patch and template X".


Yours,
Joel


Andy
=A0<= /div>

On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote:
On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Templating is described in the archtiecture document.
However, as I said when i presented the material, this is a topic on which<= br> the authors disagree.
I personally do not think it should be a protocol behavior, and therefore d= o
not see it as something the model needs to represent.

The basic idea of templating is to allow the I2RS client to say to the I2RS=
agent "I want to set this instance to these values, but for all the th= ings I
don't specify, use this template over here to determine what values to = set."
This clearly has power. =A0Equally clearly, it can be done at the client rather than at the agent.


Seems like i abused the term "template". I.e it seems to me that = would
fall under
" Default values MUST be possible to specify" - which is describe= d in the wiki.
Shouldnt this be a model problem?
I will fix the wiki entry and remove it from that sub-section.

On the OO class/instances:
The motivation is to be able to describe "set blah to RIB instance foo= ". The
concept for abstracting a "factory" which is essentially a "= class" vs
an "instance" of
that class seems to belong to the model.


cheers,
jamal


--001a1133886ee906f304f95d49af-- From nobody Wed May 14 08:03: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 EE7831A00B8; Wed, 14 May 2014 08:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 aPLaL-MNcdES; Wed, 14 May 2014 08:03:04 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E2D851A008F; Wed, 14 May 2014 08:03:03 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 142so1667703ykq.32 for ; Wed, 14 May 2014 08:02:57 -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=W+n4KIN9NLC9wsJZXHjbC6HGgy+equlmOXu1GRnbZTc=; b=b7gmFFZXL1KLB1d3/W6TCU2VlbN64jbYh2rUiLzYKMEyWKbaTWERzS1W/33crct8eJ Q9x41BtWr3UURGSM8s+CPrUgUBFrzkdGMaIkjsQvLQxPJC/TYKQoSx8HbIYrzUQzYITN hL6Rvw86PwgD3NDDieQ6MdzzP6Mqzws1eTGj2o+TagM+zbxcomYuRBHHG3C6mjPx/Hg8 8CIzGp9Zk6WzHe0Pz5bNWR6tVDWbz/OiLpiIdCuK+CExcxqxlfiOFBONAY2NcDmcA9o7 +prvZaOKp98YSYTEbjuAJ5wcOtxTHnNRdcWLDIuFA6Dp7CzDN79iQC4k2NNuQCnFfAY1 03iA== MIME-Version: 1.0 X-Received: by 10.236.220.72 with SMTP id n68mr6224364yhp.102.1400079777163; Wed, 14 May 2014 08:02:57 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Wed, 14 May 2014 08:02:57 -0700 (PDT) In-Reply-To: <53737DAA.1040809@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 11:02:57 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/27Rmcunw6ig6uD9llKpwEGPbIsM Cc: "i2rs@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 15:03:06 -0000 Hi Joel, Just quickly, the key point is to avoid having the client need to understand all the different ways of making the desired behavior happen or specifying all the details when there's only a small set that need to change. A use-case is something like assigning traffic into a particular queue or configuring that queue where there aren't good and common abstractions. Alia On Wed, May 14, 2014 at 10:28 AM, Joel M. Halpern wrote: > (Alia, correct me if I mis-represent this concept.) > > No, temnplating is not just "Default values must be possible to specify." > > An example is that you might have a scheduling structure. it has a set of > defaults which create a specific scheduling discipling. > The Client can create a scheduling instance, and can over-ride any and all > of those defaults. > So far, that is just modeling with defaults. > > The idea with templates is that the Client could also say "For all the > values I don't specify, use the WFQ template" or the EF template, or ... If > the client does that, the agent would treat the values from that template > which are specified in the template and are not specified in the request > from the controller as if they had been specified by the controller, rather > than using the base defaults. > > Coupled with this, some mechanism would provide these templates. The power > here is that there might be different templates for the "EF Scheduling > template" on different boxes to reflect how each box should be configured to > achieve the policy goal. > > Conversely, clearly, all of this data can be on the client and the client > can do the inclusion. > > Yours, > Joel > > > On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >> >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >> wrote: >>> >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on >>> which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and therefore >>> do >>> not see it as something the model needs to represent. >>> >>> The basic idea of templating is to allow the I2RS client to say to the >>> I2RS >>> agent "I want to set this instance to these values, but for all the >>> things I >>> don't specify, use this template over here to determine what values to >>> set." >>> This clearly has power. Equally clearly, it can be done at the client >>> rather than at the agent. >>> >> >> Seems like i abused the term "template". I.e it seems to me that would >> fall under >> " Default values MUST be possible to specify" - which is described in the >> wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >> >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance foo". >> The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >> >> >> cheers, >> jamal >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 14 08:18:21 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 1F7771A00C2; Wed, 14 May 2014 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 IwxxE2DLyvGo; Wed, 14 May 2014 08:18:18 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D3FC21A00B8; Wed, 14 May 2014 08:18:17 -0700 (PDT) Received: from [172.21.2.104] (unknown [74.174.42.172]) by lucidvision.com (Postfix) with ESMTP id 38E1B27A7F4E; Wed, 14 May 2014 11:18:01 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 11:18:00 -0400 Message-Id: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wUCOBsf4EF5oXF6I3x5xCMy2Iak Cc: "i2rs@ietf.org" , Crabbe Edward , Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 15:18:20 -0000 --Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Its not just default values; its more like a set of = preconfigured values for a set of objects.=20 --Tom On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern = wrote: > (Alia, correct me if I mis-represent this concept.) >=20 > No, temnplating is not just "Default values must be possible to = specify." >=20 > An example is that you might have a scheduling structure. it has a = set of defaults which create a specific scheduling discipling. > The Client can create a scheduling instance, and can over-ride any and = all of those defaults. > So far, that is just modeling with defaults. >=20 > The idea with templates is that the Client could also say "For all the = values I don't specify, use the WFQ template" or the EF template, or ... = If the client does that, the agent would treat the values from that = template which are specified in the template and are not specified in = the request from the controller as if they had been specified by the = controller, rather than using the base defaults. >=20 > Coupled with this, some mechanism would provide these templates. The = power here is that there might be different templates for the "EF = Scheduling template" on different boxes to reflect how each box should = be configured to achieve the policy goal. >=20 > Conversely, clearly, all of this data can be on the client and the = client can do the inclusion. >=20 > Yours, > Joel >=20 > On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern = wrote: >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on = which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and = therefore do >>> not see it as something the model needs to represent. >>>=20 >>> The basic idea of templating is to allow the I2RS client to say to = the I2RS >>> agent "I want to set this instance to these values, but for all the = things I >>> don't specify, use this template over here to determine what values = to set." >>> This clearly has power. Equally clearly, it can be done at the = client >>> rather than at the agent. >>>=20 >>=20 >> Seems like i abused the term "template". I.e it seems to me that = would >> fall under >> " Default values MUST be possible to specify" - which is described in = the wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >>=20 >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance = foo". The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >>=20 >>=20 >> cheers, >> jamal >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555 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 iQIcBAEBCgAGBQJTc4koAAoJEPcO+I7eiUJZ21EP/3wlHxi6hyv0TkhVltUCijAm viHuuK6D7GngmXdwvXnWCqmAgIiMfUhQNsuQmZJKUnexHMfvJZTODA4C1s4s5Ijw mjsXHb8CA9j+wFyKwCwPMrhn89q0fGvUL1+K+HEMfJYc4slrkyTqKkJX4sbjInju JKpy6G059UAB0k3v+ZazagZoVf7H6r8jK03jlKGEmfFdqJxCWhztQKJaijVjQeuF WRTfCXPfu1aBAhr4A6ebRIHhCTmnek9KSzJUfYrabhfoEHYj0RulHksaPl909PJP +co71YoESxNlFfgJAxu1ZmkURGo4Og0wnIkEreJxu0frEWkJYitPegSUeKwjAeEI y6n2qFu2BCco6wtn9ivMWEThsw9ItsKuaHZb4w/f9AI/qfxPfO9xH2hZVaqLz4hP dYWYQzdRTmGeGfZRuHyCunU+ftKIVZCu/+tWxAuugEi//C8mjeBnqEwPlnuTLJ6I s5AtlGGfYgPTlz25/S9DaW9tnO1XvR4PrRoEERRDAbdum/zqpOaqDll0UV+5Dcnz YGrQjwAYk+eq92CcnZ54+pVseN08ataaFrwVMPyocQMmCw0TsD0cMRMPWsUcqK5S poMDKH4k2O3oKN2Ysu9DM6yHRK56wcPo+WDYbyYB4WfxGhJWGrlGqZjA7AdIWNFn h5SpG+eu2lUXBWj+wE9y =jA8R -----END PGP SIGNATURE----- --Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555-- From nobody Wed May 14 08:29:54 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 40AD61A00E5 for ; Wed, 14 May 2014 08:29:50 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 0glSEfeOEQeZ for ; Wed, 14 May 2014 08:29:47 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6A1A00DA for ; Wed, 14 May 2014 08:29:47 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id lh14so2667739vcb.33 for ; Wed, 14 May 2014 08:29:40 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ylgt/FBlvxIecPKS+WeNkQg5QvfyIKuCm2REKJFyDeU=; b=aJ+C7407O7sqEL8WalTNZy/ddXBjq2+TwiGw2bDbngWrE1/0lWTSebfsUpbP9TD2S1 UceY7N3OZnfh2Tygl6bIbnYuMR6gx4sQeDcItXA2mgB1hhlWfnexIFR4EWPVa265hNAv 5cJ+x9nXOp5hcRoWeruzFaPiviuYd9hw74HHIBPZnFyUtfY4alA6Gccf5j7/bnrwP0tE +/K0MRUzDIULbAfz5tMvgEjGHyHpMEbS10eHUVebQJZlSVwZtwEJH1mEgNhUTvOkwLJB SwFEHr7neo48jxLp9/MFTGQjouqO/7cyeKwKlu07tvuwPCco1hIV51WBNYgPRpUxNDzv oh3Q== X-Gm-Message-State: ALoCoQlkMcDt1zQX/bzcSLh1QZhwwcBtMiy+nDuoBjjMeAYFW5/Pz31OInnA302xcwykcGf+52xA X-Received: by 10.52.117.237 with SMTP id kh13mr154038vdb.96.1400081380658; Wed, 14 May 2014 08:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Wed, 14 May 2014 08:29:20 -0700 (PDT) In-Reply-To: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 14 May 2014 11:29:20 -0400 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ogBpXD_I8u8jHFjsW1JwAXktM0M Cc: "i2rs@ietf.org" , "forces@ietf.org" , Crabbe Edward , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 15:29:50 -0000 Ok, I think i get then what Joel was saying. Is this then an implementation issue? cheers, jamal On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau w= rote: > > Its not just default values; its more like a set of preconfigured= values for a set of objects. > > --Tom > > > On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern wrote: > >> (Alia, correct me if I mis-represent this concept.) >> >> No, temnplating is not just "Default values must be possible to specify.= " >> >> An example is that you might have a scheduling structure. it has a set = of defaults which create a specific scheduling discipling. >> The Client can create a scheduling instance, and can over-ride any and a= ll of those defaults. >> So far, that is just modeling with defaults. >> >> The idea with templates is that the Client could also say "For all the v= alues I don't specify, use the WFQ template" or the EF template, or ... If= the client does that, the agent would treat the values from that template = which are specified in the template and are not specified in the request fr= om the controller as if they had been specified by the controller, rather t= han using the base defaults. >> >> Coupled with this, some mechanism would provide these templates. The po= wer here is that there might be different templates for the "EF Scheduling = template" on different boxes to reflect how each box should be configured t= o achieve the policy goal. >> >> Conversely, clearly, all of this data can be on the client and the clien= t can do the inclusion. >> >> Yours, >> Joel >> >> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern = wrote: >>>> Templating is described in the archtiecture document. >>>> However, as I said when i presented the material, this is a topic on w= hich >>>> the authors disagree. >>>> I personally do not think it should be a protocol behavior, and theref= ore do >>>> not see it as something the model needs to represent. >>>> >>>> The basic idea of templating is to allow the I2RS client to say to the= I2RS >>>> agent "I want to set this instance to these values, but for all the th= ings I >>>> don't specify, use this template over here to determine what values to= set." >>>> This clearly has power. Equally clearly, it can be done at the client >>>> rather than at the agent. >>>> >>> >>> Seems like i abused the term "template". I.e it seems to me that would >>> fall under >>> " Default values MUST be possible to specify" - which is described in t= he wiki. >>> Shouldnt this be a model problem? >>> I will fix the wiki entry and remove it from that sub-section. >>> >>> On the OO class/instances: >>> The motivation is to be able to describe "set blah to RIB instance foo"= . The >>> concept for abstracting a "factory" which is essentially a "class" vs >>> an "instance" of >>> that class seems to belong to the model. >>> >>> >>> cheers, >>> jamal >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Wed May 14 08:35: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 A37CB1A0301; Wed, 14 May 2014 08:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 VU5QMhiawguy; Wed, 14 May 2014 08:35:35 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 05DBB1A02EA; Wed, 14 May 2014 08:35:09 -0700 (PDT) Received: from [172.21.2.104] (unknown [74.174.42.172]) by lucidvision.com (Postfix) with ESMTP id 36EA727A804A; Wed, 14 May 2014 11:34:57 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 14 May 2014 11:34:51 -0400 Message-Id: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/zGq1f2yZLh_1r4f4VSingFZMAYo Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Crabbe Edward , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 15:35:37 -0000 --Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Maybe. I think that was the point though. Operationally you = specify these things, so as long as you can specify them we are good.=20 --Tom > Ok, I think i get then what Joel was saying. Is this then an > implementation issue? >=20 > cheers, > jamal >=20 > On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau = wrote: >>=20 >> Its not just default values; its more like a set of = preconfigured values for a set of objects. >>=20 >> --Tom >>=20 >>=20 >> On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern = wrote: >>=20 >>> (Alia, correct me if I mis-represent this concept.) >>>=20 >>> No, temnplating is not just "Default values must be possible to = specify." >>>=20 >>> An example is that you might have a scheduling structure. it has a = set of defaults which create a specific scheduling discipling. >>> The Client can create a scheduling instance, and can over-ride any = and all of those defaults. >>> So far, that is just modeling with defaults. >>>=20 >>> The idea with templates is that the Client could also say "For all = the values I don't specify, use the WFQ template" or the EF template, or = ... If the client does that, the agent would treat the values from that = template which are specified in the template and are not specified in = the request from the controller as if they had been specified by the = controller, rather than using the base defaults. >>>=20 >>> Coupled with this, some mechanism would provide these templates. = The power here is that there might be different templates for the "EF = Scheduling template" on different boxes to reflect how each box should = be configured to achieve the policy goal. >>>=20 >>> Conversely, clearly, all of this data can be on the client and the = client can do the inclusion. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern = wrote: >>>>> Templating is described in the archtiecture document. >>>>> However, as I said when i presented the material, this is a topic = on which >>>>> the authors disagree. >>>>> I personally do not think it should be a protocol behavior, and = therefore do >>>>> not see it as something the model needs to represent. >>>>>=20 >>>>> The basic idea of templating is to allow the I2RS client to say to = the I2RS >>>>> agent "I want to set this instance to these values, but for all = the things I >>>>> don't specify, use this template over here to determine what = values to set." >>>>> This clearly has power. Equally clearly, it can be done at the = client >>>>> rather than at the agent. >>>>>=20 >>>>=20 >>>> Seems like i abused the term "template". I.e it seems to me that = would >>>> fall under >>>> " Default values MUST be possible to specify" - which is described = in the wiki. >>>> Shouldnt this be a model problem? >>>> I will fix the wiki entry and remove it from that sub-section. >>>>=20 >>>> On the OO class/instances: >>>> The motivation is to be able to describe "set blah to RIB instance = foo". The >>>> concept for abstracting a "factory" which is essentially a "class" = vs >>>> an "instance" of >>>> that class seems to belong to the model. >>>>=20 >>>>=20 >>>> cheers, >>>> jamal >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B 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 iQIcBAEBCgAGBQJTc40bAAoJEPcO+I7eiUJZlGgP/ReMj6wRvicbf2Sf0Fav3iQz q7JPfSu75FU+hqXUcC7q5If6JA2EhCR2Ekayf+bK36pv3gMmxvPwfwcTgL7b+C7T KCs7tn3giWEALGpqOwP9QkjHnwa6Z/0pUvb48oi6/+hYyeirLcLd4K4reVuoLCyw /XqaqwJ6Q+L5ZH65HjSQhICjzmeyBC0SMCMn1z2H7fT0wmHjBFAExdc8XyTkw1/e nUG/L4XECdER58orLhzJ3BmH0BNHVQX5Mw5ycILHmMi3ClCEO+dm3VCuUZe+FQqx fqWAGGpnzDBTrOuaJEKpZkTAd/ZO5zxToTTcRQeZyDyXdd/boFoVNyg8KaShP13E 9nfqMIF396NPoer8Sa3PHofiFX0XXr2NEergel00t3At0zfAK59atdD0p7QDZ29p 2H3YzO/V61jxeV4VXpBrAi2UXL3O4OHfij2XsJVq1NLJ/q3QlBLT7lf0BHuIrfdc 70uI50WM2ARpjxq3pd2JSt9OpKpD+B2mnykN9NOuR/wkVJ5Cx/vQ11axW5h6icqO r9gsxgtJ4KlivzU01JIYlz0P9j2t7ZjCl2Qcv4lIGMQF+IhRe7PLdHJnl97VhIe3 1H//v5/6VcLc/bpMr8tIpIjqkJeFjUpMUR6ancebFVeIsLVZHUiVW65tPZtCg5NO +Ke1zik8eDmyDR6RXKDs =DU9J -----END PGP SIGNATURE----- --Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B-- From nobody Wed May 14 09:28:58 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 8C1371A02D5; Wed, 14 May 2014 09:28:55 -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 Yee0inWnzQfO; Wed, 14 May 2014 09:28:54 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E848B1A00D5; Wed, 14 May 2014 09:28:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7041C3E1AFC; Wed, 14 May 2014 09:28:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E017B3E1AFB; Wed, 14 May 2014 09:28:45 -0700 (PDT) Message-ID: <537399BC.4080008@joelhalpern.com> Date: Wed, 14 May 2014 12:28:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jamal Hadi Salim , Thomas Nadeau References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CHo3tJ7t_RNZAdk299SNPD4IiUE Cc: "i2rs@ietf.org" , Crabbe Edward , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 16:28:55 -0000 I wish it were just an implementation issue. If we are going to support this in the protocol then: 1) We need a mechanism explicitly in the protocol to say "use this template". 2) We need to include templates in the set of things we model. Yours, Joel On 5/14/14, 11:29 AM, Jamal Hadi Salim wrote: > Ok, I think i get then what Joel was saying. Is this then an > implementation issue? > > cheers, > jamal > > On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau wrote: >> >> Its not just default values; its more like a set of preconfigured values for a set of objects. >> >> --Tom >> >> >> On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern wrote: >> >>> (Alia, correct me if I mis-represent this concept.) >>> >>> No, temnplating is not just "Default values must be possible to specify." >>> >>> An example is that you might have a scheduling structure. it has a set of defaults which create a specific scheduling discipling. >>> The Client can create a scheduling instance, and can over-ride any and all of those defaults. >>> So far, that is just modeling with defaults. >>> >>> The idea with templates is that the Client could also say "For all the values I don't specify, use the WFQ template" or the EF template, or ... If the client does that, the agent would treat the values from that template which are specified in the template and are not specified in the request from the controller as if they had been specified by the controller, rather than using the base defaults. >>> >>> Coupled with this, some mechanism would provide these templates. The power here is that there might be different templates for the "EF Scheduling template" on different boxes to reflect how each box should be configured to achieve the policy goal. >>> >>> Conversely, clearly, all of this data can be on the client and the client can do the inclusion. >>> >>> Yours, >>> Joel >>> >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern wrote: >>>>> Templating is described in the archtiecture document. >>>>> However, as I said when i presented the material, this is a topic on which >>>>> the authors disagree. >>>>> I personally do not think it should be a protocol behavior, and therefore do >>>>> not see it as something the model needs to represent. >>>>> >>>>> The basic idea of templating is to allow the I2RS client to say to the I2RS >>>>> agent "I want to set this instance to these values, but for all the things I >>>>> don't specify, use this template over here to determine what values to set." >>>>> This clearly has power. Equally clearly, it can be done at the client >>>>> rather than at the agent. >>>>> >>>> >>>> Seems like i abused the term "template". I.e it seems to me that would >>>> fall under >>>> " Default values MUST be possible to specify" - which is described in the wiki. >>>> Shouldnt this be a model problem? >>>> I will fix the wiki entry and remove it from that sub-section. >>>> >>>> On the OO class/instances: >>>> The motivation is to be able to describe "set blah to RIB instance foo". The >>>> concept for abstracting a "factory" which is essentially a "class" vs >>>> an "instance" of >>>> that class seems to belong to the model. >>>> >>>> >>>> cheers, >>>> jamal >>>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> > From nobody Wed May 14 09:33:21 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 F29D41A0133; Wed, 14 May 2014 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 NgS_lfEpNJ4U; Wed, 14 May 2014 09:33:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2061D1A00D5; Wed, 14 May 2014 09:33:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6A8C6C26A; Wed, 14 May 2014 12:33:11 -0400 (EDT) Date: Wed, 14 May 2014 12:33:11 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20140514163311.GB17907@pfrc> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> <537399BC.4080008@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537399BC.4080008@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Rm7nNllvhemGYhbq0f9ohZJIvMc Cc: Thomas Nadeau , Crabbe Edward , "i2rs@ietf.org" , Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 16:33:19 -0000 On Wed, May 14, 2014 at 12:28:44PM -0400, Joel M. Halpern wrote: > I wish it were just an implementation issue. > If we are going to support this in the protocol then: > 1) We need a mechanism explicitly in the protocol to say "use this > template". > 2) We need to include templates in the set of things we model. +1 One of the cases in the pending architecture doc refresh (don't recall if it's in the existing version) is effectively "copy constructor" behavior for templates. If we had the equivalent of configured state that was scoped to not commit (yes, obviously ugly but potentially another one of those side data stores we have been talking about), then you have identified objects that are "committed" somewhere (not impacting running state) that can be referenced for such a copy constructor. Effectively, a form of template. -- Jeff From nobody Wed May 14 12:24: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 6FD091A017A; Wed, 14 May 2014 12:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 WC2qdoj35ZUa; Wed, 14 May 2014 12:24:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D61A0157; Wed, 14 May 2014 12:24:10 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB428.namprd05.prod.outlook.com (10.141.74.15) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 19:24:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Wed, 14 May 2014 19:24:01 +0000 From: Kent Watsen To: "Joel M. Halpern" , Jamal Hadi Salim Thread-Topic: [i2rs] Update to Wiki (ForCES for I2RS) Thread-Index: AQHPahBnjoa7vUfkeEGsG/dJCztYz5s9AdMAgAJUOICAAESbAIAAdRyAgAAVVwCAAAh1AIAAD2SA Date: Wed, 14 May 2014 19:24:01 +0000 Message-ID: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> In-Reply-To: <53737DAA.1040809@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(24454002)(479174003)(377454003)(51704005)(189002)(199002)(21056001)(46102001)(77982001)(85852003)(83072002)(99286001)(15975445006)(76482001)(2656002)(80022001)(101416001)(76176999)(66066001)(99396002)(15202345003)(79102001)(86362001)(83506001)(19580395003)(31966008)(87936001)(74502001)(54356999)(74662001)(20776003)(64706001)(83322001)(81542001)(92566001)(92726001)(50986999)(81342001)(4396001)(36756003)(19580405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB428; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <67B33AB4A8DF164DAFC0D188FB037A55@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/MIG8rUgeUGq-M46W9xo5N0CgRoE Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 19:24:13 -0000 Joel's "templates" sound like apply-groups in Junos: http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/routing-matr ix-tx-matrix-plus-using-configuration-groups-for-components-solutions.html K. On 5/14/14, 10:28 AM, "Joel M. Halpern" wrote: >(Alia, correct me if I mis-represent this concept.) > >No, temnplating is not just "Default values must be possible to specify." > >An example is that you might have a scheduling structure. it has a set >of defaults which create a specific scheduling discipling. >The Client can create a scheduling instance, and can over-ride any and >all of those defaults. >So far, that is just modeling with defaults. > >The idea with templates is that the Client could also say "For all the >values I don't specify, use the WFQ template" or the EF template, or ... > If the client does that, the agent would treat the values from that >template which are specified in the template and are not specified in >the request from the controller as if they had been specified by the >controller, rather than using the base defaults. > >Coupled with this, some mechanism would provide these templates. The >power here is that there might be different templates for the "EF >Scheduling template" on different boxes to reflect how each box should >be configured to achieve the policy goal. > >Conversely, clearly, all of this data can be on the client and the >client can do the inclusion. > >Yours, >Joel > >On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >>wrote: >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on >>>which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and >>>therefore do >>> not see it as something the model needs to represent. >>> >>> The basic idea of templating is to allow the I2RS client to say to the >>>I2RS >>> agent "I want to set this instance to these values, but for all the >>>things I >>> don't specify, use this template over here to determine what values to >>>set." >>> This clearly has power. Equally clearly, it can be done at the client >>> rather than at the agent. >>> >> >> Seems like i abused the term "template". I.e it seems to me that would >> fall under >> " Default values MUST be possible to specify" - which is described in >>the wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >> >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance >>foo". The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >> >> >> cheers, >> jamal >> > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 14 12:30: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 B591A1A02B5; Wed, 14 May 2014 12:30:02 -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 fA-h1yL7oSWC; Wed, 14 May 2014 12:30:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE411A00DD; Wed, 14 May 2014 12:30:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E7CCC3E277D; Wed, 14 May 2014 12:29:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 88F5D3E26D3; Wed, 14 May 2014 12:29:53 -0700 (PDT) Message-ID: <5373C42F.9040407@joelhalpern.com> Date: Wed, 14 May 2014 15:29:51 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> <537399BC.4080008@joelhalpern.com> <20140514163311.GB17907@pfrc> In-Reply-To: <20140514163311.GB17907@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Wr98htiH7_ex4zparxv5dM4Bk1s Cc: Thomas Nadeau , Crabbe Edward , Jamal Hadi Salim , Andy Bierman , Dean Bogdanovic , "i2rs@ietf.org" , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 19:30:02 -0000 So, having gone down this rabiit hole, let me explain my primary objection to this feature. The idea of the feature is that the I2RS client does not ahve to set up these templates, but simply uses them. And that by having different templates on different devices it can get the "right result" in different places. Which means that the client does not actually know what its request is going to do. the template may or may not actually do what it wants, because the client did not establish the template. For CLI operation, this kind of template operation seems very useful. For automated operation, I am concerned by the loss of information at the client. Yours, Joel On 5/14/14, 12:33 PM, Jeffrey Haas wrote: > On Wed, May 14, 2014 at 12:28:44PM -0400, Joel M. Halpern wrote: >> I wish it were just an implementation issue. >> If we are going to support this in the protocol then: >> 1) We need a mechanism explicitly in the protocol to say "use this >> template". >> 2) We need to include templates in the set of things we model. > > +1 > > One of the cases in the pending architecture doc refresh (don't recall if > it's in the existing version) is effectively "copy constructor" behavior for > templates. > > If we had the equivalent of configured state that was scoped to not commit > (yes, obviously ugly but potentially another one of those side data stores > we have been talking about), then you have identified objects that are > "committed" somewhere (not impacting running state) that can be referenced > for such a copy constructor. Effectively, a form of template. > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed May 14 13:47:36 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 741311A01DD; Wed, 14 May 2014 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 4_y_NT2bHx5I; Wed, 14 May 2014 13:47:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5A1A0129; Wed, 14 May 2014 13:47:28 -0700 (PDT) Received: from [10.4.188.39] (unknown [166.205.66.4]) by lucidvision.com (Postfix) with ESMTP id 9893127A8CE9; Wed, 14 May 2014 16:47:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Wed, 14 May 2014 16:47:20 -0400 Content-Transfer-Encoding: 7bit Message-Id: <56C79F88-092E-4904-B58D-AD096E0BE993@lucidvision.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> To: Kent Watsen Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1h94CdifynvauRzOvRyqpoUt2aE Cc: "i2rs@ietf.org" , "forces@ietf.org" , Edward Crabbe , Jamal Hadi Salim , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 20:47:33 -0000 Yep. Tom > On May 14, 2014, at 3:24 PM, Kent Watsen wrote: > > > > Joel's "templates" sound like apply-groups in Junos: > > http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/routing-matr > ix-tx-matrix-plus-using-configuration-groups-for-components-solutions.html > > K. > > > >> On 5/14/14, 10:28 AM, "Joel M. Halpern" wrote: >> >> (Alia, correct me if I mis-represent this concept.) >> >> No, temnplating is not just "Default values must be possible to specify." >> >> An example is that you might have a scheduling structure. it has a set >> of defaults which create a specific scheduling discipling. >> The Client can create a scheduling instance, and can over-ride any and >> all of those defaults. >> So far, that is just modeling with defaults. >> >> The idea with templates is that the Client could also say "For all the >> values I don't specify, use the WFQ template" or the EF template, or ... >> If the client does that, the agent would treat the values from that >> template which are specified in the template and are not specified in >> the request from the controller as if they had been specified by the >> controller, rather than using the base defaults. >> >> Coupled with this, some mechanism would provide these templates. The >> power here is that there might be different templates for the "EF >> Scheduling template" on different boxes to reflect how each box should >> be configured to achieve the policy goal. >> >> Conversely, clearly, all of this data can be on the client and the >> client can do the inclusion. >> >> Yours, >> Joel >> >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >>> wrote: >>>> Templating is described in the archtiecture document. >>>> However, as I said when i presented the material, this is a topic on >>>> which >>>> the authors disagree. >>>> I personally do not think it should be a protocol behavior, and >>>> therefore do >>>> not see it as something the model needs to represent. >>>> >>>> The basic idea of templating is to allow the I2RS client to say to the >>>> I2RS >>>> agent "I want to set this instance to these values, but for all the >>>> things I >>>> don't specify, use this template over here to determine what values to >>>> set." >>>> This clearly has power. Equally clearly, it can be done at the client >>>> rather than at the agent. >>> >>> Seems like i abused the term "template". I.e it seems to me that would >>> fall under >>> " Default values MUST be possible to specify" - which is described in >>> the wiki. >>> Shouldnt this be a model problem? >>> I will fix the wiki entry and remove it from that sub-section. >>> >>> On the OO class/instances: >>> The motivation is to be able to describe "set blah to RIB instance >>> foo". The >>> concept for abstracting a "factory" which is essentially a "class" vs >>> an "instance" of >>> that class seems to belong to the model. >>> >>> >>> cheers, >>> jamal >> >> _______________________________________________ >> 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 May 14 15:54: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 B12B71A033C for ; Wed, 14 May 2014 15:54:44 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 Ei_ASgEmm0nt for ; Wed, 14 May 2014 15:54:43 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828FA1A015B for ; Wed, 14 May 2014 15:54:43 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lg15so3331077vcb.7 for ; Wed, 14 May 2014 15:54:36 -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:from:date :message-id:subject:to:cc:content-type; bh=UbpK8Nrsj4CraHasq7z0e2eY+9r8ppcp62xmd6+1i0E=; b=INmbDqIdYew6ZQb1zzOGaQq4uxqFd4ppWOAzLKjw6xvhbNJOZ+yfQWJErXzdtJ8AtX WOBUo6IxV5dfFYzo6nbcDP1Au+wIe0FU3cRa1QWHAJAddhdfLCwZbk7e/83lOOLUup20 VZWoDy6u0ut7nP60LuJ+V3o/yUm5Oz/dylAQQfkPZMX7gY0y1F8k6wNY0uDUCVm1vRgP D1rxNoPT91LBIUy1gPrKgSH6bng+InB8acNXRjOpmoGHRo7xBgNak9KaBbDQNOzRyJ/l swDuLq+6dRY/yXlBAhfjDUkeocSVMLgBVG1M/pypszbmxaZOEMfsEGqvcNr+kmusCCo5 //0g== X-Gm-Message-State: ALoCoQnwjqaj7qq5j320N38cbvC1TJ0rSeIVjxZpiF9AUb/0F33U04bsiq9Gr72nNzEGuq5E/wOt X-Received: by 10.58.126.4 with SMTP id mu4mr5334247veb.0.1400108076057; Wed, 14 May 2014 15:54:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Wed, 14 May 2014 15:54:15 -0700 (PDT) In-Reply-To: <5373C42F.9040407@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> <537399BC.4080008@joelhalpern.com> <20140514163311.GB17907@pfrc> <5373C42F.9040407@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 14 May 2014 18:54:15 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4UoWNbOfOAOBI1JUN7J23Z1GS2Q Cc: Thomas Nadeau , Crabbe Edward , "i2rs@ietf.org" , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [i2rs] Update to Wiki (ForCES for I2RS) 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, 14 May 2014 22:54:44 -0000 On Wed, May 14, 2014 at 3:29 PM, Joel M. Halpern wrote: > For CLI operation, this kind of template operation seems very useful. > For automated operation, I am concerned by the loss of information at the > client. I am still struggling on why this is not "implementation specific". ex: the client should be able to pick a template specified (through some auxillary method), datafill whatever params needed and pass via the protocol to the agent. Is there is a good reason it has to be the agent that resolves what the template is? cheers, jamal From nobody Thu May 15 08:38: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 2D4451A008D; Thu, 15 May 2014 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 iw2WDtP3fXmu; Thu, 15 May 2014 08:38:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE531A00CB; Thu, 15 May 2014 08:38:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140515153847.17020.68950.idtracker@ietfa.amsl.com> Date: Thu, 15 May 2014 08:38:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/RjsDb57VQ-jjpFdQwl1DI4sChb4 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-architecture-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 15:38:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : An Architecture for the Interface to the Routing System Authors : Alia Atlas Joel Halpern Susan Hares Dave Ward Thomas D. Nadeau Filename : draft-ietf-i2rs-architecture-03.txt Pages : 30 Date : 2014-05-15 Abstract: This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet's routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of I2RS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-architecture-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-architecture-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 16 13:47:23 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 264611A028C for ; Fri, 16 May 2014 13:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 6THHL_PfcpXt for ; Fri, 16 May 2014 13:47:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3D91A01D4 for ; Fri, 16 May 2014 13:47:19 -0700 (PDT) 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.939.12; Fri, 16 May 2014 20:47:11 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.135]) with mapi id 15.00.0939.000; Fri, 16 May 2014 20:47:11 +0000 From: Dean Bogdanovic To: t.petch Thread-Topic: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model Thread-Index: AQHPZTu405vK3FP81Eang6FRLoX8SptDxYuA Date: Fri, 16 May 2014 20:47:10 +0000 Message-ID: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> In-Reply-To: <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(377454003)(24454002)(189002)(199002)(62966002)(86362001)(83072002)(21056001)(93916002)(82746002)(81542001)(81342001)(99286001)(99396002)(92726001)(46102001)(2656002)(76482001)(92566001)(83716003)(88136002)(87286001)(89996001)(50226001)(57306001)(85852003)(87936001)(77156001)(4396001)(77982001)(36756003)(31966008)(74502001)(74662001)(19580395003)(33656001)(79102001)(83322001)(19580405001)(101416001)(20776003)(80022001)(76176999)(66066001)(50986999)(64706001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <49D71BE179719F48A42302B0A8E06DCB@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/NO9OVyLMxmwktFDQb4dCQ_Ntcqc Cc: Jeffrey Haas , "" , "" Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model 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, 16 May 2014 20:47:21 -0000 On May 1, 2014, at 5:17 AM, t.petch wrote: >=20 > Jeff >=20 > If I2RS updates the routing table, do we expect it to persist for any > length of time? That is, the routing table is stable, the result of the > convergence of the routing protocols (and configuration) across the > relevant routers in the routing system and is reflected in the > operational state of a router. >=20 > A stable system in engineering is one that when perturbs, returns to its > original state. So make a change in one router and I would expect the > rest of the system to gang up on that router and reinstate the status > quo. For example, what I have in Adj-RIB-Out comes from someone else > via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I will > refresh it from Adj-RIB-In and be back where I started, while if I > change Adj-RIB-In, then the other router will repeat its advertisement - > and I will be back where I started. >=20 > If I think of the changes I might want to make, it seems to me that they > have to be changes to what NETCONF/YANG refer to as config and not to > the operational state. Ephemeral or persistent, which I take to refer > to what happens after a reboot, is then a question of which NETCONF > datastore I update, running or startup or both. >=20 > Tom Petch Tom, Good question, but IMO, I2RS agent should not change tables belonging to dy= namic routing protocols. Changes done by I2RS agent should have only device= impact, not network impact. If there is desire to change across network, t= hen each I2RS agent on each device should be updated. Dynamic protocol routing tables should be read only. I2RS agent should crea= te routing tables that can contain the same prefix as in the table belongin= g to dynamic protocol, so creating custom routing preference is possible. I= f we really want to allow full manipulation of dynamic protocol routing tab= les, I think some extensions to routing protocols would be required. Dean From nobody Fri May 16 14:12: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 2BD101A0119 for ; Fri, 16 May 2014 14:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 j10tSD2faTmD for ; Fri, 16 May 2014 14:12:12 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D9E1A0080 for ; Fri, 16 May 2014 14:12:12 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so1593283wib.5 for ; Fri, 16 May 2014 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=7uPsW55EZfdTghZE+bQQY4PtGlC+k7FRmmn76UhMoKc=; b=R6X9i4vPnerCytcmL0wx08i18tbecuYdQczOok51D4UzoraZ6fGt0E606mPr33DuLa +YgSxQLWbqVpkPqQE1UJGeZpRnefL0AkR+BD/CzFbjTAVc8X7UIpX3cEtSu7n8aE+hvd fgy8weAcNOMwD0sBmi2bRczZHfj6JUxJanqICs+vJLnE4t4ID23gZvjkAieD1vFb7z3c aUy/HGuFBbIse0RSruVC4uIYwGQ1KPuQkO9rp5uUhlxc4SnHldH0pfWYGBpnIyCxSjCv HA+0mRVMoP6uZrrdAiNrg6HHEXGvYI7oYFqrfBDQgLGsGEAAhhIDBw/FvI0aU46+kiIP 3kAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=7uPsW55EZfdTghZE+bQQY4PtGlC+k7FRmmn76UhMoKc=; b=Mdo2Uag/0LMbhfnU9ennJ0SEaMwpu5KhcbYILGc7VIy4bHLxAyRmk062+07gnjSAf7 E6tDK5NaJYOvg9t4ip0NGrM6sRfiIJHaqt4z9k8BrGJqOL5u5suhKvF3N6M0+zN3LsBs IbL8FFY8YyONDfcWJoQ5K/vzXICSQUQkviInSZgsxSJ1nG8MiZQ2F6LOAVxASOVVoacI e+V4JeBQzlAxfWZJTAQLhpL4tmzZGkAfw6KOXuluIT0VzprtPF37eYGjvsXLrJLjMZwl PdtAEoeCbezGD8Dln8+rv3w19Fbfl6oYEYLSqDeBBOjoyYwx/NwO2jnpXcJFUVLSDi0g sKEg== X-Gm-Message-State: ALoCoQnjhqma5CSYdI2CJzSeXku48zYEqaXeKpxnr2/NlNTjwJFpTSzuK2mr0W8SBESn1qaV21lY X-Received: by 10.180.7.198 with SMTP id l6mr103102wia.52.1400274723801; Fri, 16 May 2014 14:12:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.201 with HTTP; Fri, 16 May 2014 14:11:23 -0700 (PDT) From: Edward Crabbe Date: Fri, 16 May 2014 14:11:23 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=f46d044287c0803a0404f98add59 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NKJ7nL8zu0z_X1mviVSkCSzCxaA Subject: [i2rs] working group last call: draft-atlas-i2rs-architecture 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, 16 May 2014 21:12:14 -0000 --f46d044287c0803a0404f98add59 Content-Type: text/plain; charset=ISO-8859-1 Hello all; Jeff and I would like to start the two week working group last call for draft-atlas-i2rs-architecture. The document may be found here: http://tools.ietf.org/html/draft-ietf-i2rs-architecture-03 The editors and authors are advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call will end on Friday, 5/30/14 best, -ed --f46d044287c0803a0404f98add59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all;

Jeff and I would like to start the two w= eek working group last call for draft-atlas-i2rs-architecture. The document= may be found here:

http://tools.ietf.org/html/draft-ietf-i2rs-architect= ure-03


The editors and authors are advised to try to resolve as many of th= e
comments as possible (on the mailing list) as they come in, but not to=
post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call will end on Frid= ay, 5/30/14

best,
=A0 =A0-ed =A0
--f46d044287c0803a0404f98add59-- From nobody Fri May 16 14:16: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 D26C91A0151 for ; Fri, 16 May 2014 14:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 d2iQpN1lyQ-C for ; Fri, 16 May 2014 14:16:13 -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 3FE621A0119 for ; Fri, 16 May 2014 14:16:13 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so5552423wgh.19 for ; Fri, 16 May 2014 14:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=jrNXt5JYkkucAsVf763T2vP0B0183MP8DdTI5D3xHLg=; b=ok0Walt2nOqUB/kSr0KA5j9s+y1W6U25n2tuJo2a5zHx1owZisCuiX/pgs28CI+MRL 8uEPyxMy+7XfZyvmShjiu10szuDzfQcfceHfHjoQ4yEdexILix0hLF1LW2pOl0DPBCym cXXPxqlNbxCPQsIZb5ga13/tgG0dvQ17GmSjIKv7U4OwhodxcWWy5T8y4lfve973PMpf xpBhQtwBRRDgmjvOT15+pfUZhdFlSf5QJD55KmWN2pLiqQNGA13+d4aE3L0iIo66huZM pRWND/tsQ7zw1q1LjIRwm5g46VsRZFTIf/jzzcRQmd9oFs6JHD4if1OmuFToSMne7n6Z XQsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=jrNXt5JYkkucAsVf763T2vP0B0183MP8DdTI5D3xHLg=; b=ci+qjkD2q1YRfb1+L6nwzNc48ST5qqfl37tbQP1USVjNk1CPYohoFtZKglIHgW2/oV 8P7XKilTuMQe8zSBFKmu8fBHVAsPMQMhRrgy9cjmkwN7LbTovtF79WoXCWxxet10VVXa WFyQiY467OXLM2WTMhPfG1AvMSSa/wVfFiJs7h1uVxXvn+v8HsQk7b2aWAgHH3Z6s8QU SMEXAVvIt07vZkEGnQS5f97IbtPdvQRhr6yml9tLhSrAPiL2z6LXcRpNEMOzfh0xNrWS KaCFYAZXXF7ZQDX+dSQMmCqs0E1ozG06Plt1llddMCt2U+jJIpfSKMpV3AaZmrxFOgW5 E9Iw== X-Gm-Message-State: ALoCoQnXrgEt9lN/blQG8fuLHHk6A5Pi3S2ct/PiAPxJ7p89da6Femc0xLq+CfX9VH/+gpf+zXdC X-Received: by 10.194.220.42 with SMTP id pt10mr4447034wjc.60.1400274964703; Fri, 16 May 2014 14:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.201 with HTTP; Fri, 16 May 2014 14:15:24 -0700 (PDT) From: Edward Crabbe Date: Fri, 16 May 2014 14:15:24 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1b680dc24ad04f98aeba6 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wXgSGCGA4oQLA2ikotC8bsH0_5g Subject: [i2rs] working group last call: draft-atlas-i2rs-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, 16 May 2014 21:16:15 -0000 --001a11c1b680dc24ad04f98aeba6 Content-Type: text/plain; charset=ISO-8859-1 Hello all; Jeff and I would like to start the two week working group last call for draft-atlas-i2rs-problem-statement. The document may be found here: http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02 The editors and authors are advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call will end on Friday, 5/30/14 best, -ed --001a11c1b680dc24ad04f98aeba6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all;

Jeff and I would like to start the two w= eek working group last call for draft-atlas-i2rs-problem-statement. =A0The = document may be found here:

http://tools.ietf.org/html/draft-atlas= -i2rs-problem-statement-02

The editors and authors are advised to try to resolve as many of thecomments as possible (on the mailing list) as they come in, but not to
= post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call will end on Friday, 5/30/14

=
best,
=A0 =A0-ed =A0
--001a11c1b680dc24ad04f98aeba6-- From nobody Fri May 16 14:18: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 C85691A0119 for ; Fri, 16 May 2014 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 xfwzYf8sHAc7 for ; Fri, 16 May 2014 14:18:51 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45821A00FF for ; Fri, 16 May 2014 14:18:51 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so4898305yha.12 for ; Fri, 16 May 2014 14:18:44 -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=7zD7T2dP3OHMH4tB5p9sMTzKem4yJxneJEula3B/WLU=; b=aQZnoMEgSNkA9MTWHWE39EUfIDXmo5tpvJ2k/ugXgI3KMn2iZdJQIsIfbEzrdtov+Z 3PO8McgunCBBL2muSnsRwJfPU7Mg4SnmVgBrvM8VOaCKWh6mlael496Kx1AwNPoKfDPC /lif53gegXAP7C15c723Hywl+lHlI7omywmFpL4LKXrAfr9NYbZ5hmU7qcjtiY0u21Yw s4UVLC3607X/5+Ulgwu504SxY0o77uB7wwLJoPs127D645iP8tIhmbOpem15lPKCK1Bz jDukel3MMcTRe0qAmV61SK6ObrpxlJYoA/gCnsX/OC+DppEG7YPuqruNKugZGo/8pD3h 9xoQ== MIME-Version: 1.0 X-Received: by 10.236.150.205 with SMTP id z53mr29206709yhj.75.1400275123980; Fri, 16 May 2014 14:18:43 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Fri, 16 May 2014 14:18:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 May 2014 17:18:43 -0400 Message-ID: From: Alia Atlas To: Dean Bogdanovic Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/SiaWUfCuIA5_wR5yC8ShMDmLcRk Cc: Thomas Nadeau , Alia Atlas , "" , "wardd@cisco.com" Subject: Re: [i2rs] draft-ietf-i2rs-problem-statement-01 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, 16 May 2014 21:18:54 -0000 Hi Dean, Sorry for the long delay :-( I got felled by an ear infection. Responses in-line. On Tue, May 6, 2014 at 7:05 PM, Dean Bogdanovic wrote: > Alia, Tom, Dave, > > Have few comments on chapter 5 in the draft > > The following requirement is fine, but some consideration have to be put in. > Example, creating a filter construct or routing table has to be finished, > before the next operation like add term to the filter or add route to the > routing table is possible. > > Multiple Simultaneous Asynchronous Operations: A single application > should be able to send multiple operations via I2RS without being > required to wait for each to complete before sending the next. > > So would suggest changing from multiple operations to multiple independent > operations [Alia] Agreed and changed. > High-throughput is always nice to have, but the quantification is a bit > wishy washy. [Alia] I know - it varies based on use-case and what's being controlled. > High-Throughput: At a minimum, the I2RS Agent and associated router > should be able to handle a considerable number of operations per > second above what basic Netconf or a propretiary CLI can. > > What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over > NETCONF. Question: what is RPC doing? Is it simple operational get or large > config push? Or some other complex RPC? > There is also difference in creating logical interfaces and adding term to a > filter or adding route to a routing table. Creating interface is most taxing > one and adding term is fastest create operation. IMO, NETCONF has no problem > with throughput, it is the instrumentation and that is something we should > focus in I2RS. > What constructs do we want to control via I2RS and depending on that, make > sure that the protocol can sustain max throughput. [Alia] I know it depends on the back-end as well as the protocol. Remember this is the problem-statement and these are desired aspects. I've been trying to encourage less wishy-washy numbers for use-cases, but without much success. Should I just claim a goal of a sustained rate of 10000 simple operations/sec? OR bursts? [Alia] I'll update it to: "At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second (for example 10,000 per second to handle many individual subscriber routes changing simultaneously). " I'd like better wording and example though. > In the next chapter you are mentioning > > Responsive: It should be possible to complete simple operations > within a sub-second time-scale. > > > Here you are stating simple operation, so why not define few simple > operations and put some quantification with it (in the below examples I'm > pulling the numbers out of my hat) > > example: > > read routes - single prefix per transaction < 0.5sec > - multiple prefixes per transaction < time on the wire + 0.5sec > add route - single prefix per transaction < 0.5 sec > - multiple prefixes per transaction 1000 routes/sec > > get filter info - single filter per transaction < 0.5sec > - multiple filters and terms per transaction < time on the wire + 0.5sec > create filter - single filter per transaction < 0.5 sec > - multiple filters per transaction 2000/sec > add term to filter - single term per transaction < 0.5sec > - multiple terms per transaction 3000/sec > > get interface info - single interface per transaction < 0.5 sec > - multiple interfaces per transaction < time on the wire + 0.5 sec > create interface - single interface per transaction < 0.5 sec > - multiple interfaces per transaction 100/sec [Alia] Hmm, I think this is too much detail for a problem-statement. What about for responsive: "Within a sub-second time-scale, it should be possible to complete simple operations (e.g. reading or writing a single prefix)." > I'm thinking how can you do assurance for i2rs. It looks as it is covered in > following paragraph > > Scalable, Filterable Information Access: To extract information in a > scalable fashion that is more easily used by applications, the > ability to specify filtering constructs in an operation requesting > data or requesting an asynchronous notification is very valuable. > > > but it is not spelled out. [Alia] Can you clarify please? > Dean > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri May 16 14:21: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 1086B1A0157 for ; Fri, 16 May 2014 14:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Sr7KrWPXiQds for ; Fri, 16 May 2014 14:21:36 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A8F1A0151 for ; Fri, 16 May 2014 14:21:35 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id 29so4962384yhl.9 for ; Fri, 16 May 2014 14:21:28 -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=KyIhjPdnwRdyhOjpqS8nMIAYSALNyS5ucgBJXQlu4fw=; b=H5GkZrerxY0RycKbDFKRLPqC+bKF5FZwKgxDy3GHEzX3VoMtYxdJBEdlF8sxwKnEXw G/kJkkTvtZ/bBNF3/0jLKwSj+gVtinKn6DKHiph46KuThAZAyVh3hG8enulZAbPic2K4 ntydkQ/ujwBeZxQeaR2T6RFdqWetrogt+AzANvMxEoshxl6SypF+nFbxUecx3iAZ3IqU VYq4D6WhGUbl0qGzvMVC2BpNgK0f7zZ27DyWgB42QW7XF5gEa00AaZTAW1u9Ut41Z9Q2 go5za+janBD9K94azUuDEZSwtRjhuAJ2IpfdVvP0fElRbEcqBOIRDyD/C7ckbaxAYPoe 3Row== MIME-Version: 1.0 X-Received: by 10.236.108.176 with SMTP id q36mr29354657yhg.18.1400275288276; Fri, 16 May 2014 14:21:28 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Fri, 16 May 2014 14:21:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 May 2014 17:21:28 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/TetmOpX0DDKMWMOILVFYCwRhyTQ Cc: Thomas Nadeau , "wardd@cisco.com" , Alia Atlas , Dean Bogdanovic , "" Subject: Re: [i2rs] draft-ietf-i2rs-problem-statement-01 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, 16 May 2014 21:21:38 -0000 Jamal, I'd like to get some good numbers for use-cases to put in. For operations, it's not clear to me that they will always be batched in bulk as much as is done for down to the forwarding plane - I think aspiring to 100,000s ops/sec is a bit unlikely unless it is carefully crafted with good bulk operations. I'm putting in 10,000 as being more than we can generally do now with NetConf or CLI - but I'd be happy to see a use-case that justifies more. Alia On Wed, May 7, 2014 at 9:13 AM, Jamal Hadi Salim wrote: > On Tue, May 6, 2014 at 7:05 PM, Dean Bogdanovic wrote: > >> High-throughput is always nice to have, > > Is it "nice to have" or "must have"? > >>but the quantification is a bit wishy washy. >> > > Agreed. > >> High-Throughput: At a minimum, the I2RS Agent and associated router >> should be able to handle a considerable number of operations per >> second above what basic Netconf or a propretiary CLI can. >> >> What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over >> NETCONF. Question: what is RPC doing? Is it simple operational get or large >> config push? >> Or some other complex RPC? >> There is also difference in creating logical interfaces and adding term to a >> filter or adding route to a routing table. Creating interface is most taxing >> one and adding term is fastest create operation. >>IMO, NETCONF has no problem >> with throughput, it is the instrumentation and that is something we should >> focus in I2RS. >> What constructs do we want to control via I2RS and depending on that, make >> sure that the protocol can sustain max throughput. >> > > We need to pick something as a metric since as you say it will depend on the > object type. The RIB table sounds like a reasonable object to standardize on. > Pick a number like 1M table entries (large enough so as to be measurable). > > Throughput: > This refers to some bulk table create/updates/dumps. Very few transactions/sec > are needed, essentially in this case the agent and client are engaged > in batching the entries > they send to the other party. > To handwave some numbers performance numbers: > I am going to pick say 10s to 100s of thousands rows per/sec. > We need bidirectional numbers. > > Transactions rate: > This is a measure of request/response. Again using the RIB example - > this would mean taking > each of the 1M rows and send them one at a time (i.e window of 1). Eg > a request from the > client to create/update is sent to the agent and when a success > response is received by the > client the next request is issued ..... until all of 1M transactions > are complete > >> In the next chapter you are mentioning >> >> Responsive: It should be possible to complete simple operations >> within a sub-second time-scale. >> >> >> Here you are stating simple operation, so why not define few simple >> operations and put some quantification with it (in the below examples I'm >> pulling the numbers out of my hat) >> >> example: >> >> read routes - single prefix per transaction < 0.5sec >> - multiple prefixes per transaction < time on the wire + 0.5sec >> add route - single prefix per transaction < 0.5 sec >> - multiple prefixes per transaction 1000 routes/sec >> >> get filter info - single filter per transaction < 0.5sec >> - multiple filters and terms per transaction < time on the wire + 0.5sec >> create filter - single filter per transaction < 0.5 sec >> - multiple filters per transaction 2000/sec >> add term to filter - single term per transaction < 0.5sec >> - multiple terms per transaction 3000/sec >> >> get interface info - single interface per transaction < 0.5 sec >> - multiple interfaces per transaction < time on the wire + 0.5 sec >> create interface - single interface per transaction < 0.5 sec >> - multiple interfaces per transaction 100/sec >> > > We need to have some quantification numbers. They dont have to be precise > but could be in the ranges. I think what you describe above matches my thinking. > Your "multiple per transaction" is essentially a batching artifact > which falls under > "throughput" metric. The " single per transaction" is a transaction metric. > > Having said that: I know you gave those numbers as examples, but they > are way too low ;-> > >> I'm thinking how can you do assurance for i2rs. It looks as it is covered in >> following paragraph >> >> Scalable, Filterable Information Access: To extract information in a >> scalable fashion that is more easily used by applications, the >> ability to specify filtering constructs in an operation requesting >> data or requesting an asynchronous notification is very valuable. >> >> >> but it is not spelled out. >> > > I would consider the throughput, transaction rate and latency in that > category as > well. > > cheers, > jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri May 16 15:00: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 8349A1A01E6 for ; Fri, 16 May 2014 15:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 JAg6a0_dk3Pq for ; Fri, 16 May 2014 15:00:47 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FA71A0191 for ; Fri, 16 May 2014 15:00:46 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id c11so2395267lbj.10 for ; Fri, 16 May 2014 15:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fFTnkFPbU6201Af83CfcxTMVUSlwgSHfwxEZIvZZVMc=; b=WBpUzhype9IhFktsntEPlAstfHB4OctNTY9Vnh+fUDfu7Vzfr3hVZ7S/WxPlZWXWLc myTAAdrtc95upVUQMYzJCP3BWB3bOoTUenXHpeZzAqhNNyyJvBmE2RBIw2T8iv2AKJN5 nNHvWcjqrIrSIsM+2s46oK6N0NVRGZDGSzr+A0vRk0/Ut59++VrfU9ossRL1sjiIulKs vBuAxkC7w6Sb4lOktC2AKsldqP3JeiV+RY2kes3v0zNuOEzE7edXIaI6NVYUPuK2D8QS MkIWu6hIoVluCaKUrQmKOTzHPkFp/QxLm8T3Ndp7n/m3OgTB9vhngxA79qRLEnvDV6mE Xoyg== X-Received: by 10.152.143.3 with SMTP id sa3mr3619152lab.53.1400277638127; Fri, 16 May 2014 15:00:38 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.114.161.81 with HTTP; Fri, 16 May 2014 15:00:07 -0700 (PDT) In-Reply-To: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> From: Sriganesh Kini Date: Fri, 16 May 2014 15:00:07 -0700 X-Google-Sender-Auth: 9HC3x6S2ZOAfuK7N6rtDqQm1G7k Message-ID: To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a11345c0835265004f98b8bfd Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uhz3BZ0p1oGbNnAKc4VoejFJ4o4 Cc: Jeffrey Haas , "" , "" , "t.petch" Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model 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, 16 May 2014 22:00:49 -0000 --001a11345c0835265004f98b8bfd Content-Type: text/plain; charset=UTF-8 Dean, see inline On Fri, May 16, 2014 at 1:47 PM, Dean Bogdanovic wrote: > > On May 1, 2014, at 5:17 AM, t.petch wrote: > > > > > Jeff > > > > If I2RS updates the routing table, do we expect it to persist for any > > length of time? That is, the routing table is stable, the result of the > > convergence of the routing protocols (and configuration) across the > > relevant routers in the routing system and is reflected in the > > operational state of a router. > > > > A stable system in engineering is one that when perturbs, returns to its > > original state. So make a change in one router and I would expect the > > rest of the system to gang up on that router and reinstate the status > > quo. For example, what I have in Adj-RIB-Out comes from someone else > > via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I will > > refresh it from Adj-RIB-In and be back where I started, while if I > > change Adj-RIB-In, then the other router will repeat its advertisement - > > and I will be back where I started. > > > > If I think of the changes I might want to make, it seems to me that they > > have to be changes to what NETCONF/YANG refer to as config and not to > > the operational state. Ephemeral or persistent, which I take to refer > > to what happens after a reboot, is then a question of which NETCONF > > datastore I update, running or startup or both. > > > > Tom Petch > > Tom, > > Good question, but IMO, I2RS agent should not change tables belonging to > dynamic routing protocols. Yes, the I2RS agent should not provide an interface to change a table if there is no use-case to support it. A dynamic routing protocol's route-table (e.g. IGP's route-table that it downloads to RIB) has no use-case to change it by another client. A read-only interface should be sufficient. > Changes done by I2RS agent should have only device impact, not network > impact. If there is desire to change across network, then each I2RS agent > on each device should be updated. > It is not simple to classify a change to a device as having an impact scoped to just that device. E.g a route that is added to a device with a different preference can have network-wide traffic impact. > > Dynamic protocol routing tables should be read only. I2RS agent should > create routing tables that can contain the same prefix as in the table > belonging to dynamic protocol, so creating custom routing preference is > possible. The RIB is the table where multiple clients (including multiple dynamic routing protocols) can create routes in order for it to be downloaded to the FIB. 'Preference' must be used to add multiple routes for the same prefix. The clients of the RIB can be dynamic routing protocols or clients that implement other use-cases. The RIB IM is designed to interface with all such clients. > If we really want to allow full manipulation of dynamic protocol routing > tables, I think some extensions to routing protocols would be required. > I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case. Sri > > Dean > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11345c0835265004f98b8bfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dean, see inline


On Fri, May 16, 2014 at 1:47 PM, Dean Bogdanovic <dean= b@juniper.net> wrote:

On May 1, 2014, at 5:17 AM, t.petch <ietfc@btconnect.com> wrote:

>
> Jeff
>
> If I2RS updates the routing table, do we expect it to persist for any<= br> > length of time? =C2=A0That is, the routing table is stable, the result= of the
> convergence of the routing protocols (and configuration) across the > relevant routers in the routing system and is reflected in the
> operational state of a router.
>
> A stable system in engineering is one that when perturbs, returns to i= ts
> original state. =C2=A0So make a change in one router and I would expec= t the
> rest of the system to gang up on that router and reinstate the status<= br> > quo. =C2=A0For example, what I have in Adj-RIB-Out comes from someone = else
> via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I wil= l
> refresh it from Adj-RIB-In and be back where I started, while if I
> change Adj-RIB-In, then the other router will repeat its advertisement= -
> and I will be back where I started.
>
> If I think of the changes I might want to make, it seems to me that th= ey
> have to be changes to what NETCONF/YANG refer to as config and not to<= br> > the operational state. =C2=A0Ephemeral or persistent, which I take to = refer
> to what happens after a reboot, is then a question of which NETCONF > datastore I update, running or startup or both.
>
> Tom Petch

Tom,

Good question, but IMO, I2RS agent should not change tables belonging to dy= namic routing protocols.

Yes, the I2RS age= nt should not provide an interface to change a table if there is no use-cas= e to support it. A dynamic routing protocol's route-table (e.g. IGP'= ;s route-table that it downloads to RIB) has no use-case to change it by an= other client. A read-only interface should be sufficient.
=C2=A0
Changes done by I2RS agent = should have only device impact, not network impact. If there is desire to c= hange across network, then each I2RS agent on each device should be updated= .

It is not simple to classify a change to a= device as having an impact scoped to just that device. E.g a route that is= added to a device with a different preference can have network-wide traffi= c impact.=C2=A0
=C2=A0

Dynamic protocol routing tables should be read only. I2RS agent should crea= te routing tables that can contain the same prefix as in the table belongin= g to dynamic protocol, so creating custom routing preference is possible. <= /blockquote>

The RIB is the table where multiple clients (including = multiple dynamic routing protocols) can create routes in order for it to be= downloaded to the FIB. 'Preference' must be used to add multiple r= outes for the same prefix. The clients of the RIB can be dynamic routing pr= otocols or clients that implement other use-cases. The RIB IM is designed t= o interface with all such clients.
=C2=A0
If we really want to allow = full manipulation of dynamic protocol routing tables, I think some extensio= ns to routing protocols would be required.

I am yet to see a use-case that requires d= irect manipulation of a single dynamic routing-protocol-instance specific r= oute table by something other than that protocol. I don't believe there= should be any such case.


Sri
=C2=A0

Dean


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

--001a11345c0835265004f98b8bfd-- From nobody Mon May 19 16:38: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 9D31F1A0446 for ; Mon, 19 May 2014 16:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 EDzNZ9WCG4xp for ; Mon, 19 May 2014 16:38:31 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6831A020E for ; Mon, 19 May 2014 16:38:30 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so7456572yho.15 for ; Mon, 19 May 2014 16:38:30 -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=2jRERUVyz2ljw4n1hhU5iK85DPUmkzKuepJp4egwKE0=; b=PAFQYzoJGI1D+/fbvExXHZFi2b3jK9umA35C+awER1xEBBFQGMfKFTEVOEgMl8cpKh xHj6LJiJVQ9r0OPTfQZ6ZJjdo0HXlAwlgHRYISJlldjP17ghB30QzyRhtp83ej7i+drW AWA+8XaMTf5ZymjoXGv+l0niA8q+OHyqVbvoQxLqkCxZoWlUZEvdoEZq37Mx/A2xSgo1 lgyi7WnveeuqKD/zHS5QoMZORMgh6gzw4ft6FvKTzDSkkx+3JlfF53sQ5vAyQ0niDIu6 3iCpQNnMq/3dUtUO9+IYecDD0O1ZJHKRo3bGvnHep40CugvRngrs6LQ+Hk+wQoeuAwrg A71w== MIME-Version: 1.0 X-Received: by 10.236.105.141 with SMTP id k13mr9257583yhg.141.1400542710064; Mon, 19 May 2014 16:38:30 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Mon, 19 May 2014 16:38:29 -0700 (PDT) In-Reply-To: <20140501004916.GB1256@pfrc> References: <535FB50A.6090608@joelhalpern.com> <000f01cf6467$187b0c00$49712400$@ndzh.com> <5360FD05.6030407@joelhalpern.com> <20140501004916.GB1256@pfrc> Date: Mon, 19 May 2014 19:38:29 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ghrc1_O_a7xLlbKL7CmL_dabZ2E Cc: "i2rs@ietf.org" , Andy Bierman Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 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, 19 May 2014 23:38:32 -0000 When I was working on the architecture , NACM seemed a likely place to start if YANG is used. Certainly, it has all the functionality that I was looking for. Alla On Wed, Apr 30, 2014 at 8:49 PM, Jeffrey Haas wrote: > On Wed, Apr 30, 2014 at 07:02:19AM -0700, Andy Bierman wrote: >> On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern wrote: >> NETCONF and RESTCONF already have a standard Role-Based Access Control >> Model, >> called NACM (RFC 6536). Does the I2RS WG plan to create its own ACM, leave >> it >> to vendors, or something else? > > Regardless of the data model and protocol, I believe we'll need something > like this for I2RS. Section 3.2.1 of RFC 6536 covers properties that I > would suspect would be requirements for any such system. While Joel is > correct that we're not to the point of worrying about the details yet until > we choose, I suspect that it's not too hard to read the remaining content of > section 3 in the context of somewhat more abstract protocol operations and > derive impacts on requirements. > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon May 19 17:03: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 BDA161A01D9 for ; Mon, 19 May 2014 17:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 HA5pkwQnZgT5 for ; Mon, 19 May 2014 17:03:10 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C761A0155 for ; Mon, 19 May 2014 17:03:10 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id q9so5128717ykb.35 for ; Mon, 19 May 2014 17:03:09 -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=wcKH97WvKnhP6eSZrQ12CY94apNgvU0ku4D3Udcn9Jc=; b=pBZ+gZHrCwWRISrT2nnMCbMnVqfVy26HYGSFp87HetqT5+06eRLczD1b+wGtFPEapp /Sf47PtjaKY4qSWAy18VhgOa1fp+qCZZtqsT35GDYa11znWd+GqQnGLQxxlTevYNg85O hARqi2E1uNMrm5pRfK2E0MmV2Zqph9bzLi+qnlzuZB15vK7CHFnHb57fx0emXCcM+LxP rcn6RTZ0ksV7v9LZOPQ7plGFbgafrR0GYaUYHyeQcHfLxKTIwC4YoiN6zP7pVdC0Fy/W fEQyikCDIF5jeEp13ZI9I2tx1wHVCSHSOB7lb0oTNx4sAzzqYSRqwe6dKtVChoWL61Ux XehQ== MIME-Version: 1.0 X-Received: by 10.236.108.176 with SMTP id q36mr57334525yhg.18.1400544189532; Mon, 19 May 2014 17:03:09 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Mon, 19 May 2014 17:03:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 May 2014 20:03:09 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/VitsH82MuOaG1z-RFsllgCEfog8 Cc: Jeffrey Haas , i2rs , Edward Crabbe , Dean Bogdanovic , Andy Bierman Subject: Re: [i2rs] protocol requirements 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: Tue, 20 May 2014 00:03:11 -0000 Jamal, This looks like a very good start at pulling some requirements from the architecture . I do think that multiple transport sessions and types are important . There are also a few parts on data model relationship . Thanks , Alia On Sun, May 4, 2014 at 10:48 AM, Jamal Hadi Salim wrote: > Jeff, > > I could add this to the wiki and we could keep updating it. > Next i will do something similar for the model. > > Dean/Andy - Feel free to throw rotten tomatoes; at least that way we > have something to talk about. > > cheers, > jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue May 20 08:06:46 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 8DC321A0386 for ; Tue, 20 May 2014 08:06:45 -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_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 tY-a-uPcT8S6 for ; Tue, 20 May 2014 08:06:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D38B1A0395 for ; Tue, 20 May 2014 08:06:43 -0700 (PDT) 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.944.11; Tue, 20 May 2014 15:06:34 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.184]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.184]) with mapi id 15.00.0944.000; Tue, 20 May 2014 15:06:34 +0000 From: Dean Bogdanovic To: Sriganesh Kini Thread-Topic: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model Thread-Index: AQHPcVKFnXwswyt5aE6k6az9L6i0/ptJl4YA Date: Tue, 20 May 2014 15:06:34 +0000 Message-ID: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.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-originating-ip: [66.129.241.14] x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(189002)(199002)(24454002)(377454003)(16236675002)(101416001)(62966002)(15975445006)(83716003)(81342001)(19580395003)(33656001)(83322001)(21056001)(19580405001)(85852003)(76482001)(83072002)(92566001)(77156001)(92726001)(99286001)(50226001)(36756003)(66066001)(80022001)(50986999)(74502001)(76176999)(99396002)(74662001)(20776003)(31966008)(4396001)(64706001)(224313003)(82746002)(86362001)(93916002)(79102001)(81542001)(224303002)(87936001)(87286001)(46102001)(88136002)(2656002)(77982001)(89996001)(57306001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: multipart/alternative; boundary="_000_F6925CE1386E4528A88BEBF2D2E452A7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gHVx0XB3V9Qb9-z_L_3ruXFu4M4 Cc: Jeffrey Haas , "" , "" , "t.petch" Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model 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: Tue, 20 May 2014 15:06:45 -0000 --_000_F6925CE1386E4528A88BEBF2D2E452A7junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sri, See inline On May 16, 2014, at 6:00 PM, Sriganesh Kini > wrote: Dean, see inline Changes done by I2RS agent should have only device impact, not network impa= ct. If there is desire to change across network, then each I2RS agent on ea= ch device should be updated. It is not simple to classify a change to a device as having an impact scope= d to just that device. E.g a route that is added to a device with a differe= nt preference can have network-wide traffic impact. How can I explain this better. The static route on device will be routed to= the next destination, but at the next destination the dynamic protocol wil= l take effect, unless, another static route directs the traffic differently= . Makes sense? Dynamic protocol routing tables should be read only. I2RS agent should crea= te routing tables that can contain the same prefix as in the table belongin= g to dynamic protocol, so creating custom routing preference is possible. The RIB is the table where multiple clients (including multiple dynamic rou= ting protocols) can create routes in order for it to be downloaded to the F= IB. 'Preference' must be used to add multiple routes for the same prefix. T= he clients of the RIB can be dynamic routing protocols or clients that impl= ement other use-cases. The RIB IM is designed to interface with all such cl= ients. thank you for correcting me. If we really want to allow full manipulation of dynamic protocol routing ta= bles, I think some extensions to routing protocols would be required. I am yet to see a use-case that requires direct manipulation of a single dy= namic routing-protocol-instance specific route table by something other tha= n that protocol. I don't believe there should be any such case. I completely agree with you. Sri Dean _______________________________________________ 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_F6925CE1386E4528A88BEBF2D2E452A7junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <22C28170F985644AA9664728766FACC6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Sri,

See inline

On May 16, 2014, at 6:00 PM, Sriganesh Kini <sriganesh.kini@ericsson.com>
 wrote:

Dean, see inline



Changes done by I2RS agent should have only device impact, not network impa= ct. If there is desire to change across network, then each I2RS agent on ea= ch device should be updated.

It is not simple to classify a change to a device as having an impact = scoped to just that device. E.g a route that is added to a device with a di= fferent preference can have network-wide traffic impact.

How can I explain this better. The static route on device will be routed to= the next destination, but at the next destination the dynamic protocol wil= l take effect, unless, another static route directs the traffic differently= . Makes sense?
 
 

Dynamic protocol routing tables should be read only. I2RS agent should crea= te routing tables that can contain the same prefix as in the table belongin= g to dynamic protocol, so creating custom routing preference is possible.

The RIB is the table where multiple clients (including multiple dynami= c routing protocols) can create routes in order for it to be downloaded to = the FIB. 'Preference' must be used to add multiple routes for the same pref= ix. The clients of the RIB can be dynamic routing protocols or clients that implement other use-cases. The R= IB IM is designed to interface with all such clients.

thank you for correcting me.
 
If we really want to allow full manipulation of dynamic protocol routing ta= bles, I think some extensions to routing protocols would be required.

I am yet to see a use-case that requires direct manipulation of a sing= le dynamic routing-protocol-instance specific route table by something othe= r than that protocol. I don't believe there should be any such case.

I completely agree with you.


Sri
 

Dean


_______________________________________________
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

--_000_F6925CE1386E4528A88BEBF2D2E452A7junipernet_-- From nobody Tue May 20 09:23: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 2FC9F1A0780 for ; Tue, 20 May 2014 09:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 MSvQ5VVAtk7r for ; Tue, 20 May 2014 09:23:45 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D031A01A5 for ; Tue, 20 May 2014 09:23:44 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ec20so613065lab.12 for ; Tue, 20 May 2014 09:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=OflHUsXyyqOhVkv8hZz+c7ek8LKZ+P0F0u5svL8Jaac=; b=D7rbbLvw4LdigW0UXsTiR9Ku3gojTkHb0SbzJ+ToCylcgYzToryPXBJC1o5gGdkcuV ZT1tlc6ggdi4z4ellQi5gd8lqw22gPiB/PGiakqj0AiB3DaSsMFzySr67HJgNESZ4faG 5hHHztGSoxb5QBfTru4wUGY8bJ3mEAhqsSlvL1f2dVtAjXFaHs24IeyWJDUu9csfhtSL mc/p7r5dZ2ItMYmtkaOdjW7G+CLNX91RirB1Xk/w4+bxG5W89MqzLNAf2j/1vX14lvao 7T2JC9nShOUgKnWilXgmk8II11oNMdvFtbfCRmuUcJ8Omvf58hZeZYb8Fi2D7vpkSKcG DKPA== X-Received: by 10.152.18.133 with SMTP id w5mr3096000lad.60.1400603023198; Tue, 20 May 2014 09:23:43 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.114.161.81 with HTTP; Tue, 20 May 2014 09:23:13 -0700 (PDT) In-Reply-To: References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> From: Sriganesh Kini Date: Tue, 20 May 2014 09:23:13 -0700 X-Google-Sender-Auth: pwVNXnczu6Tbc5Nal6xyto5qfGE Message-ID: To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=089e01493d40ab502a04f9d74dc0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/CmEijENzJv4Uu3UrPgZeycXViIA Cc: Jeffrey Haas , "" , "" , "t.petch" Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model 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: Tue, 20 May 2014 16:23:46 -0000 --089e01493d40ab502a04f9d74dc0 Content-Type: text/plain; charset=UTF-8 On Tue, May 20, 2014 at 8:06 AM, Dean Bogdanovic wrote: > Changes done by I2RS agent should have only device impact, not network >> impact. If there is desire to change across network, then each I2RS agent >> on each device should be updated. >> > > It is not simple to classify a change to a device as having an impact > scoped to just that device. E.g a route that is added to a device with a > different preference can have network-wide traffic impact. > > > How can I explain this better. The static route on device will be routed > to the next destination, but at the next destination the dynamic protocol > will take effect, unless, another static route directs the traffic > differently. Makes sense? I think what you really wanted to say is - An I2RS agent must not interface with an I2RS agent on another network element. If an I2RS client requires to interface with I2RS agents on multiple network elements, it must do so itself without putting requirements on the I2RS agent on one network element to interface with the I2RS agent on another network element. Sri --089e01493d40ab502a04f9d74dc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, May 20, 2014 at 8:06 AM, Dean Bogdanovic <deanb@juniper.net>= ; wrote:
<= div class=3D"">
Changes done by I2RS agent should have only device impact, not network impa= ct. If there is desire to change across network, then each I2RS agent on ea= ch device should be updated.

It is not simple to classify a change to a device as having an impact = scoped to just that device. E.g a route that is added to a device with a di= fferent preference can have network-wide traffic impact.

How can I explain this better. The static route on device will be routed to= the next destination, but at the next destination the dynamic protocol wil= l take effect, unless, another static route directs the traffic differently= . Makes sense?

I think what you really wanted to say is - An I2RS agent must not= interface with an I2RS agent on another network element. If an I2RS client= requires to interface with I2RS agents on multiple network elements, it mu= st do so itself without putting requirements on the I2RS agent on one netwo= rk element to interface with the I2RS agent on another network element.


<= div class=3D"gmail_extra">Sri --089e01493d40ab502a04f9d74dc0-- From nobody Wed May 21 13:36: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 2EA231A03AF for ; Wed, 21 May 2014 13:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, 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 a79W1UCEFa5I for ; Wed, 21 May 2014 13:36:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DF6081A019B for ; Wed, 21 May 2014 13:36:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 92C58C26A; Wed, 21 May 2014 16:36:05 -0400 (EDT) Date: Wed, 21 May 2014 16:36:05 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140521203605.GM9789@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/TFCFZeBk4l2t4owM3bkj6hvFpHg Subject: [i2rs] Consensus on I2RS data modeling language and protocol 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, 21 May 2014 20:36:08 -0000 Working Group, We committed to spend the weeks following last session in London for IETF 89 to look at our proposed data modeling languages and protocols in more detail. While that conversation on the mail list didn't yield an explicit set of requirements (but thanks to Jamal for taking the first formal try at it), significant discussion occurred comparing and contrasting the benefits of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps in both proposals that would need to be addressed for use by I2RS. Each proposed mechanism had a few benefits in contrast to its counterpart, but none of these were overwhelming in scope. Our judgment of group consensus is that while both FORCES and Netconf/Yang could serve I2RS that there is substantially more support for the Netconf/Yang proposal. Part of this consideration includes elements of expediency such as existing open source tool chains and implementation experience of I2RS-like mechanisms in other organizations and vendors. Our near-term goals are to formally document the observed gaps in Netconf/Restconf and Yang with regard to I2RS uses and take them to their home working groups to be worked upon. After discussing this detail with our ADs, we can do so either in the form of documenting this upon the wiki or in the form of a requirements Internet-Draft. We welcome the chance to choose our form of agility for this effort. We will be forming a design team in the near future to work on the gap analysis and try to bring the necessary work to closure in short order. -- Ed and Jeff From nobody Thu May 22 08:23: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 52CB51A00B8 for ; Thu, 22 May 2014 08:23:11 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 g59qoFWyoDIB for ; Thu, 22 May 2014 08:23:09 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6BD1A016D for ; Thu, 22 May 2014 08:23:09 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ij19so4687458vcb.28 for ; Thu, 22 May 2014 08:23:07 -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:from:date :message-id:subject:to:cc:content-type; bh=AldVTrW/dRMYNRO6Yp+v/8l6V0taW26+PkORasY5PPA=; b=g9wJn9kwjiMUD5mR+Pk9JuBex86lREN/rZZdtiJsxqYPEDUoqw36cwkWrT0ocgvBvA 7DnO8/3S+trv0mpZ3K+kis80RfmGdleq5bLRWzywQTR+bfSasDsyogRJqRvgtdCR7TIV h2g03Edd0j8JzUf9v9MbzTVw0BvgkzJZoomuez1ofLINDfSUnHddUCb1BglxYulyc0bX Eav6f2KMsX6T+P7KIMXmU+NiWNuHUW1MnFtwqCJC+uaPzrm5+0jjQbtzx+n3QPerRSqS 6eEFvk9REJeeDd/R68E4hyutJqPfEYRRtMwqB8GnFjNUwiL0Q0/uqMnQWlGYAJibJAUo /IDg== X-Gm-Message-State: ALoCoQmpy2maIwAo/MKklfia3Ze5Q3A8TYYGPsH+/Z0YeC7kEOvRN+BoOelfDzGNW7vKeJecdpr4 X-Received: by 10.58.188.115 with SMTP id fz19mr1829669vec.40.1400772187664; Thu, 22 May 2014 08:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 08:22:47 -0700 (PDT) In-Reply-To: <20140521203605.GM9789@pfrc> References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 11:22:47 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/IqFBOsh8NTeJx_tYxC1vsqKnbqA Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 15:23:11 -0000 Jeff/Ed, First of all I want to thank you both; i think you both tried hard to provide the opportunity given the constraints. Second: I have no qualms with the WG moving forward - I understand progress MUST be made. Andy, no hard feelings I hope. Having said that, I would like to speak my mind. I am disappointed and I would like to address the two points described as cause for the decision. On the "more support" for netconf/yang: ================================ My view is this boils down to popularity contest as opposed to engineering requirements. I wouldnt call this a process breakdown in I2RS - just that in general the IETF allows the system to be very hackable. It is like money in politics. While I empathize with folks who have implemented netconf/yang and feel that is the path forward - i would argue the voting system is highly stacked. I know this is how the "game" has been played over the years - but for sometime now I feel like we need a new system for voting. Things should not be judged based on a simple +1 or a hum (I should have advertised somewhere for people to show up and "vote" for ForCES which would have been dishonest). Voting would have more more sense if there were clear requirements to begin with from which a clear checklist could be derived. There were no specific requirements. I am sure there was intent but assumptions were made that netconf/yang is the way to go from the get-go. There was not even effort to match against some requirements for netconf/restconf/yang when I put out a wiki update. There was not even an attempt to dis/credit what i listed as requirements. >From day one at the BOF, netconf and Yang were being presented as the answer. I remember standing up at the BOF mike and asking why solutions were being presented before requirements - IIRC the answer was i could present my own favorite protocol if i wanted to and that process would be followed. An engineering task requires explicit call out of requirements first. Note: I am not arguing for ForCES here - but it aint Netconf/restconf/Yang and neither do i think those will require a minor surgery to work (as per my view of the requirements). And from that perspective I am unhappy - I wish we actually used a matrix of some sort to prove me wrong but the answer seems like "we'll fix it". On "open source availability" ======================= The notion that because there is some open source implementation it qualifies some solution as legit is a red herring. 90% of IETF standards dont pass that smell test. There is no such requirement anywhere. There is *absolutely* no open source implementation of I2RS using netconf/restconf/yang. I *doubt* there is one in any organization anywhere on the globe. So this boils down to be a marketing gimmick in an engineering organization. Which is where my frustration comes in. Perhaps the starting point at IETF is to go back to the old days of implementing first as open source variant, get cohesion around it and then standardizing. I hope my views arent too harsh (I just wanted to feed that elephant in the room some peanuts). cheers, jamal On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: > Working Group, > > We committed to spend the weeks following last session in London for IETF 89 > to look at our proposed data modeling languages and protocols in more > detail. While that conversation on the mail list didn't yield an explicit > set of requirements (but thanks to Jamal for taking the first formal try at > it), significant discussion occurred comparing and contrasting the benefits > of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps in > both proposals that would need to be addressed for use by I2RS. > > Each proposed mechanism had a few benefits in contrast to its counterpart, > but none of these were overwhelming in scope. > > Our judgment of group consensus is that while both FORCES and Netconf/Yang > could serve I2RS that there is substantially more support for the > Netconf/Yang proposal. Part of this consideration includes elements of > expediency such as existing open source tool chains and implementation > experience of I2RS-like mechanisms in other organizations and vendors. > > Our near-term goals are to formally document the observed gaps in > Netconf/Restconf and Yang with regard to I2RS uses and take them to their > home working groups to be worked upon. After discussing this detail with > our ADs, we can do so either in the form of documenting this upon the wiki > or in the form of a requirements Internet-Draft. We welcome the chance to > choose our form of agility for this effort. > > We will be forming a design team in the near future to work on the gap > analysis and try to bring the necessary work to closure in short order. > > -- Ed and Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 22 09:14: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 984681A01EE for ; Thu, 22 May 2014 09:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XE0d6WeV9PsA for ; Thu, 22 May 2014 09:13:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293081A0217 for ; Thu, 22 May 2014 09:13:30 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 16:13:27 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0944.000; Thu, 22 May 2014 16:13:27 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [i2rs] Consensus on I2RS data modeling language and protocol Thread-Index: AQHPdTRlm1rPvZLwbkiU780/k5L0yJtMuPaAgAAOJ1w= Date: Thu, 22 May 2014 16:13:26 +0000 Message-ID: References: <20140521203605.GM9789@pfrc>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.227.71] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51694002)(377454003)(199002)(51704005)(24454002)(189002)(54356999)(77096999)(99286001)(76176999)(99396002)(101416001)(50986999)(83322001)(36756003)(15975445006)(2656002)(83716003)(19580395003)(4396001)(19580405001)(74502001)(82746002)(80022001)(87936001)(31966008)(74662001)(66066001)(21056001)(64706001)(81542001)(77982001)(92566001)(561944003)(86362001)(85852003)(46102001)(33656002)(79102001)(76482001)(81342001)(92726001)(83072002)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/TLF4HFM7m8LfUoQ2myTlQNirRkE Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 16:13:59 -0000 The other possibility is that FORCES is simply NQR. Sent from my iPhone > On May 22, 2014, at 11:24 AM, "Jamal Hadi Salim" wrot= e: >=20 > Jeff/Ed, >=20 > First of all I want to thank you both; i think you both tried hard to > provide the > opportunity given the constraints. > Second: I have no qualms with the WG moving forward - I understand progre= ss MUST > be made. Andy, no hard feelings I hope. >=20 > Having said that, I would like to speak my mind. I am disappointed and > I would like to address > the two points described as cause for the decision. >=20 > On the "more support" for netconf/yang: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > My view is this boils down to popularity contest as opposed to > engineering requirements. > I wouldnt call this a process breakdown in I2RS - just that in general > the IETF allows the system > to be very hackable. It is like money in politics. While I empathize with= folks > who have implemented netconf/yang and feel that is the path forward - > i would argue the > voting system is highly stacked. I know this is how the "game" has > been played over the > years - but for sometime now I feel like we need a new system for > voting. Things should not be > judged based on a simple +1 or a hum (I should have advertised > somewhere for people to > show up and "vote" for ForCES which would have been dishonest). > Voting would have more more sense if there were clear requirements to > begin with from which > a clear checklist could be derived. > There were no specific requirements. I am sure there was intent but > assumptions were made > that netconf/yang is the way to go from the get-go. > There was not even effort to match against some requirements for > netconf/restconf/yang > when I put out a wiki update. There was not even an attempt to > dis/credit what i listed as requirements. >> From day one at the BOF, netconf and Yang were being presented as the an= swer. > I remember standing up at the BOF mike and asking why solutions were > being presented before > requirements - IIRC the answer was i could present my own favorite > protocol if i wanted to > and that process would be followed. An engineering task requires > explicit call out of requirements > first. >=20 > Note: I am not arguing for ForCES here - but it aint > Netconf/restconf/Yang and neither do i think > those will require a minor surgery to work (as per my view of the > requirements). And from that > perspective I am unhappy - I wish we actually used a matrix of some > sort to prove me wrong > but the answer seems like "we'll fix it". >=20 > On "open source availability" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The notion that because there is some open source implementation it quali= fies > some solution as legit is a red herring. 90% of IETF standards dont > pass that smell test. > There is no such requirement anywhere. > There is *absolutely* no open source implementation of I2RS using > netconf/restconf/yang. > I *doubt* there is one in any organization anywhere on the globe. So > this boils down to be > a marketing gimmick in an engineering organization. Which is where my > frustration comes in. > Perhaps the starting point at IETF is to go back to the old days of > implementing first as open > source variant, get cohesion around it and then standardizing. >=20 > I hope my views arent too harsh (I just wanted to feed that elephant > in the room some peanuts). >=20 > cheers, > jamal >=20 >> On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: >> Working Group, >>=20 >> We committed to spend the weeks following last session in London for IET= F 89 >> to look at our proposed data modeling languages and protocols in more >> detail. While that conversation on the mail list didn't yield an explic= it >> set of requirements (but thanks to Jamal for taking the first formal try= at >> it), significant discussion occurred comparing and contrasting the benef= its >> of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps= in >> both proposals that would need to be addressed for use by I2RS. >>=20 >> Each proposed mechanism had a few benefits in contrast to its counterpar= t, >> but none of these were overwhelming in scope. >>=20 >> Our judgment of group consensus is that while both FORCES and Netconf/Ya= ng >> could serve I2RS that there is substantially more support for the >> Netconf/Yang proposal. Part of this consideration includes elements of >> expediency such as existing open source tool chains and implementation >> experience of I2RS-like mechanisms in other organizations and vendors. >>=20 >> Our near-term goals are to formally document the observed gaps in >> Netconf/Restconf and Yang with regard to I2RS uses and take them to thei= r >> home working groups to be worked upon. After discussing this detail wit= h >> our ADs, we can do so either in the form of documenting this upon the wi= ki >> or in the form of a requirements Internet-Draft. We welcome the chance = to >> choose our form of agility for this effort. >>=20 >> We will be forming a design team in the near future to work on the gap >> analysis and try to bring the necessary work to closure in short order. >>=20 >> -- Ed and Jeff >>=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 From nobody Thu May 22 09: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 492F01A0219 for ; Thu, 22 May 2014 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 YBXmtxI4Fzwv for ; Thu, 22 May 2014 09:19:28 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5CE1A0227 for ; Thu, 22 May 2014 09:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1657; q=dns/txt; s=iport; t=1400775567; x=1401985167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bbh4UqVkvtpALc39RmfJBrX0G0EgZ97+uTSPOK2+3BI=; b=KL8A2J7gdmYMowKPfluNvK3hCnsbMf0KJVwZa8Mf4cmTvM+b1/Rm0i6A iXpvzM79EVkVSAk20RPP5mOoI20pY+1GF66DylyN2gaU/Zz/tiRVequop cRxlt/o1nWuGRDZ2sz5UyxNw/9RJH3bWckiLtUsaggEomVLNmZAXMOvPA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJEiflOtJV2U/2dsb2JhbABZgweBKsQqAYENFnSCJgEBBG8KEAIBCEYyJQIEAQ0FG4gm1kwXjWwRAVAHhEAEiWeQCpMmgziBdzk X-IronPort-AV: E=Sophos;i="4.98,888,1392163200"; d="scan'208";a="46293265" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 22 May 2014 16:19:27 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4MGJQBT022969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 May 2014 16:19:27 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.206]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 22 May 2014 11:19:26 -0500 From: "Jan Medved (jmedved)" To: Jamal Hadi Salim , Jeffrey Haas Thread-Topic: [i2rs] Consensus on I2RS data modeling language and protocol Thread-Index: AQHPdTRRgoWQ8JPIhUGxjPWMdyAsPZtNDMiA//+afIA= Date: Thu, 22 May 2014 16:19:26 +0000 Message-ID: References: <20140521203605.GM9789@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.117.66] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7nt98JI5bZ5LZAM5H26s93cfru4 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 16:19:31 -0000 Hi Jamal, On 5/22/14, 8:22 AM, "Jamal Hadi Salim" wrote: >On "open source availability" >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >The notion that because there is some open source implementation it >qualifies some solution as legit is a red herring. 90% of IETF standards >don=B9t pass that smell test. There is no such requirement anywhere. There >is *absolutely* no open source implementation of I2RS using >netconf/restconf/yang. I *doubt* there is one in any organization >anywhere on the globe. So this boils down to be a marketing gimmick in an >engineering organization. Which is where my frustration comes in. Perhaps >the starting point at IETF is to go back to the old days of implementing >first as opensource variant, get cohesion around it and then >standardizing. > Jeff=B9s email states: "Part of this consideration includes elements of expediency such as existing open source tool chains and implementation experience of I2RS-like mechanisms in other organizations and vendors.=B2 I don=B9t think that Jeff is saying that there exists an open source I2RS implementation - he is saying that there is and *I2RS-like* mechanism in open source (I think we all agree that NC/Y qualifies as *I2RS-like*). The point is that these open source NC/Y implementations (there are multiple) will provide developers and protocols designers with a platform (and a starting point) that will allow them to extend the existing functionality towards I2RS, and to quickly prototype new protocol functionality that will be defined in the I2RS WG. =20 Thanks, Jan > From nobody Thu May 22 09:44: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 1CC4E1A021C for ; Thu, 22 May 2014 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nCYT4r9SWKL4 for ; Thu, 22 May 2014 09:43:56 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86B01A01ED for ; Thu, 22 May 2014 09:43:55 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so5899864qgd.19 for ; Thu, 22 May 2014 09:43:54 -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=5sKidZZw2iQy64kS4XAttm0a1U3wBU+FM8ecmySYGzk=; b=OWvdQOlHIndXFXHJHXPgbeyajUkJLDntvd9YwZNzNibOQjYOUGyGpNORJxeBOKVCB8 xes9uXqYXE7LhWA95so80sPUZjwqGp3BkLUpHI1ql9bijVvrVhmAYx+g8WdfSPJN6zZy Hf01K/0nJRqZ+uabzNH98XQpawhrrFSkqELKqyPyh+Q4H0u6plj6DbLQY4yh9+JQSpS/ +ETlklM4g2B8Ii2actNia1h/IxfBYivq4lZYTqDW65zMrScOqCoawMjEXixuALYw1OkS ferI8AL8/7gDPAquIMZVWL6pdfIYUM4ECaU31rzFHQrXGpTjvQgPvbY6WE5IqrqeQ550 f2YQ== X-Gm-Message-State: ALoCoQmJ+3ivk5mw9hIJvU1n7RrgipyT0kxvKplHiPwlaXzFQWivI2oGZBi6POoCsU/nOcEMgRWG MIME-Version: 1.0 X-Received: by 10.224.55.6 with SMTP id s6mr79767015qag.7.1400777034085; Thu, 22 May 2014 09:43:54 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 22 May 2014 09:43:54 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> Date: Thu, 22 May 2014 09:43:54 -0700 Message-ID: From: Andy Bierman To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=089e0153705e86e22e04f9ffd186 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uU4XLLZsOGuqoX6hI-MG9BRb0pY Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 16:43:59 -0000 --089e0153705e86e22e04f9ffd186 Content-Type: text/plain; charset=ISO-8859-1 Hi, Sorry I ran out of time to work on I2RS requirements. I tried to get some others to work on the wiki, but no takers. I think if you ask an engineer whose job depends how well they implement I2RS vs. an engineer who has no plans at all to implement it, you might get different answers. The initial and ongoing costs of the solution path really matter to vendors. Even if tools are ignored, there is the problem of I2RS interaction with the local config. That seems clearly more complicated with separate solutions for each one. YANG extensions are also significant because they allow the language to be customized instantly, without waiting for NETMOD or FORCES WG to be rechartered to change their data modeling language. Andy On Thu, May 22, 2014 at 8:22 AM, Jamal Hadi Salim wrote: > Jeff/Ed, > > First of all I want to thank you both; i think you both tried hard to > provide the > opportunity given the constraints. > Second: I have no qualms with the WG moving forward - I understand > progress MUST > be made. Andy, no hard feelings I hope. > > Having said that, I would like to speak my mind. I am disappointed and > I would like to address > the two points described as cause for the decision. > > On the "more support" for netconf/yang: > ================================ > My view is this boils down to popularity contest as opposed to > engineering requirements. > I wouldnt call this a process breakdown in I2RS - just that in general > the IETF allows the system > to be very hackable. It is like money in politics. While I empathize with > folks > who have implemented netconf/yang and feel that is the path forward - > i would argue the > voting system is highly stacked. I know this is how the "game" has > been played over the > years - but for sometime now I feel like we need a new system for > voting. Things should not be > judged based on a simple +1 or a hum (I should have advertised > somewhere for people to > show up and "vote" for ForCES which would have been dishonest). > Voting would have more more sense if there were clear requirements to > begin with from which > a clear checklist could be derived. > There were no specific requirements. I am sure there was intent but > assumptions were made > that netconf/yang is the way to go from the get-go. > There was not even effort to match against some requirements for > netconf/restconf/yang > when I put out a wiki update. There was not even an attempt to > dis/credit what i listed as requirements. > >From day one at the BOF, netconf and Yang were being presented as the > answer. > I remember standing up at the BOF mike and asking why solutions were > being presented before > requirements - IIRC the answer was i could present my own favorite > protocol if i wanted to > and that process would be followed. An engineering task requires > explicit call out of requirements > first. > > Note: I am not arguing for ForCES here - but it aint > Netconf/restconf/Yang and neither do i think > those will require a minor surgery to work (as per my view of the > requirements). And from that > perspective I am unhappy - I wish we actually used a matrix of some > sort to prove me wrong > but the answer seems like "we'll fix it". > > On "open source availability" > ======================= > The notion that because there is some open source implementation it > qualifies > some solution as legit is a red herring. 90% of IETF standards dont > pass that smell test. > There is no such requirement anywhere. > There is *absolutely* no open source implementation of I2RS using > netconf/restconf/yang. > I *doubt* there is one in any organization anywhere on the globe. So > this boils down to be > a marketing gimmick in an engineering organization. Which is where my > frustration comes in. > Perhaps the starting point at IETF is to go back to the old days of > implementing first as open > source variant, get cohesion around it and then standardizing. > > I hope my views arent too harsh (I just wanted to feed that elephant > in the room some peanuts). > > cheers, > jamal > > On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: > > Working Group, > > > > We committed to spend the weeks following last session in London for > IETF 89 > > to look at our proposed data modeling languages and protocols in more > > detail. While that conversation on the mail list didn't yield an > explicit > > set of requirements (but thanks to Jamal for taking the first formal try > at > > it), significant discussion occurred comparing and contrasting the > benefits > > of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps > in > > both proposals that would need to be addressed for use by I2RS. > > > > Each proposed mechanism had a few benefits in contrast to its > counterpart, > > but none of these were overwhelming in scope. > > > > Our judgment of group consensus is that while both FORCES and > Netconf/Yang > > could serve I2RS that there is substantially more support for the > > Netconf/Yang proposal. Part of this consideration includes elements of > > expediency such as existing open source tool chains and implementation > > experience of I2RS-like mechanisms in other organizations and vendors. > > > > Our near-term goals are to formally document the observed gaps in > > Netconf/Restconf and Yang with regard to I2RS uses and take them to their > > home working groups to be worked upon. After discussing this detail with > > our ADs, we can do so either in the form of documenting this upon the > wiki > > or in the form of a requirements Internet-Draft. We welcome the chance > to > > choose our form of agility for this effort. > > > > We will be forming a design team in the near future to work on the gap > > analysis and try to bring the necessary work to closure in short order. > > > > -- Ed and Jeff > > > > _______________________________________________ > > 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 > --089e0153705e86e22e04f9ffd186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry I ran out of time to work on = I2RS requirements.
I tried to get some others to work on the wiki= , but no takers.

I think if you ask an engineer wh= ose job depends how well
they implement I2RS vs. an engineer who has no plans at all
= to implement it, you might get different answers. The initial
and= ongoing costs of the solution path really matter to vendors.

Even if tools are ignored, there is the problem of I2RS inte= raction
with the local config. That seems clearly more complicate= d
with separate solutions for each one. =A0YANG extensions
are also significant because they allow the language to be customized<= /div>
instantly, without waiting for NETMOD or FORCES WG to be
rechartered to change their data modeling language.
=A0

Andy


On Thu, M= ay 22, 2014 at 8:22 AM, Jamal Hadi Salim <hadi@mojatatu.com>= wrote:
Jeff/Ed,

First of all I want to thank you both; i think you both tried hard to
provide the
opportunity given the constraints.
Second: I have no qualms with the WG moving forward - I understand progress= MUST
be made. Andy, no hard feelings I hope.

Having said that, I would like to speak my mind. I am disappointed and
I would like to address
the two points described as cause for the decision.

On the "more support" for netconf/yang:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
My view is this boils down to popularity contest as opposed to
engineering requirements.
I wouldnt call this a process breakdown in I2RS - just that in general
the IETF allows the system
to be very hackable. It is like money in politics. While I empathize with f= olks
who have implemented netconf/yang and feel that is the path forward -
i would argue the
voting system is highly stacked. I know this is how the "game" ha= s
been played over the
years - but for sometime now I feel like we need a new system for
voting. Things should not be
judged based on a simple +1 or a hum (I should have advertised
somewhere for people to
show up and "vote" for ForCES which would have been dishonest). Voting would =A0have more more sense if there were clear requirements to begin with from which
a clear checklist could be derived.
There were no specific requirements. I am sure there was intent but
assumptions were made
that netconf/yang is the way to go from the get-go.
There was not even effort to match against some requirements for
netconf/restconf/yang
when I put out a wiki update. There was not even an attempt to
dis/credit what i listed as requirements.
>From day one at the BOF, netconf and Yang were being presented as the a= nswer.
I remember standing up at the BOF mike and asking why solutions were
being presented before
requirements - IIRC the answer was i could present my own favorite
protocol if i wanted to
and that process would be =A0followed. An engineering task requires
explicit call out of requirements
first.

Note: I am not arguing for ForCES here - but it aint
Netconf/restconf/Yang and neither do i think
those will require a minor surgery to work (as per my view of the
requirements). And from that
perspective I am unhappy - I wish we actually used a matrix of some
sort to prove me wrong
but the answer seems like "we'll fix it".

On "open source availability"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The notion that because there is some open source implementation it qualifi= es
some solution as legit is a red herring. 90% of IETF standards dont
pass that smell test.
There is no such requirement anywhere.
There is *absolutely* no open source implementation of I2RS using
netconf/restconf/yang.
I *doubt* there is one in any organization anywhere on the globe. So
this boils down to be
a marketing gimmick in an engineering organization. Which is where my
frustration comes in.
Perhaps the starting point at IETF is to go back to the old days of
implementing first as open
source variant, get cohesion around it and then standardizing.

=A0I hope my views arent too harsh (I just wanted to feed that elephant
in the room some peanuts).

cheers,
jamal

On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> Working Group,
>
> We committed to spend the weeks following last session in London for I= ETF 89
> to look at our proposed data modeling languages and protocols in more<= br> > detail. =A0While that conversation on the mail list didn't yield a= n explicit
> set of requirements (but thanks to Jamal for taking the first formal t= ry at
> it), significant discussion occurred comparing and contrasting the ben= efits
> of FORCES and Netconf/Yang. =A0Part of that discussion helped clarify = gaps in
> both proposals that would need to be addressed for use by I2RS.
>
> Each proposed mechanism had a few benefits in contrast to its counterp= art,
> but none of these were overwhelming in scope.
>
> Our judgment of group consensus is that while both FORCES and Netconf/= Yang
> could serve I2RS that there is substantially more support for the
> Netconf/Yang proposal. =A0Part of this consideration includes elements= of
> expediency such as existing open source tool chains and implementation=
> experience of I2RS-like mechanisms in other organizations and vendors.=
>
> Our near-term goals are to formally document the observed gaps in
> Netconf/Restconf and Yang with regard to I2RS uses and take them to th= eir
> home working groups to be worked upon. =A0After discussing this detail= with
> our ADs, we can do so either in the form of documenting this upon the = wiki
> or in the form of a requirements Internet-Draft. =A0We welcome the cha= nce to
> choose our form of agility for this effort.
>
> We will be forming a design team in the near future to work on the gap=
> analysis and try to bring the necessary work to closure in short order= .
>
> -- Ed and Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

--089e0153705e86e22e04f9ffd186-- From nobody Thu May 22 10:22:37 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 346371A0224 for ; Thu, 22 May 2014 10:22:36 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 1M_nb3nBByZT for ; Thu, 22 May 2014 10:22:33 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8152C1A022D for ; Thu, 22 May 2014 10:22:33 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id sa20so4882797veb.9 for ; Thu, 22 May 2014 10:22:31 -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:from:date :message-id:subject:to:cc:content-type; bh=nfNfje/KCgpS6/zpSEuzMmNhrOL3iHB5nyuQiTGyqwU=; b=HE+LWYvHEGm2Vve1qzh2ci6gIaHt7dfG4kRz5wIUK5P3z9NJA64cB6U9vpfePNT7cS oAD0UpOEJrBnX136KHISXKRQ1rth2+QD1XrJLtDbdJMyeTNgNJ8cnxIbrJvsqfvycU66 2m0JtI0gCn1iKMIB8Ruxb0liizIpBXRAg+5fhK2E6sacCvcAKNvXuqBUGLdkfx4GVJr+ xt2cbj8hP7Hn0SkNeaSEbBc+13u2rGFbPgur3udd5A64wG3b4DazMppwUQu/IYqAIB12 HthICVmLzuoaqSVd8SsgqCJL2yPg4yB0bt4fMyi1a2fK173FMiQard9u3wF+hwfmh90P xoZw== X-Gm-Message-State: ALoCoQlc2c3nr2jHuEkjHp/guWsXlbmuwXz8AhP4Mgs7lXNV8J773Rz+5C4xeqbGZ/SNuZ7bOThC X-Received: by 10.52.13.98 with SMTP id g2mr2052477vdc.46.1400779351585; Thu, 22 May 2014 10:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 10:22:10 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 13:22:10 -0400 Message-ID: To: John E Drake Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/cV-Eh1jT1YgHZ1x6mf8HTLJwr4o Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 17:22:36 -0000 On Thu, May 22, 2014 at 12:13 PM, John E Drake wrote: > The other possibility is that FORCES is simply NQR. > Use something better than an Iphone if you want to make a meaningful comment. Nothing is QR for I2RS. I am talking about process here not a specific protocol. cheers, jamal > Sent from my iPhone > >> On May 22, 2014, at 11:24 AM, "Jamal Hadi Salim" wrote: >> >> Jeff/Ed, >> >> First of all I want to thank you both; i think you both tried hard to >> provide the >> opportunity given the constraints. >> Second: I have no qualms with the WG moving forward - I understand progress MUST >> be made. Andy, no hard feelings I hope. >> >> Having said that, I would like to speak my mind. I am disappointed and >> I would like to address >> the two points described as cause for the decision. >> >> On the "more support" for netconf/yang: >> ================================ >> My view is this boils down to popularity contest as opposed to >> engineering requirements. >> I wouldnt call this a process breakdown in I2RS - just that in general >> the IETF allows the system >> to be very hackable. It is like money in politics. While I empathize with folks >> who have implemented netconf/yang and feel that is the path forward - >> i would argue the >> voting system is highly stacked. I know this is how the "game" has >> been played over the >> years - but for sometime now I feel like we need a new system for >> voting. Things should not be >> judged based on a simple +1 or a hum (I should have advertised >> somewhere for people to >> show up and "vote" for ForCES which would have been dishonest). >> Voting would have more more sense if there were clear requirements to >> begin with from which >> a clear checklist could be derived. >> There were no specific requirements. I am sure there was intent but >> assumptions were made >> that netconf/yang is the way to go from the get-go. >> There was not even effort to match against some requirements for >> netconf/restconf/yang >> when I put out a wiki update. There was not even an attempt to >> dis/credit what i listed as requirements. >>> From day one at the BOF, netconf and Yang were being presented as the answer. >> I remember standing up at the BOF mike and asking why solutions were >> being presented before >> requirements - IIRC the answer was i could present my own favorite >> protocol if i wanted to >> and that process would be followed. An engineering task requires >> explicit call out of requirements >> first. >> >> Note: I am not arguing for ForCES here - but it aint >> Netconf/restconf/Yang and neither do i think >> those will require a minor surgery to work (as per my view of the >> requirements). And from that >> perspective I am unhappy - I wish we actually used a matrix of some >> sort to prove me wrong >> but the answer seems like "we'll fix it". >> >> On "open source availability" >> ======================= >> The notion that because there is some open source implementation it qualifies >> some solution as legit is a red herring. 90% of IETF standards dont >> pass that smell test. >> There is no such requirement anywhere. >> There is *absolutely* no open source implementation of I2RS using >> netconf/restconf/yang. >> I *doubt* there is one in any organization anywhere on the globe. So >> this boils down to be >> a marketing gimmick in an engineering organization. Which is where my >> frustration comes in. >> Perhaps the starting point at IETF is to go back to the old days of >> implementing first as open >> source variant, get cohesion around it and then standardizing. >> >> I hope my views arent too harsh (I just wanted to feed that elephant >> in the room some peanuts). >> >> cheers, >> jamal >> >>> On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: >>> Working Group, >>> >>> We committed to spend the weeks following last session in London for IETF 89 >>> to look at our proposed data modeling languages and protocols in more >>> detail. While that conversation on the mail list didn't yield an explicit >>> set of requirements (but thanks to Jamal for taking the first formal try at >>> it), significant discussion occurred comparing and contrasting the benefits >>> of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps in >>> both proposals that would need to be addressed for use by I2RS. >>> >>> Each proposed mechanism had a few benefits in contrast to its counterpart, >>> but none of these were overwhelming in scope. >>> >>> Our judgment of group consensus is that while both FORCES and Netconf/Yang >>> could serve I2RS that there is substantially more support for the >>> Netconf/Yang proposal. Part of this consideration includes elements of >>> expediency such as existing open source tool chains and implementation >>> experience of I2RS-like mechanisms in other organizations and vendors. >>> >>> Our near-term goals are to formally document the observed gaps in >>> Netconf/Restconf and Yang with regard to I2RS uses and take them to their >>> home working groups to be worked upon. After discussing this detail with >>> our ADs, we can do so either in the form of documenting this upon the wiki >>> or in the form of a requirements Internet-Draft. We welcome the chance to >>> choose our form of agility for this effort. >>> >>> We will be forming a design team in the near future to work on the gap >>> analysis and try to bring the necessary work to closure in short order. >>> >>> -- Ed and Jeff >>> >>> _______________________________________________ >>> 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 Thu May 22 10:33:38 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 E753B1A01C2 for ; Thu, 22 May 2014 10:33:35 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 h9OsAA87CA2I for ; Thu, 22 May 2014 10:33:34 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C011A025E for ; Thu, 22 May 2014 10:33:33 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jw12so4786141veb.5 for ; Thu, 22 May 2014 10:33:32 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ghcK7EOueopHniZJVi5hXYZdukD5RC7BY/6RM+PvpxY=; b=abDc/2ovAV+9DGKEhu9zgwGk2QgNlKQLnyTgReSZSXGCHn3sko03IDZWVrCp0YSGoI xQfTP+QHEv74GzP2t64fJhuiTJohkoOdNS1ZdHzi2j8GeCx1CLE0F5XXmKuI3pVYpnJ0 Il8Lz1QlRIeft5KHEblMq7v2sNaZi58mIu1zLgEntt1B7erU1GVHcjg8NQQLUxXtvaAF gjK21Fc8gIS/aRfTxatuWkxe0sp2UZNN4Xlyh0YfCgDPGJRVRdHdO9HFlscf29sfMGj4 YoSilnaZexYSZgSBQM48FeJxd8TCNogrrqmard7221wooued2+vIv+riOnwCTrkj1DQ5 WvSA== X-Gm-Message-State: ALoCoQnc31M8vr2zq6uuJLCBba/qKTG/ODy0dcS6XfQX2qVbetnitcQRQKB6ks6VhBH8Ib10fZay X-Received: by 10.52.183.228 with SMTP id ep4mr14314153vdc.30.1400780011969; Thu, 22 May 2014 10:33:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 10:33:11 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 13:33:11 -0400 Message-ID: To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wTJCJp61UNJ802IFgm9apsirk5g Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 17:33:36 -0000 Hi Jan, On Thu, May 22, 2014 at 12:19 PM, Jan Medved (jmedved) wrote: > Hi Jamal, > > [..] > Jeff=C2=B9s email states: "Part of this consideration includes elements o= f > expediency such as existing open source tool chains and implementation > experience of I2RS-like mechanisms in other organizations and vendors.=C2= =B2 > > I don=C2=B9t think that Jeff is saying that there exists an open source I= 2RS > implementation - Agreed. My argument is that the only time you can make a claim about virtues of open source is if the implementation in fact exists. >he is saying that there is and *I2RS-like* mechanism in > open source (I think we all agree that NC/Y qualifies as *I2RS-like*). It does qualify like you say as *I2RS-like* (as does ForCES arch) - unfortunately since requirements are not clear, i am not sure how far we can stretch the *like* part. >The > point is that these open source NC/Y implementations (there are multiple) > will provide developers and protocols designers with a platform (and a > starting point) that will allow them to extend the existing functionality > towards I2RS, and to quickly prototype new protocol functionality that > will be defined in the I2RS WG. > I disagree. I dont think netconf/restconf/yang without acrobatics will reso= lve the requirements; not saying it couldnt be made to with a lot of effort and refactored. I dont consider the presence of open source to be a reasonable input unless the majority use the same code (reminds me of OF "interop" where 95% of the vendors have exactly the same implementation of OVS). cheers, jamal > > > Thanks, > Jan > >> > From nobody Thu May 22 10:44: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 F1BD91A0275 for ; Thu, 22 May 2014 10:44:11 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 SR3IgHQf2Jag for ; Thu, 22 May 2014 10:44:09 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BC91A028A for ; Thu, 22 May 2014 10:44:09 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if11so1484691vcb.22 for ; Thu, 22 May 2014 10:44:07 -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:from:date :message-id:subject:to:cc:content-type; bh=G01825LasKC+a4V3z/ZF+MKq1xNNfYHIyxw95S4Sat4=; b=Gq6YeFrJ+reYADQOdOO7n9eUb2ZNLpfjBOc2RvKMTRewLcvCmkw0YF+hjMWKTPuoqI Ddnv7gFsNGzo6XrPnvstQ0yEbYpq0JpzXDGlmpi9A6kzzcwHthisDI9ZLj2VJLS4YloY k1VvBGzodPKY+ImbigxYN/SUk/FHZWm47AlZ2hVvOKSZ0Iubv5PPXCZ5V/pa2fIACGpk d8XM6u2172wFkCxZayi6OAgj2kDHGyU8Lo2udNyZ6kjeAReASHlnRL/PLlojEE68eJ58 MDTMZ9D5Af+zon2FVRB93JXW53hVtMH5fCK57mFS7K6a4mFfY3ER7Iysh1eSaiLXNCLJ 2iqg== X-Gm-Message-State: ALoCoQmTMMaCyZwn4zEdsx1bbZDN+/5decjix5Dhz71DemhNjrfnPz261ukkgnngM51zL+BwTP3p X-Received: by 10.220.81.194 with SMTP id y2mr17220855vck.29.1400780647570; Thu, 22 May 2014 10:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 10:43:47 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 13:43:47 -0400 Message-ID: To: Andy Bierman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/J2IDofQtU6T5P2_mHEnqdnaOMbw Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 17:44:12 -0000 On Thu, May 22, 2014 at 12:43 PM, Andy Bierman wrote: > Hi, > > Sorry I ran out of time to work on I2RS requirements. > I tried to get some others to work on the wiki, but no takers. > Thanks for at least attempting that or even thinking about it. > I think if you ask an engineer whose job depends how well > they implement I2RS vs. an engineer who has no plans at all > to implement it, you might get different answers. The initial > and ongoing costs of the solution path really matter to vendors. > I think this is a reasonable requirement. This is why i said i empathized with whoever has already implemented. But i would have felt more satisfied if a reasonable process was followed. Maybe it will cost more to refactor netconf/yang and it is cheaper to create something new. > Even if tools are ignored, there is the problem of I2RS interaction > with the local config. That seems clearly more complicated > with separate solutions for each one. YANG extensions > are also significant because they allow the language to be customized > instantly, without waiting for NETMOD or FORCES WG to be > rechartered to change their data modeling language. > I never looked at config/data store to be a requirement for I2RS. That could be a separate independent service. cheers, jamal > > Andy > > > On Thu, May 22, 2014 at 8:22 AM, Jamal Hadi Salim wrote: >> >> Jeff/Ed, >> >> First of all I want to thank you both; i think you both tried hard to >> provide the >> opportunity given the constraints. >> Second: I have no qualms with the WG moving forward - I understand >> progress MUST >> be made. Andy, no hard feelings I hope. >> >> Having said that, I would like to speak my mind. I am disappointed and >> I would like to address >> the two points described as cause for the decision. >> >> On the "more support" for netconf/yang: >> ================================ >> My view is this boils down to popularity contest as opposed to >> engineering requirements. >> I wouldnt call this a process breakdown in I2RS - just that in general >> the IETF allows the system >> to be very hackable. It is like money in politics. While I empathize with >> folks >> who have implemented netconf/yang and feel that is the path forward - >> i would argue the >> voting system is highly stacked. I know this is how the "game" has >> been played over the >> years - but for sometime now I feel like we need a new system for >> voting. Things should not be >> judged based on a simple +1 or a hum (I should have advertised >> somewhere for people to >> show up and "vote" for ForCES which would have been dishonest). >> Voting would have more more sense if there were clear requirements to >> begin with from which >> a clear checklist could be derived. >> There were no specific requirements. I am sure there was intent but >> assumptions were made >> that netconf/yang is the way to go from the get-go. >> There was not even effort to match against some requirements for >> netconf/restconf/yang >> when I put out a wiki update. There was not even an attempt to >> dis/credit what i listed as requirements. >> >From day one at the BOF, netconf and Yang were being presented as the >> answer. >> I remember standing up at the BOF mike and asking why solutions were >> being presented before >> requirements - IIRC the answer was i could present my own favorite >> protocol if i wanted to >> and that process would be followed. An engineering task requires >> explicit call out of requirements >> first. >> >> Note: I am not arguing for ForCES here - but it aint >> Netconf/restconf/Yang and neither do i think >> those will require a minor surgery to work (as per my view of the >> requirements). And from that >> perspective I am unhappy - I wish we actually used a matrix of some >> sort to prove me wrong >> but the answer seems like "we'll fix it". >> >> On "open source availability" >> ======================= >> The notion that because there is some open source implementation it >> qualifies >> some solution as legit is a red herring. 90% of IETF standards dont >> pass that smell test. >> There is no such requirement anywhere. >> There is *absolutely* no open source implementation of I2RS using >> netconf/restconf/yang. >> I *doubt* there is one in any organization anywhere on the globe. So >> this boils down to be >> a marketing gimmick in an engineering organization. Which is where my >> frustration comes in. >> Perhaps the starting point at IETF is to go back to the old days of >> implementing first as open >> source variant, get cohesion around it and then standardizing. >> >> I hope my views arent too harsh (I just wanted to feed that elephant >> in the room some peanuts). >> >> cheers, >> jamal >> >> On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: >> > Working Group, >> > >> > We committed to spend the weeks following last session in London for >> > IETF 89 >> > to look at our proposed data modeling languages and protocols in more >> > detail. While that conversation on the mail list didn't yield an >> > explicit >> > set of requirements (but thanks to Jamal for taking the first formal try >> > at >> > it), significant discussion occurred comparing and contrasting the >> > benefits >> > of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps >> > in >> > both proposals that would need to be addressed for use by I2RS. >> > >> > Each proposed mechanism had a few benefits in contrast to its >> > counterpart, >> > but none of these were overwhelming in scope. >> > >> > Our judgment of group consensus is that while both FORCES and >> > Netconf/Yang >> > could serve I2RS that there is substantially more support for the >> > Netconf/Yang proposal. Part of this consideration includes elements of >> > expediency such as existing open source tool chains and implementation >> > experience of I2RS-like mechanisms in other organizations and vendors. >> > >> > Our near-term goals are to formally document the observed gaps in >> > Netconf/Restconf and Yang with regard to I2RS uses and take them to >> > their >> > home working groups to be worked upon. After discussing this detail >> > with >> > our ADs, we can do so either in the form of documenting this upon the >> > wiki >> > or in the form of a requirements Internet-Draft. We welcome the chance >> > to >> > choose our form of agility for this effort. >> > >> > We will be forming a design team in the near future to work on the gap >> > analysis and try to bring the necessary work to closure in short order. >> > >> > -- Ed and Jeff >> > >> > _______________________________________________ >> > 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 Thu May 22 11:04: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 97AA91A0248 for ; Thu, 22 May 2014 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TBd5Ig-PXU2q for ; Thu, 22 May 2014 11:04:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83B41A0236 for ; Thu, 22 May 2014 11:04:14 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 18:04:12 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0944.000; Thu, 22 May 2014 18:04:11 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [i2rs] Consensus on I2RS data modeling language and protocol Thread-Index: AQHPdTRlm1rPvZLwbkiU780/k5L0yJtMuPaAgAAOJ1yAABM0AIAACGBA Date: Thu, 22 May 2014 18:04:11 +0000 Message-ID: <511468be1b9b4aafab0fa3aedaa8a481@BLUPR05MB562.namprd05.prod.outlook.com> References: <20140521203605.GM9789@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.16] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(51694002)(377454003)(24454002)(189002)(199002)(13464003)(19580405001)(15975445006)(74502001)(81542001)(46102001)(74316001)(83322001)(20776003)(4396001)(79102001)(561944003)(19580395003)(81342001)(77982001)(50986999)(83072002)(77096999)(76576001)(21056001)(92566001)(76482001)(85852003)(64706001)(2656002)(101416001)(76176999)(31966008)(54356999)(80022001)(86362001)(87936001)(74662001)(99396002)(33646001)(66066001)(99286001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/c46Ix4AsCnd5WvIIa9xagczaBrY Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 18:04:17 -0000 Q29tbWVudHMgaW5saW5lLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphbWFsIEhhZGkgU2FsaW0gW21haWx0 bzpoYWRpQG1vamF0YXR1LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE1heSAyMiwgMjAxNCAxMDoy MiBBTQ0KPiBUbzogSm9obiBFIERyYWtlDQo+IENjOiBKZWZmcmV5IEhhYXM7IGkycnNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtpMnJzXSBDb25zZW5zdXMgb24gSTJSUyBkYXRhIG1vZGVsaW5n IGxhbmd1YWdlIGFuZCBwcm90b2NvbA0KPiANCj4gT24gVGh1LCBNYXkgMjIsIDIwMTQgYXQgMTI6 MTMgUE0sIEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPiBUaGUg b3RoZXIgcG9zc2liaWxpdHkgaXMgdGhhdCBGT1JDRVMgaXMgc2ltcGx5IE5RUi4NCj4gPg0KPiAN Cj4gVXNlIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiBhbiBJcGhvbmUgaWYgeW91IHdhbnQgdG8gbWFr ZSBhIG1lYW5pbmdmdWwNCj4gY29tbWVudC4NCg0KW0pEXSAgTm93IHRoYXQncyBhIG1lYW5pbmdm dWwgY29tbWVudC4gIA0KDQo+IE5vdGhpbmcgaXMgUVIgZm9yIEkyUlMuDQo+IEkgYW0gdGFsa2lu ZyBhYm91dCBwcm9jZXNzIGhlcmUgbm90IGEgc3BlY2lmaWMgcHJvdG9jb2wuDQoNCltKRF0gIFJp Z2h0LCBhbnkgcHJvY2VzcyB0aGF0IGRvZXMgbm90IHNlbGVjdCBGT1JDRVMgaXMgYnkgZGVmaW5p dGlvbiBpbnRyaW5zaWNhbGx5IGZsYXdlZC4gDQoNCj4gDQo+IGNoZWVycywNCj4gamFtYWwNCj4g DQo+ID4gU2VudCBmcm9tIG15IGlQaG9uZQ0KPiA+DQo+ID4+IE9uIE1heSAyMiwgMjAxNCwgYXQg MTE6MjQgQU0sICJKYW1hbCBIYWRpIFNhbGltIiA8aGFkaUBtb2phdGF0dS5jb20+DQo+IHdyb3Rl Og0KPiA+Pg0KPiA+PiBKZWZmL0VkLA0KPiA+Pg0KPiA+PiBGaXJzdCBvZiBhbGwgSSB3YW50IHRv IHRoYW5rIHlvdSBib3RoOyBpIHRoaW5rIHlvdSBib3RoIHRyaWVkIGhhcmQgdG8NCj4gPj4gcHJv dmlkZSB0aGUgb3Bwb3J0dW5pdHkgZ2l2ZW4gdGhlIGNvbnN0cmFpbnRzLg0KPiA+PiBTZWNvbmQ6 IEkgaGF2ZSBubyBxdWFsbXMgd2l0aCB0aGUgV0cgbW92aW5nIGZvcndhcmQgLSBJIHVuZGVyc3Rh bmQNCj4gPj4gcHJvZ3Jlc3MgTVVTVCBiZSBtYWRlLiBBbmR5LCBubyBoYXJkIGZlZWxpbmdzIEkg aG9wZS4NCj4gPj4NCj4gPj4gSGF2aW5nIHNhaWQgdGhhdCwgSSB3b3VsZCBsaWtlIHRvIHNwZWFr IG15IG1pbmQuIEkgYW0gZGlzYXBwb2ludGVkDQo+ID4+IGFuZCBJIHdvdWxkIGxpa2UgdG8gYWRk cmVzcyB0aGUgdHdvIHBvaW50cyBkZXNjcmliZWQgYXMgY2F1c2UgZm9yIHRoZQ0KPiA+PiBkZWNp c2lvbi4NCj4gPj4NCj4gPj4gT24gdGhlICJtb3JlIHN1cHBvcnQiIGZvciBuZXRjb25mL3lhbmc6 DQo+ID4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4+IE15IHZpZXcgaXMg dGhpcyBib2lscyBkb3duIHRvIHBvcHVsYXJpdHkgY29udGVzdCBhcyBvcHBvc2VkIHRvDQo+ID4+ IGVuZ2luZWVyaW5nIHJlcXVpcmVtZW50cy4NCj4gPj4gSSB3b3VsZG50IGNhbGwgdGhpcyBhIHBy b2Nlc3MgYnJlYWtkb3duIGluIEkyUlMgLSBqdXN0IHRoYXQgaW4NCj4gPj4gZ2VuZXJhbCB0aGUg SUVURiBhbGxvd3MgdGhlIHN5c3RlbSB0byBiZSB2ZXJ5IGhhY2thYmxlLiBJdCBpcyBsaWtlDQo+ ID4+IG1vbmV5IGluIHBvbGl0aWNzLiBXaGlsZSBJIGVtcGF0aGl6ZSB3aXRoIGZvbGtzIHdobyBo YXZlIGltcGxlbWVudGVkDQo+ID4+IG5ldGNvbmYveWFuZyBhbmQgZmVlbCB0aGF0IGlzIHRoZSBw YXRoIGZvcndhcmQgLSBpIHdvdWxkIGFyZ3VlIHRoZQ0KPiA+PiB2b3Rpbmcgc3lzdGVtIGlzIGhp Z2hseSBzdGFja2VkLiBJIGtub3cgdGhpcyBpcyBob3cgdGhlICJnYW1lIiBoYXMNCj4gPj4gYmVl biBwbGF5ZWQgb3ZlciB0aGUgeWVhcnMgLSBidXQgZm9yIHNvbWV0aW1lIG5vdyBJIGZlZWwgbGlr ZSB3ZSBuZWVkDQo+ID4+IGEgbmV3IHN5c3RlbSBmb3Igdm90aW5nLiBUaGluZ3Mgc2hvdWxkIG5v dCBiZSBqdWRnZWQgYmFzZWQgb24gYQ0KPiA+PiBzaW1wbGUgKzEgb3IgYSBodW0gKEkgc2hvdWxk IGhhdmUgYWR2ZXJ0aXNlZCBzb21ld2hlcmUgZm9yIHBlb3BsZSB0bw0KPiA+PiBzaG93IHVwIGFu ZCAidm90ZSIgZm9yIEZvckNFUyB3aGljaCB3b3VsZCBoYXZlIGJlZW4gZGlzaG9uZXN0KS4NCj4g Pj4gVm90aW5nIHdvdWxkICBoYXZlIG1vcmUgbW9yZSBzZW5zZSBpZiB0aGVyZSB3ZXJlIGNsZWFy IHJlcXVpcmVtZW50cw0KPiA+PiB0byBiZWdpbiB3aXRoIGZyb20gd2hpY2ggYSBjbGVhciBjaGVj a2xpc3QgY291bGQgYmUgZGVyaXZlZC4NCj4gPj4gVGhlcmUgd2VyZSBubyBzcGVjaWZpYyByZXF1 aXJlbWVudHMuIEkgYW0gc3VyZSB0aGVyZSB3YXMgaW50ZW50IGJ1dA0KPiA+PiBhc3N1bXB0aW9u cyB3ZXJlIG1hZGUgdGhhdCBuZXRjb25mL3lhbmcgaXMgdGhlIHdheSB0byBnbyBmcm9tIHRoZQ0K PiA+PiBnZXQtZ28uDQo+ID4+IFRoZXJlIHdhcyBub3QgZXZlbiBlZmZvcnQgdG8gbWF0Y2ggYWdh aW5zdCBzb21lIHJlcXVpcmVtZW50cyBmb3INCj4gPj4gbmV0Y29uZi9yZXN0Y29uZi95YW5nIHdo ZW4gSSBwdXQgb3V0IGEgd2lraSB1cGRhdGUuIFRoZXJlIHdhcyBub3QNCj4gPj4gZXZlbiBhbiBh dHRlbXB0IHRvIGRpcy9jcmVkaXQgd2hhdCBpIGxpc3RlZCBhcyByZXF1aXJlbWVudHMuDQo+ID4+ PiBGcm9tIGRheSBvbmUgYXQgdGhlIEJPRiwgbmV0Y29uZiBhbmQgWWFuZyB3ZXJlIGJlaW5nIHBy ZXNlbnRlZCBhcyB0aGUNCj4gYW5zd2VyLg0KPiA+PiBJIHJlbWVtYmVyIHN0YW5kaW5nIHVwIGF0 IHRoZSBCT0YgbWlrZSBhbmQgYXNraW5nIHdoeSBzb2x1dGlvbnMgd2VyZQ0KPiA+PiBiZWluZyBw cmVzZW50ZWQgYmVmb3JlIHJlcXVpcmVtZW50cyAtIElJUkMgdGhlIGFuc3dlciB3YXMgaSBjb3Vs ZA0KPiA+PiBwcmVzZW50IG15IG93biBmYXZvcml0ZSBwcm90b2NvbCBpZiBpIHdhbnRlZCB0byBh bmQgdGhhdCBwcm9jZXNzDQo+ID4+IHdvdWxkIGJlICBmb2xsb3dlZC4gQW4gZW5naW5lZXJpbmcg dGFzayByZXF1aXJlcyBleHBsaWNpdCBjYWxsIG91dCBvZg0KPiA+PiByZXF1aXJlbWVudHMgZmly c3QuDQo+ID4+DQo+ID4+IE5vdGU6IEkgYW0gbm90IGFyZ3VpbmcgZm9yIEZvckNFUyBoZXJlIC0g YnV0IGl0IGFpbnQNCj4gPj4gTmV0Y29uZi9yZXN0Y29uZi9ZYW5nIGFuZCBuZWl0aGVyIGRvIGkg dGhpbmsgdGhvc2Ugd2lsbCByZXF1aXJlIGENCj4gPj4gbWlub3Igc3VyZ2VyeSB0byB3b3JrIChh cyBwZXIgbXkgdmlldyBvZiB0aGUgcmVxdWlyZW1lbnRzKS4gQW5kIGZyb20NCj4gPj4gdGhhdCBw ZXJzcGVjdGl2ZSBJIGFtIHVuaGFwcHkgLSBJIHdpc2ggd2UgYWN0dWFsbHkgdXNlZCBhIG1hdHJp eCBvZg0KPiA+PiBzb21lIHNvcnQgdG8gcHJvdmUgbWUgd3JvbmcgYnV0IHRoZSBhbnN3ZXIgc2Vl bXMgbGlrZSAid2UnbGwgZml4IGl0Ii4NCj4gPj4NCj4gPj4gT24gIm9wZW4gc291cmNlIGF2YWls YWJpbGl0eSINCj4gPj4gPT09PT09PT09PT09PT09PT09PT09PT0NCj4gPj4gVGhlIG5vdGlvbiB0 aGF0IGJlY2F1c2UgdGhlcmUgaXMgc29tZSBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbiBpdA0K PiA+PiBxdWFsaWZpZXMgc29tZSBzb2x1dGlvbiBhcyBsZWdpdCBpcyBhIHJlZCBoZXJyaW5nLiA5 MCUgb2YgSUVURg0KPiA+PiBzdGFuZGFyZHMgZG9udCBwYXNzIHRoYXQgc21lbGwgdGVzdC4NCj4g Pj4gVGhlcmUgaXMgbm8gc3VjaCByZXF1aXJlbWVudCBhbnl3aGVyZS4NCj4gPj4gVGhlcmUgaXMg KmFic29sdXRlbHkqIG5vIG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9uIG9mIEkyUlMgdXNpbmcN Cj4gPj4gbmV0Y29uZi9yZXN0Y29uZi95YW5nLg0KPiA+PiBJICpkb3VidCogdGhlcmUgaXMgb25l IGluIGFueSBvcmdhbml6YXRpb24gYW55d2hlcmUgb24gdGhlIGdsb2JlLiBTbw0KPiA+PiB0aGlz IGJvaWxzIGRvd24gdG8gYmUgYSBtYXJrZXRpbmcgZ2ltbWljayBpbiBhbiBlbmdpbmVlcmluZw0K PiA+PiBvcmdhbml6YXRpb24uIFdoaWNoIGlzIHdoZXJlIG15IGZydXN0cmF0aW9uIGNvbWVzIGlu Lg0KPiA+PiBQZXJoYXBzIHRoZSBzdGFydGluZyBwb2ludCBhdCBJRVRGIGlzIHRvIGdvIGJhY2sg dG8gdGhlIG9sZCBkYXlzIG9mDQo+ID4+IGltcGxlbWVudGluZyBmaXJzdCBhcyBvcGVuIHNvdXJj ZSB2YXJpYW50LCBnZXQgY29oZXNpb24gYXJvdW5kIGl0IGFuZA0KPiA+PiB0aGVuIHN0YW5kYXJk aXppbmcuDQo+ID4+DQo+ID4+IEkgaG9wZSBteSB2aWV3cyBhcmVudCB0b28gaGFyc2ggKEkganVz dCB3YW50ZWQgdG8gZmVlZCB0aGF0IGVsZXBoYW50DQo+ID4+IGluIHRoZSByb29tIHNvbWUgcGVh bnV0cykuDQo+ID4+DQo+ID4+IGNoZWVycywNCj4gPj4gamFtYWwNCj4gPj4NCj4gPj4+IE9uIFdl ZCwgTWF5IDIxLCAyMDE0IGF0IDQ6MzYgUE0sIEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+ IHdyb3RlOg0KPiA+Pj4gV29ya2luZyBHcm91cCwNCj4gPj4+DQo+ID4+PiBXZSBjb21taXR0ZWQg dG8gc3BlbmQgdGhlIHdlZWtzIGZvbGxvd2luZyBsYXN0IHNlc3Npb24gaW4gTG9uZG9uIGZvcg0K PiA+Pj4gSUVURiA4OSB0byBsb29rIGF0IG91ciBwcm9wb3NlZCBkYXRhIG1vZGVsaW5nIGxhbmd1 YWdlcyBhbmQNCj4gPj4+IHByb3RvY29scyBpbiBtb3JlIGRldGFpbC4gIFdoaWxlIHRoYXQgY29u dmVyc2F0aW9uIG9uIHRoZSBtYWlsIGxpc3QNCj4gPj4+IGRpZG4ndCB5aWVsZCBhbiBleHBsaWNp dCBzZXQgb2YgcmVxdWlyZW1lbnRzIChidXQgdGhhbmtzIHRvIEphbWFsDQo+ID4+PiBmb3IgdGFr aW5nIHRoZSBmaXJzdCBmb3JtYWwgdHJ5IGF0IGl0KSwgc2lnbmlmaWNhbnQgZGlzY3Vzc2lvbg0K PiA+Pj4gb2NjdXJyZWQgY29tcGFyaW5nIGFuZCBjb250cmFzdGluZyB0aGUgYmVuZWZpdHMgb2Yg Rk9SQ0VTIGFuZA0KPiA+Pj4gTmV0Y29uZi9ZYW5nLiAgUGFydCBvZiB0aGF0IGRpc2N1c3Npb24g aGVscGVkIGNsYXJpZnkgZ2FwcyBpbiBib3RoIHByb3Bvc2Fscw0KPiB0aGF0IHdvdWxkIG5lZWQg dG8gYmUgYWRkcmVzc2VkIGZvciB1c2UgYnkgSTJSUy4NCj4gPj4+DQo+ID4+PiBFYWNoIHByb3Bv c2VkIG1lY2hhbmlzbSBoYWQgYSBmZXcgYmVuZWZpdHMgaW4gY29udHJhc3QgdG8gaXRzDQo+ID4+ PiBjb3VudGVycGFydCwgYnV0IG5vbmUgb2YgdGhlc2Ugd2VyZSBvdmVyd2hlbG1pbmcgaW4gc2Nv cGUuDQo+ID4+Pg0KPiA+Pj4gT3VyIGp1ZGdtZW50IG9mIGdyb3VwIGNvbnNlbnN1cyBpcyB0aGF0 IHdoaWxlIGJvdGggRk9SQ0VTIGFuZA0KPiA+Pj4gTmV0Y29uZi9ZYW5nIGNvdWxkIHNlcnZlIEky UlMgdGhhdCB0aGVyZSBpcyBzdWJzdGFudGlhbGx5IG1vcmUNCj4gPj4+IHN1cHBvcnQgZm9yIHRo ZSBOZXRjb25mL1lhbmcgcHJvcG9zYWwuICBQYXJ0IG9mIHRoaXMgY29uc2lkZXJhdGlvbg0KPiA+ Pj4gaW5jbHVkZXMgZWxlbWVudHMgb2YgZXhwZWRpZW5jeSBzdWNoIGFzIGV4aXN0aW5nIG9wZW4g c291cmNlIHRvb2wNCj4gPj4+IGNoYWlucyBhbmQgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSBv ZiBJMlJTLWxpa2UgbWVjaGFuaXNtcyBpbiBvdGhlcg0KPiBvcmdhbml6YXRpb25zIGFuZCB2ZW5k b3JzLg0KPiA+Pj4NCj4gPj4+IE91ciBuZWFyLXRlcm0gZ29hbHMgYXJlIHRvIGZvcm1hbGx5IGRv Y3VtZW50IHRoZSBvYnNlcnZlZCBnYXBzIGluDQo+ID4+PiBOZXRjb25mL1Jlc3Rjb25mIGFuZCBZ YW5nIHdpdGggcmVnYXJkIHRvIEkyUlMgdXNlcyBhbmQgdGFrZSB0aGVtIHRvDQo+ID4+PiB0aGVp ciBob21lIHdvcmtpbmcgZ3JvdXBzIHRvIGJlIHdvcmtlZCB1cG9uLiAgQWZ0ZXIgZGlzY3Vzc2lu ZyB0aGlzDQo+ID4+PiBkZXRhaWwgd2l0aCBvdXIgQURzLCB3ZSBjYW4gZG8gc28gZWl0aGVyIGlu IHRoZSBmb3JtIG9mIGRvY3VtZW50aW5nDQo+ID4+PiB0aGlzIHVwb24gdGhlIHdpa2kgb3IgaW4g dGhlIGZvcm0gb2YgYSByZXF1aXJlbWVudHMgSW50ZXJuZXQtRHJhZnQuDQo+ID4+PiBXZSB3ZWxj b21lIHRoZSBjaGFuY2UgdG8gY2hvb3NlIG91ciBmb3JtIG9mIGFnaWxpdHkgZm9yIHRoaXMgZWZm b3J0Lg0KPiA+Pj4NCj4gPj4+IFdlIHdpbGwgYmUgZm9ybWluZyBhIGRlc2lnbiB0ZWFtIGluIHRo ZSBuZWFyIGZ1dHVyZSB0byB3b3JrIG9uIHRoZQ0KPiA+Pj4gZ2FwIGFuYWx5c2lzIGFuZCB0cnkg dG8gYnJpbmcgdGhlIG5lY2Vzc2FyeSB3b3JrIHRvIGNsb3N1cmUgaW4gc2hvcnQgb3JkZXIuDQo+ ID4+Pg0KPiA+Pj4gLS0gRWQgYW5kIEplZmYNCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gaTJycyBtYWlsaW5nIGxpc3QN Cj4gPj4+IGkycnNAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaTJycw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+PiBpMnJzIG1haWxpbmcgbGlzdA0KPiA+PiBpMnJzQGlldGYu b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K From nobody Thu May 22 11:12: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 0587B1A0294 for ; Thu, 22 May 2014 11:12:51 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 92nHV-_LBltu for ; Thu, 22 May 2014 11:12:49 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0431C1A0289 for ; Thu, 22 May 2014 11:12:48 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so4899399vcb.15 for ; Thu, 22 May 2014 11:12:46 -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:from:date :message-id:subject:to:cc:content-type; bh=AcaRf91gD+oh5uyuXP//udroWs6VRChoIxXLY0FpVS4=; b=TJ+NaxHkoO0WCbBZhpGSTpPGMf2Ls3jSn8zETs4t5vo9QkW8ifEKQH6cEGw97GPNoA d/FjBpB6K4NHZz7k0U3rXG7+xMF1dE6K6WCc0gG7eZuSW3W+dX6vfpsqpjpxuK+HcUYh 9jpyDjMrwj3hF2+bfwHqg59byh/z7ZcQXNz+34WuCL8lbmXGf1EoviZ/kmGgfYfTXlGM tO/6vbpGg94uJnYMbj6vMBXvTv2X9wwbkoYK3oqbww07uSseQwvZpGRvw6Ye/9PqZ0KP JB25HdB3YRKUSj6Qh1kBlgKpA389mRS+POB1CNjKO6ilUyIiOA7qeDaQQiJku6nDkVU+ MvTw== X-Gm-Message-State: ALoCoQlwEPUHgbAZ7jcCzzNKokAQinyLB2AKXES1/KhHsyq3KVOZOPVBCqUuOilG20/CinaSeiE1 X-Received: by 10.220.47.201 with SMTP id o9mr123391vcf.65.1400782366072; Thu, 22 May 2014 11:12:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 11:12:26 -0700 (PDT) In-Reply-To: <511468be1b9b4aafab0fa3aedaa8a481@BLUPR05MB562.namprd05.prod.outlook.com> References: <20140521203605.GM9789@pfrc> <511468be1b9b4aafab0fa3aedaa8a481@BLUPR05MB562.namprd05.prod.outlook.com> From: Jamal Hadi Salim Date: Thu, 22 May 2014 14:12:26 -0400 Message-ID: To: John E Drake Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DPEolmutYXaN4G-dxwSBaq2kyLk Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 18:12:51 -0000 On Thu, May 22, 2014 at 2:04 PM, John E Drake wrote: > [JD] Right, any process that does not select FORCES is by definition intrinsically flawed. > Seriously? Is your reading patience at the same terseness as your writing? cheers, jamal From nobody Thu May 22 11:21: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 A6BA11A024B for ; Thu, 22 May 2014 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 ZuMg6qFt_bKq for ; Thu, 22 May 2014 11:21:52 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1CE1A0248 for ; Thu, 22 May 2014 11:21:51 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so3331589yha.10 for ; Thu, 22 May 2014 11:21:50 -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=UvuedhmeRg4v2kRquglDrYDrm/h8p6egXBf7njW4lpc=; b=lctegwq67bdVMCf3z3jVlzamxEVRKZIOw8zrHIsNopeus/6xsWo4ewI2rWZlZP1JES ERHlrHw1kt0o0Q0YNwaY49hdo6gy+5AO5GT7jh9pUO3uq1Gnyp2WnxKDx50ztnhJEXFj 8T0nlI43ROZN1Er/uK5uljj1v59pvE6W9FrY70wFYwlLhRdGUBV1GHyrVF7+keAE/a6n pOIdXKjdCNNcFKAH+fLtrC5CMIe2UryXz9yCQkfEX4FuLGPsMK5xb6JJ6Uo3IltLNNFB rr/INRS6X1qdwXq4JLpCo0YB6aqPMiLrOvM6/jgx6SrOwm40rjpV/i4HBhEnZoi3Y8m4 xMUw== MIME-Version: 1.0 X-Received: by 10.236.209.68 with SMTP id r44mr8029542yho.152.1400782910174; Thu, 22 May 2014 11:21:50 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Thu, 22 May 2014 11:21:50 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> Date: Thu, 22 May 2014 14:21:50 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DHrhkvwS0X0yNvvHUik6YwFrUz0 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 18:21:54 -0000 Jamal, I really appreciate your participating in the discussion and trying to pull the requirements out of the architecture draft. Here are a few of my observations of the full discussion, though. a) Technically, both NetConf/RestConf/YANG and ForCES could work with some modifications. b) Where there is overlap between I2RS and network configuration, using YANG will allow shared model groups that should decrease the work needed. c) Active contributors from three different companies that are planning or working on implementing I2RS said that they'd prefer to start from NetConf/RestConf/YANG for I2RS. d) There are several existing tool-chains to facilitate YANG model development. There are multiple implementations of NetConf and planned of RestConf that can be used as a starting point for I2RS. Some of these happen to be open source; those planning implementations have ready access to a choice of tool-chains. Unfortunately, sometimes rough consensus means that arguments for one thing are heard, considered, and still do not change the outcome. It is critical to ensure that those arguments are heard and fairly discussed. There is a difference between X could do this and only X could do this. Personally, I do not think that there are unwritten requirements for I2RS; I think the basics are clearly articulated in the architecture draft. I do think that the gap analysis for YANG and for RestConf/NetConf will be quite interesting and needs to be done quickly to be timed with the work on-going in NetMod and NetConf. Regards, Alia On Thu, May 22, 2014 at 11:22 AM, Jamal Hadi Salim wrote: > Jeff/Ed, > > First of all I want to thank you both; i think you both tried hard to > provide the > opportunity given the constraints. > Second: I have no qualms with the WG moving forward - I understand progress MUST > be made. Andy, no hard feelings I hope. > > Having said that, I would like to speak my mind. I am disappointed and > I would like to address > the two points described as cause for the decision. > > On the "more support" for netconf/yang: > ================================ > My view is this boils down to popularity contest as opposed to > engineering requirements. > I wouldnt call this a process breakdown in I2RS - just that in general > the IETF allows the system > to be very hackable. It is like money in politics. While I empathize with folks > who have implemented netconf/yang and feel that is the path forward - > i would argue the > voting system is highly stacked. I know this is how the "game" has > been played over the > years - but for sometime now I feel like we need a new system for > voting. Things should not be > judged based on a simple +1 or a hum (I should have advertised > somewhere for people to > show up and "vote" for ForCES which would have been dishonest). > Voting would have more more sense if there were clear requirements to > begin with from which > a clear checklist could be derived. > There were no specific requirements. I am sure there was intent but > assumptions were made > that netconf/yang is the way to go from the get-go. > There was not even effort to match against some requirements for > netconf/restconf/yang > when I put out a wiki update. There was not even an attempt to > dis/credit what i listed as requirements. > >From day one at the BOF, netconf and Yang were being presented as the answer. > I remember standing up at the BOF mike and asking why solutions were > being presented before > requirements - IIRC the answer was i could present my own favorite > protocol if i wanted to > and that process would be followed. An engineering task requires > explicit call out of requirements > first. > > Note: I am not arguing for ForCES here - but it aint > Netconf/restconf/Yang and neither do i think > those will require a minor surgery to work (as per my view of the > requirements). And from that > perspective I am unhappy - I wish we actually used a matrix of some > sort to prove me wrong > but the answer seems like "we'll fix it". > > On "open source availability" > ======================= > The notion that because there is some open source implementation it qualifies > some solution as legit is a red herring. 90% of IETF standards dont > pass that smell test. > There is no such requirement anywhere. > There is *absolutely* no open source implementation of I2RS using > netconf/restconf/yang. > I *doubt* there is one in any organization anywhere on the globe. So > this boils down to be > a marketing gimmick in an engineering organization. Which is where my > frustration comes in. > Perhaps the starting point at IETF is to go back to the old days of > implementing first as open > source variant, get cohesion around it and then standardizing. > > I hope my views arent too harsh (I just wanted to feed that elephant > in the room some peanuts). > > cheers, > jamal > > On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: >> Working Group, >> >> We committed to spend the weeks following last session in London for IETF 89 >> to look at our proposed data modeling languages and protocols in more >> detail. While that conversation on the mail list didn't yield an explicit >> set of requirements (but thanks to Jamal for taking the first formal try at >> it), significant discussion occurred comparing and contrasting the benefits >> of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps in >> both proposals that would need to be addressed for use by I2RS. >> >> Each proposed mechanism had a few benefits in contrast to its counterpart, >> but none of these were overwhelming in scope. >> >> Our judgment of group consensus is that while both FORCES and Netconf/Yang >> could serve I2RS that there is substantially more support for the >> Netconf/Yang proposal. Part of this consideration includes elements of >> expediency such as existing open source tool chains and implementation >> experience of I2RS-like mechanisms in other organizations and vendors. >> >> Our near-term goals are to formally document the observed gaps in >> Netconf/Restconf and Yang with regard to I2RS uses and take them to their >> home working groups to be worked upon. After discussing this detail with >> our ADs, we can do so either in the form of documenting this upon the wiki >> or in the form of a requirements Internet-Draft. We welcome the chance to >> choose our form of agility for this effort. >> >> We will be forming a design team in the near future to work on the gap >> analysis and try to bring the necessary work to closure in short order. >> >> -- Ed and Jeff >> >> _______________________________________________ >> 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 Thu May 22 11:23:30 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 E80571A027D for ; Thu, 22 May 2014 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E75qSkawoWbJ for ; Thu, 22 May 2014 11:23:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4E51A0275 for ; Thu, 22 May 2014 11:23:12 -0700 (PDT) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB564.namprd05.prod.outlook.com (10.141.202.150) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 18:23:03 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0944.000; Thu, 22 May 2014 18:23:03 +0000 From: John E Drake To: Jamal Hadi Salim Thread-Topic: [i2rs] Consensus on I2RS data modeling language and protocol Thread-Index: AQHPdTRlm1rPvZLwbkiU780/k5L0yJtMuPaAgAAOJ1yAABM0AIAACGBAgAAFqwCAAAJeQA== Date: Thu, 22 May 2014 18:23:02 +0000 Message-ID: References: <20140521203605.GM9789@pfrc> <511468be1b9b4aafab0fa3aedaa8a481@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.16] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(189002)(199002)(24454002)(51704005)(377454003)(64706001)(2656002)(21056001)(92566001)(77096999)(76576001)(76482001)(85852003)(66066001)(33646001)(99396002)(31966008)(54356999)(76176999)(101416001)(74662001)(87936001)(80022001)(86362001)(74502001)(81542001)(19580405001)(19580395003)(79102001)(81342001)(50986999)(83072002)(77982001)(74316001)(83322001)(46102001)(4396001)(20776003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB564; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pJD0O5NqLSHUAJvWcozRI-tCOCg Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 18:23:18 -0000 SSBoYXZlIHJlYWQgZXZlcnkgcG9zdCB0byB0aGUgSTJSUyBtYWlsaW5nIGxpc3Qgc2luY2UgaXRz IGluY2VwdGlvbi4gIEFzIGEgZ2VuZXJhbCBjb21tZW50LCBzZW5kaW5nIHRoZSBzYW1lIGVtYWls IHJlcGVhdGVkbHkgZG9lcyBub3QgbWFrZSBvbmUncyBwb2ludCBtb3JlIG1lYW5pbmdmdWwuDQoN CllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogSmFtYWwgSGFkaSBTYWxpbSBbbWFpbHRvOmhhZGlAbW9qYXRhdHUuY29t XQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDIyLCAyMDE0IDExOjEyIEFNDQo+IFRvOiBKb2huIEUg RHJha2UNCj4gQ2M6IEplZmZyZXkgSGFhczsgaTJyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W2kycnNdIENvbnNlbnN1cyBvbiBJMlJTIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UgYW5kIHByb3Rv Y29sDQo+IA0KPiBPbiBUaHUsIE1heSAyMiwgMjAxNCBhdCAyOjA0IFBNLCBKb2huIEUgRHJha2Ug PGpkcmFrZUBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IA0KPiA+IFtKRF0gIFJpZ2h0LCBhbnkgcHJv Y2VzcyB0aGF0IGRvZXMgbm90IHNlbGVjdCBGT1JDRVMgaXMgYnkgZGVmaW5pdGlvbg0KPiBpbnRy aW5zaWNhbGx5IGZsYXdlZC4NCj4gPg0KPiANCj4gU2VyaW91c2x5Pw0KPiBJcyB5b3VyIHJlYWRp bmcgcGF0aWVuY2UgYXQgdGhlIHNhbWUgdGVyc2VuZXNzIGFzIHlvdXIgd3JpdGluZz8NCj4gDQo+ IGNoZWVycywNCj4gamFtYWwNCg== From nobody Thu May 22 11:47:05 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 0AF8A1A0290 for ; Thu, 22 May 2014 11:47:03 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 tMvK8WBiMQK5 for ; Thu, 22 May 2014 11:47:00 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6862E1A0228 for ; Thu, 22 May 2014 11:47:00 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jz11so4902069veb.7 for ; Thu, 22 May 2014 11:46:58 -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:from:date :message-id:subject:to:cc:content-type; bh=E4YkqxSx5acUt1P5tq5PvpQQOWqg4moBHxQ8zeOaYIw=; b=KqUscAl3YmN8d3TtGqD5Qeg0DLqRaqt8CJTFX1wUW3IvRtNfaK1gcMIOa+W4DclW3E aBoGr77eJc0+cMRzajI9CGfuE1V2KGbnv4U/LlGZedoQ4Y2vffLMQTh2xXH8hFMd4/Dc 7A4FIZVHGwsA2MyHljdix/HdMxNmm0yzb4RoTFvXN4FwzKYa0n+g+oHt0BJDrgpB9/jk LDc7e8fxekK7O94RtSfFoHA+KnsTuhtJk1wRXDX4AZBKbgeUDEDftjbEKHvODpZuwpo8 Bl9o5rAi8t2JYb6jqVh0YAp4rKkq0b+9velEthG8rf07eNWo80UiKHnmFnKeodeh9d4S 7/Qg== X-Gm-Message-State: ALoCoQni8Jh1erikxEPoyGjKVTCOkopxVkfaPl/xI0jwKiYQGZCeL1oZq/+jf1X6ETI3g6tyXgY1 X-Received: by 10.52.255.65 with SMTP id ao1mr2666117vdd.43.1400784418493; Thu, 22 May 2014 11:46:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 11:46:38 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 14:46:38 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ynZBET0hDKE628TjRinWyrNZMOg Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 18:47:03 -0000 Alia, You make reasonable arguement and i would agree there are requirements scattered all over the place not totally missing. I didnt think that my arguements were "heard and considered" as you describe. My main of arguement was to use a requirements matrix. I dont think that was considered (Andy says he heard). I understand the desire to move fast - thats why i am not disagreeing on moving forward. On your points, I empathize with #c. I am pretty sure that is the main driver. I didnt quiet get #b - is sharing a requirement or a good-to-have at all? On #d: My challenge is accepting something without seeing a gap analysis first. To me this overrides the economics of #c. So i am going to wait to see how the selections actually meet the requirements and how much refactoring is going to be needed for the protocols before i am convinced. cheers, jamal On Thu, May 22, 2014 at 2:21 PM, Alia Atlas wrote: > Jamal, > > I really appreciate your participating in the discussion and trying to > pull the requirements out of the > architecture draft. Here are a few of my observations of the full > discussion, though. > > a) Technically, both NetConf/RestConf/YANG and ForCES could work with > some modifications. > b) Where there is overlap between I2RS and network configuration, > using YANG will allow shared model groups > that should decrease the work needed. > c) Active contributors from three different companies that are > planning or working on implementing I2RS said > that they'd prefer to start from NetConf/RestConf/YANG for I2RS. > d) There are several existing tool-chains to facilitate YANG model > development. There are multiple > implementations of NetConf and planned of RestConf that can be used as > a starting point for I2RS. Some of > these happen to be open source; those planning implementations have > ready access to a choice of tool-chains. > > Unfortunately, sometimes rough consensus means that arguments for one > thing are heard, considered, and > still do not change the outcome. It is critical to ensure that those > arguments are heard and fairly discussed. > There is a difference between X could do this and only X could do this. > > Personally, I do not think that there are unwritten requirements for > I2RS; I think the basics are clearly articulated > in the architecture draft. I do think that the gap analysis for YANG > and for RestConf/NetConf will be quite interesting > and needs to be done quickly to be timed with the work on-going in > NetMod and NetConf. > > Regards, > Alia > > On Thu, May 22, 2014 at 11:22 AM, Jamal Hadi Salim wrote: >> Jeff/Ed, >> >> First of all I want to thank you both; i think you both tried hard to >> provide the >> opportunity given the constraints. >> Second: I have no qualms with the WG moving forward - I understand progress MUST >> be made. Andy, no hard feelings I hope. >> >> Having said that, I would like to speak my mind. I am disappointed and >> I would like to address >> the two points described as cause for the decision. >> >> On the "more support" for netconf/yang: >> ================================ >> My view is this boils down to popularity contest as opposed to >> engineering requirements. >> I wouldnt call this a process breakdown in I2RS - just that in general >> the IETF allows the system >> to be very hackable. It is like money in politics. While I empathize with folks >> who have implemented netconf/yang and feel that is the path forward - >> i would argue the >> voting system is highly stacked. I know this is how the "game" has >> been played over the >> years - but for sometime now I feel like we need a new system for >> voting. Things should not be >> judged based on a simple +1 or a hum (I should have advertised >> somewhere for people to >> show up and "vote" for ForCES which would have been dishonest). >> Voting would have more more sense if there were clear requirements to >> begin with from which >> a clear checklist could be derived. >> There were no specific requirements. I am sure there was intent but >> assumptions were made >> that netconf/yang is the way to go from the get-go. >> There was not even effort to match against some requirements for >> netconf/restconf/yang >> when I put out a wiki update. There was not even an attempt to >> dis/credit what i listed as requirements. >> >From day one at the BOF, netconf and Yang were being presented as the answer. >> I remember standing up at the BOF mike and asking why solutions were >> being presented before >> requirements - IIRC the answer was i could present my own favorite >> protocol if i wanted to >> and that process would be followed. An engineering task requires >> explicit call out of requirements >> first. >> >> Note: I am not arguing for ForCES here - but it aint >> Netconf/restconf/Yang and neither do i think >> those will require a minor surgery to work (as per my view of the >> requirements). And from that >> perspective I am unhappy - I wish we actually used a matrix of some >> sort to prove me wrong >> but the answer seems like "we'll fix it". >> >> On "open source availability" >> ======================= >> The notion that because there is some open source implementation it qualifies >> some solution as legit is a red herring. 90% of IETF standards dont >> pass that smell test. >> There is no such requirement anywhere. >> There is *absolutely* no open source implementation of I2RS using >> netconf/restconf/yang. >> I *doubt* there is one in any organization anywhere on the globe. So >> this boils down to be >> a marketing gimmick in an engineering organization. Which is where my >> frustration comes in. >> Perhaps the starting point at IETF is to go back to the old days of >> implementing first as open >> source variant, get cohesion around it and then standardizing. >> >> I hope my views arent too harsh (I just wanted to feed that elephant >> in the room some peanuts). >> >> cheers, >> jamal >> >> On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: >>> Working Group, >>> >>> We committed to spend the weeks following last session in London for IETF 89 >>> to look at our proposed data modeling languages and protocols in more >>> detail. While that conversation on the mail list didn't yield an explicit >>> set of requirements (but thanks to Jamal for taking the first formal try at >>> it), significant discussion occurred comparing and contrasting the benefits >>> of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps in >>> both proposals that would need to be addressed for use by I2RS. >>> >>> Each proposed mechanism had a few benefits in contrast to its counterpart, >>> but none of these were overwhelming in scope. >>> >>> Our judgment of group consensus is that while both FORCES and Netconf/Yang >>> could serve I2RS that there is substantially more support for the >>> Netconf/Yang proposal. Part of this consideration includes elements of >>> expediency such as existing open source tool chains and implementation >>> experience of I2RS-like mechanisms in other organizations and vendors. >>> >>> Our near-term goals are to formally document the observed gaps in >>> Netconf/Restconf and Yang with regard to I2RS uses and take them to their >>> home working groups to be worked upon. After discussing this detail with >>> our ADs, we can do so either in the form of documenting this upon the wiki >>> or in the form of a requirements Internet-Draft. We welcome the chance to >>> choose our form of agility for this effort. >>> >>> We will be forming a design team in the near future to work on the gap >>> analysis and try to bring the necessary work to closure in short order. >>> >>> -- Ed and Jeff >>> >>> _______________________________________________ >>> 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 Thu May 22 11:48: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 0DE671A029D for ; Thu, 22 May 2014 11:48:22 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 UyR0a72jiKJM for ; Thu, 22 May 2014 11:48:20 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CDA1A02C9 for ; Thu, 22 May 2014 11:48:10 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jw12so4984115veb.34 for ; Thu, 22 May 2014 11:48:07 -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:from:date :message-id:subject:to:cc:content-type; bh=vyriE/MntW4BwxA1fUJvGebLTg9gV2H/GmYPpKBaTqY=; b=OayWjN3vZvjLNd/6qgdfbAJQdWAmctjHqFFrJq9CEs/39nNtO/CCNuK7tVRrGIIOR8 uzOfiwVakMy+TfYctTM0zdA/azyVap5KMk3FYYrVOE1KRu1FQNqvXNSMXGAq1UKI4OJ2 icC2LlO70Si88LJzQUHd1WPYqTvFaATdCEolCHrJLIOGBd0Q3hO0oe6mqeXxTEXhB+mT PLmhBfWF+7QDZiFtPpqZAoUBLnnhcupCCpa2EOglqSup8UT3VIn6+mHdLp9D+NOBrt37 Zrhw6AgzyFWggFwcc2iNm7vByAsufkCR6GKJ2725Tuhkx+eEZVtiYft0ZbK6Ktan+Jhd wssA== X-Gm-Message-State: ALoCoQmKvrYncolxC0t/gRikFKfwsoMTw2f2fd8lJNhdZ486la+vL5VjHuVWFkpk7QTrSppDEQK+ X-Received: by 10.52.185.72 with SMTP id fa8mr14659797vdc.12.1400784487260; Thu, 22 May 2014 11:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 11:47:46 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> <511468be1b9b4aafab0fa3aedaa8a481@BLUPR05MB562.namprd05.prod.outlook.com> From: Jamal Hadi Salim Date: Thu, 22 May 2014 14:47:46 -0400 Message-ID: To: John E Drake Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ctlQucc1j0COlDxMXyW_jHTFBCM Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 18:48:22 -0000 John, As Ed says lets end this meaningless discussion. yours respectfully, jamal On Thu, May 22, 2014 at 2:23 PM, John E Drake wrote: > I have read every post to the I2RS mailing list since its inception. As a general comment, sending the same email repeatedly does not make one's point more meaningful. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] >> Sent: Thursday, May 22, 2014 11:12 AM >> To: John E Drake >> Cc: Jeffrey Haas; i2rs@ietf.org >> Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol >> >> On Thu, May 22, 2014 at 2:04 PM, John E Drake wrote: >> >> > [JD] Right, any process that does not select FORCES is by definition >> intrinsically flawed. >> > >> >> Seriously? >> Is your reading patience at the same terseness as your writing? >> >> cheers, >> jamal From nobody Thu May 22 12:16:00 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 1BCC81A02FE for ; Thu, 22 May 2014 12:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 aGTaF2bu5vzE for ; Thu, 22 May 2014 12:15:55 -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 6D06A1A02EB for ; Thu, 22 May 2014 12:15:51 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so3372729yha.4 for ; Thu, 22 May 2014 12:15:49 -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=ed4oT/ZgHX9W5zm5ZTP9a92kFpSM2mjdULSUh08lJ8w=; b=cCSSKfo3kxY9xEtKThuLkMnbRESlDFL9YTXd3rOP2cz9HfKJXc+VUCQ25iO9hjwZr/ w5Mk9oBxVgz3iVMT1XfDK9ABSMr9m+cAvTn7Nk2hL4HfSlHwM2QSh5+4w9kMSnO4mOtf a/A46FkB/GXWmv2Ib3hleLDz8iun/0mxpmTpWIyx6R/d3X16u9zyNkaIRNg4uUYXtBFJ oRQyJclCNc9zR17fXOCS0KYEtqkx4IoSeRGijVc0SjotukL8LJNyn8iLNGLX3IN+wBFZ xTYlLeLgf6NyyNPMWtIEvzhQjhDEC1O1iz3RpNqxd+R+/njV5E1/W/JkNQS2cdz6ZL+0 4QKQ== MIME-Version: 1.0 X-Received: by 10.236.105.141 with SMTP id k13mr39972732yhg.141.1400786149742; Thu, 22 May 2014 12:15:49 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Thu, 22 May 2014 12:15:49 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> Date: Thu, 22 May 2014 15:15:49 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ja6Knno7Nm8eAa_WEhfTHOUNX2E Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 19:15:58 -0000 Hi Jamal, On Thu, May 22, 2014 at 2:46 PM, Jamal Hadi Salim wrote: > Alia, > > You make reasonable arguement and i would agree there are requirements > scattered all over the place not totally missing. I didnt think that > my arguements > were "heard and considered" as you describe. My main of arguement was to use > a requirements matrix. I dont think that was considered (Andy says he heard). > I understand the desire to move fast - thats why i am not disagreeing on > moving forward. [Alia] If your arguments hadn't been being listened to and considered, the decision would have happened many months ago. At the end of the day, despite a year of discussion and suggestion for ForCES, others who are planning on implementing were not persuaded nor was there a technical reason that precluded a different choice. > On your points, I empathize with #c. I am pretty sure that is the main driver. > I didnt quiet get #b - is sharing a requirement or a good-to-have at all? [Alia] Given that either technology is possible, #b is a good to have that will simplify learning, implementation, work to be done on many models, and probably operations. > On #d: > My challenge is accepting something without seeing a gap analysis first. > To me this overrides the economics of #c. > So i am going to wait to see how the selections actually meet > the requirements and how much refactoring is going to be needed for the > protocols before i am convinced. [Alia] There was some discussion of gap analysis earlier to give concepts to the WG. I would like to see it written down cleanly with reasons in either the wiki or a draft. I don't think that waiting for completion on each step before any progress is made on the others is a good idea. It is clear from the list discussion that there are many interested people waiting for the WG to get on to the solutions step. Regards, Alia > cheers, > jamal > > > On Thu, May 22, 2014 at 2:21 PM, Alia Atlas wrote: >> Jamal, >> >> I really appreciate your participating in the discussion and trying to >> pull the requirements out of the >> architecture draft. Here are a few of my observations of the full >> discussion, though. >> >> a) Technically, both NetConf/RestConf/YANG and ForCES could work with >> some modifications. >> b) Where there is overlap between I2RS and network configuration, >> using YANG will allow shared model groups >> that should decrease the work needed. >> c) Active contributors from three different companies that are >> planning or working on implementing I2RS said >> that they'd prefer to start from NetConf/RestConf/YANG for I2RS. >> d) There are several existing tool-chains to facilitate YANG model >> development. There are multiple >> implementations of NetConf and planned of RestConf that can be used as >> a starting point for I2RS. Some of >> these happen to be open source; those planning implementations have >> ready access to a choice of tool-chains. >> >> Unfortunately, sometimes rough consensus means that arguments for one >> thing are heard, considered, and >> still do not change the outcome. It is critical to ensure that those >> arguments are heard and fairly discussed. >> There is a difference between X could do this and only X could do this. >> >> Personally, I do not think that there are unwritten requirements for >> I2RS; I think the basics are clearly articulated >> in the architecture draft. I do think that the gap analysis for YANG >> and for RestConf/NetConf will be quite interesting >> and needs to be done quickly to be timed with the work on-going in >> NetMod and NetConf. >> >> Regards, >> Alia >> >> On Thu, May 22, 2014 at 11:22 AM, Jamal Hadi Salim wrote: >>> Jeff/Ed, >>> >>> First of all I want to thank you both; i think you both tried hard to >>> provide the >>> opportunity given the constraints. >>> Second: I have no qualms with the WG moving forward - I understand progress MUST >>> be made. Andy, no hard feelings I hope. >>> >>> Having said that, I would like to speak my mind. I am disappointed and >>> I would like to address >>> the two points described as cause for the decision. >>> >>> On the "more support" for netconf/yang: >>> ================================ >>> My view is this boils down to popularity contest as opposed to >>> engineering requirements. >>> I wouldnt call this a process breakdown in I2RS - just that in general >>> the IETF allows the system >>> to be very hackable. It is like money in politics. While I empathize with folks >>> who have implemented netconf/yang and feel that is the path forward - >>> i would argue the >>> voting system is highly stacked. I know this is how the "game" has >>> been played over the >>> years - but for sometime now I feel like we need a new system for >>> voting. Things should not be >>> judged based on a simple +1 or a hum (I should have advertised >>> somewhere for people to >>> show up and "vote" for ForCES which would have been dishonest). >>> Voting would have more more sense if there were clear requirements to >>> begin with from which >>> a clear checklist could be derived. >>> There were no specific requirements. I am sure there was intent but >>> assumptions were made >>> that netconf/yang is the way to go from the get-go. >>> There was not even effort to match against some requirements for >>> netconf/restconf/yang >>> when I put out a wiki update. There was not even an attempt to >>> dis/credit what i listed as requirements. >>> >From day one at the BOF, netconf and Yang were being presented as the answer. >>> I remember standing up at the BOF mike and asking why solutions were >>> being presented before >>> requirements - IIRC the answer was i could present my own favorite >>> protocol if i wanted to >>> and that process would be followed. An engineering task requires >>> explicit call out of requirements >>> first. >>> >>> Note: I am not arguing for ForCES here - but it aint >>> Netconf/restconf/Yang and neither do i think >>> those will require a minor surgery to work (as per my view of the >>> requirements). And from that >>> perspective I am unhappy - I wish we actually used a matrix of some >>> sort to prove me wrong >>> but the answer seems like "we'll fix it". >>> >>> On "open source availability" >>> ======================= >>> The notion that because there is some open source implementation it qualifies >>> some solution as legit is a red herring. 90% of IETF standards dont >>> pass that smell test. >>> There is no such requirement anywhere. >>> There is *absolutely* no open source implementation of I2RS using >>> netconf/restconf/yang. >>> I *doubt* there is one in any organization anywhere on the globe. So >>> this boils down to be >>> a marketing gimmick in an engineering organization. Which is where my >>> frustration comes in. >>> Perhaps the starting point at IETF is to go back to the old days of >>> implementing first as open >>> source variant, get cohesion around it and then standardizing. >>> >>> I hope my views arent too harsh (I just wanted to feed that elephant >>> in the room some peanuts). >>> >>> cheers, >>> jamal >>> >>> On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas wrote: >>>> Working Group, >>>> >>>> We committed to spend the weeks following last session in London for IETF 89 >>>> to look at our proposed data modeling languages and protocols in more >>>> detail. While that conversation on the mail list didn't yield an explicit >>>> set of requirements (but thanks to Jamal for taking the first formal try at >>>> it), significant discussion occurred comparing and contrasting the benefits >>>> of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps in >>>> both proposals that would need to be addressed for use by I2RS. >>>> >>>> Each proposed mechanism had a few benefits in contrast to its counterpart, >>>> but none of these were overwhelming in scope. >>>> >>>> Our judgment of group consensus is that while both FORCES and Netconf/Yang >>>> could serve I2RS that there is substantially more support for the >>>> Netconf/Yang proposal. Part of this consideration includes elements of >>>> expediency such as existing open source tool chains and implementation >>>> experience of I2RS-like mechanisms in other organizations and vendors. >>>> >>>> Our near-term goals are to formally document the observed gaps in >>>> Netconf/Restconf and Yang with regard to I2RS uses and take them to their >>>> home working groups to be worked upon. After discussing this detail with >>>> our ADs, we can do so either in the form of documenting this upon the wiki >>>> or in the form of a requirements Internet-Draft. We welcome the chance to >>>> choose our form of agility for this effort. >>>> >>>> We will be forming a design team in the near future to work on the gap >>>> analysis and try to bring the necessary work to closure in short order. >>>> >>>> -- Ed and Jeff >>>> >>>> _______________________________________________ >>>> 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 Thu May 22 13:20: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 F3F651A0380 for ; Thu, 22 May 2014 13:20:22 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 6ePfZMbNU3T9 for ; Thu, 22 May 2014 13:20:16 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BC31A0379 for ; Thu, 22 May 2014 13:20:02 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ij19so5095322vcb.14 for ; Thu, 22 May 2014 13:20:00 -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:from:date :message-id:subject:to:cc:content-type; bh=8EjdW0ga8SqxN9b5uHXM82ODGtbEqM3Uas+ifpRm9cQ=; b=JcW37Zfz6P4WITxcoT4rlukiZUWmzKd78T0NU/96R+vWspojS9TaHfcjjEmvX017Uo AfuU/oje1HK219dAJFKvbbIVP2sOz07VyahpgUMUgrKMlYmyA8PsGeNb+Y9RdlRAwAjB hiYm0hHVNDBYYzmsMt4rGGWuJo0HZ3VoR3HS+hQV0JdPYXNmqsU9cwOn1EnXFcPhQjFn nRira+1FYdc1xuQsJkx2MdyILVKAdSqiQRnhqytzp7URQddgyopluaMX7gw1Vbyzluj4 Kez7A6o/stuyGYZYpxSRXBCTZ33HlC8/+Ux7O74sKOpJPX54qbN4HXdDeSOn2Yds6PJN FBaA== X-Gm-Message-State: ALoCoQlzK5Hgj8dlVRdfefMZ3nGagU9HI44xkz/4rgPHnjzMhy8qH2oogka/GQk0kFjukZ1AULJL X-Received: by 10.58.188.115 with SMTP id fz19mr57425vec.40.1400790000138; Thu, 22 May 2014 13:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 13:19:39 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 16:19:39 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JwlBWUUI4qZJRbKX-cq8lM18A8g Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 20:20:24 -0000 Hi Alia, On Thu, May 22, 2014 at 3:15 PM, Alia Atlas wrote: > Hi Jamal, > > [Alia] If your arguments hadn't been being listened to and > considered, the decision would have happened many months ago. Sorry, I dont mean to be ungrateful but I was referring to the last 2 months or so process where i thought the real discussion was happening. Yes, you could have dismissed ForCES right off the bat - and we have come a long way; thanks for at least providing that opportunity. > At the end of the day, despite a year of > discussion and suggestion for ForCES, others who are planning on implementing > were not persuaded nor was there a technical reason that precluded a > different choice. > Persuading people already vested in netconf/restconf/yang could only happen if the starting point was requirements from which the proposed solutions are cross-checked. Note: I recall the first time i brought it up, both yourself and Ed made it clear you were in favor of netconf/yang. I think i would have had a better chance convincing people otherwise against a requirements list. > [Alia] Given that either technology is possible, #b is a good to have > that will simplify > learning, implementation, work to be done on many models, and probably > operations. > Ok. >> On #d: >> My challenge is accepting something without seeing a gap analysis first. >> To me this overrides the economics of #c. >> So i am going to wait to see how the selections actually meet >> the requirements and how much refactoring is going to be needed for the >> protocols before i am convinced. > > [Alia] There was some discussion of gap analysis earlier to give > concepts to the WG. > I would like to see it written down cleanly with reasons in either the > wiki or a draft. > I don't think that waiting for completion on each step before any > progress is made on > the others is a good idea. It is clear from the list discussion that > there are many > interested people waiting for the WG to get on to the solutions step. > Then lets please move on. Like i said i will be curiously observing. cheers, jamal From nobody Thu May 22 13:29:58 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 5C2D51A026A for ; Thu, 22 May 2014 13:29:57 -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 BOfupoNdrmM4 for ; Thu, 22 May 2014 13:29:55 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4E11A0219 for ; Thu, 22 May 2014 13:29:55 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id z6so3463230yhz.25 for ; Thu, 22 May 2014 13:29: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=V7cHqihe+pWzfDD0QGqklTT3tzvK+t3gfZigpmGn6xI=; b=jaZpiK1l8vap73/AjKB2kAy8BZ5YtH2HGlxUNzk6SeHviu4maERr2MMvTAeUz7La3v Oqu9RCoY6o72bbkWEaKFwThHONXtXDZnIkoepkyTXShBueIK4JFg+r6pzdzCpAiYqd8n a9XICrf2WglYkKSvIhd2KW6V/ApGPldOiMV8tZNxFsqSEeVvDURoCKLCfYLdtFC5kZSx Pf978E9ovmxjCh+TeXLmTQ58hOiFQD1BfRoYvBREhbK5wiyVqv/Aj9FlirbIWSGTk9ut F6YEyzUtzhcJmplQD4xdUfPEXmQdq6A0SbdICwy2e7tGjOj8Cz+Oyku44jwfcdBLxOKH fFuw== MIME-Version: 1.0 X-Received: by 10.236.168.42 with SMTP id j30mr89414589yhl.101.1400790593822; Thu, 22 May 2014 13:29:53 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Thu, 22 May 2014 13:29:53 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> Date: Thu, 22 May 2014 16:29:53 -0400 Message-ID: From: Alia Atlas To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=20cf305b13debfe4fd04fa02f974 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/sHlo_wOkxuK_4hQSypUOSXqBqbE Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 20:29:57 -0000 --20cf305b13debfe4fd04fa02f974 Content-Type: text/plain; charset=UTF-8 Hi Jamal, I do agree on moving on. But, just to clarify, I didn't start I2RS thinking that NetConf/YANG were the right answer - though RestConf comes closer. I also know that ForCES has a lot of really good technology. I do and did know of the business considerations that were expressed during the discussion. I was trying to not have a strong opinion and be sure that you were given time to articulate why ForCES was not only possible but might be better enough technically to be able to handle the business considerations. I apologize if that came across as having made up my mind; I was trying to listen to the others in the WG as well and those opinions were fairly uniform. Regards, Alia On Thu, May 22, 2014 at 4:19 PM, Jamal Hadi Salim wrote: > Hi Alia, > > On Thu, May 22, 2014 at 3:15 PM, Alia Atlas wrote: > > Hi Jamal, > > > > > [Alia] If your arguments hadn't been being listened to and > > considered, the decision would have happened many months ago. > > Sorry, I dont mean to be ungrateful but I was referring to the last 2 > months > or so process where i thought the real discussion was happening. Yes, you > could > have dismissed ForCES right off the bat - and we have come a long way; > thanks > for at least providing that opportunity. > > > At the end of the day, despite a year of > > discussion and suggestion for ForCES, others who are planning on > implementing > > were not persuaded nor was there a technical reason that precluded a > > different choice. > > > > Persuading people already vested in netconf/restconf/yang could only happen > if the starting point was requirements from which the proposed solutions > are > cross-checked. > Note: I recall the first time i brought it up, both yourself and Ed > made it clear > you were in favor of netconf/yang. I think i would have had a better chance > convincing people otherwise against a requirements list. > > > [Alia] Given that either technology is possible, #b is a good to have > > that will simplify > > learning, implementation, work to be done on many models, and probably > > operations. > > > > Ok. > > >> On #d: > >> My challenge is accepting something without seeing a gap analysis first. > >> To me this overrides the economics of #c. > >> So i am going to wait to see how the selections actually meet > >> the requirements and how much refactoring is going to be needed for the > >> protocols before i am convinced. > > > > [Alia] There was some discussion of gap analysis earlier to give > > concepts to the WG. > > I would like to see it written down cleanly with reasons in either the > > wiki or a draft. > > I don't think that waiting for completion on each step before any > > progress is made on > > the others is a good idea. It is clear from the list discussion that > > there are many > > interested people waiting for the WG to get on to the solutions step. > > > > Then lets please move on. Like i said i will be curiously observing. > > cheers, > jamal > --20cf305b13debfe4fd04fa02f974 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jamal,

I do agree on moving on. =C2= =A0But, just to clarify, I didn't start I2RS thinking that NetConf/YANG= were the right answer - though RestConf comes closer. =C2=A0 I also know t= hat ForCES has a lot of really
good technology. =C2=A0I do and did know of the business consideration= s that were expressed
during the discussion.=C2=A0

=
I was trying to not have a strong opinion and be sure that you w= ere given time to articulate
why ForCES was not only possible but might be better enough technicall= y to be able to handle
the business considerations. =C2=A0 I apol= ogize if that came across as having made up my mind; I was trying to listen= to the others in the WG as well and those opinions were fairly uniform.

Regards,
Alia


On Thu, May 22, 2014 at 4:19 PM, Jam= al Hadi Salim <hadi@mojatatu.com> wrote:
Hi Alia,

On Thu, May 22, 2014 at 3:15 PM, Alia Atlas <akatlas@gmail.com> wrote:
> Hi Jamal,

>
> [Alia] =C2=A0If your arguments hadn't been being listened to and > considered, the decision would have happened many months ago.

Sorry, I dont mean to be ungrateful =C2=A0but I was referring to the = last 2 months
or so process where i thought the real discussion was happening. Yes, you c= ould
have dismissed ForCES right off the bat - and we have come a long way; than= ks
for at least providing that opportunity.

> At the end of the day, despite a year of
> discussion and suggestion for ForCES, others who are planning on imple= menting
> were not persuaded nor was there a technical reason that precluded a > different choice.
>

Persuading people already vested in netconf/restconf/yang could only = happen
if the starting point was requirements from which the proposed solutions ar= e
cross-checked.
Note: I recall the first time i brought it up, both yourself and Ed
made it clear
you were in favor of netconf/yang. I think i would have had a better chance=
convincing people otherwise against a requirements list.

> [Alia] Given that either technology is possible, #b is a good to have<= br> > that will simplify
> learning, implementation, work to be done on many models, and probably=
> operations.
>

Ok.

>> On #d:
>> My challenge is accepting something without seeing a gap analysis = first.
>> To me this overrides the economics of #c.
>> So i am going to wait to see how the selections actually meet
>> the requirements and how much refactoring is going to be needed fo= r the
>> protocols before i am convinced.
>
> [Alia] There was some discussion of gap analysis earlier to give
> concepts to the WG.
> I would like to see it written down cleanly with reasons in either the=
> wiki or a draft.
> I don't think that waiting for completion on each step before any<= br> > progress is made on
> the others is a good idea. =C2=A0It is clear from the list discussion = that
> there are many
> interested people waiting for the WG to get on to the solutions step.<= br> >

Then lets please move on. Like i said i will be curiously observing.<= br>
cheers,
jamal

--20cf305b13debfe4fd04fa02f974-- From nobody Thu May 22 13:34: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 13A881A0366 for ; Thu, 22 May 2014 13:34:00 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 C6rO05nYt5TM for ; Thu, 22 May 2014 13:33:56 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC881A02F2 for ; Thu, 22 May 2014 13:33:55 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jx11so5206573veb.0 for ; Thu, 22 May 2014 13:33:54 -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:from:date :message-id:subject:to:cc:content-type; bh=DfbNNjya5rMfHMEniPBBJZsy/OYEenAKCUks8vrViBs=; b=NUXdUTuHIjFY9g40L8d3tqT27GyK1szb8y+SIXzfFCR7ahr4RlL4JjOa/zG+mBfpys ZFKVCfZQXmLx2htiqtpE55Nh+lX5zoLFgmmUmyRhG9s37TBDc4N/0dsyR9N9ShSZq5qj 4iai/7Zw8gE0BUSG/RROPhW8QPNjFEikayW3FpTMME0fZrbP17bpWXLycNqZq3PmhCGO 3qO1TGQLZzXTJjXhL/V29q1XyjUHxZQTdrhvXzDd6d60CD2DW+EexSsrGOqMezUph1Mb pkrbx8pUB05QkQ5uUsI+MX3dhHrXamDaUyjeB2o6LJ/60bUsT8VvVfT1ScBHzOrth39p e7FQ== X-Gm-Message-State: ALoCoQm3kVvtuZRCnyCEMSlhfRVufcvPnHcI15u9hyhOYNhApxrfJWbK8IWSsMWTXAnkAu96JqVs X-Received: by 10.58.127.101 with SMTP id nf5mr83866veb.50.1400790834196; Thu, 22 May 2014 13:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Thu, 22 May 2014 13:33:34 -0700 (PDT) In-Reply-To: References: <20140521203605.GM9789@pfrc> From: Jamal Hadi Salim Date: Thu, 22 May 2014 16:33:34 -0400 Message-ID: To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-G6U7jGxVoPpHzr6Md7G7bK7oLc Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol 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, 22 May 2014 20:34:00 -0000 Hi Alia, I appreciate the opportunity and want to thank you, Ed and Jeff. It is time to move on. cheers, jamal On Thu, May 22, 2014 at 4:29 PM, Alia Atlas wrote: > Hi Jamal, > > I do agree on moving on. But, just to clarify, I didn't start I2RS thinking > that NetConf/YANG were the right answer - though RestConf comes closer. I > also know that ForCES has a lot of really > good technology. I do and did know of the business considerations that were > expressed > during the discussion. > > I was trying to not have a strong opinion and be sure that you were given > time to articulate > why ForCES was not only possible but might be better enough technically to > be able to handle > the business considerations. I apologize if that came across as having > made up my mind; I was trying to listen to the others in the WG as well and > those opinions were fairly uniform. > > Regards, > Alia > > > > On Thu, May 22, 2014 at 4:19 PM, Jamal Hadi Salim wrote: >> >> Hi Alia, >> >> On Thu, May 22, 2014 at 3:15 PM, Alia Atlas wrote: >> > Hi Jamal, >> >> > >> > [Alia] If your arguments hadn't been being listened to and >> > considered, the decision would have happened many months ago. >> >> Sorry, I dont mean to be ungrateful but I was referring to the last 2 >> months >> or so process where i thought the real discussion was happening. Yes, you >> could >> have dismissed ForCES right off the bat - and we have come a long way; >> thanks >> for at least providing that opportunity. >> >> > At the end of the day, despite a year of >> > discussion and suggestion for ForCES, others who are planning on >> > implementing >> > were not persuaded nor was there a technical reason that precluded a >> > different choice. >> > >> >> Persuading people already vested in netconf/restconf/yang could only >> happen >> if the starting point was requirements from which the proposed solutions >> are >> cross-checked. >> Note: I recall the first time i brought it up, both yourself and Ed >> made it clear >> you were in favor of netconf/yang. I think i would have had a better >> chance >> convincing people otherwise against a requirements list. >> >> > [Alia] Given that either technology is possible, #b is a good to have >> > that will simplify >> > learning, implementation, work to be done on many models, and probably >> > operations. >> > >> >> Ok. >> >> >> On #d: >> >> My challenge is accepting something without seeing a gap analysis >> >> first. >> >> To me this overrides the economics of #c. >> >> So i am going to wait to see how the selections actually meet >> >> the requirements and how much refactoring is going to be needed for the >> >> protocols before i am convinced. >> > >> > [Alia] There was some discussion of gap analysis earlier to give >> > concepts to the WG. >> > I would like to see it written down cleanly with reasons in either the >> > wiki or a draft. >> > I don't think that waiting for completion on each step before any >> > progress is made on >> > the others is a good idea. It is clear from the list discussion that >> > there are many >> > interested people waiting for the WG to get on to the solutions step. >> > >> >> Then lets please move on. Like i said i will be curiously observing. >> >> cheers, >> jamal > > From nobody Tue May 27 11:38: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 4FDEE1A06AD; Tue, 27 May 2014 11:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pIcizj4ttUDs; Tue, 27 May 2014 11:38:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0741D1A06B1; Tue, 27 May 2014 11:38:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140527183808.6487.38364.idtracker@ietfa.amsl.com> Date: Tue, 27 May 2014 11:38:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/XqdHqpJQw-4hkJPzGdI6dI9m6BA Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 18:38:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Routing Information Base Info Model Authors : Nitin Bahadur Ron Folkes Sriganesh Kini Jan Medved Filename : draft-ietf-i2rs-rib-info-model-03.txt Pages : 24 Date : 2014-05-27 Abstract: Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a routing information base (RIB). Protocols and configuration push data into the RIB and the RIB manager installs state into the hardware; for packet forwarding. This draft specifies an information model for the RIB to enable defining a standardized data model. Such a data model can be used to define an interface to the RIB from an entity that may even be external to the network device. This interface can be used to support new use-cases being defined by the IETF I2RS WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-info-model-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 27 11:44: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 E84A61A0682 for ; Tue, 27 May 2014 11:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 6TVSVp8knrDA for ; Tue, 27 May 2014 11:44:48 -0700 (PDT) Received: from nm25-vm2.bullet.mail.gq1.yahoo.com (nm25-vm2.bullet.mail.gq1.yahoo.com [98.136.217.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B6A1A05E5 for ; Tue, 27 May 2014 11:44:48 -0700 (PDT) Received: from [216.39.60.183] by nm25.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2014 18:44:45 -0000 Received: from [98.136.164.78] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2014 18:44:44 -0000 Received: from [127.0.0.1] by smtp240.mail.gq1.yahoo.com with NNFMP; 27 May 2014 18:44:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401216284; bh=Yif21u4ihl7da89PSML5EelNs/PX1QHBoa4u68t77rQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=ICYIDRXTkzxchKVJgunEAQ2d8dSXGvAxZ5AunP9lXc2sQ75ArHjYUQa0bZq3RdAFidfj2HNdOAZotfCNMCvoujqq3fcd0a4Fgc0AchvSU/dEWEt8aR1s48Y2Zgk7gZJT/jU5KrwtiwnwlFNxIZn86ASNk1BpV9OqQcPpRGomRT0= X-Yahoo-Newman-Id: 451936.52054.bm@smtp240.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kkkw5A8VM1l.y8NetkgEA_YhT_e_GTnloV4LQ8QQIu.Iwki ccUaYNf_asl70StXnvSBPcy3h8B9L97kMGA6U4QOz95HQnWoqL5sw20bpHjX NPI8WGeaysTqeQrokbtY93pxbR.5LsCC_dUB3sv13LsPZOHc_F0FvJueFrVq 37a9iPJjwIL5bmpYVq__QxJKJjaPS27KGSTR8sqtT2ckXSz5MUbOOgcPLdE4 7QRCglGwMIWUlb6vKrxi83qNeIBJlhlorJ.cnRZv3nB1DP6cAskYZgkWZP3u LmLVxJayv0URfAAqD35PCx3odMxKwrfVCWQpzAS29uE2sqYiJEenCfMTOS7b w1r.ISScAhbPkB7VaoLqo8XsfgvTVdTY2FbckSfEZzE_S0YDyi_.g8UEoHDt XP9x0N8vZE2zP_H4F8Nq_SRJ7FxZdDB4Bp3h2jv5BvEAh4zveH9MmdawBXmZ 6Z3NGTphzX5zLmJo_hxrFqSwWJmuQok7tHI6LAVvrqou4h2o685dt97VsydK CYHwqlQi267KYVxj43XbFaVSiXOpIQHrDNQ-- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [63.250.193.228]) by smtp240.mail.gq1.yahoo.com with SMTP; 27 May 2014 18:44:44 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Tue, 27 May 2014 11:44:40 -0700 From: Nitin Bahadur To: "i2rs@ietf.org" Message-ID: Thread-Topic: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt In-Reply-To: <20140527183808.6487.38156.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0tu6My2RUcK4r2KWZ7hF0mHNAsE Subject: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt 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: Tue, 27 May 2014 18:44:50 -0000 Updated the RIB grammar based on comments and suggestions received on this list, most notably from Sue Harris. Thanks Nitin -----Original Message----- From: Date: Tuesday, May 27, 2014 at 11:38 AM To: Nitin Bahadur , Ron Folkes , Nitin Bahadur , Sriganesh Kini , Jan Medved , Ron Folkes , Sriganesh Kini , Jan Medved Subject: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt > >A new version of I-D, draft-ietf-i2rs-rib-info-model-03.txt >has been successfully submitted by Nitin Bahadur and posted to the >IETF repository. > >Name: draft-ietf-i2rs-rib-info-model >Revision: 03 >Title: Routing Information Base Info Model >Document date: 2014-05-27 >Group: i2rs >Pages: 24 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-i2rs-rib-info-model-03.txt >Status: >https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ >Htmlized: >http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-03 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-info-model-03 > >Abstract: > Routing and routing functions in enterprise and carrier networks are > typically performed by network devices (routers and switches) using a > routing information base (RIB). Protocols and configuration push > data into the RIB and the RIB manager installs state into the > hardware; for packet forwarding. This draft specifies an information > model for the RIB to enable defining a standardized data model. Such > a data model can be used to define an interface to the RIB from an > entity that may even be external to the network device. This > interface can be used to support new use-cases being defined by the > IETF I2RS WG. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > From nobody Tue May 27 14:42:46 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 488631A0788 for ; Tue, 27 May 2014 14:42:35 -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 m-ZPFdg0Nn5T for ; Tue, 27 May 2014 14:42:33 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CD11A0301 for ; Tue, 27 May 2014 14:42:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 8CDE04A16A0; Tue, 27 May 2014 14:42:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id EBBC04A169F; Tue, 27 May 2014 14:42:29 -0700 (PDT) Message-ID: <538506C5.3050604@joelhalpern.com> Date: Tue, 27 May 2014 17:42: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.5.0 MIME-Version: 1.0 To: "i2rs@ietf.org" , draft-ietf-i2rs-rib-info-model@tools.ietf.org References: <20140527183808.6487.38364.idtracker@ietfa.amsl.com> In-Reply-To: <20140527183808.6487.38364.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pmDXnoMMjcEZS2_ZPF5R6nwXVsQ Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-03.txt 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: Tue, 27 May 2014 21:42:35 -0000 Thank you for producing a revision. Can we please get rid of the RBNF completely? Yours, Joel On 5/27/14, 2:38 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interface to the Routing System Working Group of the IETF. > > Title : Routing Information Base Info Model > Authors : Nitin Bahadur > Ron Folkes > Sriganesh Kini > Jan Medved > Filename : draft-ietf-i2rs-rib-info-model-03.txt > Pages : 24 > Date : 2014-05-27 From nobody Wed May 28 14:43: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 C10391A06B7 for ; Wed, 28 May 2014 14:43:10 -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 UbOUdJ7cjAux for ; Wed, 28 May 2014 14:43:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9C51A0428 for ; Wed, 28 May 2014 14:43:08 -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.944.11; Wed, 28 May 2014 21:43:03 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.184]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.213]) with mapi id 15.00.0944.000; Wed, 28 May 2014 21:43:03 +0000 From: Dean Bogdanovic To: Edward Crabbe Thread-Topic: [i2rs] working group last call: draft-atlas-i2rs-problem-statement Thread-Index: AQHPcUw2Rcs8L/TIcE+cGyAJd31FMZtWmP+A Date: Wed, 28 May 2014 21:43:02 +0000 Message-ID: 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-originating-ip: [66.129.241.16] x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(199002)(189002)(24454002)(377454003)(53754006)(479174003)(76482001)(82746002)(88136002)(83716003)(2656002)(33656002)(4396001)(76176999)(16236675002)(36756003)(89996001)(50226001)(93916002)(15975445006)(104166001)(77982001)(46102001)(99396002)(86362001)(77156001)(87936001)(80022001)(62966002)(83072002)(74502001)(85852003)(92726001)(81542001)(57306001)(74662001)(20776003)(19580405001)(50986999)(64706001)(99286001)(66066001)(92566001)(31966008)(15202345003)(79102001)(81342001)(19580395003)(87286001)(21056001)(101416001)(83322001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: multipart/alternative; boundary="_000_B1CFB7D065F6440C830181C1A6F611AFjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hMuUYOKv1ht-Qo4cK6TGBO-Ai2E Cc: "i2rs@ietf.org" Subject: Re: [i2rs] working group last call: draft-atlas-i2rs-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: Wed, 28 May 2014 21:43:10 -0000 --_000_B1CFB7D065F6440C830181C1A6F611AFjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I sent comments to the 01 version, but didn't see any of them answered in t= his draft. Alia responded that some of the comments were applied to the tex= t, but I don't see them in 02 text Dean On May 16, 2014, at 5:15 PM, Edward Crabbe > wrote: Hello all; Jeff and I would like to start the two week working group last call for dra= ft-atlas-i2rs-problem-statement. The document may be found here: http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02 The editors and authors are advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call will end on Friday, 5/30/14 best, -ed _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_B1CFB7D065F6440C830181C1A6F611AFjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <985F32D3F7A0AD4298C6EBD19EB1B3D8@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

I sent comments to the 01 version, but didn't see any of them answered= in this draft. Alia responded that some of the comments were applied to th= e text, but I don't see them in 02 text

Dean

On May 16, 2014, at 5:15 PM, Edward Crabbe <edc@google.com> wrote:

Hello all;

Jeff and I would like to start the two week working group last call for dra= ft-atlas-i2rs-problem-statement.  The document may be found here:

http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02

The editors and authors are advised to try to resolve as many of the
comments as possible (on the mailing list) as they come in, but not to
post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call will end on Friday, 5/30/14

best,
   -ed  
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--_000_B1CFB7D065F6440C830181C1A6F611AFjunipernet_-- From nobody Wed May 28 14:48: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 C77C41A052E for ; Wed, 28 May 2014 14:48:11 -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 O6dvULGpa27n for ; Wed, 28 May 2014 14:48:09 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5841A0261 for ; Wed, 28 May 2014 14:48:09 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id z6so9332523yhz.25 for ; Wed, 28 May 2014 14:48:05 -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=jkuO6SDOc+Uab+XtjjVRFgY7/uPPeVw06menJqssbyQ=; b=GpVxWiLWIWWgpVfYMGtIBpyY6Q6DVPxUHsAHMlkGwkuIoHm65hQjcLSv3SsgctIpAD osHWkCrdp3+a6s0RbFiOoioWM0sCSeOyW3NP+MUrzhHT1KnG4/71imL1u08p8Qn8sLm0 2DFzbcZ7uqmwR2HPKK3HE7UaO2prWr4kQkJLBnmQqNbBhWYJCbpN4paakG6EaG3QFBXY lQkUoktVsnQDms51FQxH0pfzECVdY26vF15KywK5xOjPi/SnpsGqYp1L+7gcJB3YOb9Q xa2dUlAvuvQAf8a8n3yYpmXAmk4MksgoDWEx4d5m2dksViqN+l5oZMXE20pHGEp8Onls TpLg== MIME-Version: 1.0 X-Received: by 10.236.150.205 with SMTP id z53mr3136705yhj.75.1401313685765; Wed, 28 May 2014 14:48:05 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Wed, 28 May 2014 14:48:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 May 2014 17:48:05 -0400 Message-ID: From: Alia Atlas To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=20cf303a2d61759f1804fa7cc4e0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wSOj1kEDOqsNRO7mMILZtHAFzM4 Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] working group last call: draft-atlas-i2rs-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: Wed, 28 May 2014 21:48:11 -0000 --20cf303a2d61759f1804fa7cc4e0 Content-Type: text/plain; charset=UTF-8 Dean, I have them in an updated version ready to go - but I was waiting to address all comments from WGLC in one go... Alia On Wed, May 28, 2014 at 5:43 PM, Dean Bogdanovic wrote: > Hi, > > I sent comments to the 01 version, but didn't see any of them answered > in this draft. Alia responded that some of the comments were applied to the > text, but I don't see them in 02 text > > Dean > > On May 16, 2014, at 5:15 PM, Edward Crabbe wrote: > > Hello all; > > Jeff and I would like to start the two week working group last call for > draft-atlas-i2rs-problem-statement. The document may be found here: > > http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02 > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call will end on Friday, 5/30/14 > > best, > -ed > _______________________________________________ > 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 > > --20cf303a2d61759f1804fa7cc4e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dean,

I have them in an updated version= ready to go - but I was waiting to address all comments
from WGL= C in one go...

Alia


On Wed, May 28, 2014 at 5:43 PM, Dean Bo= gdanovic <deanb@juniper.net> wrote:
Hi,

I sent comments to the 01 version, but didn't see any of them answ= ered in this draft. Alia responded that some of the comments were applied t= o the text, but I don't see them in 02 text

Dean

On May 16, 2014, at 5:15 PM, Edward Crabbe <edc@google.com> wrote:

Hello all;

Jeff and I would like to start the two week working group last call for dra= ft-atlas-i2rs-problem-statement. =C2=A0The document may be found here:

http://tools.ietf.org/html/draft-atlas-i2rs-problem-sta= tement-02

The editors and authors are advised to try to resolve as many of the
comments as possible (on the mailing list) as they come in, but not to
post the new version of the draft until the wglc is closed and the
comments are resolved.

This working group last call will end on Friday, 5/30/14

best,
=C2=A0 =C2=A0-ed =C2=A0
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


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


--20cf303a2d61759f1804fa7cc4e0-- From nobody Thu May 29 15:27: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 DDD6D1A052E for ; Thu, 29 May 2014 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 w_7HtzxgkWL2 for ; Thu, 29 May 2014 15:27:32 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA931A0293 for ; Thu, 29 May 2014 15:27:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: "'Nitin Bahadur'" , References: <20140527183808.6487.38156.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 29 May 2014 18:27:25 -0400 Message-ID: <002d01cf7b8d$2b4808a0$81d819e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoJmjNsSHYZ3f6jzd5isOG840JoZomzU+w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/yLyyU6CMH2cVVWgLwwCm6Fvy7Ew Subject: Re: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt 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, 29 May 2014 22:27:34 -0000 Nitin: It is Sue Hares (shares@ndzh.com) ... like the rabbit. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Tuesday, May 27, 2014 2:45 PM To: i2rs@ietf.org Subject: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt Updated the RIB grammar based on comments and suggestions received on this list, most notably from Sue Harris. Thanks Nitin -----Original Message----- From: Date: Tuesday, May 27, 2014 at 11:38 AM To: Nitin Bahadur , Ron Folkes , Nitin Bahadur , Sriganesh Kini , Jan Medved , Ron Folkes , Sriganesh Kini , Jan Medved Subject: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt > >A new version of I-D, draft-ietf-i2rs-rib-info-model-03.txt >has been successfully submitted by Nitin Bahadur and posted to the IETF >repository. > >Name: draft-ietf-i2rs-rib-info-model >Revision: 03 >Title: Routing Information Base Info Model >Document date: 2014-05-27 >Group: i2rs >Pages: 24 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-i2rs-rib-info-model-03.txt >Status: >https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ >Htmlized: >http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-03 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-rib-info-model-03 > >Abstract: > Routing and routing functions in enterprise and carrier networks are > typically performed by network devices (routers and switches) using a > routing information base (RIB). Protocols and configuration push > data into the RIB and the RIB manager installs state into the > hardware; for packet forwarding. This draft specifies an information > model for the RIB to enable defining a standardized data model. Such > a data model can be used to define an interface to the RIB from an > entity that may even be external to the network device. This > interface can be used to support new use-cases being defined by the > IETF I2RS WG. > > > > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu May 29 15:40: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 670801A0B71 for ; Thu, 29 May 2014 15:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 2_uJy3kUjk1a for ; Thu, 29 May 2014 15:40:52 -0700 (PDT) Received: from nm20-vm6.bullet.mail.gq1.yahoo.com (nm20-vm6.bullet.mail.gq1.yahoo.com [98.136.217.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DBE1A0274 for ; Thu, 29 May 2014 15:40:52 -0700 (PDT) Received: from [98.137.12.190] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 29 May 2014 22:40:48 -0000 Received: from [208.71.42.191] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 29 May 2014 22:40:48 -0000 Received: from [127.0.0.1] by smtp202.mail.gq1.yahoo.com with NNFMP; 29 May 2014 22:40:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401403248; bh=Aic3pfX3mrEc2HBvkCHdefrzQfMuYwOAfcXTyH3qZBw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=SqFbcmTXf8TUBBlq6tqOKz9+8YJQUgDlhw6enepEfSa+c6/ieAg3UN9/DEnNC8RyRdZouyltm62ReSm6nLtCEc9yr2MXudSmhWYT3CWyvoZiQBN0uYFKqI17pHDQAjb2VQS6sNhi5Rd2ULMYOncD8KgSed03bGjj6ANVicTg7ws= X-Yahoo-Newman-Id: 509710.27651.bm@smtp202.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tYvWRfYVM1lZgkiAbwjH40lraIvxt6AHyF8b0AvtWt4qIMj AqIDWyOWnzdFrWQ3h4SROgo2n8N2.VWF9kX2w6S1alBFo79xne5GdMJwKeYS gU4JvjMp2MSHWYHvvfrmTpITmRDmcBi5O32mUivNTeUXt4TUGry.E_vPVpf_ 9Ej7J18Z6kWzoHGuyX7DeMJmGPll.B5OSGAZNOfW1dng1rHZWbRSr3ky1vqv heGOqy3wXpl4XKw5hWeur5yxc8eFJScQWOTUzX4ABgrgYUH7erpq6lcGOYo6 Jc53NmpaVc5NrrqdFDxvoE0bKy3iUISlYj_0.gtO0_.qB_M7T2qcZP1779sC oKseHs5tnMhrdl4CxGC3QNZ.PHBVj44LWNCSKymlaPm8_ODMq0Ipy6OZAKmF 3HiAU16ApW_HHgNIdIgSh9M4kwafnO2zXwouMQIn.42pOuF.lyL7NrkTKkuM yLihDt4AMwgoiDC3zjQI44Z81wkP3HPQO9auJeUsnznac.R3ejTWZcUadYkw 5c1EFHcxNygaXcKXS1ozx76xxeB_Zjtvl X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from [10.9.1.135] (nitin_bahadur@69.12.170.18 with plain [63.250.193.228]) by smtp202.mail.gq1.yahoo.com with SMTP; 29 May 2014 15:40:48 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.8.130913 Date: Thu, 29 May 2014 15:40:40 -0700 From: Nitin Bahadur To: Susan Hares , Message-ID: Thread-Topic: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt In-Reply-To: <002d01cf7b8d$2b4808a0$81d819e0$@ndzh.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Md4BHlUrN-ZKzgyoKG2SMkNBI3k Subject: Re: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt 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, 29 May 2014 22:40:54 -0000 Hi Sue, Sincere apologies. I=B9m not sure what I was smoking when I wrote the email. Of course I know the right name=8Agrrr... -----Original Message----- From: Susan Hares Date: Thursday, May 29, 2014 at 3:27 PM To: Nitin Bahadur , Subject: Re: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt >Nitin: > >It is Sue Hares (shares@ndzh.com) ... like the rabbit. > >Sue=20 > >-----Original Message----- >From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur >Sent: Tuesday, May 27, 2014 2:45 PM >To: i2rs@ietf.org >Subject: [i2rs] FW: New Version Notification for >draft-ietf-i2rs-rib-info-model-03.txt > > >Updated the RIB grammar based on comments and suggestions received on this >list, most notably from Sue Harris. > >Thanks >Nitin > >-----Original Message----- >From: >Date: Tuesday, May 27, 2014 at 11:38 AM >To: Nitin Bahadur , Ron Folkes >, >Nitin Bahadur , Sriganesh Kini >, Jan Medved , Ron Folkes >, Sriganesh Kini , Jan >Medved > >Subject: New Version Notification for >draft-ietf-i2rs-rib-info-model-03.txt > >> >>A new version of I-D, draft-ietf-i2rs-rib-info-model-03.txt >>has been successfully submitted by Nitin Bahadur and posted to the IETF >>repository. >> >>Name: draft-ietf-i2rs-rib-info-model >>Revision: 03 >>Title: Routing Information Base Info Model >>Document date: 2014-05-27 >>Group: i2rs >>Pages: 24 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-ietf-i2rs-rib-info-model-03.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-03 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-info-model-03 >> >>Abstract: >> Routing and routing functions in enterprise and carrier networks are >> typically performed by network devices (routers and switches) using a >> routing information base (RIB). Protocols and configuration push >> data into the RIB and the RIB manager installs state into the >> hardware; for packet forwarding. This draft specifies an information >> model for the RIB to enable defining a standardized data model. Such >> a data model can be used to define an interface to the RIB from an >> entity that may even be external to the network device. This >> interface can be used to support new use-cases being defined by the >> IETF I2RS WG. >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> >> > > > >_______________________________________________ >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 Thu May 29 16:08: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 F34411A06DF for ; Thu, 29 May 2014 16:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 kYvRso50EPNu for ; Thu, 29 May 2014 16:08:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D43401A06DD for ; Thu, 29 May 2014 16:08:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: "'Nitin Bahadur'" , References: <002d01cf7b8d$2b4808a0$81d819e0$@ndzh.com> In-Reply-To: Date: Thu, 29 May 2014 19:07:59 -0400 Message-ID: <004e01cf7b92$d6325c20$82971460$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3iI7oCnrGScxaRiQn+bIqHgM2/JwIFC7A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PWSEdXSZioNgvuAR3fJaI94c8Io Subject: Re: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt 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, 29 May 2014 23:08:08 -0000 Nitin:=20 No problem... I just wanted to knew to send the complaints my way. = Thanks for sending the update. I'll be posting on the draft shortly.=20 Sue=20 -----Original Message----- From: Nitin Bahadur [mailto:nitin_bahadur@yahoo.com]=20 Sent: Thursday, May 29, 2014 6:41 PM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt Hi Sue, Sincere apologies. I=B9m not sure what I was smoking when I wrote the = email. Of course I know the right name=D0grrr... -----Original Message----- From: Susan Hares Date: Thursday, May 29, 2014 at 3:27 PM To: Nitin Bahadur , Subject: Re: [i2rs] FW: New Version Notification for draft-ietf-i2rs-rib-info-model-03.txt >Nitin: > >It is Sue Hares (shares@ndzh.com) ... like the rabbit. > >Sue > >-----Original Message----- >From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur >Sent: Tuesday, May 27, 2014 2:45 PM >To: i2rs@ietf.org >Subject: [i2rs] FW: New Version Notification for=20 >draft-ietf-i2rs-rib-info-model-03.txt > > >Updated the RIB grammar based on comments and suggestions received on=20 >this list, most notably from Sue Harris. > >Thanks >Nitin > >-----Original Message----- >From: >Date: Tuesday, May 27, 2014 at 11:38 AM >To: Nitin Bahadur , Ron Folkes=20 >, Nitin Bahadur , Sriganesh=20 >Kini , Jan Medved , Ron=20 >Folkes , Sriganesh Kini=20 >, Jan Medved >Subject: New Version Notification for >draft-ietf-i2rs-rib-info-model-03.txt > >> >>A new version of I-D, draft-ietf-i2rs-rib-info-model-03.txt >>has been successfully submitted by Nitin Bahadur and posted to the=20 >>IETF repository. >> >>Name: draft-ietf-i2rs-rib-info-model >>Revision: 03 >>Title: Routing Information Base Info Model >>Document date: 2014-05-27 >>Group: i2rs >>Pages: 24 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-ietf-i2rs-rib-info-model-03.t= xt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-03 >>Diff: =20 >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-info-model-03 >> >>Abstract: >> Routing and routing functions in enterprise and carrier networks = are >> typically performed by network devices (routers and switches) using = a >> routing information base (RIB). Protocols and configuration push >> data into the RIB and the RIB manager installs state into the >> hardware; for packet forwarding. This draft specifies an = information >> model for the RIB to enable defining a standardized data model. = Such >> a data model can be used to define an interface to the RIB from an >> entity that may even be external to the network device. This >> interface can be used to support new use-cases being defined by the >> IETF I2RS WG. >> >> =20 >> =20 >> >> >>Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >>The IETF Secretariat >> >> > > > >_______________________________________________ >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 >