Re: [GROW] [Idr] Fwd: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04

Hi, folks:

It might help the discussion to refresh ourselves about several large 
outages in the last few years that prompted the work on the error 
handling requirements and solutions:

    o issue with AS4_PATH that resulted in session resets multiple hops 
away (two separate incidents)
    o session reset triggered by a single route with a new attribute

I remember that Rob had a presentation at the NANOG on the topic.

-- Enke

On 6/22/12 8:57 AM, Robert Raszuk wrote:
> Jim,
>
>> We could as easily without any change to BGP use BGP Persistence to
>> maintain the paths except for the ones that have the invalid
>> attribute.. This is the simpler method, has the benefit of not
>> changing BGP, or educating the world on the nuances of the changes
>> etc...
> +
>> Why wouldn't we simply let the session fail and then use BGP Persistence
>> or GR ;)
>
> Please observe that when the session is down you are not receiving 
> withdraws or new best paths for those "good" prefixes (maybe 99% of 
> them) which did not have any errors in their respective update messages.
>
> Equating it with persistence proposal is therefor highly incorrect.
>
>> I also do not fully understand "treat as withdraw" does this meant that
>> the peer who has received an update with P1-PN with malformed attr then
>> initiate a withdrawal to all of its peers?  Or simply assume that the
>> paths have been received as a message?  Some sample topologies as to how
>> this works would be a good addition to this section..
>
> The speaker reacting on an error which can be addressed by 
> "treat-as-withdraw" invalidates locally those prefixes received in the 
> update message, runs local best path and as result if no other path is 
> found withdraws those prefixes from all peers it has previously sent 
> them to.
>
>> I am not in support of solutions which create a scenario where BGP
>> cannot recover without human intervention.
>
> I think no one is. But we are - I think - not there yet for the 
> routers to automatically fix their bugs, but only automatically 
> signalling them the requested action ;(.
>
> > Nothing is going to get people's attention like a failed BGP
> > Session..
>
> True statement. But the entire assumption behind treat-as-withdraw is 
> that your ops scripts parse the syslog messages indicating the issue 
> to NOC with the same red color and buzz as bgp session down. Of course 
> you need to rework your ops scripts/alarms for that to happen.
>
> Rgs,
> R.
>
> PS.
>
> Note that if the main BGP session is down (like in the persistence 
> case) BGP Operational Messages can not any longer be exchanged between 
> peers as TCP connection could have been reset (if no multisession is 
> used and if we are talking about single SAFI). That just makes the 
> issue worse especially when you do not like to have humans intervention.
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr