Subject: Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 09 Jul 2012 11:30:08 -0700

Hi,

The draft proposes a new method for BGP FRR.

The approach is very scalable as it does not require injecting any
prefixes into the core, no re-advertisement of BGP prefixes, and no
state replication. At the same time, it is transparent to the operator
in the sense that if it is enabled by default, there is no need for
human intervention due to any reason including internal and external
topology changes or even when switching from MPLS to IP core and back

All comments are most welcomed

Thanks

Ahmed

-------- Original Message --------
Subject: 	New Version Notification for
draft-bashandy-bgp-frr-vector-label-00.txt
Date: 	Sun, 8 Jul 2012 07:05:43 -0700
From: 	<[email-masked]>
To: 	<[email-masked]>
CC: 	<[email-masked]>, <[email-masked]>

A new version of I-D, draft-bashandy-bgp-frr-vector-label-00.txt
has been successfully submitted by Ahmed Bashandy and posted to the
IETF repository.

Filename:	 draft-bashandy-bgp-frr-vector-label
Revision:	 00
Title:		 BGP FRR Protection against Edge Node Failure Using Vector Labels
Creation date:	 2012-07-07
WG ID:		 Individual Submission
Number of pages: 32
URL:             http://www.ietf.org/internet-drafts/draft-bashandy-bgp-frr-vector-label-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bashandy-bgp-frr-vector-label
Htmlized:        http://tools.ietf.org/html/draft-bashandy-bgp-frr-vector-label-00

Abstract:
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1,
PE2,..., PEn know about a prefix P/m via the external routers CE1,
CE2,..., CEm.  If the edge router PEi crashes or becomes totally
disconnected from the core, it is desirable for a core router "P"
carrying traffic to the failed edge router PEi to immediately restore
traffic by re-tunneling packets originally tunneled to PEi and
destined to the prefix P/m to one of the other edge routers that
advertised P/m, say PEj, until BGP re-converges. In doing so, it is
highly desirable to keep the core BGP-free while not imposing
restrictions on external connectivity or complicating provisioning
effort. Thus (1) a core router should not be required to learn any
BGP prefix, (2) the size of the forwarding and routing tables in the
core routers should be independent of the number of BGP prefixes, (3)
re-routing traffic without waiting for re-convergence must not cause
loops, (4) provisioning effort should be kept at minimum, and (5)
there should be no restrictions on what edge routers advertise what
prefixes. For labeled prefixes, (6) the label stack on the packet
must allow the repair PEj to correctly forward the packet and (7)
there must not be any need to perform more than one label lookup on
any edge or core router during steady state

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 15 Jul 2012 02:46:55 -0700

Hi Ahmed,

Encouraged by your kind invitation let me first try to clarify few 
things reg the proposal.

>   ii. If "rL" is per-VRF, then pop *two* labels and forward the
>       packet based on the contents under the two popped labels

I am afraid this does not work.

VRF lookup on any rPE would still contain the the original best path 
towards the PE which failed. This is for any AFI/SAFI. Remember the BGP 
best path has not executed yet to eliminate the BGP best path which can 
be influenced by local preference or MED.

Your case mistakenly assumed that locally received EBGP route always 
win, however this is not the case in BGP.

You re referring to per VRF lookup option in many places of the draft - 
that needs to be deleted. Only per-CE label where "last hop" rPE does 
not perform IP lookup may work.

>        a. Acting as a rPE, PE1 allocates (on per-CE basis) and
>           advertises a repair label rL1=3100 with the prefixes
>           10.0.0.0/8 and 11.0.0.0/8 to all iBGP peers

Another issue in your proposal is that you assume that rPE will be a 
protecting PE for everyone.

Again in BGP this is not the case as during best path iPEs will consider 
BGP next hop metric. Therefor for the identical destination the same PE 
can be rPE for some iPEs while in the same time it can be pPE for other 
iPEs.

I do not see how in any BGP today you could signal both types of labels 
(even if the label is per CE).

