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:[email protected]]
*Sent**:* Thursday, October 15, 2015 7:56 PM
*To:* DECRAENE Bruno IMT/OLN
*Cc:* Pradosh Mohapatra; [email protected]
*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
> <[email protected]> <mailto:[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]
<mailto:[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] <mailto:[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.
_________________________________________________________________________________________________________________________
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.
