Subject: Re: Last Call: <draft-ietf-grow-ops-reqs-for-bgp-error-handling-05.txt> (Operational Requirements for Enhanced Error Handling Behaviour in BGP-4) to Informational RFC

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 31 Aug 2012 16:56:27 +0200

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 <[email-masked]> 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
> [email-masked] mailing lists by 2012-09-13. Exceptionally, comments may be
> sent to [email-masked] 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.
>
>
>