>   . When does the penultimate hop stop advertising pNH as its
>     own prefix? The penultimate hop should continue to
>     advertise pNH long enough for iPE's to re-converge.
>     Advertising pNH longer than necessary is harmless because
>     iPE's would have already re-converged to a new BGP next-
>     hop and hence no traffic will be attracted to the non-
>     existing pNH. The specific period length can be subject
>     to configuration but the default value may be in the
>     order of 2-3 minutes

I really do not think this section is necessary. I do not understand how 
we can stop advertising pNH from PHP node. If we stop when do we start 
again ?

>    3. Penultimate Hop
>        a. Receives a packet with top label bound to pNH
>        b. Pops *three* labels *all the time*.

Are you sure that current LSRs can pop more then one label on the stack? 
Since the early days of MPLS it was my understanding that except the 
special labels (null labels) MPLS LSRs do not POP more then one label. I 
am not sure if this is spelled out in any of the MPLS specifications, 
but I think it would be great to have some sort of assurance that this 
is doable not only in theory but also in practice

> 3. Overview of the BGP FRR using Vector Labels in an IP Core
>
>    This section describes the BGP FRR using vector labels solution in an
>    IP core for both labeled (AFI/SAFI 1/4, 2/4, 1/128, and 2/128) and
>    unlabeled (AFI/SAFI 1/1, 2/1, 1/2, and 2/2) protected prefixes.
+
>    The pPE needs to advertise the mapping (bgpNH,pNH). iPE also needs to
>    allocate a vector label for each known rPE and advertise the mapping
>    (pNH,rNH,vL)

I am not following this section. Let's consider SAFI 1/1. What is the 
"rL" if I am not running MPLS ? Same for vector label "vL" ? What 
protocol distributes those labels ?

>        a. Assume that PE0 uses "Loopback0" as the BGP next-hop, PE0
>           automatically picks Loopback2 as the pNH. As such PE0
>           advertises (bgpNH,pNH)=(1.1.1.1,1.1.1.2) to all iBGP peers
>           including the iPE PE11.

When you say that PE0 advertises pair of next hops ? How is this encoded 
? What is the semantics of this encoding ?

>        a. On receiving the repair labels 3100 and 3200 from PE1 and
>           PE2, respectively, PE0 detects that there are two rPEs: PE1
>           and PE2. AS such PE0 assigns two vector labels vL1 = 1100
>           and vL2 = 1200 to PE1 and PE2, respectively

How can PE0 receive the repair labels from PE1 and PE2 if we take SAFI 
1/1 and no add-paths ? Anyhow we do not even know that the rL is for 
SAFI 1/1 yet :) For VPNs you assume different RD per VRF. That still 
does not work as I mentioned above. The rPE will be a primary PPE for 
some ingress PEs.

Best regards,
R.

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 16 Jul 2012 16:28:50 -0700

Thanks a lot for the comments. See Inline. Look for  "AB:"

Thanks

Ahmed

