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

From: Jeff Tantsura <[email-masked]>
Date: Wed, 9 Dec 2020 20:26:30 -0800

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

---

From: Vladimir Blazhkun <[email-masked]>
Date: Thu, 10 Dec 2020 14:57:27 +0300

Strongly support ;)

-- 
Vladimir Blazhkun (via iPhone).

> On 10 Dec 2020, at 07:26, Jeff Tantsura <[email-masked]> wrote:
> 
> 
> Dear RTGWG,
> 
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 12 Dec 2020 19:38:39 +0000

I support publication. Looks like mainly editorial changes since the last time it was WG last called.
Thanks,
Acee

From: rtgwg <[email-masked]> on behalf of Jeff Tantsura <[email-masked]>
Date: Wednesday, December 9, 2020 at 11:26 PM
To: Routing WG <[email-masked]>
Cc: Routing WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: WGLC for draft-ietf-rtgwg-bgp-pic-12

Dear RTGWG,

Cheers,
Jeff and Chris

---

From: Ahmed Bashandy <[email-masked]>
Date: Sun, 13 Dec 2020 07:19:10 -0800

As a coauthor, I support the publication of this document

Ahmed

On Sat, Dec 12, 2020, 11:38 AM Acee Lindem (acee) <[email-masked]> wrote:

> *From: *rtgwg <[email-masked]> on behalf of Jeff Tantsura <
> [email-masked]>
> *Date: *Wednesday, December 9, 2020 at 11:26 PM
> *To: *Routing WG <[email-masked]>
> *Cc: *Routing WG <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *WGLC for draft-ietf-rtgwg-bgp-pic-12
>
>
>
> Dear RTGWG,
>
> There was consensus that document is ready for the last call, the authors
> have addressed all the comments received, IPR statements have been
> submitted.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 13 Dec 2020 09:38:09 -0800

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

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 13 Dec 2020 20:48:20 -0500

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

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 14 Dec 2020 02:06:42 -0500

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 <[email-masked]> wrote:

>>> There was consensus that document is ready for the last call, the
>>> authors have addressed all the comments received, IPR statements have been
>>> submitted.

*Gyan Mishra*