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

[<[e-mail]>]

Hi Ahmed,

Thanks for taking my comments into account.
Looks good to me.

Bruno


From: Ahmed Bashandy (bashandy) [mailto:[e-mail]]
Sent: Monday, October 19, 2015 8:22 PM
To: DECRAENE Bruno IMT/OLN
Cc: Pradosh Mohapatra; [e-mail]
Subject: Re: New Version Notification for draft-bashandy-rtgwg-bgp-pic-00.txt

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]<mailto:[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]<mailto:[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.


_________________________________________________________________________________________________________________________

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.