On 7/15/2012 2:46 AM, Robert Raszuk wrote:
> towards the PE which failed. This is for any AFI/SAFI. Remember the
> BGP best path has not executed yet to eliminate the BGP best path
> which can be influenced by local preference or MED.
>
AB: I thought it is understandable because the draft talks about a
pre-calculated repair path. But it looks like I should say something
like: The behavior explained in this document requires the support for
multipath, such as best external or add-path.
I'll also add a statement as follows: rPE advertises "rL" with a labeled
prefix P/m only if it has an external path for the prefix and rPE is
administratively permitted to protect the prefix. For unlabeled
prefixes, rL is only needed if one of the best paths chosen by rPE is
not an external path. The label "rL" is associated with the external
path(s) only.
>
>
> You re referring to per VRF lookup option in many places of the draft
> - that needs to be deleted. Only per-CE label where "last hop" rPE
> does not perform IP lookup may work.
AB:  If I add the statement mentioning that rL is only associated with
external path, then it becomes an implementation detail to say that a
router only considers external paths for packets arriving with rL even
if the router makes an IP lookup to determine the next-hop. But I agree
with you that per-CE rL is better and simpler to implement. I will not
be so hung up on the per-VRF option if people think that per-CE is
sufficient
> protecting PE for everyone.
AB: As I mentioned above, I will add a statement mentioning that
multi-path support is required and that rPE advertises rL for prefixes
to which rPE has an external path and is administratively allowed to do so.
> Again in BGP this is not the case as during best path iPEs will
> consider BGP next hop metric. Therefor for the identical destination
> the same PE can be rPE for some iPEs while in the same time it can be
> pPE for other iPEs.
>
> I do not see how in any BGP today you could signal both types of
> labels (even if the label is per CE).
AB: I do not understand "both types" refers to which types. But anyway,
for a router support any type of fast convergence, such as BGP-PIC or
PE-CE link protection, it has to support the notion of more than one path.
> I really do not think this section is necessary. I do not understand
> how we can stop advertising pNH from PHP node. If we stop when do we
> start again ?
AB: Again I though it is clear. But I agree with you that the bullet
needs to explain two things: what are the conditions where PHP must
advertise pNH and what are the conditions where PHP is allowed to
withdraw pNH
BTW, the statement does not imply any specific time to stop advertising
pNH and the PHP may very well continue advertising pNH for ever. IMO,
the statement is necessary to indicate that the PHP must continue to
advertise pNH after pPE disappearance for a period long enough to avoid
traffic disruption
And to answer your question "If we stop when do we start again ?"  The
condition to start advertising pNH after stopping is the same condition
to start advertising pNH for the first time. So PHP will start to
advertise pNH again when gets the message (pNH) from the pPE again.
> Are you sure that current LSRs can pop more then one label on the
> stack? Since the early days of MPLS it was my understanding that
> except the special labels (null labels) MPLS LSRs do not POP more then
> one label. I am not sure if this is spelled out in any of the MPLS
> specifications, but I think it would be great to have some sort of
> assurance that this is doable not only in theory but also in practice
AB: This is a question about an implementation detail. But to keep the
answer short, it is VERY EASY for an LSR to pop 3 labels. Routers have
been doing a lot more than this at line rate for a long period of time
> protocol distributes those labels ?
AB: First, there is a small typo. The first word in the second sentence
needs to be "pPE". Second, the response to your first comment at the
beginning of this email explains the usage of "rL" with unlabeled prefixes
Now let me answer the questions about this paragraph, which I believe
they are specific to unlabeled prefixes
First question: What is "rL" if I am not running MPLS?
rL is a label that informs rPE to always send the packet to an external
path. rL has no semantics in the core at all. So the protocol running in
the core is totally irrelevant to "rL"
Second question: What is "vL" in a pure IP core?
Section 3.1 talks about the case where all core routers, including the
repairing router "rP", do not understand MPLS. In that case, vL is not
use at all. If it is mentioned, then it is probably  a mistake
Section 3.2 talks about the case where the repairing core router "rP"
understands MPLS but the rest of the core routers does not. In that
case, "vL" is used the similar to how it is used in MPLS core
Third question: What protocol distributes those labels ?
Only "vL" needs to be distributed to the core. An optional TLV in ISIS
or OSPF can be used to distribute "vL".

> When you say that PE0 advertises pair of next hops ? How is this
> encoded ? What is the semantics of this encoding ?
AB: The actual syntax for advertising (bgpNH,pNH) is still work in
progress. But, as I mentioned in page 9 item 2 (f), we can use a method
similar to RFC5512. The semantics (bgpNH,pNH) is explained in item 4(a)
in page 10 and in more details in the last bullet at the bottom of page 10.
> does not work as I mentioned above. The rPE will be a primary PPE for
AB: This is back to the same comment about a router understanding
multipath and associating "rL" with external paths only. As mentioned
before, at least this document requires supporting multipath.

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 16 Jul 2012 17:15:32 -0700

The edge-node protecting BGP-FRR solution that I am aware of is the one
described in draft-minto-2547-egress-node-fast-protection and section
5.1.8.4 in draft-ietf-mpls-seamless-mpls

I would be happy to know to learn about other ones

Thanks

Ahmed

