It so happens that we are in the middle of an extended WG adoption debate for 
draft-uttaro-idr-bgp-persistence-01 over at IDR. The problem statement from 
that draft is kind of buried in S. 1.1:

   BGP Persistence targets the different use case of a catastrophic
   failure when the BGP control plane can remain down for a longer time
   (e.g. hours).

This relates to draft-ietf-grow-ops-reqs-for-bgp-error-handling insofar as 
draft-uttaro specifically proposes an extension to BGP error handling and (as 
far as I can tell) its problem statement is not addressed in 
reqs-for-bgp-error-handling.

While I don't think it would be reasonable to ask reqs-for-bgp-error-handling 
to address every imaginable error mode, the fact that this is a current active 
topic in IDR does suggest it might be worth speaking to this one.

--John

P.S.: It's possible I missed a relevant section in reqs-for-bgp-error-handling, 
in which case please do point it out.

On Jun 11, 2012, at 4:21 PM, Christopher Morrow wrote:

> Hello GROW-WG folk,
> Please take this message as the start of a 2 week, ending 6/25/2012
> (June 25, 2012) WGLC for the subject draft, link to current version:
>  
> <http://www.ietf.org/internet-drafts/draft-ietf-grow-ops-reqs-for-bgp-error-handling-04.txt>
> 
> Abstract:
> "BGP-4 is utilised as a key intra- and inter-Autonomous System routing
>   protocol in modern IP networks.  The failure modes as defined by the
>   original protocol standards are based on a number of assumptions
>   around the impact of session failure.  Numerous incidents both in the
>   global Internet routing table and within Service Provider networks
>   have been caused by strict handling of a single invalid UPDATE
>   message causing large-scale failures in one or more Autonomous
>   Systems.
> 
>   This memo describes the current use of BGP-4 within Service Provider
>   networks, and outlines a set of requirements for further work to
>   enhance the mechanisms available to a BGP-4 implementation when
>   erroneous data is detected.  Whilst this document does not provide
>   specification of any standard, it is intended as an overview of a set
>   of enhancements to BGP-4 to improve the protocol's robustness to suit
>   its current deployment."
> 
> -Chris
> co-chair
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to