Hi Robert, Please check inline below.
From: Robert Raszuk <[email protected]> Sent: 10 March 2019 21:40 To: Ketan Talaulikar (ketant) <[email protected]> Cc: idr@ietf. org <[email protected]>; [email protected] Subject: draft-ketant-idr-bgp-ls-bgp-only-fabric Hi Ketan, I have read your proposal of defining topology flooding in BGP with interest. It seems like a pretty brilliant twist to take pieces defined in other documents with their original intention for sending IGP information (LSDB or TED) over BGP extension and now use all of those without IGP at all :). [KT] RFC7752 did always have “direct” and “static” protocols – so it was not just IGPs. We extended to include BGP protocol for describing Peering topology for the EPE use-case with draft-ietf-idr-bgpls-segment-routing-epe But I have just one question here perhaps to the WG or ADs. Almost all normative references used in this draft clearly state that they were defined for carrying information present in ISIS & OSPF protocols as rather a courtesy of transporting them over TCP with BGP envelope between network and controller. Can we now just "reuse" verbatim all of those defined codepoints as well as redefine use of BGP-LS SAFI as a new link state p2p network topology transport just like that ? [KT] The BGP-LS SAFI is still used to report link-state information. This draft describes how it can be done even when no IGP is running and we are instead running BGP protocol (in RFC7938 hop-by-hop routing design). Each router here is setting up a BGP-LS session with a controller or a centralized BGP speaker to report the router’s own node properties, links, prefixes, etc. The objective is build a link-state topology at the controller for specific use-cases like topology discovering and TE with SR as described in Sec 6 of the draft. At min I would like to see some analysis included in this draft of running native link state protocol possibly with dynamic flooding optimization vs running BGP as the only routing protocol with using BGP as topology discovery transport before we proceed further on this document. [KT] I am not sure I see the contrast here. Personally, I support the dynamic flooding optimization work in LSR. There are already DC networks deployed with RFC7938 design. All this draft is introducing is topology discovery and other use-cases in the latter. Thanks, Ketan Kind regards, Robert.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
