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

Jeffrey Haas <jhaas@pfrc.org> Mon, 27 July 2015 19:10 UTC

Return-Path: <jhaas@slice.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 86E301B3282 for <rtgwg@ietfa.amsl.com>; Mon, 27 Jul 2015 12:10:14 -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 mG77KCxii7pS for <rtgwg@ietfa.amsl.com>; Mon, 27 Jul 2015 12:10:13 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 173E91B3299 for <rtgwg@ietf.org>; Mon, 27 Jul 2015 12:09:53 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 321251E377; Mon, 27 Jul 2015 15:12:03 -0400 (EDT)
Date: Mon, 27 Jul 2015 15:12:03 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Acee Lindem (acee)" <acee@cisco.com>
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
Message-ID: <20150727191203.GA16809@pfrc.org>
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> <20150722073931.GB30425@puck.nether.net> <etPan.55af51be.69dfac96.36f@corretto.local> <9439_1437568985_55AF8FD9_9439_5180_1_9E32478DFA9976438E7A22F69B08FF92166A398C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <D1D97D09.29830%acee@cisco.com> <20150727155051.GF24197@pfrc.org> <7A2D9D5A-CCAF-4C8B-B2BC-C8DC1F05F5AF@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7A2D9D5A-CCAF-4C8B-B2BC-C8DC1F05F5AF@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/7ldgUU5hdTtRtnwCeADYz4e5cNw>
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: Mon, 27 Jul 2015 19:10:14 -0000

Acee,

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
> > correctly.
> 
> 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.

-- Jeff