I've read this draft and I think it is useful and ready to proceed.
Two minor comments:

In section 4, it may be useful to specifically note the need for a flag, trap, 
or other notification method (to the user, rather than to the neighbor) to 
identify when BGP is in the process of recovering RIB consistency, including 
which routes are considered inconsistent (if this info is available). While 
section 6 discusses the need for more information about the state of BGP when 
it is recovering from these errors, I saw no reference to this specific item. 
Since this is likely to be a transient state, it is also helpful to log this 
information to aid in root cause analysis of transient problems.

Also, there are a lot of uses of RFC2119 words in ways that could be 
interpreted as normative despite the lack of a reference to 2119. It may be 
useful to either go ahead and make them so (all caps, include RFC2119 
boilerplate) or to consider alternate words to avoid confusion. While this is 
an informational document and not a protocol specification, there are a lot of 
specific requirements of what we are expecting changes to the implementation to 
do and not do such that normative words would likely be helpful both to 
implementers and to those who may follow this draft with one to make protocol 
changes to address the requirements set forth.

Thanks,

Wes George




> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Christopher Morrow
> Sent: Monday, June 11, 2012 4:22 PM
> To: [email protected]; [email protected] [email protected]
> Subject: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04
>
> 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

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to