[Idr] Shepherd Writeup for draft-ietf-idr-add-paths-10
"Russ White" <russw@riw.us> Fri, 10 April 2015 14:07 UTC
Return-Path: <russw@riw.us>
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 BF3121B367D for <idr@ietfa.amsl.com>; Fri, 10 Apr 2015 07:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Cv48DBLjiXLn for <idr@ietfa.amsl.com>; Fri, 10 Apr 2015 07:07:23 -0700 (PDT)
Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9BE1B367C for <idr@ietf.org>; Fri, 10 Apr 2015 07:07:23 -0700 (PDT)
Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:64613 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from <russw@riw.us>) id 1YgZac-0000Ao-4E for idr@ietf.org; Fri, 10 Apr 2015 14:07:22 +0000
From: Russ White <russw@riw.us>
To: 'idr wg' <idr@ietf.org>
Date: Fri, 10 Apr 2015 10:07:16 -0400
Message-ID: <02a201d07397$a737eae0$f5a7c0a0$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdBzl43Ss1pfx/rWRBSBQpmkBPVfow==
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.riw.us
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/tVOac9UQiUC9cr90EKiZIREdYXM>
Subject: [Idr] Shepherd Writeup for draft-ietf-idr-add-paths-10
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: Fri, 10 Apr 2015 14:07:25 -0000
Y'all -- Below is the shepherds writeup for this draft. Comments welcome. Russ == 1. Summary The document shepherd is Russ White. The responsible Area Director is Alvaro Retana. This document extends BGP so a BGP speaker can advertise multiple paths rather than a single best path to peers. It proposes a new NLRI encoding extension to carry a Path Identifier, and a new capability to negotiate the carrying of additional paths. These additional paths are intended to used to eliminate path oscillation, in a number of situations where advertising multiple paths can improve network convergence, and in a number of situations where BGP is used in "high fan out" equal cost multipath network topologies to provide optimal path availability. 2. Review and Consensus The extension to BGP is straightforward; while there has been some difficulty in coming to consensus on the benefits provided versus the difficulty in implementing the extensions, the value of the concept has been proven in deployment scenarios and use cases enough to justify moving forward with this document. The document has passed through ten revisions over a number of years, and has been discussed both on and off the relevant lists by a number of experts in the development and deployment of BGP. The working group has reached concensus on moving this document forward at this point. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. 4. Other Points There are no normative downrefs in this document. There are minimal additions to the YANG model based on the extensions described in this draft; as those models are not yet standardized, it is expected that these will be included in these models as they are standardized. Changes to the IANA registries required for the new options described in the draft have already been properly assigned and recorded.