Re: WGLC for draft-ietf-rtgwg-bgp-pic-12

Dear Authors

I reviewed the latest draft and have a few questions.

The main goal of BGP PIC  edge is to provide faster  convergence by
advertising backup paths that normally are not advertised as with BGP best
path selection only the best path gets advertised.

BGP PIC Edge only comes into play when BGP backup path exist and for
example of BGP multipath is used then their is not any BGP backup paths.
The concept of eBGP multipath ECMP is mutually exclusive of  eBGP Backup
paths that are not valid best routes.

There are two main components of BGP PIC Edge below.

BGP Add paths is in the draft as normative reference but not included as
part of the specification.

https://tools.ietf.org/html/rfc7911

BGP Best-External flag for advertisement of backup paths:

I noticed that the BGP Best-External feature that is part of the normative
references is not included as part of the BGP PIC specification.

https://tools.ietf.org/html/draft-ietf-idr-best-external-05

How is BGP PIC Edge described very briefly in 6.2 how is it even working in
this draft without advertising the backup paths via “BGP best-external”
flag and BGP add paths capability send & receive code point enabled between
PE-RR.

I am lost how this is working but maybe I missed it somewhere.  Please
explain how the backup paths are advertised that normally don’t get
advertised without a BGP best-external type flag that advertises the edge
backup paths.

BGP PIC core for iBGP convergence utilizes H-FIB instead of default
flattened FIB for core link failure convergence so that the BGP FIB does
not have to be updated by walking the massive BGP table and instead updated
the recursive IGP next hop FIB interface and next hop is updated to new
next hop.  Here also the concept of core failures can be IGP ECMP paths
which in that case two or multiple next hops are already programmed in the
BGP FIB and corresponding recursive IGP next hop FIB so the convergence
gains with IGP ECMP case for recursive next hop is not realized with BGP
PIC Core.  The convergence is realized when IGP ECMP next hop path does not
exist and only single recursive path exits in a which case the next hop has
to change thus the old next hop and interface for down core interface had
to be updated to the next next hop backup core path.

So the drawing and any references to ECMP for both BGP PIC Edge and Core
really in mind should be removed.

Kind Regards

Gyan

On Sun, Dec 13, 2020 at 8:48 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Dear Authors
>
> I read the document and was wondering why this draft is informational and
> not standards track as this draft introduces a crucial feature of PIC edge
>  “pre programmed backup paths” and PIC core new H-FIB versus default
> flattened FIB, where core link failure does not require updating BGP FIB
> next hops making it prefix independent and only requiring updating of BGP
> recursive IGP FIB next hop for core link failure convergence onto alternate
> paths.
>
> This draft provides significant advantages for cases where BGP RIB had
> backup paths that by default are not advertised and with the “advertise
> best-external knob” and BGP “add paths” MP Reach capability PE-RR and VPN
> PIC case where RD auto is set so all paths advertises to RR are unique by
> RD and reflected so the SAFI 128 backup paths can be pre programmed.
>
> This PIC core and edge feature as is implemented by almost every vendor as
> of the last 10+ years and is used by almost every operator around the
> world, I see we are now circling back to make standard which happens in
> cases where it takes time for vendor  implementation and operator use cases
> before WGLC.   This seems to be one of those cases.
>
> As the PIC feature is a new critical feature,  it is critical that this
> feature is made standards track for vendor interoperability.  BGP PIC core
> and edge are I believe locally significant features their maybe some
> components that require interoperability it is still important to be made
> standards track.
>
> I do see that Cisco has 2 IPRs field so based on that I do feel this
>  definitely should be standards track.
>
> Date
> ID
> Statement
> 2020-11-19 4490 Cisco Systems, Inc.'s Statement about IPR related to
> draft-ietf-rtgwg-bgp-pic <https://datatracker.ietf.org/ipr/4490/>
> (Updates ID#: 4488)
> 2020-11-16 4488 Cisco Systems, Inc.'s Statement about IPR related to
> draft-ietf-rtgwg-bgp-pic <https://datatracker.ietf.org/ipr/4488/>
>
> Tot
>
> I will provide a detailed review of the draft.
>
> Kind Regards
>
> Gyan
>
> On Sun, Dec 13, 2020 at 12:38 PM Greg Mirsky <gregimirsky@gmail.com>
> wrote:
>
>> Hi,
>> I've read the document and believe it is ready for publication. Several
>> notes after the reading:
>>
>>    - authors might consider changing references to list IETF documents
>>    rather than enumerating them in the list of references. For example, use
>>    [RFC5036] instead of [4].
>>    - Because the ability to realize the described technique depends on
>>    using the specific HW, I think that should be reflected in the Abstract.
>>    Perhaps following the very last sentence:
>>
>> It is noteworthy to mention that the benefits of BGP-PIC are
>> hinged on the existence of more than one path whether as ECMP or
>> primary-backup.
>>
>>
>>    - And because, as I understand, the document describes a
>>    particular implementation, an Experimental track might be used rather than
>>    the Informational.
>>
>> Regards,
>> Greg
>>
>> On Wed, Dec 9, 2020 at 8:26 PM Jeff Tantsura <jefftant.ietf@gmail.com>
>> wrote:
>>
>>> Dear RTGWG,
>>>
>>> The authors have requested  WGLC for draft-ietf-rtgwg-bgp-pic.
>>>
>>> There was consensus that document is ready for the last call, the
>>> authors have addressed all the comments received, IPR statements have been
>>> submitted.
>>> Please indicate support or no-support by December 28, 2020.
>>>
>>> Cheers,
>>> Jeff and Chris
>>> _______________________________________________
>>> rtgwg mailing list
>>> rtgwg@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>
>> _______________________________________________
>> rtgwg mailing list
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD