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: [email protected] [mailto:[email protected]] On Behalf Of Ahmed 
Bashandy
Sent: Monday, October 01, 2012 4:51 PM
To: [email protected]
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: 
<[email protected]>
Reply-To: 
<[email protected]>
To: 
<[email protected]>

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
[email protected]
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.

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to