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

[Ahmed Bashandy <[e-mail]>]

Thanks a lot for the comments. See Inline. Look for  "AB:"

Thanks

Ahmed

On 7/15/2012 2:46 AM, Robert Raszuk wrote:
> 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.
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.
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.
>
>
> 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
>
>>        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.
> 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.
>
>
>>   . 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 ?
AB: Again I though it is clear. But I agree with you that the bullet
needs to explain two things: what are the conditions where PHP must
advertise pNH and what are the conditions where PHP is allowed to
withdraw pNH
BTW, the statement does not imply any specific time to stop advertising
pNH and the PHP may very well continue advertising pNH for ever. IMO,
the statement is necessary to indicate that the PHP must continue to
advertise pNH after pPE disappearance for a period long enough to avoid
traffic disruption
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.
>
>
>>    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
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
>
>
>> 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 ?
AB: First, there is a small typo. The first word in the second sentence
needs to be "pPE". Second, the response to your first comment at the
beginning of this email explains the usage of "rL" with unlabeled prefixes
Now let me answer the questions about this paragraph, which I believe
they are specific to unlabeled prefixes
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"
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
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".


>
>>        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 ?
AB: The actual syntax for advertising (bgpNH,pNH) is still work in
progress. But, as I mentioned in page 9 item 2 (f), we can use a method
similar to RFC5512. The semantics (bgpNH,pNH) is explained in item 4(a)
in page 10 and in more details in the last bullet at the bottom of page 10.
>
>>        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.
>
AB: This is back to the same comment about a router understanding
multipath and associating "rL" with external paths only. As mentioned
before, at least this document requires supporting multipath.
> 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