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

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Wed, 14 Oct 2015 02:12:16 -0700

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-masked]>
To: 	Clarence Filsfils <[email-masked]>, Ahmed Bashandy 
<[email-masked]>, Prodosh Mohapatra <[email-masked]>, "Pradosh 
Mohapatra" <[email-masked]>

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

---

From: <[email-masked]>
Date: Wed, 14 Oct 2015 09:38:53 +0000

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-masked]] On Behalf Of Ahmed Bashandy (bashandy)
Sent: Wednesday, October 14, 2015 11:12 AM
To: [email-masked]
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

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

To:

Clarence Filsfils <[email-masked]><mailto:[email-masked]>, Ahmed Bashandy <[email-masked]><mailto:[email-masked]>, Prodosh Mohapatra <[email-masked]><mailto:[email-masked]>, "Pradosh Mohapatra" <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:     00

Title:        Abstract

Pages:        19

Abstract:

provisioning effort

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.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 15 Oct 2015 10:56:24 -0700

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

Let me reproduce your questions here for convenience of everyone

 > <[email-masked]> Mon, 22 October 2012 14:28 UTCShow header

 > 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).
 > Regards,

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-masked] 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.
>
> 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-masked]] *On Behalf Of *Ahmed 
> Bashandy (bashandy)
> *Sent:* Wednesday, October 14, 2015 11:12 AM
> *To:* [email-masked]
> *Cc:* Pradosh Mohapatra
> *Subject:* Fwd: New Version Notification for 
> draft-bashandy-rtgwg-bgp-pic-00.txt
>
> Hi
>
> 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
>
> *Subject: *
> *Date: *
> *From: *
> <[email-masked]> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Clarence Filsfils <[email-masked]> <mailto:[email-masked]>, 
> Ahmed Bashandy <[email-masked]> <mailto:[email-masked]>, 
> Prodosh Mohapatra <[email-masked]> <mailto:[email-masked]>, 
> "Pradosh Mohapatra" <[email-masked]> <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Fri, 16 Oct 2015 07:57:11 +0000

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-masked]]
Sent: Thursday, October 15, 2015 7:56 PM
To: DECRAENE Bruno IMT/OLN
Cc: Pradosh Mohapatra; [email-masked]
Subject: Re: New Version Notification for draft-bashandy-rtgwg-bgp-pic-00.txt

> <[email-masked]><mailto:[email-masked]> Mon, 22 October 2012 14:28 UTCShow header

> 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-masked]<mailto:[email-masked]> wrote:
Hi Ahmed,

Thanks,
Bruno

From: rtgwg [mailto:[email-masked]] On Behalf Of Ahmed Bashandy (bashandy)
Sent: Wednesday, October 14, 2015 11:12 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Pradosh Mohapatra
Subject: Fwd: New Version Notification for draft-bashandy-rtgwg-bgp-pic-00.txt

Hi

Please take a look

Thanks

Ahmed

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:      00

Title:         Abstract

Pages:         19

Abstract:

provisioning effort

The IETF Secretariat

Thank you.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Mon, 19 Oct 2015 11:22:25 -0700

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, [email-masked] 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.
>
> 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.
>
> 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
>
> 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.
>
> I agree that this is not an issue related to the BGP PIC architecture, 
> but to the BGP Best External proposition.
>
> (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)).
>
> 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
>
> - 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.
>
> *From:*Ahmed Bashandy (bashandy) [mailto:[email-masked]]
> *Sent**:* Thursday, October 15, 2015 7:56 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* Pradosh Mohapatra; [email-masked]
> *Subject:* Re: New Version Notification for 
> > <[email-masked]> <mailto:[email-masked]> Mon, 
> 22 October 2012 14:28 UTCShow header
>
> > Hi Ahmed,
>
> 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
> 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
>
> On 10/14/2015 2:38 AM, [email-masked] 
> <mailto:[email-masked]> 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.
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* Pradosh Mohapatra
>     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
>
>     Clarence Filsfils <[email-masked]>
>     <mailto:[email-masked]>, Ahmed Bashandy <[email-masked]>
>     <mailto:[email-masked]>, Prodosh Mohapatra
>     <[email-masked]> <mailto:[email-masked]>, "Pradosh
>     Mohapatra" <[email-masked]> <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Tue, 20 Oct 2015 13:05:59 +0000

Hi Ahmed,

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

Bruno

Sent: Monday, October 19, 2015 8:22 PM

Bruno

- 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, [email-masked]<mailto:[email-masked]> wrote:
Hi Ahmed,

Thanks for your answer.

NEW

Thanks
Regards,
Bruno

Cc: Pradosh Mohapatra; [email-masked]<mailto:[email-masked]>

For the second question

Thanks

Ahmed

Thanks,
Bruno

Hi

Please take a look

Thanks

Ahmed

-------- Original Message --------
Subject:

Date:

From:

To:

IETF repository.

Revision:       00

Title:          Abstract

Pages:          19

Abstract:

provisioning effort

The IETF Secretariat

Thank you.

Thank you.