Subject: [Idr] draft-ketant-idr-bgp-ls-bgp-only-fabric

From: Robert Raszuk <[email-masked]>
Date: Sun, 10 Mar 2019 17:09:44 +0100

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 :).

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 ?

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.

Kind regards,
Robert.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Mon, 11 Mar 2019 10:11:47 +0000

Hi Robert,

Please check inline below.

From: Robert Raszuk <[email-masked]>
Sent: 10 March 2019 21:40
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; [email-masked]
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

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.