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
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
