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

Rob Shakir <> Wed, 22 July 2015 08:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 059DB1A0032 for <>; Wed, 22 Jul 2015 01:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KqZ9GxLO1x6n for <>; Wed, 22 Jul 2015 01:18:15 -0700 (PDT)
Received: from ( [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 379B91A0137 for <>; Wed, 22 Jul 2015 01:18:13 -0700 (PDT)
Received: from [] (helo=corretto.local) by with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1ZHpDy-0003et-BZ; Wed, 22 Jul 2015 09:17:58 +0100
Date: Wed, 22 Jul 2015 09:18:06 +0100
From: Rob Shakir <>
To: Jon Mitchell <>,
Message-ID: <etPan.55af51be.69dfac96.36f@corretto.local>
In-Reply-To: <>
References: <> <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <2188_1437400730_55ACFE9A_2188_4362_1_9E32478DFA9976438E7A22F69B08FF92166A0CC7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <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> <>
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
X-Mailer: Airmail (303)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55af51be_505a3cb8_36f"
Archived-At: <>
Cc: "=?utf-8?Q?" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jul 2015 08:18:18 -0000

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.



On 22 July 2015 at 08:39:55, Jon Mitchell ( wrote:

On 22/07/15 07:32 +0000, wrote:  
> Hi Rob,  
> Agree with the case you presented, IMO, we may provide some guidance to implementation on the behavior to use when a local-tag is translated to a protocol-tag and translation is not possible due to protocol-tag constraint (for example “do not copy tag”).  

I'd also point out that some implementations (even from the same  
vendor!) have different behavior on whether to default copy up from  
lcoal tag to protocol tag even when it is possible when redistribution  
is configured.