On 7/16/2012 2:51 PM, Susan Hares wrote:
>
> Ahmed:
>
>  
>
> Can provide a short comparison of this BGP frr with past attempts for
> BGP FRR?
>
>  
>
> If you wish a list of the BGP FRR drafts, please let me know.
>
>  
>
> sue
>
>  
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Ahmed Bashandy
> *Sent:* Monday, July 09, 2012 2:30 PM
> *To:* [email-masked] List; [email-masked]
> *Cc:* Maciek Konstantynowicz (mkonstan)
> *Subject:* [Idr] Fwd: New Version Notification for
> *Subject: *
> New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt
>
> *Date: *
>
> 	
>
> Sun, 8 Jul 2012 07:05:43 -0700
>
> *From: *
>
> 	
>
> <[email-masked]> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> <[email-masked]> <mailto:[email-masked]>
>
> *CC: *
>
> 	
>
> <[email-masked]> <mailto:[email-masked]>, <[email-masked]>
> <mailto:[email-masked]>
>
>  
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Jul 2012 03:49:20 +0200

Hi Ahmed,

 > Thanks a lot for the comments. See Inline. Look for  "AB:"

You are welcome ;)

> multipath, such as best external or add-path.

Nope. Neither best external or add-paths are required for example for 
SAFI 1/128. I am not talking about path distribution at all in this point.

> administratively permitted to protect the prefix.For unlabeled

That clarification is optional. Above I am commenting on your point that 
per vrf IP lookup triggered by per-VRF label will not work in your 
solution. VRF will still point to the original best path exit.

It is my understanding that you do not keep original VRF and protected 
VRF - do you ? If you do then this needs to be clearly stated in the 
document. The content of the "protection VRF" indeed could different 
from the original VRF, but I am not sure if you are planning this.

As I said ... if the rL points outside this works .. if the rL points to 
original VRF for IP lookup it does not.

Please clarify.

> be so hung up on the per-VRF option if people think that per-CE is

Again IMHO you have just two options ..

- keep nice scaling property and _only_ bind the rL to external next 
hops (CEs)

- compromise scaling by adding new "shadow VRFs - different from primary 
VRFs and allow rL to point to such shadow VRF for local IP lookup.

> to which rPE has an external path and is administratively allowed to do so.

You are missing my point.

In the draft you say that it is on purpose that rL is different label 
then normal switching label (for example VPN label).

I am saying that if any box is advertising a prefix - it can advertise 
given BGP path only once. No best external .. no add-paths help. And 
multipath is irrelevant here completely as this term is used to indicate 
what routers installs in the forwarding.

Adding two labels for the same bgp path does not make it two paths. And 
as pointed out this is common in the networks for an exit PE to in the 
same time be primary for some ingress PEs and backup for the others.

> PE-CE link protection, it has to support the notion of more than one path.

BGP PIC or PE-CE requires the reception of more then one path. That is 
clear. Your proposal mandates advertisement of two types of exit 
switching labels (for 1/128 primary VPN label and backup rL label). In 
fact you propose to encode rL "as path attributes in MP/BGP updates"

> advertise pNH again when gets the message (pNH) from the pPE again.

You mean that when "  c. pPE advertises pNH as a prefix into IGP" right 
? Then IGP may not be impacted and may not re-advertise ... only BGP 
crashed. Then you will never start advertising the pNH.

> been doing a lot more than this at line rate for a long period of time

Perhaps it is easy. However I recall folks who invented MPLS telling me 
that you never should pop more then one level of labels. Do you know if 
currently deployed routers can do it in practice ?

Anyhow to realize your scheme even if we solve major issues a network 
wide upgrade of participating routers is mandatory.

> the core is totally irrelevant to "rL"

I am not talking about the core. I am also talking about the edge ... So 
edge must use label switching correct ?

Hint: You could have a IP tunnel endpoint terminating at the CE/NH.

> use at all. If it is mentioned, then it is probably  a mistake

ok.

> or OSPF can be used to distribute "vL".

Ahh nice .. so we are back to carrying labels in IGP .. Finally ! That 
has been proposed so many times :) Also maybe we will get the concept of 
global label rolled out in more generic way as vL is effectively and 
semantically a global label (per given IGP domain).

Thx,
R.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 16 Jul 2012 17:51:39 -0400

