Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

Florian Weimer <fw@deneb.enyo.de> Fri, 12 December 2008 08:11 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61F93A6A9C; Fri, 12 Dec 2008 00:11:31 -0800 (PST)
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 9D5053A69EC for <idr@core3.amsl.com>; Fri, 12 Dec 2008 00:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.206
X-Spam-Level:
X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 qV03Yh3OuLa3 for <idr@core3.amsl.com>; Fri, 12 Dec 2008 00:11:28 -0800 (PST)
Received: from mail.enyo.de (mail.enyo.de [IPv6:2001:14b0:202:1::a7]) by core3.amsl.com (Postfix) with ESMTP id AF78A3A6A9C for <idr@ietf.org>; Fri, 12 Dec 2008 00:11:28 -0800 (PST)
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1LB37A-0006FT-GH; Fri, 12 Dec 2008 09:11:12 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from <fw@deneb.enyo.de>) id 1LB379-0002U9-H7; Fri, 12 Dec 2008 09:11:11 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: "John G. Scudder" <jgs@juniper.net>
References: <CD705FABA8532448AA1FB7A96C88FF140898F8A4@emailbng1.jnpr.net> <4D86C4C6-F7CD-46B9-ABBE-04530F4D1278@juniper.net>
Date: Fri, 12 Dec 2008 09:11:11 +0100
In-Reply-To: <4D86C4C6-F7CD-46B9-ABBE-04530F4D1278@juniper.net> (John G. Scudder's message of "Thu, 11 Dec 2008 13:36:21 -0500")
Message-ID: <87tz99lso0.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Cc: skh@nexthop.com, idr@ietf.org, Yakov Rekhter <yakov@juniper.net>, tony.li@tony.li, Quaizar Vohra <qv@juniper.net>
Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

* John G. Scudder:

> There are well-known correctness problems with simply discarding an
> UPDATE.  This gets discussed on the list every few years, every time
> some implementation bug crops up which causes a lot of NOTIFICATIONS.
> To date, the WG has resisted the temptation to compromise the
> protocol's correctness.

Discarding the UPDATE is probably not a good idea.  Ignoring the
option (and propagating it, just to be sure) should be sufficient.

> Can anyone offer an explanation of what it's supposed to mean that the
> attribute MUST be discarded given that the section also says that
> you're going to send a NOTIFICATION and tear down the entire session?
> Seems as though the clause "the attribute MUST be discarded" should
> itself be discarded.

The update could be propagated further just before the session is torn
down.
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr