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

[Robert Raszuk <[e-mail]>]

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.