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

"Acee Lindem (acee)" <> Mon, 27 July 2015 21:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F08891B33C5 for <>; Mon, 27 Jul 2015 14:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e0Y2LI1W_hJX for <>; Mon, 27 Jul 2015 14:24:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D366B1B3499 for <>; Mon, 27 Jul 2015 14:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11530; q=dns/txt; s=iport; t=1438032289; x=1439241889; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9FhIQf9CgHRZo8pGHC3LuDgVdgChLnbn9ue+tsp1MZ0=; b=QTY9zTC3V6ThEqmAgFjap3uZrVo+12Jz2vcszseWcURlVvC3tbcGbF5u Cud1328mcdQk6P/g+jnOyJVXSPlex5L+kKWGp0WDuj0h80cxb6rnosS9B IFiGUfanVudo1/ZseqBnrUE1J/sG7pnoZuKiy6HHoZ+/PZDWOsERjBU9t A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.15,557,1432598400"; d="scan'208,217"; a="13562681"
Received: from ([]) by with ESMTP; 27 Jul 2015 21:24:48 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6RLOmV1007129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 21:24:49 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 16:24:48 -0500
From: "Acee Lindem (acee)" <>
To: Jeffrey Haas <>
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
Thread-Topic: Comments on draft-shaikh-rtgwg-policy-model
Date: Mon, 27 Jul 2015 21:24:47 +0000
Message-ID: <>
References: <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> <> <etPan.55af51be.69dfac96.36f@corretto.local> <9439_1437568985_55AF8FD9_9439_5180_1_9E32478DFA9976438E7A22F69B08FF92166A398C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CCDC5C14A8B04B06998B4E9CFD920D09ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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: Mon, 27 Jul 2015 21:24:52 -0000

Hey Jeff,

On Jul 27, 2015, at 3:12 PM, Jeffrey Haas <<>> wrote:


On Mon, Jul 27, 2015 at 05:46:48PM +0000, Acee Lindem (acee) wrote:
On Sun, Jul 26, 2015 at 05:49:28PM +0000, Acee Lindem (acee) wrote:
What do you think the model should say about redistribution of tags that are
out of range of the protocol in question?

This is one reason why I believe the redistribution or import policies
should be within the protocol themselves rather than external to the
protocol. There is less to constrain if you have per protocol
redistribution. Now, dependent on where we end up with factoring the
common policy, there may still be stuff that needs to be checked.

That's really where we're heading with regard to this model.  While BGP is
obviously the first target, this is also the beginnings of a fundamental
policy algebra that multiple protocols may share.

I'm not saying that this isn't a "solved" issue in any number of
implementations.  I suspect results go from truncation all the way through
blocking the redistribution depending on the protocol.  Or perhaps even the
protocol does the wrong thing and crashes the Internet. :-)

But since we're effectively working on this as an IETF common component for
yang, I do believe we need to figure out what it does.

What do you think, if anything, the model should have in the way of
constraints on this scenario?  Note that this is a leading question since we
don't get constraints on operational state until yang 1.1, if I recall

I’m not sure why we need constraints for operational data in this case.

By example:
For a static route, if tag is set and tag is 0 and 0 is illegal for RIP, the
operational state of the static route is tag=0.  It is possible for a
redistribution policy for static into RIP to detect an invalid operational
constraint and "do something".

Static is perhaps a weak example since one could model this against the
configuration state, but once you move the example into a learned protocol
such as OSPF, we're back to this problem.

I think we should have one full-range uint32 tag-type that is supported by all protocols, installed in the RIBs, and included in the RIB operational state. I like the current definition, only it would be good if we could limit the hex-string to the range 0x0 - 0xffffffff since, as you also pointed out, only 32 bits tags have been implemented. Note that I noted this as well and did not include 64-bit tags in

typedef tag-type {
       type union {
         type uint32;
         type yang:hex-string;
       description "type for expressing route tags on a local system,
       including IS-IS and OSPF; may be expressed as either decimal or
       hexidecimal integer";
         "RFC 2178 OSPF Version 2
         RFC 5130 A Policy Control Mechanism in IS-IS Using
         Administrative Tags";

There still is a consideration though - how many tags a particular vendor supports in a tag-set? Right now, I believe it is 1 or 2 ;^)


-- Jeff