Re: New Version Notification for draft-bashandy-rtgwg-bgp-pic-00.txt

["Ahmed Bashandy (bashandy)" <[e-mail]>]

Correct. It is similar to  "draft-rtgwg-bgp-pic-02"

Let me reproduce your questions here for convenience of everyone


 > <[e-mail]> 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, [e-mail] 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:[e-mail]] *On Behalf Of *Ahmed 
> Bashandy (bashandy)
> *Sent:* Wednesday, October 14, 2015 11:12 AM
> *To:* [e-mail]
> *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: *
>
> 	
>
> <[e-mail]> <mailto:[e-mail]>
>
> *To: *
>
> 	
>
> Clarence Filsfils <[e-mail]> <mailto:[e-mail]>, 
> Ahmed Bashandy <[e-mail]> <mailto:[e-mail]>, 
> Prodosh Mohapatra <[e-mail]> <mailto:[e-mail]>, 
> "Pradosh Mohapatra" <[e-mail]> <mailto:[e-mail]>
>
> 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.