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

[Ahmed Bashandy <[e-mail]>]

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:
> 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.
>
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"..
> 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.
>
AB2: Again implementation details about per-VRF "rL":) --> No comments
>>>>         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.
>
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.
>>> 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"
>
AB2: Thanks for clarifying what I want to say:)
>> 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.
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.
>
>> 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 ?
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?
>
> Anyhow to realize your scheme even if we solve major issues a network
> 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.
>> 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 ?
>
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?
>
>> 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 :) 
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?
> Thx,
> R.