Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20
"Susan Hares" <shares@ndzh.com> Mon, 12 October 2015 07:46 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs-proto-dt@ietfa.amsl.com
Delivered-To: i2rs-proto-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A44E1A21B7; Mon, 12 Oct 2015 00:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.455
X-Spam-Level:
X-Spam-Status: No, score=-98.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] 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 dXKE57DNkbId; Mon, 12 Oct 2015 00:46:20 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 67F631A21B3; Mon, 12 Oct 2015 00:46:20 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.139;
From: Susan Hares <shares@ndzh.com>
To: "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Andy Bierman' <andy@yumaworks.com>, i2rs@ietf.org, i2rs-proto-dt@ietf.org
References: <05c801d102ce$eb398930$c1ac9b90$@ndzh.com> <20151011161106.GA61856@elstar.local> <CABCOCHTb6VxuV1YxP+zVd8qo171+OUFoH2qeZxAiFqi2RrdrXA@mail.gmail.com> <20151011175123.GA62046@elstar.local> <CABCOCHQa1Dv-vkt-xhGDzOw4rt4UWnGPjEsxHj5vrVNFGjk-xQ@mail.gmail.com> <20151011195818.GA62201@elstar.local> <561AC25F.7050407@joelhalpern.com> <20151011202410.GA62276@elstar.local> <561AC682.4000607@joelhalpern.com>
In-Reply-To: <561AC682.4000607@joelhalpern.com>
Date: Mon, 12 Oct 2015 03:46:16 -0400
Message-ID: <00fc01d104c2$1393b9b0$3abb2d10$@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: AQHHBWI2YK0cgP6O7aghYGNeB+dLGgIYY1VbAUr8eV0C/3J64gI3r/8BAS74WKMBWsO9kgKOn5JJAsz+SjGd93pGMA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/BaNrb4z5jjrKuZsqKl-wIsuxHoQ>
Subject: Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20
X-BeenThere: i2rs-proto-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <i2rs-proto-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs-proto-dt/>
List-Post: <mailto:i2rs-proto-dt@ietf.org>
List-Help: <mailto:i2rs-proto-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2015 07:46:22 -0000
Joel: The I2RS models for BGP utilize the BGP yang module definitions, but these models are not the same. I would agree with you that the I2RS models are unique. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Sunday, October 11, 2015 4:29 PM To: Andy Bierman; Susan Hares; i2rs@ietf.org; i2rs-proto-dt@ietf.org Subject: Re: [i2rs] inteirm 10/7/20 While there will be new information that needs new models, some of the things to be manipulated in an ephemeral fashion by I2RS are already in existing models. I have heard proposals to use some version of overlapping or related models, and I do not know what can be made to work. Yours, Joel On 10/11/15 4:24 PM, Juergen Schoenwaelder wrote: > Joel, > > do you expect that special models will be written for I2RS or do you > expect that generic routing configuration models will do the job? > > /js > > On Sun, Oct 11, 2015 at 04:11:11PM -0400, Joel M. Halpern wrote: >> I would phrase the marking need slightly differently. >> Given that it would seem onerous to expect all I2RS-supporting >> devices to support ephemeral behavior for all parts of all models, we >> need some way to clearly indicate what is expected. >> >> Trying to do it as separate models seems difficult. >> >> Marking elements in the model as ephemeral seems the clearest and >> most efficient mechanism, but I am sure there are other alternatives. >> >> Yours, >> Joel >> >> On 10/11/15 3:58 PM, Juergen Schoenwaelder wrote: >>> On Sun, Oct 11, 2015 at 11:10:16AM -0700, Andy Bierman wrote: >>>> On Sun, Oct 11, 2015 at 10:51 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>> >>>>> On Sun, Oct 11, 2015 at 09:55:31AM -0700, Andy Bierman wrote: >>>>>> On Sun, Oct 11, 2015 at 9:11 AM, Juergen Schoenwaelder < >>>>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>>> >>>>>>> On Fri, Oct 09, 2015 at 04:13:03PM -0400, Susan Hares wrote: >>>>>>>> The 10/7/2015 interim discussed the ephemeral portion of the >>>>>>>> protocol >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1) Ephemeral state is not unique to zI2RS >>>>>>>> >>>>>>>> 2) The ephemeral datastore is a datastore holds >>>>>>>> >>>>>>>> configuration that is intended to not survive a reboot. >>>>>>>> >>>>>>> >>>>>>> Configuration as YANG config true or a subset thereof? >>>>>>> >>>>>> >>>>>> >>>>>> config=true nodes only. >>>>> >>>>> good >>>>> >>>>>> Some way is needed to specify I2RS conformance for a given YANG >>>>>> module, unless every persistent config leaf is expected to also >>>>>> be supported as ephemeral data. >>>>>> >>>>>> If not, a YANG "ephemeral-stmt" is probably needed, since >>>>>> config=true is insufficient to support I2RS conformance. >>>>> >>>>> One question is whether this needs to be inline in the data model >>>>> or not. If conformance is the goal, then you know what having >>>>> things defined inline has limits. If we would address conformance >>>>> in more general terms, perhaps I2RS conformance falls out as a special case. >>>>> >>>>>> One ephemeral datastore. >>>>>> No client panes. That was to support caching, but the >>>>>> architecture forbids caching, so that was taken out. >>>>>> >>>>>> One ephemeral pane that overrides the running datastore >>>>> >>>>> good >>>>> >>>>>>> Identities? I assume you mean schema nodes, do you? Adding by >>>>>>> defining an YANG extension such as i2rs:ephemeral true? How does >>>>>>> such an i2rs:ephemeral true interplay with config true/false? >>>>>>> What about contexts for must/when expressions? Or is the idea to >>>>>>> settle on RESTCONF and to work with YANG patch? >>>>>>> >>>>>> >>>>>> I think a real keyword is needed not an extension. >>>>>> Otherwise YANG groupings cannot be utilized w/ statements that >>>>>> are refined in the uses-stmt to set the ephemeral flag. >>>>> >>>>> I fail to understand the groupings argument. >>>>> >>>> >>>> >>>> The refine-stmt is defined to work on YANG statements, not external >>>> statements. >>> >>> RFC 6020bis says in section 7.13.2.: >>> >>> o Any node can get refined extensions, if the extension allows >>> refinement. See Section 7.19 for details. >>> >>>> A YANG extension is (by definition) something external to the YANG >>>> language. >>>> The WG needs to decide if the ephemeral property should be specific >>>> to an I2RS YANG module or should be basic property of the YANG data >>>> modeling language. YANG keywords must be supported and they do not >>>> need to be imported from a YANG module to be used. >>> >>> Or it is a common extension (that is the extension is not I2RS >>> specific but instead for everything that wants to use ephemeral >>> datastores). >>> >>> Anyway, if the main purpose is to define a conformance level, it may >>> be worth thinking about adding a conformance mechanism that >>> decouples conformance requirements from the data model definition. >>> >>> /js >>> >> >> _______________________________________________ >> 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-proto-dt] inteirm 10/7/20 Susan Hares
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Andy Bierman
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Andy Bierman
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Susan Hares
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Susan Hares
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Susan Hares
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Susan Hares
- Re: [I2rs-proto-dt] [i2rs] inteirm 10/7/20 Susan Hares