RE: I-D Action: draft-rtgwg-bgp-pic-00.txt

Hi Ahmed,

1) Multiple layer of BGP indirections
In addition to your 2 examples, could you please add an example with the seamless MPLS architecture where a VPN (BGP) routes is resolved using a RFC 3107 (BGP) routes, itself resolved using an IGP route. Hence 2 levels of indirections: BGP → BGP → IGP.
In the same vein, could the draft indicate the number of such indirection that an implementation compliant with your draft must support?

2) BGP Best external
Could you please elaborate on how PIC edge behaves for non labeled BGP routes when BGP best external is used? In particular, a priori, it looks to me that the backup egress PE would loop back to packets to the nominal egress PE (which would itself loop it back to the backup PE).

Thanks,
Regards,
Bruno

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy
Sent: Monday, October 01, 2012 4:51 PM
To: rtgwg@ietf.org
Cc: Pradosh Mohapatra (pmohapat)
Subject: Fwd: I-D Action: draft-rtgwg-bgp-pic-00.txt

Hi,

This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design

All comments and suggestions are most welcomed

Thanks

Ahmed

-------- Original Message -------- 
Subject: 
I-D Action: draft-rtgwg-bgp-pic-00.txt
Date: 
Mon, 1 Oct 2012 07:08:38 -0700
From: 
<internet-drafts@ietf.org>
Reply-To: 
<internet-drafts@ietf.org>
To: 
<i-d-announce@ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Abstract
	Author(s)       : Ahmed Bashandy
                          Clarence Filsfils
                          Prodosh Mohapatra
	Filename        : draft-rtgwg-bgp-pic-00.txt
	Pages           : 19
	Date            : 2012-10-01

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 a technique 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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgwg-bgp-pic

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.