Re: [i2rs] Comments re: draft-i2rs-ephemeral-state-12

"Alexander Clemm (alex)" <> Tue, 05 July 2016 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87062127078 for <>; Tue, 5 Jul 2016 14:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Status: No, score=-15.946 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rJ_eKBkHCxTz for <>; Tue, 5 Jul 2016 14:36:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5B1D127071 for <>; Tue, 5 Jul 2016 14:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=15043; q=dns/txt; s=iport; t=1467754613; x=1468964213; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e+g9PHVXPlaswZa7h64j7X7k7OGNGilCiDb15NuTLvw=; b=NDxldQVuFWmFB7TYBfqoNipNSuq+98IpOqN7QwLrxSZkwtNnOIqkjSng On5cW/dWhxrOi6SsKwGz72+OyYYBmUSBVjmNfv+3puJZMMMrHa1FinUxT g0C8W8UEBx6ggizHuW+C/aQnhmQcaw1oB7s/j7J2j54zEJCaQwrs5Dw6m Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.28,315,1464652800"; d="scan'208,217";a="122659061"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 21:36:52 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u65Laq92021261 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 21:36:52 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 17:36:51 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 17:36:51 -0400
From: "Alexander Clemm (alex)" <>
To: Susan Hares <>
Thread-Topic: [i2rs] Comments re: draft-i2rs-ephemeral-state-12
Thread-Index: AdHTLLXVK5j65/HKSm+eYJHHuRfLTgD9pA+AAAeMnoA=
Date: Tue, 05 Jul 2016 21:36:51 +0000
Message-ID: <>
References: <> <04be01d1d701$bf4d0510$3de70f30$>
In-Reply-To: <04be01d1d701$bf4d0510$3de70f30$>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_a0436de45cf7403890d13a489d71fe67XCHRTP001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [i2rs] Comments re: draft-i2rs-ephemeral-state-12
X-Mailman-Version: 2.1.17
Precedence: 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, 05 Jul 2016 21:36:56 -0000

Hi Susan,

this looks good - thank you!

--- Alex

From: Susan Hares []
Sent: Tuesday, July 05, 2016 2:11 PM
To: Alexander Clemm (alex) <>
Subject: RE: [i2rs] Comments re: draft-i2rs-ephemeral-state-12


Thank you for your comments.    The nit will be released in version 14.

From: i2rs [] On Behalf Of Alexander Clemm (alex)
Sent: Thursday, June 30, 2016 8:13 PM
To: Susan Hares (<>)
Subject: [i2rs] Comments re: draft-i2rs-ephemeral-state-12

Hi Susan,

this document looks very good & I clearly support it.

Just two very minor comments:

-          editorial nits - page  2:  "Sections 7" --> "Section 7"; "is I2RS protocol requirement" --> "is an I2RS protocol requirement"

-          I consider Ephemeral-REQ-03 as very important ("may have constraints that refer to operational state").  I am wondering, should the draft mention how to deal with the fact that it is possible for operational state to dynamically change.  I would think it is might be worth stating something to the effect that constraints should be assessed when ephemeral state is written, and that situations are conceivable where violations of such constraints might occur due to changing of operational state after the write occurred.   By the nature of the issue, the framework must allow for that; how to deal with such a situation and maintain integrity of the ephemeral configuration in such cases is up to the client.


   Ephemeral-REQ-03: Ephemeral state may have constraints that refer to
   operational state, this includes potentially fast changing or short
   lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.

Is this your suggested change?

   Ephemeral-REQ-03: Ephemeral state may have constraints that refer to
   operational state, this includes potentially fast changing or short
   lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.
   Ephemeral state constraints should be assessed when the ephemeral
   State is written, and if the constraint change after that time
   the I2RS agent should notify the I2RS Client.

If this expresses your desired change, please let me know - I will add it to version 14.

One thought re: section 9, clearly we have a requirement to support subscriptions against ephemeral data; is there a requirement for subscriptions to be ephemeral themselves?  (I think it is implicitly supported via dynamic subscriptions.)

Yes, the subscriptions for the ephemeral only models must be ephemeral.   Is this text addition ok?

Pub-Sub-REQ-03:   The subscription service must support subscriptions which are ephemeral.
(E.g. An ephemeral data model which has ephemeral subscriptions.)

--- Alex

Thank you for your comments.