Re: [Idr] Fwd: New Version Notification for draft-bashandy-bgp-frr-vector-label-00.txt

[Robert Raszuk <[e-mail]>]

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.

> 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