Ahmed:

Can provide a short comparison of this BGP frr with past attempts for BGP FRR?

sue

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ahmed Bashandy
Sent: Monday, July 09, 2012 2:30 PM
To: [email-masked] List; [email-masked]
Cc: Maciek Konstantynowicz (mkonstan)
Subject: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

Hi,

The approach is very scalable as it does not require injecting any prefixes into the core, no re-advertisement of BGP prefixes, and no state replication. At the same time, it is transparent to the operator in the sense that if it is enabled by default, there is no need for human intervention due to any reason including internal and external topology changes or even when switching from MPLS to IP core and back

Thanks

Ahmed

-------- Original Message -------- 

Subject: 

Date: 

From: 

 <mailto:[email-masked]> <[email-masked]>

To: 

 <mailto:[email-masked]> <[email-masked]>

CC: 

 <mailto:[email-masked]> <[email-masked]>,  <mailto:[email-masked]> <[email-masked]>

Abstract:

 
The IETF Secretariat

---

From: Ahmed Bashandy <[email-masked]>
Date: Thu, 19 Jul 2012 12:52:04 -0700

Hi,

May be I understood the source of confusion regarding paths
The draft does not require modifications to existing prefix
advertisements rules or implementations. All the draft is saying is that
if a prefix satisfies the conditions for attaching and advertising "rL"
and the prefix is being advertised, then rPE attaches "rL" as an
optional attribute. Satisfying or loosing the conditions for advertising
"rL" by itself has no bearing on the decision of whether a prefix should
be advertised or not. Think of "rL" as a new export RT configured on a
VRF with existing export RT in a simple VPN scenario. If the operator
adds an export RT to a VRF, the PE will re-advertise the prefixes to its
peers to inform them about the new RT that has been configured on top of
the pre-existing ones. At the same time, the operator may prohibit the
router from doing that.

Regarding diverging to implementation details, I am not prepared to
discuss any implementation details, at least at this point in time, and
I will refrain from commenting on any of them.

There are a couple of inline comments. Look for "AB2:" this time

Thanks

Ahmed

On 7/16/2012 6:49 PM, Robert Raszuk wrote:
> That clarification is optional. Above I am commenting on your point
> that per vrf IP lookup triggered by per-VRF label will not work in
> your solution. VRF will still point to the original best path exit.
>
> As I said ... if the rL points outside this works .. if the rL points
> to original VRF for IP lookup it does not.
>
AB2: I disagree with the last statement. As I mentioned before, it is
implementation details to describe how a router only considers external
path(s) for packets arriving with "rL". We're still not stuck on keeping
per-VRF "rL"..
> - compromise scaling by adding new "shadow VRFs - different from
> primary VRFs and allow rL to point to such shadow VRF for local IP
> lookup.
>
AB2: Again implementation details about per-VRF "rL":) --> No comments
> multipath is irrelevant here completely as this term is used to
> indicate what routers installs in the forwarding.
>
AB2: As mentioned at the beginning of the email, the draft never
indicated that it requires changes to BGP prefix advertisement rules or
implementations. All the draft is saying that "rL" can be attached to
advertised prefixes if the PE can and is willing to act as a repair PE

> Adding two labels for the same bgp path does not make it two paths. 
AB2: Adding "rL" has no bearing on the number of paths. Adding "rL" to a
prefix indicates to iPEs and pPEs that the advertising PE is willing to
act as a repair PE for the prefix

