[Idr] [Technical Errata Reported] RFC4456 (3898)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 24 February 2014 07:47 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C891A0708 for <idr@ietfa.amsl.com>; Sun, 23 Feb 2014 23:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.251
X-Spam-Level:
X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1Ld9ErG6iDx for <idr@ietfa.amsl.com>; Sun, 23 Feb 2014 23:47:46 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1421A0361 for <idr@ietf.org>; Sun, 23 Feb 2014 23:47:46 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 12B1E7FC39D; Sun, 23 Feb 2014 23:47:45 -0800 (PST)
To: tbates@cisco.com, enkechen@cisco.com, rchandra@sonoasystems.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140224074745.12B1E7FC39D@rfc-editor.org>
Date: Sun, 23 Feb 2014 23:47:45 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/idr/pP5MegQbCo4tb3RjeCDvE2jLaaY
X-Mailman-Approved-At: Mon, 24 Feb 2014 08:12:44 -0800
Cc: guban@microsoft.com, rfc-editor@rfc-editor.org, idr@ietf.org
Subject: [Idr] [Technical Errata Reported] RFC4456 (3898)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 07:47:47 -0000

The following errata report has been submitted for RFC4456,
"BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4456&eid=3898

--------------------------------------
Type: Technical
Reported by: Gunjan Bansal <guban@microsoft.com>

Section: 8

Original Text
-------------
ORIGINATOR_ID

   ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
   code 9.  This attribute is 4 bytes long and it will be created by an
   RR in reflecting a route.  This attribute will carry the BGP
   Identifier of the originator of the route in the local AS.  A BGP
   speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already
   exists.  A router that recognizes the ORIGINATOR_ID attribute SHOULD
   ignore a route received with its BGP Identifier as the ORIGINATOR_ID.


CLUSTER_LIST

   CLUSTER_LIST is a new, optional, non-transitive BGP attribute of Type
   code 10.  It is a sequence of CLUSTER_ID values representing the
   reflection path that the route has passed.

   When an RR reflects a route, it MUST prepend the local CLUSTER_ID to
   the CLUSTER_LIST.  If the CLUSTER_LIST is empty, it MUST create a new
   one.  Using this attribute an RR can identify if the routing
   information has looped back to the same cluster due to
   misconfiguration.  If the local CLUSTER_ID is found in the
   CLUSTER_LIST, the advertisement received SHOULD be ignored.


Corrected Text
--------------


Notes
-----
Although the guideline exists for the "egress" reflected routes (RR should create ORIGINATOR_ID if none exists, prepend its own ClusterId in CLUSTER_LIST), there is no guideline on how the routes received from iBGP peers be treated if "only one" attribute (ORIGINATOR_ID or CLUSTER_LIST) is present. 
Should such routes be dropped (Considering them as a malformed routes ?)

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4456 (draft-ietf-idr-rfc2796bis-02)
--------------------------------------
Title               : BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
Publication Date    : April 2006
Author(s)           : T. Bates, E. Chen, R. Chandra
Category            : DRAFT STANDARD
Source              : Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG