Re: Comments on draft-shaikh-rtgwg-policy-model

Jeffrey Haas <jhaas@pfrc.org> Wed, 22 July 2015 08:37 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E7A1A0377 for <rtgwg@ietfa.amsl.com>; Wed, 22 Jul 2015 01:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nJGlKOORfuQn for <rtgwg@ietfa.amsl.com>; Wed, 22 Jul 2015 01:37:43 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5992A1A009D for <rtgwg@ietf.org>; Wed, 22 Jul 2015 01:37:43 -0700 (PDT)
Received: from [172.29.64.71] (jplon-nat11.juniper.net [193.110.55.11]) by slice.pfrc.org (Postfix) with ESMTPSA id 83F991E36F; Wed, 22 Jul 2015 04:39:44 -0400 (EDT)
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: text/plain; charset="utf-8"
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <etPan.55af51be.69dfac96.36f@corretto.local>
Date: Wed, 22 Jul 2015 10:37:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8EC92E0-DDF1-4909-9188-ADA655A2C838@pfrc.org>
References: <E4CCDE37-90A5-4ED5-8E85-3DAD595347C0@pfrc.org> <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <AE597A9E-B8D5-4E7B-A292-6E1671BD5862@pfrc.org> <2188_1437400730_55ACFE9A_2188_4362_1_9E32478DFA9976438E7A22F69B08FF92166A0CC7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <23933303-B805-495D-AF0E-9305AED39F0A@pfrc.org> <26470_1437402600_55AD05E8_26470_6250_3_9E32478DFA9976438E7A22F69B08FF92166A0D94@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <etPan.55ae5784.52673c74.36f@corretto.local> <23963_1437493971_55AE6AD3_23963_745_1_9E32478DFA9976438E7A22F69B08FF92166A33EC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <etPan.55ae8fbf.2ac767e3.36f@corretto.local> <18774_1437550328_55AF46F8_18774_5612_26_9E32478DFA9976438E7A22F69B08FF92166A3667@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <20150722073931.GB30425@puck.nether.net> <etPan.55af51be.69dfac96.36f@corretto.local>
To: Rob Shakir <rjs@rob.sh>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/iTaSjtfHYouoZSluICFjZow98UE>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 08:37:44 -0000

> On Jul 22, 2015, at 10:18 AM, Rob Shakir <rjs@rob.sh> wrote:
> 
> The way that we have tried to approach these things with the OpenConfig initiated models is “what is the way that we use this feature” - and then try and design the way that the model works around this.
> 
> To me, it seems like I want to be able to explicitly control whether something that I am using as a local route marker (‘colour’) is propagated to any of my neighbours via a particular routing protocol - otherwise, it takes on other semantics that I might not intend it to do.
> 
> In the local-routing [0] module, we use ‘tag’ as a protocol-agnostic way to mark particular routes — and then when these locally generated routes are imported into other protocols, then attributes for those protocols can be set (e.g., BGP community etc.). It strikes me that we should have something similar in each protocol export policy that says match on the local ‘tag’/‘colour’ and set protocol-tag value X (or even a switch that says ‘propagate tag’ assuming that the colour type can be mapped to the protocol tag type). 
> 
> I’d really like to separate local ‘tag’/‘colour’ from ‘tag’ within any particular protocol.

This is the substance of my suggested separate attribute rather than using "tag".  I'm quite aware of operators using tag for this purpose, but it has impact in protocol and redistribution depending on implementation.  

There is some advantage to simply picking a similar attribute in an abstract fashion and letting a vendor choose where it goes to in the implementation.

-- Jeff