Reply to your request dated 30/08/2012 Draft Reviewed By: Abdussalam Baryun (AB) Dated: 31/08/2012 Reviewer Comment AB1: Editorial. ++++++++++++++++++++++++++++++++++++++++++++++++++++ Overall the reviewer felt that this Informational I-D is difficult to read/understand. Requirement level language [RFC2119] is not used, while this I-D discusses; *requirements* of BGP error handling. ---------------------------------------------------------------------------------------------------- Page 3> Whilst a number of Internet Drafts have been written to begin to enhance the behaviour of BGP-4 in terms of the handling of erroneous messages, AB> please refer to those I-Ds within the paragraph AB> what is PE device? Page 4> within a single sub-topology or service. AB> what is sub-topology? Do you mean subnet or domain! Page 4-5> Both within Internet and multi-service routing architectures, a number of BGP sessions propagate a large proportion of the required routing information for network operation. For Internet routing, these are typically BGP sessions which propagate the global routing table to an AS - failure of these sessions may have a large impact on network service, based on a single erroneous update. In an multiservice environment, typical deployments utilise a small number of core-facing BGP sessions, typically towards route reflector devices. Failure of these sessions may also result in a large impact to network operation. AB> BGP sessions don’t propagate within architectures, but within networks. AB> “typically BGP sessions which propagate the global routing Table to …” not clear. AB> amend “In an multiservice” to “In a multi-service” ------------------------------------------------------------------------------- <This is not the end of the comments> Best Regards, AB --------------------------------------------------------------------------------------- This message and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. This message is in compliance with the IETF regulations. --------------------------------------------------------------------------------------- On 8/30/12, The IESG <iesg-secretary@xxxxxxxx> wrote: > > The IESG has received a request from the Global Routing Operations WG > (grow) to consider the following document: > - 'Operational Requirements for Enhanced Error Handling Behaviour in > BGP-4' > <draft-ietf-grow-ops-reqs-for-bgp-error-handling-05.txt> as > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2012-09-13. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > 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. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-grow-ops-reqs-for-bgp-error-handling/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-grow-ops-reqs-for-bgp-error-handling/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > >