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

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

Bruno
Thanks a lot for all the comments:)

I agree with all what you mentioned below. So I submitted a new version

- For (1), I added Section 2.3.3 containing an example of "flattening" a 
3 level hierarchy into a 2 level hierarchy. In Section 4.3, I 
illustrated the gradual degradation of BGP-PIC benefit when the depth of 
the hierarchy is reduced. Section 6, "Dependency", mentions that the 
without the existence of enough levels of hierarchy, the benefit for 
BGP-PIC may be completely lost

- For (2), I modified section 6.2 to mention that the existence of a 
secondary path doesn't mean that it can be used as is without any 
additional processing. I preferred not  have any discussion regarding 
the useability of a secondary BGP path, because, in IMHO, this is a 
separate topic that can be quite involved.

Please take a look at the new version, specially the section 2.3.3 that 
gives an example of "flattened" forwarding chain. It can be found in
https://www.ietf.org/internet-drafts/draft-bashandy-rtgwg-bgp-pic-01.txt

Ahmed


On 10/16/2015 12:57 AM, [e-mail] wrote:
>
> Hi Ahmed,
>
> Thanks for your answer.
>
> First, to clarify, IMO the BGP PIC architecture is a clever solution 
> which addresses a real problem that had to be solved.
>
> Then I’m not commenting on the architecture itself but on the draft.
>
> Finally, I don’t think that we have technical disagreement. It’s more 
> an editorial point to unsure that the readers of the draft get the 
> whole picture and not get disappointed by a specific deployment of 
> router platform.
>
> 1) Regarding multiple level of BGP indirections, I agree that the BGP 
> PIC architecture work. But there is a problematic that IMO needs to be 
> described in the draft. The point is that for a SP, having the support 
> of BGP PIC does not mean that he will get the benefit in all cases. 
> There are some topology/routing architecture where the expected 
> benefits will not be collected on some platform claiming the support 
> of BGP PIC. One could say that there are multiple level of support of 
> BGP PIC. IMO this needs to be discussed in the draft, because this 
> will not be obvious to the typical reader.
>
> 2) Regarding BGP Best external, draft says
>
> “The BGP distribution of the secondary next-hop is simple thanks to
>
> the following BGP mechanisms: Add-Path [9 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-9>], 
> BGP Best-External [4 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-4>],
>
> diverse path [10 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-10>], 
> and the frequent use in VPN deployments of
>
> different VPN RD's per PE.”
>
> I disagree with “simple” for unlabeled BGP routes which have to be 
> unhidden by BGP Best External. The latter provides visibility of the 
> alternate path in the control plane, but does not allow its use in the 
> forwarding plane without an additional mechanism which is neither 
> defined in this draft, nor in BGP Best External draft.
>
> There is a problematic that the draft does solve (no problem) but also 
> does not talk about.
>
> I agree that this is not an issue related to the BGP PIC architecture, 
> but to the BGP Best External proposition.
>
> However, the draft currently says that there is no problem which is 
> not the case (for unlabeled routes).
>
> (IMHO, I would not even claim that getting the secondary route is 
> “simple” as in deployed network they may not be available (e.g. 
> Add-Path is not available or introduce a scalability impact)).
>
> I would propose the following change
>
> OLD:
>
> The BGP distribution of the secondary next-hop is simple thanks to
>
> the following BGP mechanisms: Add-Path [9 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-9>], 
> BGP Best-External [4 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-4>],
>
> diverse path [10 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-10>], 
> and the frequent use in VPN deployments of
>
> different VPN RD's per PE.
>
> NEW
>
> The BGP distribution of the secondary next-hop may require the 
> following additional mechanisms: :
>
> - Add-Path [9 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-9>] 
> or diverse path [10 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-10>], 
> or the use of per PE RD in a VPN environment or a full mush of iBGP 
> sessions. This avoid that the iBGP diffusion infrastructure filter out 
> the alternate paths.
>
> - BGP Best-External [4 
> <https://tools.ietf.org/html/draft-bashandy-rtgwg-bgp-pic-00#ref-4>] 
> on the alternate PEs to force the PE to advertise its own route, 
> although non-selected as best by BGP. This is needed in particular 
> when paths are selected based on administrative preference (e.g. BGP 
> LOCAL_PREF) rather than based on shortest path routing (aka hot potato 
> routing). However this external route is not best hence not installed 
> in the RIB nor in the FIB and hence cannot be used in the forwarding 
> plane by BGP PIC. If the route is labeled, BGP may still install the 
> label of the external router, in addition to the best route. If the 
> route is non labeled, the problem is harder and typically not solved 
> in the general case.
>
> Ideally, the above point would also need to be clarified in the BGP 
> external draft.
>
> Thanks
>
> Regards,
>
> Bruno
>
> *From:*Ahmed Bashandy (bashandy) [mailto:[e-mail]]
> *Sent**:* Thursday, October 15, 2015 7:56 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* Pradosh Mohapatra; [e-mail]
> *Subject:* Re: New Version Notification for 
> draft-bashandy-rtgwg-bgp-pic-00.txt
>
> Correct. It is similar to  "draft-rtgwg-bgp-pic-02"
>
> Let me reproduce your questions here for convenience of everyone
>
>
> > <[e-mail]> <mailto:[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] 
> <mailto:[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] <mailto:[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.
>
> _________________________________________________________________________________________________________________________
>
> 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.