From nobody Mon Sep 1 09: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 764AE1A0319; Mon, 1 Sep 2014 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 spf7EMpIliHF; Mon, 1 Sep 2014 09:23:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2521A02DF; Mon, 1 Sep 2014 09:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1619; q=dns/txt; s=iport; t=1409588612; x=1410798212; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=HJodYw8JdwC68ueLFgpTnoCc2mkp/K5U8Wj6z1+sT8c=; b=TXV6ERGEqGDkL2jI9Qpj6SzK+Z0jxHvEHOXHP0k+wRZY4qrMob+UMqRv kj4kzQKIeUJjBauZZ3Z8iof8Cs2z96NRjKkdze6IASRngF2DphPAkwWbl f2s2cSG2lDiVm8AZXFcUc3wQaQttKD6ZLZuKt6eHcHOu+onTGZBzBepm4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAMacBFStJssW/2dsb2JhbABZ1AkBgSt3hAMBAQEDATIBBUAGCwsYCRYPCQMCAQIBRQYBDAgBARaIIAi5cAEXjnlbhEwBBJxchzeNZ4NjO4J+AQEB X-IronPort-AV: E=Sophos;i="5.04,443,1406592000"; d="scan'208";a="157278220" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Sep 2014 16:23:28 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s81GNRuE023083; Mon, 1 Sep 2014 16:23:27 GMT Message-ID: <54049D7F.1010307@cisco.com> Date: Mon, 01 Sep 2014 18:23:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , i2rs@ietf.org, netmod@ietf.org References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> In-Reply-To: <20140901050331.GA70583@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E8sDfhMKpD46zpc3Uv_rh9wib54 Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Mon, 01 Sep 2014 16:23:33 -0000 Joel, On top of what Jürgen wrote, we stressed the need for such a requirement document to both I2RS chairs during the last IETF meeting. The good news is that some of the requirements were mentioned on the microphone during the Sunday YANG editing session and/or the NETMOD meeting (my memory fails me). Regards, Benoit > On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: >> Juergen, >> While I understand the request, I presume that such a request can >> not be met as a working group agreement in the time frame suggested. >> WHile I hope that some of the folks who have been involved in proposing >> the use of YANG for I2RS will write such a draft, I can not see how we >> could even get tot eh point of WG adoption of such a draft, much less WG >> rough consensus on the content, in the time frame you outline. >> Of course, I am not one of the chairs or ADs, but it seems pretty >> clear cut to me. > Joel, > > all I need is reasonably agreed upon input. Note that this request for > input is not coming out of the blue, at least not for those I2RS folks > who have been at the NETMOD meeting in Toronto. > > As NETMOD chair, I do have a target date to deliver YANG 1.1 and I > take that milestone serious. My motivation to delay this by N months > waiting for I2RS to get their input submitted is very small. I recall > that there were presentations about "what is missing" bach in London, > that is March 2014. The regular submission period for YANG 1.1 issues > was 2014-02-23 until 2014-05-07. The interim meeting is mid September. > > /js > From nobody Mon Sep 1 10:17: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 406571A04B9 for ; Mon, 1 Sep 2014 10:17:25 -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 aHRgvajeuyyl for ; Mon, 1 Sep 2014 10:17:15 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA931A03DE for ; Mon, 1 Sep 2014 10:17:15 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l6so5761017qcy.10 for ; Mon, 01 Sep 2014 10:17:14 -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=jJ/6Mfa+/YfPIrHqJuCG/KgY35aqrj9hGXQPcuW0xPY=; b=YohA2VS4T5KgfCZjqpYRhJ5PDfqZF+jaV60JSguB21LrrSdegFBW2WqXfRwzuipdFD 2Jygb98E1GfLk7h4SVDeuTEpXohKHYz+YABVpJATZzyJw4by51yD3bY07UPIJVQlupo6 PF4hciu4RQdmd/h4IAoH4ybV905bZkfEGz7A9KDwC33YFXmm/P99+6QY0SWaVawa6O1w mgpFphQliOB8/tTlSbnPG32ch3p/JEiPnLQEGCK/YbBzkAXGSIahQBLC1twUNbTU9PZh 6i3xGaUognJH0f7ebiPZSKOHSKuMQC/Z6fUJJk3i/FA4lz2UrM9eZLDJfxAccNHtkjx9 91HA== X-Gm-Message-State: ALoCoQnAoIANCvHduxAxcxSXa0WRF1EBW73ZM7FXnWxEJ8Z9WVA2et+dTSYbuXnxxmTpnVoKgGLu MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr47229635qcl.14.1409591834381; Mon, 01 Sep 2014 10:17:14 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 1 Sep 2014 10:17:14 -0700 (PDT) In-Reply-To: <54049D7F.1010307@cisco.com> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> Date: Mon, 1 Sep 2014 10:17:14 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1134525691270b0502042cb9 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/h_9XWSmsWeSurlxQU_fsZ005EKQ Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Mon, 01 Sep 2014 17:17:26 -0000 --001a1134525691270b0502042cb9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise wrote: > Joel, > > On top of what J=FCrgen wrote, we stressed the need for such a requiremen= t > document to both I2RS chairs during the last IETF meeting. > The good news is that some of the requirements were mentioned on the > microphone during the Sunday YANG editing session and/or the NETMOD meeti= ng > (my memory fails me). > > Regards, Benoit > > On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: >> >>> Juergen, >>> While I understand the request, I presume that such a request can >>> not be met as a working group agreement in the time frame suggested. >>> WHile I hope that some of the folks who have been involved in proposing >>> the use of YANG for I2RS will write such a draft, I can not see how we >>> could even get tot eh point of WG adoption of such a draft, much less W= G >>> rough consensus on the content, in the time frame you outline. >>> Of course, I am not one of the chairs or ADs, but it seems pretty >>> clear cut to me. >>> >> I agree with Joel that the I2RS does not have consensus on the details. The slides I presented in London and subsequent discussions suggest this solution: 1) define YANG extension to identify I2RS data so typedefs, etc. can be shared in config and state data models 2) define an I2RS datastore 3) define or extend a protocol to manage the I2RS datastore Let's say there is a new datastore added to the RESTCONF architecture for I2RS. Explain how this datastore works. It seems to have the same validation rules as YANG running config rules. The only difference seems to be that the I2RS datastore is not NV-saved (or NV-loaded at boot-time) like the running datastore. YANG 1.1 has some cleanup work planned to make the text less NETCONF-specific. I don't think there is much datastore and NV-store specific text that would need to change. Andy Joel, >> >> all I need is reasonably agreed upon input. Note that this request for >> input is not coming out of the blue, at least not for those I2RS folks >> who have been at the NETMOD meeting in Toronto. >> >> As NETMOD chair, I do have a target date to deliver YANG 1.1 and I >> take that milestone serious. My motivation to delay this by N months >> waiting for I2RS to get their input submitted is very small. I recall >> that there were presentations about "what is missing" bach in London, >> that is March 2014. The regular submission period for YANG 1.1 issues >> was 2014-02-23 until 2014-05-07. The interim meeting is mid September. >> >> /js >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134525691270b0502042cb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise <= ;bclaise@cisco.com> wrote:
Joel,

On top of what J=FCrgen wrote, we stressed the need for such a requirement = document to both I2RS chairs during the last IETF meeting.
The good news is that some of the requirements were mentioned on the microp= hone during the Sunday YANG editing session and/or the NETMOD meeting (my m= emory fails me).

Regards, Benoit

On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote:
Juergen,
=A0 =A0 =A0While I understand the request, I presume that such a request ca= n
not be met as a working group agreement in the time frame suggested.
WHile I hope that some of the folks who have been involved in proposing
the use of YANG for I2RS will write such a draft, I can not see how we
could even get tot eh point of WG adoption of such a draft, much less WG rough consensus on the content, in the time frame you outline.
=A0 =A0 =A0Of course, I am not one of the chairs or ADs, but it seems prett= y
clear cut to me.

<= div>I agree with Joel that the I2RS does not have consensus on the details.=

=A0 =A01) define YANG extension to identify I2RS data s= o typedefs, etc. can be shared
=A0 =A0 =A0 =A0in config and state= data models
=A0 =A02) define an I2RS datastore
=A0 =A0= 3) define or extend a protocol to manage the I2RS datastore

Let's say there is a new datastore added to the RES= TCONF architecture for I2RS.
Explain how this datastore works. = =A0It seems to have the same validation rules
as YANG running con= fig rules. =A0The only difference seems to be that the I2RS datastore
is not NV-saved (or NV-loaded at boot-time) like the running datastore= .

YANG 1.1 has some cleanup work planned to make t= he text less NETCONF-specific.
I don't think there is much da= tastore and NV-store specific text that would need to change.


Andy


=


Joel,

all I need is reasonably agreed upon input. Note that this request for
input is not coming out of the blue, at least not for those I2RS folks
who have been at the NETMOD meeting in Toronto.

As NETMOD chair, I do have a target date to deliver YANG 1.1 and I
take that milestone serious. My motivation to delay this by N months
waiting for I2RS to get their input submitted is very small. I recall
that there were presentations about "what is missing" bach in Lon= don,
that is March 2014. The regular submission period for YANG 1.1 issues
was 2014-02-23 until 2014-05-07. The interim meeting is mid September.

/js


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

--001a1134525691270b0502042cb9-- From nobody Tue Sep 2 10:50: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 442A91A0B0E for ; Tue, 2 Sep 2014 10:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 ewD6Uu5RGpbT for ; Tue, 2 Sep 2014 10:50:29 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BF11A0A92 for ; Tue, 2 Sep 2014 10:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11387; q=dns/txt; s=iport; t=1409680229; x=1410889829; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=dQTsYBd7xNG01qf/ZaJGPbvbIBfjFyuoiDtttWkPnl0=; b=B3BtVfZHiuE9+r8w74cK+rqNka0mtYFXv625OhLI1yuth5XZ32/piCPz ohgpsnsmXsBfDKb8upj3bL1+hZy5Lh19lC1SeMBb6BhsOeDGztAidBjAJ df8I/76rWkVUP6VK0Scm6nAFnGaTvQqVaiYML09bTbsaCFqp4R+puWgjm g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4HAF8CBlStJA2M/2dsb2JhbABQCoMNU1cEiFO/RQEJhnlTAYETFneEBAEBBAEBAWsKEQsSBgkWCAcJAwIBAgEVHwMOBg0GAgEBFgGIJw28DgETBI5xCFuETAWLLJEwhzeNZ4QBTIEIJByBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,450,1406592000"; d="scan'208,217"; a="74301496" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP; 02 Sep 2014 17:50:28 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s82HoSPb010422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Sep 2014 17:50:28 GMT Received: from [10.21.68.27] (10.21.68.27) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Sep 2014 12:50:27 -0500 Message-ID: <54060362.8040004@cisco.com> Date: Tue, 2 Sep 2014 10:50:26 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040600050103000509040803" X-Originating-IP: [10.21.68.27] Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/o3ggIp26FxtQderFu0Q7M5HBGpM Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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, 02 Sep 2014 17:50:31 -0000 --------------040600050103000509040803 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hi, are we taking this approach only for I2RS or this will be our preferred solution from now on? Meaning, every time when a new protocol/WG has certain valid requirements we will create a new datastore for them? thanks, On 9/1/14 10:17 AM, Andy Bierman wrote: > > > > On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise > wrote: > > Joel, > > On top of what Jürgen wrote, we stressed the need for such a > requirement document to both I2RS chairs during the last IETF meeting. > The good news is that some of the requirements were mentioned on > the microphone during the Sunday YANG editing session and/or the > NETMOD meeting (my memory fails me). > > Regards, Benoit > > On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: > > Juergen, > While I understand the request, I presume that such a > request can > not be met as a working group agreement in the time frame > suggested. > WHile I hope that some of the folks who have been involved > in proposing > the use of YANG for I2RS will write such a draft, I can > not see how we > could even get tot eh point of WG adoption of such a > draft, much less WG > rough consensus on the content, in the time frame you outline. > Of course, I am not one of the chairs or ADs, but it > seems pretty > clear cut to me. > > > I agree with Joel that the I2RS does not have consensus on the details. > The slides I presented in London and subsequent discussions suggest > this solution: > > 1) define YANG extension to identify I2RS data so typedefs, etc. > can be shared > in config and state data models > 2) define an I2RS datastore > 3) define or extend a protocol to manage the I2RS datastore > > Let's say there is a new datastore added to the RESTCONF architecture > for I2RS. > Explain how this datastore works. It seems to have the same > validation rules > as YANG running config rules. The only difference seems to be that > the I2RS datastore > is not NV-saved (or NV-loaded at boot-time) like the running datastore. > > YANG 1.1 has some cleanup work planned to make the text less > NETCONF-specific. > I don't think there is much datastore and NV-store specific text that > would need to change. > > > Andy > > > > > Joel, > > all I need is reasonably agreed upon input. Note that this > request for > input is not coming out of the blue, at least not for those > I2RS folks > who have been at the NETMOD meeting in Toronto. > > As NETMOD chair, I do have a target date to deliver YANG 1.1 and I > take that milestone serious. My motivation to delay this by N > months > waiting for I2RS to get their input submitted is very small. I > recall > that there were presentations about "what is missing" bach in > London, > that is March 2014. The regular submission period for YANG 1.1 > issues > was 2014-02-23 until 2014-05-07. The interim meeting is mid > September. > > /js > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --------------040600050103000509040803 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hi,

are we taking this approach only for I2RS or this will be our preferred solution from now on?

Meaning, every time when a new protocol/WG has certain valid requirements we will create a new datastore for them?

thanks,



On 9/1/14 10:17 AM, Andy Bierman wrote:



On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise <bclaise@cisco.com> wrote:
Joel,

On top of what Jürgen wrote, we stressed the need for such a requirement document to both I2RS chairs during the last IETF meeting.
The good news is that some of the requirements were mentioned on the microphone during the Sunday YANG editing session and/or the NETMOD meeting (my memory fails me).

Regards, Benoit

On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote:
Juergen,
     While I understand the request, I presume that such a request can
not be met as a working group agreement in the time frame suggested.
WHile I hope that some of the folks who have been involved in proposing
the use of YANG for I2RS will write such a draft, I can not see how we
could even get tot eh point of WG adoption of such a draft, much less WG
rough consensus on the content, in the time frame you outline.
     Of course, I am not one of the chairs or ADs, but it seems pretty
clear cut to me.

I agree with Joel that the I2RS does not have consensus on the details.
The slides I presented in London and subsequent discussions suggest this solution:

   1) define YANG extension to identify I2RS data so typedefs, etc. can be shared
       in config and state data models
   2) define an I2RS datastore
   3) define or extend a protocol to manage the I2RS datastore

Let's say there is a new datastore added to the RESTCONF architecture for I2RS.
Explain how this datastore works.  It seems to have the same validation rules
as YANG running config rules.  The only difference seems to be that the I2RS datastore
is not NV-saved (or NV-loaded at boot-time) like the running datastore.

YANG 1.1 has some cleanup work planned to make the text less NETCONF-specific.
I don't think there is much datastore and NV-store specific text that would need to change.


Andy




Joel,

all I need is reasonably agreed upon input. Note that this request for
input is not coming out of the blue, at least not for those I2RS folks
who have been at the NETMOD meeting in Toronto.

As NETMOD chair, I do have a target date to deliver YANG 1.1 and I
take that milestone serious. My motivation to delay this by N months
waiting for I2RS to get their input submitted is very small. I recall
that there were presentations about "what is missing" bach in London,
that is March 2014. The regular submission period for YANG 1.1 issues
was 2014-02-23 until 2014-05-07. The interim meeting is mid September.

/js


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



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

--------------040600050103000509040803-- From nobody Tue Sep 2 11:00: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 DD6821A2130 for ; Tue, 2 Sep 2014 11:00:09 -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 fP03stniiGiV for ; Tue, 2 Sep 2014 11:00:07 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A78E1A6EFA for ; Tue, 2 Sep 2014 11:00:07 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id cm18so6506433qab.23 for ; Tue, 02 Sep 2014 11:00:05 -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=tPSZsMZPUXLZgWxYiizrxtzho/MqJIdcHm0WGZDvTU8=; b=DnS+bV0qQplqyZfFAGbIMlJORQAdOlMACWCFh32IyvNtQtrhT9tBTaxsIYGI7/wAVX +E0GQCbB8vHKHG+d6UDw2Nut3XoZpqdv/kT/bauyrl/2RX8H+KFTeEu2+C9Uuhe52Ehr w2AHZI2YoMQNGWVNBy1lQy7CtvBogXSJnspd2sHUYo0TdcQlWHkQQWrwAd1GqTt8m8l1 kD4o1tythqV/v+ILAJQjXwstj96kTXHa9kUjwrDvVI117tXciybDGQxcYeGuOC9FuEu1 co1NLASIYpeVx/GHsVHRkgXoMIHn5SH32Px+kS+e9GzXbU9BofGzMNybfXRDBs15LDfg hnHQ== X-Gm-Message-State: ALoCoQmj1ylUTw5v6wHF7jnqa2L2Vhwdr4YGaWpMF8Maoquc5e7Z/71kXW82eNQucwWjdXq7PzwF MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr59450946qam.88.1409680805180; Tue, 02 Sep 2014 11:00:05 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 2 Sep 2014 11:00:05 -0700 (PDT) In-Reply-To: <54060362.8040004@cisco.com> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> <54060362.8040004@cisco.com> Date: Tue, 2 Sep 2014 11:00:05 -0700 Message-ID: From: Andy Bierman To: Reinaldo Penno Content-Type: multipart/alternative; boundary=001a11c2bbc0a3fb18050218e3b0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/BrI5B8ZzIg1axP9AlLd1hZzJS3g Cc: "i2rs@ietf.org" Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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, 02 Sep 2014 18:00:10 -0000 --001a11c2bbc0a3fb18050218e3b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno wrote: > Hi, > > are we taking this approach only for I2RS or this will be our preferred > solution from now on? > > Meaning, every time when a new protocol/WG has certain valid requirements > we will create a new datastore for them? > > Good question. It is a lot more work to add a new datastore than to tag data as ephemeral in the existing "running" datastore -- if the only difference is no non-volatile support. I think the I2RS WG has to agree on those details first. thanks, > > Andy > > > On 9/1/14 10:17 AM, Andy Bierman wrote: > > > > > On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise wrote: > >> Joel, >> >> On top of what J=FCrgen wrote, we stressed the need for such a requireme= nt >> document to both I2RS chairs during the last IETF meeting. >> The good news is that some of the requirements were mentioned on the >> microphone during the Sunday YANG editing session and/or the NETMOD meet= ing >> (my memory fails me). >> >> Regards, Benoit >> >> On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: >>> >>>> Juergen, >>>> While I understand the request, I presume that such a request can >>>> not be met as a working group agreement in the time frame suggested. >>>> WHile I hope that some of the folks who have been involved in proposin= g >>>> the use of YANG for I2RS will write such a draft, I can not see how we >>>> could even get tot eh point of WG adoption of such a draft, much less = WG >>>> rough consensus on the content, in the time frame you outline. >>>> Of course, I am not one of the chairs or ADs, but it seems pretty >>>> clear cut to me. >>>> >>> > I agree with Joel that the I2RS does not have consensus on the details. > The slides I presented in London and subsequent discussions suggest this > solution: > > 1) define YANG extension to identify I2RS data so typedefs, etc. can > be shared > in config and state data models > 2) define an I2RS datastore > 3) define or extend a protocol to manage the I2RS datastore > > Let's say there is a new datastore added to the RESTCONF architecture > for I2RS. > Explain how this datastore works. It seems to have the same validation > rules > as YANG running config rules. The only difference seems to be that the > I2RS datastore > is not NV-saved (or NV-loaded at boot-time) like the running datastore. > > YANG 1.1 has some cleanup work planned to make the text less > NETCONF-specific. > I don't think there is much datastore and NV-store specific text that > would need to change. > > > Andy > > > > > Joel, >>> >>> all I need is reasonably agreed upon input. Note that this request for >>> input is not coming out of the blue, at least not for those I2RS folks >>> who have been at the NETMOD meeting in Toronto. >>> >>> As NETMOD chair, I do have a target date to deliver YANG 1.1 and I >>> take that milestone serious. My motivation to delay this by N months >>> waiting for I2RS to get their input submitted is very small. I recall >>> that there were presentations about "what is missing" bach in London, >>> that is March 2014. The regular submission period for YANG 1.1 issues >>> was 2014-02-23 until 2014-05-07. The interim meeting is mid September. >>> >>> /js >>> >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > i2rs mailing listi2rs@ietf.orghttps://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c2bbc0a3fb18050218e3b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno &= lt;repenno@cisco.com= > wrote:
=20 =20 =20
Hi,

are we taking this approach only for I2RS or this will be our preferred solution from now on?

Meaning, every time when a new protocol/WG has certain valid requirements we will create a new datastore for them?


Good question.
It = is a lot more work to add a new datastore than to tag data as ephemeral
in the existing "running" datastore -- if the only differe= nce is no non-volatile support.
I think the I2RS WG has to agree on those details first.


thanks,


Andy
=A0


On 9/1/14 10:17 AM, Andy Bierman wrote:
=20



On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise <bclaise@cisco.com> wrote:
Joel,

On top of what J=FCrgen wrote, we stressed the need for such a requirement document to both I2RS chairs during the last IETF meeting.
The good news is that some of the requirements were mentioned on the microphone during the Sunday YANG editing session and/or the NETMOD meeting (my memory fails me).

Regards, Benoit

On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote:
Juergen,
=A0 =A0 =A0While I understand the request, I presume that such a request can
not be met as a working group agreement in the time frame suggested.
WHile I hope that some of the folks who have been involved in proposing
the use of YANG for I2RS will write such a draft, I can not see how we
could even get tot eh point of WG adoption of such a draft, much less WG
rough consensus on the content, in the time frame you outline.
=A0 =A0 =A0Of course, I am not one of the chairs or ADs, = but it seems pretty
clear cut to me.

I agree with Joel that the I2RS does not have consensus on the details.
The slides I presented in London and subsequent discussions suggest this solution:

=A0 =A01) define YANG extension to identify I2RS data so typedefs, etc. can be shared
=A0 =A0 =A0 =A0in config and state data models
=A0 =A02) define an I2RS datastore
=A0 =A03) define or extend a protocol to manage the I2RS datastore

Let's say there is a new datastore added to the RESTCONF architecture for I2RS.
Explain how this datastore works. =A0It seems to have the same validation rules
as YANG running config rules. =A0The only difference seems to be that the I2RS datastore
is not NV-saved (or NV-loaded at boot-time) like the running datastore.

YANG 1.1 has some cleanup work planned to make the text less NETCONF-specific.
I don't think there is much datastore and NV-store specific text that would need to change.


Andy




Joel,

all I need is reasonably agreed upon input. Note that this request for
input is not coming out of the blue, at least not for those I2RS folks
who have been at the NETMOD meeting in Toronto.

As NETMOD chair, I do have a target date to deliver YANG 1.1 and I
take that milestone serious. My motivation to delay this by N months
waiting for I2RS to get their input submitted is very small. I recall
that there were presentations about "what is missing&q= uot; bach in London,
that is March 2014. The regular submission period for YANG 1.1 issues
was 2014-02-23 until 2014-05-07. The interim meeting is mid September.

/js


_______________________________________________
netmod mailing list
netmod@i= etf.org
https://www.ietf.org/mailman/listinfo/netmod



_______________________________________________
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


--001a11c2bbc0a3fb18050218e3b0-- From nobody Thu Sep 4 08:22: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 E665F1A88D0; Thu, 4 Sep 2014 08:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.668, 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 o4V7GfgMtLtD; Thu, 4 Sep 2014 08:22:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E03B21A87B8; Thu, 4 Sep 2014 08:22:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AE4D8C2A8; Thu, 4 Sep 2014 11:22:19 -0400 (EDT) Date: Thu, 4 Sep 2014 11:22:19 -0400 From: Jeffrey Haas To: Benoit Claise Message-ID: <20140904152219.GO7736@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54049D7F.1010307@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UI3aLoASLmADgbgKEK6A1nBaYK0 Cc: i2rs@ietf.org, "Joel M. Halpern" , netmod@ietf.org Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Thu, 04 Sep 2014 15:22:21 -0000 Benoit and Juergen, My apologies for delay in responding to this mail. I've had a few unexpected items that have distracted me from IETF work the last several days. I will be chatting with Dean B. who had volunteered to help draft this document today. While we have previously discussed a number of items in terms of requirements and gaps, the request was that we provide a formal list of the requirements against netmod and netconf. I hope to have the result of that discussion this afternoon. -- Jeff On Mon, Sep 01, 2014 at 06:23:27PM +0200, Benoit Claise wrote: > Joel, > > On top of what J?rgen wrote, we stressed the need for such a > requirement document to both I2RS chairs during the last IETF > meeting. > The good news is that some of the requirements were mentioned on the > microphone during the Sunday YANG editing session and/or the NETMOD > meeting (my memory fails me). > > Regards, Benoit > > >On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: > >>Juergen, > >> While I understand the request, I presume that such a request can > >>not be met as a working group agreement in the time frame suggested. > >>WHile I hope that some of the folks who have been involved in proposing > >>the use of YANG for I2RS will write such a draft, I can not see how we > >>could even get tot eh point of WG adoption of such a draft, much less WG > >>rough consensus on the content, in the time frame you outline. > >> Of course, I am not one of the chairs or ADs, but it seems pretty > >>clear cut to me. > >Joel, > > > >all I need is reasonably agreed upon input. Note that this request for > >input is not coming out of the blue, at least not for those I2RS folks > >who have been at the NETMOD meeting in Toronto. > > > >As NETMOD chair, I do have a target date to deliver YANG 1.1 and I > >take that milestone serious. My motivation to delay this by N months > >waiting for I2RS to get their input submitted is very small. I recall > >that there were presentations about "what is missing" bach in London, > >that is March 2014. The regular submission period for YANG 1.1 issues > >was 2014-02-23 until 2014-05-07. The interim meeting is mid September. > > > >/js > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Sep 4 08:26: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 306461A88F1; Thu, 4 Sep 2014 08:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 ra1MlYCXizPI; Thu, 4 Sep 2014 08:26:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 353BD1A0364; Thu, 4 Sep 2014 08:26:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ECE3CC2A8; Thu, 4 Sep 2014 11:26:17 -0400 (EDT) Date: Thu, 4 Sep 2014 11:26:17 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140904152617.GP7736@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> 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/Lg8TXVOpdRNgv9yKpzA70AW3abQ Cc: Benoit Claise , "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Thu, 04 Sep 2014 15:26:21 -0000 On Mon, Sep 01, 2014 at 10:17:14AM -0700, Andy Bierman wrote: > I agree with Joel that the I2RS does not have consensus on the details. I think we continue to have consensus but not in enough detail to declare victory. Below, you identify much of what we've previously discussed: > The slides I presented in London and subsequent discussions suggest this > solution: > > 1) define YANG extension to identify I2RS data so typedefs, etc. can be > shared > in config and state data models And how this was to be different than ephemeral data, if at all. > 2) define an I2RS datastore I suspect we have consensus on this. > 3) define or extend a protocol to manage the I2RS datastore > > Let's say there is a new datastore added to the RESTCONF architecture for > I2RS. > Explain how this datastore works. It seems to have the same validation > rules > as YANG running config rules. The only difference seems to be that the > I2RS datastore > is not NV-saved (or NV-loaded at boot-time) like the running datastore. Exactly. > YANG 1.1 has some cleanup work planned to make the text less > NETCONF-specific. > I don't think there is much datastore and NV-store specific text that would > need to change. Mostly the ability to tag things emphemeral. More on that in a later message. -- Jeff From nobody Thu Sep 4 08:29: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 B6E681A8937 for ; Thu, 4 Sep 2014 08:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 oHLOp60c1tTI for ; Thu, 4 Sep 2014 08:29:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D61BC1A890E for ; Thu, 4 Sep 2014 08:29:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9B050C2A8; Thu, 4 Sep 2014 11:29:14 -0400 (EDT) Date: Thu, 4 Sep 2014 11:29:14 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140904152914.GQ7736@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> <54060362.8040004@cisco.com> 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/5IxDmZ1R1Py617iCMA-vDJeEgHc Cc: "i2rs@ietf.org" , Reinaldo Penno Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Thu, 04 Sep 2014 15:29:26 -0000 On Tue, Sep 02, 2014 at 11:00:05AM -0700, Andy Bierman wrote: > On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno wrote: > > are we taking this approach only for I2RS or this will be our preferred > > solution from now on? > > > > Meaning, every time when a new protocol/WG has certain valid requirements > > we will create a new datastore for them? > > > Good question. > It is a lot more work to add a new datastore than to tag data as ephemeral > in the existing "running" datastore -- if the only difference is no > non-volatile support. > I think the I2RS WG has to agree on those details first. Part of the discussion at the recent netmod session and post-session hallway discussion provided some suggestion there may be other users desiring ephemeral characteristics. If this is the case, providing for a mechanism for tagging ephemeral state seems to be generally useful. One of the open questions for the more general mechanism is whether ephemeral state should be in a separate data store. While I think there is good cause for I2RS to desire this, from the general standpoint it may also simplify implementations to keep ephemeral configuration segregated from static configuration. -- Jeff From nobody Thu Sep 4 09: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 C32D71A048E for ; Thu, 4 Sep 2014 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 mh-zJlrimW62 for ; Thu, 4 Sep 2014 09:20:30 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8481A89C1 for ; Thu, 4 Sep 2014 09:18:54 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l6so10837929qcy.10 for ; Thu, 04 Sep 2014 09:18:53 -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=lKaC3JnIYI3B1j4Kc04rlDe/wwA1lnn71icV5YL4TRA=; b=CU6+w9zoq7k4Qn7rpcFU6buCZ6XY7qp/1N+2W41gipMBkT+hny31ahqGFhYgCSitJ9 8tHRy14VWfnFL4nVxfumtq2PXrUuMeN5t0DCj2tifQxqnR/KaqNvajLpdoZ8fbEvRh5M 3DBsHKQMxqs5IhE903sQuOv1yHQO1KPtSheUdx4KCfccVzndbdQ3zbJb+qJdYRU2D1mg GYA0e5VSiYAgKNYLIWk1HHZ7lLvh7Hfu3Sh55J++ME/AVlkaQrFuIiE5zf2FRLpRsnbQ yXj2zoWePZfPKqtUtrXVyF7t5EcpC53MGxqC/3mgeZJbqItRww3+zR5nh8feG+1e5aH4 yTDw== X-Gm-Message-State: ALoCoQlS/p9+5cGcBNCOfycyjXYdATig4+7tZSS6xiE4mwny232INuUA/KtN9i5kJWh8sTUJfBtr MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr8181911qge.83.1409847533625; Thu, 04 Sep 2014 09:18:53 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 4 Sep 2014 09:18:53 -0700 (PDT) In-Reply-To: <20140904152914.GQ7736@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> <54060362.8040004@cisco.com> <20140904152914.GQ7736@pfrc> Date: Thu, 4 Sep 2014 09:18:53 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a113ac3c66dfd9b05023fb567 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Wb6V0ylZxeA_sfJIBMzimBfWGOU Cc: "i2rs@ietf.org" , Reinaldo Penno Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Thu, 04 Sep 2014 16:20:33 -0000 --001a113ac3c66dfd9b05023fb567 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 4, 2014 at 8:29 AM, Jeffrey Haas wrote: > On Tue, Sep 02, 2014 at 11:00:05AM -0700, Andy Bierman wrote: > > On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno > wrote: > > > are we taking this approach only for I2RS or this will be our preferred > > > solution from now on? > > > > > > Meaning, every time when a new protocol/WG has certain valid > requirements > > > we will create a new datastore for them? > > > > > Good question. > > It is a lot more work to add a new datastore than to tag data as > ephemeral > > in the existing "running" datastore -- if the only difference is no > > non-volatile support. > > I think the I2RS WG has to agree on those details first. > > Part of the discussion at the recent netmod session and post-session > hallway > discussion provided some suggestion there may be other users desiring > ephemeral characteristics. If this is the case, providing for a mechanism > for tagging ephemeral state seems to be generally useful. > > One of the open questions for the more general mechanism is whether > ephemeral state should be in a separate data store. While I think there is > good cause for I2RS to desire this, from the general standpoint it may also > simplify implementations to keep ephemeral configuration segregated from > static configuration. > > It makes a big difference to YANG XPath whether there is a separate datastore. YANG only supports 1 static context for each document type (rpc/input, rpc/output, config-data, all-data, notification). A new datastore might require many changes to YANG, depending on I2RS requirements. There are problems mixing local config and I2RS nodes in "must" or "when" expressions. One important detail is whether I2RS objects are config=true (or false) in YANG. This impacts how must, when, and other constructs will behave. If I2RS is config=false, It should be OK to reference local config from I2RS must/when stmts, but a config object must/when statement is not allowed to reference an I2RS object. Is this OK? Are there any requirements for "YANG integration" between the local config and the I2RS datastore? -- Jeff > Andy --001a113ac3c66dfd9b05023fb567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Sep 4, 2014 at 8:29 AM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
On Tue, Sep 02, 2014 at 11:00:05AM -0700, An= dy Bierman wrote:
> On Tue, Sep 2, 2014 at 10:50 AM, Reinaldo Penno <repenno@cisco.com> wrote:
> > are we taking this approach only for I2RS or this will be our pre= ferred
> > solution from now on?
> >
> > Meaning, every time when a new protocol/WG has certain valid requ= irements
> > we will create a new datastore for them?
> >
> Good question.
> It is a lot more work to add a new datastore than to tag data as ephem= eral
> in the existing "running" datastore -- if the only differenc= e is no
> non-volatile support.
> I think the I2RS WG has to agree on those details first.

Part of the discussion at the recent netmod session and post-session hallwa= y
discussion provided some suggestion there may be other users desiring
ephemeral characteristics.=A0 If this is the case, providing for a mechanis= m
for tagging ephemeral state seems to be generally useful.

One of the open questions for the more general mechanism is whether
ephemeral state should be in a separate data store.=A0 While I think there = is
good cause for I2RS to desire this, from the general standpoint it may also=
simplify implementations to keep ephemeral configuration segregated from static configuration.


It makes a big difference to YANG XPat= h whether there is a separate datastore.
YANG only supports 1 sta= tic context for each document type=A0
(rpc/input, rpc/output, con= fig-data, all-data, notification). A new datastore might
require many changes to YANG, depending on I2RS requirements.

There are problems mixing local config and I2RS nodes in &= quot;must" or "when" expressions.
One important de= tail is whether I2RS objects are config=3Dtrue (or false) in YANG.
This impacts how must, when, and other constructs will behave.=A0

If I2RS is config=3Dfalse, It should be OK to referenc= e local config from I2RS must/when stmts,
but a config object mus= t/when statement is not allowed to reference an I2RS object.
Is this OK? Are there any requirements for "YANG integration"= ; between the local config
and the I2RS datastore?

=

-- Jeff

Andy

--001a113ac3c66dfd9b05023fb567-- From nobody Thu Sep 4 09:32: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 32C8C1A0459 for ; Thu, 4 Sep 2014 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.668, 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 fASdt5eVm52Z for ; Thu, 4 Sep 2014 09:32:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 507091A046D for ; Thu, 4 Sep 2014 09:32:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0B5D7C2A8; Thu, 4 Sep 2014 12:32:24 -0400 (EDT) Date: Thu, 4 Sep 2014 12:32:24 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140904163223.GE19570@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> <54060362.8040004@cisco.com> <20140904152914.GQ7736@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/IZsNdc9wMVUgLxdALf7ZeuD4eXI Cc: Jeffrey Haas , "i2rs@ietf.org" , Reinaldo Penno Subject: Re: [i2rs] [netmod] netmod interim and i2rs 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: Thu, 04 Sep 2014 16:32:28 -0000 On Thu, Sep 04, 2014 at 09:18:53AM -0700, Andy Bierman wrote: > It makes a big difference to YANG XPath whether there is a separate > datastore. > YANG only supports 1 static context for each document type > (rpc/input, rpc/output, config-data, all-data, notification). A new > datastore might > require many changes to YANG, depending on I2RS requirements. > > There are problems mixing local config and I2RS nodes in "must" or "when" > expressions. > One important detail is whether I2RS objects are config=true (or false) in > YANG. > This impacts how must, when, and other constructs will behave. > > If I2RS is config=false, It should be OK to reference local config from > I2RS must/when stmts, > but a config object must/when statement is not allowed to reference an I2RS > object. > Is this OK? Are there any requirements for "YANG integration" between the > local config > and the I2RS datastore? An example use case that may cover this is a BGP dynamic peer I2RS interface. In such a case (ideally): - Configuration exists for BGP. This implies an IDR BGP yang module. - Some re-usable components from the BGP module have been made into groupings to permit I2RS re-use. For example, a "neighbor template". - The I2RS portion of this module would rely on some amount of local BGP configuration outside of the I2RS module. As a trivial example, "router autonomous system number" is a property that is device-wide that may be owned by BGP config; the I2RS neighbor configuration would have a "must" dependency on the presence of the ASN config. (Those who are interested in working on such a BGP I2RS module please hold your nitpicking of the example. Yes, we'll probably want to permit local configuration of the neighbor ASN as well, but it highlights the issue... :-) If we can't do this sort of thing by using a separate datastore, that may push the solution a given direction. -- Jeff From nobody Fri Sep 12 14:09: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 164711A009A; Fri, 12 Sep 2014 14:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, 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 BGbiEwZUfdbu; Fri, 12 Sep 2014 14:09:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7020C1A00F0; Fri, 12 Sep 2014 14:09:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 145DDC3DF; Fri, 12 Sep 2014 17:09:14 -0400 (EDT) Date: Fri, 12 Sep 2014 17:09:13 -0400 From: Jeffrey Haas To: i2rs@ietf.org, netmod@ietf.org Message-ID: <20140912210913.GA10692@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/NSWP7OeHD9ebKOaWAK9MDjef2jg Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Fri, 12 Sep 2014 21:09:19 -0000 With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf. It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve interested parties. As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus. At best, it reflects my attempt to summarize prior discussions and turn them into requirements. This document will most assuredly be wrong and be revised. But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week. My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out. Comments are appreciated. Flames are not unexpected. -- Jeff New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 From nobody Fri Sep 12 14:22: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 3EDF01A0049 for ; Fri, 12 Sep 2014 14:22:24 -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 m0Azm0uaoTsA for ; Fri, 12 Sep 2014 14:22:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A553B1A0032 for ; Fri, 12 Sep 2014 14:22:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 805D52412B1 for ; Fri, 12 Sep 2014 14:22:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-41.clppva.east.verizon.net [70.106.135.41]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 01DF4240759 for ; Fri, 12 Sep 2014 14:22:21 -0700 (PDT) Message-ID: <54136414.5080101@joelhalpern.com> Date: Fri, 12 Sep 2014 17:22:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> In-Reply-To: <20140912205913.27356.43819.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/_-iRRlN3CthjOmQ7ugHs_64yn_k Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Fri, 12 Sep 2014 21:22:24 -0000 Thanks for doing this Jeff. It is a great start. The Object Relationships issue does need more work however. Some of the cases are handled... YANG's tools for reuse can be used to meet the inheritance requirements. I think that the requires and when clauses are probably powerful enough to meet the architecture requirements for optionality (arch 6.4.5.2). I do not know of anything in YANG that corresponds to agent side templating, as was agreed by the working group and captured in arch 6.4.5.3. (Since I am one who argued against this, if we need more detailed examples I would appreciate some assistance.) The object relationships are three piece. Arch 6.4.5.4.2 on correlation and arch 6.4.5.4.3 on actual references seem to be covered by various parts of YANG. But the initialization reference described in arch 6.4.5.4.1 does not correspond to anything I know of in YANG. Is there a YANG tool for that? This is the case where the definition of an object Foo says that whenever a new Foo is created, it takes its initial values from an instance of Bar, so as to simplify instantiation. This is similar too, but not the same as the templates material. You talk about the priority requirements. You should probably mention the multi-headed behavioral requirements there (as I think that the resolutions will be tightly coupled.) Section 7.9 of the archtiecture document talks about several transactional scopes. The text you have does not seem to deal with all of these. Does YANG handle them all easily? Yours, Joel On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : I2RS requirements for netmod/netconf > Author : Jeffrey Haas > Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt > Pages : 10 > Date : 2014-09-12 > > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support requirements to implement the > I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-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 Fri Sep 12 18:09: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 42B291A0177 for ; Fri, 12 Sep 2014 18:09: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, 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 Bh8MyjDhAPIN for ; Fri, 12 Sep 2014 18:09:03 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05571A0175 for ; Fri, 12 Sep 2014 18:09:03 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id v10so1613263qac.27 for ; Fri, 12 Sep 2014 18:09: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:date :message-id:subject:from:to:cc:content-type; bh=QwsbLrbah9VTadwADHVXLp//FIn86aTL4fu7pkBxFt8=; b=XbEFQbJbzOyAEyLbHNQsFGNum+VKLmmE7ylLj1pIfyaa+wCS1ntldo8oyUuxetio9v xCA5SyA2A4BEtf+YV2HeRIDwUIuVURM7fwb+F/HJm62AP2Np175kc2FCklJbOIwWoFXf /K4octzExMsPqIOBvN1Yo7388zAwHJIAdDE8Ozo5NzFsB3ElHuF+58Fe/PdahyYiBZ6t Fp+hYCDgfPxa8EqoUXOg2mSXP5C7Up97tj/wQaL+GuUqrP4vFluygusU576aToIIxF08 +glJzCk0VFk/ngH1ileBcnQnB0Zg5F5AaAFaHb/v/RoA0duBKxCl1pznXQy316QeCDaU kGhA== X-Gm-Message-State: ALoCoQllsTnB8s/AujfL9rRzXpLPuovL+5dqU5PWJbCEv3mdFA1+mX/XJemUDNcF1njA53EW/LAg MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr11528694qah.99.1410570542617; Fri, 12 Sep 2014 18:09:02 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 12 Sep 2014 18:09:02 -0700 (PDT) In-Reply-To: <54136414.5080101@joelhalpern.com> References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> Date: Fri, 12 Sep 2014 18:09:02 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c3d8d41fe1ee0502e80cf5 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dQ42uhrIdbiDtYb7tYcLajNxSzQ Cc: "i2rs@ietf.org" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Sat, 13 Sep 2014 01:09:08 -0000 --001a11c3d8d41fe1ee0502e80cf5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 12, 2014 at 2:22 PM, Joel M. Halpern wrote: > Thanks for doing this Jeff. It is a great start. > > The Object Relationships issue does need more work however. > Some of the cases are handled... > > YANG's tools for reuse can be used to meet the inheritance requirements. > I think that the requires and when clauses are probably powerful enough to > meet the architecture requirements for optionality (arch 6.4.5.2). > > I do not know of anything in YANG that corresponds to agent side > templating, as was agreed by the working group and captured in arch > 6.4.5.3. (Since I am one who argued against this, if we need more detailed > examples I would appreciate some assistance.) > I agree with you that Agent templates do not belong in the I2RS base spec. There is nothing in YANG or RESTCONF to support it (yet). For some features the I2RS agent is supposedly simple and mostly stateless. This template service does not seem to fit with that theme. Are these templates ephemeral? That would be annoying. They are not straight config, so a new a configuration data model is needed to manage the templates. New protocol mechanisms to use templates in addition to payload data will be needed. > The object relationships are three piece. Arch 6.4.5.4.2 on correlation > and arch 6.4.5.4.3 on actual references seem to be covered by various parts > of YANG. But the initialization reference described in arch 6.4.5.4.1 does > not correspond to anything I know of in YANG. Is there a YANG tool for > that? This is the case where the definition of an object Foo says that > whenever a new Foo is created, it takes its initial values from an instance > of Bar, so as to simplify instantiation. This is similar too, but not the > same as the templates material. > Nothing in YANG like that except the description-stmt. The server can magically create whatever it wants, whenever it wants. > > You talk about the priority requirements. You should probably mention the > multi-headed behavioral requirements there (as I think that the resolutions > will be tightly coupled.) > > Section 7.9 of the archtiecture document talks about several transactional > scopes. The text you have does not seem to deal with all of these. Does > YANG handle them all easily? > I would need to review this again -- I don't remember any problems last time I read the arch draft. I am confused about some text in the draft about ephemeral config: In 2.1: The author wishes to prevent any action that would lead to preserving any configuration state entered via the I2RS agent across reboots. If state has to be restored, it should be solely by replay actions from I2RS client via I2RS agent. Why does the author wish to prevent NV-storage of the I2RS data? What is it about the accidental reboot of the router that makes it the I2RS data needed before the accidental reboot, but not after? If the reason is because I2RS agents are simple and NV-storage is not simple, then why does the agent need to support templates? This section might mention that the I2RS datastore has its own access control model, that is not the same as the running config. 2. Configuration state in the existing running datastore where the module is "tagged ephemeral". 3. Permitting existing configuration to be optionally configured as ephemeral. As an example, the NETCONF server advertises in its message if it supports the specified YANG module persistently and/or ephemerally. I thought the I2RS charter said I2RS was not altering the local config. Why does I2RS need to change the meaning of YANG configuration nodes in an ad-hoc manner (via tagging)? This does not really work because YANG validation may fail without some config data that has been tagged "do not save". If the router reboots and the startup config does not validate, it is probably wedged. It can't really fall back to a "known good config" if I2RS has forced some of the data to be omitted from the saved config. In sec 2.1.3, if you want a new third choice for the config-stmt for "ephemeral", then I2RS is gated on the completion of YANG 1.1 (and development of YANG 1.1 tools). Are you really sure you want that? That's why a YANG extension was suggested instead (or maybe do both). > Yours, > Joel > Andy > > On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : I2RS requirements for netmod/netconf >> Author : Jeffrey Haas >> Filename : draft-haas-i2rs-netmod- >> netconf-requirements-00.txt >> Pages : 10 >> Date : 2014-09-12 >> >> Abstract: >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support requirements to implement the >> I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod- >> netconf-requirements/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-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 >> >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c3d8d41fe1ee0502e80cf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 12, 2014 at 2:22 PM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
Thanks for doing this Jeff.=A0 = It is a great start.

The Object Relationships issue does need more work however.
Some of the cases are handled...

YANG's tools for reuse can be used to meet the inheritance requirements= .
I think that the requires and when clauses are probably powerful enough to = meet the architecture requirements for optionality (arch 6.4.5.2).

I do not know of anything in YANG that corresponds to agent side templating= , as was agreed by the working group and captured in arch 6.4.5.3.=A0 (Sinc= e I am one who argued against this, if we need more detailed examples I wou= ld appreciate some assistance.)

I agree= with you that Agent templates do not belong in the I2RS base spec.
There is nothing in YANG or RESTCONF to support it (yet).
For = some features the I2RS agent is supposedly simple and mostly stateless.
This template service does not seem to fit with that theme.
Are these templates ephemeral? =A0That would be annoying. =A0They are not= straight
config, so a new a configuration data model is needed t= o manage the templates.
New protocol mechanisms to use templates = in addition to payload data will be needed.


The object relationships are three piece.=A0 Arch 6.4.5.4.2 on correlation = and arch 6.4.5.4.3 on actual references seem to be covered by various parts= of YANG.=A0 But the initialization reference described in arch 6.4.5.4.1 d= oes not correspond to anything I know of in YANG.=A0 Is there a YANG tool f= or that?=A0 This is the case where the definition of an object Foo says tha= t whenever a new Foo is created, it takes its initial values from an instan= ce of Bar, so as to simplify instantiation.=A0 This is similar too, but not= the same as the templates material.

No= thing in YANG like that except the description-stmt.
The server c= an magically create whatever it wants, whenever it wants.

=A0

You talk about the priority requirements.=A0 You should probably mention th= e multi-headed behavioral requirements there (as I think that the resolutio= ns will be tightly coupled.)

Section 7.9 of the archtiecture document talks about several transactional = scopes.=A0 The text you have does not seem to deal with all of these.=A0 Do= es YANG handle them all easily?

I would= need to review this again -- I don't remember any problems last time I= read the arch draft.


I am confused= about some text in the draft about ephemeral config:

<= div>In 2.1:
   The author wishes to
   prevent any action that would lead to preserving any configuration
   state entered via the I2RS agent across reboots.  If state has to be
   restored, it should be solely by replay actions from I2RS client via
   I2RS agent.
=A0
Why does the author wish to prevent= NV-storage of the I2RS data?
What is it ab= out the accidental reboot of the router that makes it the
I2RS data needed before the accidental reboot, but not aft= er?

If= the reason is because I2RS agents are simple and NV-storage is not simple,=
then why does the agent need to support te= mplates?=A0

This section might mention that the I2RS datastore has its own
<= div class=3D"gmail_quote">access control model, that is not the same as the= running config.

   2.  Configuration state in the existing running datastore wher=
e the
       module is "tagged ephemeral".

   3.  Permitting existing configuration to be optionally configured as
       ephemeral.  As an example, the NETCONF server advertises in its
       <hello> message if it supports the specified YANG module
       persistently and/or ephemerally.


I thought t= he I2RS charter said I2RS was not altering the local config.
Why does I2RS need to change the meaning of YANG configuration = nodes
in an ad-hoc manner (via tagging)?

This doe= s not really work because YANG validation may fail without some config data=
that has been tagged "do not save&quo= t;. =A0If the router reboots and the startup config
does not validate, it is probably wedged. It can't really fall= back to a "known good config"
if= I2RS has forced some of the data to be omitted from the saved config.

In sec 2.1= .3, if you want a new third choice for the config-stmt for "ephemeral&= quot;,
then I2RS is gated on the completion= of YANG 1.1 (and development of YANG 1.1 tools).
Are you really sure you want that? =A0That's why a YANG extensio= n was suggested instead
(or maybe do both).=


<= /div>




Yours,
Joel


Andy
=A0<= /div>

On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 =A0Title=A0 =A0 =A0 =A0 =A0 =A0: I2RS requirements for netm= od/netconf
=A0 =A0 =A0 =A0 =A0Author=A0 =A0 =A0 =A0 =A0 : Jeffrey Haas
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-haas-i2rs-netmod-net= conf-requirements-00.txt
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 10
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-09-12

Abstract:
=A0 =A0 This document covers requests to the netmod and netconf Working
=A0 =A0 Groups for functionality to support requirements to implement the =A0 =A0 I2RS architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-haas-i2rs-netmod-netconf-requirements/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-haas-i= 2rs-netmod-netconf-requirements-00


Please note that it may take a couple of minutes from the time of submissio= n
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@iet= f.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


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

--001a11c3d8d41fe1ee0502e80cf5-- From nobody Mon Sep 15 06:17: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 30EF41A0348; Mon, 15 Sep 2014 06:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 0B1img4qXRQB; Mon, 15 Sep 2014 06:17:52 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC641A0345; Mon, 15 Sep 2014 06:17:51 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so4568854lab.33 for ; Mon, 15 Sep 2014 06:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=4rx7/yHBtxSDEtfR7bWDXAUGpzf6bf3dtn+iN8dXT4s=; b=YSLXajfsbI3M2dC0QxAZriA0mYfa7s3wWpyW5nU6P/f2KPkuEofVAjqvZo9VvdyHud x3w4CoNua++2xS8yjFn2UgXDF25Rt1CjbrjpG3awHdLo0SM+h4esouR1+W4NVk3VaBNH o8lZoGk6mak8dO6MzSA4UaEVQ15G9XH56rpg8tzJdizPu33xADZ+LZfKb7h/O59ak8wm VNpdcsmhXdj8pS7SoFJImpTQC9Okm3MNb5AXfjjzv5Yr9wMe31ZbovErAo8zcOVuQ/Lr gexiCZ/8FNPB2Qch31Y89jX36Q3WSpl4vUIfpUJOGE15D37UP9q5r1LAmM/LGpoqAXm+ GPKg== MIME-Version: 1.0 X-Received: by 10.152.121.8 with SMTP id lg8mr2871851lab.98.1410787069904; Mon, 15 Sep 2014 06:17:49 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Mon, 15 Sep 2014 06:17:49 -0700 (PDT) In-Reply-To: <20140829064207.GA63316@elstar.local> References: <20140829064207.GA63316@elstar.local> Date: Mon, 15 Sep 2014 08:17:49 -0500 Message-ID: From: Behcet Sarikaya To: Juergen Schoenwaelder , "i2rs@ietf.org" , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ZHDjPZoT0_vmcu_KkTNYPGbxYPw Subject: Re: [i2rs] netmod interim and i2rs requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:17:53 -0000 Hi Juergen, What is Netconf protocol called? SNMP v4? Regards, Behcet On Fri, Aug 29, 2014 at 1:42 AM, Juergen Schoenwaelder wrote: > Hi, > > the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one > of the agenda items is to work on any requirements I2RS might have for > YANG 1.1. For this, we need a clear definition of what the I2RS > requirements are for YANG 1.1, ideally posted as an I-D a few days > before the interim meeting so that people can come prepared. This > means there are ~15 days left to produce such a requirements writeup. > > /js > > [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Sep 15 06:22: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 F12EB1A0348; Mon, 15 Sep 2014 06:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 CmlNXXKY1Te5; Mon, 15 Sep 2014 06:21:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6971F1A0326; Mon, 15 Sep 2014 06:21:59 -0700 (PDT) Received: from [192.168.1.150] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 901E7288CCDF; Mon, 15 Sep 2014 09:21:58 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Mon, 15 Sep 2014 09:21:54 -0400 Message-Id: <0271678E-C85C-4115-89B8-392BCBEB86BF@lucidvision.com> References: <20140829064207.GA63316@elstar.local> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ZHZ6aS4hRRlJfPXQb8-Ez7QXq2Q Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , netmod@ietf.org Subject: Re: [i2rs] netmod interim and i2rs 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: Mon, 15 Sep 2014 13:22:01 -0000 --Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Netconf is called Netconf; it has nothing to do with SNMP. =20 --Tom On Sep 15, 2014:9:17 AM, at 9:17 AM, Behcet Sarikaya = wrote: > Hi Juergen, >=20 > What is Netconf protocol called? SNMP v4? >=20 > Regards, >=20 > Behcet >=20 > On Fri, Aug 29, 2014 at 1:42 AM, Juergen Schoenwaelder > wrote: >> Hi, >>=20 >> the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one >> of the agenda items is to work on any requirements I2RS might have = for >> YANG 1.1. For this, we need a clear definition of what the I2RS >> requirements are for YANG 1.1, ideally posted as an I-D a few days >> before the interim meeting so that people can come prepared. This >> means there are ~15 days left to produce such a requirements writeup. >>=20 >> /js >>=20 >> [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1 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 iQIcBAEBCgAGBQJUFufyAAoJEPcO+I7eiUJZFjkQALJqD/MTFN+Ymm7EzPe2+dxU HR7K2Jus8VSqCxzWzaNCMUimxZSZRqjY2S4QHEc/scfVLP3Kqp03uS20GzBIEXiQ qeOy2/BG0TaHzGyXSK+SqER58+yRNiU9/Q1UMXoV7LN4QBurI6FF+RgL+K16jR8o BiGOlJki7K9z5Wmo+1NDQpuP+DDJZn4B1KtQ8+GBhKoxjK7xKqqt9ZunTAxr4NXO 0TL7WUdDV7cCMdV3zsTq2I4quuZSc7MJ5MEeGk0HIU2Rq+sipP84GiFEkZRhEJG/ 3j3ensdgEbOH0JdggshF2/gjRisSVHXlntUn8C8cHBmXw9lCWBs6SziGwx/hS8e2 Nd6YqiMMuup8JGk6dvhQVbEbuQ9rwaLIgdn+8U15tqQC/o6do6DiAUdJ9Db5ZqcV dEtvlugBQ3H6yjbLctqB2K32r+DtsP66WHH02JG/bMjBJfJ+5b5BpPieFCaKb+cq 0tE0gD9TziwhyGNinyUz0fnSXBp61+X7Tez9N6RzluRm6HX2IKH+zH15JQe5dtwb 4aQKERYddiFpnGuiRndSaNgFCUTbC+Wqacsx66TYHZBHot+FmWuxnjyl8uKfRuBg wQvO3ZWKXY/941pyOivktgncayEYJNfoEVX5c9DDjiLZOBR/ozG68JxiG+vy3Yzb 5g8B49zXPQ44e21s9/Oi =lo3G -----END PGP SIGNATURE----- --Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1-- From nobody Mon Sep 15 11:25: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 A38851A03A3 for ; Mon, 15 Sep 2014 11:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, 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 I8l9K5Ylldg2 for ; Mon, 15 Sep 2014 11:25:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDEC1A8772 for ; Mon, 15 Sep 2014 10:41:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0E0A7C49E; Mon, 15 Sep 2014 13:41:57 -0400 (EDT) Date: Mon, 15 Sep 2014 13:41:57 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20140915174157.GJ14947@pfrc> References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54136414.5080101@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dB5risw6z7l9hm3J2vnw2IYWrjA Cc: "i2rs@ietf.org" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Mon, 15 Sep 2014 18:25:51 -0000 On Fri, Sep 12, 2014 at 05:22:28PM -0400, Joel M. Halpern wrote: > Thanks for doing this Jeff. It is a great start. Thanks Joel - especially for the patience. FWIW, I invite others to send edits. The xml is posted in github: https://github.com/jhaas-pfrc/I2RS-netmod-netconf-requirements > The Object Relationships issue does need more work however. > Some of the cases are handled... Agreed. This section was flagged by Alia as potentially requiring some attention but we didn't manage to get text in here. I think the biggest concern she had (trying to summarize) is that if B depends on A, when A is updated B needs to "know" that in some form. (And presumably transitive relationships such as C depends on B depends on A and A is updated...) I don't know that there's any specific action here, but certainly an open question. > YANG's tools for reuse can be used to meet the inheritance requirements. > I think that the requires and when clauses are probably powerful > enough to meet the architecture requirements for optionality (arch > 6.4.5.2). > > I do not know of anything in YANG that corresponds to agent side > templating, as was agreed by the working group and captured in arch > 6.4.5.3. (Since I am one who argued against this, if we need more > detailed examples I would appreciate some assistance.) > > The object relationships are three piece. Arch 6.4.5.4.2 on > correlation and arch 6.4.5.4.3 on actual references seem to be > covered by various parts of YANG. But the initialization reference > described in arch 6.4.5.4.1 does not correspond to anything I know > of in YANG. Is there a YANG tool for that? This is the case where > the definition of an object Foo says that whenever a new Foo is > created, it takes its initial values from an instance of Bar, so as > to simplify instantiation. This is similar too, but not the same as > the templates material. A number of these items seem logical and perhaps even trivial in a client-side environment. The clarity of whether/how they can be implemented in the agent is one of the reasons why the Architecture document has been not been published. > You talk about the priority requirements. You should probably > mention the multi-headed behavioral requirements there (as I think > that the resolutions will be tightly coupled.) How would you distinguish the property that priority imposes on the agent from that which would come from the multi-headed case? > Section 7.9 of the archtiecture document talks about several > transactional scopes. The text you have does not seem to deal with > all of these. Does YANG handle them all easily? The better question, I believe, is whether NETCONF/RESTCONF handles them appropriately for the YANG involved. Working through some of these cases with Dean B. suggested that you could get most in NETCONF and some in RESTCONF. Whether they make sense for a given use case may drive a particular application. -- Jeff From nobody Mon Sep 15 11:32: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 ACA861A6FFE for ; Mon, 15 Sep 2014 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, 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 sBUJB_3ngAvr for ; Mon, 15 Sep 2014 11:32:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 174371A889D for ; Mon, 15 Sep 2014 11:01:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CF2F0C245; Mon, 15 Sep 2014 14:01:09 -0400 (EDT) Date: Mon, 15 Sep 2014 14:01:09 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140915180109.GK14947@pfrc> References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> 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/aTOhA0J4Ux19WQ0bdKovAQxwkvY Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Mon, 15 Sep 2014 18:32:53 -0000 On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > There is nothing in YANG or RESTCONF to support it (yet). > For some features the I2RS agent is supposedly simple and mostly stateless. > This template service does not seem to fit with that theme. Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference. The tension seems to lie roughly along two points of view: 1. This is a programmatically driven API environment. As such, there's little excuse to not simply send everything needed as a large configuration block - templates are extraneous. 2. By permitting templates, you enable much smaller transactions. You also potentially allow for a stronger security model by "locking down" stuff outside of the template. To offer a somewhat concrete example, consider an application for provisioning L3VPN customers. Some minimum required configuration on a per-device basis includes: VRF name. A route-distinguisher. A route-target for the VPN. Customer PE-CE protocol and endpoint configuration. Fully expanded, this is probably a few dozens of lines of configuration in YANG. What's interesting is that the above information is potentially generic related to that configuration, which may have per-device variance - potentially based upon vendor. Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted. > Are these templates ephemeral? That would be annoying. They are not > straight > config, so a new a configuration data model is needed to manage the > templates. > New protocol mechanisms to use templates in addition to payload data will > be needed. All agreed. > > You talk about the priority requirements. You should probably mention the > > multi-headed behavioral requirements there (as I think that the resolutions > > will be tightly coupled.) > > > > Section 7.9 of the archtiecture document talks about several transactional > > scopes. The text you have does not seem to deal with all of these. Does > > YANG handle them all easily? > > > > I would need to review this again -- I don't remember any problems last > time I read the arch draft. Some of this is a matter of where this information lives. For tie-breaking of ephemeral vs. static config, is this provisioned per-module or per element in the module? Are there explicit lines of YANG in each module for this? For tie-breaking user priorities, NACM extensions may make sense. This particular state is effectively meta-data on the ephemeral config. Since the epehemeral state is "highest priority wins", but there's no requirement that the lower priority state is kept in any fashion, how do we deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state? > I am confused about some text in the draft about ephemeral config: > > In 2.1: > > The author wishes to > prevent any action that would lead to preserving any configuration > state entered via the I2RS agent across reboots. If state has to be > restored, it should be solely by replay actions from I2RS client via > I2RS agent. > > > Why does the author wish to prevent NV-storage of the I2RS data? > What is it about the accidental reboot of the router that makes it the > I2RS data needed before the accidental reboot, but not after? I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored? > If the reason is because I2RS agents are simple and NV-storage is not > simple, > then why does the agent need to support templates? This is more a "clean slate" decision. When the device comes up, it has no I2RS state. Note that the fully ephemeral nature of I2RS still doesn't feel fully-settled in the WG. See prior thread comments about wanting to do copy-config on it. :-) > This section might mention that the I2RS datastore has its own > access control model, that is not the same as the running config. > > 2. Configuration state in the existing running datastore where the > module is "tagged ephemeral". > > 3. Permitting existing configuration to be optionally configured as > ephemeral. As an example, the NETCONF server advertises in its > message if it supports the specified YANG module > persistently and/or ephemerally. > > > > I thought the I2RS charter said I2RS was not altering the local config. Correct. > Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)? For point 2, it'd be identifying I2RS modules (having the ephemeral properties) in the YANG. Point 3 is submitted as an option based on comments at the last IETF netmod session where someone else indicated being able to store things ephemerally would potentially be useful. If this is indeed a wider use case, let's discuss it. > This does not really work because YANG validation may fail without some > config data > that has been tagged "do not save". If the router reboots and the startup > config > does not validate, it is probably wedged. It can't really fall back to a > "known good config" > if I2RS has forced some of the data to be omitted from the saved config. Agreed. See also the priority discussion above. > In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral", > then I2RS is gated on the completion of YANG 1.1 (and development of YANG > 1.1 tools). > Are you really sure you want that? That's why a YANG extension was > suggested instead > (or maybe do both). Worth discussing during the interim. It has been suggested to me that many of the above properties can already be implemented in a proprietary manner with no language extensions. They would simply not be either interoperable or clear about their ephemeral nature based on module contents. So, we're looking for a balance of expeditious and correct for the long term maintainenace of the protocols and YANG. -- Jeff From nobody Mon Sep 15 15:46: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 073C21A884B for ; Mon, 15 Sep 2014 15:46:27 -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 IxiZR5aFwQFE for ; Mon, 15 Sep 2014 15:46:23 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D901A8785 for ; Mon, 15 Sep 2014 15:46:23 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x13so2673932qcv.16 for ; Mon, 15 Sep 2014 15:46: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=uIu7NRwIKcMGO2PcJB3AbP1k3x3NfrEKixD/EwGxhlc=; b=kdhP57Pv0k/6/H2FKEpRUlSCys1/63yNf9m2bUaG5thBOz3h+0nqbBHiSrzmtEDxNF J9MczyVJqLLTEofGJfcPejzIHPH9QsZUUtvuGzK/M16Z0tleETaGYRbRrx+/cQlZkfHg u//KbS7BhPELbHPnKsGOgbQBadS4SPwEE/mgQ0mthykCwJyBd5dnZYyuysEXIqyK+/zk gpeeHe460UYzY71qd0UyFO/RMMt5xXXNOlpKTQpFasITdzNG9Q6MUJ2db3hYGmeqWvhe CzoNmsyFqt7vTQBAnwsMBnZVFMJNKgkttRJaj9hUIcHLiLuuHuHoVeRzrUUj9chRgo/2 WnkQ== X-Gm-Message-State: ALoCoQnFjmfDIKYt38RtSfN9FdRkl44EzyK4ZC4sW997Wd/t5sqZJeQkWAgMpdS32+QlqYMt8GBa MIME-Version: 1.0 X-Received: by 10.229.231.68 with SMTP id jp4mr41117182qcb.4.1410821179648; Mon, 15 Sep 2014 15:46:19 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 15 Sep 2014 15:46:19 -0700 (PDT) In-Reply-To: <20140915180109.GK14947@pfrc> References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> <20140915180109.GK14947@pfrc> Date: Mon, 15 Sep 2014 15:46:19 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1134497a4143630503226700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ny36MC24OgGMZJ3wVDSlyI1sXpc Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Mon, 15 Sep 2014 22:46:27 -0000 --001a1134497a4143630503226700 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas wrote: > On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > > There is nothing in YANG or RESTCONF to support it (yet). > > For some features the I2RS agent is supposedly simple and mostly > stateless. > > This template service does not seem to fit with that theme. > > Attempting to summarize discussions with various I2RS WG participants, I > think it's a matter of perspective - and somewhat of preference. The > tension seems to lie roughly along two points of view: > > 1. This is a programmatically driven API environment. As such, there's > little excuse to not simply send everything needed as a large configuration > block - templates are extraneous. > > 2. By permitting templates, you enable much smaller transactions. You also > potentially allow for a stronger security model by "locking down" stuff > outside of the template. > > To offer a somewhat concrete example, consider an application for > provisioning L3VPN customers. Some minimum required configuration on a > per-device basis includes: > > VRF name. > A route-distinguisher. > A route-target for the VPN. > Customer PE-CE protocol and endpoint configuration. > > Fully expanded, this is probably a few dozens of lines of configuration in > YANG. What's interesting is that the above information is potentially > generic related to that configuration, which may have per-device variance - > potentially based upon vendor. > > Thought about perhaps another way, the template inputs are effectively a > mini-YANG module with much of the back-end abstracted. > > > Are these templates ephemeral? That would be annoying. They are not > > straight > > config, so a new a configuration data model is needed to manage the > > templates. > > New protocol mechanisms to use templates in addition to payload data will > > be needed. > > All agreed. > > > > You talk about the priority requirements. You should probably mention > the > > > multi-headed behavioral requirements there (as I think that the > resolutions > > > will be tightly coupled.) > > > > > > Section 7.9 of the archtiecture document talks about several > transactional > > > scopes. The text you have does not seem to deal with all of these. > Does > > > YANG handle them all easily? > > > > > > > I would need to review this again -- I don't remember any problems last > > time I read the arch draft. > > Some of this is a matter of where this information lives. > > For tie-breaking of ephemeral vs. static config, is this provisioned > per-module or per element in the module? Are there explicit lines of YANG > in each module for this? > > For tie-breaking user priorities, NACM extensions may make sense. This > particular state is effectively meta-data on the ephemeral config. > > Since the epehemeral state is "highest priority wins", but there's no > requirement that the lower priority state is kept in any fashion, how do we > deal with inconsistent configuration that may result by a higher priority > user deleting part of their configured state? > > > I am confused about some text in the draft about ephemeral config: > > > > In 2.1: > > > > The author wishes to > > prevent any action that would lead to preserving any configuration > > state entered via the I2RS agent across reboots. If state has to be > > restored, it should be solely by replay actions from I2RS client via > > I2RS agent. > > > > > > Why does the author wish to prevent NV-storage of the I2RS data? > > What is it about the accidental reboot of the router that makes it the > > I2RS data needed before the accidental reboot, but not after? > > I think my point of confusion is why you believe ephemeral configuration > would ever get NV-stored? > Several people have asked about "copy to local config", which is really "NV-save the I2RS state". What if the operator wants the state to be active until it is explicitly removed? There may be significant latency between the time the client discovers the agent has rebooted and the state is re-installed. > > If the reason is because I2RS agents are simple and NV-storage is not > > simple, > > then why does the agent need to support templates? > > This is more a "clean slate" decision. When the device comes up, it has no > I2RS state. > > Note that the fully ephemeral nature of I2RS still doesn't feel > fully-settled in the WG. See prior thread comments about wanting to do > copy-config on it. :-) > > > This section might mention that the I2RS datastore has its own > > access control model, that is not the same as the running config. > > > > 2. Configuration state in the existing running datastore where the > > module is "tagged ephemeral". > > > > 3. Permitting existing configuration to be optionally configured as > > ephemeral. As an example, the NETCONF server advertises in its > > message if it supports the specified YANG module > > persistently and/or ephemerally. > > > > > > > > I thought the I2RS charter said I2RS was not altering the local config. > > Correct. > > > Why does I2RS need to change the meaning of YANG configuration nodes > > in an ad-hoc manner (via tagging)? > > For point 2, it'd be identifying I2RS modules (having the ephemeral > properties) in the YANG. > > Point 3 is submitted as an option based on comments at the last IETF netmod > session where someone else indicated being able to store things ephemerally > would potentially be useful. If this is indeed a wider use case, let's > discuss it. > > > This does not really work because YANG validation may fail without some > > config data > > that has been tagged "do not save". If the router reboots and the > startup > > config > > does not validate, it is probably wedged. It can't really fall back to a > > "known good config" > > if I2RS has forced some of the data to be omitted from the saved config. > > Agreed. See also the priority discussion above. > > > In sec 2.1.3, if you want a new third choice for the config-stmt for > > "ephemeral", > > then I2RS is gated on the completion of YANG 1.1 (and development of YANG > > 1.1 tools). > > Are you really sure you want that? That's why a YANG extension was > > suggested instead > > (or maybe do both). > > Worth discussing during the interim. > > It has been suggested to me that many of the above properties can already > be > implemented in a proprietary manner with no language extensions. They > would > simply not be either interoperable or clear about their ephemeral nature > based on module contents. > > So, we're looking for a balance of expeditious and correct for the long > term > maintainenace of the protocols and YANG. > > -- Jeff > Andy --001a1134497a4143630503226700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Fri, Sep 12, 2014 at 06:09= :02PM -0700, Andy Bierman wrote:
> There is nothing in YANG or RESTCONF to support it (yet).
> For some features the I2RS agent is supposedly simple and mostly state= less.
> This template service does not seem to fit with that theme.

Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference.=A0 The=
tension seems to lie roughly along two points of view:

1. This is a programmatically driven API environment.=A0 As such, there'= ;s
little excuse to not simply send everything needed as a large configuration=
block - templates are extraneous.

2. By permitting templates, you enable much smaller transactions.=A0 You al= so
potentially allow for a stronger security model by "locking down"= stuff
outside of the template.

To offer a somewhat concrete example, consider an application for
provisioning L3VPN customers.=A0 Some minimum required configuration on a per-device basis includes:

VRF name.
A route-distinguisher.
A route-target for the VPN.
Customer PE-CE protocol and endpoint configuration.

Fully expanded, this is probably a few dozens of lines of configuration in<= br> YANG.=A0 What's interesting is that the above information is potentiall= y
generic related to that configuration, which may have per-device variance -=
potentially based upon vendor.

Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted.

> Are these templates ephemeral?=A0 That would be annoying.=A0 They are = not
> straight
> config, so a new a configuration data model is needed to manage the > templates.
> New protocol mechanisms to use templates in addition to payload data w= ill
> be needed.

All agreed.

> > You talk about the priority requirements.=A0 You should probably = mention the
> > multi-headed behavioral requirements there (as I think that the r= esolutions
> > will be tightly coupled.)
> >
> > Section 7.9 of the archtiecture document talks about several tran= sactional
> > scopes.=A0 The text you have does not seem to deal with all of th= ese.=A0 Does
> > YANG handle them all easily?
> >
>
> I would need to review this again -- I don't remember any problems= last
> time I read the arch draft.

Some of this is a matter of where this information lives.

For tie-breaking of ephemeral vs. static config, is this provisioned
per-module or per element in the module?=A0 Are there explicit lines of YAN= G
in each module for this?

For tie-breaking user priorities, NACM extensions may make sense.=A0 This particular state is effectively meta-data on the ephemeral config.

Since the epehemeral state is "highest priority wins", but there&= #39;s no
requirement that the lower priority state is kept in any fashion, how do we=
deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state?

> I am confused about some text in the draft about ephemeral config:
>
> In 2.1:
>
>=A0 =A0 The author wishes to
>=A0 =A0 prevent any action that would lead to preserving any configurat= ion
>=A0 =A0 state entered via the I2RS agent across reboots.=A0 If state ha= s to be
>=A0 =A0 restored, it should be solely by replay actions from I2RS clien= t via
>=A0 =A0 I2RS agent.
>
>
> Why does the author wish to prevent NV-storage of the I2RS data?
> What is it about the accidental reboot of the router that makes it the=
> I2RS data needed before the accidental reboot, but not after?

I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored?

Several peopl= e have asked about "copy to local config", which is
rea= lly "NV-save the I2RS state". =A0 =A0What if the operator wants t= he
state to be active until it is explicitly removed? =A0 There m= ay be significant latency
between the time the client discovers t= he agent has rebooted and
the state is re-installed.


> If the reason is because I2RS agents are simple and NV-storage is not<= br> > simple,
> then why does the agent need to support templates?

This is more a "clean slate" decision.=A0 When the device comes u= p, it has no
I2RS state.

Note that the fully ephemeral nature of I2RS still doesn't feel
fully-settled in the WG.=A0 See prior thread comments about wanting to do copy-config on it. :-)

> This section might mention that the I2RS datastore has its own
> access control model, that is not the same as the running config.
>
>=A0 =A0 2.=A0 Configuration state in the existing running datastore whe= re the
>=A0 =A0 =A0 =A0 module is "tagged ephemeral".
>
>=A0 =A0 3.=A0 Permitting existing configuration to be optionally config= ured as
>=A0 =A0 =A0 =A0 ephemeral.=A0 As an example, the NETCONF server adverti= ses in its
>=A0 =A0 =A0 =A0 <hello> message if it supports the specified YANG= module
>=A0 =A0 =A0 =A0 persistently and/or ephemerally.
>
>
>
> I thought the I2RS charter said I2RS was not altering the local config= .

Correct.

> Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)?

For point 2, it'd be identifying I2RS modules (having the ephemeral
properties) in the YANG.

Point 3 is submitted as an option based on comments at the last IETF netmod=
session where someone else indicated being able to store things ephemerally=
would potentially be useful.=A0 If this is indeed a wider use case, let'= ;s
discuss it.

> This does not really work because YANG validation may fail without som= e
> config data
> that has been tagged "do not save".=A0 If the router reboots= and the startup
> config
> does not validate, it is probably wedged. It can't really fall bac= k to a
> "known good config"
> if I2RS has forced some of the data to be omitted from the saved confi= g.

Agreed.=A0 See also the priority discussion above.

> In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral",
> then I2RS is gated on the completion of YANG 1.1 (and development of Y= ANG
> 1.1 tools).
> Are you really sure you want that?=A0 That's why a YANG extension = was
> suggested instead
> (or maybe do both).

Worth discussing during the interim.

It has been suggested to me that many of the above properties can already b= e
implemented in a proprietary manner with no language extensions.=A0 They wo= uld
simply not be either interoperable or clear about their ephemeral nature based on module contents.

So, we're looking for a balance of expeditious and correct for the long= term
maintainenace of the protocols and YANG.

-- Jeff


Andy

--001a1134497a4143630503226700-- From nobody Mon Sep 15 17:21: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 B5B051A0087 for ; Mon, 15 Sep 2014 17:21:38 -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 NdDDcQEJJWBf for ; Mon, 15 Sep 2014 17:21:36 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D731A0071 for ; Mon, 15 Sep 2014 17:21:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E7E191C0075; Mon, 15 Sep 2014 17:21:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from localhost (unknown [166.137.80.155]) by mailb2.tigertech.net (Postfix) with ESMTPA id 376AB1C0017; Mon, 15 Sep 2014 17:21:34 -0700 (PDT) Date: Mon, 15 Sep 2014 20:21:29 -0400 Message-ID: <8ou91fafu66p72ybrp3fa58q.1410826889178@email.android.com> Importance: low From: "Jmh.direct" To: andy@yumaworks.com, jhaas@pfrc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_872904145398631" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tI2EVBErfaraK4Yb8t0R8IQZ2Bs Cc: i2rs@ietf.org, jmh@joelhalpern.com Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Tue, 16 Sep 2014 00:21:38 -0000 ----_com.android.email_872904145398631 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 VGhlIFdHIGRpc2N1c3NlZCB0aGlzIGV4dGVuc2l2ZWx5LgpBbnkgZWZmb3J0IHRvIHBlcnNpc3Qg STJSUyBzdGF0ZSBpbnRyb2R1Y2VzIHNpZ25pZmljYW50IGNvbXBsZXhpdHkuIMKgSW4gcGFydGlj dWxhciwgdmVyeSBmZXcgY29uZmlncyBoYXZlIGEgbWVjaGFuaXNtIHRvIHN0b3JlIGEgcHJydmlv dXMgc3RhdGUgc28gdGhhdCB0aHIgc3lzdGVtIHdpbGwgYmVoYXZlIGNvcnJlY3RseSB3aGVuIHRo ZSBJMlJTIGFnZW50IGRlbGV0ZXMgdGhlIHN0YXRlIGl0IGhhcyBjcmVhdGVkLiDCoEFuZCB0aGVy ZSB3ZXJlIG90aGVyIHByb2JsZW1zIG5vdGVkLgpXaGltZSBzb21lIGZvbGtzIHdhbnRlZCBwZXRz aXN0YW5jZSwgYXMgYSBwYXJ0aWNpcGFudCB0aGUgY29uY2x1c2lvbiBvZiB0aGUgV0cgd2FzIHF1 aXRlIGNsZWFyLgoKWW91cnMsCkpvZWwKCgpTZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFydHBob25l IG9uIEFUJlQKCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KU3ViamVjdDogUmU6 IFtpMnJzXSBJLUQgQWN0aW9uOiBkcmFmdC1oYWFzLWkycnMtbmV0bW9kLW5ldGNvbmYtcmVxdWly ZW1lbnRzLTAwLnR4dCAKRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IApU bzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4gCkNDOiAiSm9lbCBNLiBIYWxwZXJuIiA8 am1oQGpvZWxoYWxwZXJuLmNvbT4sImkycnNAaWV0Zi5vcmciIDxpMnJzQGlldGYub3JnPiAKCgoK T24gTW9uLCBTZXAgMTUsIDIwMTQgYXQgMTE6MDEgQU0sIEplZmZyZXkgSGFhcyA8amhhYXNAcGZy Yy5vcmc+IHdyb3RlOgpPbiBGcmksIFNlcCAxMiwgMjAxNCBhdCAwNjowOTowMlBNIC0wNzAwLCBB bmR5IEJpZXJtYW4gd3JvdGU6Cj4gVGhlcmUgaXMgbm90aGluZyBpbiBZQU5HIG9yIFJFU1RDT05G IHRvIHN1cHBvcnQgaXQgKHlldCkuCj4gRm9yIHNvbWUgZmVhdHVyZXMgdGhlIEkyUlMgYWdlbnQg aXMgc3VwcG9zZWRseSBzaW1wbGUgYW5kIG1vc3RseSBzdGF0ZWxlc3MuCj4gVGhpcyB0ZW1wbGF0 ZSBzZXJ2aWNlIGRvZXMgbm90IHNlZW0gdG8gZml0IHdpdGggdGhhdCB0aGVtZS4KCkF0dGVtcHRp bmcgdG8gc3VtbWFyaXplIGRpc2N1c3Npb25zIHdpdGggdmFyaW91cyBJMlJTIFdHIHBhcnRpY2lw YW50cywgSQp0aGluayBpdCdzIGEgbWF0dGVyIG9mIHBlcnNwZWN0aXZlIC0gYW5kIHNvbWV3aGF0 IG9mIHByZWZlcmVuY2UuwqAgVGhlCnRlbnNpb24gc2VlbXMgdG8gbGllIHJvdWdobHkgYWxvbmcg dHdvIHBvaW50cyBvZiB2aWV3OgoKMS4gVGhpcyBpcyBhIHByb2dyYW1tYXRpY2FsbHkgZHJpdmVu IEFQSSBlbnZpcm9ubWVudC7CoCBBcyBzdWNoLCB0aGVyZSdzCmxpdHRsZSBleGN1c2UgdG8gbm90 IHNpbXBseSBzZW5kIGV2ZXJ5dGhpbmcgbmVlZGVkIGFzIGEgbGFyZ2UgY29uZmlndXJhdGlvbgpi bG9jayAtIHRlbXBsYXRlcyBhcmUgZXh0cmFuZW91cy4KCjIuIEJ5IHBlcm1pdHRpbmcgdGVtcGxh dGVzLCB5b3UgZW5hYmxlIG11Y2ggc21hbGxlciB0cmFuc2FjdGlvbnMuwqAgWW91IGFsc28KcG90 ZW50aWFsbHkgYWxsb3cgZm9yIGEgc3Ryb25nZXIgc2VjdXJpdHkgbW9kZWwgYnkgImxvY2tpbmcg ZG93biIgc3R1ZmYKb3V0c2lkZSBvZiB0aGUgdGVtcGxhdGUuCgpUbyBvZmZlciBhIHNvbWV3aGF0 IGNvbmNyZXRlIGV4YW1wbGUsIGNvbnNpZGVyIGFuIGFwcGxpY2F0aW9uIGZvcgpwcm92aXNpb25p bmcgTDNWUE4gY3VzdG9tZXJzLsKgIFNvbWUgbWluaW11bSByZXF1aXJlZCBjb25maWd1cmF0aW9u IG9uIGEKcGVyLWRldmljZSBiYXNpcyBpbmNsdWRlczoKClZSRiBuYW1lLgpBIHJvdXRlLWRpc3Rp bmd1aXNoZXIuCkEgcm91dGUtdGFyZ2V0IGZvciB0aGUgVlBOLgpDdXN0b21lciBQRS1DRSBwcm90 b2NvbCBhbmQgZW5kcG9pbnQgY29uZmlndXJhdGlvbi4KCkZ1bGx5IGV4cGFuZGVkLCB0aGlzIGlz IHByb2JhYmx5IGEgZmV3IGRvemVucyBvZiBsaW5lcyBvZiBjb25maWd1cmF0aW9uIGluCllBTkcu wqAgV2hhdCdzIGludGVyZXN0aW5nIGlzIHRoYXQgdGhlIGFib3ZlIGluZm9ybWF0aW9uIGlzIHBv dGVudGlhbGx5CmdlbmVyaWMgcmVsYXRlZCB0byB0aGF0IGNvbmZpZ3VyYXRpb24sIHdoaWNoIG1h eSBoYXZlIHBlci1kZXZpY2UgdmFyaWFuY2UgLQpwb3RlbnRpYWxseSBiYXNlZCB1cG9uIHZlbmRv ci4KClRob3VnaHQgYWJvdXQgcGVyaGFwcyBhbm90aGVyIHdheSwgdGhlIHRlbXBsYXRlIGlucHV0 cyBhcmUgZWZmZWN0aXZlbHkgYQptaW5pLVlBTkcgbW9kdWxlIHdpdGggbXVjaCBvZiB0aGUgYmFj ay1lbmQgYWJzdHJhY3RlZC4KCj4gQXJlIHRoZXNlIHRlbXBsYXRlcyBlcGhlbWVyYWw/wqAgVGhh dCB3b3VsZCBiZSBhbm5veWluZy7CoCBUaGV5IGFyZSBub3QKPiBzdHJhaWdodAo+IGNvbmZpZywg c28gYSBuZXcgYSBjb25maWd1cmF0aW9uIGRhdGEgbW9kZWwgaXMgbmVlZGVkIHRvIG1hbmFnZSB0 aGUKPiB0ZW1wbGF0ZXMuCj4gTmV3IHByb3RvY29sIG1lY2hhbmlzbXMgdG8gdXNlIHRlbXBsYXRl cyBpbiBhZGRpdGlvbiB0byBwYXlsb2FkIGRhdGEgd2lsbAo+IGJlIG5lZWRlZC4KCkFsbCBhZ3Jl ZWQuCgo+ID4gWW91IHRhbGsgYWJvdXQgdGhlIHByaW9yaXR5IHJlcXVpcmVtZW50cy7CoCBZb3Ug c2hvdWxkIHByb2JhYmx5IG1lbnRpb24gdGhlCj4gPiBtdWx0aS1oZWFkZWQgYmVoYXZpb3JhbCBy ZXF1aXJlbWVudHMgdGhlcmUgKGFzIEkgdGhpbmsgdGhhdCB0aGUgcmVzb2x1dGlvbnMKPiA+IHdp bGwgYmUgdGlnaHRseSBjb3VwbGVkLikKPiA+Cj4gPiBTZWN0aW9uIDcuOSBvZiB0aGUgYXJjaHRp ZWN0dXJlIGRvY3VtZW50IHRhbGtzIGFib3V0IHNldmVyYWwgdHJhbnNhY3Rpb25hbAo+ID4gc2Nv cGVzLsKgIFRoZSB0ZXh0IHlvdSBoYXZlIGRvZXMgbm90IHNlZW0gdG8gZGVhbCB3aXRoIGFsbCBv ZiB0aGVzZS7CoCBEb2VzCj4gPiBZQU5HIGhhbmRsZSB0aGVtIGFsbCBlYXNpbHk/Cj4gPgo+Cj4g SSB3b3VsZCBuZWVkIHRvIHJldmlldyB0aGlzIGFnYWluIC0tIEkgZG9uJ3QgcmVtZW1iZXIgYW55 IHByb2JsZW1zIGxhc3QKPiB0aW1lIEkgcmVhZCB0aGUgYXJjaCBkcmFmdC4KClNvbWUgb2YgdGhp cyBpcyBhIG1hdHRlciBvZiB3aGVyZSB0aGlzIGluZm9ybWF0aW9uIGxpdmVzLgoKRm9yIHRpZS1i cmVha2luZyBvZiBlcGhlbWVyYWwgdnMuIHN0YXRpYyBjb25maWcsIGlzIHRoaXMgcHJvdmlzaW9u ZWQKcGVyLW1vZHVsZSBvciBwZXIgZWxlbWVudCBpbiB0aGUgbW9kdWxlP8KgIEFyZSB0aGVyZSBl eHBsaWNpdCBsaW5lcyBvZiBZQU5HCmluIGVhY2ggbW9kdWxlIGZvciB0aGlzPwoKRm9yIHRpZS1i cmVha2luZyB1c2VyIHByaW9yaXRpZXMsIE5BQ00gZXh0ZW5zaW9ucyBtYXkgbWFrZSBzZW5zZS7C oCBUaGlzCnBhcnRpY3VsYXIgc3RhdGUgaXMgZWZmZWN0aXZlbHkgbWV0YS1kYXRhIG9uIHRoZSBl cGhlbWVyYWwgY29uZmlnLgoKU2luY2UgdGhlIGVwZWhlbWVyYWwgc3RhdGUgaXMgImhpZ2hlc3Qg cHJpb3JpdHkgd2lucyIsIGJ1dCB0aGVyZSdzIG5vCnJlcXVpcmVtZW50IHRoYXQgdGhlIGxvd2Vy IHByaW9yaXR5IHN0YXRlIGlzIGtlcHQgaW4gYW55IGZhc2hpb24sIGhvdyBkbyB3ZQpkZWFsIHdp dGggaW5jb25zaXN0ZW50IGNvbmZpZ3VyYXRpb24gdGhhdCBtYXkgcmVzdWx0IGJ5IGEgaGlnaGVy IHByaW9yaXR5CnVzZXIgZGVsZXRpbmcgcGFydCBvZiB0aGVpciBjb25maWd1cmVkIHN0YXRlPwoK PiBJIGFtIGNvbmZ1c2VkIGFib3V0IHNvbWUgdGV4dCBpbiB0aGUgZHJhZnQgYWJvdXQgZXBoZW1l cmFsIGNvbmZpZzoKPgo+IEluIDIuMToKPgo+wqAgwqAgVGhlIGF1dGhvciB3aXNoZXMgdG8KPsKg IMKgIHByZXZlbnQgYW55IGFjdGlvbiB0aGF0IHdvdWxkIGxlYWQgdG8gcHJlc2VydmluZyBhbnkg Y29uZmlndXJhdGlvbgo+wqAgwqAgc3RhdGUgZW50ZXJlZCB2aWEgdGhlIEkyUlMgYWdlbnQgYWNy b3NzIHJlYm9vdHMuwqAgSWYgc3RhdGUgaGFzIHRvIGJlCj7CoCDCoCByZXN0b3JlZCwgaXQgc2hv dWxkIGJlIHNvbGVseSBieSByZXBsYXkgYWN0aW9ucyBmcm9tIEkyUlMgY2xpZW50IHZpYQo+wqAg wqAgSTJSUyBhZ2VudC4KPgo+Cj4gV2h5IGRvZXMgdGhlIGF1dGhvciB3aXNoIHRvIHByZXZlbnQg TlYtc3RvcmFnZSBvZiB0aGUgSTJSUyBkYXRhPwo+IFdoYXQgaXMgaXQgYWJvdXQgdGhlIGFjY2lk ZW50YWwgcmVib290IG9mIHRoZSByb3V0ZXIgdGhhdCBtYWtlcyBpdCB0aGUKPiBJMlJTIGRhdGEg bmVlZGVkIGJlZm9yZSB0aGUgYWNjaWRlbnRhbCByZWJvb3QsIGJ1dCBub3QgYWZ0ZXI/CgpJIHRo aW5rIG15IHBvaW50IG9mIGNvbmZ1c2lvbiBpcyB3aHkgeW91IGJlbGlldmUgZXBoZW1lcmFsIGNv bmZpZ3VyYXRpb24Kd291bGQgZXZlciBnZXQgTlYtc3RvcmVkPwoKU2V2ZXJhbCBwZW9wbGUgaGF2 ZSBhc2tlZCBhYm91dCAiY29weSB0byBsb2NhbCBjb25maWciLCB3aGljaCBpcwpyZWFsbHkgIk5W LXNhdmUgdGhlIEkyUlMgc3RhdGUiLiDCoCDCoFdoYXQgaWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRo ZQpzdGF0ZSB0byBiZSBhY3RpdmUgdW50aWwgaXQgaXMgZXhwbGljaXRseSByZW1vdmVkPyDCoCBU aGVyZSBtYXkgYmUgc2lnbmlmaWNhbnQgbGF0ZW5jeQpiZXR3ZWVuIHRoZSB0aW1lIHRoZSBjbGll bnQgZGlzY292ZXJzIHRoZSBhZ2VudCBoYXMgcmVib290ZWQgYW5kCnRoZSBzdGF0ZSBpcyByZS1p bnN0YWxsZWQuCgoKCj4gSWYgdGhlIHJlYXNvbiBpcyBiZWNhdXNlIEkyUlMgYWdlbnRzIGFyZSBz aW1wbGUgYW5kIE5WLXN0b3JhZ2UgaXMgbm90Cj4gc2ltcGxlLAo+IHRoZW4gd2h5IGRvZXMgdGhl IGFnZW50IG5lZWQgdG8gc3VwcG9ydCB0ZW1wbGF0ZXM/CgpUaGlzIGlzIG1vcmUgYSAiY2xlYW4g c2xhdGUiIGRlY2lzaW9uLsKgIFdoZW4gdGhlIGRldmljZSBjb21lcyB1cCwgaXQgaGFzIG5vCkky UlMgc3RhdGUuCgpOb3RlIHRoYXQgdGhlIGZ1bGx5IGVwaGVtZXJhbCBuYXR1cmUgb2YgSTJSUyBz dGlsbCBkb2Vzbid0IGZlZWwKZnVsbHktc2V0dGxlZCBpbiB0aGUgV0cuwqAgU2VlIHByaW9yIHRo cmVhZCBjb21tZW50cyBhYm91dCB3YW50aW5nIHRvIGRvCmNvcHktY29uZmlnIG9uIGl0LiA6LSkK Cj4gVGhpcyBzZWN0aW9uIG1pZ2h0IG1lbnRpb24gdGhhdCB0aGUgSTJSUyBkYXRhc3RvcmUgaGFz IGl0cyBvd24KPiBhY2Nlc3MgY29udHJvbCBtb2RlbCwgdGhhdCBpcyBub3QgdGhlIHNhbWUgYXMg dGhlIHJ1bm5pbmcgY29uZmlnLgo+Cj7CoCDCoCAyLsKgIENvbmZpZ3VyYXRpb24gc3RhdGUgaW4g dGhlIGV4aXN0aW5nIHJ1bm5pbmcgZGF0YXN0b3JlIHdoZXJlIHRoZQo+wqAgwqAgwqAgwqAgbW9k dWxlIGlzICJ0YWdnZWQgZXBoZW1lcmFsIi4KPgo+wqAgwqAgMy7CoCBQZXJtaXR0aW5nIGV4aXN0 aW5nIGNvbmZpZ3VyYXRpb24gdG8gYmUgb3B0aW9uYWxseSBjb25maWd1cmVkIGFzCj7CoCDCoCDC oCDCoCBlcGhlbWVyYWwuwqAgQXMgYW4gZXhhbXBsZSwgdGhlIE5FVENPTkYgc2VydmVyIGFkdmVy dGlzZXMgaW4gaXRzCj7CoCDCoCDCoCDCoCA8aGVsbG8+IG1lc3NhZ2UgaWYgaXQgc3VwcG9ydHMg dGhlIHNwZWNpZmllZCBZQU5HIG1vZHVsZQo+wqAgwqAgwqAgwqAgcGVyc2lzdGVudGx5IGFuZC9v ciBlcGhlbWVyYWxseS4KPgo+Cj4KPiBJIHRob3VnaHQgdGhlIEkyUlMgY2hhcnRlciBzYWlkIEky UlMgd2FzIG5vdCBhbHRlcmluZyB0aGUgbG9jYWwgY29uZmlnLgoKQ29ycmVjdC4KCj4gV2h5IGRv ZXMgSTJSUyBuZWVkIHRvIGNoYW5nZSB0aGUgbWVhbmluZyBvZiBZQU5HIGNvbmZpZ3VyYXRpb24g bm9kZXMKPiBpbiBhbiBhZC1ob2MgbWFubmVyICh2aWEgdGFnZ2luZyk/CgpGb3IgcG9pbnQgMiwg aXQnZCBiZSBpZGVudGlmeWluZyBJMlJTIG1vZHVsZXMgKGhhdmluZyB0aGUgZXBoZW1lcmFsCnBy b3BlcnRpZXMpIGluIHRoZSBZQU5HLgoKUG9pbnQgMyBpcyBzdWJtaXR0ZWQgYXMgYW4gb3B0aW9u IGJhc2VkIG9uIGNvbW1lbnRzIGF0IHRoZSBsYXN0IElFVEYgbmV0bW9kCnNlc3Npb24gd2hlcmUg c29tZW9uZSBlbHNlIGluZGljYXRlZCBiZWluZyBhYmxlIHRvIHN0b3JlIHRoaW5ncyBlcGhlbWVy YWxseQp3b3VsZCBwb3RlbnRpYWxseSBiZSB1c2VmdWwuwqAgSWYgdGhpcyBpcyBpbmRlZWQgYSB3 aWRlciB1c2UgY2FzZSwgbGV0J3MKZGlzY3VzcyBpdC4KCj4gVGhpcyBkb2VzIG5vdCByZWFsbHkg d29yayBiZWNhdXNlIFlBTkcgdmFsaWRhdGlvbiBtYXkgZmFpbCB3aXRob3V0IHNvbWUKPiBjb25m aWcgZGF0YQo+IHRoYXQgaGFzIGJlZW4gdGFnZ2VkICJkbyBub3Qgc2F2ZSIuwqAgSWYgdGhlIHJv dXRlciByZWJvb3RzIGFuZCB0aGUgc3RhcnR1cAo+IGNvbmZpZwo+IGRvZXMgbm90IHZhbGlkYXRl LCBpdCBpcyBwcm9iYWJseSB3ZWRnZWQuIEl0IGNhbid0IHJlYWxseSBmYWxsIGJhY2sgdG8gYQo+ ICJrbm93biBnb29kIGNvbmZpZyIKPiBpZiBJMlJTIGhhcyBmb3JjZWQgc29tZSBvZiB0aGUgZGF0 YSB0byBiZSBvbWl0dGVkIGZyb20gdGhlIHNhdmVkIGNvbmZpZy4KCkFncmVlZC7CoCBTZWUgYWxz byB0aGUgcHJpb3JpdHkgZGlzY3Vzc2lvbiBhYm92ZS4KCj4gSW4gc2VjIDIuMS4zLCBpZiB5b3Ug d2FudCBhIG5ldyB0aGlyZCBjaG9pY2UgZm9yIHRoZSBjb25maWctc3RtdCBmb3IKPiAiZXBoZW1l cmFsIiwKPiB0aGVuIEkyUlMgaXMgZ2F0ZWQgb24gdGhlIGNvbXBsZXRpb24gb2YgWUFORyAxLjEg KGFuZCBkZXZlbG9wbWVudCBvZiBZQU5HCj4gMS4xIHRvb2xzKS4KPiBBcmUgeW91IHJlYWxseSBz dXJlIHlvdSB3YW50IHRoYXQ/wqAgVGhhdCdzIHdoeSBhIFlBTkcgZXh0ZW5zaW9uIHdhcwo+IHN1 Z2dlc3RlZCBpbnN0ZWFkCj4gKG9yIG1heWJlIGRvIGJvdGgpLgoKV29ydGggZGlzY3Vzc2luZyBk dXJpbmcgdGhlIGludGVyaW0uCgpJdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdG8gbWUgdGhhdCBtYW55 IG9mIHRoZSBhYm92ZSBwcm9wZXJ0aWVzIGNhbiBhbHJlYWR5IGJlCmltcGxlbWVudGVkIGluIGEg cHJvcHJpZXRhcnkgbWFubmVyIHdpdGggbm8gbGFuZ3VhZ2UgZXh0ZW5zaW9ucy7CoCBUaGV5IHdv dWxkCnNpbXBseSBub3QgYmUgZWl0aGVyIGludGVyb3BlcmFibGUgb3IgY2xlYXIgYWJvdXQgdGhl aXIgZXBoZW1lcmFsIG5hdHVyZQpiYXNlZCBvbiBtb2R1bGUgY29udGVudHMuCgpTbywgd2UncmUg bG9va2luZyBmb3IgYSBiYWxhbmNlIG9mIGV4cGVkaXRpb3VzIGFuZCBjb3JyZWN0IGZvciB0aGUg bG9uZyB0ZXJtCm1haW50YWluZW5hY2Ugb2YgdGhlIHByb3RvY29scyBhbmQgWUFORy4KCi0tIEpl ZmYKCgpBbmR5Cgo= ----_com.android.email_872904145398631 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5UaGUgV0cgZGlzY3Vzc2VkIHRoaXMg ZXh0ZW5zaXZlbHkuPGRpdj5BbnkgZWZmb3J0IHRvIHBlcnNpc3QgSTJSUyBzdGF0ZSBpbnRyb2R1 Y2VzIHNpZ25pZmljYW50IGNvbXBsZXhpdHkuICZuYnNwO0luIHBhcnRpY3VsYXIsIHZlcnkgZmV3 IGNvbmZpZ3MgaGF2ZSBhIG1lY2hhbmlzbSB0byBzdG9yZSBhIHBycnZpb3VzIHN0YXRlIHNvIHRo YXQgdGhyIHN5c3RlbSB3aWxsIGJlaGF2ZSBjb3JyZWN0bHkgd2hlbiB0aGUgSTJSUyBhZ2VudCBk ZWxldGVzIHRoZSBzdGF0ZSBpdCBoYXMgY3JlYXRlZC4gJm5ic3A7QW5kIHRoZXJlIHdlcmUgb3Ro ZXIgcHJvYmxlbXMgbm90ZWQuPC9kaXY+PGRpdj5XaGltZSBzb21lIGZvbGtzIHdhbnRlZCBwZXRz aXN0YW5jZSwgYXMgYSBwYXJ0aWNpcGFudCB0aGUgY29uY2x1c2lvbiBvZiB0aGUgV0cgd2FzIHF1 aXRlIGNsZWFyLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91cnMsPC9kaXY+PGRpdj5Kb2Vs PGJyPjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4NyUiPlNlbnQgZnJvbSBteSBTYW1z dW5nIHNtYXJ0cGhvbmUgb24gQVQmYW1wO1Q8L3NwYW4+IDwvZGl2Pjxicj48YnI+PGJyPi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+U3ViamVjdDogUmU6IFtpMnJzXSBJLUQg QWN0aW9uOiBkcmFmdC1oYWFzLWkycnMtbmV0bW9kLW5ldGNvbmYtcmVxdWlyZW1lbnRzLTAwLnR4 dCA8YnI+RnJvbTogQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj5U bzogSmVmZnJleSBIYWFzICZsdDtqaGFhc0BwZnJjLm9yZyZndDsgPGJyPkNDOiAiSm9lbCBNLiBI YWxwZXJuIiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssImkycnNAaWV0Zi5vcmciICZsdDtp MnJzQGlldGYub3JnJmd0OyA8YnI+PGJyPjxicj48ZGl2IGRpcj0ibHRyIj48YnI+PGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBTZXAg MTUsIDIwMTQgYXQgMTE6MDEgQU0sIEplZmZyZXkgSGFhcyA8c3BhbiBkaXI9Imx0ciI+Jmx0Ozxh IGhyZWY9Im1haWx0bzpqaGFhc0BwZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMu b3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij5PbiBGcmksIFNlcCAxMiwgMjAxNCBhdCAwNjowOTowMlBNIC0wNzAw LCBBbmR5IEJpZXJtYW4gd3JvdGU6PGJyPgomZ3Q7IFRoZXJlIGlzIG5vdGhpbmcgaW4gWUFORyBv ciBSRVNUQ09ORiB0byBzdXBwb3J0IGl0ICh5ZXQpLjxicj4KJmd0OyBGb3Igc29tZSBmZWF0dXJl cyB0aGUgSTJSUyBhZ2VudCBpcyBzdXBwb3NlZGx5IHNpbXBsZSBhbmQgbW9zdGx5IHN0YXRlbGVz cy48YnI+CiZndDsgVGhpcyB0ZW1wbGF0ZSBzZXJ2aWNlIGRvZXMgbm90IHNlZW0gdG8gZml0IHdp dGggdGhhdCB0aGVtZS48YnI+Cjxicj4KQXR0ZW1wdGluZyB0byBzdW1tYXJpemUgZGlzY3Vzc2lv bnMgd2l0aCB2YXJpb3VzIEkyUlMgV0cgcGFydGljaXBhbnRzLCBJPGJyPgp0aGluayBpdCdzIGEg bWF0dGVyIG9mIHBlcnNwZWN0aXZlIC0gYW5kIHNvbWV3aGF0IG9mIHByZWZlcmVuY2UuJm5ic3A7 IFRoZTxicj4KdGVuc2lvbiBzZWVtcyB0byBsaWUgcm91Z2hseSBhbG9uZyB0d28gcG9pbnRzIG9m IHZpZXc6PGJyPgo8YnI+CjEuIFRoaXMgaXMgYSBwcm9ncmFtbWF0aWNhbGx5IGRyaXZlbiBBUEkg ZW52aXJvbm1lbnQuJm5ic3A7IEFzIHN1Y2gsIHRoZXJlJ3M8YnI+CmxpdHRsZSBleGN1c2UgdG8g bm90IHNpbXBseSBzZW5kIGV2ZXJ5dGhpbmcgbmVlZGVkIGFzIGEgbGFyZ2UgY29uZmlndXJhdGlv bjxicj4KYmxvY2sgLSB0ZW1wbGF0ZXMgYXJlIGV4dHJhbmVvdXMuPGJyPgo8YnI+CjIuIEJ5IHBl cm1pdHRpbmcgdGVtcGxhdGVzLCB5b3UgZW5hYmxlIG11Y2ggc21hbGxlciB0cmFuc2FjdGlvbnMu Jm5ic3A7IFlvdSBhbHNvPGJyPgpwb3RlbnRpYWxseSBhbGxvdyBmb3IgYSBzdHJvbmdlciBzZWN1 cml0eSBtb2RlbCBieSAibG9ja2luZyBkb3duIiBzdHVmZjxicj4Kb3V0c2lkZSBvZiB0aGUgdGVt cGxhdGUuPGJyPgo8YnI+ClRvIG9mZmVyIGEgc29tZXdoYXQgY29uY3JldGUgZXhhbXBsZSwgY29u c2lkZXIgYW4gYXBwbGljYXRpb24gZm9yPGJyPgpwcm92aXNpb25pbmcgTDNWUE4gY3VzdG9tZXJz LiZuYnNwOyBTb21lIG1pbmltdW0gcmVxdWlyZWQgY29uZmlndXJhdGlvbiBvbiBhPGJyPgpwZXIt ZGV2aWNlIGJhc2lzIGluY2x1ZGVzOjxicj4KPGJyPgpWUkYgbmFtZS48YnI+CkEgcm91dGUtZGlz dGluZ3Vpc2hlci48YnI+CkEgcm91dGUtdGFyZ2V0IGZvciB0aGUgVlBOLjxicj4KQ3VzdG9tZXIg UEUtQ0UgcHJvdG9jb2wgYW5kIGVuZHBvaW50IGNvbmZpZ3VyYXRpb24uPGJyPgo8YnI+CkZ1bGx5 IGV4cGFuZGVkLCB0aGlzIGlzIHByb2JhYmx5IGEgZmV3IGRvemVucyBvZiBsaW5lcyBvZiBjb25m aWd1cmF0aW9uIGluPGJyPgpZQU5HLiZuYnNwOyBXaGF0J3MgaW50ZXJlc3RpbmcgaXMgdGhhdCB0 aGUgYWJvdmUgaW5mb3JtYXRpb24gaXMgcG90ZW50aWFsbHk8YnI+CmdlbmVyaWMgcmVsYXRlZCB0 byB0aGF0IGNvbmZpZ3VyYXRpb24sIHdoaWNoIG1heSBoYXZlIHBlci1kZXZpY2UgdmFyaWFuY2Ug LTxicj4KcG90ZW50aWFsbHkgYmFzZWQgdXBvbiB2ZW5kb3IuPGJyPgo8YnI+ClRob3VnaHQgYWJv dXQgcGVyaGFwcyBhbm90aGVyIHdheSwgdGhlIHRlbXBsYXRlIGlucHV0cyBhcmUgZWZmZWN0aXZl bHkgYTxicj4KbWluaS1ZQU5HIG1vZHVsZSB3aXRoIG11Y2ggb2YgdGhlIGJhY2stZW5kIGFic3Ry YWN0ZWQuPGJyPgo8YnI+CiZndDsgQXJlIHRoZXNlIHRlbXBsYXRlcyBlcGhlbWVyYWw/Jm5ic3A7 IFRoYXQgd291bGQgYmUgYW5ub3lpbmcuJm5ic3A7IFRoZXkgYXJlIG5vdDxicj4KJmd0OyBzdHJh aWdodDxicj4KJmd0OyBjb25maWcsIHNvIGEgbmV3IGEgY29uZmlndXJhdGlvbiBkYXRhIG1vZGVs IGlzIG5lZWRlZCB0byBtYW5hZ2UgdGhlPGJyPgomZ3Q7IHRlbXBsYXRlcy48YnI+CiZndDsgTmV3 IHByb3RvY29sIG1lY2hhbmlzbXMgdG8gdXNlIHRlbXBsYXRlcyBpbiBhZGRpdGlvbiB0byBwYXls b2FkIGRhdGEgd2lsbDxicj4KJmd0OyBiZSBuZWVkZWQuPGJyPgo8YnI+CkFsbCBhZ3JlZWQuPGJy Pgo8YnI+CiZndDsgJmd0OyBZb3UgdGFsayBhYm91dCB0aGUgcHJpb3JpdHkgcmVxdWlyZW1lbnRz LiZuYnNwOyBZb3Ugc2hvdWxkIHByb2JhYmx5IG1lbnRpb24gdGhlPGJyPgomZ3Q7ICZndDsgbXVs dGktaGVhZGVkIGJlaGF2aW9yYWwgcmVxdWlyZW1lbnRzIHRoZXJlIChhcyBJIHRoaW5rIHRoYXQg dGhlIHJlc29sdXRpb25zPGJyPgomZ3Q7ICZndDsgd2lsbCBiZSB0aWdodGx5IGNvdXBsZWQuKTxi cj4KJmd0OyAmZ3Q7PGJyPgomZ3Q7ICZndDsgU2VjdGlvbiA3Ljkgb2YgdGhlIGFyY2h0aWVjdHVy ZSBkb2N1bWVudCB0YWxrcyBhYm91dCBzZXZlcmFsIHRyYW5zYWN0aW9uYWw8YnI+CiZndDsgJmd0 OyBzY29wZXMuJm5ic3A7IFRoZSB0ZXh0IHlvdSBoYXZlIGRvZXMgbm90IHNlZW0gdG8gZGVhbCB3 aXRoIGFsbCBvZiB0aGVzZS4mbmJzcDsgRG9lczxicj4KJmd0OyAmZ3Q7IFlBTkcgaGFuZGxlIHRo ZW0gYWxsIGVhc2lseT88YnI+CiZndDsgJmd0Ozxicj4KJmd0Ozxicj4KJmd0OyBJIHdvdWxkIG5l ZWQgdG8gcmV2aWV3IHRoaXMgYWdhaW4gLS0gSSBkb24ndCByZW1lbWJlciBhbnkgcHJvYmxlbXMg bGFzdDxicj4KJmd0OyB0aW1lIEkgcmVhZCB0aGUgYXJjaCBkcmFmdC48YnI+Cjxicj4KU29tZSBv ZiB0aGlzIGlzIGEgbWF0dGVyIG9mIHdoZXJlIHRoaXMgaW5mb3JtYXRpb24gbGl2ZXMuPGJyPgo8 YnI+CkZvciB0aWUtYnJlYWtpbmcgb2YgZXBoZW1lcmFsIHZzLiBzdGF0aWMgY29uZmlnLCBpcyB0 aGlzIHByb3Zpc2lvbmVkPGJyPgpwZXItbW9kdWxlIG9yIHBlciBlbGVtZW50IGluIHRoZSBtb2R1 bGU/Jm5ic3A7IEFyZSB0aGVyZSBleHBsaWNpdCBsaW5lcyBvZiBZQU5HPGJyPgppbiBlYWNoIG1v ZHVsZSBmb3IgdGhpcz88YnI+Cjxicj4KRm9yIHRpZS1icmVha2luZyB1c2VyIHByaW9yaXRpZXMs IE5BQ00gZXh0ZW5zaW9ucyBtYXkgbWFrZSBzZW5zZS4mbmJzcDsgVGhpczxicj4KcGFydGljdWxh ciBzdGF0ZSBpcyBlZmZlY3RpdmVseSBtZXRhLWRhdGEgb24gdGhlIGVwaGVtZXJhbCBjb25maWcu PGJyPgo8YnI+ClNpbmNlIHRoZSBlcGVoZW1lcmFsIHN0YXRlIGlzICJoaWdoZXN0IHByaW9yaXR5 IHdpbnMiLCBidXQgdGhlcmUncyBubzxicj4KcmVxdWlyZW1lbnQgdGhhdCB0aGUgbG93ZXIgcHJp b3JpdHkgc3RhdGUgaXMga2VwdCBpbiBhbnkgZmFzaGlvbiwgaG93IGRvIHdlPGJyPgpkZWFsIHdp dGggaW5jb25zaXN0ZW50IGNvbmZpZ3VyYXRpb24gdGhhdCBtYXkgcmVzdWx0IGJ5IGEgaGlnaGVy IHByaW9yaXR5PGJyPgp1c2VyIGRlbGV0aW5nIHBhcnQgb2YgdGhlaXIgY29uZmlndXJlZCBzdGF0 ZT88YnI+Cjxicj4KJmd0OyBJIGFtIGNvbmZ1c2VkIGFib3V0IHNvbWUgdGV4dCBpbiB0aGUgZHJh ZnQgYWJvdXQgZXBoZW1lcmFsIGNvbmZpZzo8YnI+CiZndDs8YnI+CiZndDsgSW4gMi4xOjxicj4K Jmd0Ozxicj4KJmd0OyZuYnNwOyAmbmJzcDsgVGhlIGF1dGhvciB3aXNoZXMgdG88YnI+CiZndDsm bmJzcDsgJm5ic3A7IHByZXZlbnQgYW55IGFjdGlvbiB0aGF0IHdvdWxkIGxlYWQgdG8gcHJlc2Vy dmluZyBhbnkgY29uZmlndXJhdGlvbjxicj4KJmd0OyZuYnNwOyAmbmJzcDsgc3RhdGUgZW50ZXJl ZCB2aWEgdGhlIEkyUlMgYWdlbnQgYWNyb3NzIHJlYm9vdHMuJm5ic3A7IElmIHN0YXRlIGhhcyB0 byBiZTxicj4KJmd0OyZuYnNwOyAmbmJzcDsgcmVzdG9yZWQsIGl0IHNob3VsZCBiZSBzb2xlbHkg YnkgcmVwbGF5IGFjdGlvbnMgZnJvbSBJMlJTIGNsaWVudCB2aWE8YnI+CiZndDsmbmJzcDsgJm5i c3A7IEkyUlMgYWdlbnQuPGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IFdoeSBkb2VzIHRoZSBh dXRob3Igd2lzaCB0byBwcmV2ZW50IE5WLXN0b3JhZ2Ugb2YgdGhlIEkyUlMgZGF0YT88YnI+CiZn dDsgV2hhdCBpcyBpdCBhYm91dCB0aGUgYWNjaWRlbnRhbCByZWJvb3Qgb2YgdGhlIHJvdXRlciB0 aGF0IG1ha2VzIGl0IHRoZTxicj4KJmd0OyBJMlJTIGRhdGEgbmVlZGVkIGJlZm9yZSB0aGUgYWNj aWRlbnRhbCByZWJvb3QsIGJ1dCBub3QgYWZ0ZXI/PGJyPgo8YnI+CkkgdGhpbmsgbXkgcG9pbnQg b2YgY29uZnVzaW9uIGlzIHdoeSB5b3UgYmVsaWV2ZSBlcGhlbWVyYWwgY29uZmlndXJhdGlvbjxi cj4Kd291bGQgZXZlciBnZXQgTlYtc3RvcmVkPzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9k aXY+PGRpdj5TZXZlcmFsIHBlb3BsZSBoYXZlIGFza2VkIGFib3V0ICJjb3B5IHRvIGxvY2FsIGNv bmZpZyIsIHdoaWNoIGlzPC9kaXY+PGRpdj5yZWFsbHkgIk5WLXNhdmUgdGhlIEkyUlMgc3RhdGUi LiAmbmJzcDsgJm5ic3A7V2hhdCBpZiB0aGUgb3BlcmF0b3Igd2FudHMgdGhlPC9kaXY+PGRpdj5z dGF0ZSB0byBiZSBhY3RpdmUgdW50aWwgaXQgaXMgZXhwbGljaXRseSByZW1vdmVkPyAmbmJzcDsg VGhlcmUgbWF5IGJlIHNpZ25pZmljYW50IGxhdGVuY3k8L2Rpdj48ZGl2PmJldHdlZW4gdGhlIHRp bWUgdGhlIGNsaWVudCBkaXNjb3ZlcnMgdGhlIGFnZW50IGhhcyByZWJvb3RlZCBhbmQ8L2Rpdj48 ZGl2PnRoZSBzdGF0ZSBpcyByZS1pbnN0YWxsZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGJy PgomZ3Q7IElmIHRoZSByZWFzb24gaXMgYmVjYXVzZSBJMlJTIGFnZW50cyBhcmUgc2ltcGxlIGFu ZCBOVi1zdG9yYWdlIGlzIG5vdDxicj4KJmd0OyBzaW1wbGUsPGJyPgomZ3Q7IHRoZW4gd2h5IGRv ZXMgdGhlIGFnZW50IG5lZWQgdG8gc3VwcG9ydCB0ZW1wbGF0ZXM/PGJyPgo8YnI+ClRoaXMgaXMg bW9yZSBhICJjbGVhbiBzbGF0ZSIgZGVjaXNpb24uJm5ic3A7IFdoZW4gdGhlIGRldmljZSBjb21l cyB1cCwgaXQgaGFzIG5vPGJyPgpJMlJTIHN0YXRlLjxicj4KPGJyPgpOb3RlIHRoYXQgdGhlIGZ1 bGx5IGVwaGVtZXJhbCBuYXR1cmUgb2YgSTJSUyBzdGlsbCBkb2Vzbid0IGZlZWw8YnI+CmZ1bGx5 LXNldHRsZWQgaW4gdGhlIFdHLiZuYnNwOyBTZWUgcHJpb3IgdGhyZWFkIGNvbW1lbnRzIGFib3V0 IHdhbnRpbmcgdG8gZG88YnI+CmNvcHktY29uZmlnIG9uIGl0LiA6LSk8YnI+Cjxicj4KJmd0OyBU aGlzIHNlY3Rpb24gbWlnaHQgbWVudGlvbiB0aGF0IHRoZSBJMlJTIGRhdGFzdG9yZSBoYXMgaXRz IG93bjxicj4KJmd0OyBhY2Nlc3MgY29udHJvbCBtb2RlbCwgdGhhdCBpcyBub3QgdGhlIHNhbWUg YXMgdGhlIHJ1bm5pbmcgY29uZmlnLjxicj4KJmd0Ozxicj4KJmd0OyZuYnNwOyAmbmJzcDsgMi4m bmJzcDsgQ29uZmlndXJhdGlvbiBzdGF0ZSBpbiB0aGUgZXhpc3RpbmcgcnVubmluZyBkYXRhc3Rv cmUgd2hlcmUgdGhlPGJyPgomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1vZHVsZSBp cyAidGFnZ2VkIGVwaGVtZXJhbCIuPGJyPgomZ3Q7PGJyPgomZ3Q7Jm5ic3A7ICZuYnNwOyAzLiZu YnNwOyBQZXJtaXR0aW5nIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24gdG8gYmUgb3B0aW9uYWxseSBj b25maWd1cmVkIGFzPGJyPgomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVwaGVtZXJh bC4mbmJzcDsgQXMgYW4gZXhhbXBsZSwgdGhlIE5FVENPTkYgc2VydmVyIGFkdmVydGlzZXMgaW4g aXRzPGJyPgomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtoZWxsbyZndDsgbWVz c2FnZSBpZiBpdCBzdXBwb3J0cyB0aGUgc3BlY2lmaWVkIFlBTkcgbW9kdWxlPGJyPgomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBlcnNpc3RlbnRseSBhbmQvb3IgZXBoZW1lcmFsbHku PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IEkgdGhvdWdodCB0aGUgSTJSUyBj aGFydGVyIHNhaWQgSTJSUyB3YXMgbm90IGFsdGVyaW5nIHRoZSBsb2NhbCBjb25maWcuPGJyPgo8 YnI+CkNvcnJlY3QuPGJyPgo8YnI+CiZndDsgV2h5IGRvZXMgSTJSUyBuZWVkIHRvIGNoYW5nZSB0 aGUgbWVhbmluZyBvZiBZQU5HIGNvbmZpZ3VyYXRpb24gbm9kZXM8YnI+CiZndDsgaW4gYW4gYWQt aG9jIG1hbm5lciAodmlhIHRhZ2dpbmcpPzxicj4KPGJyPgpGb3IgcG9pbnQgMiwgaXQnZCBiZSBp ZGVudGlmeWluZyBJMlJTIG1vZHVsZXMgKGhhdmluZyB0aGUgZXBoZW1lcmFsPGJyPgpwcm9wZXJ0 aWVzKSBpbiB0aGUgWUFORy48YnI+Cjxicj4KUG9pbnQgMyBpcyBzdWJtaXR0ZWQgYXMgYW4gb3B0 aW9uIGJhc2VkIG9uIGNvbW1lbnRzIGF0IHRoZSBsYXN0IElFVEYgbmV0bW9kPGJyPgpzZXNzaW9u IHdoZXJlIHNvbWVvbmUgZWxzZSBpbmRpY2F0ZWQgYmVpbmcgYWJsZSB0byBzdG9yZSB0aGluZ3Mg ZXBoZW1lcmFsbHk8YnI+CndvdWxkIHBvdGVudGlhbGx5IGJlIHVzZWZ1bC4mbmJzcDsgSWYgdGhp cyBpcyBpbmRlZWQgYSB3aWRlciB1c2UgY2FzZSwgbGV0J3M8YnI+CmRpc2N1c3MgaXQuPGJyPgo8 YnI+CiZndDsgVGhpcyBkb2VzIG5vdCByZWFsbHkgd29yayBiZWNhdXNlIFlBTkcgdmFsaWRhdGlv biBtYXkgZmFpbCB3aXRob3V0IHNvbWU8YnI+CiZndDsgY29uZmlnIGRhdGE8YnI+CiZndDsgdGhh dCBoYXMgYmVlbiB0YWdnZWQgImRvIG5vdCBzYXZlIi4mbmJzcDsgSWYgdGhlIHJvdXRlciByZWJv b3RzIGFuZCB0aGUgc3RhcnR1cDxicj4KJmd0OyBjb25maWc8YnI+CiZndDsgZG9lcyBub3QgdmFs aWRhdGUsIGl0IGlzIHByb2JhYmx5IHdlZGdlZC4gSXQgY2FuJ3QgcmVhbGx5IGZhbGwgYmFjayB0 byBhPGJyPgomZ3Q7ICJrbm93biBnb29kIGNvbmZpZyI8YnI+CiZndDsgaWYgSTJSUyBoYXMgZm9y Y2VkIHNvbWUgb2YgdGhlIGRhdGEgdG8gYmUgb21pdHRlZCBmcm9tIHRoZSBzYXZlZCBjb25maWcu PGJyPgo8YnI+CkFncmVlZC4mbmJzcDsgU2VlIGFsc28gdGhlIHByaW9yaXR5IGRpc2N1c3Npb24g YWJvdmUuPGJyPgo8YnI+CiZndDsgSW4gc2VjIDIuMS4zLCBpZiB5b3Ugd2FudCBhIG5ldyB0aGly ZCBjaG9pY2UgZm9yIHRoZSBjb25maWctc3RtdCBmb3I8YnI+CiZndDsgImVwaGVtZXJhbCIsPGJy PgomZ3Q7IHRoZW4gSTJSUyBpcyBnYXRlZCBvbiB0aGUgY29tcGxldGlvbiBvZiBZQU5HIDEuMSAo YW5kIGRldmVsb3BtZW50IG9mIFlBTkc8YnI+CiZndDsgMS4xIHRvb2xzKS48YnI+CiZndDsgQXJl IHlvdSByZWFsbHkgc3VyZSB5b3Ugd2FudCB0aGF0PyZuYnNwOyBUaGF0J3Mgd2h5IGEgWUFORyBl eHRlbnNpb24gd2FzPGJyPgomZ3Q7IHN1Z2dlc3RlZCBpbnN0ZWFkPGJyPgomZ3Q7IChvciBtYXli ZSBkbyBib3RoKS48YnI+Cjxicj4KV29ydGggZGlzY3Vzc2luZyBkdXJpbmcgdGhlIGludGVyaW0u PGJyPgo8YnI+Ckl0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0byBtZSB0aGF0IG1hbnkgb2YgdGhlIGFi b3ZlIHByb3BlcnRpZXMgY2FuIGFscmVhZHkgYmU8YnI+CmltcGxlbWVudGVkIGluIGEgcHJvcHJp ZXRhcnkgbWFubmVyIHdpdGggbm8gbGFuZ3VhZ2UgZXh0ZW5zaW9ucy4mbmJzcDsgVGhleSB3b3Vs ZDxicj4Kc2ltcGx5IG5vdCBiZSBlaXRoZXIgaW50ZXJvcGVyYWJsZSBvciBjbGVhciBhYm91dCB0 aGVpciBlcGhlbWVyYWwgbmF0dXJlPGJyPgpiYXNlZCBvbiBtb2R1bGUgY29udGVudHMuPGJyPgo8 YnI+ClNvLCB3ZSdyZSBsb29raW5nIGZvciBhIGJhbGFuY2Ugb2YgZXhwZWRpdGlvdXMgYW5kIGNv cnJlY3QgZm9yIHRoZSBsb25nIHRlcm08YnI+Cm1haW50YWluZW5hY2Ugb2YgdGhlIHByb3RvY29s cyBhbmQgWUFORy48YnI+Cjxicj4KLS0gSmVmZjxicj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48 L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj5BbmR5PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48L2Rpdj48L2Rp dj4gPC9ib2R5Pg== ----_com.android.email_872904145398631-- From nobody Mon Sep 15 18:01:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20E1A00AD for ; Mon, 15 Sep 2014 18:01:22 -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_36=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 OhtyBVXAyWq9 for ; Mon, 15 Sep 2014 18:01:19 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137081A0099 for ; Mon, 15 Sep 2014 18:01:17 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so4777876qap.4 for ; Mon, 15 Sep 2014 18:01: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=tBZs/hx+DHr//Ul1gr+9mbk7ziXHci3aC4Y1X6AlTis=; b=fnJwOm7Y5IaksX/FDfcaSquaJYqQ9EwK63Mq2Iri+2B0qpTwLGpwVQnTosUN3m8BGd 5XZcAR8CgC7GmBPpKYRtp5DaQeY0ct+RkIneBAswi4iM98QNxPMGWW4//XpyQy/m3OPN 4rRy02L1Epa+tjJPakQsggU8xWFtt2kEWTRQkNn0+XeFgiNbmDzCJqFOkf2zxSzO4ZRL YB1OPp2fEefRP9z4X8o9Q3qlberGEz7G9HL1y9F0c9s47VqI6hZU2lBnvKs3eVdVeuID Fj9RzyXewGX6hsZqDgRmyLuDISR2q/0NrLVI2WoA2/KUPlm4Y2UCPlC2a8rJSp9THNQs qeRw== X-Gm-Message-State: ALoCoQksbiTi/RHx7gYzZ8dPlgJXcHcOKPmx1inLgAxDfM4NyNPdNEW1YlBevcT6Z+WB3FDkEPPc MIME-Version: 1.0 X-Received: by 10.140.98.102 with SMTP id n93mr35804707qge.83.1410829276855; Mon, 15 Sep 2014 18:01:16 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 15 Sep 2014 18:01:16 -0700 (PDT) In-Reply-To: <8ou91fafu66p72ybrp3fa58q.1410826889178@email.android.com> References: <8ou91fafu66p72ybrp3fa58q.1410826889178@email.android.com> Date: Mon, 15 Sep 2014 18:01:16 -0700 Message-ID: From: Andy Bierman To: "Jmh.direct" Content-Type: multipart/alternative; boundary=001a113aae0ae326540503244933 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EHC6MCVN0ql2RX5u38T_XOFEv4k Cc: Jeffrey Haas , "i2rs@ietf.org" , Joel Halpern Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Tue, 16 Sep 2014 01:01:23 -0000 --001a113aae0ae326540503244933 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct wrote: > The WG discussed this extensively. > Any effort to persist I2RS state introduces significant complexity. In > particular, very few configs have a mechanism to store a prrvious state so > that thr system will behave correctly when the I2RS agent deletes the state > it has created. And there were other problems noted. > Whime some folks wanted petsistance, as a participant the conclusion of > the WG was quite clear. > > I am OK with leaving out persistence. If glitches cause problems, vendors will extend the standard with proprietary attempts to fix them. There is complexity either way. > Yours, > Joel > > Andy > > Sent from my Samsung smartphone on AT&T > > > > -------- Original message -------- > Subject: Re: [i2rs] I-D Action: > draft-haas-i2rs-netmod-netconf-requirements-00.txt > From: Andy Bierman > To: Jeffrey Haas > CC: "Joel M. Halpern" ,"i2rs@ietf.org" > > > > > > On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas wrote: > >> On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: >> > There is nothing in YANG or RESTCONF to support it (yet). >> > For some features the I2RS agent is supposedly simple and mostly >> stateless. >> > This template service does not seem to fit with that theme. >> >> Attempting to summarize discussions with various I2RS WG participants, I >> think it's a matter of perspective - and somewhat of preference. The >> tension seems to lie roughly along two points of view: >> >> 1. This is a programmatically driven API environment. As such, there's >> little excuse to not simply send everything needed as a large >> configuration >> block - templates are extraneous. >> >> 2. By permitting templates, you enable much smaller transactions. You >> also >> potentially allow for a stronger security model by "locking down" stuff >> outside of the template. >> >> To offer a somewhat concrete example, consider an application for >> provisioning L3VPN customers. Some minimum required configuration on a >> per-device basis includes: >> >> VRF name. >> A route-distinguisher. >> A route-target for the VPN. >> Customer PE-CE protocol and endpoint configuration. >> >> Fully expanded, this is probably a few dozens of lines of configuration in >> YANG. What's interesting is that the above information is potentially >> generic related to that configuration, which may have per-device variance >> - >> potentially based upon vendor. >> >> Thought about perhaps another way, the template inputs are effectively a >> mini-YANG module with much of the back-end abstracted. >> >> > Are these templates ephemeral? That would be annoying. They are not >> > straight >> > config, so a new a configuration data model is needed to manage the >> > templates. >> > New protocol mechanisms to use templates in addition to payload data >> will >> > be needed. >> >> All agreed. >> >> > > You talk about the priority requirements. You should probably >> mention the >> > > multi-headed behavioral requirements there (as I think that the >> resolutions >> > > will be tightly coupled.) >> > > >> > > Section 7.9 of the archtiecture document talks about several >> transactional >> > > scopes. The text you have does not seem to deal with all of these. >> Does >> > > YANG handle them all easily? >> > > >> > >> > I would need to review this again -- I don't remember any problems last >> > time I read the arch draft. >> >> Some of this is a matter of where this information lives. >> >> For tie-breaking of ephemeral vs. static config, is this provisioned >> per-module or per element in the module? Are there explicit lines of YANG >> in each module for this? >> >> For tie-breaking user priorities, NACM extensions may make sense. This >> particular state is effectively meta-data on the ephemeral config. >> >> Since the epehemeral state is "highest priority wins", but there's no >> requirement that the lower priority state is kept in any fashion, how do >> we >> deal with inconsistent configuration that may result by a higher priority >> user deleting part of their configured state? >> >> > I am confused about some text in the draft about ephemeral config: >> > >> > In 2.1: >> > >> > The author wishes to >> > prevent any action that would lead to preserving any configuration >> > state entered via the I2RS agent across reboots. If state has to be >> > restored, it should be solely by replay actions from I2RS client via >> > I2RS agent. >> > >> > >> > Why does the author wish to prevent NV-storage of the I2RS data? >> > What is it about the accidental reboot of the router that makes it the >> > I2RS data needed before the accidental reboot, but not after? >> >> I think my point of confusion is why you believe ephemeral configuration >> would ever get NV-stored? >> > > Several people have asked about "copy to local config", which is > really "NV-save the I2RS state". What if the operator wants the > state to be active until it is explicitly removed? There may be > significant latency > between the time the client discovers the agent has rebooted and > the state is re-installed. > > > >> > If the reason is because I2RS agents are simple and NV-storage is not >> > simple, >> > then why does the agent need to support templates? >> >> This is more a "clean slate" decision. When the device comes up, it has >> no >> I2RS state. >> >> Note that the fully ephemeral nature of I2RS still doesn't feel >> fully-settled in the WG. See prior thread comments about wanting to do >> copy-config on it. :-) >> >> > This section might mention that the I2RS datastore has its own >> > access control model, that is not the same as the running config. >> > >> > 2. Configuration state in the existing running datastore where the >> > module is "tagged ephemeral". >> > >> > 3. Permitting existing configuration to be optionally configured as >> > ephemeral. As an example, the NETCONF server advertises in its >> > message if it supports the specified YANG module >> > persistently and/or ephemerally. >> > >> > >> > >> > I thought the I2RS charter said I2RS was not altering the local config. >> >> Correct. >> >> > Why does I2RS need to change the meaning of YANG configuration nodes >> > in an ad-hoc manner (via tagging)? >> >> For point 2, it'd be identifying I2RS modules (having the ephemeral >> properties) in the YANG. >> >> Point 3 is submitted as an option based on comments at the last IETF >> netmod >> session where someone else indicated being able to store things >> ephemerally >> would potentially be useful. If this is indeed a wider use case, let's >> discuss it. >> >> > This does not really work because YANG validation may fail without some >> > config data >> > that has been tagged "do not save". If the router reboots and the >> startup >> > config >> > does not validate, it is probably wedged. It can't really fall back to a >> > "known good config" >> > if I2RS has forced some of the data to be omitted from the saved config. >> >> Agreed. See also the priority discussion above. >> >> > In sec 2.1.3, if you want a new third choice for the config-stmt for >> > "ephemeral", >> > then I2RS is gated on the completion of YANG 1.1 (and development of >> YANG >> > 1.1 tools). >> > Are you really sure you want that? That's why a YANG extension was >> > suggested instead >> > (or maybe do both). >> >> Worth discussing during the interim. >> >> It has been suggested to me that many of the above properties can already >> be >> implemented in a proprietary manner with no language extensions. They >> would >> simply not be either interoperable or clear about their ephemeral nature >> based on module contents. >> >> So, we're looking for a balance of expeditious and correct for the long >> term >> maintainenace of the protocols and YANG. >> >> -- Jeff >> > > > Andy > > --001a113aae0ae326540503244933 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct <jmh.direct@joelh= alpern.com> wrote:
The= WG discussed this extensively.
Any effort to persist I2RS state introd= uces significant complexity. =A0In particular, very few configs have a mech= anism to store a prrvious state so that thr system will behave correctly wh= en the I2RS agent deletes the state it has created. =A0And there were other= problems noted.
Whime some folks wanted petsistance, as a partic= ipant the conclusion of the WG was quite clear.

<= /blockquote>

I am OK with leaving out persistence. =A0If= glitches cause problems, vendors
will extend the standard with p= roprietary attempts to fix them.
There is complexity either way.<= /div>

=A0
Yours,
Joel

Andy
=A0

Sent from my Samsung smartphone on AT&a= mp;T



-------- Original message --------
Subject= : Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt=
From: Andy Bierman <andy@yumaworks.com>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: "= Joel M. Halpern" <jmh@joelhalpern.com>,"i2rs@ietf.org" <i2rs@ietf.org>



On Mon, Sep 15,= 2014 at 11:01 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy B= ierman wrote:
> There is nothing in YANG or RESTCONF to support it (yet).
> For some features the I2RS agent is supposedly simple and mostly state= less.
> This template service does not seem to fit with that theme.

Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference.=A0 The=
tension seems to lie roughly along two points of view:

1. This is a programmatically driven API environment.=A0 As such, there'= ;s
little excuse to not simply send everything needed as a large configuration=
block - templates are extraneous.

2. By permitting templates, you enable much smaller transactions.=A0 You al= so
potentially allow for a stronger security model by "locking down"= stuff
outside of the template.

To offer a somewhat concrete example, consider an application for
provisioning L3VPN customers.=A0 Some minimum required configuration on a per-device basis includes:

VRF name.
A route-distinguisher.
A route-target for the VPN.
Customer PE-CE protocol and endpoint configuration.

Fully expanded, this is probably a few dozens of lines of configuration in<= br> YANG.=A0 What's interesting is that the above information is potentiall= y
generic related to that configuration, which may have per-device variance -=
potentially based upon vendor.

Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted.

> Are these templates ephemeral?=A0 That would be annoying.=A0 They are = not
> straight
> config, so a new a configuration data model is needed to manage the > templates.
> New protocol mechanisms to use templates in addition to payload data w= ill
> be needed.

All agreed.

> > You talk about the priority requirements.=A0 You should probably = mention the
> > multi-headed behavioral requirements there (as I think that the r= esolutions
> > will be tightly coupled.)
> >
> > Section 7.9 of the archtiecture document talks about several tran= sactional
> > scopes.=A0 The text you have does not seem to deal with all of th= ese.=A0 Does
> > YANG handle them all easily?
> >
>
> I would need to review this again -- I don't remember any problems= last
> time I read the arch draft.

Some of this is a matter of where this information lives.

For tie-breaking of ephemeral vs. static config, is this provisioned
per-module or per element in the module?=A0 Are there explicit lines of YAN= G
in each module for this?

For tie-breaking user priorities, NACM extensions may make sense.=A0 This particular state is effectively meta-data on the ephemeral config.

Since the epehemeral state is "highest priority wins", but there&= #39;s no
requirement that the lower priority state is kept in any fashion, how do we=
deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state?

> I am confused about some text in the draft about ephemeral config:
>
> In 2.1:
>
>=A0 =A0 The author wishes to
>=A0 =A0 prevent any action that would lead to preserving any configurat= ion
>=A0 =A0 state entered via the I2RS agent across reboots.=A0 If state ha= s to be
>=A0 =A0 restored, it should be solely by replay actions from I2RS clien= t via
>=A0 =A0 I2RS agent.
>
>
> Why does the author wish to prevent NV-storage of the I2RS data?
> What is it about the accidental reboot of the router that makes it the=
> I2RS data needed before the accidental reboot, but not after?

I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored?

Several peopl= e have asked about "copy to local config", which is
rea= lly "NV-save the I2RS state". =A0 =A0What if the operator wants t= he
state to be active until it is explicitly removed? =A0 There m= ay be significant latency
between the time the client discovers t= he agent has rebooted and
the state is re-installed.


> If the reason is because I2RS agents are simple and NV-storage is not<= br> > simple,
> then why does the agent need to support templates?

This is more a "clean slate" decision.=A0 When the device comes u= p, it has no
I2RS state.

Note that the fully ephemeral nature of I2RS still doesn't feel
fully-settled in the WG.=A0 See prior thread comments about wanting to do copy-config on it. :-)

> This section might mention that the I2RS datastore has its own
> access control model, that is not the same as the running config.
>
>=A0 =A0 2.=A0 Configuration state in the existing running datastore whe= re the
>=A0 =A0 =A0 =A0 module is "tagged ephemeral".
>
>=A0 =A0 3.=A0 Permitting existing configuration to be optionally config= ured as
>=A0 =A0 =A0 =A0 ephemeral.=A0 As an example, the NETCONF server adverti= ses in its
>=A0 =A0 =A0 =A0 <hello> message if it supports the specified YANG= module
>=A0 =A0 =A0 =A0 persistently and/or ephemerally.
>
>
>
> I thought the I2RS charter said I2RS was not altering the local config= .

Correct.

> Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)?

For point 2, it'd be identifying I2RS modules (having the ephemeral
properties) in the YANG.

Point 3 is submitted as an option based on comments at the last IETF netmod=
session where someone else indicated being able to store things ephemerally=
would potentially be useful.=A0 If this is indeed a wider use case, let'= ;s
discuss it.

> This does not really work because YANG validation may fail without som= e
> config data
> that has been tagged "do not save".=A0 If the router reboots= and the startup
> config
> does not validate, it is probably wedged. It can't really fall bac= k to a
> "known good config"
> if I2RS has forced some of the data to be omitted from the saved confi= g.

Agreed.=A0 See also the priority discussion above.

> In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral",
> then I2RS is gated on the completion of YANG 1.1 (and development of Y= ANG
> 1.1 tools).
> Are you really sure you want that?=A0 That's why a YANG extension = was
> suggested instead
> (or maybe do both).

Worth discussing during the interim.

It has been suggested to me that many of the above properties can already b= e
implemented in a proprietary manner with no language extensions.=A0 They wo= uld
simply not be either interoperable or clear about their ephemeral nature based on module contents.

So, we're looking for a balance of expeditious and correct for the long= term
maintainenace of the protocols and YANG.

-- Jeff


Andy


--001a113aae0ae326540503244933-- From nobody Tue Sep 16 02:40: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 37B2B1A020A; Tue, 16 Sep 2014 02:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 XphqotvWzSwE; Tue, 16 Sep 2014 02:40:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D76C1A01C3; Tue, 16 Sep 2014 02:40:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B69EB72D; Tue, 16 Sep 2014 11:40:10 +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 A9-L0JwcBGgg; Tue, 16 Sep 2014 11:40:03 +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; Tue, 16 Sep 2014 11:40:10 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0028520035; Tue, 16 Sep 2014 11:40:10 +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 j22Q_vi4bvbT; Tue, 16 Sep 2014 11:40:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9A5020036; Tue, 16 Sep 2014 11:40:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E2EEE2E65EB7; Tue, 16 Sep 2014 11:40:07 +0200 (CEST) Date: Tue, 16 Sep 2014 11:40:07 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140916094007.GB14437@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org References: <20140912210913.GA10692@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140912210913.GA10692@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1BSexGFsSvhf2T4H9IKw7UVEkIo Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) 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: Tue, 16 Sep 2014 09:40:15 -0000 On Fri, Sep 12, 2014 at 05:09:13PM -0400, Jeffrey Haas wrote: > With some help from Kent, Dean and Alia, I've put together a rough first > draft of requirements I2RS has on netmod/netconf. It should be strongly > noted that due to a confluence of a lot of bad timing (travel, vacation, > etc.) I didn't have time to more broadly reach out and involve interested > parties. > [...] > > Comments are appreciated. Flames are not unexpected. > Thanks Jeff for putting this together. Concerning section 2.1.1, I am not sure I agree with: The SSH transport does not mandate authentication be done; it is an optional feature. RFC 6242 says: The identity of the SSH server MUST be verified and authenticated by the SSH client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the SSH server. The identity of the SSH client MUST also be verified and authenticated by the SSH server according to local policy to ensure that the incoming SSH client request is legitimate before any configuration or state data is sent to or received from the SSH client. Neither side should establish a NETCONF over SSH connection with an unknown, unexpected, or incorrect identity on the opposite side. I also think that NC over TLS requires that both sides authenticate and verify the certificates. I think as far as NETCONF is concerned, all transports do actually mutual authentication. Perhaps there is confusion here with RESTCONF where the current wording may be read as authentication is optional. But then, this is not past the IESG yet. ;-) /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 Tue Sep 16 07:51: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 1204B1A0367; Tue, 16 Sep 2014 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, 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 b0rZiAq6Q7ZA; Tue, 16 Sep 2014 07:51:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 090E01A0515; Tue, 16 Sep 2014 07:51:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9D525C25D; Tue, 16 Sep 2014 10:51:20 -0400 (EDT) Date: Tue, 16 Sep 2014 10:51:20 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Message-ID: <20140916145120.GE28454@pfrc> References: <20140912210913.GA10692@pfrc> <20140916094007.GB14437@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140916094007.GB14437@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qdQjXkn_aTPyB7LePKCer89x6eA Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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, 16 Sep 2014 14:51:25 -0000 Juergen, On Tue, Sep 16, 2014 at 11:40:07AM +0200, Juergen Schoenwaelder wrote: > Thanks Jeff for putting this together. Concerning section 2.1.1, I am > not sure I agree with: > > The SSH transport does not mandate authentication be done; it is an > optional feature. > > RFC 6242 says: And that was one of the details I missed. As I've been doing my protocol homework, I missed the existence of this RFC. [...] > I also think that NC over TLS requires that both sides authenticate > and verify the certificates. I think as far as NETCONF is concerned, > all transports do actually mutual authentication. > > Perhaps there is confusion here with RESTCONF where the current > wording may be read as authentication is optional. But then, this > is not past the IESG yet. ;-) So, two obvious options for the document I wrote: - Presume restconf will address this, leave it in the requirements until it does. - Consider it pure noise, remove. But I think the major concern has been addressed. Thanks! (And in fairness to Kent, he did think it was covered as well, but we hadn't gotten to the level of RFC citations in our discussion prior to publishing this draft.) -- Jeff From nobody Wed Sep 17 04:33: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 63CC21A01D2 for ; Wed, 17 Sep 2014 04:33:55 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, 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 YydEEjPJUatU for ; Wed, 17 Sep 2014 04:33:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::707]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679971A00F5 for ; Wed, 17 Sep 2014 04:33:52 -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.1029.13; Wed, 17 Sep 2014 11:33:28 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.154]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.146]) with mapi id 15.00.1029.000; Wed, 17 Sep 2014 11:33:28 +0000 From: Dean Bogdanovic To: Andy Bierman Thread-Topic: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt Thread-Index: AQHP0UQoz1QKEODXfUSY5MiIs3Y26JwC8OYAgAJC6IA= Date: Wed, 17 Sep 2014 11:33:28 +0000 Message-ID: References: <8ou91fafu66p72ybrp3fa58q.1410826889178@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(51704005)(199003)(189002)(377454003)(51444003)(90102001)(19580405001)(101416001)(33656002)(92726001)(4396001)(77096002)(230783001)(85852003)(31966008)(106356001)(83072002)(83716003)(15975445006)(107046002)(106116001)(21056001)(89996001)(82746002)(50986999)(86362001)(104166001)(36756003)(64706001)(81342003)(77982003)(77156001)(16236675004)(97736003)(93916002)(83322001)(88136002)(80022003)(110136001)(105586002)(95666004)(50226001)(19580395003)(99286002)(81542003)(2656002)(79102003)(57306001)(74502003)(66066001)(46102003)(99396002)(76176999)(87286001)(20776003)(62966002)(76482002)(92566001)(74662003)(85306004)(87936001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_E9A2760B17804EC18EF52A6D82919FD9junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-D_S_vIQkf4HezL8YurGVLTm5vA Cc: Jeffrey Haas , "Jmh.direct" , Joel Halpern , "i2rs@ietf.org" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Wed, 17 Sep 2014 11:33:55 -0000 --_000_E9A2760B17804EC18EF52A6D82919FD9junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andy, Take an broadband edge scenario. BRAS/BNG has 10s of thousand of subscribe= rs. Through I2RS agent several subscriber related configurations have been = added. Box reboots and all subscribers are gone. The subscriber related con= figuration has to be removed, as nobody knows if the subscriber incoming ba= ck and if it will get the same router properties. IMO, use I2RS to change transient properties on the device. Dean On Sep 15, 2014, at 9:01 PM, Andy Bierman > wrote: On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct > wrote: The WG discussed this extensively. Any effort to persist I2RS state introduces significant complexity. In par= ticular, very few configs have a mechanism to store a prrvious state so tha= t thr system will behave correctly when the I2RS agent deletes the state it= has created. And there were other problems noted. Whime some folks wanted petsistance, as a participant the conclusion of the= WG was quite clear. I am OK with leaving out persistence. If glitches cause problems, vendors will extend the standard with proprietary attempts to fix them. There is complexity either way. Yours, Joel Andy Sent from my Samsung smartphone on AT&T -------- Original message -------- Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt From: Andy Bierman > To: Jeffrey Haas > CC: "Joel M. Halpern" >,"i2= rs@ietf.org" > On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas > wrote: On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > There is nothing in YANG or RESTCONF to support it (yet). > For some features the I2RS agent is supposedly simple and mostly stateles= s. > This template service does not seem to fit with that theme. Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference. The tension seems to lie roughly along two points of view: 1. This is a programmatically driven API environment. As such, there's little excuse to not simply send everything needed as a large configuration block - templates are extraneous. 2. By permitting templates, you enable much smaller transactions. You also potentially allow for a stronger security model by "locking down" stuff outside of the template. To offer a somewhat concrete example, consider an application for provisioning L3VPN customers. Some minimum required configuration on a per-device basis includes: VRF name. A route-distinguisher. A route-target for the VPN. Customer PE-CE protocol and endpoint configuration. Fully expanded, this is probably a few dozens of lines of configuration in YANG. What's interesting is that the above information is potentially generic related to that configuration, which may have per-device variance - potentially based upon vendor. Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted. > Are these templates ephemeral? That would be annoying. They are not > straight > config, so a new a configuration data model is needed to manage the > templates. > New protocol mechanisms to use templates in addition to payload data will > be needed. All agreed. > > You talk about the priority requirements. You should probably mention = the > > multi-headed behavioral requirements there (as I think that the resolut= ions > > will be tightly coupled.) > > > > Section 7.9 of the archtiecture document talks about several transactio= nal > > scopes. The text you have does not seem to deal with all of these. Do= es > > YANG handle them all easily? > > > > I would need to review this again -- I don't remember any problems last > time I read the arch draft. Some of this is a matter of where this information lives. For tie-breaking of ephemeral vs. static config, is this provisioned per-module or per element in the module? Are there explicit lines of YANG in each module for this? For tie-breaking user priorities, NACM extensions may make sense. This particular state is effectively meta-data on the ephemeral config. Since the epehemeral state is "highest priority wins", but there's no requirement that the lower priority state is kept in any fashion, how do we deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state? > I am confused about some text in the draft about ephemeral config: > > In 2.1: > > The author wishes to > prevent any action that would lead to preserving any configuration > state entered via the I2RS agent across reboots. If state has to be > restored, it should be solely by replay actions from I2RS client via > I2RS agent. > > > Why does the author wish to prevent NV-storage of the I2RS data? > What is it about the accidental reboot of the router that makes it the > I2RS data needed before the accidental reboot, but not after? I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored? Several people have asked about "copy to local config", which is really "NV-save the I2RS state". What if the operator wants the state to be active until it is explicitly removed? There may be significa= nt latency between the time the client discovers the agent has rebooted and the state is re-installed. > If the reason is because I2RS agents are simple and NV-storage is not > simple, > then why does the agent need to support templates? This is more a "clean slate" decision. When the device comes up, it has no I2RS state. Note that the fully ephemeral nature of I2RS still doesn't feel fully-settled in the WG. See prior thread comments about wanting to do copy-config on it. :-) > This section might mention that the I2RS datastore has its own > access control model, that is not the same as the running config. > > 2. Configuration state in the existing running datastore where the > module is "tagged ephemeral". > > 3. Permitting existing configuration to be optionally configured as > ephemeral. As an example, the NETCONF server advertises in its > message if it supports the specified YANG module > persistently and/or ephemerally. > > > > I thought the I2RS charter said I2RS was not altering the local config. Correct. > Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)? For point 2, it'd be identifying I2RS modules (having the ephemeral properties) in the YANG. Point 3 is submitted as an option based on comments at the last IETF netmod session where someone else indicated being able to store things ephemerally would potentially be useful. If this is indeed a wider use case, let's discuss it. > This does not really work because YANG validation may fail without some > config data > that has been tagged "do not save". If the router reboots and the startu= p > config > does not validate, it is probably wedged. It can't really fall back to a > "known good config" > if I2RS has forced some of the data to be omitted from the saved config. Agreed. See also the priority discussion above. > In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral", > then I2RS is gated on the completion of YANG 1.1 (and development of YANG > 1.1 tools). > Are you really sure you want that? That's why a YANG extension was > suggested instead > (or maybe do both). Worth discussing during the interim. It has been suggested to me that many of the above properties can already b= e implemented in a proprietary manner with no language extensions. They woul= d simply not be either interoperable or clear about their ephemeral nature based on module contents. So, we're looking for a balance of expeditious and correct for the long ter= m maintainenace of the protocols and YANG. -- Jeff Andy _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_E9A2760B17804EC18EF52A6D82919FD9junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <17CB71FC7288894D80E3D3B5F7418912@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Andy,

Take an broadband edge scenario.  BRAS/BNG has 10s of thousand of= subscribers. Through I2RS agent several subscriber related configurations = have been added. Box reboots and all subscribers are gone. The subscriber r= elated configuration has to be removed, as nobody knows if the subscriber incoming back and if it will get the sam= e router properties. 
IMO, use I2RS to change transient properties on the device. 

Dean

On Sep 15, 2014, at 9:01 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct <jmh.dir= ect@joelhalpern.com> wrote:
The WG discussed this extensively.
Any effort to persist I2RS state introduces significant complexity. &n= bsp;In particular, very few configs have a mechanism to store a prrvious st= ate so that thr system will behave correctly when the I2RS agent deletes th= e state it has created.  And there were other problems noted.
Whime some folks wanted petsistance, as a participant the conclusion o= f the WG was quite clear.


I am OK with leaving out persistence.  If glitches cause problems= , vendors
will extend the standard with proprietary attempts to fix them.
There is complexity either way.

 
Yours,
Joel


Andy
 

Sent from my Samsung smartphone on AT&T



-------- Original message --------
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt
From: Andy Bierman <andy@yumaworks.com>
To: Jeffrey Haas <jh= aas@pfrc.org>
CC: "Joel M. Halpern" <jmh@joelhalpern.com>,"i2rs@ietf.org" <i2rs@ietf.org>




On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <= span dir=3D"ltr"> <jhaas@pfrc.org&= gt; wrote:
On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote:
> There is nothing in YANG or RESTCONF to support it (yet).
> For some features the I2RS agent is supposedly simple and mostly state= less.
> This template service does not seem to fit with that theme.

Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference.  The<= br> tension seems to lie roughly along two points of view:

1. This is a programmatically driven API environment.  As such, there'= s
little excuse to not simply send everything needed as a large configuration=
block - templates are extraneous.

2. By permitting templates, you enable much smaller transactions.  You= also
potentially allow for a stronger security model by "locking down"= stuff
outside of the template.

To offer a somewhat concrete example, consider an application for
provisioning L3VPN customers.  Some minimum required configuration on = a
per-device basis includes:

VRF name.
A route-distinguisher.
A route-target for the VPN.
Customer PE-CE protocol and endpoint configuration.

Fully expanded, this is probably a few dozens of lines of configuration in<= br> YANG.  What's interesting is that the above information is potentially=
generic related to that configuration, which may have per-device variance -=
potentially based upon vendor.

Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted.

> Are these templates ephemeral?  That would be annoying.  The= y are not
> straight
> config, so a new a configuration data model is needed to manage the > templates.
> New protocol mechanisms to use templates in addition to payload data w= ill
> be needed.

All agreed.

> > You talk about the priority requirements.  You should probab= ly mention the
> > multi-headed behavioral requirements there (as I think that the r= esolutions
> > will be tightly coupled.)
> >
> > Section 7.9 of the archtiecture document talks about several tran= sactional
> > scopes.  The text you have does not seem to deal with all of= these.  Does
> > YANG handle them all easily?
> >
>
> I would need to review this again -- I don't remember any problems las= t
> time I read the arch draft.

Some of this is a matter of where this information lives.

For tie-breaking of ephemeral vs. static config, is this provisioned
per-module or per element in the module?  Are there explicit lines of = YANG
in each module for this?

For tie-breaking user priorities, NACM extensions may make sense.  Thi= s
particular state is effectively meta-data on the ephemeral config.

Since the epehemeral state is "highest priority wins", but there'= s no
requirement that the lower priority state is kept in any fashion, how do we=
deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state?

> I am confused about some text in the draft about ephemeral config:
>
> In 2.1:
>
>    The author wishes to
>    prevent any action that would lead to preserving any conf= iguration
>    state entered via the I2RS agent across reboots.  If= state has to be
>    restored, it should be solely by replay actions from I2RS= client via
>    I2RS agent.
>
>
> Why does the author wish to prevent NV-storage of the I2RS data?
> What is it about the accidental reboot of the router that makes it the=
> I2RS data needed before the accidental reboot, but not after?

I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored?

Several people have asked about "copy to local config", whic= h is
really "NV-save the I2RS state".    What if the op= erator wants the
state to be active until it is explicitly removed?   There may be= significant latency
between the time the client discovers the agent has rebooted and
the state is re-installed.



> If the reason is because I2RS agents are simple and NV-storage is not<= br> > simple,
> then why does the agent need to support templates?

This is more a "clean slate" decision.  When the device come= s up, it has no
I2RS state.

Note that the fully ephemeral nature of I2RS still doesn't feel
fully-settled in the WG.  See prior thread comments about wanting to d= o
copy-config on it. :-)

> This section might mention that the I2RS datastore has its own
> access control model, that is not the same as the running config.
>
>    2.  Configuration state in the existing running data= store where the
>        module is "tagged ephemeral".
>
>    3.  Permitting existing configuration to be optional= ly configured as
>        ephemeral.  As an example, the NETCONF= server advertises in its
>        <hello> message if it supports the sp= ecified YANG module
>        persistently and/or ephemerally.
>
>
>
> I thought the I2RS charter said I2RS was not altering the local config= .

Correct.

> Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)?

For point 2, it'd be identifying I2RS modules (having the ephemeral
properties) in the YANG.

Point 3 is submitted as an option based on comments at the last IETF netmod=
session where someone else indicated being able to store things ephemerally=
would potentially be useful.  If this is indeed a wider use case, let'= s
discuss it.

> This does not really work because YANG validation may fail without som= e
> config data
> that has been tagged "do not save".  If the router rebo= ots and the startup
> config
> does not validate, it is probably wedged. It can't really fall back to= a
> "known good config"
> if I2RS has forced some of the data to be omitted from the saved confi= g.

Agreed.  See also the priority discussion above.

> In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral",
> then I2RS is gated on the completion of YANG 1.1 (and development of Y= ANG
> 1.1 tools).
> Are you really sure you want that?  That's why a YANG extension w= as
> suggested instead
> (or maybe do both).

Worth discussing during the interim.

It has been suggested to me that many of the above properties can already b= e
implemented in a proprietary manner with no language extensions.  They= would
simply not be either interoperable or clear about their ephemeral nature based on module contents.

So, we're looking for a balance of expeditious and correct for the long ter= m
maintainenace of the protocols and YANG.

-- Jeff


Andy


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

--_000_E9A2760B17804EC18EF52A6D82919FD9junipernet_-- From nobody Wed Sep 17 04:51:04 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 040941A011B for ; Wed, 17 Sep 2014 04:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.251 X-Spam-Level: X-Spam-Status: No, score=-5.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 IOQB6QlXxeI4 for ; Wed, 17 Sep 2014 04:50:46 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55601A011D for ; Wed, 17 Sep 2014 04:50:45 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 59579145.0.2959509.00-2144.8247669.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 17 Sep 2014 11:50:46 +0000 (UTC) X-MXL-Hash: 541975967ce4c0e0-317b789a525654f3d77aad8f4fa6dbf282bf4703 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8HBoiFX024614; Wed, 17 Sep 2014 07:50:44 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8HBoc6x024555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2014 07:50:41 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 17 Sep 2014 11:50:20 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.28]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 07:50:20 -0400 From: "UTTARO, JAMES" To: "'Dean Bogdanovic'" , "'Andy Bierman'" Thread-Topic: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt Thread-Index: AQHP0UQoqsRlfvmajUO3Spkk9N3ADJwC8OYAgAJC6ICAAAVz0A== Date: Wed, 17 Sep 2014 11:50:20 +0000 Message-ID: References: <8ou91fafu66p72ybrp3fa58q.1410826889178@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.129.222] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06D8DAF9MISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BrEqN/r5 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=7aHsa4If4JIA:10 a=ofMgfj31e3cA:10 a=ZPN1AG1SMQcA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=xskcdSivAAAA:8 a=ABeY7kuGAAAA:8 a=Tg0nUI2_AAAA:8 a] X-AnalysisOut: [=9lsthRMA-0nphS8TOwYA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:1] X-AnalysisOut: [0 a=ChEcuLpljosA:10 a=chC_agHSu74A:10 a=3ODoesluOjEA:10 a=] X-AnalysisOut: [xu93fpMmjvuQhYoH:21 a=OeUmD4xoLIXhBktP:21 a=yMhMjlubAAAA:8] X-AnalysisOut: [ a=SSmOFEACAAAA:8 a=T6cE0jF5LYKCw0Tsd_AA:9 a=gKO2Hq4RSVkA:] X-AnalysisOut: [10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a] X-AnalysisOut: [=tXsnliwV7b4A:10 a=JU-igaeHZSINe-gQ:21 a=kTm6r7N0FrE9_j8U:] X-AnalysisOut: [21 a=kjqgdHwSWlhVvz0h:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/g-Gw4oZBohZ1Hoi20SgDZsssN70 Cc: 'Jeffrey Haas' , "'Jmh.direct'" , 'Joel Halpern' , "'i2rs@ietf.org'" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Wed, 17 Sep 2014 11:50:51 -0000 --_000_B17A6910EEDD1F45980687268941550F06D8DAF9MISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Wednesday, September 17, 2014 7:33 AM To: Andy Bierman Cc: Jeffrey Haas; Jmh.direct; Joel Halpern; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt Andy, Take an broadband edge scenario. BRAS/BNG has 10s of thousand of subscribe= rs. Through I2RS agent several subscriber related configurations have been = added. Box reboots and all subscribers are gone. The subscriber related con= figuration has to be removed, as nobody knows if the subscriber incoming ba= ck and if it will get the same router properties. IMO, use I2RS to change transient properties on the device. Dean On Sep 15, 2014, at 9:01 PM, Andy Bierman > wrote: On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct > wrote: The WG discussed this extensively. Any effort to persist I2RS state introduces significant complexity. In par= ticular, very few configs have a mechanism to store a prrvious state so tha= t thr system will behave correctly when the I2RS agent deletes the state it= has created. And there were other problems noted. Whime some folks wanted petsistance, as a participant the conclusion of the= WG was quite clear. I am OK with leaving out persistence. If glitches cause problems, vendors will extend the standard with proprietary attempts to fix them. There is complexity either way. Yours, Joel Andy Sent from my Samsung smartphone on AT&T -------- Original message -------- Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt From: Andy Bierman > To: Jeffrey Haas > CC: "Joel M. Halpern" >,"i2= rs@ietf.org" > On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas > wrote: On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > There is nothing in YANG or RESTCONF to support it (yet). > For some features the I2RS agent is supposedly simple and mostly stateles= s. > This template service does not seem to fit with that theme. Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference. The tension seems to lie roughly along two points of view: 1. This is a programmatically driven API environment. As such, there's little excuse to not simply send everything needed as a large configuration block - templates are extraneous. 2. By permitting templates, you enable much smaller transactions. You also potentially allow for a stronger security model by "locking down" stuff outside of the template. To offer a somewhat concrete example, consider an application for provisioning L3VPN customers. Some minimum required configuration on a per-device basis includes: VRF name. A route-distinguisher. A route-target for the VPN. Customer PE-CE protocol and endpoint configuration. Fully expanded, this is probably a few dozens of lines of configuration in YANG. What's interesting is that the above information is potentially generic related to that configuration, which may have per-device variance - potentially based upon vendor. Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted. > Are these templates ephemeral? That would be annoying. They are not > straight > config, so a new a configuration data model is needed to manage the > templates. > New protocol mechanisms to use templates in addition to payload data will > be needed. All agreed. > > You talk about the priority requirements. You should probably mention = the > > multi-headed behavioral requirements there (as I think that the resolut= ions > > will be tightly coupled.) > > > > Section 7.9 of the archtiecture document talks about several transactio= nal > > scopes. The text you have does not seem to deal with all of these. Do= es > > YANG handle them all easily? > > > > I would need to review this again -- I don't remember any problems last > time I read the arch draft. Some of this is a matter of where this information lives. For tie-breaking of ephemeral vs. static config, is this provisioned per-module or per element in the module? Are there explicit lines of YANG in each module for this? For tie-breaking user priorities, NACM extensions may make sense. This particular state is effectively meta-data on the ephemeral config. Since the epehemeral state is "highest priority wins", but there's no requirement that the lower priority state is kept in any fashion, how do we deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state? > I am confused about some text in the draft about ephemeral config: > > In 2.1: > > The author wishes to > prevent any action that would lead to preserving any configuration > state entered via the I2RS agent across reboots. If state has to be > restored, it should be solely by replay actions from I2RS client via > I2RS agent. > > > Why does the author wish to prevent NV-storage of the I2RS data? > What is it about the accidental reboot of the router that makes it the > I2RS data needed before the accidental reboot, but not after? I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored? Several people have asked about "copy to local config", which is really "NV-save the I2RS state". What if the operator wants the state to be active until it is explicitly removed? There may be significa= nt latency between the time the client discovers the agent has rebooted and the state is re-installed. > If the reason is because I2RS agents are simple and NV-storage is not > simple, > then why does the agent need to support templates? This is more a "clean slate" decision. When the device comes up, it has no I2RS state. Note that the fully ephemeral nature of I2RS still doesn't feel fully-settled in the WG. See prior thread comments about wanting to do copy-config on it. :-) > This section might mention that the I2RS datastore has its own > access control model, that is not the same as the running config. > > 2. Configuration state in the existing running datastore where the > module is "tagged ephemeral". > > 3. Permitting existing configuration to be optionally configured as > ephemeral. As an example, the NETCONF server advertises in its > message if it supports the specified YANG module > persistently and/or ephemerally. > > > > I thought the I2RS charter said I2RS was not altering the local config. Correct. > Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)? For point 2, it'd be identifying I2RS modules (having the ephemeral properties) in the YANG. Point 3 is submitted as an option based on comments at the last IETF netmod session where someone else indicated being able to store things ephemerally would potentially be useful. If this is indeed a wider use case, let's discuss it. > This does not really work because YANG validation may fail without some > config data > that has been tagged "do not save". If the router reboots and the startu= p > config > does not validate, it is probably wedged. It can't really fall back to a > "known good config" > if I2RS has forced some of the data to be omitted from the saved config. Agreed. See also the priority discussion above. > In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral", > then I2RS is gated on the completion of YANG 1.1 (and development of YANG > 1.1 tools). > Are you really sure you want that? That's why a YANG extension was > suggested instead > (or maybe do both). Worth discussing during the interim. It has been suggested to me that many of the above properties can already b= e implemented in a proprietary manner with no language extensions. They woul= d simply not be either interoperable or clear about their ephemeral nature based on module contents. So, we're looking for a balance of expeditious and correct for the long ter= m maintainenace of the protocols and YANG. -- Jeff Andy _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_B17A6910EEDD1F45980687268941550F06D8DAF9MISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic
Sent: Wednesday, September 17, 2014 7:33 AM
To: Andy Bierman
Cc: Jeffrey Haas; Jmh.direct; Joel Halpern; i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requi= rements-00.txt

 

Andy,

 

Take an broadband edge scenario.  BRAS/BNG has = 10s of thousand of subscribers. Through I2RS agent several subscriber relat= ed configurations have been added. Box reboots and all subscribers are gone= . The subscriber related configuration has to be removed, as nobody knows if the subscriber incoming back and if = it will get the same router properties. 

IMO, use I2RS to change transient properties on the = device. 

 

Dean

 

On Sep 15, 2014, at 9:01 PM, Andy Bierman <andy@yumaworks.com> wrote:



 

 

On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct <jmh.direct@joel= halpern.com> wrote:

The WG discussed this extensively.

Any effort to persist I2RS state introduces signific= ant complexity.  In particular, very few configs have a mechanism to s= tore a prrvious state so that thr system will behave correctly when the I2R= S agent deletes the state it has created.  And there were other problems noted.

Whime some folks wanted petsistance, as a participan= t the conclusion of the WG was quite clear.

 

 

I am OK with leaving out persistence.  If glitc= hes cause problems, vendors

will extend the standard with proprietary attempts t= o fix them.

There is complexity either way.

 

 

Yours,

Joel

 

Andy

 


Sent from my Samsung smartphone on AT&= T




-------- Original message --------
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt
From: Andy Bierman <andy@yumaworks.com>
To: Jeffrey Haas <jh= aas@pfrc.org>
CC: "Joel M. Halpern" <jmh@joelhalpern.com>,"i2rs@ietf.org" <i2rs@ietf.org>

 

 

On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <<= a href=3D"mailto:jhaas@pfrc.org" target=3D"_blank">jhaas@pfrc.org> w= rote:

On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierm= an wrote:
> There is nothing in YANG or RESTCONF to support it (yet).
> For some features the I2RS agent is supposedly simple and mostly state= less.
> This template service does not seem to fit with that theme.

Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference.  The<= br> tension seems to lie roughly along two points of view:

1. This is a programmatically driven API environment.  As such, there'= s
little excuse to not simply send everything needed as a large configuration=
block - templates are extraneous.

2. By permitting templates, you enable much smaller transactions.  You= also
potentially allow for a stronger security model by "locking down"= stuff
outside of the template.

To offer a somewhat concrete example, consider an application for
provisioning L3VPN customers.  Some minimum required configuration on = a
per-device basis includes:

VRF name.
A route-distinguisher.
A route-target for the VPN.
Customer PE-CE protocol and endpoint configuration.

Fully expanded, this is probably a few dozens of lines of configuration in<= br> YANG.  What's interesting is that the above information is potentially=
generic related to that configuration, which may have per-device variance -=
potentially based upon vendor.

Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted.

> Are these templates ephemeral?  That would be annoying.  The= y are not
> straight
> config, so a new a configuration data model is needed to manage the > templates.
> New protocol mechanisms to use templates in addition to payload data w= ill
> be needed.

All agreed.

> > You talk about the priority requirements.  You should probab= ly mention the
> > multi-headed behavioral requirements there (as I think that the r= esolutions
> > will be tightly coupled.)
> >
> > Section 7.9 of the archtiecture document talks about several tran= sactional
> > scopes.  The text you have does not seem to deal with all of= these.  Does
> > YANG handle them all easily?
> >
>
> I would need to review this again -- I don't remember any problems las= t
> time I read the arch draft.

Some of this is a matter of where this information lives.

For tie-breaking of ephemeral vs. static config, is this provisioned
per-module or per element in the module?  Are there explicit lines of = YANG
in each module for this?

For tie-breaking user priorities, NACM extensions may make sense.  Thi= s
particular state is effectively meta-data on the ephemeral config.

Since the epehemeral state is "highest priority wins", but there'= s no
requirement that the lower priority state is kept in any fashion, how do we=
deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state?

> I am confused about some text in the draft about ephemeral config:
>
> In 2.1:
>
>    The author wishes to
>    prevent any action that would lead to preserving any conf= iguration
>    state entered via the I2RS agent across reboots.  If= state has to be
>    restored, it should be solely by replay actions from I2RS= client via
>    I2RS agent.
>
>
> Why does the author wish to prevent NV-storage of the I2RS data?
> What is it about the accidental reboot of the router that makes it the=
> I2RS data needed before the accidental reboot, but not after?

I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored?

 

Several people have asked about "copy to local = config", which is

really "NV-save the I2RS state".   &n= bsp;What if the operator wants the

state to be active until it is explicitly removed? &= nbsp; There may be significant latency

between the time the client discovers the agent has = rebooted and

the state is re-installed.

 

 


> If the reason is because I2RS agents are simple and NV-storage is not<= br> > simple,
> then why does the agent need to support templates?

This is more a "clean slate" decision.  When the device come= s up, it has no
I2RS state.

Note that the fully ephemeral nature of I2RS still doesn't feel
fully-settled in the WG.  See prior thread comments about wanting to d= o
copy-config on it. :-)

> This section might mention that the I2RS datastore has its own
> access control model, that is not the same as the running config.
>
>    2.  Configuration state in the existing running data= store where the
>        module is "tagged ephemeral".
>
>    3.  Permitting existing configuration to be optional= ly configured as
>        ephemeral.  As an example, the NETCONF= server advertises in its
>        <hello> message if it supports the sp= ecified YANG module
>        persistently and/or ephemerally.
>
>
>
> I thought the I2RS charter said I2RS was not altering the local config= .

Correct.

> Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)?

For point 2, it'd be identifying I2RS modules (having the ephemeral
properties) in the YANG.

Point 3 is submitted as an option based on comments at the last IETF netmod=
session where someone else indicated being able to store things ephemerally=
would potentially be useful.  If this is indeed a wider use case, let'= s
discuss it.

> This does not really work because YANG validation may fail without som= e
> config data
> that has been tagged "do not save".  If the router rebo= ots and the startup
> config
> does not validate, it is probably wedged. It can't really fall back to= a
> "known good config"
> if I2RS has forced some of the data to be omitted from the saved confi= g.

Agreed.  See also the priority discussion above.

> In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral",
> then I2RS is gated on the completion of YANG 1.1 (and development of Y= ANG
> 1.1 tools).
> Are you really sure you want that?  That's why a YANG extension w= as
> suggested instead
> (or maybe do both).

Worth discussing during the interim.

It has been suggested to me that many of the above properties can already b= e
implemented in a proprietary manner with no language extensions.  They= would
simply not be either interoperable or clear about their ephemeral nature based on module contents.

So, we're looking for a balance of expeditious and correct for the long ter= m
maintainenace of the protocols and YANG.

-- Jeff

 

 

Andy

 

 

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

 

--_000_B17A6910EEDD1F45980687268941550F06D8DAF9MISOUT7MSGUSRCD_-- From nobody Wed Sep 17 05:09: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 37EC61A00CA for ; Wed, 17 Sep 2014 05:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.25 X-Spam-Level: X-Spam-Status: No, score=-5.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 aQ-RQLY1y8Du for ; Wed, 17 Sep 2014 05:08:55 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A191A00AB for ; Wed, 17 Sep 2014 05:08:54 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 5d979145.0.3092422.00-2349.8460348.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 17 Sep 2014 12:08:54 +0000 (UTC) X-MXL-Hash: 541979d6440761a9-807dcfc14f3608f8ff0709400d5aa07a0d40f203 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8HC8qiT013032; Wed, 17 Sep 2014 08:08:53 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s8HC8hKD012894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2014 08:08:49 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 17 Sep 2014 12:08:24 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.28]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 08:08:24 -0400 From: "UTTARO, JAMES" To: "'Dean Bogdanovic'" , "'Andy Bierman'" Thread-Topic: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt Thread-Index: AQHP0UQoqsRlfvmajUO3Spkk9N3ADJwC8OYAgAJC6ICAAAVz0IAABJBA Date: Wed, 17 Sep 2014 12:08:24 +0000 Message-ID: References: <8ou91fafu66p72ybrp3fa58q.1410826889178@email.android.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.129.222] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06D8DD67MISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=EOCxJSlC c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=7aHsa4If4JIA:10 a=ofMgfj31e3cA:10 a=ZPN1AG1SMQcA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=OUXY8nFuA] X-AnalysisOut: [AAA:8 a=1sjgXBK7AAAA:8 a=Tg0nUI2_AAAA:8 a=48vgC7mUAAAA:8 a] X-AnalysisOut: [=1XWaLZrsAAAA:8 a=voZKSeMjAAAA:8 a=_V6KcPrEAAAA:8 a=xskcdS] X-AnalysisOut: [ivAAAA:8 a=ABeY7kuGAAAA:8 a=fFc5CozTecb9SEydb94A:9 a=CjuIK] X-AnalysisOut: [1q_8ugA:10 a=eRsKL0hzPpUA:10 a=CLAJG8EyDesA:10 a=3f6_n8AV6] X-AnalysisOut: [9oA:10 a=We2So7OV-fIA:10 a=kkUMZHjH4KkA:10 a=59xvRoXLalUA:] X-AnalysisOut: [10 a=u6pmmePcEMEA:10 a=L7MQyJFtOqQA:10 a=peF9eE_zjQwA:10 a] X-AnalysisOut: [=kZwP4KTQBigA:10 a=EJ_lzN1bkxcA:10 a=lZB815dzVvQA:10 a=ChE] X-AnalysisOut: [cuLpljosA:10 a=chC_agHSu74A:10 a=3ODoesluOjEA:10 a=iJ3cGgR] X-AnalysisOut: [paNMqPrTa:21 a=6wL8JTyCXt7QYKSl:21 a=yMhMjlubAAAA:8 a=SSmO] X-AnalysisOut: [FEACAAAA:8 a=SG_rXuW8AdRFgO0EMUQA:9 a=gKO2Hq4RSVkA:10 a=Ui] X-AnalysisOut: [CQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=tXsnli] X-AnalysisOut: [wV7b4A:10 a=BfoU1Cn9dA7ZhrmW:21 a=l7LPbZW3CNynVzcG:21 a=16] X-AnalysisOut: [rVhE30mV4A6KNT:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UKI5lURAb9cYiOSAcFoxRU3fO2o Cc: 'Jeffrey Haas' , "'Jmh.direct'" , 'Joel Halpern' , "'i2rs@ietf.org'" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Wed, 17 Sep 2014 12:09:00 -0000 --_000_B17A6910EEDD1F45980687268941550F06D8DD67MISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here were my comments in re I2RS.. See bullet 3.. Jim Uttaro Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted ---------------------------------------------------------------------------= ----- From: "UTTARO, JAMES" To: "'Dean Bogdanovic'" , "'Susan Hares'" Cc: 'Jeffrey Haas' , "''" , 'Russ White' , 'Edward Crabbe' = , "'t.petch'" Date: Mon, 16 Jun 2014 17:40:29 +0000 In-reply-to: References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff0= 20$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> List-id: "Interface to The Internet Routing System \(IRS\)" ---------------------------------------------------------------------------= ----- Susan, Following find my comments in re this document.. General Comments. 1) There is a need to better define what is meant by the "h= alfway point" between completely replacing the distributed control plane an= d configuring it all. It would seem to be that this "halfway point" is diff= erent based on what is being programmed. To that end it would be useful to = call out higher level reqs some suggestions. 2) Dissemination Scope of an I2RS Instruction Set ( Block o= f instructions intended to be atomic ) - An instruction set may be local or= global in nature as it pertains to affected the distributed control plane = when configured on a network element. a) A locally scoped instruction set may co= nfigure routing state in the RIB for comparison purposes but that state may= not be disseminated via the distributed control plane. b) A globally scoped instruction set must c= onfigure routing state in the RIB for comparison purposes and that state is= available for dissemination subject to any other policy. 3) Ephemeral/Persistent Scope of an I2RS Instruction Set a) Should the instruction set persist? What= comes to mind for me are the "configuration" like changes i.e RT-C, FlowSp= ec . 4) Liveness/Safety Properties - Would like to see some disc= ussion in re these items. 5) Uses Cases - I believe addl use cases whose focus is on = configuration like services would be desirable. As an ex.. RT-C.. Specific Comments C1 - P1 - Para 2 ..." Such a system would not interact...." The paragraph us= es a routing and best path selection as an example. I assume that this not = limited to this application but spans configuration like state etc.... C2 - P3 -Para 1 "This represents a "halfway point" ..." This needs a cleare= r definition, I would suggest wording regarding how the distributed contro= l plane will be augmented by the addition of I2RS C3 - P3 - Para 3 "...Each unique has been" Typo missing the word reqs. C4 - P3 - Para 5 The reaction to Network Based Attacks may also include othe= r actions i.e mirror, drop ...I assume you are not limiting the response to= the attack to only re-direct. C5 - P4 - Para 4 1st Bullet Can the I2RS agent interact with other tools and get the de= sired info in this case available routes in the RIB? In general can I2RS pr= ovide a framework to collect data from multiple sources including directly = from a router, RR, NM? C6 - P4 - Para 4 2nd Bullet Need to describe in how state learned via I2RS agent and st= ate learned via distributed control plane interact across the set of applic= ations ( See Above General Comments. ) C7 - P5 - Para 4 3rd Bullet What is the ask for here? Is there a consistent definition = of /dev/null being sought? C8 - P5 -Para 4 4th Bullet Not sure what this req is. Is it saying the policies config= ured via distributed control plane, local and/or via I2Rs should have some= form of id? Why is this needed if the policy no matter where it is learned= is recorded in the running configuration?? C10 - P5 - Para `1 "In hub and spoke..." There are other hub/spoke solutions i= .e Virtual Hub Rekhter et al...that do not rely on a centralized server. Jim Uttaro From: UTTARO, JAMES Sent: Wednesday, September 17, 2014 7:50 AM To: 'Dean Bogdanovic'; 'Andy Bierman' Cc: 'Jeffrey Haas'; 'Jmh.direct'; 'Joel Halpern'; 'i2rs@ietf.org' Subject: RE: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt +1 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Wednesday, September 17, 2014 7:33 AM To: Andy Bierman Cc: Jeffrey Haas; Jmh.direct; Joel Halpern; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt Andy, Take an broadband edge scenario. BRAS/BNG has 10s of thousand of subscribe= rs. Through I2RS agent several subscriber related configurations have been = added. Box reboots and all subscribers are gone. The subscriber related con= figuration has to be removed, as nobody knows if the subscriber incoming ba= ck and if it will get the same router properties. IMO, use I2RS to change transient properties on the device. Dean On Sep 15, 2014, at 9:01 PM, Andy Bierman > wrote: On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct > wrote: The WG discussed this extensively. Any effort to persist I2RS state introduces significant complexity. In par= ticular, very few configs have a mechanism to store a prrvious state so tha= t thr system will behave correctly when the I2RS agent deletes the state it= has created. And there were other problems noted. Whime some folks wanted petsistance, as a participant the conclusion of the= WG was quite clear. I am OK with leaving out persistence. If glitches cause problems, vendors will extend the standard with proprietary attempts to fix them. There is complexity either way. Yours, Joel Andy Sent from my Samsung smartphone on AT&T -------- Original message -------- Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt From: Andy Bierman > To: Jeffrey Haas > CC: "Joel M. Halpern" >,"i2= rs@ietf.org" > On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas > wrote: On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > There is nothing in YANG or RESTCONF to support it (yet). > For some features the I2RS agent is supposedly simple and mostly stateles= s. > This template service does not seem to fit with that theme. Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference. The tension seems to lie roughly along two points of view: 1. This is a programmatically driven API environment. As such, there's little excuse to not simply send everything needed as a large configuration block - templates are extraneous. 2. By permitting templates, you enable much smaller transactions. You also potentially allow for a stronger security model by "locking down" stuff outside of the template. To offer a somewhat concrete example, consider an application for provisioning L3VPN customers. Some minimum required configuration on a per-device basis includes: VRF name. A route-distinguisher. A route-target for the VPN. Customer PE-CE protocol and endpoint configuration. Fully expanded, this is probably a few dozens of lines of configuration in YANG. What's interesting is that the above information is potentially generic related to that configuration, which may have per-device variance - potentially based upon vendor. Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted. > Are these templates ephemeral? That would be annoying. They are not > straight > config, so a new a configuration data model is needed to manage the > templates. > New protocol mechanisms to use templates in addition to payload data will > be needed. All agreed. > > You talk about the priority requirements. You should probably mention = the > > multi-headed behavioral requirements there (as I think that the resolut= ions > > will be tightly coupled.) > > > > Section 7.9 of the archtiecture document talks about several transactio= nal > > scopes. The text you have does not seem to deal with all of these. Do= es > > YANG handle them all easily? > > > > I would need to review this again -- I don't remember any problems last > time I read the arch draft. Some of this is a matter of where this information lives. For tie-breaking of ephemeral vs. static config, is this provisioned per-module or per element in the module? Are there explicit lines of YANG in each module for this? For tie-breaking user priorities, NACM extensions may make sense. This particular state is effectively meta-data on the ephemeral config. Since the epehemeral state is "highest priority wins", but there's no requirement that the lower priority state is kept in any fashion, how do we deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state? > I am confused about some text in the draft about ephemeral config: > > In 2.1: > > The author wishes to > prevent any action that would lead to preserving any configuration > state entered via the I2RS agent across reboots. If state has to be > restored, it should be solely by replay actions from I2RS client via > I2RS agent. > > > Why does the author wish to prevent NV-storage of the I2RS data? > What is it about the accidental reboot of the router that makes it the > I2RS data needed before the accidental reboot, but not after? I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored? Several people have asked about "copy to local config", which is really "NV-save the I2RS state". What if the operator wants the state to be active until it is explicitly removed? There may be significa= nt latency between the time the client discovers the agent has rebooted and the state is re-installed. > If the reason is because I2RS agents are simple and NV-storage is not > simple, > then why does the agent need to support templates? This is more a "clean slate" decision. When the device comes up, it has no I2RS state. Note that the fully ephemeral nature of I2RS still doesn't feel fully-settled in the WG. See prior thread comments about wanting to do copy-config on it. :-) > This section might mention that the I2RS datastore has its own > access control model, that is not the same as the running config. > > 2. Configuration state in the existing running datastore where the > module is "tagged ephemeral". > > 3. Permitting existing configuration to be optionally configured as > ephemeral. As an example, the NETCONF server advertises in its > message if it supports the specified YANG module > persistently and/or ephemerally. > > > > I thought the I2RS charter said I2RS was not altering the local config. Correct. > Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)? For point 2, it'd be identifying I2RS modules (having the ephemeral properties) in the YANG. Point 3 is submitted as an option based on comments at the last IETF netmod session where someone else indicated being able to store things ephemerally would potentially be useful. If this is indeed a wider use case, let's discuss it. > This does not really work because YANG validation may fail without some > config data > that has been tagged "do not save". If the router reboots and the startu= p > config > does not validate, it is probably wedged. It can't really fall back to a > "known good config" > if I2RS has forced some of the data to be omitted from the saved config. Agreed. See also the priority discussion above. > In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral", > then I2RS is gated on the completion of YANG 1.1 (and development of YANG > 1.1 tools). > Are you really sure you want that? That's why a YANG extension was > suggested instead > (or maybe do both). Worth discussing during the interim. It has been suggested to me that many of the above properties can already b= e implemented in a proprietary manner with no language extensions. They woul= d simply not be either interoperable or clear about their ephemeral nature based on module contents. So, we're looking for a balance of expeditious and correct for the long ter= m maintainenace of the protocols and YANG. -- Jeff Andy _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_B17A6910EEDD1F45980687268941550F06D8DD67MISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here were my comments in = re I2RS.. See bullet 3..

 <= /p>

Jim Uttaro

 <= /p>

 <= /p>

Re: [i2rs] draft-white-i2= rs-use-case-05.txt has been posted

 <= /p>

-------------------------= -------------------------------------------------------

 <= /p>

From: "UTTARO, JAMES= " <ju1738 at att.com>

To: "'Dean Bogdanovi= c'" <deanb at juniper.net>, "'Susan Hares'" <shares= at ndzh.com>

Cc: 'Jeffrey Haas' <jh= aas at pfrc.org>, "'<i2rs at ietf.org>'" <i2rs at iet= f.org>, 'Russ White' <russw at riw.us>, 'Edward Crabbe' <edc at= google.com>, "'t.petch'" <ietfc at btconnect.com>

Date: Mon, 16 Jun 2014 17= :40:29 +0000

In-reply-to: <DADF7D14= -4834-47FE-B68F-4CEBE20E4091@juniper.net>

References: <000901cf8= 68d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gate= way.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <DADF7D= 14-4834-47FE-B68F-4CEBE20E4091@juniper.net>

List-id: "Interface = to The Internet Routing System \(IRS\)" <i2rs.ietf.org>

 <= /p>

-------------------------= -------------------------------------------------------

 <= /p>

Susan,<= /p>

 <= /p>

    &= nbsp;           Following= find my comments in re this document..

 <= /p>

    &= nbsp;           General C= omments.

 <= /p>

    &= nbsp;           1) There = is a need to better define what is meant by the "halfway point" b= etween completely replacing the distributed control plane and configuring it all. It would seem to be that this "halfway point" is differe= nt based on what is being programmed. To that end it would be useful to cal= l out higher level reqs some suggestions.

 <= /p>

    &= nbsp;           2) Dissem= ination Scope of an I2RS Instruction Set ( Block of instructions intended t= o be atomic ) - An instruction set may be local or global in nature as it pertains to affected the distributed control plane when co= nfigured on a network element.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;  a)  A locally scoped instruction set may configure routing= state in the RIB for comparison purposes but that state may not be disseminated via the distributed control  plane.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;  b) A globally scoped instruction set must configure routing sta= te in the RIB for comparison purposes and that state is available for dissemination subject to any other policy.

 <= /p>

 <= /p>

    &= nbsp;           3) Epheme= ral/Persistent Scope of an I2RS Instruction Set

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;  a) Should the instruction set persist? What comes to mind for m= e are the "configuration" like changes i.e RT-C, FlowSpec .

 <= /p>

    &= nbsp;           4) Livene= ss/Safety Properties - Would like to see some discussion in re these items.=

 <= /p>

    &= nbsp;           5) Uses C= ases - I believe addl use cases whose focus is on configuration like servic= es would be desirable. As an ex.. RT-C..

 <= /p>

    &= nbsp;           Specific = Comments

 <= /p>

    &= nbsp;           C1 - P1 -= Para 2

 <= /p>

    &= nbsp;           ..."= Such a system would not interact...." The paragraph uses a routing an= d best path selection as an example. I assume that this not limited to this application but spans configuration like state etc....<= /span>

 <= /p>

    &= nbsp;           C2 - P3 -= Para 1

 <= /p>

    &= nbsp;           "Thi= s represents a "halfway point" ..." This needs a clearer def= inition, I would suggest wording regarding  how the distributed contro= l plane will be augmented by the addition of I2RS

 <= /p>

    &= nbsp;           C3 - P3 -= Para 3

 <= /p>

    &= nbsp;           "...= Each unique has been" Typo missing the word reqs.

 <= /p>

    &= nbsp;           C4 - P3 -= Para 5

 <= /p>

    &= nbsp;           The react= ion to Network Based Attacks may also include other actions i.e mirror, dro= p ...I assume you are not limiting the response to the attack to only re-direct.

 <= /p>

    &= nbsp;           C5 - P4 -= Para 4 1st Bullet

 <= /p>

    &= nbsp;           Can the I= 2RS agent interact with other tools and get the desired info in this case a= vailable routes in the RIB? In general can I2RS provide a framework to collect data from multiple sources including directly from = a router, RR, NM?

 <= /p>

    &= nbsp;           C6 - P4 -= Para 4 2nd Bullet

 <= /p>

    &= nbsp;           Need to d= escribe in how state learned via I2RS agent and state learned via distribut= ed control plane interact across the set of applications ( See Above General Comments. )

 <= /p>

    &= nbsp;           C7 - P5 -= Para 4 3rd Bullet

 <= /p>

    &= nbsp;           What is t= he ask for here? Is there a consistent definition of /dev/null being sought= ?

 <= /p>

    &= nbsp;           C8 - P5 -= Para 4 4th Bullet

 <= /p>

    &= nbsp;           Not sure = what this req is. Is it saying the policies configured via distributed cont= rol plane, local  and/or via I2Rs should have some form of id? Why is this needed if the policy no matter where it is learned is r= ecorded in the running configuration??

 <= /p>

    &= nbsp;           C10 - P5 = - Para `1

 <= /p>

    &= nbsp;           "In = hub and spoke..." There are other hub/spoke solutions i.e Virtual Hub = Rekhter et al...that do not rely on a centralized server.=

 <= /p>

    &= nbsp;          

 <= /p>

Jim Uttaro

 <= /p>

 <= /p>

From: UTTARO, = JAMES
Sent: Wednesday, September 17, 2014 7:50 AM
To: 'Dean Bogdanovic'; 'Andy Bierman'
Cc: 'Jeffrey Haas'; 'Jmh.direct'; 'Joel Halpern'; 'i2rs@ietf.org' Subject: RE: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requi= rements-00.txt

 

+1<= /p>

 <= /p>

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic
Sent: Wednesday, September 17, 2014 7:33 AM
To: Andy Bierman
Cc: Jeffrey Haas; Jmh.direct; Joel Halpern; i2rs@ietf.org
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requi= rements-00.txt

 

Andy,

 

Take an broadband edge scenario.  BRAS/BNG has = 10s of thousand of subscribers. Through I2RS agent several subscriber relat= ed configurations have been added. Box reboots and all subscribers are gone= . The subscriber related configuration has to be removed, as nobody knows if the subscriber incoming back and if = it will get the same router properties. 

IMO, use I2RS to change transient properties on the = device. 

 

Dean

 

On Sep 15, 2014, at 9:01 PM, Andy Bierman <andy@yumaworks.com> wrote:

 

 

 

On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct <jmh.direct@joel= halpern.com> wrote:

The WG discussed this extensively.

Any effort to persist I2RS state introduces signific= ant complexity.  In particular, very few configs have a mechanism to s= tore a prrvious state so that thr system will behave correctly when the I2R= S agent deletes the state it has created.  And there were other problems noted.

Whime some folks wanted petsistance, as a participan= t the conclusion of the WG was quite clear.

 

 

I am OK with leaving out persistence.  If glitc= hes cause problems, vendors

will extend the standard with proprietary attempts t= o fix them.

There is complexity either way.

 

 

Yours,

Joel

 

Andy

 


Sent from my Samsung smartphone on AT&= T




-------- Original message --------
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements= -00.txt
From: Andy Bierman <andy@yumaworks.com>
To: Jeffrey Haas <jh= aas@pfrc.org>
CC: "Joel M. Halpern" <jmh@joelhalpern.com>,"i2rs@ietf.org" <i2rs@ietf.org>

 

 

On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <<= a href=3D"mailto:jhaas@pfrc.org" target=3D"_blank">jhaas@pfrc.org> w= rote:

On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierm= an wrote:
> There is nothing in YANG or RESTCONF to support it (yet).
> For some features the I2RS agent is supposedly simple and mostly state= less.
> This template service does not seem to fit with that theme.

Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference.  The<= br> tension seems to lie roughly along two points of view:

1. This is a programmatically driven API environment.  As such, there'= s
little excuse to not simply send everything needed as a large configuration=
block - templates are extraneous.

2. By permitting templates, you enable much smaller transactions.  You= also
potentially allow for a stronger security model by "locking down"= stuff
outside of the template.

To offer a somewhat concrete example, consider an application for
provisioning L3VPN customers.  Some minimum required configuration on = a
per-device basis includes:

VRF name.
A route-distinguisher.
A route-target for the VPN.
Customer PE-CE protocol and endpoint configuration.

Fully expanded, this is probably a few dozens of lines of configuration in<= br> YANG.  What's interesting is that the above information is potentially=
generic related to that configuration, which may have per-device variance -=
potentially based upon vendor.

Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted.

> Are these templates ephemeral?  That would be annoying.  The= y are not
> straight
> config, so a new a configuration data model is needed to manage the > templates.
> New protocol mechanisms to use templates in addition to payload data w= ill
> be needed.

All agreed.

> > You talk about the priority requirements.  You should probab= ly mention the
> > multi-headed behavioral requirements there (as I think that the r= esolutions
> > will be tightly coupled.)
> >
> > Section 7.9 of the archtiecture document talks about several tran= sactional
> > scopes.  The text you have does not seem to deal with all of= these.  Does
> > YANG handle them all easily?
> >
>
> I would need to review this again -- I don't remember any problems las= t
> time I read the arch draft.

Some of this is a matter of where this information lives.

For tie-breaking of ephemeral vs. static config, is this provisioned
per-module or per element in the module?  Are there explicit lines of = YANG
in each module for this?

For tie-breaking user priorities, NACM extensions may make sense.  Thi= s
particular state is effectively meta-data on the ephemeral config.

Since the epehemeral state is "highest priority wins", but there'= s no
requirement that the lower priority state is kept in any fashion, how do we=
deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state?

> I am confused about some text in the draft about ephemeral config:
>
> In 2.1:
>
>    The author wishes to
>    prevent any action that would lead to preserving any conf= iguration
>    state entered via the I2RS agent across reboots.  If= state has to be
>    restored, it should be solely by replay actions from I2RS= client via
>    I2RS agent.
>
>
> Why does the author wish to prevent NV-storage of the I2RS data?
> What is it about the accidental reboot of the router that makes it the=
> I2RS data needed before the accidental reboot, but not after?

I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored?

 

Several people have asked about "copy to local = config", which is

really "NV-save the I2RS state".   &n= bsp;What if the operator wants the

state to be active until it is explicitly removed? &= nbsp; There may be significant latency

between the time the client discovers the agent has = rebooted and

the state is re-installed.

 

 


> If the reason is because I2RS agents are simple and NV-storage is not<= br> > simple,
> then why does the agent need to support templates?

This is more a "clean slate" decision.  When the device come= s up, it has no
I2RS state.

Note that the fully ephemeral nature of I2RS still doesn't feel
fully-settled in the WG.  See prior thread comments about wanting to d= o
copy-config on it. :-)

> This section might mention that the I2RS datastore has its own
> access control model, that is not the same as the running config.
>
>    2.  Configuration state in the existing running data= store where the
>        module is "tagged ephemeral".
>
>    3.  Permitting existing configuration to be optional= ly configured as
>        ephemeral.  As an example, the NETCONF= server advertises in its
>        <hello> message if it supports the sp= ecified YANG module
>        persistently and/or ephemerally.
>
>
>
> I thought the I2RS charter said I2RS was not altering the local config= .

Correct.

> Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)?

For point 2, it'd be identifying I2RS modules (having the ephemeral
properties) in the YANG.

Point 3 is submitted as an option based on comments at the last IETF netmod=
session where someone else indicated being able to store things ephemerally=
would potentially be useful.  If this is indeed a wider use case, let'= s
discuss it.

> This does not really work because YANG validation may fail without som= e
> config data
> that has been tagged "do not save".  If the router rebo= ots and the startup
> config
> does not validate, it is probably wedged. It can't really fall back to= a
> "known good config"
> if I2RS has forced some of the data to be omitted from the saved confi= g.

Agreed.  See also the priority discussion above.

> In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral",
> then I2RS is gated on the completion of YANG 1.1 (and development of Y= ANG
> 1.1 tools).
> Are you really sure you want that?  That's why a YANG extension w= as
> suggested instead
> (or maybe do both).

Worth discussing during the interim.

It has been suggested to me that many of the above properties can already b= e
implemented in a proprietary manner with no language extensions.  They= would
simply not be either interoperable or clear about their ephemeral nature based on module contents.

So, we're looking for a balance of expeditious and correct for the long ter= m
maintainenace of the protocols and YANG.

-- Jeff

 

 

Andy

 

 

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

 

--_000_B17A6910EEDD1F45980687268941550F06D8DD67MISOUT7MSGUSRCD_-- From nobody Wed Sep 17 16:12: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 EC43D1A03EB for ; Wed, 17 Sep 2014 16:12:50 -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 g19mYmLFjf2E for ; Wed, 17 Sep 2014 16:12:49 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 88E091A03D8 for ; Wed, 17 Sep 2014 16:12:49 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> In-Reply-To: <54136414.5080101@joelhalpern.com> Date: Wed, 17 Sep 2014 19:12:44 -0400 Message-ID: <001201cfd2cc$e3b3b380$ab1b1a80$@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: AQG2k1L3up2v+fcxTpS95jZoEMUpRQDPM7Y9nDH3IcA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OC2yErpzDaM5DbtB4CmELIhqoSY Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Wed, 17 Sep 2014 23:12:51 -0000 Joel and Jeff: Can you comment on why and why not you consider "instance-identifier" and "require-instance" yang key words to satisfying the requirements for object relationship requirements? Are you both assuming a configuration state datastore in which one instance is "config true tagged empheral" and a second instance is tagged "config" without the empheral tag? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Friday, September 12, 2014 5:22 PM To: i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt Thanks for doing this Jeff. It is a great start. The Object Relationships issue does need more work however. Some of the cases are handled... YANG's tools for reuse can be used to meet the inheritance requirements. I think that the requires and when clauses are probably powerful enough to meet the architecture requirements for optionality (arch 6.4.5.2). I do not know of anything in YANG that corresponds to agent side templating, as was agreed by the working group and captured in arch 6.4.5.3. (Since I am one who argued against this, if we need more detailed examples I would appreciate some assistance.) The object relationships are three piece. Arch 6.4.5.4.2 on correlation and arch 6.4.5.4.3 on actual references seem to be covered by various parts of YANG. But the initialization reference described in arch 6.4.5.4.1 does not correspond to anything I know of in YANG. Is there a YANG tool for that? This is the case where the definition of an object Foo says that whenever a new Foo is created, it takes its initial values from an instance of Bar, so as to simplify instantiation. This is similar too, but not the same as the templates material. You talk about the priority requirements. You should probably mention the multi-headed behavioral requirements there (as I think that the resolutions will be tightly coupled.) Section 7.9 of the archtiecture document talks about several transactional scopes. The text you have does not seem to deal with all of these. Does YANG handle them all easily? Yours, Joel On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : I2RS requirements for netmod/netconf > Author : Jeffrey Haas > Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt > Pages : 10 > Date : 2014-09-12 > > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support requirements to implement the > I2RS architecture. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requir > ements/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements > -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 > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Sep 17 16:25: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 ED7D71A070F for ; Wed, 17 Sep 2014 16:25:35 -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 q5XrvkCP3Jdw for ; Wed, 17 Sep 2014 16:25:34 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2E1A0AF6 for ; Wed, 17 Sep 2014 16:25:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Andy Bierman'" References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> <20140915180109.GK14947@pfrc> In-Reply-To: <20140915180109.GK14947@pfrc> Date: Wed, 17 Sep 2014 19:25:29 -0400 Message-ID: <001701cfd2ce$ab7c4de0$0274e9a0$@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: AQG2k1L3up2v+fcxTpS95jZoEMUpRQDPM7Y9AgnlswgB2gVIcpwS2zuw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/6MaD4IIxwIZViathUuQBWA3yg3s Cc: i2rs@ietf.org, "'Joel M. Halpern'" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Wed, 17 Sep 2014 23:25:36 -0000 Jeff: In the discussion of the requirements (draft-hares-i2rs-usecase-reqs-summary-00) BGP-REQ02, BGP-REQ05, BGP-REQ07, and BGP-REQ13 (see below for reference) could need to custom cost communities, traffic flow specifications, and BGP policies into running BGP nodes. When you say "no configuration" then my understanding is that the I2RS agent bypasses the "local" config and goes directly to the routing module to change these policies. Is this what you mean by "no local configuration? Sue ------ o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with custom cost communities to specific I2RS agents on BGP routers for insertion in specific BGP Peer(s) to aid Traffic engineering of data paths. These routes SHOULD be tracked by the I2RS Agent as specific BGP routes with customer cost communities. These routes (will/will not) installed via the RIB-Info. o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow specifications to I2RS Agents that will install them in associated BGP ASBRs and the PE routers. o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS client being able to prioritize and control BGP's announcement of flow specifications after status information reading BGP ASBR and PE router's capacity. BGP ASBRs and PE routers functions within a router MAY forward traffic flow specifications received from EBGP speakers to I2RS agents, so the I2RS Agent SHOULD be able to send these flow specifications from EBGP sources to a client in response to a read or notification. o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to write BGP Policies into the running BGP protocols and into the BGP configurations. -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 15, 2014 2:01 PM To: Andy Bierman Cc: i2rs@ietf.org; Joel M. Halpern Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > There is nothing in YANG or RESTCONF to support it (yet). > For some features the I2RS agent is supposedly simple and mostly stateless. > This template service does not seem to fit with that theme. Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference. The tension seems to lie roughly along two points of view: 1. This is a programmatically driven API environment. As such, there's little excuse to not simply send everything needed as a large configuration block - templates are extraneous. 2. By permitting templates, you enable much smaller transactions. You also potentially allow for a stronger security model by "locking down" stuff outside of the template. To offer a somewhat concrete example, consider an application for provisioning L3VPN customers. Some minimum required configuration on a per-device basis includes: VRF name. A route-distinguisher. A route-target for the VPN. Customer PE-CE protocol and endpoint configuration. Fully expanded, this is probably a few dozens of lines of configuration in YANG. What's interesting is that the above information is potentially generic related to that configuration, which may have per-device variance - potentially based upon vendor. Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted. > Are these templates ephemeral? That would be annoying. They are not > straight config, so a new a configuration data model is needed to > manage the templates. > New protocol mechanisms to use templates in addition to payload data > will be needed. All agreed. > > You talk about the priority requirements. You should probably > > mention the multi-headed behavioral requirements there (as I think > > that the resolutions will be tightly coupled.) > > > > Section 7.9 of the archtiecture document talks about several > > transactional scopes. The text you have does not seem to deal with > > all of these. Does YANG handle them all easily? > > > > I would need to review this again -- I don't remember any problems > last time I read the arch draft. Some of this is a matter of where this information lives. For tie-breaking of ephemeral vs. static config, is this provisioned per-module or per element in the module? Are there explicit lines of YANG in each module for this? For tie-breaking user priorities, NACM extensions may make sense. This particular state is effectively meta-data on the ephemeral config. Since the epehemeral state is "highest priority wins", but there's no requirement that the lower priority state is kept in any fashion, how do we deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state? > I am confused about some text in the draft about ephemeral config: > > In 2.1: > > The author wishes to > prevent any action that would lead to preserving any configuration > state entered via the I2RS agent across reboots. If state has to be > restored, it should be solely by replay actions from I2RS client via > I2RS agent. > > > Why does the author wish to prevent NV-storage of the I2RS data? > What is it about the accidental reboot of the router that makes it the > I2RS data needed before the accidental reboot, but not after? I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored? > If the reason is because I2RS agents are simple and NV-storage is not > simple, then why does the agent need to support templates? This is more a "clean slate" decision. When the device comes up, it has no I2RS state. Note that the fully ephemeral nature of I2RS still doesn't feel fully-settled in the WG. See prior thread comments about wanting to do copy-config on it. :-) > This section might mention that the I2RS datastore has its own access > control model, that is not the same as the running config. > > 2. Configuration state in the existing running datastore where the > module is "tagged ephemeral". > > 3. Permitting existing configuration to be optionally configured as > ephemeral. As an example, the NETCONF server advertises in its > message if it supports the specified YANG module > persistently and/or ephemerally. > > > > I thought the I2RS charter said I2RS was not altering the local config. Correct. > Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)? For point 2, it'd be identifying I2RS modules (having the ephemeral properties) in the YANG. Point 3 is submitted as an option based on comments at the last IETF netmod session where someone else indicated being able to store things ephemerally would potentially be useful. If this is indeed a wider use case, let's discuss it. > This does not really work because YANG validation may fail without > some config data that has been tagged "do not save". If the router > reboots and the startup config does not validate, it is probably > wedged. It can't really fall back to a "known good config" > if I2RS has forced some of the data to be omitted from the saved config. Agreed. See also the priority discussion above. > In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral", then I2RS is gated on the completion of YANG 1.1 (and > development of YANG > 1.1 tools). > Are you really sure you want that? That's why a YANG extension was > suggested instead (or maybe do both). Worth discussing during the interim. It has been suggested to me that many of the above properties can already be implemented in a proprietary manner with no language extensions. They would simply not be either interoperable or clear about their ephemeral nature based on module contents. So, we're looking for a balance of expeditious and correct for the long term maintainenace of the protocols and YANG. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Sep 17 17:07: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 0168D1A0387; Wed, 17 Sep 2014 17:07:36 -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 IzBv2iVjOPQK; Wed, 17 Sep 2014 17:07:31 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 83F9D1A6EED; Wed, 17 Sep 2014 17:07:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeffrey Haas'" , , References: <20140912210913.GA10692@pfrc> In-Reply-To: <20140912210913.GA10692@pfrc> Date: Wed, 17 Sep 2014 20:07:27 -0400 Message-ID: <002601cfd2d4$88acf610$9a06e230$@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: AQF152CPuE+kSzEZATJqaJUcwSLQn5y50NtQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Du2UIKFpbYuMG2yCJsyprcNElWg Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Thu, 18 Sep 2014 00:07:38 -0000 Jeff: In section 2.6.1, you indicate the notification must "specify type and various parameters for the endpoint session" - is this a new configuration that is I2RS and empheral or is it a part of the netconf event configuration that would need to be added? Same question for the filters in 2.6.2? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, September 12, 2014 5:09 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf. It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve interested parties. As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus. At best, it reflects my attempt to summarize prior discussions and turn them into requirements. This document will most assuredly be wrong and be revised. But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week. My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out. Comments are appreciated. Flames are not unexpected. -- Jeff New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements / There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Sep 17 17:20: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 76DBE1A6F11; Wed, 17 Sep 2014 17:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEYxjfEroT4M; Wed, 17 Sep 2014 17:20:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 213D81A6EFC; Wed, 17 Sep 2014 17:20:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeffrey Haas'" , , References: <20140912210913.GA10692@pfrc> In-Reply-To: <20140912210913.GA10692@pfrc> Date: Wed, 17 Sep 2014 20:20:16 -0400 Message-ID: <002b01cfd2d6$5316a120$f943e360$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CFD2B4.CC074B10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQn5y52lJg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/BlcXPytybQJfEc6zjJyuvlimajY Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Thu, 18 Sep 2014 00:20:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01CFD2B4.CC074B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: With I2RS datastore (empheral) and I2RS Config there is always a chance that two different actions will change the same data. Take the example config you use in section 2.7 and assume that both I2rs and normal config want to modify this bgp config in the bgp routing process. First - do you think this is possible? If you do then section 2.7's atomic transactions will need to be augmented to indicate the interaction priority between the following different events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (rollback). I define interaction priority as the priority (interrupt or sequencing) when one of these events overlaps with another. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, September 12, 2014 5:09 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf. It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve interested parties. As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus. At best, it reflects my attempt to summarize prior discussions and turn them into requirements. This document will most assuredly be wrong and be revised. But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week. My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out. Comments are appreciated. Flames are not unexpected. -- Jeff New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements / There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_002C_01CFD2B4.CC074B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

With = I2RS datastore (empheral) and I2RS Config there is always a chance that = two different actions will change the same data.  Take the example = config you use in section 2.7 and assume that both I2rs and normal = config want to modify this bgp config in the bgp routing process.  =  First – do you think this is possible? =  

 

If you do then section 2.7’s atomic = transactions will need to be augmented to indicate the interaction = priority between the following different events I2RS (valid), I2RS = (invalid/roll-back), config (valid), config (rollback).   I = define interaction priority as the priority (interrupt or sequencing) = when one of these events overlaps with another.

 

Sue

=

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: = Friday, September 12, 2014 5:09 PM
To: i2rs@ietf.org; = netmod@ietf.org
Subject: [i2rs] I2RS requests to netmod/netconf (was = netmod interim and i2rs requirements)

 

With = some help from Kent, Dean and Alia, I've put together a rough first = draft of requirements I2RS has on netmod/netconf.  It should be = strongly noted that due to a confluence of a lot of bad timing (travel, = vacation,

etc.) I didn't have time = to more broadly reach out and involve interested = parties.

 

As such, please note that this draft is not an I2RS = WG draft and does not have current WG consensus.  At best, it = reflects my attempt to summarize prior discussions and turn them into = requirements.  This document will most assuredly be wrong and be = revised.

 

But it's primary purpose was to provide a start of = the discussion of I2RS requirements at the netmod interim meeting next = week.

 

My abject apologies to the I2RS and netmod working = groups - this was the fastest I could get the text out.

 

Comments are appreciated.  Flames are not = unexpected.

 

-- = Jeff

 

 

 

New = Internet-Draft is available from the on-line Internet-Drafts = directories.

 

 

        = Title           : I2RS = requirements for netmod/netconf

        = Author          : Jeffrey = Haas

        = Filename        : = draft-haas-i2rs-netmod-netconf-requirements-00.txt

        = Pages           : = 10

        = Date            : = 2014-09-12

 

Abstract:

   This document covers requests to the = netmod and netconf Working

   Groups for functionality to support = requirements to implement the

   I2RS architecture.

 

 

The = IETF datatracker status page for this draft is:

https://datatracker.ietf.= org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 

There's also a htmlized version available = at:

http://tools.ietf.org/htm= l/draft-haas-i2rs-netmod-netconf-requirements-00

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_002C_01CFD2B4.CC074B10-- From nobody Thu Sep 18 04:09: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 6F5B81A8768; Thu, 18 Sep 2014 04:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, 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 njGYAr1QDAP7; Thu, 18 Sep 2014 04:08:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19A1A8767; Thu, 18 Sep 2014 04:08:54 -0700 (PDT) Received: from [10.130.39.167] (mobile-198-228-198-084.mycingular.net [198.228.198.84]) by slice.pfrc.org (Postfix) with ESMTPSA id E9B80C3F6; Thu, 18 Sep 2014 07:08:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Haas X-Mailer: iPhone Mail (11D257) In-Reply-To: <002601cfd2d4$88acf610$9a06e230$@ndzh.com> Date: Thu, 18 Sep 2014 07:08:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA78568-8684-4CFB-83B3-BBA903334750@pfrc.org> References: <20140912210913.GA10692@pfrc> <002601cfd2d4$88acf610$9a06e230$@ndzh.com> To: Susan Hares Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ekrHDmrw0vjGtCSxF3b0iSrJP5w Cc: "" , "" Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Thu, 18 Sep 2014 11:09:00 -0000 Sue, Such endpoint and filtering behavior, while necessary for i2rs, may be gener= ally useful. I expect good discussion about it at today's interim session.=20= Jeff > On Sep 17, 2014, at 20:07, "Susan Hares" wrote: >=20 > Jeff: >=20 > In section 2.6.1, you indicate the notification must "specify type and > various parameters for the endpoint session" - is this a new configuration= > that is I2RS and empheral or is it a part of the netconf event configurati= on > that would need to be added? Same question for the filters in 2.6.2?=20= >=20 > Sue=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Friday, September 12, 2014 5:09 PM > To: i2rs@ietf.org; netmod@ietf.org > Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2= rs > requirements) >=20 > With some help from Kent, Dean and Alia, I've put together a rough first > draft of requirements I2RS has on netmod/netconf. It should be strongly > noted that due to a confluence of a lot of bad timing (travel, vacation, > etc.) I didn't have time to more broadly reach out and involve interested > parties. >=20 > As such, please note that this draft is not an I2RS WG draft and does not > have current WG consensus. At best, it reflects my attempt to summarize > prior discussions and turn them into requirements. This document will mos= t > assuredly be wrong and be revised. >=20 > But it's primary purpose was to provide a start of the discussion of I2RS > requirements at the netmod interim meeting next week. >=20 > My abject apologies to the I2RS and netmod working groups - this was the > fastest I could get the text out. >=20 > Comments are appreciated. Flames are not unexpected. >=20 > -- Jeff >=20 >=20 >=20 > New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : I2RS requirements for netmod/netconf > Author : Jeffrey Haas > Filename : draft-haas-i2rs-netmod-netconf-requirements-00.tx= t > Pages : 10 > Date : 2014-09-12 >=20 > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support requirements to implement the > I2RS architecture. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts > / >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Sep 18 04:12: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 EA67E1A86DD; Thu, 18 Sep 2014 04:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.652, 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 xG1Hz3dVofLz; Thu, 18 Sep 2014 04:12:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3111A01D8; Thu, 18 Sep 2014 04:12:15 -0700 (PDT) Received: from [10.130.39.167] (mobile-198-228-198-084.mycingular.net [198.228.198.84]) by slice.pfrc.org (Postfix) with ESMTPSA id 9953FC3F6; Thu, 18 Sep 2014 07:12:14 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12 Mime-Version: 1.0 (1.0) From: Jeff Haas X-Mailer: iPhone Mail (11D257) In-Reply-To: <002b01cfd2d6$5316a120$f943e360$@ndzh.com> Date: Thu, 18 Sep 2014 07:12:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> To: Susan Hares Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ylAXIwNl2uCSnVT5ONP6QCBRZV0 Cc: "" , "" Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Thu, 18 Sep 2014 11:12:19 -0000 --Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sue, My expectation for such a scenario is that for overlapping config for the sa= me state that BGP will have its neighbor configuration in an IDR defined dat= a model. I2rs will have separate neighbor configuration. In such a case prio= rity is expected to arbitrate the tie breaking.=20 Jeff > On Sep 17, 2014, at 20:20, "Susan Hares" wrote: >=20 > Jeff: > =20 > With I2RS datastore (empheral) and I2RS Config there is always a chance th= at two different actions will change the same data. Take the example config= you use in section 2.7 and assume that both I2rs and normal config want to m= odify this bgp config in the bgp routing process. First =E2=80=93 do you t= hink this is possible? =20 > =20 > If you do then section 2.7=E2=80=99s atomic transactions will need to be a= ugmented to indicate the interaction priority between the following differen= t events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (rol= lback). I define interaction priority as the priority (interrupt or sequen= cing) when one of these events overlaps with another. > =20 > Sue > =20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Friday, September 12, 2014 5:09 PM > To: i2rs@ietf.org; netmod@ietf.org > Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2= rs requirements) > =20 > With some help from Kent, Dean and Alia, I've put together a rough first d= raft of requirements I2RS has on netmod/netconf. It should be strongly note= d that due to a confluence of a lot of bad timing (travel, vacation, > etc.) I didn't have time to more broadly reach out and involve interested p= arties. > =20 > As such, please note that this draft is not an I2RS WG draft and does not h= ave current WG consensus. At best, it reflects my attempt to summarize prio= r discussions and turn them into requirements. This document will most assu= redly be wrong and be revised. > =20 > But it's primary purpose was to provide a start of the discussion of I2RS r= equirements at the netmod interim meeting next week. > =20 > My abject apologies to the I2RS and netmod working groups - this was the f= astest I could get the text out. > =20 > Comments are appreciated. Flames are not unexpected. > =20 > -- Jeff > =20 > =20 > =20 > New Internet-Draft is available from the on-line Internet-Drafts directori= es. > =20 > =20 > Title : I2RS requirements for netmod/netconf > Author : Jeffrey Haas > Filename : draft-haas-i2rs-netmod-netconf-requirements-00.t= xt > Pages : 10 > Date : 2014-09-12 > =20 > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support requirements to implement the > I2RS architecture. > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts/ > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sue,

My expec= tation for such a scenario is that for overlapping config for the same state= that BGP will have its neighbor configuration in an IDR defined data model.= I2rs will have separate neighbor configuration. In such a case priority is e= xpected to arbitrate the tie breaking. 

Jeff

On Se= p 17, 2014, at 20:20, "Susan Hares" <s= hares@ndzh.com> wrote:

Jeff:

 <= /p>

With I2RS datastore (empheral) and I2RS Config t= here is always a chance that two different actions will change the same data= .  Take the example config you use in section 2.7 and assume that both I= 2rs and normal config want to modify this bgp config in the bgp routing proc= ess.   First =E2=80=93 do you think this is possible?  <= /o:p>

 

If you do then section 2.7=E2=80=99s atomic transactions will need to b= e augmented to indicate the interaction priority between the following diffe= rent events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (= rollback).   I define interaction priority as the priority (interr= upt or sequencing) when one of these events overlaps with another.

 

Sue

 

-----Original Me= ssage-----
From: i2rs [mailto:i2= rs-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Friday, Septembe= r 12, 2014 5:09 PM
To: i2rs@ietf.org= ; netmod@ietf.org
Subject: [i2rs] I= 2RS requests to netmod/netconf (was netmod interim and i2rs requirements)

 

Wi= th some help from Kent, Dean and Alia, I've put together a rough first draft= of requirements I2RS has on netmod/netconf.  It should be strongly not= ed that due to a confluence of a lot of bad timing (travel, vacation,

etc.) I didn't have time to more broadly r= each out and involve interested parties.

 

As such, please note tha= t this draft is not an I2RS WG draft and does not have current WG consensus.=   At best, it reflects my attempt to summarize prior discussions and tu= rn them into requirements.  This document will most assuredly be wrong a= nd be revised.

 

=

But it's primary purpose was to provide a start of= the discussion of I2RS requirements at the netmod interim meeting next week= .

 

My abject apologies to the I2RS and netmod working groups - thi= s was the fastest I could get the text out.

 

Comments are apprecia= ted.  Flames are not unexpected.

 

-- Jeff

 

&nb= sp;

 

New Internet-Draft is available from the on-line Internet-Drafts d= irectories.

 

 

 &= nbsp;      Title      = ;     : I2RS requirements for netmod/netconf<= /p>

        Auth= or          : Jeffrey Haas=

      &nbs= p; Filename        : draft-haas-i2rs-netm= od-netconf-requirements-00.txt

 = ;       Pages     &nb= sp;     : 10

&nb= sp;       Date     &n= bsp;      : 2014-09-12

 

Abstract:

   This document covers requests t= o the netmod and netconf Working

&nb= sp;  Groups for functionality to support requirements to implement the<= o:p>

   I2RS architecture.=

 

 

The IETF datatracker s= tatus page for this draft is:

https://datatr= acker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 

There's also a htmlized version available at:

http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requiremen= ts-00

 

_______________________________________________<= o:p>

i2rs mailing list

i2rs@ietf.org

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

= --Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12-- From nobody Thu Sep 18 07:55:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5E21A8835 for ; Thu, 18 Sep 2014 07:55:56 -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 0cvpBOXlYvju for ; Thu, 18 Sep 2014 07:55:54 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794A31A0113 for ; Thu, 18 Sep 2014 07:55:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 432121BC6CC6; Thu, 18 Sep 2014 07:55:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (aptilo2-usaa.ericsson.net [129.192.185.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CE5861BC6CC0; Thu, 18 Sep 2014 07:55:43 -0700 (PDT) Message-ID: <541AF26E.7050801@joelhalpern.com> Date: Thu, 18 Sep 2014 10:55:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , i2rs@ietf.org References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> <001201cfd2cc$e3b3b380$ab1b1a80$@ndzh.com> In-Reply-To: <001201cfd2cc$e3b3b380$ab1b1a80$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_CPJdm23nf2mrZlc-Qt0PWlJpBk Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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, 18 Sep 2014 14:55:57 -0000 There may be some restrictions on the use of those keywords that I missed. But from what I can tell. those tools let us say that item A references and uses the values from item B. (The require part is not actually spelled out in our requirements, but is a useful tool.) This seems to match teh primary mode we called for. It does not handle some of the other cases. I don't think this has anything to do with ephemeral vs config vs operational. Yours, Joel On 9/17/14, 7:12 PM, Susan Hares wrote: > Joel and Jeff: > > Can you comment on why and why not you consider "instance-identifier" and > "require-instance" yang key words to satisfying the requirements for object > relationship requirements? Are you both assuming a configuration state > datastore in which one instance is "config true tagged empheral" and a > second instance is tagged "config" without the empheral tag? > > Sue > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, September 12, 2014 5:22 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] I-D Action: > draft-haas-i2rs-netmod-netconf-requirements-00.txt > > Thanks for doing this Jeff. It is a great start. > > The Object Relationships issue does need more work however. > Some of the cases are handled... > > YANG's tools for reuse can be used to meet the inheritance requirements. > I think that the requires and when clauses are probably powerful enough to > meet the architecture requirements for optionality (arch 6.4.5.2). > > I do not know of anything in YANG that corresponds to agent side templating, > as was agreed by the working group and captured in arch 6.4.5.3. (Since I > am one who argued against this, if we need more detailed examples I would > appreciate some assistance.) > > The object relationships are three piece. Arch 6.4.5.4.2 on correlation and > arch 6.4.5.4.3 on actual references seem to be covered by various parts of > YANG. But the initialization reference described in arch > 6.4.5.4.1 does not correspond to anything I know of in YANG. Is there a > YANG tool for that? This is the case where the definition of an object Foo > says that whenever a new Foo is created, it takes its initial values from an > instance of Bar, so as to simplify instantiation. This is similar too, but > not the same as the templates material. > > You talk about the priority requirements. You should probably mention the > multi-headed behavioral requirements there (as I think that the resolutions > will be tightly coupled.) > > Section 7.9 of the archtiecture document talks about several transactional > scopes. The text you have does not seem to deal with all of these. Does > YANG handle them all easily? > > Yours, > Joel > > On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : I2RS requirements for netmod/netconf >> Author : Jeffrey Haas >> Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt >> Pages : 10 >> Date : 2014-09-12 >> >> Abstract: >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support requirements to implement the >> I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requir >> ements/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements >> -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 >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu Sep 18 08:05: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 B54911A065B for ; Thu, 18 Sep 2014 08:05:31 -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 Ny3d9ccB5gyt for ; Thu, 18 Sep 2014 08:05:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D41A058E for ; Thu, 18 Sep 2014 08:05:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Joel M. Halpern'" , References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> <001201cfd2cc$e3b3b380$ab1b1a80$@ndzh.com> <541AF26E.7050801@joelhalpern.com> In-Reply-To: <541AF26E.7050801@joelhalpern.com> Date: Thu, 18 Sep 2014 11:04:27 -0400 Message-ID: <01ca01cfd351$d7c72cc0$87558640$@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: AQG2k1L3up2v+fcxTpS95jZoEMUpRQDPM7Y9Aiof728CSzyI+5wPVteA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/p2gYz-ej2is98p-z2xI5Gcud3S8 Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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, 18 Sep 2014 15:05:32 -0000 Joel: You have understood my question - is section 2.8 orthogonal to the 3 options in 2.1? The language in option 3 could imply an instance. Section 2.8 was vague so I wanted Jeff's clarification. Sue -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Thursday, September 18, 2014 10:56 AM To: Susan Hares; i2rs@ietf.org Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt There may be some restrictions on the use of those keywords that I missed. But from what I can tell. those tools let us say that item A references and uses the values from item B. (The require part is not actually spelled out in our requirements, but is a useful tool.) This seems to match teh primary mode we called for. It does not handle some of the other cases. I don't think this has anything to do with ephemeral vs config vs operational. Yours, Joel On 9/17/14, 7:12 PM, Susan Hares wrote: > Joel and Jeff: > > Can you comment on why and why not you consider "instance-identifier" > and "require-instance" yang key words to satisfying the requirements > for object relationship requirements? Are you both assuming a > configuration state datastore in which one instance is "config true > tagged empheral" and a second instance is tagged "config" without the empheral tag? > > Sue > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Friday, September 12, 2014 5:22 PM > To: i2rs@ietf.org > Subject: Re: [i2rs] I-D Action: > draft-haas-i2rs-netmod-netconf-requirements-00.txt > > Thanks for doing this Jeff. It is a great start. > > The Object Relationships issue does need more work however. > Some of the cases are handled... > > YANG's tools for reuse can be used to meet the inheritance requirements. > I think that the requires and when clauses are probably powerful > enough to meet the architecture requirements for optionality (arch 6.4.5.2). > > I do not know of anything in YANG that corresponds to agent side > templating, as was agreed by the working group and captured in arch > 6.4.5.3. (Since I am one who argued against this, if we need more > detailed examples I would appreciate some assistance.) > > The object relationships are three piece. Arch 6.4.5.4.2 on > correlation and arch 6.4.5.4.3 on actual references seem to be covered > by various parts of YANG. But the initialization reference described > in arch > 6.4.5.4.1 does not correspond to anything I know of in YANG. Is there > a YANG tool for that? This is the case where the definition of an > object Foo says that whenever a new Foo is created, it takes its > initial values from an instance of Bar, so as to simplify > instantiation. This is similar too, but not the same as the templates material. > > You talk about the priority requirements. You should probably mention > the multi-headed behavioral requirements there (as I think that the > resolutions will be tightly coupled.) > > Section 7.9 of the archtiecture document talks about several > transactional scopes. The text you have does not seem to deal with > all of these. Does YANG handle them all easily? > > Yours, > Joel > > On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : I2RS requirements for netmod/netconf >> Author : Jeffrey Haas >> Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt >> Pages : 10 >> Date : 2014-09-12 >> >> Abstract: >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support requirements to implement the >> I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requi >> r >> ements/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirement >> s >> -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 >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu Sep 18 08:39: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 DA4221A884C for ; Thu, 18 Sep 2014 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KuzoB5AqGlkI for ; Thu, 18 Sep 2014 08:39:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327911A8844 for ; Thu, 18 Sep 2014 08:39:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 156CA1C00F9; Thu, 18 Sep 2014 08:39:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (aptilo2-usaa.ericsson.net [129.192.185.163]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 6F5B71C00E5; Thu, 18 Sep 2014 08:39:43 -0700 (PDT) Message-ID: <541AFCBE.3090408@joelhalpern.com> Date: Thu, 18 Sep 2014 11:39:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Susan Hares , i2rs@ietf.org References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> <001201cfd2cc$e3b3b380$ab1b1a80$@ndzh.com> <541AF26E.7050801@joelhalpern.com> <01ca01cfd351$d7c72cc0$87558640$@ndzh.com> In-Reply-To: <01ca01cfd351$d7c72cc0$87558640$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/psSmrQBqfKeMBHiBuRuUC3vlcfY Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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, 18 Sep 2014 15:39:46 -0000 As I understand it, 2.8 is orthogonal to 2.1 of Jeff's draft. As I said separately, 2.8 is correct for some of what we want, and incorrect for other aspects we as a WG have agreed to. I am confident that those other aspects can be addressed. Yours, Joel On 9/18/14, 11:04 AM, Susan Hares wrote: > Joel: > > You have understood my question - is section 2.8 orthogonal to the 3 options > in 2.1? The language in option 3 could imply an instance. Section 2.8 was > vague so I wanted Jeff's clarification. > > Sue > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, September 18, 2014 10:56 AM > To: Susan Hares; i2rs@ietf.org > Subject: Re: [i2rs] I-D Action: > draft-haas-i2rs-netmod-netconf-requirements-00.txt > > There may be some restrictions on the use of those keywords that I missed. > But from what I can tell. those tools let us say that item A references and > uses the values from item B. (The require part is not actually spelled out > in our requirements, but is a useful tool.) This seems to match teh primary > mode we called for. It does not handle some of the other cases. I don't > think this has anything to do with ephemeral vs config vs operational. > > Yours, > Joel > > On 9/17/14, 7:12 PM, Susan Hares wrote: >> Joel and Jeff: >> >> Can you comment on why and why not you consider "instance-identifier" >> and "require-instance" yang key words to satisfying the requirements >> for object relationship requirements? Are you both assuming a >> configuration state datastore in which one instance is "config true >> tagged empheral" and a second instance is tagged "config" without the > empheral tag? >> >> Sue >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Friday, September 12, 2014 5:22 PM >> To: i2rs@ietf.org >> Subject: Re: [i2rs] I-D Action: >> draft-haas-i2rs-netmod-netconf-requirements-00.txt >> >> Thanks for doing this Jeff. It is a great start. >> >> The Object Relationships issue does need more work however. >> Some of the cases are handled... >> >> YANG's tools for reuse can be used to meet the inheritance requirements. >> I think that the requires and when clauses are probably powerful >> enough to meet the architecture requirements for optionality (arch > 6.4.5.2). >> >> I do not know of anything in YANG that corresponds to agent side >> templating, as was agreed by the working group and captured in arch >> 6.4.5.3. (Since I am one who argued against this, if we need more >> detailed examples I would appreciate some assistance.) >> >> The object relationships are three piece. Arch 6.4.5.4.2 on >> correlation and arch 6.4.5.4.3 on actual references seem to be covered >> by various parts of YANG. But the initialization reference described >> in arch >> 6.4.5.4.1 does not correspond to anything I know of in YANG. Is there >> a YANG tool for that? This is the case where the definition of an >> object Foo says that whenever a new Foo is created, it takes its >> initial values from an instance of Bar, so as to simplify >> instantiation. This is similar too, but not the same as the templates > material. >> >> You talk about the priority requirements. You should probably mention >> the multi-headed behavioral requirements there (as I think that the >> resolutions will be tightly coupled.) >> >> Section 7.9 of the archtiecture document talks about several >> transactional scopes. The text you have does not seem to deal with >> all of these. Does YANG handle them all easily? >> >> Yours, >> Joel >> >> On 9/12/14, 4:59 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> >>> >>> Title : I2RS requirements for netmod/netconf >>> Author : Jeffrey Haas >>> Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt >>> Pages : 10 >>> Date : 2014-09-12 >>> >>> Abstract: >>> This document covers requests to the netmod and netconf Working >>> Groups for functionality to support requirements to implement the >>> I2RS architecture. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requi >>> r >>> ements/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirement >>> s >>> -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 >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > From nobody Thu Sep 18 09:59: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 092AF1A04E7; Thu, 18 Sep 2014 09:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZcMiTZ1fCHl; Thu, 18 Sep 2014 09: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 B1C451A04A1; Thu, 18 Sep 2014 09:58:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeff Haas'" References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> In-Reply-To: Date: Thu, 18 Sep 2014 12:58:51 -0400 Message-ID: <004601cfd361$d2cbe520$7863af60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01CFD340.4BBCDD30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQnwIbKt3gAQ37k3mcoapM8A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/c8cmx6ZANGwjEYmIsCiXHSPbu5Y Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Thu, 18 Sep 2014 16:59:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0047_01CFD340.4BBCDD30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff: =20 Where does the priority live =E2=80=93 in I2RS or in config module or in = BGP routing model? How does this work with the three datastore = proposals: 1) separate empheral data store, 2) configuration state in = existing datastore tagged by model as empheral, and 3) whole data stores = tagged empheral, config, or both. Is the routing code that sets the = priority and handles the rollback?=20 =20 Config datastore ----------------routing bgp code=20 | I2rs instance/datastore --------------- =20 =20 Sue=20 =20 From: Jeff Haas [mailto:jhaas@pfrc.org]=20 Sent: Thursday, September 18, 2014 7:12 AM To: Susan Hares Cc: ; Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim = and i2rs requirements) =20 Sue, =20 My expectation for such a scenario is that for overlapping config for = the same state that BGP will have its neighbor configuration in an IDR = defined data model. I2rs will have separate neighbor configuration. In = such a case priority is expected to arbitrate the tie breaking.=20 Jeff On Sep 17, 2014, at 20:20, "Susan Hares" wrote: Jeff: =20 With I2RS datastore (empheral) and I2RS Config there is always a chance = that two different actions will change the same data. Take the example = config you use in section 2.7 and assume that both I2rs and normal = config want to modify this bgp config in the bgp routing process. = First =E2=80=93 do you think this is possible? =20 =20 If you do then section 2.7=E2=80=99s atomic transactions will need to be = augmented to indicate the interaction priority between the following = different events I2RS (valid), I2RS (invalid/roll-back), config (valid), = config (rollback). I define interaction priority as the priority = (interrupt or sequencing) when one of these events overlaps with = another.=20 =20 Sue =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, September 12, 2014 5:09 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and = i2rs requirements) =20 With some help from Kent, Dean and Alia, I've put together a rough first = draft of requirements I2RS has on netmod/netconf. It should be strongly = noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve = interested parties. =20 As such, please note that this draft is not an I2RS WG draft and does = not have current WG consensus. At best, it reflects my attempt to = summarize prior discussions and turn them into requirements. This = document will most assuredly be wrong and be revised. =20 But it's primary purpose was to provide a start of the discussion of = I2RS requirements at the netmod interim meeting next week. =20 My abject apologies to the I2RS and netmod working groups - this was the = fastest I could get the text out. =20 Comments are appreciated. Flames are not unexpected. =20 -- Jeff =20 =20 =20 New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : = draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 =20 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. =20 =20 The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requireme= nts/ =20 There's also a htmlized version available at: = = http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00= =20 _______________________________________________ i2rs mailing list i2rs@ietf.org = https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0047_01CFD340.4BBCDD30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Where does the priority = live =E2=80=93 in I2RS or in config module or in BGP routing model? = =C2=A0How does this work with the three datastore proposals: 1) separate = empheral data store, 2) configuration state in existing datastore tagged = by model as empheral, and 3) whole data stores tagged empheral, config, = or both. =C2=A0=C2=A0Is the routing code that sets the priority and = handles the rollback?

 

Config datastore = ----------------routing bgp code

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=

I2rs instance/datastore = ---------------

 

 

Sue =

 

From:= = Jeff Haas [mailto:jhaas@pfrc.org]
Sent: Thursday, September = 18, 2014 7:12 AM
To: Susan Hares
Cc: = <i2rs@ietf.org>; <netmod@ietf.org>
Subject: Re: = [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs = requirements)

 

Sue,

 

My expectation for such a scenario is that for = overlapping config for the same state that BGP will have its neighbor = configuration in an IDR defined data model. I2rs will have separate = neighbor configuration. In such a case priority is expected to arbitrate = the tie breaking. 

Jeff


On Sep 17, 2014, at = 20:20, "Susan Hares" <shares@ndzh.com> = wrote:

Jeff:

 

With = I2RS datastore (empheral) and I2RS Config there is always a chance that = two different actions will change the same data.  Take the example = config you use in section 2.7 and assume that both I2rs and normal = config want to modify this bgp config in the bgp routing process.  =  First =E2=80=93 do you think this is possible? =  

 

If you do then section 2.7=E2=80=99s atomic = transactions will need to be augmented to indicate the interaction = priority between the following different events I2RS (valid), I2RS = (invalid/roll-back), config (valid), config (rollback).   I = define interaction priority as the priority (interrupt or sequencing) = when one of these events overlaps with another.

 

Sue

 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Jeffrey Haas
Sent: Friday, September 12, 2014 5:09 = PM
To: i2rs@ietf.org; netmod@ietf.org
Subject: [i2rs] = I2RS requests to netmod/netconf (was netmod interim and i2rs = requirements)

 

With = some help from Kent, Dean and Alia, I've put together a rough first = draft of requirements I2RS has on netmod/netconf.  It should be = strongly noted that due to a confluence of a lot of bad timing (travel, = vacation,

etc.) I didn't have time = to more broadly reach out and involve interested = parties.

 

As such, please note that this draft is not an I2RS = WG draft and does not have current WG consensus.  At best, it = reflects my attempt to summarize prior discussions and turn them into = requirements.  This document will most assuredly be wrong and be = revised.

 

But it's primary purpose was to provide a start of = the discussion of I2RS requirements at the netmod interim meeting next = week.

 

My abject apologies to the I2RS and netmod working = groups - this was the fastest I could get the text out.

 

Comments are appreciated.  Flames are not = unexpected.

 

-- = Jeff

 

 

 

New = Internet-Draft is available from the on-line Internet-Drafts = directories.

 

 

        = Title           : I2RS = requirements for netmod/netconf

        = Author          : Jeffrey = Haas

        = Filename        : = draft-haas-i2rs-netmod-netconf-requirements-00.txt

        = Pages           : = 10

        = Date            : = 2014-09-12

 

Abstract:

   This document covers requests to the = netmod and netconf Working

   Groups for functionality to support = requirements to implement the

   I2RS architecture.

 

 

The = IETF datatracker status page for this draft is:

https://datatracker.ietf.= org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 

There's also a htmlized version available = at:

http://tools.ietf.org/htm= l/draft-haas-i2rs-netmod-netconf-requirements-00

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0047_01CFD340.4BBCDD30-- From nobody Mon Sep 22 13:02: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 362231A1BAA; Mon, 22 Sep 2014 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u7D3kTQf5DF; Mon, 22 Sep 2014 13:01:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 348DC1A1B63; Mon, 22 Sep 2014 13:01:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 00E91C296; Mon, 22 Sep 2014 16:01:54 -0400 (EDT) Date: Mon, 22 Sep 2014 16:01:54 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140922200154.GG6550@pfrc> References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004601cfd361$d2cbe520$7863af60$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/PujSi6DShQiJ8JffD4bdQIVelAI Cc: 'Jeff Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Mon, 22 Sep 2014 20:01:56 -0000 Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff From nobody Mon Sep 22 13:09:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D751A1BC3 for ; Mon, 22 Sep 2014 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yVf5WETzT2D for ; Mon, 22 Sep 2014 13:09:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE41A1BA6 for ; Mon, 22 Sep 2014 13:08:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CAC73C296; Mon, 22 Sep 2014 16:08:58 -0400 (EDT) Date: Mon, 22 Sep 2014 16:08:58 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140922200858.GH6550@pfrc> References: <20140912205913.27356.43819.idtracker@ietfa.amsl.com> <54136414.5080101@joelhalpern.com> <001201cfd2cc$e3b3b380$ab1b1a80$@ndzh.com> <541AF26E.7050801@joelhalpern.com> <01ca01cfd351$d7c72cc0$87558640$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ca01cfd351$d7c72cc0$87558640$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/A81zPTE5m0GXkucjcQbUokJmXq0 Cc: i2rs@ietf.org, "'Joel M. Halpern'" Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-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: Mon, 22 Sep 2014 20:09:04 -0000 Sue, On Thu, Sep 18, 2014 at 11:04:27AM -0400, Susan Hares wrote: > Joel: > > You have understood my question - is section 2.8 orthogonal to the 3 options > in 2.1? The language in option 3 could imply an instance. Section 2.8 was > vague so I wanted Jeff's clarification. With regard to the original 3 options, two of them were likely covered by the existing keywords. The one that wasn't was the original proposal for the separate datastore. This ran potentially afoul of cross-datastore references. The fourth option the netmod interim provided would appear to address that. (Again, notes coming shortly.) -- Jeff From nobody Mon Sep 22 14:05: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 9D32D1A6EFE; Mon, 22 Sep 2014 14:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcCCo918-beL; Mon, 22 Sep 2014 14:05:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 675401A6EFB; Mon, 22 Sep 2014 14:05:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F0E53C3DE; Mon, 22 Sep 2014 17:05:46 -0400 (EDT) Date: Mon, 22 Sep 2014 17:05:46 -0400 From: Jeffrey Haas To: i2rs@ietf.org, netmod@ietf.org Message-ID: <20140922210546.GA5676@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/UHTETp3mWpcdhUZk52IPlui0B40 Subject: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 22 Sep 2014 21:05:49 -0000 [BCC: netconf] The netmod interim in New York City last week was a productive discussion for I2RS, although it was frustrating in its conclusions. (Those conclusions mostly being, "There's mostly no work needed here, go talk to netconf!") However, given the large overlap of WG membership between netmod and netconf, it should hopefully make the next form of this meeting somewhat easier to have. Thanks to Cisco for providing the venue for the interim. This writeup is presented to document my perception of our discussion and provide the seed to start further discussion in i2rs. No specific requests are being made to netconf at this point - and to reduce accidental noise as we try to converge on our discussion points, I have placed them in the BCC field. We can make more formal requests once the i2rs discussion of the netmod interim has gotten some traction. Juergen has placed the full netmod minutes here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt A small excerpt from those minutes: : Conclusion: We do not need any changes for YANG 1.1 (hurray) but : instead we need a document that introduces ephemeral datastores and : clarifies what validation means with ephemeral datastores. In : addition, the NETCONF WG needs to do work to define suitable : protocol operations and RESTCONF needs to make sure it is prepared : to support ephemeral datastores. There is also NETCONF work to be : done to improve notification handling. The only YANG 1.1 homework is : to make sure that the language in the YANG 1.1 specification is : flexible enough to enable the introduction of ephemeral datastores. Background: The seed for the discussion at this interim was the somewhat hastily authored document: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 ----- Ephemeral state: The I2RS portion of the discussion was kicked off by talking about the ephemeral state that I2RS wants to have and why it is important that it is ephemeral. The three options from section 2.1 were presented and discussed at length. The points about the advantages of a separate datastore (easy cleanup, clear segregation of state) were compared against the desire of other non-I2RS users wanting ephemeral state. A point that was raised early was, "why can't we simply let the operators choose whether something is ephemeral or not?" This lead to a discussion regarding the nature of "priority" and what its impact was with regard to how ephemeral state was kept. One thing that became apparent during this discussion is the I2RS Architecture draft is potentially not clear enough about the distinction of I2RS state priority vs. Local Config priority (section 6.3 of the Architecture draft) and client priority (section 7.8); the word priority is overloaded. Clarifying client priority vs. state priority lead further into where such data is kept and how it is used. Room discussion eventually went to identity and how it was associated with priority. An observation was made that this information is effectively meta-state being kept on the configuration nodes. Such information, not being yang specific, was suggested as a point for netconf. It was observed that the identity may be useful information for general users and may not be i2rs specific. The analogy was made to "git blame" (and other similar source-control annotation mechanisms). The "where is the ephemeral state kept" conversation began to converge around a possible fourth option - one that apparently had some discussion much earlier in the i2rs working group's life, apparently. Here's my attempt to describe the conclusions of that discussion: - There is a new ephemeral datastore. - It may be used by my many applications, including I2RS. - It has the property that the schema of config state is "visible" in it from a read-only perspective. - It has the property that writes to it may either create new state that is disjoint from the config data store state or it may cause changes to information that is/was visible from the config state. Such changes may be merge, override, delete, e.g. - This "shadowing" behavior avoids issues in the existing yang by not requiring additional language semantics that would require mechanisms to cross-reference between datastores. (One might observe this is somewhat similar to Object Oriented programming where the configuration state serves as a "base class" with ephemeral configuration extending that base. A different analogy is the union filesystem semantic.) Issues that came up with this model under discussion: - Validation is a problem with this design. (And was likely even more complicated in the original 3 discussion points. This was one of the elements that drove us to this fourth option.) - It is possible to refer to config state from ephemeral state for conditions (must, when), but not vice-versa. - We (i2rs) must decide what happens when ephemeral state has conditions that are invalidated by a change to the underlying config state. In such a case, the config state may validate, but i2rs may not. Does the operation succeed or fail? - Such constraints and their validation impact may negatively impact the desired speed properties of i2rs. However, it was also observed this is only the case when such references exist and that "fast" i2rs operations could simply be modeled with no dependencies on config state. - Ephemeral state priority vs. Local Config priority is difficult to fully support in such a model. In the above discussion, ephemeral state always has priority over Local Config. - Providing for Local Config to have lower priority may be possible, but introduces some unusual semantics. - Does I2RS have clear use cases for Local Config winning? The example of "configuration of last resort" was offered but is potentially a weak case. In summary, the fourth option was strongly driven by the arguments of "what keeps things simple". The original three options were apparently not simple enough and there's some doubt about the impacts of the fourth. Possible yang 1.1 implications: If the above model works, the discussed configuration semantic may be the previously discussed "config (false|true|ephemeral);" ------ Mutual authentication was also discussed. As noted on list conversation after draft-haas-* was published, while restconf doesn't currently require it, it is suspected that it will have such a requirement before working through IESG. I suggest that I2RS requirements are addressed for this point. ----- Identity requirements for the primary identity are covered by authentication requirements for the existing protocols. The "secondary identity" requirement is a netconf issues and we should talk to them about the implications. Since the primary requirement for this feature is for auditing, this may simply be meta-data that is kept on configuration state. (See commentary above.) It is noted, however, that introducing something like a secondary identity would require changes to SSH and/or TLS and may be somewhat difficult to make the case to the owning working groups. Per-client priority effectively becomes the ability to say "you can't write to this if the state exists and has an owner with a higher priority". Further discussion on this point is needed in light of the fourth option we were presented. ------ Persistance of subscriptions. Effectively we were told "go talk to netconf, it's out of scope for yang 1.1". Some discussion was given to the filtering considerations. Extending the filtering options of the ietf-inet-types module may be appropriate. [Juergen, is this an action item for yang 1.1?] ----- Hopefully this is clear enough to kick off discussion. -- Jeff From nobody Mon Sep 22 14:09: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 4D36E1A6EFC for ; Mon, 22 Sep 2014 14:09:56 -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=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 OpivVR8nUJZX for ; Mon, 22 Sep 2014 14:09:54 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA591A1B0E for ; Mon, 22 Sep 2014 14:09:53 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n8so759289qaq.27 for ; Mon, 22 Sep 2014 14:09:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oljvjbs9hqp2AZBnwVEa+slVKGsQIiDVRcGOckIRDCk=; b=jzo9pWc8D3oYhdodEaY3fcc4U5DqlpPe6lPDQVI9AhBXBnkvY/UUn+T2ggBXBGjz4F /0bcK/Iif1IirI7hzFF9WOIFeh8VYXX4/mfltMzSn4HlUQ7p/rGYS7gs4Y/qnZEenGjZ Xa99dgg2sEW1tugkNIiWbJ5/34wY+kzLAbzmx6rtc+29qFMu7/idkqdcaAk62VbAa9s1 ynVyIRQhP2KeGO82XPP3sRoaiPR3Tm6afvq8fVmhbFYL+rHMXi6DoE4x3bEX2cRAQ8IZ kSMdDAUfhr0gzK8oUftpeNHBILAYaBbziD7wWAK5gptarhip+8g4MhCk4a8+NQfQyof1 6IIg== X-Gm-Message-State: ALoCoQnhPCHzVM//mbcpCkcf1bla8ekY0gPQO2blY+7AwLsPOcJU+fKYwy3YC08yjKnj3ZGd/4L+ MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr12848351qgl.90.1411420192746; Mon, 22 Sep 2014 14:09:52 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 14:09:52 -0700 (PDT) In-Reply-To: <20140922200154.GG6550@pfrc> References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> Date: Mon, 22 Sep 2014 14:09:52 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c1398637c9db0503addf6f Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/aaoHVbwpvLq9S8t7UYkJjmPLVnI Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Mon, 22 Sep 2014 21:09:56 -0000 --001a11c1398637c9db0503addf6f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: > Sue, > > On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > > Where does the priority live ??? in I2RS or in config module or in BGP > > routing model? How does this work with the three datastore proposals: 1) > > separate empheral data store, 2) configuration state in existing > datastore > > tagged by model as empheral, and 3) whole data stores tagged empheral, > > config, or both. Is the routing code that sets the priority and handles > > the rollback? > > Priority received quite a bit of discussion during the netmod interim. The > reason why it was not explicitly spelled out in my first version of the > draft is that the implementation would vary considerably depending on which > answer netmod guided us toward for how we get ephemeral state. > > The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my > meeting minutes. If you don't believe I've adequately addressed it in that > writeup (coming shortly), please let me know and we'll resume. > > -- Jeff > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c1398637c9db0503addf6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Sue,

On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
> Where does the priority live ??? in I2RS or in config module or in BGP=
> routing model?=A0 How does this work with the three datastore proposal= s: 1)
> separate empheral data store, 2) configuration state in existing datas= tore
> tagged by model as empheral, and 3) whole data stores tagged empheral,=
> config, or both.=A0 =A0Is the routing code that sets the priority and = handles
> the rollback?

Priority received quite a bit of discussion during the netmod interim.=A0 T= he
reason why it was not explicitly spelled out in my first version of the
draft is that the implementation would vary considerably depending on which=
answer netmod guided us toward for how we get ephemeral state.


The rationale for the priority-based &= quot;first one wins" access control model is still unclear
t= o me.

A simple NACM extension to add group priorit= y has already been proposed,
which seems fine to me. So is this h= ow it works?

=A0 #1) NACM data rules can be used t= o grant or deny access to specific I2RS data nodes.
=A0 =A0 =A0 = =A0 Steps #2 and #3 assume access is granted here

= =A0 #2) the I2RS agent maintains the owner and owner priority of the data s= omehow.
=A0 =A0 =A0 =A0 =A0The priority is configured in each NAC= M group for enforcement purposes. =A0
=A0 =A0 =A0 =A0 =A0This dat= a used to decide if existing data can be overwritten by a different client.=
=A0 =A0 =A0 =A0 =A0(I think highest priority wins if target data= already exists)
=A0
=A0 #3) if both writer and cur= rent owner have the same priority, then current owner wins

Breaking ties by first-one-wins seems just as arbitrary as last-on= e-wins.=A0 It seems to be based on
the order that the networking = devices will boot.=A0 Can somebody explain why it is better?

=
I am still unclear how the operator know the exact data each cli= ent
will want to use, and how they determine the meaningful overl= ap
(e.g. what will break for client B if client A causes 2 of its= 7 entries to be deleted?)

This information seems = to be required in order to configure the tie-breaking priorities properly,<= /div>
but I think the intent is that the operator will just know what I= 2RS clients are installed
and know how to prioritize them, just b= ased on their purpose.



It turned out they gave us a fourth option.=A0 I'll be summarizing that= in my
meeting minutes.=A0 If you don't believe I've adequately addressed = it in that
writeup (coming shortly), please let me know and we'll resume.

-- Jeff



Andy
=A0
_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

--001a11c1398637c9db0503addf6f-- From nobody Mon Sep 22 19:29: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 599961A1AA4 for ; Mon, 22 Sep 2014 19:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 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, FRT_BELOW2=2.154, HTML_IMAGE_ONLY_12=2.059, HTML_IMAGE_RATIO_06=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 TV7hyfkrYJHH for ; Mon, 22 Sep 2014 19:29:52 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840781A03FF for ; Mon, 22 Sep 2014 19:29:51 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z12so5262645lbi.37 for ; Mon, 22 Sep 2014 19:29:49 -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=wQKOsGK0E4CVZiSRQ6TTBXjExdeJp1B/jWyh1nITxUM=; b=0IzPJLDio1kyS7ejpP0vU01ghdh2Tkgf5OCpp7ul0pvymfujpfSayIvHej6/lC4T/L l1LW0/XNLbtjb5F8qcgaeDL/6F4BRr5VQ5xka1xod7yc4+1d3PUJ85xXiZpK4ptZwi/7 6au2FT1/SzeJMFTJHnVGnBNYbCRz9YwJblk8gyj20MjpxIMafYMCfS7KumIMUaX12NFS j9GXxBnPrsMa+7A/wm/Xs4V9Rezp5oFhzqIpL2nPDzaAcHBAdq9gtyk9dqKplxJproz2 V4MnuGNEhGUlWgZ8DyJa5sVXwRzLX/y1USI1jqXsWHZjybk8bwhuKizhaqdLw58amZND q0sw== MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr27578862lbb.11.1411439389779; Mon, 22 Sep 2014 19:29:49 -0700 (PDT) Received: by 10.25.152.144 with HTTP; Mon, 22 Sep 2014 19:29:49 -0700 (PDT) Date: Mon, 22 Sep 2014 23:29:49 -0300 Message-ID: From: FABIO ZACCANTTE To: "i2rs@ietf.org" Content-Type: multipart/related; boundary=047d7b34340c73a36d0503b2572e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LpyrMHuoREcGZBDEWgrw0Dv5SLU Subject: [i2rs] Doubt about a item of use cases 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: Tue, 23 Sep 2014 02:29:53 -0000 --047d7b34340c73a36d0503b2572e Content-Type: multipart/alternative; boundary=047d7b34340c73a3690503b2572d --047d7b34340c73a3690503b2572d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Someone can helping me with an use cases of article http://www.computer.org/csdl/mags/ic/2013/04/mic2013040084-abs.html My doubt is the item that follows bellow =E2=80=A2 The customer might pass the traffic destined to the attacked serv= er through a =E2=80=9Cscrubbing service,=E2=80=9D either internal or external = (as shown in the figure). This could require a complex set of changes to the DNS and routing systems. Regards, Fabio. [image: Inline image 1] --047d7b34340c73a3690503b2572d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

Someone can helping me with an = use cases of article http://www.computer.org/csdl/mags/ic/2013/04/mic2= 013040084-abs.html

My doubt is the item that f= ollows bellow

=E2=80=A2 The customer might pass the traffic destined to th= e attacked server
through a =E2=80=9Cscrubbing service,=E2=80=9D = either internal or external (as shown in the figure). This could require a = complex set of changes to the DNS and routing systems.

=
Regards,
Fabio.



3D"Inline
--047d7b34340c73a3690503b2572d-- --047d7b34340c73a36d0503b2572e Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_148a04f8821330a0 iVBORw0KGgoAAAANSUhEUgAAAoIAAADzCAYAAAASEXdYAAAgAElEQVR4AexdBYAVVRv96EZA6dql kZLubpCSBmkURFJFQBpFCRGlu5QOBaS7G+lGuhvp/M/5duf9u8uybLza3Xt1ee9N3Llz7nszZ744 X4TXaGKaQcAgYBAwCBgEDAIGAYNAuEMgYrg7Y3PCBgGDgEHAIGAQMAgYBAwCioAhguaLYBAwCBgE DAIGAYOAQSCcImCIYDideHPaBgGDgEHAIGAQMAgYBAwRNN8Bg4BBwCBgEDAIGAQMAuEUAUMEw+nE m9M2CBgEDAIGAYOAQcAgYIig+Q4YBAwCBgGDgEHAIGAQCKcIGCIYTifenLZBwCBgEDAIGAQMAgYB QwTNd8AgYBAwCBgEDAIGAYNAOEXAEMFwOvHmtA0CBgGDgEHAIGAQMAgYImi+AwYBg4BBwCBgEDAI GATCKQKGCIbTiTenbRAwCBgEDAIGAYOAQcAQQfMdMAgYBAwCBgGDgEHAIBBOETBEMJxOvDltg4BB wCBgEDAIGAQMAoYImu+AQcAgYBAwCBgEDAIGgXCKgCGC4XTizWkbBAwCBgGDgEHAIGAQMETQfAcM AgYBg4BBwCBgEDAIhFMEDBEMpxNvTtsgYBAwCBgEDAIGAYOAIYLmO2AQMAgYBAwCBgGDgEEgnCIQ OZyetzltg4BBwAkI3L17V6ZNmSqHDh2UUydPSZw4cSRd+nRSsVIlKVqsmESLFs0Jowhdh/ji81Zy +/ZtHXSUKFHEw9NDatetKzly5HDYibx8+VIiRYr01v73/fOP/NT/Rxk+aqQkSpTorduZFQYBg0Do Q8BYBEPfnJkRGwRCBQKrV62S8qXLyNjRo+XZ06dSslRJSZs2rRw6eEhaf/a5LF+6LFSch7MHeeDA Abl29aqkTp1aPvjgA9m0YaPUql5DNqxf75ChPH/+XArnLyDT//jjrf3fv39f9uzeLc+ePXvrNmaF QcAgEDoRMBbB0DlvZtQGAbdG4PSpU9L+y7byYZYsMmToUEntkdo23tevX8uO7dslVqzYtmXBfXP6 9Gkll8Hd3133y/HRRzJoyM86vEcPH0mh/Pll3JixUrxECbsPmVbH5i1bSr58+ezet+nQIGAQcH8E jEXQ/efIjNAgEOoQ6Nm9h8SMFUtGjxvriwTyRCJEiCAFChaUbNmzCUnhndt3fFmaHj96JHQpW+3V q1dCYnnq5EmhC9NqkyZMkKFDhuj+PrfnerpWjx49Kk+ePLE211f2ZR3vKayUfvu8dOmSWuN87YQP 3O/smbNy4fx5HbPP9Xfv3JHHjx/rIm7DfgNqgwcODGj1G+tixoopGTJmlJs3bui6dx3vbefO/Ugq fbYHDx7IvXv3pHadOpIyVSqfq/Q8r1+/LieOn5AXz1/4WscP9sTkjc7NAoOAQcBpCBgi6DSozYEM AuEDAboP9+zZLdWqV5OECRMGeNKPHz2WvLlyycoVK2zbjR41WipXqKifSaoaID6ufJmyUqFsOSlZ tJiQ0IwZNUp+/KG/upe5f7XKH+v2Fy9elMYNP5V8uXJLlYqVJEeWrNL/+x9s5IzEh9v36dVL3aHs s3TxEnBXH8Rx6knxwkWkcIGCMnrkSNt4jh45oi7uMiVLSslixaX2JzXl5s2btvXsY9yYMfJVh47C bUqhv1u3btnW+30zdvQYv4ve+PzixQslbTzXhX/9Jfv37ZNcuXPrdm873rvO/dtvvpGaNWrYiCyP QVx/HjgI51xAZs6YYRsHCW+92nWkUL78Uql8eWn12We2dXxjb0x8dW4+GAQMAk5FwBBBp8JtDmYQ CPsIqJXtxUtJnz5DiE/2n717Zfeu3fLbiOGyA+SyWYvm8gpWxFKIPcz84YeIOywlS0EiJ/8+TRjr 9gViD2/AcjZ3wXzZvnuX/PDTjzIDsW9DBnu5Wa0BXbl8RZatWilrN6yX5yBEDerVkybNmsqe/fvU OvYr3Nm0MpLUtvvyS0mSNKkef/O2bUoqhw391epKXxcvWiQFCxfS49YA2UqQIIGv9UH9sGL5cskO t3qenLnk646dQAJzSeeuXWzd+D0ek3Dede50/548cUK2bN6i/axcvkKtnzxvn41W13Zw61+GdXQq sCPu3bp/Z9vEVZjYBmDeGAQMAnZFwMQI2hVO05lBwCAQL358BeHq1SshBiMNkktiwcU8BlZCEstm LVponyRaMWPGlLhx48Jt6kU4t27Zou7gBQsXSvYc2XU7ujzPnzsvUyZPli7dutrGUxfEz7JW5s2b Vy5cuCDlK1TQ9Q0+/VTmzpkj586eVesZ3b1169WXY0eP6fo8efPI6pWrbH3xTRZYHnkstpywOIa0 fZQzpzRt3kyiR4+uSSPp0qdXl7rVr9/jBebc88PqlzlzZpkyaZIUKVpEpk2doq/s22c7feq0WkiH jRghhYsU1lU+tzly+LC6yZ2Nic8xmvcGAYOA/RAwFkH7YWl6MggYBIBAUljPkiRNImtWrxG6H0PS KFUy788FiEd7KVUrV5Y5s2a/tbuLFy7quvSQp/HZMmbKKIw7tCRZfK7j+6hRo/paZEnaPEdc3LVr 13Tdzh07ZOb06fp34/oNyQkLHeMbreaZxtN6+87XH3788Z3bJE+eXD6uUkXKlC0r6TNk8EUCubPf 4wXm3BmbSavg+nXr5O/Fi9XS2qRZszfGwrhANuLmX3MEJv4dxywzCBgEnIOAsQg6B2dzFINAuEGA hKNLt27SqX0HGQDS0/W77yRyZN+XGiZsXL12VdKlS6ck57///rPh45Ng8T2J0MK//5Zfh/wi33Xt KmnTpZXcefLo9kxYsBqth2z79+/XZBRr+YH9B9RySCkWn8ex1gf06uHhRfBq1qolFSp5xS1ye46L 52m1iBED/0xdr0F9a7dgv/o9XmDOnQerXOVjGTRggHT+6mtN4vEvC9nD04ObqtUvLebHb3MEJn6P YT4bBAwCzkPA99XZecc1RzIIGATCMAK0Zm3euAluyMlCtyU/e3qmkdt3bsvhQ4dk8cJF8mX7duqq pNtx4Z9/SukyZeRfyMHMnztXIngTK2oN7kWcIBNPsmbLpohdvnxZmDaRMFFC2bZ1qyZSHEFCB12f dNt27fyt9OzdW1KkTIl4uE0QtJ4iHb/q5Iu4BRZ6up2Z4dyzR3fNrqUl7iSylzmu32dMD2w3vrbr AWIcGKugr53e8YExhIE5d1o/GzVpLL/8PEQaN2kqfgklD5MiRQopW66c9OvTRx4/eYx584R7/Zxt BI7AxNa5eWMQMAg4HQFDBJ0OuTmgQSDsI0Br2U+DBkrBQoVkMmLSSDysRndvzdq1pTJcvWx9v+8n bVp/oRmqjO3LB828Xbt26brkICWUiJk8caJ+pgXLiuVrgySOlrubS02ILdOVmgdWwpHI3u3Xu498 +cUX6pZ+7733lAR+hmodwWk8j2EjR4BcdpZePXqofA37tGIVg9PnrBkz7U4ESegCe+71GzQEOZ6K Oaj11uEP/mWIDB4wUC26V69c9bWdIzDxdQDzwSBgEHAqAhHg4vh/oItTD20OZhAwCIQXBBijdwdZ uEzyYAKE3/YSWcb37t/zN9uWlyhq3dENHB+JKCQiVmOG6x1IrLz//vu+ljODmFm/dAf73N7aLziv 1CSk/IzfYwW1r3QennLq7Jmg7hbo7QNz7nTNx0/gldQT6I792dBemPjTtVlkEDAIOAkBQwSdBLQ5 jEHAIGAQIAKOJoIGZYOAQcAgEBQEAh/hHJRezbYGAYOAQcAg4C8Cw32IVfu7gVloEDAIGASciICx CDoRbHMog4BBwCBgEDAIGAQMAu6EgLEIutNsmLEYBAwCYR4BVioxzSBgEDAIuAsCxiLoLjNhxmEQ MAiECwRMjGC4mGZzkgaBUIOAsQiGmqkyAzUIGAQMAgYBg4BBwCBgXwQMEbQvnqY3g4BBwCBgEDAI GAQMAqEGAUMEQ81UmYEaBAwCYQGBqX/8ERZOw5yDQcAgEEYQMDGCYWQizWkYBAwCBgGDgEHAIGAQ CCoCxiIYVMTM9gYBg4BBIAQIVK9SNQR7m10NAgYBg4B9ETBE0L54mt4MAgYBg0CACBw6eDDA9Wal QcAgYBBwJgKGCDoTbXMsg4BBwCBgEDAIGAQMAm6EgCGCbjQZZigGAYOAQcAgYBAwCBgEnImAIYLO RNscyyBgEAj3CPy1eFG4x8AAYBAwCLgPAiZr2H3mwozEIGAQMAgYBAwCBgGDgFMRMBZBp8JtDmYQ MAiEdwRKFise3iEw528QMAi4EQKGCLrRZJihGAQMAmEfgQvnz4f9kzRnaBAwCIQaBAwRDDVTZQZq EDAIGAQMAgYBg4BBwL4IGCJoXzxNbwYBg4BBwCBgEDAIGARCDQImWSTUTJUZqEHAIBAWELh37568 9957YeFUzDkYBAwCYQABQwTtOInPnz+XvDlzyoMHD+3Ya+C6ihs3ruw9sD9wG5utDAIGAYOAQcAg YBAwCACByAYF+yHw7+l/JcH78WTixF726zSQPdWt2yWQW5rNDAIGAVcikDvHR7Jn/z5XDsEc2yBg EDAI2BAwMYI2KEL+5uTJE5I8+Qch78j0YBAwCIRZBOgaNs0gYBCwDwKvX7+WV69eCV9NCx4CxiIY PNz83evE8aOSPFkif9eZhQYBRyJw69YtoUX6v/v35T7+SDYeP3ksEfCf1SJFiiQJEyaUZMmTSaJE iSVJ0iQSLVo0a7V5NQgYBJyEwMsXL+X8hfNy5fJl/b3ev+f1m3356qWv32yMGDF8/V75+40Q4f+/ aScN160P8/LlS+nZs6d0795dYsaMKREjGvtWUCfMEMGgIhbA9ieOHZfs2ZIFsIVZZRAIOQIkert2 7JTNmzfJwQMH5cy//+rTsGeaNPL++wkkDuJFmYzAm4jP9vz5Czl86JBcuXJZrl69JteuXpX4CRJI 1qxZ5MMsWSRL1qySN29eiRc/vs/dzHuDgEEghAj8i9/o9m3bZOvmLXLyxAm5cOGCJEqcWFKkSKG/ 1bj4vb73Xlzhw5rPdvnSJf2dX71yVa5fuyZ37t6R9OnS62+Vv9nsObJL9uw5JFJk3/v57COsv2ds /oABA+TOnTvSv39/iY/rlyGDQZt1kywSNLwC3LpM8eLSvkNtuIedbxVkjOCps2cCHJ9ZGXoROHPm jPy1YIFs3LABN5GLkjtPbilYsBAI3IeSJm1a+eCDoIck0JVCcePDhw7L4cOHZf++fbLvn3+0v4KF Ckqp0qUlD4ihuaiG3u+NGblrEKDFb+PGDfL34sWybes2iRM7thQoWFDy5Msr6dKnF09PT4kePXqQ B/fkyRM5fuyYHMIDHR/q9uzaLddAEPMVyC+FCxeRchXKS9KkSYPcb2je4eHDhxIb+CZLlkxq1Kgh /fr1k3jx4pnrVhAm1RDBIID1rk0zpk0nNFO7ovFJ8vjpU644dJg95qOHj+TMmX+FT/O0ut26dVtu 3riB15vy5MlTPe9IcEPEjhNbosP6FjVqVEmQ4H08CCRXd07KlCn1oh8rVqxgYcSL/p8gf3/OXyAX YUGoWr2aVP64ipI/v5aDYB3An52ePn0qe3bvll07d8r6detwk7kuFStVxLGrS44cOfzZwywyCLgP ArRy8/f67+nTcvHiRbl185Zaim4jdOIl4sjYYsSIrr9VWs6jRomqIRL8zSZNllw803hKqlSp3rDM BfYMeexZM2bK34sWSUr080nNmlKydCmEYjjOOMBz3rplq+zatVPWrFotqT08pFLlylK9RvVwYd23 iOCpU6fwcFxQmjRpom5iKmmYh9jAfXMNEQwcToHaKp2Hp/zw04+B2tbeG/Xo9p2xCIYQVLpcaXHb tXMXnrR3gQSewUU1tVrI0qRJq/F1tLx9kPADm9uVxJ9yQU8eP5Znz57J9evX5RLcOZcvX5Lz587L aVyc6ALKnDmz5MufXwrA0pYxY8YA43weP3ok0/+YLpMmTlRXbY2an0jRYsWCfXMKCSy0GC7GTW32 zFlqdWyEi2yljyvrjTQk/YbnfXmdMNZ7+3wD6GbdtHGj7IZlbO+ePfICv8d06dLqb5aE7gPE1PHh jCET1sPTY/2tPpf7iKPlb5a/Vf5mL128pASS8bbpM6RXlyutePkLFkAfCQIcMMcxasRI2bFjh9Sr X0+qVa+h144Ad3LASl6PaIH8688Fsnb1GilfoYJ82riRupIdcDi36NIigkwYOQZraZEiRaRt27by 1VdfSZw4cQwZDMQsGSIYCJACu4khgoFFyn22402B7pulfy+RPXt2S65cuaRgocJwvebR+Bta+ULS 6CKiVZGxfNu2btU4IVr6SpcpI2XLlZOixYtJlChRbIeYN3eu/DxwkC5vg4sZXUju0HiDWbtmjUyb MlXOgiC3bd9eatWuHa5jk4I7L4YIBhc5r/3Onjkr8+bMkRXLlwtJQPESJSRv/nySO3ceu5AvPhAe R7z3nt279Pe6Z89eSYP4W/5eK1SsoFZ+6wzuIi7te7gid27fIS0//1zqggQGx+Vr9WfPVxLa2TNn yh/TftcY4K+++Vpf7XkMd+jLIoKMFYwcObLs379fSuA70aVLF2nTpo26jY1lMOCZMkQwYHyCtNYQ wSDB5dKNaQGYMmmyul5z5copNUFqihYtJjFjxXT4uGg9WL1qlaxcsUJdrzU+qSElSpaSsaNHq0Xx p4ED3PoJnq7j4b/9pgHv33btqlYHh4MWhg5giGDwJnPd2rX6IHIE8aw1a9dS9ycTnBydRctwia1b tuhvdvXKVbA2ppFPatWS2LFiKwmsVLmSfPX1N065dgQHOT540qI/buxYyZU7l3RDdi3j6cJKs4gg H+qpgsDvw06EtpQtW1b69u0rLVq0UDLo6O9JaMbTEEE7zp5fIvh9n77Ci4gjGi1Vvfr2sXXtStfw uDFj1aU69Y/fbe4X28Dc7A0J4JiRo2TVypVSp149qVO3jqRALJ+r2mnEMi2YNw8xRYulwaefSsvP Pgs1VjZmQfbu2UsYC9kb30XGRJn2bgSMoPS7MfK5xdo1a/Hg8ave4Js0bSYVELPqKtmjFy9eyIZ1 64WW+/Pnz0n/n36Sj1BNKjQ03ovGjh4j06ZOlc9btZJmLZr78kaEhnPwb4wWEXzw4IF+L2gVZNu8 ebNURqzkwIED5VNcWxmrbcigfwiKGCLoPy7BWuqXCJKcMfPSEY1uOp/xiK4igry4FEEczZ3bd2TM +HFSBk9h7tgYCzR+7DiZPGmSNG7SGBfBFho/4o5jDU1jojtmwjjgOnGSdPz6K2nQsGGAw799+zbc 5Ac0kP8G4ikZU8lgd87P/fv/IQnnif7RlcObPQP7GecTDRmWiaF9mChxIkmIwHuSz6zZsml2YIAH NCvtggAJ0MmTJ+X40WNy8+ZNuXrlir5aiVOcP2pXMhOdc8dA/ZgxvRKo3mdc7QcJJUmSxML3WSB7 4umZ5p0PPIzR7durl1rNv+3aRUqWKmWXcwnvnZw7e0769emjv71fhw+TtFAdCM3NIoJ3795Vt7zP h4TVq1dLTSTs/AYPRm14fagzaMjgm7NtdATfxMRuSxgrQsLmiMYLrTu0JX//rSQwfoL4MnH8BLck gszk6/BlW2QFJpW/Fi10qQXQHebMnmNgfOMXX34JN93H0qlDe9m8cZMM/mWIPn2TJDL7mMH8hw4e lBPHT+DQESRtunSaeMLvTJKkySRbthwSAxdoizxQ/zBSpIggh8+9CeJ9xII9gPjuFWRs35JTp/6V RdcXyikQkyhRo0j69Bk1nrMY4i1z5cr9ToJhz/MPTl8kTNR5dOd2GULHzBrfCb3KEwjAP4+s9VSp Unvp3sWLj/mD/mS27Cip+b4mTsXEnL0X7z2dN95oHyHh6fGjJ/Lo8UO5cf2mko4Tx0/K7W3bZTSS Ki4hQcPDIw0SpzJoMgbj/Hxm1jLzdsjPg6VV6y+kafNmGvvlzniFprExAW7ilMkyF3GWDerUlS7f ddPs5tB0Dv6NlXHMfGBhUpBlFSyDWOwZM2ZIQzygkiBWrVrVkEF/wDMWQX9ACe4ivxbB4PYTnP1c YRHk03/1KlU1/qJMubLSv9/38tfiRWqpCc45OGIfEtW+vXpLJwRK12/QwBGHMH16I8CLcP/vv0eY wEYE13vKDgTQJ0bGdI6cuTRzkzI7JUuVlsiRIitZixgxgl60aUGKjIs3XymMS0meiHox9xLJvXTp MpIDZuPiHkWzlV+9eg3L0ytINb2Wx48fwRJ1X62Ix44dkXsI3iepoNsrx0cfueXcuGuMIC0qc2bN lvkIVSDpzvFRTsn8YWZ5DkJetHgJWPSSKNGLCJIeKSLmi6/e8xYZ82bNYwQsj4w5fIXrw5/z52ss aYyYkFDCZ6+5ey0UN//vP1TTwDEpknzo4AFJndpDanzyiezduwf6lhfktxHDNUnDLScxjAyKD8mt W34mFRHn2BFZtqHRWmZZBKmnSOMLCZ9PqyCnai5c+Z8jmWcSPEIVkEnN7ULjuTrqa2csgo5CFv06 MkaQX/SefXo7cPTv7vqfvXtV1HT4yJGa5frbL0PVRTjk16Hv3tkJW8yYPh2SDiNk2ozpkilTJicc MfwegtINvOlvh3RFxAgRIb+RWWrWqg8r4DG5cfMasqRLIYYwpcydPVuiRosupUqVlYggD7wYk0Dg DV5ROguvEfAZL7Adgjvgj3I9+QsUkoV//YmYpsgyFG4ev20gYrVq162nmnEH9u2Vrzt2Uivj561b SRVYAUx7OwLnz52TEcNGwAK4FsLEBSA30hRyKwlB5LeAyCfUWFrKKs2ds16KlyypVsEImCvOnd8/ TlpELOe88UGxUJGiwiSPRX/9JX369VWBcp8jOXH8uCz5e6m0+qKtMAlkHayQhxA6UBEW5liwEpvm WASYDT1nwXxp06q1dGzXXq35IVVKcOyI3967T4ugT6sg96BbmGEnLVu2lGnTpklphGzxHmrIoBee xiL49u9VkNf4tQiG9RhBXjh2bN8um7ZtVVP8T/1/lCmTJ8mGTZtVpDXIANpxh4njx6sW39Tfp5kk Bjvi6l9XjDn6FhbXR3AFNvi0MUhgBiUDrHyw5O+FwgcDCvZa7RjizEjqkiVLIUWgjxgV7mWSP8uq ZFkESQxJJi5C320Rto8Hl2TDRp/aYjuZJUgXYjTEEbLsFgP4K1auKs9hmaR1ki7NhX/Ox7GTyaAh P7tNxQV3sQiSvE+ZPFlGDh8ObciqUq58Bbh5Y6pFdsjPA4VutcZNm3gRdUwe4wBnz5olly9dkVJl SsNCmFTX0Y1vWQP1FQSfRJBWPyZlHT1yFKEDlaCjmc/6CsiB/QeUIObKnVu2IKg/XYZMajXm3DFW dN2albJj6xbp0q2rElHbjuaNQxBgGEd7hM/w9zZi9Ciba9UhB7Nzp5ZFkGX7LGsgXxm2QhF8Wj2t xmsGS9AthmRYvnz5QtV5WufgiFdDBO2Iql8i+EPffvoUYsdD2LpiAD1jO6zmbNcw614WLVxYPDw8 IXZcVIfBwH/q8bX6orV0hoaTqxrdwQNASudBVDUx3FmmOQ4BlqT7vEVLqVGrDnTWyqvrEHYiL0sR iByfwtetWQ0S8QQkrpEvVx+TRhbCUuTpmU4ttgcO7peD+/ZL42ZNEUeYFgK/F7WqCi2CzKi2KrTw pjUTcT/Hjh6HG7gk+gbpO3EUNVyPy8dVa+BmEF3J4EuQimdPn8mG9WuhB7dF/oBlOANi0lzdShYr LutQfsyVjSSwU/sOcvbsWcR4tkMSThJv6x6Nspy/iGrN3b1rh0qOsEKGFXdlEXC64kqVLoO4zRsa A0oS0eqLLwQ+YVm2bBn2Py6Vq3ysmpzWuTJO9PdpU/G7TCY5QQJZn52xnrFxPcuXvwAIvFecF4k8 6+zOmTVdry/9fvje6sK8OggB/q7atmmjZOrXYcNsDwAOOpzdurWIIJOLSAAZg7sFcj9NmzaVEfAI jRkzRgWmGZdLSyEtnrSEUuTfXTQf7QZGMDsyRDCYwPm3m18i6N82jlrmbCL46y+/yGjIsKTxk3F2 B1mhvKBshpWQCQDObpRjqV+7jlDKJvOHHzr78OHqeMwYLwMi1rRZS8mj1h4SCItIeJNBLKCrkNak VStXyN27tzWz2OfcsCIE541ZwBPGjkPIQx9ZuuRvfagYNXaMJpEQWIpzz5s3VxNQSEBSpPLAshdq eaJbSC2BsEKRROjfS756EYs9O3fI7t07ZOXqVXozCFcT5c/JUhicsYA9evfVMmt06VpuXrr2rc+0 zp48eULlobJm/VCtc9bNkyUYSeQ9PD1kH+pUZ870oWTJlkWaN2kqrdt8gXKIH9uOTKvxBFjpWQO2 ZJmyGmNoWW45r7a50zn7/7w9hCTI5PFj5OtvvzEufhuajnvDa3cjxFKzogpjBkNDs4ggS8zdQYww s4QZ78prCrOEqTDw448/SpUqVWwSMrQWkjRqWEpoOEkHj9HECDoQYEdaBKPjS9zDRTGCvKnPnD5D BV2HDvMdr3X0yBGpUqmy3mQ+bdzYgei+2TXJQNfO38rXnTsbEvgmPHZfwhJW1GAsULiQrW/wCTIK 8gh195IEMp4sRuQYIAyesmnDefmm01cyHO6nKN56XwlRBox/06ZOQ4ZoCySORJSPcdGOHz8BZC76 Sga4mhMmTCRrYFmkHNNnrdvIC2/CR8sWLVFMTOCr/sExqf/BP2kty/5RLpQN3AHL4HYpXKSwbbyu eMMMapJeV7Y/fv9dvmjTVmLCFaxNJ86bDGL26Ja3YjWZzZsiRQp1wz+FhZXVNaxWpGgR3HTvQQLo mjSE1ZZkcviokbDkzdEM8rLlyymJjIS5/gQPaCSROncgfK+9507nSBOAvOaPfmVr3qJGjSbFS5VB 7PFEQwQt0B34SoI0AsL2n1Sthmz+7FK6bBkHHs2+XbO2dAOQWFaHoneK1sCePXtKe1RBYubwx3gw MSXn/MfcEEH/cbHLUrrFHKkjaJdBBqMTurSbrlMAACAASURBVH8p49EELjy/jZYe3mip11cfKfs0 xTurzZ09R7XL6tSr66xDhuvjbIR78/HjJ7Y5tpFArzfeFiYmD0SUx08ey/VrVyVT5g9R5upDWb1y ta6/i4zRixcuammw/AXygyym1vgycDqN76Elib+jE3D7MouV7uJ/T/8LofYncuPGdcSpJZMSIArM IvYiFnz1IhQWmeArLYQXLpxHpvELl88ZM+1dXWuYNaTfg3WO8X3aSNj1j8ZATKD3ZxLCK5cvI94q qlSr8YkStGVLl2OX13DpnlJ3MStttPz8M1uSCGM5s2XLihq+l5V4J0qIbOMoEWXtqpVK2G/euIE5 faqhBAmgK/iKc6d/mDfMnS9Sj7lLlDipHEOcoWnOQYD11Kkv+MXnrWRZ7pXvrLPsnFG9+yj1UCCg MMKVWkEsm+ELdA2TBHbo0EF+gQdrL5IbGfdKeSrTfCPgcCLoyqoTdDk0wJejVevWGtzs+9SD9omx UEyG4NOuT72rgHqh6dlROoKxY8cO6NAOXTdt6hTJlj3bW+U5WHOzWeMmGgzuLIFpWimZIUxXIm9o pjkeAWrI0W1IF7EKtfKQFpngK//jXOB/PolXqVZNP3PZjes3ZD1i93KiKgNroDKpgDGDvIAXKcqY 0wgyZ/YsaY4sP7+amYcPHZY2+E03atIM38Ps8hKWJUuWhCRCiYWSQS9rIcnFkUP7QQJfSl4EiJuG MD5gNgeJH19/+60NDp0qzhv/bHMXQWP5cudlJjcmEvhu2rRB7t65ixjlrkrSFy9chKScv6RchfIq 9k2x6Sv4a/FZS1vf1htmc9+G+HyTZs0lOqyRnBPOnRf5s+bL+xXHIonfsXWzuo6tPsyr4xFgEk+V alVVDmrIUPdQgQjorPndJMlr3ry5ZMc1gXGAH0E+ilbB7iipx/esNEKiaKRj3kTSoUSQN4jx48aq 4DAlBJxFCnyeJuuiUgk/pI2FyNkXCUdgm6vlXQI7zqBut2DhwgB3KYpMUGdbPBZhTBkhEeNql1uA wISxlRnSZ0AyxlNpB4mWMRMmKhkk6WNTMmGRCn0ltYsg/yEjdCViBZMmTYIA7nY28WdeG+4jyJuk glnHN2/c1KBvxqDduXVbcuXJ7U0QBXWYs8hsZAjz2kJ5mmLFS0ocCKyrm1gJoDex4HsQnnv37qKE n9d39gksmMYiACstYv82waJLC37V6iDoXrOmpF1JIF3DvuYvguyGOPjZs/9K1WrVxcPTQ/fgP3T/ smwjQwVq162LCj5jIRdUBg9mI1Xwu3adOrYKMBQbp0dh3pxZkjlLVhD5j7wsuTYy6G3NpdsYfwf2 7xUmrDjTs2A7sXD+5utvvpHyiOdk9j9rOrtr43e5T58+UrFiRa2SwjhUPkD06NFDatSoIRshaH+Y 9akRO8jvtGlvIuBQIhjYqhMM6vRb5sa/ZW8O372XODRGELE2PXr3cm8Agjk6/oiD+oP9e9EizSwN 5iHNbsFAIGasmOrqxWRJ3dq1pAOsPawDy8bLLbXntmzeJJ4Ql84AXcFLly6ChEWDG7GljYwxOH0O tAX3/7NPRW0p88IED0qOpE2XHk/yOSUmrN8H9v2jupyMWSqEp/okIJI9e/eGu/majAPxuHXrDipU FNHqFuoaBomglWnrls2yavkSyQiX9Nl/T6uLOr7E1zG66h93eVip16ARas+OguV+jQz8+WcE0jNe kDRQpAvjbJFVmTR5UmgKfqBu4LIQja9a/f+ajCdPMAP4d7gO40uHrzpB9y+WsN5rcsQTRoP7rSLq vFIKZgIqDrHyCKV/mLn5cdUqmk28YvlyxBpPQ8JZesmWg4QQBN573h7BMjx7xjTM2RkpVLSEbNu8 3lXTFW6Py2S/L9u1k99gERyHGE13bbT+dezYUR8W+JBnJYAUKlRIpkNLlmXm6uIBpSg8DabEnP+z 6DAiyJv51MlTIARbQKyqE/4FSU+aMEF999//0F+Dysnm/VtGN+/Zs2e04oCHh8cbRIHHu4qapXeR NeTh6Wm70fg9bcYbPX70GBaEOBrfwgvP+XPnNVaGge8+CQj7vIF4FrpBGOAc1BZWYwSDigO3J5bE +dChg3L2zFlYaW+gXulVtdaeg4QFY7iIl0+LK60AlmQIyyJ9gIQCq95sMujS8Sk1ffr0smoF3YoH YRkqHpyhmX2CiQA15169egk3XysQt0My/Leh0KWbCPHWOlKvQX2ID5fAk/ghvZlQNqRoscISDxpe bCSAsxDAfQTJRcwu/Rhxc/wtkgTSXcjrBl/1M5bTepQ+YyZYpXbJksVL4LaqopmNiVC5pAfq0a5c sUIr27Tt+I1mA26E23krSChdzeUqVtFSdqcQZ1iskGsTRSyoqTDgysabZbr0GeXb73rJ4r/mSy24 7XPATd+xU0dkY6eSmhDgjR07psZpMvC+GqyGVjt+7Lgw2YRVY75s11brQL96ibnDfEXBTblO/fqa 4c35iwlyyLlljelhvw5Ty2CTZk3U3V8BFhyS+rZftIEF+AZE6UvKXViFF86fI8ehAZk0WXKpXb+R xphux3hNcz4CNWp+IsMg4E6Jn3S41rpj43eZoVK8d/u8fzM0qyw8DSSEXM57CZNhTHsTAYcRwcBU nRgzapT8PGiwjmr50mUqOlu/YYM3ljHuq9Vnnylx4Mb58ueXSVOn2DSAKBhJcWMq07PxSYY1ZT38 XGx5MaoD83BS1Dfl/sxwpYgm9YfYPsKFcMz4cVoHlcHU33z1tbqDuc7nF4yfA9McGSNoEaTAjMMV 2/CmfujgIY0T3ApNp2NHj+q8sM5sqlQeCABPqDeiJEmTIiP0A5WwoIWJ8RtWuTH8duXBw4d6g7kG 0ngFRJ/xRyT8B/YflBG/DUNB+mt6EShRshRcSLtVtDa0KuO7Yp5CcsyYMWMgPtArVIIWnQ9B1vbu 2Qkh7z9kEiwIGTNlRGWJIvq5XLlyKCn2n5aDY2mx69euyyK4gZMlS4aHrZtK+kgcXoJQvAS55IMf P/N7pMv18yvJjlifD7NkgYTMDmSmz5escBPv+2c/frOJURWjkIwbPRzfieuakZwnf0HoE2ZGWkME JZ5x4r4nM1GqztVuri2bt7g8czkjfofMyokTO4582qS5Wms3bVgD6ZCG0PgDltD048My5aFoxeP1 kIlBz549lQWoIEPNRj60U6bjgw8Ses+f77lj7CbnjgQxFm7UlUEISfh++nGAJMHv/8GDR9j/jmTN kUv2oxrMj/16Q/7jtnh4ppUq1WtKYlyn+cBAmRpmn5vmfAR4La2KWEH+VhnL646N92b/7s9cxnsw /0wLGAGHEUHqVFESgvEjFCKti6dEVp2g0DDdOmzUAluCeBHWsOTyyFEiq+XN77J1a9ZI9eo15GN8 IQ/s2y/fde2qFoCqeIrlhaYDyNxDFDmfPmumVpHYsH69Wg59njovJi2bNdPst5FjRquFqt2XXyop nAVtMtbT/KxFCxk29FfpjVJI7dDnLcQWTsVNLVPmTAiG/lN+hNUyKC2sxggGhAEtP1NRrYAWGj6l 5c6TV0qULC3Zc+TEBd4DyQG51frqb71SWAD1B82LPv6Y0RgnTlxYgBbLhg3rkaSTWCVF4qBf1kBl TOCLF881gzlipMiYnx+QgXpBrQysiFDQ+0kwoPGadcFHICaesBkjaDVecIsWKynFSpRCdu8FrR+7 AFp1N0DMmDT2foIPQP7TqWUhRfIU0hLZffghqkuHFmGLBL5S8sAEEJ8kEKQQy/l7f/bkucTAsZl5 StekEkwQEmbBZsqcRYqVLIPfdXJvbbrnSiY4RloDSGZc3ZpAZsXZMbR+z5luWPUBe69gnd+0zT6X pw2e4AH5MMj1Hjl84ADKys2VBMCV7t4PQbp5rc6TN5+W/KOV/8VzL51Ga+6UwGPebHOH+aK1UNdz /rDuPRDyTZs268PAf7AAMqPcE4Qzb4GCCAfIgIfBGDpn1BZkY0ax5e7zHq55cSIClHJq37at2xJB J0IRZg/lECLIuJ1ly5aKh4enDICQIxvdC7xIUFXeqjpBlX/67JkV6FPx3++yJFC9p7WIjanttBpR moCNlqaj+Js4ZbK6k7isPrSE2Hg8tufPn2mWIV2R81CqisdjFjBdlHXr1Ucfx3S7PHnzQNZiFWpt Nlal/GHIOLI0x4JjFu/f73t1TWnndv6HsRDde/W0c6/B746ug949e6kLgQS/d9/+IOMR5Z89uzFf UaTTVx1R6ue0lhxLmSq11hx9o16pLUAd9yi8x61KCbuVjcjvUge4rvzWjn2Mh4D+P/wo3Xr2lttI LNiF4PJuXbrpjb93394gJ8WCf2Jmz7ciwLivp7AQ+W0k8x6eaSQdbuq1atdFnNg9SL6cUvmWf0+f lp07tmu4heoLwqoYM0YsJI2gTFmESJpcoKYqdMr5Z2UQZgG/BOF4AsLA0IEXkIB577340LZLrskG SZIlVeIXM1Zsr/UgEHyw89tYp5h9mOaFgD50+QGDlrv8BQtpjWCSrzOYr0uXziNW719Y99fBondd KOAbA9dgkvHoqOIiEV5L1MhRJQJ+75w1ztsrXHuf4SGNhPM5viMk4PyusOoLNSFTe3ggBjGrVv5J jFJ1jOek9U///MwdCWfEiM6TofIDSbj/SAs6k7x4Dw+sYka4By2UAeAQIjgDAZq8GvBCQjeI1Uji WBu0LQJQg1J1giSQruYJ48bDnfCfkgOrT4pIsgVE1Jg1tHnTJpCITuqK4vZ0KbLt3LEDbol9+p7/ 5MxNMUqvdXRthaQxPiks6gj6xIRkezQkdaZMmiKf1Kol7Tp+rQSM+mOsD/sEGJQt11iJPIPk+cdK ErNnzkR2aHpY7QqrFZDbs6kAMUwVliuIN525SCbgwwWlexjAbjW6nFevWq1WikSJEsre3btADHJK MVilCiJx4MD+/dL5628gGVAE1Sp62TIXrf3Na8gQ8GsRfFtvjAvMB2tPoSJF1e0fCbVo6SV4/PCB 3EJMLy3vr2gRBOF7CsLABwiSCX63oiO5BJ5ieAsiYf7e12QQigw/B8kg2XtmkQd9DTiONzLICn+T puHyDHL1rsbrN63utAQyXIMeG8btct+7cOGyisM9/HG+GN/LLvk7ptWWFv2oUaKqm58ueVpr48K6 T0shaxCT0HsRP1aG8ZrHt42Hx7PpHb5tI7PcoQjkQEgG75NlEeJhWthDwO5EkD/woFad4MXBb/O5 bP26dSpuSdcv9Y3y5Mxl29wqZn8QRcyt97aV3m9Kw0KVO3ceGTxwIFwcyYV1M2mtZKsJ8mJlOvIz LzqXUOOSjRZDxrSZ5j8CxOorZGsRr0E//yLx308ACufl1qW14ZNateXB/QdI/pmEG8ILaYaqER6e HjqHnMcd27fLJJSdopv3GW7q58+fQ1mgU/LLr7/KA8STscD9LVj4GsFC69NiTCLJ8lh0I1WuUk1d w8dh1X0EYkF7hNokMIwP8STrkSaNLPt7EcrO1YU1eIEt+cT/MzJLg4JALFjzn3jHCAZlP2tbEoR4 CRJIRngGWGUkIsmGN+FQCxG+E0oS/Hm1+gjKa7Ro7kEELS9DUMZu72352/XPIhiY45DEM846ZaqU WiqOxJ7zx+ohJGx06T57yrl7pr9r/Uzih3n0eV0PzLG4TUjGGthjmO0CRoAhHRRyNy1sImB3IhjU qhMJYcnZtnWrPm0wg7Ag3BJ+l21Yt14DPjNkzIhSRlflKZ4+GS/EQGXqYDHJo2eP7vqZxeqZncxl 2bPnsM3a59A6YzxZl28668WIBJD1FLkfi1RT4uLkyZPCpJXfUZyeTz79+vTxil/x9ETG6zlbX4F9 Q/etowSlGcDt6kYR2ZMnT0i//gM09hLcT28uvMHoH0hhvPjxpC4C0B+CpM1ElijduE1bNNei38wM 5d/uXbvUWkfrDwWCaYno1KGjZp32/b6ffua5Mrln+h/TkWySGlmpjbysC7jpEItcefJgfmFdwB9v HDQp8ZVxYZVAFv+aPxdhCj/J9/1/cDVsYeb40eAefEn3H/EOBY3WLGqburox7tjVjeQtOKTMFeN+ 9RIWQZBM01yHAC26DPEwLWwiYPdfV1CrTrRBwkbL3c2lJpJBaNHLgxu632Usfk3rUUEEKefG+oSo fUmx0uTJU6DsUXUZheSPnhCP7I26gnRLMEmFemR+WxsEvDJoudu3XTSAedjIEahN21l6YV/uR0LR DAkjbBQ+HTxgoMY4MrYwOM2dYviCM/537fPnggWQmahnk+rxsgZ67eVVY9arGgFJ4eNHD9W6sxOi tHTn+Y3zY8zn3t17pGv377SDsRPGQwNui/Ts3kM8PT0QX3YBmcZJEL/ZhBxPk4q0GgFikEhE/PvD QttyliEbPXyoIYKKrn3+IWFnxRAKNlPax90byyKmgjSKq9uyJUtVM9GV40ibJq2cO3cG8kshC39x xjncvnVDUqdO7YxDmWO8BYHYiAe9cvnKW9aaxaEdgQi4gbr8cZ4kjPEm76NkleWu8LuMMSiMN2O8 Ed3Pj2BZonyBz8blFDRNAHdTUBr75n4+jx+U/a1tqQ32w09eyTFc9n2fvg6zQDCtv1ffPtahpUe3 75yeiZgrew6U+WoilSpX0ZggGAT11euFVkF+ZBJABI3JJNljDJFlMaTbj9ZAZgVmyZpNSpQsLvEx p/xCkrCvWb1KpSM4P5GQFcx97967DxLotR8tvNVq1JS00Lei3pxVzF4zUPnZ20LIV8aGDf6xnxyG PhmtIabZB4E+SNDZh1jMRk1aqHuQbkPGjPE1MuYsMrC2fdZlkRR/r/XWey/XYlBcw2+LEeQ1QOcd bkg+cPC7wu/ZfmTBXrtySZauXG6zMNsHgaD3wuuEq7OGWbHll8FD5LPW7SDtEst7vv4fB0jrqa85 8nbZczn/6Apm3GYkJHEExTXMuXhbjKDXOqz3DgWgdZ8Z4Uv+mit9f/heyleoEHSwzR52QYBSb5wL K9HTLp2aTtwGAbtbBINzZrywMJHEZ/O7jJnC/GMjCeKf38ZlQSWB7MNn3377DMlnuqHCcrII3TV/ zl8Acd/qgElpoDf5o23QiwhyAYkfYzNTpkyhRPElLvAsM/YaWQDf9fhOLYrLli6VOUggyQrXcH64 7JkcwjJjrb5o/cYUjBg2XOOP2kA7MlasOGrNZTkqLVyvr14lxtRi6G0V3LxxnRIEkhLT7IdAN8xf g7r1EBc8BRnCDd6oC2y/IwWvJ5LC3Tu3y+lTx7UsHa2YpgkEoqur7ub4scOlVp0Gwixvd2vXrl2R jWtXawk8QwJdOzusD01Pm2lhEwG3IIJhE1oIW4O4OipGkBI4rm5xYEm4efMWXO3faokq6yZrWfz+ /8qRQg4GJG31qpWoPX1bGjRsoNIR1jlQx2wLioKfO3tO8ubLjyoEv2rG4m/QdaRlp3TpUppkwu3b tm+nruUJEP9mwfoiRUsguzSGvre5i70JIeUr9iHjfOe2rXooGsA5LtPsgwC1AynSPGjAABk6+Ccp X/lj1ZijNcmVjfFvp04el62b1kkWCF0vhBalpV/qynG507H7wcrGB7mBP/2kJd5KlS6nYTeuHiMF x3ds2yKnMX/f9eyhCX2uHlN4Pz5ln/LmyxveYQiz5+/aq3WYhdXrxLqH0VrA1rTRfduoaUvIxCyQ usjE7g1Xdc5cub2NgxGk13ffIa4vMax20IpE/CWlf+rWq+crE5uyQMwOTpcuvXRCkfMokaOoha9M +XKSPl1GdVsxTGDHtu1arL4yxE1z5soJHbLUiPfrrwLSYyFW/OjREymAclWxYsZW3TkSQrr7Z0yb gvjCc0g8KStrVy3TmEFr/ObVPgjQEl+8RAnE8e6Q40cPI+FqCbQbS0iuXHl0nuxzlMD1whCTQwf2 yb49uxC3+IH0g8i4u0lesPyeOzQ+EH1Sqya8FqVQHnAYYqJ/QNWWbPog9iFCNZxJ5mm5PY3EM7rw qTlZ/ZMaMnbcGImPOsamuRYBPjzv379P+vsIewrpiFgKduqUKVp9ikmaNGywXCjLTRYtXkyT/EJ6 DLN/4BFwixjBwA/Xvbd0ZowgLTE+K5e4IkawEMpQNWveWuM2d27fIkuWLFIXf736DZFEUlP1GNev XQsLXnutNcoYTKsdRNWCGdCbZCY4E0cigwB6VZRg9QjvihIQDn6B99Zyxg5t37pFhYlr1a4tOT7y ygqn0OnQn4fIc2xbomQZZHifBTmdr2WxUqTygH5dcYQSRJMpE0fJEdRJNTGC1iyE7JUZ4LNnzVaR eFpyc+bKJXMXzIdw+L8yeeIkWH9XYV4jYZ5ya5Z4WpB9Bv1HiRrFd/wZtgmqfAxjBJ+issgVlBw8 hxrkPObxo0dUvLhkqVKoZFQPx/0oZCcYzvZmDNi8OXMg+v43av0eR9xudpToy6QSTHxQowKAvWIE mYFKeS7+Vk/C8ncaZICahVWqVgEJ/ESrEoUz+N32dPmwzmIBi5b8bZcxrl29BoL/XVSYPG++fDAM pNUwoOPHj6N0IVUofoDHqKFdjmU6CRwCxiIYOJyCtVVYjxFkrB9j7mhZKFSkmIoGswbspInjZeyY UZI2bRqU/MoMUrZQ3veOASUmlP85fvyY7EFtYFpwUqZMpXI/dOfR+sc/Jn+wHJVXeSq8x2c+meaB 2zj7R7lkzZq1kKOZrgQP3l+8RpfD/+yVdWtWI8HkIW5iOaRuwyYQso2vyQIkkYxbRB5xsObS7OSF AOdh27ZtshyVg1YsXw43/x0bNKXLlNb3adKk0exsSvWw6s/G9Rtk375/5M8F8/SBIAkqSaRFSTHG BdNinAyVQWLGREF4EMQ4cWIrSaRFl8k/lHZ6Ck06uguZvU+xd8aO3rh+Vc5fOK99sPZwgfx5pHPn r33pTdoG5mZvKKrvLlZBn9AwA5yqCfwj7hThp5V34Z+sLXwC1rkEKt3EWDH+0dXOOsOMFY6LeYuK h1MmdLG28GNY6Eksmbxz8+YNzTjlK+fu8uVLqFRxX+eKEl+tIO1VGDWp3b1+uk+swtN7hg9U+riy XU6ZD2wsV0dd2F+HDZNUfrLBD0AP2ITu2AXqIHViLIJBgivgjf1aBH/o208V9wPeK3hredHu8l03 2860CDq7RY8eTb7+tqdKiFBIVrMMcVPg+yvIED5y+KDsgYvu0oULEhOlq5gRnAoitOkyZBAPD0+8 ptc4SpYG403AF/HDzcQihl6kEDcXZP4yVuX0qX/xehIWv3NyD5aF/+4/QKmrqJIJsWCUw0gFKyCu Jl5ZoyCrmo0IIjh14mg5CKsRtQVNCxoCZ86ckYHQYdwCSR9aAv1r8/5coITev3XWsk7tO0hskAYK vF+9egUWvav4u6yKAJxnqgFYQga8IfB7we8TKxElS5YMVWSSKgFJgdq3tCbzdxDamjtkDQcVMz6c ncFN/Py58yogz7m7Ck3XG7DGc54ePHioyVjsl5adrFmzakgIVQPooqcANYkjX6nZSsuwFVMc1LGY 7Z2HACWXypcpK6vWrLGLm551tvfv2y/L4S0wMbvOm8d3HclYBN+FUAjW93ByjKCzJSlygHjRVeS3 8caQAlY+D09PqVrjE7XqXbx0wcsNBMsCBcIX3F4g92F1iAaXbfQY0fVmQjci92WDQQgNZA4WBbyo DA/lg1gLNT4khBIlSgwR6bxe5eUSJ8XyODbCZ0mLsAefjX1bJMPncvP+3Qh4Yi5HQq9zO2I1Z82c IatWrLTd+Lk3Y3woBh5QO3H8hGzevElWo1KQMwTRKTg/bcpUOXToIBJHTilpZIWEipUqaf1phleE 1/YtSi+e80ck/9uuXVSr1S8u/J2zjGdApTytfaj3OgJyI+ZGbyESel9/+flnqVGjhl1IIONAd+3c pRnr5rvhXt8JQwQdOB+OtAj6jRF04Gm8tWtaCQLzVE8LHGOMMmXKDM3Bj5U8kvTx5nIfLqL7ECQm /6PljjGBkSDxwTjB169fquuXF5BYseNKHJC9l5CcYTk6LiNJtOmSYd93NUME34VQwOs5XyyPxj+K fX+GkoFWpQ5W+PHvocDqkQS8P6rEUNTdGSSQ8Yndu3bThCFmO5YsVVLd2IcOHoKr8y8ZMnSoitFb 4wtvr6zScxM1nosWK+br1GPC8hrSxgfAf/89bYhgSIF08f6sLcx4vhUIt7FHOwuvAq/ZPsuFWv2u RaiP1ZLCcszriWnOQ8AQQQdiTSHksKwjSMsbBWWD20jMmECSCGUG6VbWhAEQRNabpZvQInokfpYI LYlgSJqxCIYEPa99SSC+A8nqDmmP0SNHacJGpsyZAux4BsqqkTQ2hgC5o9vpU6ek/ZdtkQGbRQkf M8ytxvlnlaJYCEdwVfNPG9MVY0mPEA3/KjCFdCy5UUecUlCFkMVvWuhEgA/oHRHG0QcPb/aSKmNF MLbL/lQo+RxxqVb7BAoUjvheWv2b1zcRMETwTUzstiQ6XE+O0hGMDRepqxuTL169fuXqYQTq+CQA jDm0XM+B2sls5C8CXTt/C/dqRWmAeB9me3/XtWuALsNdKCtIPcgFixYGaDX092DBWMiyhDERWzh6 3Ng3RHA5/6wx7soW1qsz1IAkTeOGn8pXkIMKyErsyjkwx347AjRgtGr5mVSoWMGu1VzoCWByCJUk vvm2s/gMzdi2a6cOqALiEU1zPgJuSwR502ZwMm/gnshC9HlB4ToGLTOIPEXKlLabO7WJokHEOQbE hSlNkBTZiPyycTnlQ2JCz85q1Jija9NyUwW1T6ufgF579Okd0OpQvy4LAsJPnToBwd5sbn8uN29e t30f3H6wbj7APv36SrLkyXWUterU1pjBt1UdYJJJuzZfys9DfxEmeDi60Yq8Z89u+bRRozdIoKOP Hdj+x44e42/FnMDub6/teMO/ePGir+6SJEmi1nlfC4P4gRnhTApjLXLKPJkWehDg76dDu3ZaCepb PODZu3Xo1FG+7thJ+vTqLX1hbbQqMjcTGAAAIABJREFUhFnXjwim8o+9IQ9Uf25JBOlCYnbR7l27 9SSYLUgNI9YZZmwL3T68wbB9lDOnjEGFCUpRVChbTuqjYgU1zRYtXKiVK7gfK19cuHBRlq5YrqSR 8WXMhCoFvbHvf+wfrD59auLpQPz5x5ExgiyL5+xkFL+n2PGrTtL5q28kKTI5LbO/323c4fPTp09k +5YN0unrr9xhOKF+DHz4shpjRHv27u0rccRaRy26ls2aSZ9+/aRY8eLWYoe+njp5UqWG0qfP4NDj hKTzwQMHugUR3Ltnj5QoUtTXqaxZv94uIuDde/bUGNIyZcroddvXQcwHt0SAkkGtP/tMEidOIgMG DbIZWOw52KrVqqlsGDVkKTVWrXoNlZK6ffuWHEMd+AeQHDLN+Qi4JRGkgCVJ4G8jhqsbZxEKpFNX jE8r7b78UiUIZs2bq8XJP0NswTC4nShCybZ40SJcZL+QRk0ay5pVq7X2cPOWLeXT+g0Qt7IF5ciK yMrlK+QapA+aNGsa7D4DM1VhPUaQgeZffNlGRgwfAUX4qsg2zBcYWJy6zaWLF2TTulWaKVq7Th2n HjssHYxxgX7rgVvnRyFp/jattm3rVrXYD/vtN/lxwE9adcRa5+hXPiyyUd7EtIARYEB+V1T/8dkS JfaK4/K5LDjvs2bLJh9DKL4zspPHjBtnRNyDA6IT9yEJa9OqtZRDRacu3bo5hATydBiawXt16bJl hDXjx40Zo7JgXEfvHCuL1EH1KdOci4BbEsE0cC1QP2zMqNHQhcugAqeEZd8//6jLt269+nLs6DFF Kk/ePLJ65Sobaqwrat3weYNiy1+ggGSGsPGUSZOUCE6bOkVfKYUQ3D5tBwzgDd3SjooRJD7u0Eim cyE4vPNXX8nePbtQzquiiki7emzUN9u1ays0DC9KX7gyK1au5Oohhdrjb960Wa3qK9eu0bAL/07E cvFwHStEMKOYSRqJvAPE/dvHEcuSJvXSGVyDbEdWtHFmmTRHnI8j+6QMEzPAHdW6dOsKi3BzuAF7 qefFUccx/YYcgaV/L5EbN25oKNXjR499hVGFvPc3e2BJSv4xJOv6teuakOIzdOvNPcwSRyLglkSQ Nw+K03bEhbxq5cpaL7ROvbpy7do1xWLnjh0QpdxnwyVn7lw2fTiKlfptfAqhVbDz11/L34sXq7Vx /KSJullw+/R7DP8++ywB59/6sLIsW/Zs8vfyZbIQltuJ48YjNmiOWgdz5swtqT09nHaaD1FR5Oih Q3LwwD9y6+YNDRNo+fnnoVJ02GmgveNA+/fvl686dJCJqAvK2NvAtASoQLF2w3qUHFwiTRs1hnRL KSQOfK1VRAKzf0i24W+dFg0KVw/48Ue1ePklg6yGcvXaVX04DMmxgrtvWE8WsXAh7iNGj5IGdetB OugH6db9u0DJTVn7m1fnIcDfZ63ateQXlOosU7KkdOjUSRj/6zM23xGjYWiJ0RR0BLJB69MtK4sw QYQXdMby/TrkFxkzerTMhis4NnTkKleooGKlFZC1aDVr+wIQGG7waUNp37Gjtcr2StdV8cJFhCKz yZInk1XIXOKXkHFMwe3T1rn3G7+VRfr3+95m9va7bUg/86bcvVdPWzeuqDVsO7ifN3QNLln8t2xA vBFmUmU8WO2DYr7p0qXTjE7qCPJGwT+rKklg5GOoG0g5GcaRnmWN2dOn5OIFL7HqW3BfFixUSK1/ 5cqXNxVE/MxLUD9eRnWYOpBy+L5/fyVzQd2f27PMGJMjZs+aKR1xc2GmMX/bjmy8HjCzef68eapZ 9nGVKuLpmUZu37kth/GgsHjhIvmyfTtpjRCS8NqqVKyk7vwWiAnz2Rhz7Z/Om89tgvqeiXltgTWv 3wMGDzJ1hIMKoJO3P3jgoAwaMEDvlb/8OlSTNWkwuQLZl5uwGvL39ejxIw3NYslOqkewfntsb0km VpJh0lESWOdNFScnT14wD+eWFsHlS5fJXsQJVqteTRhrwsabEi/olH7o2aO71sKk9e8kgsO5/e+o OxtQo+uKcYN84mncpKntyZQXveD2GdDxuI4l0cKyjuDbzp9kjH9sDN6nbhtrSE6bMgmu/TOwDCVC RmdiJJgkRGByYo09ixIlqpakYta3JSj97PlTiE3fV01BxqjduHEdlr5bWm/26pUrqjeYIlUqYQDy l23bSPYcORz+BPu2cw5ry0ngWjRtJl8ig5AWveA2loCjVESdunXk605fybq16+SnQQMdmtFLoslj 8Ds4GeEg/M1bjd6GmshkrQxPg6sak0XcwSp4GuUaKf3js/Hh0t5EkFJXEyZPVhdx5fIVZODPg10u 4ePznM17LwRI8A4cOCBHDx9R8kfPW41q1eUZHroTQO+V5R2ZJBkpMko+Ro+htcH5W+Pf61ev5cHD B0oSb1y/iRj8K+pqZvhBcqgFsJjAh1kyI2wks+TMldNcp93sS+eWRJBfnKFDhsjkiV7uW8YSlIcl kF+4YSNH4Gm/s/Tq0cMm/9LMhxhlQPjWb9BQS07VhAncaiHt0+rHvPqPgFWWqmEjr/W06J1HaSvW mGVA/+VLlxEjck0rhjA25dnz/ycdUKyadWnZeAHKkDE9EoWSouZscsgGpdC6tL179ESG+F+SAeK4 jnZjeJ1B2P/3JcS8mZlfpGhRqd+ggV1OmPphs+bMkVEjR0o1VJcZhN83E7cc1Wjtr/5JDf1jbeQ7 8ATQZc1se1c3WkhdTQQXL1vqVBho+f8Brvr1KC/I8naF8d1q37GD/p6dOhBzMF8IUDh688ZNGsu+ aeNGiYuEDQ9Yz1OlSg3DSVNJiQftRHhojxwF3hvItUWE2D89OLw2R8QrPTv8rbEIAHgkrO53UMHn tnrznsNzw2zgC5AootzbqlVrcE+fjN/ibSlUqLAaSYqXLKG/S1+D8vOBOqR587lfIqKfYYbqj27p GiaifDphOjuDSflUQcLmszEjly4HEgS/63xu5/c944PiJ/DKLPS7Lrh9Wv040zUcL148+abLt9ah xZ1cw7ZBOenNsiVLZTDkDlih5Gu4BFlSzLTgIzAGdWIpLTKa2Z64wNu77dm9G67CNtINln1ac8Nb 43XC2XXB3Qljko/fUOJv/tx5Urd+fZXSIUk3zXkIsO73VFhpl/z9Nyx1WWGly4WH6Yxy/PgxaPtF Vgmm7B99BAFoTyV6JH8W4aPWn08CSEJILw6VPZYvWyZzZs0WJusxAzh5ipSILY4OF3FUnNxrlXGL EjW63EGYxqED++Ep2iclSpWUZs2bSw4cz29jbeIWzZrKgcOH/a4yn+2IgNsSQTueo9O68ksEnXZg HCg8E0HizHjSWTNmyITxE4QkuWGjT6UK5CvcwQLkzO+BPY7FpJuIePCKYYe6s28bD0MG6Hpu2ryZ TRXgbduGteXhnQha80kx6xG/DZMVy5dLmXJlVQTcPzJgbW9eQ44ASfignwbISihtMGypVJlyapGb Of0PeR8GkjYIsaEEEw0xq1auROLdQST+5RYPj7RqASThIyFkTKC+elsIaYyh0ebJk6eyFNq9TOZs ifhTK7SLI2dcN5U0KCZduGgJjQ+/e/eebNm0AdJumyR37lzSGwoPlrg0SWAH1Ca/DlIZnh+cQj7r 7+7BEMF3YxToLfwSwe/79NUvf6A7CMKGjHns1bePbY/wTgQtIHgxWr9uvXTp/A1iDxPKnPnzTNaw BY6bvV5FeEAz1B6uWKmSugndbHgOG86sGTOlXoP6Dus/tHVML81oWKEnTZggHSFD1RaJPKbZHwFK pbX+vBWIXV6EfDTCg14MfeAjiTt//jyum2skjaeHNG3R3JbQQ0JIon7o4GHE3BYUuo1pDfzv/n9I 1vtX8uTNq27hp0jGpGrEsSNHNds4X/78thOg1BurzEiEiBpvyIQTWg9r1q4rz/EAz1CUx/DwrVqx VHZt3yZDkKBCC+K3KFE4bsJ4qfZxFUMEbWg65o1bxgg65lSd3yufgMJjsojzkfZ9xDWrV2kc4djx 4w0J9A3NWz8x85qxuUEJs3hrZ4FcQdmImXNmS51PauIG4xFu3MSGBPr+gjAEiNYnEsAv27X1vdJ8 sgsCV5Bc1/qzVtISotF5QATZ9LcOEkjrf5q0aSRturRy6dJF6QcDRnKUkKS1niLPFSpWhNB0eW+3 70y1/N1DzO1LPHST8M2aOUtOnjgBIei60txHvP6/KBE7/ffpSA5MKBUqV9H9Xjx/IS9Q2pVeB5JM eIv1lTGG1KBNmza99O7RCwTxuYyfOEFYxtRVbdyYsbJxwwaZ+sfvDgmRCei8SI4bQFi7VevWsNqW DmhTu6wzRNAuMPrfCSVeHCUo/V7cuP4fNBwvpTWwe9duSES5gsSE2Q51bYYlmFmusX7tOjL592lO 19ajG38sLvgNoTWXGgkl4cE1yOpIw5E0Y5rIBViiGjdsKB1R/vETSBWZ5hgEhiJzvjwIXb78BUAA eQxm+3qRQcq/8H+6ej08POWzVl9ApeOSNEeyCEu2sl4011VCpj3/2Lp16QLi3oG7qURM3PfiangO 1126dEnjD+PEiSvVMafs/8XLF8gsfuVN/l5L1ChRdHuSwf//x71FEwYnQOfXlSSQRpzx48Yi8eUO lA7WSpmyZb0G58R/GUtNtQxnNEMEHYiyT50/Bx7GdO2NwPd9+wqfQqeA0ARW/Di8g8dqAs0aNxGK n7P6jiuap6enDP7lF00gWbBooS1GyBVjccYxmdwkhgdq7BdLf7ZGmUpDAh37zduM8qqdu3RTN66y NxyOBI1WwQgRvV/5Hn/79+2VBfPm63vGCB5H+Tlu/fr1Kx3kS1j0ChcpgmogcfQzs/Pv3/sPsYGL YR2cCT3BWFK8ZGnVqTyL6zEtgK/wFz/++/pw/gr9KAEkCbT98aHgnMyfM0tFyP2SQIZd2bsFFHfI JBorsXQi4s7fRgQpwZQWldB8Nv+W+Vzvju8NEXTgrDgyRpBBt+GlcklgpmgupEm2b9uuMYGGBAYG MehcQlaFpeDqwqXDDD9XNpY6YyWDvggkZzUK08I2AkzuatfmS60r2wAWQdMci8C9u3dkz66dsLJl sR0InA+N5A//4p+IiOHjK2MI8+XLD4Lo9fkl5mrZ0iUgdk91/cOHjyQFwkjYSOReQUNw5ow/QA6L Ijkkuy7nP8wWXoS4wf379gszkIuXKCnR4SXj9v8ngHiPz2f/PS1zZ89ABaNJb1gCAyJstoMF8U1A xJJjmzp5ipamZRITC0McOnjQV+ILD8eYVuodf/9DfyXT9G74t4xuXhY/oPSOh4eHYuhzuDze1atX 5S6kdzw8Pd9qxKCqCSXW4oCAU47Jns2+vdlzZGGgLxMj6JxJZMH0IYMGy8y5c0xMYCAh51N9+7bt 1BX7BVyV7tA4juoQjV+9atVbn8DdYZxmDCFHYNCAgSr91aate3z3Qn5G7t0DCdjixX9BV/MTL90+ kj/85/W/9yvJoFoHvQggQ23WrVkD9+QNTW6ihisbHyCHwNV8//49+a5HD00mKVmqFCp2JddqIx6e HtxMGyuLvHz1ElVGkiEbOQGSRGANRL8kg0wYIQk6400CXR0TaI35H5A7ViBi+EbR4sXkt1+GQv9w kiaxWNtQYutn3HPYWNCCMZV0o/tdNmrsGGmF7GkmxrExpnLS1Ck2NQt6sDq2ay9HvOVxqNTwF7wi Hh6eur31z21oM7LKU1LgyP3t3QwRtDeiPvqjdImjYgTjomKDaaIByMyY/goZZp54mjItcAgM6P+j ykH0gkvYXRoz4b+DQPj3ffpoNRNHaBi6w7mG9/hAWlcWL1woy1atfMM64g7zExbHwPKdLPP5WYum 8m2XrlII1js2WgD5twK14inUn/nDDyV6tMjwrmyTM2dOK3FMkyaNbst/SFzmzJqlFaEoD/MC1q75 eABnbC+rRbGUKzUCGzVuLKz8lS9/Pv0juZqN/d4DGcydGxnF4J4kmqdPnZTZM/9weWKI7QTxZtqU qRqeUrZ8ObW8UetyyuRJKgJv1UUuVboMNBiXaCk9isNTcJuJMH6XkUhXr15DPq5WVQ7AMspKPitX rNDEOD6Md4Bw/0MQ6+kowUnxbpZlpeXQZ3sEC2zLZs00k3rkmNEak+lzvT3eGyJoDxTf0keP3r3e ssYsthcCvLiQMNCtaFrgEOBFfsuWzajfPc/p2XDvGiGrjVDwnVmkzFYMi61i5Uph8bQCdU60APX4 rrt07tpF9T4DtZPZKMQIkHRUqVZTTpw4Kj/A1ZkhY0YIuvdQSxY4mdyFxQmmOlQAOatkrkTJklKj Zg3bcZkVzNrdLAnK+tRq6UOfL16+kt9GjNIqX3T3k9yR2MzDtrQcNoMUTcqUKVWwmqLVR44cgdbr eFQrSSqxUHt61ozf3YoEssrVsmVL1SI3AJVw2KhjSPfu79Om2ioCsQxjTFjv4iJp02dJRr/LkiRO IjFjxdR+PvjgA7UEslwu27GjR+Uo/iZOmaxuaC6zKjnxeGzPUWmrDTKHaVGc99efejxdYed/DBG0 M6CmO+chwAvP6BEjZeSYMZrV5rwjh+4jsbb2nPnzbVph7nY2TVFlgDE6YZUINvn0U0hS/OFusDtl PGtWr9bj1ICL0jTnIUACTstfnrz5JXOmLCj3tlyaftoQ7twUyAT+WKphPmZOny49UGuaGcI+G3+L fy6YLz/89JOSOrp1aQkkuXwJIshXiwQyMSRypMj47VbWyl8Tx09C7OFrZCK3wkNnRPlrwZ+wnL1C ZvBzWfjHFHF1drDP8+T7GcCAkjbEYAsSbKxGEkf9z7aovR4UoX2SQFpDJ4wbDzz+U1e41ScF1dlY hvVtbSPK/m3etEk6dOoEi22yt20W4uWGCIYYQtOBqxCggGnadOkkW/ZsrhpCqD1u7Nix3XbsZcuW k17de6gMBWNvwlrzeYMJa+f2rvNhnWXGBZKUmOY8BEjULILHesJ16zeU6jVqyratm5EhPFfGjhkJ N2dSuY6khWRIBEmSJIlKvHCE3O+jnDll5PDh8jFieClBoyQQ1j99BSmkJZDvmR2sy/AaBaEeFUEy 7yGWcPiw4bCsXZP7d/+TcxfOyL07d1Fa8Is3EkOch8ibR6Jbe+b0GSqRM3TYb742OApLZpVKldUq +inc3lbjefttPpextvYXEPGm6zdX7tySJ2cu2+bWte3g/gNqmbWt8PGmNFzQuXPnkcEDB0LnNbnD susNEfQBunkbuhBgrVLGqZj2bgTojogFWQcKxLp7Y/mq0tDtWo0yWE1QZ9S0sIEAZTX4PXybFEfY OEv3PAsmbDAr2Gfj9YCWu8qo3PHgwQM5fPigHDl0UP75e7HcvHFTZWDioQZ0vHjvIbEnoaROlVqO HTshZ8+cVbdo/Hjvs1iIJoBcg0v14YOHEIp+JIxpu3z5gtxGFuzDhw9A/u7Lf//dx7UnHmoXe0jJ kmUlNjQGp02ZAq9ELLUW+hyXq94vRczfrVu3/L3mMHaSygaTJ01CUkhDDalJiNr227Zu1XJ6dHkX LFhI/C7bgCpXVPigK/4aSPZTZP6SLN+FIDf7JMHu2aO7fqagN+NnuSx79hw2GD5v3QoW1+fS5ZvO Srip62jvZoigvRE1/TkFAerfUd+qSDGvoGenHDSUHoSVG6gVyAtKzVq1QsVZFChYQOhGNEQwVExX oAbJ7MoKFSvYLFOB2slsZBcEKNFCvcC3NT4gFiteQkqVKq3JCszsvXjxgpIXkjheb08jeeQWBI4Z t8aawo8QA0iXMxtj4xg3GDVqFNQs/gCZye/DW5MBRC+OxH8/gSRLmlwiwDX8HC7h58/wh9fGLT6X cWPGCTNiv0UShautxNOmTlHv0ttE7Vt+/rleRy2B6TZQOWi5u7nURDIIrXt58uQRv8tYMnHH9u1S MG8+yPLkAVFMJKMQzpQcLvlqNarLKCR/9ESsZu+ePdWSyjrLg4b8/MY0tUHNZbrhu33bBUTylVZx eWOjECwwtYZDAJ7fXf3WGva73pGfw1utYQp+/r1osYyG+rtpb0eAEkaMSaNbghfb0NJoPWrVsqWs hmslrDX/NMnC2jn6dz4Uj+bDSLHixf1bbZY5EIGMadNJn+8Hwl0bRSJFjKRZrizrRj06xu4x4Y6Z r1zGrFVmGXutiyS00EfBXyTdlvt4redy7ke38zOQO8b9PXv6TOsHk+zxs5I+WLNsn61l3BZ/FG2e N+sPzSweMGiQHsuBMNi65r3aHvqEdIPfgeXz/fdhHfUOd/C7jPp/Tx4/hnxOfE3EIYGm5qDPRrc0 rbIJYIF1RfNtK3bFCMwxDQLBQIA6T1mzmdjAgKBjrMo3eCKlLAQlDkJT4xP2lctXbBaH0DT2d401 PH5vaTmiVprfihHvwsqstw8CVrKIfXqzXy9xIINWs15D2bdvn3yBhBKSptDUSISZSGKRQI7d7zLK yJEEslEiyy8JtJa7igTy+IYIEgXTQh0Cp06d8pW2H+pOwAkDHjrkF7h2rslPgwb6ulA54dAhPgQv nrRM8Ek6rLXqVaqGtVN65/ncgAQHb4K0nJjmfARIVGipcscWPXoMqVKjDpJJvMpd/vfff+44zDA9 JhMjGKanN+ye3L2791C70jVm9NCAKmUQWBZq3oIFGqwcGsbsd4wRcfNi9YGw1ugaDm+NcaqWVSS8 nbs7nC/j044fPSzZfWStusO4rDHQila8VFnZsnGdNEYyxkQkklgWsoDKwVn7m9eQIWCIYMjwM3u7 CAFqMsWO474SKC6CRQ/LuJuRw0fI5KlT3fLmSzcVg88pknr16hW5fOmyMJbx5csXyDJ8qJlx1PJi 3MwUZOlFjhxFhVgpn0BZiyQodUV3jGnOR4Cuu0uXLtnmjtmlbJw3ZjZybik3wviymDFjqSWaAfDM HmUyAeeZWZSmOReBbt27S4umTVHZI56kSfN23Trnjsr30SIidjFuvARy5eI5+aRqNZn8+zRbtSh7 xPP5Ppr55BMBQwR9omHehxoEYsSIqcr1oWbAThwoK3OsWL3KLQSjGae4759/ZPeu3VDRPwKrxHEt UxUHJJ4ZdJRbSJQoscRELdSIEKKlnEQkvFLqgrWH7927D3LxCvITD2QdEkeuXbki10EiWbWAGpKZ MmWCDENmCOXm04w/n7E6ToQ8TB6K2ZyUv2D1A+qoMUufbrvESRJLwg8wd4kTwSofXxMMYoD0keh5 1aqFJRduyFu3mGH6Qg4ePCCXIJ57FfIZH2XNpg8nGTJkQIxvVpXQKFqsWKiQNQqtk3z//n1ZvGiR NG7aRH6fOk0yZ8kq5StWkXhuJCX1H8a4fs1KPAw+lzHjx8nmjZu0tu74iRNDK+yhatyGCIaq6TKD tRCg3AHdTab5j4ArBaNJ0latWiWUWeAF/QNYhKienzx5SilWrJR4eHqopmEEWo7gEoronbXoZUnC Zyynq4jZiWzUJ9u79x+NcWKcE6sX8Bi0JFKXbtXK1TJ92h8obfVQSCpKlS4tpcqUdlvL07qNG/S8 3PEfkr6Vy1fo3F24cF6yZMkGIdsUqP1cRpq1/BwyIMmQ2RnRa45gwWHmqM6b33nEnNKtfwzk8cb1 mzpnLJtFqyGtiLQqUpNu06YtKh5ODTXOW7ny5ZXguyM2oW1MtKhPnjgJfxOlZu1a0qhJE5DBpjJs 6K8y+Kd+kidfASlYqIikTp3aZad24fw52bt7p5z595RKRbVt314fKNKmTSsx8HD4WYsWLhtbeDqw kY+x42zngggkn75c0egy27x9mysO7ZJj9u7ZCy6ONEZnzht9uubOnjnj0qxMlkxiOSrWJM0IAVVa 6TJ/mEWOHj4ET+9rjfl5AFJXuGhRrZlJV1AkJX0gFiASfE9SqOSQJBEkgxGCN6FdxkL327Zul0SJ E0qTps1AFCP6snjOg7h4rjz5YX3cK//s2SUXzp+H1lY9adqsKfZJ7JLvaGg5KK22y5YuVdLAOSxa rITWhqVV9sSJY5IqVQpovd0RDw9PyZo9O9y9/58jLyIYAXMWWXXqLPkRWgZZiowWxWXLlmA+LgiF cNPDEhgLZbfoOmY7dPCQPH32EmEATyHM+49s37pFMmbKKM1btISoeJnQAqHbjXPZkqUy5OfBanH9 6ptvbC5Wa6B8gJo3Z47MnjlLNQAzZ8kiH4L0f4jfK0uoOUo+5jGSv44fPQbr8hE5ceyoPlQ0adZM atepI8wg9ttW44GyY7v2cgjbmuY4BAwRdBy2pmcHIjAXF7GdO3bI4CFDHHiU0NE1LS2fQ3MvVepU 0rtvX6cPmjpirKU5acIEkLxiUrZceRSnT6KkbPmyv+VXlKaiHAwbCevc2XPU1VuiVCklhLT+kTh4 vXqTDBA9EkNaldj/2jVrVJi1bLlyajWyTpJxhtGjR1ML0+LFS6UA1P25/cVLF2XT+vUgF3ulfYcO 8mnjRmq5svZz5WvJYsXFXayCx48dl26QFqLAb/kKlSRfvoISKUokGdC/n1RESa2mzZvacNu9a5ds WL9B0qfPINlzfKRkXK25IPSWVVeJvbcllwK4V0A45s+bDytPZGnxWUtbbCe/s+dgDaI1qm/vvlKk eEl9AGAM4i78rjdtXI/vUEL5ccBASe3hOouVK78nITk2q1CUKVcWv8VyAXbDhwCS8Q34rfA3Rvd/ ipSphBY5zzRpgL2nzlkihHC8B+07y1JPohiQjuB9hHRcvXZVbt+8JbQsnz97FvN9Vi7igSC1h4eU LlNGipfgA0dO7TOgQe7ds0d1UAPaxqwLGQKGCIYMP7O3ixA4eeIE3AYt9YYa3uPCunb+VksUjRo7 xnbTdta00ALetFFjXMwjS8vPW2vMH+eDf0wc2L1rpxzcv18qVKggFSpXtI2P4qlzZs1GdYLHUhbu wPfei6vnsAexhLny5JYUSAzhTWrlypXyz+49Uq5CeSlRsqTttGjRmP77dIkGmZknSED4D2ECtAa2 +qItlsVQMvgCySdXEVM4f857KiTOAAAgAElEQVRMyJYkkAmTJ6u7ydaJi97YS8w2pMP/c/4C+eH7 flKvfkN1/dIqa83d7Vu3ZfWq5bAWxdAyjkmSJrEdbucOEsL1sD5n0XJYXHEMLuXbKM9Vpnw5iQwC fxkakLQ40brE2DRLNoZzyng1Zk4nRGzoFbj3b968ge1iI26tsm3eKEC8Yf1aWb92tfyMhz1jHbTB /9Y3q/BbIbFv277dW7d51woS8VMnT6pL/9iRo4jvPKjzeg11glnRgpm8TPbhvDL8hJZ5tosXLmmp Of7m+T2gVFAixJDyATBFypRqacyUOZM+RMSERdg090LAEEH3mg8zmiAgUL5MWRkAjbycuf5fyDsI u4eJTUeNGCFrVq2WP1DUnDE1zmy86LN0HWMAGzZq6k0iREAD1U1I1yL4oLa9u3fL7t07hVbAKlWr 2KwATD6YMxOE8PFDiRkrlqxdvUZ++e1XJY/Lly6X2vXqSP4CBWynxWzjqZOn6v7FSpRUYvkcFkCv +LMXSiT4mVZBLuN7WrsWLpiH0lfxZPiokba+XPXGHYjgrp274HJrJz1799MsbE4U54pEUOcNFlr+ d/feXVkBGaLIsBI2h9XZsuwSO5bO2r6N4SgR5D6IeHLc8KtWqyrUr2SG96eNGqnFl9vyu0KisnnT ZlSRKCApUbfWa944V4wdxDz5mTcuo4t/xu+T5fcZ0zUxiH2Z9n8ESKy3bN6ssbEMoeB3PSmy6h3R 6NZlLV7Wy+V7PgRiWlGK7qIM+mmATJlGlYJ4ej1w9rXIEecbnvo0RDA8zXYYO1eSIF6EfhwwIIyd WeBO568Ff+KmO0Tm/rkAmbeJAreTHbciCejVvaf8/OtvNksfiQSb0giSChIKWIi4nPIw06ZM1gzU uQvm2+LErCHR3R83blwpVLiwXEcR+7lz5uo+DT9tpDcYBr7TYlG+YiWVk3nuTSBeIDOVSSQWkSCB sMjFS2+CQdmSYb8MBqH4QzJnzmwd0iWv7kAE69SsDddhOSQLFNa5wj//f8VcKSH0nje+P33ylPw8 eIB83fkbuIwr+cKNc9Krew/p1qO7unfXrlkrWxHrly9ffq2nunXLFo1BzIvPjEOzCKDXqxcJ9EsE fX7ehdjnUyePyp+wJNI1aZoXAszG79enD35HUUDCpuFByjWWNnoEaK1v2ryZmZpQioAhgqF04syw RYuVly1ZSpYsXw6rxv9dV+EBG5Kw9l+2lRmzZ2lGrivO+af+P8rhQ0ekOwqmk0ZYZAK8QS2CJIM0 M1EYmhaEMbDGPUPBesYPRosWxTZkWgVJAOPGjYfknyZKQmhBIpnbvGmj7N2zV/fPli2HBpc/ffIM buOXIH+vUDs1qmTK/OH/iSBIIV3CljXQixS+UALZv093VFkZpEkLtoO74A2z3Zn17sqWFbI7o8dN kvc/8Kr04UXcOV0k7l5EkBNKIr9+3Vq1/MWCRAy35/yyPXn8ROPEuG/1T2pIOsj5MLnnJaxUF2HJ 27p1m0rPJEWmcdq0aVBLFRqRIOycN1qyGPsX5734ag205omvlnXXIvbXEWs26rehchyZpRxfeG98 +O3XuzcSeU5KL7wyQ95VjW7+4XgQXLJiuWb7umoc5rghQ8ArdStkfZi9DQIuQYDxKjWRiUjLYL/+ P7hkDM46KIlRm1atEXD/meRGDN3PgwbDLT7IZSSQ500JlyNHDmmx+v/j4HWjJvlTUuH9GiduHOny XTcs87IOcqv1iAFjMkERZBGT2DJL+D4qxlD0lkRh2ZIlKCOYUVq0zPn/7vGOEicjhg1DRmRWBJHn VbfjK2gNvsY+1Bx8jWxV4uXz79+TJ/BZpCiO5ermahLI83+GGLzNm9bj91OXdJ2cz/pHibtFBjmH ZcoyQaeC13J8pnt+5YplsKxmAbn7T86D9FFzkIk9xJiuwxV4OKtTt65UrFiBHdvakME/y024F3Pl zoNQhpjY3nveOHfe8+bVz//n7/Chgxp/FtpIIOP1mLk79LffVC7JBkII3jC2shlkYOrWrSe/Dhvu MisgT+EMVAq+79NXpv7xuyGBIZhTd9jVWATdYRbMGIKNAONUKiHZYBjIYK7cuYPdj7vvyMSKicjK vXvnjhKqj6tU0YBsV4573ty5wkSVUqXLSDe4BrWBUNBCZBELdQ37IIUkiDt37tDkgmrVq8Oal8l2 CvuRVPJNx07yG+aSlr7FCxeqa/HI4cPqerLkJaiPNhtyMvv27pOcIBSeyHBUV7APa6BamKg5CAvT k4dP5Jeff1TSshsJJa4udZYbGbd79u+znbcr3mRKl14xHjN+ArQBGVPmNWdefJD/elkDLUJPMyBF f5ctW4owhIRK8iggzUYLHjOPY0P+ox0ytJk9TgshRaRZRzZf/ny6Hf8hOfodbsxo0WJohjnnma59 WnFt1kB97zV3F86dlckTxsGK+EKOnz5l68fd3/BBpk7NWjrMx48fyVhgkiJFimAPe9PGjXDjF9L9 +fCUMlWqYPdljx0ZK9gAZLQ5dP7q1q9njy5NHy5EwBBBF4JvDm0fBFauWCG0NPwJ4uCqOBn7nIn/ vVy88L/2rgI8qqOLXpxCcCdIEiC4OxSX4C4lwbVYcSdIkQLFpVCgOAkWoEAJ7u4uwZ0AgUDR/ED/ eybddBPiWXm7e6dfuvbem5kzu+zZO/ee84AaN2hIy9g/OF78eNS1U2dVrek+amQwLb3Qzzbes9u8 vWn82PEsBfOGteay0JjxvyinCfSI6M15Jl2I3uXLV4Dy5MtDt27epJNMAiEdAe9TXUM+4MoVK1T+ V32eJwjfWiaZd27f4YigM2VmOYujnHOWJk1a1hBsE7TGICAb2EsZW5C5ODoFQoicQAhO63IEIVS7 fPEilr5IwUTGn7x37jBaMr1uPhHdaiFHMHcOZyZoZVio+yT92LUb1a1fXw1bF8X9Y8ECcnB0oIJM WuFAAQKIStAWrq5B+CPiis/e0SNHqOz35ViguDi9YweYkZwqkDNXbhajzqsihdevX6NGjRsF+6F2 7+49WsJV3NhGLs6SNahExZopwXCsIf/t3OFNh1CdXKAQXbl0ni7zdSyl/T53Hh3Yv59WeHqQB7+3 Z/L2KT6v+AEXnTZh/HhVfIMKXHM3kMA2bi2pdt06yv3H3OOR/mOOgBDBmGMoV9AAAohMwVkCkUFL 20IKDz7kz7n90IIaN2miKjGrVqumqvVGsaD2mTNnaMq0qcFIVXjXMvRriFJMGD+BmjZvyZIgXhzl u0K169Shbj26U4L4CVUEaeHCBVxJWl+9BncRfQmYJyzt4snkNkGChCqClJirhpE/BjKgcxAB2Qt8 /FVpBe7asY215xxYkqS1KhjBnBB9QeGMx8oV1KJlWyYsCciXyeX6tZ50++YtKs5Vx3nzFebHHrTa ay05OjoaGoooXU8rRNB91HjG5watWbNSFRv17tOHpXuKcSwwFq3y8FDRWug+onK4Cb//dJHUwG37 rXSa9d0qVKzAP0qKqDUIuW4g5MgJDOBK1v3sMvPgwT1FJPOzKLWu4T0wmvPc7DNlVdv8IIAnjx9V W88fWVqoYjUX1rFLR2s8lliMqDAIIP49Ws8/THW5y7BY7M/44gfQKJbs0UW3dTiEvEXkfzo7gCDq Osz932h7yIPM8BgR3c4cBYRTyU+9e5thBNKlMRAQImgMVOWaJkcA24UgTN+X+5568T+41tBQYNGu dWtluZU4sZ3SXlvOxAlCrmhbNm+m8WPGUqUqlak/f/HAY9iUDV9uQwYNpk5deqg8wXt3brH23Ha6 x9t5zs45lZhthvQZKFWalEreQn9sIABtuBoYBNeF88iSJUseRAARJVKkQkcC8Zjv64pA7rNA7X6u TM2TNzfVa1Cf9QRX0K1btyhHrjx0m6tbz509xb62T3gM7EFcsjRHTZMoWY1NG9bSwkULlduC/lhM fV8LRBBbwyN/nqCifB8/fWRHj0N0YN9uJihJqThv5TbidTmwby9v+Q8LqgjX4TRz+nSO7J6gLj92 pTzsF4wKER0J1BH5QBIYuI5qyxeEkD+je1m02M/vOTu+tONooR9Xhq+jxLw+iPYe5eriG+xkgnOL FmNXmnz5uctY9P7de/JavZwuXLmsG4Jmb4FLtx9/pN/mzeNI539b4hgwtDPHjx3LxTf7aNDgweq9 G/JHK7BasWw5zZ0zR0XcQLaSs5CzFtrWLX/RyBHu6j3RqHFjLQxJxmAgBIQIGghIuYz5EYCOFshg zVo1qXffvuYfUAxGgC/NziyYnYbzsXJxhSfEf1d78ZcmR830GyKG06dOpS2bNrOY8o8q4gKxV1O0 q1eu0I+dulD3n/opIgh7MViHPX/uS0cOH6KzZ04pfTknrhi1t89E6dgGMStvIUMEGg0FHo8fPlK5 am3bt2cywcSBq4ERRQoiEv+SQB3RwPPY/sWxFy6cp8McfXnl/5J8n/py5OoVb02novy8lViQo1Rx 4yH/7H+KBEJfbbXHUjUeU2Cj9T5QDPLzmF8pfoL4yhVEWb7xVu+5c6eZ5B0jH96GTZY0GWHtUOWN /LZ0bNXHnE81RAnhHlGufDllI6gj718VYec1VGQeRDBwq16trVq3L0pEfMP6tUrs2++5Hz179oTX 6DNXFufgdStKWR2d1NYwqoaxbvCa3rjOg85x0YiW28ULF6kjE9wpTJTxgzSsdv7cOd4+H6Eccfr0 6xekk4kI+9jRPytvZ0QBs3EVthYa/l3FDgR+bE2eOsWsNpZawMMaxyBE0BpX1YbnhH+0Wrm6qQjU oCGDLVJ37BX7uvZisd8UKVJQDSa1v4wdR9DdA5EKqyH/DnlIqL6FnlcLNzejRxKQ59Wcq7b79h8a jAgqv2AmhPCf9WeSdvnSJc4P9KGbPEZfjtRBbBZbY4mT2HH+WQrlOoF8s6Sci/Ydk0Q4g+DxO65I fc+J9q/93xALjtArdrt4yzlo796/5SjROyUJA5LiwMQhM0uRZM/mTAn42oiqwJkCW5L6RHDntr/o 57GjlU5hWDia4nktyMc4O2Wj0WMnqYjgf+vFRD4eW4cxoQf+cJi4yRE65PjBIgzSP1gjyMgkYbkf uIUkxHpx7iCKQpLx+xUVv5D28ecq4ncsEv7xQwB9+Pie/LF2vG4f339UOaUJv0tIGTLaK/KH9bPn PFCQfRA/rJ26/ZcIvuUfO5s5mnvmgnkLbMJ7b8BpBbZuv7DAfSUWTY+ogShDemX2jJkcyU+p0inw YyZd+nTB0iciuo4xX4c+JLzDkS+KrWD8uEYupzTrQ0DkY6xvTW16RqlTp1akqS9XLyKiNmX6NKMT IkMCfuH8BerZrZvaFkI+YBeWi4FYbHgkEP0jejBj9ixVlTmft6Uqs58tfEZdW7pRwUKFDDnEoGuh MOfTx09Bj0O7kzp1Gt66rqJs5HRRJ2zbvuaI0mt/f5V/9uL5M4Lg89Onj5X0CEgAiAgqSkE0EjHx SMh5f06O2ZT+HrYSYUmXKlUa+sykQ5EGEAiOKiGSGlYDyYH2nbkbqoZv3r1j7mGEm0uLtcqXPz8V 4vcOUhEQ7X3DRUHPnz3jHNXXqnrd3/+VcpoAwXvx8gVd97kadE24xCTk3M+EHHG0t89ASQoVVl61 SHFIxe8JEIrAdQuM+oG0gwiG2jgMGTuOqmcO9WVzPglCN5tlXFZ5erJrzW+8HVw8UsOJzWLdqJrP 4exMA/r05ar2KWrrGMU4KNAxdZqH/qB9nz6lFZxuAYtApAl4bdxg9ipl/fHJfcMjIETQ8JjKFc2M ADww5/GvWPzjWqu6C43lijtziq5GBg4QH09O0J8+ZSpX347j7eDc9ANH2yZNnhylrZicuXIq8gtd t7Wr19DAfv1VZAzb5S7s94svd0O5MyAy9CkgasQKBAOm87gFuVAkg4kGTOzhdau2l5mwIbKkiwxB 8w6kIdjt58DIEe8jRwZedUw8dmD48PFDpI+35gNBYELmp0U0X+h2pmE7Qbx/sF6wnYsTO3AN8TgO /th7Flu6AZ+wZgGBa4bHTNB16xkRYQ85DqQQwPZOaw2R+wG8tQstxY2bN0Xa3QeEdx275tSqU5s9 ePOQ59pARx04haB6viq7dOTj3EuXmjWpatWq7NmbzuhThybo3j176a8tW1QVeN169ZRtZTauxJdm /QgIEbT+NbbJGeIXd/+BA5T21pCBA5X8xQC+NcU/qlEFHPp5EGbFlumqdWvJycmJ4NqBvLnIbDOF 1h++tJEziL8bPj60zXsbjRjurrTdirAgdSmupC1UuLAqnIiuLyi29/DlDhJrCQ0VmCjAkcYRNv58 gAxaQsP7C+PVSkPqwfKlS2nB7/PpB9cWvK3LxVJMgiPTDh86zAUjYyhlylT0PedXIkUCrjpo+Dzi D9HxwwcPKVHumVw5DAHyEiVLquhcgQIFlSNLVEl8yLFhDlcuX6ETx4/z3zFC4Vex4sU4v7o2Tfh1 UoRVzSGvJ48tG4HIvXste44yehtGoOz3ZWnrju1sbzaXavMvbFfOnevYubMm/qF7zMKwUznid+LY cRo8dKiKEOiWCvmNhvryw/YT/nr2+okQxYAPLLTfkKN0+9ZtJUuDKt8MGTOwxl5G3sqzp4RMSu3s En8TPYSAN3KZfJ/50pNHj9Vxb3nLMAXni2m9feLq2IhkO0wxBy04iyAq+/jRA86v1H7EB8Uiydlt xtwNhHQvV6tD08+JI2VruHgrsrp+d+/cpV840n/D5wZ/1oewU4tLmNPBtjl2MPCHPq9fv87E8CA7 7Wxlb/GpKqUiN0cSs2TNqjQxM2XOpCK1+KGD3RD9hiIev+cv6AmnY7xgRxhoc9644UMYDz7n2Pqt XacuTWLPcq1UJ+uPX+6bBgEpFjENztKLBhB4+uSpIl57WMKiSbOm5NaypclzX/AP+5HDR1jyZDnL nJzliIIrderciUxV6RtyGbBNBYuwC+fO05Mnj9ny7Ym6RVQChRn4ItFvqFqGNlratGkpPUvD7Nu7 X1X4NmzcLHBblyMj/xUf8PYhb/sGPebX/tsO1r8f/a1h5JaFzBEMrVgEeYm7tm+hAyxREvLLUn9+ tnJ/yaLFvA25Ukn/QKRct1WvKxbB9q/uOV2OoP5rhtgaDpkjGLSOIYpFvLdspA/v3qofS9Vdqpv8 s4LKfK+165QwNAo7uvfsQeUrVIj0WwU/nmpUq07tOMLfph10LuNH+tzQDoS2I9x2UHyFz+vjx4+Y 5L1QRVKQqNFvsbk6HHnT2AlJmzZd0I++7Dmyqx0I/WPlvu0iIETQdtfeZmcOQriCidh6Ly/KmDGj StpGvg6qII3V4LCxf+9eJQMTn3/x4wsBQsv6Xwp/btxI1bnAw1ykMDpzf8XCt3Vr1eItrWJcnFJT CeAGET+uGtYCEbx/7w7t2bWdRrOQb3SdHaKDTVjnPGDibW6LMPwA6NC2HRd7vGSLsNZcyJEsKD8T JFALRBDb+Af372G5oADqN2AAreaCDOj0VaxciRo0bKjSPiK7JRvWWoT1PPo+yj/Ydu7cSTvYNxla ndA+RI5tZNu2rd7kyGkeyNvFDytE+qQJAlpEQIigFldFxmQSBPBleJTtyTZuWK+sshxZxqJcuUCr rJys3ZdBebBGfSi47oP7D5Sf7uFDhzhqtpdFc+04368SoRJY315Nd3X49s6ZNZvW8ViMSUh1/Rny FuLQ3Vlc+D0nnLdwa6skMAKjSeYlgqhuPX70EN26cYMmct6TVgqGtCAojfVHBG7ShInsyrKexY2b 8PuyuLIw1AIRvHnjOgta76Fi7MQx4deJQVFcOG6goGH9Oi+la1eqdGm2t/ueChQsQDlyOAfZ30X1 /Q3RamyZnufIOD6v0PpDtX1lJoAo2kCRTGQbIoDI+4MFo4Ojo9IBjey5cpwgYA4EhAiaA3XpU3MI YDsR//hj2xYJ1NeuXVVuFsgFysz+nsgFSs8aX4jgwakCLVDjjmVQXrOchv9resfbVzfZ2eL27Vu8 HZOGsmfPxhZcFakCVwFCkDestnvnLnJnB4fVXChi7khRWGOM6HmQ3/nzfqfFvOWIYpcq1Vx4/jmC RwhNtDX84P49OnOS15At7/AlPoTzL80pxxESO60QQd24Tp44yXlv4+jFi5f8Y6UqleBCIsi8mHpr GLmAZ9kV5tzpkxSf890GDxuqJJB04wx5C89b5NcePHiAIOYMLU0lWs65c8ibw2cuOXtMoxgKn1uk ZQQKYePz6q/kWp5z3hxs015xlT2id3nz5WUv7GocbSwd5a1T7DQgf9DX9yl5svSKNEHAUhAQImgp KyXjNDkCEKdGUvXDBw/o4cOH9Iz9axFFecuED+07iOiy/ROS/5Pz1lqqVKnJwcmRRXKzBdvyDW/g cOdo26o1zV/0B+uHFQzvULO/htwk2LmVLF2K8vMWWWjFLNgCgwsKSCFwKlSoiPKvzZM3n4rqGCNH EHlRcMK4xhZkuAWpb92mtcq/1GJ0VWtEUPfGgoblvLm/cSRuPznnzMkRsaJUmB1aMthn/FcuJlBs GhFDQ+QIQlIGBVNXLl0iHxauvsW+xyVLlaQOHTux6HeZKMvbwIbwLtsbYuv9EX9e8ZlFft8H9iyG GDZacrYyxOdV97nNyHPDjz2kiES34T0P0eXFixZRy1atqDNbzEW3Ej+6Y5DzBIGYICBEMCboybmC QAwQwJZqk4aNaLi7O9WsXSsGVzLdqXv37GFbuc5K6DlP3ryUL18+JWeR0T6TqkJMlOg7NRhEZvCF DG2yfXv3sLvIZbJjqQwHrlbNnIWrHfmLNz0nsOM4fBkn4a3z8HQEUZn86PFT8nsBSzJfjl49Z7eL e0zUb3Oe2wsW1M7B23iVVAQ2f4EC31Q7mw6hiHtqULee0p2L+EjzHAFijZQGrPXJ4yeUaDTWDGtn z5FxFArBQzpDxvQq8o1ik7B0BD+wgPcLjtw94yjZ82fPef1e0COuNr/Hgtog7agGLlGiJK9dFSpX oTzLqqQ0z6Sj2SucfOC3nZc/C4hghhf5j2YXcpogYHQEhAgaHWLpQBD4FgFEKpo3aaIKRn5kJxFL aivY6WTUiJFhDrlTl840cPDgbyI69+/dU4QQlmUPOMqKrbSnTIZ9OdIKOytIuyjLsn+9iD9ywj6i LcAKEZb0TBpRsawkbjLZq5ywnLlzKYKCKJU04yAQWKV6RVWq3uOI2yP2h37K7hNwoEDUHEUQ+IP9 HBxjkrJH8d+cJ4c1RXQWUdnAtcugSL+DgyNHHJ2VL7gWHFaig5ouDxD2ibhfukyZ6FxGzhEENIGA EEFNLIMMwtYQ2LNrt0omnzj5128IkyVgMZSJ3ppVq78Zatfu3bnCs/83z0fmCeRafmLyAPKHloAJ IYihTnA3MtewhGMuXbwYpepTrc8JhA9/IH+V2NpwH+fswYtYl5sX1vi1ukUe1nh1z6OwpGnjRrSB dTj1q/51r8utIGBpCAgRtLQVk/EKAmZGAEQNWoyDWNIDX4q61q5DBxrmPlz3UG7DQMBSCVAY0wn2 dFTmFpVjg3VihgeIbCI/FtZvqPpHcZREoc2wENKlURDQjm+PUaYnFxUEBAFDIIAiGTgbdGayV6JI US4I8VJ5YrprN+Zt7qHDh+keyq0gYDUIQE6mtksNJSsDQWk0IYFWs7wyEUZALObkbSAImAiBQ+wf Chs3SzRyH/vzGEJifIOGDWjUmDGqyrJFs+ZKyw0SOeMnTtDMFveQgYNYwud20KpCBgU6cLDTqt+g QZAmXdABNngnJEaAIFGiRLR42VKTobF0xQqT9RWdjiBHM27MWFWBPIR/5FRkGShpgoA1IiBE0BpX VeakOQTOnD5NA/v1o+UeKzU3tpADglwObOfKlC0b9NJg9j4O6XgC43vIbkyaMllTERK4uKAIRWcD 9pqFpS9evEBbNm+mGVOn0YzZs8ya3A//a3O3kBhhPKaWPNECDmGtAzQHRwx3VzqGLVu3UpqKYR0r zwsClo6AEEFLX0EZv+YRuHPnDvXo1p2mz5rJMifZNTle5djw11+0aeOfLO1xl1q1aROMCIYkgZgE Im0gVVrU6oM2HAiqfgMZHzxgIHXp1Il2sTQK/FfN0bQSCQsNI1PioUUZnf379im90KbNm9PKVZ6m hEP6EgTMhoDkCJoNeunYFhCA+wE8XVFJW6JkSU1NGbIgqzw8WcamKbmwm8LtW7dowKBBdOTEcere s0eEY23avBkVLlIkwuO0ckCRokVp3sIF9L+A/9GvkyaZbViHDx02W99a6ngsu5lopd3i9z5a9hw5 2K6ukFaGJeMQBEyCgEQETQKzdGKLCMC4vnP7DlS3Xl1CMYXWWo+u3VRen6ubm9oCS5Q4UZSGWLde vSgdr4WDYX+HXC+4Z5irtWnZkrSgn/f82bNgEkDx2NatIcuimKrlY3caczc4B8EWDvmAm7b+pUTR zT0m6V8QMDUCQgRNjbj0ZxMIfP36lQZwTqBjNifq3bev2ed87do1pc+nb2O3kC2x4sS1PSFmJ16T nTt2KCFga9MojMobDSkL0IPUNQh6m5IImnNrGCLlc2bNIq9166hT5y40c85s0QTUvRHk1uYQECJo c0suEzYFAnBe+Py/zzR26nizVdPCwg45f5v+3Ejv2W+1Z6+fgvkZ2yIJxNo/40gYCCCIjy03pCp4 rF5lNgggrG2OBjeQju3aU+WqVcibfxCkTp3aHMOQPgUBzSAgRFAzSyEDsSYEUE07b8F8k08Jll9e a9fRhvXr6Q07dSDCM33mTMrh7GzysWixQxTFbN+2TfnbourZHM1SfKXNgY0x+wQBzJ0njyrYWsQy Oblz5zZmd3JtQcBiEBAiaDFLJQMVBMJHAJIXrqztB//dAQMHUvmKFQh5X9ICEQAJRPU2ikUGsRyO udqsOXPM1bVN9zv3t99oEG+FZ86SRUigTb8TZPIhERAiGBIReSwIRBMBn+s+dOfObXKpUSOaV4j8 aXD6OLj/AGXKnJmcc4JL8OwAACAASURBVAZG+xDhwlaXrW756qOnXwgBS7z79+7RX1u20Nt3b2nC r5PMGiGFQ4tEBfVXyzj3Uaz1+9y5KjWjV58+NJuJoDRBQBD4FgEhgt9iIs8IAlFG4NGjR9SOtfeG u7tH+dzInoCI39kzZ+hPzvsDqcH280COcOiIIK4jJDAQTf1CCNiBpUmbhr4vV45+6tObMmXKFFnI jXJcz+7d6WbtO0a5tlyUCIVaa1atplmcElGjZg3q+dNPAosgIAiEg0As/nL5J5zX5SVBQBCIAIE3 b95Qs8ZNqEnTptSxc6cIjo76y6dOniJvlrbw3upNmTkCWLNWLXLhL7gMGTJE/WJyhtkRyO7gqAn5 GGMAEZm5IUKLfL0rV64QIrf3792nly/9KIC37BHFw1eSLn8zWbKkZM/E3d4+E0H6J1ee3JQ1a1aK HTt0CVw4powZNZrevn1LI0aNomLFixljmnJNQcCqEBAiaFXLKZMxNQIBAQHUrnUbypkrp/riMXT/ r7ngo37tOlTNxYX1COux2G0BQ3ch1zMxApEhSyYekuoO4uePHj6ix48fkf8rf4LEyvv37+jdu/fq NuSYYseKTSlTpaSUKVMpL+fU7Ofcolkz8rl96xuidvHCRdq7ZzcdP3Zc2f1lzepAOVi8OUvWLEzs HJTLS7x4cZXfsX4//v6vFVn09X2qfK2vXb2mvH+hQVi8RAm2ESzPn4mCQcRx2pQplJ5/IDVjZxBE gqUJAoJAxAgIEYwYIzlCEAgVAUQu+vbqTR8/fqQ58+Z+8+UX6knhPPnh/XvasX0HlS5bhtKmTRvO kfKSJSMwfOhQGssixuZqz58/VxG5y5cu07mzZ1X+JFIbEiZMSBnt7VXKQeo0qcnOzo6JWWJKzELj iRPbfTPcL1+/kN8LP47mvVRkzc/vBd24foMCPv+PnJnkIXqH83Zs366u7VLDhUqWKkWFChUmiJcX ZQeP0+fPfXPdiJ7A5+T48eN09MhROnTwAL1i0po8eTL6fcECVQgS0fnyuiAgCARHQIhgcDzkkSAQ aQRmTp9OB7hgY4Wnh/qii/SJegd++fyFDh06qPT+9u3dS8VKFFd5f9nYK1eaIGAIBOCasXfPXjpx /BhdYvL3mQuNEEVDdDlv3nwqKoet16g6y4Q1tvccQbzJfd644UMv/V6yk0vFUItzEO1OlixZWJeJ 8HlY9ZUoWYLu3LpNf/zxB+3etYuKFClMP/XuTVpwLYlwAnKAIKARBIQIamQhZBiWhQAI3ED2Dx7I 3rzp0qeP0uARSTxy+Ahr/XkRTO4LFy5MDRs1pkpVKkebUEZpAHKw1SNw/NgxlVOKHxeIoFWoWJHK 8TYqvKHNXSwTU/DhCzx+zFh6cP8+LWB3nKwOWdUlkV+42nMVzZ83T0UeB7JEkOTRxhRtOd8WEBAi aAurLHPUFALIl+rPchb1GjSg+g3qKwkYTQ1QBmORCEBMfIPXelq7ejXZJbFTnsoVK1Xm6Fi+GKct GAOQqOZK+vv706wZM2jzn5uoa4/u1Kp1a4ob91vhCxDf35kMrli+grr37EFt2rbV5PyNgalcUxCI DgJCBKODmpwjCEQSASTgw8kCyeuhfWlF8jJymCAQJgLI75s6eTLt37tPVZS7tnRTDhphnqCRF6JC BCEGXrO6C1Vnjc7e/CMqRcoUEc4CW+LDhgxReY5Tp0+j5CkiPifCi8oBgoAVIhB6Db4VTlSmJAjE FIFXL1/RzOkzlLxFeNeCdAUiM+3btKVqHJE5feoUQWJGmiBgSARAjsaPHUcN6tYlB5ak2X/4EI0Z P84iSGBkcThy+DDBMxsk7s8tm2n0mJ8jRQJx/WzZs9NK3iqGvSLknUCYpQkCgsC3CAgR/BYTeUYQ +AYBJMBDMJroP40z/YPevXunyF+bli2pbMlSdJi/lFu2akXHTp2kKdOmscRGSv3D5b4gECME9uze oyJk//tfAG3buZN69vqJK3QTx+iaWjr5y5cvajggb898fdX9tOnSRXmIEFgfMmwoteRt5B+aNFUV 0lG+iJwgCFg5ArI1bOULLNOLOQIoDOnSqROlSpVK2ZPpxG71r/znxo20bPESlfdXu24dSp06tf7L cl8QMBgC0MrbxHly2O5E8YelttC2hqFdOGfWLLrGwtBLli836NQ8PTxo0YKFtMbLK9JRRYMOQC4m CGgUASGCGl0YGZZ2EIDu28MHD2jh4sUqz+/6tetKv6wDk0NpgoApEZjHfrnbvLfR4qVLLZ7M6OsI IgK4dvUamsHRc1TP9+3f3yg/piZPnESXL1+mRUuXBIlQm3L9pC9BQIsICBHU4qrImDSDwML5C+jP DRtoxuzZtIu34DZx5O8tbwOj2rdnr15SAKKZlbL+gcBqsC+/5zZs3qSi09Yy4zOnT9PI4e6UlDUF h49wN2qOIwhni2bNqQ7nVbZui1QPaYKAICBEUN4DgkAYCKzgralpk6coLTK4JzRs3IgaNGwYqjhu GJeQpwUBgyHQlnNOITnUqHFjg13TnBdC8RWqf0+eOEGorq9Rs6ZJhnP79m2VL7hz754YCVqbZLDS iSBgAgSECJoAZOnCMhHo0LYdBbALQxuOHECQN168eJY5ERm1xSOAPNUCefMqSzZYwVlDy5szF527 dNEsnyvIyqRhb+TefftaA5QyB0EgRggIEYwRfHKyICAICALGR+DTp09UOH8Bunj1CsWJE8f4HZqg h4cPH5rN5QTuJK1auNLBI0cIlcXSBAFbRkDkY2x59WXugoAgYBEIJEiQgJycnNgv+LhFjDcygzSn 1R28vNNnSE9Hjx6NzFDlGEHAqhEQImjVyyuTEwQEAWtBoAdrBQ4ZNFjl00VmTvDi7ccuHBA1r1ur NqFi9vXr15E5NcrHQEezOev0HQuDWEX0OjrUaQdGufNonlCmTFk6c/pUNM+W0wQB60HgW6NG65mb zMSKECiQJy+9Zw9RrbYkSZLQ2YsXtDo8GZeFI/Dhwwc1gy+fP1On9u3ZMcOTvkuUKMxZgXi5/dCC vv7zlapWq05v3/5NS1lypkixYlSZ5VkM3UDi4KDj/8o/1EtH9Pr/OBe3XOky1LN3L3JjUXZTtHwF 8rMiwEZTdCV9CAKaRkCIoKaXRwanQwAkcOwv43UPNXc7fMhQzY1JBmT5CFy6eJGWLVmqpIuKFC2q JIuqVq8WLgnErE+dPEmPHz+m7bt2Kqs1PNe7zwNV/IT7WmsoxGrfsSOVKFHCZENLnToNQQ1AmiBg 6wgIEbT1d4CFzX/M2DH06V1gdEQLQ//uu+9oGGufSRMEDIkAPHZnTp9OL/1eUgs3VxrqPpySJ08e 6S50BSXnz58PIoKZMmcOdv4///xDT58+5SjeK3JwdCS8l9HwOAFXJuPx3Tt3KUPGDBQ/fnwV7Uts l1jdx3Ef+MfZp4CAb8b17NkzgjRMdvb6Da0QI6zXmzZrxgT3O+XljchiosSJKHbs2ITCjsw89tAs 9GD9iEIatPgJ4od6jHoxlP8l4r60vMsQypDlKUHAKAgIETQKrHJRYyEAEthqzUhjXT7K113ebHSU z5ETBIGwELh27RqNHf2zygPs068vVatePVoOGKVKl6aCBQvS4AED6erlK9Srbx+ys7ML6hZaer17 /kRX2GUDDdvMGzf9qUhjDd5KBvm8d/ceW9n9SenSp6dVa1ZTpfIVaPqsmUqMGefM/W0uea1bR4eP /VdwMW3qVLp18yZeVuf9Nm8uFSxUSD3G/8J7vWypUjRg8CBydXOj4myd1+yH5rRrx05F1lAs88eS xVSocGF1rXVr19KMqdPoyZMnQdeuzxqLU9h2L7LtzZs3lDRp0sgeLscJAlaLgBSLWO3SysQEAUHA UhCATiAigO3btKUmTZvSX9u8qbqLS7RIIOYcN25cWuHpQQ0bNaLFixZRnZq1gkgf8vV6de/BeYNv aeUqTzpw5DANHT6MYuvJ0mzetIlKly1Da9d7UUMWUU/JPtuRaY4cWdx38ACPfxul4Ahmrx49KYCj hroW0eu643B7w+cG/bV9G508e0Y5qUxnkhn4vA8NGTiIGjVpTJ5MUPPlz0/tOG8yKiQQ13nAtpH2 9vbqmvI/QcCWERAiaMurL3MXBAQBsyOA7c3OnB8Hq7XNW/+iBo0aqi3RmA4MUb6Jk3+l2exP/J6L R5o0bETwyb529Spd5b+Ro0dRSY7CZcyYkVq4uhJImq7lzZuPsFVbmCNz/QcNpFj8X2QanHewBZ0z V04aPGwYQSvw8qVLQadG9HrQgXynJTupQPQZW9SVq1YhHyaGaPfv3VdEt1uPHlSccwph97jN21u9 FpX/XTx/gfIXKBCVU+RYQcAqERAiaJXLKpMSBAQBS0DgM1cBgwSCjP2xeIlRPIRr1KpJXhs3cL5e XPJYsUKRM2CTPUeOMCFydPqPFIZ5UAQv6K7x4sWLUI+M6HX9k5IkSRoUWSxesoQih0MHDyZPDw9a ysU0RbkaOioNUdFdu3axY1CFqJwmxwoCVomA5Aha5bLKpAQBQcASEJgxbToh/200F0GhMMJQDUUi iTiSlsPZWV0SUToIOPv7+wdthyIiFtbWaMixxIsfT21T//3330FDRLFJeO3ihUA5JQcHh1APi+j1 UE/iJ5HXt3jZUvqhaTM6cew4y+FUob4D+od1eKjP792zhzJw7mOWrFlDfV2eFARsCQEhgra02jJX QUAQ0AwCyNFDRGvL1q0GJYGY4DNfXxrYrz+58fZqYS6wOHvmDOfc+VCHTh0pd548qujCnfMCQQyz Zc9GkKlBIQa2gkNrkHdBBPHPDRuoStWqdJsreb24YCNWCPJ68uQJSpU6Neff3aeJ43+h0mXKqPN0 BDKs10PrM7zn3IcNJ5caNWjazBlRzqMEgZ07ew516dY1vC7kNUHAZhAQImgzSy0TNRcC+EK+d++e 6j5hwgTqi7FN27YSjTDXgmik33Nnz1KuXLmU1Zmhh6Ry5zhfb+nixTSPcwRRPNL5xy7UuEkTRZxQ zes+fDiNdHdXjh7IxZs0ZXK4wxg95mfq9mNXKlOiJBUoWIBKlCxJJ1mvEA1EMT8LNC/l7W384TGK XdxHjVT9RfR6uB2HePHr16+q/1Uenorgli33PecJNlD5jiEODfXhmlWr1TY5KrKlCQKCAFEs/nUU fnxfUBIENIBAdgdHJSgN4WatycdA6Brjunn3TqhI1eWKTeRJlStfXlVqwoYLTgqbORLk4OgQ6jny pPUjsJ0rayG/Mn/hQqNNFqQJ770UKVIochayI1T0IjKZMmXKkC+F+hjVza/fvA7zeDigIMqYNk3a UDUEI3o91E5DPNmlUyclidOydWulaXjq1EnattWbZs6eTbXq1A5xdPCHiIq2cnVTFdXh5UgGP0se CQLWjYDhklKsGyeZnSAQIwSQq4WIy2+/z6O1G9YTvhDXsvSFNNtFANuwZ06fUe8FY6GAXL+0adOG SgLRJ4SiI0sCcTwEosM7HhW+GTJkCJUE4vyIXscxEbWjR47wFncnFeFs276dqopGxfO5c+fCPRUu Ip07dqIhvCUuJDBcqORFG0NAtoZtbMFluuZHIF26dGoQ8CeWZrsIgKBV5Xy7cWPG0Jhx46Kc62ar yEFnEZqLFy6cV/Iyly9dpkePHlHtcKKBcDNpy/mSzZo3U9vItoqdzFsQCA0BiQiGhoo8JwgYGAFY WcFx4cTx49SvTx+VH1inXj0D9yKXszQEho8cQRe4enfYkCFBVmmWNgdTj9d95EjlcIIfVO/evqMy ZcsoT2V9BxP9MaEQplH9+soRpWv37vovyX1BQBBgBCQiKG8DQcAECKAwwKVqtaCe4ISQkP1cpdk2 ArB9W7VmDQ1k+ZPaXAU7kLXxqlarZvAqYmtCOVasWCrfFjm3ETVY6bVt1Vp5EKfgPEhf9laGZZ40 QUAQ+A8BiQj+h4XcEwSMhgBssFax3IbH6lX065QphDynerXr0KuXr4zWp1zYMhBIlDiRynMbypIo c+fMoaqVKtMiLiB5/PixZUxAw6N0cnKig2yhN2yEO104d57q16mrHFY2rt8QJFCt4eHL0AQBkyAg EUGTwCyd2DoCEMEtVvxf94OSREWKFqUqFSvSeq91KvHd1vGR+ZOyUYOV2qmTp5RG35xZtTiFIAtH vyqwHl9ppfOHYgtpUUMAVnuQssEfHEX27N5NK5cvpwnjx9MPri2oU5cuKmIYtavK0YKA9SAgEUHr WUuZiQUh8PZtoEPDx4+fLGjUMlRTIIAfDL9MmkhHWZy534ABvE0ci+bMmk3flypNlZgUdu7QgebP +50g5SItagjEiROHoB+4hImg59o15Ov7jKpxBHbFsmUEuz9pgoAtIiARQVtcdZmzyRFAbhKEbKHr 9uTJY1q7eo2yFotI98zkA5UONYMApF2+L1dO/WFQ0ANs27IVa1B+VtWvkHKxlIZIHEiYlhokZ36Z OIF8rvvQaC5A2eC1XhWhZM6SRUvDlLEIAkZHQCKCRodYOhAEiG6xJddQLgQYPnQowRHBOWdO8uQi AXwZSRMEIkLgwf371KRBQ94+rkoLFy+i5CwQbSkN4ullS5ailStWaHLIzjmdabnHSqpZuzY1Zoz3 7NqtyXHKoAQBYyEgEUFjISvXFQT+RWCz91bBQhCINgJ37tyhNm4t6cfu3cjVzS3a1zHXibCXa9+x I5UoUcJcQ4iwXwhvd+zcSUnRdOrQURWS1KhVM8Lz5ABBwBoQECJoDasocxAEBAGrRABV5R3atqOu PbpTC1dXg84RaQp3WF4FLqOOXF2rv3WL1+7fu8/PxaZMmTMHE7v2f/WKErD0EQpX7t65SxkyZlBp Dng+fvwEhCpoXYN9HbaFmzZrRt8lCl7ogn6fcsoEznPgyLh+IUx4/euubYzbPHnz0qIlS5T4dAL2 Ba9UubIxupFrCgKaQkC2hjW1HDIYQUAQEAQCEQBR6tWzJ7nUcDE4Cfz06RO5Nm+utC1rVKtOlcqV V4QMPV+9coVcqlRlGZtKqjilaaPGKj9Rty44fv68edS3V291TOUKFcnPz48G9u9PjRs2VMQSx6L4 AtqZkydOorKlSpGnh4fuEgR9P0i5lCtdhurWqk0lihZTgus4IKL+gy5ipDs5c+WkmXNm05CBgwiO JNIEAWtHQIigta+wzE8QEAQsEgEUFL17944GDBpk8PGfPXNGydTMmD2Ljp8+Re06tKevTDwDAgKo J7tvpGe/YDx/6OhR5Xgyc9r0YGPYvGkTlWZHj7Xrvaghkz/4D2P794aPDx0+dFgdu2PbdiXg3KZd 22DnIkLYq3sPQrRw5SpPOsA6f0PZ/zc2F5NEtv9gFzTCg+K8jd2UifLYn382wtXlkoKAthCQrWFt rYeMRhAQBAQB+vvvv2nKr7/SspUrjeIy4pQtm9LOm/fbXMqRw5mJYAeFOhxwsN3b/IcWdO3qNfUc 5Gx27dgZbFXy5s2ntnvxZOEiRdRrJTnqlzt3blqyaBFXOn9Py5YuUbfZc+QIdu61q1fpKv/9sWQx 4Rw03bZ3ZPsPdkEjPejarRuVL1uWnj55ysQ4vZF6kcsKAuZHQCKC5l8DGYEgIAgIAsEQWLZkKVWo WJGwTWmMljZtWlq3YT3LGX1hh5vaStoI/fj6+qru4IntySQUf8+fPafCRYsEbfniAEenb6vdYf2G qOC+vXtpy+bNKuLYpl07dT39/z18+FA9DEkQ8WRk+9e/nrHuI9cRfuDr2BFImiBgzQhIRNCaV1fm JggIAhaHALZOly9dqiRNjDV45B/mcHamP7dsoelTpippo2zZs5GDQyDBa9ykCelXzeJ4ED1dQ5Vt aK123To0acIEGtC3H2V1yKrIbMjj7O3t1VMXz18g3X3dMZHtX3e8sW9LccQS2+DSBAFrRkCIoDWv rsxNEBAELA4BbI+m4Jw7EDVjtW1bvekM5wnWb1Cf4IONBm/jOnXrUqnSpcmdc/Zev36tIn83btwg HA+tvYgaRLBbtWlNUydPodZt2oa6rZ07Tx5ll4c+/P39CQT00sWL6rlChQvHqP+IxhfV1zNnyczV 0/eiepocLwhYFAJCBC1quWSwgoAgYO0IHDl8hCpWqmjUadpnykTTpkyhxX/8ofrBNrRLjRoq6oeK 2cFsbTdi+HAl/ZIsWbKgHMLIDKqFqxtha7tx0yahHg6Zmt/mzWWyOZxGururPtKkSUOTpkw2SP+h dhrNJ+PEjRtsSzyal5HTBAFNIyBEUNPLI4MLiUCCxN/R8majQz5ttsfJkiczW9/SsXUicJcFpGEt Z8xWoGAB2r57l4r6QbMvBTuV6LZ+UQE8nwnix48fVWVvqlSpgl7DmI6dOhnu0FKkTEHeO3aQnZ1d 0HFXfK4H3cedtOnS0e8LFqgqYVQPo09di6h/3XGmuEU0MKN9RlN0JX0IAmZDQIig2aCXjqODgPtw 9+icZtBzzpw6RYntkiidtKRJkxj02nIxQQBbtPaZAvPojIkGiF/y5MnD7CIhi0bjLzoNZDAyDVvJ +iRQ/5yY9K9/nZjcP3TgYFBlc0yuI+cKAlpGQIiglldHxqZJBOLyl5dKnqd/CFtH0gQBQyKAQgy8 v6SZF4E3b96QN9tDbv5LLCLNuxLSu7ERkG8xYyMs17c6BAoUKGB1c5IJaQcBWK29e/deOwOy0ZEg h7JGjZqiIWij629L0xYiaEurbcFzTZo0KQ0fMlSzM8iYUfKINLs4FjYwR/bdvcmVupWrVLawkVvP cA8dPEjbvbfR1h3brWdSMhNBIAwEhAiGAYw8rS0Ezlw4H+aAYMO1Z/du8uYtnCOHD5NdEjv68vkL vXz5UlUkhnliKC+gojFJkiQqiT01VzJWrVaVGrGmWq5cuUI5Wp4SBAyPQL4C+ZVci+GvLFeMDALn z52jfr370Oy5v4WbQxmZa8kxgoAlICBE0BJWScYYLgKobvR74aeM75FflSVrVnJm26zszjkobhRz +D5//szRmJt044YPXbl0mc6dPUcZM9oT5C1QPSlNEDA2ApUqV6ZR7iOUz3DixImN3Z1cXw+BPbv3 0KAB/Wny1KkEv2FpgoAtIBCLk5IlK9kWVtqK51iyaDHKnj07OefORQ68rZaAizkM0T4FBNBNHx/y ue5Dt2/dornz5xN8V6UJAsZGoEfXblSU32vt2rc3dldGvb6nhwf5Pn1K3Xv2pHjx4hm1r5hcHDsI M6ZPp/Ve62j6zFnyOY8JmHKuxSEgRNDilkwGHBKBwvkL0N9//x3yaYM/xvbwlm3eBr+uXFAQCInA 1atXqQM7c+zYszuYHl/I47T8GHNo27IVFSxUkOAvPGbcOCpaTHs/pI4fO0ZjRo2mzFmy0LgJv4Qp Z6NlrGVsgkBMEBAiGBP05FxBQBAQBIyEwNDBg+mfr//QL5MmGqkH413W/9UratKoEfXu21fZ1m3Z vFnZzjk5OdFPvXsTBK3N3U6dPEVzZs2ieywaPYxdTqpwPrA0QcAWERAiaIurLnMWBAQBzSPwniVk 6tepQ527/khNmzXT/Hh1A/Tz86PWbm5Uq3Yd3hLuoXtaCbCvX+dFixctIuQ+/uDagiujq5g0AofC sm3e3rRy+XIuJntFXf7FNqq5xEGTkjuCgBUgIETQChZRpiAICALWicAdtptzbdacJk7+lcpXqKD5 SSIfsDVvB9etV496/NQzzPGePHGCli1dSvv37aOCBQtRterVlYNHDi7wQsGXIdutmzdVP8d4C/g0 RwFLlCxJTZs3V37Ohu7LkOOWawkCpkJAiKCpkJZ+BAFBQBCIBgLnzp6lHzt1ptFjx5BLjRrRuIJp Tjmwfz8NHjCQ2nXoQJ26dI5Upx8+fKAjhw7TNs69PX70mKqULlioEOXOk5ucc+YkR0cnSpM2jfJC Ds/u7tOnT/TM11dt86LqH8Vdt/gPeoxJ2AayVOnSVKZMWapQqaKKRkZqcHKQIGAjCAgRtJGFlmkK AoKA5SJw9coVRQZr1alN/ZlsxYkbRzOT+fD+Pc2cMYM2b9pEU7nyFhG36LYnT54o2SaQuDu3b9MV nref3wt66feS4saLS/HjJ1A6n/rX/5ut4N7zGFKnTk1ZHRwIUUVn55xMJJ35vvM3x+ufK/cFAUGA SIigvAsEAUFAELAABFCAMXDAAKWZOfaX8ZQ7d26zjhrKY39t2UITx/+iqoFHjB5l1Hw/5PcFfAqg t2+DKwTY2SWhFClTmBUL6VwQsGQEhAha8urJ2AUBQcDmENCRr5KlS1HX7t0JlbimbF+/fqWdO3bQ /Hm/MzH7RCCAIr5syhWQvgQBwyIgRNCweMrVBAFBQBAwOgLQzVzIAucrli2nsuW+pxaurioPLlas WEbrG9u2qLj1WL6CUqVORW1Z7BpFHrBllCYICAKWi4AQQctdOxm5ICAI2DgCIIQb12+g1Z6e9Ja3 TitXqczVsJWoePHi9F2iRDFCB24bly5dpKNHj9LObdvp7t27ivi1aOnGlb4FY3RtOVkQEAS0g4AQ Qe2shYxEEBAEBIFoIwArxB3bt9O+vXvp+vXrKocwX/58yjEjS+YslC59OkqbLh0lSJAgWB8gkyj4 ePDgIT1iBxC4gPjw+ahWzpQpExVhN5Dy5ctTuQrluVjDMPaNwQYgDwQBQcCsCAgRNCv80rkgIAgI AoZHAHIqVy5fpuvXrisZlbusR/iUNf5ePH9OAeyhrd/s7OxU9DBz5szKq9vBISs5ZcvG7h8FRWpF Hyi5LwhYKQJCBK10YWVagoAgIAgIAoKAICAIRISAYSXcI+pNXhcEBAFBQBAQBAQBQUAQ0AwCQgQ1 sxQyEEFAEBAEBAFBQBAQBEyLgBBB0+ItvQkCgoAgIAgIAoKAIKAZBIQIamYpZCCCgCAgCAgCgoAg IAiYFgEhgqbFW3oTBAQBQUAQEAQEAUFAMwgIEdTMUshABAFBQBAQBAQBQUAQMC0CQgRNi7f0JggI AoKAICAICAKCk80OzwAAAMtJREFUgGYQECKomaWQgQgCgoAgIAgIAoKAIGBaBIQImhZv6U0QEAQE AUFAEBAEBAHNICBEUDNLIQMRBAQBQUAQEAQEAUHAtAgIETQt3tKbICAICAKCgCAgCAgCmkFAiKBm lkIGIggIAoKAICAICAKCgGkRECJoWrylN0FAEBAEBAFBQBAQBDSDgBBBzSyFDEQQEAQEAUFAEBAE BAHTIiBE0LR4S2+CgCAgCAgCgoAgIAhoBgEhgppZChmIICAICAKCgCAgCAgCpkXg/56zFYz8O+NV AAAAAElFTkSuQmCC --047d7b34340c73a36d0503b2572e-- From nobody Tue Sep 23 08:18: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 CFEF91A1BAD; Tue, 23 Sep 2014 00:50:48 -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 GtbdCGDKQHhY; Tue, 23 Sep 2014 00:50:46 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A41A1BAF; Tue, 23 Sep 2014 00:50:46 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XWKrv-0002h1-Nx; Tue, 23 Sep 2014 09:50:42 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest125.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XWKrv-0006eB-9H; Tue, 23 Sep 2014 09:50:39 +0200 Message-ID: <5421264E.3020103@bwijnen.net> Date: Tue, 23 Sep 2014 09:50:38 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jeffrey Haas , netconf References: <20140922210546.GA5676@pfrc> In-Reply-To: <20140922210546.GA5676@pfrc> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e612c824b427cae28f7af699a306405d Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LF6SF2M5O_Dl0PhbsVQMNi6toiU X-Mailman-Approved-At: Tue, 23 Sep 2014 08:18:14 -0700 Subject: Re: [i2rs] [Netconf] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 23 Sep 2014 07:50:49 -0000 [bcc to i2rs and netmod]; I propose to discuss the netconf aspects of this on the netconf mailing list. However, for i2rs "consensus" on the specific netconf requirements, I think it MUSR be dealth with on i2rs list. Thanks Jeff, this is good for netconf participants to be aware of. And to discuss/comment on. Bert On 22/09/14 23:05, Jeffrey Haas wrote: > [BCC: netconf] > > The netmod interim in New York City last week was a productive discussion for > I2RS, although it was frustrating in its conclusions. (Those conclusions > mostly being, "There's mostly no work needed here, go talk to netconf!") > However, given the large overlap of WG membership between netmod and > netconf, it should hopefully make the next form of this meeting somewhat > easier to have. > > Thanks to Cisco for providing the venue for the interim. > > This writeup is presented to document my perception of our discussion and > provide the seed to start further discussion in i2rs. No specific requests > are being made to netconf at this point - and to reduce accidental noise as > we try to converge on our discussion points, I have placed them in the BCC > field. We can make more formal requests once the i2rs discussion of the > netmod interim has gotten some traction. > > Juergen has placed the full netmod minutes here: > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt > > A small excerpt from those minutes: > : Conclusion: We do not need any changes for YANG 1.1 (hurray) but > : instead we need a document that introduces ephemeral datastores and > : clarifies what validation means with ephemeral datastores. In > : addition, the NETCONF WG needs to do work to define suitable > : protocol operations and RESTCONF needs to make sure it is prepared > : to support ephemeral datastores. There is also NETCONF work to be > : done to improve notification handling. The only YANG 1.1 homework is > : to make sure that the language in the YANG 1.1 specification is > : flexible enough to enable the introduction of ephemeral datastores. > > Background: > > The seed for the discussion at this interim was the somewhat hastily > authored document: > https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 > > ----- > > Ephemeral state: > > The I2RS portion of the discussion was kicked off by talking about the > ephemeral state that I2RS wants to have and why it is important that it is > ephemeral. The three options from section 2.1 were presented and discussed > at length. The points about the advantages of a separate datastore (easy > cleanup, clear segregation of state) were compared against the desire of > other non-I2RS users wanting ephemeral state. A point that was raised early > was, "why can't we simply let the operators choose whether something is > ephemeral or not?" > > This lead to a discussion regarding the nature of "priority" and what its > impact was with regard to how ephemeral state was kept. One thing that > became apparent during this discussion is the I2RS Architecture draft is > potentially not clear enough about the distinction of I2RS state priority > vs. Local Config priority (section 6.3 of the Architecture draft) and client > priority (section 7.8); the word priority is overloaded. > > Clarifying client priority vs. state priority lead further into where such > data is kept and how it is used. Room discussion eventually went to > identity and how it was associated with priority. An observation was made > that this information is effectively meta-state being kept on the > configuration nodes. Such information, not being yang specific, was > suggested as a point for netconf. It was observed that the identity may be > useful information for general users and may not be i2rs specific. The > analogy was made to "git blame" (and other similar source-control annotation > mechanisms). > > The "where is the ephemeral state kept" conversation began to converge > around a possible fourth option - one that apparently had some discussion > much earlier in the i2rs working group's life, apparently. Here's my > attempt to describe the conclusions of that discussion: > > - There is a new ephemeral datastore. > - It may be used by my many applications, including I2RS. > - It has the property that the schema of config state is "visible" in it > from a read-only perspective. > - It has the property that writes to it may either create new state that is > disjoint from the config data store state or it may cause changes to > information that is/was visible from the config state. Such changes may > be merge, override, delete, e.g. > - This "shadowing" behavior avoids issues in the existing yang by not > requiring additional language semantics that would require mechanisms to > cross-reference between datastores. (One might observe this is somewhat > similar to Object Oriented programming where the configuration state > serves as a "base class" with ephemeral configuration extending that > base. A different analogy is the union filesystem semantic.) > > Issues that came up with this model under discussion: > > - Validation is a problem with this design. (And was likely even more > complicated in the original 3 discussion points. This was one of the > elements that drove us to this fourth option.) > - It is possible to refer to config state from ephemeral state for > conditions (must, when), but not vice-versa. > - We (i2rs) must decide what happens when ephemeral state has conditions > that are invalidated by a change to the underlying config state. In such > a case, the config state may validate, but i2rs may not. Does the > operation succeed or fail? > - Such constraints and their validation impact may negatively impact the > desired speed properties of i2rs. However, it was also observed this is > only the case when such references exist and that "fast" i2rs operations > could simply be modeled with no dependencies on config state. > > - Ephemeral state priority vs. Local Config priority is difficult to fully > support in such a model. In the above discussion, ephemeral state always > has priority over Local Config. > - Providing for Local Config to have lower priority may be possible, but > introduces some unusual semantics. > - Does I2RS have clear use cases for Local Config winning? The example of > "configuration of last resort" was offered but is potentially a weak case. > > In summary, the fourth option was strongly driven by the arguments of "what > keeps things simple". The original three options were apparently not simple > enough and there's some doubt about the impacts of the fourth. > > Possible yang 1.1 implications: If the above model works, the discussed > configuration semantic may be the previously discussed > "config (false|true|ephemeral);" > > ------ > > Mutual authentication was also discussed. As noted on list conversation > after draft-haas-* was published, while restconf doesn't currently require > it, it is suspected that it will have such a requirement before working > through IESG. > > I suggest that I2RS requirements are addressed for this point. > > ----- > > Identity requirements for the primary identity are covered by authentication > requirements for the existing protocols. The "secondary identity" > requirement is a netconf issues and we should talk to them about the > implications. Since the primary requirement for this feature is for > auditing, this may simply be meta-data that is kept on configuration state. > (See commentary above.) > > It is noted, however, that introducing something like a secondary identity > would require changes to SSH and/or TLS and may be somewhat difficult to > make the case to the owning working groups. > > Per-client priority effectively becomes the ability to say "you can't write > to this if the state exists and has an owner with a higher priority". > Further discussion on this point is needed in light of the fourth option we > were presented. > > ------ > > Persistance of subscriptions. Effectively we were told "go talk to netconf, > it's out of scope for yang 1.1". > > Some discussion was given to the filtering considerations. Extending the > filtering options of the ietf-inet-types module may be appropriate. > [Juergen, is this an action item for yang 1.1?] > > ----- > > Hopefully this is clear enough to kick off discussion. > > -- Jeff > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 23 15:14: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 340031A1BD3; Tue, 23 Sep 2014 15:14:22 -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 S6r8_SCIJaq7; Tue, 23 Sep 2014 15:14:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5B42D1A8880; Tue, 23 Sep 2014 15:14:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" , , References: <20140922210546.GA5676@pfrc> In-Reply-To: <20140922210546.GA5676@pfrc> Date: Tue, 23 Sep 2014 18:14:16 -0400 Message-ID: <01ee01cfd77b$b6fc48d0$24f4da70$@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: AQF3IdMyVAHRiXadTYRdGi5dr3BteJzAsZSg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/t-1KpJKDJvVig7NKz2p768s_lA4 Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 23 Sep 2014 22:14:23 -0000 Jeff: The fourth option is interesting and creative. A few questions/requests: 1) How would the fourth model be expressed in the yang model - config (empheral)? 2) Please define your definition of local config with an example., and 3) please give an example of the (must, when) use cases envisioned? Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 22, 2014 5:06 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf [BCC: netconf] The netmod interim in New York City last week was a productive discussion for I2RS, although it was frustrating in its conclusions. (Those conclusions mostly being, "There's mostly no work needed here, go talk to netconf!") However, given the large overlap of WG membership between netmod and netconf, it should hopefully make the next form of this meeting somewhat easier to have. Thanks to Cisco for providing the venue for the interim. This writeup is presented to document my perception of our discussion and provide the seed to start further discussion in i2rs. No specific requests are being made to netconf at this point - and to reduce accidental noise as we try to converge on our discussion points, I have placed them in the BCC field. We can make more formal requests once the i2rs discussion of the netmod interim has gotten some traction. Juergen has placed the full netmod minutes here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.t xt A small excerpt from those minutes: : Conclusion: We do not need any changes for YANG 1.1 (hurray) but : instead we need a document that introduces ephemeral datastores and : clarifies what validation means with ephemeral datastores. In : addition, the NETCONF WG needs to do work to define suitable : protocol operations and RESTCONF needs to make sure it is prepared : to support ephemeral datastores. There is also NETCONF work to be : done to improve notification handling. The only YANG 1.1 homework is : to make sure that the language in the YANG 1.1 specification is : flexible enough to enable the introduction of ephemeral datastores. Background: The seed for the discussion at this interim was the somewhat hastily authored document: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 ----- Ephemeral state: The I2RS portion of the discussion was kicked off by talking about the ephemeral state that I2RS wants to have and why it is important that it is ephemeral. The three options from section 2.1 were presented and discussed at length. The points about the advantages of a separate datastore (easy cleanup, clear segregation of state) were compared against the desire of other non-I2RS users wanting ephemeral state. A point that was raised early was, "why can't we simply let the operators choose whether something is ephemeral or not?" This lead to a discussion regarding the nature of "priority" and what its impact was with regard to how ephemeral state was kept. One thing that became apparent during this discussion is the I2RS Architecture draft is potentially not clear enough about the distinction of I2RS state priority vs. Local Config priority (section 6.3 of the Architecture draft) and client priority (section 7.8); the word priority is overloaded. Clarifying client priority vs. state priority lead further into where such data is kept and how it is used. Room discussion eventually went to identity and how it was associated with priority. An observation was made that this information is effectively meta-state being kept on the configuration nodes. Such information, not being yang specific, was suggested as a point for netconf. It was observed that the identity may be useful information for general users and may not be i2rs specific. The analogy was made to "git blame" (and other similar source-control annotation mechanisms). The "where is the ephemeral state kept" conversation began to converge around a possible fourth option - one that apparently had some discussion much earlier in the i2rs working group's life, apparently. Here's my attempt to describe the conclusions of that discussion: - There is a new ephemeral datastore. - It may be used by my many applications, including I2RS. - It has the property that the schema of config state is "visible" in it from a read-only perspective. - It has the property that writes to it may either create new state that is disjoint from the config data store state or it may cause changes to information that is/was visible from the config state. Such changes may be merge, override, delete, e.g. - This "shadowing" behavior avoids issues in the existing yang by not requiring additional language semantics that would require mechanisms to cross-reference between datastores. (One might observe this is somewhat similar to Object Oriented programming where the configuration state serves as a "base class" with ephemeral configuration extending that base. A different analogy is the union filesystem semantic.) Issues that came up with this model under discussion: - Validation is a problem with this design. (And was likely even more complicated in the original 3 discussion points. This was one of the elements that drove us to this fourth option.) - It is possible to refer to config state from ephemeral state for conditions (must, when), but not vice-versa. - We (i2rs) must decide what happens when ephemeral state has conditions that are invalidated by a change to the underlying config state. In such a case, the config state may validate, but i2rs may not. Does the operation succeed or fail? - Such constraints and their validation impact may negatively impact the desired speed properties of i2rs. However, it was also observed this is only the case when such references exist and that "fast" i2rs operations could simply be modeled with no dependencies on config state. - Ephemeral state priority vs. Local Config priority is difficult to fully support in such a model. In the above discussion, ephemeral state always has priority over Local Config. - Providing for Local Config to have lower priority may be possible, but introduces some unusual semantics. - Does I2RS have clear use cases for Local Config winning? The example of "configuration of last resort" was offered but is potentially a weak case. In summary, the fourth option was strongly driven by the arguments of "what keeps things simple". The original three options were apparently not simple enough and there's some doubt about the impacts of the fourth. Possible yang 1.1 implications: If the above model works, the discussed configuration semantic may be the previously discussed "config (false|true|ephemeral);" ------ Mutual authentication was also discussed. As noted on list conversation after draft-haas-* was published, while restconf doesn't currently require it, it is suspected that it will have such a requirement before working through IESG. I suggest that I2RS requirements are addressed for this point. ----- Identity requirements for the primary identity are covered by authentication requirements for the existing protocols. The "secondary identity" requirement is a netconf issues and we should talk to them about the implications. Since the primary requirement for this feature is for auditing, this may simply be meta-data that is kept on configuration state. (See commentary above.) It is noted, however, that introducing something like a secondary identity would require changes to SSH and/or TLS and may be somewhat difficult to make the case to the owning working groups. Per-client priority effectively becomes the ability to say "you can't write to this if the state exists and has an owner with a higher priority". Further discussion on this point is needed in light of the fourth option we were presented. ------ Persistance of subscriptions. Effectively we were told "go talk to netconf, it's out of scope for yang 1.1". Some discussion was given to the filtering considerations. Extending the filtering options of the ietf-inet-types module may be appropriate. [Juergen, is this an action item for yang 1.1?] ----- Hopefully this is clear enough to kick off discussion. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Sep 23 17:59: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 EA6BD1A8994; Tue, 23 Sep 2014 17:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l-ZuNTJZGrM; Tue, 23 Sep 2014 17:59:40 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 736F81A8996; Tue, 23 Sep 2014 17:59:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Andy Bierman'" , "'Jeffrey Haas'" References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> In-Reply-To: Date: Tue, 23 Sep 2014 20:59:36 -0400 Message-ID: <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025C_01CFD771.48B19E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQnwIbKt3gAQ37k3kBfPWaBwKMmSaPAmFsweWcdrMZQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/J3cIIPAn1aykYTqhNKb5cv1gGHA Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Wed, 24 Sep 2014 00:59:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025C_01CFD771.48B19E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: The concept on priority and FCFS is "if a remote client talks to an agent at a priority - then it should not be knocked out by another remote client coming later at the same priority". In my mind this is different that the boot/reboot configuration case. Do you think I am correct? Sue From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Monday, September 22, 2014 5:10 PM To: Jeffrey Haas Cc: Susan Hares; i2rs@ietf.org; netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_025C_01CFD771.48B19E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

The concept on priority and FCFS is “if a remote client talks = to an agent at a priority – then it should not be knocked out by = another remote client coming later at the same priority”.  In = my mind this is different that the boot/reboot configuration case.  =  Do you think I am correct?

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, = September 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: = Susan Hares; i2rs@ietf.org; netmod@ietf.org
Subject: Re: = [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and = i2rs requirements)

 

 

 

On Mon, = Sep 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:

Sue,

On Thu, Sep 18, 2014 at = 12:58:51PM -0400, Susan Hares wrote:
> Where does the priority = live ??? in I2RS or in config module or in BGP
> routing = model?  How does this work with the three datastore proposals: = 1)
> separate empheral data store, 2) configuration state in = existing datastore
> tagged by model as empheral, and 3) whole = data stores tagged empheral,
> config, or both.   Is the = routing code that sets the priority and handles
> the = rollback?

Priority received quite a bit of discussion during the = netmod interim.  The
reason why it was not explicitly spelled = out in my first version of the
draft is that the implementation would = vary considerably depending on which
answer netmod guided us toward = for how we get ephemeral state.

 

The rationale for the priority-based "first one = wins" access control model is still = unclear

to = me.

 

A = simple NACM extension to add group priority has already been = proposed,

which seems fine = to me. So is this how it works?

 

  #1) NACM data rules can be used to grant or = deny access to specific I2RS data nodes.

        Steps #2 and #3 assume = access is granted here

 

  #2) the I2RS agent maintains the owner and = owner priority of the data somehow.

         The priority is = configured in each NACM group for enforcement purposes. =  

    =      This data used to decide if existing data can be = overwritten by a different client.

         (I think highest = priority wins if target data already exists)

 

  #3) if both writer and current owner have the = same priority, then current owner wins

 

Breaking ties by first-one-wins seems just as = arbitrary as last-one-wins.  It seems to be based = on

the order that the = networking devices will boot.  Can somebody explain why it is = better?

 

I = am still unclear how the operator know the exact data each = client

will want to use, = and how they determine the meaningful = overlap

(e.g. what will = break for client B if client A causes 2 of its 7 entries to be = deleted?)

 

This information seems to be required in order to = configure the tie-breaking priorities = properly,

but I think the = intent is that the operator will just know what I2RS clients are = installed

and know how to = prioritize them, just based on their = purpose.

 

 

 

It turned out they gave us a fourth = option.  I'll be summarizing that in my
meeting minutes.  = If you don't believe I've adequately addressed it in that
writeup = (coming shortly), please let me know and we'll resume.

-- = Jeff

 

 

Andy

 

_______________________________________________
netm= od mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

------=_NextPart_000_025C_01CFD771.48B19E70-- From nobody Tue Sep 23 18:24: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 4FC151A89AD for ; Tue, 23 Sep 2014 18:24:37 -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=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 WhJeWiBljAAa for ; Tue, 23 Sep 2014 18:24:34 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1FF1A89AA for ; Tue, 23 Sep 2014 18:24:34 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id q108so5276525qgd.18 for ; Tue, 23 Sep 2014 18:24:33 -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=8cdFOlMGMuN31dtsshrRsa0gF3Urae8kBMp9TRG1WXs=; b=Q917hCShd5p1IqmzeVu+Al+zPRewnVXmy/FZk6/uX6vPQL4h0nmgQR5morLzEYSV/D 4AZ1oG2bY3C+mcfF+ybaGjFqzFhbY8xhpmcfmqt2iu2XfMNNaUSYJeEGo9xN1desTk5y JHnkt6YVIGKWkXpWBiNeUtmsPJIDl5pR6juC1dpZ5pt1Fycp4imiSi+247C4fYrt7F1Y rXu8z+nSM+pXh8yQA8UdnjvCj7Dn5VfZyrAE7jKN21IICKwJLFOHl3zfEqAi3A5UbfJ+ qfXRwGAalAFu8ufigqZxE53AiGJgnhxeZCVw+jkvXPxmoEdlzd4RgUaHyhtQlTCvTM6w dAcg== X-Gm-Message-State: ALoCoQmwVfZUO6MGnVCf8Es2y4gb+X5HmHrZ+9gpQQYPz6LNPlDfAn20QDXD7Qo1K6Zdc6qpMVxV MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr4954293qab.7.1411521873655; Tue, 23 Sep 2014 18:24:33 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 23 Sep 2014 18:24:33 -0700 (PDT) In-Reply-To: <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> Date: Tue, 23 Sep 2014 18:24:33 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c1c560df75790503c58b49 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Iu3eNqK-OED-IkTA66KTAY6fTvo Cc: Jeffrey Haas , "i2rs@ietf.org" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Wed, 24 Sep 2014 01:24:37 -0000 --001a11c1c560df75790503c58b49 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares wrote: > Andy: > > > > The concept on priority and FCFS is "if a remote client talks to an agent > at a priority - then it should not be knocked out by another remote client > coming later at the same priority". In my mind this is different that the > boot/reboot configuration case. Do you think I am correct? > > > Sure. I guess I am assuming each I2RS client has some reconnect-and-reload strategy. Normally, the clients will get notified when some data gets bumped or the agent restarts. Then there may be a race between the 2+ clients with same priority. IMO ties are really errors, and the operator is going to need to assign different priorities or set some config so all the clients run without data collisions. Sue > > > Andy > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, September 22, 2014 5:10 PM > *To:* Jeffrey Haas > *Cc:* Susan Hares; i2rs@ietf.org; netmod@ietf.org > *Subject:* Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was > netmod interim and i2rs requirements) > > > > > > > > On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: > > Sue, > > On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > > Where does the priority live ??? in I2RS or in config module or in BGP > > routing model? How does this work with the three datastore proposals: 1) > > separate empheral data store, 2) configuration state in existing > datastore > > tagged by model as empheral, and 3) whole data stores tagged empheral, > > config, or both. Is the routing code that sets the priority and handles > > the rollback? > > Priority received quite a bit of discussion during the netmod interim. The > reason why it was not explicitly spelled out in my first version of the > draft is that the implementation would vary considerably depending on which > answer netmod guided us toward for how we get ephemeral state. > > > > The rationale for the priority-based "first one wins" access control model > is still unclear > > to me. > > > > A simple NACM extension to add group priority has already been proposed, > > which seems fine to me. So is this how it works? > > > > #1) NACM data rules can be used to grant or deny access to specific I2RS > data nodes. > > Steps #2 and #3 assume access is granted here > > > > #2) the I2RS agent maintains the owner and owner priority of the data > somehow. > > The priority is configured in each NACM group for enforcement > purposes. > > This data used to decide if existing data can be overwritten by a > different client. > > (I think highest priority wins if target data already exists) > > > > #3) if both writer and current owner have the same priority, then > current owner wins > > > > Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. > It seems to be based on > > the order that the networking devices will boot. Can somebody explain why > it is better? > > > > I am still unclear how the operator know the exact data each client > > will want to use, and how they determine the meaningful overlap > > (e.g. what will break for client B if client A causes 2 of its 7 entries > to be deleted?) > > > > This information seems to be required in order to configure the > tie-breaking priorities properly, > > but I think the intent is that the operator will just know what I2RS > clients are installed > > and know how to prioritize them, just based on their purpose. > > > > > > > > It turned out they gave us a fourth option. I'll be summarizing that in my > meeting minutes. If you don't believe I've adequately addressed it in that > writeup (coming shortly), please let me know and we'll resume. > > -- Jeff > > > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a11c1c560df75790503c58b49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares <shares@ndzh.com> wrote:

 

The concept on priority and FCFS is “if a remote clie= nt talks to an agent at a priority – then it should not be knocked ou= t by another remote client coming later at the same priority”.  = In my mind this is different that the boot/reboot configuration case. =  Do you think I am correct?

 


Sure.

I guess I am ass= uming each I2RS client has some reconnect-and-reload strategy.
No= rmally, the clients will get notified when some data gets bumped or the age= nt restarts.
Then there may be a race between the 2+ clients with= same priority.

IMO ties are really errors, and th= e operator is going to need to assign different priorities
or set= some config so all the clients run without data collisions.

=

Sue

 


A= ndy
 

From:<= /span> Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, S= eptember 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: Susan Ha= res; i2rs@ietf.org; = netmod@ietf.orgSubject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was n= etmod interim and i2rs requirements)

 

 <= u>

 

On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= /u>

Sue,
On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
> W= here does the priority live ??? in I2RS or in config module or in BGP
&g= t; routing model?  How does this work with the three datastore proposa= ls: 1)
> separate empheral data store, 2) configuration state in exis= ting datastore
> tagged by model as empheral, and 3) whole data store= s tagged empheral,
> config, or both.   Is the routing code= that sets the priority and handles
> the rollback?

Priority r= eceived quite a bit of discussion during the netmod interim.  The
r= eason why it was not explicitly spelled out in my first version of the
d= raft is that the implementation would vary considerably depending on which<= br>answer netmod guided us toward for how we get ephemeral state.=

 

The rationale for the priority-based "first one win= s" access control model is still unclear

<= p class=3D"MsoNormal">to me.

 

A simple NAC= M extension to add group priority has already been proposed,<= /p>

which seems fine to me. So is this how= it works?

 =

  #1) NACM data rules can= be used to grant or deny access to specific I2RS data nodes.=

        Steps #2 = and #3 assume access is granted here

 

&n= bsp; #2) the I2RS agent maintains the owner and owner priority of the data = somehow.

    &= nbsp;    The priority is configured in each NACM group for enforc= ement purposes.  

&= nbsp;        This data used to decide if existing data = can be overwritten by a different client.

         (I think highest priori= ty wins if target data already exists)

 

&n= bsp; #3) if both writer and current owner have the same priority, then curr= ent owner wins

&n= bsp;

Breaking ties by first-one= -wins seems just as arbitrary as last-one-wins.  It seems to be based = on

the order that the ne= tworking devices will boot.  Can somebody explain why it is better?=

 

I am still unclear how the operator know th= e exact data each client

will want to use, and how they determine the meaningful overlap<= /u>

(e.g. what will break for client B= if client A causes 2 of its 7 entries to be deleted?)

 

This information seems to be required in order to configure = the tie-breaking priorities properly,

but I think the intent is that the operator will just know w= hat I2RS clients are installed

and know how to prioritize them, just based on their purpose.=

 

=

 

 

It = turned out they gave us a fourth option.  I'll be summarizing that= in my
meeting minutes.  If you don't believe I've adequate= ly addressed it in that
writeup (coming shortly), please let me know and= we'll resume.

-- Jeff

 

=  

Andy

 

______= _________________________________________
netmod mailing list
netmod@ietf.org
https:= //www.ietf.org/mailman/listinfo/netmod

 

=

--001a11c1c560df75790503c58b49-- From nobody Wed Sep 24 00:00: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 083B31A70FD; Wed, 24 Sep 2014 00:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.786] 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 4j0CcJEE1XtZ; Wed, 24 Sep 2014 00:00:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F4E1A7D80; Wed, 24 Sep 2014 00:00:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 490648EC; Wed, 24 Sep 2014 09:00:30 +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 mVRktvTn_6oH; Wed, 24 Sep 2014 09:00:26 +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, 24 Sep 2014 09:00:28 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98EB520036; Wed, 24 Sep 2014 09:00:28 +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 whYcsPoUodHW; Wed, 24 Sep 2014 09:00:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FBC320035; Wed, 24 Sep 2014 09:00:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0F7382E87AEF; Wed, 24 Sep 2014 09:00:26 +0200 (CEST) Date: Wed, 24 Sep 2014 09:00:26 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140924070025.GD23280@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140922210546.GA5676@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/SOhm4AbX5OBotOZ3juqXMg0qy54 Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 07:00:35 -0000 On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > - This "shadowing" behavior avoids issues in the existing yang by not > requiring additional language semantics that would require mechanisms to > cross-reference between datastores. (One might observe this is somewhat > similar to Object Oriented programming where the configuration state > serves as a "base class" with ephemeral configuration extending that > base. A different analogy is the union filesystem semantic.) I believe the OO analogy is largely mis-leading, I think the union filesystem semantics are much closer. > Possible yang 1.1 implications: If the above model works, the discussed > configuration semantic may be the previously discussed > "config (false|true|ephemeral);" My understanding that both the config datastore and any ephemeral datastores largely use the same data model (or schema). So config true|false remains unchanged - the difference is the datastore you write to. > It is noted, however, that introducing something like a secondary identity > would require changes to SSH and/or TLS and may be somewhat difficult to > make the case to the owning working groups. I do not follow here. The secure transport delivers what NETCONF calls a username, the identity of the NETCONF client. If this client acts on behalf of another application (the secondary identity), then this identity is meta data should be attached to the information submitted to the ephemeral datastore. I do not see why this would lead to any changes to SSH or TLS. > Some discussion was given to the filtering considerations. Extending the > filtering options of the ietf-inet-types module may be appropriate. > [Juergen, is this an action item for yang 1.1?] The YANG 1.1 issue Y20 is about adding a set of built-in xpath functions. I like to ask I2RS to tell us what functions they need. We do have IP prefix-length matching on our radar. If other functions are required, please let us know as soon as possible. Now, this mostly is about the xpath function set that can be used in must and when expressions. You probably want to use them also in filtering expressions in the protocol. This is where things again become a protocol issues. Note that RFC 6241 says on page 17: The XPath expression is interpreted in the following context: [...] * The function library is the core function library. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 00:10: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 760A91A88E1; Wed, 24 Sep 2014 00:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqSOOsAXMtQQ; Wed, 24 Sep 2014 00:10:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC641A883F; Wed, 24 Sep 2014 00:10:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2C9A119E; Wed, 24 Sep 2014 09:10:27 +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 mW2L-EoZmbkb; Wed, 24 Sep 2014 09:10:25 +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, 24 Sep 2014 09:10:27 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F49620035; Wed, 24 Sep 2014 09:10:27 +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 1ODQjyjL0k1P; Wed, 24 Sep 2014 09:10:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAD8F20036; Wed, 24 Sep 2014 09:10:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43E642E87BAB; Wed, 24 Sep 2014 09:10:24 +0200 (CEST) Date: Wed, 24 Sep 2014 09:10:24 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140924071023.GF23280@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Uz4zuwwQK-maKBoPMSGojK81AgA Cc: 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 07:10:30 -0000 On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > Jeff: > > The fourth option is interesting and creative. A few questions/requests: 1) > How would the fourth model be expressed in the yang model - config > (empheral)? The beauty of the fourth option is that it does not require a large set of new data models. The idea is that you have a standard config data model and you use the same model for an ephemeral datastore. The server will then take the contents of the config datastore and 'merge' it with the content of any ephemeral datastores to produce what the box ends up doing (the operational state). The merging function will take priorities into account should conflicts arise. Here is the relevant figure (taken from the meeting minutes): +-----------------+ | | +--- (+) ---+ | ^ ^ v +---+ +---+ +---+ | | | | | | |(1)| | | | | | | | | | | +---+ +---+ +---+ NC config ephemeral operational datastore datastore state (1) The complete NC config datastore is at certain synchronization points made persistent (+) Priority resolution, priorities may be per datastore or per user or per 'application' or even per data node /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 00:27:04 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 09F7D1A70FD; Wed, 24 Sep 2014 00:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbrULYEIB4gc; Wed, 24 Sep 2014 00:27:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id CFB7B1A1BA7; Wed, 24 Sep 2014 00:27:00 -0700 (PDT) Received: from localhost (host-83-131-122-43.h4.t-ht.net [83.131.122.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 596191280457; Wed, 24 Sep 2014 09:26:59 +0200 (CEST) Date: Wed, 24 Sep 2014 09:26:58 +0200 (CEST) Message-Id: <20140924.092658.622309529428712352.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140924070025.GD23280@elstar.local> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qtBzzStbs9sZVR708mDlvwTRiX4 Cc: jhaas@pfrc.org, i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 07:27:02 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > Some discussion was given to the filtering considerations. Extending the > > filtering options of the ietf-inet-types module may be appropriate. > > [Juergen, is this an action item for yang 1.1?] > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. > > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: > > The XPath expression is interpreted in the following context: > > [...] > > * The function library is the core function library. The quoted text is for the error-path. For the filter, rfc 6241 says (p 67): o The function library is the core function library, plus any functions defined by the data model. /martin From nobody Wed Sep 24 00:32: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 20FEF1A8F3D; Wed, 24 Sep 2014 00:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYC-skantalX; Wed, 24 Sep 2014 00:32:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1751B1A8F3C; Wed, 24 Sep 2014 00:32:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DCBAF1169; Wed, 24 Sep 2014 09:32:29 +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 mYqlggRY3BYT; Wed, 24 Sep 2014 09:32:27 +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, 24 Sep 2014 09:32:29 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED81120036; Wed, 24 Sep 2014 09:32:28 +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 rymYJ39t4Y-7; Wed, 24 Sep 2014 09:32:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0C4020037; Wed, 24 Sep 2014 09:32:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D0BB42E87C83; Wed, 24 Sep 2014 09:32:27 +0200 (CEST) Date: Wed, 24 Sep 2014 09:32:27 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140924073227.GI23280@elstar.local> Mail-Followup-To: Martin Bjorklund , jhaas@pfrc.org, i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924.092658.622309529428712352.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924.092658.622309529428712352.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/fWCv7YOdibIqZCUOOewcPcSXqQU Cc: jhaas@pfrc.org, i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 07:32:33 -0000 On Wed, Sep 24, 2014 at 09:26:58AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > > > Now, this mostly is about the xpath function set that can be used in > > must and when expressions. You probably want to use them also in > > filtering expressions in the protocol. This is where things again > > become a protocol issues. Note that RFC 6241 says on page 17: > > > > The XPath expression is interpreted in the following context: > > > > [...] > > > > * The function library is the core function library. > > The quoted text is for the error-path. For the filter, rfc 6241 says > (p 67): > > o The function library is the core function library, plus any > functions defined by the data model. > Oops. So we are in a better shape than I thought. Good news I would say (although this binding of protocol and data model leads to interesting effects but I do not want to go down there). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 04:35: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 2D19C1A702C; Wed, 24 Sep 2014 04:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKQsHqpDaSXC; Wed, 24 Sep 2014 04:35:50 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADFC1A6FFA; Wed, 24 Sep 2014 04:35:49 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4D14A289E175; Wed, 24 Sep 2014 07:35:49 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140924071023.GF23280@elstar.local> Date: Wed, 24 Sep 2014 07:35:47 -0400 Message-Id: References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qx3Ps6nS2OHOfxZDWk78DgZdulI Cc: i2rs@ietf.org, netmod@ietf.org, Susan Hares Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 11:35:52 -0000 --Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder = wrote: > On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: >> Jeff: >>=20 >> The fourth option is interesting and creative. A few = questions/requests: 1) >> How would the fourth model be expressed in the yang model - config >> (empheral)?=20 >=20 > The beauty of the fourth option is that it does not require a large > set of new data models. The idea is that you have a standard config > data model and you use the same model for an ephemeral datastore. The > server will then take the contents of the config datastore and 'merge' > it with the content of any ephemeral datastores to produce what the > box ends up doing (the operational state). The merging function will > take priorities into account should conflicts arise. Here is the > relevant figure (taken from the meeting minutes): >=20 > +-----------------+ > | | > +--- (+) ---+ | > ^ ^ v > +---+ +---+ +---+ > | | | | | | > |(1)| | | | | > | | | | | | > +---+ +---+ +---+ >=20 > NC config ephemeral operational > datastore datastore state >=20 > (1) The complete NC config datastore is at certain synchronization > points made persistent >=20 > (+) Priority resolution, priorities may be per datastore or per > user or per 'application' or even per data node These are precisely the qualities I and some others were = thinking of when we started i2rs. The idea is quite simple, as you have = said above and really needs not be complicated more. =20 --Tom >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD 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 iQIcBAEBCgAGBQJUIqyTAAoJEPcO+I7eiUJZp7sP/A9DoeIfM8f8vrpONDu8toFd r0eYAoAHUxMxuGiWIMIbv45/aIajphsArcvNtEPjxyVzMDIu7CBrryioyO1gPv2r qoIjmAS/FFx2PKhUWeJ7l9ll3btLo9aUMIEBVNkyCIA5rktEu8Wo9nFWlrzlHOF4 dEkvv+OHPXImEfaJrKeyceqktU+5eKWTRpr63gt6FVkEHrAA9CCiL18n0JlmCNDi /vDIQPFX/Vts000ucyywxdG7E3XOYXq5nSWGcLwzboNH/7vmcXvkCDtaM9G29Y7I WYkgH0z93epGljAR/lIIm6LzQtHbe6FDcwHoKw88bJjQm493LRtYSXSzJFIzxH5F ZodzkW13r0lA259GdvvsBffmihcIGHvJUZw/RiGP6xl0GuUHqMMRhHYyq3LOxH9q DZWaL8QqIBorkDnebTWFWXMBXLTZKLpeEch/ByP+6f2FYVNjeZdtpflTt9V/p5CX grvKQAefxiSTwM0ezKPLaCnKusKI8BssI1T6PV9R9IKCwWwP9rMUeAbD05M66thP 4Vb6D/rASnc2rb9LO4h1sfd+vICa0yjSEAsoUluI/hA9n49uJmk5lVD9gOvKAseT msLliN/DMIMOUWxh6q9aKPJnO2AhhS3XW9nyTQ/TVQvpUpxMThFyUOnum9hXwebu /JlEN8031G4Vky14uTAu =qbhE -----END PGP SIGNATURE----- --Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD-- From nobody Wed Sep 24 04:50: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 985FD1A6FFA; Wed, 24 Sep 2014 04:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnWk-xxMUJ_U; Wed, 24 Sep 2014 04:50:45 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 789121A7023; Wed, 24 Sep 2014 04:50:42 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id F2E9A289E1D5; Wed, 24 Sep 2014 07:50:41 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140924070025.GD23280@elstar.local> Date: Wed, 24 Sep 2014 07:50:39 -0400 Message-Id: <51E02238-F84C-4102-B7D2-395EF67C2FE0@lucidvision.com> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/9lP-y9tGxUDQk7NVfxZMsXQoY9s Cc: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 11:50:46 -0000 --Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014:3:00 AM, at 3:00 AM, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: >=20 >> - This "shadowing" behavior avoids issues in the existing yang by not >> requiring additional language semantics that would require = mechanisms to >> cross-reference between datastores. (One might observe this is = somewhat >> similar to Object Oriented programming where the configuration state >> serves as a "base class" with ephemeral configuration extending that >> base. A different analogy is the union filesystem semantic.) >=20 > I believe the OO analogy is largely mis-leading, I think the union > filesystem semantics are much closer. Yes I agree. They are configuration objects. There might be two = copies of the same object across data stores not an inheritance = relationship: say one in the run-time/ephemeral, one in the persistent. > Possible yang 1.1 implications: If the above model works, the = discussed >> configuration semantic may be the previously discussed >> "config (false|true|ephemeral);" >=20 > My understanding that both the config datastore and any ephemeral > datastores largely use the same data model (or schema). So config > true|false remains unchanged - the difference is the datastore you > write to. They should use precisely the same data models with perhaps a = sub-set being actually implemented at any given time in the ephemeral = one given that some objects might not make sense in that context. In = the diagram you drew in the previous email I responded to, you showed = this analogy very well I think. --Tom > It is noted, however, that introducing something like a secondary = identity >> would require changes to SSH and/or TLS and may be somewhat difficult = to >> make the case to the owning working groups. >=20 > I do not follow here. The secure transport delivers what NETCONF calls > a username, the identity of the NETCONF client. If this client acts on > behalf of another application (the secondary identity), then this > identity is meta data should be attached to the information submitted > to the ephemeral datastore. I do not see why this would lead to any > changes to SSH or TLS. >=20 >> Some discussion was given to the filtering considerations. Extending = the >> filtering options of the ietf-inet-types module may be appropriate. >> [Juergen, is this an action item for yang 1.1?] >=20 > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. >=20 > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: >=20 > The XPath expression is interpreted in the following context: >=20 > [...] >=20 > * The function library is the core function library. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0 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 iQIcBAEBCgAGBQJUIrAPAAoJEPcO+I7eiUJZgbUQAKGs3R3HLL1nZwqtR/aDFK/M XDyQU61sjrw56fv+xo/SvQshEq84+t4X+qaPDXa3KZsD7yqEEfts2salmWNAbUMQ fcC2mvheqmT3yGigt1lAYjFqLzj3fOsLIrQNknX72i4EEOpvcKjtMZBXq8TUnOvS 0Ymu/Pn5+Uax8NwphSXkc9jcPzAFsqOPyk70YSrZKloiAeJ46rgJZrw4/exy3xwn KloLN5GBIX1NoNq8TI+6J0c8fwQXuxU3mpp3rpGqsEFGHZAn35lu8AOVrwpXvGsQ Qx/cCaO0G/YURgBqtsC+58WJBPeyftptUF+CtFJ+J6VjOTeb0o4c+UuPSsqgcdv3 9A9T27nLf6ofcF/4kSv5ccdWElRJ6+S2oB1t12phr+DnQATMX0ZQvwDxbmXCfCgy Lfe1Yg5VAL6yZ3gcBP4z5OVH9MKEqLnr9eFdV21WodZ8wASiIXjkkeIk1lQNOpFm 5pVCGf2wRZ+9IBR0tjgrlxsdzAg9rgLzyU7+K/VA0yCUHX3rkKpW+g0pFJE28+Ff 0DzoVG1ahe3/Wby7ddcCMDnAG/kHOWlj5krk5LI9pKQTfmFS8Tw8/mt/z6QPVCuZ Jn5F/SCSwWihHEShqOg6y3k7AXWkjnKTjU/WCRELb58Dk6FY1NXB5z56IjP2zv8V cBy4bM1HrKHK9E19P0B4 =rjZE -----END PGP SIGNATURE----- --Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0-- From nobody Wed Sep 24 08:30: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 1DDB31A014F for ; Wed, 24 Sep 2014 08:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2BxZ7E_mpeo for ; Wed, 24 Sep 2014 08:30:51 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C26801A00EA for ; Wed, 24 Sep 2014 08:30:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5223FC2BE; Wed, 24 Sep 2014 11:30:51 -0400 (EDT) Date: Wed, 24 Sep 2014 11:30:51 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140924153051.GB2639@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/wlx8u9K6vbP6HvIBPkvvKpu5vW8 Subject: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:30:53 -0000 In the proposed overlay model, presume that we have ephemeral data from a model that lives within an augmentation to a local config model. In other words, the ephemeral nodes are children of the local config nodes. Presume, per discussion, that the local config lives in the "config" data store and that the ephemeral config - the augmenting nodes above - live in the ephemeral data store. If we delete the container in the local config that the epehemeral config is augmenting, is there any expectation that such a deletion should carry through to the ephemeral config? Per the netmod interim discussion, probably not. It's in a separate datastore. But it does lead to integrity issues since we now have orphaned state. In this particular example, permitting the deletion to carry through to the ephemeral datastore at least provides one additional level of consistency. ----- My second thought is would we ever want to provide filtering in the conditional checks (must/when) in the ephemeral datastore based on the underlying source of the data? Since local config would be shadowed into the ephemeral datastore, do we want the ability to match on the source of the node set under evaluation? -- Jeff From nobody Wed Sep 24 08:34: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 77DA51A014F; Wed, 24 Sep 2014 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0-6pQjCAsGA; Wed, 24 Sep 2014 08:34:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 04BEB1A0142; Wed, 24 Sep 2014 08:34:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C40B2C2BE; Wed, 24 Sep 2014 11:34:01 -0400 (EDT) Date: Wed, 24 Sep 2014 11:34:01 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140924153401.GC2639@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/iL4XtSfJ2pUYjIu23noPzqNjchM Cc: i2rs@ietf.org, Juergen Schoenwaelder , Susan Hares , netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 15:34:03 -0000 On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: [...] > > > > +-----------------+ > > | | > > +--- (+) ---+ | > > ^ ^ v > > +---+ +---+ +---+ > > | | | | | | > > |(1)| | | | | > > | | | | | | > > +---+ +---+ +---+ > > > > NC config ephemeral operational > > datastore datastore state > > > > (1) The complete NC config datastore is at certain synchronization > > points made persistent > > > > (+) Priority resolution, priorities may be per datastore or per > > user or per 'application' or even per data node > > These are precisely the qualities I and some others were thinking of when we started i2rs. The idea is quite simple, as you have said above and really needs not be complicated more. It has its own complications. Do we permit more than one ephemeral datastore? If so, this simplifies data object priority when resolving the operational state. But this also complicates operational state integrity when you have multiple cross references. -- Jeff From nobody Wed Sep 24 08:38: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 44DA21A0143; Wed, 24 Sep 2014 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOIuBzqDiC7B; Wed, 24 Sep 2014 08:38:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 69D171A0142; Wed, 24 Sep 2014 08:38:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D42FC4A4; Wed, 24 Sep 2014 11:38:02 -0400 (EDT) Date: Wed, 24 Sep 2014 11:38:02 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Message-ID: <20140924153802.GD2639@pfrc> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924070025.GD23280@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/R_rfi5ud1XK_p78wGVHg7H6SMuE Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 15:38:03 -0000 On Wed, Sep 24, 2014 at 09:00:26AM +0200, Juergen Schoenwaelder wrote: > I believe the OO analogy is largely mis-leading, I think the union > filesystem semantics are much closer. Accepted. I'll stick to the union filesystem example alone for the future. > > Possible yang 1.1 implications: If the above model works, the discussed > > configuration semantic may be the previously discussed > > "config (false|true|ephemeral);" > > My understanding that both the config datastore and any ephemeral > datastores largely use the same data model (or schema). So config > true|false remains unchanged - the difference is the datastore you > write to. I had forgotten this detail. > > It is noted, however, that introducing something like a secondary identity > > would require changes to SSH and/or TLS and may be somewhat difficult to > > make the case to the owning working groups. > > I do not follow here. The secure transport delivers what NETCONF calls > a username, the identity of the NETCONF client. If this client acts on > behalf of another application (the secondary identity), then this > identity is meta data should be attached to the information submitted > to the ephemeral datastore. I do not see why this would lead to any > changes to SSH or TLS. I tried to raise this as a question during the interim, but I think it was lost. How should the meta-data be transported? > > Some discussion was given to the filtering considerations. Extending the > > filtering options of the ietf-inet-types module may be appropriate. > > [Juergen, is this an action item for yang 1.1?] > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. The primary ones I am aware of are operations on network addresses and prefixes. Was netmod looking for an explicit manifest of such operations? This may have overlap in the work for the ACL module that is already a netmod document. > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: > > The XPath expression is interpreted in the following context: > > [...] > > * The function library is the core function library. We'll raise this point separately to netconf. -- Jeff From nobody Wed Sep 24 08:43: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 5702D1A015F; Wed, 24 Sep 2014 08:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJaU1uTsO5yw; Wed, 24 Sep 2014 08:43:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 018491A014F; Wed, 24 Sep 2014 08:43:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C4FACC2BE; Wed, 24 Sep 2014 11:43:52 -0400 (EDT) Date: Wed, 24 Sep 2014 11:43:52 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140924154352.GE2639@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/tGrn8UO2sr1eIg_ExmufNN4q3Bw Cc: 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 15:43:54 -0000 Sue, On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > The fourth option is interesting and creative. A few questions/requests: 1) > How would the fourth model be expressed in the yang model - config > (empheral)? I believe Juergen has answered this point. > 2) Please define your definition of local config with an > example., This corresponds to "config true" state, probably in the running datastore. The semantics on the impact for the commit model when writable-running is not in use haven't been fully explored. > and 3) please give an example of the (must, when) use cases > envisioned? In the original proposal in my draft, when we had completely disjoint datastores, consider the BGP I2RS ephemeral peer case. The I2RS model would have a container of ephemeral peers. That container might not specify the local Autonomous System number. In that case, there would be a MUST requirement for that neighbor that there exist a system-wide configured Autonomous System number, probably in the local Config. Currently, there is no syntax that says how to examine nodes that are in a different datastore. From an XPath context, the current datastore is the document context. In the new proposal, since the ephemeral datastore gets a shadow of the local config, there is no need to have extensions to XPath to refer between data stores. However, if we end up with more than one ephemeral datastore (not recommended for this reason), such an issue returns. -- Jeff From nobody Wed Sep 24 08:47:25 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 E6A8F1A0115 for ; Wed, 24 Sep 2014 08:47:21 -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 TEm4zbXE8St3 for ; Wed, 24 Sep 2014 08:47:19 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2031A004D for ; Wed, 24 Sep 2014 08:47:19 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so3314478qae.6 for ; Wed, 24 Sep 2014 08:47:18 -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=Hl2BSFqBeu5YroftPn7OYZaTHVaZ4AjhQRKwcX/Pv28=; b=Lh1KzlAPsuk5xeM/y61p7fhetBfroMI2uI3tQ/NyiLvVy5vQdOwqhRckcuJ3WUAZNb ZMoBnVVDHM6Hv4h4UWOsnjgiJutAnJx2F4N5o+znh7FNQVIUe0iTiCPJIaskIOn3pIKL pR84X4aeIVu4KaGBO2MUUnu2bBWBxDuORgY4wzvSOyMZoybf54Y9US6nPkS/wmj9OZxe K1MZP3yrfqqO95M8By/AH3YLK6W1Jf9cm3OXsOhMnJNXp/PhYR3Y3UwDCcatvf7yStpt owv8TtrLaPfNGNBc9lunxOK2J3z5txGGqF9DlxF2DXqMuJVtT8JGtcIR7ecjoDmRtg3v 3bqQ== X-Gm-Message-State: ALoCoQkGUVbg6+4LQSYR2Z137TyqkLvPeWN5kEA3h34c6kKa2k47Ax9QgxXUbq2uMEXR4yaWwU+8 MIME-Version: 1.0 X-Received: by 10.140.22.239 with SMTP id 102mr10646440qgn.21.1411573638464; Wed, 24 Sep 2014 08:47:18 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 24 Sep 2014 08:47:18 -0700 (PDT) In-Reply-To: <20140924153051.GB2639@pfrc> References: <20140924153051.GB2639@pfrc> Date: Wed, 24 Sep 2014 08:47:18 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c13e2e4bb8e30503d199e1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/AjcNdkVLuqU5rgrSpN3SO4yz7aM Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:47:22 -0000 --001a11c13e2e4bb8e30503d199e1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas wrote: > In the proposed overlay model, presume that we have ephemeral data from a > model that lives within an augmentation to a local config model. In other > words, the ephemeral nodes are children of the local config nodes. > > Presume, per discussion, that the local config lives in the "config" data > store and that the ephemeral config - the augmenting nodes above - live in > the ephemeral data store. > > If we delete the container in the local config that the epehemeral config > is > augmenting, is there any expectation that such a deletion should carry > through to the ephemeral config? > > Per the netmod interim discussion, probably not. It's in a separate > datastore. But it does lead to integrity issues since we now have orphaned > state. In this particular example, permitting the deletion to carry > through > to the ephemeral datastore at least provides one additional level of > consistency. > > I think the concept of "shadowing the local config" makes this behavior confusing. If the ephemeral datastore instances remains after the config datastore instances are deleted, how is that really shadowing? IMO, shadowing only occurs when the ephemeral datastore is edited. It is used as a snapshot to reduce the I2RS payload size (shadow patch?. But the data that gets created in the ephemeral datastore is complete and self-contained. The actual data structures are implementation details. Maybe the local config is cloned, maybe it is shadowed. ----- > > My second thought is would we ever want to provide filtering in the > conditional checks (must/when) in the ephemeral datastore based on the > underlying source of the data? Since local config would be shadowed into > the ephemeral datastore, do we want the ability to match on the source of > the node set under evaluation? > Each datastore should only validated against itself, or else the XPath implementation would be even more complicated. If the ephemeral datastore is supposed to be fast (I remember 5000 updates a second from the BoF) then running validation tests across multiple datastores constantly will not help. Or do you mean flag a must/when as "do-not-use" in the ephemeral datastore? If that were possible it would help speed up the server. > -- Jeff > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c13e2e4bb8e30503d199e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
In the proposed overlay model,= presume that we have ephemeral data from a
model that lives within an augmentation to a local config model.=A0 In othe= r
words, the ephemeral nodes are children of the local config nodes.

Presume, per discussion, that the local config lives in the "config&qu= ot; data
store and that the ephemeral config - the augmenting nodes above - live in<= br> the ephemeral data store.

If we delete the container in the local config that the epehemeral config i= s
augmenting, is there any expectation that such a deletion should carry
through to the ephemeral config?

Per the netmod interim discussion, probably not.=A0 It's in a separate<= br> datastore.=A0 But it does lead to integrity issues since we now have orphan= ed
state.=A0 In this particular example, permitting the deletion to carry thro= ugh
to the ephemeral datastore at least provides one additional level of
consistency.


I think the concept of "shadowing= the local config" makes this behavior confusing.
If the eph= emeral datastore instances remains after the config datastore
ins= tances are deleted, how is that really shadowing?

<= div>IMO, shadowing only occurs when the ephemeral datastore is edited.
It is used as a snapshot to reduce the I2RS payload size (shadow patc= h?.
But the data that gets created in the ephemeral datastore is = complete and
self-contained.=A0 The actual data structures are im= plementation details.
Maybe the local config is cloned, maybe it = is shadowed.

-----

My second thought is would we ever want to provide filtering in the
conditional checks (must/when) in the ephemeral datastore based on the
underlying source of the data?=A0 Since local config would be shadowed into=
the ephemeral datastore, do we want the ability to match on the source of the node set under evaluation?

Each dat= astore should only validated against itself, or else the
XPath im= plementation would be even more complicated.=A0 If the ephemeral datastore<= /div>
is supposed to be fast (I remember 5000 updates a second from the= BoF)
then running validation tests across multiple datastores co= nstantly will not help.

Or do you mean flag a must= /when as "do-not-use" in the ephemeral datastore?
If th= at were possible it would help speed up the server.



-- Jeff


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

--001a11c13e2e4bb8e30503d199e1-- From nobody Wed Sep 24 08:53: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 B08E01A0149 for ; Wed, 24 Sep 2014 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT5ZU1SrGY_Z for ; Wed, 24 Sep 2014 08:53:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 761871A00C3 for ; Wed, 24 Sep 2014 08:53:32 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 381ADC2BE; Wed, 24 Sep 2014 11:53:32 -0400 (EDT) Date: Wed, 24 Sep 2014 11:53:32 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140924155332.GF2639@pfrc> References: <20140924153051.GB2639@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/V4ulT86SGzpuWVVouEIR1R5boN8 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:53:33 -0000 Andy, On Wed, Sep 24, 2014 at 08:47:18AM -0700, Andy Bierman wrote: > I think the concept of "shadowing the local config" makes this behavior > confusing. > If the ephemeral datastore instances remains after the config datastore > instances are deleted, how is that really shadowing? > > IMO, shadowing only occurs when the ephemeral datastore is edited. > It is used as a snapshot to reduce the I2RS payload size (shadow patch?. > But the data that gets created in the ephemeral datastore is complete and > self-contained. The actual data structures are implementation details. > Maybe the local config is cloned, maybe it is shadowed. I agree that this begs the semantics a bit. Is it a shadow or a snapshot? Each one has impact. In the snapshot case, if you delete stuff from the local config, do we effectively "reapply the ephemeral patch" on top of it? Does the ephemeral datastore get notified that the local config has changed and is permitted to let that operation fail? Part of the motivation will come from where your box gets its state from. If it's from reading the ephemeral config, then local config semantics with regard to snapshot vs. shadow become very important. > > ----- > > > > My second thought is would we ever want to provide filtering in the > > conditional checks (must/when) in the ephemeral datastore based on the > > underlying source of the data? Since local config would be shadowed into > > the ephemeral datastore, do we want the ability to match on the source of > > the node set under evaluation? > > > > Each datastore should only validated against itself, or else the > XPath implementation would be even more complicated. If the ephemeral > datastore > is supposed to be fast (I remember 5000 updates a second from the BoF) > then running validation tests across multiple datastores constantly will > not help. > > Or do you mean flag a must/when as "do-not-use" in the ephemeral datastore? > If that were possible it would help speed up the server. I'm thinking of it as a form of meta-data, just like creator (user) would be. Thus, "datastore='ephemeral'" or "datastore='config'" type semantics. I'm not currently arguing that this has a use case yet. -- Jeff From nobody Wed Sep 24 09:54: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 05A171A01DC; Wed, 24 Sep 2014 09:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTiMvV1kMq1V; Wed, 24 Sep 2014 09:54:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9061B1A0179; Wed, 24 Sep 2014 09:54:43 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A4747289EA87; Wed, 24 Sep 2014 12:54:42 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140924153401.GC2639@pfrc> Date: Wed, 24 Sep 2014 12:54:39 -0400 Message-Id: <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/8fYiAEf8DN6CGcHLQE2-MLOkmMw Cc: i2rs@ietf.org, Juergen Schoenwaelder , Susan Hares , netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 16:54:45 -0000 --Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas = wrote: > On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder = wrote: > [...] >>>=20 >>> +-----------------+ >>> | | >>> +--- (+) ---+ | >>> ^ ^ v >>> +---+ +---+ +---+ >>> | | | | | | >>> |(1)| | | | | >>> | | | | | | >>> +---+ +---+ +---+ >>>=20 >>> NC config ephemeral operational >>> datastore datastore state >>>=20 >>> (1) The complete NC config datastore is at certain synchronization >>> points made persistent >>>=20 >>> (+) Priority resolution, priorities may be per datastore or per >>> user or per 'application' or even per data node >>=20 >> These are precisely the qualities I and some others were = thinking of when we started i2rs. The idea is quite simple, as you have = said above and really needs not be complicated more. =20 >=20 > It has its own complications. >=20 > Do we permit more than one ephemeral datastore? If so, this = simplifies data > object priority when resolving the operational state. But this also > complicates operational state integrity when you have multiple cross I vote for keeping this simple for starters. Lets get an = implementation or two of a single ephemeral data store. This avoids = having multiple priorities too; its just 1. --Tom > references. >=20 > -- Jeff >=20 --Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE 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 iQIcBAEBCgAGBQJUIvdPAAoJEPcO+I7eiUJZzpwP/2h/o4bwDX9nkT0KP1pW1Tu0 J9ch7P9Yw9BcUKspOOeY8CrzYp6V+0XI6wGsMFmQjIASPYQ73u/4jHSKc4JsGUaP 9aowUc7bGqQQUYIp1nRQsKXoJjIMVbC5b0xzCR2q+8n8Et+PjlEtoGhzYAY99oim 789aG8U+jJ1BvshY+KEhBGxHlIm8UqIkzDsKTlAU9BW0O1r2aqmfMUliEHU9T/4g 9deyYbH47GN7bWwHcJBvI4AVmdLN2sauOCEKBlxGoGEK7EhkBaHuoDzkG6mF6lLd xpjDJ5RckEd8Yzs6qW1pK3NupYT6zD7aQm5HtoZqYkH9EBVE100R5am+iBnCpcAL XPmOev6yNAPs1wFH7VxhCk3sSbhsmcw732uaKTAufJLdLZ+CXyVRVwKtlHvBcqon /8aFuKwMQdIvl4UnVFSO1EHT4zmPWwj8+Lgqhjc1zLY8IsRVWM9pPJSEU7YIzheq 3mvPmCTCBZnwkfWboCjpn+X8Ept8F6TO35ouxh1ckcTbXHoxVBKUtT3C2GyfUqfv 97cNPyFTRXMt4zfziGUqXYAekZ7nTlNCbqCRuxY+b76O2Jh5o5LCBtUCKHgO6BHt QZn0NFy/YibDq6fUjdNoaAlY0reWjrsPoiCYfcD7yCzjUt3WHUpdsYB7GdA/BP+w phgGObYIE6RPtq01qHv3 =doPl -----END PGP SIGNATURE----- --Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE-- From nobody Wed Sep 24 14:01: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 A88401A0687; Wed, 24 Sep 2014 14:01:05 -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 aufXpMzTyBMX; Wed, 24 Sep 2014 14:00:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999691A02F6; Wed, 24 Sep 2014 14:00:56 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 24 Sep 2014 21:00:54 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) with mapi id 15.00.1039.011; Wed, 24 Sep 2014 21:00:54 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP1qkCvY2EU2y81E2yFJqHoPh2n5wPShsAgACVywCAAEolgIAAQpCAgAAWiICAAETKAA== Date: Wed, 24 Sep 2014 21:00:54 +0000 Message-ID: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> In-Reply-To: <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(377454003)(97736003)(90102001)(106356001)(107046002)(79102003)(74502003)(74662003)(77982003)(46102003)(81342003)(80022003)(95666004)(36756003)(77096002)(77156001)(110136001)(4396001)(99286002)(87286001)(105586002)(62966002)(106116001)(66066001)(85306004)(20776003)(83716003)(93886004)(87936001)(2656002)(104166001)(88136002)(83072002)(85852003)(89996001)(82746002)(33656002)(15975445006)(19580405001)(83322001)(57306001)(31966008)(50986999)(64706001)(81542003)(50226001)(19580395003)(101416001)(76176999)(92566001)(76482002)(92726001)(93916002)(120916001)(21056001)(10300001)(86362001)(99396003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <3EE5853D4D41F947AD559667123BA529@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/9D1hdFxm0FKN1bzEXZjIlYoloS4 Cc: Jeffrey Haas , "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 21:01:05 -0000 On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau wr= ote: >=20 > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas wrot= e: >=20 >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: >> [...] >>>>=20 >>>> +-----------------+ >>>> | | >>>> +--- (+) ---+ | >>>> ^ ^ v >>>> +---+ +---+ +---+ >>>> | | | | | | >>>> |(1)| | | | | >>>> | | | | | | >>>> +---+ +---+ +---+ >>>>=20 >>>> NC config ephemeral operational >>>> datastore datastore state >>>>=20 >>>> (1) The complete NC config datastore is at certain synchronization >>>> points made persistent >>>>=20 >>>> (+) Priority resolution, priorities may be per datastore or per >>>> user or per 'application' or even per data node >>>=20 >>> These are precisely the qualities I and some others were thinking of w= hen we started i2rs. The idea is quite simple, as you have said above and r= eally needs not be complicated more. =20 >>=20 >> It has its own complications. >>=20 >> Do we permit more than one ephemeral datastore? If so, this simplifies = data >> object priority when resolving the operational state. But this also >> complicates operational state integrity when you have multiple cross >=20 > I vote for keeping this simple for starters. Lets get an implementation = or two of a single ephemeral data store. This avoids having multiple priori= ties too; its just 1. >=20 > --Tom We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example: residential services business services each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store.=20 As we are still keeping 1 to 1 overlay, not many to 1. Dean >=20 >=20 >> references. >>=20 >> -- Jeff >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Sep 24 14:19: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 D69051A1A44 for ; Wed, 24 Sep 2014 14:19: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=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 2XfdDk2YrNKE for ; Wed, 24 Sep 2014 14:19:24 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3471A0191 for ; Wed, 24 Sep 2014 14:19:24 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j7so3676364qaq.37 for ; Wed, 24 Sep 2014 14:19: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:cc:content-type; bh=5jBjajOtyMO3A9BCmjF5rgkGUNJ7ymM060lZ66jiSTw=; b=dFVtq1HHrkwQugZLGFBo4kTWyDVKkIKbqylgA7DNNpCf0nb0gqKnysk19t19lifTSc 0+tSxE4O34apHduICqhAC7T7PnwObuCYN2XB/FhxZ4M69p5aXvxe6fW8QI7u9vjcGD58 rElNGkDnuTgvSBnHQXYrMiYlmTMPNd1wLO0YSQkVBfSnv79+YslycfPA4bURbLwOkfM7 gBsRmPqQp+/x8QBnLTE6ZUfItYP/UVy3OaNMHH2ZP9+2mP5XR9DqHSZWg+cWMH1SsSBa ws78ze+4DpEbx7NDDAlSe9+I3SoCNAVQhEwl6kXYG5zxhR9iIaYMqWrxYRSfrZ+7qnno 63xw== X-Gm-Message-State: ALoCoQmyzHT8UdDihdqyqu5MKNyrtS/ACsjZDE6Vl94vTl97l8KOx11lIlKLd+6Rz9n227e07ntr MIME-Version: 1.0 X-Received: by 10.140.98.11 with SMTP id n11mr13758334qge.83.1411593563340; Wed, 24 Sep 2014 14:19:23 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 24 Sep 2014 14:19:23 -0700 (PDT) In-Reply-To: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> Date: Wed, 24 Sep 2014 14:19:23 -0700 Message-ID: From: Andy Bierman To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a113ac3a0e926a90503d63c68 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NF0hjZL-7kl9PTj8fNu6PLv7ITs Cc: Jeffrey Haas , "Thomas D. Nadeau" , Susan Hares , "netmod@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 21:19:27 -0000 --001a113ac3a0e926a90503d63c68 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic wrote: > > On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau > wrote: > > > > > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas > wrote: > > > >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> [...] > >>>> > >>>> +-----------------+ > >>>> | | > >>>> +--- (+) ---+ | > >>>> ^ ^ v > >>>> +---+ +---+ +---+ > >>>> | | | | | | > >>>> |(1)| | | | | > >>>> | | | | | | > >>>> +---+ +---+ +---+ > >>>> > >>>> NC config ephemeral operational > >>>> datastore datastore state > >>>> > >>>> (1) The complete NC config datastore is at certain synchronization > >>>> points made persistent > >>>> > >>>> (+) Priority resolution, priorities may be per datastore or per > >>>> user or per 'application' or even per data node > >>> > >>> These are precisely the qualities I and some others were thinking > of when we started i2rs. The idea is quite simple, as you have said above > and really needs not be complicated more. > >> > >> It has its own complications. > >> > >> Do we permit more than one ephemeral datastore? If so, this simplifies > data > >> object priority when resolving the operational state. But this also > >> complicates operational state integrity when you have multiple cross > > > > I vote for keeping this simple for starters. Lets get an > implementation or two of a single ephemeral data store. This avoids having > multiple priorities too; its just 1. > > > > --Tom > We can allow multiple ephemeral data stores, but the only dependency can > be with the NC config datastore. Example: > > residential services > business services > > What does this really mean? I did not understand the details at the interim. Does this mean each datastore has separate data models? Does this mean each service represent separate I2RS clients? The only real reason to have multiple ephemeral datastores would be to create the same instances of 1 or more data nodes in multiple datastores. (multiple concurrent overlays). IMO this sort of complexity should be left out of the agent. each of the configuration sits in their own ephemeral datastore, but only > dependency is on NC config store. > > As we are still keeping 1 to 1 overlay, not many to 1. > Dean > > Andy > > > > > >> references. > >> > >> -- Jeff > >> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113ac3a0e926a90503d63c68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic <= deanb@juniper.net> wrote:

On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

>
> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote:<= br> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
>> [...]
>>>>
>>>>=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 =A0 =A0 =A0 =A0 =A0|
>>>>=A0 =A0 =A0 =A0^=A0 =A0 =A0 =A0 =A0 =A0^=A0 =A0 =A0 =A0 =A0= =A0v
>>>>=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|
>>>>=A0 =A0 =A0|(1)|=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 =A0|
>>>>=A0 =A0 =A0+---+=A0 =A0 =A0 =A0+---+=A0 =A0 =A0 =A0+---+ >>>>
>>>>=A0 =A0NC config=A0 ephemeral=A0 =A0 operational
>>>>=A0 =A0datastore=A0 datastore=A0 =A0 =A0 state
>>>>
>>>>=A0 (1) The complete NC config datastore is at certain sync= hronization
>>>>=A0 points made persistent
>>>>
>>>>=A0 (+) Priority resolution, priorities may be per datastor= e or per
>>>>=A0 user or per 'application' or even per data node=
>>>
>>>=A0 =A0 =A0These are precisely the qualities I and some others = were thinking of when we started i2rs. The idea is quite simple, as you hav= e said above and really needs not be complicated more.
>>
>> It has its own complications.
>>
>> Do we permit more than one ephemeral datastore?=A0 If so, this sim= plifies data
>> object priority when resolving the operational state.=A0 But this = also
>> complicates operational state integrity when you have multiple cro= ss
>
>=A0 =A0 =A0 =A0I vote for keeping this simple for starters. Lets get an= implementation or two of a single ephemeral data store. This avoids having= multiple priorities too; its just 1.
>
>=A0 =A0 =A0 =A0--Tom
We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example:

residential services
business services



What does this really m= ean?
I did not understand the details at the interim.
D= oes this mean each datastore has separate data models?
Does this = mean each service represent separate I2RS clients?

The only real reason to have multiple ephemeral datastores
would= be to create the same instances of 1 or more data nodes
in multi= ple datastores. (multiple concurrent overlays).

IM= O this sort of complexity should be left out of the agent.


each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store.

As we are still keeping 1 to 1 overlay, not many to 1.=A0

Dean



Andy
=A0
>
>
>> references.
>>
>> -- Jeff
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

--001a113ac3a0e926a90503d63c68-- From nobody Wed Sep 24 14:51: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 972501A031F; Wed, 24 Sep 2014 14:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOEk3CXTmjOT; Wed, 24 Sep 2014 14:51:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA31A06FD; Wed, 24 Sep 2014 14:51:14 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C982F289F2FB; Wed, 24 Sep 2014 17:51:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> Date: Wed, 24 Sep 2014 17:51:09 -0400 Message-Id: <9EEC8F6A-DC47-434D-A41E-CDC1D2C6DC4F@lucidvision.com> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/IyXEnlSDEnxStMxqS04pdli3c4k Cc: Jeffrey Haas , "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 24 Sep 2014 21:51:18 -0000 --Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why not start with just 1? On Sep 24, 2014:5:00 PM, at 5:00 PM, Dean Bogdanovic = wrote: >=20 > On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau = wrote: >=20 >>=20 >> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas = wrote: >>=20 >>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder = wrote: >>> [...] >>>>>=20 >>>>> +-----------------+ >>>>> | | >>>>> +--- (+) ---+ | >>>>> ^ ^ v >>>>> +---+ +---+ +---+ >>>>> | | | | | | >>>>> |(1)| | | | | >>>>> | | | | | | >>>>> +---+ +---+ +---+ >>>>>=20 >>>>> NC config ephemeral operational >>>>> datastore datastore state >>>>>=20 >>>>> (1) The complete NC config datastore is at certain synchronization >>>>> points made persistent >>>>>=20 >>>>> (+) Priority resolution, priorities may be per datastore or per >>>>> user or per 'application' or even per data node >>>>=20 >>>> These are precisely the qualities I and some others were = thinking of when we started i2rs. The idea is quite simple, as you have = said above and really needs not be complicated more. =20 >>>=20 >>> It has its own complications. >>>=20 >>> Do we permit more than one ephemeral datastore? If so, this = simplifies data >>> object priority when resolving the operational state. But this also >>> complicates operational state integrity when you have multiple cross >>=20 >> I vote for keeping this simple for starters. Lets get an = implementation or two of a single ephemeral data store. This avoids = having multiple priorities too; its just 1. >>=20 >> --Tom > We can allow multiple ephemeral data stores, but the only dependency = can be with the NC config datastore. Example: >=20 > residential services > business services >=20 > each of the configuration sits in their own ephemeral datastore, but = only dependency is on NC config store.=20 >=20 > As we are still keeping 1 to 1 overlay, not many to 1. >=20 > Dean >=20 >>=20 >>=20 >>> references. >>>=20 >>> -- Jeff >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 --Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03 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 iQIcBAEBCgAGBQJUIzzNAAoJEPcO+I7eiUJZm3kQAI3S1lVULf4IEVrFAF173jsz jZDFLGfhDEkJlZK2MaPKUmC3hTO5XNpkha4Ta2+wRaGtxcmyILR3LjleaAuB4RmT Bm6zuJV8dOUTKy36AP6zqgHdlZQILyR18Z1l6YVupTVkYoEbaMaPDkc8hN0eH31Y SBYOaQx0ivHwh1nNY+Wp2sbQllod90WQm2hniPBbWOdEi9Ib3HlfpV2EozPe9pn8 BeUtzVV6Ys1b8Q8gyKN7Wh/DOj1aybI/dV8A5o95N/AWLuzDVYie0TN6y7DL4H87 mHC6fSCfaGg6TH4A/dL4ZJ2sp4DGxfBi6IbyKdNrW8b8unqWsQhYe6apBxw33/ej jR1ChjRWG468Iob7UKIupYsPWz4/Blv+k04rCbgR5fk3+l02ORvzbl/0vD7mxb/F 0uTbZ/orLQJnU48+9TEVYmN1n8+JGYjZhKSz1JLEoOJDVpm8nDuoknIZ/36gIyNJ 0mWUaHqKvwGsew9geFojKni0uJDXCSDF673NLOKjmAL3tn6a7AlK/1jHbDJGTn4Q c8dTYWZExcF/xYtm4InmZ4ZdG2F5ixwG68LYrAsx6VBryGe1VWypxTCEkokP71KY P1LBoziDX4Bxn3NUvNAEV2gNP657JEhtwCsvm5PtqiOURCjWx2MkiMpH9MAUW0Z+ C0jIzJZ9vNk7H3bbmPCY =1Kg2 -----END PGP SIGNATURE----- --Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03-- From nobody Wed Sep 24 18:42: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 E4E951A6EFC; Wed, 24 Sep 2014 18:42:51 -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 BqQPDvNLHbot; Wed, 24 Sep 2014 18:42:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7FC1A6EFE; Wed, 24 Sep 2014 18:42:49 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB044.namprd05.prod.outlook.com (10.255.202.154) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 01:42:49 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 01:42:47 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 01:42:47 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP1qkCvY2EU2y81E2yFJqHoPh2n5wPShsAgACVywCAAEolgIAAQpCAgAAWiICAAETKAIAADg2AgABAtgA= Date: Thu, 25 Sep 2014 01:42:47 +0000 Message-ID: <0DB06D85-18C3-4874-90D5-3305057CF7C3@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <9EEC8F6A-DC47-434D-A41E-CDC1D2C6DC4F@lucidvision.com> In-Reply-To: <9EEC8F6A-DC47-434D-A41E-CDC1D2C6DC4F@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(189002)(93916002)(86362001)(99396003)(90102001)(76482002)(106356001)(106116001)(77096002)(10300001)(77156001)(76176999)(92726001)(92566001)(97736003)(36756003)(120916001)(15975445006)(31966008)(50986999)(82746002)(19580395003)(57306001)(19580405001)(66066001)(101416001)(107046002)(79102003)(83322001)(74502003)(81342003)(33656002)(64706001)(74662003)(46102003)(77982003)(4396001)(80022003)(81542003)(50226001)(104166001)(83072002)(20776003)(89996001)(88136002)(87936001)(105586002)(2656002)(62966002)(99286002)(85306004)(95666004)(83716003)(93886004)(85852003)(87286001)(110136001)(21056001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB044; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5rCV42nv2jFN2QygE9gi-pGmy7Q Cc: Jeffrey Haas , "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 01:42:52 -0000 Tom, I'm in favor of starting with one, but can see use cases for more. Please k= eep in mind that in case for more ephemeral data stores, they will all have= same schema, but different models in ephemeral stores. There will be no de= pendencies between ephemeral data stores. Dean On Sep 24, 2014, at 5:51 PM, Thomas D. Nadeau wro= te: > Why not start with just 1? >=20 > On Sep 24, 2014:5:00 PM, at 5:00 PM, Dean Bogdanovic = wrote: >=20 >>=20 >> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau = wrote: >>=20 >>>=20 >>> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas wr= ote: >>>=20 >>>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: >>>> [...] >>>>>>=20 >>>>>> +-----------------+ >>>>>> | | >>>>>> +--- (+) ---+ | >>>>>> ^ ^ v >>>>>> +---+ +---+ +---+ >>>>>> | | | | | | >>>>>> |(1)| | | | | >>>>>> | | | | | | >>>>>> +---+ +---+ +---+ >>>>>>=20 >>>>>> NC config ephemeral operational >>>>>> datastore datastore state >>>>>>=20 >>>>>> (1) The complete NC config datastore is at certain synchronization >>>>>> points made persistent >>>>>>=20 >>>>>> (+) Priority resolution, priorities may be per datastore or per >>>>>> user or per 'application' or even per data node >>>>>=20 >>>>> These are precisely the qualities I and some others were thinking of= when we started i2rs. The idea is quite simple, as you have said above and= really needs not be complicated more. =20 >>>>=20 >>>> It has its own complications. >>>>=20 >>>> Do we permit more than one ephemeral datastore? If so, this simplifie= s data >>>> object priority when resolving the operational state. But this also >>>> complicates operational state integrity when you have multiple cross >>>=20 >>> I vote for keeping this simple for starters. Lets get an implementatio= n or two of a single ephemeral data store. This avoids having multiple prio= rities too; its just 1. >>>=20 >>> --Tom >> We can allow multiple ephemeral data stores, but the only dependency can= be with the NC config datastore. Example: >>=20 >> residential services >> business services >>=20 >> each of the configuration sits in their own ephemeral datastore, but onl= y dependency is on NC config store.=20 >>=20 >> As we are still keeping 1 to 1 overlay, not many to 1. >>=20 >> Dean >>=20 >>>=20 >>>=20 >>>> references. >>>>=20 >>>> -- Jeff >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >=20 From nobody Wed Sep 24 18:48:08 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 2070D1A6F04; Wed, 24 Sep 2014 18:48: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, 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 dMcGGqMbsv7j; Wed, 24 Sep 2014 18:48:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A51B1A6EFE; Wed, 24 Sep 2014 18:48:03 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB124.namprd05.prod.outlook.com (10.255.199.28) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 01:48:02 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 01:48:01 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 01:48:01 +0000 From: Dean Bogdanovic To: Andy Bierman Thread-Topic: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP2D04ho2Qh+oBWEeVzhOAmMpnHZwRFP2A Date: Thu, 25 Sep 2014 01:48:01 +0000 Message-ID: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(24454002)(189002)(377454003)(51704005)(199003)(77982003)(46102003)(80022003)(4396001)(33656002)(81342003)(74662003)(64706001)(74502003)(83072002)(20776003)(89996001)(50226001)(81542003)(16236675004)(104166001)(19617315012)(57306001)(19580405001)(19580395003)(83322001)(66066001)(101416001)(107046002)(79102003)(87286001)(110136001)(21056001)(105586002)(99286002)(2656002)(62966002)(88136002)(87936001)(83716003)(93886004)(85852003)(95666004)(85306004)(106116001)(106356001)(77096002)(93916002)(86362001)(76482002)(90102001)(99396003)(15975445006)(31966008)(97736003)(36756003)(120916001)(82746002)(50986999)(76176999)(77156001)(10300001)(92726001)(92566001)(104396001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2384FE3B832540EA9C25B7A452564424junipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB124; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-UeiEVmdxahYieCBtbD4G0fDG7s Cc: Jeffrey Haas , "Thomas D. Nadeau" , Susan Hares , "netmod@ietf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 01:48:06 -0000 --_000_2384FE3B832540EA9C25B7A452564424junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 24, 2014, at 5:19 PM, Andy Bierman > wrote: On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic > wrote: On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau > wrote: > > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas > wrote: > >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder > wro= te: >> [...] >>>> >>>> +-----------------+ >>>> | | >>>> +--- (+) ---+ | >>>> ^ ^ v >>>> +---+ +---+ +---+ >>>> | | | | | | >>>> |(1)| | | | | >>>> | | | | | | >>>> +---+ +---+ +---+ >>>> >>>> NC config ephemeral operational >>>> datastore datastore state >>>> >>>> (1) The complete NC config datastore is at certain synchronization >>>> points made persistent >>>> >>>> (+) Priority resolution, priorities may be per datastore or per >>>> user or per 'application' or even per data node >>> >>> These are precisely the qualities I and some others were thinking o= f when we started i2rs. The idea is quite simple, as you have said above an= d really needs not be complicated more. >> >> It has its own complications. >> >> Do we permit more than one ephemeral datastore? If so, this simplifies = data >> object priority when resolving the operational state. But this also >> complicates operational state integrity when you have multiple cross > > I vote for keeping this simple for starters. Lets get an implementa= tion or two of a single ephemeral data store. This avoids having multiple p= riorities too; its just 1. > > --Tom We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example: residential services business services What does this really mean? I did not understand the details at the interim. Does this mean each datastore has separate data models? yes, each data store has separate data models Does this mean each service represent separate I2RS clients? each ephemeral datastore represents separate I2RS clients. The only real reason to have multiple ephemeral datastores would be to create the same instances of 1 or more data nodes in multiple datastores. (multiple concurrent overlays). I view it differently. In subscriber management different data models are u= sed for residential and business subscribers. Some service data models can = be very unique for business customers. So separating them in different data= stores makes sense, as they there are no overlaps with each other, only wi= th NC config store. In this case, we can get better performance. IMO this sort of complexity should be left out of the agent. each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store. As we are still keeping 1 to 1 overlay, not many to 1. Dean Andy > > >> references. >> >> -- Jeff >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_2384FE3B832540EA9C25B7A452564424junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 24, 2014, at 5:19 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic= <deanb@juniper.ne= t> wrote:

On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

>
> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote:<= br> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
>> [...]
>>>>
>>>>             +------= -----------+
>>>>             |  &nb= sp;              |
>>>>       +--- (+) ---+  =          |
>>>>       ^        &nb= sp;  ^           v
>>>>     +---+       = ;+---+       +---+
>>>>     |   |      &nb= sp;|   |       |   |
>>>>     |(1)|       | =  |       |   |
>>>>     |   |      &nb= sp;|   |       |   |
>>>>     +---+       = ;+---+       +---+
>>>>
>>>>   NC config  ephemeral    operati= onal
>>>>   datastore  datastore      = state
>>>>
>>>>  (1) The complete NC config datastore is at certain s= ynchronization
>>>>  points made persistent
>>>>
>>>>  (+) Priority resolution, priorities may be per d= atastore or per
>>>>  user or per 'application' or even per data node
>>>
>>>     These are precisely the qualities I and som= e others were thinking of when we started i2rs. The idea is quite simple, a= s you have said above and really needs not be complicated more.
>>
>> It has its own complications.
>>
>> Do we permit more than one ephemeral datastore?  If so, this = simplifies data
>> object priority when resolving the operational state.  But th= is also
>> complicates operational state integrity when you have multiple cro= ss
>
>       I vote for keeping this simple for starters.= Lets get an implementation or two of a single ephemeral data store. This a= voids having multiple priorities too; its just 1.
>
>       --Tom
We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example:

residential services
business services



What does this really mean?
I did not understand the details at the interim.
Does this mean each datastore has separate data models?

yes, each data store has separate data models
 
Does this mean each service represent separate I2RS clients?

each ephemeral datastore represents separate I2RS clients.


The only real reason to have multiple ephemeral datastores
would be to create the same instances of 1 or more data nodes
in multiple datastores. (multiple concurrent overlays).

I view it differently. In subscriber management different data models are u= sed for residential and business subscribers. Some service data models can = be very unique for business customers. So separating them in different data= stores makes sense, as they there are no overlaps with each other, only with NC config store. In this case, = we can get better performance.

IMO this sort of complexity should be left out of the agent.


each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store.

As we are still keeping 1 to 1 overlay, not many to 1. 

Dean



Andy
 
>
>
>> references.
>>
>> -- Jeff
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


--_000_2384FE3B832540EA9C25B7A452564424junipernet_-- From nobody Wed Sep 24 23:18:04 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 4881D1A1A8C for ; Wed, 24 Sep 2014 23:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9UnP1r9FVcj for ; Wed, 24 Sep 2014 23:18:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AED1A029B for ; Wed, 24 Sep 2014 23:17:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 91E46111C; Thu, 25 Sep 2014 08:17:58 +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 oCap77Jq0RuC; Thu, 25 Sep 2014 08:17:54 +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, 25 Sep 2014 08:17:57 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E72C20036; Thu, 25 Sep 2014 08:17:57 +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 Dn811_XChhni; Thu, 25 Sep 2014 08:17:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D25420035; Thu, 25 Sep 2014 08:17:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D425C2E88DD2; Thu, 25 Sep 2014 08:17:54 +0200 (CEST) Date: Thu, 25 Sep 2014 08:17:54 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140925061753.GA26200@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org References: <20140924153051.GB2639@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924153051.GB2639@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NOkU_FkizE8cV9xo9tuhnSrD6rk Cc: i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store 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, 25 Sep 2014 06:18:02 -0000 I believe this question is a general question, not particular to the way we realize ephemeral data. If I2RS injects state that is not consistent with config, then that state is likely ignored (at least this is what I understood when we touched this point last week). Conceptually, with the shadowing approach, there is a 'merge' operation between the config datastore and ephemeral datastores. If the merge fails, then (as far as I recall last weeks discussion) it is expected that a notification is emitted to the I2RS system(s) involved. I2RS seems to seek for high transaction rates. And NETCONF people love to keep the config datastore self-consistent. If changes to the config datastore invalidate I2RS content, then this needs to be signalled to I2RS clients to take action. I think it would be wrong to reject an otherwise valid config change because it creates a conflict with ephemeral state the config system may not even be aware of. /js On Wed, Sep 24, 2014 at 11:30:51AM -0400, Jeffrey Haas wrote: > In the proposed overlay model, presume that we have ephemeral data from a > model that lives within an augmentation to a local config model. In other > words, the ephemeral nodes are children of the local config nodes. > > Presume, per discussion, that the local config lives in the "config" data > store and that the ephemeral config - the augmenting nodes above - live in > the ephemeral data store. > > If we delete the container in the local config that the epehemeral config is > augmenting, is there any expectation that such a deletion should carry > through to the ephemeral config? > > Per the netmod interim discussion, probably not. It's in a separate > datastore. But it does lead to integrity issues since we now have orphaned > state. In this particular example, permitting the deletion to carry through > to the ephemeral datastore at least provides one additional level of > consistency. > > ----- > > My second thought is would we ever want to provide filtering in the > conditional checks (must/when) in the ephemeral datastore based on the > underlying source of the data? Since local config would be shadowed into > the ephemeral datastore, do we want the ability to match on the source of > the node set under evaluation? > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- 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 Sep 24 23:25:04 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 BB08C1A6F7E; Wed, 24 Sep 2014 23:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9dAnmNqm4rk; Wed, 24 Sep 2014 23:25:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A2E1A1A8C; Wed, 24 Sep 2014 23:25:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00BB8111C; Thu, 25 Sep 2014 08:24: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 9xNw2V21zELW; Thu, 25 Sep 2014 08:24:56 +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, 25 Sep 2014 08:24:59 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9B1F20036; Thu, 25 Sep 2014 08:24:58 +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 S2sn7dScftCz; Thu, 25 Sep 2014 08:24:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EE0520035; Thu, 25 Sep 2014 08:24:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E63802E88E2F; Thu, 25 Sep 2014 08:24:56 +0200 (CEST) Date: Thu, 25 Sep 2014 08:24:56 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140925062456.GB26200@elstar.local> Mail-Followup-To: Jeffrey Haas , "Thomas D. Nadeau" , i2rs@ietf.org, Susan Hares , netmod@ietf.org References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924153401.GC2639@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/qlTVMuBCDP2XZL2FMHkEtFyLbUY Cc: "Thomas D. Nadeau" , netmod@ietf.org, Susan Hares , i2rs@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 06:25:02 -0000 On Wed, Sep 24, 2014 at 11:34:01AM -0400, Jeffrey Haas wrote: > On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > > On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: > [...] > > > > > > +-----------------+ > > > | | > > > +--- (+) ---+ | > > > ^ ^ v > > > +---+ +---+ +---+ > > > | | | | | | > > > |(1)| | | | | > > > | | | | | | > > > +---+ +---+ +---+ > > > > > > NC config ephemeral operational > > > datastore datastore state > > > > > > (1) The complete NC config datastore is at certain synchronization > > > points made persistent > > > > > > (+) Priority resolution, priorities may be per datastore or per > > > user or per 'application' or even per data node > > > > These are precisely the qualities I and some others were thinking of when we started i2rs. The idea is quite simple, as you have said above and really needs not be complicated more. > > It has its own complications. > > Do we permit more than one ephemeral datastore? If so, this simplifies data > object priority when resolving the operational state. But this also > complicates operational state integrity when you have multiple cross > references. It complicates the merge operation - it does not affect the integrity of the operational state. But even that may not be true, at least not from the point of the merge algorithm. There likely is not much difference between merging 1 or N ephemeral datastores. And at the end of the day, if you have I2RS systems injecting conflicts, then it does not matter whether that happens in 1 ephemeral datastore and N ephemeral datastores. Having N ephemeral datastores had the advantage that I can easily disable a complete ephemeral datastore by modifying its priority while multiple I2RS systems writing concurrently into the same scratchpad will be much more fun to deal with. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 23:32: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 DB9041A6F82; Wed, 24 Sep 2014 23:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLqD3Daxm6y5; Wed, 24 Sep 2014 23:32:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B161A1AC6; Wed, 24 Sep 2014 23:32:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DFE8D111C; Thu, 25 Sep 2014 08:32:27 +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 FGvQi8pew4Xg; Thu, 25 Sep 2014 08:32:24 +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, 25 Sep 2014 08:32:26 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAE0E20036; Thu, 25 Sep 2014 08:32:26 +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 x9UB7gFQlAXJ; Thu, 25 Sep 2014 08:32:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 322E220035; Thu, 25 Sep 2014 08:32:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E0682E88E76; Thu, 25 Sep 2014 08:32:25 +0200 (CEST) Date: Thu, 25 Sep 2014 08:32:25 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140925063225.GC26200@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924153802.GD2639@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924153802.GD2639@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-mHWnovIwKDouF-ZiWipHH-1ixo Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 06:32:32 -0000 On Wed, Sep 24, 2014 at 11:38:02AM -0400, Jeffrey Haas wrote: > > > > I do not follow here. The secure transport delivers what NETCONF calls > > a username, the identity of the NETCONF client. If this client acts on > > behalf of another application (the secondary identity), then this > > identity is meta data should be attached to the information submitted > > to the ephemeral datastore. I do not see why this would lead to any > > changes to SSH or TLS. > > I tried to raise this as a question during the interim, but I think it was > lost. How should the meta-data be transported? > Likely as meta-data attributes. https://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > The primary ones I am aware of are operations on network addresses and > prefixes. Was netmod looking for an explicit manifest of such operations? We are happy to receive input. A starting point is here. http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 This I-D, however, does not define functions for network addresses. > This may have overlap in the work for the ACL module that is already a > netmod document. I am lost here. I do not see how additional xpath functions related to the NACM (which came out of NETCONF not NETMOD). /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 Sep 25 03:12: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 39A9B1A6F62; Thu, 25 Sep 2014 03:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZjUEtISPZ_p; Thu, 25 Sep 2014 03:12:04 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F7C1A1A5D; Thu, 25 Sep 2014 03:12:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 547161C064D; Thu, 25 Sep 2014 03:12:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [118.143.25.125]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8D73A1C062D; Thu, 25 Sep 2014 03:12:02 -0700 (PDT) Message-ID: <5423EA70.7070907@joelhalpern.com> Date: Thu, 25 Sep 2014 06:12:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dean Bogdanovic , Andy Bierman References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> In-Reply-To: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/RZCYUEB125vzGKWV-NC6ASDm5Sk Cc: Jeffrey Haas , "Thomas D. Nadeau" , "netmod@ietf.org" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 10:12:06 -0000 Separate ephemeral data stores for distinct I2RS clients would seem a very bad idea. It is perfectly acceptable for one client to read information being manipulated by another cleitn. And if so, the reader should see the results of that other clients activity. Also, separate stores would not produce the error results required in the case of collision. So no, I do not see a use case from I2RS for multiple ephemeral data stores. Yours, Joel On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: > > On Sep 24, 2014, at 5:19 PM, Andy Bierman > wrote: > >> >> >> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic > > wrote: >> >> >> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >> > wrote: >> >> > >> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >> > wrote: >> > >> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >> > > wrote: >> >> [...] >> >>>> >> >>>> +-----------------+ >> >>>> | | >> >>>> +--- (+) ---+ | >> >>>> ^ ^ v >> >>>> +---+ +---+ +---+ >> >>>> | | | | | | >> >>>> |(1)| | | | | >> >>>> | | | | | | >> >>>> +---+ +---+ +---+ >> >>>> >> >>>> NC config ephemeral operational >> >>>> datastore datastore state >> >>>> >> >>>> (1) The complete NC config datastore is at certain >> synchronization >> >>>> points made persistent >> >>>> >> >>>> (+) Priority resolution, priorities may be per datastore or per >> >>>> user or per 'application' or even per data node >> >>> >> >>> These are precisely the qualities I and some others were >> thinking of when we started i2rs. The idea is quite simple, as you >> have said above and really needs not be complicated more. >> >> >> >> It has its own complications. >> >> >> >> Do we permit more than one ephemeral datastore? If so, this >> simplifies data >> >> object priority when resolving the operational state. But this >> also >> >> complicates operational state integrity when you have multiple >> cross >> > >> > I vote for keeping this simple for starters. Lets get an >> implementation or two of a single ephemeral data store. This >> avoids having multiple priorities too; its just 1. >> > >> > --Tom >> We can allow multiple ephemeral data stores, but the only >> dependency can be with the NC config datastore. Example: >> >> residential services >> business services >> >> >> >> What does this really mean? >> I did not understand the details at the interim. >> Does this mean each datastore has separate data models? > > yes, each data store has separate data models > >> Does this mean each service represent separate I2RS clients? > > each ephemeral datastore represents separate I2RS clients. > >> >> The only real reason to have multiple ephemeral datastores >> would be to create the same instances of 1 or more data nodes >> in multiple datastores. (multiple concurrent overlays). > > I view it differently. In subscriber management different data models > are used for residential and business subscribers. Some service data > models can be very unique for business customers. So separating them in > different data stores makes sense, as they there are no overlaps with > each other, only with NC config store. In this case, we can get better > performance. >> >> IMO this sort of complexity should be left out of the agent. >> >> >> each of the configuration sits in their own ephemeral datastore, >> but only dependency is on NC config store. >> >> As we are still keeping 1 to 1 overlay, not many to 1. >> >> >> Dean >> >> >> >> Andy >> >> > >> > >> >> references. >> >> >> >> -- Jeff >> >> >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> 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 Sep 25 03:20: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 926C51A6F9F for ; Thu, 25 Sep 2014 03:20:00 -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 uHyKJRtzkh_6 for ; Thu, 25 Sep 2014 03:19:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055E01A6F9E for ; Thu, 25 Sep 2014 03:19:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CED311C0691; Thu, 25 Sep 2014 03:19:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [118.143.25.125]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D261D1C064D; Thu, 25 Sep 2014 03:19:57 -0700 (PDT) Message-ID: <5423EC4B.7080209@joelhalpern.com> Date: Thu, 25 Sep 2014 06:19:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Bierman , Jeffrey Haas References: <20140924153051.GB2639@pfrc> 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/3wciqZ0aoNyaMsTJ6iL4AlD0doU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 10:20:00 -0000 Top posting for ease of reading, but retaining the content for those who want context. As I understand the shadow proposal, there is the regular local config data store, and then there is a second data store (shadow) used by I2RS for its ephemeral data. That store is never persisted. So far, so good. Then Andy asked about when they are synchronized, and suggested that they would be sychronized only when the shadow datastore is established by teh first I2RS modification request (if I understood him correctly). I don't think that works. Suppose that I2RS has adjusted data items A and B, creating and filling the shadow data store. And then someone using CLI / normal NetCONF adjusts item C. If an I2RS client goes to read C, or does some operation which depends upon the value of C, it has to be working with the new value of C, not the value at the time the ephemeral store was created. Yours, Joel On 9/24/14, 11:47 AM, Andy Bierman wrote: > > > On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas > wrote: > > In the proposed overlay model, presume that we have ephemeral data > from a > model that lives within an augmentation to a local config model. In > other > words, the ephemeral nodes are children of the local config nodes. > > Presume, per discussion, that the local config lives in the "config" > data > store and that the ephemeral config - the augmenting nodes above - > live in > the ephemeral data store. > > If we delete the container in the local config that the epehemeral > config is > augmenting, is there any expectation that such a deletion should carry > through to the ephemeral config? > > Per the netmod interim discussion, probably not. It's in a separate > datastore. But it does lead to integrity issues since we now have > orphaned > state. In this particular example, permitting the deletion to carry > through > to the ephemeral datastore at least provides one additional level of > consistency. > > > I think the concept of "shadowing the local config" makes this behavior > confusing. > If the ephemeral datastore instances remains after the config datastore > instances are deleted, how is that really shadowing? > > IMO, shadowing only occurs when the ephemeral datastore is edited. > It is used as a snapshot to reduce the I2RS payload size (shadow patch?. > But the data that gets created in the ephemeral datastore is complete and > self-contained. The actual data structures are implementation details. > Maybe the local config is cloned, maybe it is shadowed. > > ----- > > My second thought is would we ever want to provide filtering in the > conditional checks (must/when) in the ephemeral datastore based on the > underlying source of the data? Since local config would be shadowed > into > the ephemeral datastore, do we want the ability to match on the > source of > the node set under evaluation? > > > Each datastore should only validated against itself, or else the > XPath implementation would be even more complicated. If the ephemeral > datastore > is supposed to be fast (I remember 5000 updates a second from the BoF) > then running validation tests across multiple datastores constantly will > not help. > > Or do you mean flag a must/when as "do-not-use" in the ephemeral datastore? > If that were possible it would help speed up the server. > > > > -- 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 > From nobody Thu Sep 25 03:26: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 535121A1C04; Thu, 25 Sep 2014 03:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE3bHd3sGTpj; Thu, 25 Sep 2014 03:26:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392871A01F6; Thu, 25 Sep 2014 03:26:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 09D086F5; Thu, 25 Sep 2014 12:26:46 +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 d4AFDhBVxi53; Thu, 25 Sep 2014 12:26:41 +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, 25 Sep 2014 12:26:44 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4811820037; Thu, 25 Sep 2014 12:26:44 +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 Xm_2qWgc0RSm; Thu, 25 Sep 2014 12:26:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 546BF20035; Thu, 25 Sep 2014 12:26:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D2612E89517; Thu, 25 Sep 2014 12:26:40 +0200 (CEST) Date: Thu, 25 Sep 2014 12:26:40 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20140925102640.GA27142@elstar.local> Mail-Followup-To: "Joel M. Halpern" , Dean Bogdanovic , Andy Bierman , "netmod@ietf.org" , Susan Hares , "i2rs@ietf.org" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5423EA70.7070907@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/e36Ri381EE__EfeQbeOYOcUIurE Cc: "i2rs@ietf.org" , Susan Hares , Dean Bogdanovic , "netmod@ietf.org" , Andy Bierman Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 10:26:50 -0000 Joel, my expectations about the intelligence of I2RS clients is perhaps lower than yours. Do you really believe I2RS clients will be smart to adapt to whatever some other unknown conflicting I2RS client injects into a shared ephemeral datastore? I do not expect smartness. My hope is that I2RS clients involved in a conflict can be signalled and probably more important that a human operator can be signalled that I2RS clients step into each other so that a human can take action to resolve things. Automatic conflict resultion based on observation what state is injected by other I2RS clients seems to me a huge (idealistic) assumption. I would find conflict detection during the merge operation likely more reliable than conflict detection based on smart I2RS clients monitoring closely what is going on in a shared datastore. I assume there will be dumb I2RS clients. /js On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote: > Separate ephemeral data stores for distinct I2RS clients would seem a > very bad idea. > It is perfectly acceptable for one client to read information being > manipulated by another cleitn. And if so, the reader should see the > results of that other clients activity. > > Also, separate stores would not produce the error results required in > the case of collision. > > So no, I do not see a use case from I2RS for multiple ephemeral data stores. > > Yours, > Joel > > On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: > > > >On Sep 24, 2014, at 5:19 PM, Andy Bierman >> wrote: > > > >> > >> > >>On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >>> wrote: > >> > >> > >> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau > >> > wrote: > >> > >> > > >> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas > >> > wrote: > >> > > >> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > >> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder > >> >> > wrote: > >> >> [...] > >> >>>> > >> >>>> +-----------------+ > >> >>>> | | > >> >>>> +--- (+) ---+ | > >> >>>> ^ ^ v > >> >>>> +---+ +---+ +---+ > >> >>>> | | | | | | > >> >>>> |(1)| | | | | > >> >>>> | | | | | | > >> >>>> +---+ +---+ +---+ > >> >>>> > >> >>>> NC config ephemeral operational > >> >>>> datastore datastore state > >> >>>> > >> >>>> (1) The complete NC config datastore is at certain > >> synchronization > >> >>>> points made persistent > >> >>>> > >> >>>> (+) Priority resolution, priorities may be per datastore or per > >> >>>> user or per 'application' or even per data node > >> >>> > >> >>> These are precisely the qualities I and some others were > >> thinking of when we started i2rs. The idea is quite simple, as you > >> have said above and really needs not be complicated more. > >> >> > >> >> It has its own complications. > >> >> > >> >> Do we permit more than one ephemeral datastore? If so, this > >> simplifies data > >> >> object priority when resolving the operational state. But this > >> also > >> >> complicates operational state integrity when you have multiple > >> cross > >> > > >> > I vote for keeping this simple for starters. Lets get an > >> implementation or two of a single ephemeral data store. This > >> avoids having multiple priorities too; its just 1. > >> > > >> > --Tom > >> We can allow multiple ephemeral data stores, but the only > >> dependency can be with the NC config datastore. Example: > >> > >> residential services > >> business services > >> > >> > >> > >>What does this really mean? > >>I did not understand the details at the interim. > >>Does this mean each datastore has separate data models? > > > >yes, each data store has separate data models > > > >>Does this mean each service represent separate I2RS clients? > > > >each ephemeral datastore represents separate I2RS clients. > > > >> > >>The only real reason to have multiple ephemeral datastores > >>would be to create the same instances of 1 or more data nodes > >>in multiple datastores. (multiple concurrent overlays). > > > >I view it differently. In subscriber management different data models > >are used for residential and business subscribers. Some service data > >models can be very unique for business customers. So separating them in > >different data stores makes sense, as they there are no overlaps with > >each other, only with NC config store. In this case, we can get better > >performance. > >> > >>IMO this sort of complexity should be left out of the agent. > >> > >> > >> each of the configuration sits in their own ephemeral datastore, > >> but only dependency is on NC config store. > >> > >> As we are still keeping 1 to 1 overlay, not many to 1. > >> > >> > >> Dean > >> > >> > >> > >>Andy > >> > >> > > >> > > >> >> references. > >> >> > >> >> -- Jeff > >> >> > >> > > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 Sep 25 03:29:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842A31A6F87 for ; Thu, 25 Sep 2014 03:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_RMemi9wayd for ; Thu, 25 Sep 2014 03:29:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0E91A1A1C04 for ; Thu, 25 Sep 2014 03:29:37 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CAD561280934; Thu, 25 Sep 2014 12:29:35 +0200 (CEST) Date: Thu, 25 Sep 2014 12:29:35 +0200 (CEST) Message-Id: <20140925.122935.1032892075797966525.mbj@tail-f.com> To: jhaas@pfrc.org From: Martin Bjorklund In-Reply-To: <20140924153051.GB2639@pfrc> References: <20140924153051.GB2639@pfrc> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_wS3twKYdKzhzGzLFUf25DhKkEc Cc: i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 10:29:38 -0000 Jeffrey Haas wrote: > In the proposed overlay model, presume that we have ephemeral data from a > model that lives within an augmentation to a local config model. In other > words, the ephemeral nodes are children of the local config nodes. > > Presume, per discussion, that the local config lives in the "config" data > store and that the ephemeral config - the augmenting nodes above - live in > the ephemeral data store. > > If we delete the container in the local config that the epehemeral config is > augmenting, is there any expectation that such a deletion should carry > through to the ephemeral config? > > Per the netmod interim discussion, probably not. My interpretation of the interim discussion is that the deletion carries through. > It's in a separate > datastore. But a special datastore which acts a shadow to the config. I think this is an important property of this datastore. /martin From nobody Thu Sep 25 03:33: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 BD0EE1A6F61; Thu, 25 Sep 2014 03:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmnZD16uQHtG; Thu, 25 Sep 2014 03:33:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 638881A1C04; Thu, 25 Sep 2014 03:33:14 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id A73311280934; Thu, 25 Sep 2014 12:33:13 +0200 (CEST) Date: Thu, 25 Sep 2014 12:33:13 +0200 (CEST) Message-Id: <20140925.123313.352492571894922280.mbj@tail-f.com> To: jhaas@pfrc.org From: Martin Bjorklund In-Reply-To: <20140924153802.GD2639@pfrc> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924153802.GD2639@pfrc> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vnmjtOM549wn1ySKV-Tns45d-Qw Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 10:33:15 -0000 Jeffrey Haas wrote: > On Wed, Sep 24, 2014 at 09:00:26AM +0200, Juergen Schoenwaelder wrote: > > > It is noted, however, that introducing something like a secondary identity > > > would require changes to SSH and/or TLS and may be somewhat difficult to > > > make the case to the owning working groups. > > > > I do not follow here. The secure transport delivers what NETCONF calls > > a username, the identity of the NETCONF client. If this client acts on > > behalf of another application (the secondary identity), then this > > identity is meta data should be attached to the information submitted > > to the ephemeral datastore. I do not see why this would lead to any > > changes to SSH or TLS. > > I tried to raise this as a question during the interim, but I think it was > lost. How should the meta-data be transported? In general, NETCONF / RESTCONF with YANG supports the concept of meta-data, and meta-data is in XML transported as an XML attribute. (For JSON encoding see http://tools.ietf.org/id/draft-lhotka-netmod-yang-metadata-00.txt) > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > The primary ones I am aware of are operations on network addresses and > prefixes. Was netmod looking for an explicit manifest of such operations? Yes this would help. /martin From nobody Thu Sep 25 03:39: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 989841A6F61; Thu, 25 Sep 2014 03:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vOLBM38JTEn; Thu, 25 Sep 2014 03:39:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4B1A1C04; Thu, 25 Sep 2014 03:39:31 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CB0791280934; Thu, 25 Sep 2014 12:39:30 +0200 (CEST) Date: Thu, 25 Sep 2014 12:39:30 +0200 (CEST) Message-Id: <20140925.123930.1268640776659322434.mbj@tail-f.com> To: deanb@juniper.net From: Martin Bjorklund In-Reply-To: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FePMTD8mkQYD8ssOhvhsWrIY9AA Cc: netmod@ietf.org, i2rs@ietf.org, andy@yumaworks.com, shares@ndzh.com Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 10:39:32 -0000 Dean Bogdanovic wrote: > > On Sep 24, 2014, at 5:19 PM, Andy Bierman > > wrote: > We can allow multiple ephemeral data stores, but the only dependency > can be with the NC config datastore. Example: > > residential services > business services > > > > > What does this really mean? > > I did not understand the details at the interim. > > Does this mean each datastore has separate data models? > > yes, each data store has separate data models Now I am confused. At the interim we agreed (and you argued for :) that the schema (= data models) is the same for the config and ephemeral datastore. > I view it differently. In subscriber management different data models > are used for residential and business subscribers. Some service data > models can be very unique for business customers. Ok. > So separating them > in different data stores makes sense, as they there are no overlaps > with each other, only with NC config store. But since they are disjoint, there are really no reasons for not keeping them in the same datastore, since there will be no conflicts. > In this case, we can get > better performance. I can't see why, but this is probably an implementation issue. /martin From nobody Thu Sep 25 04:14: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 798421A02EA; Thu, 25 Sep 2014 04:14:27 -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 Bu8WN-rJa_GH; Thu, 25 Sep 2014 04:14:25 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D871A1A8A; Thu, 25 Sep 2014 04:14:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C772F1C062D; Thu, 25 Sep 2014 04:14:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [118.143.25.125]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 288221C0565; Thu, 25 Sep 2014 04:14:23 -0700 (PDT) Message-ID: <5423F90D.3050104@joelhalpern.com> Date: Thu, 25 Sep 2014 07:14:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dean Bogdanovic , Andy Bierman , "netmod@ietf.org" , Susan Hares , "i2rs@ietf.org" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> <20140925102640.GA27142@elstar.local> In-Reply-To: <20140925102640.GA27142@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UKEHA9KULv0zNFK56qxcPAOdob4 Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 11:14:27 -0000 (I believe that your talking about dumb clients is because I2RS and NetCONF YANG use terms differently. In I2RS, the Agent is the thing in the box, and the Client is the smarter things outside the box.) We wrote very specific rules into the architecture document the WG adopted, specifically because we wanted to bound the expected intelligence of the I2RS Agent. The agent is required to detect collision. It is required to generate error notification upon collision. It is also required to use the priority mechanism to produce a predictable composite result in the case of collision. The odds of that result being what the human beings want is pretty small But it is predictable. Which is all we felt we could ask for. Yours, Joel On 9/25/14, 6:26 AM, Juergen Schoenwaelder wrote: > Joel, > > my expectations about the intelligence of I2RS clients is perhaps > lower than yours. Do you really believe I2RS clients will be smart to > adapt to whatever some other unknown conflicting I2RS client injects > into a shared ephemeral datastore? > > I do not expect smartness. My hope is that I2RS clients involved in a > conflict can be signalled and probably more important that a human > operator can be signalled that I2RS clients step into each other so > that a human can take action to resolve things. Automatic conflict > resultion based on observation what state is injected by other I2RS > clients seems to me a huge (idealistic) assumption. > > I would find conflict detection during the merge operation likely > more reliable than conflict detection based on smart I2RS clients > monitoring closely what is going on in a shared datastore. > > I assume there will be dumb I2RS clients. > > /js > > On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote: >> Separate ephemeral data stores for distinct I2RS clients would seem a >> very bad idea. >> It is perfectly acceptable for one client to read information being >> manipulated by another cleitn. And if so, the reader should see the >> results of that other clients activity. >> >> Also, separate stores would not produce the error results required in >> the case of collision. >> >> So no, I do not see a use case from I2RS for multiple ephemeral data stores. >> >> Yours, >> Joel >> >> On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: >>> >>> On Sep 24, 2014, at 5:19 PM, Andy Bierman >> > wrote: >>> >>>> >>>> >>>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >>> > wrote: >>>> >>>> >>>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >>>> > wrote: >>>> >>>> > >>>> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >>>> > wrote: >>>> > >>>> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >>>> >>> > wrote: >>>> >> [...] >>>> >>>> >>>> >>>> +-----------------+ >>>> >>>> | | >>>> >>>> +--- (+) ---+ | >>>> >>>> ^ ^ v >>>> >>>> +---+ +---+ +---+ >>>> >>>> | | | | | | >>>> >>>> |(1)| | | | | >>>> >>>> | | | | | | >>>> >>>> +---+ +---+ +---+ >>>> >>>> >>>> >>>> NC config ephemeral operational >>>> >>>> datastore datastore state >>>> >>>> >>>> >>>> (1) The complete NC config datastore is at certain >>>> synchronization >>>> >>>> points made persistent >>>> >>>> >>>> >>>> (+) Priority resolution, priorities may be per datastore or per >>>> >>>> user or per 'application' or even per data node >>>> >>> >>>> >>> These are precisely the qualities I and some others were >>>> thinking of when we started i2rs. The idea is quite simple, as you >>>> have said above and really needs not be complicated more. >>>> >> >>>> >> It has its own complications. >>>> >> >>>> >> Do we permit more than one ephemeral datastore? If so, this >>>> simplifies data >>>> >> object priority when resolving the operational state. But this >>>> also >>>> >> complicates operational state integrity when you have multiple >>>> cross >>>> > >>>> > I vote for keeping this simple for starters. Lets get an >>>> implementation or two of a single ephemeral data store. This >>>> avoids having multiple priorities too; its just 1. >>>> > >>>> > --Tom >>>> We can allow multiple ephemeral data stores, but the only >>>> dependency can be with the NC config datastore. Example: >>>> >>>> residential services >>>> business services >>>> >>>> >>>> >>>> What does this really mean? >>>> I did not understand the details at the interim. >>>> Does this mean each datastore has separate data models? >>> >>> yes, each data store has separate data models >>> >>>> Does this mean each service represent separate I2RS clients? >>> >>> each ephemeral datastore represents separate I2RS clients. >>> >>>> >>>> The only real reason to have multiple ephemeral datastores >>>> would be to create the same instances of 1 or more data nodes >>>> in multiple datastores. (multiple concurrent overlays). >>> >>> I view it differently. In subscriber management different data models >>> are used for residential and business subscribers. Some service data >>> models can be very unique for business customers. So separating them in >>> different data stores makes sense, as they there are no overlaps with >>> each other, only with NC config store. In this case, we can get better >>> performance. >>>> >>>> IMO this sort of complexity should be left out of the agent. >>>> >>>> >>>> each of the configuration sits in their own ephemeral datastore, >>>> but only dependency is on NC config store. >>>> >>>> As we are still keeping 1 to 1 overlay, not many to 1. >>>> >>>> >>>> Dean >>>> >>>> >>>> >>>> Andy >>>> >>>> > >>>> > >>>> >> references. >>>> >> >>>> >> -- Jeff >>>> >> >>>> > >>>> > _______________________________________________ >>>> > netmod mailing list >>>> > netmod@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Sep 25 05: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 73D6B1A6FC4; Thu, 25 Sep 2014 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7ljS7u_ZPW0; Thu, 25 Sep 2014 05:19:13 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CB1A6FBE; Thu, 25 Sep 2014 05:19:12 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DC35728A0088; Thu, 25 Sep 2014 08:19:11 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <5423EA70.7070907@joelhalpern.com> Date: Thu, 25 Sep 2014 08:19:06 -0400 Message-Id: <9CFB901E-F91F-4B65-A968-12E9E0038A3C@lucidvision.com> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/vDp14mmMRnnUDLZvo2psdG1TmeY Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , Susan Hares Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 12:19:14 -0000 --Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:6:12 AM, at 6:12 AM, Joel M. Halpern = wrote: > Separate ephemeral data stores for distinct I2RS clients would seem a = very bad idea. > It is perfectly acceptable for one client to read information being = manipulated by another cleitn. And if so, the reader should see the = results of that other clients activity. I agree with Joel here. I was quite surprised by Dean's first = note making this statement. This seems like undue complication to the = whole situation. Making this work can be quite straight-forward. The = problem with having a store per-client is that well, clients can be = ephemeral too. People need to remember that the i2rs clients are = probably going to be applications that might come and go, and as such = should a device have to keep around a lot of state for everyone that = talks to it via its Rest/i2rs API? That does not sound like a good idea = to me, even if we time it out. > Also, separate stores would not produce the error results required in = the case of collision. Yes, that is precisely another issue that came to mind - besides = the scale of having one per client, do we really want to place the = burden on the device to let all clients know of collisions when merging? = What if those clients have "gone away"?=20 > So no, I do not see a use case from I2RS for multiple ephemeral data = stores. Agree %100. --Tom >=20 > Yours, > Joel >=20 > On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: >>=20 >> On Sep 24, 2014, at 5:19 PM, Andy Bierman > > wrote: >>=20 >>>=20 >>>=20 >>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >> > wrote: >>>=20 >>>=20 >>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >>> > wrote: >>>=20 >>> > >>> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >>> > wrote: >>> > >>> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau = wrote: >>> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >>> >> > wrote: >>> >> [...] >>> >>>> >>> >>>> +-----------------+ >>> >>>> | | >>> >>>> +--- (+) ---+ | >>> >>>> ^ ^ v >>> >>>> +---+ +---+ +---+ >>> >>>> | | | | | | >>> >>>> |(1)| | | | | >>> >>>> | | | | | | >>> >>>> +---+ +---+ +---+ >>> >>>> >>> >>>> NC config ephemeral operational >>> >>>> datastore datastore state >>> >>>> >>> >>>> (1) The complete NC config datastore is at certain >>> synchronization >>> >>>> points made persistent >>> >>>> >>> >>>> (+) Priority resolution, priorities may be per datastore or = per >>> >>>> user or per 'application' or even per data node >>> >>> >>> >>> These are precisely the qualities I and some others were >>> thinking of when we started i2rs. The idea is quite simple, as = you >>> have said above and really needs not be complicated more. >>> >> >>> >> It has its own complications. >>> >> >>> >> Do we permit more than one ephemeral datastore? If so, this >>> simplifies data >>> >> object priority when resolving the operational state. But = this >>> also >>> >> complicates operational state integrity when you have multiple >>> cross >>> > >>> > I vote for keeping this simple for starters. Lets get an >>> implementation or two of a single ephemeral data store. This >>> avoids having multiple priorities too; its just 1. >>> > >>> > --Tom >>> We can allow multiple ephemeral data stores, but the only >>> dependency can be with the NC config datastore. Example: >>>=20 >>> residential services >>> business services >>>=20 >>>=20 >>>=20 >>> What does this really mean? >>> I did not understand the details at the interim. >>> Does this mean each datastore has separate data models? >>=20 >> yes, each data store has separate data models >>=20 >>> Does this mean each service represent separate I2RS clients? >>=20 >> each ephemeral datastore represents separate I2RS clients. >>=20 >>>=20 >>> The only real reason to have multiple ephemeral datastores >>> would be to create the same instances of 1 or more data nodes >>> in multiple datastores. (multiple concurrent overlays). >>=20 >> I view it differently. In subscriber management different data models >> are used for residential and business subscribers. Some service data >> models can be very unique for business customers. So separating them = in >> different data stores makes sense, as they there are no overlaps with >> each other, only with NC config store. In this case, we can get = better >> performance. >>>=20 >>> IMO this sort of complexity should be left out of the agent. >>>=20 >>>=20 >>> each of the configuration sits in their own ephemeral datastore, >>> but only dependency is on NC config store. >>>=20 >>> As we are still keeping 1 to 1 overlay, not many to 1. >>>=20 >>>=20 >>> Dean >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>> > >>> > >>> >> references. >>> >> >>> >> -- Jeff >>> >> >>> > >>> > _______________________________________________ >>> > netmod mailing list >>> > netmod@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B 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 iQIcBAEBCgAGBQJUJAg6AAoJEPcO+I7eiUJZjNwQAIi4uP9r/pB7HyPLXPHy2Iwo 6HaJ6QeGGcQuOFYW2WJP3ygXpnS4cDFjssZZP9uA1El/tj+lTnIhzawV+jlJshPC 7+1tXMAUvyvwgbhE4MvyJv8mTYGSvbmhaMvyC0x0QYiRUfY3jzs6MYUV5lCb38sP IvAYBhN+VXPYtQ+87R1k6W1u0qOFZrDJRE1acZlO+XWcfYK+s8Id4msO2hTzU1OM rRWxG3sTinst6zaa/qwIqBCrGWSLmAyVCbgg8Jswe1V/UBgQC3MHNXo1dooaS9Yy Q5QAi338n0a6G7Wp6DKBJKkyW9QTgFINIiAK/q4sOc6O9jM7Lks8o5PvVwYhABAw vk3Rxl+a7jWdgrvKQlMrCJ801NUTSMMXME1zx9zM0B7jaR9rFNQL60gBpH/zndjO zy4zBfUiaBfJ8CQD3dglxmaoeA20YbVcpoIAq6DiM2ai4p9i0ZSp2rlXikpw8BuW AFfxs6c1rlwN/5DRJFjh+M50Zb0807otWxK+/pV2GH1j9mr/zFycoFtDTrsPPlJk SrVvpLeOhgtDXuhjhgrSiKo8TlzWHi2YleikJ9IfdQ2m8HPjlj5enolBQqIR/N07 wQUv37nuKm3H4+61v8xAmNjucj17UYojW/YrSYKjzom/86RkzBCqZeextqwHd5jf PwPDqLmsD11e7P22O3Kk =AEvr -----END PGP SIGNATURE----- --Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B-- From nobody Thu Sep 25 05:30: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 88C8F1A6FC5; Thu, 25 Sep 2014 05:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGoYLBD63HJE; Thu, 25 Sep 2014 05:30:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id F3BA61A0005; Thu, 25 Sep 2014 05:30:04 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2911828A00C6; Thu, 25 Sep 2014 08:30:04 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140925102640.GA27142@elstar.local> Date: Thu, 25 Sep 2014 08:29:57 -0400 Message-Id: References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> <20140925102640.GA27142@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/zUpBP-3lb2IMNmy3B8XkXqk-O8k Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" , Susan Hares Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 12:30:10 -0000 --Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:6:26 AM, at 6:26 AM, Juergen Schoenwaelder = wrote: > Joel, >=20 > my expectations about the intelligence of I2RS clients is perhaps > lower than yours. Do you really believe I2RS clients will be smart to > adapt to whatever some other unknown conflicting I2RS client injects > into a shared ephemeral datastore? >=20 > I do not expect smartness. My hope is that I2RS clients involved in a > conflict can be signalled and probably more important that a human > operator can be signalled that I2RS clients step into each other so > that a human can take action to resolve things. Automatic conflict > resultion based on observation what state is injected by other I2RS > clients seems to me a huge (idealistic) assumption. >=20 > I would find conflict detection during the merge operation likely=20 > more reliable than conflict detection based on smart I2RS clients > monitoring closely what is going on in a shared datastore. >=20 > I assume there will be dumb I2RS clients. I too assume "dumb" clients (i.e.: or those with minimal = computational horsepower). Given that assumption, I've thought that the = "merge" operation should be a simple copy-over-the-stored-config = operation. This is why we shouldn't have more than one ephemeral store. = If its treated this way, its quite literally, just a copy-over = operation. My original ideas around i2rs were always such that the = ephemeral store was just a scratch pad where objects were stored to = reflect a shadow of a subset of the running config (just the forwarding = state information) until such time as it could get copied there "soon" = after, either via a timer popping or an explicit command from the OS or = client(s). Access to that store was done using a variant of Netconf = that a) avoided the configuration verification process from Netconf and = b) was RESTful in nature. What we have been discussing here with = multiple stores (and priorities) has vastly and IMHO unnecessarily, = complicated the original idea which was quite simple and obtainable with = mostly off-the-shelf technological components (i.e.: RESTConf + a hacked = Netconf daemon + yang models). It is the latter recipe from with which = I think we should use as a starting point to build crash test dummy = implementations from to see if this thing works rather than discussing = the theoretical aspects of complicating that further. Sorry, just my = $.02.=20 --Tom >=20 > /js >=20 > On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote: >> Separate ephemeral data stores for distinct I2RS clients would seem a=20= >> very bad idea. >> It is perfectly acceptable for one client to read information being=20= >> manipulated by another cleitn. And if so, the reader should see the=20= >> results of that other clients activity. >>=20 >> Also, separate stores would not produce the error results required in=20= >> the case of collision. >>=20 >> So no, I do not see a use case from I2RS for multiple ephemeral data = stores. >>=20 >> Yours, >> Joel >>=20 >> On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: >>>=20 >>> On Sep 24, 2014, at 5:19 PM, Andy Bierman >> > wrote: >>>=20 >>>>=20 >>>>=20 >>>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >>> > wrote: >>>>=20 >>>>=20 >>>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >>>> > wrote: >>>>=20 >>>>>=20 >>>>> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >>>> > wrote: >>>>>=20 >>>>>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>>>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >>>> >>> > wrote: >>>>>> [...] >>>>>>>>=20 >>>>>>>> +-----------------+ >>>>>>>> | | >>>>>>>> +--- (+) ---+ | >>>>>>>> ^ ^ v >>>>>>>> +---+ +---+ +---+ >>>>>>>> | | | | | | >>>>>>>> |(1)| | | | | >>>>>>>> | | | | | | >>>>>>>> +---+ +---+ +---+ >>>>>>>>=20 >>>>>>>> NC config ephemeral operational >>>>>>>> datastore datastore state >>>>>>>>=20 >>>>>>>> (1) The complete NC config datastore is at certain >>>> synchronization >>>>>>>> points made persistent >>>>>>>>=20 >>>>>>>> (+) Priority resolution, priorities may be per datastore or per >>>>>>>> user or per 'application' or even per data node >>>>>>>=20 >>>>>>> These are precisely the qualities I and some others were >>>> thinking of when we started i2rs. The idea is quite simple, as = you >>>> have said above and really needs not be complicated more. >>>>>>=20 >>>>>> It has its own complications. >>>>>>=20 >>>>>> Do we permit more than one ephemeral datastore? If so, this >>>> simplifies data >>>>>> object priority when resolving the operational state. But this >>>> also >>>>>> complicates operational state integrity when you have multiple >>>> cross >>>>>=20 >>>>> I vote for keeping this simple for starters. Lets get an >>>> implementation or two of a single ephemeral data store. This >>>> avoids having multiple priorities too; its just 1. >>>>>=20 >>>>> --Tom >>>> We can allow multiple ephemeral data stores, but the only >>>> dependency can be with the NC config datastore. Example: >>>>=20 >>>> residential services >>>> business services >>>>=20 >>>>=20 >>>>=20 >>>> What does this really mean? >>>> I did not understand the details at the interim. >>>> Does this mean each datastore has separate data models? >>>=20 >>> yes, each data store has separate data models >>>=20 >>>> Does this mean each service represent separate I2RS clients? >>>=20 >>> each ephemeral datastore represents separate I2RS clients. >>>=20 >>>>=20 >>>> The only real reason to have multiple ephemeral datastores >>>> would be to create the same instances of 1 or more data nodes >>>> in multiple datastores. (multiple concurrent overlays). >>>=20 >>> I view it differently. In subscriber management different data = models >>> are used for residential and business subscribers. Some service data >>> models can be very unique for business customers. So separating them = in >>> different data stores makes sense, as they there are no overlaps = with >>> each other, only with NC config store. In this case, we can get = better >>> performance. >>>>=20 >>>> IMO this sort of complexity should be left out of the agent. >>>>=20 >>>>=20 >>>> each of the configuration sits in their own ephemeral datastore, >>>> but only dependency is on NC config store. >>>>=20 >>>> As we are still keeping 1 to 1 overlay, not many to 1. >>>>=20 >>>>=20 >>>> Dean >>>>=20 >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>>=20 >>>>>=20 >>>>>> references. >>>>>>=20 >>>>>> -- Jeff >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0 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 iQIcBAEBCgAGBQJUJArFAAoJEPcO+I7eiUJZ190P/RZcZcDvCNuEPMmNOSgvWxVD GOmz+k9AntCwa4SycKoCYjQcxJYpTGUvpRuigBMoQJ15JbKpaOCSy5q7Hr5QFvwa aIQ4pDumXfxfgn3GoFst15hH2rLzoJODSShi5OjD/HC9+9NIWbov8P++s4KnDT7f Gfcm2prg+8yFM8GJPGIEY9xwMebkpNQICacOzSyF4f6z9PwoNwsqNww3zUO8ll80 UFZMfINzHh6cdfONEnava9hgnRTru/0zAmWytmGu5m1huJyb343JCVgRlgzhPKAn 4AyejkvDwAN5ygBDTEjAdds+cWIH2csRHhNuFzR6U9NfihsH5xMPHW8GxiiGYNWe Qn1nt6oiHzgfAmq2A5idt9c5C/zEohcSntO1ZxBGn0vIVzYf9WubSIQeM/sDPPXd J0aJpcIJAcbnsY+67cvoiwYI4Nve0jh/Brl2SJd2OmQIPFnPf3/FdC28PYVzkuUH WhTBgm+BCJZVw9p2+2D03hGYwfJy5E33dhc5vqgwFfiJCLYL61/HLNm+WiSNoAiR FBsR5l+cr9q9wssYhZYP8kWVLcZNl8tTevuPUlxvXP+sGzNUewEdaRqX8WfakKgj KEkiPBZel4wFz1D3x+ukdXcrLeOaBsEIknih9pWRxpdUlTdIgLAdiZM0L5cV6whI ZODXu+aEShY+wv+NdQPV =/pba -----END PGP SIGNATURE----- --Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0-- From nobody Thu Sep 25 05:37:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63E1A6FC7; Thu, 25 Sep 2014 05:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4qxyC0MFdrk; Thu, 25 Sep 2014 05:37:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3231A6FCD; Thu, 25 Sep 2014 05:37:10 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 12:36:46 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 12:36:46 +0000 From: Dean Bogdanovic To: Martin Bjorklund Thread-Topic: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP2Kz+t2GpzYpGM0SSGwtZmoqRg5wRyWAA Date: Thu, 25 Sep 2014 12:36:45 +0000 Message-ID: References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> In-Reply-To: <20140925.123930.1268640776659322434.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(51704005)(189002)(199003)(89996001)(20776003)(88136002)(19580395003)(66066001)(82746002)(83322001)(85852003)(64706001)(104166001)(83072002)(19580405001)(76176999)(110136001)(87286001)(107046002)(50986999)(62966002)(90102001)(101416001)(21056001)(33656002)(77096002)(85306004)(93886004)(81542003)(31966008)(46102003)(106356001)(77982003)(74662003)(80022003)(10300001)(87936001)(86362001)(50226001)(76482002)(92566001)(97736003)(95666004)(57306001)(93916002)(2656002)(83716003)(4396001)(74502003)(81342003)(105586002)(106116001)(99286002)(120916001)(92726001)(79102003)(77156001)(36756003)(99396003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/SJt3Uxv6DSN7lhv_btnF7z52-1o Cc: "" , "" , "" , "" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 12:37:47 -0000 On Sep 25, 2014, at 6:39 AM, Martin Bjorklund wrote: > Dean Bogdanovic wrote: >>=20 >> On Sep 24, 2014, at 5:19 PM, Andy Bierman >> > wrote: >> We can allow multiple ephemeral data stores, but the only dependency >> can be with the NC config datastore. Example: >>=20 >> residential services >> business services >>=20 >>=20 >>=20 >>> What does this really mean? >>> I did not understand the details at the interim. >>> Does this mean each datastore has separate data models? >>=20 >> yes, each data store has separate data models >=20 > Now I am confused. At the interim we agreed (and you argued for :) > that the schema (=3D data models) is the same for the config and > ephemeral datastore. Here is an example. The device supports x number of features and has a data= model that represents the whole device. From that data model (schema), I d= ecide to build a service that is using only parts of all available and stor= e it into ephemeral DB, example L3VPN. Now in ephemeral only L3VPN service = configurations will be stored. >=20 >=20 >=20 >> I view it differently. In subscriber management different data models >> are used for residential and business subscribers. Some service data >> models can be very unique for business customers. >=20 > Ok. >=20 >> So separating them >> in different data stores makes sense, as they there are no overlaps >> with each other, only with NC config store. >=20 > But since they are disjoint, there are really no reasons for not > keeping them in the same datastore, since there will be no conflicts. >=20 >> In this case, we can get >> better performance. >=20 > I can't see why, but this is probably an implementation issue. >=20 >=20 > /martin From nobody Thu Sep 25 05:44: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 1BC7F1A6FD7; Thu, 25 Sep 2014 05:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPKDyYBsRPQp; Thu, 25 Sep 2014 05:44:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id DF00E1A6FD3; Thu, 25 Sep 2014 05:44:07 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 61AE628A0157; Thu, 25 Sep 2014 08:44:07 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 25 Sep 2014 08:44:01 -0400 Message-Id: <4B559804-7739-4CCD-8040-82B775D9D3B0@lucidvision.com> References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dTUXP958mJgUESY0GZ7Tj5zELyo Cc: "" , Martin Bjorklund , "" , "" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 12:44:14 -0000 --Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:8:36 AM, at 8:36 AM, Dean Bogdanovic = wrote: >=20 > On Sep 25, 2014, at 6:39 AM, Martin Bjorklund wrote: >=20 >> Dean Bogdanovic wrote: >>>=20 >>> On Sep 24, 2014, at 5:19 PM, Andy Bierman >>> > wrote: >>> We can allow multiple ephemeral data stores, but the only dependency >>> can be with the NC config datastore. Example: >>>=20 >>> residential services >>> business services >>>=20 >>>=20 >>>=20 >>>> What does this really mean? >>>> I did not understand the details at the interim. >>>> Does this mean each datastore has separate data models? >>>=20 >>> yes, each data store has separate data models >>=20 >> Now I am confused. At the interim we agreed (and you argued for :) >> that the schema (=3D data models) is the same for the config and >> ephemeral datastore. > Here is an example. The device supports x number of features and has a = data model that represents the whole device. =46rom that data model = (schema), I decide to build a service that is using only parts of all = available and store it into ephemeral DB, example L3VPN. Now in = ephemeral only L3VPN service configurations will be stored. I2RS does not model the entire device; just its "routing system" = components. --Tom >=20 >>=20 >>=20 >>=20 >>> I view it differently. In subscriber management different data = models >>> are used for residential and business subscribers. Some service data >>> models can be very unique for business customers. >>=20 >> Ok. >>=20 >>> So separating them >>> in different data stores makes sense, as they there are no overlaps >>> with each other, only with NC config store. >>=20 >> But since they are disjoint, there are really no reasons for not >> keeping them in the same datastore, since there will be no conflicts. >>=20 >>> In this case, we can get >>> better performance. >>=20 >> I can't see why, but this is probably an implementation issue. >>=20 >>=20 >> /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501 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 iQIcBAEBCgAGBQJUJA4RAAoJEPcO+I7eiUJZwi4P/jS0trfbTRxnCRLZJxoNZn/X pxdR1h6HHPjxVEI6wAdcm9m+4s0SP9SZuaQVtHllAdfISWKDqqvXvPucuYAC2vgb 1BLGgRxMHx0w84Go8H/l/gCmLh3CHyQeQESD87lxmgLG8Cx3WCyNoK17E3oiTt64 q776z4T+c6J4x8bhtM4fFD7deaDWpAO5V//vkjwiBrk/hQHNOC4XFTByLUSJPZLT 2AR6UUdzs/cf1sykyeNX0V43ZiOpRSrumG+1qkQclCrG8B3Q2rGjzC00rdK23cnl IvcUFhG+jlcOl3WXhQCmD3i+MIw3FZBmQjbT93q6JewkV8XitLqyKKGoi/2BIZAl 5MUIR0f3uWJIzhrnDL4P0moDXvIvG9/w4/ISgaDgV66V/qH5Li6ZD92ugkkjUN7K 2FRzlsKhxxTxPTp2rjqcl7Fq5IrVFOiQ7a6JFa0jkSKmAnb8wZ/Nnd97uaoCSyWn OUPvXQcHNG4RkED3pmpgibNG9mGyU/KeRtq6tIv4hHzv6wh0jidsa1tzvN3Jgpb2 aNzMtlb60erdvffRgPjtJjOGAj9xEBEJ9+SyGWCvfgbjVqgP8oRLqqPX+IQEnXDe e6tX/cOCizc43Ynwa9OaV8tp2uOJOFLoKYyEd2omyE1/nmOeD6C5igcadufIacef NHAWn80RbXq8fR+94d4Z =sRTS -----END PGP SIGNATURE----- --Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501-- From nobody Thu Sep 25 05:44: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 721211A6FD5; Thu, 25 Sep 2014 05:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ui8GeJSuysB; Thu, 25 Sep 2014 05:44:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 36FDA1A6FD2; Thu, 25 Sep 2014 05:44:33 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 23C711280934; Thu, 25 Sep 2014 14:44:32 +0200 (CEST) Date: Thu, 25 Sep 2014 14:44:31 +0200 (CEST) Message-Id: <20140925.144431.1189410629141675157.mbj@tail-f.com> To: deanb@juniper.net From: Martin Bjorklund In-Reply-To: References: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5cIQN8gyl-hZ2EKiaLejEwUzT2Q Cc: netmod@ietf.org, i2rs@ietf.org, andy@yumaworks.com, shares@ndzh.com Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 12:44:36 -0000 Dean Bogdanovic wrote: > > On Sep 25, 2014, at 6:39 AM, Martin Bjorklund wrote: > > > Dean Bogdanovic wrote: > >> > >> On Sep 24, 2014, at 5:19 PM, Andy Bierman > >> > wrote: > >> We can allow multiple ephemeral data stores, but the only dependency > >> can be with the NC config datastore. Example: > >> > >> residential services > >> business services > >> > >> > >> > >>> What does this really mean? > >>> I did not understand the details at the interim. > >>> Does this mean each datastore has separate data models? > >> > >> yes, each data store has separate data models > > > > Now I am confused. At the interim we agreed (and you argued for :) > > that the schema (= data models) is the same for the config and > > ephemeral datastore. > Here is an example. The device supports x number of features and has a > data model that represents the whole device. From that data model > (schema), I decide to build a service that is using only parts of all > available and store it into ephemeral DB, example L3VPN. Now in > ephemeral only L3VPN service configurations will be stored. This is fine. This means that the *schema* is the same for both data stores, but the instance data is different. Note that the set of data models make up the schema; thus both data stores have the *same* data models (same schema), not separate. /martin From nobody Thu Sep 25 07:17: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 2ADA91A6FED for ; Thu, 25 Sep 2014 07:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYn86PUur8zt for ; Thu, 25 Sep 2014 07:17:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AB30D1A6F91 for ; Thu, 25 Sep 2014 07:17:00 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 09135C202; Thu, 25 Sep 2014 10:17:00 -0400 (EDT) Date: Thu, 25 Sep 2014 10:16:59 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org Message-ID: <20140925141659.GA10261@pfrc> References: <20140924153051.GB2639@pfrc> <20140925061753.GA26200@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925061753.GA26200@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/r-J0M-73VkEdupLIC4SXrgJ7V_o Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:17:05 -0000 Juergen, On Thu, Sep 25, 2014 at 08:17:54AM +0200, Juergen Schoenwaelder wrote: > Conceptually, with the shadowing approach, there is a 'merge' > operation between the config datastore and ephemeral datastores. If > the merge fails, then (as far as I recall last weeks discussion) it is > expected that a notification is emitted to the I2RS system(s) > involved. Working through my examples to discuss this, I realized the fault in my logic: If we treat the delete operation in the local config for overlapping schemas as propagating through to the ephemeral datastore, it's effectively not a deterministic merge. It's a merge of the last party's state on top and that's not what we want. Consider the thought withdrawn. :-) > I2RS seems to seek for high transaction rates. And NETCONF people love > to keep the config datastore self-consistent. If changes to the config > datastore invalidate I2RS content, then this needs to be signalled to > I2RS clients to take action. I think it would be wrong to reject an > otherwise valid config change because it creates a conflict with > ephemeral state the config system may not even be aware of. Agreed. This does help solidify the case about the need to deal with inconsistencies introduced by changes to the underlying local config. -- Jeff From nobody Thu Sep 25 07:19: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 F0B241A6FF7 for ; Thu, 25 Sep 2014 07:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luV1TREruTyI for ; Thu, 25 Sep 2014 07:19:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D3AF31A6FF9 for ; Thu, 25 Sep 2014 07:19:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A22B0C27A; Thu, 25 Sep 2014 10:19:37 -0400 (EDT) Date: Thu, 25 Sep 2014 10:19:37 -0400 From: Jeffrey Haas To: Martin Bjorklund Message-ID: <20140925141937.GB10261@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925.122935.1032892075797966525.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/VrzvrTZRNERL511eJyoSlqtLFTU Cc: jhaas@pfrc.org, i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:19:47 -0000 On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > Jeffrey Haas wrote: > > In the proposed overlay model, presume that we have ephemeral data from a > > model that lives within an augmentation to a local config model. In other > > words, the ephemeral nodes are children of the local config nodes. > > > > Presume, per discussion, that the local config lives in the "config" data > > store and that the ephemeral config - the augmenting nodes above - live in > > the ephemeral data store. > > > > If we delete the container in the local config that the epehemeral config is > > augmenting, is there any expectation that such a deletion should carry > > through to the ephemeral config? > > > > Per the netmod interim discussion, probably not. > > My interpretation of the interim discussion is that the deletion > carries through. To be clear what I meant, consider: local config: ephemeral: A A/B - B is introduced as an augmentation of A If A is deleted, the question is whether we had B as an orphan or not. Thus, it "carries through" in the sense that the merge results in inconsistent state rather than B being deleted as well. -- Jeff From nobody Thu Sep 25 07:23:04 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 5415E1A6FF5; Thu, 25 Sep 2014 07:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJhc8F8azzbC; Thu, 25 Sep 2014 07:23:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 016321A6FEE; Thu, 25 Sep 2014 07:23:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B06B3C202; Thu, 25 Sep 2014 10:23:01 -0400 (EDT) Date: Thu, 25 Sep 2014 10:23:01 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140925142301.GC10261@pfrc> References: <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> <20140925102640.GA27142@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/mlKW_bEtIOqZwiFSsXo_a8CfkFU Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Juergen Schoenwaelder , Susan Hares , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 14:23:03 -0000 On Thu, Sep 25, 2014 at 08:29:57AM -0400, Thomas D. Nadeau wrote: > On Sep 25, 2014:6:26 AM, at 6:26 AM, Juergen Schoenwaelder wrote: [...] > > I assume there will be dumb I2RS clients. > > I too assume "dumb" clients (i.e.: or those with minimal computational > horsepower). Given that assumption, I've thought that the "merge" > operation should be a simple copy-over-the-stored-config operation. Mostly correct, but with the idea that you can "delete" from the ephemeral datastore perspective shadowed local config state by effectively leaving a hole in the ephemeral config. E.g.: Local Config: A[1] A[2] A[3] Ephemeral Config: DELETE A[2] A[4] Active Config (post merge): A[1] A[3] A[4] -- Jeff From nobody Thu Sep 25 07:25: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 7D1291A6F0B; Thu, 25 Sep 2014 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4NNkehqscTt; Thu, 25 Sep 2014 07:25:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 553391A6FF7; Thu, 25 Sep 2014 07:25:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1DAA9C202; Thu, 25 Sep 2014 10:25:37 -0400 (EDT) Date: Thu, 25 Sep 2014 10:25:37 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140925142537.GD10261@pfrc> References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> <4B559804-7739-4CCD-8040-82B775D9D3B0@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B559804-7739-4CCD-8040-82B775D9D3B0@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7AQ41Ep0XfmujmKMe94VDwhFaRc Cc: "" , "" , Martin Bjorklund , Dean Bogdanovic , "" Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 14:25:43 -0000 On Thu, Sep 25, 2014 at 08:44:01AM -0400, Thomas D. Nadeau wrote: > On Sep 25, 2014:8:36 AM, at 8:36 AM, Dean Bogdanovic wrote: > > Here is an example. The device supports x number of features and has a data model that represents the whole device. From that data model (schema), I decide to build a service that is using only parts of all available and store it into ephemeral DB, example L3VPN. Now in ephemeral only L3VPN service configurations will be stored. > > I2RS does not model the entire device; just its "routing system" components. While we're primarily concerned with I2RS semantics, the discussion has effectively broadened because the ephemeral mechanism we're discussing may be used by non-I2RS clients. I chatted with Dean a few minutes ago. I think much of the confusion regarding multiple ephemeral datastores is a result of a JUNOS implementation detail. He'll clarify the externally visible behavior which is more like what we've previously disucssed. -- Jeff From nobody Thu Sep 25 07:27:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCFC1A6FEE; Thu, 25 Sep 2014 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zM3C7Qxfbbv; Thu, 25 Sep 2014 07:27:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DECCE1A6F30; Thu, 25 Sep 2014 07:27:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AAEABC202; Thu, 25 Sep 2014 10:27:56 -0400 (EDT) Date: Thu, 25 Sep 2014 10:27:56 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Message-ID: <20140925142756.GE10261@pfrc> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924153802.GD2639@pfrc> <20140925063225.GC26200@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925063225.GC26200@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/c4dauUM_nVMBDpi6VoojVYggpJE Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 14:27:58 -0000 On Thu, Sep 25, 2014 at 08:32:25AM +0200, Juergen Schoenwaelder wrote: > Likely as meta-data attributes. > > https://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 More homework for me. Thanks. > > The primary ones I am aware of are operations on network addresses and > > prefixes. Was netmod looking for an explicit manifest of such operations? > > We are happy to receive input. A starting point is here. > > http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 > > This I-D, however, does not define functions for network addresses. > > > This may have overlap in the work for the ACL module that is already a > > netmod document. > > I am lost here. I do not see how additional xpath functions related to > the NACM (which came out of NETCONF not NETMOD). I was referring to http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-00 -- Jeff From nobody Thu Sep 25 07:39: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 26AD41A6FF9 for ; Thu, 25 Sep 2014 07:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlHaZuLYK_2S for ; Thu, 25 Sep 2014 07:39:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id CE18B1A6F56 for ; Thu, 25 Sep 2014 07:39:02 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id C64511280934; Thu, 25 Sep 2014 16:39:01 +0200 (CEST) Date: Thu, 25 Sep 2014 16:39:01 +0200 (CEST) Message-Id: <20140925.163901.67679202204863959.mbj@tail-f.com> To: jhaas@pfrc.org From: Martin Bjorklund In-Reply-To: <20140925141937.GB10261@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/l7g2Y28sGTuKv44Pl1aYEf9iUdI Cc: i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:39:04 -0000 Jeffrey Haas wrote: > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > Jeffrey Haas wrote: > > > In the proposed overlay model, presume that we have ephemeral data from a > > > model that lives within an augmentation to a local config model. In other > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > Presume, per discussion, that the local config lives in the "config" data > > > store and that the ephemeral config - the augmenting nodes above - live in > > > the ephemeral data store. > > > > > > If we delete the container in the local config that the epehemeral config is > > > augmenting, is there any expectation that such a deletion should carry > > > through to the ephemeral config? > > > > > > Per the netmod interim discussion, probably not. > > > > My interpretation of the interim discussion is that the deletion > > carries through. > > To be clear what I meant, consider: > > local config: ephemeral: > A A/B - B is introduced as an augmentation of A I think there might be a terminology confusion here, so let's do a simple example. list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. What happens if we in local config delete foo 42? If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps? /martin From nobody Thu Sep 25 08:44: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 DD7FF1A7014 for ; Thu, 25 Sep 2014 08:44:16 -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 z93VIjlS6Uzc for ; Thu, 25 Sep 2014 08:44:15 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A9D1A0174 for ; Thu, 25 Sep 2014 08:44:15 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id o8so5159219qcw.7 for ; Thu, 25 Sep 2014 08:44:14 -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=lBjLx8Np+1/X8u5g9zJE+jpjP7jlCWyCScDj+S4uTQ4=; b=ipM5koj18Tu9vit0YDtRDoAI9GvbnXo6FxsHg02exfqTsW9Ly4+g7AXZFSyFswfKG5 sXDFf8iqUIgBBM3WCA8NlkWk29hDcJjmR2cFF7s/IVCmu+cxRF+PVOsZw0JY4OS2rssA +GtdEBmFUozOA72tt2JSeS9fn0zbTwcHDcq3+0YcxG91EmLU0BqEDPHciomgEZgYdw93 721o6Cn+KaR5XsuBgNTHcw+aGFlF1F9YTg1yXpfY7yuLJRbjlWsZCD0jBXzq47tAs/qM 6dYRMGLS1gBWDnHPwloBQA2iO02Ty2IGTDgiXwDL2Vq4GZNtyVzYC4IB5EAEAv7ZQuzg dE4Q== X-Gm-Message-State: ALoCoQlqMMO9uf2n3aJvTPoTN5V8W5zEx9bFz9c2zgXPob8fm+AcQ4kWVH56Lf2BnQlvV1z39QCK MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr8418810qgl.90.1411659854385; Thu, 25 Sep 2014 08:44:14 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 25 Sep 2014 08:44:14 -0700 (PDT) In-Reply-To: <20140925.163901.67679202204863959.mbj@tail-f.com> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> Date: Thu, 25 Sep 2014 08:44:14 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c139862a2f790503e5acd1 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/z91qngP9KRTEiiJxA7IlE-5W0To Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 15:44:17 -0000 --001a11c139862a2f790503e5acd1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund wrote: > Jeffrey Haas wrote: > > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > > Jeffrey Haas wrote: > > > > In the proposed overlay model, presume that we have ephemeral data > from a > > > > model that lives within an augmentation to a local config model. In > other > > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > > > Presume, per discussion, that the local config lives in the "config" > data > > > > store and that the ephemeral config - the augmenting nodes above - > live in > > > > the ephemeral data store. > > > > > > > > If we delete the container in the local config that the epehemeral > config is > > > > augmenting, is there any expectation that such a deletion should > carry > > > > through to the ephemeral config? > > > > > > > > Per the netmod interim discussion, probably not. > > > > > > My interpretation of the interim discussion is that the deletion > > > carries through. > > > > To be clear what I meant, consider: > > > > local config: ephemeral: > > A A/B - B is introduced as an augmentation of A > > I think there might be a terminology confusion here, so let's do a > simple example. > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > > What happens if we in local config delete foo 42? > > If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now > presented to the internal apps? > Yes -- and what is presented to a client that retrieves the ephemeral config in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephemeral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as local config when the device restarts (or the ephemeral state is removed). It should not change the injected I2RS state at all. IMO it is really important that edits stay within a single datastore. > > /martin > Andy --001a11c139862a2f790503e5acd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
> > Jeffrey Haas <jhaas@pfrc.org= > wrote:
> > > In the proposed overlay model, presume that we have ephemera= l data from a
> > > model that lives within an augmentation to a local config mo= del.=A0 In other
> > > words, the ephemeral nodes are children of the local config = nodes.
> > >
> > > Presume, per discussion, that the local config lives in the = "config" data
> > > store and that the ephemeral config - the augmenting nodes a= bove - live in
> > > the ephemeral data store.
> > >
> > > If we delete the container in the local config that the epeh= emeral config is
> > > augmenting, is there any expectation that such a deletion sh= ould carry
> > > through to the ephemeral config?
> > >
> > > Per the netmod interim discussion, probably not.
> >
> > My interpretation of the interim discussion is that the deletion<= br> > > carries through.
>
> To be clear what I meant, consider:
>
> local config:=A0 =A0 =A0 ephemeral:
> A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A/B - B is introduced as an augme= ntation of A

I think there might be a terminology confusion here, so let's do a
simple example.

=A0 list foo {
=A0 =A0 key id;
=A0 =A0 leaf id { type int32; }
=A0 =A0 leaf a { type int32; }
=A0 }

local config:

=A0 =A0foo 42

In ephemeral config we now do SET /foo[id=3D42]/a=A0 to 4711.=A0 Thus, in ephemeral we now have a single node (a) with value 4711.

What happens if we in local config delete foo 42?

If /foo[id=3D42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps?


Yes -- and what is presented to a client that retrieves the ephemer= al config
in a GET request? IMO, coupling the datastores does not= make sense.

Your example is 1 reason I prefer the= "shadow shapshot" approach.
I think the local config a= nd client that added the "foo" entry in the ephemeral datastore
are meant to have different priorities.=A0 The entries are not cou= pled.
One wins and the other loses (main use-case is that ephemer= al wins).

Editing "foo 42" in the local = config just changes what will be installed as local config
when t= he device restarts (or the ephemeral state is removed).=A0 It should not ch= ange
the injected I2RS state at all.=A0 IMO it is really importan= t that edits stay within a single
datastore.

=



/martin

Andy
=A0
<= /div>
--001a11c139862a2f790503e5acd1-- From nobody Thu Sep 25 11:00: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 F2A231A0179 for ; Thu, 25 Sep 2014 11:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooqCYVHjSKjM for ; Thu, 25 Sep 2014 11:00:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 91E361A0084 for ; Thu, 25 Sep 2014 11:00:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 262FAC202; Thu, 25 Sep 2014 14:00:55 -0400 (EDT) Date: Thu, 25 Sep 2014 14:00:55 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140925180055.GB1239@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/B_SG9qtVGNU_xbPby9mnCu5O6zU Subject: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 25 Sep 2014 18:00:57 -0000 Your chairs have been a bit over-busy recently with travel to unicast people doing various bits of chartered work. This means we've been behind on some of our goals in terms of getting regular design sessions running. I know that at least a couple calls have happened that I've missed that Sue Hares has done, so some progress is being made. We've requested a 1 hour time slot for IETF 91 in Honolulu to give us a chance to talk. This is a call for agenda slots. This is also a call for status reports. We've had some productive discussion about requests to netmod/netconf, albeit ones that haven't converged yet. What have you been up to? -- Jeff & Ed From nobody Thu Sep 25 11:43: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 2B8E11A876B for ; Thu, 25 Sep 2014 11:43:53 -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 N8Gs3Q3a4pZe for ; Thu, 25 Sep 2014 11:43:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8391A87C3 for ; Thu, 25 Sep 2014 11:43:51 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB172.namprd05.prod.outlook.com (10.255.205.11) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 18:43:50 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 18:43:48 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 18:43:48 +0000 From: Dean Bogdanovic To: Jeffrey Haas Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OqsIg7rWvErh0yfzFNkgwd1IJwSL3EA Date: Thu, 25 Sep 2014 18:43:48 +0000 Message-ID: <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> References: <20140925180055.GB1239@pfrc> In-Reply-To: <20140925180055.GB1239@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(189002)(199003)(51704005)(83716003)(87286001)(107046002)(83072002)(88136002)(62966002)(50226001)(4396001)(101416001)(33656002)(31966008)(15975445006)(85852003)(82746002)(21056001)(57306001)(104166001)(110136001)(87936001)(89996001)(19580395003)(83322001)(19580405001)(77156001)(2656002)(99396003)(120916001)(10300001)(36756003)(76176999)(50986999)(92566001)(92726001)(97736003)(86362001)(76482002)(95666004)(105586002)(99286002)(85306004)(106356001)(106116001)(64706001)(77096002)(74502003)(80022003)(79102003)(90102001)(20776003)(81542003)(81342003)(74662003)(46102003)(66066001)(77982003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB172; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eu5bzXdoKKP585-j7KZ6pgCMVQU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 25 Sep 2014 18:43:53 -0000 Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-= routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-= 00) can be extended into data model. I'll try to submit the draft by the de= adline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draf= t-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas wrote: > Your chairs have been a bit over-busy recently with travel to unicast peo= ple > doing various bits of chartered work. This means we've been behind on so= me > of our goals in terms of getting regular design sessions running. I know > that at least a couple calls have happened that I've missed that Sue Hare= s > has done, so some progress is being made. >=20 > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us a > chance to talk. This is a call for agenda slots. >=20 > This is also a call for status reports. >=20 > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. >=20 > What have you been up to? >=20 > -- Jeff & Ed >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Sep 25 15:05: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 B31E91A19FC; Thu, 25 Sep 2014 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0JHyamudmPt; Thu, 25 Sep 2014 15:05:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E72AF1A19F8; Thu, 25 Sep 2014 15:05:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Andy Bierman'" References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> In-Reply-To: Date: Thu, 25 Sep 2014 18:04:58 -0400 Message-ID: <010d01cfd90c$bfb57950$3f206bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01CFD8EB.38A93080" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQnwIbKt3gAQ37k3kBfPWaBwKMmSaPAmFsweUA8uKOdAIOcdCJnGGeAAA= X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pfuO1bTcbD6kpkifHFr93oLJElY Cc: 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs 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: Thu, 25 Sep 2014 22:05:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010E_01CFD8EB.38A93080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: I agree that ties are really errors, and I think the architecture document tries to say that the priority is just a way to allow the first one that wins - to stay connected. You are correct - the client must have a connect and reload strategy. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, September 23, 2014 9:25 PM To: Susan Hares Cc: Jeffrey Haas; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares wrote: Andy: The concept on priority and FCFS is "if a remote client talks to an agent at a priority - then it should not be knocked out by another remote client coming later at the same priority". In my mind this is different that the boot/reboot configuration case. Do you think I am correct? Sure. I guess I am assuming each I2RS client has some reconnect-and-reload strategy. Normally, the clients will get notified when some data gets bumped or the agent restarts. Then there may be a race between the 2+ clients with same priority. IMO ties are really errors, and the operator is going to need to assign different priorities or set some config so all the clients run without data collisions. Sue Andy From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Monday, September 22, 2014 5:10 PM To: Jeffrey Haas Cc: Susan Hares; i2rs@ietf.org; netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_010E_01CFD8EB.38A93080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

I agree that ties are really errors, and I think the architecture = document tries to say that the priority is just a way to allow the first = one that wins – to stay connected.  You are correct – = the client must have a connect and reload strategy. =

 

Sue  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, September 23, 2014 9:25 = PM
To: Susan Hares
Cc: Jeffrey Haas; i2rs@ietf.org; = netmod@ietf.org
Subject: Re: [i2rs] [netmod] I2RS requests to = netmod/netconf (was netmod interim and i2rs = requirements)

 

 

 

On Tue, = Sep 23, 2014 at 5:59 PM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

The concept on priority and FCFS is “if a remote client talks = to an agent at a priority – then it should not be knocked out by = another remote client coming later at the same priority”.  In = my mind this is different that the boot/reboot configuration case.  =  Do you think I am correct?

 

 

Sure.

 

I = guess I am assuming each I2RS client has some reconnect-and-reload = strategy.

Normally, the = clients will get notified when some data gets bumped or the agent = restarts.

Then there may = be a race between the 2+ clients with same = priority.

 

IMO ties are really errors, and the operator is going = to need to assign different priorities

or set some config so all the clients run without data = collisions.

 

 

Sue

 

 

Andy

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, = September 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: = Susan Hares; i2rs@ietf.org; netmod@ietf.org
Subject: Re: [netmod] = [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs = requirements)

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Mon, Sep = 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Sue,

On = Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
> Where = does the priority live ??? in I2RS or in config module or in BGP
> = routing model?  How does this work with the three datastore = proposals: 1)
> separate empheral data store, 2) configuration = state in existing datastore
> tagged by model as empheral, and 3) = whole data stores tagged empheral,
> config, or both.  =  Is the routing code that sets the priority and handles
> the = rollback?

Priority received quite a bit of discussion during the = netmod interim.  The
reason why it was not explicitly spelled = out in my first version of the
draft is that the implementation would = vary considerably depending on which
answer netmod guided us toward = for how we get ephemeral state.

 <= /o:p>

The = rationale for the priority-based "first one wins" access = control model is still unclear

to = me.

 <= /o:p>

A simple = NACM extension to add group priority has already been = proposed,

which seems = fine to me. So is this how it works?

 <= /o:p>

  #1) = NACM data rules can be used to grant or deny access to specific I2RS = data nodes.

  =       Steps #2 and #3 assume access is granted = here

 <= /o:p>

  #2) = the I2RS agent maintains the owner and owner priority of the data = somehow.

  =        The priority is configured in each NACM group = for enforcement purposes.  

  =        This data used to decide if existing data can = be overwritten by a different client.

  =        (I think highest priority wins if target data = already exists)

 <= /o:p>

  #3) = if both writer and current owner have the same priority, then current = owner wins

 <= /o:p>

Breaking = ties by first-one-wins seems just as arbitrary as last-one-wins.  = It seems to be based on

the order = that the networking devices will boot.  Can somebody explain why it = is better?

 <= /o:p>

I am still = unclear how the operator know the exact data each = client

will want = to use, and how they determine the meaningful = overlap

(e.g. what = will break for client B if client A causes 2 of its 7 entries to be = deleted?)

 <= /o:p>

This = information seems to be required in order to configure the tie-breaking = priorities properly,

but I think = the intent is that the operator will just know what I2RS clients are = installed

and know = how to prioritize them, just based on their = purpose.

 <= /o:p>

 <= /o:p>

 <= /o:p>

It turned out = they gave us a fourth option.  I'll be summarizing that in = my
meeting minutes.  If you don't believe I've adequately = addressed it in that
writeup (coming shortly), please let me know and = we'll resume.

-- Jeff

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

____________= ___________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 <= /o:p>

 

------=_NextPart_000_010E_01CFD8EB.38A93080-- From nobody Thu Sep 25 15:26: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 5255A1A0352; Thu, 25 Sep 2014 15:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xqhzse5nCji; Thu, 25 Sep 2014 15:25:56 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C14C01A016D; Thu, 25 Sep 2014 15:25:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> In-Reply-To: <20140924071023.GF23280@elstar.local> Date: Thu, 25 Sep 2014 18:25:51 -0400 Message-ID: <012c01cfd90f$aa2fcd30$fe8f6790$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012D_01CFD8EE.23216180" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAirw7sacndAm4A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/jQ4MKqSe6g7EFDRzrinNBDCBBwY Cc: 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 22:25:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012D_01CFD8EE.23216180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juregen: Option 4 does make things easy. What happens if a particular node/variables that I2RS wants, would not normally be in the configuration? Should you configure that node in the empheral store only? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, September 24, 2014 3:10 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > Jeff: > > The fourth option is interesting and creative. A few > questions/requests: 1) How would the fourth model be expressed in the > yang model - config (empheral)? The beauty of the fourth option is that it does not require a large set of new data models. The idea is that you have a standard config data model and you use the same model for an ephemeral datastore. The server will then take the contents of the config datastore and 'merge' it with the content of any ephemeral datastores to produce what the box ends up doing (the operational state). The merging function will take priorities into account should conflicts arise. Here is the relevant figure (taken from the meeting minutes): +-----------------+ | | +--- (+) ---+ | ^ ^ v +---+ +---+ +---+ | | | | | | |(1)| | | | | | | | | | | +---+ +---+ +---+ NC config ephemeral operational datastore datastore state (1) The complete NC config datastore is at certain synchronization points made persistent (+) Priority resolution, priorities may be per datastore or per user or per 'application' or even per data node /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_012D_01CFD8EE.23216180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juregen:

 

Option = 4 does make things easy.  What happens if a particular = node/variables that I2RS wants, would not normally be in the = configuration?  Should you configure that node in the empheral = store only?

 

Sue =

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Wednesday, September 24, 2014 3:10 AM
To: = Susan Hares
Cc: 'Jeffrey Haas'; i2rs@ietf.org; = netmod@ietf.org
Subject: Re: [i2rs] [netmod] Summary of discussion = from netmod interim on i2rs requirements on netmod/netconf

 

On = Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares = wrote:

> Jeff:

>

> = The fourth option is interesting and creative. A few

> questions/requests: 1) How would the fourth = model be expressed in the

> = yang model  - config (empheral)?

 

The beauty of the = fourth option is that it does not require a large set of new data = models. The idea is that you have a standard config data model and you = use the same model for an ephemeral datastore. The server will then take = the contents of the config datastore and 'merge'

it with the content = of any ephemeral datastores to produce what the box ends up doing (the = operational state). The merging function will take priorities into = account should conflicts arise. Here is the relevant figure (taken from = the meeting minutes):

 

           &= nbsp;   +-----------------+

           &= nbsp;   = |            =      |

         +--- (+) = ---+           = |

         = ^           = ^           = v

       = +---+       = +---+       +---+

       |   = |       |   = |       |   = |

       |(1)|     =   |   |       = |   |

       |   = |       |   = |       |   = |

       = +---+       = +---+       +---+

 

     NC config  = ephemeral    operational

     datastore  = datastore      state

 

    = (1) The complete NC config datastore is at certain = synchronization

    = points made persistent

 

    = (+) Priority resolution, priorities may be per datastore or = per

    = user or per 'application' or even per data node

 

/js

 

-- =

Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

Phone: +49 421 200 = 3587         Campus Ring 1, = 28759 Bremen, Germany

Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_012D_01CFD8EE.23216180-- From nobody Thu Sep 25 16:01:25 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 914FE1A00C0; Thu, 25 Sep 2014 16:01:21 -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 UE1vEwphnGGG; Thu, 25 Sep 2014 16:01:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A346D1A00B9; Thu, 25 Sep 2014 16:01:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Martin Bjorklund'" , References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924.092658.622309529428712352.mbj@tail-f.com> In-Reply-To: <20140924.092658.622309529428712352.mbj@tail-f.com> Date: Thu, 25 Sep 2014 19:01:15 -0400 Message-ID: <017f01cfd914$9c693e70$d53bbb50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAIsC/HyAjLRcSWcoOsr0A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kC1682Fm98xwa9qk53jyhA7ArHw Cc: jhaas@pfrc.org, i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 25 Sep 2014 23:01:21 -0000 Martin: Does this mean if the I2RS model provides additional functions that are not a base configuration model that the xpath should just work? Xpath1- Config - ISIS Yang model that configures Xpath2 - I2RS ISIS empheral - inherits all the configuration state ____ I2RS ISIS actions - report on the interface changes on ISIS L1 interfaces Is my I2RS ISIS model a combination of the inherited state and the I2RS actions? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Wednesday, September 24, 2014 3:27 AM To: j.schoenwaelder@jacobs-university.de Cc: jhaas@pfrc.org; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Juergen Schoenwaelder wrote: > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > Some discussion was given to the filtering considerations. > > Extending the filtering options of the ietf-inet-types module may be appropriate. > > [Juergen, is this an action item for yang 1.1?] > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. > > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: > > The XPath expression is interpreted in the following context: > > [...] > > * The function library is the core function library. The quoted text is for the error-path. For the filter, rfc 6241 says (p 67): o The function library is the core function library, plus any functions defined by the data model. /martin _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Sep 25 17:57: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 A27BB1A01D8 for ; Thu, 25 Sep 2014 17:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 2BlQtfU_5CUF for ; Thu, 25 Sep 2014 17:57:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413D21A0185 for ; Thu, 25 Sep 2014 17:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20631; q=dns/txt; s=iport; t=1411693044; x=1412902644; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aeEHWV4+iDUB8jjgFbakJV28IGhBqKZ+LEJoP3m5pUk=; b=VOnQPCnsLSPjK3fRvO3KuoxZrApuaJbSGp+e2P5pMrq3AnUoykrWbZxf /KfAc7dglrFTqmyq5racxALXcOuo2zEFxnbIc0NBbaWUORcTrHzPkUB19 3ye5ut23Y21KSwDfLySgtiJOz0lobpuJbsXMK4iJg+LSAYV6U7NlfcK20 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAG65JFStJV2a/2dsb2JhbABggkhGU1cEyjOHTAKBAxYBe4QDAQEBBC06EhACAQgRBAEBAQodBzIUCQgCBAENBQgBiDUNwWUBF486MzEGAYMugR0Fj0iCGKEZg2NsAYEFQoECAQEB X-IronPort-AV: E=Sophos;i="5.04,601,1406592000"; d="scan'208,217";a="358299750" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2014 00:57:22 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q0vLY4019328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 00:57:21 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 19:57:21 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [i2rs] Two thoughts on an ephemeral data store Thread-Index: AQHP2AyNNGxq3WM56UegT3gsiRt8HpwR+uyAgABARYCAAAVsgIAAEjgAgAA6FGA= Date: Fri, 26 Sep 2014 00:57:20 +0000 Message-ID: References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.66.35] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C8071ECxmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/umGhwsxwJLWqfdFSCs3Um21oHlo Cc: Jeffrey Haas , "i2rs@ietf.org" , "Eric Voit \(evoit\)" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 00:57:27 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C8071ECxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, I would think the semantics should be kept simple. The complexity here comes from the fact that there are dependencies between= different data stores, and some objects that are part of one data store ne= ed to be reflected in a different data store. It would seem this can be addressed with two fairly simple principles: (a) A datastore needs to have a clear way to reference objects in a diff= erent datastore, really have them incorporated into the same namespace. (b) It needs to be clear who owns the "golden copy" of an object. I need= s to be clear which objects are "authoritatively owned" by a datastore vs w= hich ones are reference. This is the datastore where the object is maintai= ned, updated, created; this is where conditions and constraints are evaluat= ed, etc. Where an ephemeral datastore has dependencies on data in another datastore,= it should incorporate these other objects "by reference". The objects tha= t are authoritatively owned by the ephemeral datastore can refer to those o= bjects, have them referred to in conditions and constraints, and so on. (T= his can also indicate which ephemeral objects are to be removed when an obj= ect in the other datastore they depend on is deleted, etc) Changes to the non-ephemeral objects (e.g. the running datastore) have to b= e made to the "golden copy", i.e. the owning datastore. One way to do that= involves implementing a "write-through" operation, in which an update to a= n ephemeral copy of the object is realized by having the server of the ephe= meral datastore turn around and make a corresponding request at the other d= atastore. Very simple semantics. I think this is preferrable to have different copie= s of the same object in different datastores, requiring "logical anding" (o= r other inter-datastore arithmetic) of different copies representing the sa= me object to figure out what actual value is in effect, etc. In the netmod WG, we have today posted a draft for what we refer to as requ= irements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-n= etmod-peer-mount-requirements-00.txt), motivating why a it would be useful = to have a capability to "mount" subtrees from a remote datastore into a loc= al datastore, and the requirements that such a capability needs to address.= While the original use case and motivation described there are somewhat d= ifferent, it seems applicable to the discussion here. --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, September 25, 2014 8:44 AM To: Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund > wrote: Jeffrey Haas > wrote: > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > Jeffrey Haas > wrote: > > > In the proposed overlay model, presume that we have ephemeral data fr= om a > > > model that lives within an augmentation to a local config model. In = other > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > Presume, per discussion, that the local config lives in the "config" = data > > > store and that the ephemeral config - the augmenting nodes above - li= ve in > > > the ephemeral data store. > > > > > > If we delete the container in the local config that the epehemeral co= nfig is > > > augmenting, is there any expectation that such a deletion should carr= y > > > through to the ephemeral config? > > > > > > Per the netmod interim discussion, probably not. > > > > My interpretation of the interim discussion is that the deletion > > carries through. > > To be clear what I meant, consider: > > local config: ephemeral: > A A/B - B is introduced as an augmentation of A I think there might be a terminology confusion here, so let's do a simple example. list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=3D42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. What happens if we in local config delete foo 42? If /foo[id=3D42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps? Yes -- and what is presented to a client that retrieves the ephemeral confi= g in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephem= eral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as= local config when the device restarts (or the ephemeral state is removed). It should no= t change the injected I2RS state at all. IMO it is really important that edits stay= within a single datastore. /martin Andy --_000_DBC595ED2346914F9F81D17DD5C32B571C8071ECxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW, I would think the s= emantics should be kept simple. 

 <= /p>

The complexity here comes= from the fact that there are dependencies between different data stores, a= nd some objects that are part of one data store need to be reflected in a different data store. 

 <= /p>

It would seem this can be= addressed with two fairly simple principles:

(a)&nbs= p;   A datastore needs= to have a clear way to reference objects in a different datastore, really = have them incorporated into the same namespace. 

(b)&nbs= p;  It needs to be cl= ear who owns the “golden copy” of an object.  I needs to b= e clear which objects are “authoritatively owned” by a datastor= e vs which ones are reference.  This is the datastore where the object is mainta= ined, updated, created; this is where conditions and constraints are evalua= ted, etc. 

 <= /p>

Where an ephemeral datast= ore has dependencies on data in another datastore, it should incorporate th= ese other objects “by reference”.  The objects that are authoritatively owned by the ephemeral datastore can refer to those object= s, have them referred to in conditions and constraints, and so on.  (T= his can also indicate which ephemeral objects are to be removed when an obj= ect in the other datastore they depend on is deleted, etc)

 <= /p>

Changes to the non-epheme= ral objects (e.g. the running datastore) have to be made to the “gold= en copy”, i.e. the owning datastore.  One way to do that involve= s implementing a “write-through” operation, in which an update t= o an ephemeral copy of the object is realized by having the server of the e= phemeral datastore turn around and make a corresponding request at the othe= r datastore. 

 <= /p>

Very simple semantics.&nb= sp; I think this is preferrable to have different copies of the same object= in different datastores, requiring “logical anding” (or other inter-datastore arithmetic) of different copies representing the same obje= ct to figure out what actual value is in effect, etc. 

 <= /p>

In the netmod WG, we have= today posted a draft for what we refer to as requirements for a peer mount= (http://www.ietf.org/internet-drafts/draft-vo= it-netmod-peer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to “mount&#= 8221; subtrees from a remote datastore into a local datastore, and the requ= irements that such a capability needs to address.  While the original = use case and motivation described there are somewhat different, it seems applicable to the discussion here. 

 <= /p>

--- Alex

 <= /p>

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, September 25, 2014 8:44 AM
To: Martin Bjorklund
Cc: Jeffrey Haas; i2rs@ietf.org
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

 

 

 

On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:

Jeffrey Haas <j= haas@pfrc.org> wrote:
> On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:<= br> > > Jeffrey Haas <jhaas@pfrc.org= > wrote:
> > > In the proposed overlay model, presume that we have ephemera= l data from a
> > > model that lives within an augmentation to a local config mo= del.  In other
> > > words, the ephemeral nodes are children of the local config = nodes.
> > >
> > > Presume, per discussion, that the local config lives in the = "config" data
> > > store and that the ephemeral config - the augmenting nodes a= bove - live in
> > > the ephemeral data store.
> > >
> > > If we delete the container in the local config that the epeh= emeral config is
> > > augmenting, is there any expectation that such a deletion sh= ould carry
> > > through to the ephemeral config?
> > >
> > > Per the netmod interim discussion, probably not.
> >
> > My interpretation of the interim discussion is that the deletion<= br> > > carries through.
>
> To be clear what I meant, consider:
>
> local config:      ephemeral:
> A                  A/B - = B is introduced as an augmentation of A

I think there might be a terminology confusion here, so let's do a
simple example.

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

In ephemeral config we now do SET /foo[id=3D42]/a  to 4711.  Thus= , in
ephemeral we now have a single node (a) with value 4711.

What happens if we in local config delete foo 42?

If /foo[id=3D42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps?

 

 

Yes -- and what is presented to a client that retrie= ves the ephemeral config

in a GET request? IMO, coupling the datastores does = not make sense.

 

Your example is 1 reason I prefer the "shadow s= hapshot" approach.

I think the local config and client that added the &= quot;foo" entry in the ephemeral datastore

are meant to have different priorities.  The en= tries are not coupled.

One wins and the other loses (main use-case is that = ephemeral wins).

 

Editing "foo 42" in the local config just = changes what will be installed as local config

when the device restarts (or the ephemeral state is = removed).  It should not change

the injected I2RS state at all.  IMO it is real= ly important that edits stay within a single

datastore.

 

 



/martin

 

Andy

 

--_000_DBC595ED2346914F9F81D17DD5C32B571C8071ECxmbrcdx05ciscoc_-- From nobody Thu Sep 25 23:44:08 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 685F21A1A43; Thu, 25 Sep 2014 23:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtDwCMrq8xft; Thu, 25 Sep 2014 23:44:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 39B741A1A32; Thu, 25 Sep 2014 23:44:01 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C9B91280474; Fri, 26 Sep 2014 08:44:00 +0200 (CEST) Date: Fri, 26 Sep 2014 08:43:59 +0200 (CEST) Message-Id: <20140926.084359.2189946003061989153.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <017f01cfd914$9c693e70$d53bbb50$@ndzh.com> References: <20140924070025.GD23280@elstar.local> <20140924.092658.622309529428712352.mbj@tail-f.com> <017f01cfd914$9c693e70$d53bbb50$@ndzh.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/v5a560Apdv8niKWt3BA4aXCit1o Cc: jhaas@pfrc.org, i2rs@ietf.org, j.schoenwaelder@jacobs-university.de, netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 26 Sep 2014 06:44:03 -0000 "Susan Hares" wrote: > Martin: > > Does this mean if the I2RS model provides additional functions that are not > a base configuration model that the xpath should just work? It means that the protocol specification does not lock down the set of XPath functions available in a filter. However, there is no standard way currently to declare new XPath functions in YANG data models. (see the expired https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 for some ideas in this area). (For the set of core XPath functions see http://www.w3.org/TR/xpath/#corelib) /martin > Xpath1- Config - ISIS Yang model that configures > Xpath2 - I2RS ISIS empheral - inherits all the configuration state > ____ I2RS ISIS actions - report on the interface changes on ISIS > L1 interfaces > > Is my I2RS ISIS model a combination of the inherited state and the I2RS > actions? > > Sue > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, September 24, 2014 3:27 AM > To: j.schoenwaelder@jacobs-university.de > Cc: jhaas@pfrc.org; i2rs@ietf.org; netmod@ietf.org > Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on > i2rs requirements on netmod/netconf > > Juergen Schoenwaelder wrote: > > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > > Some discussion was given to the filtering considerations. > > > Extending the filtering options of the ietf-inet-types module may be > appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > > > Now, this mostly is about the xpath function set that can be used in > > must and when expressions. You probably want to use them also in > > filtering expressions in the protocol. This is where things again > > become a protocol issues. Note that RFC 6241 says on page 17: > > > > The XPath expression is interpreted in the following context: > > > > [...] > > > > * The function library is the core function library. > > The quoted text is for the error-path. For the filter, rfc 6241 says (p > 67): > > o The function library is the core function library, plus any > functions defined by the data model. > > > /martin > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri Sep 26 08:30: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 4228B1A701A for ; Fri, 26 Sep 2014 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VShG4HgOj1gz for ; Fri, 26 Sep 2014 08:30:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E9D961A6FED for ; Fri, 26 Sep 2014 08:30:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Alexander Clemm \(alex\)'" , "'Andy Bierman'" , "'Martin Bjorklund'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> In-Reply-To: Date: Fri, 26 Sep 2014 11:30:00 -0400 Message-ID: <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027A_01CFD97D.36074820" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHoMTP8chsklMLfoVKSkSiC97qaUgH4M+fGAYZnjisBptWYPwIGj9ikAeIyNrObmmXAIA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DP7r_91kYV1YXSP61uVt3guEf_g Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Eric Voit \(evoit\)'" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 15:30:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_027A_01CFD97D.36074820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alexander: To help me understand your proposal, let us move to the previous example: Previous example: list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. Your model: a) The value 4711 - would be a "non-golden" copy. b) It would not be written through to the the "golden copy". Questions: a) How would you specify a "write-through" copy? b) Can I2RS decide later it wants to write-through the golden copy? Or are variables only "non-write-through" and "write-through"? c) If we delete foo 42, what happens? Thank you, Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) Sent: Thursday, September 25, 2014 8:57 PM To: Andy Bierman; Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) Subject: Re: [i2rs] Two thoughts on an ephemeral data store FWIW, I would think the semantics should be kept simple. The complexity here comes from the fact that there are dependencies between different data stores, and some objects that are part of one data store need to be reflected in a different data store. It would seem this can be addressed with two fairly simple principles: (a) A datastore needs to have a clear way to reference objects in a different datastore, really have them incorporated into the same namespace. (b) It needs to be clear who owns the "golden copy" of an object. I needs to be clear which objects are "authoritatively owned" by a datastore vs which ones are reference. This is the datastore where the object is maintained, updated, created; this is where conditions and constraints are evaluated, etc. Where an ephemeral datastore has dependencies on data in another datastore, it should incorporate these other objects "by reference". The objects that are authoritatively owned by the ephemeral datastore can refer to those objects, have them referred to in conditions and constraints, and so on. (This can also indicate which ephemeral objects are to be removed when an object in the other datastore they depend on is deleted, etc) Changes to the non-ephemeral objects (e.g. the running datastore) have to be made to the "golden copy", i.e. the owning datastore. One way to do that involves implementing a "write-through" operation, in which an update to an ephemeral copy of the object is realized by having the server of the ephemeral datastore turn around and make a corresponding request at the other datastore. Very simple semantics. I think this is preferrable to have different copies of the same object in different datastores, requiring "logical anding" (or other inter-datastore arithmetic) of different copies representing the same object to figure out what actual value is in effect, etc. In the netmod WG, we have today posted a draft for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requiremen ts-00.txt), motivating why a it would be useful to have a capability to "mount" subtrees from a remote datastore into a local datastore, and the requirements that such a capability needs to address. While the original use case and motivation described there are somewhat different, it seems applicable to the discussion here. --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, September 25, 2014 8:44 AM To: Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund wrote: Jeffrey Haas wrote: > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > Jeffrey Haas wrote: > > > In the proposed overlay model, presume that we have ephemeral data from a > > > model that lives within an augmentation to a local config model. In other > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > Presume, per discussion, that the local config lives in the "config" data > > > store and that the ephemeral config - the augmenting nodes above - live in > > > the ephemeral data store. > > > > > > If we delete the container in the local config that the epehemeral config is > > > augmenting, is there any expectation that such a deletion should carry > > > through to the ephemeral config? > > > > > > Per the netmod interim discussion, probably not. > > > > My interpretation of the interim discussion is that the deletion > > carries through. > > To be clear what I meant, consider: > > local config: ephemeral: > A A/B - B is introduced as an augmentation of A I think there might be a terminology confusion here, so let's do a simple example. list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. What happens if we in local config delete foo 42? If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps? Yes -- and what is presented to a client that retrieves the ephemeral config in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephemeral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as local config when the device restarts (or the ephemeral state is removed). It should not change the injected I2RS state at all. IMO it is really important that edits stay within a single datastore. /martin Andy ------=_NextPart_000_027A_01CFD97D.36074820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alexander: =

 

To help me = understand your proposal, let us move to the previous example: =

 

Previous example: =

 

  list foo {
    key id;
    leaf = id { type int32; }
    leaf a { type int32; }
  = }

local config:

   foo = 42

 

In ephemeral config = we now do SET /foo[id=3D42]/a  to 4711.  Thus, in
ephemeral = we now have a single node (a) with value 4711.

 

Your = model:

a)  The value 4711 = – would be a “non-golden” copy.

b)  It would not be = written through to the the “golden copy”.

 

Questions: =

a)  How would you = specify a “write-through” copy?

b)  Can I2RS decide = later it wants to write-through the golden copy?  Or are variables = only “non-write-through” and = “write-through”?

c)  If we delete foo = 42, what happens?

 

Thank = you,

Sue Hares =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm = (alex)
Sent: Thursday, September 25, 2014 8:57 = PM
To: Andy Bierman; Martin Bjorklund
Cc: Jeffrey = Haas; i2rs@ietf.org; Eric Voit (evoit)
Subject: Re: [i2rs] Two = thoughts on an ephemeral data store

 

FWIW, I would think the semantics should be kept simple.  =

 

The complexity here comes from the fact that there are dependencies = between different data stores, and some objects that are part of one = data store need to be reflected in a different data store.  =

 

It would seem this can be addressed with two fairly simple = principles:

(a)    A datastore needs to have a clear way to reference objects in a = different datastore, really have them incorporated into the same = namespace. 

(b)   It needs to be clear who owns the “golden copy” of an = object.  I needs to be clear which objects are = “authoritatively owned” by a datastore vs which ones are = reference.  This is the datastore where the object is maintained, = updated, created; this is where conditions and constraints are = evaluated, etc. 

 

Where an ephemeral datastore has dependencies on data in another = datastore, it should incorporate these other objects “by = reference”.  The objects that are authoritatively owned by = the ephemeral datastore can refer to those objects, have them referred = to in conditions and constraints, and so on.  (This can also = indicate which ephemeral objects are to be removed when an object in the = other datastore they depend on is deleted, etc)

 

Changes to the non-ephemeral objects (e.g. the running datastore) = have to be made to the “golden copy”, i.e. the owning = datastore.  One way to do that involves implementing a = “write-through” operation, in which an update to an = ephemeral copy of the object is realized by having the server of the = ephemeral datastore turn around and make a corresponding request at the = other datastore. 

 

Very simple semantics.  I think this is preferrable to have = different copies of the same object in different datastores, requiring = “logical anding” (or other inter-datastore arithmetic) of = different copies representing the same object to figure out what actual = value is in effect, etc. 

 

In the netmod WG, we have today posted a draft for what we refer to = as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmo= d-peer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to = “mount” subtrees from a remote datastore into a local = datastore, and the requirements that such a capability needs to = address.  While the original use case and motivation described = there are somewhat different, it seems applicable to the discussion = here. 

 

--- Alex

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Andy Bierman
Sent: Thursday, September 25, = 2014 8:44 AM
To: Martin Bjorklund
Cc: Jeffrey Haas; = i2rs@ietf.org
Subject: = Re: [i2rs] Two thoughts on an ephemeral data = store

 

 

 

On Thu, = Sep 25, 2014 at 7:39 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Jeffrey Haas <jhaas@pfrc.org> wrote:
> On = Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
> = > Jeffrey Haas <jhaas@pfrc.org> wrote:
> = > > In the proposed overlay model, presume that we have ephemeral = data from a
> > > model that lives within an augmentation to = a local config model.  In other
> > > words, the = ephemeral nodes are children of the local config nodes.
> > = >
> > > Presume, per discussion, that the local config = lives in the "config" data
> > > store and that = the ephemeral config - the augmenting nodes above - live in
> > = > the ephemeral data store.
> > >
> > > If we = delete the container in the local config that the epehemeral config = is
> > > augmenting, is there any expectation that such a = deletion should carry
> > > through to the ephemeral = config?
> > >
> > > Per the netmod interim = discussion, probably not.
> >
> > My interpretation of = the interim discussion is that the deletion
> > carries = through.
>
> To be clear what I meant, = consider:
>
> local config:      = ephemeral:
> A              =     A/B - B is introduced as an augmentation of A

I = think there might be a terminology confusion here, so let's do = a
simple example.

  list foo {
    key = id;
    leaf id { type int32; }
    leaf a { = type int32; }
  }

local config:

   foo = 42

In ephemeral config we now do SET /foo[id=3D42]/a  to = 4711.  Thus, in
ephemeral we now have a single node (a) with = value 4711.

What happens if we in local config delete foo = 42?

If /foo[id=3D42]/a is NOT deleted from the ephemeral config, = what is now
presented to the internal apps?

 

 

Yes -- and what is presented to a client that = retrieves the ephemeral config

in a GET request? IMO, coupling the datastores does = not make sense.

 

Your example is 1 reason I prefer the "shadow = shapshot" approach.

I = think the local config and client that added the "foo" entry = in the ephemeral datastore

are meant to have different priorities.  The = entries are not coupled.

One wins and the other loses (main use-case is that = ephemeral wins).

 

Editing "foo 42" in the local config just = changes what will be installed as local = config

when the device = restarts (or the ephemeral state is removed).  It should not = change

the injected I2RS = state at all.  IMO it is really important that edits stay within a = single

datastore.

 

 



/martin

 

Andy

 

------=_NextPart_000_027A_01CFD97D.36074820-- From nobody Fri Sep 26 08:59: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 D01CC1A8F38 for ; Fri, 26 Sep 2014 08:59: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 xCjlg4k35nHB for ; Fri, 26 Sep 2014 08:59:24 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01E81A9116 for ; Fri, 26 Sep 2014 08:55:40 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id ij19so7869545vcb.30 for ; Fri, 26 Sep 2014 08:55:39 -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=bKPeT10sZdzbt7BYFRQ2aPkqDCQR+lOQJqSkgJ8qO7k=; b=PzDPjJcAhh8LCG11i7QH4eMlPmLwjMZS45NxwFPtXSUoHDD9CBQBlD6OoYrtzVi/yK Zvb2ICgtSQCf654HAD3X+geeIyoVI/iKVV/qVszWoXWoemnoV9DSUi4KzKc20fHoS3NI c5lmJ9hO9DIs4sA16bZRDcOV66DgJGuoKZx4+5Lholdc4GOpfwyGJAYlGftaz2sIODfG k8ogxxiuEJauB97q+oPM+3P0o8rj4SqadOdCfXRMKg2P1CRoE8fK5ba4HFCpFH2gT6eq VTnrRLf8N0b3XmMY6/wCpVj2Nw2NWls5ne1AqHuw+wDuWeL2EUYE3oE/Zz4EXp4Q8xC7 QQIQ== X-Gm-Message-State: ALoCoQnF+dnWiKIi5aToxHXM+0eHFeg62E3off7JBb4TceHaQ+yMRfrMlRF7qVAXZPEHDgQrdTtu MIME-Version: 1.0 X-Received: by 10.220.144.8 with SMTP id x8mr527282vcu.47.1411746939867; Fri, 26 Sep 2014 08:55:39 -0700 (PDT) Received: by 10.31.168.200 with HTTP; Fri, 26 Sep 2014 08:55:39 -0700 (PDT) In-Reply-To: <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> Date: Fri, 26 Sep 2014 08:55:39 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=047d7b3430d4dd2a0a0503f9f2b6 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ESWHrKMkct1rHlWeI-9vKLrcN_A Cc: Jeffrey Haas , "i2rs@ietf.org" , "Alexander Clemm \(alex\)" , Martin Bjorklund , "Eric Voit \(evoit\)" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 15:59:29 -0000 --047d7b3430d4dd2a0a0503f9f2b6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 26, 2014 at 8:30 AM, Susan Hares wrote: > Alexander: > > > > To help me understand your proposal, let us move to the previous example: > > > > Previous example: > > > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > > So in this "foo 42" step, you are assuming that the NETCONF or RESTCONF client told the NETCONF or RESTCONF server that the edit to the local config is supposed to be copied to the ephemeral datastore? So modifications to those protocols to edit multiple datastores at once will be needed? (Your Q (a) below) So we are assuming the 2 datastores are in sync so concurrent edits are feasible? > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > > > You have this only if the previous step copied "foo 42". You cannot create a child node unless the parent exists or is also getting created. If you delete a node, the entire subtree (the XPath descendant-or-self axis) is deleted. I hope the various plans to couple the running and ephemeral datastores do not try to violate these rules. Andy Your model: > > a) The value 4711 - would be a "non-golden" copy. > > b) It would not be written through to the the "golden copy". > > > > Questions: > > a) How would you specify a "write-through" copy? > > b) Can I2RS decide later it wants to write-through the golden copy? Or > are variables only "non-write-through" and "write-through"? > > c) If we delete foo 42, what happens? > > > > Thank you, > > Sue Hares > > > Andy > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Alexander > Clemm (alex) > *Sent:* Thursday, September 25, 2014 8:57 PM > *To:* Andy Bierman; Martin Bjorklund > *Cc:* Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) > *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store > > > > FWIW, I would think the semantics should be kept simple. > > > > The complexity here comes from the fact that there are dependencies > between different data stores, and some objects that are part of one data > store need to be reflected in a different data store. > > > > It would seem this can be addressed with two fairly simple principles: > > (a) A datastore needs to have a clear way to reference objects in a > different datastore, really have them incorporated into the same > namespace. > > (b) It needs to be clear who owns the "golden copy" of an object. I > needs to be clear which objects are "authoritatively owned" by a datastore > vs which ones are reference. This is the datastore where the object is > maintained, updated, created; this is where conditions and constraints are > evaluated, etc. > > > > Where an ephemeral datastore has dependencies on data in another > datastore, it should incorporate these other objects "by reference". The > objects that are authoritatively owned by the ephemeral datastore can refer > to those objects, have them referred to in conditions and constraints, and > so on. (This can also indicate which ephemeral objects are to be removed > when an object in the other datastore they depend on is deleted, etc) > > > > Changes to the non-ephemeral objects (e.g. the running datastore) have to > be made to the "golden copy", i.e. the owning datastore. One way to do > that involves implementing a "write-through" operation, in which an update > to an ephemeral copy of the object is realized by having the server of the > ephemeral datastore turn around and make a corresponding request at the > other datastore. > > > > Very simple semantics. I think this is preferrable to have different > copies of the same object in different datastores, requiring "logical > anding" (or other inter-datastore arithmetic) of different copies > representing the same object to figure out what actual value is in effect, > etc. > > > > In the netmod WG, we have today posted a draft for what we refer to as > requirements for a peer mount ( > http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt), > motivating why a it would be useful to have a capability to "mount" > subtrees from a remote datastore into a local datastore, and the > requirements that such a capability needs to address. While the original > use case and motivation described there are somewhat different, it seems > applicable to the discussion here. > > > > --- Alex > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org ] *On > Behalf Of *Andy Bierman > *Sent:* Thursday, September 25, 2014 8:44 AM > *To:* Martin Bjorklund > *Cc:* Jeffrey Haas; i2rs@ietf.org > *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store > > > > > > > > On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund wrote: > > Jeffrey Haas wrote: > > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > > Jeffrey Haas wrote: > > > > In the proposed overlay model, presume that we have ephemeral data > from a > > > > model that lives within an augmentation to a local config model. In > other > > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > > > Presume, per discussion, that the local config lives in the "config" > data > > > > store and that the ephemeral config - the augmenting nodes above - > live in > > > > the ephemeral data store. > > > > > > > > If we delete the container in the local config that the epehemeral > config is > > > > augmenting, is there any expectation that such a deletion should > carry > > > > through to the ephemeral config? > > > > > > > > Per the netmod interim discussion, probably not. > > > > > > My interpretation of the interim discussion is that the deletion > > > carries through. > > > > To be clear what I meant, consider: > > > > local config: ephemeral: > > A A/B - B is introduced as an augmentation of A > > I think there might be a terminology confusion here, so let's do a > simple example. > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > > What happens if we in local config delete foo 42? > > If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now > presented to the internal apps? > > > > > > Yes -- and what is presented to a client that retrieves the ephemeral > config > > in a GET request? IMO, coupling the datastores does not make sense. > > > > Your example is 1 reason I prefer the "shadow shapshot" approach. > > I think the local config and client that added the "foo" entry in the > ephemeral datastore > > are meant to have different priorities. The entries are not coupled. > > One wins and the other loses (main use-case is that ephemeral wins). > > > > Editing "foo 42" in the local config just changes what will be installed > as local config > > when the device restarts (or the ephemeral state is removed). It should > not change > > the injected I2RS state at all. IMO it is really important that edits > stay within a single > > datastore. > > > > > > > > /martin > > > > Andy > > > --047d7b3430d4dd2a0a0503f9f2b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 26, 2014 at 8:30 AM, Susan Hares <shares@ndzh.com> wrote:

Alexander:

 

To he= lp me understand your proposal, let us move to the previous example:

 

Previous example:

=  

  list foo {=
    key id;
    leaf id { type int32; }
 = ;   leaf a { type int32; }
  }

local config:

&nb= sp;  foo 42

 



So in th= is "foo 42" step, you are assuming that the NETCONF or RESTCONF c= lient
told the NETCONF or RESTCONF server that the edit to the lo= cal config is supposed
to be copied to the ephemeral datastore?&n= bsp; So modifications to those protocols
to edit multiple datasto= res at once will be needed? (Your Q (a) below)
So we are assuming= the 2 datastores are in sync so concurrent edits are feasible?
&= nbsp;

= In ephemeral config we now do SET /foo[id=3D42]/a  to 4711.  Thus= , in
ephemeral we now have a single node (a) with value 4711.<= /u>

 


You have this only if the previous step copied &qu= ot;foo 42".
You cannot create a child node unless the parent= exists or is also getting created.
If you delete a node, the ent= ire subtree (the XPath descendant-or-self axis) is deleted.
I hop= e the various plans to couple the running and ephemeral datastores do not
try to violate these rules.


Andy

Your model:

a)  <= u>= The value 4711 – would be a “non-golden” copy.

b)  = It= would not be written through to the the “golden copy”.

<= /u> 

Questions:

a)&nb= sp; How would you specify a “write-through&rdqu= o; copy?

b)  Can I2RS decide late= r it wants to write-through the golden copy?  Or are variables only &l= dquo;non-write-through” and “write-through”?

c)  If we delete foo 42, what happens? =

 

Thank you,

Sue Hares <= /u>

<= /u> 


Andy
=
 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of A= lexander Clemm (alex)
Sent: Thursday, September 25, 2014 8:57 PM<= br>To: Andy Bierman; Martin Bjorklund
Cc: Jeffrey Haas; i2rs@ietf.org; Eric Vo= it (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data = store

&nb= sp;

FWIW, I wou= ld think the semantics should be kept simple. 

 

The complexity he= re comes from the fact that there are dependencies between different data s= tores, and some objects that are part of one data store need to be reflecte= d in a different data store. 

 

It would seem this can be address= ed with two fairly simple principles:

(a)    A datastore needs to have a clear way to reference objects in a= different datastore, really have them incorporated into the same namespace= . 

(b)   It needs to be clear wh= o owns the “golden copy” of an object.  I needs to be clea= r which objects are “authoritatively owned” by a datastore vs w= hich ones are reference.  This is the datastore where the object is ma= intained, updated, created; this is where conditions and constraints are ev= aluated, etc. 

 

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Where an ephemeral datastore has dependencies on = data in another datastore, it should incorporate these other objects &ldquo= ;by reference”.  The objects that are authoritatively owned by t= he ephemeral datastore can refer to those objects, have them referred to in= conditions and constraints, and so on.  (This can also indicate which= ephemeral objects are to be removed when an object in the other datastore = they depend on is deleted, etc)

 

Changes to the non-ephemeral objects (= e.g. the running datastore) have to be made to the “golden copy&rdquo= ;, i.e. the owning datastore.  One way to do that involves implementin= g a “write-through” operation, in which an update to an ephemer= al copy of the object is realized by having the server of the ephemeral dat= astore turn around and make a corresponding request at the other datastore.=  

 

Very simple semantics.  I think this is preferrable to ha= ve different copies of the same object in different datastores, requiring &= ldquo;logical anding” (or other inter-datastore arithmetic) of differ= ent copies representing the same object to figure out what actual value is = in effect, etc. 

 

In the netmod WG, we have today posted a draft = for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-n= etmod-peer-mount-requirements-00.txt), motiv= ating why a it would be useful to have a capability to “mount” = subtrees from a remote datastore into a local datastore, and the requiremen= ts that such a capability needs to address.  While the original use ca= se and motivation described there are somewhat different, it seems applicab= le to the discussion here. 

 

--- Alex

 <= /p>

From: i2rs = [mailto:i2rs-bou= nces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursda= y, September 25, 2014 8:44 AM
To: Martin Bjorklund
Cc: = Jeffrey Haas; i2rs@ietf.= org
Subject: Re: [i2rs] Two thoughts on an ephemeral data sto= re

 

<= div>

 

 

On Thu, Sep 25, 201= 4 at 7:39 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Thu, Sep 25, 2014 at 12:29:35PM += 0200, Martin Bjorklund wrote:
> > Jeffrey Haas <jhaas@pfrc.org> wrote:
> = > > In the proposed overlay model, presume that we have ephemeral dat= a from a
> > > model that lives within an augmentation to a loc= al config model.  In other
> > > words, the ephemeral node= s are children of the local config nodes.
> > >
> > &g= t; Presume, per discussion, that the local config lives in the "config= " data
> > > store and that the ephemeral config - the aug= menting nodes above - live in
> > > the ephemeral data store.> > >
> > > If we delete the container in the local = config that the epehemeral config is
> > > augmenting, is there= any expectation that such a deletion should carry
> > > throug= h to the ephemeral config?
> > >
> > > Per the netm= od interim discussion, probably not.
> >
> > My interpret= ation of the interim discussion is that the deletion
> > carries t= hrough.
>
> To be clear what I meant, consider:
>
>= local config:      ephemeral:
> A     =             A/B - B is introduced as an augm= entation of A

I think there might be a terminology confusion here, s= o let's do a
simple example.

  list foo {
  &nbs= p; key id;
    leaf id { type int32; }
    leaf a= { type int32; }
  }

local config:

   foo 4= 2

In ephemeral config we now do SET /foo[id=3D42]/a  to 4711.&n= bsp; Thus, in
ephemeral we now have a single node (a) with value 4711.
What happens if we in local config delete foo 42?

If /foo[id= =3D42]/a is NOT deleted from the ephemeral config, what is now
presented= to the internal apps?

=  

 

=

Yes -- and what is presented to a client = that retrieves the ephemeral config

in a GET request? IMO, coupling the datastores does not make se= nse.

 

Your example is 1 reason I prefer th= e "shadow shapshot" approach.

I think the local config and client that added the "fo= o" entry in the ephemeral datastore

are meant to have different priorities.  The entries = are not coupled.

One win= s and the other loses (main use-case is that ephemeral wins).=

 

Editing "foo 42" in the local config just ch= anges what will be installed as local config

when the device restarts (or the ephemeral state is re= moved).  It should not change

the injected I2RS state at all.  IMO it is really important= that edits stay within a single

datastore.

<= /u> 

 <= /p>



/martin=

 

=

Andy

 


--047d7b3430d4dd2a0a0503f9f2b6-- From nobody Fri Sep 26 09:21: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 6C8D01A8A7F; Fri, 26 Sep 2014 09:21:11 -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 eZUa3SUgkGxc; Fri, 26 Sep 2014 09:21:10 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2F7D1A8A88; Fri, 26 Sep 2014 09:20:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Jeffrey Haas'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <20140925062456.GB26200@elstar.local> In-Reply-To: <20140925062456.GB26200@elstar.local> Date: Fri, 26 Sep 2014 12:20:15 -0400 Message-ID: <02ce01cfd9a5$c1e81f40$45b85dc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAirw7sYBPQLsZQJvt0DrAf4qT3uccaV38A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/BaA79PTr72trwijx3fTG28tHbh0 Cc: "'Thomas D. Nadeau'" , netmod@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 26 Sep 2014 16:21:12 -0000 Juregen and Jeff: Can you define what a merge is? Could you define it using the example below and another one? I know you have talked around the subject, but I need another examples so I can adjust the drafts in progress with co-authors (ISIS IM-DM, OSPF IM-DM, BGP IM-DM, PBR IM/DM) for i2rs. Sue ============ list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, September 25, 2014 2:25 AM To: Jeffrey Haas Cc: Thomas D. Nadeau; i2rs@ietf.org; Susan Hares; netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf On Wed, Sep 24, 2014 at 11:34:01AM -0400, Jeffrey Haas wrote: > On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > > On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: > [...] > > > > > > +-----------------+ > > > | | > > > +--- (+) ---+ | > > > ^ ^ v > > > +---+ +---+ +---+ > > > | | | | | | > > > |(1)| | | | | > > > | | | | | | > > > +---+ +---+ +---+ > > > > > > NC config ephemeral operational > > > datastore datastore state > > > > > > (1) The complete NC config datastore is at certain synchronization > > > points made persistent > > > > > > (+) Priority resolution, priorities may be per datastore or per > > > user or per 'application' or even per data node > > > > These are precisely the qualities I and some others were thinking of when we started i2rs. The idea is quite simple, as you have said above and really needs not be complicated more. > > It has its own complications. > > Do we permit more than one ephemeral datastore? If so, this > simplifies data object priority when resolving the operational state. > But this also complicates operational state integrity when you have > multiple cross references. It complicates the merge operation - it does not affect the integrity of the operational state. But even that may not be true, at least not from the point of the merge algorithm. There likely is not much difference between merging 1 or N ephemeral datastores. And at the end of the day, if you have I2RS systems injecting conflicts, then it does not matter whether that happens in 1 ephemeral datastore and N ephemeral datastores. Having N ephemeral datastores had the advantage that I can easily disable a complete ephemeral datastore by modifying its priority while multiple I2RS systems writing concurrently into the same scratchpad will be much more fun to deal with. /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 Sep 26 09:23: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 3EDAC1A8A1D; Fri, 26 Sep 2014 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjDU6gw7s_ab; Fri, 26 Sep 2014 09:23:25 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2611A8A8A; Fri, 26 Sep 2014 09:22:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> In-Reply-To: <20140924154352.GE2639@pfrc> Date: Fri, 26 Sep 2014 12:22:25 -0400 Message-ID: <02d301cfd9a6$0f331c00$2d995400$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D4_01CFD984.8824FE70" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAfcWsUScoHWRYA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hPHQaR7iSB3s_mqizi7122IoGjw Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 26 Sep 2014 16:23:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D4_01CFD984.8824FE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: Just to confirm three facts before I put them in i2rs drafts (based on Juergen's email - based on Juergen's email: I2RS is "config true empheral". If i2rs has additional configuration for BGP related to your I2RS peers for reporting routes: . BGP based config + I2RS additional config + AS Config Can I2RS have additional configuration values specific to I2RS? For example, information regarding how often to report the routes for a particular pear? Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Wednesday, September 24, 2014 11:44 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Sue, On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > The fourth option is interesting and creative. A few > questions/requests: 1) How would the fourth model be expressed in the > yang model - config (empheral)? I believe Juergen has answered this point. > 2) Please define your definition of local config with an example., This corresponds to "config true" state, probably in the running datastore. The semantics on the impact for the commit model when writable-running is not in use haven't been fully explored. > and 3) please give an example of the (must, when) use cases > envisioned? In the original proposal in my draft, when we had completely disjoint datastores, consider the BGP I2RS ephemeral peer case. The I2RS model would have a container of ephemeral peers. That container might not specify the local Autonomous System number. In that case, there would be a MUST requirement for that neighbor that there exist a system-wide configured Autonomous System number, probably in the local Config. Currently, there is no syntax that says how to examine nodes that are in a different datastore. From an XPath context, the current datastore is the document context. In the new proposal, since the ephemeral datastore gets a shadow of the local config, there is no need to have extensions to XPath to refer between data stores. However, if we end up with more than one ephemeral datastore (not recommended for this reason), such an issue returns. -- Jeff ------=_NextPart_000_02D4_01CFD984.8824FE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Just = to confirm three facts before I put them in i2rs drafts (based on = Juergen's email

- based on = Juergen's email:   I2RS is "config true = empheral". 

 

If = i2rs has additional configuration for BGP related to your I2RS peers for = reporting routes:

 

·         = BGP based config + I2RS additional config = + AS Config

 

Can = I2RS have additional configuration values specific to I2RS?  For = example, information regarding how often to report the routes for a = particular pear? 

 

Sue =

 

-----Original Message-----
From: Jeffrey Haas = [mailto:jhaas@pfrc.org]
Sent: Wednesday, September 24, 2014 11:44 = AM
To: Susan Hares
Cc: 'Jeffrey Haas'; i2rs@ietf.org; = netmod@ietf.org
Subject: Re: [i2rs] Summary of discussion from netmod = interim on i2rs requirements on netmod/netconf

 

Sue,

 

On = Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares = wrote:

> The fourth option is = interesting and creative. A few

> questions/requests: 1) How would the fourth = model be expressed in the

> = yang model  - config (empheral)?

 

I = believe Juergen has answered this point.

 

> = 2)  Please define your definition of local config with an = example.,

 

This corresponds to "config true" state, = probably in the running datastore.

The semantics on the impact for the commit model = when writable-running is not in use haven't been fully = explored.

 

> and 3) please give an example of the (must, = when) use cases

> = envisioned?

 

In the = original proposal in my draft, when we had completely disjoint = datastores, consider the BGP I2RS ephemeral peer case.  The I2RS = model would have a container of ephemeral peers.  That container = might not specify the local Autonomous System number.  In that = case, there would be a MUST requirement for that neighbor that there = exist a system-wide configured Autonomous System number, probably in the = local Config.

 

Currently, there is no syntax that says how to = examine nodes that are in a different datastore.  From an XPath = context, the current datastore is the document context.

 

In the = new proposal, since the ephemeral datastore gets a shadow of the local = config, there is no need to have extensions to XPath to refer between = data stores.

 

However, if we end up with more than one ephemeral = datastore (not recommended for this reason), such an issue = returns.

 

-- Jeff

------=_NextPart_000_02D4_01CFD984.8824FE70-- From nobody Fri Sep 26 10:11: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 D3CE51A1AAD; Fri, 26 Sep 2014 10:11: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 HNZN53j-SDno; Fri, 26 Sep 2014 10:11:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86A1A0174; Fri, 26 Sep 2014 10:11:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> In-Reply-To: <20140924154352.GE2639@pfrc> Date: Fri, 26 Sep 2014 13:11:02 -0400 Message-ID: <032401cfd9ac$da30b060$8e921120$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAfcWsUScoKoxgA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/6c9NUl5zcmZJlu9QkVW8kG_iitg Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 26 Sep 2014 17:11:08 -0000 Jeff: Could you give me an example of the interim's thoughts on commit versus Alexander's message: http://www.ietf.org/mail-archive/web/i2rs/current/msg01974.html Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, September 24, 2014 11:44 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Sue, On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > The fourth option is interesting and creative. A few > questions/requests: 1) How would the fourth model be expressed in the > yang model - config (empheral)? I believe Juergen has answered this point. > 2) Please define your definition of local config with an example., This corresponds to "config true" state, probably in the running datastore. The semantics on the impact for the commit model when writable-running is not in use haven't been fully explored. > and 3) please give an example of the (must, when) use cases > envisioned? In the original proposal in my draft, when we had completely disjoint datastores, consider the BGP I2RS ephemeral peer case. The I2RS model would have a container of ephemeral peers. That container might not specify the local Autonomous System number. In that case, there would be a MUST requirement for that neighbor that there exist a system-wide configured Autonomous System number, probably in the local Config. Currently, there is no syntax that says how to examine nodes that are in a different datastore. From an XPath context, the current datastore is the document context. In the new proposal, since the ephemeral datastore gets a shadow of the local config, there is no need to have extensions to XPath to refer between data stores. However, if we end up with more than one ephemeral datastore (not recommended for this reason), such an issue returns. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Sep 26 10:34:08 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 1A45C1A010C for ; Fri, 26 Sep 2014 10:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afyDmv0XVQjJ for ; Fri, 26 Sep 2014 10:34:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB271A6FFC for ; Fri, 26 Sep 2014 10:34:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Andy Bierman'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> In-Reply-To: Date: Fri, 26 Sep 2014 13:33:54 -0400 Message-ID: <032e01cfd9b0$0bb868a0$232939e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032F_01CFD98E.84ADA670" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHoMTP8chsklMLfoVKSkSiC97qaUgH4M+fGAYZnjisBptWYPwIGj9ikAeIyNrMBO2VUwgIOvKIJm4Af3lA= X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/L9eQgQjlCHWXCxp0JtNfwuZwzlA Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Alexander Clemm \(alex\)'" , 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:34:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032F_01CFD98E.84ADA670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: I'm asking Alexander what his model is as it is unclear. Rather than tear about my question, let's let him respond, and then debate the details. Sue From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, September 26, 2014 11:56 AM To: Susan Hares Cc: Alexander Clemm (alex); Martin Bjorklund; Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Fri, Sep 26, 2014 at 8:30 AM, Susan Hares wrote: Alexander: To help me understand your proposal, let us move to the previous example: Previous example: list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 So in this "foo 42" step, you are assuming that the NETCONF or RESTCONF client told the NETCONF or RESTCONF server that the edit to the local config is supposed to be copied to the ephemeral datastore? So modifications to those protocols to edit multiple datastores at once will be needed? (Your Q (a) below) So we are assuming the 2 datastores are in sync so concurrent edits are feasible? In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. You have this only if the previous step copied "foo 42". You cannot create a child node unless the parent exists or is also getting created. If you delete a node, the entire subtree (the XPath descendant-or-self axis) is deleted. I hope the various plans to couple the running and ephemeral datastores do not try to violate these rules. Andy Your model: a) The value 4711 - would be a "non-golden" copy. b) It would not be written through to the the "golden copy". Questions: a) How would you specify a "write-through" copy? b) Can I2RS decide later it wants to write-through the golden copy? Or are variables only "non-write-through" and "write-through"? c) If we delete foo 42, what happens? Thank you, Sue Hares Andy From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) Sent: Thursday, September 25, 2014 8:57 PM To: Andy Bierman; Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) Subject: Re: [i2rs] Two thoughts on an ephemeral data store FWIW, I would think the semantics should be kept simple. The complexity here comes from the fact that there are dependencies between different data stores, and some objects that are part of one data store need to be reflected in a different data store. It would seem this can be addressed with two fairly simple principles: (a) A datastore needs to have a clear way to reference objects in a different datastore, really have them incorporated into the same namespace. (b) It needs to be clear who owns the "golden copy" of an object. I needs to be clear which objects are "authoritatively owned" by a datastore vs which ones are reference. This is the datastore where the object is maintained, updated, created; this is where conditions and constraints are evaluated, etc. Where an ephemeral datastore has dependencies on data in another datastore, it should incorporate these other objects "by reference". The objects that are authoritatively owned by the ephemeral datastore can refer to those objects, have them referred to in conditions and constraints, and so on. (This can also indicate which ephemeral objects are to be removed when an object in the other datastore they depend on is deleted, etc) Changes to the non-ephemeral objects (e.g. the running datastore) have to be made to the "golden copy", i.e. the owning datastore. One way to do that involves implementing a "write-through" operation, in which an update to an ephemeral copy of the object is realized by having the server of the ephemeral datastore turn around and make a corresponding request at the other datastore. Very simple semantics. I think this is preferrable to have different copies of the same object in different datastores, requiring "logical anding" (or other inter-datastore arithmetic) of different copies representing the same object to figure out what actual value is in effect, etc. In the netmod WG, we have today posted a draft for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requiremen ts-00.txt), motivating why a it would be useful to have a capability to "mount" subtrees from a remote datastore into a local datastore, and the requirements that such a capability needs to address. While the original use case and motivation described there are somewhat different, it seems applicable to the discussion here. --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, September 25, 2014 8:44 AM To: Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund wrote: Jeffrey Haas wrote: > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > Jeffrey Haas wrote: > > > In the proposed overlay model, presume that we have ephemeral data from a > > > model that lives within an augmentation to a local config model. In other > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > Presume, per discussion, that the local config lives in the "config" data > > > store and that the ephemeral config - the augmenting nodes above - live in > > > the ephemeral data store. > > > > > > If we delete the container in the local config that the epehemeral config is > > > augmenting, is there any expectation that such a deletion should carry > > > through to the ephemeral config? > > > > > > Per the netmod interim discussion, probably not. > > > > My interpretation of the interim discussion is that the deletion > > carries through. > > To be clear what I meant, consider: > > local config: ephemeral: > A A/B - B is introduced as an augmentation of A I think there might be a terminology confusion here, so let's do a simple example. list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. What happens if we in local config delete foo 42? If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps? Yes -- and what is presented to a client that retrieves the ephemeral config in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephemeral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as local config when the device restarts (or the ephemeral state is removed). It should not change the injected I2RS state at all. IMO it is really important that edits stay within a single datastore. /martin Andy ------=_NextPart_000_032F_01CFD98E.84ADA670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

I’m asking Alexander what his model is as it is unclear. Rather = than tear about my question, let’s let him respond, and then = debate the details.

 

Sue

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, = September 26, 2014 11:56 AM
To: Susan Hares
Cc: = Alexander Clemm (alex); Martin Bjorklund; Jeffrey Haas; i2rs@ietf.org; = Eric Voit (evoit)
Subject: Re: [i2rs] Two thoughts on an = ephemeral data store

 

 

 

On Fri, = Sep 26, 2014 at 8:30 AM, Susan Hares <shares@ndzh.com> = wrote:

Alexander: =

 

To help me = understand your proposal, let us move to the previous example: =

 

Previous example: =

 

  list foo = {
    key id;
    leaf id { type int32; = }
    leaf a { type int32; }
  }

local = config:

   foo 42

 

 

 

So in this "foo 42" step, you are assuming = that the NETCONF or RESTCONF client

told the NETCONF or RESTCONF server that the edit to = the local config is supposed

to be copied to the ephemeral datastore?  So = modifications to those protocols

to edit multiple datastores at once will be needed? = (Your Q (a) below)

So we = are assuming the 2 datastores are in sync so concurrent edits are = feasible?

 

In ephemeral config = we now do SET /foo[id=3D42]/a  to 4711.  Thus, in
ephemeral = we now have a single node (a) with value 4711.

 

 

You have this only if the previous step copied = "foo 42".

You = cannot create a child node unless the parent exists or is also getting = created.

If you delete a = node, the entire subtree (the XPath descendant-or-self axis) is = deleted.

I hope the = various plans to couple the running and ephemeral datastores do = not

try to violate these = rules.

 

 

Andy

 

Your = model:

a)  The value 4711 = – would be a “non-golden” = copy.

b)  It would not be = written through to the the “golden = copy”.

 

Questions: =

a)  How would you = specify a “write-through” copy? =

b)  Can I2RS decide = later it wants to write-through the golden copy?  Or are variables = only “non-write-through” and = “write-through”?

c)  If we delete foo = 42, what happens?

 

Thank = you,

Sue Hares =

 

 

Andy

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Alexander Clemm (alex)
Sent: Thursday, September 25, 2014 = 8:57 PM
To: Andy Bierman; Martin Bjorklund
Cc: = Jeffrey Haas; i2rs@ietf.org; Eric Voit = (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data = store

 <= /o:p>

FWIW, I would think the semantics should be kept simple.  =

 

The complexity here comes from the fact that there are dependencies = between different data stores, and some objects that are part of one = data store need to be reflected in a different data store.  =

 

It would seem this can be addressed with two fairly simple = principles:

(a)    A datastore needs to have a clear way to reference objects in a = different datastore, really have them incorporated into the same = namespace. 

(b)   = It needs to be clear who owns the “golden copy” of an = object.  I needs to be clear which objects are = “authoritatively owned” by a datastore vs which ones are = reference.  This is the datastore where the object is maintained, = updated, created; this is where conditions and constraints are = evaluated, etc. 

 

Where an ephemeral datastore has dependencies on data in another = datastore, it should incorporate these other objects “by = reference”.  The objects that are authoritatively owned by = the ephemeral datastore can refer to those objects, have them referred = to in conditions and constraints, and so on.  (This can also = indicate which ephemeral objects are to be removed when an object in the = other datastore they depend on is deleted, etc)

 

Changes to the non-ephemeral objects (e.g. the running datastore) = have to be made to the “golden copy”, i.e. the owning = datastore.  One way to do that involves implementing a = “write-through” operation, in which an update to an = ephemeral copy of the object is realized by having the server of the = ephemeral datastore turn around and make a corresponding request at the = other datastore. 

 

Very simple semantics.  I think this is preferrable to have = different copies of the same object in different datastores, requiring = “logical anding” (or other inter-datastore arithmetic) of = different copies representing the same object to figure out what actual = value is in effect, etc. 

 

In the netmod WG, we have today posted a draft for what we refer to = as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-p= eer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to = “mount” subtrees from a remote datastore into a local = datastore, and the requirements that such a capability needs to = address.  While the original use case and motivation described = there are somewhat different, it seems applicable to the discussion = here. 

 

--- Alex

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Andy Bierman
Sent: Thursday, September 25, 2014 8:44 = AM
To: Martin Bjorklund
Cc: Jeffrey Haas; i2rs@ietf.org
Subject: Re: [i2rs] Two = thoughts on an ephemeral data store

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Thu, Sep = 25, 2014 at 7:39 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Jeffrey = Haas <jhaas@pfrc.org> wrote:
> On Thu, Sep 25, = 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
> > Jeffrey = Haas <jhaas@pfrc.org> wrote:
> > > In the = proposed overlay model, presume that we have ephemeral data from = a
> > > model that lives within an augmentation to a local = config model.  In other
> > > words, the ephemeral = nodes are children of the local config nodes.
> > >
> = > > Presume, per discussion, that the local config lives in the = "config" data
> > > store and that the ephemeral = config - the augmenting nodes above - live in
> > > the = ephemeral data store.
> > >
> > > If we delete = the container in the local config that the epehemeral config is
> = > > augmenting, is there any expectation that such a deletion = should carry
> > > through to the ephemeral config?
> = > >
> > > Per the netmod interim discussion, probably = not.
> >
> > My interpretation of the interim = discussion is that the deletion
> > carries = through.
>
> To be clear what I meant, = consider:
>
> local config:      = ephemeral:
> A              =     A/B - B is introduced as an augmentation of A

I = think there might be a terminology confusion here, so let's do = a
simple example.

  list foo {
    key = id;
    leaf id { type int32; }
    leaf a { = type int32; }
  }

local config:

   foo = 42

In ephemeral config we now do SET /foo[id=3D42]/a  to = 4711.  Thus, in
ephemeral we now have a single node (a) with = value 4711.

What happens if we in local config delete foo = 42?

If /foo[id=3D42]/a is NOT deleted from the ephemeral config, = what is now
presented to the internal apps?

 <= /o:p>

 <= /o:p>

Yes -- and = what is presented to a client that retrieves the ephemeral = config

in a GET = request? IMO, coupling the datastores does not make = sense.

 <= /o:p>

Your = example is 1 reason I prefer the "shadow shapshot" = approach.

I think the = local config and client that added the "foo" entry in the = ephemeral datastore

are meant = to have different priorities.  The entries are not = coupled.

One wins = and the other loses (main use-case is that ephemeral = wins).

 <= /o:p>

Editing = "foo 42" in the local config just changes what will be = installed as local config

when the = device restarts (or the ephemeral state is removed).  It should not = change

the = injected I2RS state at all.  IMO it is really important that edits = stay within a single

datastore.

 <= /o:p>

 <= /o:p>



/mar= tin

 <= /o:p>

Andy

 <= /o:p>

 

------=_NextPart_000_032F_01CFD98E.84ADA670-- From nobody Fri Sep 26 10:46: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 B0A881A8BC1 for ; Fri, 26 Sep 2014 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31P-K8YgyxHX for ; Fri, 26 Sep 2014 10:45: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 1EA221A872B for ; Fri, 26 Sep 2014 10:45:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Andy Bierman'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> <032e01cfd9b0$0bb868a0$232939e0$@ndzh.com> In-Reply-To: <032e01cfd9b0$0bb868a0$232939e0$@ndzh.com> Date: Fri, 26 Sep 2014 13:45:48 -0400 Message-ID: <036501cfd9b1$b58fc250$20af46f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0366_01CFD990.2E810880" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHoMTP8chsklMLfoVKSkSiC97qaUgH4M+fGAYZnjisBptWYPwIGj9ikAeIyNrMBO2VUwgIOvKIJAfdUtFqbcIOVYA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/byfOxVlClda6Ma0fT1zXL6vBzps Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Alexander Clemm \(alex\)'" , 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:46:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0366_01CFD990.2E810880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: . please correct this to: I'm asking Alexander what his model is as it is unclear. Rather than tear a apart my question, let's let him respond, and then debate the details. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, September 26, 2014 1:34 PM To: 'Andy Bierman' Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Alexander Clemm (alex)'; 'Martin Bjorklund'; 'Eric Voit (evoit)' Subject: Re: [i2rs] Two thoughts on an ephemeral data store Andy: I'm asking Alexander what his model is as it is unclear. Rather than tear about my question, let's let him respond, and then debate the details. Sue From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, September 26, 2014 11:56 AM To: Susan Hares Cc: Alexander Clemm (alex); Martin Bjorklund; Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Fri, Sep 26, 2014 at 8:30 AM, Susan Hares wrote: Alexander: To help me understand your proposal, let us move to the previous example: Previous example: list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 So in this "foo 42" step, you are assuming that the NETCONF or RESTCONF client told the NETCONF or RESTCONF server that the edit to the local config is supposed to be copied to the ephemeral datastore? So modifications to those protocols to edit multiple datastores at once will be needed? (Your Q (a) below) So we are assuming the 2 datastores are in sync so concurrent edits are feasible? In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. You have this only if the previous step copied "foo 42". You cannot create a child node unless the parent exists or is also getting created. If you delete a node, the entire subtree (the XPath descendant-or-self axis) is deleted. I hope the various plans to couple the running and ephemeral datastores do not try to violate these rules. Andy Your model: a) The value 4711 - would be a "non-golden" copy. b) It would not be written through to the the "golden copy". Questions: a) How would you specify a "write-through" copy? b) Can I2RS decide later it wants to write-through the golden copy? Or are variables only "non-write-through" and "write-through"? c) If we delete foo 42, what happens? Thank you, Sue Hares Andy From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) Sent: Thursday, September 25, 2014 8:57 PM To: Andy Bierman; Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) Subject: Re: [i2rs] Two thoughts on an ephemeral data store FWIW, I would think the semantics should be kept simple. The complexity here comes from the fact that there are dependencies between different data stores, and some objects that are part of one data store need to be reflected in a different data store. It would seem this can be addressed with two fairly simple principles: (a) A datastore needs to have a clear way to reference objects in a different datastore, really have them incorporated into the same namespace. (b) It needs to be clear who owns the "golden copy" of an object. I needs to be clear which objects are "authoritatively owned" by a datastore vs which ones are reference. This is the datastore where the object is maintained, updated, created; this is where conditions and constraints are evaluated, etc. Where an ephemeral datastore has dependencies on data in another datastore, it should incorporate these other objects "by reference". The objects that are authoritatively owned by the ephemeral datastore can refer to those objects, have them referred to in conditions and constraints, and so on. (This can also indicate which ephemeral objects are to be removed when an object in the other datastore they depend on is deleted, etc) Changes to the non-ephemeral objects (e.g. the running datastore) have to be made to the "golden copy", i.e. the owning datastore. One way to do that involves implementing a "write-through" operation, in which an update to an ephemeral copy of the object is realized by having the server of the ephemeral datastore turn around and make a corresponding request at the other datastore. Very simple semantics. I think this is preferrable to have different copies of the same object in different datastores, requiring "logical anding" (or other inter-datastore arithmetic) of different copies representing the same object to figure out what actual value is in effect, etc. In the netmod WG, we have today posted a draft for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requiremen ts-00.txt), motivating why a it would be useful to have a capability to "mount" subtrees from a remote datastore into a local datastore, and the requirements that such a capability needs to address. While the original use case and motivation described there are somewhat different, it seems applicable to the discussion here. --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, September 25, 2014 8:44 AM To: Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund wrote: Jeffrey Haas wrote: > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > Jeffrey Haas wrote: > > > In the proposed overlay model, presume that we have ephemeral data from a > > > model that lives within an augmentation to a local config model. In other > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > Presume, per discussion, that the local config lives in the "config" data > > > store and that the ephemeral config - the augmenting nodes above - live in > > > the ephemeral data store. > > > > > > If we delete the container in the local config that the epehemeral config is > > > augmenting, is there any expectation that such a deletion should carry > > > through to the ephemeral config? > > > > > > Per the netmod interim discussion, probably not. > > > > My interpretation of the interim discussion is that the deletion > > carries through. > > To be clear what I meant, consider: > > local config: ephemeral: > A A/B - B is introduced as an augmentation of A I think there might be a terminology confusion here, so let's do a simple example. list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. What happens if we in local config delete foo 42? If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps? Yes -- and what is presented to a client that retrieves the ephemeral config in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephemeral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as local config when the device restarts (or the ephemeral state is removed). It should not change the injected I2RS state at all. IMO it is really important that edits stay within a single datastore. /martin Andy ------=_NextPart_000_0366_01CFD990.2E810880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

… please correct this to:

 

I’m asking Alexander what his model is as it is unclear. Rather = than tear a apart my question, let’s let him respond, and then = debate the details.

 

Sue

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, September 26, 2014 1:34 PM
To: = 'Andy Bierman'
Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Alexander = Clemm (alex)'; 'Martin Bjorklund'; 'Eric Voit = (evoit)'
Subject: Re: [i2rs] Two thoughts on an ephemeral data = store

 

Andy:

 

I’m asking Alexander what his model is as it is unclear. Rather = than tear about my question, let’s let him respond, and then = debate the details.

 

Sue

From:= = Andy Bierman [mailto:andy@yumaworks.com] =
Sent: Friday, September 26, 2014 11:56 AM
To: Susan = Hares
Cc: Alexander Clemm (alex); Martin Bjorklund; Jeffrey = Haas; i2rs@ietf.org; Eric Voit = (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data = store

 

 

 

On Fri, = Sep 26, 2014 at 8:30 AM, Susan Hares <shares@ndzh.com> = wrote:

Alexander: =

 

To help me = understand your proposal, let us move to the previous example: =

 

Previous example: =

 

  list foo = {
    key id;
    leaf id { type int32; = }
    leaf a { type int32; }
  }

local = config:

   foo 42

 

 

 

So in this "foo 42" step, you are assuming = that the NETCONF or RESTCONF client

told the NETCONF or RESTCONF server that the edit to = the local config is supposed

to be copied to the ephemeral datastore?  So = modifications to those protocols

to edit multiple datastores at once will be needed? = (Your Q (a) below)

So we = are assuming the 2 datastores are in sync so concurrent edits are = feasible?

 

In ephemeral config = we now do SET /foo[id=3D42]/a  to 4711.  Thus, in
ephemeral = we now have a single node (a) with value 4711.

 

 

You have this only if the previous step copied = "foo 42".

You = cannot create a child node unless the parent exists or is also getting = created.

If you delete a = node, the entire subtree (the XPath descendant-or-self axis) is = deleted.

I hope the = various plans to couple the running and ephemeral datastores do = not

try to violate these = rules.

 

 

Andy

 

Your = model:

a)  The value 4711 = – would be a “non-golden” = copy.

b)  It would not be = written through to the the “golden = copy”.

 

Questions: =

a)  How would you = specify a “write-through” copy? =

b)  Can I2RS decide = later it wants to write-through the golden copy?  Or are variables = only “non-write-through” and = “write-through”?

c)  If we delete foo = 42, what happens?

 

Thank = you,

Sue Hares =

 

 

Andy

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Alexander Clemm (alex)
Sent: Thursday, September 25, 2014 = 8:57 PM
To: Andy Bierman; Martin Bjorklund
Cc: = Jeffrey Haas; i2rs@ietf.org; Eric Voit = (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data = store

 <= /o:p>

FWIW, I would think the semantics should be kept simple.  =

 

The complexity here comes from the fact that there are dependencies = between different data stores, and some objects that are part of one = data store need to be reflected in a different data store.  =

 

It would seem this can be addressed with two fairly simple = principles:

(a)    A datastore needs to have a clear way to reference objects in a = different datastore, really have them incorporated into the same = namespace. 

(b)   = It needs to be clear who owns the “golden copy” of an = object.  I needs to be clear which objects are = “authoritatively owned” by a datastore vs which ones are = reference.  This is the datastore where the object is maintained, = updated, created; this is where conditions and constraints are = evaluated, etc. 

 

Where an ephemeral datastore has dependencies on data in another = datastore, it should incorporate these other objects “by = reference”.  The objects that are authoritatively owned by = the ephemeral datastore can refer to those objects, have them referred = to in conditions and constraints, and so on.  (This can also = indicate which ephemeral objects are to be removed when an object in the = other datastore they depend on is deleted, etc)

 

Changes to the non-ephemeral objects (e.g. the running datastore) = have to be made to the “golden copy”, i.e. the owning = datastore.  One way to do that involves implementing a = “write-through” operation, in which an update to an = ephemeral copy of the object is realized by having the server of the = ephemeral datastore turn around and make a corresponding request at the = other datastore. 

 

Very simple semantics.  I think this is preferrable to have = different copies of the same object in different datastores, requiring = “logical anding” (or other inter-datastore arithmetic) of = different copies representing the same object to figure out what actual = value is in effect, etc. 

 

In the netmod WG, we have today posted a draft for what we refer to = as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-p= eer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to = “mount” subtrees from a remote datastore into a local = datastore, and the requirements that such a capability needs to = address.  While the original use case and motivation described = there are somewhat different, it seems applicable to the discussion = here. 

 

--- Alex

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Andy Bierman
Sent: Thursday, September 25, 2014 8:44 = AM
To: Martin Bjorklund
Cc: Jeffrey Haas; i2rs@ietf.org
Subject: Re: [i2rs] Two = thoughts on an ephemeral data store

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Thu, Sep = 25, 2014 at 7:39 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Jeffrey = Haas <jhaas@pfrc.org> wrote:
> On Thu, Sep 25, = 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:
> > Jeffrey = Haas <jhaas@pfrc.org> wrote:
> > > In the = proposed overlay model, presume that we have ephemeral data from = a
> > > model that lives within an augmentation to a local = config model.  In other
> > > words, the ephemeral = nodes are children of the local config nodes.
> > >
> = > > Presume, per discussion, that the local config lives in the = "config" data
> > > store and that the ephemeral = config - the augmenting nodes above - live in
> > > the = ephemeral data store.
> > >
> > > If we delete = the container in the local config that the epehemeral config is
> = > > augmenting, is there any expectation that such a deletion = should carry
> > > through to the ephemeral config?
> = > >
> > > Per the netmod interim discussion, probably = not.
> >
> > My interpretation of the interim = discussion is that the deletion
> > carries = through.
>
> To be clear what I meant, = consider:
>
> local config:      = ephemeral:
> A              =     A/B - B is introduced as an augmentation of A

I = think there might be a terminology confusion here, so let's do = a
simple example.

  list foo {
    key = id;
    leaf id { type int32; }
    leaf a { = type int32; }
  }

local config:

   foo = 42

In ephemeral config we now do SET /foo[id=3D42]/a  to = 4711.  Thus, in
ephemeral we now have a single node (a) with = value 4711.

What happens if we in local config delete foo = 42?

If /foo[id=3D42]/a is NOT deleted from the ephemeral config, = what is now
presented to the internal apps?

 <= /o:p>

 <= /o:p>

Yes -- and = what is presented to a client that retrieves the ephemeral = config

in a GET = request? IMO, coupling the datastores does not make = sense.

 <= /o:p>

Your = example is 1 reason I prefer the "shadow shapshot" = approach.

I think the = local config and client that added the "foo" entry in the = ephemeral datastore

are meant = to have different priorities.  The entries are not = coupled.

One wins = and the other loses (main use-case is that ephemeral = wins).

 <= /o:p>

Editing = "foo 42" in the local config just changes what will be = installed as local config

when the = device restarts (or the ephemeral state is removed).  It should not = change

the = injected I2RS state at all.  IMO it is really important that edits = stay within a single

datastore.

 <= /o:p>

 <= /o:p>



/mar= tin

 <= /o:p>

Andy

 <= /o:p>

 

------=_NextPart_000_0366_01CFD990.2E810880-- From nobody Fri Sep 26 16:53: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 C03D01A8784 for ; Fri, 26 Sep 2014 16:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 PeXPku6H9Sja for ; Fri, 26 Sep 2014 16:53:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4397F1A8780 for ; Fri, 26 Sep 2014 16:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45724; q=dns/txt; s=iport; t=1411775626; x=1412985226; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P8edmBpuK9MtURrnjNGZ+zkKmGHg5C2loICRjOJmXGs=; b=cMNZEU3EIOH5eLyIy2zhS3V1iHBa/wzMOwxwDlwtM2WnpimCCnbfAuxa FvUa8LUAQSy1dy8/+orwf9zvakQ/1iuuknGtUiipvV6OAjeWf9bznwgnd 7ZR9BJ8VvMZ2Ud5Zz2J808kRFUtlqHW7fRZ/vRgWYqTrX7GDrKClVgdf9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOb7JVStJV2T/2dsb2JhbABfgkhGU1cEykmHTAKBBxYBe4QDAQEBBCcGOhIQAgEIDgMEAQEBChYBBgcyFAkIAgQBDQUIAYg1Db8SARePOjMxBgGDLoEdBY9LghihH4NjbAGBBUKBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,606,1406592000"; d="scan'208,217"; a="81717728" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP; 26 Sep 2014 23:53:44 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8QNri8J005886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 23:53:44 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 18:53:43 -0500 From: "Alexander Clemm (alex)" To: Susan Hares , "'Andy Bierman'" , "'Martin Bjorklund'" Thread-Topic: [i2rs] Two thoughts on an ephemeral data store Thread-Index: AQHP2AyNNGxq3WM56UegT3gsiRt8HpwR+uyAgABARYCAAAVsgIAAEjgAgAA6FGCAAVRHAIAAMDuA Date: Fri, 26 Sep 2014 23:53:43 +0000 Message-ID: References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> In-Reply-To: <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.205.44] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C80844Fxmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oRAqZ7yZ4JDMgumRwcTqsTRsZeM Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , "Eric Voit \(evoit\)" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 23:53:50 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C80844Fxmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Susan, Andy, all, there would be two datastore - "local" and "ephemeral". Local implements and owns foo, instantiated as you describe below. This is= the golden copy. Furthermore, for simplicity sake, assume that list foo is contained in a co= ntainer, foos. The ephemeral datastore implements a separate model "foo-ext". This model declares a reference / "mount" to "foos" in the local datastore. In addition, it defines some other data, that is "owned" by the ephemeral d= atastore. (This data can have conditions/constraints to data that has been= mounted from foo.) So, in the ephemeral you might have foo-ext +-- M foos --> /local/foos +-- bar An application/client that accesses ephemeral can access foo 42 via /foo-ex= t/foos/foo 42. The fact that the ephemeral datastore turns around as neede= d, as the golden copy is owned by local, is transparent to the application.= If someone changes foo 42, e.g. because they access the local datastore d= irectly, that will be reflected in the ephemeral datastore by virtue of the= fact that it in effect acts as a "cache" to the data in the local datastor= e. Now, there are a couple of items to consider: - If you want to have a list where some list elements reside on on= e datastore, others in another, you cannot do that directly. What you need= to do in that case is to introduce a partition (as part of the model that = you implement in the ephemeral) that e.g. has a "my-foos" container contain= ing the list elements it authoritatively owns, and a separate "cached-foos"= container that "contains" the list elements from the other datastore. - Should you be able to have a remote data item contain a local on= e? I would argue that you should not allow for that, precisely to avoid th= e scenario in which the local object get "decapitated" because something ha= ppens to the containing objects that are owned by a different system. If y= ou want to attach a piece of ephemeral data to the remote data item, you sh= ould do so with other ways than containment, e.g. adding a leafref to the m= ounted/referenced remote object. The distinction to other proposals is that with this proposal, the ephemera= l datastore defines its own separate model (which indicates which data it "= owns", vs which data it "caches"). Note that the model for the cached data = does not need to be redefined; it is used as-is; the fact that there is ano= ther datastore which decides to incorporate that information is not somethi= ng the local datastore needs to be aware of. Does this answer your questions? --- Alex From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, September 26, 2014 8:30 AM To: Alexander Clemm (alex); 'Andy Bierman'; 'Martin Bjorklund' Cc: 'Jeffrey Haas'; i2rs@ietf.org; Eric Voit (evoit) Subject: RE: [i2rs] Two thoughts on an ephemeral data store Alexander: To help me understand your proposal, let us move to the previous example: Previous example: list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=3D42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. Your model: a) The value 4711 - would be a "non-golden" copy. b) It would not be written through to the the "golden copy". Questions: a) How would you specify a "write-through" copy? b) Can I2RS decide later it wants to write-through the golden copy? Or ar= e variables only "non-write-through" and "write-through"? c) If we delete foo 42, what happens? Thank you, Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm (ale= x) Sent: Thursday, September 25, 2014 8:57 PM To: Andy Bierman; Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org; Eric Voit (evoit) Subject: Re: [i2rs] Two thoughts on an ephemeral data store FWIW, I would think the semantics should be kept simple. The complexity here comes from the fact that there are dependencies between= different data stores, and some objects that are part of one data store ne= ed to be reflected in a different data store. It would seem this can be addressed with two fairly simple principles: (a) A datastore needs to have a clear way to reference objects in a diff= erent datastore, really have them incorporated into the same namespace. (b) It needs to be clear who owns the "golden copy" of an object. I need= s to be clear which objects are "authoritatively owned" by a datastore vs w= hich ones are reference. This is the datastore where the object is maintai= ned, updated, created; this is where conditions and constraints are evaluat= ed, etc. Where an ephemeral datastore has dependencies on data in another datastore,= it should incorporate these other objects "by reference". The objects tha= t are authoritatively owned by the ephemeral datastore can refer to those o= bjects, have them referred to in conditions and constraints, and so on. (T= his can also indicate which ephemeral objects are to be removed when an obj= ect in the other datastore they depend on is deleted, etc) Changes to the non-ephemeral objects (e.g. the running datastore) have to b= e made to the "golden copy", i.e. the owning datastore. One way to do that= involves implementing a "write-through" operation, in which an update to a= n ephemeral copy of the object is realized by having the server of the ephe= meral datastore turn around and make a corresponding request at the other d= atastore. Very simple semantics. I think this is preferrable to have different copie= s of the same object in different datastores, requiring "logical anding" (o= r other inter-datastore arithmetic) of different copies representing the sa= me object to figure out what actual value is in effect, etc. In the netmod WG, we have today posted a draft for what we refer to as requ= irements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-n= etmod-peer-mount-requirements-00.txt), motivating why a it would be useful = to have a capability to "mount" subtrees from a remote datastore into a loc= al datastore, and the requirements that such a capability needs to address.= While the original use case and motivation described there are somewhat d= ifferent, it seems applicable to the discussion here. --- Alex From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, September 25, 2014 8:44 AM To: Martin Bjorklund Cc: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund > wrote: Jeffrey Haas > wrote: > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > Jeffrey Haas > wrote: > > > In the proposed overlay model, presume that we have ephemeral data fr= om a > > > model that lives within an augmentation to a local config model. In = other > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > Presume, per discussion, that the local config lives in the "config" = data > > > store and that the ephemeral config - the augmenting nodes above - li= ve in > > > the ephemeral data store. > > > > > > If we delete the container in the local config that the epehemeral co= nfig is > > > augmenting, is there any expectation that such a deletion should carr= y > > > through to the ephemeral config? > > > > > > Per the netmod interim discussion, probably not. > > > > My interpretation of the interim discussion is that the deletion > > carries through. > > To be clear what I meant, consider: > > local config: ephemeral: > A A/B - B is introduced as an augmentation of A I think there might be a terminology confusion here, so let's do a simple example. list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=3D42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. What happens if we in local config delete foo 42? If /foo[id=3D42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps? Yes -- and what is presented to a client that retrieves the ephemeral confi= g in a GET request? IMO, coupling the datastores does not make sense. Your example is 1 reason I prefer the "shadow shapshot" approach. I think the local config and client that added the "foo" entry in the ephem= eral datastore are meant to have different priorities. The entries are not coupled. One wins and the other loses (main use-case is that ephemeral wins). Editing "foo 42" in the local config just changes what will be installed as= local config when the device restarts (or the ephemeral state is removed). It should no= t change the injected I2RS state at all. IMO it is really important that edits stay= within a single datastore. /martin Andy --_000_DBC595ED2346914F9F81D17DD5C32B571C80844Fxmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Susan, Andy, all,=

 <= /p>

there would be two datast= ore – “local” and “ephemeral”. 

Local implements and owns= foo, instantiated as you describe below.  This is the golden copy.&nb= sp;

Furthermore, for simplici= ty sake, assume that list foo is contained in a container, foos. 

 <= /p>

The ephemeral datastore i= mplements a separate model “foo-ext”. 

This model declares a ref= erence / “mount” to “foos” in the local datastore.&= nbsp;

In addition, it defines s= ome other data, that is “owned” by the ephemeral datastore.&nbs= p; (This data can have conditions/constraints to data that has been mounted from foo.) 

 <= /p>

So, in the ephemeral you = might have

 <= /p>

foo-ext=

+-- M foos  --&g= t; /local/foos

+-- bar

 <= /p>

An application/client tha= t accesses ephemeral can access foo 42 via /foo-ext/foos/foo 42.  The = fact that the ephemeral datastore turns around as needed, as the golden copy is owned by local, is transparent to the application. = ; If someone changes foo 42, e.g. because they access the local datastore d= irectly, that will be reflected in the ephemeral datastore by virtue of the= fact that it in effect acts as a “cache” to the data in the local datastore. 

 <= /p>

Now, there are a couple o= f items to consider:

- =          If you want to ha= ve a list where some list elements reside on one datastore, others in anoth= er, you cannot do that directly.  What you need to do in that case is to introduce a partition (as part of the model that you im= plement in the ephemeral) that e.g. has a “my-foos” container c= ontaining the list elements it authoritatively owns, and a separate “= cached-foos” container that “contains” the list elements from the other datastore. 

- =          Should you be abl= e to have a remote data item contain a local one?  I would argue that = you should not allow for that, precisely to avoid the scenario in which the local object get “decapitated” because something = happens to the containing objects that are owned by a different system.&nbs= p; If you want to attach a piece of ephemeral data to the remote data item,= you should do so with other ways than containment, e.g. adding a leafref to the mounted/referenced remote object.  =

 <= /p>

The distinction to other = proposals is that with this proposal, the ephemeral datastore defines its o= wn separate model (which indicates which data it “owns”, vs which data it “caches”). Note that the model for the cached= data does not need to be redefined; it is used as-is; the fact that there = is another datastore which decides to incorporate that information is not s= omething the local datastore needs to be aware of.   

 <= /p>

Does this answer your que= stions?

--- Alex

 <= /p>

 <= /p>

From: Susan Ha= res [mailto:shares@ndzh.com]
Sent: Friday, September 26, 2014 8:30 AM
To: Alexander Clemm (alex); 'Andy Bierman'; 'Martin Bjorklund'
Cc: 'Jeffrey Haas'; i2rs@ietf.org; Eric Voit (evoit)
Subject: RE: [i2rs] Two thoughts on an ephemeral data store

 

Alexander:

 

To help me understand your proposal, let= us move to the previous example:

 

Previous example:

 

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

 

In ephemeral config we now do SET /foo[i= d=3D42]/a  to 4711.  Thus, in
ephemeral we now have a single node (a) with value 4711.<= /p>

 

Your model:

a)=   The value 4711 – would be = a “non-golden” copy.

b)=   It would not be written through = to the the “golden copy”.

 

Questions:

a)=   How would you specify a “w= rite-through” copy?

b)=   Can I2RS decide later it wants t= o write-through the golden copy?  Or are variables only “non-wri= te-through” and “write-through”?

c)=   If we delete foo 42, what happen= s?

 

Thank you,

Sue Hares

 <= /p>

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alexander Clemm (alex)
Sent: Thursday, September 25, 2014 8:57 PM
To: Andy Bierman; Martin Bjorklund
Cc: Jeffrey Haas; i2rs@ietf.org= ; Eric Voit (evoit)
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

 

FWIW, I would think the s= emantics should be kept simple. 

 <= /p>

The complexity here comes= from the fact that there are dependencies between different data stores, a= nd some objects that are part of one data store need to be reflected in a different data store. 

 <= /p>

It would seem this can be= addressed with two fairly simple principles:

(a)&nbs= p;   A datastore needs= to have a clear way to reference objects in a different datastore, really = have them incorporated into the same namespace. 

(b)&nbs= p;  It needs to be cl= ear who owns the “golden copy” of an object.  I needs to b= e clear which objects are “authoritatively owned” by a datastor= e vs which ones are reference.  This is the datastore where the object is mainta= ined, updated, created; this is where conditions and constraints are evalua= ted, etc. 

 <= /p>

Where an ephemeral datast= ore has dependencies on data in another datastore, it should incorporate th= ese other objects “by reference”.  The objects that are authoritatively owned by the ephemeral datastore can refer to those object= s, have them referred to in conditions and constraints, and so on.  (T= his can also indicate which ephemeral objects are to be removed when an obj= ect in the other datastore they depend on is deleted, etc)

 <= /p>

Changes to the non-epheme= ral objects (e.g. the running datastore) have to be made to the “gold= en copy”, i.e. the owning datastore.  One way to do that involve= s implementing a “write-through” operation, in which an update t= o an ephemeral copy of the object is realized by having the server of the e= phemeral datastore turn around and make a corresponding request at the othe= r datastore. 

 <= /p>

Very simple semantics.&nb= sp; I think this is preferrable to have different copies of the same object= in different datastores, requiring “logical anding” (or other inter-datastore arithmetic) of different copies representing the same obje= ct to figure out what actual value is in effect, etc. 

 <= /p>

In the netmod WG, we have= today posted a draft for what we refer to as requirements for a peer mount= (http://www.ietf.org/internet-drafts/draft-vo= it-netmod-peer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to “mount&#= 8221; subtrees from a remote datastore into a local datastore, and the requ= irements that such a capability needs to address.  While the original = use case and motivation described there are somewhat different, it seems applicable to the discussion here. 

 <= /p>

--- Alex

 <= /p>

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, September 25, 2014 8:44 AM
To: Martin Bjorklund
Cc: Jeffrey Haas; i2rs@ietf.org=
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

 

 

 

On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:

Jeffrey Haas <j= haas@pfrc.org> wrote:
> On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote:<= br> > > Jeffrey Haas <jhaas@pfrc.org= > wrote:
> > > In the proposed overlay model, presume that we have ephemera= l data from a
> > > model that lives within an augmentation to a local config mo= del.  In other
> > > words, the ephemeral nodes are children of the local config = nodes.
> > >
> > > Presume, per discussion, that the local config lives in the = "config" data
> > > store and that the ephemeral config - the augmenting nodes a= bove - live in
> > > the ephemeral data store.
> > >
> > > If we delete the container in the local config that the epeh= emeral config is
> > > augmenting, is there any expectation that such a deletion sh= ould carry
> > > through to the ephemeral config?
> > >
> > > Per the netmod interim discussion, probably not.
> >
> > My interpretation of the interim discussion is that the deletion<= br> > > carries through.
>
> To be clear what I meant, consider:
>
> local config:      ephemeral:
> A                  A/B - = B is introduced as an augmentation of A

I think there might be a terminology confusion here, so let's do a
simple example.

  list foo {
    key id;
    leaf id { type int32; }
    leaf a { type int32; }
  }

local config:

   foo 42

In ephemeral config we now do SET /foo[id=3D42]/a  to 4711.  Thus= , in
ephemeral we now have a single node (a) with value 4711.

What happens if we in local config delete foo 42?

If /foo[id=3D42]/a is NOT deleted from the ephemeral config, what is now presented to the internal apps?

 

 

Yes -- and what is presented to a client that retrie= ves the ephemeral config

in a GET request? IMO, coupling the datastores does = not make sense.

 

Your example is 1 reason I prefer the "shadow s= hapshot" approach.

I think the local config and client that added the &= quot;foo" entry in the ephemeral datastore

are meant to have different priorities.  The en= tries are not coupled.

One wins and the other loses (main use-case is that = ephemeral wins).

 

Editing "foo 42" in the local config just = changes what will be installed as local config

when the device restarts (or the ephemeral state is = removed).  It should not change

the injected I2RS state at all.  IMO it is real= ly important that edits stay within a single

datastore.

 

 



/martin

 

Andy

 

--_000_DBC595ED2346914F9F81D17DD5C32B571C80844Fxmbrcdx05ciscoc_-- From nobody Fri Sep 26 20:36: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 6448D1A02D4 for ; Fri, 26 Sep 2014 20:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjxvSSN7r8iZ for ; Fri, 26 Sep 2014 20:36:11 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C32481A02BC for ; Fri, 26 Sep 2014 20:36:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> In-Reply-To: <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> Date: Fri, 26 Sep 2014 23:36:05 -0400 Message-ID: <00b501cfda04$2b4db130$81e91390$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01CFD9E2.A43D97D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIExceRnK/J00A= X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/MoERJi1MJROLq8cl5xfZqEIELRU Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 03:36:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B6_01CFD9E2.A43D97D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: Please add to the agenda the following drafts: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and BGP will be uploaded next week after some internal review. The PBR model is the information model that is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model). We hoped to have the agreement on the text early next week (just 1 technical discussion). The author team has had meetings in August and September. Please add the use case to the agenda. One question - should I be submitting these I2RS configuration IM/DM as netmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas < jhaas@pfrc.org> wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 ------=_NextPart_000_00B6_01CFD9E2.A43D97D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff: =

 

Please add to the agenda the following drafts: I2RS = yang Data and Information models for ISIS, OSPF, Basic Network Policy = (BNP), PBR and BGP.  PBR and BGP will be uploaded next week after = some internal review.   

 

The = PBR model is the information model that is a collaboration between the = PBR (draft-kini-i2rs-pbr-info-model-00) and the = (draft-hares-i2rs-policy-info-model).   We hoped to have the = agreement on the text early next week (just 1 technical discussion). =   The author team has had meetings in August and September. =   

 

Please = add the use case to the agenda.

 

One = question – should I be submitting these I2RS configuration IM/DM = as netmod models? If so, I will do this as well.

 

Sue =

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic
Sent: = Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: = i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call = for agenda; status reports?

 

Jeff,

 

To = kickstart the discussions

 

looking at what is needed in NETMOD and NETCONF for = I2RS

 

datastore for I2RS (use cases for ephemeral data = store)

 

working on ACL YANG model - with ACL model = available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info = model (draft-kini-i2rs-pbr-info-model-00) can be extended into data = model. I'll try to submit the draft by the deadline (it is dependent on = new draft-ietf-netmod-routing-cfg, probably = draft-ietf-netmod-routing-cfg-16, being published)

 

Dean

 

On Sep = 25, 2014, at 2:00 PM, Jeffrey Haas <jhaas@pfrc.org= > wrote:

 

> = Your chairs have been a bit over-busy recently with travel to unicast =

> people doing various bits of = chartered work.  This means we've been

> behind on some of our goals in terms of = getting regular design

> = sessions running.  I know that at least a couple calls have = happened

> that I've missed = that Sue Hares has done, so some progress is being = made.

>

> We've requested a 1 hour time slot for IETF 91 = in Honolulu to give us

> a = chance to talk.  This is a call for agenda slots.

>

> = This is also a call for status reports.

>

> = We've had some productive discussion about requests to netmod/netconf, =

> albeit ones that haven't = converged yet.

> =

> What have you been up = to?

>

> -- Jeff & Ed

>

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_00B6_01CFD9E2.A43D97D0-- From nobody Fri Sep 26 20:37: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 383B71A02D4 for ; Fri, 26 Sep 2014 20:37:24 -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 PKQl9py66i2h for ; Fri, 26 Sep 2014 20:37:23 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 43BEC1A02BC for ; Fri, 26 Sep 2014 20:37:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> In-Reply-To: <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> Date: Fri, 26 Sep 2014 23:37:18 -0400 Message-ID: <00c201cfda04$56de3040$049a90c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIExceRnK/OfuA= X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/t5K6EwB2yYXFeZp59ZTDBns_KYA Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 03:37:24 -0000 Jeff: Just to confirm that you requested only a 1 hour instead of a 2.5 hour slot? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 From nobody Fri Sep 26 22:32:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899621A19FF for ; Fri, 26 Sep 2014 22:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wu8rV86O-4X for ; Fri, 26 Sep 2014 22:32:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE8A1A19F9 for ; Fri, 26 Sep 2014 22:32:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0445D8F2; Sat, 27 Sep 2014 07:32:18 +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 0yj_6U6xI6jo; Sat, 27 Sep 2014 07:32:12 +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, 27 Sep 2014 07:32:16 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACA8720038; Sat, 27 Sep 2014 07:32:16 +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 OsvOZReaS-hp; Sat, 27 Sep 2014 07:32:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72A1D20037; Sat, 27 Sep 2014 07:32:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9D7B82EA4F5D; Sat, 27 Sep 2014 07:32:13 +0200 (CEST) Date: Sat, 27 Sep 2014 07:32:13 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140927053213.GA71838@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b501cfda04$2b4db130$81e91390$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oBChVwia-IngjXgJtrsyf0IFFtk Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 05:32:22 -0000 On Fri, Sep 26, 2014 at 11:36:05PM -0400, Susan Hares wrote: > > One question - should I be submitting these I2RS configuration IM/DM as > netmod models? If so, I will do this as well. > Hi, one I-D is enough, multiple I-Ds only create confusion. If you want to make NETMOD people aware of these I2RS I-Ds (probably a good thing), send a short message to the NETMOD mailing list with pointers to the I-Ds. /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 Sep 27 12:58:04 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 696921A0277 for ; Sat, 27 Sep 2014 12:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 JBzghi22EYFN for ; Sat, 27 Sep 2014 12:58:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227931A0208 for ; Sat, 27 Sep 2014 12:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17739; q=dns/txt; s=iport; t=1411847881; x=1413057481; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qIGLReaj6iyaIBVrjvT0JfHBPzotoRSNxkeGiklpchk=; b=JkE1m4STVkz+LpbDA37F3AXqM+lZTzM5e93OhGVDc8PBNHw0GVmniAoM XVOxnNA9RIQVEerGasr6+munweLsG7c6mCHNd9NDwxfSlwQ+tUt6PBRBk gI+tQP6BrTIFhHt4uvOrbP0LLtoPAj8NA3mlhYn/+JeSfM2hgz96Rs0UW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFABwWJ1StJA2D/2dsb2JhbABggkhGU1vIVwEJh04CfBYBe4QDAQEBAwEBAQEaEEELBQcEAgEIDgMDAQEBKAcnCxQJCAIEAQ0FiDYIDb5BARMEjEuDQg0EBwaERQWRZYtDlV2DY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,610,1406592000"; d="scan'208,217";a="358845489" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 27 Sep 2014 19:57:58 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8RJvwcb011352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 19:57:58 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sat, 27 Sep 2014 14:57:58 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Jeffrey Haas'" Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAA== Date: Sat, 27 Sep 2014 19:57:57 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> In-Reply-To: <00b501cfda04$2b4db130$81e91390$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D04C8E0F3B4Faceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/873aRTp72nkc3Hkhd7eKQdlKQ6Q Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 19:58:03 -0000 --_000_D04C8E0F3B4Faceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Susan Hares > Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas > Cc: "i2rs@ietf.org" > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Informati= on models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and= BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have mul= ti-vendor design teams contributing to them. This works is being done in th= e OSPF and ISIS WG groups. You are welcome to review it but please don=92t = create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the = PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-in= fo-model). We hoped to have the agreement on the text early next week (ju= st 1 technical discussion). The author team has had meetings in August an= d September. Please add the use case to the agenda. One question =96 should I be submitting these I2RS configuration IM/DM as n= etmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-= routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-= 00) can be extended into data model. I'll try to submit the draft by the de= adline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draf= t-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas > wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 --_000_D04C8E0F3B4Faceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6413EEF087379A489A6FAB6CA16D9624@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Susan Hares <shares@ndzh.com>
Date: Friday, September 26, 2014 at= 11:36 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: Re: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Jeff:

 

Please add to the agenda the following drafts: I2= RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (B= NP), PBR and BGP.  PBR and BGP will be uploaded next week after some i= nternal review.   

HI Sue,
We are currently have drafts for the OSPF and ISIS YANG models and hav= e multi-vendor design teams contributing to them. This works is being done = in the OSPF and ISIS WG groups. You are welcome to review it but please don= =92t create confusion with alternate drafts. 

Thanks,
Acee 






 

The PBR model is the information model that is a = collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (= draft-hares-i2rs-policy-info-model).   We hoped to have the agree= ment on the text early next week (just 1 technical discussion).   The author team has had meetings in August and Se= ptember.   

 

Please add the use case to the agenda.

 

One question =96 should I be submitting these I2R= S configuration IM/DM as netmod models? If so, I will do this as well.

 

Sue

 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts?

 

Jeff,

 

To kickstart the discussions

 

looking at what is needed in NETMOD and NETCONF f= or I2RS

 

datastore for I2RS (use cases for ephemeral data = store)

 

working on ACL YANG model - with ACL model availa= ble and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft= -kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to = submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-net= mod-routing-cfg-16, being published)

 

Dean

 

On Sep 25, 2014, at 2:00 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

 

> Your chairs have been a bit over-busy recent= ly with travel to unicast

> people doing various bits of chartered work.=   This means we've been

> behind on some of our goals in terms of gett= ing regular design

> sessions running.  I know that at least= a couple calls have happened

> that I've missed that Sue Hares has done, so= some progress is being made.

>

> We've requested a 1 hour time slot for IETF = 91 in Honolulu to give us

> a chance to talk.  This is a call for a= genda slots.

>

> This is also a call for status reports.=

>

> We've had some productive discussion about r= equests to netmod/netconf,

> albeit ones that haven't converged yet.=

>

> What have you been up to?

>

> -- Jeff & Ed

>

> ____________________________________________= ___

> i2rs mailing list

> i2rs@ietf.org

> https://ww= w.ietf.org/mailman/listinfo/i2rs

 

_______________________________________________

i2rs mailing list

i2rs@ietf.org

https://www.iet= f.org/mailman/listinfo/i2rs

 --_000_D04C8E0F3B4Faceeciscocom_-- From nobody Sat Sep 27 13:32: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 CD7B01A02FE for ; Sat, 27 Sep 2014 13:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW8oppfYpMwr for ; Sat, 27 Sep 2014 13:32:14 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4CB1A02D6 for ; Sat, 27 Sep 2014 13:32:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Jeffrey Haas'" References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> In-Reply-To: Date: Sat, 27 Sep 2014 16:32:08 -0400 Message-ID: <003201cfda92$1c49c230$54dd4690$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CFDA70.953A6C20" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIExceRAawuzi4B220d0ZyUq+FQ X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OVYNFWlbAEIfOA-qDNCNBV-Ob3g Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 20:32:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0033_01CFDA70.953A6C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: Was this work announced on any list at IETF for general contribution? I don't see an announcement on the ospf list or the ISIS list? Perhaps you could point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? From: Susan Hares Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have multi-vendor design teams contributing to them. This works is being done in the OSPF and ISIS WG groups. You are welcome to review it but please don't create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model). We hoped to have the agreement on the text early next week (just 1 technical discussion). The author team has had meetings in August and September. Please add the use case to the agenda. One question - should I be submitting these I2RS configuration IM/DM as netmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas < jhaas@pfrc.org> wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 ------=_NextPart_000_0033_01CFDA70.953A6C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

Was this work announced = on any list at IETF for general contribution?  I don’t see an = announcement on the ospf list or the ISIS list?  Perhaps you could = point me to the list where this was announced?

 

Sue =

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem = (acee)
Sent: Saturday, September 27, 2014 3:58 = PM
To: Susan Hares; 'Jeffrey Haas'
Cc: = i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - = call for agenda; status reports?

 

 

=

 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = Re: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

=

Jeff: =

 

Please add to the = agenda the following drafts: I2RS yang Data and Information models for = ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP = will be uploaded next week after some internal review. =   

 

=

HI = Sue,

We are currently have drafts for = the OSPF and ISIS YANG models and have multi-vendor design teams = contributing to them. This works is being done in the OSPF and ISIS WG = groups. You are welcome to review it but please don’t create = confusion with alternate = drafts. 

 

=

Thanks,

Acee 

 

=

 

=

 

=

 

=

 

=

 

=

 

The PBR model is the = information model that is a collaboration between the PBR = (draft-kini-i2rs-pbr-info-model-00) and the = (draft-hares-i2rs-policy-info-model).   We hoped to have the = agreement on the text early next week (just 1 technical discussion). =   The author team has had meetings in August and September. =   

 

Please add the use case = to the agenda.

 

One question – = should I be submitting these I2RS configuration IM/DM as netmod models? = If so, I will do this as well.

 

Sue =

 

-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 = PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] = IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff,

 

To kickstart the = discussions

 

looking at what is = needed in NETMOD and NETCONF for I2RS

 

datastore for I2RS (use = cases for ephemeral data store)

 

working on ACL YANG = model - with ACL model available and draft-ietf-netmod-routing-cfg-15 = being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be = extended into data model. I'll try to submit the draft by the deadline = (it is dependent on new draft-ietf-netmod-routing-cfg, probably = draft-ietf-netmod-routing-cfg-16, being = published)

 

Dean

 

On Sep 25, 2014, at = 2:00 PM, Jeffrey Haas <jhaas@pfrc.org= > wrote:

 

> Your chairs have = been a bit over-busy recently with travel to unicast =

> people doing various bits of chartered = work.  This means we've been

> behind on some of = our goals in terms of getting regular design

> sessions = running.  I know that at least a couple calls have happened =

> that I've missed that Sue Hares has done, so = some progress is being made.

> =

> We've requested a 1 hour time slot for IETF = 91 in Honolulu to give us

> a chance to = talk.  This is a call for agenda slots.

> =

> This is also a call for status = reports.

>

> We've had some = productive discussion about requests to netmod/netconf, =

> albeit ones that haven't converged = yet.

>

> What have you been = up to?

>

> -- Jeff & = Ed

>

> = _______________________________________________

> i2rs mailing = list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

 

_______________________________________________

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0033_01CFDA70.953A6C20-- From nobody Sat Sep 27 14:06: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 DA5661A0322 for ; Sat, 27 Sep 2014 14:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 kSPXjioCbCyY for ; Sat, 27 Sep 2014 14:06:29 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ED11A0317 for ; Sat, 27 Sep 2014 14:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22169; q=dns/txt; s=iport; t=1411851989; x=1413061589; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gTvyvgTYOjiTIpuftibPGfJK2Qwuck4oid8La4bOttg=; b=d5J6aWUEDzKYG+N+cilzT/FWc696xfRu3ZOmZzBdH2n4tr/gKnkraRQ7 WIvbDtFLsVy/nSzDFycmHDfg1PGFCS5mXOzc7B/LlFAOcCNJt9UNuZnAY bYfWDaB64fhj7HJiqI3BD85VgIUffxMnKPLS9sDq6mA6ieYitfKFyP3m/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhELAJUlJ1StJV2d/2dsb2JhbABggkhGU1uEGcQ+AQmHTgJ8FgF7hAMBAQECAQEBAQEaEEELBQcEAgEIDgMDAQEBIQcHJwsUCQgCBAENBQmILQgNvjoBF4xLgzERDQQGAQaERQWRZYtDlV2DY2wBgUeBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,610,1406592000"; d="scan'208,217"; a="81914696" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 27 Sep 2014 21:06:28 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8RL6STG009566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 21:06:28 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sat, 27 Sep 2014 16:06:28 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Jeffrey Haas'" Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwA= Date: Sat, 27 Sep 2014 21:06:27 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> In-Reply-To: <003201cfda92$1c49c230$54dd4690$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D04C9D5E3B5Baceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/47pmfzAEOrIsEnXIOBnCtiXvsGk Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 21:06:32 -0000 --_000_D04C9D5E3B5Baceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were pr= esented at IETF 90 in Toronto. We intend to cross review the OSPF YANG mode= l in both the netmod and OSPF WGs. The ISIS YANG Model is already being acc= epted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares > Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: Was this work announced on any list at IETF for general contribution? I do= n=92t see an announcement on the ospf list or the ISIS list? Perhaps you c= ould point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? From: Susan Hares > Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas > Cc: "i2rs@ietf.org" > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Informati= on models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and= BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have mul= ti-vendor design teams contributing to them. This works is being done in th= e OSPF and ISIS WG groups. You are welcome to review it but please don=92t = create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the = PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-in= fo-model). We hoped to have the agreement on the text early next week (ju= st 1 technical discussion). The author team has had meetings in August an= d September. Please add the use case to the agenda. One question =96 should I be submitting these I2RS configuration IM/DM as n= etmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-= routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-= 00) can be extended into data model. I'll try to submit the draft by the de= adline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draf= t-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas > wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 --_000_D04C9D5E3B5Baceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <81D5BB4AF8AF134DB33F885F1EA24A3F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sue: 

Did you look at the archives for the OSPF and ISIS WGs? Both drafts we= re presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG= model in both the netmod and OSPF WGs. The ISIS YANG Model is already bein= g accepted as an ISIS WG document. 

http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf
http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf

Acee 

From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 = at 4:32 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: RE: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Acee:

 

Was this work announce= d on any list at IETF for general contribution?  I don=92t see an anno= uncement on the ospf list or the ISIS list?  Perhaps you could point m= e to the list where this was announced?

 

Sue =

 

 

From: i2rs [mai= lto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 

&n= bsp;

&n= bsp;

From: Susan Hares <= shares@ndzh.com>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

&n= bsp;

Jeff:

 

Please add to the age= nda the following drafts: I2RS yang Data and Information models for ISIS, O= SPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP will be upl= oaded next week after some internal review.   

&n= bsp;

HI Sue,=

We are = currently have drafts for the OSPF and ISIS YANG models and have multi-vend= or design teams contributing to them. This works is being done in the OSPF = and ISIS WG groups. You are welcome to review it but please don=92t create confusion with alternate drafts.&nb= sp;

&n= bsp;

Thanks,=

Acee&nb= sp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

 

The PBR model is the = information model that is a collaboration between the PBR (draft-kini-i2rs-= pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model).  &nbs= p;We hoped to have the agreement on the text early next week (just 1 technical discussion).   The author team has h= ad meetings in August and September.   

 

Please add the use ca= se to the agenda.

 

One question =96 shou= ld I be submitting these I2RS configuration IM/DM as netmod models? If so, = I will do this as well.

 

Sue

 

-----Original Message= -----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts?

 

Jeff,

 

To kickstart the disc= ussions

 

looking at what is ne= eded in NETMOD and NETCONF for I2RS

 

datastore for I2RS (u= se cases for ephemeral data store)

 

working on ACL YANG m= odel - with ACL model available and draft-ietf-netmod-routing-cfg-15 being = fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended i= nto data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cf= g, probably draft-ietf-netmod-routing-cfg-16, being published)

 

Dean

 

On Sep 25, 2014, at 2= :00 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= o:p>

 

> Your chairs have= been a bit over-busy recently with travel to unicast

> people doing var= ious bits of chartered work.  This means we've been

> behind on some o= f our goals in terms of getting regular design

> sessions running= .  I know that at least a couple calls have happened

> that I've missed= that Sue Hares has done, so some progress is being made.=

>

> We've requested = a 1 hour time slot for IETF 91 in Honolulu to give us

> a chance to talk= .  This is a call for agenda slots.

>

> This is also a c= all for status reports.

>

> We've had some p= roductive discussion about requests to netmod/netconf,

> albeit ones that= haven't converged yet.

>

> What have you be= en up to?

>

> -- Jeff & Ed=

>

> ________________= _______________________________

> i2rs mailing lis= t

> i2rs@ietf.org<= /a>

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

 

_____________________= __________________________

i2rs mailing list

i2rs@ietf= .org

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

 --_000_D04C9D5E3B5Baceeciscocom_-- From nobody Sat Sep 27 15:16: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 B8A3A1A036C for ; Sat, 27 Sep 2014 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoK21ElRER9u for ; Sat, 27 Sep 2014 15:16:40 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 94E761A0364 for ; Sat, 27 Sep 2014 15:16:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Jeffrey Haas'" References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> In-Reply-To: Date: Sat, 27 Sep 2014 18:16:33 -0400 Message-ID: <005401cfdaa0$b297d070$17c77150$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CFDA7F.2B8916A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIExceRAawuzi4B220d0QGawMRBAmrMpwWcdI7U8A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/73-3cFBkflK3hkq0sTX1J3IONuE Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 22:16:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CFDA7F.2B8916A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: I'm confused by this email thread because these slides state the authors are looking for co-authors for netmod drafts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft? Would you point me to the email that indicates the WG Adoption call and conclusion? The drafts I suggested are I2RS drafts for the I2RS datastore that allow it to configure the routing agent directly. The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) works. It is unclear if it will work - that's under discussion. There is no reason to stop the I2RS DM/IM models required by I2RS charter work while we find out if option 4 works. And out of curiosity, if we are now considering option 4 why don't you want more input and collaboration that provides insight from people who looked at the OSPF for the I2RS use that option 4 suggests? We have complete IM and DM (yang compiled) for the configuration we thought was necessary for I2RS if the agent talked directly to the routing process (the assumption of all I2RS with unique data store). Sue PS - the ISIS Draft is not listed as approved or listed on the ISIS mail list as approved. It has not been updated since 6/27/14. If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 5:06 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in both the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem , Jeff Haas Cc: "i2rs@ietf.org" Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Acee: Was this work announced on any list at IETF for general contribution? I don't see an announcement on the ospf list or the ISIS list? Perhaps you could point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? From: Susan Hares Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have multi-vendor design teams contributing to them. This works is being done in the OSPF and ISIS WG groups. You are welcome to review it but please don't create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model). We hoped to have the agreement on the text early next week (just 1 technical discussion). The author team has had meetings in August and September. Please add the use case to the agenda. One question - should I be submitting these I2RS configuration IM/DM as netmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas < jhaas@pfrc.org> wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 ------=_NextPart_000_0055_01CFDA7F.2B8916A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

I’m confused by this email thread = because these slides state the authors are looking for co-authors for = netmod drafts. Are you as the co-chair of OSPF declaring consensus on = the OSPF yang model draft? Would you point me to the email that = indicates the WG Adoption call and conclusion?

 

The drafts I suggested are I2RS drafts for = the I2RS datastore that allow it to configure the routing agent = directly. The only way these two drafts interact is if the option 4 = proposed by the Yang 1.1 interim (created 9/19/14) works.  It is = unclear if it will work – that’s under discussion. There is = no reason to stop the I2RS DM/IM models required by I2RS charter work = while we find out if option 4 works.

 

And out of curiosity, if we are now = considering option 4 why don’t you want more input and = collaboration that provides insight from people who looked at the OSPF = for the I2RS use that option 4 suggests?  We have complete IM and = DM (yang compiled) for the configuration we thought was necessary for = I2RS if the agent talked directly to the routing process (the assumption = of all I2RS with unique data store).  

 

Sue

 

PS = – the ISIS Draft is not listed as approved or listed on the ISIS = mail list as approved. It has not been updated since 6/27/14.  If = you believe it should be listed that way, you might want to talk to the = ISIS co-chairs.

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, = September 27, 2014 5:06 PM
To: Susan Hares; 'Jeffrey = Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 = meeting requested - call for agenda; status = reports?

 

Sue: 

 

=

Did you look at the archives for = the OSPF and ISIS WGs? Both drafts were presented at IETF 90 in Toronto. = We intend to cross review the OSPF YANG model in both the netmod and = OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG = document. 

 

=

 

=

Acee 

 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem = <acee@cisco.com>, Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = RE: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

=

Acee:

 

Was this work announced on any list at IETF for = general contribution?  I don’t see an announcement on the = ospf list or the ISIS list?  Perhaps you could point me to the list = where this was announced?

 

Sue

 

 

= From:= i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Acee Lindem (acee)
Sent: Saturday, = September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey = Haas'
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

 

 

From: = Susan Hares <shares@ndzh.com>
Date: = Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = Re: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff: =

 

Please add to the = agenda the following drafts: I2RS yang Data and Information models for = ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP = will be uploaded next week after some internal review. =   

 

HI = Sue,

We are = currently have drafts for the OSPF and ISIS YANG models and have = multi-vendor design teams contributing to them. This works is being done = in the OSPF and ISIS WG groups. You are welcome to review it but please = don’t create confusion with alternate drafts. 

 

Thanks,

Acee 

 

 

 

 

 

 

 

The PBR model is the = information model that is a collaboration between the PBR = (draft-kini-i2rs-pbr-info-model-00) and the = (draft-hares-i2rs-policy-info-model).   We hoped to have the = agreement on the text early next week (just 1 technical discussion). =   The author team has had meetings in August and September. =   

 

Please add the use case = to the agenda.

 

One question – = should I be submitting these I2RS configuration IM/DM as netmod models? = If so, I will do this as well.

 

Sue =

 

-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 = PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] = IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff,

 

To kickstart the = discussions

 

looking at what is = needed in NETMOD and NETCONF for I2RS

 

datastore for I2RS (use = cases for ephemeral data store)

 

working on ACL YANG = model - with ACL model available and draft-ietf-netmod-routing-cfg-15 = being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be = extended into data model. I'll try to submit the draft by the deadline = (it is dependent on new draft-ietf-netmod-routing-cfg, probably = draft-ietf-netmod-routing-cfg-16, being = published)

 

Dean

 

On Sep 25, 2014, at = 2:00 PM, Jeffrey Haas <jhaas@pfrc.org= > wrote:

 

> Your chairs have = been a bit over-busy recently with travel to unicast =

> people doing various bits of chartered = work.  This means we've been

> behind on some of = our goals in terms of getting regular design

> sessions = running.  I know that at least a couple calls have happened =

> that I've missed that Sue Hares has done, so = some progress is being made.

> =

> We've requested a 1 hour time slot for IETF = 91 in Honolulu to give us

> a chance to = talk.  This is a call for agenda slots.

> =

> This is also a call for status = reports.

>

> We've had some = productive discussion about requests to netmod/netconf, =

> albeit ones that haven't converged = yet.

>

> What have you been = up to?

>

> -- Jeff & = Ed

>

> = _______________________________________________

> i2rs mailing = list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

 

_______________________________________________

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0055_01CFDA7F.2B8916A0-- From nobody Sat Sep 27 15:32: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 B45921A0055 for ; Sat, 27 Sep 2014 15:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 bg76bVnn8Ctx for ; Sat, 27 Sep 2014 15:32:24 -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 10AD41A0018 for ; Sat, 27 Sep 2014 15:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34366; q=dns/txt; s=iport; t=1411857144; x=1413066744; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oIufEmLQcSXvbmH24eaDFr9IXfhaTdwhfcWLBUKMFgI=; b=OlOjIS8mIZPQENEPA1ID28SYj4L2hqHhcaPXEdnYMlF+6ahX/I0O4Qi1 VjP1J6HVFM/7YG+yrHKq2876XSpujQXE3ridyokn+1Mkeh8S/oGoNUx44 qvuIrIBlwedcpt5lW7Q8aj9B+IOHR6eHfaF8l8kFtiao2M16WFmKQsxFs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAPs5J1StJA2H/2dsb2JhbABfgkhGU1vIVwEJh04CfBYBe4QDAQEBAgEBAQEBGhBBCwUHBAIBCA4DAwEBASEBBgcnCxQJCAIEAQ0FCYgtCA2+IgEXjEuCcRACAS0RDQQGAQaERQWRZYtDlV2DY2wBgUeBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,610,1406592000"; d="scan'208,217"; a="81935399" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP; 27 Sep 2014 22:32:22 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8RMWMnH030202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 22:32:22 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sat, 27 Sep 2014 17:32:22 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Jeffrey Haas'" Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqA Date: Sat, 27 Sep 2014 22:32:21 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> In-Reply-To: <005401cfdaa0$b297d070$17c77150$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D04CB1B43B84aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/k6joDgbJs9Lg-lqkUhGaYx7Pn0Q Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 22:32:26 -0000 --_000_D04CB1B43B84aceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Susan Hares > Date: Saturday, September 27, 2014 at 6:16 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: I=92m confused by this email thread because these slides state the authors = are looking for co-authors for netmod drafts. Are you as the co-chair of OS= PF declaring consensus on the OSPF yang model draft? Yes =96 and there are now multi-vendor design teams in place. Would you point me to the email that indicates the WG Adoption call and con= clusion? We haven=92t adopted yet in OSPF. ISIS adoption is in progress. I already s= earched the proceedings for the presentations. Note that the list archives = offer a search capability=85 Anyway, here is the ISIS message: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html The drafts I suggested are I2RS drafts for the I2RS datastore that allow it= to configure the routing agent directly. The only way these two drafts int= eract is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14)= works. It is unclear if it will work =96 that=92s under discussion. There= is no reason to stop the I2RS DM/IM models required by I2RS charter work w= hile we find out if option 4 works. And out of curiosity, if we are now considering option 4 why don=92t you wa= nt more input and collaboration that provides insight from people who looke= d at the OSPF for the I2RS use that option 4 suggests? We have complete IM= and DM (yang compiled) for the configuration we thought was necessary for = I2RS if the agent talked directly to the routing process (the assumption of= all I2RS with unique data store). Please review the OSPF and ISIS drafts with respect to option 4. Thanks, Acee Sue PS =96 the ISIS Draft is not listed as approved or listed on the ISIS mail = list as approved. It has not been updated since 6/27/14. If you believe it= should be listed that way, you might want to talk to the ISIS co-chairs. From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 5:06 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were pr= esented at IETF 90 in Toronto. We intend to cross review the OSPF YANG mode= l in both the netmod and OSPF WGs. The ISIS YANG Model is already being acc= epted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares > Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: Was this work announced on any list at IETF for general contribution? I do= n=92t see an announcement on the ospf list or the ISIS list? Perhaps you c= ould point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? From: Susan Hares > Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas > Cc: "i2rs@ietf.org" > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Informati= on models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and= BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have mul= ti-vendor design teams contributing to them. This works is being done in th= e OSPF and ISIS WG groups. You are welcome to review it but please don=92t = create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the = PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-in= fo-model). We hoped to have the agreement on the text early next week (ju= st 1 technical discussion). The author team has had meetings in August an= d September. Please add the use case to the agenda. One question =96 should I be submitting these I2RS configuration IM/DM as n= etmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-= routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-= 00) can be extended into data model. I'll try to submit the draft by the de= adline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draf= t-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas > wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 --_000_D04CB1B43B84aceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 = at 6:16 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: RE: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Acee:

 

I=92m confused by this email thread becau= se these slides state the authors are looking for co-authors for netmod dra= fts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft?


Yes =96 and there are now multi-vendor design teams in place. 


Would you point me to the email that indi= cates the WG Adoption call and conclusion?

We haven=92t adopted yet in OSPF. ISIS adoption is in progress. I alre= ady searched the proceedings for the presentations. Note that the list arch= ives offer a search capability=85 Anyway, here is the ISIS message:

http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html


 

The drafts I suggested are I2RS drafts fo= r the I2RS datastore that allow it to configure the routing agent directly.= The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) work= s.  It is unclear if it will work =96 that=92s under discussion. There= is no reason to stop the I2RS DM/IM models required by I2RS charter work w= hile we find out if option 4 works.

 

And out of curiosity, if we are now consi= dering option 4 why don=92t you want more input and collaboration that prov= ides insight from people who looked at the OSPF for the I2RS use that option 4 suggests?  We have complete I= M and DM (yang compiled) for the configuration we thought was necessary for= I2RS if the agent talked directly to the routing process (the assumption o= f all I2RS with unique data store).  

Please review the OSPF and ISIS drafts with respect to option 4.

Thanks,
Acee 




 

Sue

 

PS =96 the ISIS Draft is not listed as approved or list= ed on the ISIS mail list as approved. It has not been updated since 6/27/14= .  If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. =

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 5:06 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 

Sue:&nb= sp;

&n= bsp;

Did you= look at the archives for the OSPF and ISIS WGs? Both drafts were presented= at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in bo= th the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document. 

&n= bsp;

&n= bsp;

Acee&nb= sp;

&n= bsp;

From: Susan Hares <= shares@ndzh.com>
Date: Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

&n= bsp;

Acee:

 

Was this work announce= d on any list at IETF for general contribution?  I don=92t see an anno= uncement on the ospf list or the ISIS list?  Perhaps you could point m= e to the list where this was announced?

 

Sue

 

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 =

 <= /span>

 <= /span>

From: Susan Hares <= shares@ndzh.com>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 <= /span>

Jeff:

 

Please add to the age= nda the following drafts: I2RS yang Data and Information models for ISIS, O= SPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP will be upl= oaded next week after some internal review.   

 <= /span>

HI Sue,=

We are = currently have drafts for the OSPF and ISIS YANG models and have multi-vend= or design teams contributing to them. This works is being done in the OSPF = and ISIS WG groups. You are welcome to review it but please don=92t create confusion with alternate drafts.&nb= sp;

 <= /span>

Thanks,=

Acee&nb= sp;

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 

The PBR model is the = information model that is a collaboration between the PBR (draft-kini-i2rs-= pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model).  &nbs= p;We hoped to have the agreement on the text early next week (just 1 technical discussion).   The author team has h= ad meetings in August and September.   

 

Please add the use ca= se to the agenda.

 

One question =96 shou= ld I be submitting these I2RS configuration IM/DM as netmod models? If so, = I will do this as well.

 

Sue

 

-----Original Message= -----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts?

 

Jeff,

 

To kickstart the disc= ussions

 

looking at what is ne= eded in NETMOD and NETCONF for I2RS

 

datastore for I2RS (u= se cases for ephemeral data store)

 

working on ACL YANG m= odel - with ACL model available and draft-ietf-netmod-routing-cfg-15 being = fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended i= nto data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cf= g, probably draft-ietf-netmod-routing-cfg-16, being published)

 

Dean

 

On Sep 25, 2014, at 2= :00 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= o:p>

 

> Your chairs have= been a bit over-busy recently with travel to unicast

> people doing var= ious bits of chartered work.  This means we've been

> behind on some o= f our goals in terms of getting regular design

> sessions running= .  I know that at least a couple calls have happened

> that I've missed= that Sue Hares has done, so some progress is being made.=

>

> We've requested = a 1 hour time slot for IETF 91 in Honolulu to give us

> a chance to talk= .  This is a call for agenda slots.

>

> This is also a c= all for status reports.

>

> We've had some p= roductive discussion about requests to netmod/netconf,

> albeit ones that= haven't converged yet.

>

> What have you be= en up to?

>

> -- Jeff & Ed=

>

> ________________= _______________________________

> i2rs mailing lis= t

> i2rs@ietf.org<= /a>

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

 

_____________________= __________________________

i2rs mailing list

i2rs@ietf= .org

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

 --_000_D04CB1B43B84aceeciscocom_-- From nobody Sat Sep 27 16:22: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 77D0D1A0063 for ; Sat, 27 Sep 2014 16:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WErI7CSDI5l for ; Sat, 27 Sep 2014 16:22:40 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 17F271A005D for ; Sat, 27 Sep 2014 16:22:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Jeffrey Haas'" References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> In-Reply-To: Date: Sat, 27 Sep 2014 19:22:33 -0400 Message-ID: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CFDA88.63AD8F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIExceRAawuzi4B220d0QGawMRBAmrMpwUAsW5G1gKFCejBnFr6SVA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/MiRMwVh8FH0qJBg4PpSUad6CLRw Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 23:22:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CFDA88.63AD8F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: Thank you for the pointer to the message in ISIS. Perhaps since Chris just declared consensus Friday the 9/19/14 that he will get around to posting these drafts. To be clear, I understand from your work that you are declaring consensus on the yang models for OSPF model based on your knowledge of the private multi-vendor design team. You are stating at the OSPF chair that those models have the front seat in looking at the I2RS models without reading any of the I2RS IM/DM drafts we have prepared. Please confirm that I understand this message so that I can determine the next steps to take with these drafts. Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 6:32 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports From: Susan Hares Date: Saturday, September 27, 2014 at 6:16 PM To: Acee Lindem , Jeff Haas Cc: "i2rs@ietf.org" Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Acee: I'm confused by this email thread because these slides state the authors are looking for co-authors for netmod drafts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft? Yes - and there are now multi-vendor design teams in place. Would you point me to the email that indicates the WG Adoption call and conclusion? We haven't adopted yet in OSPF. ISIS adoption is in progress. I already searched the proceedings for the presentations. Note that the list archives offer a search capability. Anyway, here is the ISIS message: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html The drafts I suggested are I2RS drafts for the I2RS datastore that allow it to configure the routing agent directly. The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) works. It is unclear if it will work - that's under discussion. There is no reason to stop the I2RS DM/IM models required by I2RS charter work while we find out if option 4 works. And out of curiosity, if we are now considering option 4 why don't you want more input and collaboration that provides insight from people who looked at the OSPF for the I2RS use that option 4 suggests? We have complete IM and DM (yang compiled) for the configuration we thought was necessary for I2RS if the agent talked directly to the routing process (the assumption of all I2RS with unique data store). Please review the OSPF and ISIS drafts with respect to option 4. Thanks, Acee Sue PS - the ISIS Draft is not listed as approved or listed on the ISIS mail list as approved. It has not been updated since 6/27/14. If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 5:06 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in both the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem , Jeff Haas Cc: "i2rs@ietf.org" Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Acee: Was this work announced on any list at IETF for general contribution? I don't see an announcement on the ospf list or the ISIS list? Perhaps you could point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? From: Susan Hares Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have multi-vendor design teams contributing to them. This works is being done in the OSPF and ISIS WG groups. You are welcome to review it but please don't create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model). We hoped to have the agreement on the text early next week (just 1 technical discussion). The author team has had meetings in August and September. Please add the use case to the agenda. One question - should I be submitting these I2RS configuration IM/DM as netmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas < jhaas@pfrc.org> wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 ------=_NextPart_000_000D_01CFDA88.63AD8F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

Thank you for the = pointer to the message in ISIS.  Perhaps since Chris just declared = consensus Friday the 9/19/14 that he will get around to posting these = drafts.

 

To be clear, I = understand from your work that you are declaring consensus on the yang = models for OSPF model based on your knowledge of the private = multi-vendor design team.  You are stating at the OSPF chair that = those models have the front seat in looking at the I2RS models without = reading any of the I2RS IM/DM drafts we have prepared.  Please = confirm that I understand this message so that I can determine the next = steps to take with these drafts.

 

Sue =

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, = September 27, 2014 6:32 PM
To: Susan Hares; 'Jeffrey = Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 = meeting requested - call for agenda; status = reports

 

=

 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Saturday, September 27, 2014 at 6:16 PM
To: Acee Lindem = <acee@cisco.com>, Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = RE: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

=

Acee:

 

I’m confused by this email thread = because these slides state the authors are looking for co-authors for = netmod drafts. Are you as the co-chair of OSPF declaring consensus on = the OSPF yang model draft?

 

=

Yes – and there are now = multi-vendor design teams in = place. 

 

=

 

=

Would you point me to the email that = indicates the WG Adoption call and conclusion?

 

=

We haven’t adopted yet in = OSPF. ISIS adoption is in progress. I already searched the proceedings = for the presentations. Note that the list archives offer a search = capability… Anyway, here is the ISIS = message:

 

=

 

=

 

=

 

The drafts I suggested are I2RS drafts for = the I2RS datastore that allow it to configure the routing agent = directly. The only way these two drafts interact is if the option 4 = proposed by the Yang 1.1 interim (created 9/19/14) works.  It is = unclear if it will work – that’s under discussion. There is = no reason to stop the I2RS DM/IM models required by I2RS charter work = while we find out if option 4 works.

 

And out of curiosity, if we are now = considering option 4 why don’t you want more input and = collaboration that provides insight from people who looked at the OSPF = for the I2RS use that option 4 suggests?  We have complete IM and = DM (yang compiled) for the configuration we thought was necessary for = I2RS if the agent talked directly to the routing process (the assumption = of all I2RS with unique data store).  

 

=

Please review the OSPF and ISIS = drafts with respect to option 4.

 

=

Thanks,

Acee 

 

=

 

=

 

=

 

=

 

Sue

 

PS – the ISIS Draft is not listed as = approved or listed on the ISIS mail list as approved. It has not been = updated since 6/27/14.  If you believe it should be listed that = way, you might want to talk to the ISIS co-chairs.

 

= From:= Acee Lindem (acee) [mailto:acee@cisco.com] =
Sent: Saturday, September 27, 2014 5:06 PM
To: = Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Sue: 

 

Did you = look at the archives for the OSPF and ISIS WGs? Both drafts were = presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG = model in both the netmod and OSPF WGs. The ISIS YANG Model is already = being accepted as an ISIS WG document. 

 

 

Acee 

 

From: = Susan Hares <shares@ndzh.com>
Date: = Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem = <acee@cisco.com>, Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = RE: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Acee:

 

Was this work announced on any list at IETF for = general contribution?  I don’t see an announcement on the = ospf list or the ISIS list?  Perhaps you could point me to the list = where this was announced?

 

Sue

 

 

= From:= i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Acee Lindem (acee)
Sent: Saturday, = September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey = Haas'
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

 

 

From: = Susan Hares <shares@ndzh.com>
Date: = Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = Re: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff: =

 

Please add to the = agenda the following drafts: I2RS yang Data and Information models for = ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP = will be uploaded next week after some internal review. =   

 

HI = Sue,

We are = currently have drafts for the OSPF and ISIS YANG models and have = multi-vendor design teams contributing to them. This works is being done = in the OSPF and ISIS WG groups. You are welcome to review it but please = don’t create confusion with alternate drafts. 

 

Thanks,

Acee 

 

 

 

 

 

 

 

The PBR model is the = information model that is a collaboration between the PBR = (draft-kini-i2rs-pbr-info-model-00) and the = (draft-hares-i2rs-policy-info-model).   We hoped to have the = agreement on the text early next week (just 1 technical discussion). =   The author team has had meetings in August and September. =   

 

Please add the use case = to the agenda.

 

One question – = should I be submitting these I2RS configuration IM/DM as netmod models? = If so, I will do this as well.

 

Sue =

 

-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 = PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] = IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff,

 

To kickstart the = discussions

 

looking at what is = needed in NETMOD and NETCONF for I2RS

 

datastore for I2RS (use = cases for ephemeral data store)

 

working on ACL YANG = model - with ACL model available and draft-ietf-netmod-routing-cfg-15 = being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be = extended into data model. I'll try to submit the draft by the deadline = (it is dependent on new draft-ietf-netmod-routing-cfg, probably = draft-ietf-netmod-routing-cfg-16, being = published)

 

Dean

 

On Sep 25, 2014, at = 2:00 PM, Jeffrey Haas <jhaas@pfrc.org= > wrote:

 

> Your chairs have = been a bit over-busy recently with travel to unicast =

> people doing various bits of chartered = work.  This means we've been

> behind on some of = our goals in terms of getting regular design

> sessions = running.  I know that at least a couple calls have happened =

> that I've missed that Sue Hares has done, so = some progress is being made.

> =

> We've requested a 1 hour time slot for IETF = 91 in Honolulu to give us

> a chance to = talk.  This is a call for agenda slots.

> =

> This is also a call for status = reports.

>

> We've had some = productive discussion about requests to netmod/netconf, =

> albeit ones that haven't converged = yet.

>

> What have you been = up to?

>

> -- Jeff & = Ed

>

> = _______________________________________________

> i2rs mailing = list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

 

_______________________________________________

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_000D_01CFDA88.63AD8F80-- From nobody Sat Sep 27 16:37: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 634241A006A for ; Sat, 27 Sep 2014 16:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 7yG13xG0UuUo for ; Sat, 27 Sep 2014 16:37:24 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C00A1A0069 for ; Sat, 27 Sep 2014 16:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45074; q=dns/txt; s=iport; t=1411861045; x=1413070645; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eOQRb6rOIFlmngt5Rio+nifwiM8pahO7O1rpZClA0wM=; b=WcW6YWAbqeiqKblzgtGUXIuOHJfPtCsj3nqLaEJWiU7hnGqjxckUuX/R JG+X9ZXPhgZCfIzY+MxM02sQimFcZQb9OG5+NG4QJSZm4bObTRC/WA5gm IiAuYvsFeu/r9230P0HiSZDfiPHumSPlfmFsa2iCA5INEqHT7gnXMxjay w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFADZJJ1StJV2S/2dsb2JhbABggkhGU1cEyFgBCYdOAnsWAXuEAwEBAQIBAQEBARoQQQsFBwQCAQgOAwMBAQEhAQYHJwsUCQgCBAENBQmILQgNvigBF4xLgnEQAgEtEQ0EBgEGhEUFkWWEOocJlV2DY2wBgUeBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,611,1406592000"; d="scan'208,217"; a="81931045" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP; 27 Sep 2014 23:37:24 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8RNbMlR019294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 27 Sep 2014 23:37:23 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 27 Sep 2014 18:37:22 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Jeffrey Haas'" Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqAgABRF4D//8ETAA== Date: Sat, 27 Sep 2014 23:37:22 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> In-Reply-To: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D04CC0173B94aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/q_UmWtzlU28IP_Waz1q5tdBsMVo Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 27 Sep 2014 23:37:28 -0000 --_000_D04CC0173B94aceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Susan Hares > Date: Saturday, September 27, 2014 at 7:22 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: Thank you for the pointer to the message in ISIS. Perhaps since Chris just= declared consensus Friday the 9/19/14 that he will get around to posting t= hese drafts. I=92m not sure why you are suggesting that these drafts have not been previ= ously posted. https://datatracker.ietf.org/doc/draft-litkowski-isis-yang-isis-cfg/ https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/ To be clear, I understand from your work that you are declaring consensus o= n the yang models for OSPF model based on your knowledge of the private mul= ti-vendor design team. As you noted, both the presentations at IETF 90 called for participation. T= hese design teams are much less private than the OSPF/ISIS IM/DM drafts you= submitted yesterday. You are stating at the OSPF chair that those models have the front seat in = looking at the I2RS models without reading any of the I2RS IM/DM drafts we = have prepared. The work on the OSPF and ISIS YANG models pre-dated the drafts you have sub= mitted yesterday by quite some time so I don=92t see we should consider rep= lacing it. Please confirm that I understand this message so that I can determine the = next steps to take with these drafts. Your next step should be to review the OSPF/ISIS drafts. Thanks,A Acee Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 6:32 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts From: Susan Hares > Date: Saturday, September 27, 2014 at 6:16 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: I=92m confused by this email thread because these slides state the authors = are looking for co-authors for netmod drafts. Are you as the co-chair of OS= PF declaring consensus on the OSPF yang model draft? Yes =96 and there are now multi-vendor design teams in place. Would you point me to the email that indicates the WG Adoption call and con= clusion? We haven=92t adopted yet in OSPF. ISIS adoption is in progress. I already s= earched the proceedings for the presentations. Note that the list archives = offer a search capability=85 Anyway, here is the ISIS message: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html The drafts I suggested are I2RS drafts for the I2RS datastore that allow it= to configure the routing agent directly. The only way these two drafts int= eract is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14)= works. It is unclear if it will work =96 that=92s under discussion. There= is no reason to stop the I2RS DM/IM models required by I2RS charter work w= hile we find out if option 4 works. And out of curiosity, if we are now considering option 4 why don=92t you wa= nt more input and collaboration that provides insight from people who looke= d at the OSPF for the I2RS use that option 4 suggests? We have complete IM= and DM (yang compiled) for the configuration we thought was necessary for = I2RS if the agent talked directly to the routing process (the assumption of= all I2RS with unique data store). Please review the OSPF and ISIS drafts with respect to option 4. Thanks, Acee Sue PS =96 the ISIS Draft is not listed as approved or listed on the ISIS mail = list as approved. It has not been updated since 6/27/14. If you believe it= should be listed that way, you might want to talk to the ISIS co-chairs. From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 5:06 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were pr= esented at IETF 90 in Toronto. We intend to cross review the OSPF YANG mode= l in both the netmod and OSPF WGs. The ISIS YANG Model is already being acc= epted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares > Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: Was this work announced on any list at IETF for general contribution? I do= n=92t see an announcement on the ospf list or the ISIS list? Perhaps you c= ould point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? From: Susan Hares > Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas > Cc: "i2rs@ietf.org" > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Informati= on models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and= BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have mul= ti-vendor design teams contributing to them. This works is being done in th= e OSPF and ISIS WG groups. You are welcome to review it but please don=92t = create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the = PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-in= fo-model). We hoped to have the agreement on the text early next week (ju= st 1 technical discussion). The author team has had meetings in August an= d September. Please add the use case to the agenda. One question =96 should I be submitting these I2RS configuration IM/DM as n= etmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-= routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-= 00) can be extended into data model. I'll try to submit the draft by the de= adline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draf= t-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas > wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 --_000_D04CC0173B94aceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 = at 7:22 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: RE: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Acee:

 

Thank you for the poin= ter to the message in ISIS.  Perhaps since Chris just declared consens= us Friday the 9/19/14 that he will get around to posting these drafts.

I=92m not sure why you are suggesting that these drafts have not been = previously posted. 

https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/



 

To be clear, I underst= and from your work that you are declaring consensus on the yang models for = OSPF model based on your knowledge of the private multi-vendor design team.=  

As you noted, both the presentations at IETF 90 called for participati= on. These design teams are much less private than the OSPF/ISIS IM/DM draft= s you submitted yesterday. 

You are stating at the= OSPF chair that those models have the front seat in looking at the I2RS mo= dels without reading any of the I2RS IM/DM drafts we have prepared.<= /p>


The work on the OSPF and ISIS YANG models pre-dated the drafts you hav= e submitted yesterday by quite some time so I don=92t see we should conside= r replacing it. 

 Please confirm t= hat I understand this message so that I can determine the next steps to tak= e with these drafts.

Your next step should be to review the OSPF/ISIS drafts. 

Thanks,A
Acee 



 

Sue =

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 6:32 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports

&n= bsp;

&n= bsp;

From: Susan Hares <= shares@ndzh.com>
Date: Saturday, September 27, 2014 at 6:16 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

&n= bsp;

Acee:<= o:p>

 =

I=92m confused by this email thread becau= se these slides state the authors are looking for co-authors for netmod dra= fts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft?

&n= bsp;

Yes =96= and there are now multi-vendor design teams in place. 

&n= bsp;

&n= bsp;

Would you point me to the email that indi= cates the WG Adoption call and conclusion?

&n= bsp;

We have= n=92t adopted yet in OSPF. ISIS adoption is in progress. I already searched= the proceedings for the presentations. Note that the list archives offer a= search capability=85 Anyway, here is the ISIS message:

&n= bsp;

&n= bsp;

&n= bsp;

 =

The drafts I suggested are I2RS drafts fo= r the I2RS datastore that allow it to configure the routing agent directly.= The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) work= s.  It is unclear if it will work =96 that=92s under discussion. There= is no reason to stop the I2RS DM/IM models required by I2RS charter work w= hile we find out if option 4 works.

 =

And out of curiosity, if we are now consi= dering option 4 why don=92t you want more input and collaboration that prov= ides insight from people who looked at the OSPF for the I2RS use that option 4 suggests?  We have complete I= M and DM (yang compiled) for the configuration we thought was necessary for= I2RS if the agent talked directly to the routing process (the assumption o= f all I2RS with unique data store).  

&n= bsp;

Please = review the OSPF and ISIS drafts with respect to option 4.=

&n= bsp;

Thanks,=

Acee&nb= sp;

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

 =

Sue

 =

PS =96 the ISIS Draft is not listed as ap= proved or listed on the ISIS mail list as approved. It has not been updated= since 6/27/14.  If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. <= span style=3D"color:black">

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 5:06 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 =

Sue:&nb= sp;

 <= /span>

Did you= look at the archives for the OSPF and ISIS WGs? Both drafts were presented= at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in bo= th the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document. <= span style=3D"color:black">

 <= /span>

 <= /span>

Acee&nb= sp;

 <= /span>

From: Susan Hares <= shares@ndzh.com>
Date: Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 <= /span>

Acee:

 

Was this work announce= d on any list at IETF for general contribution?  I don=92t see an anno= uncement on the ospf list or the ISIS list?  Perhaps you could point m= e to the list where this was announced?

 

Sue

 

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 =

 <= /span>

 <= /span>

From: Susan Hares <= shares@ndzh.com>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 <= /span>

Jeff:

 

Please add to the age= nda the following drafts: I2RS yang Data and Information models for ISIS, O= SPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP will be upl= oaded next week after some internal review.   

 <= /span>

HI Sue,=

We are = currently have drafts for the OSPF and ISIS YANG models and have multi-vend= or design teams contributing to them. This works is being done in the OSPF = and ISIS WG groups. You are welcome to review it but please don=92t create confusion with alternate drafts.&nb= sp;

 <= /span>

Thanks,=

Acee&nb= sp;

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 

The PBR model is the = information model that is a collaboration between the PBR (draft-kini-i2rs-= pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model).  &nbs= p;We hoped to have the agreement on the text early next week (just 1 technical discussion).   The author team has h= ad meetings in August and September.   

 

Please add the use ca= se to the agenda.

 

One question =96 shou= ld I be submitting these I2RS configuration IM/DM as netmod models? If so, = I will do this as well.

 

Sue

 

-----Original Message= -----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts?

 

Jeff,

 

To kickstart the disc= ussions

 

looking at what is ne= eded in NETMOD and NETCONF for I2RS

 

datastore for I2RS (u= se cases for ephemeral data store)

 

working on ACL YANG m= odel - with ACL model available and draft-ietf-netmod-routing-cfg-15 being = fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended i= nto data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cf= g, probably draft-ietf-netmod-routing-cfg-16, being published)

 

Dean

 

On Sep 25, 2014, at 2= :00 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= o:p>

 

> Your chairs have= been a bit over-busy recently with travel to unicast

> people doing var= ious bits of chartered work.  This means we've been

> behind on some o= f our goals in terms of getting regular design

> sessions running= .  I know that at least a couple calls have happened

> that I've missed= that Sue Hares has done, so some progress is being made.=

>

> We've requested = a 1 hour time slot for IETF 91 in Honolulu to give us

> a chance to talk= .  This is a call for agenda slots.

>

> This is also a c= all for status reports.

>

> We've had some p= roductive discussion about requests to netmod/netconf,

> albeit ones that= haven't converged yet.

>

> What have you be= en up to?

>

> -- Jeff & Ed=

>

> ________________= _______________________________

> i2rs mailing lis= t

> i2rs@ietf.org<= /a>

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

 

_____________________= __________________________

i2rs mailing list

i2rs@ietf= .org

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

 --_000_D04CC0173B94aceeciscocom_-- From nobody Sat Sep 27 17:21: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 2FCD61A007D for ; Sat, 27 Sep 2014 17:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtd9kaEs4RRa for ; Sat, 27 Sep 2014 17:21:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BB33E1A0074 for ; Sat, 27 Sep 2014 17:21:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Jeffrey Haas'" References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> In-Reply-To: Date: Sat, 27 Sep 2014 20:21:40 -0400 Message-ID: <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CFDA90.A615B520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIExceRAawuzi4B220d0QGawMRBAmrMpwUAsW5G1gKFCejBAg91mucCT6xHaJw4Ciug Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ZkzDyKhFeBulvqBi0XIXFpO87U8 Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 28 Sep 2014 00:21:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002F_01CFDA90.A615B520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Acee: I think we are still confused. The different streams (i2RS/config) that may or may not be merged (under debate). Both i2rs/config streams had open calls at IETF 90 for contributions and collaborators based on pre-IETF 90 work. On that portion of topic after this message, let's declare rat hole. My key question is still unanswered: "Do I understand is that you as co-chair of OSPF are stating you recommend not reading or reviewing the I2RS OSPF drafts I and my-authors created for the I2RS stream and instead you recommend figuring out if your existing configuration drafts fit I2RS?" I appreciate your bluntness so I can figure where to put our next efforts in I2RS. Thank you, Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 7:37 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? From: Susan Hares Date: Saturday, September 27, 2014 at 7:22 PM To: Acee Lindem , Jeff Haas Cc: "i2rs@ietf.org" Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Acee: Thank you for the pointer to the message in ISIS. Perhaps since Chris just declared consensus Friday the 9/19/14 that he will get around to posting these drafts. I'm not sure why you are suggesting that these drafts have not been previously posted. https://datatracker.ietf.org/doc/draft-litkowski-isis-yang-isis-cfg/ https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/ Acee - my message indicates the isis drafts had not been posted as: draft-isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the ospf web page or netmod web page. It is a polite indication between chairs that if this is important .. you might want to catch up with your housekeeping. To be clear, I understand from your work that you are declaring consensus on the yang models for OSPF model based on your knowledge of the private multi-vendor design team. As you noted, both the presentations at IETF 90 called for participation. These design teams are much less private than the OSPF/ISIS IM/DM drafts you submitted yesterday. Acee - this is simply not true. See the above information - it had the same level of call at IETF 90. You are stating at the OSPF chair that those models have the front seat in looking at the I2RS models without reading any of the I2RS IM/DM drafts we have prepared. The work on the OSPF and ISIS YANG models pre-dated the drafts you have submitted yesterday by quite some time so I don't see we should consider replacing it. Acee - I'm afraid you rare confusing the I2RS work with the configuration work. Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), was there a suggestion these might work. Please confirm that I understand this message so that I can determine the next steps to take with these drafts. Your next step should be to review the OSPF/ISIS drafts. Thanks,A Acee Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 6:32 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports From: Susan Hares Date: Saturday, September 27, 2014 at 6:16 PM To: Acee Lindem , Jeff Haas Cc: "i2rs@ietf.org" Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Acee: I'm confused by this email thread because these slides state the authors are looking for co-authors for netmod drafts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft? Yes - and there are now multi-vendor design teams in place. Would you point me to the email that indicates the WG Adoption call and conclusion? We haven't adopted yet in OSPF. ISIS adoption is in progress. I already searched the proceedings for the presentations. Note that the list archives offer a search capability. Anyway, here is the ISIS message: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html The drafts I suggested are I2RS drafts for the I2RS datastore that allow it to configure the routing agent directly. The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) works. It is unclear if it will work - that's under discussion. There is no reason to stop the I2RS DM/IM models required by I2RS charter work while we find out if option 4 works. And out of curiosity, if we are now considering option 4 why don't you want more input and collaboration that provides insight from people who looked at the OSPF for the I2RS use that option 4 suggests? We have complete IM and DM (yang compiled) for the configuration we thought was necessary for I2RS if the agent talked directly to the routing process (the assumption of all I2RS with unique data store). Please review the OSPF and ISIS drafts with respect to option 4. Thanks, Acee Sue PS - the ISIS Draft is not listed as approved or listed on the ISIS mail list as approved. It has not been updated since 6/27/14. If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 5:06 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in both the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem , Jeff Haas Cc: "i2rs@ietf.org" Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Acee: Was this work announced on any list at IETF for general contribution? I don't see an announcement on the ospf list or the ISIS list? Perhaps you could point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? From: Susan Hares Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have multi-vendor design teams contributing to them. This works is being done in the OSPF and ISIS WG groups. You are welcome to review it but please don't create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model). We hoped to have the agreement on the text early next week (just 1 technical discussion). The author team has had meetings in August and September. Please add the use case to the agenda. One question - should I be submitting these I2RS configuration IM/DM as netmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas < jhaas@pfrc.org> wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 ------=_NextPart_000_002F_01CFDA90.A615B520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee:

 

I think we are still = confused. The different streams (i2RS/config) that may or may not be = merged (under debate).  Both i2rs/config streams had open calls at = IETF 90 for contributions and collaborators based on pre-IETF 90 work. = On that portion of topic after this message, let’s declare rat = hole.  

 

My key question is still = unanswered:  “Do I understand is that you as co-chair of OSPF = are stating you recommend not reading or reviewing the I2RS OSPF drafts = I and my-authors created for the I2RS stream and instead you recommend = figuring out if your existing configuration drafts fit I2RS?” =  I appreciate your bluntness so I can figure where to put our next = efforts in I2RS.  

 

Thank you, =

 

Sue =

 

From:= = Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, = September 27, 2014 7:37 PM
To: Susan Hares; 'Jeffrey = Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 = meeting requested - call for agenda; status = reports?

 

 

=

 

=

From: = Susan Hares <shares@ndzh.com>
Date: = Saturday, September 27, 2014 at 7:22 PM
To: Acee Lindem = <acee@cisco.com>, Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = RE: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

=

Acee:

 

Thank you for the pointer to the message in = ISIS.  Perhaps since Chris just declared consensus Friday the = 9/19/14 that he will get around to posting these drafts.

 

=

I’m not sure why you are = suggesting that these drafts have not been previously = posted. 

 

=

 

Acee – my message = indicates the isis drafts had not been posted as: = draft-isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the = ospf web page or netmod web page.   It is a polite indication = between chairs that if this is important .. you might want to catch up = with your housekeeping.  

 

=

 

To be clear, I understand from your work that = you are declaring consensus on the yang models for OSPF model based on = your knowledge of the private multi-vendor design team. =  

 

=

As you noted, both the = presentations at IETF 90 called for participation. These design teams = are much less private than the OSPF/ISIS IM/DM drafts you submitted = yesterday. 

 

Acee – this is = simply not true.  See the above information – it had the same = level of call at IETF 90.  

 

=

You are stating at the = OSPF chair that those models have the front seat in looking at the I2RS = models without reading any of the I2RS IM/DM drafts we have = prepared.

 

=

The work on the OSPF and ISIS = YANG models pre-dated the drafts you have submitted yesterday by quite = some time so I don’t see we should consider replacing = it.    =

 

Acee – I’m = afraid you rare confusing the I2RS work with the configuration = work.  Only on 9/19/14 at a yang 1.1 interim (no standing with = I2RS), was there a suggestion these might work. =   

 

=

 Please confirm = that I understand this message so that I can determine the next steps to = take with these drafts.

 

=

Your next step should be to = review the OSPF/ISIS drafts. 

 

=

Thanks,A

Acee 

 

=

 

=

 

=

 

Sue

 

= From:= Acee Lindem (acee) [mailto:acee@cisco.com] =
Sent: Saturday, September 27, 2014 6:32 PM
To: = Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] IETF 91 meeting requested - call for agenda; status = reports

 

 

From: = Susan Hares <shares@ndzh.com>
Date: = Saturday, September 27, 2014 at 6:16 PM
To: Acee Lindem = <acee@cisco.com>, Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = RE: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Acee:

 

I’m confused by this email thread = because these slides state the authors are looking for co-authors for = netmod drafts. Are you as the co-chair of OSPF declaring consensus on = the OSPF yang model draft?

 

Yes = – and there are now multi-vendor design teams in = place. 

 

 

Would you point me to the email that = indicates the WG Adoption call and conclusion?

 

We = haven’t adopted yet in OSPF. ISIS adoption is in progress. I = already searched the proceedings for the presentations. Note that the = list archives offer a search capability… Anyway, here is the ISIS = message:

 

 

 

 

The drafts I suggested are I2RS drafts for = the I2RS datastore that allow it to configure the routing agent = directly. The only way these two drafts interact is if the option 4 = proposed by the Yang 1.1 interim (created 9/19/14) works.  It is = unclear if it will work – that’s under discussion. There is = no reason to stop the I2RS DM/IM models required by I2RS charter work = while we find out if option 4 works.

 

And out of curiosity, if we are now = considering option 4 why don’t you want more input and = collaboration that provides insight from people who looked at the OSPF = for the I2RS use that option 4 suggests?  We have complete IM and = DM (yang compiled) for the configuration we thought was necessary for = I2RS if the agent talked directly to the routing process (the assumption = of all I2RS with unique data store).  

 

Please = review the OSPF and ISIS drafts with respect to option 4.

 

Thanks,

Acee 

 

 

 

 

 

Sue

 

PS – the ISIS Draft is not listed as = approved or listed on the ISIS mail list as approved. It has not been = updated since 6/27/14.  If you believe it should be listed that = way, you might want to talk to the ISIS co-chairs.

 

= From:= Acee Lindem (acee) [mailto:acee@cisco.com] =
Sent: Saturday, September 27, 2014 5:06 PM
To: = Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Sue: 

 

Did you = look at the archives for the OSPF and ISIS WGs? Both drafts were = presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG = model in both the netmod and OSPF WGs. The ISIS YANG Model is already = being accepted as an ISIS WG document. 

 

 

Acee 

 

From: = Susan Hares <shares@ndzh.com>
Date: = Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem = <acee@cisco.com>, Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = RE: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Acee:

 

Was this work announced on any list at IETF for = general contribution?  I don’t see an announcement on the = ospf list or the ISIS list?  Perhaps you could point me to the list = where this was announced?

 

Sue

 

 

= From:= i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Acee Lindem (acee)
Sent: Saturday, = September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey = Haas'
Cc: i2rs@ietf.org
Subject: Re: = [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

 

 

From: = Susan Hares <shares@ndzh.com>
Date: = Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas = <jhaas@pfrc.org>
Cc: = "i2rs@ietf.org" = <i2rs@ietf.org>
Subject: = Re: [i2rs] IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff: =

 

Please add to the = agenda the following drafts: I2RS yang Data and Information models for = ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP = will be uploaded next week after some internal review. =   

 

HI = Sue,

We are = currently have drafts for the OSPF and ISIS YANG models and have = multi-vendor design teams contributing to them. This works is being done = in the OSPF and ISIS WG groups. You are welcome to review it but please = don’t create confusion with alternate drafts. 

 

Thanks,

Acee 

 

 

 

 

 

 

 

The PBR model is the = information model that is a collaboration between the PBR = (draft-kini-i2rs-pbr-info-model-00) and the = (draft-hares-i2rs-policy-info-model).   We hoped to have the = agreement on the text early next week (just 1 technical discussion). =   The author team has had meetings in August and September. =   

 

Please add the use case = to the agenda.

 

One question – = should I be submitting these I2RS configuration IM/DM as netmod models? = If so, I will do this as well.

 

Sue =

 

-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 = PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] = IETF 91 meeting requested - call for agenda; status = reports?

 

Jeff,

 

To kickstart the = discussions

 

looking at what is = needed in NETMOD and NETCONF for I2RS

 

datastore for I2RS (use = cases for ephemeral data store)

 

working on ACL YANG = model - with ACL model available and draft-ietf-netmod-routing-cfg-15 = being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be = extended into data model. I'll try to submit the draft by the deadline = (it is dependent on new draft-ietf-netmod-routing-cfg, probably = draft-ietf-netmod-routing-cfg-16, being = published)

 

Dean

 

On Sep 25, 2014, at = 2:00 PM, Jeffrey Haas <jhaas@pfrc.org= > wrote:

 

> Your chairs have = been a bit over-busy recently with travel to unicast =

> people doing various bits of chartered = work.  This means we've been

> behind on some of = our goals in terms of getting regular design

> sessions = running.  I know that at least a couple calls have happened =

> that I've missed that Sue Hares has done, so = some progress is being made.

> =

> We've requested a 1 hour time slot for IETF = 91 in Honolulu to give us

> a chance to = talk.  This is a call for agenda slots.

> =

> This is also a call for status = reports.

>

> We've had some = productive discussion about requests to netmod/netconf, =

> albeit ones that haven't converged = yet.

>

> What have you been = up to?

>

> -- Jeff & = Ed

>

> = _______________________________________________

> i2rs mailing = list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

 

_______________________________________________

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_002F_01CFDA90.A615B520-- From nobody Sat Sep 27 21:20: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 1860B1A0278 for ; Sat, 27 Sep 2014 21:20:41 -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_12=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 xCcTPq4eNe9r for ; Sat, 27 Sep 2014 21:20:39 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC381A0276 for ; Sat, 27 Sep 2014 21:20:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CC6301BC2988; Sat, 27 Sep 2014 21:20:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id A0D951BC2976; Sat, 27 Sep 2014 21:20:37 -0700 (PDT) Message-ID: <54278C94.40307@joelhalpern.com> Date: Sun, 28 Sep 2014 00:20:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander Clemm (alex)" , Susan Hares , 'Andy Bierman' , 'Martin Bjorklund' References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uVrDsHXCiHu3S1nPiO3Hbc9MXgo Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , "Eric Voit \(evoit\)" Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 04:20:41 -0000 If I am reading you correctly, you are saying taht if an I2RS client is manipulating data that is stored in the underlying golden store, you want that golden store changed. I think that won't work for the requirements. As far as I can tell from your proposal, this would result in I2RS changes being stored when someone on the CLI does a commit. Which is not what is wanted. Conversely, a read-through model would seem to work. Objects which have been created / modified in the I2RS store, when read from the I2RS store have their I2RS value. If you attempt to read or reference a value that has not been modified in I2RS, you read-through to the underlying data store, and see its value. Yours, Joel On 9/26/14, 7:53 PM, Alexander Clemm (alex) wrote: > Hi Susan, Andy, all, > > there would be two datastore – “local” and “ephemeral”. > > Local implements and owns foo, instantiated as you describe below. This > is the golden copy. > > Furthermore, for simplicity sake, assume that list foo is contained in a > container, foos. > > The ephemeral datastore implements a separate model “foo-ext”. > > This model declares a reference / “mount” to “foos” in the local datastore. > > In addition, it defines some other data, that is “owned” by the > ephemeral datastore. (This data can have conditions/constraints to data > that has been mounted from foo.) > > So, in the ephemeral you might have > > foo-ext > > +-- M foos --> /local/foos > > +-- bar > > An application/client that accesses ephemeral can access foo 42 via > /foo-ext/foos/foo 42. The fact that the ephemeral datastore turns > around as needed, as the golden copy is owned by local, is transparent > to the application. If someone changes foo 42, e.g. because they access > the local datastore directly, that will be reflected in the ephemeral > datastore by virtue of the fact that it in effect acts as a “cache” to > the data in the local datastore. > > Now, there are a couple of items to consider: > > -If you want to have a list where some list elements reside on one > datastore, others in another, you cannot do that directly. What you > need to do in that case is to introduce a partition (as part of the > model that you implement in the ephemeral) that e.g. has a “my-foos” > container containing the list elements it authoritatively owns, and a > separate “cached-foos” container that “contains” the list elements from > the other datastore. > > -Should you be able to have a remote data item contain a local one? I > would argue that you should not allow for that, precisely to avoid the > scenario in which the local object get “decapitated” because something > happens to the containing objects that are owned by a different system. > If you want to attach a piece of ephemeral data to the remote data item, > you should do so with other ways than containment, e.g. adding a leafref > to the mounted/referenced remote object. > > The distinction to other proposals is that with this proposal, the > ephemeral datastore defines its own separate model (which indicates > which data it “owns”, vs which data it “caches”). Note that the model > for the cached data does not need to be redefined; it is used as-is; the > fact that there is another datastore which decides to incorporate that > information is not something the local datastore needs to be aware of. > > Does this answer your questions? > > --- Alex > > *From:*Susan Hares [mailto:shares@ndzh.com] > *Sent:* Friday, September 26, 2014 8:30 AM > *To:* Alexander Clemm (alex); 'Andy Bierman'; 'Martin Bjorklund' > *Cc:* 'Jeffrey Haas'; i2rs@ietf.org; Eric Voit (evoit) > *Subject:* RE: [i2rs] Two thoughts on an ephemeral data store > > Alexander: > > To help me understand your proposal, let us move to the previous example: > > Previous example: > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > > Your model: > > a)The value 4711 – would be a “non-golden” copy. > > b)It would not be written through to the the “golden copy”. > > Questions: > > a)How would you specify a “write-through” copy? > > b)Can I2RS decide later it wants to write-through the golden copy? Or > are variables only “non-write-through” and “write-through”? > > c)If we delete foo 42, what happens? > > Thank you, > > Sue Hares > > *From:*i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Alexander > Clemm (alex) > *Sent:* Thursday, September 25, 2014 8:57 PM > *To:* Andy Bierman; Martin Bjorklund > *Cc:* Jeffrey Haas; i2rs@ietf.org ; Eric Voit (evoit) > *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store > > FWIW, I would think the semantics should be kept simple. > > The complexity here comes from the fact that there are dependencies > between different data stores, and some objects that are part of one > data store need to be reflected in a different data store. > > It would seem this can be addressed with two fairly simple principles: > > (a)A datastore needs to have a clear way to reference objects in a > different datastore, really have them incorporated into the same namespace. > > (b)It needs to be clear who owns the “golden copy” of an object. I > needs to be clear which objects are “authoritatively owned” by a > datastore vs which ones are reference. This is the datastore where the > object is maintained, updated, created; this is where conditions and > constraints are evaluated, etc. > > Where an ephemeral datastore has dependencies on data in another > datastore, it should incorporate these other objects “by reference”. > The objects that are authoritatively owned by the ephemeral datastore > can refer to those objects, have them referred to in conditions and > constraints, and so on. (This can also indicate which ephemeral objects > are to be removed when an object in the other datastore they depend on > is deleted, etc) > > Changes to the non-ephemeral objects (e.g. the running datastore) have > to be made to the “golden copy”, i.e. the owning datastore. One way to > do that involves implementing a “write-through” operation, in which an > update to an ephemeral copy of the object is realized by having the > server of the ephemeral datastore turn around and make a corresponding > request at the other datastore. > > Very simple semantics. I think this is preferrable to have different > copies of the same object in different datastores, requiring “logical > anding” (or other inter-datastore arithmetic) of different copies > representing the same object to figure out what actual value is in > effect, etc. > > In the netmod WG, we have today posted a draft for what we refer to as > requirements for a peer mount > (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt), > motivating why a it would be useful to have a capability to “mount” > subtrees from a remote datastore into a local datastore, and the > requirements that such a capability needs to address. While the > original use case and motivation described there are somewhat different, > it seems applicable to the discussion here. > > --- Alex > > *From:*i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Thursday, September 25, 2014 8:44 AM > *To:* Martin Bjorklund > *Cc:* Jeffrey Haas; i2rs@ietf.org > *Subject:* Re: [i2rs] Two thoughts on an ephemeral data store > > On Thu, Sep 25, 2014 at 7:39 AM, Martin Bjorklund > wrote: > > Jeffrey Haas > wrote: > > On Thu, Sep 25, 2014 at 12:29:35PM +0200, Martin Bjorklund wrote: > > > Jeffrey Haas > wrote: > > > > In the proposed overlay model, presume that we have ephemeral > data from a > > > > model that lives within an augmentation to a local config model. > In other > > > > words, the ephemeral nodes are children of the local config nodes. > > > > > > > > Presume, per discussion, that the local config lives in the > "config" data > > > > store and that the ephemeral config - the augmenting nodes above > - live in > > > > the ephemeral data store. > > > > > > > > If we delete the container in the local config that the > epehemeral config is > > > > augmenting, is there any expectation that such a deletion should > carry > > > > through to the ephemeral config? > > > > > > > > Per the netmod interim discussion, probably not. > > > > > > My interpretation of the interim discussion is that the deletion > > > carries through. > > > > To be clear what I meant, consider: > > > > local config: ephemeral: > > A A/B - B is introduced as an augmentation of A > > I think there might be a terminology confusion here, so let's do a > simple example. > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > > What happens if we in local config delete foo 42? > > If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now > presented to the internal apps? > > Yes -- and what is presented to a client that retrieves the ephemeral config > > in a GET request? IMO, coupling the datastores does not make sense. > > Your example is 1 reason I prefer the "shadow shapshot" approach. > > I think the local config and client that added the "foo" entry in the > ephemeral datastore > > are meant to have different priorities. The entries are not coupled. > > One wins and the other loses (main use-case is that ephemeral wins). > > Editing "foo 42" in the local config just changes what will be installed > as local config > > when the device restarts (or the ephemeral state is removed). It should > not change > > the injected I2RS state at all. IMO it is really important that edits > stay within a single > > datastore. > > > > /martin > > Andy > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Sun Sep 28 03:40:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FE81A0235 for ; Sun, 28 Sep 2014 03:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39JvbOVo4TDz for ; Sun, 28 Sep 2014 03:40:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F281A0394 for ; Sun, 28 Sep 2014 03:40:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CFF16A81; Sun, 28 Sep 2014 12:40:44 +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 tczGrtsIdDYN; Sun, 28 Sep 2014 12:40:37 +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; Sun, 28 Sep 2014 12:40:43 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA47420036; Sun, 28 Sep 2014 12:40:43 +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 e-Bd_eXNxQ85; Sun, 28 Sep 2014 12:40:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EE5F20035; Sun, 28 Sep 2014 12:40:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C6242EA5933; Sun, 28 Sep 2014 12:40:40 +0200 (CEST) Date: Sun, 28 Sep 2014 12:40:40 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140928104039.GB74220@elstar.local> Mail-Followup-To: Susan Hares , "'Alexander Clemm (alex)'" , 'Andy Bierman' , 'Martin Bjorklund' , 'Jeffrey Haas' , i2rs@ietf.org, "'Eric Voit (evoit)'" References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1r2k4kxwFtHsn9aBWRGAj3CC4to Cc: i2rs@ietf.org, 'Martin Bjorklund' , "'Eric Voit \(evoit\)'" , "'Alexander Clemm \(alex\)'" , 'Andy Bierman' , 'Jeffrey Haas' Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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: Sun, 28 Sep 2014 10:40:49 -0000 On Fri, Sep 26, 2014 at 11:30:00AM -0400, Susan Hares wrote: > > Previous example: > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > Lets say more precisely, I assume this would be: 42 Note that id is required (key) and a is optional. > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. I assume your mean ephemeral datastore now contains: 42 4711 I do not know what Alexander is proposal but open #4 would merge the two and the resulting operational state would be: 42 4711 This is not a particularly interesting example though... /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 Sun Sep 28 09:59: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 50FDB1A1B83 for ; Sun, 28 Sep 2014 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 EmTBJ6Izu9Rp for ; Sun, 28 Sep 2014 09:59:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FAB1A1B70 for ; Sun, 28 Sep 2014 09:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55859; q=dns/txt; s=iport; t=1411923550; x=1413133150; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PLwktc/Mc/IqhLttVgDW0DKvMQxqiYmuxYtfmc4jaxk=; b=MlMYEJ4VF9JvUUKtA4JflKH2M5YsmGHscWRIPoEkBoQUdyLAytPAzPXW ftbY0k9oJHLyP95MYcobzTiYBCi7FKn/B6f1pEv0/qZ2x4EZjSYmIV7LB mBIq5sFaqOeH5k9GkF5/cn2IwQQZj4usuDFCvzCcd5NFx8v57Kf5ABEFV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADA9KFStJV2a/2dsb2JhbABUDIJIRlNXBMoBAQmHTgJ7FgF7hAMBAQECAQEBAQEXAxBBCwUHBAIBCA4DAwEBASEBBgcnCxQJCAIEAQ0FCYgtCA2+SAEXjEuCbAEEEAIBLRENBAYBBoRFBY9LghqEOocJlV2DY2wBgUeBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,615,1406592000"; d="scan'208,217";a="358917758" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 28 Sep 2014 16:59:08 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8SGx8aH007867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Sep 2014 16:59:08 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sun, 28 Sep 2014 11:59:08 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Jeffrey Haas'" Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqAgABRF4D//8ETAAAJ7j8AABpz1oA= Date: Sun, 28 Sep 2014 16:59:07 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> In-Reply-To: <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D04DB23B3BBAaceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lBaryc9Z83KK9_uIr7m4cVC75Mg Cc: "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 28 Sep 2014 16:59:14 -0000 --_000_D04DB23B3BBAaceeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sue, See inline. From: Susan Hares > Date: Saturday, September 27, 2014 at 8:21 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: I think we are still confused. The different streams (i2RS/config) that may= or may not be merged (under debate). Both i2rs/config streams had open ca= lls at IETF 90 for contributions and collaborators based on pre-IETF 90 wor= k. On that portion of topic after this message, let=92s declare rat hole. My key question is still unanswered: =93Do I understand is that you as co-= chair of OSPF are stating you recommend not reading or reviewing the I2RS O= SPF drafts I and my-authors created for the I2RS stream and instead you rec= ommend figuring out if your existing configuration drafts fit I2RS?=94 I a= ppreciate your bluntness so I can figure where to put our next efforts in I= 2RS. Note the IESG statement on YANG models independent of I2RS: http://www.ietf.org/iesg/statement/writable-mib-module.html We have been working on YANG models for some time in both OSPF and ISIS. Th= e ISIS model is already being adopted and we will request WG OSPF adoption = upon the next refresh. I can=92t help it if you are not following the WGs f= or which you are proposing models. For your next efforts, I'd recommend bet= ter coordination and awareness of WG activities. Thanks, Acee Thank you, Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 7:37 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? From: Susan Hares > Date: Saturday, September 27, 2014 at 7:22 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: Thank you for the pointer to the message in ISIS. Perhaps since Chris just= declared consensus Friday the 9/19/14 that he will get around to posting t= hese drafts. I=92m not sure why you are suggesting that these drafts have not been previ= ously posted. https://datatracker.ietf.org/doc/draft-litkowski-isis-yang-isis-cfg/ https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/ Acee =96 my message indicates the isis drafts had not been posted as: draft= -isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the ospf web = page or netmod web page. It is a polite indication between chairs that if= this is important .. you might want to catch up with your housekeeping. To be clear, I understand from your work that you are declaring consensus o= n the yang models for OSPF model based on your knowledge of the private mul= ti-vendor design team. As you noted, both the presentations at IETF 90 called for participation. T= hese design teams are much less private than the OSPF/ISIS IM/DM drafts you= submitted yesterday. Acee =96 this is simply not true. See the above information =96 it had the= same level of call at IETF 90. You are stating at the OSPF chair that those models have the front seat in = looking at the I2RS models without reading any of the I2RS IM/DM drafts we = have prepared. The work on the OSPF and ISIS YANG models pre-dated the drafts you have sub= mitted yesterday by quite some time so I don=92t see we should consider rep= lacing it. Acee =96 I=92m afraid you rare confusing the I2RS work with the configurati= on work. Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), wa= s there a suggestion these might work. Please confirm that I understand this message so that I can determine the = next steps to take with these drafts. Your next step should be to review the OSPF/ISIS drafts. Thanks,A Acee Sue From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 6:32 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts From: Susan Hares > Date: Saturday, September 27, 2014 at 6:16 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: I=92m confused by this email thread because these slides state the authors = are looking for co-authors for netmod drafts. Are you as the co-chair of OS= PF declaring consensus on the OSPF yang model draft? Yes =96 and there are now multi-vendor design teams in place. Would you point me to the email that indicates the WG Adoption call and con= clusion? We haven=92t adopted yet in OSPF. ISIS adoption is in progress. I already s= earched the proceedings for the presentations. Note that the list archives = offer a search capability=85 Anyway, here is the ISIS message: http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html The drafts I suggested are I2RS drafts for the I2RS datastore that allow it= to configure the routing agent directly. The only way these two drafts int= eract is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14)= works. It is unclear if it will work =96 that=92s under discussion. There= is no reason to stop the I2RS DM/IM models required by I2RS charter work w= hile we find out if option 4 works. And out of curiosity, if we are now considering option 4 why don=92t you wa= nt more input and collaboration that provides insight from people who looke= d at the OSPF for the I2RS use that option 4 suggests? We have complete IM= and DM (yang compiled) for the configuration we thought was necessary for = I2RS if the agent talked directly to the routing process (the assumption of= all I2RS with unique data store). Please review the OSPF and ISIS drafts with respect to option 4. Thanks, Acee Sue PS =96 the ISIS Draft is not listed as approved or listed on the ISIS mail = list as approved. It has not been updated since 6/27/14. If you believe it= should be listed that way, you might want to talk to the ISIS co-chairs. From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, September 27, 2014 5:06 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Sue: Did you look at the archives for the OSPF and ISIS WGs? Both drafts were pr= esented at IETF 90 in Toronto. We intend to cross review the OSPF YANG mode= l in both the netmod and OSPF WGs. The ISIS YANG Model is already being acc= epted as an ISIS WG document. http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf Acee From: Susan Hares > Date: Saturday, September 27, 2014 at 4:32 PM To: Acee Lindem >, Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Acee: Was this work announced on any list at IETF for general contribution? I do= n=92t see an announcement on the ospf list or the ISIS list? Perhaps you c= ould point me to the list where this was announced? Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Saturday, September 27, 2014 3:58 PM To: Susan Hares; 'Jeffrey Haas' Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? From: Susan Hares > Date: Friday, September 26, 2014 at 11:36 PM To: Jeff Haas > Cc: "i2rs@ietf.org" > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff: Please add to the agenda the following drafts: I2RS yang Data and Informati= on models for ISIS, OSPF, Basic Network Policy (BNP), PBR and BGP. PBR and= BGP will be uploaded next week after some internal review. HI Sue, We are currently have drafts for the OSPF and ISIS YANG models and have mul= ti-vendor design teams contributing to them. This works is being done in th= e OSPF and ISIS WG groups. You are welcome to review it but please don=92t = create confusion with alternate drafts. Thanks, Acee The PBR model is the information model that is a collaboration between the = PBR (draft-kini-i2rs-pbr-info-model-00) and the (draft-hares-i2rs-policy-in= fo-model). We hoped to have the agreement on the text early next week (ju= st 1 technical discussion). The author team has had meetings in August an= d September. Please add the use case to the agenda. One question =96 should I be submitting these I2RS configuration IM/DM as n= etmod models? If so, I will do this as well. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Thursday, September 25, 2014 2:44 PM To: Jeffrey Haas Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts? Jeff, To kickstart the discussions looking at what is needed in NETMOD and NETCONF for I2RS datastore for I2RS (use cases for ephemeral data store) working on ACL YANG model - with ACL model available and draft-ietf-netmod-= routing-cfg-15 being fixed, PBR info model (draft-kini-i2rs-pbr-info-model-= 00) can be extended into data model. I'll try to submit the draft by the de= adline (it is dependent on new draft-ietf-netmod-routing-cfg, probably draf= t-ietf-netmod-routing-cfg-16, being published) Dean On Sep 25, 2014, at 2:00 PM, Jeffrey Haas > wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? > > -- Jeff & 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 --_000_D04DB23B3BBAaceeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <87339DEB33A3214FAE9A6041C0627D42@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Sue,

See inline.

From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 = at 8:21 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: RE: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Acee:

 

I think we are still c= onfused. The different streams (i2RS/config) that may or may not be merged = (under debate).  Both i2rs/config streams had open calls at IETF 90 fo= r contributions and collaborators based on pre-IETF 90 work. On that portion of topic after this message, let=92s dec= lare rat hole.  

 

My key question is sti= ll unanswered:  =93Do I understand is that you as co-chair of OSPF are= stating you recommend not reading or reviewing the I2RS OSPF drafts I and = my-authors created for the I2RS stream and instead you recommend figuring out if your existing configuration drafts f= it I2RS?=94  I appreciate your bluntness so I can figure where to put = our next efforts in I2RS.  

Note the IESG statement on YANG models independent of I2RS: 

http://www.ietf.org/iesg/statement/writable-mib-module.html

We have been working on YANG models for some time in both OSPF and ISI= S. The ISIS model is already being adopted and we will request WG OSPF adop= tion upon the next refresh. I can=92t help it if you are not following the = WGs for which you are proposing models. For your next efforts, I'd recommend better coordination and awareness of = WG activities.

Thanks,
Acee 





 

Thank you, =

 

Sue =

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 7:37 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 

&n= bsp;

&n= bsp;

From: Susan Hares <= shares@ndzh.com>
Date: Saturday, September 27, 2014 at 7:22 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

&n= bsp;

Acee:

 

Thank you for the poin= ter to the message in ISIS.  Perhaps since Chris just declared consens= us Friday the 9/19/14 that he will get around to posting these drafts.

&n= bsp;

I=92m n= ot sure why you are suggesting that these drafts have not been previously p= osted. 

&n= bsp;

=  

Acee =96 my message in= dicates the isis drafts had not been posted as: draft-isis-yang-isis-cfg, a= nd that draft-yeung-netmod-ospf was not the ospf web page or netmod web pag= e.   It is a polite indication between chairs that if this is important .. you might want to catch up with your h= ousekeeping.  

&n= bsp;

 

To be clear, I underst= and from your work that you are declaring consensus on the yang models for = OSPF model based on your knowledge of the private multi-vendor design team.=  

&n= bsp;

As you = noted, both the presentations at IETF 90 called for participation. These de= sign teams are much less private than the OSPF/ISIS IM/DM drafts you submit= ted yesterday. 

 

Acee =96 this is simpl= y not true.  See the above information =96 it had the same level of ca= ll at IETF 90.  

&n= bsp;

You are stating at the= OSPF chair that those models have the front seat in looking at the I2RS mo= dels without reading any of the I2RS IM/DM drafts we have prepared.<= span style=3D"color:black">

&n= bsp;

The wor= k on the OSPF and ISIS YANG models pre-dated the drafts you have submitted = yesterday by quite some time so I don=92t see we should consider replacing = it.   

 

Acee =96 I=92m afraid = you rare confusing the I2RS work with the configuration work.  Only on= 9/19/14 at a yang 1.1 interim (no standing with I2RS), was there a suggest= ion these might work.   

&n= bsp;

 Please confirm t= hat I understand this message so that I can determine the next steps to tak= e with these drafts.

&n= bsp;

Your ne= xt step should be to review the OSPF/ISIS drafts. 

&n= bsp;

Thanks,= A

Acee&nb= sp;

&n= bsp;

&n= bsp;

&n= bsp;

 

Sue

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 6:32 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports

 <= /span>

 <= /span>

From: Susan Hares <= shares@ndzh.com>
Date: Saturday, September 27, 2014 at 6:16 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 <= /span>

Acee:<= o:p>

 =

I=92m confused by this email thread becau= se these slides state the authors are looking for co-authors for netmod dra= fts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft?

 <= /span>

Yes =96= and there are now multi-vendor design teams in place. 

 <= /span>

 <= /span>

Would you point me to the email that indi= cates the WG Adoption call and conclusion?

 <= /span>

We have= n=92t adopted yet in OSPF. ISIS adoption is in progress. I already searched= the proceedings for the presentations. Note that the list archives offer a= search capability=85 Anyway, here is the ISIS message:

 <= /span>

 <= /span>

 <= /span>

 =

The drafts I suggested are I2RS drafts fo= r the I2RS datastore that allow it to configure the routing agent directly.= The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) work= s.  It is unclear if it will work =96 that=92s under discussion. There= is no reason to stop the I2RS DM/IM models required by I2RS charter work w= hile we find out if option 4 works.

 =

And out of curiosity, if we are now consi= dering option 4 why don=92t you want more input and collaboration that prov= ides insight from people who looked at the OSPF for the I2RS use that option 4 suggests?  We have complete I= M and DM (yang compiled) for the configuration we thought was necessary for= I2RS if the agent talked directly to the routing process (the assumption o= f all I2RS with unique data store).  

 <= /span>

Please = review the OSPF and ISIS drafts with respect to option 4.

 <= /span>

Thanks,=

Acee&nb= sp;

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 =

Sue

 =

PS =96 the ISIS Draft is not listed as ap= proved or listed on the ISIS mail list as approved. It has not been updated= since 6/27/14.  If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. <= span style=3D"color:black">

 

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 5:06 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 =

Sue:&nb= sp;

 <= /span>

Did you= look at the archives for the OSPF and ISIS WGs? Both drafts were presented= at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in bo= th the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document. <= span style=3D"color:black">

 <= /span>

 <= /span>

Acee&nb= sp;

 <= /span>

From: Susan Hares <= shares@ndzh.com>
Date: Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem <acee@cisco.com= >, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 <= /span>

Acee:

 

Was this work announce= d on any list at IETF for general contribution?  I don=92t see an anno= uncement on the ospf list or the ISIS list?  Perhaps you could point m= e to the list where this was announced?

 

Sue

 

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 =

 <= /span>

 <= /span>

From: Susan Hares <= shares@ndzh.com>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ietf.org" &= lt;i2rs@ietf.org>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

 <= /span>

Jeff:

 

Please add to the age= nda the following drafts: I2RS yang Data and Information models for ISIS, O= SPF, Basic Network Policy (BNP), PBR and BGP.  PBR and BGP will be upl= oaded next week after some internal review.   

 <= /span>

HI Sue,=

We are = currently have drafts for the OSPF and ISIS YANG models and have multi-vend= or design teams contributing to them. This works is being done in the OSPF = and ISIS WG groups. You are welcome to review it but please don=92t create confusion with alternate drafts.&nb= sp;

 <= /span>

Thanks,=

Acee&nb= sp;

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 

The PBR model is the = information model that is a collaboration between the PBR (draft-kini-i2rs-= pbr-info-model-00) and the (draft-hares-i2rs-policy-info-model).  &nbs= p;We hoped to have the agreement on the text early next week (just 1 technical discussion).   The author team has h= ad meetings in August and September.   

 

Please add the use ca= se to the agenda.

 

One question =96 shou= ld I be submitting these I2RS configuration IM/DM as netmod models? If so, = I will do this as well.

 

Sue

 

-----Original Message= -----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: i2rs@ietf.org
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts?

 

Jeff,

 

To kickstart the disc= ussions

 

looking at what is ne= eded in NETMOD and NETCONF for I2RS

 

datastore for I2RS (u= se cases for ephemeral data store)

 

working on ACL YANG m= odel - with ACL model available and draft-ietf-netmod-routing-cfg-15 being = fixed, PBR info model (draft-kini-i2rs-pbr-info-model-00) can be extended i= nto data model. I'll try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cf= g, probably draft-ietf-netmod-routing-cfg-16, being published)

 

Dean

 

On Sep 25, 2014, at 2= :00 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= o:p>

 

> Your chairs have= been a bit over-busy recently with travel to unicast

> people doing var= ious bits of chartered work.  This means we've been

> behind on some o= f our goals in terms of getting regular design

> sessions running= .  I know that at least a couple calls have happened

> that I've missed= that Sue Hares has done, so some progress is being made.=

>

> We've requested = a 1 hour time slot for IETF 91 in Honolulu to give us

> a chance to talk= .  This is a call for agenda slots.

>

> This is also a c= all for status reports.

>

> We've had some p= roductive discussion about requests to netmod/netconf,

> albeit ones that= haven't converged yet.

>

> What have you be= en up to?

>

> -- Jeff & Ed=

>

> ________________= _______________________________

> i2rs mailing lis= t

> i2rs@ietf.org<= /a>

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

 

_____________________= __________________________

i2rs mailing list

i2rs@ietf= .org

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

 --_000_D04DB23B3BBAaceeciscocom_-- From nobody Sun Sep 28 17:54:25 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 BAA351A6F22 for ; Sun, 28 Sep 2014 17:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_61=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 JJnw-sRKg5Xm for ; Sun, 28 Sep 2014 17:54:21 -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 7C3241A6F15 for ; Sun, 28 Sep 2014 17:54:21 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id a41so5030879yho.18 for ; Sun, 28 Sep 2014 17:54:20 -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=M80x7jGGZmsJGFRjTIG1XiRQrpwgKNlP2bZ/4PlW5UY=; b=iPbMA1BRGoq6lxFp4LIcfcRfxVP5lVu224afwdtu3varPOctclYSdjGcRYGabU3LKN YyPudFMHgTWp8jzhhVz7woBDrhCGqr5W5EIdP5CYc5yqVQeGe0OdqMDnE8NJLrnHIhhk vHUfUJsLgJwQ+SRqXDQetTWKUycxGZqmU5Mgzm5iNzmoy7E5JNVJzxpG+XyVqNqNyNts SN0avXHC6lQh6Mkziyh1/MGIEsnNEZbiWfBf6VTQJ4mU08Z1ciXVoPHg1b+jtpfPtvNr U3xwOaM1sRLU8scGi6B6XXlOSwj0zdo3xel9RNW/9nbiHhUOF/O5F+sk0yE4isZBYTFN lM3w== MIME-Version: 1.0 X-Received: by 10.236.19.196 with SMTP id n44mr45824371yhn.83.1411952060774; Sun, 28 Sep 2014 17:54:20 -0700 (PDT) Received: by 10.170.110.72 with HTTP; Sun, 28 Sep 2014 17:54:20 -0700 (PDT) In-Reply-To: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> Date: Sun, 28 Sep 2014 20:54:20 -0400 Message-ID: From: Alia Atlas To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=089e0153894405bf53050429b5d0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/W-BkgAQxyo5V40KZVt1Zo5k8Zds Cc: Jeffrey Haas , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 00:54:25 -0000 --089e0153894405bf53050429b5d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Acee, It is NOT OK to tell anyone that they should not contribute a draft - because it may muddy the water or for ANY other non-technical reason. Individual drafts or desire to request WG adoption do not change this. I do not ever want to see or hear something like this on an IETF mailing list. Very very few drafts start perfect and different models have different perspectives. The IETF has a consensus process, as you well know of course, to resolve differences between perspectives and drafts. Second, a NETMOD interim with tentative ideas on how it might be nice to carry out requests in an individual draft does not in any way dictate how I2RS should proceed. I2RS is in Routing because we understand the work and details to be done. The desire that there can be only one model for any and all purposes is interesting but it isn't clear that is feasible. I d not have any more polite words to discuss this. Alia On Sun, Sep 28, 2014 at 12:59 PM, Acee Lindem (acee) wrote= : > Sue, > > See inline. > > From: Susan Hares > Date: Saturday, September 27, 2014 at 8:21 PM > To: Acee Lindem , Jeff Haas > Cc: "i2rs@ietf.org" > Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > Acee: > > > > I think we are still confused. The different streams (i2RS/config) that > may or may not be merged (under debate). Both i2rs/config streams had op= en > calls at IETF 90 for contributions and collaborators based on pre-IETF 90 > work. On that portion of topic after this message, let=E2=80=99s declare = rat hole. > > > > My key question is still unanswered: =E2=80=9CDo I understand is that yo= u as > co-chair of OSPF are stating you recommend not reading or reviewing the > I2RS OSPF drafts I and my-authors created for the I2RS stream and instead > you recommend figuring out if your existing configuration drafts fit I2RS= ?=E2=80=9D > I appreciate your bluntness so I can figure where to put our next effort= s > in I2RS. > > > Note the IESG statement on YANG models independent of I2RS: > > http://www.ietf.org/iesg/statement/writable-mib-module.html > > We have been working on YANG models for some time in both OSPF and ISIS. > The ISIS model is already being adopted and we will request WG OSPF > adoption upon the next refresh. I can=E2=80=99t help it if you are not fo= llowing > the WGs for which you are proposing models. For your next efforts, I'd > recommend better coordination and awareness of WG activities. > > Thanks, > Acee > > > > > > > > Thank you, > > > > Sue > > > > *From:* Acee Lindem (acee) [mailto:acee@cisco.com ] > *Sent:* Saturday, September 27, 2014 7:37 PM > *To:* Susan Hares; 'Jeffrey Haas' > *Cc:* i2rs@ietf.org > *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > > > > > *From: *Susan Hares > *Date: *Saturday, September 27, 2014 at 7:22 PM > *To: *Acee Lindem , Jeff Haas > *Cc: *"i2rs@ietf.org" > *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > Acee: > > > > Thank you for the pointer to the message in ISIS. Perhaps since Chris > just declared consensus Friday the 9/19/14 that he will get around to > posting these drafts. > > > > I=E2=80=99m not sure why you are suggesting that these drafts have not be= en > previously posted. > > > > https://datatracker.ietf.org/doc/draft-litkowski-isis-yang-isis-cfg/ > > https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/ > > > > Acee =E2=80=93 my message indicates the isis drafts had not been posted a= s: > draft-isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the os= pf > web page or netmod web page. It is a polite indication between chairs > that if this is important .. you might want to catch up with your > housekeeping. > > > > > > To be clear, I understand from your work that you are declaring consensus > on the yang models for OSPF model based on your knowledge of the private > multi-vendor design team. > > > > As you noted, both the presentations at IETF 90 called for participation. > These design teams are much less private than the OSPF/ISIS IM/DM drafts > you submitted yesterday. > > > > Acee =E2=80=93 this is simply not true. See the above information =E2=80= =93 it had the > same level of call at IETF 90. > > > > You are stating at the OSPF chair that those models have the front seat > in looking at the I2RS models without reading any of the I2RS IM/DM draft= s > we have prepared. > > > > The work on the OSPF and ISIS YANG models pre-dated the drafts you have > submitted yesterday by quite some time so I don=E2=80=99t see we should c= onsider > replacing it. > > > > Acee =E2=80=93 I=E2=80=99m afraid you rare confusing the I2RS work with t= he configuration > work. Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), was > there a suggestion these might work. > > > > Please confirm that I understand this message so that I can determine > the next steps to take with these drafts. > > > > Your next step should be to review the OSPF/ISIS drafts. > > > > Thanks,A > > Acee > > > > > > > > > > Sue > > > > *From:* Acee Lindem (acee) [mailto:acee@cisco.com ] > *Sent:* Saturday, September 27, 2014 6:32 PM > *To:* Susan Hares; 'Jeffrey Haas' > *Cc:* i2rs@ietf.org > *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports > > > > > > *From: *Susan Hares > *Date: *Saturday, September 27, 2014 at 6:16 PM > *To: *Acee Lindem , Jeff Haas > *Cc: *"i2rs@ietf.org" > *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > Acee: > > > > I=E2=80=99m confused by this email thread because these slides state the = authors > are looking for co-authors for netmod drafts. Are you as the co-chair of > OSPF declaring consensus on the OSPF yang model draft? > > > > Yes =E2=80=93 and there are now multi-vendor design teams in place. > > > > > > Would you point me to the email that indicates the WG Adoption call and > conclusion? > > > > We haven=E2=80=99t adopted yet in OSPF. ISIS adoption is in progress. I a= lready > searched the proceedings for the presentations. Note that the list archiv= es > offer a search capability=E2=80=A6 Anyway, here is the ISIS message: > > > > http://www.ietf.org/mail-archive/web/isis-wg/current/msg03679.html > > > > > > > > The drafts I suggested are I2RS drafts for the I2RS datastore that allow > it to configure the routing agent directly. The only way these two drafts > interact is if the option 4 proposed by the Yang 1.1 interim (created > 9/19/14) works. It is unclear if it will work =E2=80=93 that=E2=80=99s u= nder discussion. > There is no reason to stop the I2RS DM/IM models required by I2RS charter > work while we find out if option 4 works. > > > > And out of curiosity, if we are now considering option 4 why don=E2=80=99= t you > want more input and collaboration that provides insight from people who > looked at the OSPF for the I2RS use that option 4 suggests? We have > complete IM and DM (yang compiled) for the configuration we thought was > necessary for I2RS if the agent talked directly to the routing process (t= he > assumption of all I2RS with unique data store). > > > > Please review the OSPF and ISIS drafts with respect to option 4. > > > > Thanks, > > Acee > > > > > > > > > > > > Sue > > > > PS =E2=80=93 the ISIS Draft is not listed as approved or listed on the IS= IS mail > list as approved. It has not been updated since 6/27/14. If you believe = it > should be listed that way, you might want to talk to the ISIS co-chairs. > > > > *From:* Acee Lindem (acee) [mailto:acee@cisco.com ] > *Sent:* Saturday, September 27, 2014 5:06 PM > *To:* Susan Hares; 'Jeffrey Haas' > *Cc:* i2rs@ietf.org > *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > Sue: > > > > Did you look at the archives for the OSPF and ISIS WGs? Both drafts were > presented at IETF 90 in Toronto. We intend to cross review the OSPF YANG > model in both the netmod and OSPF WGs. The ISIS YANG Model is already bei= ng > accepted as an ISIS WG document. > > > > http://www.ietf.org/proceedings/90/slides/slides-90-isis-0.pdf > > http://www.ietf.org/proceedings/90/slides/slides-90-ospf-8.pdf > > > > Acee > > > > *From: *Susan Hares > *Date: *Saturday, September 27, 2014 at 4:32 PM > *To: *Acee Lindem , Jeff Haas > *Cc: *"i2rs@ietf.org" > *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > Acee: > > > > Was this work announced on any list at IETF for general contribution? I > don=E2=80=99t see an announcement on the ospf list or the ISIS list? Per= haps you > could point me to the list where this was announced? > > > > Sue > > > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org ] *On > Behalf Of *Acee Lindem (acee) > *Sent:* Saturday, September 27, 2014 3:58 PM > *To:* Susan Hares; 'Jeffrey Haas' > *Cc:* i2rs@ietf.org > *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > > > > > *From: *Susan Hares > *Date: *Friday, September 26, 2014 at 11:36 PM > *To: *Jeff Haas > *Cc: *"i2rs@ietf.org" > *Subject: *Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > Jeff: > > > > Please add to the agenda the following drafts: I2RS yang Data and > Information models for ISIS, OSPF, Basic Network Policy (BNP), PBR and > BGP. PBR and BGP will be uploaded next week after some internal review. > > > > HI Sue, > > We are currently have drafts for the OSPF and ISIS YANG models and have > multi-vendor design teams contributing to them. This works is being done = in > the OSPF and ISIS WG groups. You are welcome to review it but please don= =E2=80=99t > create confusion with alternate drafts. > > > > Thanks, > > Acee > > > > > > > > > > > > > > > > The PBR model is the information model that is a collaboration between th= e > PBR (draft-kini-i2rs-pbr-info-model-00) and the > (draft-hares-i2rs-policy-info-model). We hoped to have the agreement on > the text early next week (just 1 technical discussion). The author team > has had meetings in August and September. > > > > Please add the use case to the agenda. > > > > One question =E2=80=93 should I be submitting these I2RS configuration IM= /DM as > netmod models? If so, I will do this as well. > > > > Sue > > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org ] On > Behalf Of Dean Bogdanovic > Sent: Thursday, September 25, 2014 2:44 PM > To: Jeffrey Haas > Cc: i2rs@ietf.org > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > > > Jeff, > > > > To kickstart the discussions > > > > looking at what is needed in NETMOD and NETCONF for I2RS > > > > datastore for I2RS (use cases for ephemeral data store) > > > > working on ACL YANG model - with ACL model available and > draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model > (draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'll > try to submit the draft by the deadline (it is dependent on new > draft-ietf-netmod-routing-cfg, probably draft-ietf-netmod-routing-cfg-16, > being published) > > > > Dean > > > > On Sep 25, 2014, at 2:00 PM, Jeffrey Haas wrote: > > > > > Your chairs have been a bit over-busy recently with travel to unicast > > > people doing various bits of chartered work. This means we've been > > > behind on some of our goals in terms of getting regular design > > > sessions running. I know that at least a couple calls have happened > > > that I've missed that Sue Hares has done, so some progress is being mad= e. > > > > > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > > > a chance to talk. This is a call for agenda slots. > > > > > > This is also a call for status reports. > > > > > > We've had some productive discussion about requests to netmod/netconf, > > > albeit ones that haven't converged yet. > > > > > > What have you been up to? > > > > > > -- Jeff & 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 > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --089e0153894405bf53050429b5d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Acee,

It is NOT OK to tell anyone that = they should not contribute a draft - because it may muddy the water
or for ANY other non-technical reason.=C2=A0 Individual drafts or desire= to request WG adoption do not change
this.=C2=A0 I do not ever w= ant to see or hear something like this on an IETF mailing list.
<= br>
Very very few drafts start perfect and different models have = different perspectives.=C2=A0 The IETF has a
consensus process, a= s you well know of course, to resolve differences between perspectives and = drafts.

Second, a NETMOD interim with tentative id= eas on how it might be nice to carry out requests in an=C2=A0
ind= ividual draft =C2=A0does not in any way dictate how I2RS should proceed.=C2= =A0 I2RS is in Routing
because we understand the work and details= to be done.=C2=A0 The desire that there can be only one model for
any and all purposes is interesting but it isn't clear that is feasib= le.

I d not have any more polite words to discuss = this.

Alia

On Sun, Sep 28= , 2014 at 12:59 PM, Acee Lindem (acee) <acee@cisco.com> wrote:<= br>
Sue,

See inline.

From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 = at 8:21 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <= jhaas@pfrc.org><= br> Cc: "i2rs@ietf.org" <i2rs@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Acee:

=C2=A0

I think we are still c= onfused. The different streams (i2RS/config) that may or may not be merged = (under debate).=C2=A0 Both i2rs/config streams had open calls at IETF 90 fo= r contributions and collaborators based on pre-IETF 90 work. On that portion of topic after this message, let=E2=80= =99s declare rat hole. =C2=A0

=C2=A0

My key question is sti= ll unanswered: =C2=A0=E2=80=9CDo I understand is that you as co-chair of OS= PF are stating you recommend not reading or reviewing the I2RS OSPF drafts = I and my-authors created for the I2RS stream and instead you recommend figuring out if your existing configuration drafts f= it I2RS?=E2=80=9D =C2=A0I appreciate your bluntness so I can figure where t= o put our next efforts in I2RS. =C2=A0

Note the IESG statement on YANG models independent of I2RS:=C2=A0


We have been working on YANG models for some time in both OSPF and ISI= S. The ISIS model is already being adopted and we will request WG OSPF adop= tion upon the next refresh. I can=E2=80=99t help it if you are not followin= g the WGs for which you are proposing models. For your next efforts, I'd recommend better coordination and awareness= of WG activities.

Thanks,
Acee=C2=A0





<= /p>

=C2=A0

Thank you, <= /u>

=C2=A0

Sue

=C2=A0

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 7:37 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

=C2=A0

= =C2=A0

= =C2=A0

From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 at 7:22 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ie= tf.org" <i2r= s@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

= =C2=A0

Acee:

=C2=A0

Thank you for the poin= ter to the message in ISIS.=C2=A0 Perhaps since Chris just declared consens= us Friday the 9/19/14 that he will get around to posting these drafts.

= =C2=A0

I=E2=80= =99m not sure why you are suggesting that these drafts have not been previo= usly posted.=C2=A0

= =C2=A0

=C2=A0

Acee =E2=80=93 my mess= age indicates the isis drafts had not been posted as: draft-isis-yang-isis-= cfg, and that draft-yeung-netmod-ospf was not the ospf web page or netmod w= eb page.=C2=A0=C2=A0 It is a polite indication between chairs that if this is important .. you might want to catch up with your h= ousekeeping. =C2=A0

= =C2=A0

=C2=A0

To be clear, I underst= and from your work that you are declaring consensus on the yang models for = OSPF model based on your knowledge of the private multi-vendor design team.= =C2=A0

= =C2=A0

As you = noted, both the presentations at IETF 90 called for participation. These de= sign teams are much less private than the OSPF/ISIS IM/DM drafts you submit= ted yesterday.=C2=A0

=C2=A0

Acee =E2=80=93 this is= simply not true.=C2=A0 See the above information =E2=80=93 it had the same= level of call at IETF 90. =C2=A0

= =C2=A0

You are stating at the= OSPF chair that those models have the front seat in looking at the I2RS mo= dels without reading any of the I2RS IM/DM drafts we have prepared.<= span style=3D"color:black">

= =C2=A0

The wor= k on the OSPF and ISIS YANG models pre-dated the drafts you have submitted = yesterday by quite some time so I don=E2=80=99t see we should consider repl= acing it.=C2=A0=C2=A0= =C2=A0

=C2=A0

Acee =E2=80=93 I=E2=80= =99m afraid you rare confusing the I2RS work with the configuration work.= =C2=A0 Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), was t= here a suggestion these might work. =C2=A0=C2=A0

= =C2=A0

=C2=A0Please confirm t= hat I understand this message so that I can determine the next steps to tak= e with these drafts.

= =C2=A0

Your ne= xt step should be to review the OSPF/ISIS drafts.=C2=A0

= =C2=A0

Thanks,= A

Acee=C2= =A0

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

Sue

=C2=A0

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 6:32 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports

=C2=A0<= /span>

=C2=A0<= /span>

From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 at 6:16 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ie= tf.org" <i2r= s@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

=C2=A0<= /span>

Acee:=

=C2=A0

I=E2=80=99m confused by this email threa= d because these slides state the authors are looking for co-authors for net= mod drafts. Are you as the co-chair of OSPF declaring consensus on the OSPF yang model draft?

=C2=A0<= /span>

Yes =E2= =80=93 and there are now multi-vendor design teams in place.=C2=A0

=C2=A0<= /span>

=C2=A0<= /span>

Would you point me to the email that ind= icates the WG Adoption call and conclusion?

=C2=A0<= /span>

We have= n=E2=80=99t adopted yet in OSPF. ISIS adoption is in progress. I already se= arched the proceedings for the presentations. Note that the list archives o= ffer a search capability=E2=80=A6 Anyway, here is the ISIS message:

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0

The drafts I suggested are I2RS drafts f= or the I2RS datastore that allow it to configure the routing agent directly= . The only way these two drafts interact is if the option 4 proposed by the Yang 1.1 interim (created 9/19/14) work= s.=C2=A0 It is unclear if it will work =E2=80=93 that=E2=80=99s under discu= ssion. There is no reason to stop the I2RS DM/IM models required by I2RS ch= arter work while we find out if option 4 works.

=C2=A0

And out of curiosity, if we are now cons= idering option 4 why don=E2=80=99t you want more input and collaboration th= at provides insight from people who looked at the OSPF for the I2RS use that option 4 suggests?=C2=A0 We have complete I= M and DM (yang compiled) for the configuration we thought was necessary for= I2RS if the agent talked directly to the routing process (the assumption o= f all I2RS with unique data store). =C2=A0

=C2=A0<= /span>

Please = review the OSPF and ISIS drafts with respect to option 4.

=C2=A0<= /span>

Thanks,=

Acee=C2= =A0

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0

Sue

=C2=A0

PS =E2=80=93 the ISIS Draft is not liste= d as approved or listed on the ISIS mail list as approved. It has not been = updated since 6/27/14.=C2=A0 If you believe it should be listed that way, you might want to talk to the ISIS co-chairs. <= span style=3D"color:black">

=C2=A0

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: Saturday, September 27, 2014 5:06 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

=C2=A0

Sue:=C2= =A0

=C2=A0<= /span>

Did you= look at the archives for the OSPF and ISIS WGs? Both drafts were presented= at IETF 90 in Toronto. We intend to cross review the OSPF YANG model in bo= th the netmod and OSPF WGs. The ISIS YANG Model is already being accepted as an ISIS WG document.=C2=A0<= span style=3D"color:black">

=C2=A0<= /span>

=C2=A0<= /span>

Acee=C2= =A0

=C2=A0<= /span>

From: Susan Hares <shares@ndzh.com>
Date: Saturday, September 27, 2014 at 4:32 PM
To: Acee Lindem <acee@cisco.com>, Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ie= tf.org" <i2r= s@ietf.org>
Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

=C2=A0<= /span>

Acee:

=C2=A0

Was this work announce= d on any list at IETF for general contribution?=C2=A0 I don=E2=80=99t see a= n announcement on the ospf list or the ISIS list?=C2=A0 Perhaps you could p= oint me to the list where this was announced?

=C2=A0

Sue

=C2=A0

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, September 27, 2014 3:58 PM
To: Susan Hares; 'Jeffrey Haas'
Cc: i2rs@ietf.org=
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

=C2=A0

=C2=A0<= /span>

=C2=A0<= /span>

From: Susan Hares <shares@ndzh.com>
Date: Friday, September 26, 2014 at 11:36 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: "i2rs@ie= tf.org" <i2r= s@ietf.org>
Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; sta= tus reports?

=C2=A0<= /span>

Jeff:

=C2=A0

Please add to the agenda the following draft= s: I2RS yang Data and Information models for ISIS, OSPF, Basic Network Poli= cy (BNP), PBR and BGP.=C2=A0 PBR and BGP will be uploaded next week after s= ome internal review. =C2=A0=C2=A0

=C2=A0<= /span>

HI Sue,=

We are = currently have drafts for the OSPF and ISIS YANG models and have multi-vend= or design teams contributing to them. This works is being done in the OSPF = and ISIS WG groups. You are welcome to review it but please don=E2=80=99t create confusion with alternate draf= ts.=C2=A0

=C2=A0<= /span>

Thanks,=

Acee=C2= =A0

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0

The PBR model is the information model that = is a collaboration between the PBR (draft-kini-i2rs-pbr-info-model-00) and = the (draft-hares-i2rs-policy-info-model).=C2=A0 =C2=A0We hoped to have the = agreement on the text early next week (just 1 technical discussion). =C2=A0=C2=A0The author team has h= ad meetings in August and September. =C2=A0=C2=A0

=C2=A0

Please add the use case to the agenda.

=C2=A0

One question =E2=80=93 should I be submittin= g these I2RS configuration IM/DM as netmod models? If so, I will do this as= well.

=C2=A0

Sue

=C2=A0

-----Original Message-----
From: i2rs [mail= to:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic
Sent: Thursday, September 25, 2014 2:44 PM
To: Jeffrey Haas
Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status rep= orts?

=C2=A0

Jeff,

=C2=A0

To kickstart the discussions

=C2=A0

looking at what is needed in NETMOD and NETC= ONF for I2RS

=C2=A0

datastore for I2RS (use cases for ephemeral = data store)

=C2=A0

working on ACL YANG model - with ACL model a= vailable and draft-ietf-netmod-routing-cfg-15 being fixed, PBR info model (= draft-kini-i2rs-pbr-info-model-00) can be extended into data model. I'l= l try to submit the draft by the deadline (it is dependent on new draft-ietf-netmod-routing-cf= g, probably draft-ietf-netmod-routing-cfg-16, being published)

=C2=A0

Dean

=C2=A0

On Sep 25, 2014, at 2:00 PM, Jeffrey Haas &l= t;jhaas@pfrc.org> wrote:

=C2=A0

> Your chairs have been a bit over-busy r= ecently with travel to unicast

> people doing various bits of chartered = work.=C2=A0 This means we've been

> behind on some of our goals in terms of= getting regular design

> sessions running.=C2=A0 I know that at = least a couple calls have happened

> that I've missed that Sue Hares has= done, so some progress is being made.

>

> We've requested a 1 hour time slot = for IETF 91 in Honolulu to give us

> a chance to talk.=C2=A0 This is a call = for agenda slots.

>

> This is also a call for status reports.=

>

> We've had some productive discussio= n about requests to netmod/netconf,

> albeit ones that haven't converged = yet.

>

> What have you been up to?=

>

> -- Jeff & Ed

>

> _______________________________________= ________

> i2rs mailing list<= /p>

> i2rs@ietf.org<= /a>

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

=C2=A0

____________________________________________= ___

i2rs mailing list

i2rs@ietf.org<= /span>

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


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


--089e0153894405bf53050429b5d0-- From nobody Sun Sep 28 23:31: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 6F8F91A6FC1; Sun, 28 Sep 2014 23:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW6G0osyJb5k; Sun, 28 Sep 2014 23:31:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F831A6FC6; Sun, 28 Sep 2014 23:31:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9682A75C; Mon, 29 Sep 2014 08:31:52 +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 CFvKdk3Vsmxt; Mon, 29 Sep 2014 08:31:51 +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; Mon, 29 Sep 2014 08:31:52 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2665120036; Mon, 29 Sep 2014 08:31:52 +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 3KdlbGIalfAa; Mon, 29 Sep 2014 08:31:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5D9720035; Mon, 29 Sep 2014 08:31:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 946DD2EA67D2; Mon, 29 Sep 2014 08:31:49 +0200 (CEST) Date: Mon, 29 Sep 2014 08:31:49 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140929063149.GB76248@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , "'Thomas D. Nadeau'" , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <20140925062456.GB26200@elstar.local> <02ce01cfd9a5$c1e81f40$45b85dc0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02ce01cfd9a5$c1e81f40$45b85dc0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/WglpmxSxAmzNmEmY7HFJqq0aJcg Cc: 'Jeffrey Haas' , "'Thomas D. Nadeau'" , netmod@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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: Mon, 29 Sep 2014 06:31:56 -0000 On Fri, Sep 26, 2014 at 12:20:15PM -0400, Susan Hares wrote: > Juregen and Jeff: > > Can you define what a merge is? Could you define it using the example below > and another one? I know you have talked around the subject, but I need > another examples so I can adjust the drafts in progress with co-authors > (ISIS IM-DM, OSPF IM-DM, BGP IM-DM, PBR IM/DM) for i2rs. > > Sue > > ============ > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > Merge as in NETCONF. We also discussed to have meta data attached to nodes in ephemeral datastores in order to allow things to be deleted 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 Mon Sep 29 07:16:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980F31A1A9E; Mon, 29 Sep 2014 07:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGGrhuDzRsYv; Mon, 29 Sep 2014 07:16:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 750EA1A8755; Mon, 29 Sep 2014 07:15:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3ADAFC141; Mon, 29 Sep 2014 10:15:22 -0400 (EDT) Date: Mon, 29 Sep 2014 10:15:22 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140929141522.GA7854@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> <02d301cfd9a6$0f331c00$2d995400$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02d301cfd9a6$0f331c00$2d995400$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1U_6ysVuic8eb4ebUTMrM1Xa40A Cc: 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 29 Sep 2014 14:16:19 -0000 [Note that I'm responding to things in thread-order. I2RS was very busy for a few days while I had to pay attention to other things, so my responses may appear to jump around a bit.] Sue, On Fri, Sep 26, 2014 at 12:22:25PM -0400, Susan Hares wrote: > > Just to confirm three facts before I put them in i2rs drafts (based on > Juergen's email > > - based on Juergen's email: I2RS is "config true empheral". This is a point of discussion. A critical thing to realize from the netmod interim is that it was simply a first step to trying to define what "ephemeral" even *means* in the context of existing yang and netconf/restconf. The "option 4" solution was the proposal that worked its way through discussion points with the yang experts, but still needs discussion within I2RS and then related followup with netconf if we decide it's the way to go. I like the idea, but as discussion is pointing out, there's a lot of details to reconcile. The impact of this upon writing data models for I2RS would appear to be at this point: - They're just "config true" (per correction from Juergen), but simply done in the ephemeral datastore. How you document that they're just in the ephemeral data store is unclear at this point. - They're otherwise just normal models. - But if they're intended to be i2rs ephemeral extensions on local config models (e.g. protocol WG data models), we have some dependency work to reconcile with those groups. > If i2rs has additional configuration for BGP related to your I2RS peers for > reporting routes: > > > > . BGP based config + I2RS additional config + AS Config > > > > Can I2RS have additional configuration values specific to I2RS? For > example, information regarding how often to report the routes for a > particular pear? Correct. We have roughly four scenarios with regard to modeling impact: A. Completely disjoint models for I2RS that use no state from other protocol modules and no dependencies, but interact with underlying state of that protocol. E.g. BGP configuration in an I2RS model that doesn't extend a IDR Yang module nor have constraints in such a module. B. A disjoint model for I2RS that has constraints against other modules. E.g. the I2RS BGP module may have a "must" statement against a IDR yang module's "autonomous system" configuration. C. A hybrid I2RS module that augments an underlying protocol module. This is the scenario you're suggesting above. The critical detail is since it's an augmentation it is suggesting there exists such a protocol module. D. There is a unified module developed in some working group that may simply choose to store some of its state in an ephemeral fashion. D is the newest option enabled by the "option 4" discussion from the netmod interim. -- Jeff From nobody Mon Sep 29 07:16: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 B3B6E1A1A9E; Mon, 29 Sep 2014 07:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9moIv-gjJNC; Mon, 29 Sep 2014 07:16:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ABD251A1AE2; Mon, 29 Sep 2014 07:16:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 70A88C141; Mon, 29 Sep 2014 10:16:36 -0400 (EDT) Date: Mon, 29 Sep 2014 10:16:36 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140929141636.GB7854@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> <032401cfd9ac$da30b060$8e921120$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032401cfd9ac$da30b060$8e921120$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/I0qnFmSe4SOPt2nkkyt6dzDdgjc Cc: 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf 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, 29 Sep 2014 14:16:50 -0000 Sue, On Fri, Sep 26, 2014 at 01:11:02PM -0400, Susan Hares wrote: > Jeff: > > Could you give me an example of the interim's thoughts on commit versus > Alexander's message: > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01974.html I'll address this point in the original thread. -- Jeff From nobody Mon Sep 29 07:54: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 4D37A1A6FAD for ; Mon, 29 Sep 2014 07:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YGjegHDdzSb for ; Mon, 29 Sep 2014 07:54:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 41BAE1A1ADB for ; Mon, 29 Sep 2014 07:54:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8D519C141; Mon, 29 Sep 2014 10:54:38 -0400 (EDT) Date: Mon, 29 Sep 2014 10:54:38 -0400 From: Jeffrey Haas To: Martin Bjorklund Message-ID: <20140929145438.GC7854@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925.163901.67679202204863959.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HOGPgdTImLdp0RnLGSMWcstMeq4 Cc: jhaas@pfrc.org, i2rs@ietf.org Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:54:40 -0000 [Responding in thread order] On Thu, Sep 25, 2014 at 04:39:01PM +0200, Martin Bjorklund wrote: > I think there might be a terminology confusion here, so let's do a > simple example. > > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. Correct. > What happens if we in local config delete foo 42? The original set for the ephemeral datastore was for id=42, I'd expect the GET to still return foo id=42 a=4711 > If /foo[id=42]/a is NOT deleted from the ephemeral config, what is now > presented to the internal apps? foo id=42 a=4711 A slightly different example: local config: foo id=42 a=1 GET returns foo id=42 a=1 SET /foo[id=42]/a to 4711 in the ephemeral datastore. GET returns foo id=42 a=4711 Two potential actions: a) Delete /foo[id=42] in the ephemeral datastore. GET returns id=42 a=1 (the underlying local config remains) b) Delete /foo[id=42] in the local config GET returns id=42 a=4711 (the overlay ephemeral config) ----- In general, I'm not expecting the above type of behavior to be a common i2rs operation where local config and ephemeral config overlap. When they do, the above example shows ephemeral having priority over local config - but as we discussed, that semantic may not always be the desired one. What I find more likely is either: foo id=42 a=1 # Datastore local config foo id=43 a=4711 # Datastore ephemeral No overlap. Or alternatively: list foo { key id; leaf id { type int32; } leaf a { type int32; } leaf i2rs:b { type int32; } } Where b is introduced either via augmentation from a separate module or alternatively something like b is explicitly listed in the module defining foo. In either case, b is noted to be an item that intended for the ephemeral data store. This leads to the question: SET foo id=42 a=1 # Datastore local config SET foo id=42 b=4711 # epehemeral data store GET foo returns id=42 a=1 b=4711 And then: a) Delete foo id=42 in the local config GET returns foo id=42 b=4711 b) Delete foo id=42 in the ephemeral datastore GET returns foo id=42 a=1 -- Jeff From nobody Mon Sep 29 08:01: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 6D5191A875E for ; Mon, 29 Sep 2014 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azR3W6_HzLeV for ; Mon, 29 Sep 2014 08:01:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1931A6FAE for ; Mon, 29 Sep 2014 08:01:10 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 42AFFC141; Mon, 29 Sep 2014 11:01:10 -0400 (EDT) Date: Mon, 29 Sep 2014 11:01:10 -0400 From: Jeffrey Haas To: "Alexander Clemm (alex)" Message-ID: <20140929150110.GD7854@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> 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/XU8W93EtxECGVfTUZBAySWVBNX4 Cc: Jeffrey Haas , "i2rs@ietf.org" , Martin Bjorklund , "Eric Voit \(evoit\)" , Andy Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:01:12 -0000 Alex, On Fri, Sep 26, 2014 at 12:57:20AM +0000, Alexander Clemm (alex) wrote: > The complexity here comes from the fact that there are dependencies between different data stores, and some objects that are part of one data store need to be reflected in a different data store. > > It would seem this can be addressed with two fairly simple principles: > > (a) A datastore needs to have a clear way to reference objects in a different datastore, really have them incorporated into the same namespace. This was discussed in my draft for the netmod interim. Right now, that is an issue if we have them in a different datastore and not in the same namespace. The "option 4" is really to have a unified schema across the datastores and thus we no longer have issues for how to do references. > (b) It needs to be clear who owns the "golden copy" of an object. I needs to be clear which objects are "authoritatively owned" by a datastore vs which ones are reference. This is the datastore where the object is maintained, updated, created; this is where conditions and constraints are evaluated, etc. This seems obvious, but there are a few potentially conflicting scenarios. If objects that are always intended to be ephemeral are never going to conflict (but may lie on top of) local config, there is never a conflict. There is simply referential integrity issues if the underlying local config is deleted and ephemeral config remains. If the objects are always disjoint, there is never a conflict. But if you permit an ephemeral object to override a local config one within the schema, we have this issue. Our options would appear to be: - Do not permit such overrides. Design your models so that when it is desired to configure the same underlying operational state from multiple sources, it is through disjoint pieces of the model. An example would be for static routes to have a local-config mechanism and a completely separate ephemeral config model. This is the "easy" option. - Permit such overrides as long as the semantics are "clear". > Where an ephemeral datastore has dependencies on data in another datastore, it should incorporate these other objects "by reference". The objects that are authoritatively owned by the ephemeral datastore can refer to those objects, have them referred to in conditions and constraints, and so on. (This can also indicate which ephemeral objects are to be removed when an object in the other datastore they depend on is deleted, etc) > > Changes to the non-ephemeral objects (e.g. the running datastore) have to be made to the "golden copy", i.e. the owning datastore. One way to do that involves implementing a "write-through" operation, in which an update to an ephemeral copy of the object is realized by having the server of the ephemeral datastore turn around and make a corresponding request at the other datastore. > > Very simple semantics. I think this is preferrable to have different copies of the same object in different datastores, requiring "logical anding" (or other inter-datastore arithmetic) of different copies representing the same object to figure out what actual value is in effect, etc. > > In the netmod WG, we have today posted a draft for what we refer to as requirements for a peer mount (http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requirements-00.txt), motivating why a it would be useful to have a capability to "mount" subtrees from a remote datastore into a local datastore, and the requirements that such a capability needs to address. While the original use case and motivation described there are somewhat different, it seems applicable to the discussion here. I'll have to ready this draft. From the title, the ability to "mount" a subtree was one of the likely use cases in i2rs where augmenting protocol modules was done rather than "copy and paste" sections (or utilizing well refactored groupings) in a separate model. -- Jeff From nobody Mon Sep 29 08:02:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C01A876A for ; Mon, 29 Sep 2014 08:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbInj45nFaBS for ; Mon, 29 Sep 2014 08:02:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 438241A8758 for ; Mon, 29 Sep 2014 08:02:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 15EA0C141; Mon, 29 Sep 2014 11:02:36 -0400 (EDT) Date: Mon, 29 Sep 2014 11:02:36 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20140929150235.GE7854@pfrc> References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> <54278C94.40307@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54278C94.40307@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/36BCz91WHP2fo_zTZsMTKI5L8Go Cc: "i2rs@ietf.org" , 'Martin Bjorklund' , "Eric Voit \(evoit\)" , "Alexander Clemm \(alex\)" , 'Andy Bierman' , 'Jeffrey Haas' , Susan Hares Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:02:40 -0000 On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote: > If I am reading you correctly, you are saying taht if an I2RS client > is manipulating data that is stored in the underlying golden store, > you want that golden store changed. > I think that won't work for the requirements. As far as I can tell > from your proposal, this would result in I2RS changes being stored > when someone on the CLI does a commit. Which is not what is wanted. I agree with you, Joel. This doesn't match the semantics the I2RS WG wanted. > Conversely, a read-through model would seem to work. Objects which > have been created / modified in the I2RS store, when read from the > I2RS store have their I2RS value. If you attempt to read or > reference a value that has not been modified in I2RS, you > read-through to the underlying data store, and see its value. Hopefully my most recent example shows this. -- Jeff From nobody Mon Sep 29 11:44: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 24B8B1A9104 for ; Mon, 29 Sep 2014 11:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.687 X-Spam-Level: X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdnTQmmOghyH for ; Mon, 29 Sep 2014 11:44:55 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81381A8840 for ; Mon, 29 Sep 2014 11:44:54 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Sep 2014 12:44:54 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 29 Sep 2014 12:44:51 -0600 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 894E63E40044 for ; Mon, 29 Sep 2014 12:44:50 -0600 (MDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s8TIio3c54591580 for ; Mon, 29 Sep 2014 20:44:50 +0200 Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s8TIin8w008872 for ; Mon, 29 Sep 2014 12:44:50 -0600 Received: from cichlid.raleigh.ibm.com ([9.80.86.225]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s8TIimHd008787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Sep 2014 12:44:49 -0600 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id s8TIikgh030994; Mon, 29 Sep 2014 14:44:47 -0400 Date: Mon, 29 Sep 2014 14:44:46 -0400 Message-ID: From: Thomas Narten To: Alia Atlas In-Reply-To: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14092918-0928-0000-0000-0000053EA2E2 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/MOXAh7fNkgq26oNzHU56HCTirXk Cc: Jeffrey Haas , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 18:44:57 -0000 > It is NOT OK to tell anyone that they should not contribute a draft - bec= ause > it may muddy the water > or for ANY other non-technical reason.=A0 Individual drafts or desire to = request > WG adoption do not change > this.=A0 I do not ever want to see or hear something like this on an IETF > mailing list. Let me defend Acee here a bit and try to chart a course a bit more down the middle. When a WG has an effort underway that is intended to lead to a WG document (and that is what I read the current "design team" effort to be), it is IMO often not helpful to have yet more IDs submitted on the same topic. Rather than complementing the existing work towards a concensus result, additional IDs can be a distraction and require folk to spend time figuring out how the other ID relates to the WG effort. I.e., it's much more constuctive to say "here is what is defficient in the current model, and here is what I think we should do instead". It is much less constructive to have a standalone ID that (probably) overlaps with the other IDs and doesn't focus on the *differences* from the other work that already has a head start. It is the case that the IETF mantra is "submit a draft", but frankly, I think that is a bit of a sound bite that we would do well to not spit out as often as we seem to because it too often misses what really should happen, namely, how best to contribute to reaching consensus in a WG. We have a huge problem today where there are overlapping/competing drafts that WGs have to sort through. And in many of those cases, additional IDs have very little additional content than what already exists. But since we go around telling folk to "submit an ID", we shouldn't be surprise that we get them beyond the point of diminishing returns. (And I am NOT saying that the draft at issue here is one of those.) In this case (and I personally don't have any skin in the game), it seems to that both parties are making honest efforts to do the right thing, but unfortunately, the state of play was not fully known to all. > Very very few drafts start perfect and different models have > different perspectives.=A0 The IETF has a consensus process, as you > well know of course, to resolve differences between perspectives and > drafts. I didn't hear anyone say that consensus has already been called. My take away is that we have a WG making an honest effort to move forward in a particular direction and it is doing exactly what it should be in terms of getting behind a design team effort. And IMO, once you have a WG design team working on an effort, having others submit drafts in the same space is not always what we should be encouraging people to do. Does that mean we should not allow additional IDs? Of course not. Does it mean we won't look at them and give them consideration"? Of course not. But we should also be honest that if a WG has an official document or has a DT working on a document, having additional "competing" documents show up is often not the most constructive way to contribute. Unless news IDs really are clear about how they relate to the other efforts and what those other efforts are lacking. Thomas From nobody Mon Sep 29 11:55: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 6DAC41A9143 for ; Mon, 29 Sep 2014 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 YV-f5k4YP8wr for ; Mon, 29 Sep 2014 11:55:42 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBA31A9104 for ; Mon, 29 Sep 2014 11:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=972; q=dns/txt; s=iport; t=1412016942; x=1413226542; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=DkbjsIGFdg7wgvTbVHJUZGoSC48gmyK2FjdcYqB6xTY=; b=cCnnHHQ5x6exQBG9kMcEXZP2ccsA4Umks+oeX8zAm+CssrkH+P1cqkrb rQodDTHDGVRgb0aj1P+vYiYINSaDiGDR1MFbG8dN7/OEdCKH4LFoaw+XY T974vtKlE+NZi+wfwCkIRVXoYliAfZFAIlMqvOl2+i8QZSNfPymRrivVG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAyrKVStJA2N/2dsb2JhbABggw7TEQKBFRYBe4QEAQEEHRtAEQsOCgkWDwkDAgECAUUGAQwIAQGIOr9AAReMS4NahEsBBJ0oh1KOC4N/IYJ5AQEB X-IronPort-AV: E=Sophos;i="5.04,622,1406592000"; d="scan'208";a="82452122" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 29 Sep 2014 18:55:21 +0000 Received: from [10.19.102.119] (sjc-julhunte-8816.cisco.com [10.19.102.119]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8TItKxO003660; Mon, 29 Sep 2014 18:55:21 GMT Message-ID: <5429AB19.4050406@cisco.com> Date: Mon, 29 Sep 2014 14:55:21 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Jeffrey Haas , i2rs@ietf.org References: <20140925180055.GB1239@pfrc> In-Reply-To: <20140925180055.GB1239@pfrc> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/9pLVXZA_O8opN0lHQxM4T_KiUUM Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 18:55:43 -0000 On 9/25/14 2:00 PM, Jeffrey Haas wrote: > Your chairs have been a bit over-busy recently with travel to unicast people > doing various bits of chartered work. This means we've been behind on some > of our goals in terms of getting regular design sessions running. I know > that at least a couple calls have happened that I've missed that Sue Hares > has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us a > chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? I think the list knows about the traceability "shoe" that's been waiting to drop. Question is, can it be settled on the list, should we ask in Honolulu? Does it need an agenda item or can the chairs raise the point? Thanks. Joe From nobody Mon Sep 29 13:49: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 195421ACCC7 for ; Mon, 29 Sep 2014 13:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 JxXo2KjY_C4Z for ; Mon, 29 Sep 2014 13:49:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D213F1A1BD9 for ; Mon, 29 Sep 2014 13:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3966; q=dns/txt; s=iport; t=1412023742; x=1413233342; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KP5qBzs6oMj3Tbja0hTJvDsBf5K0neja9ihXCnhtAj4=; b=NaXv92LW7OkpZuKOKOkes3xzIsjhs4akszLozLrYH8Kyq5pghrOHzi8c G4Ig3ZKFaPCGghz6LweG5U3UU8BlEqHThSlponE4KbgG5ZNIHWDpfyX4t DP3sQisBMzrE9mIk9DHj0/+ZPSXWVUOYIOoM1GFpkdSSfCHzw/GnsVGTO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAM3EKVStJV2T/2dsb2JhbABggw5TVwTKGodOAoEVFgF7hAQBAQMBHVELEAIBCEYyJQIEAQ0FCRGIHAgNvz0BF4oqgiGDIDMCBYRLBYsThlKLQ5Vdg2NsAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,622,1406592000"; d="scan'208";a="82493844" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP; 29 Sep 2014 20:49:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8TKn2IG004547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 20:49:02 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 15:49:01 -0500 From: "Acee Lindem (acee)" To: Thomas Narten , Alia Atlas Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqAgABRF4D//8ETAAAJ7j8AABpz1oAAGPrVAAAlYmsA///fpoA= Date: Mon, 29 Sep 2014 20:49:01 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] 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/-SMG0yUV-y_8swYMnIQajtmxmL8 Cc: Jeffrey Haas , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 20:49:05 -0000 Thanks Much Thomas! Given that I was the victim of considerable back-door escalations and machinations, I was giving myself a =B3cooling off=B2 perio= d prior responding. However, you expressed my sentiments with much more patience than I could have myself. Moving forward, we are going to have to agree on a home for these protocol models drafts. Of course, my preference would be to keep them in the protocol WGs with I2RS and I2RS review. Given the IESG statement on YANG models replaced MIBs (), I had viewed this as self-evident. Acee=20 On 9/29/14, 2:44 PM, "Thomas Narten" wrote: >> It is NOT OK to tell anyone that they should not contribute a draft - >>because >> it may muddy the water >> or for ANY other non-technical reason. Individual drafts or desire to >>request >> WG adoption do not change >> this. I do not ever want to see or hear something like this on an IETF >> mailing list. > >Let me defend Acee here a bit and try to chart a course a bit more >down the middle. When a WG has an effort underway that is intended to >lead to a WG document (and that is what I read the current "design >team" effort to be), it is IMO often not helpful to have yet more IDs >submitted on the same topic. Rather than complementing the existing >work towards a concensus result, additional IDs can be a distraction >and require folk to spend time figuring out how the other ID relates >to the WG effort. I.e., it's much more constuctive to say "here is >what is defficient in the current model, and here is what I think we >should do instead". It is much less constructive to have a standalone >ID that (probably) overlaps with the other IDs and doesn't focus on >the *differences* from the other work that already has a head start. > >It is the case that the IETF mantra is "submit a draft", but frankly, >I think that is a bit of a sound bite that we would do well to not >spit out as often as we seem to because it too often misses what >really should happen, namely, how best to contribute to reaching >consensus in a WG. We have a huge problem today where there are >overlapping/competing drafts that WGs have to sort through. And in >many of those cases, additional IDs have very little additional >content than what already exists. But since we go around telling folk >to "submit an ID", we shouldn't be surprise that we get them beyond >the point of diminishing returns. (And I am NOT saying that the draft >at issue here is one of those.) > >In this case (and I personally don't have any skin in the game), it >seems to that both parties are making honest efforts to do the right >thing, but unfortunately, the state of play was not fully known to all. > >> Very very few drafts start perfect and different models have >> different perspectives. The IETF has a consensus process, as you >> well know of course, to resolve differences between perspectives and >> drafts. > >I didn't hear anyone say that consensus has already been called. My >take away is that we have a WG making an honest effort to move forward >in a particular direction and it is doing exactly what it should be in >terms of getting behind a design team effort. And IMO, once you have a >WG design team working on an effort, having others submit drafts in >the same space is not always what we should be encouraging people to >do. > >Does that mean we should not allow additional IDs? Of course not. Does >it mean we won't look at them and give them consideration"? Of course >not. But we should also be honest that if a WG has an official >document or has a DT working on a document, having additional >"competing" documents show up is often not the most constructive way >to contribute. Unless news IDs really are clear about how they relate >to the other efforts and what those other efforts are lacking. > >Thomas > From nobody Mon Sep 29 14:08: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 07C1E1ACCED for ; Mon, 29 Sep 2014 14:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GrDt8tRSS7U for ; Mon, 29 Sep 2014 14:08:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 37D9D1ACCEC for ; Mon, 29 Sep 2014 14:08:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DAA91C141; Mon, 29 Sep 2014 17:08:01 -0400 (EDT) Date: Mon, 29 Sep 2014 17:08:01 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140929210801.GA24542@pfrc> References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005401cfdaa0$b297d070$17c77150$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7mIimebOguDp15x9O0V2PvZtbx4 Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Acee Lindem \(acee\)'" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:08:04 -0000 [Context for the WG, I spent some time talking to Sue about the topics here over lunch. I don't think anything has gone wrong beyond a need for greater communication of the involved parties. Picking this email to provide context...] On Sat, Sep 27, 2014 at 06:16:33PM -0400, Susan Hares wrote: > I'm confused by this email thread because these slides state the authors are > looking for co-authors for netmod drafts. Are you as the co-chair of OSPF > declaring consensus on the OSPF yang model draft? Would you point me to the > email that indicates the WG Adoption call and conclusion? As discussed later on in thread and also over my conversation with Sue, there is existing work for OSPF and ISIS for defining yang modules. That's great! Talking with Sue, there's a slightly different focus of intent: > The drafts I suggested are I2RS drafts for the I2RS datastore that allow it > to configure the routing agent directly. The only way these two drafts > interact is if the option 4 proposed by the Yang 1.1 interim (created > 9/19/14) works. It is unclear if it will work - that's under discussion. > There is no reason to stop the I2RS DM/IM models required by I2RS charter > work while we find out if option 4 works. The issue I2RS has had over the lingering ambiguity of what the I2RS ephemeral config was going to look like meant that the only instructions those who were going to do I2RS models was to take their best effort. Sue's analysis, similar to that of others, was that a configuration and operational model was going to be required. Note that while I haven't read the drafts, the comment above suggests that part of the work in there was to identify the insertion points that I2RS would need for I2RS functionality in the model. This is definitely work that we need as a WG. My own impression of the OSPF and ISIS work was while it was active, it was not necessarily that visible and may be happening in the context of a design team. If so, the impression may have been that the work has stalled. One of the discussion points at the last IETF with Benoit and the netmod chairs during their tutorial session was that the IETF is in need of a discussion list covering active efforts. This would serve to help solve some of the common modeling issues along with tracking work that may be common across models and deserving refactoring into a shared IETF module. An example of such work is the ACL work. I'm under the impression we have yet to create such a coordinating list? Further response later in thread... -- Jeff From nobody Mon Sep 29 14:16: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 B01A91ACCE5 for ; Mon, 29 Sep 2014 14:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebpU2TxA9xFs for ; Mon, 29 Sep 2014 14:16:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 532A81ACCD8 for ; Mon, 29 Sep 2014 14:16:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 14E48C141; Mon, 29 Sep 2014 17:16:50 -0400 (EDT) Date: Mon, 29 Sep 2014 17:16:49 -0400 From: Jeffrey Haas To: Thomas Narten Message-ID: <20140929211649.GB24542@pfrc> References: <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> 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/Gb5hqT5nWgwCid_TTInP10l2VfQ Cc: Jeffrey Haas , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares , Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:16:53 -0000 Thomas, [using your reply to continue my response...] On Mon, Sep 29, 2014 at 02:44:46PM -0400, Thomas Narten wrote: > > It is NOT OK to tell anyone that they should not contribute a draft - because > > it may muddy the water > > or for ANY other non-technical reason.? Individual drafts or desire to request > > WG adoption do not change > > this.? I do not ever want to see or hear something like this on an IETF > > mailing list. > > Let me defend Acee here a bit and try to chart a course a bit more > down the middle. When a WG has an effort underway that is intended to > lead to a WG document (and that is what I read the current "design > team" effort to be), it is IMO often not helpful to have yet more IDs > submitted on the same topic. Rather than complementing the existing > work towards a concensus result, additional IDs can be a distraction > and require folk to spend time figuring out how the other ID relates > to the WG effort. I.e., it's much more constuctive to say "here is > what is defficient in the current model, and here is what I think we > should do instead". It is much less constructive to have a standalone > ID that (probably) overlaps with the other IDs and doesn't focus on > the *differences* from the other work that already has a head start. I generally agree, but would also offer a counter point: As we go through our standardization efforts in the various routing protocol modules, some of the vendors will have created an internal model of their implementation. Having such a model is highly useful in the sense that it provides an overall view of how a given implementation functions. The challenge that will come is taking our individual models and reconciling them to a common IETF model. Obviously OSPF at least has made some progress toward such an implementation. BFD has recently kicked off its yang modeling work. One of the things I recommended as we start our analysis is that we simply provide the inputs in the github repository that was established for the work (currently in a repository based from my account) all contributions that help establish configuration and operational context. We currently have the BFD MIBs along with a contribution from Huawei. Juniper will be contributing its BFD yang as well and we're expecting others. I'd suggest that it might be good for the other protocol yang work to establish practices for vendor models for comparison purposes. Choose whatever place - github, or the I-D repository - you find handy. :-) > It is the case that the IETF mantra is "submit a draft", but frankly, > I think that is a bit of a sound bite that we would do well to not > spit out as often as we seem to because it too often misses what > really should happen, namely, how best to contribute to reaching > consensus in a WG. We have a huge problem today where there are > overlapping/competing drafts that WGs have to sort through. In speaking with Sue, I don't believe there was any intended affront to existing efforts. I think you'll find her happy to help coordinate that analysis and generate appropriate diffs. And I think we'll also find the benefit of having the I2RS cases considered as part of that work. > In this case (and I personally don't have any skin in the game), it > seems to that both parties are making honest efforts to do the right > thing, but unfortunately, the state of play was not fully known to all. Exactly. I think the feeling of people "getting their toes stepped upon" comes from some over-reactions. Hopefully we'll reset our levels and continue working on good standards. -- Jeff From nobody Mon Sep 29 14:20: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 2FE971ACCEA for ; Mon, 29 Sep 2014 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSMGVqtlvnm9 for ; Mon, 29 Sep 2014 14:20:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 82D831ACCE6 for ; Mon, 29 Sep 2014 14:20:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0EDBCC141; Mon, 29 Sep 2014 17:20:42 -0400 (EDT) Date: Mon, 29 Sep 2014 17:20:42 -0400 From: Jeffrey Haas To: "Acee Lindem (acee)" Message-ID: <20140929212042.GC24542@pfrc> References: <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> 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/NwyrKNsW2YIYlyaxdHKwaIv_B-8 Cc: Thomas Narten , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:20:44 -0000 On Mon, Sep 29, 2014 at 08:49:01PM +0000, Acee Lindem (acee) wrote: > Thanks Much Thomas! Given that I was the victim of considerable back-door > escalations and machinations, I was giving myself a ?cooling off? period > prior responding. However, you expressed my sentiments with much more > patience than I could have myself. Moving forward, we are going to have to > agree on a home for these protocol models drafts. Of course, my preference > would be to keep them in the protocol WGs with I2RS and I2RS review. Speaking ex oficio, I2RS is aware that protocol work MUST of necessity happen in the individually appropriate working groups. There is a strong need to avoid re-inventing various modeling constructs simply to satisfy the I2RS use case. This means that there's incentive for I2RS WG members to participate in a given WGs design efforts. Much like writing software, if we end up with copy and pasted content between modules, we've probably done it wrong. We may want to spend a portion of the upcoming rtg-area meeting discussing how to coordinate these efforts. As mentioned earlier in-thread, we've had discussions with Benoit and the netmod chairs about some form of this. -- Jeff From nobody Mon Sep 29 14:21: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 20E301ACCEB for ; Mon, 29 Sep 2014 14:21:39 -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 MdKCNL4dnO7x for ; Mon, 29 Sep 2014 14:21:33 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F131ACCF5 for ; Mon, 29 Sep 2014 14:21:31 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cc10so1024441wib.13 for ; Mon, 29 Sep 2014 14:21: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=Bwp9Wg2hD2+/Q9dhPs5gXTGNcnHiJVi5JkKug52ZhbY=; b=fEw6YhpTgow+lUJ18wTKSdfcr383s1OsZYJAOqEUkI3HJeN0/wYvZ5jaX5H5ZToPP6 pj9BtYDG9sA2OhFWeaVrC3uJSpgqAZQ2mV9xbRyC7om0Ec33y6PtkVvzfUM04ln/1oeX o3s6RDgSnTr/+EmB1tWmILDuTARvrIsGv+PGnf1qlNLPCNONAm6KHz44JlPteH4c9dp0 ex8F85TBPk5cZGu3qYzm78Cw5nJgP6qbxDz8/3U0E0MsO4oCCiiQiqN97bF0GtLgbzbZ BWvtQ7oqw2WrvcOIyHRZqwz+5hhV36GfiNDCD4bt6zrI4RQwDQ0HdqPajU5qPwAnCd09 Jbzw== MIME-Version: 1.0 X-Received: by 10.194.189.115 with SMTP id gh19mr6210043wjc.119.1412025690273; Mon, 29 Sep 2014 14:21:30 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 29 Sep 2014 14:21:30 -0700 (PDT) In-Reply-To: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> Date: Mon, 29 Sep 2014 17:21:30 -0400 Message-ID: From: Alia Atlas To: Thomas Narten Content-Type: multipart/alternative; boundary=047d7bb70a40aec16c05043ad902 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/OsyWM79urmdY0I8kIWjZxNqT4xU Cc: Jeffrey Haas , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:21:39 -0000 --047d7bb70a40aec16c05043ad902 Content-Type: text/plain; charset=UTF-8 Thomas, On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten wrote: > > It is NOT OK to tell anyone that they should not contribute a draft - > because > > it may muddy the water > > or for ANY other non-technical reason. Individual drafts or desire to > request > > WG adoption do not change > > this. I do not ever want to see or hear something like this on an IETF > > mailing list. > > Let me defend Acee here a bit and try to chart a course a bit more > down the middle. When a WG has an effort underway that is intended to > lead to a WG document (and that is what I read the current "design > team" effort to be), it is IMO often not helpful to have yet more IDs > submitted on the same topic. Rather than complementing the existing > work towards a concensus result, additional IDs can be a distraction > and require folk to spend time figuring out how the other ID relates > to the WG effort. I.e., it's much more constuctive to say "here is > what is defficient in the current model, and here is what I think we > should do instead". It is much less constructive to have a standalone > ID that (probably) overlaps with the other IDs and doesn't focus on > the *differences* from the other work that already has a head start. > First, I have been encouraging the routing WGs to work on and consider YANG models. I have been quite clear in discussing with Benoit that they should be homed in the Routing area and that I don't think it makes sense to create a separate working group to just work on YANG models. Second, the assumption that we have had with I2RS is that it will need different and possibly more limited models than would be used for configuration of a particular protocol. A reasonable approach could be doing the I2RS-specific models in I2RS and having them cross-reviewed in the relevant protocol working-groups. This is the path that, as I understand it, Sue was working on. It would allow review of the interactions between the different models for their I2RS aspects (assuming that the WG believes that there are some). Third, individuals have been working an individual draft (draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model. This was discussed in OSPF last IETF. I agree that the updated draft, when posted, is likely to be an excellent candidate for the OSPF WG. However, regardless of whom may be working on writing draft-yeung-netmod-ospf-01 or who may have been going behind the scenes pushing and encouraging (and I am also quite happy and eager and encouraging to see good YANG models for routing functionality), this is not an official design team effort. Deliberately writing a competing draft may not be constructive. That is not what happened here and it was the combination of trying to incorrectly privilege an (expired) individual draft that was written to solve a different problem and asking for someone who had done work to produce a draft towards a different problem that caused me to be extremely displeased. I realize that one of the topics of discussion since the netmod interim has been whether it makes sense to have one YANG model that can be used by NetConf and I2RS for writing and reading. However, I have not heard discussed much less agreed upon that approach in I2RS and it is inappropriate to presuppose the answer and punt work that it is quite reasonable to assume (and examine to determine) will move the WG forward. > It is the case that the IETF mantra is "submit a draft", but frankly, > I think that is a bit of a sound bite that we would do well to not > spit out as often as we seem to because it too often misses what > really should happen, namely, how best to contribute to reaching > consensus in a WG. We have a huge problem today where there are > overlapping/competing drafts that WGs have to sort through. And in > many of those cases, additional IDs have very little additional > content than what already exists. But since we go around telling folk > to "submit an ID", we shouldn't be surprise that we get them beyond > the point of diminishing returns. (And I am NOT saying that the draft > at issue here is one of those.) > Please let's not try to conflate one specific case with its own concerns with generalities. That is not constructive. > In this case (and I personally don't have any skin in the game), it > seems to that both parties are making honest efforts to do the right > thing, but unfortunately, the state of play was not fully known to all. Yes, this is communication and clear communication is needed. > > Very very few drafts start perfect and different models have > > different perspectives. The IETF has a consensus process, as you > > well know of course, to resolve differences between perspectives and > > drafts. > > I didn't hear anyone say that consensus has already been called. My > take away is that we have a WG making an honest effort to move forward > in a particular direction and it is doing exactly what it should be in > terms of getting behind a design team effort. And IMO, once you have a > WG design team working on an effort, having others submit drafts in > the same space is not always what we should be encouraging people to > do. > There IS NOT a WG Design Team in OSPF working on the YANG model. There are individuals, whom were encouraged to work together, but that does not make it a design team. IFF there were an announced WG Design Team and IFF there were consensus in I2RS that I2RS would use exactly the same YANG models, then this point might hold water. Since neither are the case, I do not believe that it does so. > Does that mean we should not allow additional IDs? Of course not. Does > it mean we won't look at them and give them consideration"? Of course > not. But we should also be honest that if a WG has an official > document or has a DT working on a document, having additional > "competing" documents show up is often not the most constructive way > to contribute. Unless news IDs really are clear about how they relate > to the other efforts and what those other efforts are lacking. Yes - and official WG design teams are different from a group of individuals. To be extremely clear yet again, this is a group of individuals. Regards, Alia Thomas > > --047d7bb70a40aec16c05043ad902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas,

On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten <= ;narten@us.ibm.com> wrote:
> It is NOT OK= to tell anyone that they should not contribute a draft - because
> it may muddy the water
> or for ANY other non-technical reason.=C2=A0 Individual drafts or desi= re to request
> WG adoption do not change
> this.=C2=A0 I do not ever want to see or hear something like this on a= n IETF
> mailing list.

Let me defend Acee here a bit and try to chart a course a bit more down the middle. When a WG has an effort underway that is intended to
lead to a WG document (and that is what I read the current "design
team" effort to be), it is IMO often not helpful to have yet more IDs<= br> submitted on the same topic. Rather than complementing the existing
work towards a concensus result, additional IDs can be a distraction
and require folk to spend time figuring out how the other ID relates
to the WG effort. I.e., it's much more constuctive to say "here is=
what is defficient in the current model, and here is what I think we
should do instead". It is much less constructive to have a standalone<= br> ID that (probably) overlaps with the other IDs and doesn't focus on
the *differences* from the other work that already has a head start.

First, I have been encouraging the routing WG= s to work on and consider YANG models.
I have been quite clear in= discussing with Benoit that they should be homed in the Routing
= area and that I don't think it makes sense to create a separate working= group to just work
on YANG models.

Seco= nd, the assumption that we have had with I2RS is that it will need differen= t and possibly
more limited models than would be used for configu= ration of a particular protocol.=C2=A0 A reasonable
approach coul= d be doing the I2RS-specific models in I2RS and having them cross-reviewed = in
the relevant protocol working-groups.=C2=A0 This is the path t= hat, as I understand it, Sue was working on.
It would allow revie= w of the interactions between the different models for their I2RS aspects (= assuming
that the WG believes that there are some).
Third, individuals have been working an individual draft (draft= -yeung-netmod-ospf-01) for an OSPF configuration YANG model.=C2=A0 This was= discussed in OSPF last IETF.=C2=A0 I agree that the updated draft, when po= sted, is likely to be an excellent candidate for the OSPF WG.
However, regardless of whom may be working on writing draft-yeu= ng-netmod-ospf-01 or who may have been going behind the scenes pushing and = encouraging (and I am also quite happy and eager and encouraging to see goo= d YANG models for routing functionality), this is not an official design te= am
effort.=C2=A0

Deliberately writing a = competing draft may not be constructive.=C2=A0 That is not what happened he= re and
it was the combination of trying to incorrectly privilege = an (expired) individual draft that was written to solve a different problem= and asking for someone =C2=A0who had done work to produce a draft towards = a different problem that caused me to be extremely displeased.
=C2=A0I realize that one of the topics of discussion since the= netmod interim has been whether it makes sense to have one YANG model that= can be used by NetConf and I2RS for writing and reading.=C2=A0 However, I = have not heard discussed much less agreed upon that approach in I2RS and it= is inappropriate to presuppose the answer and punt work that it is quite r= easonable to assume (and examine to determine) will move the WG forward.
=C2=A0
It is the case that the IETF mantra is "submit a draft", but fran= kly,
I think that is a bit of a sound bite that we would do well to not
spit out as often as we seem to because it too often misses what
really should happen, namely, how best to contribute to reaching
consensus in a WG. We have a huge problem today where there are
overlapping/competing drafts that WGs have to sort through. And in
many of those cases, additional IDs have very little additional
content than what already exists. But since we go around telling folk
to "submit an ID", we shouldn't be surprise that we get them = beyond
the point of diminishing returns. (And I am NOT saying that the draft
at issue here is one of those.)

Please = let's not try to conflate one specific case with its own concerns with<= /div>
generalities.=C2=A0 That is not constructive.=C2=A0
=C2= =A0
In this case (and I personally don't have any skin in the game), it
seems to that both parties are making honest efforts to do the right
thing, but unfortunately, the state of play was not fully known to all.

Yes, this is communication and clear communica= tion is needed.=C2=A0

=C2=A0
> Very very few drafts start perfect and different models have
> different perspectives.=C2=A0 The IETF has a consensus process, as you=
> well know of course, to resolve differences between perspectives and > drafts.

I didn't hear anyone say that consensus has already been called.= =C2=A0 My
take away is that we have a WG making an honest effort to move forward
in a particular direction and it is doing exactly what it should be in
terms of getting behind a design team effort. And IMO, once you have a
WG design team working on an effort, having others submit drafts in
the same space is not always what we should be encouraging people to
do.

There IS NOT a WG Design Team in OS= PF working on the YANG model.=C2=A0 There
are individuals, whom w= ere encouraged to work together, but that does not make it
a desi= gn team.=C2=A0 IFF there were an announced WG Design Team and IFF there wer= e
consensus in I2RS that I2RS would use exactly the same YANG mod= els, then this
point might hold water. =C2=A0 Since neither are t= he case, I do not believe that it does so.=C2=A0

= =C2=A0
Does that mean we should not allow additional IDs? Of course not. Does
it mean we won't look at them and give them consideration"? Of cou= rse
not. But we should also be honest that if a WG has an official
document or has a DT working on a document, having additional
"competing" documents show up is often not the most constructive = way
to contribute. Unless news IDs really are clear about how they relate
to the other efforts and what those other efforts are lacking.
=

Yes - and official WG design teams are different from a= group of individuals.=C2=A0 To be
extremely clear yet again, thi= s is a group of individuals.=C2=A0

Regards,
<= div>Alia=C2=A0

Thomas


--047d7bb70a40aec16c05043ad902-- From nobody Mon Sep 29 14:25: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 D594F1ACCE9 for ; Mon, 29 Sep 2014 14:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQttZ5ZOXA_w for ; Mon, 29 Sep 2014 14:25:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A323B1AC7E8 for ; Mon, 29 Sep 2014 14:25:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5E10CC141; Mon, 29 Sep 2014 17:25:19 -0400 (EDT) Date: Mon, 29 Sep 2014 17:25:19 -0400 From: Jeffrey Haas To: Joe Clarke Message-ID: <20140929212519.GD24542@pfrc> References: <20140925180055.GB1239@pfrc> <5429AB19.4050406@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5429AB19.4050406@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/bbiHa_yecdAgB3e1kbWRpGw0eto Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:25:21 -0000 On Mon, Sep 29, 2014 at 02:55:21PM -0400, Joe Clarke wrote: > On 9/25/14 2:00 PM, Jeffrey Haas wrote: > >Your chairs have been a bit over-busy recently with travel to unicast people > >doing various bits of chartered work. This means we've been behind on some > >of our goals in terms of getting regular design sessions running. I know > >that at least a couple calls have happened that I've missed that Sue Hares > >has done, so some progress is being made. > > > >We've requested a 1 hour time slot for IETF 91 in Honolulu to give us a > >chance to talk. This is a call for agenda slots. > > > >This is also a call for status reports. > > > >We've had some productive discussion about requests to netmod/netconf, > >albeit ones that haven't converged yet. > > > >What have you been up to? > > I think the list knows about the traceability "shoe" that's been > waiting to drop. Question is, can it be settled on the list, should > we ask in Honolulu? Does it need an agenda item or can the chairs > raise the point? Thanks. This chair admits he's been a slacker even though oversubscribed. One of the reasons why this has been left to linger slightly is the detail that we've left the architecture document unpublished as an RFC to permit some time to reconcile the ephemeral datastore question. The answer to that question may have impact on the architecture. Aside from that, the document is past WGLC and was ready to be submitted for publication. Since the architecture draft is still open, do you believe that the traceability draft should be incorporated into the architecture document or left separately? This question obviously is for the WG to answer. Once we have that answer, we'll either look for the edits to the architecture or simply do an adoption call. We saw good support for the idea that traceability is something we should have. -- Jeff From nobody Mon Sep 29 14:27: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 674431ACCF2 for ; Mon, 29 Sep 2014 14:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teNOsg22ibPc for ; Mon, 29 Sep 2014 14:27:21 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE931ACCF4 for ; Mon, 29 Sep 2014 14:27:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 07237C141; Mon, 29 Sep 2014 17:27:21 -0400 (EDT) Date: Mon, 29 Sep 2014 17:27:21 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140929212720.GE24542@pfrc> References: <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> 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/rCI3t2jAG-sH4rtsjdkgqhjpzf8 Cc: Thomas Narten , Jeffrey Haas , "Acee Lindem \(acee\)" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:27:22 -0000 Alia, On Mon, Sep 29, 2014 at 05:21:30PM -0400, Alia Atlas wrote: > Second, the assumption that we have had with I2RS is that it will need > different and possibly more limited models than would be used for > configuration of a particular protocol. A reasonable approach could be > doing the I2RS-specific models in I2RS and having them cross-reviewed in > the relevant protocol working-groups. This is the path that, as I > understand it, Sue was working on. As noted in a prior message, this path is complicated by not having settled on what I2RS config looks like in an ephemeral datastore. -- Jeff From nobody Mon Sep 29 14:33: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 541B91ACCEA for ; Mon, 29 Sep 2014 14:33:28 -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 QmhTqTqC9BGW for ; Mon, 29 Sep 2014 14:33:25 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37B81A1BE8 for ; Mon, 29 Sep 2014 14:33:24 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so1264143wgg.8 for ; Mon, 29 Sep 2014 14:33:23 -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=zC+fBt6vsyKhv76qrXMi8wDiWGiYb8ImWmIbnZPwDRQ=; b=yZlh18xMAQfxDvvzP5a8z2teteaWqOb3OKD/Au9fJY7PS/JnlmNFLCU91r5G4iEbSZ 49VWLdNIKDhtONIih9h3VDjGKGGDv12xTV8cOGRYF4FgLaslGbT7a2sgxUqP2ik619cC SLalN90svA7QSSQtH050I/3bhpUUxkSqp/B2z7T0XB0jm5vGa+ioj0s+GbO33V9XGy9l W8ZlDt8nUg4pOBEmN2LWxLKO63/lCDdAVwr9XVXM3mEtnvPOV5pIGRV5zJGOVivspzol dpkGBa2HzFD07OVl5qLbdjyuOvAQg/2mJ9jLA1MeMzsaF1n5bAtI5I8x5RWCq/DVkTtO 6Zmg== MIME-Version: 1.0 X-Received: by 10.194.189.115 with SMTP id gh19mr6270111wjc.119.1412026403466; Mon, 29 Sep 2014 14:33:23 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 29 Sep 2014 14:33:23 -0700 (PDT) In-Reply-To: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> Date: Mon, 29 Sep 2014 17:33:23 -0400 Message-ID: From: Alia Atlas To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=047d7bb70a4031834c05043b0413 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7u0Q-1LpaR08zPjsAOyXFO1alNQ Cc: Thomas Narten , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:33:28 -0000 --047d7bb70a4031834c05043b0413 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Acee, On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (acee) wrote: > Thanks Much Thomas! Given that I was the victim of considerable back-door > escalations and machinations, I was giving myself a =C2=B3cooling off=C2= =B2 period > prior responding. However, you expressed my sentiments with much more > patience than I could have myself. Moving forward, we are going to have t= o > agree on a home for these protocol models drafts. Of course, my preferenc= e > would be to keep them in the protocol WGs with I2RS and I2RS review. Give= n > the IESG statement on YANG models replaced MIBs > (), I had > viewed this as self-evident. First, I really appreciate that you gave yourself a cooling-off period before responding. I did exactly the same thing before responding. The last thing that is needed or desired is escalations. I think this is an excellent practice when email conversations get heated. Second, what I have been encouraging is absolutely that the YANG configuration models should go to each protocol group. What is confusing the situation here is that the I2RS related models are not/have not been assumed to be the same thing. Instead, the assumption has been that they would be more limited and perhaps have I2RS specifics (such as for events) - and therefore would happen in I2RS and also be discussed in the specific protocol WG. Third, there was discussion on the mailing list and at the interim about "option 4" which is pushing I2RS to use exactly the same YANG models. I have seen discussion trying to understand what this would look like but certainly nothing around consensus that that should be the case. My strong reaction and email was to several things that I saw happening together: a) Efforts to privilege an individual draft (expired) and push away other approaches. I do understand that it was very well received last IETF, that a new version will be out soon, and that you can't ask for WG adoption in OSPF until that occurs. b) A claim that the draft targeted at a config model for OSPF was all that was needed for I2RS (prejudging the situation) I know that we want to get really great YANG models out of this and encourage more people to work in this space and also want to see I2RS make actual progress= . I also agree that there are better ways for people to collaborate than to go away and write a competing draft - but I do not think that was the intent or what happened here. Regards, Alia > Acee > > On 9/29/14, 2:44 PM, "Thomas Narten" wrote: > > >> It is NOT OK to tell anyone that they should not contribute a draft - > >>because > >> it may muddy the water > >> or for ANY other non-technical reason. Individual drafts or desire to > >>request > >> WG adoption do not change > >> this. I do not ever want to see or hear something like this on an IET= F > >> mailing list. > > > >Let me defend Acee here a bit and try to chart a course a bit more > >down the middle. When a WG has an effort underway that is intended to > >lead to a WG document (and that is what I read the current "design > >team" effort to be), it is IMO often not helpful to have yet more IDs > >submitted on the same topic. Rather than complementing the existing > >work towards a concensus result, additional IDs can be a distraction > >and require folk to spend time figuring out how the other ID relates > >to the WG effort. I.e., it's much more constuctive to say "here is > >what is defficient in the current model, and here is what I think we > >should do instead". It is much less constructive to have a standalone > >ID that (probably) overlaps with the other IDs and doesn't focus on > >the *differences* from the other work that already has a head start. > > > >It is the case that the IETF mantra is "submit a draft", but frankly, > >I think that is a bit of a sound bite that we would do well to not > >spit out as often as we seem to because it too often misses what > >really should happen, namely, how best to contribute to reaching > >consensus in a WG. We have a huge problem today where there are > >overlapping/competing drafts that WGs have to sort through. And in > >many of those cases, additional IDs have very little additional > >content than what already exists. But since we go around telling folk > >to "submit an ID", we shouldn't be surprise that we get them beyond > >the point of diminishing returns. (And I am NOT saying that the draft > >at issue here is one of those.) > > > >In this case (and I personally don't have any skin in the game), it > >seems to that both parties are making honest efforts to do the right > >thing, but unfortunately, the state of play was not fully known to all. > > > >> Very very few drafts start perfect and different models have > >> different perspectives. The IETF has a consensus process, as you > >> well know of course, to resolve differences between perspectives and > >> drafts. > > > >I didn't hear anyone say that consensus has already been called. My > >take away is that we have a WG making an honest effort to move forward > >in a particular direction and it is doing exactly what it should be in > >terms of getting behind a design team effort. And IMO, once you have a > >WG design team working on an effort, having others submit drafts in > >the same space is not always what we should be encouraging people to > >do. > > > >Does that mean we should not allow additional IDs? Of course not. Does > >it mean we won't look at them and give them consideration"? Of course > >not. But we should also be honest that if a WG has an official > >document or has a DT working on a document, having additional > >"competing" documents show up is often not the most constructive way > >to contribute. Unless news IDs really are clear about how they relate > >to the other efforts and what those other efforts are lacking. > > > >Thomas > > > > --047d7bb70a4031834c05043b0413 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Acee,

On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (acee) = <acee@cisco.com&= gt; wrote:
Thanks Much Thomas! Giv= en that I was the victim of considerable back-door
escalations and machinations, I was giving myself a =C2=B3cooling off=C2=B2= period
prior responding. However, you expressed my sentiments with much more
patience than I could have myself. Moving forward, we are going to have to<= br> agree on a home for these protocol models drafts. Of course, my preference<= br> would be to keep them in the protocol WGs with I2RS and I2RS review. Given<= br> the IESG statement on YANG models replaced MIBs
(<http://www.ietf.org/iesg/statement/writable-mib-module.= html>), I had
viewed this as self-evident.

First, I reall= y appreciate that you gave yourself a cooling-off period before responding.=
I did exactly the same thing before responding.=C2=A0 The last t= hing that is needed or desired
is escalations.=C2=A0 I think this= is an excellent practice when email conversations get heated.
Second, what I have been encouraging is absolutely that the YA= NG configuration models
should go to each protocol group.=C2=A0 W= hat is confusing the situation here is that the I2RS related
mode= ls are not/have not been assumed to be the same thing.=C2=A0 Instead, the a= ssumption has been
that they would be more limited and perhaps ha= ve I2RS specifics (such as for events) - and
therefore would happ= en in I2RS and also be discussed in the specific protocol WG.
Third, there was discussion on the mailing list and at the inte= rim about "option 4" which is
pushing I2RS to use exact= ly the same YANG models.=C2=A0 I have seen discussion trying to understand<= /div>
what this would look like but certainly nothing around consensus = that that should be the case.

My strong reaction a= nd email was to several things that I saw happening together:
=C2= =A0 =C2=A0 a) Efforts to privilege an individual draft (expired) and push a= way other approaches.=C2=A0 I do understand that it was very well received = last IETF, that a new version will be out soon, and that you can't ask = for WG adoption in OSPF until that occurs.
=C2=A0 =C2=A0 b) A cla= im that the draft targeted at a config model for OSPF was all that was need= ed for I2RS (prejudging the situation)

I know that= we want to get really great YANG models out of this and encourage more
people to work in this space and also want to see I2RS make actual p= rogress.

I also agree that there are better ways f= or people to collaborate than to go away and write a competing draft - but = I do not think that was the intent or what happened here.

Regards,
Alia

=C2=A0
Acee

On 9/29/14, 2:44 PM, "Thomas Narten" <narten@us.ibm.com> wrote:

>> It is NOT OK to tell anyone that they should not contribute a draf= t -
>>because
>> it may muddy the water
>> or for ANY other non-technical reason.=C2=A0 Individual drafts or = desire to
>>request
>> WG adoption do not change
>> this.=C2=A0 I do not ever want to see or hear something like this = on an IETF
>> mailing list.
>
>Let me defend Acee here a bit and try to chart a course a bit more
>down the middle. When a WG has an effort underway that is intended to >lead to a WG document (and that is what I read the current "design=
>team" effort to be), it is IMO often not helpful to have yet more = IDs
>submitted on the same topic. Rather than complementing the existing
>work towards a concensus result, additional IDs can be a distraction >and require folk to spend time figuring out how the other ID relates >to the WG effort. I.e., it's much more constuctive to say "her= e is
>what is defficient in the current model, and here is what I think we >should do instead". It is much less constructive to have a standal= one
>ID that (probably) overlaps with the other IDs and doesn't focus on=
>the *differences* from the other work that already has a head start. >
>It is the case that the IETF mantra is "submit a draft", but = frankly,
>I think that is a bit of a sound bite that we would do well to not
>spit out as often as we seem to because it too often misses what
>really should happen, namely, how best to contribute to reaching
>consensus in a WG. We have a huge problem today where there are
>overlapping/competing drafts that WGs have to sort through. And in
>many of those cases, additional IDs have very little additional
>content than what already exists. But since we go around telling folk >to "submit an ID", we shouldn't be surprise that we get t= hem beyond
>the point of diminishing returns. (And I am NOT saying that the draft >at issue here is one of those.)
>
>In this case (and I personally don't have any skin in the game), it=
>seems to that both parties are making honest efforts to do the right >thing, but unfortunately, the state of play was not fully known to all.=
>
>> Very very few drafts start perfect and different models have
>> different perspectives.=C2=A0 The IETF has a consensus process, as= you
>> well know of course, to resolve differences between perspectives a= nd
>> drafts.
>
>I didn't hear anyone say that consensus has already been called.=C2= =A0 My
>take away is that we have a WG making an honest effort to move forward<= br> >in a particular direction and it is doing exactly what it should be in<= br> >terms of getting behind a design team effort. And IMO, once you have a<= br> >WG design team working on an effort, having others submit drafts in
>the same space is not always what we should be encouraging people to >do.
>
>Does that mean we should not allow additional IDs? Of course not. Does<= br> >it mean we won't look at them and give them consideration"? Of= course
>not. But we should also be honest that if a WG has an official
>document or has a DT working on a document, having additional
>"competing" documents show up is often not the most construct= ive way
>to contribute. Unless news IDs really are clear about how they relate >to the other efforts and what those other efforts are lacking.
>
>Thomas
>


--047d7bb70a4031834c05043b0413-- From nobody Mon Sep 29 14:36: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 476BB1ACCE6 for ; Mon, 29 Sep 2014 14:36:29 -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 skMaBSxIg_yh for ; Mon, 29 Sep 2014 14:36:27 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790BD1A1BE8 for ; Mon, 29 Sep 2014 14:36:27 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id a1so2578061wgh.26 for ; Mon, 29 Sep 2014 14:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uApZ/3Im6Mc3rbt5xbMJycUqk2UlIuYsrFlXhOgYYdk=; b=pwodZ8W6WaXMXOweXuQiIc7gGAAjUPjLvg2GfaauOr0RW70FG+LJJdDKicUbN7OQvB uyIel93MU12zY3EAxEHZ69sHXwbPk7EZFwdKALFUj4bylFF6oo6znhnXVJdzSjk+NCAt l1BY8rAJEbvBBIjJppUuIEZXsr73EN3M8o44J30+n2VeW7Lg64LDDX460p/s3uzPM3QJ e+Xd52mL33cIUieQgVNNBLZwG6ldqGfcpf7NE89IDMP730/XzRMGEJNZItAZ+Ig86YfJ 2VYrU7rRgiRLii0Z9eup+REY+iwf/+aq+g+kxqcCVjN7TH8E4gJRPe+2RZgc+RrK2SfW m89w== MIME-Version: 1.0 X-Received: by 10.194.184.111 with SMTP id et15mr28343531wjc.14.1412026586108; Mon, 29 Sep 2014 14:36:26 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 29 Sep 2014 14:36:25 -0700 (PDT) In-Reply-To: <20140929212720.GE24542@pfrc> References: <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929212720.GE24542@pfrc> Date: Mon, 29 Sep 2014 17:36:25 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7ba97e9a14192405043b0fdb Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2tPTriYh8vtMRCXBJ5maQ5oYPO4 Cc: Thomas Narten , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:36:29 -0000 --047d7ba97e9a14192405043b0fdb Content-Type: text/plain; charset=UTF-8 Jeff, On Mon, Sep 29, 2014 at 5:27 PM, Jeffrey Haas wrote: > Alia, > > On Mon, Sep 29, 2014 at 05:21:30PM -0400, Alia Atlas wrote: > > Second, the assumption that we have had with I2RS is that it will need > > different and possibly more limited models than would be used for > > configuration of a particular protocol. A reasonable approach could be > > doing the I2RS-specific models in I2RS and having them cross-reviewed in > > the relevant protocol working-groups. This is the path that, as I > > understand it, Sue was working on. > > As noted in a prior message, this path is complicated by not having settled > on what I2RS config looks like in an ephemeral datastore. > Absolutely - and since I2RS is still doing info models until there is a clear direction, split of the work, and recharter. Alia > -- Jeff > --047d7ba97e9a14192405043b0fdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

On Mon, Sep 29, 2014 at 5:27 PM, Jeffrey Haas &l= t;jhaas@pfrc.org>= ; wrote:
Alia,

On Mon, Sep 29, 2014 at 05:21:30PM -0400, Alia Atlas wrote:
> Second, the assumption that we have had with I2RS is that it will need=
> different and possibly more limited models than would be used for
> configuration of a particular protocol.=C2=A0 A reasonable approach co= uld be
> doing the I2RS-specific models in I2RS and having them cross-reviewed = in
> the relevant protocol working-groups.=C2=A0 This is the path that, as = I
> understand it, Sue was working on.

As noted in a prior message, this path is complicated by not having = settled
on what I2RS config looks like in an ephemeral datastore.
<= div>
Absolutely - and since I2RS is still doing info models u= ntil there is a clear
direction, split of the work, and recharter= .

Alia=C2=A0

=C2=A0
=
-- Jeff

--047d7ba97e9a14192405043b0fdb-- From nobody Mon Sep 29 14:40: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 E73071ACCF2 for ; Mon, 29 Sep 2014 14:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf-EltpV6yWq for ; Mon, 29 Sep 2014 14:40:31 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F3F541AC7E8 for ; Mon, 29 Sep 2014 14:40:30 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B24B5C141; Mon, 29 Sep 2014 17:40:30 -0400 (EDT) Date: Mon, 29 Sep 2014 17:40:30 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140929214030.GB25791@pfrc> References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929212720.GE24542@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/dew7zE-RRyXCo9asr_SZCWaPNJI Cc: Jeffrey Haas , Thomas Narten , "Acee Lindem \(acee\)" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:40:32 -0000 On Mon, Sep 29, 2014 at 05:36:25PM -0400, Alia Atlas wrote: > On Mon, Sep 29, 2014 at 5:27 PM, Jeffrey Haas wrote: > > As noted in a prior message, this path is complicated by not having settled > > on what I2RS config looks like in an ephemeral datastore. > > Absolutely - and since I2RS is still doing info models until there is a > clear direction, split of the work, and recharter. Per prior discussions and our last session, the WG was suggested to go forth and start writing data models - knowing that they'll be incomplete until this is settled. Info models were okay to generate from the data models if a separate info model provided no additional useful context. Yes, your chairs are behind on sending the recharter request from this discussion. -- Jeff From nobody Mon Sep 29 14:41: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 4B5BA1ACCF5 for ; Mon, 29 Sep 2014 14:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 dQTf3yd56oD1 for ; Mon, 29 Sep 2014 14:41:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852C71ACCE6 for ; Mon, 29 Sep 2014 14:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23730; q=dns/txt; s=iport; t=1412026872; x=1413236472; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qCs824TmZnZjaKpBaJy7T5x3wxtGNKL/cvcWrZ7X+Hw=; b=NeQKjHJQxLzDOglslOaypRZ2KEdu9cw4lKIGqmM1bl2amYYhSiEVkzWF IEfj4vvO/afR73nK6SEZRUl3K1zXifD6hTVhF6wOpF4R1Vb/gqOrh57KY 0eA+78C+1u5K6xvOHJFV+uMnn6p1ZW5o+PCQ0Rv4HDwCmZDwGEwqguQnd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAAfRKVStJA2I/2dsb2JhbABggkhGU1cEgn3HHYdOAhl9FgF7hAMBAQEDAR1RCxACAQgOAwMBAigFAgIfERQJCAIEDgUJEYgQAwkIDYxInEQGjloNhx4BF4oqgiGBI4FOCgcBPxEHgnKBWQWRZYkzghCPFYZIg2NsAYEFCRcigQIBAQE X-IronPort-AV: E=Sophos;i="5.04,622,1406592000"; d="scan'208,217";a="359292044" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2014 21:41:10 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8TLfA3h003281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 21:41:10 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 16:41:09 -0500 From: "Acee Lindem (acee)" To: Alia Atlas Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqAgABRF4D//8ETAAAJ7j8AABpz1oAAGPrVAAAlYmsA///fpoCAAE92gP//vxwA Date: Mon, 29 Sep 2014 21:41:09 +0000 Message-ID: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D04F49253DD5aceeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-Cw96h4pVksnvowwcMoTuZLbRAQ Cc: Thomas Narten , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:41:14 -0000 --_000_D04F49253DD5aceeciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 DQoNCkZyb206IEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdt YWlsLmNvbT4+DQpEYXRlOiBNb25kYXksIFNlcHRlbWJlciAyOSwgMjAxNCBhdCA1OjMzIFBNDQpU bzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQpD YzogVGhvbWFzIE5hcnRlbiA8bmFydGVuQHVzLmlibS5jb208bWFpbHRvOm5hcnRlbkB1cy5pYm0u Y29tPj4sIEplZmYgSGFhcyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4s ICJpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPiIgPGkycnNAaWV0Zi5vcmc8bWFp bHRvOmkycnNAaWV0Zi5vcmc+PiwgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86 c2hhcmVzQG5kemguY29tPj4NClN1YmplY3Q6IFJlOiBbaTJyc10gSUVURiA5MSBtZWV0aW5nIHJl cXVlc3RlZCAtIGNhbGwgZm9yIGFnZW5kYTsgc3RhdHVzIHJlcG9ydHM/DQoNCkFjZWUsDQoNCk9u IE1vbiwgU2VwIDI5LCAyMDE0IGF0IDQ6NDkgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBj aXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4gd3JvdGU6DQpUaGFua3MgTXVjaCBUaG9t YXMhIEdpdmVuIHRoYXQgSSB3YXMgdGhlIHZpY3RpbSBvZiBjb25zaWRlcmFibGUgYmFjay1kb29y DQplc2NhbGF0aW9ucyBhbmQgbWFjaGluYXRpb25zLCBJIHdhcyBnaXZpbmcgbXlzZWxmIGEgqfhj b29saW5nIG9mZqn3IHBlcmlvZA0KcHJpb3IgcmVzcG9uZGluZy4gSG93ZXZlciwgeW91IGV4cHJl c3NlZCBteSBzZW50aW1lbnRzIHdpdGggbXVjaCBtb3JlDQpwYXRpZW5jZSB0aGFuIEkgY291bGQg aGF2ZSBteXNlbGYuIE1vdmluZyBmb3J3YXJkLCB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSB0bw0KYWdy ZWUgb24gYSBob21lIGZvciB0aGVzZSBwcm90b2NvbCBtb2RlbHMgZHJhZnRzLiBPZiBjb3Vyc2Us IG15IHByZWZlcmVuY2UNCndvdWxkIGJlIHRvIGtlZXAgdGhlbSBpbiB0aGUgcHJvdG9jb2wgV0dz IHdpdGggSTJSUyBhbmQgSTJSUyByZXZpZXcuIEdpdmVuDQp0aGUgSUVTRyBzdGF0ZW1lbnQgb24g WUFORyBtb2RlbHMgcmVwbGFjZWQgTUlCcw0KKDxodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L3dyaXRhYmxlLW1pYi1tb2R1bGUuaHRtbD4pLCBJIGhhZA0Kdmlld2VkIHRoaXMgYXMg c2VsZi1ldmlkZW50Lg0KDQpGaXJzdCwgSSByZWFsbHkgYXBwcmVjaWF0ZSB0aGF0IHlvdSBnYXZl IHlvdXJzZWxmIGEgY29vbGluZy1vZmYgcGVyaW9kIGJlZm9yZSByZXNwb25kaW5nLg0KSSBkaWQg ZXhhY3RseSB0aGUgc2FtZSB0aGluZyBiZWZvcmUgcmVzcG9uZGluZy4gIFRoZSBsYXN0IHRoaW5n IHRoYXQgaXMgbmVlZGVkIG9yIGRlc2lyZWQNCmlzIGVzY2FsYXRpb25zLiAgSSB0aGluayB0aGlz IGlzIGFuIGV4Y2VsbGVudCBwcmFjdGljZSB3aGVuIGVtYWlsIGNvbnZlcnNhdGlvbnMgZ2V0IGhl YXRlZC4NCg0KU2Vjb25kLCB3aGF0IEkgaGF2ZSBiZWVuIGVuY291cmFnaW5nIGlzIGFic29sdXRl bHkgdGhhdCB0aGUgWUFORyBjb25maWd1cmF0aW9uIG1vZGVscw0Kc2hvdWxkIGdvIHRvIGVhY2gg cHJvdG9jb2wgZ3JvdXAuICBXaGF0IGlzIGNvbmZ1c2luZyB0aGUgc2l0dWF0aW9uIGhlcmUgaXMg dGhhdCB0aGUgSTJSUyByZWxhdGVkDQptb2RlbHMgYXJlIG5vdC9oYXZlIG5vdCBiZWVuIGFzc3Vt ZWQgdG8gYmUgdGhlIHNhbWUgdGhpbmcuICBJbnN0ZWFkLCB0aGUgYXNzdW1wdGlvbiBoYXMgYmVl bg0KdGhhdCB0aGV5IHdvdWxkIGJlIG1vcmUgbGltaXRlZCBhbmQgcGVyaGFwcyBoYXZlIEkyUlMg c3BlY2lmaWNzIChzdWNoIGFzIGZvciBldmVudHMpIC0gYW5kDQp0aGVyZWZvcmUgd291bGQgaGFw cGVuIGluIEkyUlMgYW5kIGFsc28gYmUgZGlzY3Vzc2VkIGluIHRoZSBzcGVjaWZpYyBwcm90b2Nv bCBXRy4NCg0KVGhpcmQsIHRoZXJlIHdhcyBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3Qg YW5kIGF0IHRoZSBpbnRlcmltIGFib3V0ICJvcHRpb24gNCIgd2hpY2ggaXMNCnB1c2hpbmcgSTJS UyB0byB1c2UgZXhhY3RseSB0aGUgc2FtZSBZQU5HIG1vZGVscy4gIEkgaGF2ZSBzZWVuIGRpc2N1 c3Npb24gdHJ5aW5nIHRvIHVuZGVyc3RhbmQNCndoYXQgdGhpcyB3b3VsZCBsb29rIGxpa2UgYnV0 IGNlcnRhaW5seSBub3RoaW5nIGFyb3VuZCBjb25zZW5zdXMgdGhhdCB0aGF0IHNob3VsZCBiZSB0 aGUgY2FzZS4NCg0KSSB3b3VsZCBob3BlIHRoYXQgd2UgaGF2ZSBhIHNpbmdsZSBtb2RlbCBmb3Ig TkVUQ09ORiBhbmQgSTJSUyBvciBhdCBsZWFzdCBhIGNvcmUgT1NQRiBtb2RlbCB0aGF0IGNvbnRh aW5zIHRoZSBsYXJnZSBpbnRlcnNlY3Rpb24uDQoNCg0KTXkgc3Ryb25nIHJlYWN0aW9uIGFuZCBl bWFpbCB3YXMgdG8gc2V2ZXJhbCB0aGluZ3MgdGhhdCBJIHNhdyBoYXBwZW5pbmcgdG9nZXRoZXI6 DQogICAgYSkgRWZmb3J0cyB0byBwcml2aWxlZ2UgYW4gaW5kaXZpZHVhbCBkcmFmdCAoZXhwaXJl ZCkgYW5kIHB1c2ggYXdheSBvdGhlciBhcHByb2FjaGVzLiAgSSBkbyB1bmRlcnN0YW5kIHRoYXQg aXQgd2FzIHZlcnkgd2VsbCByZWNlaXZlZCBsYXN0IElFVEYsIHRoYXQgYSBuZXcgdmVyc2lvbiB3 aWxsIGJlIG91dCBzb29uLCBhbmQgdGhhdCB5b3UgY2FuJ3QgYXNrIGZvciBXRyBhZG9wdGlvbiBp biBPU1BGIHVudGlsIHRoYXQgb2NjdXJzLg0KICAgIGIpIEEgY2xhaW0gdGhhdCB0aGUgZHJhZnQg dGFyZ2V0ZWQgYXQgYSBjb25maWcgbW9kZWwgZm9yIE9TUEYgd2FzIGFsbCB0aGF0IHdhcyBuZWVk ZWQgZm9yIEkyUlMgKHByZWp1ZGdpbmcgdGhlIHNpdHVhdGlvbikNCg0KVGhlIGxhdGVzdCBPU1BG IG1vZGVsIGluY2x1ZGVzIG9wZXJhdGlvbmFsIHN0YXRlIGFzIHdlbGwgYXMgY29uZmlndXJhdGlv biBhbmQgdGhpcyBpcyBvbmUgcmVhc29uIHdoeSBpdCBoYXMgdGFrZW4gYSBsb25nIHRpbWUgdG8g cHVibGlzaC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCg0KSSBrbm93IHRoYXQgd2Ugd2FudCB0byBn ZXQgcmVhbGx5IGdyZWF0IFlBTkcgbW9kZWxzIG91dCBvZiB0aGlzIGFuZCBlbmNvdXJhZ2UgbW9y ZQ0KcGVvcGxlIHRvIHdvcmsgaW4gdGhpcyBzcGFjZSBhbmQgYWxzbyB3YW50IHRvIHNlZSBJMlJT IG1ha2UgYWN0dWFsIHByb2dyZXNzLg0KDQpJIGFsc28gYWdyZWUgdGhhdCB0aGVyZSBhcmUgYmV0 dGVyIHdheXMgZm9yIHBlb3BsZSB0byBjb2xsYWJvcmF0ZSB0aGFuIHRvIGdvIGF3YXkgYW5kIHdy aXRlIGEgY29tcGV0aW5nIGRyYWZ0IC0gYnV0IEkgZG8gbm90IHRoaW5rIHRoYXQgd2FzIHRoZSBp bnRlbnQgb3Igd2hhdCBoYXBwZW5lZCBoZXJlLg0KDQpSZWdhcmRzLA0KQWxpYQ0KDQoNCkFjZWUN Cg0KT24gOS8yOS8xNCwgMjo0NCBQTSwgIlRob21hcyBOYXJ0ZW4iIDxuYXJ0ZW5AdXMuaWJtLmNv bTxtYWlsdG86bmFydGVuQHVzLmlibS5jb20+PiB3cm90ZToNCg0KPj4gSXQgaXMgTk9UIE9LIHRv IHRlbGwgYW55b25lIHRoYXQgdGhleSBzaG91bGQgbm90IGNvbnRyaWJ1dGUgYSBkcmFmdCAtDQo+ PmJlY2F1c2UNCj4+IGl0IG1heSBtdWRkeSB0aGUgd2F0ZXINCj4+IG9yIGZvciBBTlkgb3RoZXIg bm9uLXRlY2huaWNhbCByZWFzb24uICBJbmRpdmlkdWFsIGRyYWZ0cyBvciBkZXNpcmUgdG8NCj4+ cmVxdWVzdA0KPj4gV0cgYWRvcHRpb24gZG8gbm90IGNoYW5nZQ0KPj4gdGhpcy4gIEkgZG8gbm90 IGV2ZXIgd2FudCB0byBzZWUgb3IgaGVhciBzb21ldGhpbmcgbGlrZSB0aGlzIG9uIGFuIElFVEYN Cj4+IG1haWxpbmcgbGlzdC4NCj4NCj5MZXQgbWUgZGVmZW5kIEFjZWUgaGVyZSBhIGJpdCBhbmQg dHJ5IHRvIGNoYXJ0IGEgY291cnNlIGEgYml0IG1vcmUNCj5kb3duIHRoZSBtaWRkbGUuIFdoZW4g YSBXRyBoYXMgYW4gZWZmb3J0IHVuZGVyd2F5IHRoYXQgaXMgaW50ZW5kZWQgdG8NCj5sZWFkIHRv IGEgV0cgZG9jdW1lbnQgKGFuZCB0aGF0IGlzIHdoYXQgSSByZWFkIHRoZSBjdXJyZW50ICJkZXNp Z24NCj50ZWFtIiBlZmZvcnQgdG8gYmUpLCBpdCBpcyBJTU8gb2Z0ZW4gbm90IGhlbHBmdWwgdG8g aGF2ZSB5ZXQgbW9yZSBJRHMNCj5zdWJtaXR0ZWQgb24gdGhlIHNhbWUgdG9waWMuIFJhdGhlciB0 aGFuIGNvbXBsZW1lbnRpbmcgdGhlIGV4aXN0aW5nDQo+d29yayB0b3dhcmRzIGEgY29uY2Vuc3Vz IHJlc3VsdCwgYWRkaXRpb25hbCBJRHMgY2FuIGJlIGEgZGlzdHJhY3Rpb24NCj5hbmQgcmVxdWly ZSBmb2xrIHRvIHNwZW5kIHRpbWUgZmlndXJpbmcgb3V0IGhvdyB0aGUgb3RoZXIgSUQgcmVsYXRl cw0KPnRvIHRoZSBXRyBlZmZvcnQuIEkuZS4sIGl0J3MgbXVjaCBtb3JlIGNvbnN0dWN0aXZlIHRv IHNheSAiaGVyZSBpcw0KPndoYXQgaXMgZGVmZmljaWVudCBpbiB0aGUgY3VycmVudCBtb2RlbCwg YW5kIGhlcmUgaXMgd2hhdCBJIHRoaW5rIHdlDQo+c2hvdWxkIGRvIGluc3RlYWQiLiBJdCBpcyBt dWNoIGxlc3MgY29uc3RydWN0aXZlIHRvIGhhdmUgYSBzdGFuZGFsb25lDQo+SUQgdGhhdCAocHJv YmFibHkpIG92ZXJsYXBzIHdpdGggdGhlIG90aGVyIElEcyBhbmQgZG9lc24ndCBmb2N1cyBvbg0K PnRoZSAqZGlmZmVyZW5jZXMqIGZyb20gdGhlIG90aGVyIHdvcmsgdGhhdCBhbHJlYWR5IGhhcyBh IGhlYWQgc3RhcnQuDQo+DQo+SXQgaXMgdGhlIGNhc2UgdGhhdCB0aGUgSUVURiBtYW50cmEgaXMg InN1Ym1pdCBhIGRyYWZ0IiwgYnV0IGZyYW5rbHksDQo+SSB0aGluayB0aGF0IGlzIGEgYml0IG9m IGEgc291bmQgYml0ZSB0aGF0IHdlIHdvdWxkIGRvIHdlbGwgdG8gbm90DQo+c3BpdCBvdXQgYXMg b2Z0ZW4gYXMgd2Ugc2VlbSB0byBiZWNhdXNlIGl0IHRvbyBvZnRlbiBtaXNzZXMgd2hhdA0KPnJl YWxseSBzaG91bGQgaGFwcGVuLCBuYW1lbHksIGhvdyBiZXN0IHRvIGNvbnRyaWJ1dGUgdG8gcmVh Y2hpbmcNCj5jb25zZW5zdXMgaW4gYSBXRy4gV2UgaGF2ZSBhIGh1Z2UgcHJvYmxlbSB0b2RheSB3 aGVyZSB0aGVyZSBhcmUNCj5vdmVybGFwcGluZy9jb21wZXRpbmcgZHJhZnRzIHRoYXQgV0dzIGhh dmUgdG8gc29ydCB0aHJvdWdoLiBBbmQgaW4NCj5tYW55IG9mIHRob3NlIGNhc2VzLCBhZGRpdGlv bmFsIElEcyBoYXZlIHZlcnkgbGl0dGxlIGFkZGl0aW9uYWwNCj5jb250ZW50IHRoYW4gd2hhdCBh bHJlYWR5IGV4aXN0cy4gQnV0IHNpbmNlIHdlIGdvIGFyb3VuZCB0ZWxsaW5nIGZvbGsNCj50byAi c3VibWl0IGFuIElEIiwgd2Ugc2hvdWxkbid0IGJlIHN1cnByaXNlIHRoYXQgd2UgZ2V0IHRoZW0g YmV5b25kDQo+dGhlIHBvaW50IG9mIGRpbWluaXNoaW5nIHJldHVybnMuIChBbmQgSSBhbSBOT1Qg c2F5aW5nIHRoYXQgdGhlIGRyYWZ0DQo+YXQgaXNzdWUgaGVyZSBpcyBvbmUgb2YgdGhvc2UuKQ0K Pg0KPkluIHRoaXMgY2FzZSAoYW5kIEkgcGVyc29uYWxseSBkb24ndCBoYXZlIGFueSBza2luIGlu IHRoZSBnYW1lKSwgaXQNCj5zZWVtcyB0byB0aGF0IGJvdGggcGFydGllcyBhcmUgbWFraW5nIGhv bmVzdCBlZmZvcnRzIHRvIGRvIHRoZSByaWdodA0KPnRoaW5nLCBidXQgdW5mb3J0dW5hdGVseSwg dGhlIHN0YXRlIG9mIHBsYXkgd2FzIG5vdCBmdWxseSBrbm93biB0byBhbGwuDQo+DQo+PiBWZXJ5 IHZlcnkgZmV3IGRyYWZ0cyBzdGFydCBwZXJmZWN0IGFuZCBkaWZmZXJlbnQgbW9kZWxzIGhhdmUN Cj4+IGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMuICBUaGUgSUVURiBoYXMgYSBjb25zZW5zdXMgcHJv Y2VzcywgYXMgeW91DQo+PiB3ZWxsIGtub3cgb2YgY291cnNlLCB0byByZXNvbHZlIGRpZmZlcmVu Y2VzIGJldHdlZW4gcGVyc3BlY3RpdmVzIGFuZA0KPj4gZHJhZnRzLg0KPg0KPkkgZGlkbid0IGhl YXIgYW55b25lIHNheSB0aGF0IGNvbnNlbnN1cyBoYXMgYWxyZWFkeSBiZWVuIGNhbGxlZC4gIE15 DQo+dGFrZSBhd2F5IGlzIHRoYXQgd2UgaGF2ZSBhIFdHIG1ha2luZyBhbiBob25lc3QgZWZmb3J0 IHRvIG1vdmUgZm9yd2FyZA0KPmluIGEgcGFydGljdWxhciBkaXJlY3Rpb24gYW5kIGl0IGlzIGRv aW5nIGV4YWN0bHkgd2hhdCBpdCBzaG91bGQgYmUgaW4NCj50ZXJtcyBvZiBnZXR0aW5nIGJlaGlu ZCBhIGRlc2lnbiB0ZWFtIGVmZm9ydC4gQW5kIElNTywgb25jZSB5b3UgaGF2ZSBhDQo+V0cgZGVz aWduIHRlYW0gd29ya2luZyBvbiBhbiBlZmZvcnQsIGhhdmluZyBvdGhlcnMgc3VibWl0IGRyYWZ0 cyBpbg0KPnRoZSBzYW1lIHNwYWNlIGlzIG5vdCBhbHdheXMgd2hhdCB3ZSBzaG91bGQgYmUgZW5j b3VyYWdpbmcgcGVvcGxlIHRvDQo+ZG8uDQo+DQo+RG9lcyB0aGF0IG1lYW4gd2Ugc2hvdWxkIG5v dCBhbGxvdyBhZGRpdGlvbmFsIElEcz8gT2YgY291cnNlIG5vdC4gRG9lcw0KPml0IG1lYW4gd2Ug d29uJ3QgbG9vayBhdCB0aGVtIGFuZCBnaXZlIHRoZW0gY29uc2lkZXJhdGlvbiI/IE9mIGNvdXJz ZQ0KPm5vdC4gQnV0IHdlIHNob3VsZCBhbHNvIGJlIGhvbmVzdCB0aGF0IGlmIGEgV0cgaGFzIGFu IG9mZmljaWFsDQo+ZG9jdW1lbnQgb3IgaGFzIGEgRFQgd29ya2luZyBvbiBhIGRvY3VtZW50LCBo YXZpbmcgYWRkaXRpb25hbA0KPiJjb21wZXRpbmciIGRvY3VtZW50cyBzaG93IHVwIGlzIG9mdGVu IG5vdCB0aGUgbW9zdCBjb25zdHJ1Y3RpdmUgd2F5DQo+dG8gY29udHJpYnV0ZS4gVW5sZXNzIG5l d3MgSURzIHJlYWxseSBhcmUgY2xlYXIgYWJvdXQgaG93IHRoZXkgcmVsYXRlDQo+dG8gdGhlIG90 aGVyIGVmZm9ydHMgYW5kIHdoYXQgdGhvc2Ugb3RoZXIgZWZmb3J0cyBhcmUgbGFja2luZy4NCj4N Cj5UaG9tYXMNCj4NCg0KDQo= --_000_D04F49253DD5aceeciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: <90A026D4A3937E4EB21848361932B973@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFs aWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBp bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBTZXB0ZW1i ZXIgMjksIDIwMTQgYXQgNTozMyBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5j b20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj5UaG9tYXMgTmFydGVuICZsdDs8YSBocmVmPSJtYWlsdG86bmFydGVu QHVzLmlibS5jb20iPm5hcnRlbkB1cy5pYm0uY29tPC9hPiZndDssIEplZmYgSGFhcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZndDss DQogU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJl c0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1 YmplY3Q6IDwvc3Bhbj5SZTogW2kycnNdIElFVEYgOTEgbWVldGluZyByZXF1ZXN0ZWQgLSBjYWxs IGZvciBhZ2VuZGE7IHN0YXR1cyByZXBvcnRzPzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJH SU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5BY2VlLA0KPGRpdiBj bGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24s IFNlcCAyOSwgMjAxNCBhdCA0OjQ5IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPHNwYW4gZGlyPSJs dHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmFjZWVAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KVGhhbmtzIE11Y2ggVGhvbWFzISBHaXZl biB0aGF0IEkgd2FzIHRoZSB2aWN0aW0gb2YgY29uc2lkZXJhYmxlIGJhY2stZG9vcjxicj4NCmVz Y2FsYXRpb25zIGFuZCBtYWNoaW5hdGlvbnMsIEkgd2FzIGdpdmluZyBteXNlbGYgYSCp+GNvb2xp bmcgb2ZmqfcgcGVyaW9kPGJyPg0KcHJpb3IgcmVzcG9uZGluZy4gSG93ZXZlciwgeW91IGV4cHJl c3NlZCBteSBzZW50aW1lbnRzIHdpdGggbXVjaCBtb3JlPGJyPg0KcGF0aWVuY2UgdGhhbiBJIGNv dWxkIGhhdmUgbXlzZWxmLiBNb3ZpbmcgZm9yd2FyZCwgd2UgYXJlIGdvaW5nIHRvIGhhdmUgdG88 YnI+DQphZ3JlZSBvbiBhIGhvbWUgZm9yIHRoZXNlIHByb3RvY29sIG1vZGVscyBkcmFmdHMuIE9m IGNvdXJzZSwgbXkgcHJlZmVyZW5jZTxicj4NCndvdWxkIGJlIHRvIGtlZXAgdGhlbSBpbiB0aGUg cHJvdG9jb2wgV0dzIHdpdGggSTJSUyBhbmQgSTJSUyByZXZpZXcuIEdpdmVuPGJyPg0KdGhlIElF U0cgc3RhdGVtZW50IG9uIFlBTkcgbW9kZWxzIHJlcGxhY2VkIE1JQnM8YnI+DQooJmx0OzxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvd3JpdGFibGUtbWliLW1vZHVs ZS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC93cml0YWJsZS1taWItbW9kdWxlLmh0bWw8L2E+Jmd0OyksIEkgaGFkPGJyPg0Kdmlld2VkIHRo aXMgYXMgc2VsZi1ldmlkZW50LjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PkZpcnN0LCBJIHJlYWxseSBhcHByZWNpYXRlIHRoYXQgeW91IGdhdmUgeW91cnNlbGYgYSBjb29s aW5nLW9mZiBwZXJpb2QgYmVmb3JlIHJlc3BvbmRpbmcuPC9kaXY+DQo8ZGl2PkkgZGlkIGV4YWN0 bHkgdGhlIHNhbWUgdGhpbmcgYmVmb3JlIHJlc3BvbmRpbmcuJm5ic3A7IFRoZSBsYXN0IHRoaW5n IHRoYXQgaXMgbmVlZGVkIG9yIGRlc2lyZWQ8L2Rpdj4NCjxkaXY+aXMgZXNjYWxhdGlvbnMuJm5i c3A7IEkgdGhpbmsgdGhpcyBpcyBhbiBleGNlbGxlbnQgcHJhY3RpY2Ugd2hlbiBlbWFpbCBjb252 ZXJzYXRpb25zIGdldCBoZWF0ZWQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZWNv bmQsIHdoYXQgSSBoYXZlIGJlZW4gZW5jb3VyYWdpbmcgaXMgYWJzb2x1dGVseSB0aGF0IHRoZSBZ QU5HIGNvbmZpZ3VyYXRpb24gbW9kZWxzPC9kaXY+DQo8ZGl2PnNob3VsZCBnbyB0byBlYWNoIHBy b3RvY29sIGdyb3VwLiZuYnNwOyBXaGF0IGlzIGNvbmZ1c2luZyB0aGUgc2l0dWF0aW9uIGhlcmUg aXMgdGhhdCB0aGUgSTJSUyByZWxhdGVkPC9kaXY+DQo8ZGl2Pm1vZGVscyBhcmUgbm90L2hhdmUg bm90IGJlZW4gYXNzdW1lZCB0byBiZSB0aGUgc2FtZSB0aGluZy4mbmJzcDsgSW5zdGVhZCwgdGhl IGFzc3VtcHRpb24gaGFzIGJlZW48L2Rpdj4NCjxkaXY+dGhhdCB0aGV5IHdvdWxkIGJlIG1vcmUg bGltaXRlZCBhbmQgcGVyaGFwcyBoYXZlIEkyUlMgc3BlY2lmaWNzIChzdWNoIGFzIGZvciBldmVu dHMpIC0gYW5kPC9kaXY+DQo8ZGl2PnRoZXJlZm9yZSB3b3VsZCBoYXBwZW4gaW4gSTJSUyBhbmQg YWxzbyBiZSBkaXNjdXNzZWQgaW4gdGhlIHNwZWNpZmljIHByb3RvY29sIFdHLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcmQsIHRoZXJlIHdhcyBkaXNjdXNzaW9uIG9uIHRoZSBt YWlsaW5nIGxpc3QgYW5kIGF0IHRoZSBpbnRlcmltIGFib3V0ICZxdW90O29wdGlvbiA0JnF1b3Q7 IHdoaWNoIGlzPC9kaXY+DQo8ZGl2PnB1c2hpbmcgSTJSUyB0byB1c2UgZXhhY3RseSB0aGUgc2Ft ZSBZQU5HIG1vZGVscy4mbmJzcDsgSSBoYXZlIHNlZW4gZGlzY3Vzc2lvbiB0cnlpbmcgdG8gdW5k ZXJzdGFuZDwvZGl2Pg0KPGRpdj53aGF0IHRoaXMgd291bGQgbG9vayBsaWtlIGJ1dCBjZXJ0YWlu bHkgbm90aGluZyBhcm91bmQgY29uc2Vuc3VzIHRoYXQgdGhhdCBzaG91bGQgYmUgdGhlIGNhc2Uu PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB3b3VsZCBob3BlIHRoYXQg d2UgaGF2ZSBhIHNpbmdsZSBtb2RlbCBmb3IgTkVUQ09ORiBhbmQgSTJSUyBvciBhdCBsZWFzdCBh IGNvcmUgT1NQRiBtb2RlbCB0aGF0IGNvbnRhaW5zIHRoZSBsYXJnZSBpbnRlcnNlY3Rpb24uJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN QVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xh c3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pk15IHN0cm9uZyByZWFjdGlvbiBhbmQgZW1haWwgd2FzIHRvIHNldmVyYWwg dGhpbmdzIHRoYXQgSSBzYXcgaGFwcGVuaW5nIHRvZ2V0aGVyOjwvZGl2Pg0KPGRpdj4mbmJzcDsg Jm5ic3A7IGEpIEVmZm9ydHMgdG8gcHJpdmlsZWdlIGFuIGluZGl2aWR1YWwgZHJhZnQgKGV4cGly ZWQpIGFuZCBwdXNoIGF3YXkgb3RoZXIgYXBwcm9hY2hlcy4mbmJzcDsgSSBkbyB1bmRlcnN0YW5k IHRoYXQgaXQgd2FzIHZlcnkgd2VsbCByZWNlaXZlZCBsYXN0IElFVEYsIHRoYXQgYSBuZXcgdmVy c2lvbiB3aWxsIGJlIG91dCBzb29uLCBhbmQgdGhhdCB5b3UgY2FuJ3QgYXNrIGZvciBXRyBhZG9w dGlvbiBpbiBPU1BGIHVudGlsIHRoYXQgb2NjdXJzLjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7 IGIpIEEgY2xhaW0gdGhhdCB0aGUgZHJhZnQgdGFyZ2V0ZWQgYXQgYSBjb25maWcgbW9kZWwgZm9y IE9TUEYgd2FzIGFsbCB0aGF0IHdhcyBuZWVkZWQgZm9yIEkyUlMgKHByZWp1ZGdpbmcgdGhlIHNp dHVhdGlvbik8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgbGF0ZXN0 IE9TUEYgbW9kZWwgaW5jbHVkZXMgb3BlcmF0aW9uYWwgc3RhdGUgYXMgd2VsbCBhcyBjb25maWd1 cmF0aW9uIGFuZCB0aGlzIGlzIG9uZSByZWFzb24gd2h5IGl0IGhhcyB0YWtlbiBhIGxvbmcgdGlt ZSB0byBwdWJsaXNoLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtz LDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90 ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1M RUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGtu b3cgdGhhdCB3ZSB3YW50IHRvIGdldCByZWFsbHkgZ3JlYXQgWUFORyBtb2RlbHMgb3V0IG9mIHRo aXMgYW5kIGVuY291cmFnZSBtb3JlPC9kaXY+DQo8ZGl2PnBlb3BsZSB0byB3b3JrIGluIHRoaXMg c3BhY2UgYW5kIGFsc28gd2FudCB0byBzZWUgSTJSUyBtYWtlIGFjdHVhbCBwcm9ncmVzcy48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYWxzbyBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBi ZXR0ZXIgd2F5cyBmb3IgcGVvcGxlIHRvIGNvbGxhYm9yYXRlIHRoYW4gdG8gZ28gYXdheSBhbmQg d3JpdGUgYSBjb21wZXRpbmcgZHJhZnQgLSBidXQgSSBkbyBub3QgdGhpbmsgdGhhdCB3YXMgdGhl IGludGVudCBvciB3aGF0IGhhcHBlbmVkIGhlcmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5BbGlhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPkFjZWU8 YnI+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxkaXYgY2xhc3M9Img1 Ij48YnI+DQpPbiA5LzI5LzE0LCAyOjQ0IFBNLCAmcXVvdDtUaG9tYXMgTmFydGVuJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bmFydGVuQHVzLmlibS5jb20iPm5hcnRlbkB1cy5pYm0uY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyZndDsgSXQgaXMgTk9UIE9LIHRvIHRlbGwgYW55 b25lIHRoYXQgdGhleSBzaG91bGQgbm90IGNvbnRyaWJ1dGUgYSBkcmFmdCAtPGJyPg0KJmd0OyZn dDtiZWNhdXNlPGJyPg0KJmd0OyZndDsgaXQgbWF5IG11ZGR5IHRoZSB3YXRlcjxicj4NCiZndDsm Z3Q7IG9yIGZvciBBTlkgb3RoZXIgbm9uLXRlY2huaWNhbCByZWFzb24uJm5ic3A7IEluZGl2aWR1 YWwgZHJhZnRzIG9yIGRlc2lyZSB0bzxicj4NCiZndDsmZ3Q7cmVxdWVzdDxicj4NCiZndDsmZ3Q7 IFdHIGFkb3B0aW9uIGRvIG5vdCBjaGFuZ2U8YnI+DQomZ3Q7Jmd0OyB0aGlzLiZuYnNwOyBJIGRv IG5vdCBldmVyIHdhbnQgdG8gc2VlIG9yIGhlYXIgc29tZXRoaW5nIGxpa2UgdGhpcyBvbiBhbiBJ RVRGPGJyPg0KJmd0OyZndDsgbWFpbGluZyBsaXN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7TGV0IG1l IGRlZmVuZCBBY2VlIGhlcmUgYSBiaXQgYW5kIHRyeSB0byBjaGFydCBhIGNvdXJzZSBhIGJpdCBt b3JlPGJyPg0KJmd0O2Rvd24gdGhlIG1pZGRsZS4gV2hlbiBhIFdHIGhhcyBhbiBlZmZvcnQgdW5k ZXJ3YXkgdGhhdCBpcyBpbnRlbmRlZCB0bzxicj4NCiZndDtsZWFkIHRvIGEgV0cgZG9jdW1lbnQg KGFuZCB0aGF0IGlzIHdoYXQgSSByZWFkIHRoZSBjdXJyZW50ICZxdW90O2Rlc2lnbjxicj4NCiZn dDt0ZWFtJnF1b3Q7IGVmZm9ydCB0byBiZSksIGl0IGlzIElNTyBvZnRlbiBub3QgaGVscGZ1bCB0 byBoYXZlIHlldCBtb3JlIElEczxicj4NCiZndDtzdWJtaXR0ZWQgb24gdGhlIHNhbWUgdG9waWMu IFJhdGhlciB0aGFuIGNvbXBsZW1lbnRpbmcgdGhlIGV4aXN0aW5nPGJyPg0KJmd0O3dvcmsgdG93 YXJkcyBhIGNvbmNlbnN1cyByZXN1bHQsIGFkZGl0aW9uYWwgSURzIGNhbiBiZSBhIGRpc3RyYWN0 aW9uPGJyPg0KJmd0O2FuZCByZXF1aXJlIGZvbGsgdG8gc3BlbmQgdGltZSBmaWd1cmluZyBvdXQg aG93IHRoZSBvdGhlciBJRCByZWxhdGVzPGJyPg0KJmd0O3RvIHRoZSBXRyBlZmZvcnQuIEkuZS4s IGl0J3MgbXVjaCBtb3JlIGNvbnN0dWN0aXZlIHRvIHNheSAmcXVvdDtoZXJlIGlzPGJyPg0KJmd0 O3doYXQgaXMgZGVmZmljaWVudCBpbiB0aGUgY3VycmVudCBtb2RlbCwgYW5kIGhlcmUgaXMgd2hh dCBJIHRoaW5rIHdlPGJyPg0KJmd0O3Nob3VsZCBkbyBpbnN0ZWFkJnF1b3Q7LiBJdCBpcyBtdWNo IGxlc3MgY29uc3RydWN0aXZlIHRvIGhhdmUgYSBzdGFuZGFsb25lPGJyPg0KJmd0O0lEIHRoYXQg KHByb2JhYmx5KSBvdmVybGFwcyB3aXRoIHRoZSBvdGhlciBJRHMgYW5kIGRvZXNuJ3QgZm9jdXMg b248YnI+DQomZ3Q7dGhlICpkaWZmZXJlbmNlcyogZnJvbSB0aGUgb3RoZXIgd29yayB0aGF0IGFs cmVhZHkgaGFzIGEgaGVhZCBzdGFydC48YnI+DQomZ3Q7PGJyPg0KJmd0O0l0IGlzIHRoZSBjYXNl IHRoYXQgdGhlIElFVEYgbWFudHJhIGlzICZxdW90O3N1Ym1pdCBhIGRyYWZ0JnF1b3Q7LCBidXQg ZnJhbmtseSw8YnI+DQomZ3Q7SSB0aGluayB0aGF0IGlzIGEgYml0IG9mIGEgc291bmQgYml0ZSB0 aGF0IHdlIHdvdWxkIGRvIHdlbGwgdG8gbm90PGJyPg0KJmd0O3NwaXQgb3V0IGFzIG9mdGVuIGFz IHdlIHNlZW0gdG8gYmVjYXVzZSBpdCB0b28gb2Z0ZW4gbWlzc2VzIHdoYXQ8YnI+DQomZ3Q7cmVh bGx5IHNob3VsZCBoYXBwZW4sIG5hbWVseSwgaG93IGJlc3QgdG8gY29udHJpYnV0ZSB0byByZWFj aGluZzxicj4NCiZndDtjb25zZW5zdXMgaW4gYSBXRy4gV2UgaGF2ZSBhIGh1Z2UgcHJvYmxlbSB0 b2RheSB3aGVyZSB0aGVyZSBhcmU8YnI+DQomZ3Q7b3ZlcmxhcHBpbmcvY29tcGV0aW5nIGRyYWZ0 cyB0aGF0IFdHcyBoYXZlIHRvIHNvcnQgdGhyb3VnaC4gQW5kIGluPGJyPg0KJmd0O21hbnkgb2Yg dGhvc2UgY2FzZXMsIGFkZGl0aW9uYWwgSURzIGhhdmUgdmVyeSBsaXR0bGUgYWRkaXRpb25hbDxi cj4NCiZndDtjb250ZW50IHRoYW4gd2hhdCBhbHJlYWR5IGV4aXN0cy4gQnV0IHNpbmNlIHdlIGdv IGFyb3VuZCB0ZWxsaW5nIGZvbGs8YnI+DQomZ3Q7dG8gJnF1b3Q7c3VibWl0IGFuIElEJnF1b3Q7 LCB3ZSBzaG91bGRuJ3QgYmUgc3VycHJpc2UgdGhhdCB3ZSBnZXQgdGhlbSBiZXlvbmQ8YnI+DQom Z3Q7dGhlIHBvaW50IG9mIGRpbWluaXNoaW5nIHJldHVybnMuIChBbmQgSSBhbSBOT1Qgc2F5aW5n IHRoYXQgdGhlIGRyYWZ0PGJyPg0KJmd0O2F0IGlzc3VlIGhlcmUgaXMgb25lIG9mIHRob3NlLik8 YnI+DQomZ3Q7PGJyPg0KJmd0O0luIHRoaXMgY2FzZSAoYW5kIEkgcGVyc29uYWxseSBkb24ndCBo YXZlIGFueSBza2luIGluIHRoZSBnYW1lKSwgaXQ8YnI+DQomZ3Q7c2VlbXMgdG8gdGhhdCBib3Ro IHBhcnRpZXMgYXJlIG1ha2luZyBob25lc3QgZWZmb3J0cyB0byBkbyB0aGUgcmlnaHQ8YnI+DQom Z3Q7dGhpbmcsIGJ1dCB1bmZvcnR1bmF0ZWx5LCB0aGUgc3RhdGUgb2YgcGxheSB3YXMgbm90IGZ1 bGx5IGtub3duIHRvIGFsbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgVmVyeSB2ZXJ5IGZldyBk cmFmdHMgc3RhcnQgcGVyZmVjdCBhbmQgZGlmZmVyZW50IG1vZGVscyBoYXZlPGJyPg0KJmd0OyZn dDsgZGlmZmVyZW50IHBlcnNwZWN0aXZlcy4mbmJzcDsgVGhlIElFVEYgaGFzIGEgY29uc2Vuc3Vz IHByb2Nlc3MsIGFzIHlvdTxicj4NCiZndDsmZ3Q7IHdlbGwga25vdyBvZiBjb3Vyc2UsIHRvIHJl c29sdmUgZGlmZmVyZW5jZXMgYmV0d2VlbiBwZXJzcGVjdGl2ZXMgYW5kPGJyPg0KJmd0OyZndDsg ZHJhZnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7SSBkaWRuJ3QgaGVhciBhbnlvbmUgc2F5IHRoYXQg Y29uc2Vuc3VzIGhhcyBhbHJlYWR5IGJlZW4gY2FsbGVkLiZuYnNwOyBNeTxicj4NCiZndDt0YWtl IGF3YXkgaXMgdGhhdCB3ZSBoYXZlIGEgV0cgbWFraW5nIGFuIGhvbmVzdCBlZmZvcnQgdG8gbW92 ZSBmb3J3YXJkPGJyPg0KJmd0O2luIGEgcGFydGljdWxhciBkaXJlY3Rpb24gYW5kIGl0IGlzIGRv aW5nIGV4YWN0bHkgd2hhdCBpdCBzaG91bGQgYmUgaW48YnI+DQomZ3Q7dGVybXMgb2YgZ2V0dGlu ZyBiZWhpbmQgYSBkZXNpZ24gdGVhbSBlZmZvcnQuIEFuZCBJTU8sIG9uY2UgeW91IGhhdmUgYTxi cj4NCiZndDtXRyBkZXNpZ24gdGVhbSB3b3JraW5nIG9uIGFuIGVmZm9ydCwgaGF2aW5nIG90aGVy cyBzdWJtaXQgZHJhZnRzIGluPGJyPg0KJmd0O3RoZSBzYW1lIHNwYWNlIGlzIG5vdCBhbHdheXMg d2hhdCB3ZSBzaG91bGQgYmUgZW5jb3VyYWdpbmcgcGVvcGxlIHRvPGJyPg0KJmd0O2RvLjxicj4N CiZndDs8YnI+DQomZ3Q7RG9lcyB0aGF0IG1lYW4gd2Ugc2hvdWxkIG5vdCBhbGxvdyBhZGRpdGlv bmFsIElEcz8gT2YgY291cnNlIG5vdC4gRG9lczxicj4NCiZndDtpdCBtZWFuIHdlIHdvbid0IGxv b2sgYXQgdGhlbSBhbmQgZ2l2ZSB0aGVtIGNvbnNpZGVyYXRpb24mcXVvdDs/IE9mIGNvdXJzZTxi cj4NCiZndDtub3QuIEJ1dCB3ZSBzaG91bGQgYWxzbyBiZSBob25lc3QgdGhhdCBpZiBhIFdHIGhh cyBhbiBvZmZpY2lhbDxicj4NCiZndDtkb2N1bWVudCBvciBoYXMgYSBEVCB3b3JraW5nIG9uIGEg ZG9jdW1lbnQsIGhhdmluZyBhZGRpdGlvbmFsPGJyPg0KJmd0OyZxdW90O2NvbXBldGluZyZxdW90 OyBkb2N1bWVudHMgc2hvdyB1cCBpcyBvZnRlbiBub3QgdGhlIG1vc3QgY29uc3RydWN0aXZlIHdh eTxicj4NCiZndDt0byBjb250cmlidXRlLiBVbmxlc3MgbmV3cyBJRHMgcmVhbGx5IGFyZSBjbGVh ciBhYm91dCBob3cgdGhleSByZWxhdGU8YnI+DQomZ3Q7dG8gdGhlIG90aGVyIGVmZm9ydHMgYW5k IHdoYXQgdGhvc2Ugb3RoZXIgZWZmb3J0cyBhcmUgbGFja2luZy48YnI+DQomZ3Q7PGJyPg0KJmd0 O1Rob21hczxicj4NCiZndDs8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D04F49253DD5aceeciscocom_-- From nobody Mon Sep 29 14:44: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 60D041ACCF4 for ; Mon, 29 Sep 2014 14:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xm7x01NZG4t for ; Mon, 29 Sep 2014 14:44:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF61ACCFC for ; Mon, 29 Sep 2014 14:44:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6FBB4C141; Mon, 29 Sep 2014 17:44:43 -0400 (EDT) Date: Mon, 29 Sep 2014 17:44:43 -0400 From: Jeffrey Haas To: "Acee Lindem (acee)" Message-ID: <20140929214443.GC25791@pfrc> References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> 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/xXraSqbJZXiwq79vQcDUkAfnDao Cc: Thomas Narten , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 21:44:45 -0000 On Mon, Sep 29, 2014 at 09:41:09PM +0000, Acee Lindem (acee) wrote: > I would hope that we have a single model for NETCONF and I2RS or at least a core OSPF model that contains the large intersection. That's why option 4 was suggested. Given that you now have a body of work representing config for OSPF and knowing that I2RS may want to add state into it, please take a look the option 4 discussion and see if it's a good fit. A reminder to the wider WG: "Option 4" was simply the line of discussion from the netmod interim. As seen in its thread it's either not fully explained well or there's still confusion among the interim participants what it actually means. It's not settled that this is what we'll be doing, but it is currently the method that has received the most discussion. -- Jeff From nobody Mon Sep 29 15:57: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 BF48B1ACD68 for ; Mon, 29 Sep 2014 15:57:36 -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 gqJWCfktFeoR for ; Mon, 29 Sep 2014 15:57:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C461ACD5E for ; Mon, 29 Sep 2014 15:57:34 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 29 Sep 2014 22:57:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Mon, 29 Sep 2014 22:57:32 +0000 From: Dean Bogdanovic To: Jeffrey Haas Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OqsIg7rWvErh0yfzFNkgwd1IJwSL3EAgAInD4CAARJUgIAACY0AgAAJl4CAABOWgIAABGqAgAAOBoCAAAQkAIAADGEAgAEWr4CAAITGAIABKxQAgAAit4CAAAxlgIAAAiuAgAABAICAABRXgA== Date: Mon, 29 Sep 2014 22:57:32 +0000 Message-ID: <910DB609-38CA-474C-BF14-413008C51119@juniper.net> References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929214443.GC25791@pfrc> In-Reply-To: <20140929214443.GC25791@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(377454003)(86362001)(87936001)(80022003)(106356001)(92566001)(2656002)(85852003)(105586002)(106116001)(95666004)(83716003)(50226001)(31966008)(85306004)(93886004)(46102003)(76482002)(10300001)(15975445006)(36756003)(93916002)(99286002)(4396001)(97736003)(57306001)(77156001)(99396003)(66066001)(88136002)(82746002)(92726001)(120916001)(87286001)(107046002)(89996001)(20776003)(19580395003)(19580405001)(50986999)(110136001)(21056001)(77096002)(33656002)(101416001)(76176999)(104166001)(64706001)(62966002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <07A062AD24B21344AB7658BEE7B80573@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/O5dqm2rwg6MPp2h1tt5RtHrXz_o Cc: Thomas Narten , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares , Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 22:57:37 -0000 To keep with the existing topic of the discussion (OSPF model), here is my = question: Why would you have two different OSPF models on a single device? That devic= e has certain OSPF capabilities that are implemented and are represented by= a data model. Configuration can be created based on it and written into a = data store. Once you have a base model, you can decide to create other mode= l, but it can be only subset of the base model. There is nothing preventing= you to create a private model, but it has to be based on the base model. Why do you need different model for I2RS? I strongly believe that a single = data model is needed, but having different config stores to save different = configuration parts. In my mind, I2RS has to provide a good mechanism that = allows non-vendor owner of the device to define what can be changed on the = device. The 3rd party should be able to decide that all of device capabilit= ies can be changed through I2RS (I would then argue why do you really want = to do that) or they can decide to go as minimal as changing ACLs, but allow= ing only ACE to be added/deleted from ACL (which makes much more sense IMO)= . In I2RS we can focus on "light weight templates", that fills in specific st= uff across multiple config snippets. L3VPN is such an example. It would fil= l in configs in BGP, routing instances, interfaces. It would all be based o= n the standard models. Another thing could be a proprietary data model like vCPE. Device owner cre= ates private "light weight templates" and it allows I2RS clients to manage = vCPEs. The proprietary vCPE template is a subset of device base model. Base= d on vCPE model, configuration is created and stored in a data store, which= ever is supported by the device and decided by the owner. Now we have to figure out error handling, what happens when you populate a = template, and the commit fails due to underlying config issue, how do you p= ropagate such things back to the upper layer? IMO, all the minimum required= configuration should be copied into ephemeral datastore, so if something b= reaks in the underlying config store, it is still viable, and there are no = interdependencies between data stores. This is how the running config is cr= eated (cfg A || cfg eph) =3D cfg running Base config and ephemeral config are overlaid, ephemeral is see through to = the base config, but device can function correctly by reading most of the c= onfig from ephemeral data store to certain extent.=20 Dean On Sep 29, 2014, at 5:44 PM, Jeffrey Haas wrote: > On Mon, Sep 29, 2014 at 09:41:09PM +0000, Acee Lindem (acee) wrote: >> I would hope that we have a single model for NETCONF and I2RS or at leas= t a core OSPF model that contains the large intersection. >=20 > That's why option 4 was suggested. Given that you now have a body of wor= k > representing config for OSPF and knowing that I2RS may want to add state > into it, please take a look the option 4 discussion and see if it's a goo= d > fit. >=20 > A reminder to the wider WG: "Option 4" was simply the line of discussion > from the netmod interim. As seen in its thread it's either not fully > explained well or there's still confusion among the interim participants > what it actually means. It's not settled that this is what we'll be doin= g, > but it is currently the method that has received the most discussion. >=20 > -- Jeff >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Sep 29 16:12: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 7C1A21ACDC9 for ; Mon, 29 Sep 2014 16:12:45 -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 NQ4cHYS5dqdw for ; Mon, 29 Sep 2014 16:12:43 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3ECD1ACDCE for ; Mon, 29 Sep 2014 16:12:39 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id q58so4481589wes.15 for ; Mon, 29 Sep 2014 16:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bl7qEsRt9TfJr1Z1Oc2Sa5NXUdxeiLAg07hz86RAdS4=; b=YAYXKgDCSRag64wzTSApsEETIUS7hFD5wDdDpn86WtODS2e1HQzMkNSeWaHaFsTAYl Llnp1rfS96OLrUr5Ye65nn1iIKa462ysjCZbiARZQbMhq/5V4R971t9AzCHXMfaevSCf kOoE9HFVzVLgp3ISAo5k4nOMp5Bm6rx2IiXg/oUic3k0PORo1miDonmDtsWYEgMWD2CK NQRO1MDnTjCEHDjxp2ig8itkmj+5wCctl/UZtUVXr3h7PNsr/LaZYhLgiZ+BB0Ld/Qwj KcGwmngoggTXsMi2kEf2jrmQh9Dfm4ljr/gbgnLrtSXsqvdcDwM6LD70xDCYei5iLU1X K+iQ== MIME-Version: 1.0 X-Received: by 10.180.91.164 with SMTP id cf4mr1148017wib.3.1412032358123; Mon, 29 Sep 2014 16:12:38 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 29 Sep 2014 16:12:37 -0700 (PDT) In-Reply-To: <20140929210801.GA24542@pfrc> References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <20140929210801.GA24542@pfrc> Date: Mon, 29 Sep 2014 19:12:37 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: multipart/alternative; boundary=f46d043893431e0d7605043c670e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/6ymmbw-7Ljqkoz_m82AAER_fVKI Cc: "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 23:12:45 -0000 --f46d043893431e0d7605043c670e Content-Type: text/plain; charset=UTF-8 On Mon, Sep 29, 2014 at 5:08 PM, Jeffrey Haas wrote: > [Context for the WG, I spent some time talking to Sue about the topics here > over lunch. I don't think anything has gone wrong beyond a need for > greater > communication of the involved parties. Picking this email to provide > context...] > > On Sat, Sep 27, 2014 at 06:16:33PM -0400, Susan Hares wrote: > > I'm confused by this email thread because these slides state the authors > are > > looking for co-authors for netmod drafts. Are you as the co-chair of OSPF > > declaring consensus on the OSPF yang model draft? Would you point me to > the > > email that indicates the WG Adoption call and conclusion? > > As discussed later on in thread and also over my conversation with Sue, > there is existing work for OSPF and ISIS for defining yang modules. That's > great! Talking with Sue, there's a slightly different focus of intent: > > > The drafts I suggested are I2RS drafts for the I2RS datastore that allow > it > > to configure the routing agent directly. The only way these two drafts > > interact is if the option 4 proposed by the Yang 1.1 interim (created > > 9/19/14) works. It is unclear if it will work - that's under discussion. > > There is no reason to stop the I2RS DM/IM models required by I2RS charter > > work while we find out if option 4 works. > > The issue I2RS has had over the lingering ambiguity of what the I2RS > ephemeral config was going to look like meant that the only instructions > those who were going to do I2RS models was to take their best effort. > Sue's > analysis, similar to that of others, was that a configuration and > operational model was going to be required. > > Note that while I haven't read the drafts, the comment above suggests that > part of the work in there was to identify the insertion points that I2RS > would need for I2RS functionality in the model. This is definitely work > that we need as a WG. > > My own impression of the OSPF and ISIS work was while it was active, it was > not necessarily that visible and may be happening in the context of a > design > team. If so, the impression may have been that the work has stalled. > > One of the discussion points at the last IETF with Benoit and the netmod > chairs during their tutorial session was that the IETF is in need of a > discussion list covering active efforts. This would serve to help solve > some of the common modeling issues along with tracking work that may be > common across models and deserving refactoring into a shared IETF module. > An example of such work is the ACL work. > > I'm under the impression we have yet to create such a coordinating list? > Yes - I spoke with Benoit about creating a rtg-yang-interest mailing list. It hadn't made it to the top of my priority queue, but I plan on working on that this Friday. Alia > Further response later in thread... > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --f46d043893431e0d7605043c670e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Sep 29, 2014 at 5:08 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:
[Context for the WG, I spent some = time talking to Sue about the topics here
over lunch.=C2=A0 I don't think anything has gone wrong beyond a need f= or greater
communication of the involved parties.=C2=A0 Picking this email to provide<= br> context...]

On Sat, Sep 27, 2014 at 06:16:33PM -0400, Susan Hares wrote:
> I'm confused by this email thread because these slides state the a= uthors are
> looking for co-authors for netmod drafts. Are you as the co-chair of O= SPF
> declaring consensus on the OSPF yang model draft? Would you point me t= o the
> email that indicates the WG Adoption call and conclusion?

As discussed later on in thread and also over my conversation with S= ue,
there is existing work for OSPF and ISIS for defining yang modules.=C2=A0 T= hat's
great!=C2=A0 Talking with Sue, there's a slightly different focus of in= tent:

> The drafts I suggested are I2RS drafts for the I2RS datastore that all= ow it
> to configure the routing agent directly. The only way these two drafts=
> interact is if the option 4 proposed by the Yang 1.1 interim (created<= br> > 9/19/14) works.=C2=A0 It is unclear if it will work - that'= s under discussion.
> There is no reason to stop the I2RS DM/IM models requ= ired by I2RS charter
> work while we find out if option 4 works.

The issue I2RS has had over the lingering ambiguity of what the I2RS=
ephemeral config was going to look like meant that the only instructions those who were going to do I2RS models was to take their best effort.=C2=A0= Sue's
analysis, similar to that of others, was that a configuration and
operational model was going to be required.

Note that while I haven't read the drafts, the comment above suggests t= hat
part of the work in there was to identify the insertion points that I2RS would need for I2RS functionality in the model.=C2=A0 This is definitely wo= rk
that we need as a WG.

My own impression of the OSPF and ISIS work was while it was active, it was=
not necessarily that visible and may be happening in the context of a desig= n
team.=C2=A0 If so, the impression may have been that the work has stalled.<= br>
One of the discussion points at the last IETF with Benoit and the netmod chairs during their tutorial session was that the IETF is in need of a
discussion list covering active efforts.=C2=A0 This would serve to help sol= ve
some of the common modeling issues along with tracking work that may be
common across models and deserving refactoring into a shared IETF module. An example of such work is the ACL work.

I'm under the impression we have yet to create such a coordinating list= ?

Yes - I spoke with Benoit about creat= ing a rtg-yang-interest mailing list.=C2=A0 It hadn't
made it= to the top of my priority queue, but I plan on working on that this Friday= .

Alia=C2=A0

=C2=A0
=
Further response later in thread...
-- Jeff

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

--f46d043893431e0d7605043c670e-- From nobody Mon Sep 29 16:16: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 878EE1ACDDD for ; Mon, 29 Sep 2014 16:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqpy2rq6fN-P for ; Mon, 29 Sep 2014 16:16:46 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE9A1ACDE6 for ; Mon, 29 Sep 2014 16:16:42 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so14012538wes.36 for ; Mon, 29 Sep 2014 16:16:41 -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=IMxjqL0u6ALvbAVR4U3+ZNxXBH2uBFszuhnM75CN9v0=; b=WqV/uBA171p97tOQEZCyELEE8vQC9T50Uafnvgo68vCaLJqubWAWj0j+UCc3yfKVBS ctRYuDswBf2jzrxFy25WWFadVUXKmkKiCPPkZ0o/RXsLl/KW07tY85IJ4GBVdImDj9lt XB1UHfrs1w7PazbIBbE+Kp7H2R3pUTL9RGFl5WJFlxNv8yJOh6rIME3UhJOnD6dBW+k5 n106HZQymTDOHV+fabigvtEpIcyLpqgx9cRV736g+PlWN9RhbN46ao65qhaV1abe2m9V EFLMdNzfgKpjmatSiiJGLBohm8jiFV9lUMP+PTpS/vr9aMBp3Q69PZ5ksvVGMcFFnIC2 sxKA== MIME-Version: 1.0 X-Received: by 10.180.74.9 with SMTP id p9mr1270175wiv.54.1412032601254; Mon, 29 Sep 2014 16:16:41 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 29 Sep 2014 16:16:41 -0700 (PDT) In-Reply-To: <20140929214030.GB25791@pfrc> References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929212720.GE24542@pfrc> <20140929214030.GB25791@pfrc> Date: Mon, 29 Sep 2014 19:16:41 -0400 Message-ID: From: Alia Atlas To: Jeffrey Haas Content-Type: multipart/alternative; boundary=f46d043c81aa9bee8c05043c753e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/TprfTsJR4xpApPIWwVW9tU7rjDQ Cc: Thomas Narten , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 23:16:48 -0000 --f46d043c81aa9bee8c05043c753e Content-Type: text/plain; charset=UTF-8 On Mon, Sep 29, 2014 at 5:40 PM, Jeffrey Haas wrote: > On Mon, Sep 29, 2014 at 05:36:25PM -0400, Alia Atlas wrote: > > On Mon, Sep 29, 2014 at 5:27 PM, Jeffrey Haas wrote: > > > As noted in a prior message, this path is complicated by not having > settled > > > on what I2RS config looks like in an ephemeral datastore. > > > > Absolutely - and since I2RS is still doing info models until there is a > > clear direction, split of the work, and recharter. > > Per prior discussions and our last session, the WG was suggested to go > forth > and start writing data models - knowing that they'll be incomplete until > this is settled. Info models were okay to generate from the data models if > a separate info model provided no additional useful context. > Absolutely - that was the direction I encouraged and what I was expecting to consider as part of a recharter. Yes, your chairs are behind on sending the recharter request from this > discussion. > It's ok - I've found other charters to go rewrite ;-) This discussion (or rather the one about "option 4") and understanding what differences would be, if any, for I2RS data models is very very useful to have before touching the charter. Alia > > -- Jeff > --f46d043c81aa9bee8c05043c753e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Sep 29, 2014 at 5:40 PM, Jeffrey Haas <jhaas@pfrc.org> wrot= e:
On Mon, Sep 29, 2014 = at 05:36:25PM -0400, Alia Atlas wrote:
> On Mon, Sep 29, 2014 at 5:27 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> > As noted in a prior message, this path is= complicated by not having settled
> > on what I2RS config looks like in an ephemeral datastore.
>
> Absolutely - and since I2RS is still doing info models until there is = a
> clear direction, split of the work, and recharter.

Per prior discussions and our last session, the WG was suggested to = go forth
and start writing data models - knowing that they'll be incomplete unti= l
this is settled.=C2=A0 Info models were okay to generate from the data mode= ls if
a separate info model provided no additional useful context.

Absolutely - that was the direction I encouraged and = what I was expecting to
consider as part of a recharter.=C2=A0

Yes, your chairs are behin= d on sending the recharter request from this
discussion.

It's ok - I've foun= d other charters to go rewrite ;-)
This discussion (or rather the= one about "option 4") and understanding what differences
would be, if any, for I2RS data models is very very useful to have befor= e touching the charter.

Alia
=C2=A0

-- Jeff

--f46d043c81aa9bee8c05043c753e-- From nobody Mon Sep 29 16:22: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 0C6671ACDC9 for ; Mon, 29 Sep 2014 16:22:17 -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 VpTfvyb3bLHU for ; Mon, 29 Sep 2014 16:22:13 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148EC1ACCDC for ; Mon, 29 Sep 2014 16:22:12 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id w62so13554602wes.33 for ; Mon, 29 Sep 2014 16:22:11 -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=1n6G3Ny/wtOCyAL0o0BQF37k5XEyTLzwWlFOla4QwQk=; b=eCBtLsIHwi3GjwcRo4PJq/dRKj5qyYMGS/zP+eDiih6O1oMsCGtOhy9G+pH8U89cr4 lhHrPFU34yYkebLYMJW97HlaZBdpD24bqnVBYvvsUg5CojC//9c3uYArL4aJuTUrF/LO 7V6UO3CsenSRVl5ZEISzjxMTrbF6DjVM9a7ieIVAjcI6E9CI0wYDBMrsK+wynA5iArEu /zSZaik9OJTk5DNIB1L0e4c+PymRTx+k9vVBAwkuVy0sbmDF3Ooe3oiEzCzFWb01RljC jOLr8C6xbXQZovSBDLD8YaH7brtd2HgFFcZs3jwhoxng1EN+Nhl1T9dUR1ma/Q1C/UUh Xk7w== MIME-Version: 1.0 X-Received: by 10.180.91.164 with SMTP id cf4mr1189972wib.3.1412032931672; Mon, 29 Sep 2014 16:22:11 -0700 (PDT) Received: by 10.217.69.138 with HTTP; Mon, 29 Sep 2014 16:22:11 -0700 (PDT) In-Reply-To: References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> Date: Mon, 29 Sep 2014 19:22:11 -0400 Message-ID: From: Alia Atlas To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=f46d043893434dbb9a05043c89b4 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NZN6ssKdD0hpW5_Q7xScmeM_Jbo Cc: Thomas Narten , Jeffrey Haas , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 23:22:17 -0000 --f46d043893434dbb9a05043c89b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 5:41 PM, Acee Lindem (acee) wrote: > > > From: Alia Atlas > Date: Monday, September 29, 2014 at 5:33 PM > To: Acee Lindem > Cc: Thomas Narten , Jeff Haas , " > i2rs@ietf.org" , Susan Hares > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > Acee, > > On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (acee) > wrote: > >> Thanks Much Thomas! Given that I was the victim of considerable back-doo= r >> escalations and machinations, I was giving myself a =C2=B3cooling off=C2= =B2 period >> prior responding. However, you expressed my sentiments with much more >> patience than I could have myself. Moving forward, we are going to have = to >> agree on a home for these protocol models drafts. Of course, my preferen= ce >> would be to keep them in the protocol WGs with I2RS and I2RS review. Giv= en >> the IESG statement on YANG models replaced MIBs >> (), I had >> viewed this as self-evident. > > > First, I really appreciate that you gave yourself a cooling-off period > before responding. > I did exactly the same thing before responding. The last thing that is > needed or desired > is escalations. I think this is an excellent practice when email > conversations get heated. > > Second, what I have been encouraging is absolutely that the YANG > configuration models > should go to each protocol group. What is confusing the situation here i= s > that the I2RS related > models are not/have not been assumed to be the same thing. Instead, the > assumption has been > that they would be more limited and perhaps have I2RS specifics (such as > for events) - and > therefore would happen in I2RS and also be discussed in the specific > protocol WG. > > Third, there was discussion on the mailing list and at the interim about > "option 4" which is > pushing I2RS to use exactly the same YANG models. I have seen discussion > trying to understand > what this would look like but certainly nothing around consensus that tha= t > should be the case. > > > I would hope that we have a single model for NETCONF and I2RS or at > least a core OSPF model that contains the large intersection. > Yes, one of the things that Jeff has been actively working on is coordination between models, understanding what should be groups for reuse, etc. The desire to have a large intersection defined only once is part of why getting good IM/DM from the I2RS perspective is really useful too. For something like the RIB DM, it's easy to talk about events (active/inactive, etc) that one doesn't see or expect in a non-I2RS model. Whether we have the similar events and other examples for OSPF is the question. > My strong reaction and email was to several things that I saw happening > together: > a) Efforts to privilege an individual draft (expired) and push away > other approaches. I do understand that it was very well received last > IETF, that a new version will be out soon, and that you can't ask for WG > adoption in OSPF until that occurs. > b) A claim that the draft targeted at a config model for OSPF was all > that was needed for I2RS (prejudging the situation) > > > The latest OSPF model includes operational state as well as > configuration and this is one reason why it has taken a long time to > publish. > Yes - unfortunate though because I believe that it has changed significantly from what is published and that makes it basically impossible to review. I do know that the authors are trying to get out a new version very very soon; this isn't trying to push them more. I look forward to reviewing it (and I don't say that about many drafts these days). Regards, Alia > > Thanks, > Acee > > > > I know that we want to get really great YANG models out of this and > encourage more > people to work in this space and also want to see I2RS make actual > progress. > > I also agree that there are better ways for people to collaborate than > to go away and write a competing draft - but I do not think that was the > intent or what happened here. > > Regards, > Alia > > > >> Acee >> >> On 9/29/14, 2:44 PM, "Thomas Narten" wrote: >> >> >> It is NOT OK to tell anyone that they should not contribute a draft - >> >>because >> >> it may muddy the water >> >> or for ANY other non-technical reason. Individual drafts or desire t= o >> >>request >> >> WG adoption do not change >> >> this. I do not ever want to see or hear something like this on an IE= TF >> >> mailing list. >> > >> >Let me defend Acee here a bit and try to chart a course a bit more >> >down the middle. When a WG has an effort underway that is intended to >> >lead to a WG document (and that is what I read the current "design >> >team" effort to be), it is IMO often not helpful to have yet more IDs >> >submitted on the same topic. Rather than complementing the existing >> >work towards a concensus result, additional IDs can be a distraction >> >and require folk to spend time figuring out how the other ID relates >> >to the WG effort. I.e., it's much more constuctive to say "here is >> >what is defficient in the current model, and here is what I think we >> >should do instead". It is much less constructive to have a standalone >> >ID that (probably) overlaps with the other IDs and doesn't focus on >> >the *differences* from the other work that already has a head start. >> > >> >It is the case that the IETF mantra is "submit a draft", but frankly, >> >I think that is a bit of a sound bite that we would do well to not >> >spit out as often as we seem to because it too often misses what >> >really should happen, namely, how best to contribute to reaching >> >consensus in a WG. We have a huge problem today where there are >> >overlapping/competing drafts that WGs have to sort through. And in >> >many of those cases, additional IDs have very little additional >> >content than what already exists. But since we go around telling folk >> >to "submit an ID", we shouldn't be surprise that we get them beyond >> >the point of diminishing returns. (And I am NOT saying that the draft >> >at issue here is one of those.) >> > >> >In this case (and I personally don't have any skin in the game), it >> >seems to that both parties are making honest efforts to do the right >> >thing, but unfortunately, the state of play was not fully known to all. >> > >> >> Very very few drafts start perfect and different models have >> >> different perspectives. The IETF has a consensus process, as you >> >> well know of course, to resolve differences between perspectives and >> >> drafts. >> > >> >I didn't hear anyone say that consensus has already been called. My >> >take away is that we have a WG making an honest effort to move forward >> >in a particular direction and it is doing exactly what it should be in >> >terms of getting behind a design team effort. And IMO, once you have a >> >WG design team working on an effort, having others submit drafts in >> >the same space is not always what we should be encouraging people to >> >do. >> > >> >Does that mean we should not allow additional IDs? Of course not. Does >> >it mean we won't look at them and give them consideration"? Of course >> >not. But we should also be honest that if a WG has an official >> >document or has a DT working on a document, having additional >> >"competing" documents show up is often not the most constructive way >> >to contribute. Unless news IDs really are clear about how they relate >> >to the other efforts and what those other efforts are lacking. >> > >> >Thomas >> > >> >> > --f46d043893434dbb9a05043c89b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Sep 29, 2014 at 5:41 PM, Acee Lindem (acee) <acee@cisco.com> wrote:


From: Alia Atlas <akatlas@gmail.com>
Date: Monday, September 29, 2014 at= 5:33 PM
To: Acee Lindem <acee@cisco.com>
Cc: Thomas Narten <narten@us.ibm.com>, Jeff H= aas <jhaas@pfrc.org<= /a>>, "i2rs@ietf= .org" <i2rs@= ietf.org>, Susan Hares <share= s@ndzh.com>
Subject: Re: [i2rs] IETF 91 meeting= requested - call for agenda; status reports?

Acee,

On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (ac= ee) <acee@cisco.com&= gt; wrote:
Thanks Much Thomas! Given that I was the victim of considerable back-door escalations and machinations, I was giving myself a =C2=B3cooling off=C2=B2= period
prior responding. However, you expressed my sentiments with much more
patience than I could have myself. Moving forward, we are going to have to<= br> agree on a home for these protocol models drafts. Of course, my preference<= br> would be to keep them in the protocol WGs with I2RS and I2RS review. Given<= br> the IESG statement on YANG models replaced MIBs
(<http://www.ietf.org/iesg/statement/writable-mib-module.= html>), I had
viewed this as self-evident.

First, I really appreciate that you gave yourself a cooling-off period= before responding.
I did exactly the same thing before responding.=C2=A0 The last thing t= hat is needed or desired
is escalations.=C2=A0 I think this is an excellent practice when email= conversations get heated.

Second, what I have been encouraging is absolutely that the YANG confi= guration models
should go to each protocol group.=C2=A0 What is confusing the situatio= n here is that the I2RS related
models are not/have not been assumed to be the same thing.=C2=A0 Inste= ad, the assumption has been
that they would be more limited and perhaps have I2RS specifics (such = as for events) - and
therefore would happen in I2RS and also be discussed in the specific p= rotocol WG.

Third, there was discussion on the mailing list and at the interim abo= ut "option 4" which is
pushing I2RS to use exactly the same YANG models.=C2=A0 I have seen di= scussion trying to understand
what this would look like but certainly nothing around consensus that = that should be the case.

I would hope that we have a single model for NETCONF and I2RS or at le= ast a core OSPF model that contains the large intersection.=C2=A0

Yes, one of the things that Jeff has bee= n actively working on is coordination between models, understanding what sh= ould be groups for reuse, etc.=C2=A0 The desire to have a large intersectio= n defined only once is part of why getting good IM/DM from the I2RS perspec= tive is really useful too.=C2=A0

For something lik= e the RIB DM, it's easy to talk about events (active/inactive, etc) tha= t one doesn't see or expect in a non-I2RS model.=C2=A0 Whether we have = the similar events and other examples for OSPF is the question.
= =C2=A0
My strong reaction and email was to several things t= hat I saw happening together:
=C2=A0 =C2=A0 a) Efforts to privilege an individual draft (expired) an= d push away other approaches.=C2=A0 I do understand that it was very well r= eceived last IETF, that a new version will be out soon, and that you can= 9;t ask for WG adoption in OSPF until that occurs.
=C2=A0 =C2=A0 b) A claim that the draft targeted at a config model for= OSPF was all that was needed for I2RS (prejudging the situation)

The latest OSPF model includes operational state as well as con= figuration and this is one reason why it has taken a long time to publish.= =C2=A0

Yes - unfortunate though= because I believe that it has changed significantly from what is published= and that makes it basically impossible to review.=C2=A0 I do know that the= authors are trying to get out a new version very very soon; this isn't= trying to push them more. =C2=A0 I look forward to reviewing it (and I don= 't say that about many drafts these days).

Reg= ards,
Alia
=C2=A0
<= div style=3D"word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-fami= ly:Calibri,sans-serif">

Thanks,
Acee=C2=A0



I know that we want to get really great YANG models out of this and en= courage more
people to work in this space and also want to see I2RS make actual pro= gress.

I also agree that there are better ways for people to collaborate than= to go away and write a competing draft - but I do not think that was the i= ntent or what happened here.

Regards,
Alia

=C2=A0
Acee

On 9/29/14, 2:44 PM, "Thomas Narten" <narten@us.ibm.com> wrote:

>> It is NOT OK to tell anyone that they should not contribute a draf= t -
>>because
>> it may muddy the water
>> or for ANY other non-technical reason.=C2=A0 Individual drafts or = desire to
>>request
>> WG adoption do not change
>> this.=C2=A0 I do not ever want to see or hear something like this = on an IETF
>> mailing list.
>
>Let me defend Acee here a bit and try to chart a course a bit more
>down the middle. When a WG has an effort underway that is intended to >lead to a WG document (and that is what I read the current "design=
>team" effort to be), it is IMO often not helpful to have yet more = IDs
>submitted on the same topic. Rather than complementing the existing
>work towards a concensus result, additional IDs can be a distraction >and require folk to spend time figuring out how the other ID relates >to the WG effort. I.e., it's much more constuctive to say "her= e is
>what is defficient in the current model, and here is what I think we >should do instead". It is much less constructive to have a standal= one
>ID that (probably) overlaps with the other IDs and doesn't focus on=
>the *differences* from the other work that already has a head start. >
>It is the case that the IETF mantra is "submit a draft", but = frankly,
>I think that is a bit of a sound bite that we would do well to not
>spit out as often as we seem to because it too often misses what
>really should happen, namely, how best to contribute to reaching
>consensus in a WG. We have a huge problem today where there are
>overlapping/competing drafts that WGs have to sort through. And in
>many of those cases, additional IDs have very little additional
>content than what already exists. But since we go around telling folk >to "submit an ID", we shouldn't be surprise that we get t= hem beyond
>the point of diminishing returns. (And I am NOT saying that the draft >at issue here is one of those.)
>
>In this case (and I personally don't have any skin in the game), it=
>seems to that both parties are making honest efforts to do the right >thing, but unfortunately, the state of play was not fully known to all.=
>
>> Very very few drafts start perfect and different models have
>> different perspectives.=C2=A0 The IETF has a consensus process, as= you
>> well know of course, to resolve differences between perspectives a= nd
>> drafts.
>
>I didn't hear anyone say that consensus has already been called.=C2= =A0 My
>take away is that we have a WG making an honest effort to move forward<= br> >in a particular direction and it is doing exactly what it should be in<= br> >terms of getting behind a design team effort. And IMO, once you have a<= br> >WG design team working on an effort, having others submit drafts in
>the same space is not always what we should be encouraging people to >do.
>
>Does that mean we should not allow additional IDs? Of course not. Does<= br> >it mean we won't look at them and give them consideration"? Of= course
>not. But we should also be honest that if a WG has an official
>document or has a DT working on a document, having additional
>"competing" documents show up is often not the most construct= ive way
>to contribute. Unless news IDs really are clear about how they relate >to the other efforts and what those other efforts are lacking.
>
>Thomas
>

--f46d043893434dbb9a05043c89b4-- From nobody Mon Sep 29 16:39: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 728A11ACD76 for ; Mon, 29 Sep 2014 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 cnpqiE_AEILU for ; Mon, 29 Sep 2014 16:39:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764B91A6F05 for ; Mon, 29 Sep 2014 16:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3903; q=dns/txt; s=iport; t=1412033965; x=1413243565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tcGpdvXkJLbcYQA51E3ScNgsEWr6X+f+o/vvxMkjPp0=; b=iitlJfVwHPC0cRAauEwzEPTx9o0bI+Z6r0yZiCQ1aVtXOb1yiEXfWFXr QY6LOZA5gtoxXThGF0EEK7ab4Iw2aNJIKKntHDg5naKuSyMxqOmkTp5Kd Uj2ZVarUPR2fuNVcXxmcsS1ZTxNGveoYxHrDZ6JQg7634C49mLLZ7v+fA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAKzsKVStJV2P/2dsb2JhbABggw5TVwTKEQqHTgKBEBYBe4QEAQEEAQEBGlELEAIBCBguJwslAgQBDQWIPg2/HAETBIxLg1MHhEsFixOGUotDlV2DY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,623,1406592000"; d="scan'208";a="82534958" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP; 29 Sep 2014 23:39:24 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8TNdOjO025535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 23:39:24 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 18:39:24 -0500 From: "Acee Lindem (acee)" To: Dean Bogdanovic , Jeffrey Haas Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqAgABRF4D//8ETAAAJ7j8AABpz1oAAGPrVAAAlYmsA///fpoCAAE92gP//vxwAgABED4CAABRYAP//yKIA Date: Mon, 29 Sep 2014 23:39:23 +0000 Message-ID: References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929214443.GC25791@pfrc> <910DB609-38CA-474C-BF14-413008C51119@juniper.net> In-Reply-To: <910DB609-38CA-474C-BF14-413008C51119@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] 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/OwPNEv5r_1BNk__LpuQZyAU675Y Cc: Thomas Narten , "i2rs@ietf.org" , Susan Hares , Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 29 Sep 2014 23:39:27 -0000 Right - while there may be unique access models for the data which reflect unique I2RS or NETCONF requirements, I don=B9t see why the domain specific (e.g., OSPF) model content would be different. On 9/29/14, 6:57 PM, "Dean Bogdanovic" wrote: >To keep with the existing topic of the discussion (OSPF model), here is >my question: > >Why would you have two different OSPF models on a single device? That >device has certain OSPF capabilities that are implemented and are >represented by a data model. Configuration can be created based on it and >written into a data store. Once you have a base model, you can decide to >create other model, but it can be only subset of the base model. There is >nothing preventing you to create a private model, but it has to be based >on the base model. >Why do you need different model for I2RS? I strongly believe that a >single data model is needed, but having different config stores to save >different configuration parts. In my mind, I2RS has to provide a good >mechanism that allows non-vendor owner of the device to define what can >be changed on the device. The 3rd party should be able to decide that all >of device capabilities can be changed through I2RS (I would then argue >why do you really want to do that) or they can decide to go as minimal as >changing ACLs, but allowing only ACE to be added/deleted from ACL (which >makes much more sense IMO). >In I2RS we can focus on "light weight templates", that fills in specific >stuff across multiple config snippets. L3VPN is such an example. It would >fill in configs in BGP, routing instances, interfaces. It would all be >based on the standard models. >Another thing could be a proprietary data model like vCPE. Device owner >creates private "light weight templates" and it allows I2RS clients to >manage vCPEs. The proprietary vCPE template is a subset of device base >model. Based on vCPE model, configuration is created and stored in a data >store, which ever is supported by the device and decided by the owner. >Now we have to figure out error handling, what happens when you populate >a template, and the commit fails due to underlying config issue, how do >you propagate such things back to the upper layer? IMO, all the minimum >required configuration should be copied into ephemeral datastore, so if >something breaks in the underlying config store, it is still viable, and >there are no interdependencies between data stores. This is how the >running config is created > >(cfg A || cfg eph) =3D cfg running > >Base config and ephemeral config are overlaid, ephemeral is see through >to the base config, but device can function correctly by reading most of >the config from ephemeral data store to certain extent. > >Dean > >On Sep 29, 2014, at 5:44 PM, Jeffrey Haas wrote: > >> On Mon, Sep 29, 2014 at 09:41:09PM +0000, Acee Lindem (acee) wrote: >>> I would hope that we have a single model for NETCONF and I2RS or at >>>least a core OSPF model that contains the large intersection. >>=20 >> That's why option 4 was suggested. Given that you now have a body of >>work >> representing config for OSPF and knowing that I2RS may want to add state >> into it, please take a look the option 4 discussion and see if it's a >>good >> fit. >>=20 >> A reminder to the wider WG: "Option 4" was simply the line of discussion >> from the netmod interim. As seen in its thread it's either not fully >> explained well or there's still confusion among the interim participants >> what it actually means. It's not settled that this is what we'll be >>doing, >> but it is currently the method that has received the most discussion. >>=20 >> -- Jeff >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Sep 29 17:40: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 59F5D1A0004 for ; Mon, 29 Sep 2014 17:40:19 -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 0nuG5cCuSufm for ; Mon, 29 Sep 2014 17:40:18 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6191A0009 for ; Mon, 29 Sep 2014 17:40:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Joe Clarke'" , "'Jeffrey Haas'" , References: <20140925180055.GB1239@pfrc> <5429AB19.4050406@cisco.com> In-Reply-To: <5429AB19.4050406@cisco.com> Date: Mon, 29 Sep 2014 20:40:10 -0400 Message-ID: <00f901cfdc47$174e4d30$45eae790$@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: AQF6CdpPDPl0C8Ln1ozC47wAm7/GlQIxvPt4nLLsb7A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eUZmPXhrOGqOpY6LkfpsfdmfT0Q Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 30 Sep 2014 00:40:19 -0000 Joe: By shoe dropping - I think you mean accepted of the traceability as WG draft. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke Sent: Monday, September 29, 2014 2:55 PM To: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? On 9/25/14 2:00 PM, Jeffrey Haas wrote: > Your chairs have been a bit over-busy recently with travel to unicast > people doing various bits of chartered work. This means we've been > behind on some of our goals in terms of getting regular design > sessions running. I know that at least a couple calls have happened > that I've missed that Sue Hares has done, so some progress is being made. > > We've requested a 1 hour time slot for IETF 91 in Honolulu to give us > a chance to talk. This is a call for agenda slots. > > This is also a call for status reports. > > We've had some productive discussion about requests to netmod/netconf, > albeit ones that haven't converged yet. > > What have you been up to? I think the list knows about the traceability "shoe" that's been waiting to drop. Question is, can it be settled on the list, should we ask in Honolulu? Does it need an agenda item or can the chairs raise the point? Thanks. Joe _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Sep 29 19:46:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B363C1A00C9 for ; Mon, 29 Sep 2014 19:46:38 -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 TEFQGFhEfp6i for ; Mon, 29 Sep 2014 19:46:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A9FE41A0072 for ; Mon, 29 Sep 2014 19:46:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Dean Bogdanovic'" , "'Jeffrey Haas'" References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929214443.GC25791@pfrc> <910DB609-38CA-474C-BF14-413008C51119@juniper.net> In-Reply-To: Date: Mon, 29 Sep 2014 22:45:50 -0400 Message-ID: <013501cfdc58$b7d55d00$27801700$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKFCejByBkuVBwZ4sNlfWCl7yDNNAIPdZrnAk+sR2gC9jzY6AKrn///AfaLXvsB2ewIDQH7anQsAnX62egBb5lD9QHM/KKIAbmJikECE26aAJnkN3ww Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/yGBqj7kBwXgkwPbUF4UW2oLY_Wg Cc: 'Thomas Narten' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 30 Sep 2014 02:46:38 -0000 Acee: I think that you, Dean, and I hope to work toward a model that finds as = much common ground for device specific. As Jeff pointed out, the domain = specific configuration models need to look at all vendor yang to see we've found = the IETF I2rs/config to make sure we've found that common ground. In my = earlier request to review, it was based on concept of discovering anything with = the OSPF models that need to be augmented for I2RS. =20 Dean suggests modular models that can be used to create the final model within the standard or proprietary - which is good. The error handling = is key during commits or crashes.=20 Thank you for active discussion, Sue =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Acee Lindem = (acee) Sent: Monday, September 29, 2014 7:39 PM To: Dean Bogdanovic; Jeffrey Haas Cc: Thomas Narten; i2rs@ietf.org; Susan Hares; Alia Atlas Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Right - while there may be unique access models for the data which = reflect unique I2RS or NETCONF requirements, I don=B9t see why the domain = specific (e.g., OSPF) model content would be different. On 9/29/14, 6:57 PM, "Dean Bogdanovic" wrote: >To keep with the existing topic of the discussion (OSPF model), here is = >my question: > >Why would you have two different OSPF models on a single device? That=20 >device has certain OSPF capabilities that are implemented and are=20 >represented by a data model. Configuration can be created based on it=20 >and written into a data store. Once you have a base model, you can=20 >decide to create other model, but it can be only subset of the base=20 >model. There is nothing preventing you to create a private model, but=20 >it has to be based on the base model. >Why do you need different model for I2RS? I strongly believe that a=20 >single data model is needed, but having different config stores to save = >different configuration parts. In my mind, I2RS has to provide a good=20 >mechanism that allows non-vendor owner of the device to define what can = >be changed on the device. The 3rd party should be able to decide that=20 >all of device capabilities can be changed through I2RS (I would then=20 >argue why do you really want to do that) or they can decide to go as=20 >minimal as changing ACLs, but allowing only ACE to be added/deleted=20 >from ACL (which makes much more sense IMO). >In I2RS we can focus on "light weight templates", that fills in=20 >specific stuff across multiple config snippets. L3VPN is such an=20 >example. It would fill in configs in BGP, routing instances,=20 >interfaces. It would all be based on the standard models. >Another thing could be a proprietary data model like vCPE. Device owner = >creates private "light weight templates" and it allows I2RS clients to=20 >manage vCPEs. The proprietary vCPE template is a subset of device base=20 >model. Based on vCPE model, configuration is created and stored in a=20 >data store, which ever is supported by the device and decided by the = owner. >Now we have to figure out error handling, what happens when you=20 >populate a template, and the commit fails due to underlying config=20 >issue, how do you propagate such things back to the upper layer? IMO,=20 >all the minimum required configuration should be copied into ephemeral=20 >datastore, so if something breaks in the underlying config store, it is = >still viable, and there are no interdependencies between data stores.=20 >This is how the running config is created > >(cfg A || cfg eph) =3D cfg running > >Base config and ephemeral config are overlaid, ephemeral is see through = >to the base config, but device can function correctly by reading most=20 >of the config from ephemeral data store to certain extent. > >Dean > >On Sep 29, 2014, at 5:44 PM, Jeffrey Haas wrote: > >> On Mon, Sep 29, 2014 at 09:41:09PM +0000, Acee Lindem (acee) wrote: >>> I would hope that we have a single model for NETCONF and I2RS or at=20 >>>least a core OSPF model that contains the large intersection. >>=20 >> That's why option 4 was suggested. Given that you now have a body of = >>work representing config for OSPF and knowing that I2RS may want to=20 >>add state into it, please take a look the option 4 discussion and see = >>if it's a good fit. >>=20 >> A reminder to the wider WG: "Option 4" was simply the line of=20 >>discussion from the netmod interim. As seen in its thread it's=20 >>either not fully explained well or there's still confusion among the=20 >>interim participants what it actually means. It's not settled that=20 >>this is what we'll be doing, but it is currently the method that has=20 >>received the most discussion. >>=20 >> -- Jeff >>=20 >> _______________________________________________ >> 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 Tue Sep 30 06:49: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 26F7D1A1A05 for ; Tue, 30 Sep 2014 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 YzaotQWXzBCE for ; Tue, 30 Sep 2014 06:48:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6261A030B for ; Tue, 30 Sep 2014 06:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7756; q=dns/txt; s=iport; t=1412084939; x=1413294539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ySBg/hWlWSBNNcwyJr8LXLowXMS7iXKRCL6uSW+yaUY=; b=I2q3w3L7hKuOQs1D6COFseJor03qYuQnNEfRPdX5GfcoW4T71370C20k jLjDI2G5wrYHx3Wu+VgmN4O43pkh0LVSegq6NRyr42F+7Mq1GrWgBX635 2j8cPPYukRvn0d6f6mWprUpfZLvL4lJPigxK9F4xaAxNAMMqJK4lAE0y0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFANezKlStJA2E/2dsb2JhbABggw5TVwSCfsccCodNAhlvFgF7hAMBAQEDAQEBARoXOgsMBAIBCA4DBAEBAQQjBQICJQsUCQgCBAENBYg2CA2MaZxEBpYWARMEgSaLJYMgMwcGgmyBWQWRaotFlXCDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,626,1406592000"; d="scan'208";a="359453851" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 30 Sep 2014 13:48:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UDmwXx026031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 13:48:58 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 08:48:58 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "'Dean Bogdanovic'" , "'Jeffrey Haas'" Thread-Topic: [i2rs] IETF 91 meeting requested - call for agenda; status reports? Thread-Index: AQHP2OquSp4i883k10igxhKi8uSjxpwSg0UAgAInDICAAM9KAIAATJgA///GhwCAAFalgP//wVqAgABRF4D//8ETAAAJ7j8AABpz1oAAGPrVAAAlYmsA///fpoCAAE92gP//vxwAgABED4CAABRYAP//yKIAgAB3JwCAAHY3AA== Date: Tue, 30 Sep 2014 13:48:57 +0000 Message-ID: References: <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929214443.GC25791@pfrc> <910DB609-38CA-474C-BF14-413008C51119@juniper.net> <013501cfdc58$b7d55d00$27801700$@ndzh.com> In-Reply-To: <013501cfdc58$b7d55d00$27801700$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="euc-kr" Content-ID: <1DADDC0ED5E52E42977437647746F4DE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EMagAgf8PzTEQjZU4qiCNiOXcFc Cc: 'Thomas Narten' , "i2rs@ietf.org" , 'Alia Atlas' Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 30 Sep 2014 13:49:01 -0000 SGkgU3VlLCANCg0KVGhlcmUgYXJlIGVmZm9ydHMgdW5kZXJ3YXkgdG8gaW5jb3Jwb3JhdGUgYWRk aXRpb25hbCBwYXJ0aWNpcGFudHMgaW50byB0aGUNCklHUCBZQU5HIG1vZGVsIHRlYW1zIGFuZCwg b2YgY291cnNlLCBmdWxsIFdHIHJldmlldy4gVGhlIGRpcmVjdGlvbiB3ZSBoYXZlDQpiZWVuIHRh a2luZyBpcyB0aGF0IGNvbW1vbiBleHRlbnNpb25zIGFyZSBoYW5kbGVkIGFzIGZlYXR1cmVzIGFu ZCBzdHJpY3RseQ0KcHJvcHJpZXRhcnkgZXh0ZW5zaW9ucyB3aWxsIGJlIGhhbmRsZWQgd2l0aCBt b2RlbHMgYXVnbWVudGluZyB0aGUgYmFzZS4NCg0KVGhhbmtzLA0KQWNlZSANCg0KT24gOS8yOS8x NCwgMTA6NDUgUE0sICJTdXNhbiBIYXJlcyIgPHNoYXJlc0BuZHpoLmNvbT4gd3JvdGU6DQoNCj5B Y2VlOg0KPg0KPkkgdGhpbmsgdGhhdCB5b3UsIERlYW4sIGFuZCBJIGhvcGUgdG8gd29yayB0b3dh cmQgYSBtb2RlbCB0aGF0IGZpbmRzIGFzDQo+bXVjaA0KPmNvbW1vbiBncm91bmQgZm9yIGRldmlj ZSBzcGVjaWZpYy4gQXMgSmVmZiBwb2ludGVkIG91dCwgdGhlIGRvbWFpbg0KPnNwZWNpZmljDQo+ Y29uZmlndXJhdGlvbiBtb2RlbHMgbmVlZCB0byBsb29rIGF0IGFsbCB2ZW5kb3IgeWFuZyB0byBz ZWUgd2UndmUgZm91bmQNCj50aGUNCj5JRVRGIEkycnMvY29uZmlnIHRvIG1ha2Ugc3VyZSB3ZSd2 ZSBmb3VuZCB0aGF0IGNvbW1vbiBncm91bmQuICBJbiBteQ0KPmVhcmxpZXINCj5yZXF1ZXN0IHRv IHJldmlldywgaXQgd2FzIGJhc2VkIG9uIGNvbmNlcHQgb2YgZGlzY292ZXJpbmcgYW55dGhpbmcg d2l0aA0KPnRoZQ0KPk9TUEYgbW9kZWxzIHRoYXQgbmVlZCB0byBiZSBhdWdtZW50ZWQgZm9yIEky UlMuDQo+DQo+RGVhbiBzdWdnZXN0cyBtb2R1bGFyIG1vZGVscyB0aGF0IGNhbiBiZSB1c2VkIHRv IGNyZWF0ZSB0aGUgZmluYWwgbW9kZWwNCj53aXRoaW4gdGhlIHN0YW5kYXJkIG9yIHByb3ByaWV0 YXJ5IC0gd2hpY2ggaXMgZ29vZC4gIFRoZSBlcnJvciBoYW5kbGluZyBpcw0KPmtleSBkdXJpbmcg Y29tbWl0cyBvciBjcmFzaGVzLg0KPg0KPlRoYW5rIHlvdSBmb3IgYWN0aXZlIGRpc2N1c3Npb24s DQo+DQo+U3VlICANCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGkycnMg W21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbSAo YWNlZSkNCj5TZW50OiBNb25kYXksIFNlcHRlbWJlciAyOSwgMjAxNCA3OjM5IFBNDQo+VG86IERl YW4gQm9nZGFub3ZpYzsgSmVmZnJleSBIYWFzDQo+Q2M6IFRob21hcyBOYXJ0ZW47IGkycnNAaWV0 Zi5vcmc7IFN1c2FuIEhhcmVzOyBBbGlhIEF0bGFzDQo+U3ViamVjdDogUmU6IFtpMnJzXSBJRVRG IDkxIG1lZXRpbmcgcmVxdWVzdGVkIC0gY2FsbCBmb3IgYWdlbmRhOyBzdGF0dXMNCj5yZXBvcnRz Pw0KPg0KPlJpZ2h0IC0gd2hpbGUgdGhlcmUgbWF5IGJlIHVuaXF1ZSBhY2Nlc3MgbW9kZWxzIGZv ciB0aGUgZGF0YSB3aGljaCByZWZsZWN0DQo+dW5pcXVlIEkyUlMgb3IgTkVUQ09ORiByZXF1aXJl bWVudHMsIEkgZG9uqfZ0IHNlZSB3aHkgdGhlIGRvbWFpbiBzcGVjaWZpYw0KPihlLmcuLCBPU1BG KSBtb2RlbCBjb250ZW50IHdvdWxkIGJlIGRpZmZlcmVudC4NCj4NCj5PbiA5LzI5LzE0LCA2OjU3 IFBNLCAiRGVhbiBCb2dkYW5vdmljIiA8ZGVhbmJAanVuaXBlci5uZXQ+IHdyb3RlOg0KPg0KPj5U byBrZWVwIHdpdGggdGhlIGV4aXN0aW5nIHRvcGljIG9mIHRoZSBkaXNjdXNzaW9uIChPU1BGIG1v ZGVsKSwgaGVyZSBpcw0KPj5teSBxdWVzdGlvbjoNCj4+DQo+PldoeSB3b3VsZCB5b3UgaGF2ZSB0 d28gZGlmZmVyZW50IE9TUEYgbW9kZWxzIG9uIGEgc2luZ2xlIGRldmljZT8gVGhhdA0KPj5kZXZp Y2UgaGFzIGNlcnRhaW4gT1NQRiBjYXBhYmlsaXRpZXMgdGhhdCBhcmUgaW1wbGVtZW50ZWQgYW5k IGFyZQ0KPj5yZXByZXNlbnRlZCBieSBhIGRhdGEgbW9kZWwuIENvbmZpZ3VyYXRpb24gY2FuIGJl IGNyZWF0ZWQgYmFzZWQgb24gaXQNCj4+YW5kIHdyaXR0ZW4gaW50byBhIGRhdGEgc3RvcmUuIE9u Y2UgeW91IGhhdmUgYSBiYXNlIG1vZGVsLCB5b3UgY2FuDQo+PmRlY2lkZSB0byBjcmVhdGUgb3Ro ZXIgbW9kZWwsIGJ1dCBpdCBjYW4gYmUgb25seSBzdWJzZXQgb2YgdGhlIGJhc2UNCj4+bW9kZWwu IFRoZXJlIGlzIG5vdGhpbmcgcHJldmVudGluZyB5b3UgdG8gY3JlYXRlIGEgcHJpdmF0ZSBtb2Rl bCwgYnV0DQo+Pml0IGhhcyB0byBiZSBiYXNlZCBvbiB0aGUgYmFzZSBtb2RlbC4NCj4+V2h5IGRv IHlvdSBuZWVkIGRpZmZlcmVudCBtb2RlbCBmb3IgSTJSUz8gSSBzdHJvbmdseSBiZWxpZXZlIHRo YXQgYQ0KPj5zaW5nbGUgZGF0YSBtb2RlbCBpcyBuZWVkZWQsIGJ1dCBoYXZpbmcgZGlmZmVyZW50 IGNvbmZpZyBzdG9yZXMgdG8gc2F2ZQ0KPj5kaWZmZXJlbnQgY29uZmlndXJhdGlvbiBwYXJ0cy4g SW4gbXkgbWluZCwgSTJSUyBoYXMgdG8gcHJvdmlkZSBhIGdvb2QNCj4+bWVjaGFuaXNtIHRoYXQg YWxsb3dzIG5vbi12ZW5kb3Igb3duZXIgb2YgdGhlIGRldmljZSB0byBkZWZpbmUgd2hhdCBjYW4N Cj4+YmUgY2hhbmdlZCBvbiB0aGUgZGV2aWNlLiBUaGUgM3JkIHBhcnR5IHNob3VsZCBiZSBhYmxl IHRvIGRlY2lkZSB0aGF0DQo+PmFsbCBvZiBkZXZpY2UgY2FwYWJpbGl0aWVzIGNhbiBiZSBjaGFu Z2VkIHRocm91Z2ggSTJSUyAoSSB3b3VsZCB0aGVuDQo+PmFyZ3VlIHdoeSBkbyB5b3UgcmVhbGx5 IHdhbnQgdG8gZG8gdGhhdCkgb3IgdGhleSBjYW4gZGVjaWRlIHRvIGdvIGFzDQo+Pm1pbmltYWwg YXMgY2hhbmdpbmcgQUNMcywgYnV0IGFsbG93aW5nIG9ubHkgQUNFIHRvIGJlIGFkZGVkL2RlbGV0 ZWQNCj4+ZnJvbSBBQ0wgKHdoaWNoIG1ha2VzIG11Y2ggbW9yZSBzZW5zZSBJTU8pLg0KPj5JbiBJ MlJTIHdlIGNhbiBmb2N1cyBvbiAibGlnaHQgd2VpZ2h0IHRlbXBsYXRlcyIsIHRoYXQgZmlsbHMg aW4NCj4+c3BlY2lmaWMgc3R1ZmYgYWNyb3NzIG11bHRpcGxlIGNvbmZpZyBzbmlwcGV0cy4gTDNW UE4gaXMgc3VjaCBhbg0KPj5leGFtcGxlLiBJdCB3b3VsZCBmaWxsIGluIGNvbmZpZ3MgaW4gQkdQ LCByb3V0aW5nIGluc3RhbmNlcywNCj4+aW50ZXJmYWNlcy4gSXQgd291bGQgYWxsIGJlIGJhc2Vk IG9uIHRoZSBzdGFuZGFyZCBtb2RlbHMuDQo+PkFub3RoZXIgdGhpbmcgY291bGQgYmUgYSBwcm9w cmlldGFyeSBkYXRhIG1vZGVsIGxpa2UgdkNQRS4gRGV2aWNlIG93bmVyDQo+PmNyZWF0ZXMgcHJp dmF0ZSAibGlnaHQgd2VpZ2h0IHRlbXBsYXRlcyIgYW5kIGl0IGFsbG93cyBJMlJTIGNsaWVudHMg dG8NCj4+bWFuYWdlIHZDUEVzLiBUaGUgcHJvcHJpZXRhcnkgdkNQRSB0ZW1wbGF0ZSBpcyBhIHN1 YnNldCBvZiBkZXZpY2UgYmFzZQ0KPj5tb2RlbC4gQmFzZWQgb24gdkNQRSBtb2RlbCwgY29uZmln dXJhdGlvbiBpcyBjcmVhdGVkIGFuZCBzdG9yZWQgaW4gYQ0KPj5kYXRhIHN0b3JlLCB3aGljaCBl dmVyIGlzIHN1cHBvcnRlZCBieSB0aGUgZGV2aWNlIGFuZCBkZWNpZGVkIGJ5IHRoZQ0KPj5vd25l ci4NCj4+Tm93IHdlIGhhdmUgdG8gZmlndXJlIG91dCBlcnJvciBoYW5kbGluZywgd2hhdCBoYXBw ZW5zIHdoZW4geW91DQo+PnBvcHVsYXRlIGEgdGVtcGxhdGUsIGFuZCB0aGUgY29tbWl0IGZhaWxz IGR1ZSB0byB1bmRlcmx5aW5nIGNvbmZpZw0KPj5pc3N1ZSwgaG93IGRvIHlvdSBwcm9wYWdhdGUg c3VjaCB0aGluZ3MgYmFjayB0byB0aGUgdXBwZXIgbGF5ZXI/IElNTywNCj4+YWxsIHRoZSBtaW5p bXVtIHJlcXVpcmVkIGNvbmZpZ3VyYXRpb24gc2hvdWxkIGJlIGNvcGllZCBpbnRvIGVwaGVtZXJh bA0KPj5kYXRhc3RvcmUsIHNvIGlmIHNvbWV0aGluZyBicmVha3MgaW4gdGhlIHVuZGVybHlpbmcg Y29uZmlnIHN0b3JlLCBpdCBpcw0KPj5zdGlsbCB2aWFibGUsIGFuZCB0aGVyZSBhcmUgbm8gaW50 ZXJkZXBlbmRlbmNpZXMgYmV0d2VlbiBkYXRhIHN0b3Jlcy4NCj4+VGhpcyBpcyBob3cgdGhlIHJ1 bm5pbmcgY29uZmlnIGlzIGNyZWF0ZWQNCj4+DQo+PihjZmcgQSB8fCBjZmcgZXBoKSA9IGNmZyBy dW5uaW5nDQo+Pg0KPj5CYXNlIGNvbmZpZyBhbmQgZXBoZW1lcmFsIGNvbmZpZyBhcmUgb3Zlcmxh aWQsIGVwaGVtZXJhbCBpcyBzZWUgdGhyb3VnaA0KPj50byB0aGUgYmFzZSBjb25maWcsIGJ1dCBk ZXZpY2UgY2FuIGZ1bmN0aW9uIGNvcnJlY3RseSBieSByZWFkaW5nIG1vc3QNCj4+b2YgdGhlIGNv bmZpZyBmcm9tIGVwaGVtZXJhbCBkYXRhIHN0b3JlIHRvIGNlcnRhaW4gZXh0ZW50Lg0KPj4NCj4+ RGVhbg0KPj4NCj4+T24gU2VwIDI5LCAyMDE0LCBhdCA1OjQ0IFBNLCBKZWZmcmV5IEhhYXMgPGpo YWFzQHBmcmMub3JnPiB3cm90ZToNCj4+DQo+Pj4gT24gTW9uLCBTZXAgMjksIDIwMTQgYXQgMDk6 NDE6MDlQTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4+PiBJIHdvdWxkIGhv cGUgdGhhdCB3ZSBoYXZlIGEgc2luZ2xlIG1vZGVsIGZvciBORVRDT05GIGFuZCBJMlJTIG9yIGF0 DQo+Pj4+bGVhc3QgYSBjb3JlIE9TUEYgbW9kZWwgdGhhdCBjb250YWlucyB0aGUgbGFyZ2UgaW50 ZXJzZWN0aW9uLg0KPj4+IA0KPj4+IFRoYXQncyB3aHkgb3B0aW9uIDQgd2FzIHN1Z2dlc3RlZC4g IEdpdmVuIHRoYXQgeW91IG5vdyBoYXZlIGEgYm9keSBvZg0KPj4+d29yayAgcmVwcmVzZW50aW5n IGNvbmZpZyBmb3IgT1NQRiBhbmQga25vd2luZyB0aGF0IEkyUlMgbWF5IHdhbnQgdG8NCj4+PmFk ZCBzdGF0ZSAgaW50byBpdCwgcGxlYXNlIHRha2UgYSBsb29rIHRoZSBvcHRpb24gNCBkaXNjdXNz aW9uIGFuZCBzZWUNCj4+PmlmIGl0J3MgYSBnb29kICBmaXQuDQo+Pj4gDQo+Pj4gQSByZW1pbmRl ciB0byB0aGUgd2lkZXIgV0c6ICJPcHRpb24gNCIgd2FzIHNpbXBseSB0aGUgbGluZSBvZg0KPj4+ ZGlzY3Vzc2lvbiAgZnJvbSB0aGUgbmV0bW9kIGludGVyaW0uICBBcyBzZWVuIGluIGl0cyB0aHJl YWQgaXQncw0KPj4+ZWl0aGVyIG5vdCBmdWxseSAgZXhwbGFpbmVkIHdlbGwgb3IgdGhlcmUncyBz dGlsbCBjb25mdXNpb24gYW1vbmcgdGhlDQo+Pj5pbnRlcmltIHBhcnRpY2lwYW50cyAgd2hhdCBp dCBhY3R1YWxseSBtZWFucy4gIEl0J3Mgbm90IHNldHRsZWQgdGhhdA0KPj4+dGhpcyBpcyB3aGF0 IHdlJ2xsIGJlIGRvaW5nLCAgYnV0IGl0IGlzIGN1cnJlbnRseSB0aGUgbWV0aG9kIHRoYXQgaGFz DQo+Pj5yZWNlaXZlZCB0aGUgbW9zdCBkaXNjdXNzaW9uLg0KPj4+IA0KPj4+IC0tIEplZmYNCj4+ PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IGkycnMgbWFpbGluZyBsaXN0DQo+Pj4gaTJyc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPj4NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmkycnMgbWFpbGluZyBsaXN0DQo+aTJy c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+aTJy cyBtYWlsaW5nIGxpc3QNCj5pMnJzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pMnJzDQoNCg== From nobody Tue Sep 30 06: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 5B9971A19EC for ; Tue, 30 Sep 2014 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8j5POpP0oWu for ; Tue, 30 Sep 2014 06:52:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF451A030B for ; Tue, 30 Sep 2014 06:52:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 357C5C4A2; Tue, 30 Sep 2014 09:52:52 -0400 (EDT) Date: Tue, 30 Sep 2014 09:52:52 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140930135252.GE25791@pfrc> References: <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> <20140929212720.GE24542@pfrc> <20140929214030.GB25791@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/nHvdbtWmLMkzwrqRN2NDsZ4Qlb4 Cc: Jeffrey Haas , Thomas Narten , "Acee Lindem \(acee\)" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 30 Sep 2014 13:52:54 -0000 On Mon, Sep 29, 2014 at 07:16:41PM -0400, Alia Atlas wrote: > > Yes, your chairs are behind on sending the recharter request from this > > discussion. > > It's ok - I've found other charters to go rewrite ;-) > This discussion (or rather the one about "option 4") and understanding > what differences would be, if any, for I2RS data models is very very > useful to have before touching the charter. My thoughts exactly. :-) -- Jeff From nobody Tue Sep 30 06:53: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 C0DDB1A030B for ; Tue, 30 Sep 2014 06:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 u1Y5TQGyZG-J for ; Tue, 30 Sep 2014 06:53:49 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F7B1A0362 for ; Tue, 30 Sep 2014 06:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36218; q=dns/txt; s=iport; t=1412085229; x=1413294829; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ONj+T2CJAzzAsih9KzUp8ilhLIB01irjNAg0khqOxTg=; b=hyJB7wEUDDqQ+AVpctnls+Eow7oXY+9HV3QIwN8oegyHnzzrII1Uv/UO fX8LMCdXgthvuZwX6Bfaw6KKpAeci5h8qSyn93g65cny0kZqY1K4vFMRx KEY6ORJ1yqxsQqvmMC8QShFs3nA2wjQaMghcDrldZsT7t3x4SXbKk/AgY o=; X-IronPort-AV: E=Sophos;i="5.04,626,1406592000"; d="scan'208,217";a="190310846" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 30 Sep 2014 13:53:46 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8UDrjjG010374; Tue, 30 Sep 2014 13:53:45 GMT Message-ID: <542AB5E9.3060401@cisco.com> Date: Tue, 30 Sep 2014 15:53:45 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alia Atlas , Thomas Narten References: <20140925180055.GB1239@pfrc> <3C001E8E-FB91-4E31-9258-9E376F46AD8E@juniper.net> <00b501cfda04$2b4db130$81e91390$@ndzh.com> <003201cfda92$1c49c230$54dd4690$@ndzh.com> <005401cfdaa0$b297d070$17c77150$@ndzh.com> <000c01cfdaa9$eab7b570$c0272050$@ndzh.com> <002e01cfdab2$2d1ef0b0$875cd210$@ndzh.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060703070804090302090703" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4_T4fRSBp4KM4t9aT8hBJnzmeLg Cc: Jeffrey Haas , "i2rs@ietf.org" , "Acee Lindem \(acee\)" , Susan Hares Subject: [i2rs] YANG models fast track (was: IETF 91 meeting requested - call for agenda; status reports?) 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, 30 Sep 2014 13:53:53 -0000 This is a multi-part message in MIME format. --------------060703070804090302090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Since my name has been mentioned multiple times, let me explain what I've been trying to do with the YANG modeling fast track. http://tools.ietf.org/html/draft-yeung-netmod-ospf-00 was created in in Oct 2013 (Then later http://tools.ietf.org/html/draft-yeung-netmod-ospf-01) It was on the agenda for the NETMOD IETF 88, Nov 2013. See http://www.ietf.org/proceedings/88/minutes/minutes-88-netmod Already at that time, there were discussions to align the OSPF and core routing YANG models (what became draft-ietf-netmod-routing-cfg-15 later). See the meeting minutes. This OSPF YANG model was discussed again during the NETMOD IETF 89 (http://www.ietf.org/proceedings/89/minutes/minutes-89-netmod). Read specifically this part of the meeting minutes: LL: It is not likely that this working group can do all data models. There is an OSPF module which is quite Cisco specific. I have one that is Bird specific. It is up to the vendors to work out a common model. Experience with the routing module tells us that the exposition to routing experts is much less here than in the routing area. Leave it to the domain experts to do their data models. We can help them but not do their work. The above, plus the following thoughts _at that point in time_, are exactly what triggered my action: - there is clear demand for YANG models in the industry, but we need to gain momentum. - the industry/vendors can't agree ("There is an OSPF module which is quite Cisco specific") - NETMOD is not the right place for all the YANG models, because we don't have the technology expertise. And the other WGs don't have the YANG expertise. - the IETF is an important point in its life, with more and more people going to open source to avoid the heavier consensus-based SDO such as the IETF, typically opendaylight producing a lot of proprietary YANG models - At that time, there were no interest to standardize YANG models in the routing WGs. From there, I tried to evaluate the willingness from vendors to work together. I made an experiment with 3 YANG models (syslog, OSPF, and ACL) and 3 companies (Brocade, Juniper, Cisco). See this as closed author teams if you want to. IMO, the experiment has been successful. See http://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ See http://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/ _What I regret_, and this was mentioned to the authors: there is no update of http://tools.ietf.org/html/draft-yeung-netmod-ospf-01, so it might be perceived as: the work was abandoned or not open. However, work was done to first review and improve the base routing model (Lada is point of contact here), and to try to come up with a consistent approach for routing (VRF versus protocol centric view) among vendors. At the last IETF, I've been open, and I explained those closed design teams: - to the routing ADs - to the IESG - during the ///YANG/ Advice and /Editing Session/ - to the NETMOD WG: See "Accelerated Development" in the meeting minutes (http://www.ietf.org/proceedings/90/minutes/minutes-90-netmod) See the slides: http://www.ietf.org/proceedings/90/slides/slides-90-netmod-5.pdf What next? (copied from slides 6 of the above presentation) Open up and scale up these design teams We will be soliciting the next set of YANG models The YANG editing session was a first step to list the existing YANG models Goal: Stretch goal to publish YANG model RFCs within a year Where? In the different WGs or in NETMOD (charter is now open) I'm exactly in that process of collecting the interesting YANG models the vendors want to work on. Why a focus on the vendors? Because I want to focus on the device-level, protocol-specific YANG models (the building blocks). Not the services ones. These days, I'm compiling the list of interesting YANG models from multiple vendors: Juniper, Brocade, Huawei, Ericsson, Ciena, ALU, and Cisco. More companies are obviously welcome. The findings will be shared, don't worry. From here, the different WGs (not speaking about routing specifically) should organize official design teams, organized by the WG chair. For example, to create the version 00 of the draft. Based on my experience from those closed design teams, what worked well, and should be followed IMO. - one point of contact per company to work on the draft (too many authors dilutes the responsibility - this point of contact should be close the development team - ideally, these should different people for the different YANG models (we want this process to scale) - weekly webex proved to work efficiently - a willingness to implement (we learn a lot from implementation) Is this NETMOD taking over the world of YANG models standardization? Certainly not. My goal is to get the right experts together. Coming back to the OSPF model, the experts are not NETMOD expert: Kent Leung, Dean Bogdanovic, Kiran Koushik. As you can see, these are not the tyipcal YANG experts in the NETMOD WG. Also, In order to facilitate their work, I have assign a YANG doctor. See http://www.ietf.org/iesg/directorate/yang-doctors.html -> YANG review assignments Where should these YANG models be standardized? Honestly, I don't care, as long as we right the right experts. Ideally they should be standardized in the respective WGs. Note that the NETMOD charter has been open to welcome the YANG models that don't have an appropriate home (example: syslog) As you can see, no willingness to hide anything with this fast-track, simply an OPS AD who humbly tries to organize an industry/vendors/a community to work together. I have not coordinated enough I2RS (and I don't follow the I2RS mailing list, it's just archived in a folder but recently I had to read it :-) ), that's probably a mistake. On the other hand, from what I can see from the different vendors, there is a willingness to implement non I2RS/routing YANG models: QoS, VLAN, AAA. So why warn only the I2RS WG on the not the rest of the community? Btw, I believe that creating this mailing list for routing YANG models coordination would be a plus. Regards, Benoit (OPS AD) > Thomas, > > On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten > wrote: > > > It is NOT OK to tell anyone that they should not contribute a draft - because > > it may muddy the water > > or for ANY other non-technical reason. Individual drafts or > desire to request > > WG adoption do not change > > this. I do not ever want to see or hear something like this on > an IETF > > mailing list. > > Let me defend Acee here a bit and try to chart a course a bit more > down the middle. When a WG has an effort underway that is intended to > lead to a WG document (and that is what I read the current "design > team" effort to be), it is IMO often not helpful to have yet more IDs > submitted on the same topic. Rather than complementing the existing > work towards a concensus result, additional IDs can be a distraction > and require folk to spend time figuring out how the other ID relates > to the WG effort. I.e., it's much more constuctive to say "here is > what is defficient in the current model, and here is what I think we > should do instead". It is much less constructive to have a standalone > ID that (probably) overlaps with the other IDs and doesn't focus on > the *differences* from the other work that already has a head start. > > > First, I have been encouraging the routing WGs to work on and consider > YANG models. > I have been quite clear in discussing with Benoit that they should be > homed in the Routing > area and that I don't think it makes sense to create a separate > working group to just work > on YANG models. > > Second, the assumption that we have had with I2RS is that it will need > different and possibly > more limited models than would be used for configuration of a > particular protocol. A reasonable > approach could be doing the I2RS-specific models in I2RS and having > them cross-reviewed in > the relevant protocol working-groups. This is the path that, as I > understand it, Sue was working on. > It would allow review of the interactions between the different models > for their I2RS aspects (assuming > that the WG believes that there are some). > > Third, individuals have been working an individual draft > (draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model. > This was discussed in OSPF last IETF. I agree that the updated draft, > when posted, is likely to be an excellent candidate for the OSPF WG. > > However, regardless of whom may be working on writing > draft-yeung-netmod-ospf-01 or who may have been going behind the > scenes pushing and encouraging (and I am also quite happy and eager > and encouraging to see good YANG models for routing functionality), > this is not an official design team > effort. > > Deliberately writing a competing draft may not be constructive. That > is not what happened here and > it was the combination of trying to incorrectly privilege an (expired) > individual draft that was written to solve a different problem and > asking for someone who had done work to produce a draft towards a > different problem that caused me to be extremely displeased. > > I realize that one of the topics of discussion since the netmod > interim has been whether it makes sense to have one YANG model that > can be used by NetConf and I2RS for writing and reading. However, I > have not heard discussed much less agreed upon that approach in I2RS > and it is inappropriate to presuppose the answer and punt work that it > is quite reasonable to assume (and examine to determine) will move the > WG forward. > > It is the case that the IETF mantra is "submit a draft", but frankly, > I think that is a bit of a sound bite that we would do well to not > spit out as often as we seem to because it too often misses what > really should happen, namely, how best to contribute to reaching > consensus in a WG. We have a huge problem today where there are > overlapping/competing drafts that WGs have to sort through. And in > many of those cases, additional IDs have very little additional > content than what already exists. But since we go around telling folk > to "submit an ID", we shouldn't be surprise that we get them beyond > the point of diminishing returns. (And I am NOT saying that the draft > at issue here is one of those.) > > > Please let's not try to conflate one specific case with its own > concerns with > generalities. That is not constructive. > > In this case (and I personally don't have any skin in the game), it > seems to that both parties are making honest efforts to do the right > thing, but unfortunately, the state of play was not fully known to > all. > > > Yes, this is communication and clear communication is needed. > > > Very very few drafts start perfect and different models have > > different perspectives. The IETF has a consensus process, as you > > well know of course, to resolve differences between perspectives and > > drafts. > > I didn't hear anyone say that consensus has already been called. My > take away is that we have a WG making an honest effort to move forward > in a particular direction and it is doing exactly what it should be in > terms of getting behind a design team effort. And IMO, once you have a > WG design team working on an effort, having others submit drafts in > the same space is not always what we should be encouraging people to > do. > > > There IS NOT a WG Design Team in OSPF working on the YANG model. There > are individuals, whom were encouraged to work together, but that does > not make it > a design team. IFF there were an announced WG Design Team and IFF > there were > consensus in I2RS that I2RS would use exactly the same YANG models, > then this > point might hold water. Since neither are the case, I do not believe > that it does so. > > Does that mean we should not allow additional IDs? Of course not. Does > it mean we won't look at them and give them consideration"? Of course > not. But we should also be honest that if a WG has an official > document or has a DT working on a document, having additional > "competing" documents show up is often not the most constructive way > to contribute. Unless news IDs really are clear about how they relate > to the other efforts and what those other efforts are lacking. > > > Yes - and official WG design teams are different from a group of > individuals. To be > extremely clear yet again, this is a group of individuals. > > Regards, > Alia > > Thomas > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --------------060703070804090302090703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Since my name has been mentioned multiple times, let me explain what I've been trying to do with the YANG modeling fast track.

http://tools.ietf.org/html/draft-yeung-netmod-ospf-00 was created in in Oct 2013 (Then later http://tools.ietf.org/html/draft-yeung-netmod-ospf-01)
It was on the agenda for the NETMOD IETF 88, Nov 2013. See http://www.ietf.org/proceedings/88/minutes/minutes-88-netmod
Already at that time, there were discussions to align the OSPF and core routing YANG models (what became draft-ietf-netmod-routing-cfg-15 later). See the meeting minutes.
This OSPF YANG model was discussed again during the NETMOD IETF 89 (http://www.ietf.org/proceedings/89/minutes/minutes-89-netmod).
Read specifically this part of the meeting minutes:
LL: It is not likely that this working group can do all data models.
      There is an OSPF module which is quite Cisco specific. I have
      one that is Bird specific. It is up to the vendors to work out a
      common model. Experience with the routing module tells us that
      the exposition to routing experts is much less here than in the
      routing area. Leave it to the domain experts to do their data
      models. We can help them but not do their work.
The above, plus the following thoughts at that point in time, are exactly what triggered my action:
    - there is clear demand for YANG models in the industry, but we need to gain momentum.
    - the industry/vendors can't agree ("There is an OSPF module which is quite Cisco specific")
    - NETMOD is not the right place for all the YANG models, because we don't have the technology expertise. And the other WGs don't have the YANG expertise.
    - the IETF is an important point in its life, with more and more people going to open source to avoid the heavier consensus-based SDO such as the IETF,
      typically opendaylight producing a lot of proprietary YANG models
   - At that time, there were no interest to standardize YANG models in the routing WGs.

From there, I tried to evaluate the willingness from vendors to work together. I made an experiment with 3 YANG models (syslog, OSPF, and ACL) and 3 companies (Brocade, Juniper, Cisco). See this as closed author teams if you want to. IMO, the experiment has been successful.
See http://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/
See http://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/
What I regret, and this was mentioned to the authors: there is no update of http://tools.ietf.org/html/draft-yeung-netmod-ospf-01, so it might be perceived as: the work was abandoned or not open. However, work was done to first review and improve the base routing model (Lada is point of contact here), and to try to come up with a consistent approach for routing (VRF versus protocol centric view) among vendors.

At the last IETF, I've been open, and I explained those closed design teams:
    - to the routing ADs
    - to the IESG
    - during the YANG Advice and Editing Session
    - to the NETMOD WG:
            See "Accelerated  Development" in the meeting minutes (http://www.ietf.org/proceedings/90/minutes/minutes-90-netmod)
            See the slides: http://www.ietf.org/proceedings/90/slides/slides-90-netmod-5.pdf

What next? (copied from slides 6 of the above presentation)
    Open up and scale up these design teams
    We will be soliciting the next set of YANG models
    The YANG editing session was a first step to list the existing YANG models
    Goal: Stretch goal to publish YANG model RFCs within a year
    Where? In the different WGs or in NETMOD (charter is now open)

I'm exactly in that process of collecting the interesting YANG models the vendors want to work on.
Why a focus on the vendors? Because I want to focus on the device-level, protocol-specific YANG models (the building blocks). Not the services ones.
These days, I'm compiling the list of interesting YANG models from multiple vendors: Juniper, Brocade, Huawei, Ericsson, Ciena, ALU, and Cisco. More companies are obviously welcome. The findings will be shared, don't worry.
From here, the different WGs (not speaking about routing specifically) should organize official design teams, organized by the WG chair. For example, to create the version 00 of the draft. Based on my experience from those closed design teams, what worked well, and should be followed IMO.
    - one point of contact per company to work on the draft (too many authors dilutes the responsibility
    - this point of contact should be close the development team
    - ideally, these should different people for the different YANG models (we want this process to scale)
    - weekly webex proved to work efficiently
    - a willingness to implement (we learn a lot from implementation)

Is this NETMOD taking over the world of YANG models standardization?
Certainly not. My goal is to get the right experts together.
Coming back to the OSPF model, the experts are not NETMOD expert: Kent Leung, Dean Bogdanovic, Kiran Koushik. As you can see, these are not the tyipcal YANG experts in the NETMOD WG.
Also, In order to facilitate their work, I have assign a YANG doctor. See http://www.ietf.org/iesg/directorate/yang-doctors.html -> YANG review assignments
Where should these YANG models be standardized? Honestly, I don't care, as long as we right the right experts. Ideally they should be standardized in the respective WGs. Note that the NETMOD charter has been open to welcome the YANG models that don't have an appropriate home (example: syslog)

As you can see, no willingness to hide anything with this fast-track, simply an OPS AD who humbly tries to organize an industry/vendors/a community to work together. I have not coordinated enough I2RS (and I don't follow the I2RS mailing list, it's just archived in a folder but recently I had to read it :-) ), that's probably a mistake. On the other hand, from what I can see from the different vendors, there is a willingness to implement non I2RS/routing YANG models: QoS,  VLAN, AAA. So why warn only the I2RS WG on the not the rest of the community?
Btw, I believe that creating this mailing list for routing YANG models coordination would be a plus.

Regards, Benoit (OPS AD)


Thomas,

On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten <narten@us.ibm.com> wrote:
> It is NOT OK to tell anyone that they should not contribute a draft - because
> it may muddy the water
> or for ANY other non-technical reason.  Individual drafts or desire to request
> WG adoption do not change
> this.  I do not ever want to see or hear something like this on an IETF
> mailing list.

Let me defend Acee here a bit and try to chart a course a bit more
down the middle. When a WG has an effort underway that is intended to
lead to a WG document (and that is what I read the current "design
team" effort to be), it is IMO often not helpful to have yet more IDs
submitted on the same topic. Rather than complementing the existing
work towards a concensus result, additional IDs can be a distraction
and require folk to spend time figuring out how the other ID relates
to the WG effort. I.e., it's much more constuctive to say "here is
what is defficient in the current model, and here is what I think we
should do instead". It is much less constructive to have a standalone
ID that (probably) overlaps with the other IDs and doesn't focus on
the *differences* from the other work that already has a head start.

First, I have been encouraging the routing WGs to work on and consider YANG models.
I have been quite clear in discussing with Benoit that they should be homed in the Routing
area and that I don't think it makes sense to create a separate working group to just work
on YANG models.

Second, the assumption that we have had with I2RS is that it will need different and possibly
more limited models than would be used for configuration of a particular protocol.  A reasonable
approach could be doing the I2RS-specific models in I2RS and having them cross-reviewed in
the relevant protocol working-groups.  This is the path that, as I understand it, Sue was working on.
It would allow review of the interactions between the different models for their I2RS aspects (assuming
that the WG believes that there are some).

Third, individuals have been working an individual draft (draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model.  This was discussed in OSPF last IETF.  I agree that the updated draft, when posted, is likely to be an excellent candidate for the OSPF WG.

However, regardless of whom may be working on writing draft-yeung-netmod-ospf-01 or who may have been going behind the scenes pushing and encouraging (and I am also quite happy and eager and encouraging to see good YANG models for routing functionality), this is not an official design team
effort. 

Deliberately writing a competing draft may not be constructive.  That is not what happened here and
it was the combination of trying to incorrectly privilege an (expired) individual draft that was written to solve a different problem and asking for someone  who had done work to produce a draft towards a different problem that caused me to be extremely displeased.

 I realize that one of the topics of discussion since the netmod interim has been whether it makes sense to have one YANG model that can be used by NetConf and I2RS for writing and reading.  However, I have not heard discussed much less agreed upon that approach in I2RS and it is inappropriate to presuppose the answer and punt work that it is quite reasonable to assume (and examine to determine) will move the WG forward.
 
It is the case that the IETF mantra is "submit a draft", but frankly,
I think that is a bit of a sound bite that we would do well to not
spit out as often as we seem to because it too often misses what
really should happen, namely, how best to contribute to reaching
consensus in a WG. We have a huge problem today where there are
overlapping/competing drafts that WGs have to sort through. And in
many of those cases, additional IDs have very little additional
content than what already exists. But since we go around telling folk
to "submit an ID", we shouldn't be surprise that we get them beyond
the point of diminishing returns. (And I am NOT saying that the draft
at issue here is one of those.)

Please let's not try to conflate one specific case with its own concerns with
generalities.  That is not constructive. 
 
In this case (and I personally don't have any skin in the game), it
seems to that both parties are making honest efforts to do the right
thing, but unfortunately, the state of play was not fully known to all.

Yes, this is communication and clear communication is needed. 

 
> Very very few drafts start perfect and different models have
> different perspectives.  The IETF has a consensus process, as you
> well know of course, to resolve differences between perspectives and
> drafts.

I didn't hear anyone say that consensus has already been called.  My
take away is that we have a WG making an honest effort to move forward
in a particular direction and it is doing exactly what it should be in
terms of getting behind a design team effort. And IMO, once you have a
WG design team working on an effort, having others submit drafts in
the same space is not always what we should be encouraging people to
do.

There IS NOT a WG Design Team in OSPF working on the YANG model.  There
are individuals, whom were encouraged to work together, but that does not make it
a design team.  IFF there were an announced WG Design Team and IFF there were
consensus in I2RS that I2RS would use exactly the same YANG models, then this
point might hold water.   Since neither are the case, I do not believe that it does so. 

 
Does that mean we should not allow additional IDs? Of course not. Does
it mean we won't look at them and give them consideration"? Of course
not. But we should also be honest that if a WG has an official
document or has a DT working on a document, having additional
"competing" documents show up is often not the most constructive way
to contribute. Unless news IDs really are clear about how they relate
to the other efforts and what those other efforts are lacking.

Yes - and official WG design teams are different from a group of individuals.  To be
extremely clear yet again, this is a group of individuals. 

Regards,
Alia 

Thomas




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

--------------060703070804090302090703-- From nobody Tue Sep 30 12: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 6E73E1A87AF for ; Tue, 30 Sep 2014 12:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atFMNFklz1r6 for ; Tue, 30 Sep 2014 12:23:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 960EB1A8790 for ; Tue, 30 Sep 2014 12:23:13 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id 0F63D28A934C; Tue, 30 Sep 2014 15:23:11 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_66BF834E-CAF5-4945-B7A1-3222255493E2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <5423EC4B.7080209@joelhalpern.com> Date: Tue, 30 Sep 2014 12:23:10 -0700 Message-Id: <2DAF104A-9F4C-4FF7-84FA-B97BA4919818@lucidvision.com> References: <20140924153051.GB2639@pfrc> <5423EC4B.7080209@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5LQjQHIiwCM5F0UkaCMJo300m_k Cc: Jeffrey Haas , "i2rs@ietf.org" , Andy Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 19:23:15 -0000 --Apple-Mail=_66BF834E-CAF5-4945-B7A1-3222255493E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:6:19 AM, at 6:19 AM, Joel M. Halpern = wrote: > Top posting for ease of reading, but retaining the content for those = who want context. >=20 > As I understand the shadow proposal, there is the regular local config = data store, and then there is a second data store (shadow) used by I2RS = for its ephemeral data. That store is never persisted. So far, so = good. >=20 > Then Andy asked about when they are synchronized, and suggested that = they would be sychronized only when the shadow datastore is established = by teh first I2RS modification request (if I understood him correctly). >=20 > I don't think that works. Suppose that I2RS has adjusted data items A = and B, creating and filling the shadow data store. And then someone = using CLI / normal NetCONF adjusts item C. If an I2RS client goes to = read C, or does some operation which depends upon the value of C, it has = to be working with the new value of C, not the value at the time the = ephemeral store was created. It might be useful to define the operational semantics of what = the shadow data store is. In my opinion, its modifying a version of the = running config of the device.=20 >=20 > Yours, > Joel >=20 > On 9/24/14, 11:47 AM, Andy Bierman wrote: >>=20 >>=20 >> On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas > > wrote: >>=20 >> In the proposed overlay model, presume that we have ephemeral data >> from a >> model that lives within an augmentation to a local config model. = In >> other >> words, the ephemeral nodes are children of the local config nodes. >>=20 >> Presume, per discussion, that the local config lives in the = "config" >> data >> store and that the ephemeral config - the augmenting nodes above - >> live in >> the ephemeral data store. >>=20 >> If we delete the container in the local config that the epehemeral >> config is >> augmenting, is there any expectation that such a deletion should = carry >> through to the ephemeral config? >>=20 >> Per the netmod interim discussion, probably not. It's in a = separate >> datastore. But it does lead to integrity issues since we now have >> orphaned >> state. In this particular example, permitting the deletion to = carry >> through >> to the ephemeral datastore at least provides one additional level = of >> consistency. >>=20 >>=20 >> I think the concept of "shadowing the local config" makes this = behavior >> confusing. >> If the ephemeral datastore instances remains after the config = datastore >> instances are deleted, how is that really shadowing? >>=20 >> IMO, shadowing only occurs when the ephemeral datastore is edited. >> It is used as a snapshot to reduce the I2RS payload size (shadow = patch?. >> But the data that gets created in the ephemeral datastore is complete = and >> self-contained. The actual data structures are implementation = details. >> Maybe the local config is cloned, maybe it is shadowed. >>=20 >> ----- >>=20 >> My second thought is would we ever want to provide filtering in = the >> conditional checks (must/when) in the ephemeral datastore based on = the >> underlying source of the data? Since local config would be = shadowed >> into >> the ephemeral datastore, do we want the ability to match on the >> source of >> the node set under evaluation? >>=20 >>=20 >> Each datastore should only validated against itself, or else the >> XPath implementation would be even more complicated. If the = ephemeral >> datastore >> is supposed to be fast (I remember 5000 updates a second from the = BoF) >> then running validation tests across multiple datastores constantly = will >> not help. >>=20 >> Or do you mean flag a must/when as "do-not-use" in the ephemeral = datastore? >> If that were possible it would help speed up the server. >>=20 >>=20 >>=20 >> -- Jeff >>=20 >>=20 >> Andy >>=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 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_66BF834E-CAF5-4945-B7A1-3222255493E2 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 iQIcBAEBCgAGBQJUKwMeAAoJEPcO+I7eiUJZE9kP/jeDtKIGgi/o8e4W0fn+GJO+ uj6uczf8yQdeFoo1Wi4GI09xMFaMFVIdkVMkbUaJwYZeoL6SgYsCZRNfxVhCU2eF q28d5OeVHKm9mc1n94z9es27++FKOfRum75nzN3s1ydYeoPp9G/FcxdPXrmz83LU fG+kTUk6mLrzLvleVeQXddXHN2Ui/jfhQV+7TK07tb16jDol9I7i4rU5NJpqTkKU rBoxYgM4dgyct9/2YWtEVkMLqc96QJIHlGQDxgBeHj1i2ydOZyj25Zba+tsz2ur2 BPkjElf5e1lMk5rQ+JKuenX2T3QIEJOVYgyyN0tlVxgfE4QUO/nXL4bmxiF2lEUg ORioxC0+La/PpGcC7f3JZpsD3opcuNz0wr/CDpBOse29ilGmvrgq7d4m6D5H/lJg 3llvQKndUPC1V8/gIoA6PZvRFOn/vmG4V3T6woRAFjxKxwp51t3VRObGjTwsfcVF B1Ix+Ea5Qnrtrak8J4jWM7RDwxyavD8DYT8HYQtJvRBgRixqVZA1MsLXWlG1g34H bcG2/yDmIBU6tRUCy5f1p7jxy7GKvI3LRc5baWB70IZxWbUFIB/lL7L3qqpIOAD5 4pWxCpG7ZMpKF/3qXdHiKZFTbw4TA6+8privpIeVBKODA8zOihQpMxXl8dR2kFVO tlb+Ft0OqDqpe+MWWRN0 =Aca0 -----END PGP SIGNATURE----- --Apple-Mail=_66BF834E-CAF5-4945-B7A1-3222255493E2-- From nobody Tue Sep 30 13:55: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 BEDB51A8A47 for ; Tue, 30 Sep 2014 13:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 rDHIOJYJ1Tmo for ; Tue, 30 Sep 2014 13:55:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332691A8A39 for ; Tue, 30 Sep 2014 13:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1721; q=dns/txt; s=iport; t=1412110529; x=1413320129; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Q/V3bZ7LB+iC+qqj1bR5Ty1pZ5CRTB3NFoqw8Cd6KIw=; b=CFZN7tCjYNCGA8tJTswztZSCgnLEfnwfPaHVwfe0+Cfd/PlVnXVPTOmL Q+i25Vw7Q04x/bNOZVCczB6kPUKz054XiacrFAj7MGS2Q5FoBA3WtD2u1 aTHtKBihBlwOxpOipxYlvTMPMppMgINF+VWwqltkJuxJVeB2zpXbpvgNv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFADQYK1StJV2Z/2dsb2JhbABggw5TV8oiCodNAoEPFgF7hAMBAQEDAQEBARobNgoNBAsOAwQBAQEJFggHCQMCAQIBFR8JCAYBDAYCAQGIMggNvkgBEwSMS4JxEQFXBoRFAQSdL4dYjhiDfyEvgQ+BOwEBAQ X-IronPort-AV: E=Sophos;i="5.04,629,1406592000"; d="scan'208";a="359622107" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 30 Sep 2014 20:55:29 +0000 Received: from [10.19.102.119] (sjc-julhunte-8816.cisco.com [10.19.102.119]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8UKtRX8015558; Tue, 30 Sep 2014 20:55:28 GMT Message-ID: <542B18BF.9030408@cisco.com> Date: Tue, 30 Sep 2014 16:55:27 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Susan Hares , "'Jeffrey Haas'" , i2rs@ietf.org References: <20140925180055.GB1239@pfrc> <5429AB19.4050406@cisco.com> <00f901cfdc47$174e4d30$45eae790$@ndzh.com> In-Reply-To: <00f901cfdc47$174e4d30$45eae790$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1kw9_GEQbzSmZ3Ih8wD8AD0tA_w Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 30 Sep 2014 20:55:30 -0000 On 9/29/14 8:40 PM, Susan Hares wrote: > Joe: > > By shoe dropping - I think you mean accepted of the traceability as WG > draft. Yes, that is correct. We had a few signs of support, and Carlos sent an email out copying the chairs explicitly, but we have not heard anything back. Joe > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke > Sent: Monday, September 29, 2014 2:55 PM > To: Jeffrey Haas; i2rs@ietf.org > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > On 9/25/14 2:00 PM, Jeffrey Haas wrote: >> Your chairs have been a bit over-busy recently with travel to unicast >> people doing various bits of chartered work. This means we've been >> behind on some of our goals in terms of getting regular design >> sessions running. I know that at least a couple calls have happened >> that I've missed that Sue Hares has done, so some progress is being made. >> >> We've requested a 1 hour time slot for IETF 91 in Honolulu to give us >> a chance to talk. This is a call for agenda slots. >> >> This is also a call for status reports. >> >> We've had some productive discussion about requests to netmod/netconf, >> albeit ones that haven't converged yet. >> >> What have you been up to? > > I think the list knows about the traceability "shoe" that's been waiting to > drop. Question is, can it be settled on the list, should we ask in > Honolulu? Does it need an agenda item or can the chairs raise the point? > Thanks. > > Joe > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Sep 30 13:55: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 BAF981A8A57 for ; Tue, 30 Sep 2014 13:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwfSn4Ibb5sq for ; Tue, 30 Sep 2014 13:55:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CDA831A8A39 for ; Tue, 30 Sep 2014 13:55:33 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 64462C4A2; Tue, 30 Sep 2014 16:55:33 -0400 (EDT) Date: Tue, 30 Sep 2014 16:55:33 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140930205533.GB8728@pfrc> References: <20140924153051.GB2639@pfrc> <5423EC4B.7080209@joelhalpern.com> <2DAF104A-9F4C-4FF7-84FA-B97BA4919818@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DAF104A-9F4C-4FF7-84FA-B97BA4919818@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/-9Vh1b-xZ3bDHGr0eQr4IhLYMj0 Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 20:55:44 -0000 Tom, On Tue, Sep 30, 2014 at 12:23:10PM -0700, Thomas D. Nadeau wrote: > On Sep 25, 2014:6:19 AM, at 6:19 AM, Joel M. Halpern wrote: > > Top posting for ease of reading, but retaining the content for those who want context. > > > > As I understand the shadow proposal, there is the regular local config data store, and then there is a second data store (shadow) used by I2RS for its ephemeral data. That store is never persisted. So far, so good. > > > > Then Andy asked about when they are synchronized, and suggested that they would be sychronized only when the shadow datastore is established by teh first I2RS modification request (if I understood him correctly). > > > > I don't think that works. Suppose that I2RS has adjusted data items A and B, creating and filling the shadow data store. And then someone using CLI / normal NetCONF adjusts item C. If an I2RS client goes to read C, or does some operation which depends upon the value of C, it has to be working with the new value of C, not the value at the time the ephemeral store was created. > > It might be useful to define the operational semantics of what the shadow data store is. In my opinion, its modifying a version of the running config of the device. During the interim, the phrase I was using was "active" config. Effectively when both local config and ephemeral config are both functioning without issues, logically: Without ephemeral datastore: Active = Running With ephemeral datastore: Active = Running + Ephemeral. (I.e. patch running < ephemeral) The question about whether we have "pull-up/snapshot" of local config on top of ephemeral or simply "overlay/see-through" is mostly an implementation detail to cover what happens when there's problems. ----- Overlay: Active = patch running < ephemeral Ephemeral crashes: Active = running (should still be in tact) Instead, running goes away Active = patch NULL < ephemeral This may lead you to an invalid config. ----- Snapshot: Active = cp running ephemeral.candidate ; patch ephemeral.candidate < ephemeral; mv ephemeral.candidate ephemeral. Ephemeral crashes: Running config remains. Instead, running goes away: Ephemeral = last state of ephemeral, potentially with future changes laid on top. In other words, in the snapshot implementation, if you lose local config, you have the last in tact state of running copied in ephemeral. You still must track the individual ephemeral-only changes to lay on top of it. > > > > > Yours, > > Joel > > > > On 9/24/14, 11:47 AM, Andy Bierman wrote: > >> > >> > >> On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas >> > wrote: > >> > >> In the proposed overlay model, presume that we have ephemeral data > >> from a > >> model that lives within an augmentation to a local config model. In > >> other > >> words, the ephemeral nodes are children of the local config nodes. > >> > >> Presume, per discussion, that the local config lives in the "config" > >> data > >> store and that the ephemeral config - the augmenting nodes above - > >> live in > >> the ephemeral data store. > >> > >> If we delete the container in the local config that the epehemeral > >> config is > >> augmenting, is there any expectation that such a deletion should carry > >> through to the ephemeral config? > >> > >> Per the netmod interim discussion, probably not. It's in a separate > >> datastore. But it does lead to integrity issues since we now have > >> orphaned > >> state. In this particular example, permitting the deletion to carry > >> through > >> to the ephemeral datastore at least provides one additional level of > >> consistency. > >> > >> > >> I think the concept of "shadowing the local config" makes this behavior > >> confusing. > >> If the ephemeral datastore instances remains after the config datastore > >> instances are deleted, how is that really shadowing? > >> > >> IMO, shadowing only occurs when the ephemeral datastore is edited. > >> It is used as a snapshot to reduce the I2RS payload size (shadow patch?. > >> But the data that gets created in the ephemeral datastore is complete and > >> self-contained. The actual data structures are implementation details. > >> Maybe the local config is cloned, maybe it is shadowed. > >> > >> ----- > >> > >> My second thought is would we ever want to provide filtering in the > >> conditional checks (must/when) in the ephemeral datastore based on the > >> underlying source of the data? Since local config would be shadowed > >> into > >> the ephemeral datastore, do we want the ability to match on the > >> source of > >> the node set under evaluation? > >> > >> > >> Each datastore should only validated against itself, or else the > >> XPath implementation would be even more complicated. If the ephemeral > >> datastore > >> is supposed to be fast (I remember 5000 updates a second from the BoF) > >> then running validation tests across multiple datastores constantly will > >> not help. > >> > >> Or do you mean flag a must/when as "do-not-use" in the ephemeral datastore? > >> If that were possible it would help speed up the server. > >> > >> > >> > >> -- 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 > >> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > From nobody Tue Sep 30 13:58: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 7AA8E1A8AAB for ; Tue, 30 Sep 2014 13:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 3_AQwBZdq56F for ; Tue, 30 Sep 2014 13:58:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7875E1A8A8A for ; Tue, 30 Sep 2014 13:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2527; q=dns/txt; s=iport; t=1412110719; x=1413320319; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NDKCw0K233vQsfKNUUChHCJtGLCkf0bth2/tvqSgPXw=; b=SmIb8JhlxVjMbRH3DLSzDoLyNg5tSENXIQUni7uVwDro4oDjCUqTkm8i 7RPIaWNmXTurBs7yoyQrtoWr5d5zlxN6+b4p0h7dmU9bzF0cx4JkMJB4m TjsnOSUFKGNEzy9F6BKfKBWpt4HVEy6ospt58cI4eHE1tB8p5h8XrsnwY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAOkYK1StJA2L/2dsb2JhbABggw7TIwKBDxYBe4QEAQEEHRs8BAEQCw4EBgkWDwkDAgECATcOBg0BBwEBiDq+VQEXjEuDUweESwEEnS+HWI4Yg38hgnkBAQE X-IronPort-AV: E=Sophos;i="5.04,629,1406592000"; d="scan'208";a="359403251" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 30 Sep 2014 20:58:38 +0000 Received: from [10.19.102.119] (sjc-julhunte-8816.cisco.com [10.19.102.119]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8UKwcFZ013762; Tue, 30 Sep 2014 20:58:38 GMT Message-ID: <542B197E.6080403@cisco.com> Date: Tue, 30 Sep 2014 16:58:38 -0400 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Jeffrey Haas References: <20140925180055.GB1239@pfrc> <5429AB19.4050406@cisco.com> <20140929212519.GD24542@pfrc> In-Reply-To: <20140929212519.GD24542@pfrc> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4DaOOv8YfkGyvY6u2u6y01eG16w Cc: i2rs@ietf.org Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports? 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, 30 Sep 2014 20:58:42 -0000 On 9/29/14 5:25 PM, Jeffrey Haas wrote: > On Mon, Sep 29, 2014 at 02:55:21PM -0400, Joe Clarke wrote: >> On 9/25/14 2:00 PM, Jeffrey Haas wrote: >>> Your chairs have been a bit over-busy recently with travel to unicast people >>> doing various bits of chartered work. This means we've been behind on some >>> of our goals in terms of getting regular design sessions running. I know >>> that at least a couple calls have happened that I've missed that Sue Hares >>> has done, so some progress is being made. >>> >>> We've requested a 1 hour time slot for IETF 91 in Honolulu to give us a >>> chance to talk. This is a call for agenda slots. >>> >>> This is also a call for status reports. >>> >>> We've had some productive discussion about requests to netmod/netconf, >>> albeit ones that haven't converged yet. >>> >>> What have you been up to? >> >> I think the list knows about the traceability "shoe" that's been >> waiting to drop. Question is, can it be settled on the list, should >> we ask in Honolulu? Does it need an agenda item or can the chairs >> raise the point? Thanks. > > This chair admits he's been a slacker even though oversubscribed. > > One of the reasons why this has been left to linger slightly is the detail > that we've left the architecture document unpublished as an RFC to permit > some time to reconcile the ephemeral datastore question. The answer to that > question may have impact on the architecture. Aside from that, the document > is past WGLC and was ready to be submitted for publication. > > Since the architecture draft is still open, do you believe that the traceability > draft should be incorporated into the architecture document or left > separately? > > This question obviously is for the WG to answer. Once we have that answer, > we'll either look for the edits to the architecture or simply do an adoption > call. We saw good support for the idea that traceability is something we > should have. We (the authors) believe this is a separate document based on the previous comments. Aside from the open questions concerning the ephemeral data stores, we still feel the architecture draft is well-baked and sets the stage nicely for this additional document. However, as you point out, this is a question for the WG to answer. But, should we ask it in Honolulu via an agenda item, or is this something the chairs will ask in a general agenda section (as was kind of done in Toronto)? Joe > > > -- Jeff > From nobody Tue Sep 30 14:00: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 E74A11A8A7D for ; Tue, 30 Sep 2014 13:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5j6Pfr_EC_z for ; Tue, 30 Sep 2014 13:59:50 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4005F1A8FD7 for ; Tue, 30 Sep 2014 13:59:23 -0700 (PDT) Received: from [10.110.1.6] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id B4AE928A95F0; Tue, 30 Sep 2014 16:59:20 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_509C0457-1A57-4DC6-AFE9-9DE254D02BCD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140930205533.GB8728@pfrc> Date: Tue, 30 Sep 2014 13:59:16 -0700 Message-Id: References: <20140924153051.GB2639@pfrc> <5423EC4B.7080209@joelhalpern.com> <2DAF104A-9F4C-4FF7-84FA-B97BA4919818@lucidvision.com> <20140930205533.GB8728@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dEw4xoO3Ez5VV0EuQnUnKzDm3vc Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 20:59:53 -0000 --Apple-Mail=_509C0457-1A57-4DC6-AFE9-9DE254D02BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 30, 2014:1:55 PM, at 1:55 PM, Jeffrey Haas = wrote: > Tom, >=20 > On Tue, Sep 30, 2014 at 12:23:10PM -0700, Thomas D. Nadeau wrote: >> On Sep 25, 2014:6:19 AM, at 6:19 AM, Joel M. Halpern = wrote: >>> Top posting for ease of reading, but retaining the content for those = who want context. >>>=20 >>> As I understand the shadow proposal, there is the regular local = config data store, and then there is a second data store (shadow) used = by I2RS for its ephemeral data. That store is never persisted. So far, = so good. >>>=20 >>> Then Andy asked about when they are synchronized, and suggested that = they would be sychronized only when the shadow datastore is established = by teh first I2RS modification request (if I understood him correctly). >>>=20 >>> I don't think that works. Suppose that I2RS has adjusted data items = A and B, creating and filling the shadow data store. And then someone = using CLI / normal NetCONF adjusts item C. If an I2RS client goes to = read C, or does some operation which depends upon the value of C, it has = to be working with the new value of C, not the value at the time the = ephemeral store was created. >>=20 >> It might be useful to define the operational semantics of what = the shadow data store is. In my opinion, its modifying a version of the = running config of the device.=20 >=20 > During the interim, the phrase I was using was "active" config. >=20 > Effectively when both local config and ephemeral config are both = functioning > without issues, logically: >=20 > Without ephemeral datastore: > Active =3D Running >=20 > With ephemeral datastore: > Active =3D Running + Ephemeral. > (I.e. patch running < ephemeral) >=20 > The question about whether we have "pull-up/snapshot" of local config = on top > of ephemeral or simply "overlay/see-through" is mostly an = implementation > detail to cover what happens when there's problems. >=20 > ----- > Overlay: > Active =3D patch running < ephemeral >=20 > Ephemeral crashes: > Active =3D running (should still be in tact) >=20 > Instead, running goes away > Active =3D patch NULL < ephemeral >=20 > This may lead you to an invalid config. >=20 > ----- > Snapshot: >=20 > Active =3D cp running ephemeral.candidate ; patch ephemeral.candidate = < > ephemeral; mv ephemeral.candidate ephemeral. >=20 > Ephemeral crashes: Running config remains. >=20 > Instead, running goes away: > Ephemeral =3D last state of ephemeral, potentially with future changes = laid on > top. >=20 > In other words, in the snapshot implementation, if you lose local = config, > you have the last in tact state of running copied in ephemeral. You = still > must track the individual ephemeral-only changes to lay on top of it. That makes sense.=20 --Tom >=20 >=20 >=20 >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 9/24/14, 11:47 AM, Andy Bierman wrote: >>>>=20 >>>>=20 >>>> On Wed, Sep 24, 2014 at 8:30 AM, Jeffrey Haas >>> > wrote: >>>>=20 >>>> In the proposed overlay model, presume that we have ephemeral = data >>>> from a >>>> model that lives within an augmentation to a local config model. = In >>>> other >>>> words, the ephemeral nodes are children of the local config = nodes. >>>>=20 >>>> Presume, per discussion, that the local config lives in the = "config" >>>> data >>>> store and that the ephemeral config - the augmenting nodes above = - >>>> live in >>>> the ephemeral data store. >>>>=20 >>>> If we delete the container in the local config that the = epehemeral >>>> config is >>>> augmenting, is there any expectation that such a deletion should = carry >>>> through to the ephemeral config? >>>>=20 >>>> Per the netmod interim discussion, probably not. It's in a = separate >>>> datastore. But it does lead to integrity issues since we now = have >>>> orphaned >>>> state. In this particular example, permitting the deletion to = carry >>>> through >>>> to the ephemeral datastore at least provides one additional level = of >>>> consistency. >>>>=20 >>>>=20 >>>> I think the concept of "shadowing the local config" makes this = behavior >>>> confusing. >>>> If the ephemeral datastore instances remains after the config = datastore >>>> instances are deleted, how is that really shadowing? >>>>=20 >>>> IMO, shadowing only occurs when the ephemeral datastore is edited. >>>> It is used as a snapshot to reduce the I2RS payload size (shadow = patch?. >>>> But the data that gets created in the ephemeral datastore is = complete and >>>> self-contained. The actual data structures are implementation = details. >>>> Maybe the local config is cloned, maybe it is shadowed. >>>>=20 >>>> ----- >>>>=20 >>>> My second thought is would we ever want to provide filtering in = the >>>> conditional checks (must/when) in the ephemeral datastore based = on the >>>> underlying source of the data? Since local config would be = shadowed >>>> into >>>> the ephemeral datastore, do we want the ability to match on the >>>> source of >>>> the node set under evaluation? >>>>=20 >>>>=20 >>>> Each datastore should only validated against itself, or else the >>>> XPath implementation would be even more complicated. If the = ephemeral >>>> datastore >>>> is supposed to be fast (I remember 5000 updates a second from the = BoF) >>>> then running validation tests across multiple datastores constantly = will >>>> not help. >>>>=20 >>>> Or do you mean flag a must/when as "do-not-use" in the ephemeral = datastore? >>>> If that were possible it would help speed up the server. >>>>=20 >>>>=20 >>>>=20 >>>> -- Jeff >>>>=20 >>>>=20 >>>> Andy >>>>=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 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_509C0457-1A57-4DC6-AFE9-9DE254D02BCD 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 iQIcBAEBCgAGBQJUKxmkAAoJEPcO+I7eiUJZ3sEP/AhkBjFeuUvCiKYaVBCP24f2 B8Ukx55ihWx5ZBMRAcFd5V8vY81Wf2NI6wQSBSjiHI7hdqF2s0x+LAMDUcStG08m /+kLMW7WI7EPUTep5q0QEIP5p0HnEpcjFhmY0RxB/zytWpPaAZ8MNZmJoJvFkcpn 0N6Pq1VMCO+diUeh0Vidq+GA2wn+7wh11mMt5D7VYowcfhd3LFf9P3IiFZWBtSYf 1Zp0BHSd0TGCwcjOEoBd1G5/J1FwXVqZbZ/Tt+toM3XTXhW6WTH41xDwIbXX+Lr5 XEbFJqEjc+FRXwyoe/DV8OKvdi9gK0wW1IW7EdcXa7aJG9Tzhf/eg+ISGphSnzWg dz68Ehc9luUAlh2J0HhFwlbs2LXWLjrky6TIq+3a2pxFWkQhHhe4yErxLZFLN1/T ewXloGQNTjey6BhctP2nqwqbBc/xe1YiJ5bf1vAwhusw5J7jPwMLBiWnh5sQ8q6l uBd8pJ+OABb71LFGQ5ZDtwO+Ff2qXW0MbtgQebTk4BvxKUehUuBfVwQao/2Hm22g L4ZIeMhD8DkMN3NXejqKoXkxKZ1LzAMz8A+lU+GmAy8qkveKVGX4sLD2aT5A4XFs csL28F3ke3lIFNOBTeZEV1aXPfdDCZF+45VgPjGMJgNyYFA8chm7jVQmzGIuZUXY N3+nSV8jXXesCMvCtivx =WfrK -----END PGP SIGNATURE----- --Apple-Mail=_509C0457-1A57-4DC6-AFE9-9DE254D02BCD-- From nobody Tue Sep 30 16:52: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 9D4761ACD23 for ; Tue, 30 Sep 2014 16:52:17 -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 o7y14YELgFaT for ; Tue, 30 Sep 2014 16:52:16 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35B31ACCE8 for ; Tue, 30 Sep 2014 16:52:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A7D40240201 for ; Tue, 30 Sep 2014 16:52:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 590782401D6 for ; Tue, 30 Sep 2014 16:52:15 -0700 (PDT) Message-ID: <542B422D.6000908@joelhalpern.com> Date: Tue, 30 Sep 2014 19:52:13 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dD0PNfgd7aHAU50ufIul2sCn0_U Subject: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 23:52:17 -0000 I was tyring to understand the descriptions being used. After looking back at the email, and talk to folks, there seem to be two different issues. The first one is what happens the complete running config disappears. As far as I am concerned, the device can do anything it wants, and whatever it does is probably wrong. After all, for the running config to disappear there have to be very serious problems. The second issue is what happens when something (foo) is deleted from the running config, but some property of that thing (foo/a) has been set by I2RS. Unfortunately,as far as I can tell, there is not a good general rule. Some examples: If the operator takes down BGP, and deletes the full BGP configuration, then the presence of I2RS policy rules should not cause BGP to keep running. On the other hand, if foo is a static route create by operations, and then I2RS modified the next hop for that route, I tend to suspect that the route I2RS has "created" by doing so should stay around even if the operator goes in a deletes the static route. I suspect that the issue is determining what scope is being created when I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a consistent rule. Yours, Joel From nobody Tue Sep 30 17:35: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 3A8FF1A87E1 for ; Tue, 30 Sep 2014 17:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOxeWMXSld_9 for ; Tue, 30 Sep 2014 17:35:27 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1291A8770 for ; Tue, 30 Sep 2014 17:35:27 -0700 (PDT) Received: from [10.228.143.65] (unknown [166.170.39.10]) by lucidvision.com (Postfix) with ESMTP id 2827728A9A3B; Tue, 30 Sep 2014 20:35:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: <542B422D.6000908@joelhalpern.com> Date: Tue, 30 Sep 2014 17:35:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> References: <542B422D.6000908@joelhalpern.com> To: "Joel M. Halpern" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/07c5WjwZlsRYKVmbosAI_JT5lUc Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 00:35:29 -0000 > On Sep 30, 2014, at 4:52 PM, Joel M. Halpern wrote: >=20 > I was tyring to understand the descriptions being used. >=20 > After looking back at the email, and talk to folks, there seem to be two d= ifferent issues. >=20 > The first one is what happens the complete running config disappears. > As far as I am concerned, the device can do anything it wants, and whateve= r it does is probably wrong. After all, for the running config to disappear= there have to be very serious problems. Yea >=20 > The second issue is what happens when something (foo) is deleted from the r= unning config, but some property of that thing (foo/a) has been set by I2RS.= Unfortunately,as far as I can tell, there is not a good general rule. The simple solution is to make the i2rs config changes apply immediately to t= he running config/state. > Some examples: > If the operator takes down BGP, and deletes the full BGP configuration, th= en the presence of I2RS policy rules should not cause BGP to keep running. > On the other hand, if foo is a static route create by operations, and then= I2RS modified the next hop for that route, I tend to suspect that the route= I2RS has "created" by doing so should stay around even if the operator goes= in a deletes the static route. >=20 > I suspect that the issue is determining what scope is being created when I= 2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a cons= istent rule. If you make it just write to the running config, you have no issues. Tom=20 >=20 > Yours, > Joel >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Tue Sep 30 18:23: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 D8AF71ACD30 for ; Tue, 30 Sep 2014 18:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8JzfKSN8iNx for ; Tue, 30 Sep 2014 18:23:13 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907101ACD36 for ; Tue, 30 Sep 2014 18:23:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 775DE1BC86D2; Tue, 30 Sep 2014 18:23:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 027811BC8696; Tue, 30 Sep 2014 18:23:10 -0700 (PDT) Message-ID: <542B577D.9080309@joelhalpern.com> Date: Tue, 30 Sep 2014 21:23:09 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Nadeau References: <542B422D.6000908@joelhalpern.com> <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> In-Reply-To: <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ucevw4dtTnbeXz36jrR1Gg71PY8 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 01:23:15 -0000 There are multiple problems with "just copying it to running." The primary one is that as per the I2RS WG rough consensus, the I2RS mods are not supposed to be preserved across a restart. But if they are copied to running, and an operator then does a commit, they will get preserved. In fact, if they get copied to running, and an operator then makes other changes and wants to commit them, he can't help but commit the I2RS changes. Yours, Joel On 9/30/14, 8:35 PM, Thomas Nadeau wrote: > > > > >> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern wrote: >> >> I was tyring to understand the descriptions being used. >> >> After looking back at the email, and talk to folks, there seem to be two different issues. >> >> The first one is what happens the complete running config disappears. >> As far as I am concerned, the device can do anything it wants, and whatever it does is probably wrong. After all, for the running config to disappear there have to be very serious problems. > > Yea > >> >> The second issue is what happens when something (foo) is deleted from the running config, but some property of that thing (foo/a) has been set by I2RS. Unfortunately,as far as I can tell, there is not a good general rule. > > The simple solution is to make the i2rs config changes apply immediately to the running config/state. > >> Some examples: >> If the operator takes down BGP, and deletes the full BGP configuration, then the presence of I2RS policy rules should not cause BGP to keep running. >> On the other hand, if foo is a static route create by operations, and then I2RS modified the next hop for that route, I tend to suspect that the route I2RS has "created" by doing so should stay around even if the operator goes in a deletes the static route. >> >> I suspect that the issue is determining what scope is being created when I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a consistent rule. > > If you make it just write to the running config, you have no issues. > > Tom > > >> >> Yours, >> Joel >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Tue Sep 30 18:34: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 AC0C81ACD51 for ; Tue, 30 Sep 2014 18:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLceUl053qNe for ; Tue, 30 Sep 2014 18:34:36 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BD20B1ACD45 for ; Tue, 30 Sep 2014 18:34:35 -0700 (PDT) Received: from [10.228.143.65] (unknown [166.170.39.10]) by lucidvision.com (Postfix) with ESMTP id 8FCEF28A9B46; Tue, 30 Sep 2014 21:34:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: <542B577D.9080309@joelhalpern.com> Date: Tue, 30 Sep 2014 18:34:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1590378A-4CB1-49D2-AD75-9CD7AD49C541@lucidvision.com> References: <542B422D.6000908@joelhalpern.com> <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> <542B577D.9080309@joelhalpern.com> To: "Joel M. Halpern" Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HZwn5gfoVK6JyqcTuQobzZYE6sk Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 01:34:37 -0000 The running config is by virtue not preserved until an action to save it is m= ade. Of the operator wishes to save the running config then yes they "commi= t" it. =20 I honestly think we're making this harder than it needs to be. Tom=20 > On Sep 30, 2014, at 6:23 PM, Joel M. Halpern wrote: >=20 > There are multiple problems with "just copying it to running." > The primary one is that as per the I2RS WG rough consensus, the I2RS mods a= re not supposed to be preserved across a restart. > But if they are copied to running, and an operator then does a commit, the= y will get preserved. > In fact, if they get copied to running, and an operator then makes other c= hanges and wants to commit them, he can't help but commit the I2RS changes. >=20 > Yours, > Joel >=20 >> On 9/30/14, 8:35 PM, Thomas Nadeau wrote: >>=20 >>=20 >>=20 >>=20 >>> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern wrote= : >>>=20 >>> I was tyring to understand the descriptions being used. >>>=20 >>> After looking back at the email, and talk to folks, there seem to be two= different issues. >>>=20 >>> The first one is what happens the complete running config disappears. >>> As far as I am concerned, the device can do anything it wants, and whate= ver it does is probably wrong. After all, for the running config to disappe= ar there have to be very serious problems. >>=20 >> Yea >>=20 >>>=20 >>> The second issue is what happens when something (foo) is deleted from th= e running config, but some property of that thing (foo/a) has been set by I2= RS. Unfortunately,as far as I can tell, there is not a good general rule. >>=20 >> The simple solution is to make the i2rs config changes apply immediately t= o the running config/state. >>=20 >>> Some examples: >>> If the operator takes down BGP, and deletes the full BGP configuration, t= hen the presence of I2RS policy rules should not cause BGP to keep running. >>> On the other hand, if foo is a static route create by operations, and th= en I2RS modified the next hop for that route, I tend to suspect that the rou= te I2RS has "created" by doing so should stay around even if the operator go= es in a deletes the static route. >>>=20 >>> I suspect that the issue is determining what scope is being created when= I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a co= nsistent rule. >>=20 >> If you make it just write to the running config, you have no issues. >>=20 >> Tom >>=20 >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Tue Sep 30 18:44: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 9A4DE1ACD4E for ; Tue, 30 Sep 2014 18:44:15 -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 g90OlVPBJ5k6 for ; Tue, 30 Sep 2014 18:44:14 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8171ACD7B for ; Tue, 30 Sep 2014 18:44:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7B7121BC8835; Tue, 30 Sep 2014 18:44:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-101-135.public.wayport.net [64.134.101.135]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 07D861BC8818; Tue, 30 Sep 2014 18:44:12 -0700 (PDT) Message-ID: <542B5C6B.2000108@joelhalpern.com> Date: Tue, 30 Sep 2014 21:44:11 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Nadeau References: <542B422D.6000908@joelhalpern.com> <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> <542B577D.9080309@joelhalpern.com> <1590378A-4CB1-49D2-AD75-9CD7AD49C541@lucidvision.com> In-Reply-To: <1590378A-4CB1-49D2-AD75-9CD7AD49C541@lucidvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/1ZNPnXYPKibiwiskmssJBidtW08 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 01:44:15 -0000 Thomas, the approach you propose would mean that whether the I2RS client wanted it or not, if an operator committed the config, he would commit the current state of the I2RS operations. That strikes me as completely wrong, and more importantly as being an extreme violation of the WG agreements. Yours, Joel On 9/30/14, 9:34 PM, Thomas Nadeau wrote: > The running config is by virtue not preserved until an action to save it is made. Of the operator wishes to save the running config then yes they "commit" it. > > I honestly think we're making this harder than it needs to be. > > Tom > > > > >> On Sep 30, 2014, at 6:23 PM, Joel M. Halpern wrote: >> >> There are multiple problems with "just copying it to running." >> The primary one is that as per the I2RS WG rough consensus, the I2RS mods are not supposed to be preserved across a restart. >> But if they are copied to running, and an operator then does a commit, they will get preserved. >> In fact, if they get copied to running, and an operator then makes other changes and wants to commit them, he can't help but commit the I2RS changes. >> >> Yours, >> Joel >> >>> On 9/30/14, 8:35 PM, Thomas Nadeau wrote: >>> >>> >>> >>> >>>> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern wrote: >>>> >>>> I was tyring to understand the descriptions being used. >>>> >>>> After looking back at the email, and talk to folks, there seem to be two different issues. >>>> >>>> The first one is what happens the complete running config disappears. >>>> As far as I am concerned, the device can do anything it wants, and whatever it does is probably wrong. After all, for the running config to disappear there have to be very serious problems. >>> >>> Yea >>> >>>> >>>> The second issue is what happens when something (foo) is deleted from the running config, but some property of that thing (foo/a) has been set by I2RS. Unfortunately,as far as I can tell, there is not a good general rule. >>> >>> The simple solution is to make the i2rs config changes apply immediately to the running config/state. >>> >>>> Some examples: >>>> If the operator takes down BGP, and deletes the full BGP configuration, then the presence of I2RS policy rules should not cause BGP to keep running. >>>> On the other hand, if foo is a static route create by operations, and then I2RS modified the next hop for that route, I tend to suspect that the route I2RS has "created" by doing so should stay around even if the operator goes in a deletes the static route. >>>> >>>> I suspect that the issue is determining what scope is being created when I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a consistent rule. >>> >>> If you make it just write to the running config, you have no issues. >>> >>> Tom >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> _______________________________________________ >>>> 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 Tue Sep 30 21:03: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 181CE1A00F0 for ; Tue, 30 Sep 2014 21:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 luxyhCP2G8Pf for ; Tue, 30 Sep 2014 21:03:28 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E5C1A00EF for ; Tue, 30 Sep 2014 21:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2309; q=dns/txt; s=iport; t=1412136208; x=1413345808; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uINOjJzLf3aEWkojwQesZaOllpnxhGYd1ySIST/zzEM=; b=dTZXQL2OQ02Oyog+avy4End0kSPUfrug3fJQy24qyaKBKoCqbKU86FU9 oFWtNcqWR0xBICl3vEwHg0ppYLneqRQs+xXPC2qgJJrCitWl83jb3/gNK KjZ5HvDfh32AjrfT9GSUsIRtApCsFKZcXPKPCcOZ9Y0BIqtQqF6IOg6Np 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMR8K1StJV2Z/2dsb2JhbABggw5TW8lLCodNAoEPFgF7hAMBAQEDAQEBATc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCIguCA2+QQETBI9tBisHBoMogR0FkWqhNYNjbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,630,1406592000"; d="scan'208";a="82936132" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 01 Oct 2014 04:03:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9143RvS028055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 04:03:27 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 23:03:27 -0500 From: "Alexander Clemm (alex)" To: Jeffrey Haas , "Joel M. Halpern" Thread-Topic: [i2rs] Two thoughts on an ephemeral data store Thread-Index: AQHP2AyNNGxq3WM56UegT3gsiRt8HpwR+uyAgABARYCAAAVsgIAAEjgAgAA6FGCAAVRHAIAAMDuAgAI5aACAAkW0AIACFdvQ Date: Wed, 1 Oct 2014 04:03:27 +0000 Message-ID: References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> <54278C94.40307@joelhalpern.com> <20140929150235.GE7854@pfrc> In-Reply-To: <20140929150235.GE7854@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.69.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eN34pi7Hv-Le9Ha0xnm1xjx2UWQ Cc: "i2rs@ietf.org" , 'Martin Bjorklund' , "Eric Voit \(evoit\)" , 'Andy Bierman' , Susan Hares Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 04:03:30 -0000 Hi, one reply inline, . =20 --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 29, 2014 8:03 AM To: Joel M. Halpern Cc: i2rs@ietf.org; 'Martin Bjorklund'; Eric Voit (evoit); Alexander Clemm (= alex); 'Andy Bierman'; 'Jeffrey Haas'; Susan Hares Subject: Re: [i2rs] Two thoughts on an ephemeral data store On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote: > If I am reading you correctly, you are saying taht if an I2RS client=20 > is manipulating data that is stored in the underlying golden store,=20 > you want that golden store changed. > I think that won't work for the requirements. As far as I can tell=20 > from your proposal, this would result in I2RS changes being stored=20 > when someone on the CLI does a commit. Which is not what is wanted. I agree with you, Joel. This doesn't match the semantics the I2RS WG wante= d. Your understanding is correct. These are the semantics of the propo= sal. When the data in the golden store is changed, it is changed. It is t= he authoritative copy; the changes will be visible in the other datastores = that reference it / mount it and there is no question which values/settings= are in effect. It's not "panes of glass" semantics where which setting is= in effect is computed from overlays of the same object instance across dif= ferent datastores. The semantics are simpler. If you want to have setting= s that go into effect when something in another datastore is deleted etc, y= ou can still achieve that, but you will need to reflect that explicitly in = the model. Whether that's a tradeoff you're willing to make is I guess sub= ject for discussion. =20 > Conversely, a read-through model would seem to work. Objects which=20 > have been created / modified in the I2RS store, when read from the=20 > I2RS store have their I2RS value. If you attempt to read or reference=20 > a value that has not been modified in I2RS, you read-through to the=20 > underlying data store, and see its value. Hopefully my most recent example shows this. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Sep 30 21:16: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 56AF41A0104 for ; Tue, 30 Sep 2014 21:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVVcps403_IV for ; Tue, 30 Sep 2014 21:16:41 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047D51A00FD for ; Tue, 30 Sep 2014 21:16:40 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id i57so20671yha.3 for ; Tue, 30 Sep 2014 21:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vgrPDqDlWrkJQ+nvpHhWZYWybSk/ZpThCMf4RDBa4U0=; b=vnUBVc3RpDFFHIRtx+ftNse+6JBprp6+LeeBqe0eFhMLcklZbX5pn1I5m7q0jE6WG9 MBl5ilPl00nsz51TinRAQM2chLQql5lA4HPpS4uSyW/YDrj3COSwyY6TxnnyUozQrSRE 21m+Zm3+hs932MJ3hX8IhNeT9pKDSffpTrmDSh2RkVHs48J5a5Dfeg6V/CtIiolXJ2DS iigDjR3sgleNpevx5Vkc9M50cuw71S8YpfnKqoqS8HtM09k/9Ici7hekrOYHcnzJq97i yAIY56RHJuVdLhbjgYIA5goWZOZNNoMJOXaZnGZKYZl9x4cff+NLvsq6gU4Q5K4yXwne bxrQ== MIME-Version: 1.0 X-Received: by 10.236.32.4 with SMTP id n4mr74219285yha.16.1412137000269; Tue, 30 Sep 2014 21:16:40 -0700 (PDT) Received: by 10.170.110.72 with HTTP; Tue, 30 Sep 2014 21:16:40 -0700 (PDT) In-Reply-To: References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <027901cfd99e$bd12f4b0$3738de10$@ndzh.com> <54278C94.40307@joelhalpern.com> <20140929150235.GE7854@pfrc> Date: Wed, 1 Oct 2014 00:16:40 -0400 Message-ID: From: Alia Atlas To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=001a11c1bae6468004050454c479 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/VhcQMJPTkOa4kMyBX7zgQ642FZY Cc: "i2rs@ietf.org" , Martin Bjorklund , "Eric Voit \(evoit\)" , Andy Bierman , Jeffrey Haas , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 04:16:43 -0000 --001a11c1bae6468004050454c479 Content-Type: text/plain; charset=UTF-8 Hi Alex, Tom, Joel, et al. (top-posting) In the initial I2RS framework, we had the ideal of different data lifetimes as well as being able to have written state be permanent or ephemeral. The I2RS WG consensus was very clear that I2RS should only support ephemeral state and that is reflected in the architecture. In the architecture, the configuration interacts with an I2RS Agent based on the relative priorities of the configuration and the I2RS client that wrote the state. An easy example - certainly what I'd assume to occur while gaining initial experience - is that the configuration always overrules I2RS Clients. If state is written by an I2RS client that depends on configuration and the configuration is deleted, then the I2RS client's state is also deleted and the client is notified. This is what would happen if it were another I2RS client that caused the change as well. I'm quite happy to see focused discussion on how we can actually use YANG for I2RS in the nitty-gritty details, but I am concerned that what we end up with is what I2RS is rather than a different animal. no-hats Alia On Wed, Oct 1, 2014 at 12:03 AM, Alexander Clemm (alex) wrote: > Hi, one reply inline, . > --- Alex > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, September 29, 2014 8:03 AM > To: Joel M. Halpern > Cc: i2rs@ietf.org; 'Martin Bjorklund'; Eric Voit (evoit); Alexander Clemm > (alex); 'Andy Bierman'; 'Jeffrey Haas'; Susan Hares > Subject: Re: [i2rs] Two thoughts on an ephemeral data store > > On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote: > > If I am reading you correctly, you are saying taht if an I2RS client > > is manipulating data that is stored in the underlying golden store, > > you want that golden store changed. > > I think that won't work for the requirements. As far as I can tell > > from your proposal, this would result in I2RS changes being stored > > when someone on the CLI does a commit. Which is not what is wanted. > > I agree with you, Joel. This doesn't match the semantics the I2RS WG > wanted. > > Your understanding is correct. These are the semantics of the > proposal. When the data in the golden store is changed, it is changed. It > is the authoritative copy; the changes will be visible in the other > datastores that reference it / mount it and there is no question which > values/settings are in effect. It's not "panes of glass" semantics where > which setting is in effect is computed from overlays of the same object > instance across different datastores. The semantics are simpler. If you > want to have settings that go into effect when something in another > datastore is deleted etc, you can still achieve that, but you will need to > reflect that explicitly in the model. Whether that's a tradeoff you're > willing to make is I guess subject for discussion. > > > > > Conversely, a read-through model would seem to work. Objects which > > have been created / modified in the I2RS store, when read from the > > I2RS store have their I2RS value. If you attempt to read or reference > > a value that has not been modified in I2RS, you read-through to the > > underlying data store, and see its value. > > Hopefully my most recent example shows this. > > -- 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 > --001a11c1bae6468004050454c479 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alex, Tom, Joel, et al.

(top-posting= ) =C2=A0In the initial I2RS framework, we had the ideal of different data l= ifetimes as well as being able to have
written state be permanent= or ephemeral.=C2=A0 The I2RS WG consensus was very clear that I2RS should = only support
ephemeral state and that is reflected in the archite= cture.

In the architecture, the configuration inte= racts with an I2RS Agent based on the relative priorities of the configurat= ion
and the I2RS client that wrote the state.=C2=A0 An easy examp= le - certainly what I'd assume to occur while gaining initial
experience - is that the configuration always overrules I2RS Clients.=C2= =A0 If state is written by an I2RS client that depends
on configu= ration and the configuration is deleted, then the I2RS client's state i= s also deleted and the client is notified.=C2=A0
This is what wou= ld happen if it were another I2RS client that caused the change as well.

I'm quite happy to see focused discussion on how w= e can actually use YANG for I2RS in the nitty-gritty details, but I am
concerned that what we end up with is what I2RS is rather than = a different animal.

no-hats Alia

On Wed, Oct 1, 2014 at = 12:03 AM, Alexander Clemm (alex) <alex@cisco.com> wrote:
Hi, one reply inline, <Alex>.
--- Alex

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Jeffrey Haas
Sent: Monday, September 29, 2014 8:03 AM
To: Joel M. Halpern
Cc: i2rs@ietf.org; 'Martin Bjorklu= nd'; Eric Voit (evoit); Alexander Clemm (alex); 'Andy Bierman';= 'Jeffrey Haas'; Susan Hares
Subject: Re: [i2rs] Two thoughts on an ephemeral data store

On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote:
> If I am reading you correctly, you are saying taht if an I2RS client > is manipulating data that is stored in the underlying golden store, > you want that golden store changed.
> I think that won't work for the requirements.=C2=A0 As far as I ca= n tell
> from your proposal, this would result in I2RS changes being stored
> when someone on the CLI does a commit.=C2=A0 Which is not what is want= ed.

I agree with you, Joel.=C2=A0 This doesn't match the semantics the I2RS= WG wanted.

<ALEX> Your understanding is correct.=C2=A0 These are the sema= ntics of the proposal.=C2=A0 When the data in the golden store is changed, = it is changed.=C2=A0 It is the authoritative copy; the changes will be visi= ble in the other datastores that reference it / mount it and there is no qu= estion which values/settings are in effect.=C2=A0 It's not "panes = of glass" semantics where which setting is in effect is computed from = overlays of the same object instance across different datastores.=C2=A0 The= semantics are simpler.=C2=A0 If you want to have settings that go into eff= ect when something in another datastore is deleted etc, you can still achie= ve that, but you will need to reflect that explicitly in the model.=C2=A0 W= hether that's a tradeoff you're willing to make is I guess subject = for discussion.
</ALEX>


> Conversely, a read-through model would seem to work.=C2=A0 Objects whi= ch
> have been created / modified in the I2RS store, when read from the
> I2RS store have their I2RS value.=C2=A0 If you attempt to read or refe= rence
> a value that has not been modified in I2RS, you read-through to the > underlying data store, and see its value.

Hopefully my most recent example shows this.

-- Jeff

_______________________________________________
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

--001a11c1bae6468004050454c479-- From nobody Tue Sep 30 21:25: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 4A0DA1ACCEF for ; Tue, 30 Sep 2014 21:25:28 -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 ghAtYYQWpF-s for ; Tue, 30 Sep 2014 21:25:27 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024431A923C for ; Tue, 30 Sep 2014 21:25:26 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id f10so21513yha.13 for ; Tue, 30 Sep 2014 21:25:26 -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=ETGyFKSDvYPfnu5oMikGRkZjJoaENB5peQ3mecQvKwk=; b=cVyCW1VFEJ16eZRO4XDMvE4t2IBOW0ver95cDUDNhUnJ3wqPAoQEe18akh8RvG5TWZ MjT1GZ+lfh6tASkqsgoaq3CjU2IhGnRDGdXmH59EpvhAsalzRKr3Whn3b33PXOeQG0/6 eA3y2Efi7pH+/1eGVJliJjyu/XUbf2yx3ukPXBi+xHggsIfWUM4UNMEteV9u/q4Rk0ac 6zptzmUK+tyjTcnVpi/zoqNR5+7uvXyEjqkFvxsmtXrIogwyEyj64qaRUDAZ0+YgXBHS bXQjm470Y0BBTkgZF1pNEok2gl5HxMF2dlZHUXXNqfr6o0JJK4lv4GbbNpn1OtsmnyHC dPCg== MIME-Version: 1.0 X-Received: by 10.236.164.196 with SMTP id c44mr59345117yhl.79.1412137526310; Tue, 30 Sep 2014 21:25:26 -0700 (PDT) Received: by 10.170.110.72 with HTTP; Tue, 30 Sep 2014 21:25:26 -0700 (PDT) Date: Wed, 1 Oct 2014 00:25:26 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf303f6480a13f18050454e3ec Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gf5i7KW_Wu6Ec8COhfHjkPbAm1M Subject: [i2rs] Why do we need a datastore? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 04:25:28 -0000 --20cf303f6480a13f18050454e3ec Content-Type: text/plain; charset=UTF-8 Hi, I'd like to really understand why I2RS needs a datastore and what that actually means. In my initial conception of what an I2RS agent would do for, say, writing a route in the RIB model, is that the I2RS agent would simply parse a received request from a standard format and model into the internal and pass that to a RIB Manager - just as an OSPF implementation might install a route to the RIB manager. An I2RS agent could also query the RIB Manager to read routes and there'd be events coming out. With the introduction of priorities to handle multi-headed writers and collision errors, the I2RS agent would need to store what was written by which client. What benefits and rationale does a YANG datastore add? Why does using one need to be standardized? I apologize if this seems a naive question, but it's been quite a while since I read up on YANG and NetConf/RestConf. Regards, no-hats Alia --20cf303f6480a13f18050454e3ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

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

With the introducti= on of priorities to handle multi-headed writers and collision errors, the I= 2RS agent would need to store what was written by which client.
<= br>
What benefits and rationale does a YANG datastore add?=C2=A0 = Why does using one need to be
standardized?

<= div>I apologize if this seems a naive question, but it's been quite a w= hile since I read up on YANG and NetConf/RestConf. =C2=A0

Regards,
no-hats =C2=A0Alia

--20cf303f6480a13f18050454e3ec-- From nobody Tue Sep 30 22:38: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 B50391A0146 for ; Tue, 30 Sep 2014 22:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 m98eyD_g-Au0 for ; Tue, 30 Sep 2014 22:38:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CB21A0167 for ; Tue, 30 Sep 2014 22:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2401; q=dns/txt; s=iport; t=1412141883; x=1413351483; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rqWW7/BHyeQzxxVQBvPw9k64VnMJFJLaF2SV1y5wQFU=; b=FGDRVOjgJCy7FS3LO8hfP75huJuSisLGX9imPA/QPmLLv8bZF9X/zii8 xnfPpX0sv+2PLP7QZyxuiemYcmciINHFG+GCxNh5qpKJMSJs7/BIczaRN zukMHJioiuBNOlNDK0ZT4F1VlvNHRgeID7Fho72ySoY/62u5dNqBuJGFQ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMuSK1StJV2c/2dsb2JhbABggw6BLtEwAoENFgF7hAMBAQEEOj8MBAIBCA4DBAEBCxQJBzIUCQgCBA4FCIg2vl0BF49tBisHBoMogR0BBJFqoTWDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,630,1406592000"; d="scan'208";a="359492143" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 01 Oct 2014 05:38:02 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s915c2fT002452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 05:38:02 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 1 Oct 2014 00:38:01 -0500 From: "Alexander Clemm (alex)" To: Jeffrey Haas Thread-Topic: [i2rs] Two thoughts on an ephemeral data store Thread-Index: AQHP2AyNNGxq3WM56UegT3gsiRt8HpwR+uyAgABARYCAAAVsgIAAEjgAgAA6FGCABgM3AIACLZhQ Date: Wed, 1 Oct 2014 05:38:00 +0000 Message-ID: References: <20140924153051.GB2639@pfrc> <20140925.122935.1032892075797966525.mbj@tail-f.com> <20140925141937.GB10261@pfrc> <20140925.163901.67679202204863959.mbj@tail-f.com> <20140929150110.GD7854@pfrc> In-Reply-To: <20140929150110.GD7854@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.69.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GiUm5KWtw-TgEjeMTHTm8o8VV1s Cc: "i2rs@ietf.org" , Martin Bjorklund , "Eric Voit \(evoit\)" , Andy Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 05:38:04 -0000 Hello Jeff, just one brief reply/comment to point (b) in your summary, inline Thanks --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 29, 2014 8:01 AM To: Alexander Clemm (alex) Cc: Jeffrey Haas; i2rs@ietf.org; Martin Bjorklund; Eric Voit (evoit); Andy = Bierman Subject: Re: [i2rs] Two thoughts on an ephemeral data store ... > (b) It needs to be clear who owns the "golden copy" of an object. I ne= eds to be clear which objects are "authoritatively owned" by a datastore vs= which ones are reference. This is the datastore where the object is maint= ained, updated, created; this is where conditions and constraints are evalu= ated, etc. This seems obvious, but there are a few potentially conflicting scenarios. If objects that are always intended to be ephemeral are never going to conf= lict (but may lie on top of) local config, there is never a conflict. There is simply referential integrity issues if the underlying local config= is deleted and ephemeral config remains. If the objects are always disjoint, there is never a conflict. But if you permit an ephemeral object to override a local config one within= the schema, we have this issue. Our options would appear to be: - Do not permit such overrides. Design your models so that when it is desired to configure the same underlying operational state from multiple sources, it is through disjoint pieces of the model. An example would be for static routes to have a local-config mechanism and a completely separ= ate ephemeral config model. This is the "easy" option. - Permit such overrides as long as the semantics are "clear". Yes, and the third option is the one in which you treat the datasto= res as separate entities in which references and dependencies as well as wh= at constititutes the "golden copy" are explicitly exposed instead of being= implicitly manged. =20 Of course there are some constraints that need to be imposed on the model a= nd what's allowed, such as not allowing a "local" object to be contained in= and existentially depend on a "remote" object owned by a different datasto= re, due to the referential integrity issues that you point out. I would co= nsider such constraints features, not limitations of the model. =20 ... From nobody Tue Sep 30 23:43: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 5ECEE1A01F9 for ; Tue, 30 Sep 2014 23:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwj0131yxvGi for ; Tue, 30 Sep 2014 23:43:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B83D1A00E8 for ; Tue, 30 Sep 2014 23:43:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CB39C72F; Wed, 1 Oct 2014 08:43:13 +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 BTmktmR-BQhD; Wed, 1 Oct 2014 08:43:12 +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, 1 Oct 2014 08:43:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3E2120036; Wed, 1 Oct 2014 08:43:12 +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 fbPeLAW3o4XA; Wed, 1 Oct 2014 08:43:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C242920035; Wed, 1 Oct 2014 08:43:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B59182EBD427; Wed, 1 Oct 2014 08:43:11 +0200 (CEST) Date: Wed, 1 Oct 2014 08:43:11 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20141001064311.GF36781@elstar.local> Mail-Followup-To: "Joel M. Halpern" , "i2rs@ietf.org" References: <542B422D.6000908@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542B422D.6000908@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Y7-thgSA8jfGHRj0TzNIBnStwYI Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:43:16 -0000 On Tue, Sep 30, 2014 at 07:52:13PM -0400, Joel M. Halpern wrote: > The second issue is what happens when something (foo) is deleted from > the running config, but some property of that thing (foo/a) has been set > by I2RS. Unfortunately,as far as I can tell, there is not a good > general rule. > > Some examples: > If the operator takes down BGP, and deletes the full BGP configuration, > then the presence of I2RS policy rules should not cause BGP to keep running. > On the other hand, if foo is a static route create by operations, and > then I2RS modified the next hop for that route, I tend to suspect that > the route I2RS has "created" by doing so should stay around even if the > operator goes in a deletes the static route. If I2RS only modifies the next hop and the underlying route is delete from config, then the route should be removed from the operational state. If I2RS wants the route to persist even if the underlying config goes away, then the I2RS client has to inject a complete routing record overlaying the underlying route from config. I believe this is actually simple as long as we keep it simple. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 30 23:47: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 66F3B1A0104 for ; Tue, 30 Sep 2014 23:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOMcl9JSPK5x for ; Tue, 30 Sep 2014 23:47:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F3C1A008A for ; Tue, 30 Sep 2014 23:47:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1AD0CF8D; Wed, 1 Oct 2014 08:47:38 +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 zPo3vj-BcoYi; Wed, 1 Oct 2014 08:47:36 +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, 1 Oct 2014 08:47:36 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B859920036; Wed, 1 Oct 2014 08:47:36 +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 5-7YQfFlYCPs; Wed, 1 Oct 2014 08:47: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 5150420035; Wed, 1 Oct 2014 08:47:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 452AF2EBD46B; Wed, 1 Oct 2014 08:47:35 +0200 (CEST) Date: Wed, 1 Oct 2014 08:47:35 +0200 From: Juergen Schoenwaelder To: Thomas Nadeau Message-ID: <20141001064735.GG36781@elstar.local> Mail-Followup-To: Thomas Nadeau , "Joel M. Halpern" , "i2rs@ietf.org" References: <542B422D.6000908@joelhalpern.com> <9D4CED3E-41FB-40B9-B8A4-DB5BC6CA11D3@lucidvision.com> <542B577D.9080309@joelhalpern.com> <1590378A-4CB1-49D2-AD75-9CD7AD49C541@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1590378A-4CB1-49D2-AD75-9CD7AD49C541@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FGYR6_N1QGErCobmwFngtk1Q8rg Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] Running and I2RS Ephemeral Config Interaction X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:47:41 -0000 Tom, this is correct only if the NETCONF server supports the :startup capability. During the interim, I said that there are certain 'synchronization points' at which the running datastore is made persistent. What these 'synchronization points' are depends on the capabilities of the NETCONF server. In other words, I2RS should assume that the 'running configuration datastore' is generally persistent (even if there may be periods where this is not true, until the next 'synchronization points' has been reached. The main reason we discussed ephemeral datastores is that they will never have any 'synchronization points'. /js On Tue, Sep 30, 2014 at 06:34:32PM -0700, Thomas Nadeau wrote: > The running config is by virtue not preserved until an action to save it is made. Of the operator wishes to save the running config then yes they "commit" it. > > I honestly think we're making this harder than it needs to be. > > Tom > > > > > > On Sep 30, 2014, at 6:23 PM, Joel M. Halpern wrote: > > > > There are multiple problems with "just copying it to running." > > The primary one is that as per the I2RS WG rough consensus, the I2RS mods are not supposed to be preserved across a restart. > > But if they are copied to running, and an operator then does a commit, they will get preserved. > > In fact, if they get copied to running, and an operator then makes other changes and wants to commit them, he can't help but commit the I2RS changes. > > > > Yours, > > Joel > > > >> On 9/30/14, 8:35 PM, Thomas Nadeau wrote: > >> > >> > >> > >> > >>> On Sep 30, 2014, at 4:52 PM, Joel M. Halpern wrote: > >>> > >>> I was tyring to understand the descriptions being used. > >>> > >>> After looking back at the email, and talk to folks, there seem to be two different issues. > >>> > >>> The first one is what happens the complete running config disappears. > >>> As far as I am concerned, the device can do anything it wants, and whatever it does is probably wrong. After all, for the running config to disappear there have to be very serious problems. > >> > >> Yea > >> > >>> > >>> The second issue is what happens when something (foo) is deleted from the running config, but some property of that thing (foo/a) has been set by I2RS. Unfortunately,as far as I can tell, there is not a good general rule. > >> > >> The simple solution is to make the i2rs config changes apply immediately to the running config/state. > >> > >>> Some examples: > >>> If the operator takes down BGP, and deletes the full BGP configuration, then the presence of I2RS policy rules should not cause BGP to keep running. > >>> On the other hand, if foo is a static route create by operations, and then I2RS modified the next hop for that route, I tend to suspect that the route I2RS has "created" by doing so should stay around even if the operator goes in a deletes the static route. > >>> > >>> I suspect that the issue is determining what scope is being created when I2RS writes b/c/d/foo/a. I don't think it is obvious or that there is a consistent rule. > >> > >> If you make it just write to the running config, you have no issues. > >> > >> Tom > >> > >> > >>> > >>> Yours, > >>> Joel > >>> > >>> _______________________________________________ > >>> 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103