[i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

Joe Clarke <jclarke@cisco.com> Mon, 18 July 2016 14:38 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185FE12DDD1 for <i2rs@ietfa.amsl.com>; Mon, 18 Jul 2016 07:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level:
X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncYOPqvkR-Cb for <i2rs@ietfa.amsl.com>; Mon, 18 Jul 2016 07:38:14 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ADB12DC10 for <i2rs@ietf.org>; Mon, 18 Jul 2016 07:07:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=922; q=dns/txt; s=iport; t=1468850869; x=1470060469; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=sf7ElzCeyiByFALUdfJ435AWz64y8bmjKRVnnGSXH6A=; b=W7Hd7LVng2tYvltAmHerImDPJLfUZ5zowyBXSRdrz9ie3WoAOGYVp/RR zLSx4OfARV9bgRRDTJ75uL7ZDdq8pHKCDPJR7ok0eDGd4mXSsBSeQ2m4D ChiWAxkBuwiqfYSukO4ZmM6+N6rJcervwkkJSB1YBLZPxPsFIlAbEFw43 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DUCgCg4YxX/5pdJa1bgz+BALtGh048EAEBAQEBAQFlHAuFBhV2AiYCXw0IAQGILKBFj2KNcQEBAQcCJYEBhSmBeAiKDoJaAQSZJIE1jSqBa4dlI4VEkB41H4QPIIYsKoEaAQEB
X-IronPort-AV: E=Sophos;i="5.28,384,1464652800"; d="scan'208";a="299228529"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2016 14:07:49 +0000
Received: from [10.82.236.218] (rtp-vpn5-1238.cisco.com [10.82.236.218]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u6IE7mGW030750 for <i2rs@ietf.org>; Mon, 18 Jul 2016 14:07:48 GMT
To: "i2rs@ietf.org" <i2rs@ietf.org>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco Systems, Inc.
Message-ID: <fc5d171b-82da-0041-3248-8a01d31e9202@cisco.com>
Date: Mon, 18 Jul 2016 10:07:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/gUcryJvSAWayoPckKF-kPV_qVGY>
Subject: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2016 14:38:15 -0000

As I stated at the mic today, I think the way REQ-07 is written is a bit 
broad.  This was evidently the intent, but I have a proposal.

Can we not treat "local config" (e.g., CLI changes) as an I2RS client 
with its own I2RS priority?  If all players (I2RS and local config) play 
with the same priority concept, then one can easily control what gets 
precedence.

For example, if I want to temporarily overlay ephemeral-provided changes 
with local config, I could increase the local config priority.  When I'm 
done with that, I set the priority back.  By default, the local config 
priority would be the lowest value to allow for ephemeral changes to 
take precedence.

I do not think this will have a negative impact on topology as I have 
read it, but if this doesn't make sense in some use cases, the priority 
could be ignored.

Hopefully I've described this well so that it makes sense.

Joe