Subject: [GROW] Proposing an alternative behaviour for BGP-4 in case of update corruption

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Sat, 3 Jul 2010 08:14:00 +0200

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
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 04 Jul 2010 12:17:52 +0200

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.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow