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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg >> > _______________________________________________ > rtgwg mailing list > [email protected] > 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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
