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