Re: IDR WG Last Call

Jeffrey Haas <jhaas@nexthop.com> Tue, 15 January 2002 21:13 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09203 for <idr-archive@nic.merit.edu>; Tue, 15 Jan 2002 16:13:31 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 79C9F9126A; Tue, 15 Jan 2002 16:12:51 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49ADA9126C; Tue, 15 Jan 2002 16:12:51 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 499CE9126A for <idr@trapdoor.merit.edu>; Tue, 15 Jan 2002 16:12:50 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 242035DDCA; Tue, 15 Jan 2002 16:12:50 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 0A7A15DDA5 for <idr@merit.edu>; Tue, 15 Jan 2002 16:12:50 -0500 (EST)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FLCM398333; Tue, 15 Jan 2002 16:12:22 -0500 (EST) (envelope-from jhaas@nexthop.com)
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0FLCMa16574; Tue, 15 Jan 2002 16:12:22 -0500 (EST)
Date: Tue, 15 Jan 2002 16:12:22 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: Dave Thaler <dthaler@windows.microsoft.com>
Cc: Enke Chen <enke@redback.com>, idr@merit.edu
Subject: Re: IDR WG Last Call
Message-ID: <20020115161222.B16527@nexthop.com>
References: <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>; from dthaler@windows.microsoft.com on Tue, Jan 15, 2002 at 11:13:42AM -0800
X-NextHop-MailScanner: Found to be clean
Sender: owner-idr@merit.edu
Precedence: bulk

Dave,

On Tue, Jan 15, 2002 at 11:13:42AM -0800, Dave Thaler wrote:
> SAFI 3 was put in at operator's requests (Dorian, for one, I forget who
> else now).  They considered it a MUST to avoid doubling the routing
> table size and amount of BGP traffic when one's unicast and multicast
> topology are the same.
> 
> Before taking it out, you might want to check with Dorian.

While I agree that its nice in theory, you have the added difficulty
of having to maintain additional state for things such as WRD
and potentially awkward queue mechanisms for outgoing routes.
As such, you actually implement at least as much, if not more, 
infrastructure to deal with the additional overhead of having
a SAFI that covers the unicast+multicast case.

Additionally, policy is now a real pain - and very ambiguous in
the current spec.  If you say "accept unicast and multicast routes",
does that mean accept only SAFI 3 or SAFI's 1, 2 and 3?

As Sue has mentioned, treating them as bits works fine for these
three SAFI's.  But I'd rather not have to.

I'm not going to argue very hard for removing SAFI 3 - we already
implement it.  But there are complications that don't seem to be
accounted for with regards to its supposed information overhead reduction.

> -Dave

-- 
Jeff Haas 
NextHop Technologies