Re: [GROW] Proposing an alternative behaviour for BGP-4 in case of update corruption
Robert Raszuk <raszuk@cisco.com> Sun, 04 July 2010 10:17 UTC
Return-Path: <raszuk@cisco.com>
X-Original-To: grow@core3.amsl.com
Delivered-To: grow@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC02B3A68B3 for <grow@core3.amsl.com>; Sun, 4 Jul 2010 03:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
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 UKFqJl+BD5Z8 for <grow@core3.amsl.com>; Sun, 4 Jul 2010 03:17:53 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E2E043A68A9 for <grow@ietf.org>; Sun, 4 Jul 2010 03:17:53 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EALf8L0yrR7H+/2dsb2JhbACDHI9njGVxoymBegsBhyKPXYEpgwpyBIg6
X-IronPort-AV: E=Sophos;i="4.53,534,1272844800"; d="scan'208";a="153596027"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 04 Jul 2010 10:17:54 +0000
Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o64AHqeS020455; Sun, 4 Jul 2010 10:17:53 GMT
Message-ID: <4C305FD0.90605@cisco.com>
Date: Sun, 04 Jul 2010 12:17:52 +0200
From: Robert Raszuk <raszuk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: grow@ietf.org, paaguti@gmail.com
References: <AANLkTik0K29l-v-JzkNjZXqeq6Zc2nbuhpWJEFX4o-Gi@mail.gmail.com>
In-Reply-To: <AANLkTik0K29l-v-JzkNjZXqeq6Zc2nbuhpWJEFX4o-Gi@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [GROW] Proposing an alternative behaviour for BGP-4 in case of update corruption
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@cisco.com
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jul 2010 10:17:54 -0000
Hi Pedro, > This is my first email to the list. Welcome to GROW WG. While I don't to discourage you I would like to send some hints and send you few comments: * In general sending any draft to the list has no procedural value. You need to format it correctly and submit using IETF document submission tool: https://datatracker.ietf.org/idst/upload.cgi It is just impossible to version track emails. * The idea which you have have already been discussed number of times in IDR WG. There are mature proposals in this area too. Example: http://tools.ietf.org/html/draft-nalawade-bgp-soft-notify-01 http://tools.ietf.org/html/draft-scudder-idr-optional-transitive-01 While it is ok to send similar proposals a bit of attempt needs to be made to compare the existing document and analyze what is different or what is missing in there. * More technical points: > When a BGP‐4 speaker sends a malformed update to its neighbours: > > 1. the neighbours MUST withdraw from their routing table the prefix > or prefixes contained in the malformed update. Clearly as discussed in draft-scudder-idr-optional-transitive-01 that is not required in all cases. > The behaviour described above has side effects on BGP‐4 sessions > carried multi‐protocol information (e.g. IPv6, MPLS‐VPNs, etc.) In > this case, the effect propagates to all address families supported by > the BGP‐4 session. In the coexistence period of IPv4 and IPv6, this > behaviour could be used to attack the IPv6 infrastructure from the > IPv4 world. That could be addressed by multisession proposal. http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-05 > IANA Considerations > This document has no actions for IANA. That is clearly wrong. You are defining a new packet format for Soft Notification. It is not clear at all from your draft how are you going to carry it in BGP today. Also IMHO capability exchange are required here. Cheers, R. > HI, > > This is my first email to the list. As part of my PhD work, I have > been analysing the latest routing storms and > come up with an alternative that would make life much easier for all of us. > > Cheers,/PA > Pedro A Aranda > paaguti@hotmail.com > > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow
- [GROW] Proposing an alternative behaviour for BGP… Pedro Andres Aranda Gutierrez
- Re: [GROW] Proposing an alternative behaviour for… Robert Raszuk