Hi Ahmed,
> Thanks a lot for the comments. See Inline. Look for "AB:"
You are welcome ;)
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.
>
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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"
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.
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.
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
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.
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"
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.
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
ok.
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".
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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
