Correct. It is similar to "draft-rtgwg-bgp-pic-02"
Let me reproduce your questions here for convenience of everyone
> <[email protected]> Mon, 22 October 2012 14:28 UTCShow header
> 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
Let me try to answer first the 1st question
The BGP-PIC architecture does not dictate any number of hierarchy
levels. For the specific case you mentioned above, if the platform
supports 3 levels of hierarchy then it will get the full benefit of the
BGP-PIC architecture through modifying the minimum number of pathlists.
But let's say it supports only 2 levels. IN that case, the forwarding
chain will have to be "flattened" somehow down to 2 levels, thereby
increasing the number of pathlists that needs to be modified, let's say
when an IGP path gets lost. How the flattening will occur is totally up
to the platform. The reason is that at the flattened level there will be
a need to push two labels. So the actual forwarding chain is very
platform specific
For the second question
What BGP-PIC is proposing is to construct the forwarding chain in a
shared and hierarchical fashion so the that the FIB manager can update
the forwarding chain in a time complexity that does not depend on the
number of BGP leaves (or PW wires) and without waiting for the control
plane to react. The actual calculation of the paths (primary and/or
backup) is a routing protocol functionality that is really beyond the
scope of BGP-PIC
For the best external case, or any backup path calculation mechanism,
there is a need to somehow tell the backup PE not to reroute traffic
arriving from the core back to the core.
For the PE-CE link failure, there are few proposals and implementations
out there to handle this scenario in a loop free fashion. For example,
the router with best external can program the BGP label to always point
to the external path. Hence packets arriving from the core will never be
looped back to the core. Such solution integrates smoothly into the
BGP-PIC architecture
For the unlabeled case a simple solution is to push an additional label
when sending a packet to the PE with the best external. So basically,
there will be one additional label pushed for a short period until the
network converges. At the PE with best external, that label will never
loop the packet back to the core
Both the label and unlabeled solution integrate smoothly with the
BGP-PIC architecture
Thanks
Ahmed
On 10/14/2015 2:38 AM, [email protected] wrote:
Hi Ahmed,
This draft is a mostly repost of draft-rtgwg-bgp-pic-02.txt, that I
commented at the time but never get an answer.
Although after 3 years Iām afraid that I lost the context, in
principle I would welcome an answer
https://mailarchive.ietf.org/arch/msg/rtgwg/HrCYUfrUht7L8bBqqqYS-zqt7SA
I also assume that the IPR is equally applicable
https://mailarchive.ietf.org/arch/msg/ipr-announce/Ff0cZMBybeBfn3o-TxyUqLDYE8Q
but the datatracker has no record of it
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bashandy-rtgwg-bgp-pic
Thanks,
Bruno
*From:*rtgwg [mailto:[email protected]] *On Behalf Of *Ahmed
Bashandy (bashandy)
*Sent:* Wednesday, October 14, 2015 11:12 AM
*To:* [email protected]
*Cc:* Pradosh Mohapatra
*Subject:* Fwd: New Version Notification for
draft-bashandy-rtgwg-bgp-pic-00.txt
Hi
This a draft that explains the architecture of BGP Prefix Independent
Convergence and how the architecture allows a router achieve
convergence after internal and/or external topology changes that does
not depend on the number BGP prefixes on a router
Please take a look
All comments are most welcomed
Thanks
Ahmed
-------- Original Message --------
*Subject: *
New Version Notification for draft-bashandy-rtgwg-bgp-pic-00.txt
*Date: *
Wed, 14 Oct 2015 02:04:14 -0700
*From: *
<[email protected]> <mailto:[email protected]>
*To: *
Clarence Filsfils <[email protected]> <mailto:[email protected]>,
Ahmed Bashandy <[email protected]> <mailto:[email protected]>,
Prodosh Mohapatra <[email protected]> <mailto:[email protected]>,
"Pradosh Mohapatra" <[email protected]> <mailto:[email protected]>
A new version of I-D, draft-bashandy-rtgwg-bgp-pic-00.txt
has been successfully submitted by Ahmed Bashandy and posted to the
IETF repository.
Name: draft-bashandy-rtgwg-bgp-pic
Revision: 00
Title: Abstract
Document date: 2015-10-12
Group: Individual Submission
Pages: 19
URL:
https://www.ietf.org/internet-drafts/draft-bashandy-rtgwg-bgp-pic-00.txt
Status: https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-bgp-pic/
Htmlized: https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00
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
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
_________________________________________________________________________________________________________________________
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,
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, 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
