[OSPF] scalability draft-shrivastava-ospf-flow-spec-01

"A. Przygienda" <prz@mail.zeta2.ch> Thu, 18 July 2013 15:39 UTC

Return-Path: <prz@mail.zeta2.ch>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DAA3A11E815F for <ospf@ietfa.amsl.com>; Thu, 18 Jul 2013 08:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ukQCkg-P6xAQ for <ospf@ietfa.amsl.com>; Thu, 18 Jul 2013 08:39:34 -0700 (PDT)
Received: from www.zeta2.ch (zux172-086.adsl.green.ch []) by ietfa.amsl.com (Postfix) with ESMTP id B828311E80FC for <ospf@ietf.org>; Thu, 18 Jul 2013 08:39:32 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r6IFatNh013118 for <ospf@ietf.org>; Thu, 18 Jul 2013 17:39:29 +0200
X-Virus-Scanned: amavisd-new at zeta2.ch
Received: from www.zeta2.ch ([]) by localhost (www.zeta2.ch []) (amavisd-new, port 10024) with LMTP id T5E4OUiPTatA for <ospf@ietf.org>; Thu, 18 Jul 2013 17:39:29 +0200 (CEST)
Received: from prz-aus-n56v.zeta2.ch (75-173-17-192.albq.qwest.net []) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r6IFdOIq013138 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ospf@ietf.org>; Thu, 18 Jul 2013 17:39:26 +0200
Message-ID: <51E80C26.8010709@zeta2.ch>
Date: Thu, 18 Jul 2013 09:39:18 -0600
From: "A. Przygienda" <prz@mail.zeta2.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: "'OSPF List'" <ospf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OSPF] scalability draft-shrivastava-ospf-flow-spec-01
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2013 15:39:40 -0000

Quick comment on draft-shrivastava-ospf-flow-spec-01 from my side after having looked @ it a while ago.

Generally, surely an interesting idea that will suffer from 2 problems I foresee but I don't see
it clearly spelled out:

. lots of routers not interested in the flowspecs will have to carry those in LSAs, especially with naive configuration.
	Flowspecs like this should be most useful on edges since they basically stand for policies and policies
	are an 'edge' or 'perimeter' problem in my mind (which is why the flowspec map so well onto BGP, it's
	basically an 'edge' protocol, rather than IGP protocol [well, RRs help to solve the IBGP problem
	obviously ;-) ])

	One possiblility is to write a scalability section with examples comparing to BGP and enlightening
	people about dangers of massive amount of flowspecs sloshing in areas, other is to start
	to think about 'edge-routers-lsa-distribution-scope' or something like this which will however
	lead to something like IBGP problems with meshes & so on. This is just brain-dumping, don't nail
	me whether this makes any sense when worked out.

. policies are applied in a 'directional' fashion normally, i.e. ingress or egress and I think that would need
	to be taken into account in the draft (yes, the prefix on the flow _should_ kind of determine together
	with source & so on the direction but it may not if underspecified).
	So some discussion of how to apply those specs
	per interface and per interface/adjacency direction (yeah, not a natural for OSPF) may be
	beneficial or it should
	be pointed out that the flowspecs are not 'directional'.  This point kind of got clearer in my mind
	after some discussions with Acee to give credit where credit is due.

--- tony