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 <lsr-boun...@ietf.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Wednesday, November 7, 2018 at 7:36 PM To: "hhws...@xs4all.nl" <hhws...@xs4all.nl> Cc: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, Tony Li <tony...@tony.li>, "lsr@ietf.org" <lsr@ietf.org> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
