Another limitations with IGPs is that the adjacencies are single hop. We had proposed a solution for this for OSPF but it didn’t get a lot of momentum. It would have handled the BGP-LS requirement.
https://www.ietf.org/archive/id/draft-acee-ospf-transport-instance-03.txt From: Lsr <[email protected]> on behalf of Robert Raszuk <[email protected]> Date: Wednesday, November 7, 2018 at 7:36 PM To: "[email protected]" <[email protected]> Cc: "Les Ginsberg (ginsberg)" <[email protected]>, Tony Li <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [Lsr] IS-IS over TCP All, Again, if people think that LSVR is a good idea, then how can they think that ISIS flooding over TCP is not a good idea ? This is the base idea for our proposal. A quick look at the LSVR draft show people from Cisco, Nokia (and Arrcus). (I'm not sure what Juniper or Arista or other vendors think about using BGP-LS). I would like to make one additional observation here ... We are experiencing BGP-LS crusade (completely outside of LSVR) as there is some demand to send data carried by IGP (incl SR, TE and now even BFD extensions) to remote controllers over TCP. I am pretty sure that BGP-LS would have never started if we would have had an ability to send LSDB content over TCP day one. /* Let's put controller to controller NNI across ASes aside for a moment. */ With that to me ability to progress with TCP transport extension for ISIS (and OSPF) is actually more important then work on flooding reduction. I know it may not be a popular statement, but that is based on both looking at the operational side as well as BGP protocol side. Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