> And as pointed out this is common in the networks for an exit PE to in
> the same time be primary for some ingress PEs and backup for the others.
AB: Why do you think that there is a problem if the same ePE is primary
for some iPEs and repair for others? In fact item 3(a) at the bottom pf
page 9 covers this this case. If there some scenarios where being a
primary and repair at the same time causes problems or does not work, it
would be very helpful to point them out.
> fact you propose to encode rL "as path attributes in MP/BGP updates"
AB2: Thanks for clarifying what I want to say:)
> You mean that when "  c. pPE advertises pNH as a prefix into IGP"
> right ? Then IGP may not be impacted and may not re-advertise ... only
> BGP crashed. Then you will never start advertising the pNH.
AB2: No, I do not mean IGP. I mean a special advertisement. Item 2 (e)
mentions that. For example, an optional TLV in LDP can be used to
advertise this special IP address to the PHP.
> Perhaps it is easy. However I recall folks who invented MPLS telling
> me that you never should pop more then one level of labels. Do you
> know if currently deployed routers can do it in practice ?
AB2: I already answered the question "Do you know if currently deployed
routers can do it in practice ? " when I said "it is VERY EASY". I will
not comment any further because this is  implementation details.
Regarding popping more than one label, routers have been doing that for
a very long time. For example, a PE that advertises an explicit label
(instead of implicit null) for the BGP next-hop. Besides, is there an
RFC that explicitly prohibits a router from popping more than one label?
> wide upgrade of participating routers is mandatory.
AB2: This is incorrect. The scheme can be incrementally deployed few
routers at a time. For example, one iPE, one rP and two ePEs.
> I am not talking about the core. I am also talking about the edge ...
> So edge must use label switching correct ?
>
AB2: This draft expects a PE to understand MPLS. PEs that do not support
MPLS are not covered by this draftt. IP core means only core routers.
> Hint: You could have a IP tunnel endpoint terminating at the CE/NH.
AB2: The draft never claimed that it works in all scenarios (and no
document should be making this claim). But for this particular scenario,
can you provide more clarification?
> has been proposed so many times :) 
AB2: So I heard:) So one more time would not be so weird:)
> Also maybe we will get the concept of global label rolled out in more
> generic way as vL is effectively and semantically a global label (per
> given IGP domain).
AB2: Another misunderstanding. The semantics of "vL" are not global. Is
there a place in the draft where it is implied that "vL" has global
semantics in an IGP domain?

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Jul 2012 08:39:42 +0200

Ahmed,

> optional attribute.

To the best of my knowledge today we do not have a defined attribute in 
BGP to carry MPLS labels. If you are proposing a solution which does not 
have corresponding encoding in the protocol you intend to use I think 
you are going a wrong way.

> I will refrain from commenting on any of them.

That's neat :) While you may claim that everything is an implementation 
detail I think you should not be stating as an advantage of your 
proposal the following:

"   o  Very scalable:
        o No router has to copy the routing table of another router"

> advertised prefixes if the PE can and is willing to act as a repair PE

Than your solution is broken. You must at min enable best external to 
cover the case where the VPN chooses by local preference or med 
different exit point as best path. If you do not enable best external or 
add-paths your repair paths will not get advertised.

> routers at a time. For example, one iPE, one rP and two ePEs.

That was correct. Pls notice what I said: "participating routers". Do 
you expect iPE, rP and two ePEs all be from the same vendor and same OS 
branch supporting your feature ???

> can you provide more clarification ?

I am afraid this is an implementation detail how you organize the packet 
switching after termination of the IP tunnel.

Rgs,
R.

---

From: Ahmed Bashandy <[email-masked]>
Date: Fri, 20 Jul 2012 18:17:42 -0700

Robert,
See comments inline. This time look for "AB3:"

Thanks

Ahmed

