Re: Shepherd review of draft-ietf-rtgwg-bgp-pic

[Gyan Mishra <[e-mail]>]

On Sat, Jan 4, 2020 at 2:06 PM Robert Raszuk <[e-mail]> wrote:

> Gyan,
>
> I noticed in the document there is a mention in the beginning of the draft
>> regarding “best-external” but the detailed use of that knob is not
>> documented as part of BGP PIC edge functionality.
>>
>
> It does not need to be documented. Section 2.1.2 just makes is clear that
> to use BGP PIC you need more paths. How you organize your BGP such that
> multiple paths are present is beyond the scope of this draft.
>

   I was referring to the best-external flag operation and how that feature
works as far as advertisements of backup paths. Not necessarily the
organization of multiple paths.

>
> I noticed that the router reflector critical functions of selecting all
>> paths and advertising additional paths is not mentioned which is critical
>> for BGP PIC operation.
>>
>
> Use of route reflection is just a way to distribute your BGP paths. It is
> not a necessity. Moreover RRs if deployed well do not select bgp paths
> based on their view of IGP metric. Hint: Pls look at Optimal Route
> Reflection draft.
>

   Glad to see the draft and I agree keeping the state centralized is a
better design strategy then pushing state to the edge.  Also lends itself
to a centralized controller based model.

https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-19#page-6
>


> Another critical feature to mention in the draft related to route
>> reflector and BGP PIC edge functionality is that for L3 VPN vpnv4 and vpnv6
>> the route reflector is not able to advertise all paths as with IPv4 and
>> IPv6..  Workaround to this issue is that the RD must be unique for each PE
>> within the VPN
>>
>
> Unique RD per VRF is not a workaround. It is best practice for years now.
> Number of implementations allocate RDs by default (auto-rd) per VRF. Other
> deployments do it properly via NMS.
>
>
    I agree RD auto  has been a best practice for years.  I was just
pointing out that if RD auto is not employed that the issue will present
itself.  Something to be cognizant of which is why I mentioned.

>
> Also mention that PIC edge can be used independently of PIC core however
>> in most cases PIC core if the platform supports is enabled by default.  PIC
>> edge can be configured even if PIC core is not supported on the hardware
>> platform and would still improve convergence.
>>
>
> That would be a bit stating the obvious :)
>

   Understood

>
> We should also I think mention NHT next hop tracking FIB watcher and
>> basically part of using the hierarchal fib is similar to NHT feature
>> tracking the next hop PE exit points that correlate to all BGP NLRI from
>> the exit point.  For hardware platforms that don’t support hierarchical fib
>> that NHT can be used as a workaround to achieve the same convergence.
>>
>
> NHT and hierarchical FIB are completely orthogonal features. First is
> responsible to detect the failure via watching RIB updates (registers next
> hops and get's callback when IGP deletes or modifies it) while latter is
> part of the repair mechanism. There is nothing "similar" between those two
> features.
>

  Understood

>
> Also note that for PIC Core to really be beneficial that the IGP timers
>> must be optimized as well as use of IP LFA, R-LFA for ldp and BFD should be
>> configured to optimize next hop convergence.
>>
>
> Sorry - no. PIC can work fine without IGP too just using BGP recursive
> next hops. Use of any flavour of LFA helps to quickly restore connectivity
> to a given next hop - it is completely orthogonal to BGP PIC feature.
>

   Understood.  I was just stating for “optimal” convergence recommendation
which I thought was relevant since using BGP PIC is an “optimization” to
that end in achieving as close to hitless convergence.

>
>
>> Should also be noted that if exit point PEs edge uses  BGP next-hop-self
>> ; next hop rewrite to loopback ; the loopback never goes down even if PE-CE
>> failure occurs and that can impact overall convergence and this issue
>> exists for both MPLS and  IP core scenario.
>> I am trying to develop a workaround for this issue but have not found a
>> solution yet.
>>
>
> We solved this problem over 11 years ago by defining new
> Edge_Discriminator attribute. However the draft was not progressed due to
> lack of real interest and easy workaround of not setting next hop self.
>
> https://tools.ietf.org/html/draft-pmohapat-idr-fast-conn-restore-03
>

   I found that draft when I was researching and wondered why it didn’t
progress.  I do think it has a lot of merit.  Major point being that if you
don’t do the next hop self and advertise you external links now imagine
with millions of peers your LFIB FEC binding state becomes unmanageable.  I
am all for resurrection of the draft and I would support.

>
Kind regards,

Gyan

>
>
> Thx,
> Robert.
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant