IETF Logo Mail Archive

Re: [Idr] draft-scholl-idr-advisory-00

Robert Raszuk <robert@raszuk.net> Wed, 25 March 2009 16:59 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F1B3A677D for <idr@core3.amsl.com>; Wed, 25 Mar 2009 09:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9JuvHZmFg9t for <idr@core3.amsl.com>; Wed, 25 Mar 2009 09:59:48 -0700 (PDT)
Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 24BDD3A67FD for <idr@ietf.org>; Wed, 25 Mar 2009 09:59:48 -0700 (PDT)
Received: (qmail 27095 invoked by uid 399); 25 Mar 2009 17:00:40 -0000
Received: from unknown (HELO ?192.168.1.100?) (83.5.240.237) by mail37.opentransfer.com with SMTP; 25 Mar 2009 17:00:40 -0000
Message-ID: <49CA6334.9030100@raszuk.net>
Date: Wed, 25 Mar 2009 10:00:36 -0700
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Elmar K. Bins" <elmi@4ever.de>
References: <20090325151253.GN74388@ronin.4ever.de> <22087C66F061B24EA008D146B7E91643042139C2@gaalpa1msgusr73.ITServices.sbc.com> <20090325164820.GO74388@ronin.4ever.de>
In-Reply-To: <20090325164820.GO74388@ronin.4ever.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: idr@ietf.org
Subject: Re: [Idr] draft-scholl-idr-advisory-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2009 16:59:49 -0000

Hi Elmar,

>   - this isn't routing info being transmitted (anyone want to
>     introduce the like in OSPF or ISIS?) and thus doesn't belong
>     in BGP transmissions

Actually on this you are not fully right. The amount of non routing 
information carried in IGPs today is huge :) Look at the mpls traffic 
eng alone ...

Perhaps let me suggest analogy to this solution from the IGP world. In 
IGP just for reuse of good IGP flooding there is OSPF transport instance 
defined draft-ietf-ospf-transport-instance They came with this idea too 
late and have already bunch of non routing stuff carrier in the routing 
instance.

Perhaps let's just do things right in BGP to start with. Why not to 
define a BGP-CI (communication instance) and use it for exchange of such 
advisory information without any impact to routing ?

 From operator's point of view if the need is so strong (in which I 
don't fully believe) it would be fully transparent. For implementations 
as well as for mitigation of the impact much safer yet still allowing 
the very same functionality (or in fact more :) as proposed originally.

Comments ?
R.

v2.23.0 | Report a Bug | By Email