On 7/19/2012 11:39 PM, Robert Raszuk wrote:
> To the best of my knowledge today we do not have a defined attribute
> in BGP to carry MPLS labels. If you are proposing a solution which
> does not have corresponding encoding in the protocol you intend to use
> I think you are going a wrong way.
AB3: You are rushing things too fast:) We're still discussing the idea.
The syntax of the new attribute will come at later versions. I hope you
do not think that the whole solution is wrong just because I did not put
the syntax of the attribute in the first version.
> That's neat :) While you may claim that everything is an
> implementation detail I think you should not be stating as an
> advantage of your proposal the following:
>
> "   o  Very scalable:
AB3: So either I diverge into implementations or blindly accept what
should be kept in the draft and what should not. If I were to suggest
the above modification, I would make a it more scientific by taking a
closer  look at the draft and trying to corroborate the suggestion by
finding one or more deployment scenarios where one router needs to copy
the routing table of another.
> Than your solution is broken. 
AB3: No it is not. You do not have a full understanding of the draft
> You must at min enable best external to cover the case where the VPN
> chooses by local preference or med different exit point as best path.
> If you do not enable best external or add-paths your repair paths will
> not get advertised.
AB3: I am not sure why you insist on pushing path selection and
advertisement down the throat of the draft. The conditions for
advertising "rL" are clear. What you just suggested is one way to
satisfy the conditions in a certain scenario. BGP-PIC edge and PE-CE
link protection are other scenarios where the conditions of advertising
"rL" are satisfied without best external or add-path.
> That was correct. Pls notice what I said: "participating routers".
AB3: IMHO, if a network has thousands of routers, it is hard to label
updating 4 routers as "network wide"
>
> Do you expect iPE, rP and two ePEs all be from the same vendor and
> same OS branch supporting your feature ???
AB3: Ah. So now we're taking the discussion of implementation details to
the level of feature release and router sales:)
> I am afraid this is an implementation detail how you organize the
> packet switching after termination of the IP tunnel.
AB3: Excellent, so I see an agreement to avoid implementation details:).

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 21 Jul 2012 19:28:10 +0200

Hi Ahmed,

Since you seem to be skipping answering some questions in your replies 
let me ask (well repeat) one question at a time.

Question:

How are you going to propagate any information in iBGP from repair PEs 
to ingress PEs considering that overall best path for this prefix is 
advertised by some other protected PE ?

Are you mandating that your solution is deployable only with use of one 
of the following techniques:

- add-paths on rPEs, RRs & iPEs
- best-external on rPEs + add-paths on RRs & iPEs
- best-external on rPEs + diverse-path on RRs
- full mesh of iPEs & rPEs with best external

(I am skipping cluster external option on RRs as in the control plane 
only RRs which are randomly located this may be a bit difficult to 
provision).

Scenario clarification:

I am talking about case where pPE chooses the best path based on local 
preference or MED.

The only comment I found related to the above is in the introduction:

    In modern networks, it is not uncommon to have a prefix reachable
    via multiple edge routers. One example is the best external path
    [8].

The reason for such fundamental question is that architectures which do 
not require at the service level participation of ingress routers and 
repair routers in the protection may be chosen over the one which does 
(your proposal).

Rgs,
R.

---

From: Ahmed Bashandy <[email-masked]>
Date: Mon, 23 Jul 2012 18:48:25 -0700

It looks like I am going to re-iterate some of the statements that you
seem to avoid (I don't know why)

See replies inline. Look for AB4

Thanks

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] Sent: Saturday, July 21,
2012 10:28 AM
To: Ahmed Bashandy (bashandy)
Cc: [email-masked] List; [email-masked]; Maciek Konstantynowicz (mkonstan)
Subject: Re: [Idr] Fwd: New Version Notification for
draft-bashandy-bgp-frr-vector-label-00.txt

Hi Ahmed,

Question:

AB4: Quotation from the first reply (AB:) "The behavior explained in
this document requires the support for multipath". More explicit
statement: how to satisfy the multipath requirement is deliberately left
out of the draft.

AB4: No. The draft does NOT mandate particular multipath technique(s).
This is a question that is already answered. Here is a quotation from
the previous email (AB3:) "What you just suggested is one way to satisfy
the conditions in a certain scenario. BGP-PIC edge and PE-CE link
protection are other scenarios where the conditions of advertising "rL"
are satisfied without best external or add-path."

Scenario clarification:

AB4: So all these questions are alluding to a comparison:) A more direct
question, like what Susan asked, would have been easier to answer. IMHO
comparison with other techniques is more befitting an informational draft.

For the participation of iPE and rPE, I have a comment and a request
- BGP-PIC edge is a deployed solution that requires iPE participation.
So it seems like other factors, such as scalability, transparency to
operators, and simplified provisioning and management, are as important
in deployment decisions
- For rPE participation, I would be very happy if you point me to a
paper/draft/implemented/deployed or about to be implemented/deployed
BGP-FRR technique (that rely on local failure detection and traffic
re-routing when an ePE fails) that does not require the participation of
rPE. That would also help with Susan's request.

Rgs,
R.