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

[Gyan Mishra <[e-mail]>]

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

> Hi Gyan,
>
>    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.
>>
>
> Best external is covered already in
> https://tools.ietf.org/html/draft-ietf-idr-best-external-05 Honestly I am
> not sure what "flag" are you referring to.
>

    I’m good as it’s already documented in another draft.  Maybe good to
add as reference.

>
>    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
>>>
>>
> I think it would be good not to mix two things. Optimal reflection chooses
> N optimal paths for given client and group of clients. Those for PIC to
> work still need to be distributed to the edges in any network which uses
> encapsulation.
>
> For networks using IP lookup based routing BGP PIC can be used on ABRs
> possibly also acting as physical or virtual RRs.
>

    Thanks for clarification

>
>
>>     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.
>>
>
> Great that we seems to agree on RD best practice. Again for this draft ie
> BGP PIC to be able to work redundant paths must be present.
>
> /* We considered just sending multiple next hops for non VPN use cases
> effectively also allowing to construct bundle rewrites with BGP PIC, but
> then add-paths came as "the solution" which overruled alternatives :) */
>

   Makes sense

>
> 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.
>>
>
> Your point is sound and indeed many networks (or vendors) today do not
> even employ basic IGP or BGP PIC. In fact many folks still care about speed
> of IGP or BGP *convergence* instead of focusing on fast connectivity
> restoration objective leaving protocols in peace allowing them to converge
> at their own pace.
>
> But I don't think that current draft in question is the best place for
> such education :)
>

   Agreed

>
>    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.
>>
>
> Well I do not know any network with millions of peers :) But I am always
> open to learn !
>
> Said this I do still see some value in moving fwd with this draft. If
> other think this is useful we could restart this as a separate IDR/GROW
> thread.
>

    Let me know I would be happy to collaborate with you on the restart.

>
> Thx,
> R.
>
> --

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