Request for WG adoption of draft-bashandy-rtgwg-bgp-pic-02.txt

"Ahmed Bashandy (bashandy)" <bashandy@cisco.com> Tue, 10 November 2015 00:25 UTC

Return-Path: <bashandy@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1441ACED9 for <rtgwg@ietfa.amsl.com>; Mon, 9 Nov 2015 16:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 7RQZd7hbjOhN for <rtgwg@ietfa.amsl.com>; Mon, 9 Nov 2015 16:25:29 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACED1ACED1 for <rtgwg@ietf.org>; Mon, 9 Nov 2015 16:25:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8750; q=dns/txt; s=iport; t=1447115129; x=1448324729; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=T4n40fBgrqaRqPNQPh1tVNtwcPqUP0Z+ezNEJYWx7Yc=; b=NwGRVXZeDu4vg6/3x5La91F/IkyjmqR/JkcnL+Ujm7u7x1dlLlx4LwUu YmBzbvQVk7h5zCbU9rdGzhkeUyAR98Gp/otXB9snScyAl4Fwc9JW0lsb6 3q7m2yBDh70hlGkYP/HF1zJr6ydU4tFSvug52+vS8OOre/PKI68IhySFy c=;
X-IronPort-AV: E=Sophos;i="5.20,267,1444694400"; d="scan'208,217";a="206699789"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 10 Nov 2015 00:25:28 +0000
Received: from [10.32.172.32] ([10.32.172.32]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tAA0PSMW014052; Tue, 10 Nov 2015 00:25:28 GMT
Message-ID: <56413977.1060100@cisco.com>
Date: Mon, 09 Nov 2015 16:25:27 -0800
From: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "jeff.tantsura@ericsson.com" <jeff.tantsura@ericsson.com>, Chris Bowers <cbowers@juniper.net>
Subject: Request for WG adoption of draft-bashandy-rtgwg-bgp-pic-02.txt
References: <20151110000559.13326.25820.idtracker@ietfa.amsl.com>
In-Reply-To: <20151110000559.13326.25820.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20151110000559.13326.25820.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------090308000200070201070107"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/k9ShmDJiP7WuOxpkZVvdRcq_804>
Cc: Pradosh Mohapatra <mpradosh@yahoo.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2015 00:25:31 -0000

Hi,

This is the latest version of the BGP-PIC draft that was presented on 
Nov/2/15 during the IETF-94 meeting in Yokohama
We have addressed the comments as follows:
- Added statements in multiple places, including the abstract, 
indicating the need for more than one BGP path
- Added example in Section 2.3.3 with illustrations in Figure 4,5,6 on 
how to handle a platform that does not support the required number of 
hierarchy levels.  Section 4.3 explains the gradual degradation of 
BGP-PIC benefit as a result of the reduced platform support
- For handling unlabeled traffic in case PE-CE failure, the last bullet 
in Section 4.2.2 indicates that an egress PE must always treat a core 
facing path as a backup path to avoid looping the packet in case of 
PE-CE link failure. The first statement in Section 5.1 indicates that 
the draft does not cover the failure of a CE node


We would like to request adoption of the draft.

Thanks

Ahmed



-------- Original Message --------
Subject: 	New Version Notification for draft-bashandy-rtgwg-bgp-pic-02.txt
Date: 	Mon, 9 Nov 2015 16:05:59 -0800
From: 	<internet-drafts@ietf.org>
To: 	Clarence Filsfils <cfilsfil@cisco.com>, Ahmed Bashandy 
<bashandy@cisco.com>, Prodosh Mohapatra <mpradosh@yahoo.com>, "Pradosh 
Mohapatra" <mpradosh@yahoo.com>



A new version of I-D, draft-bashandy-rtgwg-bgp-pic-02.txt
has been successfully submitted by Ahmed Bashandy and posted to the
IETF repository.

Name:		draft-bashandy-rtgwg-bgp-pic
Revision:	02
Title:		Abstract
Document date:	2015-11-09
Group:		Individual Submission
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-bashandy-rtgwg-bgp-pic-02.txt
Status:         https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-bgp-pic/
Htmlized:       https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-bgp-pic-02

Abstract:
In the network comprising thousands of iBGP peers exchanging millions
of routes, many routes are reachable via more than one path. Given
the large scaling targets, it is desirable to restore traffic after
failure in a time period that does not depend on the number of BGP
prefixes. In this document we proposed an architecture by which
traffic can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding chains in a
hierarchical manner and sharing forwarding elements among the maximum
possible number of routes. The proposed technique achieves prefix
independent convergence while ensuring incremental deployment,
complete transparency and automation, and zero management and
provisioning effort. It is noteworthy to mention that the benefits of
BGP-PIC are hinged on the existence of more than one path whether as
ECMP or primary-backup.

                                                                                   


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat